From: Kalle Rosenbaum <kalle@rosenbaum.se>
To: Gregory Maxwell <greg@xiph.org>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Why not witnessless nodes?
Date: Mon, 18 Dec 2017 22:51:40 +0100 [thread overview]
Message-ID: <CAPswA9xurB=RJq4z1pJxkLN+ojSccf+T5nK4YJh2eAwwpb7r9A@mail.gmail.com> (raw)
In-Reply-To: <CAAS2fgRuLWbQLw=2EQEODGHOp0=OrLkGguw=jJSCpQXEC_P+hQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2810 bytes --]
Hi Greg,
2017-12-18 21:42 GMT+01:00 Gregory Maxwell <greg@xiph.org>:
> Because it would make no meaningful difference now,
Sure.
> and if you are not
> going to check the history
I'm not going to do any less checks than a node running with assumevalid.
Well not exactly true, because a node running today with assumevalid will
verify the witness root hash, right?
> there are much more efficient things to
> do-- like not transfer it at all.
>
I'm not sure what you are referring to.
Thank you
/Kalle
>
> On Mon, Dec 18, 2017 at 8:32 AM, 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. 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: 4452 bytes --]
prev parent reply other threads:[~2017-12-18 21:51 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-18 8:32 [bitcoin-dev] Why not witnessless nodes? 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
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 [this message]
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='CAPswA9xurB=RJq4z1pJxkLN+ojSccf+T5nK4YJh2eAwwpb7r9A@mail.gmail.com' \
--to=kalle@rosenbaum.se \
--cc=bitcoin-dev@lists.linuxfoundation.org \
--cc=greg@xiph.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