📅 Original date posted:2020-08-17
📝 Original message:Hi Eric,
Thanks for your response. If I understand correctly, you're suggesting
that in the future we do the same as what was done in BIP 339, of
accompanying new messages (which are optional) with a protocol version
bump, so that network clients are never reading unknown messages from a
peer (and can be free to disconnect a peer for sending an unknown message)?
I think that works fine, so if indeed there will be software that will
expect things to operate this way then I can withdraw the suggestion I've
made in this thread. However I wanted to clarify that this is what you
suggest, because there is another downside to this approach (beyond the
sequential nature of sequence numbers that you mention) -- if a software
implementation misses a proposed new protocol upgrade, and thus fails to
parse (and ignore) some proposed new message, the result can be a network
split down the road as incompatible clients get slowly upgraded over time.
I think this coordination cost is something to be concerned about -- for
instance, the lack of response to my wtxid-relay proposal made me wonder if
other software would be implementing something to account for the new
message that proposal introduces (for clients with version >= 70016). It's
reasonable for people to be busy and miss things like this, and I think
it's worth considering whether there's a safer way for us to deploy changes.
That said, I don't think this coordination cost is unbearable, so as long
as we have a process for making p2p protocol improvements I'm not too
worried about what mechanism we use. So if this concern over coordination
of changes doesn't sway you, I think we can continue to just bump protocol
version at the same time as deploying new messages, as we have been doing,
and hope that we don't run into problems down the road.
If I have misunderstood how you think we should be making future protocol
changes, please let me know.
Thanks,
Suhas
On Sun, Aug 16, 2020 at 3:06 PM Eric Voskuil <eric at voskuil.org> wrote:
> A requirement to ignore unknown (invalid) messages is not only a protocol
> breaking change but poor protocol design. The purpose of version
> negotiation is to determine the set of valid messages. Changes to version
> negotiation itself are very problematic.
>
> The only limitation presented by versioning is that the system is
> sequential. As such, clients that do not wish to implement (or operators
> who do not wish to enable) them are faced with a problem when wanting to
> support later features. This is resolvable by making such features optional
> at the new protocol level. This allows each client to limit its
> communication to the negotiated protocol, and allows ignoring of known but
> unsupported/disabled features.
>
> Sorry I missed your earlier post. Been distracted for a while.
>
> e
>
>
> On Aug 14, 2020, at 12:28, Suhas Daftuar via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>
> Hi,
>
> Back in February I posted a proposal for WTXID-based transaction relay[1]
> (now known as BIP 339), which included a proposal for feature negotiation
> to take place prior to the VERACK message being received by each side. In
> my email to this list, I had asked for feedback as to whether that proposal
> was problematic, and didn't receive any responses.
>
> Since then, the implementation of BIP 339 has been merged into Bitcoin
> Core, though it has not yet been released.
>
> In thinking about the mechanism used there, I thought it would be helpful
> to codify in a BIP the idea that Bitcoin network clients should ignore
> unknown messages received before a VERACK. A draft of my proposal is
> available here[2].
>
> I presume that software upgrading past protocol version 70016 was already
> planning to either implement BIP 339, or ignore the wtxidrelay message
> proposed in BIP 339 (if not, then this would create network split concerns
> in the future -- so I hope that someone would speak up if this were a
> problem). When we propose future protocol upgrades that would benefit from
> feature negotiation at the time of connection, I think it would be nice to
> be able to use the same method as proposed in BIP 339, without even needing
> to bump the protocol version. So having an understanding that this is the
> standard of how other network clients operate would be helpful.
>
> If, on the other hand, this is problematic for some reason, I look forward
> to hearing that as well, so that we can be careful about how we deploy
> future p2p changes to avoid disruption.
>
> Thanks,
> Suhas Daftuar
>
> [1]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-February/017648.html
>
> [2]
> https://github.com/sdaftuar/bips/blob/2020-08-generalized-feature-negotiation/bip-p2p-feature-negotiation.mediawiki
> _______________________________________________
> 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/20200817/f449fb1f/attachment.html>;
Suhas Daftuar [ARCHIVE] /
npub1ss…e0am4
2023-06-07 18:26:23
in reply to nevent1q…ym2a
Author Public Key
npub1ss2s89s938xfh3zzz0j2mhp25tlrlcrj0duljr0ne0t8v2r4cv0q5e0am4Published at
2023-06-07 18:26:23Event JSON
{
"id": "945a9a720ba6e61b70dfe168dc75ad3f266b3093f869ba79ede9cee22d99174b",
"pubkey": "841503960589cc9bc44213e4addc2aa2fe3fe0727b79f90df3cbd6762875c31e",
"created_at": 1686162383,
"kind": 1,
"tags": [
[
"e",
"43edfd73733fa9cb455dfd9022ab700e39020c27283a7e2f0343a8c6fb631001",
"",
"root"
],
[
"e",
"f3a23720fd62057e537c2009fb0ba39149714d11fd9d2c557e619ebf7d2cc88f",
"",
"reply"
],
[
"p",
"82205f272f995d9be742779a3c19a2ae08522ca14824c3a3b01525fb5459161e"
]
],
"content": "📅 Original date posted:2020-08-17\n📝 Original message:Hi Eric,\n\nThanks for your response. If I understand correctly, you're suggesting\nthat in the future we do the same as what was done in BIP 339, of\naccompanying new messages (which are optional) with a protocol version\nbump, so that network clients are never reading unknown messages from a\npeer (and can be free to disconnect a peer for sending an unknown message)?\n\nI think that works fine, so if indeed there will be software that will\nexpect things to operate this way then I can withdraw the suggestion I've\nmade in this thread. However I wanted to clarify that this is what you\nsuggest, because there is another downside to this approach (beyond the\nsequential nature of sequence numbers that you mention) -- if a software\nimplementation misses a proposed new protocol upgrade, and thus fails to\nparse (and ignore) some proposed new message, the result can be a network\nsplit down the road as incompatible clients get slowly upgraded over time.\n\nI think this coordination cost is something to be concerned about -- for\ninstance, the lack of response to my wtxid-relay proposal made me wonder if\nother software would be implementing something to account for the new\nmessage that proposal introduces (for clients with version \u003e= 70016). It's\nreasonable for people to be busy and miss things like this, and I think\nit's worth considering whether there's a safer way for us to deploy changes.\n\nThat said, I don't think this coordination cost is unbearable, so as long\nas we have a process for making p2p protocol improvements I'm not too\nworried about what mechanism we use. So if this concern over coordination\nof changes doesn't sway you, I think we can continue to just bump protocol\nversion at the same time as deploying new messages, as we have been doing,\nand hope that we don't run into problems down the road.\n\nIf I have misunderstood how you think we should be making future protocol\nchanges, please let me know.\n\nThanks,\nSuhas\n\n\n\nOn Sun, Aug 16, 2020 at 3:06 PM Eric Voskuil \u003ceric at voskuil.org\u003e wrote:\n\n\u003e A requirement to ignore unknown (invalid) messages is not only a protocol\n\u003e breaking change but poor protocol design. The purpose of version\n\u003e negotiation is to determine the set of valid messages. Changes to version\n\u003e negotiation itself are very problematic.\n\u003e\n\u003e The only limitation presented by versioning is that the system is\n\u003e sequential. As such, clients that do not wish to implement (or operators\n\u003e who do not wish to enable) them are faced with a problem when wanting to\n\u003e support later features. This is resolvable by making such features optional\n\u003e at the new protocol level. This allows each client to limit its\n\u003e communication to the negotiated protocol, and allows ignoring of known but\n\u003e unsupported/disabled features.\n\u003e\n\u003e Sorry I missed your earlier post. Been distracted for a while.\n\u003e\n\u003e e\n\u003e\n\u003e\n\u003e On Aug 14, 2020, at 12:28, Suhas Daftuar via bitcoin-dev \u003c\n\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\n\u003e \n\u003e Hi,\n\u003e\n\u003e Back in February I posted a proposal for WTXID-based transaction relay[1]\n\u003e (now known as BIP 339), which included a proposal for feature negotiation\n\u003e to take place prior to the VERACK message being received by each side. In\n\u003e my email to this list, I had asked for feedback as to whether that proposal\n\u003e was problematic, and didn't receive any responses.\n\u003e\n\u003e Since then, the implementation of BIP 339 has been merged into Bitcoin\n\u003e Core, though it has not yet been released.\n\u003e\n\u003e In thinking about the mechanism used there, I thought it would be helpful\n\u003e to codify in a BIP the idea that Bitcoin network clients should ignore\n\u003e unknown messages received before a VERACK. A draft of my proposal is\n\u003e available here[2].\n\u003e\n\u003e I presume that software upgrading past protocol version 70016 was already\n\u003e planning to either implement BIP 339, or ignore the wtxidrelay message\n\u003e proposed in BIP 339 (if not, then this would create network split concerns\n\u003e in the future -- so I hope that someone would speak up if this were a\n\u003e problem). When we propose future protocol upgrades that would benefit from\n\u003e feature negotiation at the time of connection, I think it would be nice to\n\u003e be able to use the same method as proposed in BIP 339, without even needing\n\u003e to bump the protocol version. So having an understanding that this is the\n\u003e standard of how other network clients operate would be helpful.\n\u003e\n\u003e If, on the other hand, this is problematic for some reason, I look forward\n\u003e to hearing that as well, so that we can be careful about how we deploy\n\u003e future p2p changes to avoid disruption.\n\u003e\n\u003e Thanks,\n\u003e Suhas Daftuar\n\u003e\n\u003e [1]\n\u003e https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-February/017648.html\n\u003e\n\u003e [2]\n\u003e https://github.com/sdaftuar/bips/blob/2020-08-generalized-feature-negotiation/bip-p2p-feature-negotiation.mediawiki\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\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200817/f449fb1f/attachment.html\u003e",
"sig": "4e4d1b37057703e3d4425116935e7f5e9a85874bbdccb6c67dfa4e8bff2944f74981fc5a9b89078b96fd13d96631c926fb452643a8e537d7c9eb86b796ba15a6"
}