Suhas Daftuar [ARCHIVE] on Nostr: š Original date posted:2015-09-24 š Original message:Hi, I'm proposing the ...
š
Original date posted:2015-09-24
š Original message:Hi,
I'm proposing the addition of a new, optional p2p message to help improve
the way blocks are announced on the network. The draft BIP is available
here and pasted below:
https://gist.github.com/sdaftuar/465bf008f0a4768c0def
The goal of this p2p message is to facilitate nodes being able to
optionally announce blocks with headers messages rather than with inv's,
which is particularly beneficial since the introduction of headers-first
download in Bitcoin Core 0.10. In particular, this allows for more
efficient propagation of reorgs as it would eliminate a round trip in
network communication.
The implementation of this BIP (which includes code to directly fetch
blocks based on announced headers) is in
https://github.com/bitcoin/bitcoin/pull/6494. For additional background,
please also see https://github.com/bitcoin/bitcoin/issues/5982.
Note that this new p2p message is optional; nodes can feel free to ignore
and continue to use inv messages to announce new blocks.
Thanks to Pieter Wuille for suggesting this idea.
Draft BIP text:
<pre>
BIP: <unassigned>
Title: sendheaders message
Author: Suhas Daftuar <sdaftuar at chaincode.com>
Status: Draft
Type: Standards Track
Created: 2015-05-08
</pre>
==Abstract==
Add a new message, "sendheaders", which indicates that a node prefers to
receive new block announcements via a "headers" message rather than an
"inv".
==Motivation==
Since the introduction of "headers-first" downloading of blocks in 0.10,
blocks will not be processed unless
they are able to connect to a (valid) headers chain. Consequently, block
relay generally works
as follows:
# A node (N) announces the new tip with an "inv" message, containing the
block hash
# A peer (P) responds to the "inv" with a "getheaders" message (to request
headers up to the new tip) and a "getdata" message for the new tip itself
# N responds with a "headers" message (with the header for the new block
along with any preceding headers unknown to P) and a "block" message
containing the new block
However, in the case where a new block is being announced that builds on
the tip, it would be generally more efficient if the node N just announced
the block header for the new block, rather than just the block hash, and
saved the peer from generating and transmitting the getheaders message (and
the required block locator).
In the case of a reorg, where 1 or more blocks are disconnected, nodes
currently just send an "inv" for the new tip. Peers currently are able to
request the new tip immediately, but wait until the headers for the
intermediate blocks are delivered before requesting those blocks. By
announcing headers from the last fork point leading up to the new tip in
the block announcement, peers are able to request all the intermediate
blocks immediately.
==Specification==
# The sendheaders message is defined as an empty message where pchCommand
== "sendheaders"
# Upon receipt of a "sendheaders" message, the node will be permitted, but
not required, to announce new blocks by sending the header of the new block
(along with any other blocks that a node believes a peer might need in
order for the block to connect).
# Feature discovery is enabled by checking protocol version >= 70012
==Backward compatibility==
Older clients remain fully compatible and interoperable after this change.
==Implementation==
https://github.com/bitcoin/bitcoin/pull/6494
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150924/42c7569e/attachment.html>;
š Original message:Hi,
I'm proposing the addition of a new, optional p2p message to help improve
the way blocks are announced on the network. The draft BIP is available
here and pasted below:
https://gist.github.com/sdaftuar/465bf008f0a4768c0def
The goal of this p2p message is to facilitate nodes being able to
optionally announce blocks with headers messages rather than with inv's,
which is particularly beneficial since the introduction of headers-first
download in Bitcoin Core 0.10. In particular, this allows for more
efficient propagation of reorgs as it would eliminate a round trip in
network communication.
The implementation of this BIP (which includes code to directly fetch
blocks based on announced headers) is in
https://github.com/bitcoin/bitcoin/pull/6494. For additional background,
please also see https://github.com/bitcoin/bitcoin/issues/5982.
Note that this new p2p message is optional; nodes can feel free to ignore
and continue to use inv messages to announce new blocks.
Thanks to Pieter Wuille for suggesting this idea.
Draft BIP text:
<pre>
BIP: <unassigned>
Title: sendheaders message
Author: Suhas Daftuar <sdaftuar at chaincode.com>
Status: Draft
Type: Standards Track
Created: 2015-05-08
</pre>
==Abstract==
Add a new message, "sendheaders", which indicates that a node prefers to
receive new block announcements via a "headers" message rather than an
"inv".
==Motivation==
Since the introduction of "headers-first" downloading of blocks in 0.10,
blocks will not be processed unless
they are able to connect to a (valid) headers chain. Consequently, block
relay generally works
as follows:
# A node (N) announces the new tip with an "inv" message, containing the
block hash
# A peer (P) responds to the "inv" with a "getheaders" message (to request
headers up to the new tip) and a "getdata" message for the new tip itself
# N responds with a "headers" message (with the header for the new block
along with any preceding headers unknown to P) and a "block" message
containing the new block
However, in the case where a new block is being announced that builds on
the tip, it would be generally more efficient if the node N just announced
the block header for the new block, rather than just the block hash, and
saved the peer from generating and transmitting the getheaders message (and
the required block locator).
In the case of a reorg, where 1 or more blocks are disconnected, nodes
currently just send an "inv" for the new tip. Peers currently are able to
request the new tip immediately, but wait until the headers for the
intermediate blocks are delivered before requesting those blocks. By
announcing headers from the last fork point leading up to the new tip in
the block announcement, peers are able to request all the intermediate
blocks immediately.
==Specification==
# The sendheaders message is defined as an empty message where pchCommand
== "sendheaders"
# Upon receipt of a "sendheaders" message, the node will be permitted, but
not required, to announce new blocks by sending the header of the new block
(along with any other blocks that a node believes a peer might need in
order for the block to connect).
# Feature discovery is enabled by checking protocol version >= 70012
==Backward compatibility==
Older clients remain fully compatible and interoperable after this change.
==Implementation==
https://github.com/bitcoin/bitcoin/pull/6494
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150924/42c7569e/attachment.html>;