Add section on lightning network examples written by Anthony Towns

1 files changed, 105 insertions, 13 deletions

diff --git a/bip-0112.mediawiki b/bip-0112.mediawiki
index c92fbe0..dcd9237 100644
--- a/bip-0112.mediawiki
+++ b/bip-0112.mediawiki
@@ -96,7 +96,7 @@ another party from broadcasting the transaction in the first place. If the inval
 condition does not occur before the timeout, the delayed branch becomes spendable,
 honoring the original contract.
 
-Some more specific applications of this  idea:
+Some more specific applications of this idea:
 
 
 =====Payment Channel Revocation=====
@@ -110,17 +110,109 @@ long to wait (in number of blocks) before funds can be pulled out of the channel
 in the event of a noncooperative counterparty.
 
 
-=====Hash Time-Locked Contracts=====
+=====Bidirectional Payment Channels=====
 
-Hashed Timelock Contracts (HTLCs) can be used to create chains of payments which
-is required for lightning network payment channels. The scheme requires both
-CHECKSEQUENCEVERIFY and CHECKLOCKTIMEVERIFY to enforce HTLC timeouts and
-revokation.
+The lightning network proposes bidirectional two-party payment channels
+(between Alice and Bob) that would benefit from CHECKSEQUENCEVERIFY.
 
-In lightning commitment transactions, CHECKSEQUENCEVERIFY and CHECKLOCKTIMEVERIFY
-enforce a delay between publishing the commitment transaction, and spending the
-output. The delay is needed so that the counterparty has time to prove the
-commitment was revoked and claim the outputs as a penalty.
+These channels are based on an anchor transaction that requires a 2-of-2
+multisig from Alice and Bob, and a series of revocable commitment
+transactions that spend the anchor transaction.  The commitment
+transaction splits the funds from the anchor between Alice and Bob and
+the latest commitment transaction may be published by either party at
+any time, finalising the channel.
+
+Ideally then, a revoked commitment transaction would never be able to
+be successfully spent; and the latest commitment transaction would be
+able to be spent very quickly.
+
+To allow a commitment transaction to be effectively revoked, Alice
+and Bob have slightly different versions of the latest commitment
+transaction. In Alice's version, any outputs in the commitment
+transaction that pay Alice also include a forced delay, and an
+alternative branch that allows Bob to spend the output if he knows that
+transaction's revocation code. In Bob's version, payments to Bob are
+similarly encumbered. When Alice and Bob negotiate new balances and
+new commitment transactions, they also reveal the old revocation code,
+thus committing to not relaying the old transaction.
+
+A simple output, paying to Alice might then look like:
+
+    OP_HASH160 <revokehash> OP_EQUAL
+    OP_IF
+        OP_DUP OP_HASH160 <Bob key hash> OP_CHECKSIGVERIFY
+    OP_ELSE
+        24h OP_CHECKSEQUENCEVERIFY
+        OP_DUP OP_HASH160 <Alice key hash> OP_CHECKSIGVERIFY
+    OP_ENDIF
+
+This allows Alice to publish the latest commitment transaction at any
+time and spend the funds after 24 hours, but also ensures that if Alice
+relays a revoked transaction, that Bob has 24 hours to claim the funds.
+
+With CHECKLOCKTIMEVERIFY, this would look like:
+
+    OP_HASH160 <revokehash> OP_EQUAL
+    OP_IF
+        OP_DUP OP_HASH160 <Bob key hash> OP_CHECKSIGVERIFY
+    OP_ELSE
+        2015/12/15 OP_CHECKLOCKTIMEVERIFY
+        OP_DUP OP_HASH160 <Alice key hash> OP_CHECKSIGVERIFY
+    OP_ENDIF
+
+This form of transaction would mean that if the anchor is unspent on
+2015/12/16, Alice can use this commitment even if it has been revoked,
+simply by spending it immediately, giving no time for Bob to claim it.
+
+Ths means that the channel has a deadline that cannot be pushed
+back without hitting the blockchain; and also that funds may not be
+available until the deadline is hit. CHECKSEQUENCEVERIFY allows you
+to avoid making that tradeoff.
+
+Hashed Time-Lock Contracts (HTLCs) make this slightly more complicated,
+since in principle they may pay either Alice or Bob, depending on whether
+Alice discovers a secret R, or a timeout is reached, but the same principle
+applies -- the branch paying Alice in Alice's commitment transaction gets a
+delay, and the entire output can be claimed by the other party if the
+revocation secret is known. With CHECKSEQUENCEVERIFY, a HTLC payable to
+Alice might look like the following in Alice's commitment transaction:
+
+    OP_HASH160 OP_DUP <revokehash> OP_EQUAL
+    OP_IF
+        OP_DROP OP_DUP OP_HASH160 <Bob key hash> OP_CHECKSIGVERIFY
+    OP_ELSE
+        <R hash> OP_EQUAL
+        OP_IF
+            "24h" OP_CHECKSEQUENCEVERIFY OP_DROP
+            OP_DUP OP_HASH160 <Alice key hash> OP_CHECKSIGVERIFY
+        OP_ELSE
+            "2015/10/20 10:33" OP_CHECKLOCKTIMEVERIFY OP_DROP
+            OP_DUP OP_HASH160 <Bob key hash> OP_CHECKSIGVERIFY
+        OP_ENDIF
+    OP_ENDIF
+
+and correspondingly in Bob's commitment transaction:
+
+   OP_HASH160 OP_DUP <revokehash> OP_EQUAL
+   OP_IF
+       OP_DROP OP_DUP OP_HASH160 <Alice key hash> OP_CHECKSIGVERIFY
+   OP_ELSE
+       <R hash> OP_EQUAL
+       OP_IF
+           OP_DUP OP_HASH160 <Alice key hash> OP_CHECKSIGVERIFY
+       OP_ELSE
+           "24h" OP_CHECKSEQUENCEVERIFY OP_DROP
+           "2015/10/20 10:33" OP_CHECKLOCKTIMEVERIFY OP_DROP
+           OP_DUP OP_HASH160 <Bob key hash> OP_CHECKSIGVERIFY
+       OP_ENDIF
+   OP_ENDIF
+
+Note that both CHECKSEQUENCEVERIFY and CHECKLOCKTIMEVERIFY are used in the
+final branch of above to ensure Bob cannot spend the output until after both
+the timeout is complete and Alice has had time to reveal the revocation
+secret.
+
+See the [https://github.com/ElementsProject/lightning/blob/master/doc/deployable-lightning.pdf Deployable Lightning] paper.
 
 
 =====2-Way Pegged Sidechains=====
@@ -276,7 +368,7 @@ done by Peter Todd for the closely related BIP 65.
 
 BtcDrak authored this BIP document.
 
-Thanks to Eric Lombrozo help with example usecases.
+Thanks to Eric Lombrozo and Anthony Towns for contributing example usecases.
 
 
 ==References==
@@ -291,6 +383,8 @@ Thanks to Eric Lombrozo help with example usecases.
 
 [http://lightning.network/lightning-network-paper.pdf Lightning Network]
 
+[https://github.com/ElementsProject/lightning/blob/master/doc/deployable-lightning.pdf Deployable Lightning]
+
 [http://diyhpl.us/diyhpluswiki/transcripts/sf-bitcoin-meetup/2015-02-23-scaling-bitcoin-to-billions-of-transactions-per-day/ Scaling Bitcoin to Billions of Transactions Per Day]
 
 [http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010396.html Softfork deployment considerations]
@@ -300,8 +394,6 @@ Thanks to Eric Lombrozo help with example usecases.
 [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2013-April/002433.html Jeremy Spilman Micropayment Channels]
 
 
-
-
 ==Copyright==
 
 This document is placed in the public domain.