Skip to content

taproot updates: fix htlc scripts correctness #21

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 1 commit into from
May 24, 2022
Merged

taproot updates: fix htlc scripts correctness #21

Changes from all commits
Commits
Show all changes
1 commit
Select commit
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
12 changes: 6 additions & 6 deletions taproot-updates.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -136,12 +136,12 @@ 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_CHECKSIGVERIFY
<local_htlcpubkey> OP_CHECKSIGVERIFY <remote_htlcpubkey> OP_CHECKSIGVERIFY
1 OP_CHECKSEQUENCEVERIFY
",
"tapleaf_2": "
# funds go to the remote node if it has the payment preimage.
OP_HASH160 <RIPEMD160(payment_hash)> OP_EQUALVERIFY
OP_SIZE 32 OP_EQUALVERIFY OP_HASH160 <RIPEMD160(payment_hash)> OP_EQUALVERIFY
<remote_htlcpubkey>
OP_CHECKSIGVERIFY
1 OP_CHECKSEQUENCEVERIFY
Expand All @@ -159,8 +159,8 @@ The commitment transaction will then become:
"tapleaf_1": "
# 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_CHECKSIGVERIFY
OP_SIZE 32 OP_EQUALVERIFY OP_HASH160 <RIPEMD160(payment_hash)> OP_EQUALVERIFY
<local_htlcpubkey> OP_CHECKSIGVERIFY <remote_htlcpubkey> OP_CHECKSIGVERIFY
1 OP_CHECKSEQUENCEVERIFY
",
"tapleaf_2": "
Expand Down Expand Up @@ -195,7 +195,7 @@ A taproot HTLC-success transaction looks like:
{
"txid": "...",
"vout": 42,
"scriptSig": "<payment_preimage> <remotehtlcsig> <localhtlcsig>",
"scriptSig": "<remotehtlcsig> <localhtlcsig> <payment_preimage>",
"sequence": 1
}
],
Expand Down Expand Up @@ -318,7 +318,7 @@ We can see a few problems emerge from that two steps process:
transactions that let the remote peer claim PTLCs from the local commitment
* claiming successful PTLCs from the remote peer's commitment now requires using RBF and sighash
flags similar to anchor outputs HTLC transactions (`sighash_single | sighash_anyonecanpay` trick)
* before signing a commitment update, peers must obtain from their counterpary adaptor signatures
* before signing a commitment update, peers must obtain from their counterparty adaptor signatures
for their pending received PTLCs in the future remote commitment

Let's now detail a strawman, high-level proposal that enables PTLCs.
Expand Down