📅 Original date posted:2013-06-20
📝 Original message:On Thu, Jun 20, 2013 at 09:36:40AM +0200, Mike Hearn wrote:
> Sure but why not do that when there's an actual new field to add? Does
> anyone have a proposal for a feature that needs a new version field at the
> moment? There's no point changing the protocol now unless there's actually
> a new field to add.
>
> Anyway I still don't see why anyone cares about this issue. The Bitcoin
> protocol does not and never has required that all messages have a fixed
> number of fields per version. Any parser written on the assumption it did
> was just buggy. Look at how tx messages are relayed for the most obvious
> example of that pattern in action - it's actually the raw byte stream
> that's stored and relayed to ensure that fields added in new versions
> aren't dropped during round-tripping. Old versions are supposed to preserve
> fields from the future.
Actually, that is not the same issue. What is being argued for here is that
the version in the version message itself should indicate which fields are
present, so a parser doesn't need to look at the length of the message. That
seems like a minor but very reasonable request to me, and it's trivial to do.
That doesn't mean that you may receive versions higher than what you know of,
and thus messages with fields you don't know about. That doesn't matter, you
can just ignore them.
I see no problem with raising the protocol version number to indicate
"all fields up to fRelayTxes are required, if the announced nVersion is above N".
In fact, I believe (though haven't checked) all previous additions to the version
message were accompanied with a protocol version (then: client version) increase
as well.
--
Pieter
Pieter Wuille [ARCHIVE] /
npub1tj…jtl6r
2023-06-07 15:03:47
in reply to nevent1q…s9s4
Author Public Key
npub1tjephawh7fdf6358jufuh5eyxwauzrjqa7qn50pglee4tayc2ntqcjtl6rPublished at
2023-06-07 15:03:47Event JSON
{
"id": "99f07b753cef04e1e2e82e1710ae3fbca803152ac4c56a08ca438897228c4b5b",
"pubkey": "5cb21bf5d7f25a9d46879713cbd32433bbc10e40ef813a3c28fe7355f49854d6",
"created_at": 1686150227,
"kind": 1,
"tags": [
[
"e",
"e9b1d9a1ddf5c8677e9abe0f134ce38b3c249cc7d3052122574b8fda5672d89b",
"",
"root"
],
[
"e",
"0f38959080abd63765327b5816176bc17e355675a906f8d6a50225f0011f89eb",
"",
"reply"
],
[
"p",
"c632841665fccdabf021322b1d969539c9c1f829ceed38844fea24e8512962d7"
]
],
"content": "📅 Original date posted:2013-06-20\n📝 Original message:On Thu, Jun 20, 2013 at 09:36:40AM +0200, Mike Hearn wrote:\n\u003e Sure but why not do that when there's an actual new field to add? Does\n\u003e anyone have a proposal for a feature that needs a new version field at the\n\u003e moment? There's no point changing the protocol now unless there's actually\n\u003e a new field to add.\n\u003e \n\u003e Anyway I still don't see why anyone cares about this issue. The Bitcoin\n\u003e protocol does not and never has required that all messages have a fixed\n\u003e number of fields per version. Any parser written on the assumption it did\n\u003e was just buggy. Look at how tx messages are relayed for the most obvious\n\u003e example of that pattern in action - it's actually the raw byte stream\n\u003e that's stored and relayed to ensure that fields added in new versions\n\u003e aren't dropped during round-tripping. Old versions are supposed to preserve\n\u003e fields from the future.\n\nActually, that is not the same issue. What is being argued for here is that\nthe version in the version message itself should indicate which fields are\npresent, so a parser doesn't need to look at the length of the message. That\nseems like a minor but very reasonable request to me, and it's trivial to do.\nThat doesn't mean that you may receive versions higher than what you know of,\nand thus messages with fields you don't know about. That doesn't matter, you\ncan just ignore them.\n\nI see no problem with raising the protocol version number to indicate\n\"all fields up to fRelayTxes are required, if the announced nVersion is above N\".\nIn fact, I believe (though haven't checked) all previous additions to the version\nmessage were accompanied with a protocol version (then: client version) increase\nas well.\n\n-- \nPieter",
"sig": "f11361a697951c13f9271cb29e531aa2889638f33b9ebf0a7e556458783b606bf20e66220fd8d9e8cb6a05954857f2b308f037d017c4ef02017543a29196b0d8"
}