Rusty Russell [ARCHIVE] on Nostr: 📅 Original date posted:2016-01-28 📝 Original message: Mats Jerratsch ...
📅 Original date posted:2016-01-28
📝 Original message:
Mats Jerratsch <mats.jerratsch at blockchain.com> writes:
> https://github.com/lightning-core/lightning
>
> and writing up their specifications so others do not have to search
> through code, plus separating code from design is good practice. It
> will also be easier to commit to them once the discussion is done.
ACK.
>> For this email I'll simply list the changes or proposals I'm aware
>> of, then we can dissect and comment on each one: defer, accept or
>> close.
> I am so free and add changes from TN :)
Fantastic, thanks.
>> Direct wire format stuff ------------------------
>>
>> - Protobufs vs open-coded structures - lnd open-coded their own
>> protocol; I haven't finished reading their code though. - protobufs
>> are easy to extend with new fields; with an open-coded proto we
>> simply need a rule that too-long packets are valid. - protobufs are
>> annoying for fixed-length blobs which we use a lot (keys,
>> signatures, hashes). - The protocol is currently simple with very
>> few variable-length
> fields.
> - - TN currently is using JSON encoded objects. It is by no standard
> efficient, but allows for easy integration of other systems and
> it's easy to extend/modify.
>
> Right now I think the open-coded messaging is a bit too much. You
> don't get the efficiency of protobufs, nor the readibility of JSON,
> but still have to manually code each serialisation/deserialisation,
> and each change to the messages has to be carefully inserted into
> these functions.
I'm extremely reluctant to use JSON for wire formats beyond prototyping;
I really prefer formats where there is only one possible representation
of any given message, and where parsing is as trivial as possible.
I would be generating my serialization code anyway, ideally from some
spec document directly.
I'll hack up a binary protocol and see if it lines up into nice, neatly
packed structs. I can write you a JSON translation layer if you want :)
> I still don't think JSON is a bad choice for the beginning. If it
> actually turns out to be a bottleneck it is a very low-hanging fruit.
>
> I would rather adapt something like protobufs if it comes to it. (I
> heard there are other *bufs, maybe some of these serve us better?)
Unfortunately the other contender (Capnproto) doesn't fix our worst pain
point either, which is fixed-size blobs.
>> - 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)
> Agree, same on TN.
>
> Won't new crypto be non-compatibily anyways?
The length word makes it backwards compatible. If you see extra data,
you know they're using crypto v2, and ignore the old key.
>> - Length prefix for other packets - lightning-c sends an 8 byte
>> prefix indicating the offset of the
> end of
>> the current packet: this effectively encodes both length and
> ordering.
>> - lnd uses a 4 byte network ID, 4 byte type, 4 byte length.
> - - TN uses 4 byte length, type is JSON encoded (message types are
> completely taken care of of GSON)
>
> I agree that a network ID prefix might make sense. Probably worth
> designing for an equivalent of testnet (and they should not just
> differ by the standard port they run on... )
Definitely in the original handshake, but on every packet seems a bit
extreme?
>> - 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.
> - - TN allows for adding / settling / refunding arbitrary amount of
> HTLCs at the same time.
>
> Agree with lnd here, the complexity is worth it IMO.
OK. There are a few ways of doing it. Any change is a 4-step process,
"offer, accept, sig+oldrevocation, sig+oldrevocation" (though my
protocol put the last sig in the accept, that is ugly and wrong, see
below).
So simplest is to tag each one with what HTLC it's talking about: lnd
introduces 64 bit HTLCs ids to optimize this. IIUC for clarity, one
party uses even ids, the other odd, counting in order.
If you want to batch signing as well, so you can say "I include
everything up to change #N, here's the signature", we'd skip the HTLC id
and use an incrementing offer id. But I think this step is overkill?
>> - HTLC abort stage - Setting up a new HTLC involves both sides
>> accepting, then revocation message exchange. Currently there's no
>> way to abort this process. - Allow the initator to abort any time
>> before the revocation exchange, for weird corner cases such as
>> timeouts.
> - - TN allows for any party to start a new exchange to abort the
> current one. I adapted the dice-rolling from CJP, in case both
> initiate at the same time.
If we allow parallel negotiation, we don't need a priority scheme I
think? But we do need an explicit abort.
> - - It is important be careful with revocation hashes when aborting.
> You don't want the other party to hold on to an unrevoked tx...
I think you really want to send the old revocation hash and the sig for
the new tx together. At that point, aborting is no longer possible and
you have to cancel through normal means...
ie. You can send "add this please", and then "abort that".
>> - Version bits - If we use an open-coded protocol, initial
>> handshake after key setup should exchange two sets of version bits:
>> one for compulsory features, one for optional features. You hang
>> up if there's a compulsory feature you don't grok.
>
> Good point, agree here.
OK, I'll add.
>> - Anchor tx renegotiation - We should allow re-anchoring of
>> channels, to add or remove funds. - This would allow easy payment
>> from lightning channel to normal bitcoin addresses, for example. -
>> During transition, signatures for both commit txs must be
>> exchanged.
>
> This sounds like a 1.1 feature. Agree that we should allow it, but
> does not seem urgent right now.
Agreed; stuff we can defer is good....
>> - R value vs keypair - Using a simple secret "redeemhash" allows
>> easy tracing of transactions through the network. - Mats Jeratsch
>> proposed a keypair scheme which decorrelates them[3], Greg Maxwell
>> optimized it slightly, and Anthony Towns[4] and Andrew Poelstra
>> independently came up with a way to do it without any bitcoin
>> mods.
>
> Currently I am using R value, I am still a bit afraid of the lengthy
> scripts when doing it without bitcoin mods. Might make sense to just
> design the system in a way that it's easy to change later than to
> implement it already.
Yes, everyone is on R AFAIK. This might be worth deferring, if only
because it raises the interesting question on how we would do the
upgrade (every node on your path needs to understand the new version).
>> - Multi-sig txs - Joseph pointed out that by simply allowing more
>> than one
> signature on
>> commit txs[5], we can enable escrow-style services (including
>> things like GreenAddress.it which does this for normal wallets).
>>
>> I'm sure I've missed things; what are they?
>
> Would be great to discuss connection/node failures. TN currently does
> not support 'picking up' a lost connection again. I feel like anything
> that MUST be finished on resume should rather be saved on hard disk in
> advance, designing for various node failure modes.
> Restarting a fresh connection seems to be much cleaner for me?
Yes, TBA for me too.
There should be a new crypto handshake, then the conversation should
continue as before.
This means you need to save state, and also tolerate limited amount of
identical re-transmission. My plan for c-lightning was to hand this at
a layer between the state machine and cryptopkt: if we see a
retransmission we replay our previous responses. My current state
machine could theoretically send out 4 packets in a row after receiving
one (decline, propose new, close, error), but this would be more if we
allow multiple parallel change negotiations.
Cheers,
Rusty.
📝 Original message:
Mats Jerratsch <mats.jerratsch at blockchain.com> writes:
> https://github.com/lightning-core/lightning
>
> and writing up their specifications so others do not have to search
> through code, plus separating code from design is good practice. It
> will also be easier to commit to them once the discussion is done.
ACK.
>> For this email I'll simply list the changes or proposals I'm aware
>> of, then we can dissect and comment on each one: defer, accept or
>> close.
> I am so free and add changes from TN :)
Fantastic, thanks.
>> Direct wire format stuff ------------------------
>>
>> - Protobufs vs open-coded structures - lnd open-coded their own
>> protocol; I haven't finished reading their code though. - protobufs
>> are easy to extend with new fields; with an open-coded proto we
>> simply need a rule that too-long packets are valid. - protobufs are
>> annoying for fixed-length blobs which we use a lot (keys,
>> signatures, hashes). - The protocol is currently simple with very
>> few variable-length
> fields.
> - - TN currently is using JSON encoded objects. It is by no standard
> efficient, but allows for easy integration of other systems and
> it's easy to extend/modify.
>
> Right now I think the open-coded messaging is a bit too much. You
> don't get the efficiency of protobufs, nor the readibility of JSON,
> but still have to manually code each serialisation/deserialisation,
> and each change to the messages has to be carefully inserted into
> these functions.
I'm extremely reluctant to use JSON for wire formats beyond prototyping;
I really prefer formats where there is only one possible representation
of any given message, and where parsing is as trivial as possible.
I would be generating my serialization code anyway, ideally from some
spec document directly.
I'll hack up a binary protocol and see if it lines up into nice, neatly
packed structs. I can write you a JSON translation layer if you want :)
> I still don't think JSON is a bad choice for the beginning. If it
> actually turns out to be a bottleneck it is a very low-hanging fruit.
>
> I would rather adapt something like protobufs if it comes to it. (I
> heard there are other *bufs, maybe some of these serve us better?)
Unfortunately the other contender (Capnproto) doesn't fix our worst pain
point either, which is fixed-size blobs.
>> - 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)
> Agree, same on TN.
>
> Won't new crypto be non-compatibily anyways?
The length word makes it backwards compatible. If you see extra data,
you know they're using crypto v2, and ignore the old key.
>> - Length prefix for other packets - lightning-c sends an 8 byte
>> prefix indicating the offset of the
> end of
>> the current packet: this effectively encodes both length and
> ordering.
>> - lnd uses a 4 byte network ID, 4 byte type, 4 byte length.
> - - TN uses 4 byte length, type is JSON encoded (message types are
> completely taken care of of GSON)
>
> I agree that a network ID prefix might make sense. Probably worth
> designing for an equivalent of testnet (and they should not just
> differ by the standard port they run on... )
Definitely in the original handshake, but on every packet seems a bit
extreme?
>> - 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.
> - - TN allows for adding / settling / refunding arbitrary amount of
> HTLCs at the same time.
>
> Agree with lnd here, the complexity is worth it IMO.
OK. There are a few ways of doing it. Any change is a 4-step process,
"offer, accept, sig+oldrevocation, sig+oldrevocation" (though my
protocol put the last sig in the accept, that is ugly and wrong, see
below).
So simplest is to tag each one with what HTLC it's talking about: lnd
introduces 64 bit HTLCs ids to optimize this. IIUC for clarity, one
party uses even ids, the other odd, counting in order.
If you want to batch signing as well, so you can say "I include
everything up to change #N, here's the signature", we'd skip the HTLC id
and use an incrementing offer id. But I think this step is overkill?
>> - HTLC abort stage - Setting up a new HTLC involves both sides
>> accepting, then revocation message exchange. Currently there's no
>> way to abort this process. - Allow the initator to abort any time
>> before the revocation exchange, for weird corner cases such as
>> timeouts.
> - - TN allows for any party to start a new exchange to abort the
> current one. I adapted the dice-rolling from CJP, in case both
> initiate at the same time.
If we allow parallel negotiation, we don't need a priority scheme I
think? But we do need an explicit abort.
> - - It is important be careful with revocation hashes when aborting.
> You don't want the other party to hold on to an unrevoked tx...
I think you really want to send the old revocation hash and the sig for
the new tx together. At that point, aborting is no longer possible and
you have to cancel through normal means...
ie. You can send "add this please", and then "abort that".
>> - Version bits - If we use an open-coded protocol, initial
>> handshake after key setup should exchange two sets of version bits:
>> one for compulsory features, one for optional features. You hang
>> up if there's a compulsory feature you don't grok.
>
> Good point, agree here.
OK, I'll add.
>> - Anchor tx renegotiation - We should allow re-anchoring of
>> channels, to add or remove funds. - This would allow easy payment
>> from lightning channel to normal bitcoin addresses, for example. -
>> During transition, signatures for both commit txs must be
>> exchanged.
>
> This sounds like a 1.1 feature. Agree that we should allow it, but
> does not seem urgent right now.
Agreed; stuff we can defer is good....
>> - R value vs keypair - Using a simple secret "redeemhash" allows
>> easy tracing of transactions through the network. - Mats Jeratsch
>> proposed a keypair scheme which decorrelates them[3], Greg Maxwell
>> optimized it slightly, and Anthony Towns[4] and Andrew Poelstra
>> independently came up with a way to do it without any bitcoin
>> mods.
>
> Currently I am using R value, I am still a bit afraid of the lengthy
> scripts when doing it without bitcoin mods. Might make sense to just
> design the system in a way that it's easy to change later than to
> implement it already.
Yes, everyone is on R AFAIK. This might be worth deferring, if only
because it raises the interesting question on how we would do the
upgrade (every node on your path needs to understand the new version).
>> - Multi-sig txs - Joseph pointed out that by simply allowing more
>> than one
> signature on
>> commit txs[5], we can enable escrow-style services (including
>> things like GreenAddress.it which does this for normal wallets).
>>
>> I'm sure I've missed things; what are they?
>
> Would be great to discuss connection/node failures. TN currently does
> not support 'picking up' a lost connection again. I feel like anything
> that MUST be finished on resume should rather be saved on hard disk in
> advance, designing for various node failure modes.
> Restarting a fresh connection seems to be much cleaner for me?
Yes, TBA for me too.
There should be a new crypto handshake, then the conversation should
continue as before.
This means you need to save state, and also tolerate limited amount of
identical re-transmission. My plan for c-lightning was to hand this at
a layer between the state machine and cryptopkt: if we see a
retransmission we replay our previous responses. My current state
machine could theoretically send out 4 packets in a row after receiving
one (decline, propose new, close, error), but this would be more if we
allow multiple parallel change negotiations.
Cheers,
Rusty.