From rusty at rustcorp.com.au  Wed Jan 27 03:07:04 2016
From: rusty at rustcorp.com.au (Rusty Russell)
Date: Wed, 27 Jan 2016 13:37:04 +1030
Subject: [Lightning-dev] Laundry list of inter-peer wire protocol changes
Message-ID: <87d1snvhyf.fsf@rustcorp.com.au>

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