[Lightning-dev] type,len,value standard

Conner Fromknecht conner at lightning.engineering
Fri Nov 16 00:12:45 UTC 2018

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.


On Thu, Nov 15, 2018 at 1:45 AM ZmnSCPxj <ZmnSCPxj at 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

More information about the Lightning-dev mailing list