@@ -136,7 +136,7 @@ The commitment transaction will then become:
136136 "tapleaf_1": "
137137 # funds go back to us via a second-stage HTLC-timeout transaction (which contains an absolute delay)
138138 # NB: we also need the remote signature, which prevents us from unilaterally changing the HTLC-timeout transaction
139- <remote_htlcpubkey> OP_CHECKSIGVERIFY <local_htlcpubkey> OP_CHECKSIG
139+ <remote_htlcpubkey> OP_CHECKSIGVERIFY <local_htlcpubkey> OP_CHECKSIGVERIFY
140140 1 OP_CHECKSEQUENCEVERIFY
141141 ",
142142 "tapleaf_2": "
@@ -160,16 +160,17 @@ The commitment transaction will then become:
160160 # funds go to us via a second-stage HTLC-success transaction once we have the payment preimage
161161 # NB: we also need the remote signature, which prevents us from unilaterally changing the HTLC-success transaction
162162 OP_HASH160 <RIPEMD160(payment_hash)> OP_EQUALVERIFY
163- <remote_htlcpubkey> OP_CHECKSIGVERIFY <local_htlcpubkey> OP_CHECKSIG
163+ <remote_htlcpubkey> OP_CHECKSIGVERIFY <local_htlcpubkey> OP_CHECKSIGVERIFY
164164 1 OP_CHECKSEQUENCEVERIFY
165165 ",
166166 "tapleaf_2": "
167167 # funds go to the remote node after an absolute delay (timeout)
168168 <remote_htlcpubkey>
169169 OP_CHECKSIGVERIFY
170+ 1 OP_CHECKSEQUENCEVERIFY
170171 <cltv_expiry>
171172 OP_CHECKLOCKTIMEVERIFY
172- 1 OP_CHECKSEQUENCEVERIFY
173+ OP_DROP
173174 "
174175 }
175176 },
@@ -195,7 +196,7 @@ A taproot HTLC-success transaction looks like:
195196 "txid": "...",
196197 "vout": 42,
197198 "scriptSig": "<payment_preimage> <remotehtlcsig> <localhtlcsig>",
198- "sequence": 0
199+ "sequence": 1
199200 }
200201 ],
201202 "vout": [
@@ -230,7 +231,7 @@ A taproot HTLC-timeout transaction looks like:
230231 "txid": "...",
231232 "vout": 42,
232233 "scriptSig": "<remotehtlcsig> <localhtlcsig>",
233- "sequence": 0
234+ "sequence": 1
234235 }
235236 ],
236237 "vout": [
@@ -283,13 +284,13 @@ structure (or something similar) to our commitment transaction:
283284 "tapleaf_1": "
284285 # funds go back to us via a second-stage PTLC-timeout transaction (which contains an absolute delay)
285286 # NB: we need the remote signature, which prevents us from unilaterally changing the PTLC-timeout transaction
286- <remote_ptlcpubkey> OP_CHECKSIGVERIFY <local_ptlcpubkey> OP_CHECKSIG
287+ <remote_ptlcpubkey> OP_CHECKSIGVERIFY <local_ptlcpubkey> OP_CHECKSIGVERIFY
287288 1 OP_CHECKSEQUENCEVERIFY
288289 ",
289290 "tapleaf_2": "
290291 # funds go to the remote node via a second-stage Claim-PTLC-success transaction by completing an adaptor sig, revealing the payment secret
291292 # NB: we don't use musig2 here because it would force local and remote signatures to use the same sighash flags
292- <local_ptlcpubkey> OP_CHECKSIGVERIFY <remote_ptlcpubkey> OP_CHECKSIG
293+ <local_ptlcpubkey> OP_CHECKSIGVERIFY <remote_ptlcpubkey> OP_CHECKSIGVERIFY
293294 1 OP_CHECKSEQUENCEVERIFY
294295 "
295296}
@@ -333,7 +334,7 @@ We simply add two new types of outputs to the commit tx (PTLC offered / PTLC rec
333334 | +------------------------+
334335 +------->| commit tx B |
335336 +------------------------+
336- | | | | | | | |
337+ | | | | | | | |
337338 | | | | | | | | A's main output
338339 | | | | | | | +-----------------> to A after a 1-block relative delay
339340 | | | | | | |
@@ -388,7 +389,7 @@ We simply add two new types of outputs to the commit tx (PTLC offered / PTLC rec
388389 | +---> to A with revocation key
389390 |
390391 | (B's RBF inputs) ---+
391- | | +---> to B after relative delay
392+ | | +---> to B after relative delay
392393 | +---->+-----------------+ |
393394 | +---------->| PTLC-success tx |----------------+
394395 | PTLC received by B | +-----------------+ |
0 commit comments