📅 Original date posted:2014-05-24
📝 Original message:Hi,
On this list there has been some discussion around techniques to speed up
block propagation, with a particular focus on reducing the extra orphan
risk carried by larger blocks.
The current store-and-forward method means that larger blocks will
propagate with higher latency. One proposed solution has been to broadcast
two separate messages: a fast, fixed-size header message, and a 2nd, slower
body message containing the full block. Whilst this allows larger blocks
to compete equally with smaller blocks on the "which came first" rule, it
creates a new area of uncertain delay between receiving the header, and
receiving the body, where there may be perverse incentives to mine empty
blocks on top of not-yet-valid headers.
So I would like to propose another method which is hopefully a less
significant change to the existing protocol rules, but should help reduce
the latency gap between large and small blocks.
* Skip the inv/getdata sequence for new blocks - just push them out
directly to save 1 roundtrip per hop
* When receiving a new block from a peer, as soon as we have the first 80
bytes (header) we can validate the PoW and, with only a low-level change to
the networking code, begin streaming that block to our peers (in the style
of cut-through switching).
* No other rules need to change. Block primacy can still be determined as
of the moment they are fully validated and accepted, but now the latency
caused by larger blocks is only (1 * BlockSize * BottleneckHopSpeed),
instead of (Sum[n=0 to NumHops](BlockSize * NodeBandwidth(n))).
* As far as I can tell, this shouldn't change any game theory or incentives
because nodes still receive blocks exactly as they do now, just sooner.
The difference is, invalid blocks that meet the PoW will be broadcast to
everyone, but this is nothing new since someone can peer with you and send
you an invalid block already. Network DoS should not be a possibility
since it is very expensive to make invalid blocks that meet network PoW.
Thoughts?
Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140524/62e3e230/attachment.html>;
Ashley Holman [ARCHIVE] /
npub14g…u4vq6
2023-06-07 15:22:03
in reply to nevent1q…phv7
Author Public Key
npub14gv4tc4w0zkzyrfa5u2gvsajqlf3cgevux3xth46ukfrnqlcl8xqru4vq6Published at
2023-06-07 15:22:03Event JSON
{
"id": "0d70412b45485fc0b85505821927ecb7726bc1aa339bdc6723809c7b5a9e884b",
"pubkey": "aa1955e2ae78ac220d3da7148643b207d31c232ce1a265debae5923983f8f9cc",
"created_at": 1686151323,
"kind": 1,
"tags": [
[
"e",
"db0c94828eb521bd60e5a762540ad2fb3c4dc34552a9817c80dbbcb4c4cf34fe",
"",
"reply"
],
[
"p",
"a23dbf6c6cc83e14cc3df4e56cc71845f611908084cfe620e83e40c06ccdd3d0"
]
],
"content": "📅 Original date posted:2014-05-24\n📝 Original message:Hi,\n\nOn this list there has been some discussion around techniques to speed up\nblock propagation, with a particular focus on reducing the extra orphan\nrisk carried by larger blocks.\n\nThe current store-and-forward method means that larger blocks will\npropagate with higher latency. One proposed solution has been to broadcast\ntwo separate messages: a fast, fixed-size header message, and a 2nd, slower\nbody message containing the full block. Whilst this allows larger blocks\nto compete equally with smaller blocks on the \"which came first\" rule, it\ncreates a new area of uncertain delay between receiving the header, and\nreceiving the body, where there may be perverse incentives to mine empty\nblocks on top of not-yet-valid headers.\n\nSo I would like to propose another method which is hopefully a less\nsignificant change to the existing protocol rules, but should help reduce\nthe latency gap between large and small blocks.\n\n* Skip the inv/getdata sequence for new blocks - just push them out\ndirectly to save 1 roundtrip per hop\n* When receiving a new block from a peer, as soon as we have the first 80\nbytes (header) we can validate the PoW and, with only a low-level change to\nthe networking code, begin streaming that block to our peers (in the style\nof cut-through switching).\n* No other rules need to change. Block primacy can still be determined as\nof the moment they are fully validated and accepted, but now the latency\ncaused by larger blocks is only (1 * BlockSize * BottleneckHopSpeed),\ninstead of (Sum[n=0 to NumHops](BlockSize * NodeBandwidth(n))).\n* As far as I can tell, this shouldn't change any game theory or incentives\nbecause nodes still receive blocks exactly as they do now, just sooner.\n The difference is, invalid blocks that meet the PoW will be broadcast to\neveryone, but this is nothing new since someone can peer with you and send\nyou an invalid block already. Network DoS should not be a possibility\nsince it is very expensive to make invalid blocks that meet network PoW.\n\nThoughts?\n\nThanks\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140524/62e3e230/attachment.html\u003e",
"sig": "0144e087f5750d0a2ccd5c199241c52471978989202c68e29baeebaeb821dc771bed5230696b8325f2806c5fa58e00e67dbc32761268884cd8b9d782fe6a56d6"
}