From conner at lightning.engineering Fri Nov 16 00:12:45 2018 From: conner at lightning.engineering (Conner Fromknecht) Date: Thu, 15 Nov 2018 16:12:45 -0800 Subject: [Lightning-dev] type,len,value standard In-Reply-To: References: Message-ID: Hi ZmnSCPxj, Precisely, something like that is what I had in mind. Since the max message size is 65KB, one option could be to only allow the varint to be max 2 bytes where: - if the 8th bit is not set, the lowest 7 bits of the first bytes translate to 0 - 127 - if the 8th bit is set, this implies that the second byte is also treated as part of the length, and the total value is 0x7f & first byte + second byte << 7 This would be fairly straightforward to implement, at the cost of limiting a particular field to 2^15 bytes. I wonder, is this too restrictive? At the same time, we could offer a varint that could extend up to the three bytes. The third byte would only come in to play if the length of the field is greater than 2^14 - 1. The argument could be made that for values of this size, one extra byte is irrelevant compared to the size of these larger fields. Cheers, Conner On Thu, Nov 15, 2018 at 1:45 AM ZmnSCPxj wrote: > > Good morning Conner et al, > > > > > 5. `len` - one byte or two? I believe we tend to use two bytes for various > > > > lengths. > > > > > > > > > > Maybe varint? One byte is not enough for all lengths, but two seems excessive > > > for uint8 or even uint32. > > > > Given that messages are currently only up to 65536 bytes total, is that not a bit much? > > Sorry, I misunderstood. > > This is varint, correct? http://learnmeabitcoin.com/glossary/varint > > If so, I think this is good idea. > It seems we do not have varint currently in Lightning (at least the parts I am familiar with). > I suppose the t-l-v being in a different BOLT would let us make some section or part for describing `varint`. > > Regards, > ZmnSCPxj