Rusty Russell [ARCHIVE] on Nostr: 📅 Original date posted:2016-02-01 📝 Original message: Fabrice Drouin ...
📅 Original date posted:2016-02-01
📝 Original message:
Fabrice Drouin <fabrice.drouin at acinq.fr> writes:
> On 27 January 2016 at 04:07, Rusty Russell <rusty at rustcorp.com.au> wrote:
> Hello,
>
> We (Pierre and I, the guys who work on the scala thingy :-) would
> rather use a "standard" binary format and protobuf seems to be a very
> good choice. Since incoming messages are encrypted, text based formats
> (JSON, ...) would not help that much for debugging and are not imho a
> good fit for binary protocols.
Well, I'm thinking of providing a binary which will do the crypto and
provide a (generated) JSON interface. That will keep the JSON people
happy, separate out the crypto and wire-protocol issues, and generally
give one less thing to worry about. I can also keep it up to date as we
debate formats...
>> - Length prefix for initial key exchange
>> - Both lnd and c-lightning begin by exchanging a 33-byte EC key for DH.
>> - We should prefix with a length word, so we can extend this later
>> (eg. for new crypto)
> Agreed.
>
>> - HTLC pipelining
>> - lnd's protocol supports multiple in-flight HTLC negotiations; this
>> would allow much greater throughput, with some complexity.
>> - lightning-c uses a simple one-at-a-time scheme, with alternating
>> priority in case of simultaneous sends.
>
> Just to be sure that we understand this, you mean grouping HTLCs and
> sending them with one message (so just one signature will be
> exchanged). It becomes more complex for clients because they will have
> to buffer and group incoming HTLCs but the protocol and the
> transitions remain pretty much the same ?
I haven't got a description of lnd's protocol, but I've been thinking
about it. We can certainly be more optimal than the 4 trips per change
we have now (amortized).
See the other thread "Protocol for multiple in-flight updates.".
>> Misc
>> ----
>> - shachain vs elkrem
>> - We use this to generate the revocation secrets, to minimize storage
>> and computation for a huge number of old commitment txs.
>> - They're actually very similar, but elkrem is much easier to grok.[6]
> I like both, they're easy to implement and elkrem was indeed much
> easier to understand. I don't know precisely why yet but I would
> choose shachain though.
I have to write up a better explanation of shachain. And as AJ points
out, it should be defined in the other direction to be more like chains
in the literature, so seed is index 0, first value is index 2^64-1...
Cheers,
Rusty.
📝 Original message:
Fabrice Drouin <fabrice.drouin at acinq.fr> writes:
> On 27 January 2016 at 04:07, Rusty Russell <rusty at rustcorp.com.au> wrote:
> Hello,
>
> We (Pierre and I, the guys who work on the scala thingy :-) would
> rather use a "standard" binary format and protobuf seems to be a very
> good choice. Since incoming messages are encrypted, text based formats
> (JSON, ...) would not help that much for debugging and are not imho a
> good fit for binary protocols.
Well, I'm thinking of providing a binary which will do the crypto and
provide a (generated) JSON interface. That will keep the JSON people
happy, separate out the crypto and wire-protocol issues, and generally
give one less thing to worry about. I can also keep it up to date as we
debate formats...
>> - Length prefix for initial key exchange
>> - Both lnd and c-lightning begin by exchanging a 33-byte EC key for DH.
>> - We should prefix with a length word, so we can extend this later
>> (eg. for new crypto)
> Agreed.
>
>> - HTLC pipelining
>> - lnd's protocol supports multiple in-flight HTLC negotiations; this
>> would allow much greater throughput, with some complexity.
>> - lightning-c uses a simple one-at-a-time scheme, with alternating
>> priority in case of simultaneous sends.
>
> Just to be sure that we understand this, you mean grouping HTLCs and
> sending them with one message (so just one signature will be
> exchanged). It becomes more complex for clients because they will have
> to buffer and group incoming HTLCs but the protocol and the
> transitions remain pretty much the same ?
I haven't got a description of lnd's protocol, but I've been thinking
about it. We can certainly be more optimal than the 4 trips per change
we have now (amortized).
See the other thread "Protocol for multiple in-flight updates.".
>> Misc
>> ----
>> - shachain vs elkrem
>> - We use this to generate the revocation secrets, to minimize storage
>> and computation for a huge number of old commitment txs.
>> - They're actually very similar, but elkrem is much easier to grok.[6]
> I like both, they're easy to implement and elkrem was indeed much
> easier to understand. I don't know precisely why yet but I would
> choose shachain though.
I have to write up a better explanation of shachain. And as AJ points
out, it should be defined in the other direction to be more like chains
in the literature, so seed is index 0, first value is index 2^64-1...
Cheers,
Rusty.