diff options
| -rw-r--r-- | bip-0112.mediawiki | 54 |
1 files changed, 34 insertions, 20 deletions
diff --git a/bip-0112.mediawiki b/bip-0112.mediawiki index 8e0e9f1..0ecd77c 100644 --- a/bip-0112.mediawiki +++ b/bip-0112.mediawiki @@ -3,7 +3,7 @@ Title: CHECKSEQUENCEVERIFY Authors: BtcDrak <btcdrak@gmail.com> Mark Friedenbach <mark@friedenbach.org> - Eric Lombrozo <Eric Lombrozo> + Eric Lombrozo <elombrozo@gmail.com> Status: Draft Type: Standards Track Created: 2015-08-10 @@ -53,7 +53,10 @@ or bidirectional pegs. ===Examples=== -====Escrow with Timeout==== + +====Contracts With Expiration Deadlines==== + +=====Escrow with Timeout===== 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 @@ -75,7 +78,28 @@ The clock does not start ticking until the payment to the escrow address 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 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. -====Hash Time-Locked Contracts==== +=====Hash Time-Locked Contracts===== Hashed Timelock Contracts (HTLCs) can be used to create chains of payments which 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. -====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. +=====2-Way Pegged Sidechains===== -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. + OP_IF + lockTxHeight <lockTxHash> nlocktxOut [<workAmount>] reorgBounty Hash160(<...>) <genesisHash> OP_REORGPROOFVERIFY + OP_ELSE + withdrawLockTime OP_CHECKSEQUENCEVERIFY OP_DROP OP_HASH160 p2shWithdrawDest OP_EQUAL + OP_ENDIF ==Specification== |