Jeff Garzik [ARCHIVE] on Nostr: đź“… Original date posted:2012-04-12 đź“ť Original message:On Wed, Apr 11, 2012 at ...
đź“… Original date posted:2012-04-12
đź“ť Original message:On Wed, Apr 11, 2012 at 2:39 PM, Christian Bodt <sirk390 at gmail.com> wrote:
> Hi,
>
> I would like to discuss the following bitcoin protocol improvement proposal:
>
> Â Â Â Â Â Adding request/reply id in all messages (in the message header,
> based on what was done for the "checksum" field)
>
> The original reason is that I found it very hard to implement robust
> blockchain downloading as we are missing context information:
> The download protocol relies on the other peer sending one (or more) "inv"
> reponse(s) to "getblocks" and sending the "hashContinue".
> But if the other peer doesn't send a response to getblock, send a partial
> response to getblocks, mixes it with some unrelated blocks inventories
> or doesn't send the "hashContinue" it is very hard to detect and handle
> (e.g. ban the peer and switch to another). Â This could cause some DoS
> attacks by misbehaving peers.
If the peer is misbehaving, then disconnect. Your protocol change
does not offer any clear benefits in this area, as these sorts of
attacks/misbehaviors/bugs are still just as possible, and just as
damaging (or not).
Just disconnect the strange peer!
> The problems are that 1/ we don't know how many "inv" messages to wait for
> after "getblocks" and 2/ we don't know how to distinguish between result of
> "getblocks" and spontaneous "inv" notifications.
> The same is true for  "addr" messages (it is both a notification and reply)
> but this is less of a problem as a lack of response to getaddr
> doesn't constitute a DoS.
>
> The idea would be to add a new "requestid" field in messages and define the
> following:
Stateless protocols have a lot of value. They are easiest to
implement, and easier to prove correct. Existing clients like
ArtForz' half-a-node, variants of which are deployed all over the
place in bitcoin-land, rely on the stateless-ness to one degree or
another.
Stateful protocols, too, have their problems as well. One must add
code to help remain "synchronized" between local and remote states,
which your suggested change only hints at. NFSv4 and RPC have a long
history of dealing with stateful-ness issues. Obviously bitcoin P2P
is nowhere near as complex, but the history of NFS development offers
several lessons applicable to your proposed change.
Overall, IMO your listed reasons for needing this major change
(stateless->stateful) do not really justify the change. Handling
initial block download can be accomplished in a number of ways, and
peer(s) may crash or return odd results. You must handle these cases
properly, regardless of the presence of req/reply id's.
--
Jeff Garzik
exMULTI, Inc.
jgarzik at exmulti.com
Published at
2023-06-07 10:03:35Event JSON
{
"id": "12a11664ec17e7417a95466293dc5ce0de21164172725184bcb4d78e39bde9a6",
"pubkey": "b25e10e25d470d9b215521b50da0dfe7a209bec7fedeb53860c3e180ffdc8c11",
"created_at": 1686132215,
"kind": 1,
"tags": [
[
"e",
"70f3e14328ccee7dd310e8ed2c4f7e00d554c01acb76355b74eb0489f5adac90",
"",
"root"
],
[
"e",
"5740907556d1ec4f9c8864a470e381f4670510e3d6787239d03e21c3b9a50c04",
"",
"reply"
],
[
"p",
"c86b2a2e41d61aaf7ab7198ba65cf5a35c015f3117a71eaba5e19bb537b20051"
]
],
"content": "📅 Original date posted:2012-04-12\n📝 Original message:On Wed, Apr 11, 2012 at 2:39 PM, Christian Bodt \u003csirk390 at gmail.com\u003e wrote:\n\u003e Hi,\n\u003e\n\u003e I would like to discuss the following bitcoin protocol improvement proposal:\n\u003e\n\u003e      Adding request/reply id in all messages (in the message header,\n\u003e based on what was done for the \"checksum\" field)\n\u003e\n\u003e The original reason is that I found it very hard to implement robust\n\u003e blockchain downloading as we are missing context information:\n\u003e The download protocol relies on the other peer sending one (or more) \"inv\"\n\u003e reponse(s) to \"getblocks\" and sending the \"hashContinue\".\n\u003e But if the other peer doesn't send a response to getblock, send a partial\n\u003e response to getblocks, mixes it with some unrelated blocks inventories\n\u003e or doesn't send the \"hashContinue\" it is very hard to detect and handle\n\u003e (e.g. ban the peer and switch to another).  This could cause some DoS\n\u003e attacks by misbehaving peers.\n\nIf the peer is misbehaving, then disconnect. Your protocol change\ndoes not offer any clear benefits in this area, as these sorts of\nattacks/misbehaviors/bugs are still just as possible, and just as\ndamaging (or not).\n\nJust disconnect the strange peer!\n\n\u003e The problems are that 1/ we don't know how many \"inv\" messages to wait for\n\u003e after \"getblocks\" and 2/ we don't know how to distinguish between result of\n\u003e \"getblocks\" and spontaneous \"inv\" notifications.\n\u003e The same is true for  \"addr\" messages (it is both a notification and reply)\n\u003e but this is less of a problem as a lack of response to getaddr\n\u003e doesn't constitute a DoS.\n\u003e\n\u003e The idea would be to add a new \"requestid\" field in messages and define the\n\u003e following:\n\n\nStateless protocols have a lot of value. They are easiest to\nimplement, and easier to prove correct. Existing clients like\nArtForz' half-a-node, variants of which are deployed all over the\nplace in bitcoin-land, rely on the stateless-ness to one degree or\nanother.\n\nStateful protocols, too, have their problems as well. One must add\ncode to help remain \"synchronized\" between local and remote states,\nwhich your suggested change only hints at. NFSv4 and RPC have a long\nhistory of dealing with stateful-ness issues. Obviously bitcoin P2P\nis nowhere near as complex, but the history of NFS development offers\nseveral lessons applicable to your proposed change.\n\nOverall, IMO your listed reasons for needing this major change\n(stateless-\u003estateful) do not really justify the change. Handling\ninitial block download can be accomplished in a number of ways, and\npeer(s) may crash or return odd results. You must handle these cases\nproperly, regardless of the presence of req/reply id's.\n\n-- \nJeff Garzik\nexMULTI, Inc.\njgarzik at exmulti.com",
"sig": "d52207e63b9a1d84f8017037be0490da7539e7f79d076dabcc6b3629ccc767177a80000355fdf448b4d037b4006e9564fe48291466c0bf9ab13b7b1c525987ff"
}