📅 Original date posted:2015-10-27
📝 Original message:
Peter Todd <pete at petertodd.org> writes:
> On Wed, Oct 28, 2015 at 06:11:20AM +1030, Rusty Russell wrote:
>> Pierre <pm+lists at acinq.fr> writes:
>> > Hi Rusty,
>> >
>> >> 5) Unknown protobuf fields are handled in the protocol as follows
>> >> (including in the initial Authenticate packet):
>> >>
>> >> 1) Odd numbered fields are optional, and backwards compatible.
>> >> 2) Even numbered fields are required; abort if you get one.
>> >
>> > I don't get it, what is it about ?
>>
>> Yes, I really need to write this up in Matsjj's lightning-core docs
>> repository.
>>
>> Since protobuf fields are explicitly numbered, we can use this to
>> deliberately break backwards compatibility in future after some
>> transition.
>>
>> For example, if we want to add a "currency identifier" field in HTLC,
>> for non-bitcoin transactions. That would be an even numbered field,
>> since you need to understand it. (There would also need to be some way
>> to indicate you support those, during connection setup or something).
>>
>> But if we want to add an optional new field, we'd make it odd, and
>> existing implementations could ignore it.
>
> FWIW an analogous idea is OpenPGP's "critical bit" for packets, which
> indicates that if the software doesn't understand the packet it should
> consider the signature to be invalid:
>
> https://tools.ietf.org/html/rfc4880#section-5.2.3.1
Yes, it's a pretty simple idea. In lightning, you should probably never
send an implementation a packet it won't understand (after the initial
handshake stage), but it still serves as belt-and-braces check.
eg. if we want to introduce a field with the intent to eventually make
it optional, we would add it as *two* optional fields, say 11 and 12.
You could set one or the other, not both, but accept either. In a few
years' time, implementations would stop using 11.
Cheers,
Rusty.
Rusty Russell [ARCHIVE] /
npub1zw…hkhpx
2023-06-09 12:44:56
in reply to nevent1q…6vq6
Author Public Key
npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpxPublished at
2023-06-09 12:44:56Event JSON
{
"id": "c224781531b52446b26c359f51b7a44be0d8f843c6289a5639c944a68594c247",
"pubkey": "13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425",
"created_at": 1686314696,
"kind": 1,
"tags": [
[
"e",
"8f7f2db21682c914495fbd222b86e1fdad7235916c75551e48ed09d538570897",
"",
"root"
],
[
"e",
"14e8cb2991c5ba3170f32a9c6064984d37c70879fec4759ec7421d9a55924adf",
"",
"reply"
],
[
"p",
"daa2fc676a25e3b5b45644540bcbd1e1168b111427cd0e3cf19c56194fb231aa"
]
],
"content": "📅 Original date posted:2015-10-27\n📝 Original message:\nPeter Todd \u003cpete at petertodd.org\u003e writes:\n\u003e On Wed, Oct 28, 2015 at 06:11:20AM +1030, Rusty Russell wrote:\n\u003e\u003e Pierre \u003cpm+lists at acinq.fr\u003e writes:\n\u003e\u003e \u003e Hi Rusty,\n\u003e\u003e \u003e\n\u003e\u003e \u003e\u003e 5) Unknown protobuf fields are handled in the protocol as follows\n\u003e\u003e \u003e\u003e (including in the initial Authenticate packet):\n\u003e\u003e \u003e\u003e\n\u003e\u003e \u003e\u003e 1) Odd numbered fields are optional, and backwards compatible.\n\u003e\u003e \u003e\u003e 2) Even numbered fields are required; abort if you get one.\n\u003e\u003e \u003e\n\u003e\u003e \u003e I don't get it, what is it about ?\n\u003e\u003e \n\u003e\u003e Yes, I really need to write this up in Matsjj's lightning-core docs\n\u003e\u003e repository.\n\u003e\u003e \n\u003e\u003e Since protobuf fields are explicitly numbered, we can use this to\n\u003e\u003e deliberately break backwards compatibility in future after some\n\u003e\u003e transition.\n\u003e\u003e \n\u003e\u003e For example, if we want to add a \"currency identifier\" field in HTLC,\n\u003e\u003e for non-bitcoin transactions. That would be an even numbered field,\n\u003e\u003e since you need to understand it. (There would also need to be some way\n\u003e\u003e to indicate you support those, during connection setup or something).\n\u003e\u003e \n\u003e\u003e But if we want to add an optional new field, we'd make it odd, and\n\u003e\u003e existing implementations could ignore it.\n\u003e\n\u003e FWIW an analogous idea is OpenPGP's \"critical bit\" for packets, which\n\u003e indicates that if the software doesn't understand the packet it should\n\u003e consider the signature to be invalid:\n\u003e\n\u003e https://tools.ietf.org/html/rfc4880#section-5.2.3.1\n\nYes, it's a pretty simple idea. In lightning, you should probably never\nsend an implementation a packet it won't understand (after the initial\nhandshake stage), but it still serves as belt-and-braces check.\n\neg. if we want to introduce a field with the intent to eventually make\nit optional, we would add it as *two* optional fields, say 11 and 12.\nYou could set one or the other, not both, but accept either. In a few\nyears' time, implementations would stop using 11.\n\nCheers,\nRusty.",
"sig": "d0419786772bb0a98095937c92524b1bd2b513265a85f884d84299906c5b6b6c9195e11c454ee5bcc1a181e9597ea58f51d12c496acb4d99f96a4c8bc6420fd2"
}