CJP [ARCHIVE] on Nostr: 📅 Original date posted:2016-01-27 📝 Original message: There are a couple of ...
📅 Original date posted:2016-01-27
📝 Original message:
There are a couple of subjects where new concepts are being worked out,
or where alternative concepts exist; these things are likely to continue
to evolve after you finish the first version of the protocol.
It would be great if concept changes in one subject can be made more or
less independently from concept changes in another subject. In order to
make this possible, I suggest to de-couple certain things, and let each
subject have its own sub-protocol, with version number / protocol
identifier.
The way I see it, the following subjects have ongoing design /
alternative concepts, more or less independently from each other:
* Micro-transaction channel design: e.g. several variations on the
Lightning channel design, and Amiko Pay's escrow-based HTLC emulation
and IOU semi-channel.
* Commit conditions: traditional definition consists of a hash value and
a time-out. For practical purposes, Amiko Pay also adds a "start time",
and there is an alternative concept of using keypairs instead of hash
values to de-correlate a transaction in different links.
* Routing: how to exchange routing info. For source routing: informing
each other about Lightning nodes that exist. For source and non-source
routing: informing each other about availability of routes, expected
capacity and fees. The type of routing info depends on the routing
algorithm in use by a node.
In Amiko Pay, the micro-transaction channel design is already separated
from the rest of the protocol; commit conditions are not (yet), and
exchange of routing info doesn't really exist yet, since it's still
doing "dumb" non-source routing (trying every possible route).
CJP
Rusty Russell schreef op wo 27-01-2016 om 13:37 [+1030]:
> Hi all!
>
> As more code emerges, I'd like to try to nail down a "1.0"
> version of the inter-node protocol as much as possible. Since I'm most
> familiar with my own code (c-lightning[1]), I'll use that as a basis and
> discuss differences (esp. vs lnd[2]).
>
> 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.
>
> 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.
>
> - 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)
>
> - 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.
>
> - 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.
>
> - 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.
>
> - 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.
>
> Wire protocol crypto
> --------------------
> - Crypto AES/HMAC-SHA256 or Chacha20/Poly1305
> - AES has the word Standard in the name, but chacha20 is faster w/o
> accel (ie. ARM) and almost as widely supported.
>
> - Use separate encoding stream for packet lengths
> - Laolu's suggestion; encode the packet lengths as well which makes
> traffic analysis a bit harder.
> - Makes it a bit harder to detect re-transmissions (required on node
> restart), but probably not enough to kill the idea?
>
> 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]
>
> - 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.
>
> - 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.
>
> - 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?
>
> Thanks!
> Rusty.
>
> [1] https://github.com/ElementsProject/lightning
> [2] https://github.com/LightningNetwork/lnd
> [3] http://lists.linuxfoundation.org/pipermail/lightning-dev/2015-November/000314.html
> [4] http://lists.linuxfoundation.org/pipermail/lightning-dev/2015-November/000344.html
> [5] http://lists.linuxfoundation.org/pipermail/lightning-dev/2016-January/000403.html
> [6] https://github.com/LightningNetwork/lnd/blob/master/elkrem/elkrem.go
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
📝 Original message:
There are a couple of subjects where new concepts are being worked out,
or where alternative concepts exist; these things are likely to continue
to evolve after you finish the first version of the protocol.
It would be great if concept changes in one subject can be made more or
less independently from concept changes in another subject. In order to
make this possible, I suggest to de-couple certain things, and let each
subject have its own sub-protocol, with version number / protocol
identifier.
The way I see it, the following subjects have ongoing design /
alternative concepts, more or less independently from each other:
* Micro-transaction channel design: e.g. several variations on the
Lightning channel design, and Amiko Pay's escrow-based HTLC emulation
and IOU semi-channel.
* Commit conditions: traditional definition consists of a hash value and
a time-out. For practical purposes, Amiko Pay also adds a "start time",
and there is an alternative concept of using keypairs instead of hash
values to de-correlate a transaction in different links.
* Routing: how to exchange routing info. For source routing: informing
each other about Lightning nodes that exist. For source and non-source
routing: informing each other about availability of routes, expected
capacity and fees. The type of routing info depends on the routing
algorithm in use by a node.
In Amiko Pay, the micro-transaction channel design is already separated
from the rest of the protocol; commit conditions are not (yet), and
exchange of routing info doesn't really exist yet, since it's still
doing "dumb" non-source routing (trying every possible route).
CJP
Rusty Russell schreef op wo 27-01-2016 om 13:37 [+1030]:
> Hi all!
>
> As more code emerges, I'd like to try to nail down a "1.0"
> version of the inter-node protocol as much as possible. Since I'm most
> familiar with my own code (c-lightning[1]), I'll use that as a basis and
> discuss differences (esp. vs lnd[2]).
>
> 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.
>
> 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.
>
> - 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)
>
> - 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.
>
> - 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.
>
> - 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.
>
> - 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.
>
> Wire protocol crypto
> --------------------
> - Crypto AES/HMAC-SHA256 or Chacha20/Poly1305
> - AES has the word Standard in the name, but chacha20 is faster w/o
> accel (ie. ARM) and almost as widely supported.
>
> - Use separate encoding stream for packet lengths
> - Laolu's suggestion; encode the packet lengths as well which makes
> traffic analysis a bit harder.
> - Makes it a bit harder to detect re-transmissions (required on node
> restart), but probably not enough to kill the idea?
>
> 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]
>
> - 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.
>
> - 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.
>
> - 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?
>
> Thanks!
> Rusty.
>
> [1] https://github.com/ElementsProject/lightning
> [2] https://github.com/LightningNetwork/lnd
> [3] http://lists.linuxfoundation.org/pipermail/lightning-dev/2015-November/000314.html
> [4] http://lists.linuxfoundation.org/pipermail/lightning-dev/2015-November/000344.html
> [5] http://lists.linuxfoundation.org/pipermail/lightning-dev/2016-January/000403.html
> [6] https://github.com/LightningNetwork/lnd/blob/master/elkrem/elkrem.go
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev