Christian Bodt [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2012-04-11 to 2012-04-12
💬 Posted a total of 3 messages
📚 Participated in the following categories: Bitcoin-development
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 10:03:52

- reply

📅 Original date posted:2012-04-12
📝 Original message:> For example, doing a second
> identical "getblocks" request will not result in more "inv" replies, as
> the client
> prevents retransmits.
Yes, the current prototype implementation modifies that. "getblocks" always
results in one "inv" with [0-500] elements.
It also removes the filtering on previously transmitted block invs.
see patch:
https://github.com/sirk390/bitcoin/commit/17a27e3d56efa107697b53c193364a33951f1dd1
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20120412/6d6d42f9/attachment.html>

2023-06-07 10:03:45

- reply

📅 Original date posted:2012-04-12
📝 Original message:On Thu, Apr 12, 2012 at 7:24 PM, Amir Taaki <zgenjix at yahoo.com> wrote:
> Jeff elaborated the problems very well, but I just want to add this:
>
> Your change is essentially relying (trusting) the server to track a piece
> of information (your state).
No, it is more about distinguishing between replies (multiple asynchroneous
request) and spontaneous notifications of the other peer.
Every state would still be tracked locally on the client side.
I don't understand why you say my proposal would make the protocol more
stateful. I think it doesn't.
Each reply is only the result of the current request only, and there is no
new session information.
As you see in my implementation, there is not even a new variable.
Request/reply id is a very robust pattern that is compatible with stateless
protocols.
Indead, this change doesn't directly improve on peer that don't answer
requests: it only enables to do so easily in a secondary step. This step
can only be done when all peers on the network are running the modified
code.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20120412/38e08138/attachment.html>

2023-06-07 10:03:22

- reply

📅 Original date posted:2012-04-11
📝 Original message: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.
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:
- verack sends back the requestid given in version.
- inv sends back the requestid given in getblocks or a special value
in case of a notification.
- addr sends back the requestid given in getaddr or a special value
in case of a notification.
- tx sends back the requestid given in getdata.
- block sends back the requestid given in getdata
- headers sends back the requestid given in getheaders.
- reply sends back the requestid given in checkorder/submitorder.
- pong sends back the requestid given in ping.
With the following rules:
- getblocks always results in a single"inv" reply (0-500 elements
allowed).
- getdata still result in multiple 'tx' or 'block' 's (as currently).
This is inspired by the common request/reply pattern (the id is sometimes
called "correlation id").
This would permit better asynchronous messaging (multiple request of the
same type in parallel. This could be useful for
getblocks/getdata/getheaders and future messages).
Historic note: It seems similar to the existing mechanism of
"CRequestTracker, hashReply & PushRequest" in the current bitcoin source
code except requestId would only be a 32bits instead of the 256bits
of hashReply .
I have implemented a prototype here: https://github.com/sirk390/bitcoin/
This could allow to remove "hashContinue" in a second step like this:
https://github.com/sirk390/bitcoin/tree/better_block_download
I'm discussing it now as I read the PONG BIP and saw some similar nonce
field added.
I was not sure if this nonce field would still be required if we had
request/reply ids .
What do you think?
Best Regards,
Christian Bodt, France
Note: I am working on a python implementation of bitcoin.
See https://github.com/sirk390/coinpy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20120411/3b4afcbf/attachment.html>