public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Eric Voskuil <eric@voskuil•org>
To: Kalle Rosenbaum <kalle@rosenbaum•se>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Why not witnessless nodes?
Date: Mon, 18 Dec 2017 11:19:34 -0500	[thread overview]
Message-ID: <A2B6418E-069F-476A-86EE-638C6D9E826A@voskuil.org> (raw)
In-Reply-To: <CAPswA9zo1dLYHP9A+xrYLsrFO5GVYFqVLQC-A9uHQSCie7xeYg@mail.gmail.com>

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

You can't know (assume) a block is valid unless you have previously validated the block yourself. But in the case where you have, and then intend to rely on it in a future sync, there is no need for witness data for blocks you are not going to validate. So you can just not request it. 

However you will not be able to provide those blocks to nodes that *are* validating; the client is pruned and therefore not a peer (cannot reciprocate). (An SPV client is similarly not a peer; it is a more deeply pruned client than the witnessless client.)

There is no other reason that a node requires witness data. SPV clients don't need it as it is neither require it to verify header commitment to transactions nor to extract payment addresses from them.

The harm to the network by pruning is that eventually it can become harder and even impossible for anyone to validate the chain. But because you are fully validating you individually remain secure, so there is no individual incentive working against this system harm.

e

> On Dec 18, 2017, at 08:35, Kalle Rosenbaum <kalle@rosenbaum•se> wrote:
> 
> 2017-12-18 13:43 GMT+01:00 Eric Voskuil <eric@voskuil•org>:
>> 
>> > On Dec 18, 2017, at 03:32, Kalle Rosenbaum via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
>> >
>> > 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.
>> 
>> Why run a full node if you are not going to verify the chain?
> 
> I meant to say "I find it hard to understand why a full node that does initial block
> download also must download witnesses when it is going to skip verification of the witnesses anyway."
> 
> I'm referring to the "assumevalid" feature of Bitcoin Core that skips signature verification up to block X. Or have I misunderstood assumevalid?
> 
> /Kalle
>  
>> 
>> > 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
>> > _______________________________________________
>> > bitcoin-dev mailing list
>> > bitcoin-dev@lists•linuxfoundation.org
>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 

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

  reply	other threads:[~2017-12-18 16:19 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-18  8:32 Kalle Rosenbaum
2017-12-18 12:11 ` Ozgur
2017-12-18 12:43 ` Eric Voskuil
2017-12-18 13:35   ` Kalle Rosenbaum
2017-12-18 16:19     ` Eric Voskuil [this message]
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=A2B6418E-069F-476A-86EE-638C6D9E826A@voskuil.org \
    --to=eric@voskuil$(echo .)org \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    --cc=kalle@rosenbaum$(echo .)se \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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