📅 Original date posted:2016-01-27
📝 Original message:
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
Rusty Russell [ARCHIVE] /
npub1zw…hkhpx
2023-06-09 12:45:33
in reply to nevent1q…u8hu
Author Public Key
npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpxPublished at
2023-06-09 12:45:33Event JSON
{
"id": "6be407793afc7c9a8a3289986b2bbf6fd241b3225dc2fefd78ce68dbced58596",
"pubkey": "13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425",
"created_at": 1686314733,
"kind": 1,
"tags": [
[
"e",
"1a61101c4617aecbef63f89e90e92d029874cb7e068b2b0dce3ecb1bf14d55f8",
"",
"reply"
],
[
"p",
"9456f7acb763eaab2e02bd8e60cf17df74f352c2ae579dce1f1dd25c95dd611c"
]
],
"content": "📅 Original date posted:2016-01-27\n📝 Original message:\nHi all!\n\n As more code emerges, I'd like to try to nail down a \"1.0\"\nversion of the inter-node protocol as much as possible. Since I'm most\nfamiliar with my own code (c-lightning[1]), I'll use that as a basis and\ndiscuss differences (esp. vs lnd[2]).\n\nFor this email I'll simply list the changes or proposals I'm aware of,\nthen we can dissect and comment on each one: defer, accept or close.\n\nDirect wire format stuff\n------------------------\n\n- Protobufs vs open-coded structures\n - lnd open-coded their own protocol; I haven't finished reading their\n code though.\n - protobufs are easy to extend with new fields; with an open-coded\n proto we simply need a rule that too-long packets are valid.\n - protobufs are annoying for fixed-length blobs which we use a lot\n (keys, signatures, hashes).\n - The protocol is currently simple with very few variable-length fields.\n\n- Length prefix for initial key exchange\n - Both lnd and c-lightning begin by exchanging a 33-byte EC key for DH.\n - We should prefix with a length word, so we can extend this later\n (eg. for new crypto)\n\n- Length prefix for other packets\n - lightning-c sends an 8 byte prefix indicating the offset of the end of\n the current packet: this effectively encodes both length and ordering.\n - lnd uses a 4 byte network ID, 4 byte type, 4 byte length.\n\n- HTLC pipelining\n - lnd's protocol supports multiple in-flight HTLC negotiations; this\n would allow much greater throughput, with some complexity.\n - lightning-c uses a simple one-at-a-time scheme, with alternating\n priority in case of simultaneous sends.\n\n- HTLC abort stage\n - Setting up a new HTLC involves both sides accepting, then revocation\n message exchange. Currently there's no way to abort this process.\n - Allow the initator to abort any time before the revocation exchange,\n for weird corner cases such as timeouts.\n\n- Version bits\n - If we use an open-coded protocol, initial handshake after key setup\n should exchange two sets of version bits: one for compulsory\n features, one for optional features. You hang up if there's a\n compulsory feature you don't grok.\n\nWire protocol crypto\n--------------------\n- Crypto AES/HMAC-SHA256 or Chacha20/Poly1305\n - AES has the word Standard in the name, but chacha20 is faster w/o\n accel (ie. ARM) and almost as widely supported.\n \n- Use separate encoding stream for packet lengths\n - Laolu's suggestion; encode the packet lengths as well which makes\n traffic analysis a bit harder.\n - Makes it a bit harder to detect re-transmissions (required on node\n restart), but probably not enough to kill the idea?\n\nMisc\n----\n- shachain vs elkrem\n - We use this to generate the revocation secrets, to minimize storage\n and computation for a huge number of old commitment txs.\n - They're actually very similar, but elkrem is much easier to grok.[6]\n\n- Anchor tx renegotiation\n - We should allow re-anchoring of channels, to add or remove funds.\n - This would allow easy payment from lightning channel to normal\n bitcoin addresses, for example.\n - During transition, signatures for both commit txs must be exchanged.\n\n- R value vs keypair\n - Using a simple secret \"redeemhash\" allows easy tracing of\n transactions through the network.\n - Mats Jeratsch proposed a keypair scheme which decorrelates them[3],\n Greg Maxwell optimized it slightly, and Anthony Towns[4] and Andrew\n Poelstra independently came up with a way to do it without any\n bitcoin mods.\n\n- Multi-sig txs\n - Joseph pointed out that by simply allowing more than one signature on\n commit txs[5], we can enable escrow-style services (including things\n like GreenAddress.it which does this for normal wallets).\n\nI'm sure I've missed things; what are they?\n\nThanks!\nRusty.\n\n[1] https://github.com/ElementsProject/lightning\n[2] https://github.com/LightningNetwork/lnd\n[3] http://lists.linuxfoundation.org/pipermail/lightning-dev/2015-November/000314.html\n[4] http://lists.linuxfoundation.org/pipermail/lightning-dev/2015-November/000344.html\n[5] http://lists.linuxfoundation.org/pipermail/lightning-dev/2016-January/000403.html\n[6] https://github.com/LightningNetwork/lnd/blob/master/elkrem/elkrem.go",
"sig": "ba979b96be1995e7e2cf726ab334e38b16cacdbf321213f78d50b74375926cc466534c46f246e11c0af5d9d8c7c6f6800207891479f7936990b1c65a09d7353f"
}