📅 Original date posted:2012-04-12
📝 Original message:This is a bad idea. The bitcoin protocol is (mostly) stateless. Stateless protocols are more secure.
________________________________
From: Pieter Wuille <pieter.wuille at gmail.com>
To: Gavin Andresen <gavinandresen at gmail.com>
Cc: bitcoin-development at lists.sourceforge.net
Sent: Thursday, April 12, 2012 5:01 PM
Subject: Re: [Bitcoin-development] Adding request/reply id in messages
On Thu, Apr 12, 2012 at 11:41:05AM -0400, Gavin Andresen wrote:
> On Wed, Apr 11, 2012 at 2:39 PM, Christian Bodt <sirk390 at gmail.com> wrote:
> > 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)
>
> That seems like a perfectly reasonable protocol improvement to me.
> Anybody else have an opinion?
If there is a reasonable use for it, I have no objections.
However: the bitcoin P2P protocol is not fully request-reply based, and trying to use
it that may be be less intuitive than how it looks. For example, doing a second
identical "getblocks" request will not result in more "inv" replies, as the client
prevents retransmits. This is not a large problem, but maybe such an extension
should also include an extra "denied" message, which is sent if the client is
unwilling to answer (and may also be used to report transactions that are not
accepted into the memory pool, for example).
--
Pieter
------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20120412/b046c13c/attachment.html>;
Amir Taaki [ARCHIVE] /
npub1ep…m3rel
2023-06-07 10:03:32
in reply to nevent1q…vv9r
Author Public Key
npub1ep4j5tjp6cd2774hrx96vh845dwqzhe3z7n3a2a9uxdm2dajqpgscm3relPublished at
2023-06-07 10:03:32Event JSON
{
"id": "5740907556d1ec4f9c8864a470e381f4670510e3d6787239d03e21c3b9a50c04",
"pubkey": "c86b2a2e41d61aaf7ab7198ba65cf5a35c015f3117a71eaba5e19bb537b20051",
"created_at": 1686132212,
"kind": 1,
"tags": [
[
"e",
"70f3e14328ccee7dd310e8ed2c4f7e00d554c01acb76355b74eb0489f5adac90",
"",
"root"
],
[
"e",
"a7ca69a263728f431eecb113465898432e2c76f643a0d569e7e9afc7097ad41e",
"",
"reply"
],
[
"p",
"5cb21bf5d7f25a9d46879713cbd32433bbc10e40ef813a3c28fe7355f49854d6"
]
],
"content": "📅 Original date posted:2012-04-12\n📝 Original message:This is a bad idea. The bitcoin protocol is (mostly) stateless. Stateless protocols are more secure.\n\n\n\n________________________________\n From: Pieter Wuille \u003cpieter.wuille at gmail.com\u003e\nTo: Gavin Andresen \u003cgavinandresen at gmail.com\u003e \nCc: bitcoin-development at lists.sourceforge.net \nSent: Thursday, April 12, 2012 5:01 PM\nSubject: Re: [Bitcoin-development] Adding request/reply id in messages\n \nOn Thu, Apr 12, 2012 at 11:41:05AM -0400, Gavin Andresen wrote:\n\u003e On Wed, Apr 11, 2012 at 2:39 PM, Christian Bodt \u003csirk390 at gmail.com\u003e wrote:\n\u003e \u003e I would like to discuss the following bitcoin protocol improvement proposal:\n\u003e \u003e\n\u003e \u003e Adding request/reply id in all messages (in the message header,\n\u003e \u003e based on what was done for the \"checksum\" field)\n\u003e \n\u003e That seems like a perfectly reasonable protocol improvement to me.\n\u003e Anybody else have an opinion?\n\nIf there is a reasonable use for it, I have no objections.\n\nHowever: the bitcoin P2P protocol is not fully request-reply based, and trying to use\nit that may be be less intuitive than how it looks. For example, doing a second\nidentical \"getblocks\" request will not result in more \"inv\" replies, as the client\nprevents retransmits. This is not a large problem, but maybe such an extension\nshould also include an extra \"denied\" message, which is sent if the client is\nunwilling to answer (and may also be used to report transactions that are not\naccepted into the memory pool, for example).\n\n-- \nPieter\n\n------------------------------------------------------------------------------\nFor Developers, A Lot Can Happen In A Second.\nBoundary is the first to Know...and Tell You.\nMonitor Your Applications in Ultra-Fine Resolution. Try it FREE!\nhttp://p.sf.net/sfu/Boundary-d2dvs2\n_______________________________________________\nBitcoin-development mailing list\nBitcoin-development at lists.sourceforge.net\nhttps://lists.sourceforge.net/lists/listinfo/bitcoin-development\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20120412/b046c13c/attachment.html\u003e",
"sig": "f7f0e6c8038a303f3e63340707792b62e3be25225eb3c09491e3e574ca3df0e18a4765bb1c9489a25fc12797e8b26dee742a2a7a1790c6ffeeca159e223872f6"
}