This is the third part of my series of posts explaining the bitcoin Lightning Networks 0.5 draft paper.

In Part I I described how a Poon-Dryja channel uses a single in-blockchain transaction to create off-blockchain transactions which can be safely updated by either party (as long as both agree), with fallback to publishing the latest versions to the blockchain if something goes wrong.

In Part II I described how Hashed Timelocked Contracts allow you to safely make one payment conditional upon another, so payments can be routed across untrusted parties using a series of transactions with decrementing timeout values.

Now we'll join the two together: encapsulate Hashed Timelocked Contracts inside a channel, so they don't have to be placed in the blockchain (unless something goes wrong).

Revision: Why Poon-Dryja Channels Work

Here's half of a channel setup between me and you where I'm paying you 1c: (there's always a mirror setup between you and me, so it's symmetrical)

[caption id="" align="aligncenter" width="350"] Half a channel: we will invalidate transaction 1 (in favour of a new transaction 2) to send funds.[/caption]

The system works because after we agree on a new transaction (eg. to pay you another 1c), you revoke this by handing me your private keys to unlock that 1c output.  Now if you ever released Transaction 1, I can spend both the outputs.  If we want to add a new output to Transaction 1, we need to be able to make it similarly stealable.

Adding a 1c HTLC Output To Transaction 1 In The Channel

I'm going to send you 1c now via a HTLC (which means you'll only get it if the riddle is answered; if it times out, I get the 1c back).  So we replace transaction 1 with transaction 2, which has three outputs: $9.98 to me, 1c to you, and 1c to the HTLC: (once we agree on the new transactions, we invalidate transaction 1 as detailed in Part I)

[caption id="" align="aligncenter" width="553"] Our Channel With an Output for an HTLC[/caption]

Note that you supply another separate signature (sig3) for this output, so you can reveal that private key later without giving away any other output.

We modify our previous HTLC design so you revealing the sig3 would allow me to steal this output. We do this the same way we did for that 1c going to you: send the output via a timelocked mutually signed transaction.  But there are two transaction paths in an HTLC: the got-the-riddle path and the timeout path, so we need to insert those timelocked mutually signed transactions in both of them.  First let's append a 1 day delay to the timeout path:

[caption id="" align="aligncenter" width="318"] Timeout path of HTLC, with locktime so it can be stolen once you give me your sig3.[/caption]

Similarly, we need to append a timelocked transaction on the "got the riddle solution" path, which now needs my signature as well (otherwise you could create a replacement transaction and bypass the timelocked transaction):

[caption id="" align="aligncenter" width="422"] Full HTLC: If you reveal Transaction 2 after we agree it's been revoked, and I have your sig3 private key, I can spend that output before you can, down either the settlement or timeout paths.[/caption]

Remember The Other Side?

Poon-Dryja channels are symmetrical, so the full version has a matching HTLC on the other side (except with my temporary keys, so you can catch me out if I use a revoked transaction).  Here's the full diagram, just to be complete:

[caption id="" align="aligncenter" width="499"] A complete lightning network channel with an HTLC, containing a glorious 13 transactions.[/caption]

Closing The HTLC

When an HTLC is completed, we just update transaction 2, and don't include the HTLC output.  The funds either get added to your output (R value revealed before timeout) or my output (timeout).

Note that we can have an arbitrary number of independent HTLCs in progress at once, and open and/or close as many in each transaction update as both parties agree to.

Keys, Keys Everywhere!

Each output for a revocable transaction needs to use a separate address, so we can hand the private key to the other party.  We use two disposable keys for each HTLC[1], and every new HTLC will change one of the other outputs (either mine, if I'm paying you, or yours if you're paying me), so that needs a new key too.  That's 3 keys, doubled for the symmetry, to give 6 keys per HTLC.

Adam Back pointed out that we can actually implement this scheme without the private key handover, and instead sign a transaction for the other side which gives them the money immediately.  This would permit more key reuse, but means we'd have to store these transactions somewhere on the off chance we needed them.

Storing just the keys is smaller, but more importantly, Section 6.2 of the paper describes using BIP 32 key hierarchies so the disposable keys are derived: after a while, you only need to store one key for all the keys the other side has given you.  This is vastly more efficient than storing a transaction for every HTLC, and indicates the scale (thousands of HTLCs per second) that the authors are thinking.

Next: Conclusion

My next post will be a TL;DR summary, and some more references to the implementation details and possibilities provided by the paper.

 

[1] The new sighash types are fairly loose, and thus allow you to attach a transaction to a different parent if it uses the same output addresses.  I think we could re-use the same keys in both paths if we ensure that the order of keys required is reversed for one, but we'd still need 4 keys, so it seems a bit too tricky.