public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
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 --]

      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 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$(echo .)se \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    --cc=greg@xiph$(echo .)org \
    /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