Add example usecase from Eric Lombrozo and quote from Anthony Towns

regarding lightning commitment transactions

1 files changed, 32 insertions, 3 deletions

diff --git a/bip-0112.mediawiki b/bip-0112.mediawiki
index 097a136..8e0e9f1 100644
--- a/bip-0112.mediawiki
+++ b/bip-0112.mediawiki
@@ -2,7 +2,8 @@
   BIP: 112
   Title: CHECKSEQUENCEVERIFY
   Authors: BtcDrak <btcdrak@gmail.com>
-           Mark Friedenbach <mark@friedenbach.org>	
+           Mark Friedenbach <mark@friedenbach.org>
+           Eric Lombrozo <Eric Lombrozo>
   Status: Draft
   Type: Standards Track
   Created: 2015-08-10
@@ -21,9 +22,9 @@ being spent.
 CHECKSEQUENCEVERIFY redefines the existing NOP3 opcode. When executed it
 compares the top item on the stack to the nSequence field of the transaction
 input containing the scriptSig. If it is greater than or equal to (1 << 31),
-or if the transaction version is greater than or equal to 2, the transaction
+or if the transaction version is greater than or equal to 2, the transaction input
 sequence is less than or equal to (1 << 31) and the top stack item is less than
-the transaction sequence, script exection continues as if a NOP was executed,
+the transaction input sequence, script exection continues as if a NOP was executed,
 otherwise the script fails.
 
 BIP 68's redefinition of nSequence prevents a non-final transaction
@@ -92,6 +93,30 @@ is required for lightning network payment channels. The scheme requires both
 CHECKSEQUENCEVERIFY and CHECKLOCKTIMEVERIFY to enforce HTLC timeouts and
 revokation.
 
+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.
+
+
+====Retroactive Invalidation====
+
+In many instances, we would like to create contracts that can be revoked in case
+of some future event. However, given the immutable nature of the blockchain, it
+is practically impossible to retroactively invalidate a previous commitment that
+has already confirmed. The only mechanism we really have for retroactive
+invalidation is blockchain reorganization which, for fundamental security
+reasons, is designed to be very hard and very expensive to deliberately pull off.
+
+Despite this limitation, we do have a way to provide something fairly similar
+using CHECKSEQUENCEVERIFY by constructing scripts with multiple branches of
+execution where one or more of the branches are delayed. That's to say, a
+delayed branch cannot execute until a certain amount of time has passed since
+the transaction containing the script (or a hash of it) confirmed. This provides
+a time window in which someone can supply an invalidation condition which spends
+the output, effectively invalidating the contract and potentially discouraging
+another party from broadcasting the transaction in the first place.
+
 
 ==Specification==
 
@@ -237,6 +262,8 @@ done by Peter Todd for the closely related BIP 65.
 
 BtcDrak authored this BIP document.
 
+Thanks to Eric Lombrozo help with example usecases.
+
 
 ==References==
 
@@ -259,6 +286,8 @@ BtcDrak authored this BIP document.
 [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2013-April/002433.html Jeremy Spilman Micropayment Channels]
 
 
+
+
 ==Copyright==
 
 This document is placed in the public domain.