diff options
| author | BtcDrak <btcdrak@gmail.com> | 2015-10-04 19:23:12 +0100 |
|---|---|---|
| committer | BtcDrak <btcdrak@gmail.com> | 2015-10-04 19:23:12 +0100 |
| commit | 748f33ccfb88f904287a076abffc6469bc097995 (patch) | |
| tree | 6617ac5bf488f7fcbecc56a80e9a81d5772699b6 /bip-0112.mediawiki | |
| parent | d80b70554399e1f5125773466bb276224bc0b295 (diff) | |
Better formatting
Diffstat (limited to 'bip-0112.mediawiki')
| -rw-r--r-- | bip-0112.mediawiki | 16 |
1 files changed, 7 insertions, 9 deletions
diff --git a/bip-0112.mediawiki b/bip-0112.mediawiki index eefd627..425c966 100644 --- a/bip-0112.mediawiki +++ b/bip-0112.mediawiki @@ -51,12 +51,10 @@ 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=== +===Contracts With Expiration Deadlines=== -====Contracts With Expiration Deadlines==== - -=====Escrow with Timeout===== +====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 @@ -78,7 +76,7 @@ The clock does not start ticking until the payment to the escrow address confirms. -====Retroactive Invalidation==== +===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 @@ -98,11 +96,11 @@ honoring the original contract. Some more specific applications of this idea: -=====Hash Time-Locked Contracts===== +====Hash Time-Locked Contracts==== Hash Time-Locked Contracts (HTLCs) provide a general mechanism for offchain contract negotiation. An execution pathway can be made to require knowledge of a secret (a hash preimage) that can be presented within an invalidation time window. By sharing the secret it is possible to guarantee to the counterparty that the transaction will never be broadcast since this would allow the counterparty to claim the output immediately while one would have to wait for the time window to pass. If the secret has not been shared, the counterparty will be unable to use the instant pathway and the delayed pathway will be used instead. -=====Bidirectional Payment Channels===== +====Bidirectional Payment Channels==== Scriptable relative locktime provides a predictable amount of time to respond in the event a counterparty broadcasts a revoked transaction: Absolute locktime @@ -113,7 +111,7 @@ long to wait (in number of blocks) before funds can be pulled out of the channel in the event of a noncooperative counterparty. -=====Lightning Network===== +====Lightning Network==== The lightning network extends the bidirectional payment channel idea to allow for payments to be routed over multiple bidirectional payment channel hops. @@ -217,7 +215,7 @@ secret. See the [https://github.com/ElementsProject/lightning/blob/master/doc/deployable-lightning.pdf Deployable Lightning] paper. -=====2-Way Pegged Sidechains===== +====2-Way Pegged Sidechains==== OP_IF lockTxHeight <lockTxHash> nlocktxOut [<workAmount>] reorgBounty Hash160(<...>) <genesisHash> OP_REORGPROOFVERIFY |