Re: [bitcoin-dev] Chain width expansion

[Braydon Fuller <braydon@purse.io>]

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.