bitcoin/bips
1
0
Fork 0
mirror of https://github.com/bitcoin/bips.git synced 2025-05-12 12:03:29 +00:00
Code Issues Releases Wiki Activity

Added "Contracts With Invalidation Deadline" and "Retroactive Invalidation" sections under examples.

Browse Source
This commit is contained in:
Eric Lombrozo 2015-10-04 03:51:17 -07:00
parent 9c0df8fd0d
commit e2d6ffbadd
1 changed files with 34 additions and 20 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

54
bip-0112.mediawiki
View File

@ -3,7 +3,7 @@
Title: CHECKSEQUENCEVERIFY Title: CHECKSEQUENCEVERIFY
Authors: BtcDrak <btcdrak@gmail.com> Authors: BtcDrak <btcdrak@gmail.com>
Mark Friedenbach <mark@friedenbach.org> Mark Friedenbach <mark@friedenbach.org>
Eric Lombrozo <Eric Lombrozo> Eric Lombrozo <elombrozo@gmail.com>
Status: Draft Status: Draft
Type: Standards Track Type: Standards Track
Created: 2015-08-10 Created: 2015-08-10
@ -53,7 +53,10 @@ or bidirectional pegs.
===Examples=== ===Examples===
====Escrow with Timeout====
====Contracts With Expiration Deadlines====
=====Escrow with Timeout=====
An escrow that times out automatically 30 days after being funded can be An escrow that times out automatically 30 days after being funded can be
established in the following way. Alice, Bob and Escrow create a 2-of-3 established in the following way. Alice, Bob and Escrow create a 2-of-3
@ -75,7 +78,28 @@ The clock does not start ticking until the payment to the escrow address
confirms. confirms.
====Payment Channel Revokation==== ====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 functionally similar
using CHECKSEQUENCEVERIFY. By constructing scripts with multiple branches of
execution where one or more of the branches are delayed we provide
a time window in which someone can supply an invalidation condition that allows the
output to be spent, effectively invalidating the would-be delayed branch and potentially discouraging
another party from broadcasting the transaction in the first place. If the invalidation
condition does not occur before the timeout, the delayed branch becomes spendable,
honoring the original contract.
Some more specific applications of this idea:
=====Payment Channel Revokation=====
Scriptable relative locktime provides a predictable amount of time to respond in Scriptable relative locktime provides a predictable amount of time to respond in
the event a counterparty broadcasts a revoked transaction: Absolute locktime the event a counterparty broadcasts a revoked transaction: Absolute locktime
@ -86,7 +110,7 @@ long to wait (in number of blocks) before funds can be pulled out of the channel
in the event of a noncooperative counterparty. in the event of a noncooperative counterparty.
====Hash Time-Locked Contracts==== =====Hash Time-Locked Contracts=====
Hashed Timelock Contracts (HTLCs) can be used to create chains of payments which Hashed Timelock Contracts (HTLCs) can be used to create chains of payments which
is required for lightning network payment channels. The scheme requires both is required for lightning network payment channels. The scheme requires both
@ -99,23 +123,13 @@ output. The delay is needed so that the counterparty has time to prove the
commitment was revoked and claim the outputs as a penalty. commitment was revoked and claim the outputs as a penalty.
====Retroactive Invalidation==== =====2-Way Pegged Sidechains=====
In many instances, we would like to create contracts that can be revoked in case OP_IF
of some future event. However, given the immutable nature of the blockchain, it lockTxHeight <lockTxHash> nlocktxOut [<workAmount>] reorgBounty Hash160(<...>) <genesisHash> OP_REORGPROOFVERIFY
is practically impossible to retroactively invalidate a previous commitment that OP_ELSE
has already confirmed. The only mechanism we really have for retroactive withdrawLockTime OP_CHECKSEQUENCEVERIFY OP_DROP OP_HASH160 p2shWithdrawDest OP_EQUAL
invalidation is blockchain reorganization which, for fundamental security OP_ENDIF
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== ==Specification==