Skip to content

update taproot-updates.md #19

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
May 12, 2022
Merged

update taproot-updates.md #19

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
a45c7b6
update taproot-updates.md
antonilol May 10, 2022
0294da6
remove script optimizations for readability
antonilol May 11, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
19 changes: 10 additions & 9 deletions taproot-updates.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -136,7 +136,7 @@ The commitment transaction will then become:
"tapleaf_1": "
# funds go back to us via a second-stage HTLC-timeout transaction (which contains an absolute delay)
# NB: we also need the remote signature, which prevents us from unilaterally changing the HTLC-timeout transaction
<remote_htlcpubkey> OP_CHECKSIGVERIFY <local_htlcpubkey> OP_CHECKSIG
<remote_htlcpubkey> OP_CHECKSIGVERIFY <local_htlcpubkey> OP_CHECKSIGVERIFY
1 OP_CHECKSEQUENCEVERIFY
",
"tapleaf_2": "
Expand All @@ -160,16 +160,17 @@ The commitment transaction will then become:
# funds go to us via a second-stage HTLC-success transaction once we have the payment preimage
# NB: we also need the remote signature, which prevents us from unilaterally changing the HTLC-success transaction
OP_HASH160 <RIPEMD160(payment_hash)> OP_EQUALVERIFY
<remote_htlcpubkey> OP_CHECKSIGVERIFY <local_htlcpubkey> OP_CHECKSIG
<remote_htlcpubkey> OP_CHECKSIGVERIFY <local_htlcpubkey> OP_CHECKSIGVERIFY
1 OP_CHECKSEQUENCEVERIFY
",
"tapleaf_2": "
# funds go to the remote node after an absolute delay (timeout)
<remote_htlcpubkey>
OP_CHECKSIGVERIFY
1 OP_CHECKSEQUENCEVERIFY
<cltv_expiry>
OP_CHECKLOCKTIMEVERIFY
1 OP_CHECKSEQUENCEVERIFY
OP_DROP
"
}
},
Expand All @@ -195,7 +196,7 @@ A taproot HTLC-success transaction looks like:
"txid": "...",
"vout": 42,
"scriptSig": "<payment_preimage> <remotehtlcsig> <localhtlcsig>",
"sequence": 0
"sequence": 1
}
],
"vout": [
Expand Down Expand Up @@ -230,7 +231,7 @@ A taproot HTLC-timeout transaction looks like:
"txid": "...",
"vout": 42,
"scriptSig": "<remotehtlcsig> <localhtlcsig>",
"sequence": 0
"sequence": 1
}
],
"vout": [
Expand Down Expand Up @@ -283,13 +284,13 @@ structure (or something similar) to our commitment transaction:
"tapleaf_1": "
# funds go back to us via a second-stage PTLC-timeout transaction (which contains an absolute delay)
# NB: we need the remote signature, which prevents us from unilaterally changing the PTLC-timeout transaction
<remote_ptlcpubkey> OP_CHECKSIGVERIFY <local_ptlcpubkey> OP_CHECKSIG
<remote_ptlcpubkey> OP_CHECKSIGVERIFY <local_ptlcpubkey> OP_CHECKSIGVERIFY
1 OP_CHECKSEQUENCEVERIFY
",
"tapleaf_2": "
# funds go to the remote node via a second-stage Claim-PTLC-success transaction by completing an adaptor sig, revealing the payment secret
# NB: we don't use musig2 here because it would force local and remote signatures to use the same sighash flags
<local_ptlcpubkey> OP_CHECKSIGVERIFY <remote_ptlcpubkey> OP_CHECKSIG
<local_ptlcpubkey> OP_CHECKSIGVERIFY <remote_ptlcpubkey> OP_CHECKSIGVERIFY
1 OP_CHECKSEQUENCEVERIFY
"
}
Expand Down Expand Up @@ -333,7 +334,7 @@ We simply add two new types of outputs to the commit tx (PTLC offered / PTLC rec
| +------------------------+
+------->| commit tx B |
+------------------------+
| | | | | | | |
| | | | | | | |
| | | | | | | | A's main output
| | | | | | | +-----------------> to A after a 1-block relative delay
| | | | | | |
Expand Down Expand Up @@ -388,7 +389,7 @@ We simply add two new types of outputs to the commit tx (PTLC offered / PTLC rec
| +---> to A with revocation key
|
| (B's RBF inputs) ---+
| | +---> to B after relative delay
| | +---> to B after relative delay
| +---->+-----------------+ |
| +---------->| PTLC-success tx |----------------+
| PTLC received by B | +-----------------+ |
Expand Down