📅 Original date posted:2020-08-24
📝 Original message:Since discussion around allowing unknown messages or not allowing them
seems contentious, I'd like to offer up another possibility: create a
single new message, XVERSION, (and bump the protocol rev) which is a
key-value array of arbitrary data. Any protocol extension can then choose
a new key (with a 32 or 64 bit keyspace you can basically hand out prefixes
to any implementation that wants one) and publish custom data via this
message without needing to bump the protocol rev field. Typical "custom
data" would be the min and max supported version of some specific extended
protocol, but any data is possible since the "value" field can be
serialized via the same network serialization format. It therefore doubles
as a "configuration" message as well as protocol extension negotiation.
For example, we use it to communicate the maximum unconfirmed chain a node
will commit to the mempool, and peers don't bother to send transactions
that exceed this limit.
You can find a specification here:
https://gitlab.com/bitcoinunlimited/BCHUnlimited/-/blob/dev/doc/xversionmessage.md
Code has been deployed for a long time.
Regards,
Andrew
On Mon, Aug 24, 2020 at 5:44 AM Suhas Daftuar via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hi all,
>
> Thanks for the helpful discussion.
>
> My primary motivation in starting this thread was to establish what the
> expectations are for new feature deployment (particularly whether the
> protocol version should continue to be bumped or not), and I think I have
> that answer -- different from what I proposed when I started this thread,
> but not in a way that I think meaningfully hinders future work. So I'm
> happy to leave it at that and withdraw my suggestion.
>
> Cheers,
> Suhas
>
>
> On Sun, Aug 23, 2020 at 1:51 PM Eric Voskuil via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>>
>> > On Aug 21, 2020, at 15:16, Matt Corallo <lf-lists at mattcorallo.com>
>> wrote:
>> >
>> > Hmm, could that not be accomplished by simply building this into new
>> messages? eg, send "betterprotocol", if you see a verack and no
>> "betterprotocol" from your peer, send "worseprotocol" before you send a
>> "verack".
>> >
>> > Matt
>> >
>> >> On 8/21/20 5:17 PM, Jeremy wrote:
>> >> As for an example of where you'd want multi-round, you could imagine a
>> scenario where you have a feature A which gets bugfixed by the introduction
>> of feature B, and you don't want to expose that you support A unless you
>> first negotiate B. Or if you can negotiate B you should never expose A, but
>> for old nodes you'll still do it if B is unknown to them.
>>
>> This seems to imply a security benefit (I can’t discern any other
>> rationale for this complexity). It should be clear that this is no more
>> than trivially weak obfuscation and not worth complicating the protocol to
>> achieve.
>>
>> >> An example of this would be (were it not already out without a feature
>> negotiation existing) WTXID/TXID relay.
>> >> The SYNC primitve simply codifies what order messages should be in and
>> when you're done for a phase of negotiation offering something. It can be
>> done without, but then you have to be more careful to broadcast in the
>> correct order and it's not clear when/if you should wait for more time
>> before responding.
>> >> On Fri, Aug 21, 2020 at 2:08 PM Jeremy <jlrubin at mit.edu <mailto:
>> jlrubin at mit.edu>> wrote:
>> >> Actually we already have service bits (which are sadly limited)
>> which allow negotiation of non bilateral feature
>> >> support, so this would supercede that.
>> >> --
>> >> @JeremyRubin <https://twitter.com/JeremyRubin><;
>> https://twitter.com/JeremyRubin>;
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200824/3991406e/attachment.html>;
G. Andrew Stone [ARCHIVE] /
npub1ts…9cyxz
2023-06-07 18:26:31
in reply to nevent1q…74ps
Author Public Key
npub1tsl0vdp4gegx6p7m073lphfl7zcrctud0qhutzf63up2h6r2kdcq99cyxzPublished at
2023-06-07 18:26:31Event JSON
{
"id": "16cf8871a134ce28c1297a01033b58feffbf6a503d4092f6e7f32f3a4a07a6da",
"pubkey": "5c3ef6343546506d07db7fa3f0dd3ff0b03c2f8d782fc5893a8f02abe86ab370",
"created_at": 1686162391,
"kind": 1,
"tags": [
[
"e",
"43edfd73733fa9cb455dfd9022ab700e39020c27283a7e2f0343a8c6fb631001",
"",
"root"
],
[
"e",
"2bf81bb78512b54a8690565016d3a0845dd6801a7567b4b0871f8123d50632bd",
"",
"reply"
],
[
"p",
"841503960589cc9bc44213e4addc2aa2fe3fe0727b79f90df3cbd6762875c31e"
]
],
"content": "📅 Original date posted:2020-08-24\n📝 Original message:Since discussion around allowing unknown messages or not allowing them\nseems contentious, I'd like to offer up another possibility: create a\nsingle new message, XVERSION, (and bump the protocol rev) which is a\nkey-value array of arbitrary data. Any protocol extension can then choose\na new key (with a 32 or 64 bit keyspace you can basically hand out prefixes\nto any implementation that wants one) and publish custom data via this\nmessage without needing to bump the protocol rev field. Typical \"custom\ndata\" would be the min and max supported version of some specific extended\nprotocol, but any data is possible since the \"value\" field can be\nserialized via the same network serialization format. It therefore doubles\nas a \"configuration\" message as well as protocol extension negotiation.\nFor example, we use it to communicate the maximum unconfirmed chain a node\nwill commit to the mempool, and peers don't bother to send transactions\nthat exceed this limit.\n\nYou can find a specification here:\nhttps://gitlab.com/bitcoinunlimited/BCHUnlimited/-/blob/dev/doc/xversionmessage.md\n\nCode has been deployed for a long time.\n\nRegards,\nAndrew\n\n\nOn Mon, Aug 24, 2020 at 5:44 AM Suhas Daftuar via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e Hi all,\n\u003e\n\u003e Thanks for the helpful discussion.\n\u003e\n\u003e My primary motivation in starting this thread was to establish what the\n\u003e expectations are for new feature deployment (particularly whether the\n\u003e protocol version should continue to be bumped or not), and I think I have\n\u003e that answer -- different from what I proposed when I started this thread,\n\u003e but not in a way that I think meaningfully hinders future work. So I'm\n\u003e happy to leave it at that and withdraw my suggestion.\n\u003e\n\u003e Cheers,\n\u003e Suhas\n\u003e\n\u003e\n\u003e On Sun, Aug 23, 2020 at 1:51 PM Eric Voskuil via bitcoin-dev \u003c\n\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\n\u003e\u003e\n\u003e\u003e \u003e On Aug 21, 2020, at 15:16, Matt Corallo \u003clf-lists at mattcorallo.com\u003e\n\u003e\u003e wrote:\n\u003e\u003e \u003e\n\u003e\u003e \u003e Hmm, could that not be accomplished by simply building this into new\n\u003e\u003e messages? eg, send \"betterprotocol\", if you see a verack and no\n\u003e\u003e \"betterprotocol\" from your peer, send \"worseprotocol\" before you send a\n\u003e\u003e \"verack\".\n\u003e\u003e \u003e\n\u003e\u003e \u003e Matt\n\u003e\u003e \u003e\n\u003e\u003e \u003e\u003e On 8/21/20 5:17 PM, Jeremy wrote:\n\u003e\u003e \u003e\u003e As for an example of where you'd want multi-round, you could imagine a\n\u003e\u003e scenario where you have a feature A which gets bugfixed by the introduction\n\u003e\u003e of feature B, and you don't want to expose that you support A unless you\n\u003e\u003e first negotiate B. Or if you can negotiate B you should never expose A, but\n\u003e\u003e for old nodes you'll still do it if B is unknown to them.\n\u003e\u003e\n\u003e\u003e This seems to imply a security benefit (I can’t discern any other\n\u003e\u003e rationale for this complexity). It should be clear that this is no more\n\u003e\u003e than trivially weak obfuscation and not worth complicating the protocol to\n\u003e\u003e achieve.\n\u003e\u003e\n\u003e\u003e \u003e\u003e An example of this would be (were it not already out without a feature\n\u003e\u003e negotiation existing) WTXID/TXID relay.\n\u003e\u003e \u003e\u003e The SYNC primitve simply codifies what order messages should be in and\n\u003e\u003e when you're done for a phase of negotiation offering something. It can be\n\u003e\u003e done without, but then you have to be more careful to broadcast in the\n\u003e\u003e correct order and it's not clear when/if you should wait for more time\n\u003e\u003e before responding.\n\u003e\u003e \u003e\u003e On Fri, Aug 21, 2020 at 2:08 PM Jeremy \u003cjlrubin at mit.edu \u003cmailto:\n\u003e\u003e jlrubin at mit.edu\u003e\u003e wrote:\n\u003e\u003e \u003e\u003e Actually we already have service bits (which are sadly limited)\n\u003e\u003e which allow negotiation of non bilateral feature\n\u003e\u003e \u003e\u003e support, so this would supercede that.\n\u003e\u003e \u003e\u003e --\n\u003e\u003e \u003e\u003e @JeremyRubin \u003chttps://twitter.com/JeremyRubin\u003e\u003c\n\u003e\u003e https://twitter.com/JeremyRubin\u003e\n\u003e\u003e _______________________________________________\n\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200824/3991406e/attachment.html\u003e",
"sig": "59f8414f69626684d1eb1cad20d94d490a165eefd200f7ac95bdf09cf9fa653ddca0a0e175772196741247d33b6a09326bc5e084ca9cd06e1e6e9c95a68ab1cc"
}