📅 Original date posted:2016-02-26
📝 Original message:On Fri, Feb 26, 2016 at 5:35 AM, Jonathan Toomim via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> An improvement that I've been thinking about implementing (after
> Blocktorrent) is an option for batched INVs. Including the hashes for two
> txes per IP packet instead of one would increase the INV size to 229 bytes
> for 64 bytes of payload -- that is, you add 36 bytes to the packet for every
> 32 bytes of actual payload. This is a marginal efficiency of 88.8% for each
> hash after the first. This is *much* better.
>
> Waiting a short period of time to accumulate several hashes together and
> send them as a batched INV could easily reduce the traffic of running
> bitcoin nodes by a factor of 2,
Copying my response to you from BitcoinTalk
(https://bitcointalk.org/index.php?topic=1377345.msg14013294#msg14013294):
Uh. Bitcoin has done this since the very early days. The batching was
temporarily somewhat hobbled between 0.10 and 0.12 (especially when
you had any abusive frequently pinging peers attached), but is now
fully functional again and it now manages to batch many transactions
per INV pretty effectively. Turn on net message debugging and you'll
see the many INVs that are much larger than the minimum. The average
batching size (ignoring the trickle cut-through) is about 5 seconds
long-- and usually gets about 10 transactions per INV. My measurements
were with these fixes in effect; I expect the blocksonly savings would
have been higher otherwise.
2016-02-26 05:47:08 sending: inv (1261 bytes) peer=33900
2016-02-26 05:47:08 sending: inv (109 bytes) peer=32460
2016-02-26 05:47:08 sending: inv (37 bytes) peer=34501
2016-02-26 05:47:08 sending: inv (217 bytes) peer=33897
2016-02-26 05:47:08 sending: inv (145 bytes) peer=41863
2016-02-26 05:47:08 sending: inv (37 bytes) peer=35725
2016-02-26 05:47:08 sending: inv (73 bytes) peer=20567
2016-02-26 05:47:08 sending: inv (289 bytes) peer=44703
2016-02-26 05:47:08 sending: inv (73 bytes) peer=13408
2016-02-26 05:47:09 sending: inv (649 bytes) peer=41279
2016-02-26 05:47:09 sending: inv (145 bytes) peer=42612
2016-02-26 05:47:09 sending: inv (325 bytes) peer=34525
2016-02-26 05:47:09 sending: inv (181 bytes) peer=41174
2016-02-26 05:47:09 sending: inv (469 bytes) peer=41460
2016-02-26 05:47:10 sending: inv (973 bytes) peer=133
2016-02-26 05:47:10 sending: inv (361 bytes) peer=20541
Twiddling here doesn't change the asymptotic efficiency though; which
is what my post is about.
[I'm also somewhat surprised that you were unaware of this; one of the
patches "classic" was talking about patching out was the one restoring
the batching... due to a transaction deanonymization service (or
troll) claiming it interfered with their operations.]
Gregory Maxwell [ARCHIVE] /
npub1f2…crwet
2023-06-07 17:49:19
in reply to nevent1q…64kx
Author Public Key
npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwetPublished at
2023-06-07 17:49:19Event JSON
{
"id": "50768a115b0a1456d0dad3216ce5e2a3acc639fb91672bb9f80224a7c9689564",
"pubkey": "4aa6cf9aa5c8e98f401dac603c6a10207509b6a07317676e9d6615f3d7103d73",
"created_at": 1686160159,
"kind": 1,
"tags": [
[
"e",
"729f44ab8db8f0ef1527a89dbfbb490970362b00f322f0d6494d2e6a52fbdb99",
"",
"root"
],
[
"e",
"41ea055ff0f7b7ca939223f2ded694d378807395afd5f5081c0406d42beefe18",
"",
"reply"
],
[
"p",
"0ff56c09ef879c89ea04bfa2d5f5e0d96000ed6eaf5ac38e7b538a9d92767569"
]
],
"content": "📅 Original date posted:2016-02-26\n📝 Original message:On Fri, Feb 26, 2016 at 5:35 AM, Jonathan Toomim via bitcoin-dev\n\u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e An improvement that I've been thinking about implementing (after\n\u003e Blocktorrent) is an option for batched INVs. Including the hashes for two\n\u003e txes per IP packet instead of one would increase the INV size to 229 bytes\n\u003e for 64 bytes of payload -- that is, you add 36 bytes to the packet for every\n\u003e 32 bytes of actual payload. This is a marginal efficiency of 88.8% for each\n\u003e hash after the first. This is *much* better.\n\u003e\n\u003e Waiting a short period of time to accumulate several hashes together and\n\u003e send them as a batched INV could easily reduce the traffic of running\n\u003e bitcoin nodes by a factor of 2,\n\nCopying my response to you from BitcoinTalk\n(https://bitcointalk.org/index.php?topic=1377345.msg14013294#msg14013294):\n\nUh. Bitcoin has done this since the very early days. The batching was\ntemporarily somewhat hobbled between 0.10 and 0.12 (especially when\nyou had any abusive frequently pinging peers attached), but is now\nfully functional again and it now manages to batch many transactions\nper INV pretty effectively. Turn on net message debugging and you'll\nsee the many INVs that are much larger than the minimum. The average\nbatching size (ignoring the trickle cut-through) is about 5 seconds\nlong-- and usually gets about 10 transactions per INV. My measurements\nwere with these fixes in effect; I expect the blocksonly savings would\nhave been higher otherwise.\n\n2016-02-26 05:47:08 sending: inv (1261 bytes) peer=33900\n2016-02-26 05:47:08 sending: inv (109 bytes) peer=32460\n2016-02-26 05:47:08 sending: inv (37 bytes) peer=34501\n2016-02-26 05:47:08 sending: inv (217 bytes) peer=33897\n2016-02-26 05:47:08 sending: inv (145 bytes) peer=41863\n2016-02-26 05:47:08 sending: inv (37 bytes) peer=35725\n2016-02-26 05:47:08 sending: inv (73 bytes) peer=20567\n2016-02-26 05:47:08 sending: inv (289 bytes) peer=44703\n2016-02-26 05:47:08 sending: inv (73 bytes) peer=13408\n2016-02-26 05:47:09 sending: inv (649 bytes) peer=41279\n2016-02-26 05:47:09 sending: inv (145 bytes) peer=42612\n2016-02-26 05:47:09 sending: inv (325 bytes) peer=34525\n2016-02-26 05:47:09 sending: inv (181 bytes) peer=41174\n2016-02-26 05:47:09 sending: inv (469 bytes) peer=41460\n2016-02-26 05:47:10 sending: inv (973 bytes) peer=133\n2016-02-26 05:47:10 sending: inv (361 bytes) peer=20541\n\nTwiddling here doesn't change the asymptotic efficiency though; which\nis what my post is about.\n\n[I'm also somewhat surprised that you were unaware of this; one of the\npatches \"classic\" was talking about patching out was the one restoring\nthe batching... due to a transaction deanonymization service (or\ntroll) claiming it interfered with their operations.]",
"sig": "69190187bb1fbf91894e86535dd56b3e341b739397ac2faf7bcb45808386087e7ce6b41fbffa56529b17c0850b5772776bd355027c6e19dd95234ef431c47fd3"
}