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 <zmnsc...@protonmail.com> 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 _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
