From rusty at rustcorp.com.au Wed Oct 28 00:32:18 2015 From: rusty at rustcorp.com.au (Rusty Russell) Date: Wed, 28 Oct 2015 11:02:18 +1030 Subject: [Lightning-dev] [PATCH v3] daemon: encrypted communication (version 3) In-Reply-To: <20151027204046.GG27905@muck> References: <87twpibc7m.fsf@rustcorp.com.au> <87io5sw13z.fsf@rustcorp.com.au> <20151027204046.GG27905@muck> Message-ID: <871tcfx27h.fsf@rustcorp.com.au> Peter Todd writes: > On Wed, Oct 28, 2015 at 06:11:20AM +1030, Rusty Russell wrote: >> Pierre 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.