David A. Harding [ARCHIVE] on Nostr: 📅 Original date posted:2020-08-20 📝 Original message:On Sun, Aug 16, 2020 at ...
📅 Original date posted:2020-08-20
📝 Original message:On Sun, Aug 16, 2020 at 12:06:55PM -0700, Eric Voskuil via bitcoin-dev wrote:
> A requirement to ignore unknown (invalid) messages is [...] a protocol
> breaking change
I don't think it is. The proposed BIP, as currently written, only tells
nodes to ignore unknown messages during peer negotiation. The only case
where this will happen so far is BIP339, which says:
The wtxidrelay message must be sent in response to a VERSION message
from a peer whose protocol version is >= 70016, and prior to sending
a VERACK
So unless you signal support for version >=70016, you'll never receive an
unknown message. (And, if you do signal, you probably can't claim that
you were unaware of this new requirement, unless you were using a
non-BIP protocol like xthin[1]).
However, perhaps this new proposed BIP could be a bit clearer about its
expectations for future protocol upgrades by saying something like:
Nodes implementing this BIP MUST also not send new negotiation
message types to nodes whose protocol version is less than 70017.
That should promote backwards compatibility. If you don't want to
ignore unknown negotiation messages between `version` and `verack`, you
can just set your protocol version to a max of 70016.
> A requirement to ignore unknown (invalid) messages is [...] poor
> protocol design. The purpose of version negotiation is to determine
> the set of valid messages.
To be clear, the proposed requirement to ignore unknown messages is
limited in scope to the brief negotiation phase between `version` and
`verack`. If you want to terminate connections (or do whatever) on
receipt of an unknown message, you can do that at any other time.
> Changes to version negotiation itself are very problematic.
For whom?
> The only limitation presented by versioning is that the system is
> sequential.
That seems like a pretty significant limitation to decentralized
protocol development.
I think there are currently several people who want to run long-term
experiements for new protocol features using open source opt-in
codebases that anyone can run, and it would be advantageous to them to
have a flexible and lightweight feature negotiation system like this
proposed method.
> 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.
I don't understand this. How do two peers negotiate a set of two or
more optional features using only the exchange of single numbers? For
example:
- Node A supports Feature X (implemented in protocol version 70998) and Feature Y (version 70999).
- Node B does not support X but does want to use Y; what does it use for its
protocol version number when establishing a connection with node A?
---
Overall, I like the proposed BIP and the negotiation method it
describes.
Cheers,
-Dave
[1] This is not a recommendation for xthin, but I do think it's an example
of the challenges of using a shared linear version number scheme for
protocol negotiation in a decentralized system where different teams
don't necessarily get along well with each other.
https://github.com/ptschip/bitcoinxt/commit/7ea5854a3599851beffb1323544173f03d45373b#diff-c61070c281aed6ded69036c08bd08addR12
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200820/faec9a70/attachment.sig>;
📝 Original message:On Sun, Aug 16, 2020 at 12:06:55PM -0700, Eric Voskuil via bitcoin-dev wrote:
> A requirement to ignore unknown (invalid) messages is [...] a protocol
> breaking change
I don't think it is. The proposed BIP, as currently written, only tells
nodes to ignore unknown messages during peer negotiation. The only case
where this will happen so far is BIP339, which says:
The wtxidrelay message must be sent in response to a VERSION message
from a peer whose protocol version is >= 70016, and prior to sending
a VERACK
So unless you signal support for version >=70016, you'll never receive an
unknown message. (And, if you do signal, you probably can't claim that
you were unaware of this new requirement, unless you were using a
non-BIP protocol like xthin[1]).
However, perhaps this new proposed BIP could be a bit clearer about its
expectations for future protocol upgrades by saying something like:
Nodes implementing this BIP MUST also not send new negotiation
message types to nodes whose protocol version is less than 70017.
That should promote backwards compatibility. If you don't want to
ignore unknown negotiation messages between `version` and `verack`, you
can just set your protocol version to a max of 70016.
> A requirement to ignore unknown (invalid) messages is [...] poor
> protocol design. The purpose of version negotiation is to determine
> the set of valid messages.
To be clear, the proposed requirement to ignore unknown messages is
limited in scope to the brief negotiation phase between `version` and
`verack`. If you want to terminate connections (or do whatever) on
receipt of an unknown message, you can do that at any other time.
> Changes to version negotiation itself are very problematic.
For whom?
> The only limitation presented by versioning is that the system is
> sequential.
That seems like a pretty significant limitation to decentralized
protocol development.
I think there are currently several people who want to run long-term
experiements for new protocol features using open source opt-in
codebases that anyone can run, and it would be advantageous to them to
have a flexible and lightweight feature negotiation system like this
proposed method.
> 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.
I don't understand this. How do two peers negotiate a set of two or
more optional features using only the exchange of single numbers? For
example:
- Node A supports Feature X (implemented in protocol version 70998) and Feature Y (version 70999).
- Node B does not support X but does want to use Y; what does it use for its
protocol version number when establishing a connection with node A?
---
Overall, I like the proposed BIP and the negotiation method it
describes.
Cheers,
-Dave
[1] This is not a recommendation for xthin, but I do think it's an example
of the challenges of using a shared linear version number scheme for
protocol negotiation in a decentralized system where different teams
don't necessarily get along well with each other.
https://github.com/ptschip/bitcoinxt/commit/7ea5854a3599851beffb1323544173f03d45373b#diff-c61070c281aed6ded69036c08bd08addR12
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200820/faec9a70/attachment.sig>;