public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Kalle Rosenbaum <kalle@rosenbaum.se>
To: bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: [bitcoin-dev] Why not witnessless nodes?
Date: Mon, 18 Dec 2017 09:32:23 +0100	[thread overview]
Message-ID: <CAPswA9ycPdTtm9PeD5a2R36cZ46HwnkwJu06FXuoE-F5Dx+eZQ@mail.gmail.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 1811 bytes --]

Dear list,

I find it hard to understand why a full node that does initial block
download also must download witnesses if they are going to skip
verification anyway. If my full node skips signature verification for
blocks earlier than X, it seems the reasons for downloading the
witnesses for those blocks are:

* to be able to send witnesses to other nodes.

* to verify the witness root hash of the blocks

I suppose that it's important to verify the witness root hash because
a bad peer may send me invalid witnesses during initial block
download, and if I don't verify that the witness root hash actually
commits to them, I will get banned by peers requesting the blocks from
me because I send them garbage.

So both the reasons above (there may be more that I don't know about)
are actually the same reason: To be able to send witnesses to others
without getting banned.

What if a node could chose not to download witnesses and thus chose to
send only witnessless blocks to peers. Let's call these nodes
witnessless nodes. Note that witnessless nodes are only witnessless
for blocks up to X. Everything after X is fully verified.

Witnessless nodes would be able to sync faster because it needs to
download less data to calculate their UTXO set. They would therefore
more quickly be able to provide full service to SPV wallets and its
local wallets as well as serving blocks to other witnessless nodes
with same or higher assumevalid block. For witnessless nodes with
lower assumevalid they can serve at least some blocks. It could also
serve blocks to non-segwit nodes.

Do witnessless nodes risk dividing the network in two parts, one
witnessless and one with full nodes, with few connections between the
parts?

So basically, what are the reasons not to implement witnessless
nodes?

Thank you,
/Kalle

[-- Attachment #2: Type: text/html, Size: 2330 bytes --]

             reply	other threads:[~2017-12-18  8:32 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-18  8:32 Kalle Rosenbaum [this message]
2017-12-18 12:11 ` [bitcoin-dev] Why not witnessless nodes? Ozgur
2017-12-18 12:43 ` Eric Voskuil
2017-12-18 13:35   ` Kalle Rosenbaum
2017-12-18 16:19     ` Eric Voskuil
2017-12-18 17:30       ` Mark Friedenbach
2017-12-18 21:27         ` Kalle Rosenbaum
2017-12-18 21:58           ` Eric Voskuil
2017-12-18 20:34       ` Kalle Rosenbaum
2017-12-18 20:42 ` Gregory Maxwell
2017-12-18 21:51   ` Kalle Rosenbaum

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAPswA9ycPdTtm9PeD5a2R36cZ46HwnkwJu06FXuoE-F5Dx+eZQ@mail.gmail.com \
    --to=kalle@rosenbaum.se \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox