mirrors/bitcoin-bips
1
0
Fork 0
mirror of https://github.com/bitcoin/bips.git synced 2024-11-19 01:40:05 +01:00
Code Issues Projects Releases Wiki Activity

Add example usecase from Eric Lombrozo and quote from Anthony Towns

Browse Source 
regarding lightning commitment transactions
This commit is contained in:
BtcDrak 2015-10-04 10:42:51 +01:00
parent 315bd227d7
commit 9c0df8fd0d
1 changed files with 32 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

35
bip-0112.mediawiki
View File

@ -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.