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

Use optimised script examples

Browse Source 
Taken from 20/11/15 version of deployable lightning
This commit is contained in:
BtcDrak 2015-11-25 18:48:39 +00:00
parent 8d85335f2a
commit 0026fcb929
1 changed files with 25 additions and 25 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

50
bip-0112.mediawiki
View File

@ -137,11 +137,12 @@ A simple output, paying to Alice might then look like:
HASH160 <revokehash> EQUAL HASH160 <revokehash> EQUAL
IF IF
DUP HASH160 <Bob key hash> CHECKSIGVERIFY <Bob key hash>
ELSE ELSE
"24h" CHECKSEQUENCEVERIFY "24h" CHECKSEQUENCEVERIFY DROP
DUP HASH160 <Alice key hash> CHECKSIGVERIFY <Alice key hash>
ENDIF ENDIF
CHECKSIG
This allows Alice to publish the latest commitment transaction at any This allows Alice to publish the latest commitment transaction at any
time and spend the funds after 24 hours, but also ensures that if Alice time and spend the funds after 24 hours, but also ensures that if Alice
@ -151,11 +152,12 @@ With CHECKLOCKTIMEVERIFY, this would look like:
HASH160 <revokehash> EQUAL HASH160 <revokehash> EQUAL
IF IF
DUP HASH160 <Bob key hash> CHECKSIGVERIFY <Bob key hash>
ELSE ELSE
"2015/12/15" CHECKLOCKTIMEVERIFY "2015/12/15" CHECKLOCKTIMEVERIFY DROP
DUP HASH160 <Alice key hash> CHECKSIGVERIFY <Alice key hash>
ENDIF ENDIF
CHECKSIG
This form of transaction would mean that if the anchor is unspent on This form of transaction would mean that if the anchor is unspent on
2015/12/16, Alice can use this commitment even if it has been revoked, 2015/12/16, Alice can use this commitment even if it has been revoked,
@ -174,35 +176,33 @@ delay, and the entire output can be claimed by the other party if the
revocation secret is known. With CHECKSEQUENCEVERIFY, a HTLC payable to revocation secret is known. With CHECKSEQUENCEVERIFY, a HTLC payable to
Alice might look like the following in Alice's commitment transaction: Alice might look like the following in Alice's commitment transaction:
HASH160 DUP <revokehash> EQUAL HASH160 DUP <R-HASH> EQUAL
IF IF
DROP DUP HASH160 <Bob key hash> CHECKSIGVERIFY "24h" CHECKSEQUENCEVERIFY
2DROP
<Alice key hash>
ELSE ELSE
<R hash> EQUAL <Commit-Revocation-Hash> EQUAL
IF NOTIF
"24h" CHECKSEQUENCEVERIFY DROP "24h" CHECKLOCKTIMEVERIFY DROP
DUP HASH160 <Alice key hash> CHECKSIGVERIFY
ELSE
"2015/10/20 10:33" CHECKLOCKTIMEVERIFY DROP
DUP HASH160 <Bob key hash> CHECKSIGVERIFY
ENDIF ENDIF
<Bob key hash>
ENDIF ENDIF
CHECKSIG
and correspondingly in Bob's commitment transaction: and correspondingly in Bob's commitment transaction:
HASH160 DUP <revokehash> EQUAL HASH160 DUP <R-HASH> EQUAL
SWAP <Commit-Revocation-Hash> EQUAL ADD
IF IF
DROP DUP HASH160 <Alice key hash> CHECKSIGVERIFY <Alice key hash>
ELSE ELSE
<R hash> EQUAL "2015/10/20 10:33" CHECKLOCKTIMEVERIFY
IF "24h" CHECKSEQUENCEVERIFY
"24h" CHECKSEQUENCEVERIFY DROP 2DROP
DUP HASH160 <Alice key hash> CHECKSIGVERIFY <Bob key hash>
ELSE
"2015/10/20 10:33" CHECKLOCKTIMEVERIFY DROP
DUP HASH160 <Bob key hash> CHECKSIGVERIFY
ENDIF
ENDIF ENDIF
CHECKSIG
Note that both CHECKSEQUENCEVERIFY and CHECKLOCKTIMEVERIFY are used in the Note that both CHECKSEQUENCEVERIFY and CHECKLOCKTIMEVERIFY are used in the
final branch of above to ensure Bob cannot spend the output until after both final branch of above to ensure Bob cannot spend the output until after both