From: Braydon Fuller <braydon@purse•io>
To: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] Chain width expansion
Date: Thu, 10 Oct 2019 09:16:16 -0700 [thread overview]
Message-ID: <e9c5e519-ea8a-f0e2-d8fb-c955b5c2de40@purse.io> (raw)
In-Reply-To: <CAE-z3OV_LL+Jww3e=gO6t=02VW7m9PK+8EaYoEVLy9NKNMiSaQ@mail.gmail.com>
On 10/4/19 4:31 PM, Tier Nolan via bitcoin-dev wrote
> [..] At root, the requirement is that peers can prove their total chain POW. [...]
Indeed, it's currently necessary to receive all of the chain headers to
determine. It would be interesting to have a succinct chainwork proof
for all cases. Chainwork being a sum of the total proof-of-work in a
chain. Such proofs currently only require a few headers for common cases
and the other cases can be identified.
> In regard to your proposal, I think the key is to limit things by peer, rather than globally. [...]
Yeah, there should be enough width available for every active
connection, only one chain of headers is requested at a time per peer.
Peer based limiting is susceptible to Sybil attacks; A peer could
broadcast a few low-work header chains, reconnect and repeat ad nauseam.
The delay for the next set of headers is based on the chainwork of the
last received headers from the peer. The peer could change identity and
run into the same limit. The unrequested header rate is tracked per peer.
A header chain with more chainwork will be requested at a faster rate
than a header chain with less chainwork. The chainwork is compared to
the current fully validated chain. Honest peers with more chainwork will
have a time advantage over dishonest peers with less chainwork.
For example, let's assume a case that the initial chain of headers was
dishonest and with low chainwork. The initial block download retrieves
the header chain from a single loader peer first. Once recent time is
reached, header chains are downloaded from all outgoing peers. A single
honest peer will have an advantage over many dishonest peers. Thus, as
you have mentioned, there is a security assumption that there is at
least one connected honest node.
next prev parent reply other threads:[~2019-10-10 16:16 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-04 0:38 Braydon Fuller
2019-10-04 8:20 ` David A. Harding
2019-10-04 19:51 ` Braydon Fuller
2019-10-11 21:24 ` Braydon Fuller
2019-10-04 23:31 ` Tier Nolan
2019-10-10 16:16 ` Braydon Fuller [this message]
2019-10-12 16:27 ` Tier Nolan
2019-10-12 17:56 ` Joachim Strömbergson
2019-10-12 20:46 ` Tier Nolan
2019-10-16 19:07 ` Braydon Fuller
2019-10-15 0:42 ` Braydon Fuller
2019-10-15 7:20 ` Joachim Strömbergson
2019-10-15 8:12 ` Braydon Fuller
2019-10-15 15:50 ` Joachim Strömbergson
2019-10-16 19:25 ` Braydon Fuller
2019-10-15 18:30 ` Tier Nolan
2019-10-15 0:38 ` Braydon Fuller
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=e9c5e519-ea8a-f0e2-d8fb-c955b5c2de40@purse.io \
--to=braydon@purse$(echo .)io \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.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