From 4b0c6dc4ad23fce54b75182b43ec314fc8889ef3 Mon Sep 17 00:00:00 2001 From: BtcDrak Date: Sat, 3 Oct 2015 23:24:17 +0100 Subject: Move examples under motivation section --- bip-0112.mediawiki | 85 +++++++++++++++++++++++++++--------------------------- 1 file changed, 42 insertions(+), 43 deletions(-) diff --git a/bip-0112.mediawiki b/bip-0112.mediawiki index ae569b6..4773b17 100644 --- a/bip-0112.mediawiki +++ b/bip-0112.mediawiki @@ -50,6 +50,48 @@ minimum time after proof-of-publication. This enables a wide variety of applications in phased protocols such as escrow, payment channels, or bidirectional pegs. +===Examples=== + +====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 +address with the following redeemscript. + + IF + 2 3 CHECKMULTISIGVERIFY + ELSE + CHECKSEQUENCEVERIFY DROP + CHECKSIGVERIFY + ENDIF + +At any time funds can be spent using signatures from any two of Alice, +Bob or the Escrow. + +After 30 days Alice can sign alone. + +The clock does not start ticking until the payment to the escrow address +confirms. + + +====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 +necessitates closing the channel and reopen it when getting close to the timeout, +whereas with relative locktime, the clock starts ticking the moment the +transactions confirms in a block. It also provides a means to know exactly how +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==== + +Hashed Timelock Contracts (HTLCs) can be used to create chains of payments which +is required for lightning network payment channels. The scheme requires both +CHECKSEQUENCEVERIFY and CHECKLOCKTIMEVERIFY to enforce HTLC timeouts and +revokation. + ==Specification== @@ -155,49 +197,6 @@ semantics and detailed rationale for those semantics. } -==Examples== - -===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 -address with the following redeemscript. - - IF - 2 3 CHECKMULTISIGVERIFY - ELSE - CHECKSEQUENCEVERIFY DROP - CHECKSIGVERIFY - ENDIF - -At any time funds can be spent using signatures from any two of Alice, -Bob or the Escrow. - -After 30 days Alice can sign alone. - -The clock does not start ticking until the payment to the escrow address -confirms. - - -===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 -necessitates closing the channel and reopen it when getting close to the timeout, -whereas with relative locktime, the clock starts ticking the moment the -transactions confirms in a block. It also provides a means to know exactly how -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=== - -Hashed Timelock Contracts (HTLCs) can be used to create chains of payments which -is required for lightning network payment channels. The scheme requires both -CHECKSEQUENCEVERIFY and CHECKLOCKTIMEVERIFY to enforce HTLC timeouts and -revokation. - - ==Reference Implementation== A reference implementation is provided in the following git repository: -- cgit v1.2.3