diff options
Diffstat (limited to 'bip-0199.mediawiki')
-rw-r--r-- | bip-0199.mediawiki | 80 |
1 files changed, 80 insertions, 0 deletions
diff --git a/bip-0199.mediawiki b/bip-0199.mediawiki new file mode 100644 index 0000000..e463c7f --- /dev/null +++ b/bip-0199.mediawiki @@ -0,0 +1,80 @@ +<pre> + BIP: 199 + Layer: Applications + Title: Hashed Time-Locked Contract transactions + Author: Sean Bowe <sean@z.cash> + Daira Hopwood <daira@z.cash> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0199 + Status: Draft + Type: Standards Track + Created: 2017-03-27 + License: BSD-3-Clause + CC0-1.0 +</pre> + +==Abstract== + +This BIP describes a script for generalized off-chain contract negotiation. + +==Summary== + +A Hashed Time-Locked Contract (HTLC) is a script that permits a designated party (the "seller") to spend funds by disclosing the preimage of a hash. It also permits +a second party (the "buyer") to spend the funds after a timeout is reached, in a refund situation. + +The script takes the following form: + + OP_IF + [HASHOP] <digest> OP_EQUALVERIFY OP_DUP OP_HASH160 <seller pubkey hash> + OP_ELSE + <num> [TIMEOUTOP] OP_DROP OP_DUP OP_HASH160 <buyer pubkey hash> + OP_ENDIF + OP_EQUALVERIFY + OP_CHECKSIG + +[HASHOP] is either OP_SHA256 or OP_HASH160. + +[TIMEOUTOP] is either OP_CHECKSEQUENCEVERIFY or OP_CHECKLOCKTIMEVERIFY. + +===Interaction=== + +* Victor (the "buyer") and Peggy (the "seller") exchange public keys and mutually agree upon a timeout threshold. Peggy provides a hash digest. Both parties can now construct the script and P2SH address for the HTLC. +* Victor sends funds to the P2SH address. +* Either: +** Peggy spends the funds, and in doing so, reveals the preimage to Victor in the transaction; OR +** Victor recovers the funds after the timeout threshold. + +Victor is interested in a lower timeout to reduce the amount of time that his funds are encumbered in the event that Peggy does not reveal the preimage. Peggy is +interested in a higher timeout to reduce the risk that she is unable to spend the funds before the threshold, or worse, that her transaction spending the funds does +not enter the blockchain before Victor's but does reveal the preimage to Victor anyway. + +==Motivation== + +In many off-chain protocols, secret disclosure is used as part of a settlement mechanism. In some others, the secrets themselves are valuable. HTLC transactions are +a safe and cheap method of exchanging secrets for money over the blockchain, due to the ability to recover funds from an uncooperative counterparty, and the +opportunity that the possessor of a secret has to receive the funds before such a refund can occur. + +===Lightning network=== + +In the lightning network, HTLC scripts are used to perform atomic swaps between payment channels. + +Alice constructs K and hashes it to produce L. She sends an HTLC payment to Bob for the preimage of L. Bob sends an HTLC payment to Carol for the same preimage and +amount. Only when Alice releases the preimage K does any exchange of value occur, and because the secret is divulged for each hop, all parties are compensated. If +at any point some parties become uncooperative, the process can be aborted via the refund conditions. + +===Zero-knowledge contingent payments=== + +Various practical zero-knowledge proving systems exist which can be used to guarantee that a hash preimage derives valuable information. As an example, a +zero-knowledge proof can be used to prove that a hash preimage acts as a decryption key for an encrypted sudoku puzzle solution. (See +[https://github.com/zcash/pay-to-sudoku pay-to-sudoku] for a concrete example of such a protocol.) + +HTLC transactions can be used to exchange such decryption keys for money without risk, and they do not require large or expensive-to-validate transactions. + +==Implementation== + +https://github.com/bitcoin/bitcoin/pull/7601 + +==Copyright== + +This document is dual licensed as BSD 3-clause, and Creative Commons CC0 1.0 Universal. + |