📅 Original date posted:2014-05-24
📝 Original message:On Fri, May 23, 2014 at 8:57 PM, Ashley Holman <dscvlt at gmail.com> wrote:
> 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.
FWIW, there are a lot of improvements which can be made before more
complex changes like cut-through-forwarding that change the protocol.
For example, the reference software has a 100ms sleep in p2p message
processing which could be replaced with a semaphore, this would
dramatically lower latency for block relaying.
Likewise nodes which are becoming bandwidth overloaded could adapt
their concurrent connection counts down (and ones that are underloaded
could accept more connections).
Relaying to multiple peers could be done in parallel instead of
serialized, and the order in which peers are relayed to could be
adapted to place more apparently useful and faster peers first, e.g.
every time a peer is the first to tell you about a block or
transaction you accept they move up the list, every time their socket
send queue fills they move down.
Luke-Jr had implemented cut through behavior previously and had posted
a patch, but absent those other network processing improvements it
didn't appear to help.
If you want to go full out crazy in optimizing in this space, there
are fancier things that can be done to further reduce latency and
increase efficiency:
https://en.bitcoin.it/wiki/User:Gmaxwell/block_network_coding ... but
some of this stuff really should be done as a seperate protocol. There
is no need to have Bitcoin transport all using a single protocol, and
we can get better robustness and feature velocity if there are a
couple protocols in use (you could just run a block-transport-protocol
daemon that connects to your local node via the classic protocol).
Gregory Maxwell [ARCHIVE] /
npub1f2…crwet
2023-06-07 15:22:04
in reply to nevent1q…n3w5
Author Public Key
npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwetPublished at
2023-06-07 15:22:04Event JSON
{
"id": "c7229766476c4b0067e47cc13debc1397ccc21fc10c5aabc9a1175fdae93925c",
"pubkey": "4aa6cf9aa5c8e98f401dac603c6a10207509b6a07317676e9d6615f3d7103d73",
"created_at": 1686151324,
"kind": 1,
"tags": [
[
"e",
"db0c94828eb521bd60e5a762540ad2fb3c4dc34552a9817c80dbbcb4c4cf34fe",
"",
"root"
],
[
"e",
"1e21d525378714fc99fe8398929bf13f5bc7c9072b97bfb52aec8aaa7fc2adda",
"",
"reply"
],
[
"p",
"9b0144b1291cf6a2e8616fed31620f7ee7dcb7757055108a38c45814cafe814c"
]
],
"content": "📅 Original date posted:2014-05-24\n📝 Original message:On Fri, May 23, 2014 at 8:57 PM, Ashley Holman \u003cdscvlt at gmail.com\u003e wrote:\n\u003e Hi,\n\u003e On this list there has been some discussion around techniques to speed up\n\u003e block propagation, with a particular focus on reducing the extra orphan risk\n\u003e carried by larger blocks.\n\u003e The current store-and-forward method means that larger blocks will propagate\n\u003e with higher latency.\n\nFWIW, there are a lot of improvements which can be made before more\ncomplex changes like cut-through-forwarding that change the protocol.\n\nFor example, the reference software has a 100ms sleep in p2p message\nprocessing which could be replaced with a semaphore, this would\ndramatically lower latency for block relaying.\n\nLikewise nodes which are becoming bandwidth overloaded could adapt\ntheir concurrent connection counts down (and ones that are underloaded\ncould accept more connections).\n\nRelaying to multiple peers could be done in parallel instead of\nserialized, and the order in which peers are relayed to could be\nadapted to place more apparently useful and faster peers first, e.g.\nevery time a peer is the first to tell you about a block or\ntransaction you accept they move up the list, every time their socket\nsend queue fills they move down.\n\nLuke-Jr had implemented cut through behavior previously and had posted\na patch, but absent those other network processing improvements it\ndidn't appear to help.\n\n\nIf you want to go full out crazy in optimizing in this space, there\nare fancier things that can be done to further reduce latency and\nincrease efficiency:\nhttps://en.bitcoin.it/wiki/User:Gmaxwell/block_network_coding ... but\nsome of this stuff really should be done as a seperate protocol. There\nis no need to have Bitcoin transport all using a single protocol, and\nwe can get better robustness and feature velocity if there are a\ncouple protocols in use (you could just run a block-transport-protocol\ndaemon that connects to your local node via the classic protocol).",
"sig": "a0cd95d58573952b456137b8a0424e7a189ae1a0b63ade9b90f17af766b2707fe01ed8e1daa53899b4df5627bd6e63fde17a28714bc1735b9a99c15fa279c797"
}