[Lightning-dev] type,len,value standard

[Conner Fromknecht]

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 <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