From 9c0df8fd0d1b4e9ff94f6e3d8799c69d17473066 Mon Sep 17 00:00:00 2001 From: BtcDrak Date: Sun, 4 Oct 2015 10:42:51 +0100 Subject: Add example usecase from Eric Lombrozo and quote from Anthony Towns regarding lightning commitment transactions --- bip-0112.mediawiki | 35 ++++++++++++++++++++++++++++++++--- 1 file changed, 32 insertions(+), 3 deletions(-) (limited to 'bip-0112.mediawiki') 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 - Mark Friedenbach + Mark Friedenbach + 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. -- cgit v1.2.3