mirrors/lightning-bolts
1
0
Fork 0
mirror of https://github.com/lightning/bolts.git synced 2024-11-19 10:00:04 +01:00
Code Issues Projects Releases Wiki Activity
2be691e19d
lightning-bolts/03-transactions.md

2691 lines
297 KiB
Markdown
Raw Normal View History

BOLT 3: remove rogue a.k.a.
2017-12-18 22:30:58 +01:00
# BOLT #3: Bitcoin Transaction and Script Formats
Transfer from google doc. Minimal markdown and consistency fixes, more to come. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-11-15 02:23:20 +01:00
BOLT-3 Edits This is my final first-pass BOLT. Some grammar changes, some remote/local additions, a few questions.
2018-01-16 20:52:38 +01:00
This details the exact format of on-chain transactions, which both sides need to agree on to ensure signatures are valid. This consists of the funding transaction output script, the commitment transactions, and the HTLC transactions.
Transfer from google doc. Minimal markdown and consistency fixes, more to come. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-11-15 02:23:20 +01:00
added a table of contents to bolt3
2016-12-20 16:43:08 +01:00
# Table of Contents
BOLT 1,2,3: first pass copy-edit; BOLT 1,2: minor header spacing fixes BOLT 3: first pass copy edit, according to capitalization, formatting stylesheet guidelines;
2017-11-18 22:04:58 +01:00
added a table of contents to bolt3
2016-12-20 16:43:08 +01:00
* [Transactions](#transactions)
Concretize Output Ordering to be less confusing (#876) * Clean up output sorting wording to be a sorted list and way more explicit * Retitle section to not mention input ordering as we do not need it
2021-06-21 22:14:27 +02:00
* [Transaction Output Ordering](#transaction-output-ordering)
BOLT 1,2,3: first pass copy-edit; BOLT 1,2: minor header spacing fixes BOLT 3: first pass copy edit, according to capitalization, formatting stylesheet guidelines;
2017-11-18 22:04:58 +01:00
* [Use of Segwit](#use-of-segwit)
added a table of contents to bolt3
2016-12-20 16:43:08 +01:00
* [Funding Transaction Output](#funding-transaction-output)
* [Commitment Transaction](#commitment-transaction)
* [Commitment Transaction Outputs](#commitment-transaction-outputs)
Fix TOC indentation and links
2018-05-24 17:05:44 +02:00
* [`to_local` Output](#to_local-output)
* [`to_remote` Output](#to_remote-output)
Anchor outputs This commit extends the specification with a new commitment format that adds two anchor outputs to the commitment transaction. Anchor outputs are a safety feature that allows a channel party to unilaterally increase the fee of the commitment transaction using CPFP and ensure timely confirmation on the chain. There is no cooperation required from the remote party.
2020-08-19 12:29:11 +02:00
* [`to_local_anchor` and `to_remote_anchor`](#to_local_anchor-and-to_remote_anchor-output-option_anchor_outputs)
Fix TOC indentation and links
2018-05-24 17:05:44 +02:00
* [Offered HTLC Outputs](#offered-htlc-outputs)
* [Received HTLC Outputs](#received-htlc-outputs)
BOLT 3: Spell out how to construct the commitment transaction. * I add the term "trimmed outputs" for sub-dust outputs; this matters for both fee calculation and transaction construction. * Introduce the concept of "base fee": this is what needs to be extracted from the funder. * The requirements are spread between the different sections, let's tie it together in a new section at the end. * Spell out all the steps in the example which calculates fees. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-01-23 23:57:40 +01:00
* [Trimmed Outputs](#trimmed-outputs)
BOLT 3: complete first pass copy-edit according to stylesheet guidelines;
2017-11-21 03:51:25 +01:00
* [HTLC-timeout and HTLC-success Transactions](#htlc-timeout-and-htlc-success-transactions)
BOLT 3: define closing transaction. The only surprise here (maybe?) is that we use the commitment number encoding. I think that makes sense, but it was unspecified before. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-07-04 05:58:37 +02:00
* [Closing Transaction](#closing-transaction)
added a section about who pays the fee
2017-01-03 18:20:12 +01:00
* [Fees](#fees)
Remove trailing whitespace
2018-01-30 05:26:52 +01:00
* [Fee Calculation](#fee-calculation)
added a section about who pays the fee
2017-01-03 18:20:12 +01:00
* [Fee Payment](#fee-payment)
Peers need to check each other's dust limit (#894) Since HTLCs below this amount will not appear in the commitment tx, they are effectively converted to miner fees. The peer could use this to grief you by broadcasting its commitment once it contains a lot of dust HTLCs. Add network dust thresholds computation details, as implemented in Bitcoin Core's default relay policy. Drop non-segwit support in shutdown: this allows dust limit to go as low as 354 sats without creating relay issues with default node policies. We add a requirement that dust limit cannot be lower than 354 sats. This ensures implementers don't have to figure this subtlety on their own. Fixes #696 and #905
2021-10-06 09:40:22 +02:00
* [Dust Limits](#dust-limits)
* [Commitment Transaction Construction](#commitment-transaction-construction)
moved weight computation to Appendix section, fixed index
2017-01-03 11:28:37 +01:00
* [Keys](#keys)
* [Key Derivation](#key-derivation)
Fix TOC indentation and links
2018-05-24 17:05:44 +02:00
* [`localpubkey`, `remotepubkey`, `local_htlcpubkey`, `remote_htlcpubkey`, `local_delayedpubkey`, and `remote_delayedpubkey` Derivation](#localpubkey-remotepubkey-local_htlcpubkey-remote_htlcpubkey-local_delayedpubkey-and-remote_delayedpubkey-derivation)
BOLT 2,3,5: always refer to shared/pubkey/private key. Make it clear what kind of key we're talking about. We use the abbreviation pubkey for public key (as it's quite common to use in field names), but generally spell out 'private'. (I generally prefer 'secret' to 'private' but we use private far more often already, and we use 'secret' for things which don't directly derive keys). Fixes: #368 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2018-02-06 01:18:41 +01:00
* [`revocationpubkey` Derivation](#revocationpubkey-derivation)
BOLT 1,2,3: first pass copy-edit; BOLT 1,2: minor header spacing fixes BOLT 3: first pass copy edit, according to capitalization, formatting stylesheet guidelines;
2017-11-18 22:04:58 +01:00
* [Per-commitment Secret Requirements](#per-commitment-secret-requirements)
moved weight computation to Appendix section, fixed index
2017-01-03 11:28:37 +01:00
* [Efficient Per-commitment Secret Storage](#efficient-per-commitment-secret-storage)
Remove trailing whitespace
2018-01-30 05:26:52 +01:00
* [Appendix A: Expected Weights](#appendix-a-expected-weights)
BOLT 1,2,3: first pass copy-edit; BOLT 1,2: minor header spacing fixes BOLT 3: first pass copy edit, according to capitalization, formatting stylesheet guidelines;
2017-11-18 22:04:58 +01:00
* [Expected Weight of the Commitment Transaction](#expected-weight-of-the-commitment-transaction)
BOLT 3: complete first pass copy-edit according to stylesheet guidelines;
2017-11-21 03:51:25 +01:00
* [Expected Weight of HTLC-timeout and HTLC-success Transactions](#expected-weight-of-htlc-timeout-and-htlc-success-transactions)
BOLT 03: Fix appendix numbers and TOC links.
2017-09-22 08:18:18 +02:00
* [Appendix B: Funding Transaction Test Vectors](#appendix-b-funding-transaction-test-vectors)
* [Appendix C: Commitment and HTLC Transaction Test Vectors](#appendix-c-commitment-and-htlc-transaction-test-vectors)
* [Appendix D: Per-commitment Secret Generation Test Vectors](#appendix-d-per-commitment-secret-generation-test-vectors)
BOLT 1,2,3: first pass copy-edit; BOLT 1,2: minor header spacing fixes BOLT 3: first pass copy edit, according to capitalization, formatting stylesheet guidelines;
2017-11-18 22:04:58 +01:00
* [Generation Tests](#generation-tests)
* [Storage Tests](#storage-tests)
fix some links
2017-10-17 02:55:45 +02:00
* [Appendix E: Key Derivation Test Vectors](#appendix-e-key-derivation-test-vectors)
Anchor outputs This commit extends the specification with a new commitment format that adds two anchor outputs to the commitment transaction. Anchor outputs are a safety feature that allows a channel party to unilaterally increase the fee of the commitment transaction using CPFP and ensure timely confirmation on the chain. There is no cooperation required from the remote party.
2020-08-19 12:29:11 +02:00
* [Appendix F: Commitment and HTLC Transaction Test Vectors (anchors)](#appendix-f-commitment-and-htlc-transaction-test-vectors-anchors)
Add test vectors for option_anchors_zero_fee_htlc_tx (#1018) These are the same test vectors as those found under Appendix F, except that each HTLC has a zero fee transaction instead, resulting in a signature change.
2023-02-28 09:30:50 +01:00
* [Appendix G: Commitment and HTLC Transaction Test Vectors (anchors-zero-fee-htlc-tx)](#appendix-g-commitment-and-htlc-transaction-test-vectors-anchors_zero_fee_htlc_tx)
Remove trailing whitespace
2018-01-30 05:26:52 +01:00
* [References](#references)
* [Authors](#authors)
BOLT 1,2,3: first pass copy-edit; BOLT 1,2: minor header spacing fixes BOLT 3: first pass copy edit, according to capitalization, formatting stylesheet guidelines;
2017-11-18 22:04:58 +01:00
added a table of contents to bolt3
2016-12-20 16:43:08 +01:00
# Transactions
Concretize Output Ordering to be less confusing (#876) * Clean up output sorting wording to be a sorted list and way more explicit * Retitle section to not mention input ordering as we do not need it
2021-06-21 22:14:27 +02:00
## Transaction Output Ordering
Transfer from google doc. Minimal markdown and consistency fixes, more to come. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-11-15 02:23:20 +01:00
Concretize Output Ordering to be less confusing (#876) * Clean up output sorting wording to be a sorted list and way more explicit * Retitle section to not mention input ordering as we do not need it
2021-06-21 22:14:27 +02:00
Outputs in transactions are always sorted according to:
Update 03-transactions.md
2022-05-22 18:40:39 +02:00
* first according to their value, smallest first (in whole satoshis, note that for HTLC outputs, the millisatoshi part must be ignored)
Concretize Output Ordering to be less confusing (#876) * Clean up output sorting wording to be a sorted list and way more explicit * Retitle section to not mention input ordering as we do not need it
2021-06-21 22:14:27 +02:00
* followed by `scriptpubkey`, comparing the common-length prefix lexicographically as if by `memcmp`, then selecting the shorter script (if they differ in length),
* finally, for HTLC outputs, in increasing `cltv_expiry` order.
BOLT #2: order htlc_signatures by BIP69 + increasing CLTV. We express it has how the outputs are ordered, but the only way you can detect that is by the htlc_signatures order, which is the part which really matters. I finally reproduced this, BTW, which is why I'm digging it up! Closes: #448 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2018-10-21 12:21:30 +02:00
## Rationale
BOLT-03: make sats portion of HTLC CLTV tie-breaker more explicit This commit is intended to fix an ambiguity in the spec that led to a divergence in the sorting tie breaker between implementations, that can lead to force closed transaction in practice. BIP 69 operates on the output level, therefore it examines the _satoshi_ amount of a output when sorting. The spec however, references BIP 69, but states that an "identical" HTLC output may have the same `amount_msat` value. In the wild this led to some implementations checking the _sat_ value of an HTLC while others checked the _msat_ value. In the scenario where an pair HTLC has the same _sat_ value, but differing _msat_ values, then one will fall through to the tie-breaker, while the other while sort them according to their _msat_ values. In this commit, we attempt to make this requirement more explicit by removing the reference to `msat`, and more explicitly describing when an HTLC pair is to be considered identical.
2021-05-15 01:03:54 +02:00
Two offered HTLCs which have the same `amount` (rounded from `amount_msat`) and
`payment_hash` will have identical outputs, even if their `cltv_expiry`
differs. This only matters because the same ordering is used to send
`htlc_signatures` and the HTLC transactions themselves are different, thus the
two peers must agree on the canonical ordering for this case.
Transfer from google doc. Minimal markdown and consistency fixes, more to come. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-11-15 02:23:20 +01:00
BOLT 1,2,3: first pass copy-edit; BOLT 1,2: minor header spacing fixes BOLT 3: first pass copy edit, according to capitalization, formatting stylesheet guidelines;
2017-11-18 22:04:58 +01:00
## Use of Segwit
BOLT 3: fix witness scripts 1. Add a short paragraph on P2WSH (the witness script is omitted for brevity in all descriptions) and fix witness scripts for spending the different tx outputs. 2. use CHECK(MULTI)SIG instead of CHECK(MULTI)SIGVERIFY 3. Fix order and nulldummy for witness in HTLC transactions 4. Fix a minor typo (if -> it) (Commits rebased and squashed together by Rusty)
2016-11-23 17:21:37 +01:00
Define P2WSH earlier
2018-04-02 08:26:30 +02:00
Most transaction outputs used here are pay-to-witness-script-hash<sup>[BIP141](https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#witness-program)</sup> (P2WSH) outputs: the Segwit version of P2SH. To spend such outputs, the last item on the witness stack must be the actual script that was used to generate the P2WSH output that is being spent. This last item has been omitted for brevity in the rest of this document.
BOLT 3: fix witness scripts 1. Add a short paragraph on P2WSH (the witness script is omitted for brevity in all descriptions) and fix witness scripts for spending the different tx outputs. 2. use CHECK(MULTI)SIG instead of CHECK(MULTI)SIGVERIFY 3. Fix order and nulldummy for witness in HTLC transactions 4. Fix a minor typo (if -> it) (Commits rebased and squashed together by Rusty)
2016-11-23 17:21:37 +01:00
Make explicit witness must conform to MINIMALIF (#764)
2020-04-27 21:50:57 +02:00
A `<>` designates an empty vector as required for compliance with MINIMALIF-standard rule.<sup>[MINIMALIF](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-August/013014.html)</sup>
Transfer from google doc. Minimal markdown and consistency fixes, more to come. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-11-15 02:23:20 +01:00
## Funding Transaction Output
Define P2WSH earlier
2018-04-02 08:26:30 +02:00
* The funding output script is a P2WSH to:
`2 <pubkey1> <pubkey2> 2 OP_CHECKMULTISIG`
Clarify numerical comparison of pubkeys (#743) We are using lexixographic order (which is the same as big-endian when inputs have the same size, such as compressed public keys).
2020-02-18 09:53:12 +01:00
* Where `pubkey1` is the lexicographically lesser of the two `funding_pubkey` in compressed format, and where `pubkey2` is the lexicographically greater of the two.
Transfer from google doc. Minimal markdown and consistency fixes, more to come. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-11-15 02:23:20 +01:00
## Commitment Transaction
BOLT 1,2,3: first pass copy-edit; BOLT 1,2: minor header spacing fixes BOLT 3: first pass copy edit, according to capitalization, formatting stylesheet guidelines;
2017-11-18 22:04:58 +01:00
Transfer from google doc. Minimal markdown and consistency fixes, more to come. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-11-15 02:23:20 +01:00
* version: 2
BOLT 3: `commitment number` not `commitment transaction number`. Be consistent.
2018-11-14 12:20:42 +01:00
* locktime: upper 8 bits are 0x20, lower 24 bits are the lower 24 bits of the obscured commitment number
Transfer from google doc. Minimal markdown and consistency fixes, more to come. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-11-15 02:23:20 +01:00
* txin count: 1
trivial: Minor markup fixes
2016-12-09 15:25:48 +01:00
* `txin[0]` outpoint: `txid` and `output_index` from `funding_created` message
BOLT 3: `commitment number` not `commitment transaction number`. Be consistent.
2018-11-14 12:20:42 +01:00
* `txin[0]` sequence: upper 8 bits are 0x80, lower 24 bits are upper 24 bits of the obscured commitment number
trivial: Minor markup fixes
2016-12-09 15:25:48 +01:00
* `txin[0]` script bytes: 0
BOLT 2,3,5: always refer to shared/pubkey/private key. Make it clear what kind of key we're talking about. We use the abbreviation pubkey for public key (as it's quite common to use in field names), but generally spell out 'private'. (I generally prefer 'secret' to 'private' but we use private far more often already, and we use 'secret' for things which don't directly derive keys). Fixes: #368 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2018-02-06 01:18:41 +01:00
* `txin[0]` witness: `0 <signature_for_pubkey1> <signature_for_pubkey2>`
Transfer from google doc. Minimal markdown and consistency fixes, more to come. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-11-15 02:23:20 +01:00
BOLT 3: `commitment number` not `commitment transaction number`. Be consistent.
2018-11-14 12:20:42 +01:00
The 48-bit commitment number is obscured by `XOR` with the lower 48 bits of:
BOLT #3: re-add XORing to obscure the commitment index. I missed this somehow from the spec. Reported-by: Olaoluwa Osuntokun <laolu32@gmail.com> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-11-19 01:09:30 +01:00
BOLT 3: Replace many hyphens with underscores in descriptions. Not sure how I missed these: 1. funding-pubkey -> funding_pubkey 2. to-self-delay -> to_self_delay 3. per-commitment-point -> per_commitment_point 4. per-commitment-secret -> per_commitment_secret 5. revocation-basepoint -> revocation_basepoint 6. delayed-payment-basepoint -> delayed_payment_basepoint 7. payment-basepoint -> payment_basepoint Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-05-11 08:13:40 +02:00
SHA256(payment_basepoint from open_channel || payment_basepoint from accept_channel)
BOLT #3: re-add XORing to obscure the commitment index. I missed this somehow from the spec. Reported-by: Olaoluwa Osuntokun <laolu32@gmail.com> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-11-19 01:09:30 +01:00
This obscures the number of commitments made on the channel in the
case of unilateral close, yet still provides a useful index for both
Underscores for all terms, not just fields. Plus a few more missing ones, and some consistency fixes in names as pointed out by Roasbeed and Fabrice. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-05-14 02:32:22 +02:00
nodes (who know the `payment_basepoint`s) to quickly find a revoked
BOLT #3: re-add XORing to obscure the commitment index. I missed this somehow from the spec. Reported-by: Olaoluwa Osuntokun <laolu32@gmail.com> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-11-19 01:09:30 +01:00
commitment transaction.
Transfer from google doc. Minimal markdown and consistency fixes, more to come. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-11-15 02:23:20 +01:00
### Commitment Transaction Outputs
Minor clarification of htlcs to_self_delay (#983) This is a minor clarification that the `to_self_delay` is enforced in a 2nd-stage transaction for HTLCs, while it's directly enforced in the commit tx for the main output.
2022-04-22 09:36:52 +02:00
To allow an opportunity for penalty transactions, in case of a revoked commitment transaction, all outputs that return funds to the owner of the commitment transaction (a.k.a. the "local node") must be delayed for `to_self_delay` blocks. For HTLCs this delay is done in a second-stage HTLC transaction (HTLC-success for HTLCs accepted by the local node, HTLC-timeout for HTLCs offered by the local node).
Transfer from google doc. Minimal markdown and consistency fixes, more to come. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-11-15 02:23:20 +01:00
BOLT 3: complete first pass copy-edit according to stylesheet guidelines;
2017-11-21 03:51:25 +01:00
The reason for the separate transaction stage for HTLC outputs is so that HTLCs can timeout or be fulfilled even though they are within the `to_self_delay` delay.
Otherwise, the required minimum timeout on HTLCs is lengthened by this delay, causing longer timeouts for HTLCs traversing the network.
Transfer from google doc. Minimal markdown and consistency fixes, more to come. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-11-15 02:23:20 +01:00
BOLT 3: complete first pass copy-edit according to stylesheet guidelines;
2017-11-21 03:51:25 +01:00
The amounts for each output MUST be rounded down to whole satoshis. If this amount, minus the fees for the HTLC transaction, is less than the `dust_limit_satoshis` set by the owner of the commitment transaction, the output MUST NOT be produced (thus the funds add to fees).
BOLT 02/03: Add fee calculation details. Make the fee amount by kiloweight, not by kilobyte, and spell out how to calculate it. Note that we have to trim HTLCs outputs whose second-stage would also fall below dust limit, and we also make some reasonable approximations on transaction size (which is unknowable before signatures anyway). Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-11-21 04:13:42 +01:00
Underscores for all terms, not just fields. Plus a few more missing ones, and some consistency fixes in names as pointed out by Roasbeed and Fabrice. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-05-14 02:32:22 +02:00
#### `to_local` Output
Transfer from google doc. Minimal markdown and consistency fixes, more to come. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-11-15 02:23:20 +01:00
Change opcode reference format (#594) OP_CHECKLOCKTIMEVERIFY and OP_CSV use an inconsistent naming convention. Update OP_CSV to match the OP_CHECKLOCKTIMEVERIFY convention as OP_CHECKSEQUENCEVERIFY.
2019-07-09 10:40:29 +02:00
This output sends funds back to the owner of this commitment transaction and thus must be timelocked using `OP_CHECKSEQUENCEVERIFY`. It can be claimed, without delay, by the other party if they know the revocation private key. The output is a version-0 P2WSH, with a witness script:
'to-local output': add revocation key The 'to local' output in the commit tx should be spendable without delay if you know the revocation key.
2016-11-22 15:33:07 +01:00
OP_IF
# Penalty transaction
BOLT 2,3,5: always refer to shared/pubkey/private key. Make it clear what kind of key we're talking about. We use the abbreviation pubkey for public key (as it's quite common to use in field names), but generally spell out 'private'. (I generally prefer 'secret' to 'private' but we use private far more often already, and we use 'secret' for things which don't directly derive keys). Fixes: #368 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2018-02-06 01:18:41 +01:00
<revocationpubkey>
'to-local output': add revocation key The 'to local' output in the commit tx should be spendable without delay if you know the revocation key.
2016-11-22 15:33:07 +01:00
OP_ELSE
BOLT 3: Replace many hyphens with underscores in descriptions. Not sure how I missed these: 1. funding-pubkey -> funding_pubkey 2. to-self-delay -> to_self_delay 3. per-commitment-point -> per_commitment_point 4. per-commitment-secret -> per_commitment_secret 5. revocation-basepoint -> revocation_basepoint 6. delayed-payment-basepoint -> delayed_payment_basepoint 7. payment-basepoint -> payment_basepoint Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-05-11 08:13:40 +02:00
`to_self_delay`
Change opcode reference format (#594) OP_CHECKLOCKTIMEVERIFY and OP_CSV use an inconsistent naming convention. Update OP_CSV to match the OP_CHECKLOCKTIMEVERIFY convention as OP_CHECKSEQUENCEVERIFY.
2019-07-09 10:40:29 +02:00
OP_CHECKSEQUENCEVERIFY
'to-local output': add revocation key The 'to local' output in the commit tx should be spendable without delay if you know the revocation key.
2016-11-22 15:33:07 +01:00
OP_DROP
BOLT 2,3,5: always refer to shared/pubkey/private key. Make it clear what kind of key we're talking about. We use the abbreviation pubkey for public key (as it's quite common to use in field names), but generally spell out 'private'. (I generally prefer 'secret' to 'private' but we use private far more often already, and we use 'secret' for things which don't directly derive keys). Fixes: #368 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2018-02-06 01:18:41 +01:00
<local_delayedpubkey>
'to-local output': add revocation key The 'to local' output in the commit tx should be spendable without delay if you know the revocation key.
2016-11-22 15:33:07 +01:00
OP_ENDIF
OP_CHECKSIG
Transfer from google doc. Minimal markdown and consistency fixes, more to come. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-11-15 02:23:20 +01:00
Anchor outputs This commit extends the specification with a new commitment format that adds two anchor outputs to the commitment transaction. Anchor outputs are a safety feature that allows a channel party to unilaterally increase the fee of the commitment transaction using CPFP and ensure timely confirmation on the chain. There is no cooperation required from the remote party.
2020-08-19 12:29:11 +02:00
The output is spent by an input with `nSequence` field set to `to_self_delay` (which can only be valid after that duration has passed) and witness:
trivial: Consolidating inline code Now using `<>` on inline code only when part of a script and extra emphasis is warranted. Outside of scripts the variable names are already highlighted, so no need to add further emphasis.
2016-12-09 15:27:55 +01:00
Make explicit witness must conform to MINIMALIF (#764)
2020-04-27 21:50:57 +02:00
<local_delayedsig> <>
Transfer from google doc. Minimal markdown and consistency fixes, more to come. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-11-15 02:23:20 +01:00
witnessScript is part of witness + null dummy for OP_CHECKMULTISIG (#70) * Add null dummy consumed by OP_CHECKMULTISIG * scriptsig -> witness. * witness script -> witness.
2017-01-04 06:39:18 +01:00
If a revoked commitment transaction is published, the other party can spend this output immediately with the following witness:
'to-local output': add revocation key The 'to local' output in the commit tx should be spendable without delay if you know the revocation key.
2016-11-22 15:33:07 +01:00
Underscores for all terms, not just fields. Plus a few more missing ones, and some consistency fixes in names as pointed out by Roasbeed and Fabrice. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-05-14 02:32:22 +02:00
<revocation_sig> 1
'to-local output': add revocation key The 'to local' output in the commit tx should be spendable without delay if you know the revocation key.
2016-11-22 15:33:07 +01:00
Underscores for all terms, not just fields. Plus a few more missing ones, and some consistency fixes in names as pointed out by Roasbeed and Fabrice. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-05-14 02:32:22 +02:00
#### `to_remote` Output
Transfer from google doc. Minimal markdown and consistency fixes, more to come. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-11-15 02:23:20 +01:00
feature: define option_zero_htlc_tx_fee (feature 22/23) (#824) This PR adds a new feature bit to define the new and improved anchor outputs commitment format.
2021-08-30 22:50:25 +02:00
If `option_anchors` applies to the commitment transaction, the `to_remote` output is encumbered by a one block csv lock.
Anchor outputs This commit extends the specification with a new commitment format that adds two anchor outputs to the commitment transaction. Anchor outputs are a safety feature that allows a channel party to unilaterally increase the fee of the commitment transaction using CPFP and ensure timely confirmation on the chain. There is no cooperation required from the remote party.
2020-08-19 12:29:11 +02:00
Make generated pubkeys slightly more grep-able (#988) * remotepubkey instead of remote_pubkey * Add a grepable reference of localpubkey usage
2022-05-12 09:19:21 +02:00
<remotepubkey> OP_CHECKSIGVERIFY 1 OP_CHECKSEQUENCEVERIFY
Anchor outputs This commit extends the specification with a new commitment format that adds two anchor outputs to the commitment transaction. Anchor outputs are a safety feature that allows a channel party to unilaterally increase the fee of the commitment transaction using CPFP and ensure timely confirmation on the chain. There is no cooperation required from the remote party.
2020-08-19 12:29:11 +02:00
The output is spent by an input with `nSequence` field set to `1` and witness:
<remote_sig>
Make generated pubkeys slightly more grep-able (#988) * remotepubkey instead of remote_pubkey * Add a grepable reference of localpubkey usage
2022-05-12 09:19:21 +02:00
Otherwise, this output is a simple P2WPKH to `remotepubkey`. Note: the remote's commitment transaction uses your `localpubkey` for their
`to_remote` output to yourself.
Anchor outputs This commit extends the specification with a new commitment format that adds two anchor outputs to the commitment transaction. Anchor outputs are a safety feature that allows a channel party to unilaterally increase the fee of the commitment transaction using CPFP and ensure timely confirmation on the chain. There is no cooperation required from the remote party.
2020-08-19 12:29:11 +02:00
feature: define option_zero_htlc_tx_fee (feature 22/23) (#824) This PR adds a new feature bit to define the new and improved anchor outputs commitment format.
2021-08-30 22:50:25 +02:00
#### `to_local_anchor` and `to_remote_anchor` Output (option_anchors)
Anchor outputs This commit extends the specification with a new commitment format that adds two anchor outputs to the commitment transaction. Anchor outputs are a safety feature that allows a channel party to unilaterally increase the fee of the commitment transaction using CPFP and ensure timely confirmation on the chain. There is no cooperation required from the remote party.
2020-08-19 12:29:11 +02:00
This output can be spent by the local and remote nodes respectively to provide incentive to mine the transaction, using child-pays-for-parent. Both
anchor outputs are always added, except for the case where there are no htlcs and one of the parties has a commitment output that is below the dust limit.
In that case only an anchor is added for the commitment output that does materialize. This typically happens if the initiator closes right after opening
(no `to_remote` output).
<local_funding_pubkey/remote_funding_pubkey> OP_CHECKSIG OP_IFDUP
OP_NOTIF
OP_16 OP_CHECKSEQUENCEVERIFY
OP_ENDIF
Each party has its own anchor output that locks to their funding key. This is to prevent a malicious peer from attaching child transactions with a low fee
density to an anchor and thereby blocking the victim from getting the commit tx confirmed in time. This defense is supported by a change in Bitcoin core 0.19:
https://github.com/bitcoin/bitcoin/pull/15681. This is also the reason that every non-anchor output on the commit tx is CSV locked.
To prevent utxo set pollution, any anchor that remains unspent can be spent by anyone after the commitment tx confirms. This is also the reason to lock
the anchor outputs to the funding key. Third parties can observe this key and reconstruct the spend script, even if none of the commitment outputs would
be spent. This does assume that at some point the fee market goes down to a level where sweeping the anchors is economical.
The amount of the output is fixed at 330 sats, the default dust limit for P2WSH.
Spending of the output requires the following witness:
<local_sig/remote_sig>
After 16 blocks, anyone can sweep the anchor with witness:
<>
Transfer from google doc. Minimal markdown and consistency fixes, more to come. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-11-15 02:23:20 +01:00
#### Offered HTLC Outputs
feature: define option_zero_htlc_tx_fee (feature 22/23) (#824) This PR adds a new feature bit to define the new and improved anchor outputs commitment format.
2021-08-30 22:50:25 +02:00
This output sends funds to either an HTLC-timeout transaction after the HTLC-timeout or to the remote node using the payment preimage or the revocation key. The output is a P2WSH, with a witness script (no option_anchors):
Transfer from google doc. Minimal markdown and consistency fixes, more to come. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-11-15 02:23:20 +01:00
BOLT-3 Edits This is my final first-pass BOLT. Some grammar changes, some remote/local additions, a few questions.
2018-01-16 20:52:38 +01:00
# To remote node with revocation key
BOLT 2,3,5: always refer to shared/pubkey/private key. Make it clear what kind of key we're talking about. We use the abbreviation pubkey for public key (as it's quite common to use in field names), but generally spell out 'private'. (I generally prefer 'secret' to 'private' but we use private far more often already, and we use 'secret' for things which don't directly derive keys). Fixes: #368 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2018-02-06 01:18:41 +01:00
OP_DUP OP_HASH160 <RIPEMD160(SHA256(revocationpubkey))> OP_EQUAL
BOLT 3: Use revocation key hash rather than revocation key in scripts. This means more bytes if we need to create a penalty tx, but less for normal operation: Witness script for offered htlcs: 139 bytes -> 133 bytes. Witness script for accepted htlcs: 156 bytes -> 139 bytes. It's also a little simpler; it's just an OP_IF around the old scripts to test for the revocation key being the top arg. Suggested-by: Joseph Poon <joseph@lightning.network> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-03-07 00:11:06 +01:00
OP_IF
BOLT 3: fix witness scripts 1. Add a short paragraph on P2WSH (the witness script is omitted for brevity in all descriptions) and fix witness scripts for spending the different tx outputs. 2. use CHECK(MULTI)SIG instead of CHECK(MULTI)SIGVERIFY 3. Fix order and nulldummy for witness in HTLC transactions 4. Fix a minor typo (if -> it) (Commits rebased and squashed together by Rusty)
2016-11-23 17:21:37 +01:00
OP_CHECKSIG
BOLT 3: Use revocation key hash rather than revocation key in scripts. This means more bytes if we need to create a penalty tx, but less for normal operation: Witness script for offered htlcs: 139 bytes -> 133 bytes. Witness script for accepted htlcs: 156 bytes -> 139 bytes. It's also a little simpler; it's just an OP_IF around the old scripts to test for the revocation key being the top arg. Suggested-by: Joseph Poon <joseph@lightning.network> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-03-07 00:11:06 +01:00
OP_ELSE
BOLT 2,3,5: always refer to shared/pubkey/private key. Make it clear what kind of key we're talking about. We use the abbreviation pubkey for public key (as it's quite common to use in field names), but generally spell out 'private'. (I generally prefer 'secret' to 'private' but we use private far more often already, and we use 'secret' for things which don't directly derive keys). Fixes: #368 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2018-02-06 01:18:41 +01:00
<remote_htlcpubkey> OP_SWAP OP_SIZE 32 OP_EQUAL
BOLT 3: Use revocation key hash rather than revocation key in scripts. This means more bytes if we need to create a penalty tx, but less for normal operation: Witness script for offered htlcs: 139 bytes -> 133 bytes. Witness script for accepted htlcs: 156 bytes -> 139 bytes. It's also a little simpler; it's just an OP_IF around the old scripts to test for the revocation key being the top arg. Suggested-by: Joseph Poon <joseph@lightning.network> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-03-07 00:11:06 +01:00
OP_NOTIF
BOLT-3 Edits This is my final first-pass BOLT. Some grammar changes, some remote/local additions, a few questions.
2018-01-16 20:52:38 +01:00
# To local node via HTLC-timeout transaction (timelocked).
BOLT 2,3,5: always refer to shared/pubkey/private key. Make it clear what kind of key we're talking about. We use the abbreviation pubkey for public key (as it's quite common to use in field names), but generally spell out 'private'. (I generally prefer 'secret' to 'private' but we use private far more often already, and we use 'secret' for things which don't directly derive keys). Fixes: #368 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2018-02-06 01:18:41 +01:00
OP_DROP 2 OP_SWAP <local_htlcpubkey> 2 OP_CHECKMULTISIG
BOLT 3: Use revocation key hash rather than revocation key in scripts. This means more bytes if we need to create a penalty tx, but less for normal operation: Witness script for offered htlcs: 139 bytes -> 133 bytes. Witness script for accepted htlcs: 156 bytes -> 139 bytes. It's also a little simpler; it's just an OP_IF around the old scripts to test for the revocation key being the top arg. Suggested-by: Joseph Poon <joseph@lightning.network> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-03-07 00:11:06 +01:00
OP_ELSE
BOLT-3 Edits This is my final first-pass BOLT. Some grammar changes, some remote/local additions, a few questions.
2018-01-16 20:52:38 +01:00
# To remote node with preimage.
BOLT 3: instead of ripemd-of-X, use RIPEMD160(X). This is more specific and clearer. Reported-by: Olaoluwa Osuntokun <laolu32@gmail.com> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-05-13 08:37:19 +02:00
OP_HASH160 <RIPEMD160(payment_hash)> OP_EQUALVERIFY
BOLT 3: Use revocation key hash rather than revocation key in scripts. This means more bytes if we need to create a penalty tx, but less for normal operation: Witness script for offered htlcs: 139 bytes -> 133 bytes. Witness script for accepted htlcs: 156 bytes -> 139 bytes. It's also a little simpler; it's just an OP_IF around the old scripts to test for the revocation key being the top arg. Suggested-by: Joseph Poon <joseph@lightning.network> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-03-07 00:11:06 +01:00
OP_CHECKSIG
OP_ENDIF
Transfer from google doc. Minimal markdown and consistency fixes, more to come. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-11-15 02:23:20 +01:00
OP_ENDIF
feature: define option_zero_htlc_tx_fee (feature 22/23) (#824) This PR adds a new feature bit to define the new and improved anchor outputs commitment format.
2021-08-30 22:50:25 +02:00
Or, with `option_anchors`:
Anchor outputs This commit extends the specification with a new commitment format that adds two anchor outputs to the commitment transaction. Anchor outputs are a safety feature that allows a channel party to unilaterally increase the fee of the commitment transaction using CPFP and ensure timely confirmation on the chain. There is no cooperation required from the remote party.
2020-08-19 12:29:11 +02:00
# To remote node with revocation key
OP_DUP OP_HASH160 <RIPEMD160(SHA256(revocationpubkey))> OP_EQUAL
OP_IF
OP_CHECKSIG
OP_ELSE
<remote_htlcpubkey> OP_SWAP OP_SIZE 32 OP_EQUAL
OP_NOTIF
# To local node via HTLC-timeout transaction (timelocked).
OP_DROP 2 OP_SWAP <local_htlcpubkey> 2 OP_CHECKMULTISIG
OP_ELSE
# To remote node with preimage.
OP_HASH160 <RIPEMD160(payment_hash)> OP_EQUALVERIFY
OP_CHECKSIG
OP_ENDIF
1 OP_CHECKSEQUENCEVERIFY OP_DROP
OP_ENDIF
witnessScript is part of witness + null dummy for OP_CHECKMULTISIG (#70) * Add null dummy consumed by OP_CHECKMULTISIG * scriptsig -> witness. * witness script -> witness.
2017-01-04 06:39:18 +01:00
The remote node can redeem the HTLC with the witness:
Transfer from google doc. Minimal markdown and consistency fixes, more to come. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-11-15 02:23:20 +01:00
htlckey: new basepoint avoid holding the payment secret. This is stolen from @sstone's #243 "reduce attack surface". This breaks compatibility, as agreed at the 2017-11-13 meeting. Note also that it does not update the test vectors. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-10-31 02:02:32 +01:00
<remotehtlcsig> <payment_preimage>
Transfer from google doc. Minimal markdown and consistency fixes, more to come. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-11-15 02:23:20 +01:00
feature: define option_zero_htlc_tx_fee (feature 22/23) (#824) This PR adds a new feature bit to define the new and improved anchor outputs commitment format.
2021-08-30 22:50:25 +02:00
Note that if `option_anchors` applies, the nSequence field of
Anchor outputs This commit extends the specification with a new commitment format that adds two anchor outputs to the commitment transaction. Anchor outputs are a safety feature that allows a channel party to unilaterally increase the fee of the commitment transaction using CPFP and ensure timely confirmation on the chain. There is no cooperation required from the remote party.
2020-08-19 12:29:11 +02:00
the spending input must be `1`.
make htlc outputs of the commitment tx spendable with revocation key (Merge conflict in test vectors fixed by selecting Pierre's, will have to be re-evaluated). Closes: #105
2017-02-10 12:23:32 +01:00
If a revoked commitment transaction is published, the remote node can spend this output immediately with the following witness:
BOLT 2,3,5: always refer to shared/pubkey/private key. Make it clear what kind of key we're talking about. We use the abbreviation pubkey for public key (as it's quite common to use in field names), but generally spell out 'private'. (I generally prefer 'secret' to 'private' but we use private far more often already, and we use 'secret' for things which don't directly derive keys). Fixes: #368 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2018-02-06 01:18:41 +01:00
<revocation_sig> <revocationpubkey>
make htlc outputs of the commitment tx spendable with revocation key (Merge conflict in test vectors fixed by selecting Pierre's, will have to be re-evaluated). Closes: #105
2017-02-10 12:23:32 +01:00
BOLT 3: Explicit description of implicitly enforced timelocks on HTLC outputs (#601) * Added descriptions of how a 2-of-2 multisignature verification is used for enforcing timelocks when timing out on-chain offered HTLCs as well as spending on-chain received HTLCs in the success case.
2019-08-19 23:52:09 +02:00
The sending node can use the HTLC-timeout transaction to timeout the HTLC once the HTLC is expired, as shown below. This is the only way that the local node can timeout the HTLC, and this branch requires `<remotehtlcsig>`, which ensures that the local node cannot prematurely timeout the HTLC since the HTLC-timeout transaction has `cltv_expiry` as its specified `locktime`. The local node must also wait `to_self_delay` before accessing these funds, allowing for the remote node to claim these funds if the transaction has been revoked.
Transfer from google doc. Minimal markdown and consistency fixes, more to come. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-11-15 02:23:20 +01:00
#### Received HTLC Outputs
feature: define option_zero_htlc_tx_fee (feature 22/23) (#824) This PR adds a new feature bit to define the new and improved anchor outputs commitment format.
2021-08-30 22:50:25 +02:00
This output sends funds to either the remote node after the HTLC-timeout or using the revocation key, or to an HTLC-success transaction with a successful payment preimage. The output is a P2WSH, with a witness script (no `option_anchors`):
Transfer from google doc. Minimal markdown and consistency fixes, more to come. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-11-15 02:23:20 +01:00
BOLT-3 Edits This is my final first-pass BOLT. Some grammar changes, some remote/local additions, a few questions.
2018-01-16 20:52:38 +01:00
# To remote node with revocation key
BOLT 2,3,5: always refer to shared/pubkey/private key. Make it clear what kind of key we're talking about. We use the abbreviation pubkey for public key (as it's quite common to use in field names), but generally spell out 'private'. (I generally prefer 'secret' to 'private' but we use private far more often already, and we use 'secret' for things which don't directly derive keys). Fixes: #368 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2018-02-06 01:18:41 +01:00
OP_DUP OP_HASH160 <RIPEMD160(SHA256(revocationpubkey))> OP_EQUAL
Transfer from google doc. Minimal markdown and consistency fixes, more to come. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-11-15 02:23:20 +01:00
OP_IF
BOLT 3: Use revocation key hash rather than revocation key in scripts. This means more bytes if we need to create a penalty tx, but less for normal operation: Witness script for offered htlcs: 139 bytes -> 133 bytes. Witness script for accepted htlcs: 156 bytes -> 139 bytes. It's also a little simpler; it's just an OP_IF around the old scripts to test for the revocation key being the top arg. Suggested-by: Joseph Poon <joseph@lightning.network> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-03-07 00:11:06 +01:00
OP_CHECKSIG
Transfer from google doc. Minimal markdown and consistency fixes, more to come. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-11-15 02:23:20 +01:00
OP_ELSE
Align offered and received HTLC scripts similarly
2019-01-16 20:51:08 +01:00
<remote_htlcpubkey> OP_SWAP OP_SIZE 32 OP_EQUAL
make htlc outputs of the commitment tx spendable with revocation key (Merge conflict in test vectors fixed by selecting Pierre's, will have to be re-evaluated). Closes: #105
2017-02-10 12:23:32 +01:00
OP_IF
BOLT-3 Edits This is my final first-pass BOLT. Some grammar changes, some remote/local additions, a few questions.
2018-01-16 20:52:38 +01:00
# To local node via HTLC-success transaction.
BOLT 3: instead of ripemd-of-X, use RIPEMD160(X). This is more specific and clearer. Reported-by: Olaoluwa Osuntokun <laolu32@gmail.com> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-05-13 08:37:19 +02:00
OP_HASH160 <RIPEMD160(payment_hash)> OP_EQUALVERIFY
BOLT 2,3,5: always refer to shared/pubkey/private key. Make it clear what kind of key we're talking about. We use the abbreviation pubkey for public key (as it's quite common to use in field names), but generally spell out 'private'. (I generally prefer 'secret' to 'private' but we use private far more often already, and we use 'secret' for things which don't directly derive keys). Fixes: #368 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2018-02-06 01:18:41 +01:00
2 OP_SWAP <local_htlcpubkey> 2 OP_CHECKMULTISIG
BOLT 3: Use revocation key hash rather than revocation key in scripts. This means more bytes if we need to create a penalty tx, but less for normal operation: Witness script for offered htlcs: 139 bytes -> 133 bytes. Witness script for accepted htlcs: 156 bytes -> 139 bytes. It's also a little simpler; it's just an OP_IF around the old scripts to test for the revocation key being the top arg. Suggested-by: Joseph Poon <joseph@lightning.network> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-03-07 00:11:06 +01:00
OP_ELSE
BOLT-3 Edits This is my final first-pass BOLT. Some grammar changes, some remote/local additions, a few questions.
2018-01-16 20:52:38 +01:00
# To remote node after timeout.
BOLT 3: use correct field name for HTLC timeout value. It's called cltv_expiry in BOLT 2's update_add_htlc. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-05-11 08:24:11 +02:00
OP_DROP <cltv_expiry> OP_CHECKLOCKTIMEVERIFY OP_DROP
make htlc outputs of the commitment tx spendable with revocation key (Merge conflict in test vectors fixed by selecting Pierre's, will have to be re-evaluated). Closes: #105
2017-02-10 12:23:32 +01:00
OP_CHECKSIG
OP_ENDIF
Transfer from google doc. Minimal markdown and consistency fixes, more to come. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-11-15 02:23:20 +01:00
OP_ENDIF
feature: define option_zero_htlc_tx_fee (feature 22/23) (#824) This PR adds a new feature bit to define the new and improved anchor outputs commitment format.
2021-08-30 22:50:25 +02:00
Or, with `option_anchors`:
Anchor outputs This commit extends the specification with a new commitment format that adds two anchor outputs to the commitment transaction. Anchor outputs are a safety feature that allows a channel party to unilaterally increase the fee of the commitment transaction using CPFP and ensure timely confirmation on the chain. There is no cooperation required from the remote party.
2020-08-19 12:29:11 +02:00
# To remote node with revocation key
OP_DUP OP_HASH160 <RIPEMD160(SHA256(revocationpubkey))> OP_EQUAL
OP_IF
OP_CHECKSIG
OP_ELSE
<remote_htlcpubkey> OP_SWAP OP_SIZE 32 OP_EQUAL
OP_IF
# To local node via HTLC-success transaction.
OP_HASH160 <RIPEMD160(payment_hash)> OP_EQUALVERIFY
2 OP_SWAP <local_htlcpubkey> 2 OP_CHECKMULTISIG
OP_ELSE
# To remote node after timeout.
OP_DROP <cltv_expiry> OP_CHECKLOCKTIMEVERIFY OP_DROP
OP_CHECKSIG
OP_ENDIF
1 OP_CHECKSEQUENCEVERIFY OP_DROP
OP_ENDIF
fixed typo htlc->HTLC (#262)
2017-10-12 11:40:05 +02:00
To timeout the HTLC, the remote node spends it with the witness:
Transfer from google doc. Minimal markdown and consistency fixes, more to come. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-11-15 02:23:20 +01:00
Make explicit witness must conform to MINIMALIF (#764)
2020-04-27 21:50:57 +02:00
<remotehtlcsig> <>
Transfer from google doc. Minimal markdown and consistency fixes, more to come. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-11-15 02:23:20 +01:00
feature: define option_zero_htlc_tx_fee (feature 22/23) (#824) This PR adds a new feature bit to define the new and improved anchor outputs commitment format.
2021-08-30 22:50:25 +02:00
Note that if `option_anchors` applies, the nSequence field of
Anchor outputs This commit extends the specification with a new commitment format that adds two anchor outputs to the commitment transaction. Anchor outputs are a safety feature that allows a channel party to unilaterally increase the fee of the commitment transaction using CPFP and ensure timely confirmation on the chain. There is no cooperation required from the remote party.
2020-08-19 12:29:11 +02:00
the spending input must be `1`.
make htlc outputs of the commitment tx spendable with revocation key (Merge conflict in test vectors fixed by selecting Pierre's, will have to be re-evaluated). Closes: #105
2017-02-10 12:23:32 +01:00
If a revoked commitment transaction is published, the remote node can spend this output immediately with the following witness:
BOLT 2,3,5: always refer to shared/pubkey/private key. Make it clear what kind of key we're talking about. We use the abbreviation pubkey for public key (as it's quite common to use in field names), but generally spell out 'private'. (I generally prefer 'secret' to 'private' but we use private far more often already, and we use 'secret' for things which don't directly derive keys). Fixes: #368 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2018-02-06 01:18:41 +01:00
<revocation_sig> <revocationpubkey>
make htlc outputs of the commitment tx spendable with revocation key (Merge conflict in test vectors fixed by selecting Pierre's, will have to be re-evaluated). Closes: #105
2017-02-10 12:23:32 +01:00
BOLT 3: Explicit description of implicitly enforced timelocks on HTLC outputs (#601) * Added descriptions of how a 2-of-2 multisignature verification is used for enforcing timelocks when timing out on-chain offered HTLCs as well as spending on-chain received HTLCs in the success case.
2019-08-19 23:52:09 +02:00
To redeem the HTLC, the HTLC-success transaction is used as detailed below. This is the only way that the local node can spend the HTLC, since this branch requires `<remotehtlcsig>`, which ensures that the local node must wait `to_self_delay` before accessing these funds allowing for the remote node to claim these funds if the transaction has been revoked.
Transfer from google doc. Minimal markdown and consistency fixes, more to come. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-11-15 02:23:20 +01:00
BOLT 3: Spell out how to construct the commitment transaction. * I add the term "trimmed outputs" for sub-dust outputs; this matters for both fee calculation and transaction construction. * Introduce the concept of "base fee": this is what needs to be extracted from the funder. * The requirements are spread between the different sections, let's tie it together in a new section at the end. * Spell out all the steps in the example which calculates fees. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-01-23 23:57:40 +01:00
### Trimmed Outputs
BOLT-3 Edits This is my final first-pass BOLT. Some grammar changes, some remote/local additions, a few questions.
2018-01-16 20:52:38 +01:00
Each peer specifies a `dust_limit_satoshis` below which outputs should
not be produced; these outputs that are not produced are termed "trimmed". A trimmed output is
BOLT 3: complete first pass copy-edit according to stylesheet guidelines;
2017-11-21 03:51:25 +01:00
considered too small to be worth creating and is instead added
to the commitment transaction fee. For HTLCs, it needs to be taken into
BOLT 3: Spell out how to construct the commitment transaction. * I add the term "trimmed outputs" for sub-dust outputs; this matters for both fee calculation and transaction construction. * Introduce the concept of "base fee": this is what needs to be extracted from the funder. * The requirements are spread between the different sections, let's tie it together in a new section at the end. * Spell out all the steps in the example which calculates fees. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-01-23 23:57:40 +01:00
account that the second-stage HTLC transaction may also be below the
limit.
#### Requirements
Anchor outputs This commit extends the specification with a new commitment format that adds two anchor outputs to the commitment transaction. Anchor outputs are a safety feature that allows a channel party to unilaterally increase the fee of the commitment transaction using CPFP and ensure timely confirmation on the chain. There is no cooperation required from the remote party.
2020-08-19 12:29:11 +02:00
The base fee and anchor output values:
BOLT 3: complete first pass copy-edit according to stylesheet guidelines;
2017-11-21 03:51:25 +01:00
- before the commitment transaction outputs are determined:
- MUST be subtracted from the `to_local` or `to_remote`
outputs, as specified in [Fee Calculation](#fee-calculation).
The commitment transaction:
- if the amount of the commitment transaction `to_local` output would be
less than `dust_limit_satoshis` set by the transaction owner:
- MUST NOT contain that output.
- otherwise:
transactions: fix broken anchor links Signed-off-by: William Casarin <jb55@jb55.com>
2018-01-15 20:41:52 +01:00
- MUST be generated as specified in [`to_local` Output](#to_local-output).
BOLT 3: complete first pass copy-edit according to stylesheet guidelines;
2017-11-21 03:51:25 +01:00
- if the amount of the commitment transaction `to_remote` output would be
less than `dust_limit_satoshis` set by the transaction owner:
- MUST NOT contain that output.
- otherwise:
transactions: fix broken anchor links Signed-off-by: William Casarin <jb55@jb55.com>
2018-01-15 20:41:52 +01:00
- MUST be generated as specified in [`to_remote` Output](#to_remote-output).
BOLT 3: complete first pass copy-edit according to stylesheet guidelines;
2017-11-21 03:51:25 +01:00
- for every offered HTLC:
- if the HTLC amount minus the HTLC-timeout fee would be less than
`dust_limit_satoshis` set by the transaction owner:
- MUST NOT contain that output.
- otherwise:
- MUST be generated as specified in
[Offered HTLC Outputs](#offered-htlc-outputs).
- for every received HTLC:
- if the HTLC amount minus the HTLC-success fee would be less than
`dust_limit_satoshis` set by the transaction owner:
- MUST NOT contain that output.
- otherwise:
- MUST be generated as specified in
[Received HTLC Outputs](#received-htlc-outputs).
BOLT 3: Spell out how to construct the commitment transaction. * I add the term "trimmed outputs" for sub-dust outputs; this matters for both fee calculation and transaction construction. * Introduce the concept of "base fee": this is what needs to be extracted from the funder. * The requirements are spread between the different sections, let's tie it together in a new section at the end. * Spell out all the steps in the example which calculates fees. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-01-23 23:57:40 +01:00
added a table of contents to bolt3
2016-12-20 16:43:08 +01:00
## HTLC-Timeout and HTLC-Success Transactions
BOLT 1,2,3: first pass copy-edit; BOLT 1,2: minor header spacing fixes BOLT 3: first pass copy edit, according to capitalization, formatting stylesheet guidelines;
2017-11-18 22:04:58 +01:00
Fix ambiguity on HTLC transactions spendable by a penalty one Both HTLC-success/HTLC-timeout can be spent by a valid penalty transaction
2018-11-08 04:16:55 +01:00
These HTLC transactions are almost identical, except the HTLC-timeout transaction is timelocked. Both HTLC-timeout/HTLC-success transactions can be spent by a valid penalty transaction.
Transfer from google doc. Minimal markdown and consistency fixes, more to come. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-11-15 02:23:20 +01:00
* version: 2
BOLT 3: complete first pass copy-edit according to stylesheet guidelines;
2017-11-21 03:51:25 +01:00
* locktime: `0` for HTLC-success, `cltv_expiry` for HTLC-timeout
Transfer from google doc. Minimal markdown and consistency fixes, more to come. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-11-15 02:23:20 +01:00
* txin count: 1
BOLT 3: complete first pass copy-edit according to stylesheet guidelines;
2017-11-21 03:51:25 +01:00
* `txin[0]` outpoint: `txid` of the commitment transaction and `output_index` of the matching HTLC output for the HTLC transaction
feature: define option_zero_htlc_tx_fee (feature 22/23) (#824) This PR adds a new feature bit to define the new and improved anchor outputs commitment format.
2021-08-30 22:50:25 +02:00
* `txin[0]` sequence: `0` (set to `1` for `option_anchors`)
typos and consistency
2016-12-13 15:44:14 +01:00
* `txin[0]` script bytes: `0`
Make explicit witness must conform to MINIMALIF (#764)
2020-04-27 21:50:57 +02:00
* `txin[0]` witness stack: `0 <remotehtlcsig> <localhtlcsig> <payment_preimage>` for HTLC-success, `0 <remotehtlcsig> <localhtlcsig> <>` for HTLC-timeout
Transfer from google doc. Minimal markdown and consistency fixes, more to come. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-11-15 02:23:20 +01:00
* txout count: 1
bolt3: Clarify order of operations for HTLC amount calculation (#1020) The order of operations is now more clearly specified as: HTLC output amount = (`amount_msat` / 1000) - (fees in satoshis) where all divisions are rounded down. This is required to avoid issues in rounding if we were to take HTLC output amount = (`amount_msat` - (`feerate_per_kw` * weight)) / 1000 and then rounded down.
2022-08-30 17:21:41 +02:00
* `txout[0]` amount: the HTLC `amount_msat` divided by 1000 (rounding down) minus fees in satoshis (see [Fee Calculation](#fee-calculation))
BOLT-3 Edits This is my final first-pass BOLT. Some grammar changes, some remote/local additions, a few questions.
2018-01-16 20:52:38 +01:00
* `txout[0]` script: version-0 P2WSH with witness script as shown below
Clarify the sighash types for HTLC Success and Timeout transactions (#954)
2022-01-31 21:05:20 +01:00
* if `option_anchors` applies to this commitment transaction, `SIGHASH_SINGLE|SIGHASH_ANYONECANPAY` is used as described in [BOLT #5](05-onchain.md#generation-of-htlc-transactions).
03-transactions: fix script formatting. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-11-15 03:56:22 +01:00
The witness script for the output is:
Transfer from google doc. Minimal markdown and consistency fixes, more to come. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-11-15 02:23:20 +01:00
OP_IF
# Penalty transaction
BOLT 2,3,5: always refer to shared/pubkey/private key. Make it clear what kind of key we're talking about. We use the abbreviation pubkey for public key (as it's quite common to use in field names), but generally spell out 'private'. (I generally prefer 'secret' to 'private' but we use private far more often already, and we use 'secret' for things which don't directly derive keys). Fixes: #368 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2018-02-06 01:18:41 +01:00
<revocationpubkey>
Transfer from google doc. Minimal markdown and consistency fixes, more to come. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-11-15 02:23:20 +01:00
OP_ELSE
BOLT 3: Replace many hyphens with underscores in descriptions. Not sure how I missed these: 1. funding-pubkey -> funding_pubkey 2. to-self-delay -> to_self_delay 3. per-commitment-point -> per_commitment_point 4. per-commitment-secret -> per_commitment_secret 5. revocation-basepoint -> revocation_basepoint 6. delayed-payment-basepoint -> delayed_payment_basepoint 7. payment-basepoint -> payment_basepoint Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-05-11 08:13:40 +02:00
`to_self_delay`
Change opcode reference format (#594) OP_CHECKLOCKTIMEVERIFY and OP_CSV use an inconsistent naming convention. Update OP_CSV to match the OP_CHECKLOCKTIMEVERIFY convention as OP_CHECKSEQUENCEVERIFY.
2019-07-09 10:40:29 +02:00
OP_CHECKSEQUENCEVERIFY
Transfer from google doc. Minimal markdown and consistency fixes, more to come. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-11-15 02:23:20 +01:00
OP_DROP
BOLT 2,3,5: always refer to shared/pubkey/private key. Make it clear what kind of key we're talking about. We use the abbreviation pubkey for public key (as it's quite common to use in field names), but generally spell out 'private'. (I generally prefer 'secret' to 'private' but we use private far more often already, and we use 'secret' for things which don't directly derive keys). Fixes: #368 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2018-02-06 01:18:41 +01:00
<local_delayedpubkey>
Transfer from google doc. Minimal markdown and consistency fixes, more to come. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-11-15 02:23:20 +01:00
OP_ENDIF
OP_CHECKSIG
BOLT 3: complete first pass copy-edit according to stylesheet guidelines;
2017-11-21 03:51:25 +01:00
To spend this via penalty, the remote node uses a witness stack `<revocationsig> 1`, and to collect the output, the local node uses an input with nSequence `to_self_delay` and a witness stack `<local_delayedsig> 0`.
Transfer from google doc. Minimal markdown and consistency fixes, more to come. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-11-15 02:23:20 +01:00
BOLT 3: define closing transaction. The only surprise here (maybe?) is that we use the commitment number encoding. I think that makes sense, but it was unspecified before. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-07-04 05:58:37 +02:00
## Closing Transaction
Note that there are two possible variants for each node.
BOLT3: the closing transaction now uses version 2 In this commit, we modify the cooperative closing transaction to use version 2. Currently eclair and lnd already use version 2, while c-lightning uses version 1. The commitment transaction already uses version 2, so making this additional transaction (which spends the funding output) also use version 2 would be consistent. Additionally, as a best practice, we should be using the highest currently defined/use transaction version.
2017-12-01 04:28:54 +01:00
* version: 2
BOLT 3: define closing transaction. The only surprise here (maybe?) is that we use the commitment number encoding. I think that makes sense, but it was unspecified before. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-07-04 05:58:37 +02:00
* locktime: 0
* txin count: 1
* `txin[0]` outpoint: `txid` and `output_index` from `funding_created` message
* `txin[0]` sequence: 0xFFFFFFFF
* `txin[0]` script bytes: 0
BOLT 2,3,5: always refer to shared/pubkey/private key. Make it clear what kind of key we're talking about. We use the abbreviation pubkey for public key (as it's quite common to use in field names), but generally spell out 'private'. (I generally prefer 'secret' to 'private' but we use private far more often already, and we use 'secret' for things which don't directly derive keys). Fixes: #368 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2018-02-06 01:18:41 +01:00
* `txin[0]` witness: `0 <signature_for_pubkey1> <signature_for_pubkey2>`
BOLT 3: define closing transaction. The only surprise here (maybe?) is that we use the commitment number encoding. I think that makes sense, but it was unspecified before. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-07-04 05:58:37 +02:00
* txout count: 0, 1 or 2
BOLT 3: complete first pass copy-edit according to stylesheet guidelines;
2017-11-21 03:51:25 +01:00
* `txout` amount: final balance to be paid to one node (minus `fee_satoshis` from `closing_signed`, if this peer funded the channel)
* `txout` script: as specified in that node's `scriptpubkey` in its `shutdown` message
BOLT 3: define closing transaction. The only surprise here (maybe?) is that we use the commitment number encoding. I think that makes sense, but it was unspecified before. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-07-04 05:58:37 +02:00
### Requirements
BOLT 3: complete first pass copy-edit according to stylesheet guidelines;
2017-11-21 03:51:25 +01:00
Each node offering a signature:
BOLT 3: closing tx must also round outputs down to whole satoshis. We specify this for the commitment tx, but not for the closing tx. Reported-by: Christian Decker Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2018-01-29 01:02:04 +01:00
- MUST round each output down to whole satoshis.
BOLT 3: complete first pass copy-edit according to stylesheet guidelines;
2017-11-21 03:51:25 +01:00
- MUST subtract the fee given by `fee_satoshis` from the output to the funder.
- MUST remove any output below its own `dust_limit_satoshis`.
- MAY eliminate its own output.
BOLT 3: define closing transaction. The only surprise here (maybe?) is that we use the commitment number encoding. I think that makes sense, but it was unspecified before. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-07-04 05:58:37 +02:00
### Rationale
There is a possibility of irreparable differences on closing if one
node considers the other's output too small to allow propagation on
BOLT 3: apply a.k.a. abbreviation
2017-12-16 07:36:47 +01:00
the Bitcoin network (a.k.a. "dust"), and that other node instead
BOLT 3: complete first pass copy-edit according to stylesheet guidelines;
2017-11-21 03:51:25 +01:00
considers that output too valuable to discard. This is why each
BOLT 3: define closing transaction. The only surprise here (maybe?) is that we use the commitment number encoding. I think that makes sense, but it was unspecified before. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-07-04 05:58:37 +02:00
side uses its own `dust_limit_satoshis`, and the result can be a
signature validation failure, if they disagree on what the closing
transaction should look like.
However, if one side chooses to eliminate its own output, there's no
BOLT 3: complete first pass copy-edit according to stylesheet guidelines;
2017-11-21 03:51:25 +01:00
reason for the other side to fail the closing protocol; so this is
explicitly allowed. The signature indicates which variant
BOLT 3: define closing transaction. The only surprise here (maybe?) is that we use the commitment number encoding. I think that makes sense, but it was unspecified before. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-07-04 05:58:37 +02:00
has been used.
BOLT 3: fix the rationale of `Closing Transaction`.
2018-12-06 08:53:35 +01:00
There will be at least one output, if the funding amount is greater
than twice `dust_limit_satoshis`.
BOLT 3: define closing transaction. The only surprise here (maybe?) is that we use the commitment number encoding. I think that makes sense, but it was unspecified before. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-07-04 05:58:37 +02:00
added a section about who pays the fee
2017-01-03 18:20:12 +01:00
## Fees
### Fee Calculation
BOLT 02/03: Add fee calculation details. Make the fee amount by kiloweight, not by kilobyte, and spell out how to calculate it. Note that we have to trim HTLCs outputs whose second-stage would also fall below dust limit, and we also make some reasonable approximations on transaction size (which is unknowable before signatures anyway). Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-11-21 04:13:42 +01:00
The fee calculation for both commitment transactions and HTLC
BOLT 4: underscores and backticks everywhere. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-05-11 03:46:04 +02:00
transactions is based on the current `feerate_per_kw` and the
BOLT 02/03: Add fee calculation details. Make the fee amount by kiloweight, not by kilobyte, and spell out how to calculate it. Note that we have to trim HTLCs outputs whose second-stage would also fall below dust limit, and we also make some reasonable approximations on transaction size (which is unknowable before signatures anyway). Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-11-21 04:13:42 +01:00
*expected weight* of the transaction.
BOLT 3: complete first pass copy-edit according to stylesheet guidelines;
2017-11-21 03:51:25 +01:00
The actual and expected weights vary for several reasons:
trivial: Minor markup fixes
2016-12-09 15:25:48 +01:00
BOLT-3 Edits This is my final first-pass BOLT. Some grammar changes, some remote/local additions, a few questions.
2018-01-16 20:52:38 +01:00
* Bitcoin uses DER-encoded signatures, which vary in size.
BOLT 02/03: Add fee calculation details. Make the fee amount by kiloweight, not by kilobyte, and spell out how to calculate it. Note that we have to trim HTLCs outputs whose second-stage would also fall below dust limit, and we also make some reasonable approximations on transaction size (which is unknowable before signatures anyway). Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-11-21 04:13:42 +01:00
* Bitcoin also uses variable-length integers, so a large number of outputs will take 3 bytes to encode rather than 1.
Underscores for all terms, not just fields. Plus a few more missing ones, and some consistency fixes in names as pointed out by Roasbeed and Fabrice. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-05-14 02:32:22 +02:00
* The `to_remote` output may be below the dust limit.
* The `to_local` output may be below the dust limit once fees are extracted.
BOLT 02/03: Add fee calculation details. Make the fee amount by kiloweight, not by kilobyte, and spell out how to calculate it. Note that we have to trim HTLCs outputs whose second-stage would also fall below dust limit, and we also make some reasonable approximations on transaction size (which is unknowable before signatures anyway). Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-11-21 04:13:42 +01:00
BOLT 3: complete first pass copy-edit according to stylesheet guidelines;
2017-11-21 03:51:25 +01:00
Thus, a simplified formula for *expected weight* is used, which assumes:
trivial: Minor markup fixes
2016-12-09 15:25:48 +01:00
BOLT 3: complete first pass copy-edit according to stylesheet guidelines;
2017-11-21 03:51:25 +01:00
* Signatures are 73 bytes long (the maximum length).
* There are a small number of outputs (thus 1 byte to count them).
* There are always both a `to_local` output and a `to_remote` output.
feature: define option_zero_htlc_tx_fee (feature 22/23) (#824) This PR adds a new feature bit to define the new and improved anchor outputs commitment format.
2021-08-30 22:50:25 +02:00
* (if `option_anchors`) there are always both a `to_local_anchor` and `to_remote_anchor` output.
BOLT 02/03: Add fee calculation details. Make the fee amount by kiloweight, not by kilobyte, and spell out how to calculate it. Note that we have to trim HTLCs outputs whose second-stage would also fall below dust limit, and we also make some reasonable approximations on transaction size (which is unknowable before signatures anyway). Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-11-21 04:13:42 +01:00
stylesheet update and apply to BOLT 2,3
2017-12-16 07:27:42 +01:00
This yields the following *expected weights* (details of the computation in [Appendix A](#appendix-a-expected-weights)):
BOLT 3: expand and correct HTLC transaction weights. Inspired by Andrew Shvv's work, this expands the HTLC weight calculation and fixes the gross errors (the witness program itself wasn't counted in the weights!). Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-11-29 21:26:56 +01:00
feature: define option_zero_htlc_tx_fee (feature 22/23) (#824) This PR adds a new feature bit to define the new and improved anchor outputs commitment format.
2021-08-30 22:50:25 +02:00
Commitment weight (no option_anchors): 724 + 172 * num-untrimmed-htlc-outputs
Commitment weight (option_anchors): 1124 + 172 * num-untrimmed-htlc-outputs
HTLC-timeout weight (no option_anchors): 663
HTLC-timeout weight (option_anchors): 666
HTLC-success weight (no option_anchors): 703
HTLC-success weight (option_anchors): 706
BOLT 02/03: Add fee calculation details. Make the fee amount by kiloweight, not by kilobyte, and spell out how to calculate it. Note that we have to trim HTLCs outputs whose second-stage would also fall below dust limit, and we also make some reasonable approximations on transaction size (which is unknowable before signatures anyway). Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-11-21 04:13:42 +01:00
BOLT 3: complete first pass copy-edit according to stylesheet guidelines;
2017-11-21 03:51:25 +01:00
Note the reference to the "base fee" for a commitment transaction in the requirements below, which is what the funder pays. The actual fee may be higher than the amount calculated here, due to rounding and trimmed outputs.
BOLT 3: Spell out how to construct the commitment transaction. * I add the term "trimmed outputs" for sub-dust outputs; this matters for both fee calculation and transaction construction. * Introduce the concept of "base fee": this is what needs to be extracted from the funder. * The requirements are spread between the different sections, let's tie it together in a new section at the end. * Spell out all the steps in the example which calculates fees. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-01-23 23:57:40 +01:00
added a section about who pays the fee
2017-01-03 18:20:12 +01:00
#### Requirements
BOLT 02/03: Add fee calculation details. Make the fee amount by kiloweight, not by kilobyte, and spell out how to calculate it. Note that we have to trim HTLCs outputs whose second-stage would also fall below dust limit, and we also make some reasonable approximations on transaction size (which is unknowable before signatures anyway). Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-11-21 04:13:42 +01:00
BOLT 3: complete first pass copy-edit according to stylesheet guidelines;
2017-11-21 03:51:25 +01:00
The fee for an HTLC-timeout transaction:
feature: define option_zero_htlc_tx_fee (feature 22/23) (#824) This PR adds a new feature bit to define the new and improved anchor outputs commitment format.
2021-08-30 22:50:25 +02:00
- If `option_anchors_zero_fee_htlc_tx` applies:
BOLT 3: add a missing Otherwise, don't SHOULD "be". (#907) Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2021-09-03 08:37:48 +02:00
1. MUST be 0.
- Otherwise, MUST be calculated to match:
Anchor outputs This commit extends the specification with a new commitment format that adds two anchor outputs to the commitment transaction. Anchor outputs are a safety feature that allows a channel party to unilaterally increase the fee of the commitment transaction using CPFP and ensure timely confirmation on the chain. There is no cooperation required from the remote party.
2020-08-19 12:29:11 +02:00
1. Multiply `feerate_per_kw` by 663 (666 if `option_anchor_outputs` applies) and divide by 1000 (rounding down).
BOLT 02/03: Add fee calculation details. Make the fee amount by kiloweight, not by kilobyte, and spell out how to calculate it. Note that we have to trim HTLCs outputs whose second-stage would also fall below dust limit, and we also make some reasonable approximations on transaction size (which is unknowable before signatures anyway). Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-11-21 04:13:42 +01:00
BOLT 3: complete first pass copy-edit according to stylesheet guidelines;
2017-11-21 03:51:25 +01:00
The fee for an HTLC-success transaction:
feature: define option_zero_htlc_tx_fee (feature 22/23) (#824) This PR adds a new feature bit to define the new and improved anchor outputs commitment format.
2021-08-30 22:50:25 +02:00
- If `option_anchors_zero_fee_htlc_tx` applies:
BOLT 3: add a missing Otherwise, don't SHOULD "be". (#907) Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2021-09-03 08:37:48 +02:00
1. MUST be 0.
- Otherwise, MUST be calculated to match:
Anchor outputs This commit extends the specification with a new commitment format that adds two anchor outputs to the commitment transaction. Anchor outputs are a safety feature that allows a channel party to unilaterally increase the fee of the commitment transaction using CPFP and ensure timely confirmation on the chain. There is no cooperation required from the remote party.
2020-08-19 12:29:11 +02:00
1. Multiply `feerate_per_kw` by 703 (706 if `option_anchor_outputs` applies) and divide by 1000 (rounding down).
BOLT 02/03: Add fee calculation details. Make the fee amount by kiloweight, not by kilobyte, and spell out how to calculate it. Note that we have to trim HTLCs outputs whose second-stage would also fall below dust limit, and we also make some reasonable approximations on transaction size (which is unknowable before signatures anyway). Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-11-21 04:13:42 +01:00
BOLT 3: complete first pass copy-edit according to stylesheet guidelines;
2017-11-21 03:51:25 +01:00
The base fee for a commitment transaction:
BOLT 2,3: fix changes requested
2017-11-22 03:31:23 +01:00
- MUST be calculated to match:
feature: define option_zero_htlc_tx_fee (feature 22/23) (#824) This PR adds a new feature bit to define the new and improved anchor outputs commitment format.
2021-08-30 22:50:25 +02:00
1. Start with `weight` = 724 (1124 if `option_anchors` applies).
BOLT 3: complete first pass copy-edit according to stylesheet guidelines;
2017-11-21 03:51:25 +01:00
2. For each committed HTLC, if that output is not trimmed as specified in
[Trimmed Outputs](#trimmed-outputs), add 172 to `weight`.
3. Multiply `feerate_per_kw` by `weight`, divide by 1000 (rounding down).
BOLT 02/03: Add fee calculation details. Make the fee amount by kiloweight, not by kilobyte, and spell out how to calculate it. Note that we have to trim HTLCs outputs whose second-stage would also fall below dust limit, and we also make some reasonable approximations on transaction size (which is unknowable before signatures anyway). Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-11-21 04:13:42 +01:00
added a section about who pays the fee
2017-01-03 18:20:12 +01:00
#### Example
BOLT 02/03: Add fee calculation details. Make the fee amount by kiloweight, not by kilobyte, and spell out how to calculate it. Note that we have to trim HTLCs outputs whose second-stage would also fall below dust limit, and we also make some reasonable approximations on transaction size (which is unknowable before signatures anyway). Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-11-21 04:13:42 +01:00
BOLT 3: complete first pass copy-edit according to stylesheet guidelines;
2017-11-21 03:51:25 +01:00
For example, suppose there is a `feerate_per_kw` of 5000, a `dust_limit_satoshis` of 546 satoshis, and a commitment transaction with:
BOLT 1,2,3: first pass copy-edit; BOLT 1,2: minor header spacing fixes BOLT 3: first pass copy edit, according to capitalization, formatting stylesheet guidelines;
2017-11-18 22:04:58 +01:00
* two offered HTLCs of 5000000 and 1000000 millisatoshis (5000 and 1000 satoshis)
* two received HTLCs of 7000000 and 800000 millisatoshis (7000 and 800 satoshis)
BOLT 3: fix fee computations 1. HTLC must be able to pay for their HTLC success/timeout transaction fees 2. add examples
2016-12-19 17:57:08 +01:00
BOLT 3: complete first pass copy-edit according to stylesheet guidelines;
2017-11-21 03:51:25 +01:00
The HTLC-timeout transaction `weight` is 663, and thus the fee is 3315 satoshis.
The HTLC-success transaction `weight` is 703, and thus the fee is 3515 satoshis
BOLT 3: Spell out how to construct the commitment transaction. * I add the term "trimmed outputs" for sub-dust outputs; this matters for both fee calculation and transaction construction. * Introduce the concept of "base fee": this is what needs to be extracted from the funder. * The requirements are spread between the different sections, let's tie it together in a new section at the end. * Spell out all the steps in the example which calculates fees. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-01-23 23:57:40 +01:00
BOLT 3: complete first pass copy-edit according to stylesheet guidelines;
2017-11-21 03:51:25 +01:00
The commitment transaction `weight` is calculated as follows:
BOLT 3: fix fee computations 1. HTLC must be able to pay for their HTLC success/timeout transaction fees 2. add examples
2016-12-19 17:57:08 +01:00
BOLT 3: complete first pass copy-edit according to stylesheet guidelines;
2017-11-21 03:51:25 +01:00
* `weight` starts at 724.
BOLT 3: fix fee computations 1. HTLC must be able to pay for their HTLC success/timeout transaction fees 2. add examples
2016-12-19 17:57:08 +01:00
BOLT 3: complete first pass copy-edit according to stylesheet guidelines;
2017-11-21 03:51:25 +01:00
* The offered HTLC of 5000 satoshis is above 546 + 3315 and results in:
BOLT 3: Spell out how to construct the commitment transaction. * I add the term "trimmed outputs" for sub-dust outputs; this matters for both fee calculation and transaction construction. * Introduce the concept of "base fee": this is what needs to be extracted from the funder. * The requirements are spread between the different sections, let's tie it together in a new section at the end. * Spell out all the steps in the example which calculates fees. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-01-23 23:57:40 +01:00
* an output of 5000 satoshi in the commitment transaction
fix fee calculation numbers
2018-05-19 11:21:57 +02:00
* an HTLC-timeout transaction of 5000 - 3315 satoshis that spends this output
BOLT 3: complete first pass copy-edit according to stylesheet guidelines;
2017-11-21 03:51:25 +01:00
* `weight` increases to 896
BOLT 3: fix fee computations 1. HTLC must be able to pay for their HTLC success/timeout transaction fees 2. add examples
2016-12-19 17:57:08 +01:00
fix fee calculation numbers
2018-05-19 11:21:57 +02:00
* The offered HTLC of 1000 satoshis is below 546 + 3315 so it is trimmed.
BOLT 3: fix fee computations 1. HTLC must be able to pay for their HTLC success/timeout transaction fees 2. add examples
2016-12-19 17:57:08 +01:00
fix fee calculation numbers
2018-05-19 11:21:57 +02:00
* The received HTLC of 7000 satoshis is above 546 + 3515 and results in:
BOLT 3: Spell out how to construct the commitment transaction. * I add the term "trimmed outputs" for sub-dust outputs; this matters for both fee calculation and transaction construction. * Introduce the concept of "base fee": this is what needs to be extracted from the funder. * The requirements are spread between the different sections, let's tie it together in a new section at the end. * Spell out all the steps in the example which calculates fees. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-01-23 23:57:40 +01:00
* an output of 7000 satoshi in the commitment transaction
fix fee calculation numbers
2018-05-19 11:21:57 +02:00
* an HTLC-success transaction of 7000 - 3515 satoshis that spends this output
BOLT 3: complete first pass copy-edit according to stylesheet guidelines;
2017-11-21 03:51:25 +01:00
* `weight` increases to 1068
BOLT 3: Spell out how to construct the commitment transaction. * I add the term "trimmed outputs" for sub-dust outputs; this matters for both fee calculation and transaction construction. * Introduce the concept of "base fee": this is what needs to be extracted from the funder. * The requirements are spread between the different sections, let's tie it together in a new section at the end. * Spell out all the steps in the example which calculates fees. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-01-23 23:57:40 +01:00
fix fee calculation numbers
2018-05-19 11:21:57 +02:00
* The received HTLC of 800 satoshis is below 546 + 3515 so it is trimmed.
BOLT 3: Spell out how to construct the commitment transaction. * I add the term "trimmed outputs" for sub-dust outputs; this matters for both fee calculation and transaction construction. * Introduce the concept of "base fee": this is what needs to be extracted from the funder. * The requirements are spread between the different sections, let's tie it together in a new section at the end. * Spell out all the steps in the example which calculates fees. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-01-23 23:57:40 +01:00
BOLT 3: complete first pass copy-edit according to stylesheet guidelines;
2017-11-21 03:51:25 +01:00
The base commitment transaction fee is 5340 satoshi; the actual
BOLT-3 Edits This is my final first-pass BOLT. Some grammar changes, some remote/local additions, a few questions.
2018-01-16 20:52:38 +01:00
fee (which adds the 1000 and 800 satoshi HTLCs that would make dust
BOLT 3: complete first pass copy-edit according to stylesheet guidelines;
2017-11-21 03:51:25 +01:00
outputs) is 7140 satoshi. The final fee may be even higher if the
Underscores for all terms, not just fields. Plus a few more missing ones, and some consistency fixes in names as pointed out by Roasbeed and Fabrice. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-05-14 02:32:22 +02:00
`to_local` or `to_remote` outputs fall below `dust_limit_satoshis`.
BOLT 3: fix fee computations 1. HTLC must be able to pay for their HTLC success/timeout transaction fees 2. add examples
2016-12-19 17:57:08 +01:00
added a section about who pays the fee
2017-01-03 18:20:12 +01:00
### Fee Payment
Anchor outputs This commit extends the specification with a new commitment format that adds two anchor outputs to the commitment transaction. Anchor outputs are a safety feature that allows a channel party to unilaterally increase the fee of the commitment transaction using CPFP and ensure timely confirmation on the chain. There is no cooperation required from the remote party.
2020-08-19 12:29:11 +02:00
Base commitment transaction fees and amounts for `to_local_anchor` and `to_remote_anchor` outputs are extracted from the funder's amount;
Restrictions to the commitment tx output for the funder in relation to the
channel reserve apply as described in [BOLT #2](02-peer-protocol.md).
BOLT 3: Spell out how to construct the commitment transaction. * I add the term "trimmed outputs" for sub-dust outputs; this matters for both fee calculation and transaction construction. * Introduce the concept of "base fee": this is what needs to be extracted from the funder. * The requirements are spread between the different sections, let's tie it together in a new section at the end. * Spell out all the steps in the example which calculates fees. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-01-23 23:57:40 +01:00
BOLT-3 Edits This is my final first-pass BOLT. Some grammar changes, some remote/local additions, a few questions.
2018-01-16 20:52:38 +01:00
Note that after the fee amount is subtracted from the to-funder output,
BOLT 3: complete first pass copy-edit according to stylesheet guidelines;
2017-11-21 03:51:25 +01:00
that output may be below `dust_limit_satoshis`, and thus will also
contribute to fees.
added a section about who pays the fee
2017-01-03 18:20:12 +01:00
BOLT 3: complete first pass copy-edit according to stylesheet guidelines;
2017-11-21 03:51:25 +01:00
A node:
- if the resulting fee rate is too low:
Update 03-transactions.md Co-authored-by: Bastien Teinturier <31281497+t-bast@users.noreply.github.com>
2021-12-14 01:02:24 +01:00
- MAY send a `warning` and close the connection, or send an
Make it explicit when to send warnings, errors, fail channel and close connection. And make most places warn or error. Places where we're operating on a channel tend to be "warn and close connection" since we want to forget the mistake they just sent, and closing the connection does that. We now use the same words everywhere: 1. "fail channel" means to go onchain (if necessary). 2. "send `error`" means to send an error message. 3. "send `warning`" means to send a warning message. 4. "close connection" means close the connection. These are all spelled out explicitly, rather than having "fail channel" imply sending an error packet, for example. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2021-12-14 01:02:22 +01:00
`error` and fail the channel.
added a section about who pays the fee
2017-01-03 18:20:12 +01:00
Peers need to check each other's dust limit (#894) Since HTLCs below this amount will not appear in the commitment tx, they are effectively converted to miner fees. The peer could use this to grief you by broadcasting its commitment once it contains a lot of dust HTLCs. Add network dust thresholds computation details, as implemented in Bitcoin Core's default relay policy. Drop non-segwit support in shutdown: this allows dust limit to go as low as 354 sats without creating relay issues with default node policies. We add a requirement that dust limit cannot be lower than 354 sats. This ensures implementers don't have to figure this subtlety on their own. Fixes #696 and #905
2021-10-06 09:40:22 +02:00
## Dust Limits
The `dust_limit_satoshis` parameter is used to configure the threshold below
which nodes will not produce on-chain transaction outputs.
There is no consensus rule in Bitcoin that makes outputs below dust thresholds
invalid or unspendable, but policy rules in popular implementations will prevent
relaying transactions that contain such outputs.
Bitcoin Core defines the following dust thresholds:
- pay to pubkey hash (p2pkh): 546 satoshis
- pay to script hash (p2sh): 540 satoshis
- pay to witness pubkey hash (p2wpkh): 294 satoshis
- pay to witness script hash (p2wsh): 330 satoshis
- unknown segwit versions: 354 satoshis
The rationale of this calculation (implemented [here](https://github.com/bitcoin/bitcoin/blob/0.21/src/policy/policy.cpp))
is explained in the following sections.
In all these sections, the calculations are done with a feerate of 3000 sat/kB
as per Bitcoin Core's implementation.
### Pay to pubkey hash (p2pkh)
A p2pkh output is 34 bytes:
- 8 bytes for the output amount
- 1 byte for the script length
- 25 bytes for the script (`OP_DUP` `OP_HASH160` `20` 20-bytes `OP_EQUALVERIFY` `OP_CHECKSIG`)
A p2pkh input is at least 148 bytes:
- 36 bytes for the previous output (32 bytes hash + 4 bytes index)
- 4 bytes for the sequence
- 1 byte for the script sig length
- 107 bytes for the script sig:
- 1 byte for the items count
- 1 byte for the signature length
- 71 bytes for the signature
- 1 byte for the public key length
- 33 bytes for the public key
The p2pkh dust threshold is then `(34 + 148) * 3000 / 1000 = 546 satoshis`
### Pay to script hash (p2sh)
A p2sh output is 32 bytes:
- 8 bytes for the output amount
- 1 byte for the script length
- 23 bytes for the script (`OP_HASH160` `20` 20-bytes `OP_EQUAL`)
A p2sh input doesn't have a fixed size, since it depends on the underlying
script, so we use 148 bytes as a lower bound.
The p2sh dust threshold is then `(32 + 148) * 3000 / 1000 = 540 satoshis`
### Pay to witness pubkey hash (p2wpkh)
A p2wpkh output is 31 bytes:
- 8 bytes for the output amount
- 1 byte for the script length
- 22 bytes for the script (`OP_0` `20` 20-bytes)
A p2wpkh input is at least 67 bytes (depending on the signature length):
- 36 bytes for the previous output (32 bytes hash + 4 bytes index)
- 4 bytes for the sequence
- 1 byte for the script sig length
- 26 bytes for the witness (rounded down from 26.75, with the 75% segwit discount applied):
- 1 byte for the items count
- 1 byte for the signature length
- 71 bytes for the signature
- 1 byte for the public key length
- 33 bytes for the public key
The p2wpkh dust threshold is then `(31 + 67) * 3000 / 1000 = 294 satoshis`
### Pay to witness script hash (p2wsh)
A p2wsh output is 43 bytes:
- 8 bytes for the output amount
- 1 byte for the script length
- 34 bytes for the script (`OP_0` `32` 32-bytes)
A p2wsh input doesn't have a fixed size, since it depends on the underlying
script, so we use 67 bytes as a lower bound.
The p2wsh dust threshold is then `(43 + 67) * 3000 / 1000 = 330 satoshis`
### Unknown segwit versions
Unknown segwit outputs are at most 51 bytes:
- 8 bytes for the output amount
- 1 byte for the script length
- 42 bytes for the script (`OP_1` through `OP_16` inclusive, followed by a single push of 2 to 40 bytes)
The input doesn't have a fixed size, since it depends on the underlying
script, so we use 67 bytes as a lower bound.
The unknown segwit version dust threshold is then `(51 + 67) * 3000 / 1000 = 354 satoshis`
BOLT 3: Spell out how to construct the commitment transaction. * I add the term "trimmed outputs" for sub-dust outputs; this matters for both fee calculation and transaction construction. * Introduce the concept of "base fee": this is what needs to be extracted from the funder. * The requirements are spread between the different sections, let's tie it together in a new section at the end. * Spell out all the steps in the example which calculates fees. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-01-23 23:57:40 +01:00
## Commitment Transaction Construction
BOLT 3: complete first pass copy-edit according to stylesheet guidelines;
2017-11-21 03:51:25 +01:00
This section ties the previous sections together to detail the
algorithm for constructing the commitment transaction for one peer:
BOLT 4: underscores and backticks everywhere. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-05-11 03:46:04 +02:00
given that peer's `dust_limit_satoshis`, the current `feerate_per_kw`,
BOLT 3: complete first pass copy-edit according to stylesheet guidelines;
2017-11-21 03:51:25 +01:00
the amounts due to each peer (`to_local` and `to_remote`), and all
BOLT 3: Spell out how to construct the commitment transaction. * I add the term "trimmed outputs" for sub-dust outputs; this matters for both fee calculation and transaction construction. * Introduce the concept of "base fee": this is what needs to be extracted from the funder. * The requirements are spread between the different sections, let's tie it together in a new section at the end. * Spell out all the steps in the example which calculates fees. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-01-23 23:57:40 +01:00
committed HTLCs:
BOLT 3: complete first pass copy-edit according to stylesheet guidelines;
2017-11-21 03:51:25 +01:00
1. Initialize the commitment transaction input and locktime, as specified
BOLT 3: minor cleanup. Remove redundant sentence about commitment txin; it's specified exactly 3 lines later. Refer to the Commitment Transaction section in "Commitment Transaction Construction". Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-01-25 06:35:11 +01:00
in [Commitment Transaction](#commitment-transaction).
BOLT 3: Spell out how to construct the commitment transaction. * I add the term "trimmed outputs" for sub-dust outputs; this matters for both fee calculation and transaction construction. * Introduce the concept of "base fee": this is what needs to be extracted from the funder. * The requirements are spread between the different sections, let's tie it together in a new section at the end. * Spell out all the steps in the example which calculates fees. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-01-23 23:57:40 +01:00
1. Calculate which committed HTLCs need to be trimmed (see [Trimmed Outputs](#trimmed-outputs)).
2. Calculate the base [commitment transaction fee](#fee-calculation).
Fixes to existing spec
2019-11-22 10:10:17 +01:00
3. Subtract this base fee from the funder (either `to_local` or `to_remote`).
feature: define option_zero_htlc_tx_fee (feature 22/23) (#824) This PR adds a new feature bit to define the new and improved anchor outputs commitment format.
2021-08-30 22:50:25 +02:00
If `option_anchors` applies to the commitment transaction,
Anchor outputs This commit extends the specification with a new commitment format that adds two anchor outputs to the commitment transaction. Anchor outputs are a safety feature that allows a channel party to unilaterally increase the fee of the commitment transaction using CPFP and ensure timely confirmation on the chain. There is no cooperation required from the remote party.
2020-08-19 12:29:11 +02:00
also subtract two times the fixed anchor size of 330 sats from the funder
(either `to_local` or `to_remote`).
4. For every offered HTLC, if it is not trimmed, add an
BOLT 3: Spell out how to construct the commitment transaction. * I add the term "trimmed outputs" for sub-dust outputs; this matters for both fee calculation and transaction construction. * Introduce the concept of "base fee": this is what needs to be extracted from the funder. * The requirements are spread between the different sections, let's tie it together in a new section at the end. * Spell out all the steps in the example which calculates fees. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-01-23 23:57:40 +01:00
[offered HTLC output](#offered-htlc-outputs).
Anchor outputs This commit extends the specification with a new commitment format that adds two anchor outputs to the commitment transaction. Anchor outputs are a safety feature that allows a channel party to unilaterally increase the fee of the commitment transaction using CPFP and ensure timely confirmation on the chain. There is no cooperation required from the remote party.
2020-08-19 12:29:11 +02:00
5. For every received HTLC, if it is not trimmed, add an
BOLT 3: Spell out how to construct the commitment transaction. * I add the term "trimmed outputs" for sub-dust outputs; this matters for both fee calculation and transaction construction. * Introduce the concept of "base fee": this is what needs to be extracted from the funder. * The requirements are spread between the different sections, let's tie it together in a new section at the end. * Spell out all the steps in the example which calculates fees. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-01-23 23:57:40 +01:00
[received HTLC output](#received-htlc-outputs).
Anchor outputs This commit extends the specification with a new commitment format that adds two anchor outputs to the commitment transaction. Anchor outputs are a safety feature that allows a channel party to unilaterally increase the fee of the commitment transaction using CPFP and ensure timely confirmation on the chain. There is no cooperation required from the remote party.
2020-08-19 12:29:11 +02:00
6. If the `to_local` amount is greater or equal to `dust_limit_satoshis`,
BOLT 3/BOLT 7: Fix broken links.
2018-08-03 05:00:19 +02:00
add a [`to_local` output](#to_local-output).
Anchor outputs This commit extends the specification with a new commitment format that adds two anchor outputs to the commitment transaction. Anchor outputs are a safety feature that allows a channel party to unilaterally increase the fee of the commitment transaction using CPFP and ensure timely confirmation on the chain. There is no cooperation required from the remote party.
2020-08-19 12:29:11 +02:00
7. If the `to_remote` amount is greater or equal to `dust_limit_satoshis`,
BOLT 3/BOLT 7: Fix broken links.
2018-08-03 05:00:19 +02:00
add a [`to_remote` output](#to_remote-output).
feature: define option_zero_htlc_tx_fee (feature 22/23) (#824) This PR adds a new feature bit to define the new and improved anchor outputs commitment format.
2021-08-30 22:50:25 +02:00
8. If `option_anchors` applies to the commitment transaction:
Add links to section 9 (anchor outputs) (#833)
2021-01-27 09:12:41 +01:00
* if `to_local` exists or there are untrimmed HTLCs, add a [`to_local_anchor` output](#to_local_anchor-and-to_remote_anchor-output-option_anchor_outputs)
* if `to_remote` exists or there are untrimmed HTLCs, add a [`to_remote_anchor` output](#to_local_anchor-and-to_remote_anchor-output-option_anchor_outputs)
Bolt 3: fix broken markdown link (#984)
2022-04-22 13:31:59 +02:00
9. Sort the outputs into [BIP 69+CLTV order](#transaction-output-ordering).
BOLT 3: Spell out how to construct the commitment transaction. * I add the term "trimmed outputs" for sub-dust outputs; this matters for both fee calculation and transaction construction. * Introduce the concept of "base fee": this is what needs to be extracted from the funder. * The requirements are spread between the different sections, let's tie it together in a new section at the end. * Spell out all the steps in the example which calculates fees. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-01-23 23:57:40 +01:00
moved weight computation to Appendix section, fixed index
2017-01-03 11:28:37 +01:00
# Keys
## Key Derivation
Transfer from google doc. Minimal markdown and consistency fixes, more to come. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-11-15 02:23:20 +01:00
option_static_remotekey: final draft. This separates out the static remotekey changes from the more ambitious option_simplified_commitment (which also included pushme outputs and bring-your-own-fee for HTLC outputs). As per http://www.erisian.com.au/meetbot/lightning-dev/2019/lightning-dev.2019-09-02-20.06.html Thanks to everyone for feedback: @araspitzu @roasbeef @bitconner Suggested-by: @roasbeef Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2019-08-28 09:21:28 +02:00
Each commitment transaction uses a unique `localpubkey`, and a `remotepubkey`.
BOLT 2,3,5: always refer to shared/pubkey/private key. Make it clear what kind of key we're talking about. We use the abbreviation pubkey for public key (as it's quite common to use in field names), but generally spell out 'private'. (I generally prefer 'secret' to 'private' but we use private far more often already, and we use 'secret' for things which don't directly derive keys). Fixes: #368 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2018-02-06 01:18:41 +01:00
The HTLC-success and HTLC-timeout transactions use `local_delayedpubkey` and `revocationpubkey`.
Anchor outputs This commit extends the specification with a new commitment format that adds two anchor outputs to the commitment transaction. Anchor outputs are a safety feature that allows a channel party to unilaterally increase the fee of the commitment transaction using CPFP and ensure timely confirmation on the chain. There is no cooperation required from the remote party.
2020-08-19 12:29:11 +02:00
These are changed for every transaction based on the `per_commitment_point`.
feature: define option_zero_htlc_tx_fee (feature 22/23) (#824) This PR adds a new feature bit to define the new and improved anchor outputs commitment format.
2021-08-30 22:50:25 +02:00
For `option_static_remotekey` and `option_anchors`, no key rotation
Anchor outputs This commit extends the specification with a new commitment format that adds two anchor outputs to the commitment transaction. Anchor outputs are a safety feature that allows a channel party to unilaterally increase the fee of the commitment transaction using CPFP and ensure timely confirmation on the chain. There is no cooperation required from the remote party.
2020-08-19 12:29:11 +02:00
is applied to `remotepubkey`.
BOLT 2/3: watcher-compatible key derivation. After much discussion with Tadge and Laolu, I think we have something which is nicely outsourcable, and yetnot insanely complex. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-11-17 05:03:22 +01:00
BOLT 3: complete first pass copy-edit according to stylesheet guidelines;
2017-11-21 03:51:25 +01:00
The reason for key change is so that trustless watching for revoked
transactions can be outsourced. Such a _watcher_ should not be able to
determine the contents of a commitment transaction — even if the _watcher_ knows
which transaction ID to watch for and can make a reasonable guess
as to which HTLCs and balances may be included. Nonetheless, to
avoid storage of every commitment transaction, a _watcher_ can be given the
BOLT 3: Replace many hyphens with underscores in descriptions. Not sure how I missed these: 1. funding-pubkey -> funding_pubkey 2. to-self-delay -> to_self_delay 3. per-commitment-point -> per_commitment_point 4. per-commitment-secret -> per_commitment_secret 5. revocation-basepoint -> revocation_basepoint 6. delayed-payment-basepoint -> delayed_payment_basepoint 7. payment-basepoint -> payment_basepoint Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-05-11 08:13:40 +02:00
`per_commitment_secret` values (which can be stored compactly) and the
BOLT 3: complete first pass copy-edit according to stylesheet guidelines;
2017-11-21 03:51:25 +01:00
`revocation_basepoint` and `delayed_payment_basepoint` used to regenerate
the scripts required for the penalty transaction; thus, a _watcher_ need only be
BOLT 2/3: watcher-compatible key derivation. After much discussion with Tadge and Laolu, I think we have something which is nicely outsourcable, and yetnot insanely complex. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-11-17 05:03:22 +01:00
given (and store) the signatures for each penalty input.
option_static_remotekey: final draft. This separates out the static remotekey changes from the more ambitious option_simplified_commitment (which also included pushme outputs and bring-your-own-fee for HTLC outputs). As per http://www.erisian.com.au/meetbot/lightning-dev/2019/lightning-dev.2019-09-02-20.06.html Thanks to everyone for feedback: @araspitzu @roasbeef @bitconner Suggested-by: @roasbeef Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2019-08-28 09:21:28 +02:00
Changing the `localpubkey` every time ensures that commitment
transaction ID cannot be guessed except in the trivial case where there is no
`to_local` output, as every commitment transaction uses an ID
BOLT 2,3,5: always refer to shared/pubkey/private key. Make it clear what kind of key we're talking about. We use the abbreviation pubkey for public key (as it's quite common to use in field names), but generally spell out 'private'. (I generally prefer 'secret' to 'private' but we use private far more often already, and we use 'secret' for things which don't directly derive keys). Fixes: #368 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2018-02-06 01:18:41 +01:00
in its output script. Splitting the `local_delayedpubkey`, which is required for
BOLT 3: complete first pass copy-edit according to stylesheet guidelines;
2017-11-21 03:51:25 +01:00
the penalty transaction, allows it to be shared with the _watcher_ without
BOLT 2,3,5: always refer to shared/pubkey/private key. Make it clear what kind of key we're talking about. We use the abbreviation pubkey for public key (as it's quite common to use in field names), but generally spell out 'private'. (I generally prefer 'secret' to 'private' but we use private far more often already, and we use 'secret' for things which don't directly derive keys). Fixes: #368 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2018-02-06 01:18:41 +01:00
revealing `localpubkey`; even if both peers use the same _watcher_, nothing is revealed.
BOLT 2/3: watcher-compatible key derivation. After much discussion with Tadge and Laolu, I think we have something which is nicely outsourcable, and yetnot insanely complex. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-11-17 05:03:22 +01:00
Finally, even in the case of normal unilateral close, the HTLC-success
and/or HTLC-timeout transactions do not reveal anything to the
BOLT 3: complete first pass copy-edit according to stylesheet guidelines;
2017-11-21 03:51:25 +01:00
_watcher_, as it does not know the corresponding `per_commitment_secret` and
BOLT 2,3,5: always refer to shared/pubkey/private key. Make it clear what kind of key we're talking about. We use the abbreviation pubkey for public key (as it's quite common to use in field names), but generally spell out 'private'. (I generally prefer 'secret' to 'private' but we use private far more often already, and we use 'secret' for things which don't directly derive keys). Fixes: #368 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2018-02-06 01:18:41 +01:00
cannot relate the `local_delayedpubkey` or `revocationpubkey` with their bases.
Transfer from google doc. Minimal markdown and consistency fixes, more to come. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-11-15 02:23:20 +01:00
BOLT 3: complete first pass copy-edit according to stylesheet guidelines;
2017-11-21 03:51:25 +01:00
For efficiency, keys are generated from a series of per-commitment secrets
that are generated from a single seed, which allows the receiver to compactly
store them (see [below](#efficient-per-commitment-secret-storage)).
Transfer from google doc. Minimal markdown and consistency fixes, more to come. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-11-15 02:23:20 +01:00
option_static_remotekey: final draft. This separates out the static remotekey changes from the more ambitious option_simplified_commitment (which also included pushme outputs and bring-your-own-fee for HTLC outputs). As per http://www.erisian.com.au/meetbot/lightning-dev/2019/lightning-dev.2019-09-02-20.06.html Thanks to everyone for feedback: @araspitzu @roasbeef @bitconner Suggested-by: @roasbeef Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2019-08-28 09:21:28 +02:00
### `localpubkey`, `local_htlcpubkey`, `remote_htlcpubkey`, `local_delayedpubkey`, and `remote_delayedpubkey` Derivation
BOLT 2/3: watcher-compatible key derivation. After much discussion with Tadge and Laolu, I think we have something which is nicely outsourcable, and yetnot insanely complex. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-11-17 05:03:22 +01:00
BOLT 2,3,5: always refer to shared/pubkey/private key. Make it clear what kind of key we're talking about. We use the abbreviation pubkey for public key (as it's quite common to use in field names), but generally spell out 'private'. (I generally prefer 'secret' to 'private' but we use private far more often already, and we use 'secret' for things which don't directly derive keys). Fixes: #368 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2018-02-06 01:18:41 +01:00
These pubkeys are simply generated by addition from their base points:
BOLT 2/3: watcher-compatible key derivation. After much discussion with Tadge and Laolu, I think we have something which is nicely outsourcable, and yetnot insanely complex. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-11-17 05:03:22 +01:00
BOLT 3: complete first pass copy-edit according to stylesheet guidelines;
2017-11-21 03:51:25 +01:00
pubkey = basepoint + SHA256(per_commitment_point || basepoint) * G
BOLT 2/3: watcher-compatible key derivation. After much discussion with Tadge and Laolu, I think we have something which is nicely outsourcable, and yetnot insanely complex. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-11-17 05:03:22 +01:00
BOLT 3: add description of `remote_htlcpubkey` in `Key Derivation`.
2018-12-06 13:30:01 +01:00
The `localpubkey` uses the local node's `payment_basepoint`;
Fixes to existing spec
2019-11-22 10:10:17 +01:00
The `remotepubkey` uses the remote node's `payment_basepoint`;
BOLT 3: add description of `remote_htlcpubkey` in `Key Derivation`.
2018-12-06 13:30:01 +01:00
the `local_htlcpubkey` uses the local node's `htlc_basepoint`;
the `remote_htlcpubkey` uses the remote node's `htlc_basepoint`;
the `local_delayedpubkey` uses the local node's `delayed_payment_basepoint`;
and the `remote_delayedpubkey` uses the remote node's `delayed_payment_basepoint`.
BOLT 2/3: watcher-compatible key derivation. After much discussion with Tadge and Laolu, I think we have something which is nicely outsourcable, and yetnot insanely complex. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-11-17 05:03:22 +01:00
BOLT 3: complete first pass copy-edit according to stylesheet guidelines;
2017-11-21 03:51:25 +01:00
The corresponding private keys can be similarly derived, if the basepoint
BOLT 2,3,5: always refer to shared/pubkey/private key. Make it clear what kind of key we're talking about. We use the abbreviation pubkey for public key (as it's quite common to use in field names), but generally spell out 'private'. (I generally prefer 'secret' to 'private' but we use private far more often already, and we use 'secret' for things which don't directly derive keys). Fixes: #368 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2018-02-06 01:18:41 +01:00
secrets are known (i.e. the private keys corresponding to `localpubkey`, `local_htlcpubkey`, and `local_delayedpubkey` only):
Transfer from google doc. Minimal markdown and consistency fixes, more to come. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-11-15 02:23:20 +01:00
BOLT 2,3,5: always refer to shared/pubkey/private key. Make it clear what kind of key we're talking about. We use the abbreviation pubkey for public key (as it's quite common to use in field names), but generally spell out 'private'. (I generally prefer 'secret' to 'private' but we use private far more often already, and we use 'secret' for things which don't directly derive keys). Fixes: #368 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2018-02-06 01:18:41 +01:00
privkey = basepoint_secret + SHA256(per_commitment_point || basepoint)
Transfer from google doc. Minimal markdown and consistency fixes, more to come. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-11-15 02:23:20 +01:00
option_static_remotekey: final draft. This separates out the static remotekey changes from the more ambitious option_simplified_commitment (which also included pushme outputs and bring-your-own-fee for HTLC outputs). As per http://www.erisian.com.au/meetbot/lightning-dev/2019/lightning-dev.2019-09-02-20.06.html Thanks to everyone for feedback: @araspitzu @roasbeef @bitconner Suggested-by: @roasbeef Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2019-08-28 09:21:28 +02:00
### `remotepubkey` Derivation
feature: define option_zero_htlc_tx_fee (feature 22/23) (#824) This PR adds a new feature bit to define the new and improved anchor outputs commitment format.
2021-08-30 22:50:25 +02:00
If `option_static_remotekey` or `option_anchors` is negotiated, the `remotepubkey` is simply the
option_static_remotekey: final draft. This separates out the static remotekey changes from the more ambitious option_simplified_commitment (which also included pushme outputs and bring-your-own-fee for HTLC outputs). As per http://www.erisian.com.au/meetbot/lightning-dev/2019/lightning-dev.2019-09-02-20.06.html Thanks to everyone for feedback: @araspitzu @roasbeef @bitconner Suggested-by: @roasbeef Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2019-08-28 09:21:28 +02:00
remote node's `payment_basepoint`, otherwise it is calculated as above using
the remote node's `payment_basepoint`.
The simplified derivation means that a node can spend a commitment
transaction even if it has lost data and doesn't know the
corresponding `per_commitment_point`. A watchtower could correlate
transactions given to it which only have a `to_remote` output if it
sees one of them onchain, but such transactions do not need any
enforcement and should not be handed to a watchtower.
BOLT 2,3,5: always refer to shared/pubkey/private key. Make it clear what kind of key we're talking about. We use the abbreviation pubkey for public key (as it's quite common to use in field names), but generally spell out 'private'. (I generally prefer 'secret' to 'private' but we use private far more often already, and we use 'secret' for things which don't directly derive keys). Fixes: #368 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2018-02-06 01:18:41 +01:00
### `revocationpubkey` Derivation
Transfer from google doc. Minimal markdown and consistency fixes, more to come. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-11-15 02:23:20 +01:00
BOLT 2,3,5: always refer to shared/pubkey/private key. Make it clear what kind of key we're talking about. We use the abbreviation pubkey for public key (as it's quite common to use in field names), but generally spell out 'private'. (I generally prefer 'secret' to 'private' but we use private far more often already, and we use 'secret' for things which don't directly derive keys). Fixes: #368 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2018-02-06 01:18:41 +01:00
The `revocationpubkey` is a blinded key: when the local node wishes to create a new
BOLT 2,3: fix changes requested
2017-11-22 03:31:23 +01:00
commitment for the remote node, it uses its own `revocation_basepoint` and the remote
BOLT 2,3,5: always refer to shared/pubkey/private key. Make it clear what kind of key we're talking about. We use the abbreviation pubkey for public key (as it's quite common to use in field names), but generally spell out 'private'. (I generally prefer 'secret' to 'private' but we use private far more often already, and we use 'secret' for things which don't directly derive keys). Fixes: #368 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2018-02-06 01:18:41 +01:00
node's `per_commitment_point` to derive a new `revocationpubkey` for the
BOLT-3 Edits This is my final first-pass BOLT. Some grammar changes, some remote/local additions, a few questions.
2018-01-16 20:52:38 +01:00
commitment. After the remote node reveals the
`per_commitment_secret` used (thereby revoking that commitment), the local node
BOLT 2,3,5: always refer to shared/pubkey/private key. Make it clear what kind of key we're talking about. We use the abbreviation pubkey for public key (as it's quite common to use in field names), but generally spell out 'private'. (I generally prefer 'secret' to 'private' but we use private far more often already, and we use 'secret' for things which don't directly derive keys). Fixes: #368 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2018-02-06 01:18:41 +01:00
can then derive the `revocationprivkey`, as it now knows the two secrets
BOLT 3: clarify description of revocation key derivation (#170) This commit attempts to clarify some ambiguity in the way the revocation key derivation was formerly described. Rather than framing the description in terms of local vs remote nodes, we instead frame the description around the _process_ of creating a new commitment transaction for a remote node, [ minor typos and remove weird part-sentence -- RR ]
2017-05-20 02:20:51 +02:00
necessary to derive the key (`revocation_basepoint_secret` and
`per_commitment_secret`).
Transfer from google doc. Minimal markdown and consistency fixes, more to come. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-11-15 02:23:20 +01:00
BOLT-3 Edits This is my final first-pass BOLT. Some grammar changes, some remote/local additions, a few questions.
2018-01-16 20:52:38 +01:00
The `per_commitment_point` is generated using elliptic-curve multiplication:
Transfer from google doc. Minimal markdown and consistency fixes, more to come. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-11-15 02:23:20 +01:00
BOLT 3: Replace many hyphens with underscores in descriptions. Not sure how I missed these: 1. funding-pubkey -> funding_pubkey 2. to-self-delay -> to_self_delay 3. per-commitment-point -> per_commitment_point 4. per-commitment-secret -> per_commitment_secret 5. revocation-basepoint -> revocation_basepoint 6. delayed-payment-basepoint -> delayed_payment_basepoint 7. payment-basepoint -> payment_basepoint Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-05-11 08:13:40 +02:00
per_commitment_point = per_commitment_secret * G
Transfer from google doc. Minimal markdown and consistency fixes, more to come. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-11-15 02:23:20 +01:00
BOLT 2,3,5: always refer to shared/pubkey/private key. Make it clear what kind of key we're talking about. We use the abbreviation pubkey for public key (as it's quite common to use in field names), but generally spell out 'private'. (I generally prefer 'secret' to 'private' but we use private far more often already, and we use 'secret' for things which don't directly derive keys). Fixes: #368 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2018-02-06 01:18:41 +01:00
And this is used to derive the revocation pubkey from the remote node's
BOLT 3: Replace many hyphens with underscores in descriptions. Not sure how I missed these: 1. funding-pubkey -> funding_pubkey 2. to-self-delay -> to_self_delay 3. per-commitment-point -> per_commitment_point 4. per-commitment-secret -> per_commitment_secret 5. revocation-basepoint -> revocation_basepoint 6. delayed-payment-basepoint -> delayed_payment_basepoint 7. payment-basepoint -> payment_basepoint Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-05-11 08:13:40 +02:00
`revocation_basepoint`:
Transfer from google doc. Minimal markdown and consistency fixes, more to come. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-11-15 02:23:20 +01:00
BOLT 2,3,5: always refer to shared/pubkey/private key. Make it clear what kind of key we're talking about. We use the abbreviation pubkey for public key (as it's quite common to use in field names), but generally spell out 'private'. (I generally prefer 'secret' to 'private' but we use private far more often already, and we use 'secret' for things which don't directly derive keys). Fixes: #368 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2018-02-06 01:18:41 +01:00
revocationpubkey = revocation_basepoint * SHA256(revocation_basepoint || per_commitment_point) + per_commitment_point * SHA256(per_commitment_point || revocation_basepoint)
Transfer from google doc. Minimal markdown and consistency fixes, more to come. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-11-15 02:23:20 +01:00
BOLT 2/3: watcher-compatible key derivation. After much discussion with Tadge and Laolu, I think we have something which is nicely outsourcable, and yetnot insanely complex. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-11-17 05:03:22 +01:00
This construction ensures that neither the node providing the
BOLT 3: Replace many hyphens with underscores in descriptions. Not sure how I missed these: 1. funding-pubkey -> funding_pubkey 2. to-self-delay -> to_self_delay 3. per-commitment-point -> per_commitment_point 4. per-commitment-secret -> per_commitment_secret 5. revocation-basepoint -> revocation_basepoint 6. delayed-payment-basepoint -> delayed_payment_basepoint 7. payment-basepoint -> payment_basepoint Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-05-11 08:13:40 +02:00
basepoint nor the node providing the `per_commitment_point` can know the
BOLT 2/3: watcher-compatible key derivation. After much discussion with Tadge and Laolu, I think we have something which is nicely outsourcable, and yetnot insanely complex. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-11-17 05:03:22 +01:00
private key without the other node's secret.
Transfer from google doc. Minimal markdown and consistency fixes, more to come. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-11-15 02:23:20 +01:00
BOLT 3: Replace many hyphens with underscores in descriptions. Not sure how I missed these: 1. funding-pubkey -> funding_pubkey 2. to-self-delay -> to_self_delay 3. per-commitment-point -> per_commitment_point 4. per-commitment-secret -> per_commitment_secret 5. revocation-basepoint -> revocation_basepoint 6. delayed-payment-basepoint -> delayed_payment_basepoint 7. payment-basepoint -> payment_basepoint Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-05-11 08:13:40 +02:00
The corresponding private key can be derived once the `per_commitment_secret`
BOLT 3: Add test vectors for key derivation. (#83) * BOLT 3: Add test vectors for key derivation. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-01-23 21:22:29 +01:00
is known:
BOLT 2,3,5: always refer to shared/pubkey/private key. Make it clear what kind of key we're talking about. We use the abbreviation pubkey for public key (as it's quite common to use in field names), but generally spell out 'private'. (I generally prefer 'secret' to 'private' but we use private far more often already, and we use 'secret' for things which don't directly derive keys). Fixes: #368 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2018-02-06 01:18:41 +01:00
revocationprivkey = revocation_basepoint_secret * SHA256(revocation_basepoint || per_commitment_point) + per_commitment_secret * SHA256(per_commitment_point || revocation_basepoint)
BOLT 3: Add test vectors for key derivation. (#83) * BOLT 3: Add test vectors for key derivation. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-01-23 21:22:29 +01:00
moved weight computation to Appendix section, fixed index
2017-01-03 11:28:37 +01:00
### Per-commitment Secret Requirements
Transfer from google doc. Minimal markdown and consistency fixes, more to come. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-11-15 02:23:20 +01:00
BOLT 3: complete first pass copy-edit according to stylesheet guidelines;
2017-11-21 03:51:25 +01:00
A node:
- MUST select an unguessable 256-bit seed for each connection,
- MUST NOT reveal the seed.
BOLT-3 Edits This is my final first-pass BOLT. Some grammar changes, some remote/local additions, a few questions.
2018-01-16 20:52:38 +01:00
Up to (2^48 - 1) per-commitment secrets can be generated.
BOLT 3: complete first pass copy-edit according to stylesheet guidelines;
2017-11-21 03:51:25 +01:00
The first secret used:
- MUST be index 281474976710655,
- and from there, the index is decremented.
Transfer from google doc. Minimal markdown and consistency fixes, more to come. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-11-15 02:23:20 +01:00
BOLT 3: complete first pass copy-edit according to stylesheet guidelines;
2017-11-21 03:51:25 +01:00
The I'th secret P:
- MUST match the output of this algorithm:
BOLT 3: fix secret gen requirements layout It misrenders on GitHub. Matt had a patch which changed the actual form of the requiremnt, this uses ``` instead. Based-on-Patch-By: Matt Corallo @TheBlueMatt Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-12-21 04:12:24 +01:00
```
generate_from_seed(seed, I):
P = seed
for B in 47 down to 0:
if B set in I:
flip(B) in P
P = SHA256(P)
return P
```
Transfer from google doc. Minimal markdown and consistency fixes, more to come. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-11-15 02:23:20 +01:00
BOLT 3: fix definition of flip(B) in P. (#779) It turns out everyone does `P[B / 8] ^= (1 << (P % 8))`, which is not what the spec says to do (it implies you would treat P as a bitstring numbered 255 to 0). See this stackoverflow question: https://stackoverflow.com/questions/49928131/lightning-secret-generation-from-seed Reported-by: Janus Troelsen @ysangkok (on Twitter) Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2020-07-07 08:58:08 +02:00
Where "flip(B)" alternates the (B mod 8) bit of the (B div 8)
byte of the value. So, "flip(0) in e3b0..." is "e2b0...", and
"flip(10) in "e3b0..." is "e3b4...".
Transfer from google doc. Minimal markdown and consistency fixes, more to come. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-11-15 02:23:20 +01:00
BOLT 3: complete first pass copy-edit according to stylesheet guidelines;
2017-11-21 03:51:25 +01:00
The receiving node:
- MAY store all previous per-commitment secrets.
- MAY calculate them from a compact representation, as described below.
BOLT #3: document how to efficiently derive shachain, fix refs to it. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-11-15 07:00:38 +01:00
added a table of contents to bolt3
2016-12-20 16:43:08 +01:00
## Efficient Per-commitment Secret Storage
BOLT #3: document how to efficiently derive shachain, fix refs to it. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-11-15 07:00:38 +01:00
The receiver of a series of secrets can store them compactly in an
BOLT 3: complete first pass copy-edit according to stylesheet guidelines;
2017-11-21 03:51:25 +01:00
array of 49 (value,index) pairs. Because, for a given secret on a
2^X boundary, all secrets up to the next 2^X boundary can be derived;
and secrets are always received in descending order starting at
trivial: Minor markup fixes
2016-12-09 15:25:48 +01:00
`0xFFFFFFFFFFFF`.
BOLT #3: document how to efficiently derive shachain, fix refs to it. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-11-15 07:00:38 +01:00
In binary, it's helpful to think of any index in terms of a *prefix*,
BOLT 3: complete first pass copy-edit according to stylesheet guidelines;
2017-11-21 03:51:25 +01:00
followed by some trailing 0s. You can derive the secret for any
BOLT-3 Edits This is my final first-pass BOLT. Some grammar changes, some remote/local additions, a few questions.
2018-01-16 20:52:38 +01:00
index that matches this *prefix*.
BOLT #3: document how to efficiently derive shachain, fix refs to it. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-11-15 07:00:38 +01:00
stylesheet update and apply to BOLT 2,3
2017-12-16 07:27:42 +01:00
For example, secret `0xFFFFFFFFFFF0` allows the secrets to be derived for
`0xFFFFFFFFFFF1` through `0xFFFFFFFFFFFF`, inclusive; and secret `0xFFFFFFFFFF08`
BOLT 0, BOLT 3: minor typo fixes. Reported-by: Shannon Appelcline <shannon.appelcline@gmail.com> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-12-21 05:05:49 +01:00
allows the secrets to be derived for `0xFFFFFFFFFF09` through `0xFFFFFFFFFF0F`,
BOLT #3: document how to efficiently derive shachain, fix refs to it. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-11-15 07:00:38 +01:00
inclusive.
BOLT 3: complete first pass copy-edit according to stylesheet guidelines;
2017-11-21 03:51:25 +01:00
This is done using a slight generalization of `generate_from_seed` above:
BOLT #3: document how to efficiently derive shachain, fix refs to it. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-11-15 07:00:38 +01:00
# Return I'th secret given base secret whose index has bits..47 the same.
derive_secret(base, bits, I):
P = base
BOLT 3: complete first pass copy-edit according to stylesheet guidelines;
2017-11-21 03:51:25 +01:00
for B in bits - 1 down to 0:
BOLT #3: document how to efficiently derive shachain, fix refs to it. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-11-15 07:00:38 +01:00
if B set in I:
flip(B) in P
P = SHA256(P)
return P
BOLT 3: complete first pass copy-edit according to stylesheet guidelines;
2017-11-21 03:51:25 +01:00
Only one secret for each unique prefix need be saved; in effect, the number of
trailing 0s is counted, and this determines where in the storage array the
secret is stored:
BOLT #3: document how to efficiently derive shachain, fix refs to it. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-11-15 07:00:38 +01:00
BOLT 3: apply a.k.a. abbreviation
2017-12-16 07:36:47 +01:00
# a.k.a. count trailing 0s
BOLT #3: document how to efficiently derive shachain, fix refs to it. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-11-15 07:00:38 +01:00
where_to_put_secret(I):
BOLT #3: Use space to indent in key derivation algorithms (#665)
2019-09-05 09:44:38 +02:00
for B in 0 to 47:
if testbit(I) in B == 1:
return B
BOLT #3: document how to efficiently derive shachain, fix refs to it. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-11-15 07:00:38 +01:00
# I = 0, this is the seed.
BOLT #3: Use space to indent in key derivation algorithms (#665)
2019-09-05 09:44:38 +02:00
return 48
BOLT #3: document how to efficiently derive shachain, fix refs to it. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-11-15 07:00:38 +01:00
BOLT 3: complete first pass copy-edit according to stylesheet guidelines;
2017-11-21 03:51:25 +01:00
A double-check, that all previous secrets derive correctly, is needed;
if this check fails, the secrets were not generated from the same seed:
BOLT #3: document how to efficiently derive shachain, fix refs to it. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-11-15 07:00:38 +01:00
insert_secret(secret, I):
Fix a typo in `insert_secret` pseudo code (#741) ... to make it consistent with the `where_to_put_secret` above.
2020-02-14 09:45:32 +01:00
B = where_to_put_secret(I)
BOLT #3: document how to efficiently derive shachain, fix refs to it. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-11-15 07:00:38 +01:00
BOLT 3: complete first pass copy-edit according to stylesheet guidelines;
2017-11-21 03:51:25 +01:00
# This tracks the index of the secret in each bucket across the traversal.
BOLT #3: Use space to indent in key derivation algorithms (#665)
2019-09-05 09:44:38 +02:00
for b in 0 to B:
if derive_secret(secret, B, known[b].index) != known[b].secret:
error The secret for I is incorrect
return
BOLT #3: document how to efficiently derive shachain, fix refs to it. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-11-15 07:00:38 +01:00
# Assuming this automatically extends known[] as required.
BOLT #3: Use space to indent in key derivation algorithms (#665)
2019-09-05 09:44:38 +02:00
known[B].index = I
known[B].secret = secret
BOLT #3: document how to efficiently derive shachain, fix refs to it. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-11-15 07:00:38 +01:00
BOLT 3: complete first pass copy-edit according to stylesheet guidelines;
2017-11-21 03:51:25 +01:00
Finally, if an unknown secret at index `I` needs be derived, it must be
discovered which known secret can be used to derive it. The simplest
method is iterating over all the known secrets, and testing if each
can be used to derive the unknown secret:
BOLT #3: document how to efficiently derive shachain, fix refs to it. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-11-15 07:00:38 +01:00
BOLT #3: Use space to indent in key derivation algorithms (#665)
2019-09-05 09:44:38 +02:00
derive_old_secret(I):
for b in 0 to len(secrets):
# Mask off the non-zero prefix of the index.
MASK = ~((1 << b) - 1)
if (I & MASK) == secrets[b].index:
return derive_secret(known, i, I)
error Index 'I' hasn't been received yet.
BOLT #3: document how to efficiently derive shachain, fix refs to it. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-11-15 07:00:38 +01:00
This looks complicated, but remember that the index in entry `b` has
BOLT 3: complete first pass copy-edit according to stylesheet guidelines;
2017-11-21 03:51:25 +01:00
`b` trailing 0s; the mask and compare simply checks if the index
at each bucket is a prefix of the desired index.
Transfer from google doc. Minimal markdown and consistency fixes, more to come. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-11-15 02:23:20 +01:00
BOLT 1,2,3: first pass copy-edit; BOLT 1,2: minor header spacing fixes BOLT 3: first pass copy edit, according to capitalization, formatting stylesheet guidelines;
2017-11-18 22:04:58 +01:00
# Appendix A: Expected Weights
moved weight computation to Appendix section, fixed index
2017-01-03 11:28:37 +01:00
BOLT 1,2,3: first pass copy-edit; BOLT 1,2: minor header spacing fixes BOLT 3: first pass copy edit, according to capitalization, formatting stylesheet guidelines;
2017-11-18 22:04:58 +01:00
## Expected Weight of the Commitment Transaction
moved weight computation to Appendix section, fixed index
2017-01-03 11:28:37 +01:00
The *expected weight* of a commitment transaction is calculated as follows:
p2wsh: 34 bytes
- OP_0: 1 byte
- OP_DATA: 1 byte (witness_script_SHA256 length)
- witness_script_SHA256: 32 bytes
p2wpkh: 22 bytes
- OP_0: 1 byte
- OP_DATA: 1 byte (public_key_HASH160 length)
- public_key_HASH160: 20 bytes
multi_sig: 71 bytes
- OP_2: 1 byte
- OP_DATA: 1 byte (pub_key_alice length)
- pub_key_alice: 33 bytes
- OP_DATA: 1 byte (pub_key_bob length)
- pub_key_bob: 33 bytes
- OP_2: 1 byte
- OP_CHECKMULTISIG: 1 byte
witness: 222 bytes
- number_of_witness_elements: 1 byte
- nil_length: 1 byte
- sig_alice_length: 1 byte
- sig_alice: 73 bytes
- sig_bob_length: 1 byte
- sig_bob: 73 bytes
- witness_script_length: 1 byte
- witness_script (multi_sig)
BOLT 03: Fix appendix numbers and TOC links.
2017-09-22 08:18:18 +02:00
moved weight computation to Appendix section, fixed index
2017-01-03 11:28:37 +01:00
funding_input: 41 bytes
- previous_out_point: 36 bytes
- hash: 32 bytes
- index: 4 bytes
- var_int: 1 byte (script_sig length)
- script_sig: 0 bytes
BOLT 3: complete first pass copy-edit according to stylesheet guidelines;
2017-11-21 03:51:25 +01:00
- witness <---- "witness" is used instead of "script_sig" for
transaction validation; however, "witness" is stored
separately, and the cost for its size is smaller. So,
the calculation of ordinary data is separated
from the witness data.
moved weight computation to Appendix section, fixed index
2017-01-03 11:28:37 +01:00
- sequence: 4 bytes
BOLT-3 Edits This is my final first-pass BOLT. Some grammar changes, some remote/local additions, a few questions.
2018-01-16 20:52:38 +01:00
output_paying_to_local: 43 bytes
moved weight computation to Appendix section, fixed index
2017-01-03 11:28:37 +01:00
- value: 8 bytes
- var_int: 1 byte (pk_script length)
- pk_script (p2wsh): 34 bytes
feature: define option_zero_htlc_tx_fee (feature 22/23) (#824) This PR adds a new feature bit to define the new and improved anchor outputs commitment format.
2021-08-30 22:50:25 +02:00
output_paying_to_remote (no option_anchors): 31 bytes
moved weight computation to Appendix section, fixed index
2017-01-03 11:28:37 +01:00
- value: 8 bytes
- var_int: 1 byte (pk_script length)
- pk_script (p2wpkh): 22 bytes
feature: define option_zero_htlc_tx_fee (feature 22/23) (#824) This PR adds a new feature bit to define the new and improved anchor outputs commitment format.
2021-08-30 22:50:25 +02:00
output_paying_to_remote (option_anchors): 43 bytes
Anchor outputs This commit extends the specification with a new commitment format that adds two anchor outputs to the commitment transaction. Anchor outputs are a safety feature that allows a channel party to unilaterally increase the fee of the commitment transaction using CPFP and ensure timely confirmation on the chain. There is no cooperation required from the remote party.
2020-08-19 12:29:11 +02:00
- value: 8 bytes
- var_int: 1 byte (pk_script length)
- pk_script (p2wsh): 34 bytes
feature: define option_zero_htlc_tx_fee (feature 22/23) (#824) This PR adds a new feature bit to define the new and improved anchor outputs commitment format.
2021-08-30 22:50:25 +02:00
output_anchor (option_anchors): 43 bytes
Anchor outputs This commit extends the specification with a new commitment format that adds two anchor outputs to the commitment transaction. Anchor outputs are a safety feature that allows a channel party to unilaterally increase the fee of the commitment transaction using CPFP and ensure timely confirmation on the chain. There is no cooperation required from the remote party.
2020-08-19 12:29:11 +02:00
- value: 8 bytes
- var_int: 1 byte (pk_script length)
- pk_script (p2wsh): 34 bytes
htlc_output: 43 bytes
moved weight computation to Appendix section, fixed index
2017-01-03 11:28:37 +01:00
- value: 8 bytes
- var_int: 1 byte (pk_script length)
- pk_script (p2wsh): 34 bytes
witness_header: 2 bytes
- flag: 1 byte
- marker: 1 byte
feature: define option_zero_htlc_tx_fee (feature 22/23) (#824) This PR adds a new feature bit to define the new and improved anchor outputs commitment format.
2021-08-30 22:50:25 +02:00
commitment_transaction (no option_anchors): 125 + 43 * num-htlc-outputs bytes
moved weight computation to Appendix section, fixed index
2017-01-03 11:28:37 +01:00
- version: 4 bytes
- witness_header <---- part of the witness data
- count_tx_in: 1 byte
- tx_in: 41 bytes
funding_input
- count_tx_out: 1 byte
- tx_out: 74 + 43 * num-htlc-outputs bytes
BOLT-3 Edits This is my final first-pass BOLT. Some grammar changes, some remote/local additions, a few questions.
2018-01-16 20:52:38 +01:00
output_paying_to_remote,
output_paying_to_local,
moved weight computation to Appendix section, fixed index
2017-01-03 11:28:37 +01:00
....htlc_output's...
- lock_time: 4 bytes
BOLT 1,2,3: first pass copy-edit; BOLT 1,2: minor header spacing fixes BOLT 3: first pass copy edit, according to capitalization, formatting stylesheet guidelines;
2017-11-18 22:04:58 +01:00
feature: define option_zero_htlc_tx_fee (feature 22/23) (#824) This PR adds a new feature bit to define the new and improved anchor outputs commitment format.
2021-08-30 22:50:25 +02:00
commitment_transaction (option_anchors): 225 + 43 * num-htlc-outputs bytes
Anchor outputs This commit extends the specification with a new commitment format that adds two anchor outputs to the commitment transaction. Anchor outputs are a safety feature that allows a channel party to unilaterally increase the fee of the commitment transaction using CPFP and ensure timely confirmation on the chain. There is no cooperation required from the remote party.
2020-08-19 12:29:11 +02:00
- version: 4 bytes
- witness_header <---- part of the witness data
- count_tx_in: 1 byte
- tx_in: 41 bytes
funding_input
- count_tx_out: 3 byte
- tx_out: 172 + 43 * num-htlc-outputs bytes
output_paying_to_remote,
output_paying_to_local,
output_anchor,
output_anchor,
....htlc_output's...
- lock_time: 4 bytes
BOLT 3: complete first pass copy-edit according to stylesheet guidelines;
2017-11-21 03:51:25 +01:00
Multiplying non-witness data by 4 results in a weight of:
BOLT 1,2,3: first pass copy-edit; BOLT 1,2: minor header spacing fixes BOLT 3: first pass copy edit, according to capitalization, formatting stylesheet guidelines;
2017-11-18 22:04:58 +01:00
feature: define option_zero_htlc_tx_fee (feature 22/23) (#824) This PR adds a new feature bit to define the new and improved anchor outputs commitment format.
2021-08-30 22:50:25 +02:00
// 500 + 172 * num-htlc-outputs weight (no option_anchors)
// 900 + 172 * num-htlc-outputs weight (option_anchors)
moved weight computation to Appendix section, fixed index
2017-01-03 11:28:37 +01:00
commitment_transaction_weight = 4 * commitment_transaction
// 224 weight
witness_weight = witness_header + witness
feature: define option_zero_htlc_tx_fee (feature 22/23) (#824) This PR adds a new feature bit to define the new and improved anchor outputs commitment format.
2021-08-30 22:50:25 +02:00
overall_weight (no option_anchors) = 500 + 172 * num-htlc-outputs + 224 weight
overall_weight (option_anchors) = 900 + 172 * num-htlc-outputs + 224 weight
moved weight computation to Appendix section, fixed index
2017-01-03 11:28:37 +01:00
BOLT 3: complete first pass copy-edit according to stylesheet guidelines;
2017-11-21 03:51:25 +01:00
## Expected Weight of HTLC-timeout and HTLC-success Transactions
moved weight computation to Appendix section, fixed index
2017-01-03 11:28:37 +01:00
The *expected weight* of an HTLC transaction is calculated as follows:
feature: define option_zero_htlc_tx_fee (feature 22/23) (#824) This PR adds a new feature bit to define the new and improved anchor outputs commitment format.
2021-08-30 22:50:25 +02:00
accepted_htlc_script: 140 bytes (143 bytes with option_anchors)
BOLT 3,5: update weight calculations for revocation key hash in script. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-03-07 00:58:30 +01:00
- OP_DUP: 1 byte
- OP_HASH160: 1 byte
BOLT 2,3,5: always refer to shared/pubkey/private key. Make it clear what kind of key we're talking about. We use the abbreviation pubkey for public key (as it's quite common to use in field names), but generally spell out 'private'. (I generally prefer 'secret' to 'private' but we use private far more often already, and we use 'secret' for things which don't directly derive keys). Fixes: #368 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2018-02-06 01:18:41 +01:00
- OP_DATA: 1 byte (RIPEMD160(SHA256(revocationpubkey)) length)
- RIPEMD160(SHA256(revocationpubkey)): 20 bytes
make htlc outputs of the commitment tx spendable with revocation key (Merge conflict in test vectors fixed by selecting Pierre's, will have to be re-evaluated). Closes: #105
2017-02-10 12:23:32 +01:00
- OP_EQUAL: 1 byte
- OP_IF: 1 byte
moved weight computation to Appendix section, fixed index
2017-01-03 11:28:37 +01:00
- OP_CHECKSIG: 1 byte
make htlc outputs of the commitment tx spendable with revocation key (Merge conflict in test vectors fixed by selecting Pierre's, will have to be re-evaluated). Closes: #105
2017-02-10 12:23:32 +01:00
- OP_ELSE: 1 byte
BOLT 2,3,5: always refer to shared/pubkey/private key. Make it clear what kind of key we're talking about. We use the abbreviation pubkey for public key (as it's quite common to use in field names), but generally spell out 'private'. (I generally prefer 'secret' to 'private' but we use private far more often already, and we use 'secret' for things which don't directly derive keys). Fixes: #368 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2018-02-06 01:18:41 +01:00
- OP_DATA: 1 byte (remotepubkey length)
- remotepubkey: 33 bytes
make htlc outputs of the commitment tx spendable with revocation key (Merge conflict in test vectors fixed by selecting Pierre's, will have to be re-evaluated). Closes: #105
2017-02-10 12:23:32 +01:00
- OP_SWAP: 1 byte
BOLT 3,5: update weight calculations for revocation key hash in script. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-03-07 00:58:30 +01:00
- OP_SIZE: 1 byte
Specify OP_DATA to express accepted/offered_htlc_script with same convention
2019-01-25 03:37:43 +01:00
- OP_DATA: 1 byte (32 length)
- 32: 1 byte
BOLT 3,5: update weight calculations for revocation key hash in script. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-03-07 00:58:30 +01:00
- OP_EQUAL: 1 byte
- OP_IF: 1 byte
- OP_HASH160: 1 byte
BOLT 3: instead of ripemd-of-X, use RIPEMD160(X). This is more specific and clearer. Reported-by: Olaoluwa Osuntokun <laolu32@gmail.com> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-05-13 08:37:19 +02:00
- OP_DATA: 1 byte (RIPEMD160(payment_hash) length)
- RIPEMD160(payment_hash): 20 bytes
BOLT 3,5: update weight calculations for revocation key hash in script. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-03-07 00:58:30 +01:00
- OP_EQUALVERIFY: 1 byte
make htlc outputs of the commitment tx spendable with revocation key (Merge conflict in test vectors fixed by selecting Pierre's, will have to be re-evaluated). Closes: #105
2017-02-10 12:23:32 +01:00
- 2: 1 byte
- OP_SWAP: 1 byte
BOLT 2,3,5: always refer to shared/pubkey/private key. Make it clear what kind of key we're talking about. We use the abbreviation pubkey for public key (as it's quite common to use in field names), but generally spell out 'private'. (I generally prefer 'secret' to 'private' but we use private far more often already, and we use 'secret' for things which don't directly derive keys). Fixes: #368 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2018-02-06 01:18:41 +01:00
- OP_DATA: 1 byte (localpubkey length)
- localpubkey: 33 bytes
make htlc outputs of the commitment tx spendable with revocation key (Merge conflict in test vectors fixed by selecting Pierre's, will have to be re-evaluated). Closes: #105
2017-02-10 12:23:32 +01:00
- 2: 1 byte
- OP_CHECKMULTISIG: 1 byte
BOLT 3,5: update weight calculations for revocation key hash in script. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-03-07 00:58:30 +01:00
- OP_ELSE: 1 byte
- OP_DROP: 1 byte
BOLT 3: use correct field name for HTLC timeout value. It's called cltv_expiry in BOLT 2's update_add_htlc. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-05-11 08:24:11 +02:00
- OP_DATA: 1 byte (cltv_expiry length)
Correct htlc witness size calculations (#815) * BOLT#3: use 4 bytes for cltv_expiry in accepted_htlc_script * BOLT#3: correct success_witness size * BOLT#3: note HTLC tx weights differ a bit from actual weights
2020-12-07 21:32:29 +01:00
- cltv_expiry: 4 bytes
BOLT 3,5: update weight calculations for revocation key hash in script. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-03-07 00:58:30 +01:00
- OP_CHECKLOCKTIMEVERIFY: 1 byte
- OP_DROP: 1 byte
- OP_CHECKSIG: 1 byte
- OP_ENDIF: 1 byte
feature: define option_zero_htlc_tx_fee (feature 22/23) (#824) This PR adds a new feature bit to define the new and improved anchor outputs commitment format.
2021-08-30 22:50:25 +02:00
- OP_1: 1 byte (option_anchors)
- OP_CHECKSEQUENCEVERIFY: 1 byte (option_anchors)
- OP_DROP: 1 byte (option_anchors)
make htlc outputs of the commitment tx spendable with revocation key (Merge conflict in test vectors fixed by selecting Pierre's, will have to be re-evaluated). Closes: #105
2017-02-10 12:23:32 +01:00
- OP_ENDIF: 1 byte
moved weight computation to Appendix section, fixed index
2017-01-03 11:28:37 +01:00
feature: define option_zero_htlc_tx_fee (feature 22/23) (#824) This PR adds a new feature bit to define the new and improved anchor outputs commitment format.
2021-08-30 22:50:25 +02:00
offered_htlc_script: 133 bytes (136 bytes with option_anchors)
BOLT 3,5: update weight calculations for revocation key hash in script. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-03-07 00:58:30 +01:00
- OP_DUP: 1 byte
- OP_HASH160: 1 byte
BOLT 2,3,5: always refer to shared/pubkey/private key. Make it clear what kind of key we're talking about. We use the abbreviation pubkey for public key (as it's quite common to use in field names), but generally spell out 'private'. (I generally prefer 'secret' to 'private' but we use private far more often already, and we use 'secret' for things which don't directly derive keys). Fixes: #368 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2018-02-06 01:18:41 +01:00
- OP_DATA: 1 byte (RIPEMD160(SHA256(revocationpubkey)) length)
- RIPEMD160(SHA256(revocationpubkey)): 20 bytes
BOLT 3,5: update weight calculations for revocation key hash in script. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-03-07 00:58:30 +01:00
- OP_EQUAL: 1 byte
- OP_IF: 1 byte
- OP_CHECKSIG: 1 byte
- OP_ELSE: 1 byte
BOLT 2,3,5: always refer to shared/pubkey/private key. Make it clear what kind of key we're talking about. We use the abbreviation pubkey for public key (as it's quite common to use in field names), but generally spell out 'private'. (I generally prefer 'secret' to 'private' but we use private far more often already, and we use 'secret' for things which don't directly derive keys). Fixes: #368 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2018-02-06 01:18:41 +01:00
- OP_DATA: 1 byte (remotepubkey length)
- remotepubkey: 33 bytes
moved weight computation to Appendix section, fixed index
2017-01-03 11:28:37 +01:00
- OP_SWAP: 1 byte
- OP_SIZE: 1 byte
fixed htlc weight calculation
2017-02-09 16:33:34 +01:00
- OP_DATA: 1 byte (32 length)
moved weight computation to Appendix section, fixed index
2017-01-03 11:28:37 +01:00
- 32: 1 byte
- OP_EQUAL: 1 byte
- OP_NOTIF: 1 byte
- OP_DROP: 1 byte
- 2: 1 byte
- OP_SWAP: 1 byte
BOLT 2,3,5: always refer to shared/pubkey/private key. Make it clear what kind of key we're talking about. We use the abbreviation pubkey for public key (as it's quite common to use in field names), but generally spell out 'private'. (I generally prefer 'secret' to 'private' but we use private far more often already, and we use 'secret' for things which don't directly derive keys). Fixes: #368 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2018-02-06 01:18:41 +01:00
- OP_DATA: 1 byte (localpubkey length)
- localpubkey: 33 bytes
BOLT 3,5: update weight calculations for revocation key hash in script. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-03-07 00:58:30 +01:00
- 2: 1 byte
moved weight computation to Appendix section, fixed index
2017-01-03 11:28:37 +01:00
- OP_CHECKMULTISIG: 1 byte
- OP_ELSE: 1 byte
- OP_HASH160: 1 byte
BOLT 3: instead of ripemd-of-X, use RIPEMD160(X). This is more specific and clearer. Reported-by: Olaoluwa Osuntokun <laolu32@gmail.com> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-05-13 08:37:19 +02:00
- OP_DATA: 1 byte (RIPEMD160(payment_hash) length)
- RIPEMD160(payment_hash): 20 bytes
moved weight computation to Appendix section, fixed index
2017-01-03 11:28:37 +01:00
- OP_EQUALVERIFY: 1 byte
- OP_CHECKSIG: 1 byte
- OP_ENDIF: 1 byte
feature: define option_zero_htlc_tx_fee (feature 22/23) (#824) This PR adds a new feature bit to define the new and improved anchor outputs commitment format.
2021-08-30 22:50:25 +02:00
- OP_1: 1 byte (option_anchors)
- OP_CHECKSEQUENCEVERIFY: 1 byte (option_anchors)
- OP_DROP: 1 byte (option_anchors)
BOLT 3,5: update weight calculations for revocation key hash in script. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-03-07 00:58:30 +01:00
- OP_ENDIF: 1 byte
moved weight computation to Appendix section, fixed index
2017-01-03 11:28:37 +01:00
feature: define option_zero_htlc_tx_fee (feature 22/23) (#824) This PR adds a new feature bit to define the new and improved anchor outputs commitment format.
2021-08-30 22:50:25 +02:00
timeout_witness: 285 bytes (288 bytes with option_anchors)
moved weight computation to Appendix section, fixed index
2017-01-03 11:28:37 +01:00
- number_of_witness_elements: 1 byte
- nil_length: 1 byte
- sig_alice_length: 1 byte
- sig_alice: 73 bytes
- sig_bob_length: 1 byte
- sig_bob: 73 bytes
- nil_length: 1 byte
- witness_script_length: 1 byte
- witness_script (offered_htlc_script)
feature: define option_zero_htlc_tx_fee (feature 22/23) (#824) This PR adds a new feature bit to define the new and improved anchor outputs commitment format.
2021-08-30 22:50:25 +02:00
success_witness: 324 bytes (327 bytes with option_anchors)
moved weight computation to Appendix section, fixed index
2017-01-03 11:28:37 +01:00
- number_of_witness_elements: 1 byte
- nil_length: 1 byte
- sig_alice_length: 1 byte
- sig_alice: 73 bytes
- sig_bob_length: 1 byte
- sig_bob: 73 bytes
- preimage_length: 1 byte
- preimage: 32 bytes
- witness_script_length: 1 byte
- witness_script (accepted_htlc_script)
commitment_input: 41 bytes
- previous_out_point: 36 bytes
- hash: 32 bytes
- index: 4 bytes
- var_int: 1 byte (script_sig length)
- script_sig: 0 bytes
- witness (success_witness or timeout_witness)
- sequence: 4 bytes
make htlc outputs of the commitment tx spendable with revocation key (Merge conflict in test vectors fixed by selecting Pierre's, will have to be re-evaluated). Closes: #105
2017-02-10 12:23:32 +01:00
htlc_output: 43 bytes
moved weight computation to Appendix section, fixed index
2017-01-03 11:28:37 +01:00
- value: 8 bytes
- var_int: 1 byte (pk_script length)
- pk_script (p2wsh): 34 bytes
BOLT 1,2,3: first pass copy-edit; BOLT 1,2: minor header spacing fixes BOLT 3: first pass copy edit, according to capitalization, formatting stylesheet guidelines;
2017-11-18 22:04:58 +01:00
htlc_transaction:
moved weight computation to Appendix section, fixed index
2017-01-03 11:28:37 +01:00
- version: 4 bytes
- witness_header <---- part of the witness data
- count_tx_in: 1 byte
- tx_in: 41 bytes
commitment_input
- count_tx_out: 1 byte
- tx_out: 43
make htlc outputs of the commitment tx spendable with revocation key (Merge conflict in test vectors fixed by selecting Pierre's, will have to be re-evaluated). Closes: #105
2017-02-10 12:23:32 +01:00
htlc_output
moved weight computation to Appendix section, fixed index
2017-01-03 11:28:37 +01:00
- lock_time: 4 bytes
BOLT 3: complete first pass copy-edit according to stylesheet guidelines;
2017-11-21 03:51:25 +01:00
Multiplying non-witness data by 4 results in a weight of 376. Adding
Correct htlc witness size calculations (#815) * BOLT#3: use 4 bytes for cltv_expiry in accepted_htlc_script * BOLT#3: correct success_witness size * BOLT#3: note HTLC tx weights differ a bit from actual weights
2020-12-07 21:32:29 +01:00
the witness data for each case (285 or 288 + 2 for HTLC-timeout, 324 or 327 + 2 for
BOLT 3: complete first pass copy-edit according to stylesheet guidelines;
2017-11-21 03:51:25 +01:00
HTLC-success) results in weights of:
moved weight computation to Appendix section, fixed index
2017-01-03 11:28:37 +01:00
feature: define option_zero_htlc_tx_fee (feature 22/23) (#824) This PR adds a new feature bit to define the new and improved anchor outputs commitment format.
2021-08-30 22:50:25 +02:00
663 (HTLC-timeout) (666 with option_anchors))
703 (HTLC-success) (706 with option_anchors))
Correct htlc witness size calculations (#815) * BOLT#3: use 4 bytes for cltv_expiry in accepted_htlc_script * BOLT#3: correct success_witness size * BOLT#3: note HTLC tx weights differ a bit from actual weights
2020-12-07 21:32:29 +01:00
- (really 702 and 705, but we use these numbers for historical reasons)
moved weight computation to Appendix section, fixed index
2017-01-03 11:28:37 +01:00
BOLT 03: Fix appendix numbers and TOC links.
2017-09-22 08:18:18 +02:00
# Appendix B: Funding Transaction Test Vectors
bolt3 fix and enhance tx testvectors (#99) This is a smerge of Fabrice Drouin and my work: he update them, I updated them and enhanced them, he found bugs, I re-derived them, etc. - rename keys properly - fix fees - sign all transactions - Derive test transaction vectors from minimal subset of parameters. - rewrite test vectors to test edge cases for trimming. - add funding tx test vector, make testable on regtest. This adds a funding transaction test (really, we only specify the output), but importantly adds enough information to duplicate a blockchain with that particular funding tx: $ rm -rf ~/.bitcoin/regtest/ $ bitcoind -regtest=1 & $ bitcoin-cli -regtest=1 submitblock 0000002006226e46111a0b59caaf126043eb5bbf28c34f3a5e332a1fc7b2b73cf188910fadbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fdc30f9858ffff7f20000000000101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff03510101ffffffff0100f2052a010000001976a9143ca33c2e4446f4a305f23c80df8ad1afdcf652f988ac00000000 $ bitcoin-cli -regtest=1 generate 431 $ bitcoin-cli -regtest=1 sendrawtransaction 0200000001adbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fd000000006b48304502210090587b6201e166ad6af0227d3036a9454223d49a1f11839c1a362184340ef0240220577f7cd5cca78719405cbf1de7414ac027f0239ef6e214c90fcaab0454d84b3b012103535b32d5eb0a6ed0982a0479bbadc9868d9836f6ba94dd5a63be16d875069184ffffffff028096980000000000220020c015c4a6be010e21657068fc2e6a9d02b27ebe4d490a25846f7237f104d1a3cd20256d29010000001600143ca33c2e4446f4a305f23c80df8ad1afdcf652f900000000 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-02-07 01:45:33 +01:00
In the following:
BOLT 1,2,3: apply updated stylesheet guidelines for list capitalization, punctuation
2017-11-24 07:15:16 +01:00
- It's assumed that *local* is the funder.
- Private keys are displayed as 32 bytes plus a trailing 1 (Bitcoin's convention for "compressed" private keys, i.e. keys for which the public key is compressed).
BOLT 3: fix trivial typo.
2018-12-03 05:40:06 +01:00
- Transaction signatures are all deterministic, using RFC6979 (using HMAC-SHA256). A valid signature MUST sign all inputs and outputs of the relevant transaction (i.e. MUST be created with a `SIGHASH_ALL` [signature hash](https://bitcoin.org/en/glossary/signature-hash)), unless explicitly stated otherwise. Note that clients MUST send the signature in compact encoding and not in Bitcoin-script format, thus the signature hash byte is not transmitted.
bolt3 fix and enhance tx testvectors (#99) This is a smerge of Fabrice Drouin and my work: he update them, I updated them and enhanced them, he found bugs, I re-derived them, etc. - rename keys properly - fix fees - sign all transactions - Derive test transaction vectors from minimal subset of parameters. - rewrite test vectors to test edge cases for trimming. - add funding tx test vector, make testable on regtest. This adds a funding transaction test (really, we only specify the output), but importantly adds enough information to duplicate a blockchain with that particular funding tx: $ rm -rf ~/.bitcoin/regtest/ $ bitcoind -regtest=1 & $ bitcoin-cli -regtest=1 submitblock 0000002006226e46111a0b59caaf126043eb5bbf28c34f3a5e332a1fc7b2b73cf188910fadbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fdc30f9858ffff7f20000000000101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff03510101ffffffff0100f2052a010000001976a9143ca33c2e4446f4a305f23c80df8ad1afdcf652f988ac00000000 $ bitcoin-cli -regtest=1 generate 431 $ bitcoin-cli -regtest=1 sendrawtransaction 0200000001adbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fd000000006b48304502210090587b6201e166ad6af0227d3036a9454223d49a1f11839c1a362184340ef0240220577f7cd5cca78719405cbf1de7414ac027f0239ef6e214c90fcaab0454d84b3b012103535b32d5eb0a6ed0982a0479bbadc9868d9836f6ba94dd5a63be16d875069184ffffffff028096980000000000220020c015c4a6be010e21657068fc2e6a9d02b27ebe4d490a25846f7237f104d1a3cd20256d29010000001600143ca33c2e4446f4a305f23c80df8ad1afdcf652f900000000 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-02-07 01:45:33 +01:00
The input for the funding transaction was created using a test chain
BOLT 3: complete first pass copy-edit according to stylesheet guidelines;
2017-11-21 03:51:25 +01:00
with the following first two blocks; the second block contains a spendable
coinbase (note that such a P2PKH input is inadvisable, as detailed in [BOLT #2](02-peer-protocol.md#the-funding_created-message), but provides the simplest example):
bolt3 fix and enhance tx testvectors (#99) This is a smerge of Fabrice Drouin and my work: he update them, I updated them and enhanced them, he found bugs, I re-derived them, etc. - rename keys properly - fix fees - sign all transactions - Derive test transaction vectors from minimal subset of parameters. - rewrite test vectors to test edge cases for trimming. - add funding tx test vector, make testable on regtest. This adds a funding transaction test (really, we only specify the output), but importantly adds enough information to duplicate a blockchain with that particular funding tx: $ rm -rf ~/.bitcoin/regtest/ $ bitcoind -regtest=1 & $ bitcoin-cli -regtest=1 submitblock 0000002006226e46111a0b59caaf126043eb5bbf28c34f3a5e332a1fc7b2b73cf188910fadbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fdc30f9858ffff7f20000000000101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff03510101ffffffff0100f2052a010000001976a9143ca33c2e4446f4a305f23c80df8ad1afdcf652f988ac00000000 $ bitcoin-cli -regtest=1 generate 431 $ bitcoin-cli -regtest=1 sendrawtransaction 0200000001adbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fd000000006b48304502210090587b6201e166ad6af0227d3036a9454223d49a1f11839c1a362184340ef0240220577f7cd5cca78719405cbf1de7414ac027f0239ef6e214c90fcaab0454d84b3b012103535b32d5eb0a6ed0982a0479bbadc9868d9836f6ba94dd5a63be16d875069184ffffffff028096980000000000220020c015c4a6be010e21657068fc2e6a9d02b27ebe4d490a25846f7237f104d1a3cd20256d29010000001600143ca33c2e4446f4a305f23c80df8ad1afdcf652f900000000 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-02-07 01:45:33 +01:00
Block 0 (genesis): 0100000000000000000000000000000000000000000000000000000000000000000000003ba3edfd7a7b12b27ac72c3e67768f617fc81bc3888a51323a9fb8aa4b1e5e4adae5494dffff7f20020000000101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff4d04ffff001d0104455468652054696d65732030332f4a616e2f32303039204368616e63656c6c6f72206f6e206272696e6b206f66207365636f6e64206261696c6f757420666f722062616e6b73ffffffff0100f2052a01000000434104678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5fac00000000
Block 1: 0000002006226e46111a0b59caaf126043eb5bbf28c34f3a5e332a1fc7b2b73cf188910fadbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fdc30f9858ffff7f20000000000101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff03510101ffffffff0100f2052a010000001976a9143ca33c2e4446f4a305f23c80df8ad1afdcf652f988ac00000000
Block 1 coinbase transaction: 01000000010000000000000000000000000000000000000000000000000000000000000000ffffffff03510101ffffffff0100f2052a010000001976a9143ca33c2e4446f4a305f23c80df8ad1afdcf652f988ac00000000
BOLT 03: Remove extra 0x01 byte from private keys in test vectors. An 0x01 byte is appended to the end of private keys in the test vectors to mark them as using compressed serialization to derive the pubkeys. Two of the private keys have two 0x01 bytes appended, presumably by accident.
2017-09-22 08:23:19 +02:00
Block 1 coinbase privkey: 6bd078650fcee8444e4e09825227b801a1ca928debb750eb36e6d56124bb20e801
bolt3 fix and enhance tx testvectors (#99) This is a smerge of Fabrice Drouin and my work: he update them, I updated them and enhanced them, he found bugs, I re-derived them, etc. - rename keys properly - fix fees - sign all transactions - Derive test transaction vectors from minimal subset of parameters. - rewrite test vectors to test edge cases for trimming. - add funding tx test vector, make testable on regtest. This adds a funding transaction test (really, we only specify the output), but importantly adds enough information to duplicate a blockchain with that particular funding tx: $ rm -rf ~/.bitcoin/regtest/ $ bitcoind -regtest=1 & $ bitcoin-cli -regtest=1 submitblock 0000002006226e46111a0b59caaf126043eb5bbf28c34f3a5e332a1fc7b2b73cf188910fadbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fdc30f9858ffff7f20000000000101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff03510101ffffffff0100f2052a010000001976a9143ca33c2e4446f4a305f23c80df8ad1afdcf652f988ac00000000 $ bitcoin-cli -regtest=1 generate 431 $ bitcoin-cli -regtest=1 sendrawtransaction 0200000001adbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fd000000006b48304502210090587b6201e166ad6af0227d3036a9454223d49a1f11839c1a362184340ef0240220577f7cd5cca78719405cbf1de7414ac027f0239ef6e214c90fcaab0454d84b3b012103535b32d5eb0a6ed0982a0479bbadc9868d9836f6ba94dd5a63be16d875069184ffffffff028096980000000000220020c015c4a6be010e21657068fc2e6a9d02b27ebe4d490a25846f7237f104d1a3cd20256d29010000001600143ca33c2e4446f4a305f23c80df8ad1afdcf652f900000000 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-02-07 01:45:33 +01:00
# privkey in base58: cRCH7YNcarfvaiY1GWUKQrRGmoezvfAiqHtdRvxe16shzbd7LDMz
# pubkey in base68: mm3aPLSv9fBrbS68JzurAMp4xGoddJ6pSf
BOLT 2,3,5: always refer to shared/pubkey/private key. Make it clear what kind of key we're talking about. We use the abbreviation pubkey for public key (as it's quite common to use in field names), but generally spell out 'private'. (I generally prefer 'secret' to 'private' but we use private far more often already, and we use 'secret' for things which don't directly derive keys). Fixes: #368 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2018-02-06 01:18:41 +01:00
The funding transaction is paid to the following pubkeys:
bolt3 fix and enhance tx testvectors (#99) This is a smerge of Fabrice Drouin and my work: he update them, I updated them and enhanced them, he found bugs, I re-derived them, etc. - rename keys properly - fix fees - sign all transactions - Derive test transaction vectors from minimal subset of parameters. - rewrite test vectors to test edge cases for trimming. - add funding tx test vector, make testable on regtest. This adds a funding transaction test (really, we only specify the output), but importantly adds enough information to duplicate a blockchain with that particular funding tx: $ rm -rf ~/.bitcoin/regtest/ $ bitcoind -regtest=1 & $ bitcoin-cli -regtest=1 submitblock 0000002006226e46111a0b59caaf126043eb5bbf28c34f3a5e332a1fc7b2b73cf188910fadbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fdc30f9858ffff7f20000000000101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff03510101ffffffff0100f2052a010000001976a9143ca33c2e4446f4a305f23c80df8ad1afdcf652f988ac00000000 $ bitcoin-cli -regtest=1 generate 431 $ bitcoin-cli -regtest=1 sendrawtransaction 0200000001adbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fd000000006b48304502210090587b6201e166ad6af0227d3036a9454223d49a1f11839c1a362184340ef0240220577f7cd5cca78719405cbf1de7414ac027f0239ef6e214c90fcaab0454d84b3b012103535b32d5eb0a6ed0982a0479bbadc9868d9836f6ba94dd5a63be16d875069184ffffffff028096980000000000220020c015c4a6be010e21657068fc2e6a9d02b27ebe4d490a25846f7237f104d1a3cd20256d29010000001600143ca33c2e4446f4a305f23c80df8ad1afdcf652f900000000 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-02-07 01:45:33 +01:00
local_funding_pubkey: 023da092f6980e58d2c037173180e9a465476026ee50f96695963e8efe436f54eb
remote_funding_pubkey: 030e9f7b623d2ccc7c9bd44d66d5ce21ce504c0acf6385a132cec6d3c39fa711c1
# funding witness script = 5221023da092f6980e58d2c037173180e9a465476026ee50f96695963e8efe436f54eb21030e9f7b623d2ccc7c9bd44d66d5ce21ce504c0acf6385a132cec6d3c39fa711c152ae
BOLT 3: complete first pass copy-edit according to stylesheet guidelines;
2017-11-21 03:51:25 +01:00
The funding transaction has a single input and a change output (order
bolt3 fix and enhance tx testvectors (#99) This is a smerge of Fabrice Drouin and my work: he update them, I updated them and enhanced them, he found bugs, I re-derived them, etc. - rename keys properly - fix fees - sign all transactions - Derive test transaction vectors from minimal subset of parameters. - rewrite test vectors to test edge cases for trimming. - add funding tx test vector, make testable on regtest. This adds a funding transaction test (really, we only specify the output), but importantly adds enough information to duplicate a blockchain with that particular funding tx: $ rm -rf ~/.bitcoin/regtest/ $ bitcoind -regtest=1 & $ bitcoin-cli -regtest=1 submitblock 0000002006226e46111a0b59caaf126043eb5bbf28c34f3a5e332a1fc7b2b73cf188910fadbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fdc30f9858ffff7f20000000000101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff03510101ffffffff0100f2052a010000001976a9143ca33c2e4446f4a305f23c80df8ad1afdcf652f988ac00000000 $ bitcoin-cli -regtest=1 generate 431 $ bitcoin-cli -regtest=1 sendrawtransaction 0200000001adbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fd000000006b48304502210090587b6201e166ad6af0227d3036a9454223d49a1f11839c1a362184340ef0240220577f7cd5cca78719405cbf1de7414ac027f0239ef6e214c90fcaab0454d84b3b012103535b32d5eb0a6ed0982a0479bbadc9868d9836f6ba94dd5a63be16d875069184ffffffff028096980000000000220020c015c4a6be010e21657068fc2e6a9d02b27ebe4d490a25846f7237f104d1a3cd20256d29010000001600143ca33c2e4446f4a305f23c80df8ad1afdcf652f900000000 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-02-07 01:45:33 +01:00
determined by BIP69 in this case):
BOLT 03: Correct txid of funding transaction in test vector. The txid has the wrong endianness since Bitcoin reverses the byte order of double-SHA256 hashes.
2017-09-22 08:25:07 +02:00
input txid: fd2105607605d2302994ffea703b09f66b6351816ee737a93e42a841ea20bbad
bolt3 fix and enhance tx testvectors (#99) This is a smerge of Fabrice Drouin and my work: he update them, I updated them and enhanced them, he found bugs, I re-derived them, etc. - rename keys properly - fix fees - sign all transactions - Derive test transaction vectors from minimal subset of parameters. - rewrite test vectors to test edge cases for trimming. - add funding tx test vector, make testable on regtest. This adds a funding transaction test (really, we only specify the output), but importantly adds enough information to duplicate a blockchain with that particular funding tx: $ rm -rf ~/.bitcoin/regtest/ $ bitcoind -regtest=1 & $ bitcoin-cli -regtest=1 submitblock 0000002006226e46111a0b59caaf126043eb5bbf28c34f3a5e332a1fc7b2b73cf188910fadbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fdc30f9858ffff7f20000000000101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff03510101ffffffff0100f2052a010000001976a9143ca33c2e4446f4a305f23c80df8ad1afdcf652f988ac00000000 $ bitcoin-cli -regtest=1 generate 431 $ bitcoin-cli -regtest=1 sendrawtransaction 0200000001adbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fd000000006b48304502210090587b6201e166ad6af0227d3036a9454223d49a1f11839c1a362184340ef0240220577f7cd5cca78719405cbf1de7414ac027f0239ef6e214c90fcaab0454d84b3b012103535b32d5eb0a6ed0982a0479bbadc9868d9836f6ba94dd5a63be16d875069184ffffffff028096980000000000220020c015c4a6be010e21657068fc2e6a9d02b27ebe4d490a25846f7237f104d1a3cd20256d29010000001600143ca33c2e4446f4a305f23c80df8ad1afdcf652f900000000 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-02-07 01:45:33 +01:00
input index: 0
input satoshis: 5000000000
funding satoshis: 10000000
# funding witness script = 5221023da092f6980e58d2c037173180e9a465476026ee50f96695963e8efe436f54eb21030e9f7b623d2ccc7c9bd44d66d5ce21ce504c0acf6385a132cec6d3c39fa711c152ae
# feerate_per_kw: 15000
change satoshis: 4989986080
funding output: 0
The resulting funding transaction is:
funding tx: 0200000001adbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fd000000006b48304502210090587b6201e166ad6af0227d3036a9454223d49a1f11839c1a362184340ef0240220577f7cd5cca78719405cbf1de7414ac027f0239ef6e214c90fcaab0454d84b3b012103535b32d5eb0a6ed0982a0479bbadc9868d9836f6ba94dd5a63be16d875069184ffffffff028096980000000000220020c015c4a6be010e21657068fc2e6a9d02b27ebe4d490a25846f7237f104d1a3cd20256d29010000001600143ca33c2e4446f4a305f23c80df8ad1afdcf652f900000000
# txid: 8984484a580b825b9972d7adb15050b3ab624ccd731946b3eeddb92f4e7ef6be
# Appendix C: Commitment and HTLC Transaction Test Vectors
added test vectors for transactions
2017-01-03 18:21:10 +01:00
In the following:
BOLT 3: complete first pass copy-edit according to stylesheet guidelines;
2017-11-21 03:51:25 +01:00
- *local* transactions are considered, which implies that all payments to *local* are delayed.
BOLT 1,2,3: apply updated stylesheet guidelines for list capitalization, punctuation
2017-11-24 07:15:16 +01:00
- It's assumed that *local* is the funder.
- Private keys are displayed as 32 bytes plus a trailing 1 (Bitcoin's convention for "compressed" private keys, i.e. keys for which the public key is compressed).
- Transaction signatures are all deterministic, using RFC6979 (using HMAC-SHA256).
bolt3 fix and enhance tx testvectors (#99) This is a smerge of Fabrice Drouin and my work: he update them, I updated them and enhanced them, he found bugs, I re-derived them, etc. - rename keys properly - fix fees - sign all transactions - Derive test transaction vectors from minimal subset of parameters. - rewrite test vectors to test edge cases for trimming. - add funding tx test vector, make testable on regtest. This adds a funding transaction test (really, we only specify the output), but importantly adds enough information to duplicate a blockchain with that particular funding tx: $ rm -rf ~/.bitcoin/regtest/ $ bitcoind -regtest=1 & $ bitcoin-cli -regtest=1 submitblock 0000002006226e46111a0b59caaf126043eb5bbf28c34f3a5e332a1fc7b2b73cf188910fadbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fdc30f9858ffff7f20000000000101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff03510101ffffffff0100f2052a010000001976a9143ca33c2e4446f4a305f23c80df8ad1afdcf652f988ac00000000 $ bitcoin-cli -regtest=1 generate 431 $ bitcoin-cli -regtest=1 sendrawtransaction 0200000001adbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fd000000006b48304502210090587b6201e166ad6af0227d3036a9454223d49a1f11839c1a362184340ef0240220577f7cd5cca78719405cbf1de7414ac027f0239ef6e214c90fcaab0454d84b3b012103535b32d5eb0a6ed0982a0479bbadc9868d9836f6ba94dd5a63be16d875069184ffffffff028096980000000000220020c015c4a6be010e21657068fc2e6a9d02b27ebe4d490a25846f7237f104d1a3cd20256d29010000001600143ca33c2e4446f4a305f23c80df8ad1afdcf652f900000000 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-02-07 01:45:33 +01:00
BOLT 3: complete first pass copy-edit according to stylesheet guidelines;
2017-11-21 03:51:25 +01:00
To start, common basic parameters for each test vector are defined: the
BOLT 3: add test vectors for htlc-transactions in case where CLTV is used as tie-breaker for sorting (#539) Add a serialized transactions test vector for the edge case of sorting htlc-timeout-tx when there are multiple offered htlc with the same amount and preimage. The test vector reuses previous preimages and creates a case scenario with 1 received htlc and 2 offered, the two offered will have same scriptPubKey and redeemScript, but different CLTV value. It is asserted the order in which the htlc transactions should be kept internally and we assume the same order is used to construct the commitment_signed message. This complements #491 .
2021-03-05 09:10:26 +01:00
HTLCs are not used for the first "simple commitment tx with no HTLCs" test,
and HTLCs 5 and 6 are only used in the "same amount and preimage" test.
added test vectors for transactions
2017-01-03 18:21:10 +01:00
bolt3 fix and enhance tx testvectors (#99) This is a smerge of Fabrice Drouin and my work: he update them, I updated them and enhanced them, he found bugs, I re-derived them, etc. - rename keys properly - fix fees - sign all transactions - Derive test transaction vectors from minimal subset of parameters. - rewrite test vectors to test edge cases for trimming. - add funding tx test vector, make testable on regtest. This adds a funding transaction test (really, we only specify the output), but importantly adds enough information to duplicate a blockchain with that particular funding tx: $ rm -rf ~/.bitcoin/regtest/ $ bitcoind -regtest=1 & $ bitcoin-cli -regtest=1 submitblock 0000002006226e46111a0b59caaf126043eb5bbf28c34f3a5e332a1fc7b2b73cf188910fadbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fdc30f9858ffff7f20000000000101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff03510101ffffffff0100f2052a010000001976a9143ca33c2e4446f4a305f23c80df8ad1afdcf652f988ac00000000 $ bitcoin-cli -regtest=1 generate 431 $ bitcoin-cli -regtest=1 sendrawtransaction 0200000001adbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fd000000006b48304502210090587b6201e166ad6af0227d3036a9454223d49a1f11839c1a362184340ef0240220577f7cd5cca78719405cbf1de7414ac027f0239ef6e214c90fcaab0454d84b3b012103535b32d5eb0a6ed0982a0479bbadc9868d9836f6ba94dd5a63be16d875069184ffffffff028096980000000000220020c015c4a6be010e21657068fc2e6a9d02b27ebe4d490a25846f7237f104d1a3cd20256d29010000001600143ca33c2e4446f4a305f23c80df8ad1afdcf652f900000000 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-02-07 01:45:33 +01:00
funding_tx_id: 8984484a580b825b9972d7adb15050b3ab624ccd731946b3eeddb92f4e7ef6be
funding_output_index: 0
added test vectors for transactions
2017-01-03 18:21:10 +01:00
funding_amount_satoshi: 10000000
bolt3 fix and enhance tx testvectors (#99) This is a smerge of Fabrice Drouin and my work: he update them, I updated them and enhanced them, he found bugs, I re-derived them, etc. - rename keys properly - fix fees - sign all transactions - Derive test transaction vectors from minimal subset of parameters. - rewrite test vectors to test edge cases for trimming. - add funding tx test vector, make testable on regtest. This adds a funding transaction test (really, we only specify the output), but importantly adds enough information to duplicate a blockchain with that particular funding tx: $ rm -rf ~/.bitcoin/regtest/ $ bitcoind -regtest=1 & $ bitcoin-cli -regtest=1 submitblock 0000002006226e46111a0b59caaf126043eb5bbf28c34f3a5e332a1fc7b2b73cf188910fadbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fdc30f9858ffff7f20000000000101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff03510101ffffffff0100f2052a010000001976a9143ca33c2e4446f4a305f23c80df8ad1afdcf652f988ac00000000 $ bitcoin-cli -regtest=1 generate 431 $ bitcoin-cli -regtest=1 sendrawtransaction 0200000001adbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fd000000006b48304502210090587b6201e166ad6af0227d3036a9454223d49a1f11839c1a362184340ef0240220577f7cd5cca78719405cbf1de7414ac027f0239ef6e214c90fcaab0454d84b3b012103535b32d5eb0a6ed0982a0479bbadc9868d9836f6ba94dd5a63be16d875069184ffffffff028096980000000000220020c015c4a6be010e21657068fc2e6a9d02b27ebe4d490a25846f7237f104d1a3cd20256d29010000001600143ca33c2e4446f4a305f23c80df8ad1afdcf652f900000000 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-02-07 01:45:33 +01:00
commitment_number: 42
added test vectors for transactions
2017-01-03 18:21:10 +01:00
local_delay: 144
local_dust_limit_satoshi: 546
htlc 0 direction: remote->local
bolt3 fix and enhance tx testvectors (#99) This is a smerge of Fabrice Drouin and my work: he update them, I updated them and enhanced them, he found bugs, I re-derived them, etc. - rename keys properly - fix fees - sign all transactions - Derive test transaction vectors from minimal subset of parameters. - rewrite test vectors to test edge cases for trimming. - add funding tx test vector, make testable on regtest. This adds a funding transaction test (really, we only specify the output), but importantly adds enough information to duplicate a blockchain with that particular funding tx: $ rm -rf ~/.bitcoin/regtest/ $ bitcoind -regtest=1 & $ bitcoin-cli -regtest=1 submitblock 0000002006226e46111a0b59caaf126043eb5bbf28c34f3a5e332a1fc7b2b73cf188910fadbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fdc30f9858ffff7f20000000000101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff03510101ffffffff0100f2052a010000001976a9143ca33c2e4446f4a305f23c80df8ad1afdcf652f988ac00000000 $ bitcoin-cli -regtest=1 generate 431 $ bitcoin-cli -regtest=1 sendrawtransaction 0200000001adbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fd000000006b48304502210090587b6201e166ad6af0227d3036a9454223d49a1f11839c1a362184340ef0240220577f7cd5cca78719405cbf1de7414ac027f0239ef6e214c90fcaab0454d84b3b012103535b32d5eb0a6ed0982a0479bbadc9868d9836f6ba94dd5a63be16d875069184ffffffff028096980000000000220020c015c4a6be010e21657068fc2e6a9d02b27ebe4d490a25846f7237f104d1a3cd20256d29010000001600143ca33c2e4446f4a305f23c80df8ad1afdcf652f900000000 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-02-07 01:45:33 +01:00
htlc 0 amount_msat: 1000000
htlc 0 expiry: 500
htlc 0 payment_preimage: 0000000000000000000000000000000000000000000000000000000000000000
added test vectors for transactions
2017-01-03 18:21:10 +01:00
htlc 1 direction: remote->local
bolt3 fix and enhance tx testvectors (#99) This is a smerge of Fabrice Drouin and my work: he update them, I updated them and enhanced them, he found bugs, I re-derived them, etc. - rename keys properly - fix fees - sign all transactions - Derive test transaction vectors from minimal subset of parameters. - rewrite test vectors to test edge cases for trimming. - add funding tx test vector, make testable on regtest. This adds a funding transaction test (really, we only specify the output), but importantly adds enough information to duplicate a blockchain with that particular funding tx: $ rm -rf ~/.bitcoin/regtest/ $ bitcoind -regtest=1 & $ bitcoin-cli -regtest=1 submitblock 0000002006226e46111a0b59caaf126043eb5bbf28c34f3a5e332a1fc7b2b73cf188910fadbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fdc30f9858ffff7f20000000000101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff03510101ffffffff0100f2052a010000001976a9143ca33c2e4446f4a305f23c80df8ad1afdcf652f988ac00000000 $ bitcoin-cli -regtest=1 generate 431 $ bitcoin-cli -regtest=1 sendrawtransaction 0200000001adbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fd000000006b48304502210090587b6201e166ad6af0227d3036a9454223d49a1f11839c1a362184340ef0240220577f7cd5cca78719405cbf1de7414ac027f0239ef6e214c90fcaab0454d84b3b012103535b32d5eb0a6ed0982a0479bbadc9868d9836f6ba94dd5a63be16d875069184ffffffff028096980000000000220020c015c4a6be010e21657068fc2e6a9d02b27ebe4d490a25846f7237f104d1a3cd20256d29010000001600143ca33c2e4446f4a305f23c80df8ad1afdcf652f900000000 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-02-07 01:45:33 +01:00
htlc 1 amount_msat: 2000000
htlc 1 expiry: 501
htlc 1 payment_preimage: 0101010101010101010101010101010101010101010101010101010101010101
added test vectors for transactions
2017-01-03 18:21:10 +01:00
htlc 2 direction: local->remote
bolt3 fix and enhance tx testvectors (#99) This is a smerge of Fabrice Drouin and my work: he update them, I updated them and enhanced them, he found bugs, I re-derived them, etc. - rename keys properly - fix fees - sign all transactions - Derive test transaction vectors from minimal subset of parameters. - rewrite test vectors to test edge cases for trimming. - add funding tx test vector, make testable on regtest. This adds a funding transaction test (really, we only specify the output), but importantly adds enough information to duplicate a blockchain with that particular funding tx: $ rm -rf ~/.bitcoin/regtest/ $ bitcoind -regtest=1 & $ bitcoin-cli -regtest=1 submitblock 0000002006226e46111a0b59caaf126043eb5bbf28c34f3a5e332a1fc7b2b73cf188910fadbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fdc30f9858ffff7f20000000000101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff03510101ffffffff0100f2052a010000001976a9143ca33c2e4446f4a305f23c80df8ad1afdcf652f988ac00000000 $ bitcoin-cli -regtest=1 generate 431 $ bitcoin-cli -regtest=1 sendrawtransaction 0200000001adbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fd000000006b48304502210090587b6201e166ad6af0227d3036a9454223d49a1f11839c1a362184340ef0240220577f7cd5cca78719405cbf1de7414ac027f0239ef6e214c90fcaab0454d84b3b012103535b32d5eb0a6ed0982a0479bbadc9868d9836f6ba94dd5a63be16d875069184ffffffff028096980000000000220020c015c4a6be010e21657068fc2e6a9d02b27ebe4d490a25846f7237f104d1a3cd20256d29010000001600143ca33c2e4446f4a305f23c80df8ad1afdcf652f900000000 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-02-07 01:45:33 +01:00
htlc 2 amount_msat: 2000000
htlc 2 expiry: 502
htlc 2 payment_preimage: 0202020202020202020202020202020202020202020202020202020202020202
added test vectors for transactions
2017-01-03 18:21:10 +01:00
htlc 3 direction: local->remote
bolt3 fix and enhance tx testvectors (#99) This is a smerge of Fabrice Drouin and my work: he update them, I updated them and enhanced them, he found bugs, I re-derived them, etc. - rename keys properly - fix fees - sign all transactions - Derive test transaction vectors from minimal subset of parameters. - rewrite test vectors to test edge cases for trimming. - add funding tx test vector, make testable on regtest. This adds a funding transaction test (really, we only specify the output), but importantly adds enough information to duplicate a blockchain with that particular funding tx: $ rm -rf ~/.bitcoin/regtest/ $ bitcoind -regtest=1 & $ bitcoin-cli -regtest=1 submitblock 0000002006226e46111a0b59caaf126043eb5bbf28c34f3a5e332a1fc7b2b73cf188910fadbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fdc30f9858ffff7f20000000000101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff03510101ffffffff0100f2052a010000001976a9143ca33c2e4446f4a305f23c80df8ad1afdcf652f988ac00000000 $ bitcoin-cli -regtest=1 generate 431 $ bitcoin-cli -regtest=1 sendrawtransaction 0200000001adbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fd000000006b48304502210090587b6201e166ad6af0227d3036a9454223d49a1f11839c1a362184340ef0240220577f7cd5cca78719405cbf1de7414ac027f0239ef6e214c90fcaab0454d84b3b012103535b32d5eb0a6ed0982a0479bbadc9868d9836f6ba94dd5a63be16d875069184ffffffff028096980000000000220020c015c4a6be010e21657068fc2e6a9d02b27ebe4d490a25846f7237f104d1a3cd20256d29010000001600143ca33c2e4446f4a305f23c80df8ad1afdcf652f900000000 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-02-07 01:45:33 +01:00
htlc 3 amount_msat: 3000000
htlc 3 expiry: 503
htlc 3 payment_preimage: 0303030303030303030303030303030303030303030303030303030303030303
added test vectors for transactions
2017-01-03 18:21:10 +01:00
htlc 4 direction: remote->local
bolt3 fix and enhance tx testvectors (#99) This is a smerge of Fabrice Drouin and my work: he update them, I updated them and enhanced them, he found bugs, I re-derived them, etc. - rename keys properly - fix fees - sign all transactions - Derive test transaction vectors from minimal subset of parameters. - rewrite test vectors to test edge cases for trimming. - add funding tx test vector, make testable on regtest. This adds a funding transaction test (really, we only specify the output), but importantly adds enough information to duplicate a blockchain with that particular funding tx: $ rm -rf ~/.bitcoin/regtest/ $ bitcoind -regtest=1 & $ bitcoin-cli -regtest=1 submitblock 0000002006226e46111a0b59caaf126043eb5bbf28c34f3a5e332a1fc7b2b73cf188910fadbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fdc30f9858ffff7f20000000000101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff03510101ffffffff0100f2052a010000001976a9143ca33c2e4446f4a305f23c80df8ad1afdcf652f988ac00000000 $ bitcoin-cli -regtest=1 generate 431 $ bitcoin-cli -regtest=1 sendrawtransaction 0200000001adbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fd000000006b48304502210090587b6201e166ad6af0227d3036a9454223d49a1f11839c1a362184340ef0240220577f7cd5cca78719405cbf1de7414ac027f0239ef6e214c90fcaab0454d84b3b012103535b32d5eb0a6ed0982a0479bbadc9868d9836f6ba94dd5a63be16d875069184ffffffff028096980000000000220020c015c4a6be010e21657068fc2e6a9d02b27ebe4d490a25846f7237f104d1a3cd20256d29010000001600143ca33c2e4446f4a305f23c80df8ad1afdcf652f900000000 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-02-07 01:45:33 +01:00
htlc 4 amount_msat: 4000000
htlc 4 expiry: 504
htlc 4 payment_preimage: 0404040404040404040404040404040404040404040404040404040404040404
BOLT 3: add test vectors for htlc-transactions in case where CLTV is used as tie-breaker for sorting (#539) Add a serialized transactions test vector for the edge case of sorting htlc-timeout-tx when there are multiple offered htlc with the same amount and preimage. The test vector reuses previous preimages and creates a case scenario with 1 received htlc and 2 offered, the two offered will have same scriptPubKey and redeemScript, but different CLTV value. It is asserted the order in which the htlc transactions should be kept internally and we assume the same order is used to construct the commitment_signed message. This complements #491 .
2021-03-05 09:10:26 +01:00
htlc 5 direction: local->remote
htlc 5 amount_msat: 5000000
BOLT-03: update test vectors w/ updated HTLC tie-breaker case
2021-05-24 21:51:54 +02:00
htlc 5 expiry: 506
BOLT 3: add test vectors for htlc-transactions in case where CLTV is used as tie-breaker for sorting (#539) Add a serialized transactions test vector for the edge case of sorting htlc-timeout-tx when there are multiple offered htlc with the same amount and preimage. The test vector reuses previous preimages and creates a case scenario with 1 received htlc and 2 offered, the two offered will have same scriptPubKey and redeemScript, but different CLTV value. It is asserted the order in which the htlc transactions should be kept internally and we assume the same order is used to construct the commitment_signed message. This complements #491 .
2021-03-05 09:10:26 +01:00
htlc 5 payment_preimage: 0505050505050505050505050505050505050505050505050505050505050505
htlc 6 direction: local->remote
BOLT-03: update test vectors w/ updated HTLC tie-breaker case
2021-05-24 21:51:54 +02:00
htlc 6 amount_msat: 5000001
htlc 6 expiry: 505
BOLT 3: add test vectors for htlc-transactions in case where CLTV is used as tie-breaker for sorting (#539) Add a serialized transactions test vector for the edge case of sorting htlc-timeout-tx when there are multiple offered htlc with the same amount and preimage. The test vector reuses previous preimages and creates a case scenario with 1 received htlc and 2 offered, the two offered will have same scriptPubKey and redeemScript, but different CLTV value. It is asserted the order in which the htlc transactions should be kept internally and we assume the same order is used to construct the commitment_signed message. This complements #491 .
2021-03-05 09:10:26 +01:00
htlc 6 payment_preimage: 0505050505050505050505050505050505050505050505050505050505050505
bolt3 fix and enhance tx testvectors (#99) This is a smerge of Fabrice Drouin and my work: he update them, I updated them and enhanced them, he found bugs, I re-derived them, etc. - rename keys properly - fix fees - sign all transactions - Derive test transaction vectors from minimal subset of parameters. - rewrite test vectors to test edge cases for trimming. - add funding tx test vector, make testable on regtest. This adds a funding transaction test (really, we only specify the output), but importantly adds enough information to duplicate a blockchain with that particular funding tx: $ rm -rf ~/.bitcoin/regtest/ $ bitcoind -regtest=1 & $ bitcoin-cli -regtest=1 submitblock 0000002006226e46111a0b59caaf126043eb5bbf28c34f3a5e332a1fc7b2b73cf188910fadbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fdc30f9858ffff7f20000000000101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff03510101ffffffff0100f2052a010000001976a9143ca33c2e4446f4a305f23c80df8ad1afdcf652f988ac00000000 $ bitcoin-cli -regtest=1 generate 431 $ bitcoin-cli -regtest=1 sendrawtransaction 0200000001adbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fd000000006b48304502210090587b6201e166ad6af0227d3036a9454223d49a1f11839c1a362184340ef0240220577f7cd5cca78719405cbf1de7414ac027f0239ef6e214c90fcaab0454d84b3b012103535b32d5eb0a6ed0982a0479bbadc9868d9836f6ba94dd5a63be16d875069184ffffffff028096980000000000220020c015c4a6be010e21657068fc2e6a9d02b27ebe4d490a25846f7237f104d1a3cd20256d29010000001600143ca33c2e4446f4a305f23c80df8ad1afdcf652f900000000 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-02-07 01:45:33 +01:00
BOLT 3: complete first pass copy-edit according to stylesheet guidelines;
2017-11-21 03:51:25 +01:00
<!-- The test vector values are derived, as per Key Derivation, though it's not
BOLT 1,2,3: first pass copy-edit; BOLT 1,2: minor header spacing fixes BOLT 3: first pass copy edit, according to capitalization, formatting stylesheet guidelines;
2017-11-18 22:04:58 +01:00
required for this test. They're included here for completeness and
bolt3 fix and enhance tx testvectors (#99) This is a smerge of Fabrice Drouin and my work: he update them, I updated them and enhanced them, he found bugs, I re-derived them, etc. - rename keys properly - fix fees - sign all transactions - Derive test transaction vectors from minimal subset of parameters. - rewrite test vectors to test edge cases for trimming. - add funding tx test vector, make testable on regtest. This adds a funding transaction test (really, we only specify the output), but importantly adds enough information to duplicate a blockchain with that particular funding tx: $ rm -rf ~/.bitcoin/regtest/ $ bitcoind -regtest=1 & $ bitcoin-cli -regtest=1 submitblock 0000002006226e46111a0b59caaf126043eb5bbf28c34f3a5e332a1fc7b2b73cf188910fadbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fdc30f9858ffff7f20000000000101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff03510101ffffffff0100f2052a010000001976a9143ca33c2e4446f4a305f23c80df8ad1afdcf652f988ac00000000 $ bitcoin-cli -regtest=1 generate 431 $ bitcoin-cli -regtest=1 sendrawtransaction 0200000001adbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fd000000006b48304502210090587b6201e166ad6af0227d3036a9454223d49a1f11839c1a362184340ef0240220577f7cd5cca78719405cbf1de7414ac027f0239ef6e214c90fcaab0454d84b3b012103535b32d5eb0a6ed0982a0479bbadc9868d9836f6ba94dd5a63be16d875069184ffffffff028096980000000000220020c015c4a6be010e21657068fc2e6a9d02b27ebe4d490a25846f7237f104d1a3cd20256d29010000001600143ca33c2e4446f4a305f23c80df8ad1afdcf652f900000000 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-02-07 01:45:33 +01:00
in case someone wants to reproduce the test vectors themselves:
BOLT 3: fix private key in internal part
2018-10-31 06:03:53 +01:00
INTERNAL: remote_funding_privkey: 1552dfba4f6cf29a62a0af13c8d6981d36d0ef8d61ba10fb0fe90da7634d7e1301
bolt3 fix and enhance tx testvectors (#99) This is a smerge of Fabrice Drouin and my work: he update them, I updated them and enhanced them, he found bugs, I re-derived them, etc. - rename keys properly - fix fees - sign all transactions - Derive test transaction vectors from minimal subset of parameters. - rewrite test vectors to test edge cases for trimming. - add funding tx test vector, make testable on regtest. This adds a funding transaction test (really, we only specify the output), but importantly adds enough information to duplicate a blockchain with that particular funding tx: $ rm -rf ~/.bitcoin/regtest/ $ bitcoind -regtest=1 & $ bitcoin-cli -regtest=1 submitblock 0000002006226e46111a0b59caaf126043eb5bbf28c34f3a5e332a1fc7b2b73cf188910fadbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fdc30f9858ffff7f20000000000101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff03510101ffffffff0100f2052a010000001976a9143ca33c2e4446f4a305f23c80df8ad1afdcf652f988ac00000000 $ bitcoin-cli -regtest=1 generate 431 $ bitcoin-cli -regtest=1 sendrawtransaction 0200000001adbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fd000000006b48304502210090587b6201e166ad6af0227d3036a9454223d49a1f11839c1a362184340ef0240220577f7cd5cca78719405cbf1de7414ac027f0239ef6e214c90fcaab0454d84b3b012103535b32d5eb0a6ed0982a0479bbadc9868d9836f6ba94dd5a63be16d875069184ffffffff028096980000000000220020c015c4a6be010e21657068fc2e6a9d02b27ebe4d490a25846f7237f104d1a3cd20256d29010000001600143ca33c2e4446f4a305f23c80df8ad1afdcf652f900000000 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-02-07 01:45:33 +01:00
INTERNAL: local_payment_basepoint_secret: 111111111111111111111111111111111111111111111111111111111111111101
BOLT 3: fix labels on test vectors. As per ElementsProject/lightning#134 Fabrice points out that to calculate our own commitment tx, we use the *other* side's revocation basepoint: The revocationkey is a blinded key: the remote node provides the base, and the local node provides the blinding factor which it later reveals Thus, we fix the test vectors by renaming "local_revocation_basepoint" to "remote_revocation_basepoint", which is what we should be using. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-03-24 02:43:38 +01:00
INTERNAL: remote_revocation_basepoint_secret: 222222222222222222222222222222222222222222222222222222222222222201
bolt3 fix and enhance tx testvectors (#99) This is a smerge of Fabrice Drouin and my work: he update them, I updated them and enhanced them, he found bugs, I re-derived them, etc. - rename keys properly - fix fees - sign all transactions - Derive test transaction vectors from minimal subset of parameters. - rewrite test vectors to test edge cases for trimming. - add funding tx test vector, make testable on regtest. This adds a funding transaction test (really, we only specify the output), but importantly adds enough information to duplicate a blockchain with that particular funding tx: $ rm -rf ~/.bitcoin/regtest/ $ bitcoind -regtest=1 & $ bitcoin-cli -regtest=1 submitblock 0000002006226e46111a0b59caaf126043eb5bbf28c34f3a5e332a1fc7b2b73cf188910fadbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fdc30f9858ffff7f20000000000101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff03510101ffffffff0100f2052a010000001976a9143ca33c2e4446f4a305f23c80df8ad1afdcf652f988ac00000000 $ bitcoin-cli -regtest=1 generate 431 $ bitcoin-cli -regtest=1 sendrawtransaction 0200000001adbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fd000000006b48304502210090587b6201e166ad6af0227d3036a9454223d49a1f11839c1a362184340ef0240220577f7cd5cca78719405cbf1de7414ac027f0239ef6e214c90fcaab0454d84b3b012103535b32d5eb0a6ed0982a0479bbadc9868d9836f6ba94dd5a63be16d875069184ffffffff028096980000000000220020c015c4a6be010e21657068fc2e6a9d02b27ebe4d490a25846f7237f104d1a3cd20256d29010000001600143ca33c2e4446f4a305f23c80df8ad1afdcf652f900000000 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-02-07 01:45:33 +01:00
INTERNAL: local_delayed_payment_basepoint_secret: 333333333333333333333333333333333333333333333333333333333333333301
INTERNAL: remote_payment_basepoint_secret: 444444444444444444444444444444444444444444444444444444444444444401
x_local_per_commitment_secret: 1f1e1d1c1b1a191817161514131211100f0e0d0c0b0a0908070605040302010001
BOLT 3: fix labels on test vectors. As per ElementsProject/lightning#134 Fabrice points out that to calculate our own commitment tx, we use the *other* side's revocation basepoint: The revocationkey is a blinded key: the remote node provides the base, and the local node provides the blinding factor which it later reveals Thus, we fix the test vectors by renaming "local_revocation_basepoint" to "remote_revocation_basepoint", which is what we should be using. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-03-24 02:43:38 +01:00
# From remote_revocation_basepoint_secret
INTERNAL: remote_revocation_basepoint: 02466d7fcae563e5cb09a0d1870bb580344804617879a14949cf22285f1bae3f27
bolt3 fix and enhance tx testvectors (#99) This is a smerge of Fabrice Drouin and my work: he update them, I updated them and enhanced them, he found bugs, I re-derived them, etc. - rename keys properly - fix fees - sign all transactions - Derive test transaction vectors from minimal subset of parameters. - rewrite test vectors to test edge cases for trimming. - add funding tx test vector, make testable on regtest. This adds a funding transaction test (really, we only specify the output), but importantly adds enough information to duplicate a blockchain with that particular funding tx: $ rm -rf ~/.bitcoin/regtest/ $ bitcoind -regtest=1 & $ bitcoin-cli -regtest=1 submitblock 0000002006226e46111a0b59caaf126043eb5bbf28c34f3a5e332a1fc7b2b73cf188910fadbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fdc30f9858ffff7f20000000000101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff03510101ffffffff0100f2052a010000001976a9143ca33c2e4446f4a305f23c80df8ad1afdcf652f988ac00000000 $ bitcoin-cli -regtest=1 generate 431 $ bitcoin-cli -regtest=1 sendrawtransaction 0200000001adbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fd000000006b48304502210090587b6201e166ad6af0227d3036a9454223d49a1f11839c1a362184340ef0240220577f7cd5cca78719405cbf1de7414ac027f0239ef6e214c90fcaab0454d84b3b012103535b32d5eb0a6ed0982a0479bbadc9868d9836f6ba94dd5a63be16d875069184ffffffff028096980000000000220020c015c4a6be010e21657068fc2e6a9d02b27ebe4d490a25846f7237f104d1a3cd20256d29010000001600143ca33c2e4446f4a305f23c80df8ad1afdcf652f900000000 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-02-07 01:45:33 +01:00
# From local_delayed_payment_basepoint_secret
INTERNAL: local_delayed_payment_basepoint: 023c72addb4fdf09af94f0c94d7fe92a386a7e70cf8a1d85916386bb2535c7b1b1
INTERNAL: local_per_commitment_point: 025f7117a78150fe2ef97db7cfc83bd57b2e2c0d0dd25eaf467a4a1c2a45ce1486
BOLT 2,3,5: always refer to shared/pubkey/private key. Make it clear what kind of key we're talking about. We use the abbreviation pubkey for public key (as it's quite common to use in field names), but generally spell out 'private'. (I generally prefer 'secret' to 'private' but we use private far more often already, and we use 'secret' for things which don't directly derive keys). Fixes: #368 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2018-02-06 01:18:41 +01:00
INTERNAL: remote_privkey: 8deba327a7cc6d638ab0eb025770400a6184afcba6713c210d8d10e199ff2fda01
bolt3 fix and enhance tx testvectors (#99) This is a smerge of Fabrice Drouin and my work: he update them, I updated them and enhanced them, he found bugs, I re-derived them, etc. - rename keys properly - fix fees - sign all transactions - Derive test transaction vectors from minimal subset of parameters. - rewrite test vectors to test edge cases for trimming. - add funding tx test vector, make testable on regtest. This adds a funding transaction test (really, we only specify the output), but importantly adds enough information to duplicate a blockchain with that particular funding tx: $ rm -rf ~/.bitcoin/regtest/ $ bitcoind -regtest=1 & $ bitcoin-cli -regtest=1 submitblock 0000002006226e46111a0b59caaf126043eb5bbf28c34f3a5e332a1fc7b2b73cf188910fadbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fdc30f9858ffff7f20000000000101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff03510101ffffffff0100f2052a010000001976a9143ca33c2e4446f4a305f23c80df8ad1afdcf652f988ac00000000 $ bitcoin-cli -regtest=1 generate 431 $ bitcoin-cli -regtest=1 sendrawtransaction 0200000001adbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fd000000006b48304502210090587b6201e166ad6af0227d3036a9454223d49a1f11839c1a362184340ef0240220577f7cd5cca78719405cbf1de7414ac027f0239ef6e214c90fcaab0454d84b3b012103535b32d5eb0a6ed0982a0479bbadc9868d9836f6ba94dd5a63be16d875069184ffffffff028096980000000000220020c015c4a6be010e21657068fc2e6a9d02b27ebe4d490a25846f7237f104d1a3cd20256d29010000001600143ca33c2e4446f4a305f23c80df8ad1afdcf652f900000000 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-02-07 01:45:33 +01:00
# From local_delayed_payment_basepoint_secret, local_per_commitment_point and local_delayed_payment_basepoint
BOLT 2,3,5: always refer to shared/pubkey/private key. Make it clear what kind of key we're talking about. We use the abbreviation pubkey for public key (as it's quite common to use in field names), but generally spell out 'private'. (I generally prefer 'secret' to 'private' but we use private far more often already, and we use 'secret' for things which don't directly derive keys). Fixes: #368 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2018-02-06 01:18:41 +01:00
INTERNAL: local_delayed_privkey: adf3464ce9c2f230fd2582fda4c6965e4993ca5524e8c9580e3df0cf226981ad01
bolt3 fix and enhance tx testvectors (#99) This is a smerge of Fabrice Drouin and my work: he update them, I updated them and enhanced them, he found bugs, I re-derived them, etc. - rename keys properly - fix fees - sign all transactions - Derive test transaction vectors from minimal subset of parameters. - rewrite test vectors to test edge cases for trimming. - add funding tx test vector, make testable on regtest. This adds a funding transaction test (really, we only specify the output), but importantly adds enough information to duplicate a blockchain with that particular funding tx: $ rm -rf ~/.bitcoin/regtest/ $ bitcoind -regtest=1 & $ bitcoin-cli -regtest=1 submitblock 0000002006226e46111a0b59caaf126043eb5bbf28c34f3a5e332a1fc7b2b73cf188910fadbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fdc30f9858ffff7f20000000000101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff03510101ffffffff0100f2052a010000001976a9143ca33c2e4446f4a305f23c80df8ad1afdcf652f988ac00000000 $ bitcoin-cli -regtest=1 generate 431 $ bitcoin-cli -regtest=1 sendrawtransaction 0200000001adbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fd000000006b48304502210090587b6201e166ad6af0227d3036a9454223d49a1f11839c1a362184340ef0240220577f7cd5cca78719405cbf1de7414ac027f0239ef6e214c90fcaab0454d84b3b012103535b32d5eb0a6ed0982a0479bbadc9868d9836f6ba94dd5a63be16d875069184ffffffff028096980000000000220020c015c4a6be010e21657068fc2e6a9d02b27ebe4d490a25846f7237f104d1a3cd20256d29010000001600143ca33c2e4446f4a305f23c80df8ad1afdcf652f900000000 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-02-07 01:45:33 +01:00
-->
Here are the points used to derive the obscuring factor for the commitment number:
local_payment_basepoint: 034f355bdcb7cc0af728ef3cceb9615d90684bb5b2ca5f859ab0f0b704075871aa
remote_payment_basepoint: 032c0b7cf95324a07d05398b240174dc0c2be444d96b159aa6c7f7b1e668680991
BOLT 3: `commitment number` not `commitment transaction number`. Be consistent.
2018-11-14 12:20:42 +01:00
# obscured commitment number = 0x2bb038521914 ^ 42
bolt3 fix and enhance tx testvectors (#99) This is a smerge of Fabrice Drouin and my work: he update them, I updated them and enhanced them, he found bugs, I re-derived them, etc. - rename keys properly - fix fees - sign all transactions - Derive test transaction vectors from minimal subset of parameters. - rewrite test vectors to test edge cases for trimming. - add funding tx test vector, make testable on regtest. This adds a funding transaction test (really, we only specify the output), but importantly adds enough information to duplicate a blockchain with that particular funding tx: $ rm -rf ~/.bitcoin/regtest/ $ bitcoind -regtest=1 & $ bitcoin-cli -regtest=1 submitblock 0000002006226e46111a0b59caaf126043eb5bbf28c34f3a5e332a1fc7b2b73cf188910fadbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fdc30f9858ffff7f20000000000101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff03510101ffffffff0100f2052a010000001976a9143ca33c2e4446f4a305f23c80df8ad1afdcf652f988ac00000000 $ bitcoin-cli -regtest=1 generate 431 $ bitcoin-cli -regtest=1 sendrawtransaction 0200000001adbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fd000000006b48304502210090587b6201e166ad6af0227d3036a9454223d49a1f11839c1a362184340ef0240220577f7cd5cca78719405cbf1de7414ac027f0239ef6e214c90fcaab0454d84b3b012103535b32d5eb0a6ed0982a0479bbadc9868d9836f6ba94dd5a63be16d875069184ffffffff028096980000000000220020c015c4a6be010e21657068fc2e6a9d02b27ebe4d490a25846f7237f104d1a3cd20256d29010000001600143ca33c2e4446f4a305f23c80df8ad1afdcf652f900000000 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-02-07 01:45:33 +01:00
BOLT 3: complete first pass copy-edit according to stylesheet guidelines;
2017-11-21 03:51:25 +01:00
And, here are the keys needed to create the transactions:
bolt3 fix and enhance tx testvectors (#99) This is a smerge of Fabrice Drouin and my work: he update them, I updated them and enhanced them, he found bugs, I re-derived them, etc. - rename keys properly - fix fees - sign all transactions - Derive test transaction vectors from minimal subset of parameters. - rewrite test vectors to test edge cases for trimming. - add funding tx test vector, make testable on regtest. This adds a funding transaction test (really, we only specify the output), but importantly adds enough information to duplicate a blockchain with that particular funding tx: $ rm -rf ~/.bitcoin/regtest/ $ bitcoind -regtest=1 & $ bitcoin-cli -regtest=1 submitblock 0000002006226e46111a0b59caaf126043eb5bbf28c34f3a5e332a1fc7b2b73cf188910fadbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fdc30f9858ffff7f20000000000101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff03510101ffffffff0100f2052a010000001976a9143ca33c2e4446f4a305f23c80df8ad1afdcf652f988ac00000000 $ bitcoin-cli -regtest=1 generate 431 $ bitcoin-cli -regtest=1 sendrawtransaction 0200000001adbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fd000000006b48304502210090587b6201e166ad6af0227d3036a9454223d49a1f11839c1a362184340ef0240220577f7cd5cca78719405cbf1de7414ac027f0239ef6e214c90fcaab0454d84b3b012103535b32d5eb0a6ed0982a0479bbadc9868d9836f6ba94dd5a63be16d875069184ffffffff028096980000000000220020c015c4a6be010e21657068fc2e6a9d02b27ebe4d490a25846f7237f104d1a3cd20256d29010000001600143ca33c2e4446f4a305f23c80df8ad1afdcf652f900000000 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-02-07 01:45:33 +01:00
BOLT 03: Remove extra 0x01 byte from private keys in test vectors. An 0x01 byte is appended to the end of private keys in the test vectors to mark them as using compressed serialization to derive the pubkeys. Two of the private keys have two 0x01 bytes appended, presumably by accident.
2017-09-22 08:23:19 +02:00
local_funding_privkey: 30ff4956bbdd3222d44cc5e8a1261dab1e07957bdac5ae88fe3261ef321f374901
bolt3 fix and enhance tx testvectors (#99) This is a smerge of Fabrice Drouin and my work: he update them, I updated them and enhanced them, he found bugs, I re-derived them, etc. - rename keys properly - fix fees - sign all transactions - Derive test transaction vectors from minimal subset of parameters. - rewrite test vectors to test edge cases for trimming. - add funding tx test vector, make testable on regtest. This adds a funding transaction test (really, we only specify the output), but importantly adds enough information to duplicate a blockchain with that particular funding tx: $ rm -rf ~/.bitcoin/regtest/ $ bitcoind -regtest=1 & $ bitcoin-cli -regtest=1 submitblock 0000002006226e46111a0b59caaf126043eb5bbf28c34f3a5e332a1fc7b2b73cf188910fadbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fdc30f9858ffff7f20000000000101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff03510101ffffffff0100f2052a010000001976a9143ca33c2e4446f4a305f23c80df8ad1afdcf652f988ac00000000 $ bitcoin-cli -regtest=1 generate 431 $ bitcoin-cli -regtest=1 sendrawtransaction 0200000001adbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fd000000006b48304502210090587b6201e166ad6af0227d3036a9454223d49a1f11839c1a362184340ef0240220577f7cd5cca78719405cbf1de7414ac027f0239ef6e214c90fcaab0454d84b3b012103535b32d5eb0a6ed0982a0479bbadc9868d9836f6ba94dd5a63be16d875069184ffffffff028096980000000000220020c015c4a6be010e21657068fc2e6a9d02b27ebe4d490a25846f7237f104d1a3cd20256d29010000001600143ca33c2e4446f4a305f23c80df8ad1afdcf652f900000000 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-02-07 01:45:33 +01:00
local_funding_pubkey: 023da092f6980e58d2c037173180e9a465476026ee50f96695963e8efe436f54eb
remote_funding_pubkey: 030e9f7b623d2ccc7c9bd44d66d5ce21ce504c0acf6385a132cec6d3c39fa711c1
BOLT 2,3,5: always refer to shared/pubkey/private key. Make it clear what kind of key we're talking about. We use the abbreviation pubkey for public key (as it's quite common to use in field names), but generally spell out 'private'. (I generally prefer 'secret' to 'private' but we use private far more often already, and we use 'secret' for things which don't directly derive keys). Fixes: #368 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2018-02-06 01:18:41 +01:00
local_privkey: bb13b121cdc357cd2e608b0aea294afca36e2b34cf958e2e6451a2f27469449101
localpubkey: 030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e7
remotepubkey: 0394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b
local_delayedpubkey: 03fd5960528dc152014952efdb702a88f71e3c1653b2314431701ec77e57fde83c
local_revocation_pubkey: 0212a140cd0c6539d07cd08dfe09984dec3251ea808b892efeac3ede9402bf2b19
bolt3 fix and enhance tx testvectors (#99) This is a smerge of Fabrice Drouin and my work: he update them, I updated them and enhanced them, he found bugs, I re-derived them, etc. - rename keys properly - fix fees - sign all transactions - Derive test transaction vectors from minimal subset of parameters. - rewrite test vectors to test edge cases for trimming. - add funding tx test vector, make testable on regtest. This adds a funding transaction test (really, we only specify the output), but importantly adds enough information to duplicate a blockchain with that particular funding tx: $ rm -rf ~/.bitcoin/regtest/ $ bitcoind -regtest=1 & $ bitcoin-cli -regtest=1 submitblock 0000002006226e46111a0b59caaf126043eb5bbf28c34f3a5e332a1fc7b2b73cf188910fadbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fdc30f9858ffff7f20000000000101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff03510101ffffffff0100f2052a010000001976a9143ca33c2e4446f4a305f23c80df8ad1afdcf652f988ac00000000 $ bitcoin-cli -regtest=1 generate 431 $ bitcoin-cli -regtest=1 sendrawtransaction 0200000001adbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fd000000006b48304502210090587b6201e166ad6af0227d3036a9454223d49a1f11839c1a362184340ef0240220577f7cd5cca78719405cbf1de7414ac027f0239ef6e214c90fcaab0454d84b3b012103535b32d5eb0a6ed0982a0479bbadc9868d9836f6ba94dd5a63be16d875069184ffffffff028096980000000000220020c015c4a6be010e21657068fc2e6a9d02b27ebe4d490a25846f7237f104d1a3cd20256d29010000001600143ca33c2e4446f4a305f23c80df8ad1afdcf652f900000000 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-02-07 01:45:33 +01:00
# funding wscript = 5221023da092f6980e58d2c037173180e9a465476026ee50f96695963e8efe436f54eb21030e9f7b623d2ccc7c9bd44d66d5ce21ce504c0acf6385a132cec6d3c39fa711c152ae
BOLT 3: complete first pass copy-edit according to stylesheet guidelines;
2017-11-21 03:51:25 +01:00
And, here are the test vectors themselves:
bolt3 fix and enhance tx testvectors (#99) This is a smerge of Fabrice Drouin and my work: he update them, I updated them and enhanced them, he found bugs, I re-derived them, etc. - rename keys properly - fix fees - sign all transactions - Derive test transaction vectors from minimal subset of parameters. - rewrite test vectors to test edge cases for trimming. - add funding tx test vector, make testable on regtest. This adds a funding transaction test (really, we only specify the output), but importantly adds enough information to duplicate a blockchain with that particular funding tx: $ rm -rf ~/.bitcoin/regtest/ $ bitcoind -regtest=1 & $ bitcoin-cli -regtest=1 submitblock 0000002006226e46111a0b59caaf126043eb5bbf28c34f3a5e332a1fc7b2b73cf188910fadbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fdc30f9858ffff7f20000000000101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff03510101ffffffff0100f2052a010000001976a9143ca33c2e4446f4a305f23c80df8ad1afdcf652f988ac00000000 $ bitcoin-cli -regtest=1 generate 431 $ bitcoin-cli -regtest=1 sendrawtransaction 0200000001adbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fd000000006b48304502210090587b6201e166ad6af0227d3036a9454223d49a1f11839c1a362184340ef0240220577f7cd5cca78719405cbf1de7414ac027f0239ef6e214c90fcaab0454d84b3b012103535b32d5eb0a6ed0982a0479bbadc9868d9836f6ba94dd5a63be16d875069184ffffffff028096980000000000220020c015c4a6be010e21657068fc2e6a9d02b27ebe4d490a25846f7237f104d1a3cd20256d29010000001600143ca33c2e4446f4a305f23c80df8ad1afdcf652f900000000 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-02-07 01:45:33 +01:00
name: simple commitment tx with no HTLCs
to_local_msat: 7000000000
to_remote_msat: 3000000000
make htlc outputs of the commitment tx spendable with revocation key (Merge conflict in test vectors fixed by selecting Pierre's, will have to be re-evaluated). Closes: #105
2017-02-10 12:23:32 +01:00
local_feerate_per_kw: 15000
bolt3 fix and enhance tx testvectors (#99) This is a smerge of Fabrice Drouin and my work: he update them, I updated them and enhanced them, he found bugs, I re-derived them, etc. - rename keys properly - fix fees - sign all transactions - Derive test transaction vectors from minimal subset of parameters. - rewrite test vectors to test edge cases for trimming. - add funding tx test vector, make testable on regtest. This adds a funding transaction test (really, we only specify the output), but importantly adds enough information to duplicate a blockchain with that particular funding tx: $ rm -rf ~/.bitcoin/regtest/ $ bitcoind -regtest=1 & $ bitcoin-cli -regtest=1 submitblock 0000002006226e46111a0b59caaf126043eb5bbf28c34f3a5e332a1fc7b2b73cf188910fadbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fdc30f9858ffff7f20000000000101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff03510101ffffffff0100f2052a010000001976a9143ca33c2e4446f4a305f23c80df8ad1afdcf652f988ac00000000 $ bitcoin-cli -regtest=1 generate 431 $ bitcoin-cli -regtest=1 sendrawtransaction 0200000001adbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fd000000006b48304502210090587b6201e166ad6af0227d3036a9454223d49a1f11839c1a362184340ef0240220577f7cd5cca78719405cbf1de7414ac027f0239ef6e214c90fcaab0454d84b3b012103535b32d5eb0a6ed0982a0479bbadc9868d9836f6ba94dd5a63be16d875069184ffffffff028096980000000000220020c015c4a6be010e21657068fc2e6a9d02b27ebe4d490a25846f7237f104d1a3cd20256d29010000001600143ca33c2e4446f4a305f23c80df8ad1afdcf652f900000000 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-02-07 01:45:33 +01:00
# base commitment transaction fee = 10860
BOLT 3: update test vectors for new scripts and weight calculation. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-03-07 05:56:08 +01:00
# actual commitment transaction fee = 10860
Underscores for all terms, not just fields. Plus a few more missing ones, and some consistency fixes in names as pointed out by Roasbeed and Fabrice. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-05-14 02:32:22 +02:00
# to_local amount 6989140 wscript 63210212a140cd0c6539d07cd08dfe09984dec3251ea808b892efeac3ede9402bf2b1967029000b2752103fd5960528dc152014952efdb702a88f71e3c1653b2314431701ec77e57fde83c68ac
# to_remote amount 3000000 P2WPKH(0394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b)
BOLT 3: update test vectors for new scripts and weight calculation. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-03-07 05:56:08 +01:00
remote_signature = 3045022100f51d2e566a70ba740fc5d8c0f07b9b93d2ed741c3c0860c613173de7d39e7968022041376d520e9c0e1ad52248ddf4b22e12be8763007df977253ef45a4ca3bdb7c0
# local_signature = 3044022051b75c73198c6deee1a875871c3961832909acd297c6b908d59e3319e5185a46022055c419379c5051a78d00dbbce11b5b664a0c22815fbcc6fcef6b1937c3836939
output commit_tx: 02000000000101bef67e4e2fb9ddeeb3461973cd4c62abb35050b1add772995b820b584a488489000000000038b02b8002c0c62d0000000000160014ccf1af2f2aabee14bb40fa3851ab2301de84311054a56a00000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e0400473044022051b75c73198c6deee1a875871c3961832909acd297c6b908d59e3319e5185a46022055c419379c5051a78d00dbbce11b5b664a0c22815fbcc6fcef6b1937c383693901483045022100f51d2e566a70ba740fc5d8c0f07b9b93d2ed741c3c0860c613173de7d39e7968022041376d520e9c0e1ad52248ddf4b22e12be8763007df977253ef45a4ca3bdb7c001475221023da092f6980e58d2c037173180e9a465476026ee50f96695963e8efe436f54eb21030e9f7b623d2ccc7c9bd44d66d5ce21ce504c0acf6385a132cec6d3c39fa711c152ae3e195220
bolt3 fix and enhance tx testvectors (#99) This is a smerge of Fabrice Drouin and my work: he update them, I updated them and enhanced them, he found bugs, I re-derived them, etc. - rename keys properly - fix fees - sign all transactions - Derive test transaction vectors from minimal subset of parameters. - rewrite test vectors to test edge cases for trimming. - add funding tx test vector, make testable on regtest. This adds a funding transaction test (really, we only specify the output), but importantly adds enough information to duplicate a blockchain with that particular funding tx: $ rm -rf ~/.bitcoin/regtest/ $ bitcoind -regtest=1 & $ bitcoin-cli -regtest=1 submitblock 0000002006226e46111a0b59caaf126043eb5bbf28c34f3a5e332a1fc7b2b73cf188910fadbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fdc30f9858ffff7f20000000000101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff03510101ffffffff0100f2052a010000001976a9143ca33c2e4446f4a305f23c80df8ad1afdcf652f988ac00000000 $ bitcoin-cli -regtest=1 generate 431 $ bitcoin-cli -regtest=1 sendrawtransaction 0200000001adbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fd000000006b48304502210090587b6201e166ad6af0227d3036a9454223d49a1f11839c1a362184340ef0240220577f7cd5cca78719405cbf1de7414ac027f0239ef6e214c90fcaab0454d84b3b012103535b32d5eb0a6ed0982a0479bbadc9868d9836f6ba94dd5a63be16d875069184ffffffff028096980000000000220020c015c4a6be010e21657068fc2e6a9d02b27ebe4d490a25846f7237f104d1a3cd20256d29010000001600143ca33c2e4446f4a305f23c80df8ad1afdcf652f900000000 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-02-07 01:45:33 +01:00
num_htlcs: 0
make htlc outputs of the commitment tx spendable with revocation key (Merge conflict in test vectors fixed by selecting Pierre's, will have to be re-evaluated). Closes: #105
2017-02-10 12:23:32 +01:00
BOLT 1,2,3: first pass copy-edit; BOLT 1,2: minor header spacing fixes BOLT 3: first pass copy edit, according to capitalization, formatting stylesheet guidelines;
2017-11-18 22:04:58 +01:00
name: commitment tx with all five HTLCs untrimmed (minimum feerate)
bolt3 fix and enhance tx testvectors (#99) This is a smerge of Fabrice Drouin and my work: he update them, I updated them and enhanced them, he found bugs, I re-derived them, etc. - rename keys properly - fix fees - sign all transactions - Derive test transaction vectors from minimal subset of parameters. - rewrite test vectors to test edge cases for trimming. - add funding tx test vector, make testable on regtest. This adds a funding transaction test (really, we only specify the output), but importantly adds enough information to duplicate a blockchain with that particular funding tx: $ rm -rf ~/.bitcoin/regtest/ $ bitcoind -regtest=1 & $ bitcoin-cli -regtest=1 submitblock 0000002006226e46111a0b59caaf126043eb5bbf28c34f3a5e332a1fc7b2b73cf188910fadbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fdc30f9858ffff7f20000000000101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff03510101ffffffff0100f2052a010000001976a9143ca33c2e4446f4a305f23c80df8ad1afdcf652f988ac00000000 $ bitcoin-cli -regtest=1 generate 431 $ bitcoin-cli -regtest=1 sendrawtransaction 0200000001adbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fd000000006b48304502210090587b6201e166ad6af0227d3036a9454223d49a1f11839c1a362184340ef0240220577f7cd5cca78719405cbf1de7414ac027f0239ef6e214c90fcaab0454d84b3b012103535b32d5eb0a6ed0982a0479bbadc9868d9836f6ba94dd5a63be16d875069184ffffffff028096980000000000220020c015c4a6be010e21657068fc2e6a9d02b27ebe4d490a25846f7237f104d1a3cd20256d29010000001600143ca33c2e4446f4a305f23c80df8ad1afdcf652f900000000 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-02-07 01:45:33 +01:00
to_local_msat: 6988000000
to_remote_msat: 3000000000
local_feerate_per_kw: 0
# base commitment transaction fee = 0
make htlc outputs of the commitment tx spendable with revocation key (Merge conflict in test vectors fixed by selecting Pierre's, will have to be re-evaluated). Closes: #105
2017-02-10 12:23:32 +01:00
# actual commitment transaction fee = 0
Clarify Bolt 3 htlc tx output test vectors (#852) It was sometimes unclear where we indexed by the output or the htlc id. This is a follow-up from discussions made in #539.
2021-06-21 22:01:47 +02:00
# HTLC #2 offered amount 2000 wscript 76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c820120876475527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae67a914b43e1b38138a41b37f7cd9a1d274bc63e3a9b5d188ac6868
# HTLC #3 offered amount 3000 wscript 76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c820120876475527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae67a9148a486ff2e31d6158bf39e2608864d63fefd09d5b88ac6868
# HTLC #0 received amount 1000 wscript 76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c8201208763a914b8bcb07f6344b42ab04250c86a6e8b75d3fdbbc688527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae677502f401b175ac6868
# HTLC #1 received amount 2000 wscript 76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c8201208763a9144b6b2e5444c2639cc0fb7bcea5afba3f3cdce23988527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae677502f501b175ac6868
# HTLC #4 received amount 4000 wscript 76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c8201208763a91418bc1a114ccf9c052d3d23e28d3b0a9d1227434288527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae677502f801b175ac6868
Underscores for all terms, not just fields. Plus a few more missing ones, and some consistency fixes in names as pointed out by Roasbeed and Fabrice. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-05-14 02:32:22 +02:00
# to_local amount 6988000 wscript 63210212a140cd0c6539d07cd08dfe09984dec3251ea808b892efeac3ede9402bf2b1967029000b2752103fd5960528dc152014952efdb702a88f71e3c1653b2314431701ec77e57fde83c68ac
# to_remote amount 3000000 P2WPKH(0394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b)
BOLT 3: update test vectors for new scripts and weight calculation. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-03-07 05:56:08 +01:00
remote_signature = 304402204fd4928835db1ccdfc40f5c78ce9bd65249b16348df81f0c44328dcdefc97d630220194d3869c38bc732dd87d13d2958015e2fc16829e74cd4377f84d215c0b70606
# local_signature = 30440220275b0c325a5e9355650dc30c0eccfbc7efb23987c24b556b9dfdd40effca18d202206caceb2c067836c51f296740c7ae807ffcbfbf1dd3a0d56b6de9a5b247985f06
output commit_tx: 02000000000101bef67e4e2fb9ddeeb3461973cd4c62abb35050b1add772995b820b584a488489000000000038b02b8007e80300000000000022002052bfef0479d7b293c27e0f1eb294bea154c63a3294ef092c19af51409bce0e2ad007000000000000220020403d394747cae42e98ff01734ad5c08f82ba123d3d9a620abda88989651e2ab5d007000000000000220020748eba944fedc8827f6b06bc44678f93c0f9e6078b35c6331ed31e75f8ce0c2db80b000000000000220020c20b5d1f8584fd90443e7b7b720136174fa4b9333c261d04dbbd012635c0f419a00f0000000000002200208c48d15160397c9731df9bc3b236656efb6665fbfe92b4a6878e88a499f741c4c0c62d0000000000160014ccf1af2f2aabee14bb40fa3851ab2301de843110e0a06a00000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e04004730440220275b0c325a5e9355650dc30c0eccfbc7efb23987c24b556b9dfdd40effca18d202206caceb2c067836c51f296740c7ae807ffcbfbf1dd3a0d56b6de9a5b247985f060147304402204fd4928835db1ccdfc40f5c78ce9bd65249b16348df81f0c44328dcdefc97d630220194d3869c38bc732dd87d13d2958015e2fc16829e74cd4377f84d215c0b7060601475221023da092f6980e58d2c037173180e9a465476026ee50f96695963e8efe436f54eb21030e9f7b623d2ccc7c9bd44d66d5ce21ce504c0acf6385a132cec6d3c39fa711c152ae3e195220
bolt3 fix and enhance tx testvectors (#99) This is a smerge of Fabrice Drouin and my work: he update them, I updated them and enhanced them, he found bugs, I re-derived them, etc. - rename keys properly - fix fees - sign all transactions - Derive test transaction vectors from minimal subset of parameters. - rewrite test vectors to test edge cases for trimming. - add funding tx test vector, make testable on regtest. This adds a funding transaction test (really, we only specify the output), but importantly adds enough information to duplicate a blockchain with that particular funding tx: $ rm -rf ~/.bitcoin/regtest/ $ bitcoind -regtest=1 & $ bitcoin-cli -regtest=1 submitblock 0000002006226e46111a0b59caaf126043eb5bbf28c34f3a5e332a1fc7b2b73cf188910fadbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fdc30f9858ffff7f20000000000101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff03510101ffffffff0100f2052a010000001976a9143ca33c2e4446f4a305f23c80df8ad1afdcf652f988ac00000000 $ bitcoin-cli -regtest=1 generate 431 $ bitcoin-cli -regtest=1 sendrawtransaction 0200000001adbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fd000000006b48304502210090587b6201e166ad6af0227d3036a9454223d49a1f11839c1a362184340ef0240220577f7cd5cca78719405cbf1de7414ac027f0239ef6e214c90fcaab0454d84b3b012103535b32d5eb0a6ed0982a0479bbadc9868d9836f6ba94dd5a63be16d875069184ffffffff028096980000000000220020c015c4a6be010e21657068fc2e6a9d02b27ebe4d490a25846f7237f104d1a3cd20256d29010000001600143ca33c2e4446f4a305f23c80df8ad1afdcf652f900000000 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-02-07 01:45:33 +01:00
num_htlcs: 5
Clarify Bolt 3 htlc tx output test vectors (#852) It was sometimes unclear where we indexed by the output or the htlc id. This is a follow-up from discussions made in #539.
2021-06-21 22:01:47 +02:00
# signature for output #0 (htlc-success for htlc #0)
BOLT 3: update test vectors for new scripts and weight calculation. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-03-07 05:56:08 +01:00
remote_htlc_signature = 304402206a6e59f18764a5bf8d4fa45eebc591566689441229c918b480fb2af8cc6a4aeb02205248f273be447684b33e3c8d1d85a8e0ca9fa0bae9ae33f0527ada9c162919a6
Clarify Bolt 3 htlc tx output test vectors (#852) It was sometimes unclear where we indexed by the output or the htlc id. This is a follow-up from discussions made in #539.
2021-06-21 22:01:47 +02:00
# local_htlc_signature = 304402207cb324fa0de88f452ffa9389678127ebcf4cabe1dd848b8e076c1a1962bf34720220116ed922b12311bd602d67e60d2529917f21c5b82f25ff6506c0f87886b4dfd5
htlc_success_tx (htlc #0): 020000000001018154ecccf11a5fb56c39654c4deb4d2296f83c69268280b94d021370c94e219700000000000000000001e8030000000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e050047304402206a6e59f18764a5bf8d4fa45eebc591566689441229c918b480fb2af8cc6a4aeb02205248f273be447684b33e3c8d1d85a8e0ca9fa0bae9ae33f0527ada9c162919a60147304402207cb324fa0de88f452ffa9389678127ebcf4cabe1dd848b8e076c1a1962bf34720220116ed922b12311bd602d67e60d2529917f21c5b82f25ff6506c0f87886b4dfd5012000000000000000000000000000000000000000000000000000000000000000008a76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c8201208763a914b8bcb07f6344b42ab04250c86a6e8b75d3fdbbc688527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae677502f401b175ac686800000000
# signature for output #1 (htlc-timeout for htlc #2)
BOLT 3: update test vectors for new scripts and weight calculation. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-03-07 05:56:08 +01:00
remote_htlc_signature = 3045022100d5275b3619953cb0c3b5aa577f04bc512380e60fa551762ce3d7a1bb7401cff9022037237ab0dac3fe100cde094e82e2bed9ba0ed1bb40154b48e56aa70f259e608b
Clarify Bolt 3 htlc tx output test vectors (#852) It was sometimes unclear where we indexed by the output or the htlc id. This is a follow-up from discussions made in #539.
2021-06-21 22:01:47 +02:00
# local_htlc_signature = 3045022100c89172099507ff50f4c925e6c5150e871fb6e83dd73ff9fbb72f6ce829a9633f02203a63821d9162e99f9be712a68f9e589483994feae2661e4546cd5b6cec007be5
htlc_timeout_tx (htlc #2): 020000000001018154ecccf11a5fb56c39654c4deb4d2296f83c69268280b94d021370c94e219701000000000000000001d0070000000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e0500483045022100d5275b3619953cb0c3b5aa577f04bc512380e60fa551762ce3d7a1bb7401cff9022037237ab0dac3fe100cde094e82e2bed9ba0ed1bb40154b48e56aa70f259e608b01483045022100c89172099507ff50f4c925e6c5150e871fb6e83dd73ff9fbb72f6ce829a9633f02203a63821d9162e99f9be712a68f9e589483994feae2661e4546cd5b6cec007be501008576a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c820120876475527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae67a914b43e1b38138a41b37f7cd9a1d274bc63e3a9b5d188ac6868f6010000
# signature for output #2 (htlc-success for htlc #1)
BOLT 3: update test vectors for new scripts and weight calculation. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-03-07 05:56:08 +01:00
remote_htlc_signature = 304402201b63ec807771baf4fdff523c644080de17f1da478989308ad13a58b51db91d360220568939d38c9ce295adba15665fa68f51d967e8ed14a007b751540a80b325f202
Clarify Bolt 3 htlc tx output test vectors (#852) It was sometimes unclear where we indexed by the output or the htlc id. This is a follow-up from discussions made in #539.
2021-06-21 22:01:47 +02:00
# local_htlc_signature = 3045022100def389deab09cee69eaa1ec14d9428770e45bcbe9feb46468ecf481371165c2f022015d2e3c46600b2ebba8dcc899768874cc6851fd1ecb3fffd15db1cc3de7e10da
htlc_success_tx (htlc #1): 020000000001018154ecccf11a5fb56c39654c4deb4d2296f83c69268280b94d021370c94e219702000000000000000001d0070000000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e050047304402201b63ec807771baf4fdff523c644080de17f1da478989308ad13a58b51db91d360220568939d38c9ce295adba15665fa68f51d967e8ed14a007b751540a80b325f20201483045022100def389deab09cee69eaa1ec14d9428770e45bcbe9feb46468ecf481371165c2f022015d2e3c46600b2ebba8dcc899768874cc6851fd1ecb3fffd15db1cc3de7e10da012001010101010101010101010101010101010101010101010101010101010101018a76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c8201208763a9144b6b2e5444c2639cc0fb7bcea5afba3f3cdce23988527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae677502f501b175ac686800000000
# signature for output #3 (htlc-timeout for htlc #3)
BOLT 3: update test vectors for new scripts and weight calculation. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-03-07 05:56:08 +01:00
remote_htlc_signature = 3045022100daee1808f9861b6c3ecd14f7b707eca02dd6bdfc714ba2f33bc8cdba507bb182022026654bf8863af77d74f51f4e0b62d461a019561bb12acb120d3f7195d148a554
Clarify Bolt 3 htlc tx output test vectors (#852) It was sometimes unclear where we indexed by the output or the htlc id. This is a follow-up from discussions made in #539.
2021-06-21 22:01:47 +02:00
# local_htlc_signature = 30440220643aacb19bbb72bd2b635bc3f7375481f5981bace78cdd8319b2988ffcc6704202203d27784ec8ad51ed3bd517a05525a5139bb0b755dd719e0054332d186ac08727
htlc_timeout_tx (htlc #3): 020000000001018154ecccf11a5fb56c39654c4deb4d2296f83c69268280b94d021370c94e219703000000000000000001b80b0000000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e0500483045022100daee1808f9861b6c3ecd14f7b707eca02dd6bdfc714ba2f33bc8cdba507bb182022026654bf8863af77d74f51f4e0b62d461a019561bb12acb120d3f7195d148a554014730440220643aacb19bbb72bd2b635bc3f7375481f5981bace78cdd8319b2988ffcc6704202203d27784ec8ad51ed3bd517a05525a5139bb0b755dd719e0054332d186ac0872701008576a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c820120876475527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae67a9148a486ff2e31d6158bf39e2608864d63fefd09d5b88ac6868f7010000
# signature for output #4 (htlc-success for htlc #4)
BOLT 3: update test vectors for new scripts and weight calculation. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-03-07 05:56:08 +01:00
remote_htlc_signature = 304402207e0410e45454b0978a623f36a10626ef17b27d9ad44e2760f98cfa3efb37924f0220220bd8acd43ecaa916a80bd4f919c495a2c58982ce7c8625153f8596692a801d
Clarify Bolt 3 htlc tx output test vectors (#852) It was sometimes unclear where we indexed by the output or the htlc id. This is a follow-up from discussions made in #539.
2021-06-21 22:01:47 +02:00
# local_htlc_signature = 30440220549e80b4496803cbc4a1d09d46df50109f546d43fbbf86cd90b174b1484acd5402205f12a4f995cb9bded597eabfee195a285986aa6d93ae5bb72507ebc6a4e2349e
htlc_success_tx (htlc #4): 020000000001018154ecccf11a5fb56c39654c4deb4d2296f83c69268280b94d021370c94e219704000000000000000001a00f0000000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e050047304402207e0410e45454b0978a623f36a10626ef17b27d9ad44e2760f98cfa3efb37924f0220220bd8acd43ecaa916a80bd4f919c495a2c58982ce7c8625153f8596692a801d014730440220549e80b4496803cbc4a1d09d46df50109f546d43fbbf86cd90b174b1484acd5402205f12a4f995cb9bded597eabfee195a285986aa6d93ae5bb72507ebc6a4e2349e012004040404040404040404040404040404040404040404040404040404040404048a76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c8201208763a91418bc1a114ccf9c052d3d23e28d3b0a9d1227434288527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae677502f801b175ac686800000000
make htlc outputs of the commitment tx spendable with revocation key (Merge conflict in test vectors fixed by selecting Pierre's, will have to be re-evaluated). Closes: #105
2017-02-10 12:23:32 +01:00
BOLT 1,2,3: first pass copy-edit; BOLT 1,2: minor header spacing fixes BOLT 3: first pass copy edit, according to capitalization, formatting stylesheet guidelines;
2017-11-18 22:04:58 +01:00
name: commitment tx with seven outputs untrimmed (maximum feerate)
bolt3 fix and enhance tx testvectors (#99) This is a smerge of Fabrice Drouin and my work: he update them, I updated them and enhanced them, he found bugs, I re-derived them, etc. - rename keys properly - fix fees - sign all transactions - Derive test transaction vectors from minimal subset of parameters. - rewrite test vectors to test edge cases for trimming. - add funding tx test vector, make testable on regtest. This adds a funding transaction test (really, we only specify the output), but importantly adds enough information to duplicate a blockchain with that particular funding tx: $ rm -rf ~/.bitcoin/regtest/ $ bitcoind -regtest=1 & $ bitcoin-cli -regtest=1 submitblock 0000002006226e46111a0b59caaf126043eb5bbf28c34f3a5e332a1fc7b2b73cf188910fadbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fdc30f9858ffff7f20000000000101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff03510101ffffffff0100f2052a010000001976a9143ca33c2e4446f4a305f23c80df8ad1afdcf652f988ac00000000 $ bitcoin-cli -regtest=1 generate 431 $ bitcoin-cli -regtest=1 sendrawtransaction 0200000001adbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fd000000006b48304502210090587b6201e166ad6af0227d3036a9454223d49a1f11839c1a362184340ef0240220577f7cd5cca78719405cbf1de7414ac027f0239ef6e214c90fcaab0454d84b3b012103535b32d5eb0a6ed0982a0479bbadc9868d9836f6ba94dd5a63be16d875069184ffffffff028096980000000000220020c015c4a6be010e21657068fc2e6a9d02b27ebe4d490a25846f7237f104d1a3cd20256d29010000001600143ca33c2e4446f4a305f23c80df8ad1afdcf652f900000000 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-02-07 01:45:33 +01:00
to_local_msat: 6988000000
to_remote_msat: 3000000000
BOLT 3: update test vectors for new scripts and weight calculation. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-03-07 05:56:08 +01:00
local_feerate_per_kw: 647
# base commitment transaction fee = 1024
# actual commitment transaction fee = 1024
Clarify Bolt 3 htlc tx output test vectors (#852) It was sometimes unclear where we indexed by the output or the htlc id. This is a follow-up from discussions made in #539.
2021-06-21 22:01:47 +02:00
# HTLC #2 offered amount 2000 wscript 76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c820120876475527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae67a914b43e1b38138a41b37f7cd9a1d274bc63e3a9b5d188ac6868
# HTLC #3 offered amount 3000 wscript 76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c820120876475527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae67a9148a486ff2e31d6158bf39e2608864d63fefd09d5b88ac6868
# HTLC #0 received amount 1000 wscript 76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c8201208763a914b8bcb07f6344b42ab04250c86a6e8b75d3fdbbc688527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae677502f401b175ac6868
# HTLC #1 received amount 2000 wscript 76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c8201208763a9144b6b2e5444c2639cc0fb7bcea5afba3f3cdce23988527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae677502f501b175ac6868
# HTLC #4 received amount 4000 wscript 76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c8201208763a91418bc1a114ccf9c052d3d23e28d3b0a9d1227434288527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae677502f801b175ac6868
Underscores for all terms, not just fields. Plus a few more missing ones, and some consistency fixes in names as pointed out by Roasbeed and Fabrice. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-05-14 02:32:22 +02:00
# to_local amount 6986976 wscript 63210212a140cd0c6539d07cd08dfe09984dec3251ea808b892efeac3ede9402bf2b1967029000b2752103fd5960528dc152014952efdb702a88f71e3c1653b2314431701ec77e57fde83c68ac
# to_remote amount 3000000 P2WPKH(0394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b)
BOLT 3: update test vectors for new scripts and weight calculation. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-03-07 05:56:08 +01:00
remote_signature = 3045022100a5c01383d3ec646d97e40f44318d49def817fcd61a0ef18008a665b3e151785502203e648efddd5838981ef55ec954be69c4a652d021e6081a100d034de366815e9b
# local_signature = 304502210094bfd8f5572ac0157ec76a9551b6c5216a4538c07cd13a51af4a54cb26fa14320220768efce8ce6f4a5efac875142ff19237c011343670adf9c7ac69704a120d1163
output commit_tx: 02000000000101bef67e4e2fb9ddeeb3461973cd4c62abb35050b1add772995b820b584a488489000000000038b02b8007e80300000000000022002052bfef0479d7b293c27e0f1eb294bea154c63a3294ef092c19af51409bce0e2ad007000000000000220020403d394747cae42e98ff01734ad5c08f82ba123d3d9a620abda88989651e2ab5d007000000000000220020748eba944fedc8827f6b06bc44678f93c0f9e6078b35c6331ed31e75f8ce0c2db80b000000000000220020c20b5d1f8584fd90443e7b7b720136174fa4b9333c261d04dbbd012635c0f419a00f0000000000002200208c48d15160397c9731df9bc3b236656efb6665fbfe92b4a6878e88a499f741c4c0c62d0000000000160014ccf1af2f2aabee14bb40fa3851ab2301de843110e09c6a00000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e040048304502210094bfd8f5572ac0157ec76a9551b6c5216a4538c07cd13a51af4a54cb26fa14320220768efce8ce6f4a5efac875142ff19237c011343670adf9c7ac69704a120d116301483045022100a5c01383d3ec646d97e40f44318d49def817fcd61a0ef18008a665b3e151785502203e648efddd5838981ef55ec954be69c4a652d021e6081a100d034de366815e9b01475221023da092f6980e58d2c037173180e9a465476026ee50f96695963e8efe436f54eb21030e9f7b623d2ccc7c9bd44d66d5ce21ce504c0acf6385a132cec6d3c39fa711c152ae3e195220
bolt3 fix and enhance tx testvectors (#99) This is a smerge of Fabrice Drouin and my work: he update them, I updated them and enhanced them, he found bugs, I re-derived them, etc. - rename keys properly - fix fees - sign all transactions - Derive test transaction vectors from minimal subset of parameters. - rewrite test vectors to test edge cases for trimming. - add funding tx test vector, make testable on regtest. This adds a funding transaction test (really, we only specify the output), but importantly adds enough information to duplicate a blockchain with that particular funding tx: $ rm -rf ~/.bitcoin/regtest/ $ bitcoind -regtest=1 & $ bitcoin-cli -regtest=1 submitblock 0000002006226e46111a0b59caaf126043eb5bbf28c34f3a5e332a1fc7b2b73cf188910fadbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fdc30f9858ffff7f20000000000101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff03510101ffffffff0100f2052a010000001976a9143ca33c2e4446f4a305f23c80df8ad1afdcf652f988ac00000000 $ bitcoin-cli -regtest=1 generate 431 $ bitcoin-cli -regtest=1 sendrawtransaction 0200000001adbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fd000000006b48304502210090587b6201e166ad6af0227d3036a9454223d49a1f11839c1a362184340ef0240220577f7cd5cca78719405cbf1de7414ac027f0239ef6e214c90fcaab0454d84b3b012103535b32d5eb0a6ed0982a0479bbadc9868d9836f6ba94dd5a63be16d875069184ffffffff028096980000000000220020c015c4a6be010e21657068fc2e6a9d02b27ebe4d490a25846f7237f104d1a3cd20256d29010000001600143ca33c2e4446f4a305f23c80df8ad1afdcf652f900000000 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-02-07 01:45:33 +01:00
num_htlcs: 5
Clarify Bolt 3 htlc tx output test vectors (#852) It was sometimes unclear where we indexed by the output or the htlc id. This is a follow-up from discussions made in #539.
2021-06-21 22:01:47 +02:00
# signature for output #0 (htlc-success for htlc #0)
BOLT 3: update test vectors for new scripts and weight calculation. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-03-07 05:56:08 +01:00
remote_htlc_signature = 30440220385a5afe75632f50128cbb029ee95c80156b5b4744beddc729ad339c9ca432c802202ba5f48550cad3379ac75b9b4fedb86a35baa6947f16ba5037fb8b11ab343740
Clarify Bolt 3 htlc tx output test vectors (#852) It was sometimes unclear where we indexed by the output or the htlc id. This is a follow-up from discussions made in #539.
2021-06-21 22:01:47 +02:00
# local_htlc_signature = 304402205999590b8a79fa346e003a68fd40366397119b2b0cdf37b149968d6bc6fbcc4702202b1e1fb5ab7864931caed4e732c359e0fe3d86a548b557be2246efb1708d579a
htlc_success_tx (htlc #0): 020000000001018323148ce2419f21ca3d6780053747715832e18ac780931a514b187768882bb60000000000000000000122020000000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e05004730440220385a5afe75632f50128cbb029ee95c80156b5b4744beddc729ad339c9ca432c802202ba5f48550cad3379ac75b9b4fedb86a35baa6947f16ba5037fb8b11ab3437400147304402205999590b8a79fa346e003a68fd40366397119b2b0cdf37b149968d6bc6fbcc4702202b1e1fb5ab7864931caed4e732c359e0fe3d86a548b557be2246efb1708d579a012000000000000000000000000000000000000000000000000000000000000000008a76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c8201208763a914b8bcb07f6344b42ab04250c86a6e8b75d3fdbbc688527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae677502f401b175ac686800000000
# signature for output #1 (htlc-timeout for htlc #2)
BOLT 3: update test vectors for new scripts and weight calculation. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-03-07 05:56:08 +01:00
remote_htlc_signature = 304402207ceb6678d4db33d2401fdc409959e57c16a6cb97a30261d9c61f29b8c58d34b90220084b4a17b4ca0e86f2d798b3698ca52de5621f2ce86f80bed79afa66874511b0
Clarify Bolt 3 htlc tx output test vectors (#852) It was sometimes unclear where we indexed by the output or the htlc id. This is a follow-up from discussions made in #539.
2021-06-21 22:01:47 +02:00
# local_htlc_signature = 304402207ff03eb0127fc7c6cae49cc29e2a586b98d1e8969cf4a17dfa50b9c2647720b902205e2ecfda2252956c0ca32f175080e75e4e390e433feb1f8ce9f2ba55648a1dac
htlc_timeout_tx (htlc #2): 020000000001018323148ce2419f21ca3d6780053747715832e18ac780931a514b187768882bb60100000000000000000124060000000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e050047304402207ceb6678d4db33d2401fdc409959e57c16a6cb97a30261d9c61f29b8c58d34b90220084b4a17b4ca0e86f2d798b3698ca52de5621f2ce86f80bed79afa66874511b00147304402207ff03eb0127fc7c6cae49cc29e2a586b98d1e8969cf4a17dfa50b9c2647720b902205e2ecfda2252956c0ca32f175080e75e4e390e433feb1f8ce9f2ba55648a1dac01008576a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c820120876475527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae67a914b43e1b38138a41b37f7cd9a1d274bc63e3a9b5d188ac6868f6010000
# signature for output #2 (htlc-success for htlc #1)
BOLT 3: update test vectors for new scripts and weight calculation. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-03-07 05:56:08 +01:00
remote_htlc_signature = 304402206a401b29a0dff0d18ec903502c13d83e7ec019450113f4a7655a4ce40d1f65ba0220217723a084e727b6ca0cc8b6c69c014a7e4a01fcdcba3e3993f462a3c574d833
Clarify Bolt 3 htlc tx output test vectors (#852) It was sometimes unclear where we indexed by the output or the htlc id. This is a follow-up from discussions made in #539.
2021-06-21 22:01:47 +02:00
# local_htlc_signature = 3045022100d50d067ca625d54e62df533a8f9291736678d0b86c28a61bb2a80cf42e702d6e02202373dde7e00218eacdafb9415fe0e1071beec1857d1af3c6a201a44cbc47c877
htlc_success_tx (htlc #1): 020000000001018323148ce2419f21ca3d6780053747715832e18ac780931a514b187768882bb6020000000000000000010a060000000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e050047304402206a401b29a0dff0d18ec903502c13d83e7ec019450113f4a7655a4ce40d1f65ba0220217723a084e727b6ca0cc8b6c69c014a7e4a01fcdcba3e3993f462a3c574d83301483045022100d50d067ca625d54e62df533a8f9291736678d0b86c28a61bb2a80cf42e702d6e02202373dde7e00218eacdafb9415fe0e1071beec1857d1af3c6a201a44cbc47c877012001010101010101010101010101010101010101010101010101010101010101018a76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c8201208763a9144b6b2e5444c2639cc0fb7bcea5afba3f3cdce23988527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae677502f501b175ac686800000000
# signature for output #3 (htlc-timeout for htlc #3)
BOLT 3: update test vectors for new scripts and weight calculation. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-03-07 05:56:08 +01:00
remote_htlc_signature = 30450221009b1c987ba599ee3bde1dbca776b85481d70a78b681a8d84206723e2795c7cac002207aac84ad910f8598c4d1c0ea2e3399cf6627a4e3e90131315bc9f038451ce39d
Clarify Bolt 3 htlc tx output test vectors (#852) It was sometimes unclear where we indexed by the output or the htlc id. This is a follow-up from discussions made in #539.
2021-06-21 22:01:47 +02:00
# local_htlc_signature = 3045022100db9dc65291077a52728c622987e9895b7241d4394d6dcb916d7600a3e8728c22022036ee3ee717ba0bb5c45ee84bc7bbf85c0f90f26ae4e4a25a6b4241afa8a3f1cb
htlc_timeout_tx (htlc #3): 020000000001018323148ce2419f21ca3d6780053747715832e18ac780931a514b187768882bb6030000000000000000010c0a0000000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e05004830450221009b1c987ba599ee3bde1dbca776b85481d70a78b681a8d84206723e2795c7cac002207aac84ad910f8598c4d1c0ea2e3399cf6627a4e3e90131315bc9f038451ce39d01483045022100db9dc65291077a52728c622987e9895b7241d4394d6dcb916d7600a3e8728c22022036ee3ee717ba0bb5c45ee84bc7bbf85c0f90f26ae4e4a25a6b4241afa8a3f1cb01008576a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c820120876475527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae67a9148a486ff2e31d6158bf39e2608864d63fefd09d5b88ac6868f7010000
# signature for output #4 (htlc-success for htlc #4)
BOLT 3: update test vectors for new scripts and weight calculation. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-03-07 05:56:08 +01:00
remote_htlc_signature = 3045022100cc28030b59f0914f45b84caa983b6f8effa900c952310708c2b5b00781117022022027ba2ccdf94d03c6d48b327f183f6e28c8a214d089b9227f94ac4f85315274f0
Clarify Bolt 3 htlc tx output test vectors (#852) It was sometimes unclear where we indexed by the output or the htlc id. This is a follow-up from discussions made in #539.
2021-06-21 22:01:47 +02:00
# local_htlc_signature = 304402202d1a3c0d31200265d2a2def2753ead4959ae20b4083e19553acfffa5dfab60bf022020ede134149504e15b88ab261a066de49848411e15e70f9e6a5462aec2949f8f
htlc_success_tx (htlc #4): 020000000001018323148ce2419f21ca3d6780053747715832e18ac780931a514b187768882bb604000000000000000001da0d0000000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e0500483045022100cc28030b59f0914f45b84caa983b6f8effa900c952310708c2b5b00781117022022027ba2ccdf94d03c6d48b327f183f6e28c8a214d089b9227f94ac4f85315274f00147304402202d1a3c0d31200265d2a2def2753ead4959ae20b4083e19553acfffa5dfab60bf022020ede134149504e15b88ab261a066de49848411e15e70f9e6a5462aec2949f8f012004040404040404040404040404040404040404040404040404040404040404048a76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c8201208763a91418bc1a114ccf9c052d3d23e28d3b0a9d1227434288527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae677502f801b175ac686800000000
make htlc outputs of the commitment tx spendable with revocation key (Merge conflict in test vectors fixed by selecting Pierre's, will have to be re-evaluated). Closes: #105
2017-02-10 12:23:32 +01:00
BOLT 1,2,3: first pass copy-edit; BOLT 1,2: minor header spacing fixes BOLT 3: first pass copy edit, according to capitalization, formatting stylesheet guidelines;
2017-11-18 22:04:58 +01:00
name: commitment tx with six outputs untrimmed (minimum feerate)
bolt3 fix and enhance tx testvectors (#99) This is a smerge of Fabrice Drouin and my work: he update them, I updated them and enhanced them, he found bugs, I re-derived them, etc. - rename keys properly - fix fees - sign all transactions - Derive test transaction vectors from minimal subset of parameters. - rewrite test vectors to test edge cases for trimming. - add funding tx test vector, make testable on regtest. This adds a funding transaction test (really, we only specify the output), but importantly adds enough information to duplicate a blockchain with that particular funding tx: $ rm -rf ~/.bitcoin/regtest/ $ bitcoind -regtest=1 & $ bitcoin-cli -regtest=1 submitblock 0000002006226e46111a0b59caaf126043eb5bbf28c34f3a5e332a1fc7b2b73cf188910fadbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fdc30f9858ffff7f20000000000101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff03510101ffffffff0100f2052a010000001976a9143ca33c2e4446f4a305f23c80df8ad1afdcf652f988ac00000000 $ bitcoin-cli -regtest=1 generate 431 $ bitcoin-cli -regtest=1 sendrawtransaction 0200000001adbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fd000000006b48304502210090587b6201e166ad6af0227d3036a9454223d49a1f11839c1a362184340ef0240220577f7cd5cca78719405cbf1de7414ac027f0239ef6e214c90fcaab0454d84b3b012103535b32d5eb0a6ed0982a0479bbadc9868d9836f6ba94dd5a63be16d875069184ffffffff028096980000000000220020c015c4a6be010e21657068fc2e6a9d02b27ebe4d490a25846f7237f104d1a3cd20256d29010000001600143ca33c2e4446f4a305f23c80df8ad1afdcf652f900000000 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-02-07 01:45:33 +01:00
to_local_msat: 6988000000
to_remote_msat: 3000000000
BOLT 3: update test vectors for new scripts and weight calculation. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-03-07 05:56:08 +01:00
local_feerate_per_kw: 648
# base commitment transaction fee = 914
# actual commitment transaction fee = 1914
Clarify Bolt 3 htlc tx output test vectors (#852) It was sometimes unclear where we indexed by the output or the htlc id. This is a follow-up from discussions made in #539.
2021-06-21 22:01:47 +02:00
# HTLC #2 offered amount 2000 wscript 76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c820120876475527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae67a914b43e1b38138a41b37f7cd9a1d274bc63e3a9b5d188ac6868
# HTLC #3 offered amount 3000 wscript 76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c820120876475527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae67a9148a486ff2e31d6158bf39e2608864d63fefd09d5b88ac6868
# HTLC #1 received amount 2000 wscript 76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c8201208763a9144b6b2e5444c2639cc0fb7bcea5afba3f3cdce23988527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae677502f501b175ac6868
# HTLC #4 received amount 4000 wscript 76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c8201208763a91418bc1a114ccf9c052d3d23e28d3b0a9d1227434288527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae677502f801b175ac6868
Underscores for all terms, not just fields. Plus a few more missing ones, and some consistency fixes in names as pointed out by Roasbeed and Fabrice. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-05-14 02:32:22 +02:00
# to_local amount 6987086 wscript 63210212a140cd0c6539d07cd08dfe09984dec3251ea808b892efeac3ede9402bf2b1967029000b2752103fd5960528dc152014952efdb702a88f71e3c1653b2314431701ec77e57fde83c68ac
# to_remote amount 3000000 P2WPKH(0394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b)
BOLT 3: update test vectors for new scripts and weight calculation. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-03-07 05:56:08 +01:00
remote_signature = 3044022072714e2fbb93cdd1c42eb0828b4f2eff143f717d8f26e79d6ada4f0dcb681bbe02200911be4e5161dd6ebe59ff1c58e1997c4aea804f81db6b698821db6093d7b057
# local_signature = 3045022100a2270d5950c89ae0841233f6efea9c951898b301b2e89e0adbd2c687b9f32efa02207943d90f95b9610458e7c65a576e149750ff3accaacad004cd85e70b235e27de
output commit_tx: 02000000000101bef67e4e2fb9ddeeb3461973cd4c62abb35050b1add772995b820b584a488489000000000038b02b8006d007000000000000220020403d394747cae42e98ff01734ad5c08f82ba123d3d9a620abda88989651e2ab5d007000000000000220020748eba944fedc8827f6b06bc44678f93c0f9e6078b35c6331ed31e75f8ce0c2db80b000000000000220020c20b5d1f8584fd90443e7b7b720136174fa4b9333c261d04dbbd012635c0f419a00f0000000000002200208c48d15160397c9731df9bc3b236656efb6665fbfe92b4a6878e88a499f741c4c0c62d0000000000160014ccf1af2f2aabee14bb40fa3851ab2301de8431104e9d6a00000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e0400483045022100a2270d5950c89ae0841233f6efea9c951898b301b2e89e0adbd2c687b9f32efa02207943d90f95b9610458e7c65a576e149750ff3accaacad004cd85e70b235e27de01473044022072714e2fbb93cdd1c42eb0828b4f2eff143f717d8f26e79d6ada4f0dcb681bbe02200911be4e5161dd6ebe59ff1c58e1997c4aea804f81db6b698821db6093d7b05701475221023da092f6980e58d2c037173180e9a465476026ee50f96695963e8efe436f54eb21030e9f7b623d2ccc7c9bd44d66d5ce21ce504c0acf6385a132cec6d3c39fa711c152ae3e195220
bolt3 fix and enhance tx testvectors (#99) This is a smerge of Fabrice Drouin and my work: he update them, I updated them and enhanced them, he found bugs, I re-derived them, etc. - rename keys properly - fix fees - sign all transactions - Derive test transaction vectors from minimal subset of parameters. - rewrite test vectors to test edge cases for trimming. - add funding tx test vector, make testable on regtest. This adds a funding transaction test (really, we only specify the output), but importantly adds enough information to duplicate a blockchain with that particular funding tx: $ rm -rf ~/.bitcoin/regtest/ $ bitcoind -regtest=1 & $ bitcoin-cli -regtest=1 submitblock 0000002006226e46111a0b59caaf126043eb5bbf28c34f3a5e332a1fc7b2b73cf188910fadbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fdc30f9858ffff7f20000000000101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff03510101ffffffff0100f2052a010000001976a9143ca33c2e4446f4a305f23c80df8ad1afdcf652f988ac00000000 $ bitcoin-cli -regtest=1 generate 431 $ bitcoin-cli -regtest=1 sendrawtransaction 0200000001adbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fd000000006b48304502210090587b6201e166ad6af0227d3036a9454223d49a1f11839c1a362184340ef0240220577f7cd5cca78719405cbf1de7414ac027f0239ef6e214c90fcaab0454d84b3b012103535b32d5eb0a6ed0982a0479bbadc9868d9836f6ba94dd5a63be16d875069184ffffffff028096980000000000220020c015c4a6be010e21657068fc2e6a9d02b27ebe4d490a25846f7237f104d1a3cd20256d29010000001600143ca33c2e4446f4a305f23c80df8ad1afdcf652f900000000 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-02-07 01:45:33 +01:00
num_htlcs: 4
Clarify Bolt 3 htlc tx output test vectors (#852) It was sometimes unclear where we indexed by the output or the htlc id. This is a follow-up from discussions made in #539.
2021-06-21 22:01:47 +02:00
# signature for output #0 (htlc-timeout for htlc #2)
BOLT 3: update test vectors for new scripts and weight calculation. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-03-07 05:56:08 +01:00
remote_htlc_signature = 3044022062ef2e77591409d60d7817d9bb1e71d3c4a2931d1a6c7c8307422c84f001a251022022dad9726b0ae3fe92bda745a06f2c00f92342a186d84518588cf65f4dfaada8
Clarify Bolt 3 htlc tx output test vectors (#852) It was sometimes unclear where we indexed by the output or the htlc id. This is a follow-up from discussions made in #539.
2021-06-21 22:01:47 +02:00
# local_htlc_signature = 3045022100a4c574f00411dd2f978ca5cdc1b848c311cd7849c087ad2f21a5bce5e8cc5ae90220090ae39a9bce2fb8bc879d7e9f9022df249f41e25e51f1a9bf6447a9eeffc098
htlc_timeout_tx (htlc #2): 02000000000101579c183eca9e8236a5d7f5dcd79cfec32c497fdc0ec61533cde99ecd436cadd10000000000000000000123060000000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e0500473044022062ef2e77591409d60d7817d9bb1e71d3c4a2931d1a6c7c8307422c84f001a251022022dad9726b0ae3fe92bda745a06f2c00f92342a186d84518588cf65f4dfaada801483045022100a4c574f00411dd2f978ca5cdc1b848c311cd7849c087ad2f21a5bce5e8cc5ae90220090ae39a9bce2fb8bc879d7e9f9022df249f41e25e51f1a9bf6447a9eeffc09801008576a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c820120876475527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae67a914b43e1b38138a41b37f7cd9a1d274bc63e3a9b5d188ac6868f6010000
# signature for output #1 (htlc-success for htlc #1)
BOLT 3: update test vectors for new scripts and weight calculation. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-03-07 05:56:08 +01:00
remote_htlc_signature = 3045022100e968cbbb5f402ed389fdc7f6cd2a80ed650bb42c79aeb2a5678444af94f6c78502204b47a1cb24ab5b0b6fe69fe9cfc7dba07b9dd0d8b95f372c1d9435146a88f8d4
Clarify Bolt 3 htlc tx output test vectors (#852) It was sometimes unclear where we indexed by the output or the htlc id. This is a follow-up from discussions made in #539.
2021-06-21 22:01:47 +02:00
# local_htlc_signature = 304402207679cf19790bea76a733d2fa0672bd43ab455687a068f815a3d237581f57139a0220683a1a799e102071c206b207735ca80f627ab83d6616b4bcd017c5d79ef3e7d0
htlc_success_tx (htlc #1): 02000000000101579c183eca9e8236a5d7f5dcd79cfec32c497fdc0ec61533cde99ecd436cadd10100000000000000000109060000000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e0500483045022100e968cbbb5f402ed389fdc7f6cd2a80ed650bb42c79aeb2a5678444af94f6c78502204b47a1cb24ab5b0b6fe69fe9cfc7dba07b9dd0d8b95f372c1d9435146a88f8d40147304402207679cf19790bea76a733d2fa0672bd43ab455687a068f815a3d237581f57139a0220683a1a799e102071c206b207735ca80f627ab83d6616b4bcd017c5d79ef3e7d0012001010101010101010101010101010101010101010101010101010101010101018a76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c8201208763a9144b6b2e5444c2639cc0fb7bcea5afba3f3cdce23988527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae677502f501b175ac686800000000
# signature for output #2 (htlc-timeout for htlc #3)
BOLT 3: update test vectors for new scripts and weight calculation. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-03-07 05:56:08 +01:00
remote_htlc_signature = 3045022100aa91932e305292cf9969cc23502bbf6cef83a5df39c95ad04a707c4f4fed5c7702207099fc0f3a9bfe1e7683c0e9aa5e76c5432eb20693bf4cb182f04d383dc9c8c2
Clarify Bolt 3 htlc tx output test vectors (#852) It was sometimes unclear where we indexed by the output or the htlc id. This is a follow-up from discussions made in #539.
2021-06-21 22:01:47 +02:00
# local_htlc_signature = 304402200df76fea718745f3c529bac7fd37923e7309ce38b25c0781e4cf514dd9ef8dc802204172295739dbae9fe0474dcee3608e3433b4b2af3a2e6787108b02f894dcdda3
htlc_timeout_tx (htlc #3): 02000000000101579c183eca9e8236a5d7f5dcd79cfec32c497fdc0ec61533cde99ecd436cadd1020000000000000000010b0a0000000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e0500483045022100aa91932e305292cf9969cc23502bbf6cef83a5df39c95ad04a707c4f4fed5c7702207099fc0f3a9bfe1e7683c0e9aa5e76c5432eb20693bf4cb182f04d383dc9c8c20147304402200df76fea718745f3c529bac7fd37923e7309ce38b25c0781e4cf514dd9ef8dc802204172295739dbae9fe0474dcee3608e3433b4b2af3a2e6787108b02f894dcdda301008576a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c820120876475527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae67a9148a486ff2e31d6158bf39e2608864d63fefd09d5b88ac6868f7010000
# signature for output #3 (htlc-success for htlc #4)
BOLT 3: update test vectors for new scripts and weight calculation. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-03-07 05:56:08 +01:00
remote_htlc_signature = 3044022035cac88040a5bba420b1c4257235d5015309113460bc33f2853cd81ca36e632402202fc94fd3e81e9d34a9d01782a0284f3044370d03d60f3fc041e2da088d2de58f
Clarify Bolt 3 htlc tx output test vectors (#852) It was sometimes unclear where we indexed by the output or the htlc id. This is a follow-up from discussions made in #539.
2021-06-21 22:01:47 +02:00
# local_htlc_signature = 304402200daf2eb7afd355b4caf6fb08387b5f031940ea29d1a9f35071288a839c9039e4022067201b562456e7948616c13acb876b386b511599b58ac1d94d127f91c50463a6
htlc_success_tx (htlc #4): 02000000000101579c183eca9e8236a5d7f5dcd79cfec32c497fdc0ec61533cde99ecd436cadd103000000000000000001d90d0000000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e0500473044022035cac88040a5bba420b1c4257235d5015309113460bc33f2853cd81ca36e632402202fc94fd3e81e9d34a9d01782a0284f3044370d03d60f3fc041e2da088d2de58f0147304402200daf2eb7afd355b4caf6fb08387b5f031940ea29d1a9f35071288a839c9039e4022067201b562456e7948616c13acb876b386b511599b58ac1d94d127f91c50463a6012004040404040404040404040404040404040404040404040404040404040404048a76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c8201208763a91418bc1a114ccf9c052d3d23e28d3b0a9d1227434288527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae677502f801b175ac686800000000
make htlc outputs of the commitment tx spendable with revocation key (Merge conflict in test vectors fixed by selecting Pierre's, will have to be re-evaluated). Closes: #105
2017-02-10 12:23:32 +01:00
BOLT 1,2,3: first pass copy-edit; BOLT 1,2: minor header spacing fixes BOLT 3: first pass copy edit, according to capitalization, formatting stylesheet guidelines;
2017-11-18 22:04:58 +01:00
name: commitment tx with six outputs untrimmed (maximum feerate)
bolt3 fix and enhance tx testvectors (#99) This is a smerge of Fabrice Drouin and my work: he update them, I updated them and enhanced them, he found bugs, I re-derived them, etc. - rename keys properly - fix fees - sign all transactions - Derive test transaction vectors from minimal subset of parameters. - rewrite test vectors to test edge cases for trimming. - add funding tx test vector, make testable on regtest. This adds a funding transaction test (really, we only specify the output), but importantly adds enough information to duplicate a blockchain with that particular funding tx: $ rm -rf ~/.bitcoin/regtest/ $ bitcoind -regtest=1 & $ bitcoin-cli -regtest=1 submitblock 0000002006226e46111a0b59caaf126043eb5bbf28c34f3a5e332a1fc7b2b73cf188910fadbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fdc30f9858ffff7f20000000000101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff03510101ffffffff0100f2052a010000001976a9143ca33c2e4446f4a305f23c80df8ad1afdcf652f988ac00000000 $ bitcoin-cli -regtest=1 generate 431 $ bitcoin-cli -regtest=1 sendrawtransaction 0200000001adbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fd000000006b48304502210090587b6201e166ad6af0227d3036a9454223d49a1f11839c1a362184340ef0240220577f7cd5cca78719405cbf1de7414ac027f0239ef6e214c90fcaab0454d84b3b012103535b32d5eb0a6ed0982a0479bbadc9868d9836f6ba94dd5a63be16d875069184ffffffff028096980000000000220020c015c4a6be010e21657068fc2e6a9d02b27ebe4d490a25846f7237f104d1a3cd20256d29010000001600143ca33c2e4446f4a305f23c80df8ad1afdcf652f900000000 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-02-07 01:45:33 +01:00
to_local_msat: 6988000000
to_remote_msat: 3000000000
BOLT 3: update test vectors for new scripts and weight calculation. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-03-07 05:56:08 +01:00
local_feerate_per_kw: 2069
# base commitment transaction fee = 2921
# actual commitment transaction fee = 3921
Clarify Bolt 3 htlc tx output test vectors (#852) It was sometimes unclear where we indexed by the output or the htlc id. This is a follow-up from discussions made in #539.
2021-06-21 22:01:47 +02:00
# HTLC #2 offered amount 2000 wscript 76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c820120876475527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae67a914b43e1b38138a41b37f7cd9a1d274bc63e3a9b5d188ac6868
# HTLC #3 offered amount 3000 wscript 76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c820120876475527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae67a9148a486ff2e31d6158bf39e2608864d63fefd09d5b88ac6868
# HTLC #1 received amount 2000 wscript 76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c8201208763a9144b6b2e5444c2639cc0fb7bcea5afba3f3cdce23988527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae677502f501b175ac6868
# HTLC #4 received amount 4000 wscript 76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c8201208763a91418bc1a114ccf9c052d3d23e28d3b0a9d1227434288527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae677502f801b175ac6868
Underscores for all terms, not just fields. Plus a few more missing ones, and some consistency fixes in names as pointed out by Roasbeed and Fabrice. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-05-14 02:32:22 +02:00
# to_local amount 6985079 wscript 63210212a140cd0c6539d07cd08dfe09984dec3251ea808b892efeac3ede9402bf2b1967029000b2752103fd5960528dc152014952efdb702a88f71e3c1653b2314431701ec77e57fde83c68ac
# to_remote amount 3000000 P2WPKH(0394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b)
BOLT 3: update test vectors for new scripts and weight calculation. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-03-07 05:56:08 +01:00
remote_signature = 3044022001d55e488b8b035b2dd29d50b65b530923a416d47f377284145bc8767b1b6a75022019bb53ddfe1cefaf156f924777eaaf8fdca1810695a7d0a247ad2afba8232eb4
# local_signature = 304402203ca8f31c6a47519f83255dc69f1894d9a6d7476a19f498d31eaf0cd3a85eeb63022026fd92dc752b33905c4c838c528b692a8ad4ced959990b5d5ee2ff940fa90eea
output commit_tx: 02000000000101bef67e4e2fb9ddeeb3461973cd4c62abb35050b1add772995b820b584a488489000000000038b02b8006d007000000000000220020403d394747cae42e98ff01734ad5c08f82ba123d3d9a620abda88989651e2ab5d007000000000000220020748eba944fedc8827f6b06bc44678f93c0f9e6078b35c6331ed31e75f8ce0c2db80b000000000000220020c20b5d1f8584fd90443e7b7b720136174fa4b9333c261d04dbbd012635c0f419a00f0000000000002200208c48d15160397c9731df9bc3b236656efb6665fbfe92b4a6878e88a499f741c4c0c62d0000000000160014ccf1af2f2aabee14bb40fa3851ab2301de84311077956a00000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e040047304402203ca8f31c6a47519f83255dc69f1894d9a6d7476a19f498d31eaf0cd3a85eeb63022026fd92dc752b33905c4c838c528b692a8ad4ced959990b5d5ee2ff940fa90eea01473044022001d55e488b8b035b2dd29d50b65b530923a416d47f377284145bc8767b1b6a75022019bb53ddfe1cefaf156f924777eaaf8fdca1810695a7d0a247ad2afba8232eb401475221023da092f6980e58d2c037173180e9a465476026ee50f96695963e8efe436f54eb21030e9f7b623d2ccc7c9bd44d66d5ce21ce504c0acf6385a132cec6d3c39fa711c152ae3e195220
bolt3 fix and enhance tx testvectors (#99) This is a smerge of Fabrice Drouin and my work: he update them, I updated them and enhanced them, he found bugs, I re-derived them, etc. - rename keys properly - fix fees - sign all transactions - Derive test transaction vectors from minimal subset of parameters. - rewrite test vectors to test edge cases for trimming. - add funding tx test vector, make testable on regtest. This adds a funding transaction test (really, we only specify the output), but importantly adds enough information to duplicate a blockchain with that particular funding tx: $ rm -rf ~/.bitcoin/regtest/ $ bitcoind -regtest=1 & $ bitcoin-cli -regtest=1 submitblock 0000002006226e46111a0b59caaf126043eb5bbf28c34f3a5e332a1fc7b2b73cf188910fadbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fdc30f9858ffff7f20000000000101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff03510101ffffffff0100f2052a010000001976a9143ca33c2e4446f4a305f23c80df8ad1afdcf652f988ac00000000 $ bitcoin-cli -regtest=1 generate 431 $ bitcoin-cli -regtest=1 sendrawtransaction 0200000001adbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fd000000006b48304502210090587b6201e166ad6af0227d3036a9454223d49a1f11839c1a362184340ef0240220577f7cd5cca78719405cbf1de7414ac027f0239ef6e214c90fcaab0454d84b3b012103535b32d5eb0a6ed0982a0479bbadc9868d9836f6ba94dd5a63be16d875069184ffffffff028096980000000000220020c015c4a6be010e21657068fc2e6a9d02b27ebe4d490a25846f7237f104d1a3cd20256d29010000001600143ca33c2e4446f4a305f23c80df8ad1afdcf652f900000000 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-02-07 01:45:33 +01:00
num_htlcs: 4
Clarify Bolt 3 htlc tx output test vectors (#852) It was sometimes unclear where we indexed by the output or the htlc id. This is a follow-up from discussions made in #539.
2021-06-21 22:01:47 +02:00
# signature for output #0 (htlc-timeout for htlc #2)
BOLT 3: update test vectors for new scripts and weight calculation. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-03-07 05:56:08 +01:00
remote_htlc_signature = 3045022100d1cf354de41c1369336cf85b225ed033f1f8982a01be503668df756a7e668b66022001254144fb4d0eecc61908fccc3388891ba17c5d7a1a8c62bdd307e5a513f992
Clarify Bolt 3 htlc tx output test vectors (#852) It was sometimes unclear where we indexed by the output or the htlc id. This is a follow-up from discussions made in #539.
2021-06-21 22:01:47 +02:00
# local_htlc_signature = 3044022056eb1af429660e45a1b0b66568cb8c4a3aa7e4c9c292d5d6c47f86ebf2c8838f022065c3ac4ebe980ca7a41148569be4ad8751b0a724a41405697ec55035dae66402
htlc_timeout_tx (htlc #2): 02000000000101ca94a9ad516ebc0c4bdd7b6254871babfa978d5accafb554214137d398bfcf6a0000000000000000000175020000000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e0500483045022100d1cf354de41c1369336cf85b225ed033f1f8982a01be503668df756a7e668b66022001254144fb4d0eecc61908fccc3388891ba17c5d7a1a8c62bdd307e5a513f99201473044022056eb1af429660e45a1b0b66568cb8c4a3aa7e4c9c292d5d6c47f86ebf2c8838f022065c3ac4ebe980ca7a41148569be4ad8751b0a724a41405697ec55035dae6640201008576a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c820120876475527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae67a914b43e1b38138a41b37f7cd9a1d274bc63e3a9b5d188ac6868f6010000
# signature for output #1 (htlc-success for htlc #1)
BOLT 3: update test vectors for new scripts and weight calculation. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-03-07 05:56:08 +01:00
remote_htlc_signature = 3045022100d065569dcb94f090345402736385efeb8ea265131804beac06dd84d15dd2d6880220664feb0b4b2eb985fadb6ec7dc58c9334ea88ce599a9be760554a2d4b3b5d9f4
Clarify Bolt 3 htlc tx output test vectors (#852) It was sometimes unclear where we indexed by the output or the htlc id. This is a follow-up from discussions made in #539.
2021-06-21 22:01:47 +02:00
# local_htlc_signature = 3045022100914bb232cd4b2690ee3d6cb8c3713c4ac9c4fb925323068d8b07f67c8541f8d9022057152f5f1615b793d2d45aac7518989ae4fe970f28b9b5c77504799d25433f7f
htlc_success_tx (htlc #1): 02000000000101ca94a9ad516ebc0c4bdd7b6254871babfa978d5accafb554214137d398bfcf6a0100000000000000000122020000000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e0500483045022100d065569dcb94f090345402736385efeb8ea265131804beac06dd84d15dd2d6880220664feb0b4b2eb985fadb6ec7dc58c9334ea88ce599a9be760554a2d4b3b5d9f401483045022100914bb232cd4b2690ee3d6cb8c3713c4ac9c4fb925323068d8b07f67c8541f8d9022057152f5f1615b793d2d45aac7518989ae4fe970f28b9b5c77504799d25433f7f012001010101010101010101010101010101010101010101010101010101010101018a76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c8201208763a9144b6b2e5444c2639cc0fb7bcea5afba3f3cdce23988527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae677502f501b175ac686800000000
# signature for output #2 (htlc-timeout for htlc #3)
BOLT 3: update test vectors for new scripts and weight calculation. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-03-07 05:56:08 +01:00
remote_htlc_signature = 3045022100d4e69d363de993684eae7b37853c40722a4c1b4a7b588ad7b5d8a9b5006137a102207a069c628170ee34be5612747051bdcc087466dbaa68d5756ea81c10155aef18
Clarify Bolt 3 htlc tx output test vectors (#852) It was sometimes unclear where we indexed by the output or the htlc id. This is a follow-up from discussions made in #539.
2021-06-21 22:01:47 +02:00
# local_htlc_signature = 304402200e362443f7af830b419771e8e1614fc391db3a4eb799989abfc5ab26d6fcd032022039ab0cad1c14dfbe9446bf847965e56fe016e0cbcf719fd18c1bfbf53ecbd9f9
htlc_timeout_tx (htlc #3): 02000000000101ca94a9ad516ebc0c4bdd7b6254871babfa978d5accafb554214137d398bfcf6a020000000000000000015d060000000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e0500483045022100d4e69d363de993684eae7b37853c40722a4c1b4a7b588ad7b5d8a9b5006137a102207a069c628170ee34be5612747051bdcc087466dbaa68d5756ea81c10155aef180147304402200e362443f7af830b419771e8e1614fc391db3a4eb799989abfc5ab26d6fcd032022039ab0cad1c14dfbe9446bf847965e56fe016e0cbcf719fd18c1bfbf53ecbd9f901008576a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c820120876475527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae67a9148a486ff2e31d6158bf39e2608864d63fefd09d5b88ac6868f7010000
# signature for output #3 (htlc-success for htlc #4)
BOLT 3: update test vectors for new scripts and weight calculation. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-03-07 05:56:08 +01:00
remote_htlc_signature = 30450221008ec888e36e4a4b3dc2ed6b823319855b2ae03006ca6ae0d9aa7e24bfc1d6f07102203b0f78885472a67ff4fe5916c0bb669487d659527509516fc3a08e87a2cc0a7c
Clarify Bolt 3 htlc tx output test vectors (#852) It was sometimes unclear where we indexed by the output or the htlc id. This is a follow-up from discussions made in #539.
2021-06-21 22:01:47 +02:00
# local_htlc_signature = 304402202c3e14282b84b02705dfd00a6da396c9fe8a8bcb1d3fdb4b20a4feba09440e8b02202b058b39aa9b0c865b22095edcd9ff1f71bbfe20aa4993755e54d042755ed0d5
htlc_success_tx (htlc #4): 02000000000101ca94a9ad516ebc0c4bdd7b6254871babfa978d5accafb554214137d398bfcf6a03000000000000000001f2090000000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e05004830450221008ec888e36e4a4b3dc2ed6b823319855b2ae03006ca6ae0d9aa7e24bfc1d6f07102203b0f78885472a67ff4fe5916c0bb669487d659527509516fc3a08e87a2cc0a7c0147304402202c3e14282b84b02705dfd00a6da396c9fe8a8bcb1d3fdb4b20a4feba09440e8b02202b058b39aa9b0c865b22095edcd9ff1f71bbfe20aa4993755e54d042755ed0d5012004040404040404040404040404040404040404040404040404040404040404048a76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c8201208763a91418bc1a114ccf9c052d3d23e28d3b0a9d1227434288527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae677502f801b175ac686800000000
make htlc outputs of the commitment tx spendable with revocation key (Merge conflict in test vectors fixed by selecting Pierre's, will have to be re-evaluated). Closes: #105
2017-02-10 12:23:32 +01:00
BOLT 1,2,3: first pass copy-edit; BOLT 1,2: minor header spacing fixes BOLT 3: first pass copy edit, according to capitalization, formatting stylesheet guidelines;
2017-11-18 22:04:58 +01:00
name: commitment tx with five outputs untrimmed (minimum feerate)
bolt3 fix and enhance tx testvectors (#99) This is a smerge of Fabrice Drouin and my work: he update them, I updated them and enhanced them, he found bugs, I re-derived them, etc. - rename keys properly - fix fees - sign all transactions - Derive test transaction vectors from minimal subset of parameters. - rewrite test vectors to test edge cases for trimming. - add funding tx test vector, make testable on regtest. This adds a funding transaction test (really, we only specify the output), but importantly adds enough information to duplicate a blockchain with that particular funding tx: $ rm -rf ~/.bitcoin/regtest/ $ bitcoind -regtest=1 & $ bitcoin-cli -regtest=1 submitblock 0000002006226e46111a0b59caaf126043eb5bbf28c34f3a5e332a1fc7b2b73cf188910fadbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fdc30f9858ffff7f20000000000101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff03510101ffffffff0100f2052a010000001976a9143ca33c2e4446f4a305f23c80df8ad1afdcf652f988ac00000000 $ bitcoin-cli -regtest=1 generate 431 $ bitcoin-cli -regtest=1 sendrawtransaction 0200000001adbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fd000000006b48304502210090587b6201e166ad6af0227d3036a9454223d49a1f11839c1a362184340ef0240220577f7cd5cca78719405cbf1de7414ac027f0239ef6e214c90fcaab0454d84b3b012103535b32d5eb0a6ed0982a0479bbadc9868d9836f6ba94dd5a63be16d875069184ffffffff028096980000000000220020c015c4a6be010e21657068fc2e6a9d02b27ebe4d490a25846f7237f104d1a3cd20256d29010000001600143ca33c2e4446f4a305f23c80df8ad1afdcf652f900000000 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-02-07 01:45:33 +01:00
to_local_msat: 6988000000
to_remote_msat: 3000000000
BOLT 3: update test vectors for new scripts and weight calculation. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-03-07 05:56:08 +01:00
local_feerate_per_kw: 2070
# base commitment transaction fee = 2566
# actual commitment transaction fee = 5566
Clarify Bolt 3 htlc tx output test vectors (#852) It was sometimes unclear where we indexed by the output or the htlc id. This is a follow-up from discussions made in #539.
2021-06-21 22:01:47 +02:00
# HTLC #2 offered amount 2000 wscript 76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c820120876475527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae67a914b43e1b38138a41b37f7cd9a1d274bc63e3a9b5d188ac6868
# HTLC #3 offered amount 3000 wscript 76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c820120876475527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae67a9148a486ff2e31d6158bf39e2608864d63fefd09d5b88ac6868
# HTLC #4 received amount 4000 wscript 76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c8201208763a91418bc1a114ccf9c052d3d23e28d3b0a9d1227434288527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae677502f801b175ac6868
Underscores for all terms, not just fields. Plus a few more missing ones, and some consistency fixes in names as pointed out by Roasbeed and Fabrice. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-05-14 02:32:22 +02:00
# to_local amount 6985434 wscript 63210212a140cd0c6539d07cd08dfe09984dec3251ea808b892efeac3ede9402bf2b1967029000b2752103fd5960528dc152014952efdb702a88f71e3c1653b2314431701ec77e57fde83c68ac
# to_remote amount 3000000 P2WPKH(0394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b)
BOLT 3: update test vectors for new scripts and weight calculation. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-03-07 05:56:08 +01:00
remote_signature = 3045022100f2377f7a67b7fc7f4e2c0c9e3a7de935c32417f5668eda31ea1db401b7dc53030220415fdbc8e91d0f735e70c21952342742e25249b0d062d43efbfc564499f37526
# local_signature = 30440220443cb07f650aebbba14b8bc8d81e096712590f524c5991ac0ed3bbc8fd3bd0c7022028a635f548e3ca64b19b69b1ea00f05b22752f91daf0b6dab78e62ba52eb7fd0
output commit_tx: 02000000000101bef67e4e2fb9ddeeb3461973cd4c62abb35050b1add772995b820b584a488489000000000038b02b8005d007000000000000220020403d394747cae42e98ff01734ad5c08f82ba123d3d9a620abda88989651e2ab5b80b000000000000220020c20b5d1f8584fd90443e7b7b720136174fa4b9333c261d04dbbd012635c0f419a00f0000000000002200208c48d15160397c9731df9bc3b236656efb6665fbfe92b4a6878e88a499f741c4c0c62d0000000000160014ccf1af2f2aabee14bb40fa3851ab2301de843110da966a00000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e04004730440220443cb07f650aebbba14b8bc8d81e096712590f524c5991ac0ed3bbc8fd3bd0c7022028a635f548e3ca64b19b69b1ea00f05b22752f91daf0b6dab78e62ba52eb7fd001483045022100f2377f7a67b7fc7f4e2c0c9e3a7de935c32417f5668eda31ea1db401b7dc53030220415fdbc8e91d0f735e70c21952342742e25249b0d062d43efbfc564499f3752601475221023da092f6980e58d2c037173180e9a465476026ee50f96695963e8efe436f54eb21030e9f7b623d2ccc7c9bd44d66d5ce21ce504c0acf6385a132cec6d3c39fa711c152ae3e195220
bolt3 fix and enhance tx testvectors (#99) This is a smerge of Fabrice Drouin and my work: he update them, I updated them and enhanced them, he found bugs, I re-derived them, etc. - rename keys properly - fix fees - sign all transactions - Derive test transaction vectors from minimal subset of parameters. - rewrite test vectors to test edge cases for trimming. - add funding tx test vector, make testable on regtest. This adds a funding transaction test (really, we only specify the output), but importantly adds enough information to duplicate a blockchain with that particular funding tx: $ rm -rf ~/.bitcoin/regtest/ $ bitcoind -regtest=1 & $ bitcoin-cli -regtest=1 submitblock 0000002006226e46111a0b59caaf126043eb5bbf28c34f3a5e332a1fc7b2b73cf188910fadbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fdc30f9858ffff7f20000000000101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff03510101ffffffff0100f2052a010000001976a9143ca33c2e4446f4a305f23c80df8ad1afdcf652f988ac00000000 $ bitcoin-cli -regtest=1 generate 431 $ bitcoin-cli -regtest=1 sendrawtransaction 0200000001adbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fd000000006b48304502210090587b6201e166ad6af0227d3036a9454223d49a1f11839c1a362184340ef0240220577f7cd5cca78719405cbf1de7414ac027f0239ef6e214c90fcaab0454d84b3b012103535b32d5eb0a6ed0982a0479bbadc9868d9836f6ba94dd5a63be16d875069184ffffffff028096980000000000220020c015c4a6be010e21657068fc2e6a9d02b27ebe4d490a25846f7237f104d1a3cd20256d29010000001600143ca33c2e4446f4a305f23c80df8ad1afdcf652f900000000 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-02-07 01:45:33 +01:00
num_htlcs: 3
Clarify Bolt 3 htlc tx output test vectors (#852) It was sometimes unclear where we indexed by the output or the htlc id. This is a follow-up from discussions made in #539.
2021-06-21 22:01:47 +02:00
# signature for output #0 (htlc-timeout for htlc #2)
BOLT 3: update test vectors for new scripts and weight calculation. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-03-07 05:56:08 +01:00
remote_htlc_signature = 3045022100eed143b1ee4bed5dc3cde40afa5db3e7354cbf9c44054b5f713f729356f08cf7022077161d171c2bbd9badf3c9934de65a4918de03bbac1450f715275f75b103f891
Clarify Bolt 3 htlc tx output test vectors (#852) It was sometimes unclear where we indexed by the output or the htlc id. This is a follow-up from discussions made in #539.
2021-06-21 22:01:47 +02:00
# local_htlc_signature = 3045022100a0d043ed533e7fb1911e0553d31a8e2f3e6de19dbc035257f29d747c5e02f1f5022030cd38d8e84282175d49c1ebe0470db3ebd59768cf40780a784e248a43904fb8
htlc_timeout_tx (htlc #2): 0200000000010140a83ce364747ff277f4d7595d8d15f708418798922c40bc2b056aca5485a2180000000000000000000174020000000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e0500483045022100eed143b1ee4bed5dc3cde40afa5db3e7354cbf9c44054b5f713f729356f08cf7022077161d171c2bbd9badf3c9934de65a4918de03bbac1450f715275f75b103f89101483045022100a0d043ed533e7fb1911e0553d31a8e2f3e6de19dbc035257f29d747c5e02f1f5022030cd38d8e84282175d49c1ebe0470db3ebd59768cf40780a784e248a43904fb801008576a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c820120876475527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae67a914b43e1b38138a41b37f7cd9a1d274bc63e3a9b5d188ac6868f6010000
# signature for output #1 (htlc-timeout for htlc #3)
BOLT 3: update test vectors for new scripts and weight calculation. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-03-07 05:56:08 +01:00
remote_htlc_signature = 3044022071e9357619fd8d29a411dc053b326a5224c5d11268070e88ecb981b174747c7a02202b763ae29a9d0732fa8836dd8597439460b50472183f420021b768981b4f7cf6
Clarify Bolt 3 htlc tx output test vectors (#852) It was sometimes unclear where we indexed by the output or the htlc id. This is a follow-up from discussions made in #539.
2021-06-21 22:01:47 +02:00
# local_htlc_signature = 3045022100adb1d679f65f96178b59f23ed37d3b70443118f345224a07ecb043eee2acc157022034d24524fe857144a3bcfff3065a9994d0a6ec5f11c681e49431d573e242612d
htlc_timeout_tx (htlc #3): 0200000000010140a83ce364747ff277f4d7595d8d15f708418798922c40bc2b056aca5485a218010000000000000000015c060000000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e0500473044022071e9357619fd8d29a411dc053b326a5224c5d11268070e88ecb981b174747c7a02202b763ae29a9d0732fa8836dd8597439460b50472183f420021b768981b4f7cf601483045022100adb1d679f65f96178b59f23ed37d3b70443118f345224a07ecb043eee2acc157022034d24524fe857144a3bcfff3065a9994d0a6ec5f11c681e49431d573e242612d01008576a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c820120876475527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae67a9148a486ff2e31d6158bf39e2608864d63fefd09d5b88ac6868f7010000
# signature for output #2 (htlc-success for htlc #4)
BOLT 3: update test vectors for new scripts and weight calculation. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-03-07 05:56:08 +01:00
remote_htlc_signature = 3045022100c9458a4d2cbb741705577deb0a890e5cb90ee141be0400d3162e533727c9cb2102206edcf765c5dc5e5f9b976ea8149bf8607b5a0efb30691138e1231302b640d2a4
Clarify Bolt 3 htlc tx output test vectors (#852) It was sometimes unclear where we indexed by the output or the htlc id. This is a follow-up from discussions made in #539.
2021-06-21 22:01:47 +02:00
# local_htlc_signature = 304402200831422aa4e1ee6d55e0b894201770a8f8817a189356f2d70be76633ffa6a6f602200dd1b84a4855dc6727dd46c98daae43dfc70889d1ba7ef0087529a57c06e5e04
htlc_success_tx (htlc #4): 0200000000010140a83ce364747ff277f4d7595d8d15f708418798922c40bc2b056aca5485a21802000000000000000001f1090000000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e0500483045022100c9458a4d2cbb741705577deb0a890e5cb90ee141be0400d3162e533727c9cb2102206edcf765c5dc5e5f9b976ea8149bf8607b5a0efb30691138e1231302b640d2a40147304402200831422aa4e1ee6d55e0b894201770a8f8817a189356f2d70be76633ffa6a6f602200dd1b84a4855dc6727dd46c98daae43dfc70889d1ba7ef0087529a57c06e5e04012004040404040404040404040404040404040404040404040404040404040404048a76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c8201208763a91418bc1a114ccf9c052d3d23e28d3b0a9d1227434288527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae677502f801b175ac686800000000
make htlc outputs of the commitment tx spendable with revocation key (Merge conflict in test vectors fixed by selecting Pierre's, will have to be re-evaluated). Closes: #105
2017-02-10 12:23:32 +01:00
BOLT 1,2,3: first pass copy-edit; BOLT 1,2: minor header spacing fixes BOLT 3: first pass copy edit, according to capitalization, formatting stylesheet guidelines;
2017-11-18 22:04:58 +01:00
name: commitment tx with five outputs untrimmed (maximum feerate)
bolt3 fix and enhance tx testvectors (#99) This is a smerge of Fabrice Drouin and my work: he update them, I updated them and enhanced them, he found bugs, I re-derived them, etc. - rename keys properly - fix fees - sign all transactions - Derive test transaction vectors from minimal subset of parameters. - rewrite test vectors to test edge cases for trimming. - add funding tx test vector, make testable on regtest. This adds a funding transaction test (really, we only specify the output), but importantly adds enough information to duplicate a blockchain with that particular funding tx: $ rm -rf ~/.bitcoin/regtest/ $ bitcoind -regtest=1 & $ bitcoin-cli -regtest=1 submitblock 0000002006226e46111a0b59caaf126043eb5bbf28c34f3a5e332a1fc7b2b73cf188910fadbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fdc30f9858ffff7f20000000000101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff03510101ffffffff0100f2052a010000001976a9143ca33c2e4446f4a305f23c80df8ad1afdcf652f988ac00000000 $ bitcoin-cli -regtest=1 generate 431 $ bitcoin-cli -regtest=1 sendrawtransaction 0200000001adbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fd000000006b48304502210090587b6201e166ad6af0227d3036a9454223d49a1f11839c1a362184340ef0240220577f7cd5cca78719405cbf1de7414ac027f0239ef6e214c90fcaab0454d84b3b012103535b32d5eb0a6ed0982a0479bbadc9868d9836f6ba94dd5a63be16d875069184ffffffff028096980000000000220020c015c4a6be010e21657068fc2e6a9d02b27ebe4d490a25846f7237f104d1a3cd20256d29010000001600143ca33c2e4446f4a305f23c80df8ad1afdcf652f900000000 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-02-07 01:45:33 +01:00
to_local_msat: 6988000000
to_remote_msat: 3000000000
BOLT 3: update test vectors for new scripts and weight calculation. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-03-07 05:56:08 +01:00
local_feerate_per_kw: 2194
# base commitment transaction fee = 2720
# actual commitment transaction fee = 5720
Clarify Bolt 3 htlc tx output test vectors (#852) It was sometimes unclear where we indexed by the output or the htlc id. This is a follow-up from discussions made in #539.
2021-06-21 22:01:47 +02:00
# HTLC #2 offered amount 2000 wscript 76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c820120876475527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae67a914b43e1b38138a41b37f7cd9a1d274bc63e3a9b5d188ac6868
# HTLC #3 offered amount 3000 wscript 76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c820120876475527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae67a9148a486ff2e31d6158bf39e2608864d63fefd09d5b88ac6868
# HTLC #4 received amount 4000 wscript 76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c8201208763a91418bc1a114ccf9c052d3d23e28d3b0a9d1227434288527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae677502f801b175ac6868
Underscores for all terms, not just fields. Plus a few more missing ones, and some consistency fixes in names as pointed out by Roasbeed and Fabrice. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-05-14 02:32:22 +02:00
# to_local amount 6985280 wscript 63210212a140cd0c6539d07cd08dfe09984dec3251ea808b892efeac3ede9402bf2b1967029000b2752103fd5960528dc152014952efdb702a88f71e3c1653b2314431701ec77e57fde83c68ac
# to_remote amount 3000000 P2WPKH(0394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b)
BOLT 3: update test vectors for new scripts and weight calculation. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-03-07 05:56:08 +01:00
remote_signature = 3045022100d33c4e541aa1d255d41ea9a3b443b3b822ad8f7f86862638aac1f69f8f760577022007e2a18e6931ce3d3a804b1c78eda1de17dbe1fb7a95488c9a4ec86203953348
# local_signature = 304402203b1b010c109c2ecbe7feb2d259b9c4126bd5dc99ee693c422ec0a5781fe161ba0220571fe4e2c649dea9c7aaf7e49b382962f6a3494963c97d80fef9a430ca3f7061
output commit_tx: 02000000000101bef67e4e2fb9ddeeb3461973cd4c62abb35050b1add772995b820b584a488489000000000038b02b8005d007000000000000220020403d394747cae42e98ff01734ad5c08f82ba123d3d9a620abda88989651e2ab5b80b000000000000220020c20b5d1f8584fd90443e7b7b720136174fa4b9333c261d04dbbd012635c0f419a00f0000000000002200208c48d15160397c9731df9bc3b236656efb6665fbfe92b4a6878e88a499f741c4c0c62d0000000000160014ccf1af2f2aabee14bb40fa3851ab2301de84311040966a00000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e040047304402203b1b010c109c2ecbe7feb2d259b9c4126bd5dc99ee693c422ec0a5781fe161ba0220571fe4e2c649dea9c7aaf7e49b382962f6a3494963c97d80fef9a430ca3f706101483045022100d33c4e541aa1d255d41ea9a3b443b3b822ad8f7f86862638aac1f69f8f760577022007e2a18e6931ce3d3a804b1c78eda1de17dbe1fb7a95488c9a4ec8620395334801475221023da092f6980e58d2c037173180e9a465476026ee50f96695963e8efe436f54eb21030e9f7b623d2ccc7c9bd44d66d5ce21ce504c0acf6385a132cec6d3c39fa711c152ae3e195220
bolt3 fix and enhance tx testvectors (#99) This is a smerge of Fabrice Drouin and my work: he update them, I updated them and enhanced them, he found bugs, I re-derived them, etc. - rename keys properly - fix fees - sign all transactions - Derive test transaction vectors from minimal subset of parameters. - rewrite test vectors to test edge cases for trimming. - add funding tx test vector, make testable on regtest. This adds a funding transaction test (really, we only specify the output), but importantly adds enough information to duplicate a blockchain with that particular funding tx: $ rm -rf ~/.bitcoin/regtest/ $ bitcoind -regtest=1 & $ bitcoin-cli -regtest=1 submitblock 0000002006226e46111a0b59caaf126043eb5bbf28c34f3a5e332a1fc7b2b73cf188910fadbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fdc30f9858ffff7f20000000000101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff03510101ffffffff0100f2052a010000001976a9143ca33c2e4446f4a305f23c80df8ad1afdcf652f988ac00000000 $ bitcoin-cli -regtest=1 generate 431 $ bitcoin-cli -regtest=1 sendrawtransaction 0200000001adbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fd000000006b48304502210090587b6201e166ad6af0227d3036a9454223d49a1f11839c1a362184340ef0240220577f7cd5cca78719405cbf1de7414ac027f0239ef6e214c90fcaab0454d84b3b012103535b32d5eb0a6ed0982a0479bbadc9868d9836f6ba94dd5a63be16d875069184ffffffff028096980000000000220020c015c4a6be010e21657068fc2e6a9d02b27ebe4d490a25846f7237f104d1a3cd20256d29010000001600143ca33c2e4446f4a305f23c80df8ad1afdcf652f900000000 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-02-07 01:45:33 +01:00
num_htlcs: 3
Clarify Bolt 3 htlc tx output test vectors (#852) It was sometimes unclear where we indexed by the output or the htlc id. This is a follow-up from discussions made in #539.
2021-06-21 22:01:47 +02:00
# signature for output #0 (htlc-timeout for htlc #2)
BOLT 3: update test vectors for new scripts and weight calculation. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-03-07 05:56:08 +01:00
remote_htlc_signature = 30450221009ed2f0a67f99e29c3c8cf45c08207b765980697781bb727fe0b1416de0e7622902206052684229bc171419ed290f4b615c943f819c0262414e43c5b91dcf72ddcf44
Clarify Bolt 3 htlc tx output test vectors (#852) It was sometimes unclear where we indexed by the output or the htlc id. This is a follow-up from discussions made in #539.
2021-06-21 22:01:47 +02:00
# local_htlc_signature = 3044022004ad5f04ae69c71b3b141d4db9d0d4c38d84009fb3cfeeae6efdad414487a9a0022042d3fe1388c1ff517d1da7fb4025663d372c14728ed52dc88608363450ff6a2f
htlc_timeout_tx (htlc #2): 02000000000101fb824d4e4dafc0f567789dee3a6bce8d411fe80f5563d8cdfdcc7d7e4447d43a0000000000000000000122020000000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e05004830450221009ed2f0a67f99e29c3c8cf45c08207b765980697781bb727fe0b1416de0e7622902206052684229bc171419ed290f4b615c943f819c0262414e43c5b91dcf72ddcf4401473044022004ad5f04ae69c71b3b141d4db9d0d4c38d84009fb3cfeeae6efdad414487a9a0022042d3fe1388c1ff517d1da7fb4025663d372c14728ed52dc88608363450ff6a2f01008576a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c820120876475527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae67a914b43e1b38138a41b37f7cd9a1d274bc63e3a9b5d188ac6868f6010000
# signature for output #1 (htlc-timeout for htlc #3)
BOLT 3: update test vectors for new scripts and weight calculation. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-03-07 05:56:08 +01:00
remote_htlc_signature = 30440220155d3b90c67c33a8321996a9be5b82431b0c126613be751d400669da9d5c696702204318448bcd48824439d2c6a70be6e5747446be47ff45977cf41672bdc9b6b12d
Clarify Bolt 3 htlc tx output test vectors (#852) It was sometimes unclear where we indexed by the output or the htlc id. This is a follow-up from discussions made in #539.
2021-06-21 22:01:47 +02:00
# local_htlc_signature = 304402201707050c870c1f77cc3ed58d6d71bf281de239e9eabd8ef0955bad0d7fe38dcc02204d36d80d0019b3a71e646a08fa4a5607761d341ae8be371946ebe437c289c915
htlc_timeout_tx (htlc #3): 02000000000101fb824d4e4dafc0f567789dee3a6bce8d411fe80f5563d8cdfdcc7d7e4447d43a010000000000000000010a060000000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e05004730440220155d3b90c67c33a8321996a9be5b82431b0c126613be751d400669da9d5c696702204318448bcd48824439d2c6a70be6e5747446be47ff45977cf41672bdc9b6b12d0147304402201707050c870c1f77cc3ed58d6d71bf281de239e9eabd8ef0955bad0d7fe38dcc02204d36d80d0019b3a71e646a08fa4a5607761d341ae8be371946ebe437c289c91501008576a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c820120876475527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae67a9148a486ff2e31d6158bf39e2608864d63fefd09d5b88ac6868f7010000
# signature for output #2 (htlc-success for htlc #4)
BOLT 3: update test vectors for new scripts and weight calculation. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-03-07 05:56:08 +01:00
remote_htlc_signature = 3045022100a12a9a473ece548584aabdd051779025a5ed4077c4b7aa376ec7a0b1645e5a48022039490b333f53b5b3e2ddde1d809e492cba2b3e5fc3a436cd3ffb4cd3d500fa5a
Clarify Bolt 3 htlc tx output test vectors (#852) It was sometimes unclear where we indexed by the output or the htlc id. This is a follow-up from discussions made in #539.
2021-06-21 22:01:47 +02:00
# local_htlc_signature = 3045022100ff200bc934ab26ce9a559e998ceb0aee53bc40368e114ab9d3054d9960546e2802202496856ca163ac12c143110b6b3ac9d598df7254f2e17b3b94c3ab5301f4c3b0
htlc_success_tx (htlc #4): 02000000000101fb824d4e4dafc0f567789dee3a6bce8d411fe80f5563d8cdfdcc7d7e4447d43a020000000000000000019a090000000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e0500483045022100a12a9a473ece548584aabdd051779025a5ed4077c4b7aa376ec7a0b1645e5a48022039490b333f53b5b3e2ddde1d809e492cba2b3e5fc3a436cd3ffb4cd3d500fa5a01483045022100ff200bc934ab26ce9a559e998ceb0aee53bc40368e114ab9d3054d9960546e2802202496856ca163ac12c143110b6b3ac9d598df7254f2e17b3b94c3ab5301f4c3b0012004040404040404040404040404040404040404040404040404040404040404048a76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c8201208763a91418bc1a114ccf9c052d3d23e28d3b0a9d1227434288527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae677502f801b175ac686800000000
make htlc outputs of the commitment tx spendable with revocation key (Merge conflict in test vectors fixed by selecting Pierre's, will have to be re-evaluated). Closes: #105
2017-02-10 12:23:32 +01:00
BOLT 1,2,3: first pass copy-edit; BOLT 1,2: minor header spacing fixes BOLT 3: first pass copy edit, according to capitalization, formatting stylesheet guidelines;
2017-11-18 22:04:58 +01:00
name: commitment tx with four outputs untrimmed (minimum feerate)
bolt3 fix and enhance tx testvectors (#99) This is a smerge of Fabrice Drouin and my work: he update them, I updated them and enhanced them, he found bugs, I re-derived them, etc. - rename keys properly - fix fees - sign all transactions - Derive test transaction vectors from minimal subset of parameters. - rewrite test vectors to test edge cases for trimming. - add funding tx test vector, make testable on regtest. This adds a funding transaction test (really, we only specify the output), but importantly adds enough information to duplicate a blockchain with that particular funding tx: $ rm -rf ~/.bitcoin/regtest/ $ bitcoind -regtest=1 & $ bitcoin-cli -regtest=1 submitblock 0000002006226e46111a0b59caaf126043eb5bbf28c34f3a5e332a1fc7b2b73cf188910fadbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fdc30f9858ffff7f20000000000101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff03510101ffffffff0100f2052a010000001976a9143ca33c2e4446f4a305f23c80df8ad1afdcf652f988ac00000000 $ bitcoin-cli -regtest=1 generate 431 $ bitcoin-cli -regtest=1 sendrawtransaction 0200000001adbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fd000000006b48304502210090587b6201e166ad6af0227d3036a9454223d49a1f11839c1a362184340ef0240220577f7cd5cca78719405cbf1de7414ac027f0239ef6e214c90fcaab0454d84b3b012103535b32d5eb0a6ed0982a0479bbadc9868d9836f6ba94dd5a63be16d875069184ffffffff028096980000000000220020c015c4a6be010e21657068fc2e6a9d02b27ebe4d490a25846f7237f104d1a3cd20256d29010000001600143ca33c2e4446f4a305f23c80df8ad1afdcf652f900000000 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-02-07 01:45:33 +01:00
to_local_msat: 6988000000
to_remote_msat: 3000000000
BOLT 3: update test vectors for new scripts and weight calculation. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-03-07 05:56:08 +01:00
local_feerate_per_kw: 2195
# base commitment transaction fee = 2344
# actual commitment transaction fee = 7344
Clarify Bolt 3 htlc tx output test vectors (#852) It was sometimes unclear where we indexed by the output or the htlc id. This is a follow-up from discussions made in #539.
2021-06-21 22:01:47 +02:00
# HTLC #3 offered amount 3000 wscript 76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c820120876475527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae67a9148a486ff2e31d6158bf39e2608864d63fefd09d5b88ac6868
# HTLC #4 received amount 4000 wscript 76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c8201208763a91418bc1a114ccf9c052d3d23e28d3b0a9d1227434288527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae677502f801b175ac6868
Underscores for all terms, not just fields. Plus a few more missing ones, and some consistency fixes in names as pointed out by Roasbeed and Fabrice. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-05-14 02:32:22 +02:00
# to_local amount 6985656 wscript 63210212a140cd0c6539d07cd08dfe09984dec3251ea808b892efeac3ede9402bf2b1967029000b2752103fd5960528dc152014952efdb702a88f71e3c1653b2314431701ec77e57fde83c68ac
# to_remote amount 3000000 P2WPKH(0394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b)
BOLT 3: update test vectors for new scripts and weight calculation. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-03-07 05:56:08 +01:00
remote_signature = 304402205e2f76d4657fb732c0dfc820a18a7301e368f5799e06b7828007633741bda6df0220458009ae59d0c6246065c419359e05eb2a4b4ef4a1b310cc912db44eb7924298
# local_signature = 304402203b12d44254244b8ff3bb4129b0920fd45120ab42f553d9976394b099d500c99e02205e95bb7a3164852ef0c48f9e0eaf145218f8e2c41251b231f03cbdc4f29a5429
output commit_tx: 02000000000101bef67e4e2fb9ddeeb3461973cd4c62abb35050b1add772995b820b584a488489000000000038b02b8004b80b000000000000220020c20b5d1f8584fd90443e7b7b720136174fa4b9333c261d04dbbd012635c0f419a00f0000000000002200208c48d15160397c9731df9bc3b236656efb6665fbfe92b4a6878e88a499f741c4c0c62d0000000000160014ccf1af2f2aabee14bb40fa3851ab2301de843110b8976a00000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e040047304402203b12d44254244b8ff3bb4129b0920fd45120ab42f553d9976394b099d500c99e02205e95bb7a3164852ef0c48f9e0eaf145218f8e2c41251b231f03cbdc4f29a54290147304402205e2f76d4657fb732c0dfc820a18a7301e368f5799e06b7828007633741bda6df0220458009ae59d0c6246065c419359e05eb2a4b4ef4a1b310cc912db44eb792429801475221023da092f6980e58d2c037173180e9a465476026ee50f96695963e8efe436f54eb21030e9f7b623d2ccc7c9bd44d66d5ce21ce504c0acf6385a132cec6d3c39fa711c152ae3e195220
bolt3 fix and enhance tx testvectors (#99) This is a smerge of Fabrice Drouin and my work: he update them, I updated them and enhanced them, he found bugs, I re-derived them, etc. - rename keys properly - fix fees - sign all transactions - Derive test transaction vectors from minimal subset of parameters. - rewrite test vectors to test edge cases for trimming. - add funding tx test vector, make testable on regtest. This adds a funding transaction test (really, we only specify the output), but importantly adds enough information to duplicate a blockchain with that particular funding tx: $ rm -rf ~/.bitcoin/regtest/ $ bitcoind -regtest=1 & $ bitcoin-cli -regtest=1 submitblock 0000002006226e46111a0b59caaf126043eb5bbf28c34f3a5e332a1fc7b2b73cf188910fadbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fdc30f9858ffff7f20000000000101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff03510101ffffffff0100f2052a010000001976a9143ca33c2e4446f4a305f23c80df8ad1afdcf652f988ac00000000 $ bitcoin-cli -regtest=1 generate 431 $ bitcoin-cli -regtest=1 sendrawtransaction 0200000001adbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fd000000006b48304502210090587b6201e166ad6af0227d3036a9454223d49a1f11839c1a362184340ef0240220577f7cd5cca78719405cbf1de7414ac027f0239ef6e214c90fcaab0454d84b3b012103535b32d5eb0a6ed0982a0479bbadc9868d9836f6ba94dd5a63be16d875069184ffffffff028096980000000000220020c015c4a6be010e21657068fc2e6a9d02b27ebe4d490a25846f7237f104d1a3cd20256d29010000001600143ca33c2e4446f4a305f23c80df8ad1afdcf652f900000000 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-02-07 01:45:33 +01:00
num_htlcs: 2
Clarify Bolt 3 htlc tx output test vectors (#852) It was sometimes unclear where we indexed by the output or the htlc id. This is a follow-up from discussions made in #539.
2021-06-21 22:01:47 +02:00
# signature for output #0 (htlc-timeout for htlc #3)
BOLT 3: update test vectors for new scripts and weight calculation. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-03-07 05:56:08 +01:00
remote_htlc_signature = 3045022100a8a78fa1016a5c5c3704f2e8908715a3cef66723fb95f3132ec4d2d05cd84fb4022025ac49287b0861ec21932405f5600cbce94313dbde0e6c5d5af1b3366d8afbfc
Clarify Bolt 3 htlc tx output test vectors (#852) It was sometimes unclear where we indexed by the output or the htlc id. This is a follow-up from discussions made in #539.
2021-06-21 22:01:47 +02:00
# local_htlc_signature = 3045022100be6ae1977fd7b630a53623f3f25c542317ccfc2b971782802a4f1ef538eb22b402207edc4d0408f8f38fd3c7365d1cfc26511b7cd2d4fecd8b005fba3cd5bc704390
htlc_timeout_tx (htlc #3): 020000000001014e16c488fa158431c1a82e8f661240ec0a71ba0ce92f2721a6538c510226ad5c0000000000000000000109060000000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e0500483045022100a8a78fa1016a5c5c3704f2e8908715a3cef66723fb95f3132ec4d2d05cd84fb4022025ac49287b0861ec21932405f5600cbce94313dbde0e6c5d5af1b3366d8afbfc01483045022100be6ae1977fd7b630a53623f3f25c542317ccfc2b971782802a4f1ef538eb22b402207edc4d0408f8f38fd3c7365d1cfc26511b7cd2d4fecd8b005fba3cd5bc70439001008576a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c820120876475527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae67a9148a486ff2e31d6158bf39e2608864d63fefd09d5b88ac6868f7010000
# signature for output #1 (htlc-success for htlc #4)
BOLT 3: update test vectors for new scripts and weight calculation. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-03-07 05:56:08 +01:00
remote_htlc_signature = 3045022100e769cb156aa2f7515d126cef7a69968629620ce82afcaa9e210969de6850df4602200b16b3f3486a229a48aadde520dbee31ae340dbadaffae74fbb56681fef27b92
Clarify Bolt 3 htlc tx output test vectors (#852) It was sometimes unclear where we indexed by the output or the htlc id. This is a follow-up from discussions made in #539.
2021-06-21 22:01:47 +02:00
# local_htlc_signature = 30440220665b9cb4a978c09d1ca8977a534999bc8a49da624d0c5439451dd69cde1a003d022070eae0620f01f3c1bd029cc1488da13fb40fdab76f396ccd335479a11c5276d8
htlc_success_tx (htlc #4): 020000000001014e16c488fa158431c1a82e8f661240ec0a71ba0ce92f2721a6538c510226ad5c0100000000000000000199090000000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e0500483045022100e769cb156aa2f7515d126cef7a69968629620ce82afcaa9e210969de6850df4602200b16b3f3486a229a48aadde520dbee31ae340dbadaffae74fbb56681fef27b92014730440220665b9cb4a978c09d1ca8977a534999bc8a49da624d0c5439451dd69cde1a003d022070eae0620f01f3c1bd029cc1488da13fb40fdab76f396ccd335479a11c5276d8012004040404040404040404040404040404040404040404040404040404040404048a76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c8201208763a91418bc1a114ccf9c052d3d23e28d3b0a9d1227434288527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae677502f801b175ac686800000000
make htlc outputs of the commitment tx spendable with revocation key (Merge conflict in test vectors fixed by selecting Pierre's, will have to be re-evaluated). Closes: #105
2017-02-10 12:23:32 +01:00
BOLT 1,2,3: first pass copy-edit; BOLT 1,2: minor header spacing fixes BOLT 3: first pass copy edit, according to capitalization, formatting stylesheet guidelines;
2017-11-18 22:04:58 +01:00
name: commitment tx with four outputs untrimmed (maximum feerate)
bolt3 fix and enhance tx testvectors (#99) This is a smerge of Fabrice Drouin and my work: he update them, I updated them and enhanced them, he found bugs, I re-derived them, etc. - rename keys properly - fix fees - sign all transactions - Derive test transaction vectors from minimal subset of parameters. - rewrite test vectors to test edge cases for trimming. - add funding tx test vector, make testable on regtest. This adds a funding transaction test (really, we only specify the output), but importantly adds enough information to duplicate a blockchain with that particular funding tx: $ rm -rf ~/.bitcoin/regtest/ $ bitcoind -regtest=1 & $ bitcoin-cli -regtest=1 submitblock 0000002006226e46111a0b59caaf126043eb5bbf28c34f3a5e332a1fc7b2b73cf188910fadbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fdc30f9858ffff7f20000000000101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff03510101ffffffff0100f2052a010000001976a9143ca33c2e4446f4a305f23c80df8ad1afdcf652f988ac00000000 $ bitcoin-cli -regtest=1 generate 431 $ bitcoin-cli -regtest=1 sendrawtransaction 0200000001adbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fd000000006b48304502210090587b6201e166ad6af0227d3036a9454223d49a1f11839c1a362184340ef0240220577f7cd5cca78719405cbf1de7414ac027f0239ef6e214c90fcaab0454d84b3b012103535b32d5eb0a6ed0982a0479bbadc9868d9836f6ba94dd5a63be16d875069184ffffffff028096980000000000220020c015c4a6be010e21657068fc2e6a9d02b27ebe4d490a25846f7237f104d1a3cd20256d29010000001600143ca33c2e4446f4a305f23c80df8ad1afdcf652f900000000 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-02-07 01:45:33 +01:00
to_local_msat: 6988000000
to_remote_msat: 3000000000
BOLT 3: update test vectors for new scripts and weight calculation. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-03-07 05:56:08 +01:00
local_feerate_per_kw: 3702
# base commitment transaction fee = 3953
# actual commitment transaction fee = 8953
Clarify Bolt 3 htlc tx output test vectors (#852) It was sometimes unclear where we indexed by the output or the htlc id. This is a follow-up from discussions made in #539.
2021-06-21 22:01:47 +02:00
# HTLC #3 offered amount 3000 wscript 76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c820120876475527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae67a9148a486ff2e31d6158bf39e2608864d63fefd09d5b88ac6868
# HTLC #4 received amount 4000 wscript 76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c8201208763a91418bc1a114ccf9c052d3d23e28d3b0a9d1227434288527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae677502f801b175ac6868
Underscores for all terms, not just fields. Plus a few more missing ones, and some consistency fixes in names as pointed out by Roasbeed and Fabrice. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-05-14 02:32:22 +02:00
# to_local amount 6984047 wscript 63210212a140cd0c6539d07cd08dfe09984dec3251ea808b892efeac3ede9402bf2b1967029000b2752103fd5960528dc152014952efdb702a88f71e3c1653b2314431701ec77e57fde83c68ac
# to_remote amount 3000000 P2WPKH(0394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b)
BOLT 3: update test vectors for new scripts and weight calculation. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-03-07 05:56:08 +01:00
remote_signature = 3045022100c1a3b0b60ca092ed5080121f26a74a20cec6bdee3f8e47bae973fcdceb3eda5502207d467a9873c939bf3aa758014ae67295fedbca52412633f7e5b2670fc7c381c1
# local_signature = 304402200e930a43c7951162dc15a2b7344f48091c74c70f7024e7116e900d8bcfba861c022066fa6cbda3929e21daa2e7e16a4b948db7e8919ef978402360d1095ffdaff7b0
output commit_tx: 02000000000101bef67e4e2fb9ddeeb3461973cd4c62abb35050b1add772995b820b584a488489000000000038b02b8004b80b000000000000220020c20b5d1f8584fd90443e7b7b720136174fa4b9333c261d04dbbd012635c0f419a00f0000000000002200208c48d15160397c9731df9bc3b236656efb6665fbfe92b4a6878e88a499f741c4c0c62d0000000000160014ccf1af2f2aabee14bb40fa3851ab2301de8431106f916a00000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e040047304402200e930a43c7951162dc15a2b7344f48091c74c70f7024e7116e900d8bcfba861c022066fa6cbda3929e21daa2e7e16a4b948db7e8919ef978402360d1095ffdaff7b001483045022100c1a3b0b60ca092ed5080121f26a74a20cec6bdee3f8e47bae973fcdceb3eda5502207d467a9873c939bf3aa758014ae67295fedbca52412633f7e5b2670fc7c381c101475221023da092f6980e58d2c037173180e9a465476026ee50f96695963e8efe436f54eb21030e9f7b623d2ccc7c9bd44d66d5ce21ce504c0acf6385a132cec6d3c39fa711c152ae3e195220
bolt3 fix and enhance tx testvectors (#99) This is a smerge of Fabrice Drouin and my work: he update them, I updated them and enhanced them, he found bugs, I re-derived them, etc. - rename keys properly - fix fees - sign all transactions - Derive test transaction vectors from minimal subset of parameters. - rewrite test vectors to test edge cases for trimming. - add funding tx test vector, make testable on regtest. This adds a funding transaction test (really, we only specify the output), but importantly adds enough information to duplicate a blockchain with that particular funding tx: $ rm -rf ~/.bitcoin/regtest/ $ bitcoind -regtest=1 & $ bitcoin-cli -regtest=1 submitblock 0000002006226e46111a0b59caaf126043eb5bbf28c34f3a5e332a1fc7b2b73cf188910fadbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fdc30f9858ffff7f20000000000101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff03510101ffffffff0100f2052a010000001976a9143ca33c2e4446f4a305f23c80df8ad1afdcf652f988ac00000000 $ bitcoin-cli -regtest=1 generate 431 $ bitcoin-cli -regtest=1 sendrawtransaction 0200000001adbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fd000000006b48304502210090587b6201e166ad6af0227d3036a9454223d49a1f11839c1a362184340ef0240220577f7cd5cca78719405cbf1de7414ac027f0239ef6e214c90fcaab0454d84b3b012103535b32d5eb0a6ed0982a0479bbadc9868d9836f6ba94dd5a63be16d875069184ffffffff028096980000000000220020c015c4a6be010e21657068fc2e6a9d02b27ebe4d490a25846f7237f104d1a3cd20256d29010000001600143ca33c2e4446f4a305f23c80df8ad1afdcf652f900000000 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-02-07 01:45:33 +01:00
num_htlcs: 2
Clarify Bolt 3 htlc tx output test vectors (#852) It was sometimes unclear where we indexed by the output or the htlc id. This is a follow-up from discussions made in #539.
2021-06-21 22:01:47 +02:00
# signature for output #0 (htlc-timeout for htlc #3)
BOLT 3: update test vectors for new scripts and weight calculation. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-03-07 05:56:08 +01:00
remote_htlc_signature = 3045022100dfb73b4fe961b31a859b2bb1f4f15cabab9265016dd0272323dc6a9e85885c54022059a7b87c02861ee70662907f25ce11597d7b68d3399443a831ae40e777b76bdb
Clarify Bolt 3 htlc tx output test vectors (#852) It was sometimes unclear where we indexed by the output or the htlc id. This is a follow-up from discussions made in #539.
2021-06-21 22:01:47 +02:00
# local_htlc_signature = 304402202765b9c9ece4f127fa5407faf66da4c5ce2719cdbe47cd3175fc7d48b482e43d02205605125925e07bad1e41c618a4b434d72c88a164981c4b8af5eaf4ee9142ec3a
htlc_timeout_tx (htlc #3): 02000000000101b8de11eb51c22498fe39722c7227b6e55ff1a94146cf638458cb9bc6a060d3a30000000000000000000122020000000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e0500483045022100dfb73b4fe961b31a859b2bb1f4f15cabab9265016dd0272323dc6a9e85885c54022059a7b87c02861ee70662907f25ce11597d7b68d3399443a831ae40e777b76bdb0147304402202765b9c9ece4f127fa5407faf66da4c5ce2719cdbe47cd3175fc7d48b482e43d02205605125925e07bad1e41c618a4b434d72c88a164981c4b8af5eaf4ee9142ec3a01008576a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c820120876475527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae67a9148a486ff2e31d6158bf39e2608864d63fefd09d5b88ac6868f7010000
# signature for output #1 (htlc-success for htlc #4)
BOLT 3: update test vectors for new scripts and weight calculation. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-03-07 05:56:08 +01:00
remote_htlc_signature = 3045022100ea9dc2a7c3c3640334dab733bb4e036e32a3106dc707b24227874fa4f7da746802204d672f7ac0fe765931a8df10b81e53a3242dd32bd9dc9331eb4a596da87954e9
Clarify Bolt 3 htlc tx output test vectors (#852) It was sometimes unclear where we indexed by the output or the htlc id. This is a follow-up from discussions made in #539.
2021-06-21 22:01:47 +02:00
# local_htlc_signature = 30440220048a41c660c4841693de037d00a407810389f4574b3286afb7bc392a438fa3f802200401d71fa87c64fe621b49ac07e3bf85157ac680acb977124da28652cc7f1a5c
htlc_success_tx (htlc #4): 02000000000101b8de11eb51c22498fe39722c7227b6e55ff1a94146cf638458cb9bc6a060d3a30100000000000000000176050000000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e0500483045022100ea9dc2a7c3c3640334dab733bb4e036e32a3106dc707b24227874fa4f7da746802204d672f7ac0fe765931a8df10b81e53a3242dd32bd9dc9331eb4a596da87954e9014730440220048a41c660c4841693de037d00a407810389f4574b3286afb7bc392a438fa3f802200401d71fa87c64fe621b49ac07e3bf85157ac680acb977124da28652cc7f1a5c012004040404040404040404040404040404040404040404040404040404040404048a76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c8201208763a91418bc1a114ccf9c052d3d23e28d3b0a9d1227434288527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae677502f801b175ac686800000000
make htlc outputs of the commitment tx spendable with revocation key (Merge conflict in test vectors fixed by selecting Pierre's, will have to be re-evaluated). Closes: #105
2017-02-10 12:23:32 +01:00
BOLT 1,2,3: first pass copy-edit; BOLT 1,2: minor header spacing fixes BOLT 3: first pass copy edit, according to capitalization, formatting stylesheet guidelines;
2017-11-18 22:04:58 +01:00
name: commitment tx with three outputs untrimmed (minimum feerate)
bolt3 fix and enhance tx testvectors (#99) This is a smerge of Fabrice Drouin and my work: he update them, I updated them and enhanced them, he found bugs, I re-derived them, etc. - rename keys properly - fix fees - sign all transactions - Derive test transaction vectors from minimal subset of parameters. - rewrite test vectors to test edge cases for trimming. - add funding tx test vector, make testable on regtest. This adds a funding transaction test (really, we only specify the output), but importantly adds enough information to duplicate a blockchain with that particular funding tx: $ rm -rf ~/.bitcoin/regtest/ $ bitcoind -regtest=1 & $ bitcoin-cli -regtest=1 submitblock 0000002006226e46111a0b59caaf126043eb5bbf28c34f3a5e332a1fc7b2b73cf188910fadbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fdc30f9858ffff7f20000000000101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff03510101ffffffff0100f2052a010000001976a9143ca33c2e4446f4a305f23c80df8ad1afdcf652f988ac00000000 $ bitcoin-cli -regtest=1 generate 431 $ bitcoin-cli -regtest=1 sendrawtransaction 0200000001adbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fd000000006b48304502210090587b6201e166ad6af0227d3036a9454223d49a1f11839c1a362184340ef0240220577f7cd5cca78719405cbf1de7414ac027f0239ef6e214c90fcaab0454d84b3b012103535b32d5eb0a6ed0982a0479bbadc9868d9836f6ba94dd5a63be16d875069184ffffffff028096980000000000220020c015c4a6be010e21657068fc2e6a9d02b27ebe4d490a25846f7237f104d1a3cd20256d29010000001600143ca33c2e4446f4a305f23c80df8ad1afdcf652f900000000 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-02-07 01:45:33 +01:00
to_local_msat: 6988000000
to_remote_msat: 3000000000
BOLT 3: update test vectors for new scripts and weight calculation. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-03-07 05:56:08 +01:00
local_feerate_per_kw: 3703
# base commitment transaction fee = 3317
# actual commitment transaction fee = 11317
Clarify Bolt 3 htlc tx output test vectors (#852) It was sometimes unclear where we indexed by the output or the htlc id. This is a follow-up from discussions made in #539.
2021-06-21 22:01:47 +02:00
# HTLC #4 received amount 4000 wscript 76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c8201208763a91418bc1a114ccf9c052d3d23e28d3b0a9d1227434288527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae677502f801b175ac6868
Underscores for all terms, not just fields. Plus a few more missing ones, and some consistency fixes in names as pointed out by Roasbeed and Fabrice. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-05-14 02:32:22 +02:00
# to_local amount 6984683 wscript 63210212a140cd0c6539d07cd08dfe09984dec3251ea808b892efeac3ede9402bf2b1967029000b2752103fd5960528dc152014952efdb702a88f71e3c1653b2314431701ec77e57fde83c68ac
# to_remote amount 3000000 P2WPKH(0394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b)
BOLT 3: update test vectors for new scripts and weight calculation. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-03-07 05:56:08 +01:00
remote_signature = 30450221008b7c191dd46893b67b628e618d2dc8e81169d38bade310181ab77d7c94c6675e02203b4dd131fd7c9deb299560983dcdc485545c98f989f7ae8180c28289f9e6bdb0
# local_signature = 3044022047305531dd44391dce03ae20f8735005c615eb077a974edb0059ea1a311857d602202e0ed6972fbdd1e8cb542b06e0929bc41b2ddf236e04cb75edd56151f4197506
output commit_tx: 02000000000101bef67e4e2fb9ddeeb3461973cd4c62abb35050b1add772995b820b584a488489000000000038b02b8003a00f0000000000002200208c48d15160397c9731df9bc3b236656efb6665fbfe92b4a6878e88a499f741c4c0c62d0000000000160014ccf1af2f2aabee14bb40fa3851ab2301de843110eb936a00000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e0400473044022047305531dd44391dce03ae20f8735005c615eb077a974edb0059ea1a311857d602202e0ed6972fbdd1e8cb542b06e0929bc41b2ddf236e04cb75edd56151f4197506014830450221008b7c191dd46893b67b628e618d2dc8e81169d38bade310181ab77d7c94c6675e02203b4dd131fd7c9deb299560983dcdc485545c98f989f7ae8180c28289f9e6bdb001475221023da092f6980e58d2c037173180e9a465476026ee50f96695963e8efe436f54eb21030e9f7b623d2ccc7c9bd44d66d5ce21ce504c0acf6385a132cec6d3c39fa711c152ae3e195220
bolt3 fix and enhance tx testvectors (#99) This is a smerge of Fabrice Drouin and my work: he update them, I updated them and enhanced them, he found bugs, I re-derived them, etc. - rename keys properly - fix fees - sign all transactions - Derive test transaction vectors from minimal subset of parameters. - rewrite test vectors to test edge cases for trimming. - add funding tx test vector, make testable on regtest. This adds a funding transaction test (really, we only specify the output), but importantly adds enough information to duplicate a blockchain with that particular funding tx: $ rm -rf ~/.bitcoin/regtest/ $ bitcoind -regtest=1 & $ bitcoin-cli -regtest=1 submitblock 0000002006226e46111a0b59caaf126043eb5bbf28c34f3a5e332a1fc7b2b73cf188910fadbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fdc30f9858ffff7f20000000000101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff03510101ffffffff0100f2052a010000001976a9143ca33c2e4446f4a305f23c80df8ad1afdcf652f988ac00000000 $ bitcoin-cli -regtest=1 generate 431 $ bitcoin-cli -regtest=1 sendrawtransaction 0200000001adbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fd000000006b48304502210090587b6201e166ad6af0227d3036a9454223d49a1f11839c1a362184340ef0240220577f7cd5cca78719405cbf1de7414ac027f0239ef6e214c90fcaab0454d84b3b012103535b32d5eb0a6ed0982a0479bbadc9868d9836f6ba94dd5a63be16d875069184ffffffff028096980000000000220020c015c4a6be010e21657068fc2e6a9d02b27ebe4d490a25846f7237f104d1a3cd20256d29010000001600143ca33c2e4446f4a305f23c80df8ad1afdcf652f900000000 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-02-07 01:45:33 +01:00
num_htlcs: 1
Clarify Bolt 3 htlc tx output test vectors (#852) It was sometimes unclear where we indexed by the output or the htlc id. This is a follow-up from discussions made in #539.
2021-06-21 22:01:47 +02:00
# signature for output #0 (htlc-success for htlc #4)
BOLT 3: update test vectors for new scripts and weight calculation. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-03-07 05:56:08 +01:00
remote_htlc_signature = 3044022044f65cf833afdcb9d18795ca93f7230005777662539815b8a601eeb3e57129a902206a4bf3e53392affbba52640627defa8dc8af61c958c9e827b2798ab45828abdd
Clarify Bolt 3 htlc tx output test vectors (#852) It was sometimes unclear where we indexed by the output or the htlc id. This is a follow-up from discussions made in #539.
2021-06-21 22:01:47 +02:00
# local_htlc_signature = 3045022100b94d931a811b32eeb885c28ddcf999ae1981893b21dd1329929543fe87ce793002206370107fdd151c5f2384f9ceb71b3107c69c74c8ed5a28a94a4ab2d27d3b0724
htlc_success_tx (htlc #4): 020000000001011c076aa7fb3d7460d10df69432c904227ea84bbf3134d4ceee5fb0f135ef206d0000000000000000000175050000000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e0500473044022044f65cf833afdcb9d18795ca93f7230005777662539815b8a601eeb3e57129a902206a4bf3e53392affbba52640627defa8dc8af61c958c9e827b2798ab45828abdd01483045022100b94d931a811b32eeb885c28ddcf999ae1981893b21dd1329929543fe87ce793002206370107fdd151c5f2384f9ceb71b3107c69c74c8ed5a28a94a4ab2d27d3b0724012004040404040404040404040404040404040404040404040404040404040404048a76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c8201208763a91418bc1a114ccf9c052d3d23e28d3b0a9d1227434288527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae677502f801b175ac686800000000
make htlc outputs of the commitment tx spendable with revocation key (Merge conflict in test vectors fixed by selecting Pierre's, will have to be re-evaluated). Closes: #105
2017-02-10 12:23:32 +01:00
BOLT 1,2,3: first pass copy-edit; BOLT 1,2: minor header spacing fixes BOLT 3: first pass copy edit, according to capitalization, formatting stylesheet guidelines;
2017-11-18 22:04:58 +01:00
name: commitment tx with three outputs untrimmed (maximum feerate)
bolt3 fix and enhance tx testvectors (#99) This is a smerge of Fabrice Drouin and my work: he update them, I updated them and enhanced them, he found bugs, I re-derived them, etc. - rename keys properly - fix fees - sign all transactions - Derive test transaction vectors from minimal subset of parameters. - rewrite test vectors to test edge cases for trimming. - add funding tx test vector, make testable on regtest. This adds a funding transaction test (really, we only specify the output), but importantly adds enough information to duplicate a blockchain with that particular funding tx: $ rm -rf ~/.bitcoin/regtest/ $ bitcoind -regtest=1 & $ bitcoin-cli -regtest=1 submitblock 0000002006226e46111a0b59caaf126043eb5bbf28c34f3a5e332a1fc7b2b73cf188910fadbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fdc30f9858ffff7f20000000000101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff03510101ffffffff0100f2052a010000001976a9143ca33c2e4446f4a305f23c80df8ad1afdcf652f988ac00000000 $ bitcoin-cli -regtest=1 generate 431 $ bitcoin-cli -regtest=1 sendrawtransaction 0200000001adbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fd000000006b48304502210090587b6201e166ad6af0227d3036a9454223d49a1f11839c1a362184340ef0240220577f7cd5cca78719405cbf1de7414ac027f0239ef6e214c90fcaab0454d84b3b012103535b32d5eb0a6ed0982a0479bbadc9868d9836f6ba94dd5a63be16d875069184ffffffff028096980000000000220020c015c4a6be010e21657068fc2e6a9d02b27ebe4d490a25846f7237f104d1a3cd20256d29010000001600143ca33c2e4446f4a305f23c80df8ad1afdcf652f900000000 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-02-07 01:45:33 +01:00
to_local_msat: 6988000000
to_remote_msat: 3000000000
BOLT 3: update test vectors for new scripts and weight calculation. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-03-07 05:56:08 +01:00
local_feerate_per_kw: 4914
# base commitment transaction fee = 4402
# actual commitment transaction fee = 12402
Clarify Bolt 3 htlc tx output test vectors (#852) It was sometimes unclear where we indexed by the output or the htlc id. This is a follow-up from discussions made in #539.
2021-06-21 22:01:47 +02:00
# HTLC #4 received amount 4000 wscript 76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c8201208763a91418bc1a114ccf9c052d3d23e28d3b0a9d1227434288527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae677502f801b175ac6868
Underscores for all terms, not just fields. Plus a few more missing ones, and some consistency fixes in names as pointed out by Roasbeed and Fabrice. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-05-14 02:32:22 +02:00
# to_local amount 6983598 wscript 63210212a140cd0c6539d07cd08dfe09984dec3251ea808b892efeac3ede9402bf2b1967029000b2752103fd5960528dc152014952efdb702a88f71e3c1653b2314431701ec77e57fde83c68ac
# to_remote amount 3000000 P2WPKH(0394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b)
BOLT 3: update test vectors for new scripts and weight calculation. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-03-07 05:56:08 +01:00
remote_signature = 304402206d6cb93969d39177a09d5d45b583f34966195b77c7e585cf47ac5cce0c90cefb022031d71ae4e33a4e80df7f981d696fbdee517337806a3c7138b7491e2cbb077a0e
# local_signature = 304402206a2679efa3c7aaffd2a447fd0df7aba8792858b589750f6a1203f9259173198a022008d52a0e77a99ab533c36206cb15ad7aeb2aa72b93d4b571e728cb5ec2f6fe26
output commit_tx: 02000000000101bef67e4e2fb9ddeeb3461973cd4c62abb35050b1add772995b820b584a488489000000000038b02b8003a00f0000000000002200208c48d15160397c9731df9bc3b236656efb6665fbfe92b4a6878e88a499f741c4c0c62d0000000000160014ccf1af2f2aabee14bb40fa3851ab2301de843110ae8f6a00000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e040047304402206a2679efa3c7aaffd2a447fd0df7aba8792858b589750f6a1203f9259173198a022008d52a0e77a99ab533c36206cb15ad7aeb2aa72b93d4b571e728cb5ec2f6fe260147304402206d6cb93969d39177a09d5d45b583f34966195b77c7e585cf47ac5cce0c90cefb022031d71ae4e33a4e80df7f981d696fbdee517337806a3c7138b7491e2cbb077a0e01475221023da092f6980e58d2c037173180e9a465476026ee50f96695963e8efe436f54eb21030e9f7b623d2ccc7c9bd44d66d5ce21ce504c0acf6385a132cec6d3c39fa711c152ae3e195220
bolt3 fix and enhance tx testvectors (#99) This is a smerge of Fabrice Drouin and my work: he update them, I updated them and enhanced them, he found bugs, I re-derived them, etc. - rename keys properly - fix fees - sign all transactions - Derive test transaction vectors from minimal subset of parameters. - rewrite test vectors to test edge cases for trimming. - add funding tx test vector, make testable on regtest. This adds a funding transaction test (really, we only specify the output), but importantly adds enough information to duplicate a blockchain with that particular funding tx: $ rm -rf ~/.bitcoin/regtest/ $ bitcoind -regtest=1 & $ bitcoin-cli -regtest=1 submitblock 0000002006226e46111a0b59caaf126043eb5bbf28c34f3a5e332a1fc7b2b73cf188910fadbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fdc30f9858ffff7f20000000000101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff03510101ffffffff0100f2052a010000001976a9143ca33c2e4446f4a305f23c80df8ad1afdcf652f988ac00000000 $ bitcoin-cli -regtest=1 generate 431 $ bitcoin-cli -regtest=1 sendrawtransaction 0200000001adbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fd000000006b48304502210090587b6201e166ad6af0227d3036a9454223d49a1f11839c1a362184340ef0240220577f7cd5cca78719405cbf1de7414ac027f0239ef6e214c90fcaab0454d84b3b012103535b32d5eb0a6ed0982a0479bbadc9868d9836f6ba94dd5a63be16d875069184ffffffff028096980000000000220020c015c4a6be010e21657068fc2e6a9d02b27ebe4d490a25846f7237f104d1a3cd20256d29010000001600143ca33c2e4446f4a305f23c80df8ad1afdcf652f900000000 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-02-07 01:45:33 +01:00
num_htlcs: 1
Clarify Bolt 3 htlc tx output test vectors (#852) It was sometimes unclear where we indexed by the output or the htlc id. This is a follow-up from discussions made in #539.
2021-06-21 22:01:47 +02:00
# signature for output #0 (htlc-success for htlc #4)
BOLT 3: update test vectors for new scripts and weight calculation. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-03-07 05:56:08 +01:00
remote_htlc_signature = 3045022100fcb38506bfa11c02874092a843d0cc0a8613c23b639832564a5f69020cb0f6ba02206508b9e91eaa001425c190c68ee5f887e1ad5b1b314002e74db9dbd9e42dbecf
Clarify Bolt 3 htlc tx output test vectors (#852) It was sometimes unclear where we indexed by the output or the htlc id. This is a follow-up from discussions made in #539.
2021-06-21 22:01:47 +02:00
# local_htlc_signature = 304502210086e76b460ddd3cea10525fba298405d3fe11383e56966a5091811368362f689a02200f72ee75657915e0ede89c28709acd113ede9e1b7be520e3bc5cda425ecd6e68
htlc_success_tx (htlc #4): 0200000000010110a3fdcbcd5db477cd3ad465e7f501ffa8c437e8301f00a6061138590add757f0000000000000000000122020000000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e0500483045022100fcb38506bfa11c02874092a843d0cc0a8613c23b639832564a5f69020cb0f6ba02206508b9e91eaa001425c190c68ee5f887e1ad5b1b314002e74db9dbd9e42dbecf0148304502210086e76b460ddd3cea10525fba298405d3fe11383e56966a5091811368362f689a02200f72ee75657915e0ede89c28709acd113ede9e1b7be520e3bc5cda425ecd6e68012004040404040404040404040404040404040404040404040404040404040404048a76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c8201208763a91418bc1a114ccf9c052d3d23e28d3b0a9d1227434288527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae677502f801b175ac686800000000
make htlc outputs of the commitment tx spendable with revocation key (Merge conflict in test vectors fixed by selecting Pierre's, will have to be re-evaluated). Closes: #105
2017-02-10 12:23:32 +01:00
BOLT 1,2,3: first pass copy-edit; BOLT 1,2: minor header spacing fixes BOLT 3: first pass copy edit, according to capitalization, formatting stylesheet guidelines;
2017-11-18 22:04:58 +01:00
name: commitment tx with two outputs untrimmed (minimum feerate)
bolt3 fix and enhance tx testvectors (#99) This is a smerge of Fabrice Drouin and my work: he update them, I updated them and enhanced them, he found bugs, I re-derived them, etc. - rename keys properly - fix fees - sign all transactions - Derive test transaction vectors from minimal subset of parameters. - rewrite test vectors to test edge cases for trimming. - add funding tx test vector, make testable on regtest. This adds a funding transaction test (really, we only specify the output), but importantly adds enough information to duplicate a blockchain with that particular funding tx: $ rm -rf ~/.bitcoin/regtest/ $ bitcoind -regtest=1 & $ bitcoin-cli -regtest=1 submitblock 0000002006226e46111a0b59caaf126043eb5bbf28c34f3a5e332a1fc7b2b73cf188910fadbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fdc30f9858ffff7f20000000000101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff03510101ffffffff0100f2052a010000001976a9143ca33c2e4446f4a305f23c80df8ad1afdcf652f988ac00000000 $ bitcoin-cli -regtest=1 generate 431 $ bitcoin-cli -regtest=1 sendrawtransaction 0200000001adbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fd000000006b48304502210090587b6201e166ad6af0227d3036a9454223d49a1f11839c1a362184340ef0240220577f7cd5cca78719405cbf1de7414ac027f0239ef6e214c90fcaab0454d84b3b012103535b32d5eb0a6ed0982a0479bbadc9868d9836f6ba94dd5a63be16d875069184ffffffff028096980000000000220020c015c4a6be010e21657068fc2e6a9d02b27ebe4d490a25846f7237f104d1a3cd20256d29010000001600143ca33c2e4446f4a305f23c80df8ad1afdcf652f900000000 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-02-07 01:45:33 +01:00
to_local_msat: 6988000000
to_remote_msat: 3000000000
BOLT 3: update test vectors for new scripts and weight calculation. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-03-07 05:56:08 +01:00
local_feerate_per_kw: 4915
# base commitment transaction fee = 3558
# actual commitment transaction fee = 15558
Underscores for all terms, not just fields. Plus a few more missing ones, and some consistency fixes in names as pointed out by Roasbeed and Fabrice. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-05-14 02:32:22 +02:00
# to_local amount 6984442 wscript 63210212a140cd0c6539d07cd08dfe09984dec3251ea808b892efeac3ede9402bf2b1967029000b2752103fd5960528dc152014952efdb702a88f71e3c1653b2314431701ec77e57fde83c68ac
# to_remote amount 3000000 P2WPKH(0394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b)
BOLT 3: update test vectors for new scripts and weight calculation. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-03-07 05:56:08 +01:00
remote_signature = 304402200769ba89c7330dfa4feba447b6e322305f12ac7dac70ec6ba997ed7c1b598d0802204fe8d337e7fee781f9b7b1a06e580b22f4f79d740059560191d7db53f8765552
# local_signature = 3045022100a012691ba6cea2f73fa8bac37750477e66363c6d28813b0bb6da77c8eb3fb0270220365e99c51304b0b1a6ab9ea1c8500db186693e39ec1ad5743ee231b0138384b9
output commit_tx: 02000000000101bef67e4e2fb9ddeeb3461973cd4c62abb35050b1add772995b820b584a488489000000000038b02b8002c0c62d0000000000160014ccf1af2f2aabee14bb40fa3851ab2301de843110fa926a00000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e0400483045022100a012691ba6cea2f73fa8bac37750477e66363c6d28813b0bb6da77c8eb3fb0270220365e99c51304b0b1a6ab9ea1c8500db186693e39ec1ad5743ee231b0138384b90147304402200769ba89c7330dfa4feba447b6e322305f12ac7dac70ec6ba997ed7c1b598d0802204fe8d337e7fee781f9b7b1a06e580b22f4f79d740059560191d7db53f876555201475221023da092f6980e58d2c037173180e9a465476026ee50f96695963e8efe436f54eb21030e9f7b623d2ccc7c9bd44d66d5ce21ce504c0acf6385a132cec6d3c39fa711c152ae3e195220
bolt3 fix and enhance tx testvectors (#99) This is a smerge of Fabrice Drouin and my work: he update them, I updated them and enhanced them, he found bugs, I re-derived them, etc. - rename keys properly - fix fees - sign all transactions - Derive test transaction vectors from minimal subset of parameters. - rewrite test vectors to test edge cases for trimming. - add funding tx test vector, make testable on regtest. This adds a funding transaction test (really, we only specify the output), but importantly adds enough information to duplicate a blockchain with that particular funding tx: $ rm -rf ~/.bitcoin/regtest/ $ bitcoind -regtest=1 & $ bitcoin-cli -regtest=1 submitblock 0000002006226e46111a0b59caaf126043eb5bbf28c34f3a5e332a1fc7b2b73cf188910fadbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fdc30f9858ffff7f20000000000101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff03510101ffffffff0100f2052a010000001976a9143ca33c2e4446f4a305f23c80df8ad1afdcf652f988ac00000000 $ bitcoin-cli -regtest=1 generate 431 $ bitcoin-cli -regtest=1 sendrawtransaction 0200000001adbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fd000000006b48304502210090587b6201e166ad6af0227d3036a9454223d49a1f11839c1a362184340ef0240220577f7cd5cca78719405cbf1de7414ac027f0239ef6e214c90fcaab0454d84b3b012103535b32d5eb0a6ed0982a0479bbadc9868d9836f6ba94dd5a63be16d875069184ffffffff028096980000000000220020c015c4a6be010e21657068fc2e6a9d02b27ebe4d490a25846f7237f104d1a3cd20256d29010000001600143ca33c2e4446f4a305f23c80df8ad1afdcf652f900000000 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-02-07 01:45:33 +01:00
num_htlcs: 0
make htlc outputs of the commitment tx spendable with revocation key (Merge conflict in test vectors fixed by selecting Pierre's, will have to be re-evaluated). Closes: #105
2017-02-10 12:23:32 +01:00
BOLT 1,2,3: first pass copy-edit; BOLT 1,2: minor header spacing fixes BOLT 3: first pass copy edit, according to capitalization, formatting stylesheet guidelines;
2017-11-18 22:04:58 +01:00
name: commitment tx with two outputs untrimmed (maximum feerate)
bolt3 fix and enhance tx testvectors (#99) This is a smerge of Fabrice Drouin and my work: he update them, I updated them and enhanced them, he found bugs, I re-derived them, etc. - rename keys properly - fix fees - sign all transactions - Derive test transaction vectors from minimal subset of parameters. - rewrite test vectors to test edge cases for trimming. - add funding tx test vector, make testable on regtest. This adds a funding transaction test (really, we only specify the output), but importantly adds enough information to duplicate a blockchain with that particular funding tx: $ rm -rf ~/.bitcoin/regtest/ $ bitcoind -regtest=1 & $ bitcoin-cli -regtest=1 submitblock 0000002006226e46111a0b59caaf126043eb5bbf28c34f3a5e332a1fc7b2b73cf188910fadbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fdc30f9858ffff7f20000000000101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff03510101ffffffff0100f2052a010000001976a9143ca33c2e4446f4a305f23c80df8ad1afdcf652f988ac00000000 $ bitcoin-cli -regtest=1 generate 431 $ bitcoin-cli -regtest=1 sendrawtransaction 0200000001adbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fd000000006b48304502210090587b6201e166ad6af0227d3036a9454223d49a1f11839c1a362184340ef0240220577f7cd5cca78719405cbf1de7414ac027f0239ef6e214c90fcaab0454d84b3b012103535b32d5eb0a6ed0982a0479bbadc9868d9836f6ba94dd5a63be16d875069184ffffffff028096980000000000220020c015c4a6be010e21657068fc2e6a9d02b27ebe4d490a25846f7237f104d1a3cd20256d29010000001600143ca33c2e4446f4a305f23c80df8ad1afdcf652f900000000 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-02-07 01:45:33 +01:00
to_local_msat: 6988000000
to_remote_msat: 3000000000
local_feerate_per_kw: 9651180
# base commitment transaction fee = 6987454
make htlc outputs of the commitment tx spendable with revocation key (Merge conflict in test vectors fixed by selecting Pierre's, will have to be re-evaluated). Closes: #105
2017-02-10 12:23:32 +01:00
# actual commitment transaction fee = 6999454
Underscores for all terms, not just fields. Plus a few more missing ones, and some consistency fixes in names as pointed out by Roasbeed and Fabrice. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-05-14 02:32:22 +02:00
# to_local amount 546 wscript 63210212a140cd0c6539d07cd08dfe09984dec3251ea808b892efeac3ede9402bf2b1967029000b2752103fd5960528dc152014952efdb702a88f71e3c1653b2314431701ec77e57fde83c68ac
# to_remote amount 3000000 P2WPKH(0394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b)
BOLT 3: update test vectors for new scripts and weight calculation. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-03-07 05:56:08 +01:00
remote_signature = 3044022037f83ff00c8e5fb18ae1f918ffc24e54581775a20ff1ae719297ef066c71caa9022039c529cccd89ff6c5ed1db799614533844bd6d101da503761c45c713996e3bbd
# local_signature = 30440220514f977bf7edc442de8ce43ace9686e5ebdc0f893033f13e40fb46c8b8c6e1f90220188006227d175f5c35da0b092c57bea82537aed89f7778204dc5bacf4f29f2b9
output commit_tx: 02000000000101bef67e4e2fb9ddeeb3461973cd4c62abb35050b1add772995b820b584a488489000000000038b02b800222020000000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80ec0c62d0000000000160014ccf1af2f2aabee14bb40fa3851ab2301de84311004004730440220514f977bf7edc442de8ce43ace9686e5ebdc0f893033f13e40fb46c8b8c6e1f90220188006227d175f5c35da0b092c57bea82537aed89f7778204dc5bacf4f29f2b901473044022037f83ff00c8e5fb18ae1f918ffc24e54581775a20ff1ae719297ef066c71caa9022039c529cccd89ff6c5ed1db799614533844bd6d101da503761c45c713996e3bbd01475221023da092f6980e58d2c037173180e9a465476026ee50f96695963e8efe436f54eb21030e9f7b623d2ccc7c9bd44d66d5ce21ce504c0acf6385a132cec6d3c39fa711c152ae3e195220
bolt3 fix and enhance tx testvectors (#99) This is a smerge of Fabrice Drouin and my work: he update them, I updated them and enhanced them, he found bugs, I re-derived them, etc. - rename keys properly - fix fees - sign all transactions - Derive test transaction vectors from minimal subset of parameters. - rewrite test vectors to test edge cases for trimming. - add funding tx test vector, make testable on regtest. This adds a funding transaction test (really, we only specify the output), but importantly adds enough information to duplicate a blockchain with that particular funding tx: $ rm -rf ~/.bitcoin/regtest/ $ bitcoind -regtest=1 & $ bitcoin-cli -regtest=1 submitblock 0000002006226e46111a0b59caaf126043eb5bbf28c34f3a5e332a1fc7b2b73cf188910fadbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fdc30f9858ffff7f20000000000101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff03510101ffffffff0100f2052a010000001976a9143ca33c2e4446f4a305f23c80df8ad1afdcf652f988ac00000000 $ bitcoin-cli -regtest=1 generate 431 $ bitcoin-cli -regtest=1 sendrawtransaction 0200000001adbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fd000000006b48304502210090587b6201e166ad6af0227d3036a9454223d49a1f11839c1a362184340ef0240220577f7cd5cca78719405cbf1de7414ac027f0239ef6e214c90fcaab0454d84b3b012103535b32d5eb0a6ed0982a0479bbadc9868d9836f6ba94dd5a63be16d875069184ffffffff028096980000000000220020c015c4a6be010e21657068fc2e6a9d02b27ebe4d490a25846f7237f104d1a3cd20256d29010000001600143ca33c2e4446f4a305f23c80df8ad1afdcf652f900000000 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-02-07 01:45:33 +01:00
num_htlcs: 0
make htlc outputs of the commitment tx spendable with revocation key (Merge conflict in test vectors fixed by selecting Pierre's, will have to be re-evaluated). Closes: #105
2017-02-10 12:23:32 +01:00
BOLT 1,2,3: first pass copy-edit; BOLT 1,2: minor header spacing fixes BOLT 3: first pass copy edit, according to capitalization, formatting stylesheet guidelines;
2017-11-18 22:04:58 +01:00
name: commitment tx with one output untrimmed (minimum feerate)
bolt3 fix and enhance tx testvectors (#99) This is a smerge of Fabrice Drouin and my work: he update them, I updated them and enhanced them, he found bugs, I re-derived them, etc. - rename keys properly - fix fees - sign all transactions - Derive test transaction vectors from minimal subset of parameters. - rewrite test vectors to test edge cases for trimming. - add funding tx test vector, make testable on regtest. This adds a funding transaction test (really, we only specify the output), but importantly adds enough information to duplicate a blockchain with that particular funding tx: $ rm -rf ~/.bitcoin/regtest/ $ bitcoind -regtest=1 & $ bitcoin-cli -regtest=1 submitblock 0000002006226e46111a0b59caaf126043eb5bbf28c34f3a5e332a1fc7b2b73cf188910fadbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fdc30f9858ffff7f20000000000101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff03510101ffffffff0100f2052a010000001976a9143ca33c2e4446f4a305f23c80df8ad1afdcf652f988ac00000000 $ bitcoin-cli -regtest=1 generate 431 $ bitcoin-cli -regtest=1 sendrawtransaction 0200000001adbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fd000000006b48304502210090587b6201e166ad6af0227d3036a9454223d49a1f11839c1a362184340ef0240220577f7cd5cca78719405cbf1de7414ac027f0239ef6e214c90fcaab0454d84b3b012103535b32d5eb0a6ed0982a0479bbadc9868d9836f6ba94dd5a63be16d875069184ffffffff028096980000000000220020c015c4a6be010e21657068fc2e6a9d02b27ebe4d490a25846f7237f104d1a3cd20256d29010000001600143ca33c2e4446f4a305f23c80df8ad1afdcf652f900000000 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-02-07 01:45:33 +01:00
to_local_msat: 6988000000
to_remote_msat: 3000000000
local_feerate_per_kw: 9651181
# base commitment transaction fee = 6987455
make htlc outputs of the commitment tx spendable with revocation key (Merge conflict in test vectors fixed by selecting Pierre's, will have to be re-evaluated). Closes: #105
2017-02-10 12:23:32 +01:00
# actual commitment transaction fee = 7000000
Underscores for all terms, not just fields. Plus a few more missing ones, and some consistency fixes in names as pointed out by Roasbeed and Fabrice. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-05-14 02:32:22 +02:00
# to_remote amount 3000000 P2WPKH(0394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b)
BOLT 3: update test vectors for new scripts and weight calculation. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-03-07 05:56:08 +01:00
remote_signature = 3044022064901950be922e62cbe3f2ab93de2b99f37cff9fc473e73e394b27f88ef0731d02206d1dfa227527b4df44a07599289e207d6fd9cca60c0365682dcd3deaf739567e
# local_signature = 3044022031a82b51bd014915fe68928d1abf4b9885353fb896cac10c3fdd88d7f9c7f2e00220716bda819641d2c63e65d3549b6120112e1aeaf1742eed94a471488e79e206b1
output commit_tx: 02000000000101bef67e4e2fb9ddeeb3461973cd4c62abb35050b1add772995b820b584a488489000000000038b02b8001c0c62d0000000000160014ccf1af2f2aabee14bb40fa3851ab2301de8431100400473044022031a82b51bd014915fe68928d1abf4b9885353fb896cac10c3fdd88d7f9c7f2e00220716bda819641d2c63e65d3549b6120112e1aeaf1742eed94a471488e79e206b101473044022064901950be922e62cbe3f2ab93de2b99f37cff9fc473e73e394b27f88ef0731d02206d1dfa227527b4df44a07599289e207d6fd9cca60c0365682dcd3deaf739567e01475221023da092f6980e58d2c037173180e9a465476026ee50f96695963e8efe436f54eb21030e9f7b623d2ccc7c9bd44d66d5ce21ce504c0acf6385a132cec6d3c39fa711c152ae3e195220
bolt3 fix and enhance tx testvectors (#99) This is a smerge of Fabrice Drouin and my work: he update them, I updated them and enhanced them, he found bugs, I re-derived them, etc. - rename keys properly - fix fees - sign all transactions - Derive test transaction vectors from minimal subset of parameters. - rewrite test vectors to test edge cases for trimming. - add funding tx test vector, make testable on regtest. This adds a funding transaction test (really, we only specify the output), but importantly adds enough information to duplicate a blockchain with that particular funding tx: $ rm -rf ~/.bitcoin/regtest/ $ bitcoind -regtest=1 & $ bitcoin-cli -regtest=1 submitblock 0000002006226e46111a0b59caaf126043eb5bbf28c34f3a5e332a1fc7b2b73cf188910fadbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fdc30f9858ffff7f20000000000101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff03510101ffffffff0100f2052a010000001976a9143ca33c2e4446f4a305f23c80df8ad1afdcf652f988ac00000000 $ bitcoin-cli -regtest=1 generate 431 $ bitcoin-cli -regtest=1 sendrawtransaction 0200000001adbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fd000000006b48304502210090587b6201e166ad6af0227d3036a9454223d49a1f11839c1a362184340ef0240220577f7cd5cca78719405cbf1de7414ac027f0239ef6e214c90fcaab0454d84b3b012103535b32d5eb0a6ed0982a0479bbadc9868d9836f6ba94dd5a63be16d875069184ffffffff028096980000000000220020c015c4a6be010e21657068fc2e6a9d02b27ebe4d490a25846f7237f104d1a3cd20256d29010000001600143ca33c2e4446f4a305f23c80df8ad1afdcf652f900000000 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-02-07 01:45:33 +01:00
num_htlcs: 0
make htlc outputs of the commitment tx spendable with revocation key (Merge conflict in test vectors fixed by selecting Pierre's, will have to be re-evaluated). Closes: #105
2017-02-10 12:23:32 +01:00
bolt3 fix and enhance tx testvectors (#99) This is a smerge of Fabrice Drouin and my work: he update them, I updated them and enhanced them, he found bugs, I re-derived them, etc. - rename keys properly - fix fees - sign all transactions - Derive test transaction vectors from minimal subset of parameters. - rewrite test vectors to test edge cases for trimming. - add funding tx test vector, make testable on regtest. This adds a funding transaction test (really, we only specify the output), but importantly adds enough information to duplicate a blockchain with that particular funding tx: $ rm -rf ~/.bitcoin/regtest/ $ bitcoind -regtest=1 & $ bitcoin-cli -regtest=1 submitblock 0000002006226e46111a0b59caaf126043eb5bbf28c34f3a5e332a1fc7b2b73cf188910fadbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fdc30f9858ffff7f20000000000101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff03510101ffffffff0100f2052a010000001976a9143ca33c2e4446f4a305f23c80df8ad1afdcf652f988ac00000000 $ bitcoin-cli -regtest=1 generate 431 $ bitcoin-cli -regtest=1 sendrawtransaction 0200000001adbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fd000000006b48304502210090587b6201e166ad6af0227d3036a9454223d49a1f11839c1a362184340ef0240220577f7cd5cca78719405cbf1de7414ac027f0239ef6e214c90fcaab0454d84b3b012103535b32d5eb0a6ed0982a0479bbadc9868d9836f6ba94dd5a63be16d875069184ffffffff028096980000000000220020c015c4a6be010e21657068fc2e6a9d02b27ebe4d490a25846f7237f104d1a3cd20256d29010000001600143ca33c2e4446f4a305f23c80df8ad1afdcf652f900000000 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-02-07 01:45:33 +01:00
name: commitment tx with fee greater than funder amount
to_local_msat: 6988000000
to_remote_msat: 3000000000
local_feerate_per_kw: 9651936
# base commitment transaction fee = 6988001
make htlc outputs of the commitment tx spendable with revocation key (Merge conflict in test vectors fixed by selecting Pierre's, will have to be re-evaluated). Closes: #105
2017-02-10 12:23:32 +01:00
# actual commitment transaction fee = 7000000
Underscores for all terms, not just fields. Plus a few more missing ones, and some consistency fixes in names as pointed out by Roasbeed and Fabrice. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-05-14 02:32:22 +02:00
# to_remote amount 3000000 P2WPKH(0394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b)
BOLT 3: update test vectors for new scripts and weight calculation. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-03-07 05:56:08 +01:00
remote_signature = 3044022064901950be922e62cbe3f2ab93de2b99f37cff9fc473e73e394b27f88ef0731d02206d1dfa227527b4df44a07599289e207d6fd9cca60c0365682dcd3deaf739567e
# local_signature = 3044022031a82b51bd014915fe68928d1abf4b9885353fb896cac10c3fdd88d7f9c7f2e00220716bda819641d2c63e65d3549b6120112e1aeaf1742eed94a471488e79e206b1
output commit_tx: 02000000000101bef67e4e2fb9ddeeb3461973cd4c62abb35050b1add772995b820b584a488489000000000038b02b8001c0c62d0000000000160014ccf1af2f2aabee14bb40fa3851ab2301de8431100400473044022031a82b51bd014915fe68928d1abf4b9885353fb896cac10c3fdd88d7f9c7f2e00220716bda819641d2c63e65d3549b6120112e1aeaf1742eed94a471488e79e206b101473044022064901950be922e62cbe3f2ab93de2b99f37cff9fc473e73e394b27f88ef0731d02206d1dfa227527b4df44a07599289e207d6fd9cca60c0365682dcd3deaf739567e01475221023da092f6980e58d2c037173180e9a465476026ee50f96695963e8efe436f54eb21030e9f7b623d2ccc7c9bd44d66d5ce21ce504c0acf6385a132cec6d3c39fa711c152ae3e195220
bolt3 fix and enhance tx testvectors (#99) This is a smerge of Fabrice Drouin and my work: he update them, I updated them and enhanced them, he found bugs, I re-derived them, etc. - rename keys properly - fix fees - sign all transactions - Derive test transaction vectors from minimal subset of parameters. - rewrite test vectors to test edge cases for trimming. - add funding tx test vector, make testable on regtest. This adds a funding transaction test (really, we only specify the output), but importantly adds enough information to duplicate a blockchain with that particular funding tx: $ rm -rf ~/.bitcoin/regtest/ $ bitcoind -regtest=1 & $ bitcoin-cli -regtest=1 submitblock 0000002006226e46111a0b59caaf126043eb5bbf28c34f3a5e332a1fc7b2b73cf188910fadbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fdc30f9858ffff7f20000000000101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff03510101ffffffff0100f2052a010000001976a9143ca33c2e4446f4a305f23c80df8ad1afdcf652f988ac00000000 $ bitcoin-cli -regtest=1 generate 431 $ bitcoin-cli -regtest=1 sendrawtransaction 0200000001adbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fd000000006b48304502210090587b6201e166ad6af0227d3036a9454223d49a1f11839c1a362184340ef0240220577f7cd5cca78719405cbf1de7414ac027f0239ef6e214c90fcaab0454d84b3b012103535b32d5eb0a6ed0982a0479bbadc9868d9836f6ba94dd5a63be16d875069184ffffffff028096980000000000220020c015c4a6be010e21657068fc2e6a9d02b27ebe4d490a25846f7237f104d1a3cd20256d29010000001600143ca33c2e4446f4a305f23c80df8ad1afdcf652f900000000 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-02-07 01:45:33 +01:00
num_htlcs: 0
added test vectors for transactions
2017-01-03 18:21:10 +01:00
BOLT 3: add test vectors for htlc-transactions in case where CLTV is used as tie-breaker for sorting (#539) Add a serialized transactions test vector for the edge case of sorting htlc-timeout-tx when there are multiple offered htlc with the same amount and preimage. The test vector reuses previous preimages and creates a case scenario with 1 received htlc and 2 offered, the two offered will have same scriptPubKey and redeemScript, but different CLTV value. It is asserted the order in which the htlc transactions should be kept internally and we assume the same order is used to construct the commitment_signed message. This complements #491 .
2021-03-05 09:10:26 +01:00
name: commitment tx with 3 htlc outputs, 2 offered having the same amount and preimage
to_local_msat: 6988000000
to_remote_msat: 3000000000
local_feerate_per_kw: 253
Clarify Bolt 3 htlc tx output test vectors (#852) It was sometimes unclear where we indexed by the output or the htlc id. This is a follow-up from discussions made in #539.
2021-06-21 22:01:47 +02:00
# HTLC #1 received amount 2000 wscript 76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c8201208763a9144b6b2e5444c2639cc0fb7bcea5afba3f3cdce23988527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae677502f501b175ac6868
# HTLC #5 offered amount 5000 wscript 76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c820120876475527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae67a9142002cc93ebefbb1b73f0af055dcc27a0b504ad7688ac6868
# HTLC #6 offered amount 5000 wscript 76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c820120876475527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae67a9142002cc93ebefbb1b73f0af055dcc27a0b504ad7688ac6868
# HTLC #5 and 6 have CLTV 506 and 505, respectively, and preimage 0505050505050505050505050505050505050505050505050505050505050505
BOLT 3: add test vectors for htlc-transactions in case where CLTV is used as tie-breaker for sorting (#539) Add a serialized transactions test vector for the edge case of sorting htlc-timeout-tx when there are multiple offered htlc with the same amount and preimage. The test vector reuses previous preimages and creates a case scenario with 1 received htlc and 2 offered, the two offered will have same scriptPubKey and redeemScript, but different CLTV value. It is asserted the order in which the htlc transactions should be kept internally and we assume the same order is used to construct the commitment_signed message. This complements #491 .
2021-03-05 09:10:26 +01:00
remote_signature = 3044022044f807aefa41480a5d1df2fc312c486900617fd24493cf41976428cb249ec2c2022007fd1229cfb57d638b9c137b03bc7917d0e418b63e62a3642f1c13354cc71df8
# local_signature = 304502210098674686a13c7da2d95abea08d27e9324573156d79e5eb08cd96d1e33bb0045002206391216f4fd5fb7b0fe8c43074fd19f485dd47d7b07f7325c5a6121f5b0a591b
output commit_tx: 02000000000101bef67e4e2fb9ddeeb3461973cd4c62abb35050b1add772995b820b584a488489000000000038b02b8005d007000000000000220020748eba944fedc8827f6b06bc44678f93c0f9e6078b35c6331ed31e75f8ce0c2d8813000000000000220020305c12e1a0bc21e283c131cea1c66d68857d28b7b2fce0a6fbc40c164852121b8813000000000000220020305c12e1a0bc21e283c131cea1c66d68857d28b7b2fce0a6fbc40c164852121bc0c62d0000000000160014ccf1af2f2aabee14bb40fa3851ab2301de843110a79f6a00000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e040048304502210098674686a13c7da2d95abea08d27e9324573156d79e5eb08cd96d1e33bb0045002206391216f4fd5fb7b0fe8c43074fd19f485dd47d7b07f7325c5a6121f5b0a591b01473044022044f807aefa41480a5d1df2fc312c486900617fd24493cf41976428cb249ec2c2022007fd1229cfb57d638b9c137b03bc7917d0e418b63e62a3642f1c13354cc71df801475221023da092f6980e58d2c037173180e9a465476026ee50f96695963e8efe436f54eb21030e9f7b623d2ccc7c9bd44d66d5ce21ce504c0acf6385a132cec6d3c39fa711c152ae3e195220
num_htlcs: 3
Clarify Bolt 3 htlc tx output test vectors (#852) It was sometimes unclear where we indexed by the output or the htlc id. This is a follow-up from discussions made in #539.
2021-06-21 22:01:47 +02:00
# signature for output #0 (htlc-success for htlc #1)
BOLT 3: add test vectors for htlc-transactions in case where CLTV is used as tie-breaker for sorting (#539) Add a serialized transactions test vector for the edge case of sorting htlc-timeout-tx when there are multiple offered htlc with the same amount and preimage. The test vector reuses previous preimages and creates a case scenario with 1 received htlc and 2 offered, the two offered will have same scriptPubKey and redeemScript, but different CLTV value. It is asserted the order in which the htlc transactions should be kept internally and we assume the same order is used to construct the commitment_signed message. This complements #491 .
2021-03-05 09:10:26 +01:00
remote_htlc_signature = 3044022031694c29682ed2646dc6b64f59236f7d262027cac742b89030692483ca8326fe022040ca3216802d232eb04894f81008785b82b74812983fc05f93db7db5ff5ef613
# local_htlc_signature = 304402203198b389ca301ee713eef7beb2b73655fa28eb25ac3cb2e6b295767776fe67a402206e7dcfbcd5ce2bcadf254ba9911c9a770d3e1b752b276575ba8b9fd1c2b424e7
Clarify Bolt 3 htlc tx output test vectors (#852) It was sometimes unclear where we indexed by the output or the htlc id. This is a follow-up from discussions made in #539.
2021-06-21 22:01:47 +02:00
htlc_success_tx (htlc #1): 0200000000010175a53c9a465f56140f1c7b2c42b27f0e56b508e39cb6971f3c5b551cfda8e5e4000000000000000000011f070000000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e0500473044022031694c29682ed2646dc6b64f59236f7d262027cac742b89030692483ca8326fe022040ca3216802d232eb04894f81008785b82b74812983fc05f93db7db5ff5ef6130147304402203198b389ca301ee713eef7beb2b73655fa28eb25ac3cb2e6b295767776fe67a402206e7dcfbcd5ce2bcadf254ba9911c9a770d3e1b752b276575ba8b9fd1c2b424e7012001010101010101010101010101010101010101010101010101010101010101018a76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c8201208763a9144b6b2e5444c2639cc0fb7bcea5afba3f3cdce23988527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae677502f501b175ac686800000000
# signature for output #1 (htlc-timeout for htlc #5)
remote_htlc_signature = 3045022100b3884c0174eb3650e68807bba145a752f8769b4ec886e95553f78380edbd28e6022058621ac2f742239f7be25b549d2f3bad9a1524f2b346a247fcb151afb1c4c5eb
BOLT 3: add test vectors for htlc-transactions in case where CLTV is used as tie-breaker for sorting (#539) Add a serialized transactions test vector for the edge case of sorting htlc-timeout-tx when there are multiple offered htlc with the same amount and preimage. The test vector reuses previous preimages and creates a case scenario with 1 received htlc and 2 offered, the two offered will have same scriptPubKey and redeemScript, but different CLTV value. It is asserted the order in which the htlc transactions should be kept internally and we assume the same order is used to construct the commitment_signed message. This complements #491 .
2021-03-05 09:10:26 +01:00
# local_htlc_signature = 304402201ef4ba8337e517980256d61301ab83e528d4aab79c9610066ef200a6b252d58d0220277cebbbff3ac7d1fecafd8befe1525470b3ee180d282fc8c36e0237c96d9739
Clarify Bolt 3 htlc tx output test vectors (#852) It was sometimes unclear where we indexed by the output or the htlc id. This is a follow-up from discussions made in #539.
2021-06-21 22:01:47 +02:00
htlc_timeout_tx (htlc #5): 0200000000010175a53c9a465f56140f1c7b2c42b27f0e56b508e39cb6971f3c5b551cfda8e5e401000000000000000001e1120000000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e0500483045022100b3884c0174eb3650e68807bba145a752f8769b4ec886e95553f78380edbd28e6022058621ac2f742239f7be25b549d2f3bad9a1524f2b346a247fcb151afb1c4c5eb0147304402201ef4ba8337e517980256d61301ab83e528d4aab79c9610066ef200a6b252d58d0220277cebbbff3ac7d1fecafd8befe1525470b3ee180d282fc8c36e0237c96d973901008576a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c820120876475527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae67a9142002cc93ebefbb1b73f0af055dcc27a0b504ad7688ac6868f9010000
# signature for output #2 (htlc-timeout for htlc #6)
remote_htlc_signature = 3045022100de2757977d17699d092c1b05cebb52fa498de5d5fba6a60762f73aa7354ad8a50220199295de83336966e7387e8ebb2f105adc0db516260d6cd1e3c166f8b32d853e
BOLT 3: add test vectors for htlc-transactions in case where CLTV is used as tie-breaker for sorting (#539) Add a serialized transactions test vector for the edge case of sorting htlc-timeout-tx when there are multiple offered htlc with the same amount and preimage. The test vector reuses previous preimages and creates a case scenario with 1 received htlc and 2 offered, the two offered will have same scriptPubKey and redeemScript, but different CLTV value. It is asserted the order in which the htlc transactions should be kept internally and we assume the same order is used to construct the commitment_signed message. This complements #491 .
2021-03-05 09:10:26 +01:00
# local_htlc_signature = 30440220207ee7d74a0f223b5d05db49653c541d4a043f2ab3e88abbeeb5f1d1d761535902207de25db7f70a939eae6cec89d8487ad1e9c953cb0f30a5f84e5ade5736d6f9ce
Clarify Bolt 3 htlc tx output test vectors (#852) It was sometimes unclear where we indexed by the output or the htlc id. This is a follow-up from discussions made in #539.
2021-06-21 22:01:47 +02:00
htlc_timeout_tx (htlc #6): 0200000000010175a53c9a465f56140f1c7b2c42b27f0e56b508e39cb6971f3c5b551cfda8e5e402000000000000000001e1120000000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e0500483045022100de2757977d17699d092c1b05cebb52fa498de5d5fba6a60762f73aa7354ad8a50220199295de83336966e7387e8ebb2f105adc0db516260d6cd1e3c166f8b32d853e014730440220207ee7d74a0f223b5d05db49653c541d4a043f2ab3e88abbeeb5f1d1d761535902207de25db7f70a939eae6cec89d8487ad1e9c953cb0f30a5f84e5ade5736d6f9ce01008576a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c820120876475527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae67a9142002cc93ebefbb1b73f0af055dcc27a0b504ad7688ac6868fa010000
BOLT 3: add test vectors for htlc-transactions in case where CLTV is used as tie-breaker for sorting (#539) Add a serialized transactions test vector for the edge case of sorting htlc-timeout-tx when there are multiple offered htlc with the same amount and preimage. The test vector reuses previous preimages and creates a case scenario with 1 received htlc and 2 offered, the two offered will have same scriptPubKey and redeemScript, but different CLTV value. It is asserted the order in which the htlc transactions should be kept internally and we assume the same order is used to construct the commitment_signed message. This complements #491 .
2021-03-05 09:10:26 +01:00
Here are the same test vectors, but when `option_static_remotekey` is used:
name: simple commitment tx with no HTLCs
to_local_msat: 7000000000
to_remote_msat: 3000000000
local_feerate_per_kw: 15000
# base commitment transaction fee = 10860
# actual commitment transaction fee = 10860
# to_local amount 6989140 wscript 63210212a140cd0c6539d07cd08dfe09984dec3251ea808b892efeac3ede9402bf2b1967029000b2752103fd5960528dc152014952efdb702a88f71e3c1653b2314431701ec77e57fde83c68ac
# to_remote amount 3000000 P2WPKH(032c0b7cf95324a07d05398b240174dc0c2be444d96b159aa6c7f7b1e668680991)
remote_signature = 3045022100c3127b33dcc741dd6b05b1e63cbd1a9a7d816f37af9b6756fa2376b056f032370220408b96279808fe57eb7e463710804cdf4f108388bc5cf722d8c848d2c7f9f3b0
# local_signature = 30440220616210b2cc4d3afb601013c373bbd8aac54febd9f15400379a8cb65ce7deca60022034236c010991beb7ff770510561ae8dc885b8d38d1947248c38f2ae055647142
output commit_tx: 02000000000101bef67e4e2fb9ddeeb3461973cd4c62abb35050b1add772995b820b584a488489000000000038b02b8002c0c62d0000000000160014cc1b07838e387deacd0e5232e1e8b49f4c29e48454a56a00000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e04004730440220616210b2cc4d3afb601013c373bbd8aac54febd9f15400379a8cb65ce7deca60022034236c010991beb7ff770510561ae8dc885b8d38d1947248c38f2ae05564714201483045022100c3127b33dcc741dd6b05b1e63cbd1a9a7d816f37af9b6756fa2376b056f032370220408b96279808fe57eb7e463710804cdf4f108388bc5cf722d8c848d2c7f9f3b001475221023da092f6980e58d2c037173180e9a465476026ee50f96695963e8efe436f54eb21030e9f7b623d2ccc7c9bd44d66d5ce21ce504c0acf6385a132cec6d3c39fa711c152ae3e195220
num_htlcs: 0
name: commitment tx with all five HTLCs untrimmed (minimum feerate)
to_local_msat: 6988000000
to_remote_msat: 3000000000
local_feerate_per_kw: 0
# base commitment transaction fee = 0
# actual commitment transaction fee = 0
Clarify Bolt 3 htlc tx output test vectors (#852) It was sometimes unclear where we indexed by the output or the htlc id. This is a follow-up from discussions made in #539.
2021-06-21 22:01:47 +02:00
# HTLC #2 offered amount 2000 wscript 76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c820120876475527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae67a914b43e1b38138a41b37f7cd9a1d274bc63e3a9b5d188ac6868
# HTLC #3 offered amount 3000 wscript 76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c820120876475527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae67a9148a486ff2e31d6158bf39e2608864d63fefd09d5b88ac6868
# HTLC #0 received amount 1000 wscript 76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c8201208763a914b8bcb07f6344b42ab04250c86a6e8b75d3fdbbc688527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae677502f401b175ac6868
# HTLC #1 received amount 2000 wscript 76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c8201208763a9144b6b2e5444c2639cc0fb7bcea5afba3f3cdce23988527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae677502f501b175ac6868
# HTLC #4 received amount 4000 wscript 76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c8201208763a91418bc1a114ccf9c052d3d23e28d3b0a9d1227434288527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae677502f801b175ac6868
BOLT 3: add test vectors for htlc-transactions in case where CLTV is used as tie-breaker for sorting (#539) Add a serialized transactions test vector for the edge case of sorting htlc-timeout-tx when there are multiple offered htlc with the same amount and preimage. The test vector reuses previous preimages and creates a case scenario with 1 received htlc and 2 offered, the two offered will have same scriptPubKey and redeemScript, but different CLTV value. It is asserted the order in which the htlc transactions should be kept internally and we assume the same order is used to construct the commitment_signed message. This complements #491 .
2021-03-05 09:10:26 +01:00
# to_local amount 6988000 wscript 63210212a140cd0c6539d07cd08dfe09984dec3251ea808b892efeac3ede9402bf2b1967029000b2752103fd5960528dc152014952efdb702a88f71e3c1653b2314431701ec77e57fde83c68ac
# to_remote amount 3000000 P2WPKH(032c0b7cf95324a07d05398b240174dc0c2be444d96b159aa6c7f7b1e668680991)
remote_signature = 3044022009b048187705a8cbc9ad73adbe5af148c3d012e1f067961486c822c7af08158c022006d66f3704cfab3eb2dc49dae24e4aa22a6910fc9b424007583204e3621af2e5
# local_signature = 304402206fc2d1f10ea59951eefac0b4b7c396a3c3d87b71ff0b019796ef4535beaf36f902201765b0181e514d04f4c8ad75659d7037be26cdb3f8bb6f78fe61decef484c3ea
output commit_tx: 02000000000101bef67e4e2fb9ddeeb3461973cd4c62abb35050b1add772995b820b584a488489000000000038b02b8007e80300000000000022002052bfef0479d7b293c27e0f1eb294bea154c63a3294ef092c19af51409bce0e2ad007000000000000220020403d394747cae42e98ff01734ad5c08f82ba123d3d9a620abda88989651e2ab5d007000000000000220020748eba944fedc8827f6b06bc44678f93c0f9e6078b35c6331ed31e75f8ce0c2db80b000000000000220020c20b5d1f8584fd90443e7b7b720136174fa4b9333c261d04dbbd012635c0f419a00f0000000000002200208c48d15160397c9731df9bc3b236656efb6665fbfe92b4a6878e88a499f741c4c0c62d0000000000160014cc1b07838e387deacd0e5232e1e8b49f4c29e484e0a06a00000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e040047304402206fc2d1f10ea59951eefac0b4b7c396a3c3d87b71ff0b019796ef4535beaf36f902201765b0181e514d04f4c8ad75659d7037be26cdb3f8bb6f78fe61decef484c3ea01473044022009b048187705a8cbc9ad73adbe5af148c3d012e1f067961486c822c7af08158c022006d66f3704cfab3eb2dc49dae24e4aa22a6910fc9b424007583204e3621af2e501475221023da092f6980e58d2c037173180e9a465476026ee50f96695963e8efe436f54eb21030e9f7b623d2ccc7c9bd44d66d5ce21ce504c0acf6385a132cec6d3c39fa711c152ae3e195220
num_htlcs: 5
Clarify Bolt 3 htlc tx output test vectors (#852) It was sometimes unclear where we indexed by the output or the htlc id. This is a follow-up from discussions made in #539.
2021-06-21 22:01:47 +02:00
# signature for output #0 (htlc-success for htlc #0)
BOLT 3: add test vectors for htlc-transactions in case where CLTV is used as tie-breaker for sorting (#539) Add a serialized transactions test vector for the edge case of sorting htlc-timeout-tx when there are multiple offered htlc with the same amount and preimage. The test vector reuses previous preimages and creates a case scenario with 1 received htlc and 2 offered, the two offered will have same scriptPubKey and redeemScript, but different CLTV value. It is asserted the order in which the htlc transactions should be kept internally and we assume the same order is used to construct the commitment_signed message. This complements #491 .
2021-03-05 09:10:26 +01:00
remote_htlc_signature = 3045022100d9e29616b8f3959f1d3d7f7ce893ffedcdc407717d0de8e37d808c91d3a7c50d022078c3033f6d00095c8720a4bc943c1b45727818c082e4e3ddbc6d3116435b624b
Clarify Bolt 3 htlc tx output test vectors (#852) It was sometimes unclear where we indexed by the output or the htlc id. This is a follow-up from discussions made in #539.
2021-06-21 22:01:47 +02:00
# local_htlc_signature = 30440220636de5682ef0c5b61f124ec74e8aa2461a69777521d6998295dcea36bc3338110220165285594b23c50b28b82df200234566628a27bcd17f7f14404bd865354eb3ce
htlc_success_tx (htlc #0): 02000000000101ab84ff284f162cfbfef241f853b47d4368d171f9e2a1445160cd591c4c7d882b00000000000000000001e8030000000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e0500483045022100d9e29616b8f3959f1d3d7f7ce893ffedcdc407717d0de8e37d808c91d3a7c50d022078c3033f6d00095c8720a4bc943c1b45727818c082e4e3ddbc6d3116435b624b014730440220636de5682ef0c5b61f124ec74e8aa2461a69777521d6998295dcea36bc3338110220165285594b23c50b28b82df200234566628a27bcd17f7f14404bd865354eb3ce012000000000000000000000000000000000000000000000000000000000000000008a76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c8201208763a914b8bcb07f6344b42ab04250c86a6e8b75d3fdbbc688527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae677502f401b175ac686800000000
# signature for output #1 (htlc-timeout for htlc #2)
BOLT 3: add test vectors for htlc-transactions in case where CLTV is used as tie-breaker for sorting (#539) Add a serialized transactions test vector for the edge case of sorting htlc-timeout-tx when there are multiple offered htlc with the same amount and preimage. The test vector reuses previous preimages and creates a case scenario with 1 received htlc and 2 offered, the two offered will have same scriptPubKey and redeemScript, but different CLTV value. It is asserted the order in which the htlc transactions should be kept internally and we assume the same order is used to construct the commitment_signed message. This complements #491 .
2021-03-05 09:10:26 +01:00
remote_htlc_signature = 30440220649fe8b20e67e46cbb0d09b4acea87dbec001b39b08dee7bdd0b1f03922a8640022037c462dff79df501cecfdb12ea7f4de91f99230bb544726f6e04527b1f896004
Clarify Bolt 3 htlc tx output test vectors (#852) It was sometimes unclear where we indexed by the output or the htlc id. This is a follow-up from discussions made in #539.
2021-06-21 22:01:47 +02:00
# local_htlc_signature = 3045022100803159dee7935dba4a1d36a61055ce8fd62caa528573cc221ae288515405a252022029c59e7cffce374fe860100a4a63787e105c3cf5156d40b12dd53ff55ac8cf3f
htlc_timeout_tx (htlc #2): 02000000000101ab84ff284f162cfbfef241f853b47d4368d171f9e2a1445160cd591c4c7d882b01000000000000000001d0070000000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e05004730440220649fe8b20e67e46cbb0d09b4acea87dbec001b39b08dee7bdd0b1f03922a8640022037c462dff79df501cecfdb12ea7f4de91f99230bb544726f6e04527b1f89600401483045022100803159dee7935dba4a1d36a61055ce8fd62caa528573cc221ae288515405a252022029c59e7cffce374fe860100a4a63787e105c3cf5156d40b12dd53ff55ac8cf3f01008576a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c820120876475527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae67a914b43e1b38138a41b37f7cd9a1d274bc63e3a9b5d188ac6868f6010000
# signature for output #2 (htlc-success for htlc #1)
BOLT 3: add test vectors for htlc-transactions in case where CLTV is used as tie-breaker for sorting (#539) Add a serialized transactions test vector for the edge case of sorting htlc-timeout-tx when there are multiple offered htlc with the same amount and preimage. The test vector reuses previous preimages and creates a case scenario with 1 received htlc and 2 offered, the two offered will have same scriptPubKey and redeemScript, but different CLTV value. It is asserted the order in which the htlc transactions should be kept internally and we assume the same order is used to construct the commitment_signed message. This complements #491 .
2021-03-05 09:10:26 +01:00
remote_htlc_signature = 30440220770fc321e97a19f38985f2e7732dd9fe08d16a2efa4bcbc0429400a447faf49102204d40b417f3113e1b0944ae0986f517564ab4acd3d190503faf97a6e420d43352
Clarify Bolt 3 htlc tx output test vectors (#852) It was sometimes unclear where we indexed by the output or the htlc id. This is a follow-up from discussions made in #539.
2021-06-21 22:01:47 +02:00
# local_htlc_signature = 3045022100a437cc2ce77400ecde441b3398fea3c3ad8bdad8132be818227fe3c5b8345989022069d45e7fa0ae551ec37240845e2c561ceb2567eacf3076a6a43a502d05865faa
htlc_success_tx (htlc #1): 02000000000101ab84ff284f162cfbfef241f853b47d4368d171f9e2a1445160cd591c4c7d882b02000000000000000001d0070000000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e05004730440220770fc321e97a19f38985f2e7732dd9fe08d16a2efa4bcbc0429400a447faf49102204d40b417f3113e1b0944ae0986f517564ab4acd3d190503faf97a6e420d4335201483045022100a437cc2ce77400ecde441b3398fea3c3ad8bdad8132be818227fe3c5b8345989022069d45e7fa0ae551ec37240845e2c561ceb2567eacf3076a6a43a502d05865faa012001010101010101010101010101010101010101010101010101010101010101018a76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c8201208763a9144b6b2e5444c2639cc0fb7bcea5afba3f3cdce23988527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae677502f501b175ac686800000000
# signature for output #3 (htlc-timeout for htlc #3)
BOLT 3: add test vectors for htlc-transactions in case where CLTV is used as tie-breaker for sorting (#539) Add a serialized transactions test vector for the edge case of sorting htlc-timeout-tx when there are multiple offered htlc with the same amount and preimage. The test vector reuses previous preimages and creates a case scenario with 1 received htlc and 2 offered, the two offered will have same scriptPubKey and redeemScript, but different CLTV value. It is asserted the order in which the htlc transactions should be kept internally and we assume the same order is used to construct the commitment_signed message. This complements #491 .
2021-03-05 09:10:26 +01:00
remote_htlc_signature = 304402207bcbf4f60a9829b05d2dbab84ed593e0291836be715dc7db6b72a64caf646af802201e489a5a84f7c5cc130398b841d138d031a5137ac8f4c49c770a4959dc3c1363
Clarify Bolt 3 htlc tx output test vectors (#852) It was sometimes unclear where we indexed by the output or the htlc id. This is a follow-up from discussions made in #539.
2021-06-21 22:01:47 +02:00
# local_htlc_signature = 304402203121d9b9c055f354304b016a36662ee99e1110d9501cb271b087ddb6f382c2c80220549882f3f3b78d9c492de47543cb9a697cecc493174726146536c5954dac7487
htlc_timeout_tx (htlc #3): 02000000000101ab84ff284f162cfbfef241f853b47d4368d171f9e2a1445160cd591c4c7d882b03000000000000000001b80b0000000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e050047304402207bcbf4f60a9829b05d2dbab84ed593e0291836be715dc7db6b72a64caf646af802201e489a5a84f7c5cc130398b841d138d031a5137ac8f4c49c770a4959dc3c13630147304402203121d9b9c055f354304b016a36662ee99e1110d9501cb271b087ddb6f382c2c80220549882f3f3b78d9c492de47543cb9a697cecc493174726146536c5954dac748701008576a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c820120876475527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae67a9148a486ff2e31d6158bf39e2608864d63fefd09d5b88ac6868f7010000
# signature for output #4 (htlc-success for htlc #4)
BOLT 3: add test vectors for htlc-transactions in case where CLTV is used as tie-breaker for sorting (#539) Add a serialized transactions test vector for the edge case of sorting htlc-timeout-tx when there are multiple offered htlc with the same amount and preimage. The test vector reuses previous preimages and creates a case scenario with 1 received htlc and 2 offered, the two offered will have same scriptPubKey and redeemScript, but different CLTV value. It is asserted the order in which the htlc transactions should be kept internally and we assume the same order is used to construct the commitment_signed message. This complements #491 .
2021-03-05 09:10:26 +01:00
remote_htlc_signature = 3044022076dca5cb81ba7e466e349b7128cdba216d4d01659e29b96025b9524aaf0d1899022060de85697b88b21c749702b7d2cfa7dfeaa1f472c8f1d7d9c23f2bf968464b87
Clarify Bolt 3 htlc tx output test vectors (#852) It was sometimes unclear where we indexed by the output or the htlc id. This is a follow-up from discussions made in #539.
2021-06-21 22:01:47 +02:00
# local_htlc_signature = 3045022100d9080f103cc92bac15ec42464a95f070c7fb6925014e673ee2ea1374d36a7f7502200c65294d22eb20d48564954d5afe04a385551919d8b2ddb4ae2459daaeee1d95
htlc_success_tx (htlc #4): 02000000000101ab84ff284f162cfbfef241f853b47d4368d171f9e2a1445160cd591c4c7d882b04000000000000000001a00f0000000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e0500473044022076dca5cb81ba7e466e349b7128cdba216d4d01659e29b96025b9524aaf0d1899022060de85697b88b21c749702b7d2cfa7dfeaa1f472c8f1d7d9c23f2bf968464b8701483045022100d9080f103cc92bac15ec42464a95f070c7fb6925014e673ee2ea1374d36a7f7502200c65294d22eb20d48564954d5afe04a385551919d8b2ddb4ae2459daaeee1d95012004040404040404040404040404040404040404040404040404040404040404048a76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c8201208763a91418bc1a114ccf9c052d3d23e28d3b0a9d1227434288527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae677502f801b175ac686800000000
BOLT 3: add test vectors for htlc-transactions in case where CLTV is used as tie-breaker for sorting (#539) Add a serialized transactions test vector for the edge case of sorting htlc-timeout-tx when there are multiple offered htlc with the same amount and preimage. The test vector reuses previous preimages and creates a case scenario with 1 received htlc and 2 offered, the two offered will have same scriptPubKey and redeemScript, but different CLTV value. It is asserted the order in which the htlc transactions should be kept internally and we assume the same order is used to construct the commitment_signed message. This complements #491 .
2021-03-05 09:10:26 +01:00
name: commitment tx with seven outputs untrimmed (maximum feerate)
to_local_msat: 6988000000
to_remote_msat: 3000000000
local_feerate_per_kw: 647
# base commitment transaction fee = 1024
# actual commitment transaction fee = 1024
Clarify Bolt 3 htlc tx output test vectors (#852) It was sometimes unclear where we indexed by the output or the htlc id. This is a follow-up from discussions made in #539.
2021-06-21 22:01:47 +02:00
# HTLC #2 offered amount 2000 wscript 76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c820120876475527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae67a914b43e1b38138a41b37f7cd9a1d274bc63e3a9b5d188ac6868
# HTLC #3 offered amount 3000 wscript 76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c820120876475527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae67a9148a486ff2e31d6158bf39e2608864d63fefd09d5b88ac6868
# HTLC #0 received amount 1000 wscript 76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c8201208763a914b8bcb07f6344b42ab04250c86a6e8b75d3fdbbc688527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae677502f401b175ac6868
# HTLC #1 received amount 2000 wscript 76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c8201208763a9144b6b2e5444c2639cc0fb7bcea5afba3f3cdce23988527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae677502f501b175ac6868
# HTLC #4 received amount 4000 wscript 76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c8201208763a91418bc1a114ccf9c052d3d23e28d3b0a9d1227434288527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae677502f801b175ac6868
BOLT 3: add test vectors for htlc-transactions in case where CLTV is used as tie-breaker for sorting (#539) Add a serialized transactions test vector for the edge case of sorting htlc-timeout-tx when there are multiple offered htlc with the same amount and preimage. The test vector reuses previous preimages and creates a case scenario with 1 received htlc and 2 offered, the two offered will have same scriptPubKey and redeemScript, but different CLTV value. It is asserted the order in which the htlc transactions should be kept internally and we assume the same order is used to construct the commitment_signed message. This complements #491 .
2021-03-05 09:10:26 +01:00
# to_local amount 6986976 wscript 63210212a140cd0c6539d07cd08dfe09984dec3251ea808b892efeac3ede9402bf2b1967029000b2752103fd5960528dc152014952efdb702a88f71e3c1653b2314431701ec77e57fde83c68ac
# to_remote amount 3000000 P2WPKH(032c0b7cf95324a07d05398b240174dc0c2be444d96b159aa6c7f7b1e668680991)
remote_signature = 3045022100a135f9e8a5ed25f7277446c67956b00ce6f610ead2bdec2c2f686155b7814772022059f1f6e1a8b336a68efcc1af3fe4d422d4827332b5b067501b099c47b7b5b5ee
# local_signature = 30450221009ec15c687898bb4da8b3a833e5ab8bfc51ec6e9202aaa8e66611edfd4a85ed1102203d7183e45078b9735c93450bc3415d3e5a8c576141a711ec6ddcb4a893926bb7
output commit_tx: 02000000000101bef67e4e2fb9ddeeb3461973cd4c62abb35050b1add772995b820b584a488489000000000038b02b8007e80300000000000022002052bfef0479d7b293c27e0f1eb294bea154c63a3294ef092c19af51409bce0e2ad007000000000000220020403d394747cae42e98ff01734ad5c08f82ba123d3d9a620abda88989651e2ab5d007000000000000220020748eba944fedc8827f6b06bc44678f93c0f9e6078b35c6331ed31e75f8ce0c2db80b000000000000220020c20b5d1f8584fd90443e7b7b720136174fa4b9333c261d04dbbd012635c0f419a00f0000000000002200208c48d15160397c9731df9bc3b236656efb6665fbfe92b4a6878e88a499f741c4c0c62d0000000000160014cc1b07838e387deacd0e5232e1e8b49f4c29e484e09c6a00000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e04004830450221009ec15c687898bb4da8b3a833e5ab8bfc51ec6e9202aaa8e66611edfd4a85ed1102203d7183e45078b9735c93450bc3415d3e5a8c576141a711ec6ddcb4a893926bb701483045022100a135f9e8a5ed25f7277446c67956b00ce6f610ead2bdec2c2f686155b7814772022059f1f6e1a8b336a68efcc1af3fe4d422d4827332b5b067501b099c47b7b5b5ee01475221023da092f6980e58d2c037173180e9a465476026ee50f96695963e8efe436f54eb21030e9f7b623d2ccc7c9bd44d66d5ce21ce504c0acf6385a132cec6d3c39fa711c152ae3e195220
num_htlcs: 5
Clarify Bolt 3 htlc tx output test vectors (#852) It was sometimes unclear where we indexed by the output or the htlc id. This is a follow-up from discussions made in #539.
2021-06-21 22:01:47 +02:00
# signature for output #0 (htlc-success for htlc #0)
BOLT 3: add test vectors for htlc-transactions in case where CLTV is used as tie-breaker for sorting (#539) Add a serialized transactions test vector for the edge case of sorting htlc-timeout-tx when there are multiple offered htlc with the same amount and preimage. The test vector reuses previous preimages and creates a case scenario with 1 received htlc and 2 offered, the two offered will have same scriptPubKey and redeemScript, but different CLTV value. It is asserted the order in which the htlc transactions should be kept internally and we assume the same order is used to construct the commitment_signed message. This complements #491 .
2021-03-05 09:10:26 +01:00
remote_htlc_signature = 30450221008437627f9ad84ac67052e2a414a4367b8556fd1f94d8b02590f89f50525cd33502205b9c21ff6e7fc864f2352746ad8ba59182510819acb644e25b8a12fc37bbf24f
Clarify Bolt 3 htlc tx output test vectors (#852) It was sometimes unclear where we indexed by the output or the htlc id. This is a follow-up from discussions made in #539.
2021-06-21 22:01:47 +02:00
# local_htlc_signature = 30440220344b0deb055230d01703e6c7acd45853c4af2328b49b5d8af4f88a060733406602202ea64f2a43d5751edfe75503cbc35a62e3141b5ed032fa03360faf4ca66f670b
htlc_success_tx (htlc #0): 020000000001012cfb3e4788c206881d38f2996b6cb2109b5935acb527d14bdaa7b908afa9b2fe0000000000000000000122020000000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e05004830450221008437627f9ad84ac67052e2a414a4367b8556fd1f94d8b02590f89f50525cd33502205b9c21ff6e7fc864f2352746ad8ba59182510819acb644e25b8a12fc37bbf24f014730440220344b0deb055230d01703e6c7acd45853c4af2328b49b5d8af4f88a060733406602202ea64f2a43d5751edfe75503cbc35a62e3141b5ed032fa03360faf4ca66f670b012000000000000000000000000000000000000000000000000000000000000000008a76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c8201208763a914b8bcb07f6344b42ab04250c86a6e8b75d3fdbbc688527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae677502f401b175ac686800000000
# signature for output #1 (htlc-timeout for htlc #2)
BOLT 3: add test vectors for htlc-transactions in case where CLTV is used as tie-breaker for sorting (#539) Add a serialized transactions test vector for the edge case of sorting htlc-timeout-tx when there are multiple offered htlc with the same amount and preimage. The test vector reuses previous preimages and creates a case scenario with 1 received htlc and 2 offered, the two offered will have same scriptPubKey and redeemScript, but different CLTV value. It is asserted the order in which the htlc transactions should be kept internally and we assume the same order is used to construct the commitment_signed message. This complements #491 .
2021-03-05 09:10:26 +01:00
remote_htlc_signature = 304402205a67f92bf6845cf2892b48d874ac1daf88a36495cf8a06f93d83180d930a6f75022031da1621d95c3f335cc06a3056cf960199dae600b7cf89088f65fc53cdbef28c
Clarify Bolt 3 htlc tx output test vectors (#852) It was sometimes unclear where we indexed by the output or the htlc id. This is a follow-up from discussions made in #539.
2021-06-21 22:01:47 +02:00
# local_htlc_signature = 30450221009e5e3822b0185c6799a95288c597b671d6cc69ab80f43740f00c6c3d0752bdda02206da947a74bd98f3175324dc56fdba86cc783703a120a6f0297537e60632f4c7f
htlc_timeout_tx (htlc #2): 020000000001012cfb3e4788c206881d38f2996b6cb2109b5935acb527d14bdaa7b908afa9b2fe0100000000000000000124060000000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e050047304402205a67f92bf6845cf2892b48d874ac1daf88a36495cf8a06f93d83180d930a6f75022031da1621d95c3f335cc06a3056cf960199dae600b7cf89088f65fc53cdbef28c014830450221009e5e3822b0185c6799a95288c597b671d6cc69ab80f43740f00c6c3d0752bdda02206da947a74bd98f3175324dc56fdba86cc783703a120a6f0297537e60632f4c7f01008576a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c820120876475527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae67a914b43e1b38138a41b37f7cd9a1d274bc63e3a9b5d188ac6868f6010000
# signature for output #2 (htlc-success for htlc #1)
BOLT 3: add test vectors for htlc-transactions in case where CLTV is used as tie-breaker for sorting (#539) Add a serialized transactions test vector for the edge case of sorting htlc-timeout-tx when there are multiple offered htlc with the same amount and preimage. The test vector reuses previous preimages and creates a case scenario with 1 received htlc and 2 offered, the two offered will have same scriptPubKey and redeemScript, but different CLTV value. It is asserted the order in which the htlc transactions should be kept internally and we assume the same order is used to construct the commitment_signed message. This complements #491 .
2021-03-05 09:10:26 +01:00
remote_htlc_signature = 30440220437e21766054a3eef7f65690c5bcfa9920babbc5af92b819f772f6ea96df6c7402207173622024bd97328cfb26c6665e25c2f5d67c319443ccdc60c903217005d8c8
Clarify Bolt 3 htlc tx output test vectors (#852) It was sometimes unclear where we indexed by the output or the htlc id. This is a follow-up from discussions made in #539.
2021-06-21 22:01:47 +02:00
# local_htlc_signature = 3045022100fcfc47e36b712624677626cef3dc1d67f6583bd46926a6398fe6b00b0c9a37760220525788257b187fc775c6370d04eadf34d06f3650a63f8df851cee0ecb47a1673
htlc_success_tx (htlc #1): 020000000001012cfb3e4788c206881d38f2996b6cb2109b5935acb527d14bdaa7b908afa9b2fe020000000000000000010a060000000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e05004730440220437e21766054a3eef7f65690c5bcfa9920babbc5af92b819f772f6ea96df6c7402207173622024bd97328cfb26c6665e25c2f5d67c319443ccdc60c903217005d8c801483045022100fcfc47e36b712624677626cef3dc1d67f6583bd46926a6398fe6b00b0c9a37760220525788257b187fc775c6370d04eadf34d06f3650a63f8df851cee0ecb47a1673012001010101010101010101010101010101010101010101010101010101010101018a76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c8201208763a9144b6b2e5444c2639cc0fb7bcea5afba3f3cdce23988527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae677502f501b175ac686800000000
# signature for output #3 (htlc-timeout for htlc #3)
BOLT 3: add test vectors for htlc-transactions in case where CLTV is used as tie-breaker for sorting (#539) Add a serialized transactions test vector for the edge case of sorting htlc-timeout-tx when there are multiple offered htlc with the same amount and preimage. The test vector reuses previous preimages and creates a case scenario with 1 received htlc and 2 offered, the two offered will have same scriptPubKey and redeemScript, but different CLTV value. It is asserted the order in which the htlc transactions should be kept internally and we assume the same order is used to construct the commitment_signed message. This complements #491 .
2021-03-05 09:10:26 +01:00
remote_htlc_signature = 304402207436e10737e4df499fc051686d3e11a5bb2310e4d1f1e691d287cef66514791202207cb58e71a6b7a42dd001b7e3ae672ea4f71ea3e1cd412b742e9124abb0739c64
Clarify Bolt 3 htlc tx output test vectors (#852) It was sometimes unclear where we indexed by the output or the htlc id. This is a follow-up from discussions made in #539.
2021-06-21 22:01:47 +02:00
# local_htlc_signature = 3045022100e78211b8409afb7255ffe37337da87f38646f1faebbdd61bc1920d69e3ead67a02201a626305adfcd16bfb7e9340928d9b6305464eab4aa4c4a3af6646e9b9f69dee
htlc_timeout_tx (htlc #3): 020000000001012cfb3e4788c206881d38f2996b6cb2109b5935acb527d14bdaa7b908afa9b2fe030000000000000000010c0a0000000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e050047304402207436e10737e4df499fc051686d3e11a5bb2310e4d1f1e691d287cef66514791202207cb58e71a6b7a42dd001b7e3ae672ea4f71ea3e1cd412b742e9124abb0739c6401483045022100e78211b8409afb7255ffe37337da87f38646f1faebbdd61bc1920d69e3ead67a02201a626305adfcd16bfb7e9340928d9b6305464eab4aa4c4a3af6646e9b9f69dee01008576a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c820120876475527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae67a9148a486ff2e31d6158bf39e2608864d63fefd09d5b88ac6868f7010000
# signature for output #4 (htlc-success for htlc #4)
BOLT 3: add test vectors for htlc-transactions in case where CLTV is used as tie-breaker for sorting (#539) Add a serialized transactions test vector for the edge case of sorting htlc-timeout-tx when there are multiple offered htlc with the same amount and preimage. The test vector reuses previous preimages and creates a case scenario with 1 received htlc and 2 offered, the two offered will have same scriptPubKey and redeemScript, but different CLTV value. It is asserted the order in which the htlc transactions should be kept internally and we assume the same order is used to construct the commitment_signed message. This complements #491 .
2021-03-05 09:10:26 +01:00
remote_htlc_signature = 30450221009acd6a827a76bfee50806178dfe0495cd4e1d9c58279c194c7b01520fe68cb8d022024d439047c368883e570997a7d40f0b430cb5a742f507965e7d3063ae3feccca
Clarify Bolt 3 htlc tx output test vectors (#852) It was sometimes unclear where we indexed by the output or the htlc id. This is a follow-up from discussions made in #539.
2021-06-21 22:01:47 +02:00
# local_htlc_signature = 3044022048762cf546bbfe474f1536365ea7c416e3c0389d60558bc9412cb148fb6ab68202207215d7083b75c96ff9d2b08c59c34e287b66820f530b486a9aa4cdd9c347d5b9
htlc_success_tx (htlc #4): 020000000001012cfb3e4788c206881d38f2996b6cb2109b5935acb527d14bdaa7b908afa9b2fe04000000000000000001da0d0000000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e05004830450221009acd6a827a76bfee50806178dfe0495cd4e1d9c58279c194c7b01520fe68cb8d022024d439047c368883e570997a7d40f0b430cb5a742f507965e7d3063ae3feccca01473044022048762cf546bbfe474f1536365ea7c416e3c0389d60558bc9412cb148fb6ab68202207215d7083b75c96ff9d2b08c59c34e287b66820f530b486a9aa4cdd9c347d5b9012004040404040404040404040404040404040404040404040404040404040404048a76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c8201208763a91418bc1a114ccf9c052d3d23e28d3b0a9d1227434288527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae677502f801b175ac686800000000
BOLT 3: add test vectors for htlc-transactions in case where CLTV is used as tie-breaker for sorting (#539) Add a serialized transactions test vector for the edge case of sorting htlc-timeout-tx when there are multiple offered htlc with the same amount and preimage. The test vector reuses previous preimages and creates a case scenario with 1 received htlc and 2 offered, the two offered will have same scriptPubKey and redeemScript, but different CLTV value. It is asserted the order in which the htlc transactions should be kept internally and we assume the same order is used to construct the commitment_signed message. This complements #491 .
2021-03-05 09:10:26 +01:00
name: commitment tx with six outputs untrimmed (minimum feerate)
to_local_msat: 6988000000
to_remote_msat: 3000000000
local_feerate_per_kw: 648
# base commitment transaction fee = 914
# actual commitment transaction fee = 1914
Clarify Bolt 3 htlc tx output test vectors (#852) It was sometimes unclear where we indexed by the output or the htlc id. This is a follow-up from discussions made in #539.
2021-06-21 22:01:47 +02:00
# HTLC #2 offered amount 2000 wscript 76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c820120876475527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae67a914b43e1b38138a41b37f7cd9a1d274bc63e3a9b5d188ac6868
# HTLC #3 offered amount 3000 wscript 76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c820120876475527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae67a9148a486ff2e31d6158bf39e2608864d63fefd09d5b88ac6868
# HTLC #1 received amount 2000 wscript 76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c8201208763a9144b6b2e5444c2639cc0fb7bcea5afba3f3cdce23988527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae677502f501b175ac6868
# HTLC #4 received amount 4000 wscript 76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c8201208763a91418bc1a114ccf9c052d3d23e28d3b0a9d1227434288527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae677502f801b175ac6868
BOLT 3: add test vectors for htlc-transactions in case where CLTV is used as tie-breaker for sorting (#539) Add a serialized transactions test vector for the edge case of sorting htlc-timeout-tx when there are multiple offered htlc with the same amount and preimage. The test vector reuses previous preimages and creates a case scenario with 1 received htlc and 2 offered, the two offered will have same scriptPubKey and redeemScript, but different CLTV value. It is asserted the order in which the htlc transactions should be kept internally and we assume the same order is used to construct the commitment_signed message. This complements #491 .
2021-03-05 09:10:26 +01:00
# to_local amount 6987086 wscript 63210212a140cd0c6539d07cd08dfe09984dec3251ea808b892efeac3ede9402bf2b1967029000b2752103fd5960528dc152014952efdb702a88f71e3c1653b2314431701ec77e57fde83c68ac
# to_remote amount 3000000 P2WPKH(032c0b7cf95324a07d05398b240174dc0c2be444d96b159aa6c7f7b1e668680991)
remote_signature = 304402203948f900a5506b8de36a4d8502f94f21dd84fd9c2314ab427d52feaa7a0a19f2022059b6a37a4adaa2c5419dc8aea63c6e2a2ec4c4bde46207f6dc1fcd22152fc6e5
# local_signature = 3045022100b15f72908ba3382a34ca5b32519240a22300cc6015b6f9418635fb41f3d01d8802207adb331b9ed1575383dca0f2355e86c173802feecf8298fbea53b9d4610583e9
output commit_tx: 02000000000101bef67e4e2fb9ddeeb3461973cd4c62abb35050b1add772995b820b584a488489000000000038b02b8006d007000000000000220020403d394747cae42e98ff01734ad5c08f82ba123d3d9a620abda88989651e2ab5d007000000000000220020748eba944fedc8827f6b06bc44678f93c0f9e6078b35c6331ed31e75f8ce0c2db80b000000000000220020c20b5d1f8584fd90443e7b7b720136174fa4b9333c261d04dbbd012635c0f419a00f0000000000002200208c48d15160397c9731df9bc3b236656efb6665fbfe92b4a6878e88a499f741c4c0c62d0000000000160014cc1b07838e387deacd0e5232e1e8b49f4c29e4844e9d6a00000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e0400483045022100b15f72908ba3382a34ca5b32519240a22300cc6015b6f9418635fb41f3d01d8802207adb331b9ed1575383dca0f2355e86c173802feecf8298fbea53b9d4610583e90147304402203948f900a5506b8de36a4d8502f94f21dd84fd9c2314ab427d52feaa7a0a19f2022059b6a37a4adaa2c5419dc8aea63c6e2a2ec4c4bde46207f6dc1fcd22152fc6e501475221023da092f6980e58d2c037173180e9a465476026ee50f96695963e8efe436f54eb21030e9f7b623d2ccc7c9bd44d66d5ce21ce504c0acf6385a132cec6d3c39fa711c152ae3e195220
num_htlcs: 4
Clarify Bolt 3 htlc tx output test vectors (#852) It was sometimes unclear where we indexed by the output or the htlc id. This is a follow-up from discussions made in #539.
2021-06-21 22:01:47 +02:00
# signature for output #0 (htlc-timeout for htlc #2)
BOLT 3: add test vectors for htlc-transactions in case where CLTV is used as tie-breaker for sorting (#539) Add a serialized transactions test vector for the edge case of sorting htlc-timeout-tx when there are multiple offered htlc with the same amount and preimage. The test vector reuses previous preimages and creates a case scenario with 1 received htlc and 2 offered, the two offered will have same scriptPubKey and redeemScript, but different CLTV value. It is asserted the order in which the htlc transactions should be kept internally and we assume the same order is used to construct the commitment_signed message. This complements #491 .
2021-03-05 09:10:26 +01:00
remote_htlc_signature = 3045022100a031202f3be94678f0e998622ee95ebb6ada8da1e9a5110228b5e04a747351e4022010ca6a21e18314ed53cfaae3b1f51998552a61a468e596368829a50ce40110e0
Clarify Bolt 3 htlc tx output test vectors (#852) It was sometimes unclear where we indexed by the output or the htlc id. This is a follow-up from discussions made in #539.
2021-06-21 22:01:47 +02:00
# local_htlc_signature = 304502210097e1873b57267730154595187a34949d3744f52933070c74757005e61ce2112e02204ecfba2aa42d4f14bdf8bad4206bb97217b702e6c433e0e1b0ce6587e6d46ec6
htlc_timeout_tx (htlc #2): 020000000001010f44041fdfba175987cf4e6135ba2a154e3b7fb96483dc0ed5efc0678e5b6bf10000000000000000000123060000000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e0500483045022100a031202f3be94678f0e998622ee95ebb6ada8da1e9a5110228b5e04a747351e4022010ca6a21e18314ed53cfaae3b1f51998552a61a468e596368829a50ce40110e00148304502210097e1873b57267730154595187a34949d3744f52933070c74757005e61ce2112e02204ecfba2aa42d4f14bdf8bad4206bb97217b702e6c433e0e1b0ce6587e6d46ec601008576a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c820120876475527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae67a914b43e1b38138a41b37f7cd9a1d274bc63e3a9b5d188ac6868f6010000
# signature for output #1 (htlc-success for htlc #1)
BOLT 3: add test vectors for htlc-transactions in case where CLTV is used as tie-breaker for sorting (#539) Add a serialized transactions test vector for the edge case of sorting htlc-timeout-tx when there are multiple offered htlc with the same amount and preimage. The test vector reuses previous preimages and creates a case scenario with 1 received htlc and 2 offered, the two offered will have same scriptPubKey and redeemScript, but different CLTV value. It is asserted the order in which the htlc transactions should be kept internally and we assume the same order is used to construct the commitment_signed message. This complements #491 .
2021-03-05 09:10:26 +01:00
remote_htlc_signature = 304402202361012a634aee7835c5ecdd6413dcffa8f404b7e77364c792cff984e4ee71e90220715c5e90baa08daa45a7439b1ee4fa4843ed77b19c058240b69406606d384124
Clarify Bolt 3 htlc tx output test vectors (#852) It was sometimes unclear where we indexed by the output or the htlc id. This is a follow-up from discussions made in #539.
2021-06-21 22:01:47 +02:00
# local_htlc_signature = 3044022019de73b00f1d818fb388e83b2c8c31f6bce35ac624e215bc12f88f9dc33edf48022006ff814bb9f700ee6abc3294e146fac3efd4f13f0005236b41c0a946ee00c9ae
htlc_success_tx (htlc #1): 020000000001010f44041fdfba175987cf4e6135ba2a154e3b7fb96483dc0ed5efc0678e5b6bf10100000000000000000109060000000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e050047304402202361012a634aee7835c5ecdd6413dcffa8f404b7e77364c792cff984e4ee71e90220715c5e90baa08daa45a7439b1ee4fa4843ed77b19c058240b69406606d38412401473044022019de73b00f1d818fb388e83b2c8c31f6bce35ac624e215bc12f88f9dc33edf48022006ff814bb9f700ee6abc3294e146fac3efd4f13f0005236b41c0a946ee00c9ae012001010101010101010101010101010101010101010101010101010101010101018a76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c8201208763a9144b6b2e5444c2639cc0fb7bcea5afba3f3cdce23988527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae677502f501b175ac686800000000
# signature for output #2 (htlc-timeout for htlc #3)
BOLT 3: add test vectors for htlc-transactions in case where CLTV is used as tie-breaker for sorting (#539) Add a serialized transactions test vector for the edge case of sorting htlc-timeout-tx when there are multiple offered htlc with the same amount and preimage. The test vector reuses previous preimages and creates a case scenario with 1 received htlc and 2 offered, the two offered will have same scriptPubKey and redeemScript, but different CLTV value. It is asserted the order in which the htlc transactions should be kept internally and we assume the same order is used to construct the commitment_signed message. This complements #491 .
2021-03-05 09:10:26 +01:00
remote_htlc_signature = 304402207e8e82cd71ed4febeb593732c260456836e97d81896153ecd2b3cf320ca6861702202dd4a30f68f98ced7cc56a36369ac1fdd978248c5ff4ed204fc00cc625532989
Clarify Bolt 3 htlc tx output test vectors (#852) It was sometimes unclear where we indexed by the output or the htlc id. This is a follow-up from discussions made in #539.
2021-06-21 22:01:47 +02:00
# local_htlc_signature = 3045022100bd0be6100c4fd8f102ec220e1b053e4c4e2ecca25615490150007b40d314dc3902201a1e0ea266965b43164d9e6576f58fa6726d42883dd1c3996d2925c2e2260796
htlc_timeout_tx (htlc #3): 020000000001010f44041fdfba175987cf4e6135ba2a154e3b7fb96483dc0ed5efc0678e5b6bf1020000000000000000010b0a0000000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e050047304402207e8e82cd71ed4febeb593732c260456836e97d81896153ecd2b3cf320ca6861702202dd4a30f68f98ced7cc56a36369ac1fdd978248c5ff4ed204fc00cc62553298901483045022100bd0be6100c4fd8f102ec220e1b053e4c4e2ecca25615490150007b40d314dc3902201a1e0ea266965b43164d9e6576f58fa6726d42883dd1c3996d2925c2e226079601008576a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c820120876475527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae67a9148a486ff2e31d6158bf39e2608864d63fefd09d5b88ac6868f7010000
# signature for output #3 (htlc-success for htlc #4)
BOLT 3: add test vectors for htlc-transactions in case where CLTV is used as tie-breaker for sorting (#539) Add a serialized transactions test vector for the edge case of sorting htlc-timeout-tx when there are multiple offered htlc with the same amount and preimage. The test vector reuses previous preimages and creates a case scenario with 1 received htlc and 2 offered, the two offered will have same scriptPubKey and redeemScript, but different CLTV value. It is asserted the order in which the htlc transactions should be kept internally and we assume the same order is used to construct the commitment_signed message. This complements #491 .
2021-03-05 09:10:26 +01:00
remote_htlc_signature = 3044022024cd52e4198c8ae0e414a86d86b5a65ea7450f2eb4e783096736d93395eca5ce022078f0094745b45be4d4b2b04dd5978c9e66ba49109e5704403e84aaf5f387d6be
Clarify Bolt 3 htlc tx output test vectors (#852) It was sometimes unclear where we indexed by the output or the htlc id. This is a follow-up from discussions made in #539.
2021-06-21 22:01:47 +02:00
# local_htlc_signature = 3045022100bbfb9d0a946d420807c86e985d636cceb16e71c3694ed186316251a00cbd807202207773223f9a337e145f64673825be9b30d07ef1542c82188b264bedcf7cda78c6
htlc_success_tx (htlc #4): 020000000001010f44041fdfba175987cf4e6135ba2a154e3b7fb96483dc0ed5efc0678e5b6bf103000000000000000001d90d0000000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e0500473044022024cd52e4198c8ae0e414a86d86b5a65ea7450f2eb4e783096736d93395eca5ce022078f0094745b45be4d4b2b04dd5978c9e66ba49109e5704403e84aaf5f387d6be01483045022100bbfb9d0a946d420807c86e985d636cceb16e71c3694ed186316251a00cbd807202207773223f9a337e145f64673825be9b30d07ef1542c82188b264bedcf7cda78c6012004040404040404040404040404040404040404040404040404040404040404048a76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c8201208763a91418bc1a114ccf9c052d3d23e28d3b0a9d1227434288527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae677502f801b175ac686800000000
BOLT 3: add test vectors for htlc-transactions in case where CLTV is used as tie-breaker for sorting (#539) Add a serialized transactions test vector for the edge case of sorting htlc-timeout-tx when there are multiple offered htlc with the same amount and preimage. The test vector reuses previous preimages and creates a case scenario with 1 received htlc and 2 offered, the two offered will have same scriptPubKey and redeemScript, but different CLTV value. It is asserted the order in which the htlc transactions should be kept internally and we assume the same order is used to construct the commitment_signed message. This complements #491 .
2021-03-05 09:10:26 +01:00
name: commitment tx with six outputs untrimmed (maximum feerate)
to_local_msat: 6988000000
to_remote_msat: 3000000000
local_feerate_per_kw: 2069
# base commitment transaction fee = 2921
# actual commitment transaction fee = 3921
Clarify Bolt 3 htlc tx output test vectors (#852) It was sometimes unclear where we indexed by the output or the htlc id. This is a follow-up from discussions made in #539.
2021-06-21 22:01:47 +02:00
# HTLC #2 offered amount 2000 wscript 76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c820120876475527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae67a914b43e1b38138a41b37f7cd9a1d274bc63e3a9b5d188ac6868
# HTLC #3 offered amount 3000 wscript 76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c820120876475527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae67a9148a486ff2e31d6158bf39e2608864d63fefd09d5b88ac6868
# HTLC #1 received amount 2000 wscript 76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c8201208763a9144b6b2e5444c2639cc0fb7bcea5afba3f3cdce23988527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae677502f501b175ac6868
# HTLC #4 received amount 4000 wscript 76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c8201208763a91418bc1a114ccf9c052d3d23e28d3b0a9d1227434288527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae677502f801b175ac6868
BOLT 3: add test vectors for htlc-transactions in case where CLTV is used as tie-breaker for sorting (#539) Add a serialized transactions test vector for the edge case of sorting htlc-timeout-tx when there are multiple offered htlc with the same amount and preimage. The test vector reuses previous preimages and creates a case scenario with 1 received htlc and 2 offered, the two offered will have same scriptPubKey and redeemScript, but different CLTV value. It is asserted the order in which the htlc transactions should be kept internally and we assume the same order is used to construct the commitment_signed message. This complements #491 .
2021-03-05 09:10:26 +01:00
# to_local amount 6985079 wscript 63210212a140cd0c6539d07cd08dfe09984dec3251ea808b892efeac3ede9402bf2b1967029000b2752103fd5960528dc152014952efdb702a88f71e3c1653b2314431701ec77e57fde83c68ac
# to_remote amount 3000000 P2WPKH(032c0b7cf95324a07d05398b240174dc0c2be444d96b159aa6c7f7b1e668680991)
remote_signature = 304502210090b96a2498ce0c0f2fadbec2aab278fed54c1a7838df793ec4d2c78d96ec096202204fdd439c50f90d483baa7b68feeef4bd33bc277695405447bcd0bfb2ca34d7bc
# local_signature = 3045022100ad9a9bbbb75d506ca3b716b336ee3cf975dd7834fcf129d7dd188146eb58a8b4022061a759ee417339f7fe2ea1e8deb83abb6a74db31a09b7648a932a639cda23e33
output commit_tx: 02000000000101bef67e4e2fb9ddeeb3461973cd4c62abb35050b1add772995b820b584a488489000000000038b02b8006d007000000000000220020403d394747cae42e98ff01734ad5c08f82ba123d3d9a620abda88989651e2ab5d007000000000000220020748eba944fedc8827f6b06bc44678f93c0f9e6078b35c6331ed31e75f8ce0c2db80b000000000000220020c20b5d1f8584fd90443e7b7b720136174fa4b9333c261d04dbbd012635c0f419a00f0000000000002200208c48d15160397c9731df9bc3b236656efb6665fbfe92b4a6878e88a499f741c4c0c62d0000000000160014cc1b07838e387deacd0e5232e1e8b49f4c29e48477956a00000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e0400483045022100ad9a9bbbb75d506ca3b716b336ee3cf975dd7834fcf129d7dd188146eb58a8b4022061a759ee417339f7fe2ea1e8deb83abb6a74db31a09b7648a932a639cda23e330148304502210090b96a2498ce0c0f2fadbec2aab278fed54c1a7838df793ec4d2c78d96ec096202204fdd439c50f90d483baa7b68feeef4bd33bc277695405447bcd0bfb2ca34d7bc01475221023da092f6980e58d2c037173180e9a465476026ee50f96695963e8efe436f54eb21030e9f7b623d2ccc7c9bd44d66d5ce21ce504c0acf6385a132cec6d3c39fa711c152ae3e195220
num_htlcs: 4
Clarify Bolt 3 htlc tx output test vectors (#852) It was sometimes unclear where we indexed by the output or the htlc id. This is a follow-up from discussions made in #539.
2021-06-21 22:01:47 +02:00
# signature for output #0 (htlc-timeout for htlc #2)
BOLT 3: add test vectors for htlc-transactions in case where CLTV is used as tie-breaker for sorting (#539) Add a serialized transactions test vector for the edge case of sorting htlc-timeout-tx when there are multiple offered htlc with the same amount and preimage. The test vector reuses previous preimages and creates a case scenario with 1 received htlc and 2 offered, the two offered will have same scriptPubKey and redeemScript, but different CLTV value. It is asserted the order in which the htlc transactions should be kept internally and we assume the same order is used to construct the commitment_signed message. This complements #491 .
2021-03-05 09:10:26 +01:00
remote_htlc_signature = 3045022100f33513ee38abf1c582876f921f8fddc06acff48e04515532a32d3938de938ffd02203aa308a2c1863b7d6fdf53159a1465bf2e115c13152546cc5d74483ceaa7f699
Clarify Bolt 3 htlc tx output test vectors (#852) It was sometimes unclear where we indexed by the output or the htlc id. This is a follow-up from discussions made in #539.
2021-06-21 22:01:47 +02:00
# local_htlc_signature = 3045022100a637902a5d4c9ba9e7c472a225337d5aac9e2e3f6744f76e237132e7619ba0400220035c60d784a031c0d9f6df66b7eab8726a5c25397399ee4aa960842059eb3f9d
htlc_timeout_tx (htlc #2): 02000000000101adbe717a63fb658add30ada1e6e12ed257637581898abe475c11d7bbcd65bd4d0000000000000000000175020000000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e0500483045022100f33513ee38abf1c582876f921f8fddc06acff48e04515532a32d3938de938ffd02203aa308a2c1863b7d6fdf53159a1465bf2e115c13152546cc5d74483ceaa7f69901483045022100a637902a5d4c9ba9e7c472a225337d5aac9e2e3f6744f76e237132e7619ba0400220035c60d784a031c0d9f6df66b7eab8726a5c25397399ee4aa960842059eb3f9d01008576a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c820120876475527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae67a914b43e1b38138a41b37f7cd9a1d274bc63e3a9b5d188ac6868f6010000
# signature for output #1 (htlc-success for htlc #1)
BOLT 3: add test vectors for htlc-transactions in case where CLTV is used as tie-breaker for sorting (#539) Add a serialized transactions test vector for the edge case of sorting htlc-timeout-tx when there are multiple offered htlc with the same amount and preimage. The test vector reuses previous preimages and creates a case scenario with 1 received htlc and 2 offered, the two offered will have same scriptPubKey and redeemScript, but different CLTV value. It is asserted the order in which the htlc transactions should be kept internally and we assume the same order is used to construct the commitment_signed message. This complements #491 .
2021-03-05 09:10:26 +01:00
remote_htlc_signature = 3045022100ce07682cf4b90093c22dc2d9ab2a77ad6803526b655ef857221cc96af5c9e0bf02200f501cee22e7a268af40b555d15a8237c9f36ad67ef1841daf9f6a0267b1e6df
Clarify Bolt 3 htlc tx output test vectors (#852) It was sometimes unclear where we indexed by the output or the htlc id. This is a follow-up from discussions made in #539.
2021-06-21 22:01:47 +02:00
# local_htlc_signature = 3045022100e57e46234f8782d3ff7aa593b4f7446fb5316c842e693dc63ee324fd49f6a1c302204a2f7b44c48bd26e1554422afae13153eb94b29d3687b733d18930615fb2db61
htlc_success_tx (htlc #1): 02000000000101adbe717a63fb658add30ada1e6e12ed257637581898abe475c11d7bbcd65bd4d0100000000000000000122020000000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e0500483045022100ce07682cf4b90093c22dc2d9ab2a77ad6803526b655ef857221cc96af5c9e0bf02200f501cee22e7a268af40b555d15a8237c9f36ad67ef1841daf9f6a0267b1e6df01483045022100e57e46234f8782d3ff7aa593b4f7446fb5316c842e693dc63ee324fd49f6a1c302204a2f7b44c48bd26e1554422afae13153eb94b29d3687b733d18930615fb2db61012001010101010101010101010101010101010101010101010101010101010101018a76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c8201208763a9144b6b2e5444c2639cc0fb7bcea5afba3f3cdce23988527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae677502f501b175ac686800000000
# signature for output #2 (htlc-timeout for htlc #3)
BOLT 3: add test vectors for htlc-transactions in case where CLTV is used as tie-breaker for sorting (#539) Add a serialized transactions test vector for the edge case of sorting htlc-timeout-tx when there are multiple offered htlc with the same amount and preimage. The test vector reuses previous preimages and creates a case scenario with 1 received htlc and 2 offered, the two offered will have same scriptPubKey and redeemScript, but different CLTV value. It is asserted the order in which the htlc transactions should be kept internally and we assume the same order is used to construct the commitment_signed message. This complements #491 .
2021-03-05 09:10:26 +01:00
remote_htlc_signature = 3045022100e3e35492e55f82ec0bc2f317ffd7a486d1f7024330fe9743c3559fc39f32ef0c02203d1d4db651fc388a91d5ad8ecdd8e83673063bc8eefe27cfd8c189090e3a23e0
Clarify Bolt 3 htlc tx output test vectors (#852) It was sometimes unclear where we indexed by the output or the htlc id. This is a follow-up from discussions made in #539.
2021-06-21 22:01:47 +02:00
# local_htlc_signature = 3044022068613fb1b98eb3aec7f44c5b115b12343c2f066c4277c82b5f873dfe68f37f50022028109b4650f3f528ca4bfe9a467aff2e3e43893b61b5159157119d5d95cf1c18
htlc_timeout_tx (htlc #3): 02000000000101adbe717a63fb658add30ada1e6e12ed257637581898abe475c11d7bbcd65bd4d020000000000000000015d060000000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e0500483045022100e3e35492e55f82ec0bc2f317ffd7a486d1f7024330fe9743c3559fc39f32ef0c02203d1d4db651fc388a91d5ad8ecdd8e83673063bc8eefe27cfd8c189090e3a23e001473044022068613fb1b98eb3aec7f44c5b115b12343c2f066c4277c82b5f873dfe68f37f50022028109b4650f3f528ca4bfe9a467aff2e3e43893b61b5159157119d5d95cf1c1801008576a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c820120876475527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae67a9148a486ff2e31d6158bf39e2608864d63fefd09d5b88ac6868f7010000
# signature for output #3 (htlc-success for htlc #4)
BOLT 3: add test vectors for htlc-transactions in case where CLTV is used as tie-breaker for sorting (#539) Add a serialized transactions test vector for the edge case of sorting htlc-timeout-tx when there are multiple offered htlc with the same amount and preimage. The test vector reuses previous preimages and creates a case scenario with 1 received htlc and 2 offered, the two offered will have same scriptPubKey and redeemScript, but different CLTV value. It is asserted the order in which the htlc transactions should be kept internally and we assume the same order is used to construct the commitment_signed message. This complements #491 .
2021-03-05 09:10:26 +01:00
remote_htlc_signature = 304402207475aeb0212ef9bf5130b60937817ad88c9a87976988ef1f323f026148cc4a850220739fea17ad3257dcad72e509c73eebe86bee30b178467b9fdab213d631b109df
Clarify Bolt 3 htlc tx output test vectors (#852) It was sometimes unclear where we indexed by the output or the htlc id. This is a follow-up from discussions made in #539.
2021-06-21 22:01:47 +02:00
# local_htlc_signature = 3045022100d315522e09e7d53d2a659a79cb67fef56d6c4bddf3f46df6772d0d20a7beb7c8022070bcc17e288607b6a72be0bd83368bb6d53488db266c1cdb4d72214e4f02ac33
htlc_success_tx (htlc #4): 02000000000101adbe717a63fb658add30ada1e6e12ed257637581898abe475c11d7bbcd65bd4d03000000000000000001f2090000000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e050047304402207475aeb0212ef9bf5130b60937817ad88c9a87976988ef1f323f026148cc4a850220739fea17ad3257dcad72e509c73eebe86bee30b178467b9fdab213d631b109df01483045022100d315522e09e7d53d2a659a79cb67fef56d6c4bddf3f46df6772d0d20a7beb7c8022070bcc17e288607b6a72be0bd83368bb6d53488db266c1cdb4d72214e4f02ac33012004040404040404040404040404040404040404040404040404040404040404048a76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c8201208763a91418bc1a114ccf9c052d3d23e28d3b0a9d1227434288527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae677502f801b175ac686800000000
BOLT 3: add test vectors for htlc-transactions in case where CLTV is used as tie-breaker for sorting (#539) Add a serialized transactions test vector for the edge case of sorting htlc-timeout-tx when there are multiple offered htlc with the same amount and preimage. The test vector reuses previous preimages and creates a case scenario with 1 received htlc and 2 offered, the two offered will have same scriptPubKey and redeemScript, but different CLTV value. It is asserted the order in which the htlc transactions should be kept internally and we assume the same order is used to construct the commitment_signed message. This complements #491 .
2021-03-05 09:10:26 +01:00
name: commitment tx with five outputs untrimmed (minimum feerate)
to_local_msat: 6988000000
to_remote_msat: 3000000000
local_feerate_per_kw: 2070
# base commitment transaction fee = 2566
# actual commitment transaction fee = 5566
Clarify Bolt 3 htlc tx output test vectors (#852) It was sometimes unclear where we indexed by the output or the htlc id. This is a follow-up from discussions made in #539.
2021-06-21 22:01:47 +02:00
# HTLC #2 offered amount 2000 wscript 76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c820120876475527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae67a914b43e1b38138a41b37f7cd9a1d274bc63e3a9b5d188ac6868
# HTLC #3 offered amount 3000 wscript 76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c820120876475527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae67a9148a486ff2e31d6158bf39e2608864d63fefd09d5b88ac6868
# HTLC #4 received amount 4000 wscript 76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c8201208763a91418bc1a114ccf9c052d3d23e28d3b0a9d1227434288527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae677502f801b175ac6868
BOLT 3: add test vectors for htlc-transactions in case where CLTV is used as tie-breaker for sorting (#539) Add a serialized transactions test vector for the edge case of sorting htlc-timeout-tx when there are multiple offered htlc with the same amount and preimage. The test vector reuses previous preimages and creates a case scenario with 1 received htlc and 2 offered, the two offered will have same scriptPubKey and redeemScript, but different CLTV value. It is asserted the order in which the htlc transactions should be kept internally and we assume the same order is used to construct the commitment_signed message. This complements #491 .
2021-03-05 09:10:26 +01:00
# to_local amount 6985434 wscript 63210212a140cd0c6539d07cd08dfe09984dec3251ea808b892efeac3ede9402bf2b1967029000b2752103fd5960528dc152014952efdb702a88f71e3c1653b2314431701ec77e57fde83c68ac
# to_remote amount 3000000 P2WPKH(032c0b7cf95324a07d05398b240174dc0c2be444d96b159aa6c7f7b1e668680991)
remote_signature = 304402204ca1ba260dee913d318271d86e10ca0f5883026fb5653155cff600fb40895223022037b145204b7054a40e08bb1fefbd826f827b40838d3e501423bcc57924bcb50c
# local_signature = 3044022001014419b5ba00e083ac4e0a85f19afc848aacac2d483b4b525d15e2ae5adbfe022015ebddad6ee1e72b47cb09f3e78459da5be01ccccd95dceca0e056a00cc773c1
output commit_tx: 02000000000101bef67e4e2fb9ddeeb3461973cd4c62abb35050b1add772995b820b584a488489000000000038b02b8005d007000000000000220020403d394747cae42e98ff01734ad5c08f82ba123d3d9a620abda88989651e2ab5b80b000000000000220020c20b5d1f8584fd90443e7b7b720136174fa4b9333c261d04dbbd012635c0f419a00f0000000000002200208c48d15160397c9731df9bc3b236656efb6665fbfe92b4a6878e88a499f741c4c0c62d0000000000160014cc1b07838e387deacd0e5232e1e8b49f4c29e484da966a00000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e0400473044022001014419b5ba00e083ac4e0a85f19afc848aacac2d483b4b525d15e2ae5adbfe022015ebddad6ee1e72b47cb09f3e78459da5be01ccccd95dceca0e056a00cc773c10147304402204ca1ba260dee913d318271d86e10ca0f5883026fb5653155cff600fb40895223022037b145204b7054a40e08bb1fefbd826f827b40838d3e501423bcc57924bcb50c01475221023da092f6980e58d2c037173180e9a465476026ee50f96695963e8efe436f54eb21030e9f7b623d2ccc7c9bd44d66d5ce21ce504c0acf6385a132cec6d3c39fa711c152ae3e195220
num_htlcs: 3
Clarify Bolt 3 htlc tx output test vectors (#852) It was sometimes unclear where we indexed by the output or the htlc id. This is a follow-up from discussions made in #539.
2021-06-21 22:01:47 +02:00
# signature for output #0 (htlc-timeout for htlc #2)
BOLT 3: add test vectors for htlc-transactions in case where CLTV is used as tie-breaker for sorting (#539) Add a serialized transactions test vector for the edge case of sorting htlc-timeout-tx when there are multiple offered htlc with the same amount and preimage. The test vector reuses previous preimages and creates a case scenario with 1 received htlc and 2 offered, the two offered will have same scriptPubKey and redeemScript, but different CLTV value. It is asserted the order in which the htlc transactions should be kept internally and we assume the same order is used to construct the commitment_signed message. This complements #491 .
2021-03-05 09:10:26 +01:00
remote_htlc_signature = 304402205f6b6d12d8d2529fb24f4445630566cf4abbd0f9330ab6c2bdb94222d6a2a0c502202f556258ae6f05b193749e4c541dfcc13b525a5422f6291f073f15617ba8579b
Clarify Bolt 3 htlc tx output test vectors (#852) It was sometimes unclear where we indexed by the output or the htlc id. This is a follow-up from discussions made in #539.
2021-06-21 22:01:47 +02:00
# local_htlc_signature = 30440220150b11069454da70caf2492ded9e0065c9a57f25ac2a4c52657b1d15b6c6ed85022068a38833b603c8892717206383611bad210f1cbb4b1f87ea29c6c65b9e1cb3e5
htlc_timeout_tx (htlc #2): 02000000000101403ad7602b43293497a3a2235a12ecefda4f3a1f1d06e49b1786d945685de1ff0000000000000000000174020000000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e050047304402205f6b6d12d8d2529fb24f4445630566cf4abbd0f9330ab6c2bdb94222d6a2a0c502202f556258ae6f05b193749e4c541dfcc13b525a5422f6291f073f15617ba8579b014730440220150b11069454da70caf2492ded9e0065c9a57f25ac2a4c52657b1d15b6c6ed85022068a38833b603c8892717206383611bad210f1cbb4b1f87ea29c6c65b9e1cb3e501008576a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c820120876475527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae67a914b43e1b38138a41b37f7cd9a1d274bc63e3a9b5d188ac6868f6010000
# signature for output #1 (htlc-timeout for htlc #3)
BOLT 3: add test vectors for htlc-transactions in case where CLTV is used as tie-breaker for sorting (#539) Add a serialized transactions test vector for the edge case of sorting htlc-timeout-tx when there are multiple offered htlc with the same amount and preimage. The test vector reuses previous preimages and creates a case scenario with 1 received htlc and 2 offered, the two offered will have same scriptPubKey and redeemScript, but different CLTV value. It is asserted the order in which the htlc transactions should be kept internally and we assume the same order is used to construct the commitment_signed message. This complements #491 .
2021-03-05 09:10:26 +01:00
remote_htlc_signature = 3045022100f960dfb1c9aee7ce1437efa65b523e399383e8149790e05d8fed27ff6e42fe0002202fe8613e062ffe0b0c518cc4101fba1c6de70f64a5bcc7ae663f2efae43b8546
Clarify Bolt 3 htlc tx output test vectors (#852) It was sometimes unclear where we indexed by the output or the htlc id. This is a follow-up from discussions made in #539.
2021-06-21 22:01:47 +02:00
# local_htlc_signature = 30450221009a6ed18e6873bc3644332a6ee21c152a5b102821865350df7a8c74451a51f9f2022050d801fb4895d7d7fbf452824c0168347f5c0cbe821cf6a97a63af5b8b2563c6
htlc_timeout_tx (htlc #3): 02000000000101403ad7602b43293497a3a2235a12ecefda4f3a1f1d06e49b1786d945685de1ff010000000000000000015c060000000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e0500483045022100f960dfb1c9aee7ce1437efa65b523e399383e8149790e05d8fed27ff6e42fe0002202fe8613e062ffe0b0c518cc4101fba1c6de70f64a5bcc7ae663f2efae43b8546014830450221009a6ed18e6873bc3644332a6ee21c152a5b102821865350df7a8c74451a51f9f2022050d801fb4895d7d7fbf452824c0168347f5c0cbe821cf6a97a63af5b8b2563c601008576a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c820120876475527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae67a9148a486ff2e31d6158bf39e2608864d63fefd09d5b88ac6868f7010000
# signature for output #2 (htlc-success for htlc #4)
BOLT 3: add test vectors for htlc-transactions in case where CLTV is used as tie-breaker for sorting (#539) Add a serialized transactions test vector for the edge case of sorting htlc-timeout-tx when there are multiple offered htlc with the same amount and preimage. The test vector reuses previous preimages and creates a case scenario with 1 received htlc and 2 offered, the two offered will have same scriptPubKey and redeemScript, but different CLTV value. It is asserted the order in which the htlc transactions should be kept internally and we assume the same order is used to construct the commitment_signed message. This complements #491 .
2021-03-05 09:10:26 +01:00
remote_htlc_signature = 3045022100ae5fc7717ae684bc1fcf9020854e5dbe9842c9e7472879ac06ff95ac2bb10e4e022057728ada4c00083a3e65493fb5d50a232165948a1a0f530ef63185c2c8c56504
Clarify Bolt 3 htlc tx output test vectors (#852) It was sometimes unclear where we indexed by the output or the htlc id. This is a follow-up from discussions made in #539.
2021-06-21 22:01:47 +02:00
# local_htlc_signature = 30440220408ad3009827a8fccf774cb285587686bfb2ed041f89a89453c311ce9c8ee0f902203c7392d9f8306d3a46522a66bd2723a7eb2628cb2d9b34d4c104f1766bf37502
htlc_success_tx (htlc #4): 02000000000101403ad7602b43293497a3a2235a12ecefda4f3a1f1d06e49b1786d945685de1ff02000000000000000001f1090000000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e0500483045022100ae5fc7717ae684bc1fcf9020854e5dbe9842c9e7472879ac06ff95ac2bb10e4e022057728ada4c00083a3e65493fb5d50a232165948a1a0f530ef63185c2c8c56504014730440220408ad3009827a8fccf774cb285587686bfb2ed041f89a89453c311ce9c8ee0f902203c7392d9f8306d3a46522a66bd2723a7eb2628cb2d9b34d4c104f1766bf37502012004040404040404040404040404040404040404040404040404040404040404048a76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c8201208763a91418bc1a114ccf9c052d3d23e28d3b0a9d1227434288527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae677502f801b175ac686800000000
BOLT 3: add test vectors for htlc-transactions in case where CLTV is used as tie-breaker for sorting (#539) Add a serialized transactions test vector for the edge case of sorting htlc-timeout-tx when there are multiple offered htlc with the same amount and preimage. The test vector reuses previous preimages and creates a case scenario with 1 received htlc and 2 offered, the two offered will have same scriptPubKey and redeemScript, but different CLTV value. It is asserted the order in which the htlc transactions should be kept internally and we assume the same order is used to construct the commitment_signed message. This complements #491 .
2021-03-05 09:10:26 +01:00
name: commitment tx with five outputs untrimmed (maximum feerate)
to_local_msat: 6988000000
to_remote_msat: 3000000000
local_feerate_per_kw: 2194
# base commitment transaction fee = 2720
# actual commitment transaction fee = 5720
Clarify Bolt 3 htlc tx output test vectors (#852) It was sometimes unclear where we indexed by the output or the htlc id. This is a follow-up from discussions made in #539.
2021-06-21 22:01:47 +02:00
# HTLC #2 offered amount 2000 wscript 76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c820120876475527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae67a914b43e1b38138a41b37f7cd9a1d274bc63e3a9b5d188ac6868
# HTLC #3 offered amount 3000 wscript 76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c820120876475527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae67a9148a486ff2e31d6158bf39e2608864d63fefd09d5b88ac6868
# HTLC #4 received amount 4000 wscript 76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c8201208763a91418bc1a114ccf9c052d3d23e28d3b0a9d1227434288527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae677502f801b175ac6868
BOLT 3: add test vectors for htlc-transactions in case where CLTV is used as tie-breaker for sorting (#539) Add a serialized transactions test vector for the edge case of sorting htlc-timeout-tx when there are multiple offered htlc with the same amount and preimage. The test vector reuses previous preimages and creates a case scenario with 1 received htlc and 2 offered, the two offered will have same scriptPubKey and redeemScript, but different CLTV value. It is asserted the order in which the htlc transactions should be kept internally and we assume the same order is used to construct the commitment_signed message. This complements #491 .
2021-03-05 09:10:26 +01:00
# to_local amount 6985280 wscript 63210212a140cd0c6539d07cd08dfe09984dec3251ea808b892efeac3ede9402bf2b1967029000b2752103fd5960528dc152014952efdb702a88f71e3c1653b2314431701ec77e57fde83c68ac
# to_remote amount 3000000 P2WPKH(032c0b7cf95324a07d05398b240174dc0c2be444d96b159aa6c7f7b1e668680991)
remote_signature = 304402204bb3d6e279d71d9da414c82de42f1f954267c762b2e2eb8b76bc3be4ea07d4b0022014febc009c5edc8c3fc5d94015de163200f780046f1c293bfed8568f08b70fb3
# local_signature = 3044022072c2e2b1c899b2242656a537dde2892fa3801be0d6df0a87836c550137acde8302201654aa1974d37a829083c3ba15088689f30b56d6a4f6cb14c7bad0ee3116d398
output commit_tx: 02000000000101bef67e4e2fb9ddeeb3461973cd4c62abb35050b1add772995b820b584a488489000000000038b02b8005d007000000000000220020403d394747cae42e98ff01734ad5c08f82ba123d3d9a620abda88989651e2ab5b80b000000000000220020c20b5d1f8584fd90443e7b7b720136174fa4b9333c261d04dbbd012635c0f419a00f0000000000002200208c48d15160397c9731df9bc3b236656efb6665fbfe92b4a6878e88a499f741c4c0c62d0000000000160014cc1b07838e387deacd0e5232e1e8b49f4c29e48440966a00000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e0400473044022072c2e2b1c899b2242656a537dde2892fa3801be0d6df0a87836c550137acde8302201654aa1974d37a829083c3ba15088689f30b56d6a4f6cb14c7bad0ee3116d3980147304402204bb3d6e279d71d9da414c82de42f1f954267c762b2e2eb8b76bc3be4ea07d4b0022014febc009c5edc8c3fc5d94015de163200f780046f1c293bfed8568f08b70fb301475221023da092f6980e58d2c037173180e9a465476026ee50f96695963e8efe436f54eb21030e9f7b623d2ccc7c9bd44d66d5ce21ce504c0acf6385a132cec6d3c39fa711c152ae3e195220
num_htlcs: 3
Clarify Bolt 3 htlc tx output test vectors (#852) It was sometimes unclear where we indexed by the output or the htlc id. This is a follow-up from discussions made in #539.
2021-06-21 22:01:47 +02:00
# signature for output #0 (htlc-timeout for htlc #2)
BOLT 3: add test vectors for htlc-transactions in case where CLTV is used as tie-breaker for sorting (#539) Add a serialized transactions test vector for the edge case of sorting htlc-timeout-tx when there are multiple offered htlc with the same amount and preimage. The test vector reuses previous preimages and creates a case scenario with 1 received htlc and 2 offered, the two offered will have same scriptPubKey and redeemScript, but different CLTV value. It is asserted the order in which the htlc transactions should be kept internally and we assume the same order is used to construct the commitment_signed message. This complements #491 .
2021-03-05 09:10:26 +01:00
remote_htlc_signature = 3045022100939726680351a7856c1bc386d4a1f422c7d29bd7b56afc139570f508474e6c40022023175a799ccf44c017fbaadb924c40b2a12115a5b7d0dfd3228df803a2de8450
Clarify Bolt 3 htlc tx output test vectors (#852) It was sometimes unclear where we indexed by the output or the htlc id. This is a follow-up from discussions made in #539.
2021-06-21 22:01:47 +02:00
# local_htlc_signature = 304502210099c98c2edeeee6ec0fb5f3bea8b79bb016a2717afa9b5072370f34382de281d302206f5e2980a995e045cf90a547f0752a7ee99d48547bc135258fe7bc07e0154301
htlc_timeout_tx (htlc #2): 02000000000101153cd825fdb3aa624bfe513e8031d5d08c5e582fb3d1d1fe8faf27d3eed410cd0000000000000000000122020000000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e0500483045022100939726680351a7856c1bc386d4a1f422c7d29bd7b56afc139570f508474e6c40022023175a799ccf44c017fbaadb924c40b2a12115a5b7d0dfd3228df803a2de84500148304502210099c98c2edeeee6ec0fb5f3bea8b79bb016a2717afa9b5072370f34382de281d302206f5e2980a995e045cf90a547f0752a7ee99d48547bc135258fe7bc07e015430101008576a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c820120876475527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae67a914b43e1b38138a41b37f7cd9a1d274bc63e3a9b5d188ac6868f6010000
# signature for output #1 (htlc-timeout for htlc #3)
BOLT 3: add test vectors for htlc-transactions in case where CLTV is used as tie-breaker for sorting (#539) Add a serialized transactions test vector for the edge case of sorting htlc-timeout-tx when there are multiple offered htlc with the same amount and preimage. The test vector reuses previous preimages and creates a case scenario with 1 received htlc and 2 offered, the two offered will have same scriptPubKey and redeemScript, but different CLTV value. It is asserted the order in which the htlc transactions should be kept internally and we assume the same order is used to construct the commitment_signed message. This complements #491 .
2021-03-05 09:10:26 +01:00
remote_htlc_signature = 3044022021bb883bf324553d085ba2e821cad80c28ef8b303dbead8f98e548783c02d1600220638f9ef2a9bba25869afc923f4b5dc38be3bb459f9efa5d869392d5f7779a4a0
Clarify Bolt 3 htlc tx output test vectors (#852) It was sometimes unclear where we indexed by the output or the htlc id. This is a follow-up from discussions made in #539.
2021-06-21 22:01:47 +02:00
# local_htlc_signature = 3045022100fd85bd7697b89c08ec12acc8ba89b23090637d83abd26ca37e01ae93e67c367302202b551fe69386116c47f984aab9c8dfd25d864dcde5d3389cfbef2447a85c4b77
htlc_timeout_tx (htlc #3): 02000000000101153cd825fdb3aa624bfe513e8031d5d08c5e582fb3d1d1fe8faf27d3eed410cd010000000000000000010a060000000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e0500473044022021bb883bf324553d085ba2e821cad80c28ef8b303dbead8f98e548783c02d1600220638f9ef2a9bba25869afc923f4b5dc38be3bb459f9efa5d869392d5f7779a4a001483045022100fd85bd7697b89c08ec12acc8ba89b23090637d83abd26ca37e01ae93e67c367302202b551fe69386116c47f984aab9c8dfd25d864dcde5d3389cfbef2447a85c4b7701008576a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c820120876475527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae67a9148a486ff2e31d6158bf39e2608864d63fefd09d5b88ac6868f7010000
# signature for output #2 (htlc-success for htlc #4)
BOLT 3: add test vectors for htlc-transactions in case where CLTV is used as tie-breaker for sorting (#539) Add a serialized transactions test vector for the edge case of sorting htlc-timeout-tx when there are multiple offered htlc with the same amount and preimage. The test vector reuses previous preimages and creates a case scenario with 1 received htlc and 2 offered, the two offered will have same scriptPubKey and redeemScript, but different CLTV value. It is asserted the order in which the htlc transactions should be kept internally and we assume the same order is used to construct the commitment_signed message. This complements #491 .
2021-03-05 09:10:26 +01:00
remote_htlc_signature = 3045022100c9e6f0454aa598b905a35e641a70cc9f67b5f38cc4b00843a041238c4a9f1c4a0220260a2822a62da97e44583e837245995ca2e36781769c52f19e498efbdcca262b
Clarify Bolt 3 htlc tx output test vectors (#852) It was sometimes unclear where we indexed by the output or the htlc id. This is a follow-up from discussions made in #539.
2021-06-21 22:01:47 +02:00
# local_htlc_signature = 30450221008a9f2ea24cd455c2b64c1472a5fa83865b0a5f49a62b661801e884cf2849af8302204d44180e50bf6adfcf1c1e581d75af91aba4e28681ce4a5ee5f3cbf65eca10f3
htlc_success_tx (htlc #4): 02000000000101153cd825fdb3aa624bfe513e8031d5d08c5e582fb3d1d1fe8faf27d3eed410cd020000000000000000019a090000000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e0500483045022100c9e6f0454aa598b905a35e641a70cc9f67b5f38cc4b00843a041238c4a9f1c4a0220260a2822a62da97e44583e837245995ca2e36781769c52f19e498efbdcca262b014830450221008a9f2ea24cd455c2b64c1472a5fa83865b0a5f49a62b661801e884cf2849af8302204d44180e50bf6adfcf1c1e581d75af91aba4e28681ce4a5ee5f3cbf65eca10f3012004040404040404040404040404040404040404040404040404040404040404048a76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c8201208763a91418bc1a114ccf9c052d3d23e28d3b0a9d1227434288527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae677502f801b175ac686800000000
BOLT 3: add test vectors for htlc-transactions in case where CLTV is used as tie-breaker for sorting (#539) Add a serialized transactions test vector for the edge case of sorting htlc-timeout-tx when there are multiple offered htlc with the same amount and preimage. The test vector reuses previous preimages and creates a case scenario with 1 received htlc and 2 offered, the two offered will have same scriptPubKey and redeemScript, but different CLTV value. It is asserted the order in which the htlc transactions should be kept internally and we assume the same order is used to construct the commitment_signed message. This complements #491 .
2021-03-05 09:10:26 +01:00
name: commitment tx with four outputs untrimmed (minimum feerate)
to_local_msat: 6988000000
to_remote_msat: 3000000000
local_feerate_per_kw: 2195
# base commitment transaction fee = 2344
# actual commitment transaction fee = 7344
Clarify Bolt 3 htlc tx output test vectors (#852) It was sometimes unclear where we indexed by the output or the htlc id. This is a follow-up from discussions made in #539.
2021-06-21 22:01:47 +02:00
# HTLC #3 offered amount 3000 wscript 76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c820120876475527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae67a9148a486ff2e31d6158bf39e2608864d63fefd09d5b88ac6868
# HTLC #4 received amount 4000 wscript 76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c8201208763a91418bc1a114ccf9c052d3d23e28d3b0a9d1227434288527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae677502f801b175ac6868
BOLT 3: add test vectors for htlc-transactions in case where CLTV is used as tie-breaker for sorting (#539) Add a serialized transactions test vector for the edge case of sorting htlc-timeout-tx when there are multiple offered htlc with the same amount and preimage. The test vector reuses previous preimages and creates a case scenario with 1 received htlc and 2 offered, the two offered will have same scriptPubKey and redeemScript, but different CLTV value. It is asserted the order in which the htlc transactions should be kept internally and we assume the same order is used to construct the commitment_signed message. This complements #491 .
2021-03-05 09:10:26 +01:00
# to_local amount 6985656 wscript 63210212a140cd0c6539d07cd08dfe09984dec3251ea808b892efeac3ede9402bf2b1967029000b2752103fd5960528dc152014952efdb702a88f71e3c1653b2314431701ec77e57fde83c68ac
# to_remote amount 3000000 P2WPKH(032c0b7cf95324a07d05398b240174dc0c2be444d96b159aa6c7f7b1e668680991)
remote_signature = 304402201a8c1b1f9671cd9e46c7323a104d7047cc48d3ee80d40d4512e0c72b8dc65666022066d7f9a2ce18c9eb22d2739ffcce05721c767f9b607622a31b6ea5793ddce403
# local_signature = 3044022044d592025b610c0d678f65032e87035cdfe89d1598c522cc32524ae8172417c30220749fef9d5b2ae8cdd91ece442ba8809bc891efedae2291e578475f97715d1767
output commit_tx: 02000000000101bef67e4e2fb9ddeeb3461973cd4c62abb35050b1add772995b820b584a488489000000000038b02b8004b80b000000000000220020c20b5d1f8584fd90443e7b7b720136174fa4b9333c261d04dbbd012635c0f419a00f0000000000002200208c48d15160397c9731df9bc3b236656efb6665fbfe92b4a6878e88a499f741c4c0c62d0000000000160014cc1b07838e387deacd0e5232e1e8b49f4c29e484b8976a00000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e0400473044022044d592025b610c0d678f65032e87035cdfe89d1598c522cc32524ae8172417c30220749fef9d5b2ae8cdd91ece442ba8809bc891efedae2291e578475f97715d17670147304402201a8c1b1f9671cd9e46c7323a104d7047cc48d3ee80d40d4512e0c72b8dc65666022066d7f9a2ce18c9eb22d2739ffcce05721c767f9b607622a31b6ea5793ddce40301475221023da092f6980e58d2c037173180e9a465476026ee50f96695963e8efe436f54eb21030e9f7b623d2ccc7c9bd44d66d5ce21ce504c0acf6385a132cec6d3c39fa711c152ae3e195220
num_htlcs: 2
Clarify Bolt 3 htlc tx output test vectors (#852) It was sometimes unclear where we indexed by the output or the htlc id. This is a follow-up from discussions made in #539.
2021-06-21 22:01:47 +02:00
# signature for output #0 (htlc-timeout for htlc #3)
BOLT 3: add test vectors for htlc-transactions in case where CLTV is used as tie-breaker for sorting (#539) Add a serialized transactions test vector for the edge case of sorting htlc-timeout-tx when there are multiple offered htlc with the same amount and preimage. The test vector reuses previous preimages and creates a case scenario with 1 received htlc and 2 offered, the two offered will have same scriptPubKey and redeemScript, but different CLTV value. It is asserted the order in which the htlc transactions should be kept internally and we assume the same order is used to construct the commitment_signed message. This complements #491 .
2021-03-05 09:10:26 +01:00
remote_htlc_signature = 3045022100e57b845066a06ee7c2cbfc29eabffe52daa9bf6f6de760066d04df9f9b250e0002202ffb197f0e6e0a77a75a9aff27014bd3de83b7f748d7efef986abe655e1dd50e
Clarify Bolt 3 htlc tx output test vectors (#852) It was sometimes unclear where we indexed by the output or the htlc id. This is a follow-up from discussions made in #539.
2021-06-21 22:01:47 +02:00
# local_htlc_signature = 3045022100ecc8c6529d0b2316d046f0f0757c1e1c25a636db168ec4f3aa1b9278df685dc0022067ae6b65e936f1337091f7b18a15935b608c5f2cdddb2f892ed0babfdd376d76
htlc_timeout_tx (htlc #3): 020000000001018130a10f09b13677ba2885a8bca32860f3a952e5912b829a473639b5a2c07b900000000000000000000109060000000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e0500483045022100e57b845066a06ee7c2cbfc29eabffe52daa9bf6f6de760066d04df9f9b250e0002202ffb197f0e6e0a77a75a9aff27014bd3de83b7f748d7efef986abe655e1dd50e01483045022100ecc8c6529d0b2316d046f0f0757c1e1c25a636db168ec4f3aa1b9278df685dc0022067ae6b65e936f1337091f7b18a15935b608c5f2cdddb2f892ed0babfdd376d7601008576a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c820120876475527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae67a9148a486ff2e31d6158bf39e2608864d63fefd09d5b88ac6868f7010000
# signature for output #1 (htlc-success for htlc #4)
BOLT 3: add test vectors for htlc-transactions in case where CLTV is used as tie-breaker for sorting (#539) Add a serialized transactions test vector for the edge case of sorting htlc-timeout-tx when there are multiple offered htlc with the same amount and preimage. The test vector reuses previous preimages and creates a case scenario with 1 received htlc and 2 offered, the two offered will have same scriptPubKey and redeemScript, but different CLTV value. It is asserted the order in which the htlc transactions should be kept internally and we assume the same order is used to construct the commitment_signed message. This complements #491 .
2021-03-05 09:10:26 +01:00
remote_htlc_signature = 3045022100d193b7ecccad8057571620a0b1ffa6c48e9483311723b59cf536043b20bc51550220546d4bd37b3b101ecda14f6c907af46ec391abce1cd9c7ce22b1a62b534f2f2a
Clarify Bolt 3 htlc tx output test vectors (#852) It was sometimes unclear where we indexed by the output or the htlc id. This is a follow-up from discussions made in #539.
2021-06-21 22:01:47 +02:00
# local_htlc_signature = 3044022014d66f11f9cacf923807eba49542076c5fe5cccf252fb08fe98c78ef3ca6ab5402201b290dbe043cc512d9d78de074a5a129b8759bc6a6c546b190d120b690bd6e82
htlc_success_tx (htlc #4): 020000000001018130a10f09b13677ba2885a8bca32860f3a952e5912b829a473639b5a2c07b900100000000000000000199090000000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e0500483045022100d193b7ecccad8057571620a0b1ffa6c48e9483311723b59cf536043b20bc51550220546d4bd37b3b101ecda14f6c907af46ec391abce1cd9c7ce22b1a62b534f2f2a01473044022014d66f11f9cacf923807eba49542076c5fe5cccf252fb08fe98c78ef3ca6ab5402201b290dbe043cc512d9d78de074a5a129b8759bc6a6c546b190d120b690bd6e82012004040404040404040404040404040404040404040404040404040404040404048a76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c8201208763a91418bc1a114ccf9c052d3d23e28d3b0a9d1227434288527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae677502f801b175ac686800000000
BOLT 3: add test vectors for htlc-transactions in case where CLTV is used as tie-breaker for sorting (#539) Add a serialized transactions test vector for the edge case of sorting htlc-timeout-tx when there are multiple offered htlc with the same amount and preimage. The test vector reuses previous preimages and creates a case scenario with 1 received htlc and 2 offered, the two offered will have same scriptPubKey and redeemScript, but different CLTV value. It is asserted the order in which the htlc transactions should be kept internally and we assume the same order is used to construct the commitment_signed message. This complements #491 .
2021-03-05 09:10:26 +01:00
name: commitment tx with four outputs untrimmed (maximum feerate)
to_local_msat: 6988000000
to_remote_msat: 3000000000
local_feerate_per_kw: 3702
# base commitment transaction fee = 3953
# actual commitment transaction fee = 8953
Clarify Bolt 3 htlc tx output test vectors (#852) It was sometimes unclear where we indexed by the output or the htlc id. This is a follow-up from discussions made in #539.
2021-06-21 22:01:47 +02:00
# HTLC #3 offered amount 3000 wscript 76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c820120876475527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae67a9148a486ff2e31d6158bf39e2608864d63fefd09d5b88ac6868
# HTLC #4 received amount 4000 wscript 76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c8201208763a91418bc1a114ccf9c052d3d23e28d3b0a9d1227434288527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae677502f801b175ac6868
BOLT 3: add test vectors for htlc-transactions in case where CLTV is used as tie-breaker for sorting (#539) Add a serialized transactions test vector for the edge case of sorting htlc-timeout-tx when there are multiple offered htlc with the same amount and preimage. The test vector reuses previous preimages and creates a case scenario with 1 received htlc and 2 offered, the two offered will have same scriptPubKey and redeemScript, but different CLTV value. It is asserted the order in which the htlc transactions should be kept internally and we assume the same order is used to construct the commitment_signed message. This complements #491 .
2021-03-05 09:10:26 +01:00
# to_local amount 6984047 wscript 63210212a140cd0c6539d07cd08dfe09984dec3251ea808b892efeac3ede9402bf2b1967029000b2752103fd5960528dc152014952efdb702a88f71e3c1653b2314431701ec77e57fde83c68ac
# to_remote amount 3000000 P2WPKH(032c0b7cf95324a07d05398b240174dc0c2be444d96b159aa6c7f7b1e668680991)
remote_signature = 304502210092a587aeb777f869e7ff0d7898ea619ee26a3dacd1f3672b945eea600be431100220077ee9eae3528d15251f2a52b607b189820e57a6ccfac8d1af502b132ee40169
# local_signature = 3045022100e5efb73c32d32da2d79702299b6317de6fb24a60476e3855926d78484dd1b3c802203557cb66a42c944ef06e00bcc4da35a5bcb2f185aab0f8e403e519e1d66aaf75
output commit_tx: 02000000000101bef67e4e2fb9ddeeb3461973cd4c62abb35050b1add772995b820b584a488489000000000038b02b8004b80b000000000000220020c20b5d1f8584fd90443e7b7b720136174fa4b9333c261d04dbbd012635c0f419a00f0000000000002200208c48d15160397c9731df9bc3b236656efb6665fbfe92b4a6878e88a499f741c4c0c62d0000000000160014cc1b07838e387deacd0e5232e1e8b49f4c29e4846f916a00000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e0400483045022100e5efb73c32d32da2d79702299b6317de6fb24a60476e3855926d78484dd1b3c802203557cb66a42c944ef06e00bcc4da35a5bcb2f185aab0f8e403e519e1d66aaf750148304502210092a587aeb777f869e7ff0d7898ea619ee26a3dacd1f3672b945eea600be431100220077ee9eae3528d15251f2a52b607b189820e57a6ccfac8d1af502b132ee4016901475221023da092f6980e58d2c037173180e9a465476026ee50f96695963e8efe436f54eb21030e9f7b623d2ccc7c9bd44d66d5ce21ce504c0acf6385a132cec6d3c39fa711c152ae3e195220
num_htlcs: 2
Clarify Bolt 3 htlc tx output test vectors (#852) It was sometimes unclear where we indexed by the output or the htlc id. This is a follow-up from discussions made in #539.
2021-06-21 22:01:47 +02:00
# signature for output #0 (htlc-timeout for htlc #3)
BOLT 3: add test vectors for htlc-transactions in case where CLTV is used as tie-breaker for sorting (#539) Add a serialized transactions test vector for the edge case of sorting htlc-timeout-tx when there are multiple offered htlc with the same amount and preimage. The test vector reuses previous preimages and creates a case scenario with 1 received htlc and 2 offered, the two offered will have same scriptPubKey and redeemScript, but different CLTV value. It is asserted the order in which the htlc transactions should be kept internally and we assume the same order is used to construct the commitment_signed message. This complements #491 .
2021-03-05 09:10:26 +01:00
remote_htlc_signature = 304402206fa54c11f98c3bae1e93df43fc7affeb05b476bf8060c03e29c377c69bc08e8b0220672701cce50d5c379ff45a5d2cfe48ac44973adb066ac32608e21221d869bb89
Clarify Bolt 3 htlc tx output test vectors (#852) It was sometimes unclear where we indexed by the output or the htlc id. This is a follow-up from discussions made in #539.
2021-06-21 22:01:47 +02:00
# local_htlc_signature = 304402206e36c683ebf2cb16bcef3d5439cf8b53cd97280a365ed8acd7abb85a8ba5f21c02206e8621edfc2a5766cbc96eb67fd501127ff163eb6b85518a39f7d4974aef126f
htlc_timeout_tx (htlc #3): 020000000001018db483bff65c70ee71d8282aeec5a880e2e2b39e45772bda5460403095c62e3f0000000000000000000122020000000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e050047304402206fa54c11f98c3bae1e93df43fc7affeb05b476bf8060c03e29c377c69bc08e8b0220672701cce50d5c379ff45a5d2cfe48ac44973adb066ac32608e21221d869bb890147304402206e36c683ebf2cb16bcef3d5439cf8b53cd97280a365ed8acd7abb85a8ba5f21c02206e8621edfc2a5766cbc96eb67fd501127ff163eb6b85518a39f7d4974aef126f01008576a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c820120876475527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae67a9148a486ff2e31d6158bf39e2608864d63fefd09d5b88ac6868f7010000
# signature for output #1 (htlc-success for htlc #4)
BOLT 3: add test vectors for htlc-transactions in case where CLTV is used as tie-breaker for sorting (#539) Add a serialized transactions test vector for the edge case of sorting htlc-timeout-tx when there are multiple offered htlc with the same amount and preimage. The test vector reuses previous preimages and creates a case scenario with 1 received htlc and 2 offered, the two offered will have same scriptPubKey and redeemScript, but different CLTV value. It is asserted the order in which the htlc transactions should be kept internally and we assume the same order is used to construct the commitment_signed message. This complements #491 .
2021-03-05 09:10:26 +01:00
remote_htlc_signature = 3044022057649739b0eb74d541ead0dfdb3d4b2c15aa192720031044c3434c67812e5ca902201e5ede42d960ae551707f4a6b34b09393cf4dee2418507daa022e3550dbb5817
Clarify Bolt 3 htlc tx output test vectors (#852) It was sometimes unclear where we indexed by the output or the htlc id. This is a follow-up from discussions made in #539.
2021-06-21 22:01:47 +02:00
# local_htlc_signature = 304402207faad26678c8850e01b4a0696d60841f7305e1832b786110ee9075cb92ed14a30220516ef8ee5dfa80824ea28cbcec0dd95f8b847146257c16960db98507db15ffdc
htlc_success_tx (htlc #4): 020000000001018db483bff65c70ee71d8282aeec5a880e2e2b39e45772bda5460403095c62e3f0100000000000000000176050000000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e0500473044022057649739b0eb74d541ead0dfdb3d4b2c15aa192720031044c3434c67812e5ca902201e5ede42d960ae551707f4a6b34b09393cf4dee2418507daa022e3550dbb58170147304402207faad26678c8850e01b4a0696d60841f7305e1832b786110ee9075cb92ed14a30220516ef8ee5dfa80824ea28cbcec0dd95f8b847146257c16960db98507db15ffdc012004040404040404040404040404040404040404040404040404040404040404048a76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c8201208763a91418bc1a114ccf9c052d3d23e28d3b0a9d1227434288527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae677502f801b175ac686800000000
BOLT 3: add test vectors for htlc-transactions in case where CLTV is used as tie-breaker for sorting (#539) Add a serialized transactions test vector for the edge case of sorting htlc-timeout-tx when there are multiple offered htlc with the same amount and preimage. The test vector reuses previous preimages and creates a case scenario with 1 received htlc and 2 offered, the two offered will have same scriptPubKey and redeemScript, but different CLTV value. It is asserted the order in which the htlc transactions should be kept internally and we assume the same order is used to construct the commitment_signed message. This complements #491 .
2021-03-05 09:10:26 +01:00
name: commitment tx with three outputs untrimmed (minimum feerate)
to_local_msat: 6988000000
to_remote_msat: 3000000000
local_feerate_per_kw: 3703
# base commitment transaction fee = 3317
# actual commitment transaction fee = 11317
Clarify Bolt 3 htlc tx output test vectors (#852) It was sometimes unclear where we indexed by the output or the htlc id. This is a follow-up from discussions made in #539.
2021-06-21 22:01:47 +02:00
# HTLC #4 received amount 4000 wscript 76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c8201208763a91418bc1a114ccf9c052d3d23e28d3b0a9d1227434288527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae677502f801b175ac6868
BOLT 3: add test vectors for htlc-transactions in case where CLTV is used as tie-breaker for sorting (#539) Add a serialized transactions test vector for the edge case of sorting htlc-timeout-tx when there are multiple offered htlc with the same amount and preimage. The test vector reuses previous preimages and creates a case scenario with 1 received htlc and 2 offered, the two offered will have same scriptPubKey and redeemScript, but different CLTV value. It is asserted the order in which the htlc transactions should be kept internally and we assume the same order is used to construct the commitment_signed message. This complements #491 .
2021-03-05 09:10:26 +01:00
# to_local amount 6984683 wscript 63210212a140cd0c6539d07cd08dfe09984dec3251ea808b892efeac3ede9402bf2b1967029000b2752103fd5960528dc152014952efdb702a88f71e3c1653b2314431701ec77e57fde83c68ac
# to_remote amount 3000000 P2WPKH(032c0b7cf95324a07d05398b240174dc0c2be444d96b159aa6c7f7b1e668680991)
remote_signature = 3045022100b495d239772a237ff2cf354b1b11be152fd852704cb184e7356d13f2fb1e5e430220723db5cdb9cbd6ead7bfd3deb419cf41053a932418cbb22a67b581f40bc1f13e
# local_signature = 304402201b736d1773a124c745586217a75bed5f66c05716fbe8c7db4fdb3c3069741cdd02205083f39c321c1bcadfc8d97e3c791a66273d936abac0c6a2fde2ed46019508e1
output commit_tx: 02000000000101bef67e4e2fb9ddeeb3461973cd4c62abb35050b1add772995b820b584a488489000000000038b02b8003a00f0000000000002200208c48d15160397c9731df9bc3b236656efb6665fbfe92b4a6878e88a499f741c4c0c62d0000000000160014cc1b07838e387deacd0e5232e1e8b49f4c29e484eb936a00000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e040047304402201b736d1773a124c745586217a75bed5f66c05716fbe8c7db4fdb3c3069741cdd02205083f39c321c1bcadfc8d97e3c791a66273d936abac0c6a2fde2ed46019508e101483045022100b495d239772a237ff2cf354b1b11be152fd852704cb184e7356d13f2fb1e5e430220723db5cdb9cbd6ead7bfd3deb419cf41053a932418cbb22a67b581f40bc1f13e01475221023da092f6980e58d2c037173180e9a465476026ee50f96695963e8efe436f54eb21030e9f7b623d2ccc7c9bd44d66d5ce21ce504c0acf6385a132cec6d3c39fa711c152ae3e195220
num_htlcs: 1
Clarify Bolt 3 htlc tx output test vectors (#852) It was sometimes unclear where we indexed by the output or the htlc id. This is a follow-up from discussions made in #539.
2021-06-21 22:01:47 +02:00
# signature for output #0 (htlc-success for htlc #4)
BOLT 3: add test vectors for htlc-transactions in case where CLTV is used as tie-breaker for sorting (#539) Add a serialized transactions test vector for the edge case of sorting htlc-timeout-tx when there are multiple offered htlc with the same amount and preimage. The test vector reuses previous preimages and creates a case scenario with 1 received htlc and 2 offered, the two offered will have same scriptPubKey and redeemScript, but different CLTV value. It is asserted the order in which the htlc transactions should be kept internally and we assume the same order is used to construct the commitment_signed message. This complements #491 .
2021-03-05 09:10:26 +01:00
remote_htlc_signature = 3045022100c34c61735f93f2e324cc873c3b248111ccf8f6db15d5969583757010d4ad2b4602207867bb919b2ddd6387873e425345c9b7fd18d1d66aba41f3607bc2896ef3c30a
Clarify Bolt 3 htlc tx output test vectors (#852) It was sometimes unclear where we indexed by the output or the htlc id. This is a follow-up from discussions made in #539.
2021-06-21 22:01:47 +02:00
# local_htlc_signature = 3045022100988c143e2110067117d2321bdd4bd16ca1734c98b29290d129384af0962b634e02206c1b02478878c5f547018b833986578f90c3e9be669fe5788ad0072a55acbb05
htlc_success_tx (htlc #4): 0200000000010120060e4a29579d429f0f27c17ee5f1ee282f20d706d6f90b63d35946d8f3029a0000000000000000000175050000000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e0500483045022100c34c61735f93f2e324cc873c3b248111ccf8f6db15d5969583757010d4ad2b4602207867bb919b2ddd6387873e425345c9b7fd18d1d66aba41f3607bc2896ef3c30a01483045022100988c143e2110067117d2321bdd4bd16ca1734c98b29290d129384af0962b634e02206c1b02478878c5f547018b833986578f90c3e9be669fe5788ad0072a55acbb05012004040404040404040404040404040404040404040404040404040404040404048a76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c8201208763a91418bc1a114ccf9c052d3d23e28d3b0a9d1227434288527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae677502f801b175ac686800000000
BOLT 3: add test vectors for htlc-transactions in case where CLTV is used as tie-breaker for sorting (#539) Add a serialized transactions test vector for the edge case of sorting htlc-timeout-tx when there are multiple offered htlc with the same amount and preimage. The test vector reuses previous preimages and creates a case scenario with 1 received htlc and 2 offered, the two offered will have same scriptPubKey and redeemScript, but different CLTV value. It is asserted the order in which the htlc transactions should be kept internally and we assume the same order is used to construct the commitment_signed message. This complements #491 .
2021-03-05 09:10:26 +01:00
name: commitment tx with three outputs untrimmed (maximum feerate)
to_local_msat: 6988000000
to_remote_msat: 3000000000
local_feerate_per_kw: 4914
# base commitment transaction fee = 4402
# actual commitment transaction fee = 12402
Clarify Bolt 3 htlc tx output test vectors (#852) It was sometimes unclear where we indexed by the output or the htlc id. This is a follow-up from discussions made in #539.
2021-06-21 22:01:47 +02:00
# HTLC #4 received amount 4000 wscript 76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c8201208763a91418bc1a114ccf9c052d3d23e28d3b0a9d1227434288527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae677502f801b175ac6868
BOLT 3: add test vectors for htlc-transactions in case where CLTV is used as tie-breaker for sorting (#539) Add a serialized transactions test vector for the edge case of sorting htlc-timeout-tx when there are multiple offered htlc with the same amount and preimage. The test vector reuses previous preimages and creates a case scenario with 1 received htlc and 2 offered, the two offered will have same scriptPubKey and redeemScript, but different CLTV value. It is asserted the order in which the htlc transactions should be kept internally and we assume the same order is used to construct the commitment_signed message. This complements #491 .
2021-03-05 09:10:26 +01:00
# to_local amount 6983598 wscript 63210212a140cd0c6539d07cd08dfe09984dec3251ea808b892efeac3ede9402bf2b1967029000b2752103fd5960528dc152014952efdb702a88f71e3c1653b2314431701ec77e57fde83c68ac
# to_remote amount 3000000 P2WPKH(032c0b7cf95324a07d05398b240174dc0c2be444d96b159aa6c7f7b1e668680991)
remote_signature = 3045022100b4b16d5f8cc9fc4c1aff48831e832a0d8990e133978a66e302c133550954a44d022073573ce127e2200d316f6b612803a5c0c97b8d20e1e44dbe2ac0dd2fb8c95244
# local_signature = 3045022100d72638bc6308b88bb6d45861aae83e5b9ff6e10986546e13bce769c70036e2620220320be7c6d66d22f30b9fcd52af66531505b1310ca3b848c19285b38d8a1a8c19
output commit_tx: 02000000000101bef67e4e2fb9ddeeb3461973cd4c62abb35050b1add772995b820b584a488489000000000038b02b8003a00f0000000000002200208c48d15160397c9731df9bc3b236656efb6665fbfe92b4a6878e88a499f741c4c0c62d0000000000160014cc1b07838e387deacd0e5232e1e8b49f4c29e484ae8f6a00000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e0400483045022100d72638bc6308b88bb6d45861aae83e5b9ff6e10986546e13bce769c70036e2620220320be7c6d66d22f30b9fcd52af66531505b1310ca3b848c19285b38d8a1a8c1901483045022100b4b16d5f8cc9fc4c1aff48831e832a0d8990e133978a66e302c133550954a44d022073573ce127e2200d316f6b612803a5c0c97b8d20e1e44dbe2ac0dd2fb8c9524401475221023da092f6980e58d2c037173180e9a465476026ee50f96695963e8efe436f54eb21030e9f7b623d2ccc7c9bd44d66d5ce21ce504c0acf6385a132cec6d3c39fa711c152ae3e195220
num_htlcs: 1
Clarify Bolt 3 htlc tx output test vectors (#852) It was sometimes unclear where we indexed by the output or the htlc id. This is a follow-up from discussions made in #539.
2021-06-21 22:01:47 +02:00
# signature for output #0 (htlc-success for htlc #4)
BOLT 3: add test vectors for htlc-transactions in case where CLTV is used as tie-breaker for sorting (#539) Add a serialized transactions test vector for the edge case of sorting htlc-timeout-tx when there are multiple offered htlc with the same amount and preimage. The test vector reuses previous preimages and creates a case scenario with 1 received htlc and 2 offered, the two offered will have same scriptPubKey and redeemScript, but different CLTV value. It is asserted the order in which the htlc transactions should be kept internally and we assume the same order is used to construct the commitment_signed message. This complements #491 .
2021-03-05 09:10:26 +01:00
remote_htlc_signature = 3045022100f43591c156038ba217756006bb3c55f7d113a325cdd7d9303c82115372858d68022016355b5aadf222bc8d12e426c75f4a03423917b2443a103eb2a498a3a2234374
Clarify Bolt 3 htlc tx output test vectors (#852) It was sometimes unclear where we indexed by the output or the htlc id. This is a follow-up from discussions made in #539.
2021-06-21 22:01:47 +02:00
# local_htlc_signature = 30440220585dee80fafa264beac535c3c0bb5838ac348b156fdc982f86adc08dfc9bfd250220130abb82f9f295cc9ef423dcfef772fde2acd85d9df48cc538981d26a10a9c10
htlc_success_tx (htlc #4): 02000000000101a9172908eace869cc35128c31fc2ab502f72e4dff31aab23e0244c4b04b11ab00000000000000000000122020000000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e0500483045022100f43591c156038ba217756006bb3c55f7d113a325cdd7d9303c82115372858d68022016355b5aadf222bc8d12e426c75f4a03423917b2443a103eb2a498a3a2234374014730440220585dee80fafa264beac535c3c0bb5838ac348b156fdc982f86adc08dfc9bfd250220130abb82f9f295cc9ef423dcfef772fde2acd85d9df48cc538981d26a10a9c10012004040404040404040404040404040404040404040404040404040404040404048a76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c8201208763a91418bc1a114ccf9c052d3d23e28d3b0a9d1227434288527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae677502f801b175ac686800000000
BOLT 3: add test vectors for htlc-transactions in case where CLTV is used as tie-breaker for sorting (#539) Add a serialized transactions test vector for the edge case of sorting htlc-timeout-tx when there are multiple offered htlc with the same amount and preimage. The test vector reuses previous preimages and creates a case scenario with 1 received htlc and 2 offered, the two offered will have same scriptPubKey and redeemScript, but different CLTV value. It is asserted the order in which the htlc transactions should be kept internally and we assume the same order is used to construct the commitment_signed message. This complements #491 .
2021-03-05 09:10:26 +01:00
name: commitment tx with two outputs untrimmed (minimum feerate)
to_local_msat: 6988000000
to_remote_msat: 3000000000
local_feerate_per_kw: 4915
# base commitment transaction fee = 3558
# actual commitment transaction fee = 15558
# to_local amount 6984442 wscript 63210212a140cd0c6539d07cd08dfe09984dec3251ea808b892efeac3ede9402bf2b1967029000b2752103fd5960528dc152014952efdb702a88f71e3c1653b2314431701ec77e57fde83c68ac
# to_remote amount 3000000 P2WPKH(032c0b7cf95324a07d05398b240174dc0c2be444d96b159aa6c7f7b1e668680991)
remote_signature = 304402203a286936e74870ca1459c700c71202af0381910a6bfab687ef494ef1bc3e02c902202506c362d0e3bee15e802aa729bf378e051644648253513f1c085b264cc2a720
# local_signature = 30450221008a953551f4d67cb4df3037207fc082ddaf6be84d417b0bd14c80aab66f1b01a402207508796dc75034b2dee876fe01dc05a08b019f3e5d689ac8842ade2f1befccf5
output commit_tx: 02000000000101bef67e4e2fb9ddeeb3461973cd4c62abb35050b1add772995b820b584a488489000000000038b02b8002c0c62d0000000000160014cc1b07838e387deacd0e5232e1e8b49f4c29e484fa926a00000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e04004830450221008a953551f4d67cb4df3037207fc082ddaf6be84d417b0bd14c80aab66f1b01a402207508796dc75034b2dee876fe01dc05a08b019f3e5d689ac8842ade2f1befccf50147304402203a286936e74870ca1459c700c71202af0381910a6bfab687ef494ef1bc3e02c902202506c362d0e3bee15e802aa729bf378e051644648253513f1c085b264cc2a72001475221023da092f6980e58d2c037173180e9a465476026ee50f96695963e8efe436f54eb21030e9f7b623d2ccc7c9bd44d66d5ce21ce504c0acf6385a132cec6d3c39fa711c152ae3e195220
num_htlcs: 0
name: commitment tx with two outputs untrimmed (maximum feerate)
to_local_msat: 6988000000
to_remote_msat: 3000000000
local_feerate_per_kw: 9651180
# base commitment transaction fee = 6987454
# actual commitment transaction fee = 6999454
# to_local amount 546 wscript 63210212a140cd0c6539d07cd08dfe09984dec3251ea808b892efeac3ede9402bf2b1967029000b2752103fd5960528dc152014952efdb702a88f71e3c1653b2314431701ec77e57fde83c68ac
# to_remote amount 3000000 P2WPKH(032c0b7cf95324a07d05398b240174dc0c2be444d96b159aa6c7f7b1e668680991)
remote_signature = 304402200a8544eba1d216f5c5e530597665fa9bec56943c0f66d98fc3d028df52d84f7002201e45fa5c6bc3a506cc2553e7d1c0043a9811313fc39c954692c0d47cfce2bbd3
# local_signature = 3045022100e11b638c05c650c2f63a421d36ef8756c5ce82f2184278643520311cdf50aa200220259565fb9c8e4a87ccaf17f27a3b9ca4f20625754a0920d9c6c239d8156a11de
output commit_tx: 02000000000101bef67e4e2fb9ddeeb3461973cd4c62abb35050b1add772995b820b584a488489000000000038b02b800222020000000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80ec0c62d0000000000160014cc1b07838e387deacd0e5232e1e8b49f4c29e4840400483045022100e11b638c05c650c2f63a421d36ef8756c5ce82f2184278643520311cdf50aa200220259565fb9c8e4a87ccaf17f27a3b9ca4f20625754a0920d9c6c239d8156a11de0147304402200a8544eba1d216f5c5e530597665fa9bec56943c0f66d98fc3d028df52d84f7002201e45fa5c6bc3a506cc2553e7d1c0043a9811313fc39c954692c0d47cfce2bbd301475221023da092f6980e58d2c037173180e9a465476026ee50f96695963e8efe436f54eb21030e9f7b623d2ccc7c9bd44d66d5ce21ce504c0acf6385a132cec6d3c39fa711c152ae3e195220
num_htlcs: 0
name: commitment tx with one output untrimmed (minimum feerate)
to_local_msat: 6988000000
to_remote_msat: 3000000000
local_feerate_per_kw: 9651181
# base commitment transaction fee = 6987455
# actual commitment transaction fee = 7000000
# to_remote amount 3000000 P2WPKH(032c0b7cf95324a07d05398b240174dc0c2be444d96b159aa6c7f7b1e668680991)
remote_signature = 304402202ade0142008309eb376736575ad58d03e5b115499709c6db0b46e36ff394b492022037b63d78d66404d6504d4c4ac13be346f3d1802928a6d3ad95a6a944227161a2
# local_signature = 304402207e8d51e0c570a5868a78414f4e0cbfaed1106b171b9581542c30718ee4eb95ba02203af84194c97adf98898c9afe2f2ed4a7f8dba05a2dfab28ac9d9c604aa49a379
output commit_tx: 02000000000101bef67e4e2fb9ddeeb3461973cd4c62abb35050b1add772995b820b584a488489000000000038b02b8001c0c62d0000000000160014cc1b07838e387deacd0e5232e1e8b49f4c29e484040047304402207e8d51e0c570a5868a78414f4e0cbfaed1106b171b9581542c30718ee4eb95ba02203af84194c97adf98898c9afe2f2ed4a7f8dba05a2dfab28ac9d9c604aa49a3790147304402202ade0142008309eb376736575ad58d03e5b115499709c6db0b46e36ff394b492022037b63d78d66404d6504d4c4ac13be346f3d1802928a6d3ad95a6a944227161a201475221023da092f6980e58d2c037173180e9a465476026ee50f96695963e8efe436f54eb21030e9f7b623d2ccc7c9bd44d66d5ce21ce504c0acf6385a132cec6d3c39fa711c152ae3e195220
num_htlcs: 0
name: commitment tx with fee greater than funder amount
to_local_msat: 6988000000
to_remote_msat: 3000000000
local_feerate_per_kw: 9651936
# base commitment transaction fee = 6988001
# actual commitment transaction fee = 7000000
# to_remote amount 3000000 P2WPKH(032c0b7cf95324a07d05398b240174dc0c2be444d96b159aa6c7f7b1e668680991)
remote_signature = 304402202ade0142008309eb376736575ad58d03e5b115499709c6db0b46e36ff394b492022037b63d78d66404d6504d4c4ac13be346f3d1802928a6d3ad95a6a944227161a2
# local_signature = 304402207e8d51e0c570a5868a78414f4e0cbfaed1106b171b9581542c30718ee4eb95ba02203af84194c97adf98898c9afe2f2ed4a7f8dba05a2dfab28ac9d9c604aa49a379
output commit_tx: 02000000000101bef67e4e2fb9ddeeb3461973cd4c62abb35050b1add772995b820b584a488489000000000038b02b8001c0c62d0000000000160014cc1b07838e387deacd0e5232e1e8b49f4c29e484040047304402207e8d51e0c570a5868a78414f4e0cbfaed1106b171b9581542c30718ee4eb95ba02203af84194c97adf98898c9afe2f2ed4a7f8dba05a2dfab28ac9d9c604aa49a3790147304402202ade0142008309eb376736575ad58d03e5b115499709c6db0b46e36ff394b492022037b63d78d66404d6504d4c4ac13be346f3d1802928a6d3ad95a6a944227161a201475221023da092f6980e58d2c037173180e9a465476026ee50f96695963e8efe436f54eb21030e9f7b623d2ccc7c9bd44d66d5ce21ce504c0acf6385a132cec6d3c39fa711c152ae3e195220
num_htlcs: 0
name: commitment tx with 3 htlc outputs, 2 offered having the same amount and preimage
to_local_msat: 6988000000
to_remote_msat: 3000000000
local_feerate_per_kw: 253
Clarify Bolt 3 htlc tx output test vectors (#852) It was sometimes unclear where we indexed by the output or the htlc id. This is a follow-up from discussions made in #539.
2021-06-21 22:01:47 +02:00
# HTLC #1 received amount 2000 wscript 76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c8201208763a9144b6b2e5444c2639cc0fb7bcea5afba3f3cdce23988527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae677502f501b175ac6868
# HTLC #5 offered amount 5000 wscript 76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c820120876475527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae67a9142002cc93ebefbb1b73f0af055dcc27a0b504ad7688ac6868
# HTLC #6 offered amount 5000 wscript 76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c820120876475527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae67a9142002cc93ebefbb1b73f0af055dcc27a0b504ad7688ac6868
# HTLC #5 and 6 have CLTV 506 and 505, respectively, and preimage 0505050505050505050505050505050505050505050505050505050505050505
BOLT 3: add test vectors for htlc-transactions in case where CLTV is used as tie-breaker for sorting (#539) Add a serialized transactions test vector for the edge case of sorting htlc-timeout-tx when there are multiple offered htlc with the same amount and preimage. The test vector reuses previous preimages and creates a case scenario with 1 received htlc and 2 offered, the two offered will have same scriptPubKey and redeemScript, but different CLTV value. It is asserted the order in which the htlc transactions should be kept internally and we assume the same order is used to construct the commitment_signed message. This complements #491 .
2021-03-05 09:10:26 +01:00
remote_signature = 30440220048705bec5288d28b3f29344b8d124853b1af423a568664d2c6f02c8ea886525022060f998a461052a2476b912db426ea2a06700953a241135c7957f2e79bc222df9
# local_signature = 3045022100c4f1d60b6fca9febc8b39de1a31e84c5f7c4b41c97239ef05f4350aa484c6b5e02200c5134ac8b20eb7a29d0dd4a501f6aa8fefb8489171f4cb408bd2a32324ab03f
output commit_tx: 02000000000101bef67e4e2fb9ddeeb3461973cd4c62abb35050b1add772995b820b584a488489000000000038b02b8005d007000000000000220020748eba944fedc8827f6b06bc44678f93c0f9e6078b35c6331ed31e75f8ce0c2d8813000000000000220020305c12e1a0bc21e283c131cea1c66d68857d28b7b2fce0a6fbc40c164852121b8813000000000000220020305c12e1a0bc21e283c131cea1c66d68857d28b7b2fce0a6fbc40c164852121bc0c62d0000000000160014cc1b07838e387deacd0e5232e1e8b49f4c29e484a79f6a00000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e0400483045022100c4f1d60b6fca9febc8b39de1a31e84c5f7c4b41c97239ef05f4350aa484c6b5e02200c5134ac8b20eb7a29d0dd4a501f6aa8fefb8489171f4cb408bd2a32324ab03f014730440220048705bec5288d28b3f29344b8d124853b1af423a568664d2c6f02c8ea886525022060f998a461052a2476b912db426ea2a06700953a241135c7957f2e79bc222df901475221023da092f6980e58d2c037173180e9a465476026ee50f96695963e8efe436f54eb21030e9f7b623d2ccc7c9bd44d66d5ce21ce504c0acf6385a132cec6d3c39fa711c152ae3e195220
num_htlcs: 3
Clarify Bolt 3 htlc tx output test vectors (#852) It was sometimes unclear where we indexed by the output or the htlc id. This is a follow-up from discussions made in #539.
2021-06-21 22:01:47 +02:00
# signature for output #0 (htlc-success for htlc #1)
BOLT 3: add test vectors for htlc-transactions in case where CLTV is used as tie-breaker for sorting (#539) Add a serialized transactions test vector for the edge case of sorting htlc-timeout-tx when there are multiple offered htlc with the same amount and preimage. The test vector reuses previous preimages and creates a case scenario with 1 received htlc and 2 offered, the two offered will have same scriptPubKey and redeemScript, but different CLTV value. It is asserted the order in which the htlc transactions should be kept internally and we assume the same order is used to construct the commitment_signed message. This complements #491 .
2021-03-05 09:10:26 +01:00
remote_htlc_signature = 304502210081cbb94121761d34c189cd4e6a281feea6f585060ad0ba2632e8d6b3c6bb8a6c02201007981bbd16539d63df2805b5568f1f5688cd2a885d04706f50db9b77ba13c6
# local_htlc_signature = 304502210090ed76aeb21b53236a598968abc66e2024691d07b62f53ddbeca8f93144af9c602205f873af5a0c10e62690e9aba09740550f194a9dc455ba4c1c23f6cde7704674c
Clarify Bolt 3 htlc tx output test vectors (#852) It was sometimes unclear where we indexed by the output or the htlc id. This is a follow-up from discussions made in #539.
2021-06-21 22:01:47 +02:00
htlc_success_tx (htlc #1): 0200000000010189a326e23addc28323dbadcb4e71c2c17088b6e8fa184103e552f44075dddc34000000000000000000011f070000000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e050048304502210081cbb94121761d34c189cd4e6a281feea6f585060ad0ba2632e8d6b3c6bb8a6c02201007981bbd16539d63df2805b5568f1f5688cd2a885d04706f50db9b77ba13c60148304502210090ed76aeb21b53236a598968abc66e2024691d07b62f53ddbeca8f93144af9c602205f873af5a0c10e62690e9aba09740550f194a9dc455ba4c1c23f6cde7704674c012001010101010101010101010101010101010101010101010101010101010101018a76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c8201208763a9144b6b2e5444c2639cc0fb7bcea5afba3f3cdce23988527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae677502f501b175ac686800000000
# signature for output #1 (htlc-timeout for htlc #5)
remote_htlc_signature = 304402201d0f09d2bf7bc245a4f17980e1e9164290df16c70c6a2ff1592f5030d6108581022061e744a7dc151b36bf0aff7a4f1812ba90b8b03633bb979a270d19858fd960c5
BOLT 3: add test vectors for htlc-transactions in case where CLTV is used as tie-breaker for sorting (#539) Add a serialized transactions test vector for the edge case of sorting htlc-timeout-tx when there are multiple offered htlc with the same amount and preimage. The test vector reuses previous preimages and creates a case scenario with 1 received htlc and 2 offered, the two offered will have same scriptPubKey and redeemScript, but different CLTV value. It is asserted the order in which the htlc transactions should be kept internally and we assume the same order is used to construct the commitment_signed message. This complements #491 .
2021-03-05 09:10:26 +01:00
# local_htlc_signature = 30450221009aef000d2e843a4202c1b1a2bf554abc9a7902bf49b2cb0759bc507456b7ebad02204e7c3d193ede2fd2b4cd6b39f51a920e581e35575e357e44d7b699c40ce61d39
Clarify Bolt 3 htlc tx output test vectors (#852) It was sometimes unclear where we indexed by the output or the htlc id. This is a follow-up from discussions made in #539.
2021-06-21 22:01:47 +02:00
htlc_timeout_tx (htlc #5): 0200000000010189a326e23addc28323dbadcb4e71c2c17088b6e8fa184103e552f44075dddc3401000000000000000001e1120000000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e050047304402201d0f09d2bf7bc245a4f17980e1e9164290df16c70c6a2ff1592f5030d6108581022061e744a7dc151b36bf0aff7a4f1812ba90b8b03633bb979a270d19858fd960c5014830450221009aef000d2e843a4202c1b1a2bf554abc9a7902bf49b2cb0759bc507456b7ebad02204e7c3d193ede2fd2b4cd6b39f51a920e581e35575e357e44d7b699c40ce61d3901008576a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c820120876475527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae67a9142002cc93ebefbb1b73f0af055dcc27a0b504ad7688ac6868f9010000
# signature for output #2 (htlc-timeout for htlc #6)
remote_htlc_signature = 30440220010bf035d5823596e50dce2076a4d9f942d8d28031c9c428b901a02b6b8140de02203250e8e4a08bc5b4ecdca4d0eedf98223e02e3ac1c0206b3a7ffdb374aa21e5f
BOLT 3: add test vectors for htlc-transactions in case where CLTV is used as tie-breaker for sorting (#539) Add a serialized transactions test vector for the edge case of sorting htlc-timeout-tx when there are multiple offered htlc with the same amount and preimage. The test vector reuses previous preimages and creates a case scenario with 1 received htlc and 2 offered, the two offered will have same scriptPubKey and redeemScript, but different CLTV value. It is asserted the order in which the htlc transactions should be kept internally and we assume the same order is used to construct the commitment_signed message. This complements #491 .
2021-03-05 09:10:26 +01:00
# local_htlc_signature = 30440220073de0067b88e425b3018b30366bfeda0ccb703118ccd3d02ead08c0f53511d002203fac50ac0e4cf8a3af0b4b1b12e801650591f748f8ddf1e089c160f10b69e511
Clarify Bolt 3 htlc tx output test vectors (#852) It was sometimes unclear where we indexed by the output or the htlc id. This is a follow-up from discussions made in #539.
2021-06-21 22:01:47 +02:00
htlc_timeout_tx (htlc #6): 0200000000010189a326e23addc28323dbadcb4e71c2c17088b6e8fa184103e552f44075dddc3402000000000000000001e1120000000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e05004730440220010bf035d5823596e50dce2076a4d9f942d8d28031c9c428b901a02b6b8140de02203250e8e4a08bc5b4ecdca4d0eedf98223e02e3ac1c0206b3a7ffdb374aa21e5f014730440220073de0067b88e425b3018b30366bfeda0ccb703118ccd3d02ead08c0f53511d002203fac50ac0e4cf8a3af0b4b1b12e801650591f748f8ddf1e089c160f10b69e51101008576a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c820120876475527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae67a9142002cc93ebefbb1b73f0af055dcc27a0b504ad7688ac6868fa010000
BOLT 3: add test vectors for htlc-transactions in case where CLTV is used as tie-breaker for sorting (#539) Add a serialized transactions test vector for the edge case of sorting htlc-timeout-tx when there are multiple offered htlc with the same amount and preimage. The test vector reuses previous preimages and creates a case scenario with 1 received htlc and 2 offered, the two offered will have same scriptPubKey and redeemScript, but different CLTV value. It is asserted the order in which the htlc transactions should be kept internally and we assume the same order is used to construct the commitment_signed message. This complements #491 .
2021-03-05 09:10:26 +01:00
bolt3 fix and enhance tx testvectors (#99) This is a smerge of Fabrice Drouin and my work: he update them, I updated them and enhanced them, he found bugs, I re-derived them, etc. - rename keys properly - fix fees - sign all transactions - Derive test transaction vectors from minimal subset of parameters. - rewrite test vectors to test edge cases for trimming. - add funding tx test vector, make testable on regtest. This adds a funding transaction test (really, we only specify the output), but importantly adds enough information to duplicate a blockchain with that particular funding tx: $ rm -rf ~/.bitcoin/regtest/ $ bitcoind -regtest=1 & $ bitcoin-cli -regtest=1 submitblock 0000002006226e46111a0b59caaf126043eb5bbf28c34f3a5e332a1fc7b2b73cf188910fadbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fdc30f9858ffff7f20000000000101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff03510101ffffffff0100f2052a010000001976a9143ca33c2e4446f4a305f23c80df8ad1afdcf652f988ac00000000 $ bitcoin-cli -regtest=1 generate 431 $ bitcoin-cli -regtest=1 sendrawtransaction 0200000001adbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fd000000006b48304502210090587b6201e166ad6af0227d3036a9454223d49a1f11839c1a362184340ef0240220577f7cd5cca78719405cbf1de7414ac027f0239ef6e214c90fcaab0454d84b3b012103535b32d5eb0a6ed0982a0479bbadc9868d9836f6ba94dd5a63be16d875069184ffffffff028096980000000000220020c015c4a6be010e21657068fc2e6a9d02b27ebe4d490a25846f7237f104d1a3cd20256d29010000001600143ca33c2e4446f4a305f23c80df8ad1afdcf652f900000000 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-02-07 01:45:33 +01:00
# Appendix D: Per-commitment Secret Generation Test Vectors
BOLT 3: Add test vectors for per-commitment-secret generation These were generated (and recovery tested) by the command-line tool at: https://github.com/rustyrussell/ccan/tree/master/ccan/crypto/shachain/tools Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-12-02 02:16:04 +01:00
BOLT-3 Edits This is my final first-pass BOLT. Some grammar changes, some remote/local additions, a few questions.
2018-01-16 20:52:38 +01:00
These test the generation algorithm that all nodes use.
BOLT 3: Add test vectors for per-commitment-secret generation These were generated (and recovery tested) by the command-line tool at: https://github.com/rustyrussell/ccan/tree/master/ccan/crypto/shachain/tools Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-12-02 02:16:04 +01:00
BOLT 1,2,3: first pass copy-edit; BOLT 1,2: minor header spacing fixes BOLT 3: first pass copy edit, according to capitalization, formatting stylesheet guidelines;
2017-11-18 22:04:58 +01:00
## Generation Tests
BOLT 3: Add test vectors for per-commitment-secret generation These were generated (and recovery tested) by the command-line tool at: https://github.com/rustyrussell/ccan/tree/master/ccan/crypto/shachain/tools Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-12-02 02:16:04 +01:00
name: generate_from_seed 0 final node
seed: 0x0000000000000000000000000000000000000000000000000000000000000000
I: 281474976710655
output: 0x02a40c85b6f28da08dfdbe0926c53fab2de6d28c10301f8f7c4073d5e42e3148
name: generate_from_seed FF final node
seed: 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
I: 281474976710655
output: 0x7cc854b54e3e0dcdb010d7a3fee464a9687be6e8db3be6854c475621e007a5dc
name: generate_from_seed FF alternate bits 1
seed: 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
I: 0xaaaaaaaaaaa
output: 0x56f4008fb007ca9acf0e15b054d5c9fd12ee06cea347914ddbaed70d1c13a528
name: generate_from_seed FF alternate bits 2
seed: 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
I: 0x555555555555
output: 0x9015daaeb06dba4ccc05b91b2f73bd54405f2be9f217fbacd3c5ac2e62327d31
name: generate_from_seed 01 last nontrivial node
seed: 0x0101010101010101010101010101010101010101010101010101010101010101
I: 1
output: 0x915c75942a26bb3a433a8ce2cb0427c29ec6c1775cfc78328b57f6ba7bfeaa9c
BOLT 1,2,3: first pass copy-edit; BOLT 1,2: minor header spacing fixes BOLT 3: first pass copy edit, according to capitalization, formatting stylesheet guidelines;
2017-11-18 22:04:58 +01:00
## Storage Tests
BOLT 3: Add test vectors for per-commitment-secret generation These were generated (and recovery tested) by the command-line tool at: https://github.com/rustyrussell/ccan/tree/master/ccan/crypto/shachain/tools Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-12-02 02:16:04 +01:00
BOLT 1,2,3: first pass copy-edit; BOLT 1,2: minor header spacing fixes BOLT 3: first pass copy edit, according to capitalization, formatting stylesheet guidelines;
2017-11-18 22:04:58 +01:00
These test the optional compact storage system. In many cases, an
Updates for FIXMEs
2018-02-02 20:44:16 +01:00
incorrect entry cannot be determined until its parent is revealed: an entry is
specifically corrupted, along with all its children.
BOLT-3 Edits This is my final first-pass BOLT. Some grammar changes, some remote/local additions, a few questions.
2018-01-16 20:52:38 +01:00
For
BOLT 3: complete first pass copy-edit according to stylesheet guidelines;
2017-11-21 03:51:25 +01:00
these tests a seed of `0xFFF...FF` is used, and incorrect entries are
trivial: Minor markup fixes
2016-12-09 15:25:48 +01:00
seeded with `0x000...00`.
BOLT 3: Add test vectors for per-commitment-secret generation These were generated (and recovery tested) by the command-line tool at: https://github.com/rustyrussell/ccan/tree/master/ccan/crypto/shachain/tools Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-12-02 02:16:04 +01:00
name: insert_secret correct sequence
I: 281474976710655
secret: 0x7cc854b54e3e0dcdb010d7a3fee464a9687be6e8db3be6854c475621e007a5dc
output: OK
I: 281474976710654
secret: 0xc7518c8ae4660ed02894df8976fa1a3659c1a8b4b5bec0c4b872abeba4cb8964
output: OK
I: 281474976710653
secret: 0x2273e227a5b7449b6e70f1fb4652864038b1cbf9cd7c043a7d6456b7fc275ad8
output: OK
I: 281474976710652
secret: 0x27cddaa5624534cb6cb9d7da077cf2b22ab21e9b506fd4998a51d54502e99116
output: OK
I: 281474976710651
secret: 0xc65716add7aa98ba7acb236352d665cab17345fe45b55fb879ff80e6bd0c41dd
output: OK
I: 281474976710650
secret: 0x969660042a28f32d9be17344e09374b379962d03db1574df5a8a5a47e19ce3f2
output: OK
I: 281474976710649
secret: 0xa5a64476122ca0925fb344bdc1854c1c0a59fc614298e50a33e331980a220f32
output: OK
I: 281474976710648
secret: 0x05cde6323d949933f7f7b78776bcc1ea6d9b31447732e3802e1f7ac44b650e17
output: OK
name: insert_secret #1 incorrect
I: 281474976710655
secret: 0x02a40c85b6f28da08dfdbe0926c53fab2de6d28c10301f8f7c4073d5e42e3148
output: OK
I: 281474976710654
secret: 0xc7518c8ae4660ed02894df8976fa1a3659c1a8b4b5bec0c4b872abeba4cb8964
output: ERROR
name: insert_secret #2 incorrect (#1 derived from incorrect)
I: 281474976710655
secret: 0x02a40c85b6f28da08dfdbe0926c53fab2de6d28c10301f8f7c4073d5e42e3148
output: OK
I: 281474976710654
secret: 0xdddc3a8d14fddf2b68fa8c7fbad2748274937479dd0f8930d5ebb4ab6bd866a3
output: OK
I: 281474976710653
secret: 0x2273e227a5b7449b6e70f1fb4652864038b1cbf9cd7c043a7d6456b7fc275ad8
output: OK
I: 281474976710652
secret: 0x27cddaa5624534cb6cb9d7da077cf2b22ab21e9b506fd4998a51d54502e99116
output: ERROR
name: insert_secret #3 incorrect
I: 281474976710655
secret: 0x7cc854b54e3e0dcdb010d7a3fee464a9687be6e8db3be6854c475621e007a5dc
output: OK
I: 281474976710654
secret: 0xc7518c8ae4660ed02894df8976fa1a3659c1a8b4b5bec0c4b872abeba4cb8964
output: OK
I: 281474976710653
secret: 0xc51a18b13e8527e579ec56365482c62f180b7d5760b46e9477dae59e87ed423a
output: OK
I: 281474976710652
secret: 0x27cddaa5624534cb6cb9d7da077cf2b22ab21e9b506fd4998a51d54502e99116
output: ERROR
name: insert_secret #4 incorrect (1,2,3 derived from incorrect)
I: 281474976710655
secret: 0x02a40c85b6f28da08dfdbe0926c53fab2de6d28c10301f8f7c4073d5e42e3148
output: OK
I: 281474976710654
secret: 0xdddc3a8d14fddf2b68fa8c7fbad2748274937479dd0f8930d5ebb4ab6bd866a3
output: OK
I: 281474976710653
secret: 0xc51a18b13e8527e579ec56365482c62f180b7d5760b46e9477dae59e87ed423a
output: OK
I: 281474976710652
secret: 0xba65d7b0ef55a3ba300d4e87af29868f394f8f138d78a7011669c79b37b936f4
output: OK
I: 281474976710651
secret: 0xc65716add7aa98ba7acb236352d665cab17345fe45b55fb879ff80e6bd0c41dd
output: OK
I: 281474976710650
secret: 0x969660042a28f32d9be17344e09374b379962d03db1574df5a8a5a47e19ce3f2
output: OK
I: 281474976710649
secret: 0xa5a64476122ca0925fb344bdc1854c1c0a59fc614298e50a33e331980a220f32
output: OK
I: 281474976710648
secret: 0x05cde6323d949933f7f7b78776bcc1ea6d9b31447732e3802e1f7ac44b650e17
output: ERROR
BOLT 1,2,3: first pass copy-edit; BOLT 1,2: minor header spacing fixes BOLT 3: first pass copy edit, according to capitalization, formatting stylesheet guidelines;
2017-11-18 22:04:58 +01:00
BOLT 3: Add test vectors for per-commitment-secret generation These were generated (and recovery tested) by the command-line tool at: https://github.com/rustyrussell/ccan/tree/master/ccan/crypto/shachain/tools Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-12-02 02:16:04 +01:00
name: insert_secret #5 incorrect
I: 281474976710655
secret: 0x7cc854b54e3e0dcdb010d7a3fee464a9687be6e8db3be6854c475621e007a5dc
output: OK
I: 281474976710654
secret: 0xc7518c8ae4660ed02894df8976fa1a3659c1a8b4b5bec0c4b872abeba4cb8964
output: OK
I: 281474976710653
secret: 0x2273e227a5b7449b6e70f1fb4652864038b1cbf9cd7c043a7d6456b7fc275ad8
output: OK
I: 281474976710652
secret: 0x27cddaa5624534cb6cb9d7da077cf2b22ab21e9b506fd4998a51d54502e99116
output: OK
I: 281474976710651
secret: 0x631373ad5f9ef654bb3dade742d09504c567edd24320d2fcd68e3cc47e2ff6a6
output: OK
I: 281474976710650
secret: 0x969660042a28f32d9be17344e09374b379962d03db1574df5a8a5a47e19ce3f2
output: ERROR
name: insert_secret #6 incorrect (5 derived from incorrect)
I: 281474976710655
secret: 0x7cc854b54e3e0dcdb010d7a3fee464a9687be6e8db3be6854c475621e007a5dc
output: OK
I: 281474976710654
secret: 0xc7518c8ae4660ed02894df8976fa1a3659c1a8b4b5bec0c4b872abeba4cb8964
output: OK
I: 281474976710653
secret: 0x2273e227a5b7449b6e70f1fb4652864038b1cbf9cd7c043a7d6456b7fc275ad8
output: OK
I: 281474976710652
secret: 0x27cddaa5624534cb6cb9d7da077cf2b22ab21e9b506fd4998a51d54502e99116
output: OK
I: 281474976710651
secret: 0x631373ad5f9ef654bb3dade742d09504c567edd24320d2fcd68e3cc47e2ff6a6
output: OK
I: 281474976710650
secret: 0xb7e76a83668bde38b373970155c868a653304308f9896692f904a23731224bb1
output: OK
I: 281474976710649
secret: 0xa5a64476122ca0925fb344bdc1854c1c0a59fc614298e50a33e331980a220f32
output: OK
I: 281474976710648
secret: 0x05cde6323d949933f7f7b78776bcc1ea6d9b31447732e3802e1f7ac44b650e17
output: ERROR
name: insert_secret #7 incorrect
I: 281474976710655
secret: 0x7cc854b54e3e0dcdb010d7a3fee464a9687be6e8db3be6854c475621e007a5dc
output: OK
I: 281474976710654
secret: 0xc7518c8ae4660ed02894df8976fa1a3659c1a8b4b5bec0c4b872abeba4cb8964
output: OK
I: 281474976710653
secret: 0x2273e227a5b7449b6e70f1fb4652864038b1cbf9cd7c043a7d6456b7fc275ad8
output: OK
I: 281474976710652
secret: 0x27cddaa5624534cb6cb9d7da077cf2b22ab21e9b506fd4998a51d54502e99116
output: OK
I: 281474976710651
secret: 0xc65716add7aa98ba7acb236352d665cab17345fe45b55fb879ff80e6bd0c41dd
output: OK
I: 281474976710650
secret: 0x969660042a28f32d9be17344e09374b379962d03db1574df5a8a5a47e19ce3f2
output: OK
I: 281474976710649
secret: 0xe7971de736e01da8ed58b94c2fc216cb1dca9e326f3a96e7194fe8ea8af6c0a3
output: OK
I: 281474976710648
secret: 0x05cde6323d949933f7f7b78776bcc1ea6d9b31447732e3802e1f7ac44b650e17
output: ERROR
name: insert_secret #8 incorrect
I: 281474976710655
secret: 0x7cc854b54e3e0dcdb010d7a3fee464a9687be6e8db3be6854c475621e007a5dc
output: OK
I: 281474976710654
secret: 0xc7518c8ae4660ed02894df8976fa1a3659c1a8b4b5bec0c4b872abeba4cb8964
output: OK
I: 281474976710653
secret: 0x2273e227a5b7449b6e70f1fb4652864038b1cbf9cd7c043a7d6456b7fc275ad8
output: OK
I: 281474976710652
secret: 0x27cddaa5624534cb6cb9d7da077cf2b22ab21e9b506fd4998a51d54502e99116
output: OK
I: 281474976710651
secret: 0xc65716add7aa98ba7acb236352d665cab17345fe45b55fb879ff80e6bd0c41dd
output: OK
I: 281474976710650
secret: 0x969660042a28f32d9be17344e09374b379962d03db1574df5a8a5a47e19ce3f2
output: OK
I: 281474976710649
secret: 0xa5a64476122ca0925fb344bdc1854c1c0a59fc614298e50a33e331980a220f32
output: OK
I: 281474976710648
secret: 0xa7efbc61aac46d34f77778bac22c8a20c6a46ca460addc49009bda875ec88fa4
output: ERROR
BOLT 1,2,3: first pass copy-edit; BOLT 1,2: minor header spacing fixes BOLT 3: first pass copy edit, according to capitalization, formatting stylesheet guidelines;
2017-11-18 22:04:58 +01:00
bolt3 fix and enhance tx testvectors (#99) This is a smerge of Fabrice Drouin and my work: he update them, I updated them and enhanced them, he found bugs, I re-derived them, etc. - rename keys properly - fix fees - sign all transactions - Derive test transaction vectors from minimal subset of parameters. - rewrite test vectors to test edge cases for trimming. - add funding tx test vector, make testable on regtest. This adds a funding transaction test (really, we only specify the output), but importantly adds enough information to duplicate a blockchain with that particular funding tx: $ rm -rf ~/.bitcoin/regtest/ $ bitcoind -regtest=1 & $ bitcoin-cli -regtest=1 submitblock 0000002006226e46111a0b59caaf126043eb5bbf28c34f3a5e332a1fc7b2b73cf188910fadbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fdc30f9858ffff7f20000000000101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff03510101ffffffff0100f2052a010000001976a9143ca33c2e4446f4a305f23c80df8ad1afdcf652f988ac00000000 $ bitcoin-cli -regtest=1 generate 431 $ bitcoin-cli -regtest=1 sendrawtransaction 0200000001adbb20ea41a8423ea937e76e8151636bf6093b70eaff942930d20576600521fd000000006b48304502210090587b6201e166ad6af0227d3036a9454223d49a1f11839c1a362184340ef0240220577f7cd5cca78719405cbf1de7414ac027f0239ef6e214c90fcaab0454d84b3b012103535b32d5eb0a6ed0982a0479bbadc9868d9836f6ba94dd5a63be16d875069184ffffffff028096980000000000220020c015c4a6be010e21657068fc2e6a9d02b27ebe4d490a25846f7237f104d1a3cd20256d29010000001600143ca33c2e4446f4a305f23c80df8ad1afdcf652f900000000 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-02-07 01:45:33 +01:00
# Appendix E: Key Derivation Test Vectors
BOLT 3: Add test vectors for key derivation. (#83) * BOLT 3: Add test vectors for key derivation. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-01-23 21:22:29 +01:00
BOLT 2,3,5: always refer to shared/pubkey/private key. Make it clear what kind of key we're talking about. We use the abbreviation pubkey for public key (as it's quite common to use in field names), but generally spell out 'private'. (I generally prefer 'secret' to 'private' but we use private far more often already, and we use 'secret' for things which don't directly derive keys). Fixes: #368 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2018-02-06 01:18:41 +01:00
These test the derivation for `localpubkey`, `remotepubkey`, `local_htlcpubkey`, `remote_htlcpubkey`, `local_delayedpubkey`, and
`remote_delayedpubkey` (which use the same formula), as well as the `revocationpubkey`.
BOLT 3: Add test vectors for key derivation. (#83) * BOLT 3: Add test vectors for key derivation. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-01-23 21:22:29 +01:00
All of them use the following secrets (and thus the derived points):
base_secret: 0x000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f
per_commitment_secret: 0x1f1e1d1c1b1a191817161514131211100f0e0d0c0b0a09080706050403020100
base_point: 0x036d6caac248af96f6afa7f904f550253a0f3ef3f5aa2fe6838a95b216691468e2
per_commitment_point: 0x025f7117a78150fe2ef97db7cfc83bd57b2e2c0d0dd25eaf467a4a1c2a45ce1486
BOLT 2,3,5: always refer to shared/pubkey/private key. Make it clear what kind of key we're talking about. We use the abbreviation pubkey for public key (as it's quite common to use in field names), but generally spell out 'private'. (I generally prefer 'secret' to 'private' but we use private far more often already, and we use 'secret' for things which don't directly derive keys). Fixes: #368 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2018-02-06 01:18:41 +01:00
name: derivation of pubkey from basepoint and per_commitment_point
BOLT 3: Replace many hyphens with underscores in descriptions. Not sure how I missed these: 1. funding-pubkey -> funding_pubkey 2. to-self-delay -> to_self_delay 3. per-commitment-point -> per_commitment_point 4. per-commitment-secret -> per_commitment_secret 5. revocation-basepoint -> revocation_basepoint 6. delayed-payment-basepoint -> delayed_payment_basepoint 7. payment-basepoint -> payment_basepoint Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-05-11 08:13:40 +02:00
# SHA256(per_commitment_point || basepoint)
BOLT 3: Add test vectors for key derivation. (#83) * BOLT 3: Add test vectors for key derivation. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-01-23 21:22:29 +01:00
# => SHA256(0x025f7117a78150fe2ef97db7cfc83bd57b2e2c0d0dd25eaf467a4a1c2a45ce1486 || 0x036d6caac248af96f6afa7f904f550253a0f3ef3f5aa2fe6838a95b216691468e2)
# = 0xcbcdd70fcfad15ea8e9e5c5a12365cf00912504f08ce01593689dd426bca9ff0
# + basepoint (0x036d6caac248af96f6afa7f904f550253a0f3ef3f5aa2fe6838a95b216691468e2)
# = 0x0235f2dbfaa89b57ec7b055afe29849ef7ddfeb1cefdb9ebdc43f5494984db29e5
BOLT 2,3,5: always refer to shared/pubkey/private key. Make it clear what kind of key we're talking about. We use the abbreviation pubkey for public key (as it's quite common to use in field names), but generally spell out 'private'. (I generally prefer 'secret' to 'private' but we use private far more often already, and we use 'secret' for things which don't directly derive keys). Fixes: #368 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2018-02-06 01:18:41 +01:00
localpubkey: 0x0235f2dbfaa89b57ec7b055afe29849ef7ddfeb1cefdb9ebdc43f5494984db29e5
BOLT 3: Add test vectors for key derivation. (#83) * BOLT 3: Add test vectors for key derivation. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-01-23 21:22:29 +01:00
BOLT 2,3,5: always refer to shared/pubkey/private key. Make it clear what kind of key we're talking about. We use the abbreviation pubkey for public key (as it's quite common to use in field names), but generally spell out 'private'. (I generally prefer 'secret' to 'private' but we use private far more often already, and we use 'secret' for things which don't directly derive keys). Fixes: #368 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2018-02-06 01:18:41 +01:00
name: derivation of private key from basepoint secret and per_commitment_secret
Clarify Bolt 3 htlc tx output test vectors (#852) It was sometimes unclear where we indexed by the output or the htlc id. This is a follow-up from discussions made in #539.
2021-06-21 22:01:47 +02:00
# SHA256(per_commitment_point || basepoint)
BOLT 3: Add test vectors for key derivation. (#83) * BOLT 3: Add test vectors for key derivation. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-01-23 21:22:29 +01:00
# => SHA256(0x025f7117a78150fe2ef97db7cfc83bd57b2e2c0d0dd25eaf467a4a1c2a45ce1486 || 0x036d6caac248af96f6afa7f904f550253a0f3ef3f5aa2fe6838a95b216691468e2)
# = 0xcbcdd70fcfad15ea8e9e5c5a12365cf00912504f08ce01593689dd426bca9ff0
# + basepoint_secret (0x000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f)
# = 0xcbced912d3b21bf196a766651e436aff192362621ce317704ea2f75d87e7be0f
localprivkey: 0xcbced912d3b21bf196a766651e436aff192362621ce317704ea2f75d87e7be0f
BOLT 2,3,5: always refer to shared/pubkey/private key. Make it clear what kind of key we're talking about. We use the abbreviation pubkey for public key (as it's quite common to use in field names), but generally spell out 'private'. (I generally prefer 'secret' to 'private' but we use private far more often already, and we use 'secret' for things which don't directly derive keys). Fixes: #368 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2018-02-06 01:18:41 +01:00
name: derivation of revocation pubkey from basepoint and per_commitment_point
BOLT 3: Replace many hyphens with underscores in descriptions. Not sure how I missed these: 1. funding-pubkey -> funding_pubkey 2. to-self-delay -> to_self_delay 3. per-commitment-point -> per_commitment_point 4. per-commitment-secret -> per_commitment_secret 5. revocation-basepoint -> revocation_basepoint 6. delayed-payment-basepoint -> delayed_payment_basepoint 7. payment-basepoint -> payment_basepoint Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-05-11 08:13:40 +02:00
# SHA256(revocation_basepoint || per_commitment_point)
BOLT 3: Add test vectors for key derivation. (#83) * BOLT 3: Add test vectors for key derivation. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-01-23 21:22:29 +01:00
# => SHA256(0x036d6caac248af96f6afa7f904f550253a0f3ef3f5aa2fe6838a95b216691468e2 || 0x025f7117a78150fe2ef97db7cfc83bd57b2e2c0d0dd25eaf467a4a1c2a45ce1486)
# = 0xefbf7ba5a074276701798376950a64a90f698997cce0dff4d24a6d2785d20963
BOLT 3: Replace many hyphens with underscores in descriptions. Not sure how I missed these: 1. funding-pubkey -> funding_pubkey 2. to-self-delay -> to_self_delay 3. per-commitment-point -> per_commitment_point 4. per-commitment-secret -> per_commitment_secret 5. revocation-basepoint -> revocation_basepoint 6. delayed-payment-basepoint -> delayed_payment_basepoint 7. payment-basepoint -> payment_basepoint Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-05-11 08:13:40 +02:00
# x revocation_basepoint = 0x02c00c4aadc536290422a807250824a8d87f19d18da9d610d45621df22510db8ce
# SHA256(per_commitment_point || revocation_basepoint)
BOLT 3: Add test vectors for key derivation. (#83) * BOLT 3: Add test vectors for key derivation. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-01-23 21:22:29 +01:00
# => SHA256(0x025f7117a78150fe2ef97db7cfc83bd57b2e2c0d0dd25eaf467a4a1c2a45ce1486 || 0x036d6caac248af96f6afa7f904f550253a0f3ef3f5aa2fe6838a95b216691468e2)
# = 0xcbcdd70fcfad15ea8e9e5c5a12365cf00912504f08ce01593689dd426bca9ff0
BOLT 3: Replace many hyphens with underscores in descriptions. Not sure how I missed these: 1. funding-pubkey -> funding_pubkey 2. to-self-delay -> to_self_delay 3. per-commitment-point -> per_commitment_point 4. per-commitment-secret -> per_commitment_secret 5. revocation-basepoint -> revocation_basepoint 6. delayed-payment-basepoint -> delayed_payment_basepoint 7. payment-basepoint -> payment_basepoint Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-05-11 08:13:40 +02:00
# x per_commitment_point = 0x0325ee7d3323ce52c4b33d4e0a73ab637711057dd8866e3b51202a04112f054c43
BOLT 3: Add test vectors for key derivation. (#83) * BOLT 3: Add test vectors for key derivation. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-01-23 21:22:29 +01:00
# 0x02c00c4aadc536290422a807250824a8d87f19d18da9d610d45621df22510db8ce + 0x0325ee7d3323ce52c4b33d4e0a73ab637711057dd8866e3b51202a04112f054c43 => 0x02916e326636d19c33f13e8c0c3a03dd157f332f3e99c317c141dd865eb01f8ff0
BOLT 2,3,5: always refer to shared/pubkey/private key. Make it clear what kind of key we're talking about. We use the abbreviation pubkey for public key (as it's quite common to use in field names), but generally spell out 'private'. (I generally prefer 'secret' to 'private' but we use private far more often already, and we use 'secret' for things which don't directly derive keys). Fixes: #368 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2018-02-06 01:18:41 +01:00
revocationpubkey: 0x02916e326636d19c33f13e8c0c3a03dd157f332f3e99c317c141dd865eb01f8ff0
BOLT 3: Add test vectors for key derivation. (#83) * BOLT 3: Add test vectors for key derivation. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-01-23 21:22:29 +01:00
BOLT 3: Replace many hyphens with underscores in descriptions. Not sure how I missed these: 1. funding-pubkey -> funding_pubkey 2. to-self-delay -> to_self_delay 3. per-commitment-point -> per_commitment_point 4. per-commitment-secret -> per_commitment_secret 5. revocation-basepoint -> revocation_basepoint 6. delayed-payment-basepoint -> delayed_payment_basepoint 7. payment-basepoint -> payment_basepoint Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-05-11 08:13:40 +02:00
name: derivation of revocation secret from basepoint_secret and per_commitment_secret
# SHA256(revocation_basepoint || per_commitment_point)
BOLT 3: Add test vectors for key derivation. (#83) * BOLT 3: Add test vectors for key derivation. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-01-23 21:22:29 +01:00
# => SHA256(0x036d6caac248af96f6afa7f904f550253a0f3ef3f5aa2fe6838a95b216691468e2 || 0x025f7117a78150fe2ef97db7cfc83bd57b2e2c0d0dd25eaf467a4a1c2a45ce1486)
# = 0xefbf7ba5a074276701798376950a64a90f698997cce0dff4d24a6d2785d20963
BOLT 3: Replace many hyphens with underscores in descriptions. Not sure how I missed these: 1. funding-pubkey -> funding_pubkey 2. to-self-delay -> to_self_delay 3. per-commitment-point -> per_commitment_point 4. per-commitment-secret -> per_commitment_secret 5. revocation-basepoint -> revocation_basepoint 6. delayed-payment-basepoint -> delayed_payment_basepoint 7. payment-basepoint -> payment_basepoint Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-05-11 08:13:40 +02:00
# * revocation_basepoint_secret (0x000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f)# = 0x44bfd55f845f885b8e60b2dca4b30272d5343be048d79ce87879d9863dedc842
# SHA256(per_commitment_point || revocation_basepoint)
BOLT 3: Add test vectors for key derivation. (#83) * BOLT 3: Add test vectors for key derivation. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-01-23 21:22:29 +01:00
# => SHA256(0x025f7117a78150fe2ef97db7cfc83bd57b2e2c0d0dd25eaf467a4a1c2a45ce1486 || 0x036d6caac248af96f6afa7f904f550253a0f3ef3f5aa2fe6838a95b216691468e2)
# = 0xcbcdd70fcfad15ea8e9e5c5a12365cf00912504f08ce01593689dd426bca9ff0
BOLT 3: Replace many hyphens with underscores in descriptions. Not sure how I missed these: 1. funding-pubkey -> funding_pubkey 2. to-self-delay -> to_self_delay 3. per-commitment-point -> per_commitment_point 4. per-commitment-secret -> per_commitment_secret 5. revocation-basepoint -> revocation_basepoint 6. delayed-payment-basepoint -> delayed_payment_basepoint 7. payment-basepoint -> payment_basepoint Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-05-11 08:13:40 +02:00
# * per_commitment_secret (0x1f1e1d1c1b1a191817161514131211100f0e0d0c0b0a09080706050403020100)# = 0x8be02a96a97b9a3c1c9f59ebb718401128b72ec009d85ee1656319b52319b8ce
BOLT 3: Add test vectors for key derivation. (#83) * BOLT 3: Add test vectors for key derivation. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-01-23 21:22:29 +01:00
# => 0xd09ffff62ddb2297ab000cc85bcb4283fdeb6aa052affbc9dddcf33b61078110
revocationprivkey: 0xd09ffff62ddb2297ab000cc85bcb4283fdeb6aa052affbc9dddcf33b61078110
Anchor outputs This commit extends the specification with a new commitment format that adds two anchor outputs to the commitment transaction. Anchor outputs are a safety feature that allows a channel party to unilaterally increase the fee of the commitment transaction using CPFP and ensure timely confirmation on the chain. There is no cooperation required from the remote party.
2020-08-19 12:29:11 +02:00
# Appendix F: Commitment and HTLC Transaction Test Vectors (anchors)
The anchor test vectors are based on the test cases as defined in appendix C.
Note that in appendix C, `to_local_msat` and `to_remote_msat` are balances
before subtraction of:
* Commit fee (funder only)
* Anchor outputs (funder only)
* In-flight htlcs
BOLT 3: add test vectors for htlc-transactions in case where CLTV is used as tie-breaker for sorting (#539) Add a serialized transactions test vector for the edge case of sorting htlc-timeout-tx when there are multiple offered htlc with the same amount and preimage. The test vector reuses previous preimages and creates a case scenario with 1 received htlc and 2 offered, the two offered will have same scriptPubKey and redeemScript, but different CLTV value. It is asserted the order in which the htlc transactions should be kept internally and we assume the same order is used to construct the commitment_signed message. This complements #491 .
2021-03-05 09:10:26 +01:00
Anchor outputs This commit extends the specification with a new commitment format that adds two anchor outputs to the commitment transaction. Anchor outputs are a safety feature that allows a channel party to unilaterally increase the fee of the commitment transaction using CPFP and ensure timely confirmation on the chain. There is no cooperation required from the remote party.
2020-08-19 12:29:11 +02:00
```yaml
[
{
"Name": "simple commitment tx with no HTLCs",
"LocalBalance": 7000000000,
"RemoteBalance": 3000000000,
"FeePerKw": 15000,
"UseTestHtlcs": false,
"HtlcDescs": [],
"ExpectedCommitmentTxHex": "02000000000101bef67e4e2fb9ddeeb3461973cd4c62abb35050b1add772995b820b584a488489000000000038b02b80044a010000000000002200202b1b5854183c12d3316565972c4668929d314d81c5dcdbb21cb45fe8a9a8114f4a01000000000000220020e9e86e4823faa62e222ebc858a226636856158f07e69898da3b0d1af0ddb3994c0c62d0000000000220020f3394e1e619b0eca1f91be2fb5ab4dfc59ba5b84ebe014ad1d43a564d012994a508b6a00000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e04004830450221008266ac6db5ea71aac3c95d97b0e172ff596844851a3216eb88382a8dddfd33d2022050e240974cfd5d708708b4365574517c18e7ae535ef732a3484d43d0d82be9f701483045022100f89034eba16b2be0e5581f750a0a6309192b75cce0f202f0ee2b4ec0cc394850022076c65dc507fe42276152b7a3d90e961e678adbe966e916ecfe85e64d430e75f301475221023da092f6980e58d2c037173180e9a465476026ee50f96695963e8efe436f54eb21030e9f7b623d2ccc7c9bd44d66d5ce21ce504c0acf6385a132cec6d3c39fa711c152ae3e195220",
"RemoteSigHex": "3045022100f89034eba16b2be0e5581f750a0a6309192b75cce0f202f0ee2b4ec0cc394850022076c65dc507fe42276152b7a3d90e961e678adbe966e916ecfe85e64d430e75f3"
},
{
"Name": "simple commitment tx with no HTLCs and single anchor",
BOLT 03: fix no htlc single anchor test The commitment transaction tests are all meant to use the same funding transaction which has an amount of 10000000000 msat. The LocalBalance and RemoteBalance along with the value of any htlcs should always add up to this amount. This commit updates the `simple commitment tx with no HTLCs and single anchor` anchors test to comply with the above.
2023-02-22 08:53:52 +01:00
"LocalBalance": 10000000000,
Anchor outputs This commit extends the specification with a new commitment format that adds two anchor outputs to the commitment transaction. Anchor outputs are a safety feature that allows a channel party to unilaterally increase the fee of the commitment transaction using CPFP and ensure timely confirmation on the chain. There is no cooperation required from the remote party.
2020-08-19 12:29:11 +02:00
"RemoteBalance": 0,
"FeePerKw": 15000,
"UseTestHtlcs": false,
"HtlcDescs": [],
BOLT 03: fix no htlc single anchor test The commitment transaction tests are all meant to use the same funding transaction which has an amount of 10000000000 msat. The LocalBalance and RemoteBalance along with the value of any htlcs should always add up to this amount. This commit updates the `simple commitment tx with no HTLCs and single anchor` anchors test to comply with the above.
2023-02-22 08:53:52 +01:00
"ExpectedCommitmentTxHex": "02000000000101bef67e4e2fb9ddeeb3461973cd4c62abb35050b1add772995b820b584a488489000000000038b02b80024a010000000000002200202b1b5854183c12d3316565972c4668929d314d81c5dcdbb21cb45fe8a9a8114f10529800000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e0400473044022007cf6b405e9c9b4f527b0ecad9d8bb661fabb8b12abf7d1c0b3ad1855db3ed490220616d5c1eeadccc63bd775a131149455d62d95a42c2a1b01cc7821fc42dce7778014730440220655bf909fb6fa81d086f1336ac72c97906dce29d1b166e305c99152d810e26e1022051f577faa46412c46707aaac46b65d50053550a66334e00a44af2706f27a865801475221023da092f6980e58d2c037173180e9a465476026ee50f96695963e8efe436f54eb21030e9f7b623d2ccc7c9bd44d66d5ce21ce504c0acf6385a132cec6d3c39fa711c152ae3e195220",
"RemoteSigHex": "30440220655bf909fb6fa81d086f1336ac72c97906dce29d1b166e305c99152d810e26e1022051f577faa46412c46707aaac46b65d50053550a66334e00a44af2706f27a8658"
Anchor outputs This commit extends the specification with a new commitment format that adds two anchor outputs to the commitment transaction. Anchor outputs are a safety feature that allows a channel party to unilaterally increase the fee of the commitment transaction using CPFP and ensure timely confirmation on the chain. There is no cooperation required from the remote party.
2020-08-19 12:29:11 +02:00
},
{
"Name": "commitment tx with seven outputs untrimmed (maximum feerate)",
"LocalBalance": 6988000000,
"RemoteBalance": 3000000000,
"FeePerKw": 644,
"UseTestHtlcs": true,
"HtlcDescs": [
{
"RemoteSigHex": "304402205912d91c58016f593d9e46fefcdb6f4125055c41a17b03101eaaa034b9028ab60220520d4d239c85c66e4c75c5b413620b62736e227659d7821b308e2b8ced3e728e",
"ResolutionTxHex": "02000000000101b8cefef62ea66f5178b9361b2371be0759cbc8c689bcfa7a8e6746d497ec221a0200000000010000000122020000000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e050047304402205912d91c58016f593d9e46fefcdb6f4125055c41a17b03101eaaa034b9028ab60220520d4d239c85c66e4c75c5b413620b62736e227659d7821b308e2b8ced3e728e834730440220473166a5adcca68550bab80403f410a726b5bd855030527e3fefa8c1e4b4fd7b02203b1dc91d8d69039473036cb5c34398b99e8eb90ae500c22130a557b62294b188012000000000000000000000000000000000000000000000000000000000000000008d76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c8201208763a914b8bcb07f6344b42ab04250c86a6e8b75d3fdbbc688527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae677502f401b175ac6851b2756800000000"
},
{
"RemoteSigHex": "3045022100c6b4113678039ee1e43a6cba5e3224ed2355ffc05e365a393afe8843dc9a76860220566d01fd52d65a89ba8595023884f9e8f2e9a310a6b9b85281c0bce06863430c",
"ResolutionTxHex": "02000000000101b8cefef62ea66f5178b9361b2371be0759cbc8c689bcfa7a8e6746d497ec221a0300000000010000000124060000000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e0500483045022100c6b4113678039ee1e43a6cba5e3224ed2355ffc05e365a393afe8843dc9a76860220566d01fd52d65a89ba8595023884f9e8f2e9a310a6b9b85281c0bce06863430c83483045022100d0d86307ea55d5daa80f453ad6d64b78fe8a6504aac25407c73e8502c0702c1602206a0809a02aa00c8dc4a53d976bb05d4605d8bb0b7b26b973a5c4e2734d8afbb401008876a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c820120876475527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae67a914b43e1b38138a41b37f7cd9a1d274bc63e3a9b5d188ac6851b27568f6010000"
},
{
"RemoteSigHex": "304402203c3a699fb80a38112aafd73d6e3a9b7d40bc2c3ed8b7fbc182a20f43b215172202204e71821b984d1af52c4b8e2cd4c572578c12a965866130c2345f61e4c2d3fef4",
"ResolutionTxHex": "02000000000101b8cefef62ea66f5178b9361b2371be0759cbc8c689bcfa7a8e6746d497ec221a040000000001000000010a060000000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e050047304402203c3a699fb80a38112aafd73d6e3a9b7d40bc2c3ed8b7fbc182a20f43b215172202204e71821b984d1af52c4b8e2cd4c572578c12a965866130c2345f61e4c2d3fef48347304402205bcfa92f83c69289a412b0b6dd4f2a0fe0b0fc2d45bd74706e963257a09ea24902203783e47883e60b86240e877fcbf33d50b1742f65bc93b3162d1be26583b367ee012001010101010101010101010101010101010101010101010101010101010101018d76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c8201208763a9144b6b2e5444c2639cc0fb7bcea5afba3f3cdce23988527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae677502f501b175ac6851b2756800000000"
},
{
"RemoteSigHex": "304402200f089bcd20f25475216307d32aa5b6c857419624bfba1da07335f51f6ba4645b02206ce0f7153edfba23b0d4b2afc26bb3157d404368cb8ea0ca7cf78590dcdd28cf",
"ResolutionTxHex": "02000000000101b8cefef62ea66f5178b9361b2371be0759cbc8c689bcfa7a8e6746d497ec221a050000000001000000010c0a0000000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e050047304402200f089bcd20f25475216307d32aa5b6c857419624bfba1da07335f51f6ba4645b02206ce0f7153edfba23b0d4b2afc26bb3157d404368cb8ea0ca7cf78590dcdd28cf83483045022100e4516da08f72c7a4f7b2f37aa84a0feb54ae2cc5b73f0da378e81ae0ca8119bf02207751b2628d8e2f62b4b9abccda4866246c1bfcc82e3d416ad562fd212102c28f01008876a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c820120876475527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae67a9148a486ff2e31d6158bf39e2608864d63fefd09d5b88ac6851b27568f7010000"
},
{
"RemoteSigHex": "3045022100aa72cfaf0965020c73a12c77276c6411ca68c4de36ac1998adf86c917a899a43022060da0a159fecfe0bed37c3962d767f12f90e30fed8a8f34b1301775c21a2bd3a",
"ResolutionTxHex": "02000000000101b8cefef62ea66f5178b9361b2371be0759cbc8c689bcfa7a8e6746d497ec221a06000000000100000001da0d0000000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e0500483045022100aa72cfaf0965020c73a12c77276c6411ca68c4de36ac1998adf86c917a899a43022060da0a159fecfe0bed37c3962d767f12f90e30fed8a8f34b1301775c21a2bd3a8347304402203cd12065c2a42963c762e6b1a981e17695616ecb6f9fb33d8b0717cdd7ca0ee4022065500005c491c1dcf2fe9c4024f74b1c90785d572527055a491278f901143904012004040404040404040404040404040404040404040404040404040404040404048d76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c8201208763a91418bc1a114ccf9c052d3d23e28d3b0a9d1227434288527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae677502f801b175ac6851b2756800000000"
}
],
"ExpectedCommitmentTxHex": "02000000000101bef67e4e2fb9ddeeb3461973cd4c62abb35050b1add772995b820b584a488489000000000038b02b80094a010000000000002200202b1b5854183c12d3316565972c4668929d314d81c5dcdbb21cb45fe8a9a8114f4a01000000000000220020e9e86e4823faa62e222ebc858a226636856158f07e69898da3b0d1af0ddb3994e80300000000000022002010f88bf09e56f14fb4543fd26e47b0db50ea5de9cf3fc46434792471082621aed0070000000000002200203e68115ae0b15b8de75b6c6bc9af5ac9f01391544e0870dae443a1e8fe7837ead007000000000000220020fe0598d74fee2205cc3672e6e6647706b4f3099713b4661b62482c3addd04a5eb80b000000000000220020f96d0334feb64a4f40eb272031d07afcb038db56aa57446d60308c9f8ccadef9a00f000000000000220020ce6e751274836ff59622a0d1e07f8831d80bd6730bd48581398bfadd2bb8da9ac0c62d0000000000220020f3394e1e619b0eca1f91be2fb5ab4dfc59ba5b84ebe014ad1d43a564d012994a4f996a00000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e0400483045022100ef82a405364bfc4007e63a7cc82925a513d79065bdbc216d60b6a4223a323f8a02200716730b8561f3c6d362eaf47f202e99fb30d0557b61b92b5f9134f8e2de368101483045022100e0106830467a558c07544a3de7715610c1147062e7d091deeebe8b5c661cda9402202ad049c1a6d04834317a78483f723c205c9f638d17222aafc620800cc1b6ae3501475221023da092f6980e58d2c037173180e9a465476026ee50f96695963e8efe436f54eb21030e9f7b623d2ccc7c9bd44d66d5ce21ce504c0acf6385a132cec6d3c39fa711c152ae3e195220",
"RemoteSigHex": "3045022100e0106830467a558c07544a3de7715610c1147062e7d091deeebe8b5c661cda9402202ad049c1a6d04834317a78483f723c205c9f638d17222aafc620800cc1b6ae35"
},
{
"Name": "commitment tx with six outputs untrimmed (minimum feerate)",
"LocalBalance": 6988000000,
"RemoteBalance": 3000000000,
"FeePerKw": 645,
"UseTestHtlcs": true,
"HtlcDescs": [
{
"RemoteSigHex": "30440220446f9e5c375db6a61d6eeee8b59219a30a4a37372afc2670a1a2889c78e9b943022061895f6088fb48b490ab2140a4842c277b64bf25ff591625dd0356e0c96ab7a8",
"ResolutionTxHex": "02000000000101104f394af4c4fad78337f95e3e9f802f4c0d86ab231853af09b28534856132000200000000010000000123060000000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e05004730440220446f9e5c375db6a61d6eeee8b59219a30a4a37372afc2670a1a2889c78e9b943022061895f6088fb48b490ab2140a4842c277b64bf25ff591625dd0356e0c96ab7a883483045022100c1621ba26a99c263fd885feff5fda5ca2cc73df080b3a49ecf15164ee244d2a5022037f4cc7fd4441af39a83a0e44c3b1db7d64a4c8080e8697f9e952f85421a34d801008876a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c820120876475527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae67a914b43e1b38138a41b37f7cd9a1d274bc63e3a9b5d188ac6851b27568f6010000"
},
{
"RemoteSigHex": "3044022027a3ffcb8a007e3349d75382efbd4b3fb99fcbd479a18555e58697bd1278d5c402205c8303d46211c3ae8975fe84a0df08b4623119fecd03bc93b49d7f7a0c64c710",
"ResolutionTxHex": "02000000000101104f394af4c4fad78337f95e3e9f802f4c0d86ab231853af09b28534856132000300000000010000000109060000000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e0500473044022027a3ffcb8a007e3349d75382efbd4b3fb99fcbd479a18555e58697bd1278d5c402205c8303d46211c3ae8975fe84a0df08b4623119fecd03bc93b49d7f7a0c64c71083483045022100b697aca55c6fb15e5348bb7387b584815fd15e8dd306afe0c477cb550d0c2d40022050b0f7e370f7604d2fec781fefe86715dbe95dff4dab88d628f509d62f854de1012001010101010101010101010101010101010101010101010101010101010101018d76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c8201208763a9144b6b2e5444c2639cc0fb7bcea5afba3f3cdce23988527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae677502f501b175ac6851b2756800000000"
},
{
"RemoteSigHex": "30440220013975ae356e6daf22a86a29f21c4f35aca82ed8f731a1103c60c74f5ed1c5aa02200350d4e5455cdbcacb7ccf174db5bed8286019e509a113f6b4c5e606ee12c9d7",
"ResolutionTxHex": "02000000000101104f394af4c4fad78337f95e3e9f802f4c0d86ab231853af09b2853485613200040000000001000000010b0a0000000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e05004730440220013975ae356e6daf22a86a29f21c4f35aca82ed8f731a1103c60c74f5ed1c5aa02200350d4e5455cdbcacb7ccf174db5bed8286019e509a113f6b4c5e606ee12c9d783483045022100e69a29f78779577830e73f327073c93168896f1b89432124b7846f5def9cd9cb02204433db3697e6ed7ac89574ca066a749640e0c9e114ac2e0ee4545741fcf7b7e901008876a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c820120876475527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae67a9148a486ff2e31d6158bf39e2608864d63fefd09d5b88ac6851b27568f7010000"
},
{
"RemoteSigHex": "304402205257017423644c7e831f30bc0c334eecfe66e9a6d2e92d157c5bece576b2be4f022047b21cf8e955e22b7471940563922d1a5852fb95459ca32905c7d46a19141664",
"ResolutionTxHex": "02000000000101104f394af4c4fad78337f95e3e9f802f4c0d86ab231853af09b285348561320005000000000100000001d90d0000000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e050047304402205257017423644c7e831f30bc0c334eecfe66e9a6d2e92d157c5bece576b2be4f022047b21cf8e955e22b7471940563922d1a5852fb95459ca32905c7d46a191416648347304402204f5de65a624e3f757adffb678bd887eb4e656538c5ea7044922f6ee3eed8a06202206ff6f7bfe73b565343cae76131ac658f1a9c60d3ca2343358cda60b9e35f94c8012004040404040404040404040404040404040404040404040404040404040404048d76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c8201208763a91418bc1a114ccf9c052d3d23e28d3b0a9d1227434288527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae677502f801b175ac6851b2756800000000"
}
],
"ExpectedCommitmentTxHex": "02000000000101bef67e4e2fb9ddeeb3461973cd4c62abb35050b1add772995b820b584a488489000000000038b02b80084a010000000000002200202b1b5854183c12d3316565972c4668929d314d81c5dcdbb21cb45fe8a9a8114f4a01000000000000220020e9e86e4823faa62e222ebc858a226636856158f07e69898da3b0d1af0ddb3994d0070000000000002200203e68115ae0b15b8de75b6c6bc9af5ac9f01391544e0870dae443a1e8fe7837ead007000000000000220020fe0598d74fee2205cc3672e6e6647706b4f3099713b4661b62482c3addd04a5eb80b000000000000220020f96d0334feb64a4f40eb272031d07afcb038db56aa57446d60308c9f8ccadef9a00f000000000000220020ce6e751274836ff59622a0d1e07f8831d80bd6730bd48581398bfadd2bb8da9ac0c62d0000000000220020f3394e1e619b0eca1f91be2fb5ab4dfc59ba5b84ebe014ad1d43a564d012994abc996a00000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e0400483045022100d57697c707b6f6d053febf24b98e8989f186eea42e37e9e91663ec2c70bb8f70022079b0715a472118f262f43016a674f59c015d9cafccec885968e76d9d9c5d005101473044022025d97466c8049e955a5afce28e322f4b34d2561118e52332fb400f9b908cc0a402205dc6fba3a0d67ee142c428c535580cd1f2ff42e2f89b47e0c8a01847caffc31201475221023da092f6980e58d2c037173180e9a465476026ee50f96695963e8efe436f54eb21030e9f7b623d2ccc7c9bd44d66d5ce21ce504c0acf6385a132cec6d3c39fa711c152ae3e195220",
"RemoteSigHex": "3044022025d97466c8049e955a5afce28e322f4b34d2561118e52332fb400f9b908cc0a402205dc6fba3a0d67ee142c428c535580cd1f2ff42e2f89b47e0c8a01847caffc312"
},
{
"Name": "commitment tx with six outputs untrimmed (maximum feerate)",
"LocalBalance": 6988000000,
"RemoteBalance": 3000000000,
"FeePerKw": 2060,
"UseTestHtlcs": true,
"HtlcDescs": [
{
"RemoteSigHex": "30440220011f999016570bbab9f3125377d0f35096b4dbe155f97c20f71829ead2817d1602201f23f7e17f6928734601c5d8613431eed5c90aa41c3106e8c1cb02ce32aacb5d",
"ResolutionTxHex": "02000000000101e7f364cf3a554b670767e723ef14b2af7a3eac70bd79dbde9256f384369c062d0200000000010000000175020000000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e05004730440220011f999016570bbab9f3125377d0f35096b4dbe155f97c20f71829ead2817d1602201f23f7e17f6928734601c5d8613431eed5c90aa41c3106e8c1cb02ce32aacb5d83473044022017da96dfb0eb4061fa0162dc6fa6b2e07ecc5040ab5e6cb07be59838460b3e58022079371ffc95002cc1dc2891ec38198c9c25aca8164304fe114f1b55e2ffd1ddd501008876a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c820120876475527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae67a914b43e1b38138a41b37f7cd9a1d274bc63e3a9b5d188ac6851b27568f6010000"
},
{
"RemoteSigHex": "304402202d2d9681409b0a0987bd4a268ffeb112df85c4c988ac2a3a2475cb00a61912c302206aa4f4d1388b7d3282bc847871af3cca30766cc8f1064e3a41ec7e82221e10f7",
"ResolutionTxHex": "02000000000101e7f364cf3a554b670767e723ef14b2af7a3eac70bd79dbde9256f384369c062d0300000000010000000122020000000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e050047304402202d2d9681409b0a0987bd4a268ffeb112df85c4c988ac2a3a2475cb00a61912c302206aa4f4d1388b7d3282bc847871af3cca30766cc8f1064e3a41ec7e82221e10f78347304402206426d67911aa6ff9b1cb147b093f3f65a37831a86d7c741d999afc0666e1773d022000bb71821650c70ea58d9bcdd03af736c41a5a8159d436c3ee0408a07394dcce012001010101010101010101010101010101010101010101010101010101010101018d76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c8201208763a9144b6b2e5444c2639cc0fb7bcea5afba3f3cdce23988527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae677502f501b175ac6851b2756800000000"
},
{
"RemoteSigHex": "3045022100f51cdaa525b7d4304548c642bb7945215eb5ae7d32874517cde67ca23ab0a12202206286d59e4b19926c6ac844be6f3ab8149a1ddb9c70f5026b7e83e40a6c08e6e1",
"ResolutionTxHex": "02000000000101e7f364cf3a554b670767e723ef14b2af7a3eac70bd79dbde9256f384369c062d040000000001000000015d060000000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e0500483045022100f51cdaa525b7d4304548c642bb7945215eb5ae7d32874517cde67ca23ab0a12202206286d59e4b19926c6ac844be6f3ab8149a1ddb9c70f5026b7e83e40a6c08e6e18348304502210091b16b1ac63b867e7a5ca0344f7b2aa1cdd49d4b72eac86a31e7ec6f069e20640220402bfb571ba3a9c49e3b0061c89303453803d0241059d899222aaac4799b507601008876a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c820120876475527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae67a9148a486ff2e31d6158bf39e2608864d63fefd09d5b88ac6851b27568f7010000"
},
{
"RemoteSigHex": "304402202f058d99cb5a54f90773d43ba4e7a0089efd9f8269ef2da1b85d48a3e230555402205acc4bd6561830867d45cd7b84bba9fa35ad2b345016471c1737142bc99782c4",
"ResolutionTxHex": "02000000000101e7f364cf3a554b670767e723ef14b2af7a3eac70bd79dbde9256f384369c062d05000000000100000001f2090000000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e050047304402202f058d99cb5a54f90773d43ba4e7a0089efd9f8269ef2da1b85d48a3e230555402205acc4bd6561830867d45cd7b84bba9fa35ad2b345016471c1737142bc99782c48347304402202913f9cacea54efd2316cffa91219def9e0e111977216c1e76e9da80befab14f022000a9a69e8f37ebe4a39107ab50fab0dde537334588f8f412bbaca57b179b87a6012004040404040404040404040404040404040404040404040404040404040404048d76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c8201208763a91418bc1a114ccf9c052d3d23e28d3b0a9d1227434288527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae677502f801b175ac6851b2756800000000"
}
],
"ExpectedCommitmentTxHex": "02000000000101bef67e4e2fb9ddeeb3461973cd4c62abb35050b1add772995b820b584a488489000000000038b02b80084a010000000000002200202b1b5854183c12d3316565972c4668929d314d81c5dcdbb21cb45fe8a9a8114f4a01000000000000220020e9e86e4823faa62e222ebc858a226636856158f07e69898da3b0d1af0ddb3994d0070000000000002200203e68115ae0b15b8de75b6c6bc9af5ac9f01391544e0870dae443a1e8fe7837ead007000000000000220020fe0598d74fee2205cc3672e6e6647706b4f3099713b4661b62482c3addd04a5eb80b000000000000220020f96d0334feb64a4f40eb272031d07afcb038db56aa57446d60308c9f8ccadef9a00f000000000000220020ce6e751274836ff59622a0d1e07f8831d80bd6730bd48581398bfadd2bb8da9ac0c62d0000000000220020f3394e1e619b0eca1f91be2fb5ab4dfc59ba5b84ebe014ad1d43a564d012994ab88f6a00000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e040047304402201ce37a44b95213358c20f44404d6db7a6083bea6f58de6c46547ae41a47c9f8202206db1d45be41373e92f90d346381febbea8c78671b28c153e30ad1db3441a94970147304402206208aeb34e404bd052ce3f298dfa832891c9d42caec99fe2a0d2832e9690b94302201b034bfcc6fa9faec667a9b7cbfe0b8d85e954aa239b66277887b5088aff08c301475221023da092f6980e58d2c037173180e9a465476026ee50f96695963e8efe436f54eb21030e9f7b623d2ccc7c9bd44d66d5ce21ce504c0acf6385a132cec6d3c39fa711c152ae3e195220",
"RemoteSigHex": "304402206208aeb34e404bd052ce3f298dfa832891c9d42caec99fe2a0d2832e9690b94302201b034bfcc6fa9faec667a9b7cbfe0b8d85e954aa239b66277887b5088aff08c3"
},
{
"Name": "commitment tx with five outputs untrimmed (minimum feerate)",
"LocalBalance": 6988000000,
"RemoteBalance": 3000000000,
"FeePerKw": 2061,
"UseTestHtlcs": true,
"HtlcDescs": [
{
"RemoteSigHex": "3045022100e10744f572a2cd1d787c969e894b792afaed21217ee0480df0112d2fa3ef96ea02202af4f66eb6beebc36d8e98719ed6b4be1b181659fcb561fc491d8cfebff3aa85",
"ResolutionTxHex": "02000000000101cf32732fe2d1387ed4e2335f69ddd3c0f337dabc03269e742531f89d35e161d10200000000010000000174020000000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e0500483045022100e10744f572a2cd1d787c969e894b792afaed21217ee0480df0112d2fa3ef96ea02202af4f66eb6beebc36d8e98719ed6b4be1b181659fcb561fc491d8cfebff3aa8583483045022100c3dc3ea50a0ca20e350f97b50c52c5514717cfa36cb9600918caac5cb556842b022049af018d676dde0c8e28ecf325f3ff5c1594261c4f7511d501f9d62d0594d2a201008876a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c820120876475527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae67a914b43e1b38138a41b37f7cd9a1d274bc63e3a9b5d188ac6851b27568f6010000"
},
{
"RemoteSigHex": "3045022100e1f51fb72fec604b029b348a3bb6363454e1869f5b1e24fd736f860c8039f8070220030a2c90186437d8c9b47d4897798c024521b1274991c4cdc125970b346094b1",
"ResolutionTxHex": "02000000000101cf32732fe2d1387ed4e2335f69ddd3c0f337dabc03269e742531f89d35e161d1030000000001000000015c060000000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e0500483045022100e1f51fb72fec604b029b348a3bb6363454e1869f5b1e24fd736f860c8039f8070220030a2c90186437d8c9b47d4897798c024521b1274991c4cdc125970b346094b183483045022100ec7ade6037e531629f24390ca9713782a04d648065d17fbe6b015981cdb296c202202d61049a6ecba2fb5314f3edcda2361cad187a89bea6e5d15185354d80c0c08501008876a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c820120876475527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae67a9148a486ff2e31d6158bf39e2608864d63fefd09d5b88ac6851b27568f7010000"
},
{
"RemoteSigHex": "304402203479f81a1d83c516957679dc98bf91d35deada967739a8e3869e3e8db08246130220053c8e154b97e3019048dcec3d51bfaf396f36861fbda6d33f0e2a57155c8b9f",
"ResolutionTxHex": "02000000000101cf32732fe2d1387ed4e2335f69ddd3c0f337dabc03269e742531f89d35e161d104000000000100000001f1090000000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e050047304402203479f81a1d83c516957679dc98bf91d35deada967739a8e3869e3e8db08246130220053c8e154b97e3019048dcec3d51bfaf396f36861fbda6d33f0e2a57155c8b9f83483045022100a558eb5caa04e35a4417c1f0123ac12eec5f6badee28f5764dc6b69486e594f802201589b12784e242f205832d2d032149bd4e79433ec304c05394241fc7dcba5a71012004040404040404040404040404040404040404040404040404040404040404048d76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c8201208763a91418bc1a114ccf9c052d3d23e28d3b0a9d1227434288527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae677502f801b175ac6851b2756800000000"
}
],
"ExpectedCommitmentTxHex": "02000000000101bef67e4e2fb9ddeeb3461973cd4c62abb35050b1add772995b820b584a488489000000000038b02b80074a010000000000002200202b1b5854183c12d3316565972c4668929d314d81c5dcdbb21cb45fe8a9a8114f4a01000000000000220020e9e86e4823faa62e222ebc858a226636856158f07e69898da3b0d1af0ddb3994d0070000000000002200203e68115ae0b15b8de75b6c6bc9af5ac9f01391544e0870dae443a1e8fe7837eab80b000000000000220020f96d0334feb64a4f40eb272031d07afcb038db56aa57446d60308c9f8ccadef9a00f000000000000220020ce6e751274836ff59622a0d1e07f8831d80bd6730bd48581398bfadd2bb8da9ac0c62d0000000000220020f3394e1e619b0eca1f91be2fb5ab4dfc59ba5b84ebe014ad1d43a564d012994a18916a00000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e040047304402204ab07c659412dd2cd6043b1ad811ab215e901b6b5653e08cb3d2fe63d3e3dc57022031c7b3d130f9380ef09581f4f5a15cb6f359a2e0a597146b96c3533a26d6f4cd01483045022100a2faf2ad7e323b2a82e07dc40b6847207ca6ad7b089f2c21dea9a4d37e52d59d02204c9480ce0358eb51d92a4342355a97e272e3cc45f86c612a76a3fe32fc3c4cb401475221023da092f6980e58d2c037173180e9a465476026ee50f96695963e8efe436f54eb21030e9f7b623d2ccc7c9bd44d66d5ce21ce504c0acf6385a132cec6d3c39fa711c152ae3e195220",
"RemoteSigHex": "3045022100a2faf2ad7e323b2a82e07dc40b6847207ca6ad7b089f2c21dea9a4d37e52d59d02204c9480ce0358eb51d92a4342355a97e272e3cc45f86c612a76a3fe32fc3c4cb4"
},
{
"Name": "commitment tx with five outputs untrimmed (maximum feerate)",
"LocalBalance": 6988000000,
"RemoteBalance": 3000000000,
"FeePerKw": 2184,
"UseTestHtlcs": true,
"HtlcDescs": [
{
"RemoteSigHex": "304402202e03ba1390998b3487e9a7fefcb66814c09abea0ef1bcc915dbaefbcf310569a02206bd10493a105ac69048e9bcedcb8e3301ef81b55018d911a4afd297297f98d30",
"ResolutionTxHex": "020000000001015b03043e20eb467029305a22af4c3b915e793743f192c5d225cf1d3c6e8c03010200000000010000000122020000000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e050047304402202e03ba1390998b3487e9a7fefcb66814c09abea0ef1bcc915dbaefbcf310569a02206bd10493a105ac69048e9bcedcb8e3301ef81b55018d911a4afd297297f98d308347304402200c3952ca04be0c60dcc0b7873a0829f560607524943554ae4a27d8d967166199022021a68657b88e22f9bf9ac6065be412685aff643d17049f04f2e99e86197dabb101008876a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c820120876475527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae67a914b43e1b38138a41b37f7cd9a1d274bc63e3a9b5d188ac6851b27568f6010000"
},
{
"RemoteSigHex": "304402201f8a6adda2403bc400c919ea69d72d315337291e00d02cde085ea32953dbc50002202d65230da98df7af8ebefd2b60b457d0945232988ee2d7460a94a77d414a9acc",
"ResolutionTxHex": "020000000001015b03043e20eb467029305a22af4c3b915e793743f192c5d225cf1d3c6e8c0301030000000001000000010a060000000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e050047304402201f8a6adda2403bc400c919ea69d72d315337291e00d02cde085ea32953dbc50002202d65230da98df7af8ebefd2b60b457d0945232988ee2d7460a94a77d414a9acc83483045022100ea69c9273b8914ac62b5b7082d6ac1da2b7b065ebf2ef3cd6403f5305ce3f26802203d98736ea97638895a898dfcc5ee0d0c55eb496b3964df0bb25d223688ea8b8701008876a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c820120876475527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae67a9148a486ff2e31d6158bf39e2608864d63fefd09d5b88ac6851b27568f7010000"
},
{
"RemoteSigHex": "3045022100ea6e4c9b8f56dd9cf5799492a201cdd65b8bc9bc089c3cff34107896ae313f90022034760f7760975cc68e8917a7f62894e25583da7be11af557c4fc402661d0cbf8",
"ResolutionTxHex": "020000000001015b03043e20eb467029305a22af4c3b915e793743f192c5d225cf1d3c6e8c0301040000000001000000019b090000000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e0500483045022100ea6e4c9b8f56dd9cf5799492a201cdd65b8bc9bc089c3cff34107896ae313f90022034760f7760975cc68e8917a7f62894e25583da7be11af557c4fc402661d0cbf8834730440220717012f2f7ef6cac590aaf66c2109132c93ffba245959ac62d82e394ba80191302203f00fd9cb37c92c6b0ad4b33e62c3e55b04e5c2cfa0adcca5a9bc49774eeca8a012004040404040404040404040404040404040404040404040404040404040404048d76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c8201208763a91418bc1a114ccf9c052d3d23e28d3b0a9d1227434288527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae677502f801b175ac6851b2756800000000"
}
],
"ExpectedCommitmentTxHex": "02000000000101bef67e4e2fb9ddeeb3461973cd4c62abb35050b1add772995b820b584a488489000000000038b02b80074a010000000000002200202b1b5854183c12d3316565972c4668929d314d81c5dcdbb21cb45fe8a9a8114f4a01000000000000220020e9e86e4823faa62e222ebc858a226636856158f07e69898da3b0d1af0ddb3994d0070000000000002200203e68115ae0b15b8de75b6c6bc9af5ac9f01391544e0870dae443a1e8fe7837eab80b000000000000220020f96d0334feb64a4f40eb272031d07afcb038db56aa57446d60308c9f8ccadef9a00f000000000000220020ce6e751274836ff59622a0d1e07f8831d80bd6730bd48581398bfadd2bb8da9ac0c62d0000000000220020f3394e1e619b0eca1f91be2fb5ab4dfc59ba5b84ebe014ad1d43a564d012994a4f906a00000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e04004730440220555c05261f72c5b4702d5c83a608630822b473048724b08640d6e75e345094250220448950b74a96a56963928ba5db8b457661a742c855e69d239b3b6ab73de307a301473044022013d326f80ff7607cf366c823fcbbcb7a2b10322484825f151e6c4c756af24b8f02201ba05b9d8beb7cea2947f9f4d9e03f90435e93db2dd48b32eb9ca3f3dd042c7901475221023da092f6980e58d2c037173180e9a465476026ee50f96695963e8efe436f54eb21030e9f7b623d2ccc7c9bd44d66d5ce21ce504c0acf6385a132cec6d3c39fa711c152ae3e195220",
"RemoteSigHex": "3044022013d326f80ff7607cf366c823fcbbcb7a2b10322484825f151e6c4c756af24b8f02201ba05b9d8beb7cea2947f9f4d9e03f90435e93db2dd48b32eb9ca3f3dd042c79"
},
{
"Name": "commitment tx with four outputs untrimmed (minimum feerate)",
"LocalBalance": 6988000000,
"RemoteBalance": 3000000000,
"FeePerKw": 2185,
"UseTestHtlcs": true,
"HtlcDescs": [
{
"RemoteSigHex": "304502210094480e38afb41d10fae299224872f19c53abe23c7033a1c0642c48713e7863a10220726dd9456407682667dc4bd9c66975acb3744961770b5002f7eb9c0df9ef2f3e",
"ResolutionTxHex": "02000000000101ac13a7715f80b8e52dda43c6929cade5521bdced3a405da02b443f1ffb1e33cc0200000000010000000109060000000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e050048304502210094480e38afb41d10fae299224872f19c53abe23c7033a1c0642c48713e7863a10220726dd9456407682667dc4bd9c66975acb3744961770b5002f7eb9c0df9ef2f3e8347304402203148dac61513dc0361738cba30cb341a1e580f8acd5ab0149bf65bd670688cf002207e5d9a0fcbbea2c263bc714fa9e9c44d7f582ea447f366119fc614a23de32f1f01008876a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c820120876475527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae67a9148a486ff2e31d6158bf39e2608864d63fefd09d5b88ac6851b27568f7010000"
},
{
"RemoteSigHex": "304402200dbde868dbc20c6a2433fe8979ba5e3f966b1c2d1aeb615f1c42e9c938b3495402202eec5f663c8b601c2061c1453d35de22597c137d1907a2feaf714d551035cb6e",
"ResolutionTxHex": "02000000000101ac13a7715f80b8e52dda43c6929cade5521bdced3a405da02b443f1ffb1e33cc030000000001000000019a090000000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e050047304402200dbde868dbc20c6a2433fe8979ba5e3f966b1c2d1aeb615f1c42e9c938b3495402202eec5f663c8b601c2061c1453d35de22597c137d1907a2feaf714d551035cb6e83483045022100b896bded41d7feac7af25c19e35c53037c53b50e73cfd01eb4ba139c7fdf231602203a3be049d3d89396c4dc766d82ce31e237da8bc3a93e2c7d35992d1932d9cfeb012004040404040404040404040404040404040404040404040404040404040404048d76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c8201208763a91418bc1a114ccf9c052d3d23e28d3b0a9d1227434288527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae677502f801b175ac6851b2756800000000"
}
],
"ExpectedCommitmentTxHex": "02000000000101bef67e4e2fb9ddeeb3461973cd4c62abb35050b1add772995b820b584a488489000000000038b02b80064a010000000000002200202b1b5854183c12d3316565972c4668929d314d81c5dcdbb21cb45fe8a9a8114f4a01000000000000220020e9e86e4823faa62e222ebc858a226636856158f07e69898da3b0d1af0ddb3994b80b000000000000220020f96d0334feb64a4f40eb272031d07afcb038db56aa57446d60308c9f8ccadef9a00f000000000000220020ce6e751274836ff59622a0d1e07f8831d80bd6730bd48581398bfadd2bb8da9ac0c62d0000000000220020f3394e1e619b0eca1f91be2fb5ab4dfc59ba5b84ebe014ad1d43a564d012994ac5916a00000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e0400483045022100cd8479cfe1edb1e5a1d487391e0451a469c7171e51e680183f19eb4321f20e9b02204eab7d5a6384b1b08e03baa6e4d9748dfd2b5ab2bae7e39604a0d0055bbffdd501473044022040f63a16148cf35c8d3d41827f5ae7f7c3746885bb64d4d1b895892a83812b3e02202fcf95c2bf02c466163b3fa3ced6a24926fbb4035095a96842ef516e86ba54c001475221023da092f6980e58d2c037173180e9a465476026ee50f96695963e8efe436f54eb21030e9f7b623d2ccc7c9bd44d66d5ce21ce504c0acf6385a132cec6d3c39fa711c152ae3e195220",
"RemoteSigHex": "3044022040f63a16148cf35c8d3d41827f5ae7f7c3746885bb64d4d1b895892a83812b3e02202fcf95c2bf02c466163b3fa3ced6a24926fbb4035095a96842ef516e86ba54c0"
},
{
"Name": "commitment tx with four outputs untrimmed (maximum feerate)",
"LocalBalance": 6988000000,
"RemoteBalance": 3000000000,
"FeePerKw": 3686,
"UseTestHtlcs": true,
"HtlcDescs": [
{
"RemoteSigHex": "304402202cfe6618926ca9f1574f8c4659b425e9790b4677ba2248d77901290806130ffe02204ab37bb0287abcdb8b750b018d41a09effe37cb65ff801fa70d3f1a416599841",
"ResolutionTxHex": "020000000001012c32e55722e4b96324d8e5b398d583a20780b25202816adc32dc3157dee731c90200000000010000000122020000000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e050047304402202cfe6618926ca9f1574f8c4659b425e9790b4677ba2248d77901290806130ffe02204ab37bb0287abcdb8b750b018d41a09effe37cb65ff801fa70d3f1a41659984183473044022030b318139715e3b34f19be852cc01c1c0e1599e8b926a73df2bfb70dd186ddee022062a2b7398aed9f563b4014da04a1a99debd0ff663ceece68a547df5982dc2d7201008876a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c820120876475527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae67a9148a486ff2e31d6158bf39e2608864d63fefd09d5b88ac6851b27568f7010000"
},
{
"RemoteSigHex": "30440220687af8544d335376620a6f4b5412bfd0da48de047c1785674f26e669d4a3ff82022058591c1e3a6c50017427d38a8f756eb685bdab88ec73838eed3530048861f9d5",
"ResolutionTxHex": "020000000001012c32e55722e4b96324d8e5b398d583a20780b25202816adc32dc3157dee731c90300000000010000000176050000000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e05004730440220687af8544d335376620a6f4b5412bfd0da48de047c1785674f26e669d4a3ff82022058591c1e3a6c50017427d38a8f756eb685bdab88ec73838eed3530048861f9d5834730440220109f1a62b5a13d28d5b7634dd7693b1d5994eb404c4bb4a9a80aa540d3984d170220307251107ff8499a23e99abce7dda4f1c707c98abddb9405a83de0081cde8ace012004040404040404040404040404040404040404040404040404040404040404048d76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c8201208763a91418bc1a114ccf9c052d3d23e28d3b0a9d1227434288527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae677502f801b175ac6851b2756800000000"
}
],
"ExpectedCommitmentTxHex": "02000000000101bef67e4e2fb9ddeeb3461973cd4c62abb35050b1add772995b820b584a488489000000000038b02b80064a010000000000002200202b1b5854183c12d3316565972c4668929d314d81c5dcdbb21cb45fe8a9a8114f4a01000000000000220020e9e86e4823faa62e222ebc858a226636856158f07e69898da3b0d1af0ddb3994b80b000000000000220020f96d0334feb64a4f40eb272031d07afcb038db56aa57446d60308c9f8ccadef9a00f000000000000220020ce6e751274836ff59622a0d1e07f8831d80bd6730bd48581398bfadd2bb8da9ac0c62d0000000000220020f3394e1e619b0eca1f91be2fb5ab4dfc59ba5b84ebe014ad1d43a564d012994a29896a00000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e0400483045022100c268496aad5c3f97f25cf41c1ba5483a12982de29b222051b6de3daa2229413b02207f3c82d77a2c14f0096ed9bb4c34649483bb20fa71f819f71af44de6593e8bb2014730440220784485cf7a0ad7979daf2c858ffdaf5298d0020cea7aea466843e7948223bd9902206031b81d25e02a178c64e62f843577fdcdfc7a1decbbfb54cd895de692df85ca01475221023da092f6980e58d2c037173180e9a465476026ee50f96695963e8efe436f54eb21030e9f7b623d2ccc7c9bd44d66d5ce21ce504c0acf6385a132cec6d3c39fa711c152ae3e195220",
"RemoteSigHex": "30440220784485cf7a0ad7979daf2c858ffdaf5298d0020cea7aea466843e7948223bd9902206031b81d25e02a178c64e62f843577fdcdfc7a1decbbfb54cd895de692df85ca"
},
{
"Name": "commitment tx with three outputs untrimmed (minimum feerate)",
"LocalBalance": 6988000000,
"RemoteBalance": 3000000000,
"FeePerKw": 3687,
"UseTestHtlcs": true,
"HtlcDescs": [
{
"RemoteSigHex": "3045022100b287bb8e079a62dcb3aaa8b6c67c0f434a87ebf64ab0bcfb2fc14b55576b859f02206d37c2eb5fd04cfc9eb0534c76a28a98da251b84a931377cce307af39dfaed74",
"ResolutionTxHex": "02000000000101542562b326c08e3a076d9cfca2be175041366591da334d8d513ff1686fd95a600200000000010000000175050000000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e0500483045022100b287bb8e079a62dcb3aaa8b6c67c0f434a87ebf64ab0bcfb2fc14b55576b859f02206d37c2eb5fd04cfc9eb0534c76a28a98da251b84a931377cce307af39dfaed7483483045022100a497c64faea286ec4221f48628086dc6403fd7b60a23c4176e8ebbca15ae70dc0220754e20e968e96cf6421fd2a672c8c26d3bc6e19218cfc8fc2aa51fce026c14b1012004040404040404040404040404040404040404040404040404040404040404048d76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c8201208763a91418bc1a114ccf9c052d3d23e28d3b0a9d1227434288527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae677502f801b175ac6851b2756800000000"
}
],
"ExpectedCommitmentTxHex": "02000000000101bef67e4e2fb9ddeeb3461973cd4c62abb35050b1add772995b820b584a488489000000000038b02b80054a010000000000002200202b1b5854183c12d3316565972c4668929d314d81c5dcdbb21cb45fe8a9a8114f4a01000000000000220020e9e86e4823faa62e222ebc858a226636856158f07e69898da3b0d1af0ddb3994a00f000000000000220020ce6e751274836ff59622a0d1e07f8831d80bd6730bd48581398bfadd2bb8da9ac0c62d0000000000220020f3394e1e619b0eca1f91be2fb5ab4dfc59ba5b84ebe014ad1d43a564d012994aa28b6a00000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e0400483045022100c970799bcb33f43179eb43b3378a0a61991cf2923f69b36ef12548c3df0e6d500220413dc27d2e39ee583093adfcb7799be680141738babb31cc7b0669a777a31f5d01483045022100ad6c71569856b2d7ff42e838b4abe74a713426b37f22fa667a195a4c88908c6902202b37272b02a42dc6d9f4f82cab3eaf84ac882d9ed762859e1e75455c2c22837701475221023da092f6980e58d2c037173180e9a465476026ee50f96695963e8efe436f54eb21030e9f7b623d2ccc7c9bd44d66d5ce21ce504c0acf6385a132cec6d3c39fa711c152ae3e195220",
"RemoteSigHex": "3045022100ad6c71569856b2d7ff42e838b4abe74a713426b37f22fa667a195a4c88908c6902202b37272b02a42dc6d9f4f82cab3eaf84ac882d9ed762859e1e75455c2c228377"
},
{
"Name": "commitment tx with three outputs untrimmed (maximum feerate)",
"LocalBalance": 6988000000,
"RemoteBalance": 3000000000,
"FeePerKw": 4893,
"UseTestHtlcs": true,
"HtlcDescs": [
{
"RemoteSigHex": "30450221008db80f8531104820b3e894492b4463f074f965b542e1b5c153ddfb108a5ea642022030b203d857a2b3581c2087a7bf17c95d04fadc1c6cdae88c620477f2dccb1ee4",
"ResolutionTxHex": "02000000000101d515a15e9175fd315bb8d4e768f28684801a9e5a9acdfeba34f7b3b3b3a9ba1d0200000000010000000122020000000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e05004830450221008db80f8531104820b3e894492b4463f074f965b542e1b5c153ddfb108a5ea642022030b203d857a2b3581c2087a7bf17c95d04fadc1c6cdae88c620477f2dccb1ee483483045022100e5fbae857c47dbfc050a05924bd449fc9804798bd6442002c578437dc34450810220296589bc387645512345299e307116aaac4ce9fc752abcd1936b802d03526312012004040404040404040404040404040404040404040404040404040404040404048d76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c8201208763a91418bc1a114ccf9c052d3d23e28d3b0a9d1227434288527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae677502f801b175ac6851b2756800000000"
}
],
"ExpectedCommitmentTxHex": "02000000000101bef67e4e2fb9ddeeb3461973cd4c62abb35050b1add772995b820b584a488489000000000038b02b80054a010000000000002200202b1b5854183c12d3316565972c4668929d314d81c5dcdbb21cb45fe8a9a8114f4a01000000000000220020e9e86e4823faa62e222ebc858a226636856158f07e69898da3b0d1af0ddb3994a00f000000000000220020ce6e751274836ff59622a0d1e07f8831d80bd6730bd48581398bfadd2bb8da9ac0c62d0000000000220020f3394e1e619b0eca1f91be2fb5ab4dfc59ba5b84ebe014ad1d43a564d012994a87856a00000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e04004730440220086288faceab47461eb2d808e9e9b0cb3ffc24a03c2f18db7198247d38f10e58022031d1c2782a58c8c6ce187d0019eb47a83babdf3040e2caff299ab48f7e12b1fa01483045022100a8771147109e4d3f44a5976c3c3de98732bbb77308d21444dbe0d76faf06480e02200b4e916e850c3d1f918de87bbbbb07843ffea1d4658dfe060b6f9ccd96d34be801475221023da092f6980e58d2c037173180e9a465476026ee50f96695963e8efe436f54eb21030e9f7b623d2ccc7c9bd44d66d5ce21ce504c0acf6385a132cec6d3c39fa711c152ae3e195220",
"RemoteSigHex": "3045022100a8771147109e4d3f44a5976c3c3de98732bbb77308d21444dbe0d76faf06480e02200b4e916e850c3d1f918de87bbbbb07843ffea1d4658dfe060b6f9ccd96d34be8"
},
{
"Name": "commitment tx with two outputs untrimmed (minimum feerate)",
"LocalBalance": 6988000000,
"RemoteBalance": 3000000000,
"FeePerKw": 4894,
"UseTestHtlcs": true,
"HtlcDescs": [],
"ExpectedCommitmentTxHex": "02000000000101bef67e4e2fb9ddeeb3461973cd4c62abb35050b1add772995b820b584a488489000000000038b02b80044a010000000000002200202b1b5854183c12d3316565972c4668929d314d81c5dcdbb21cb45fe8a9a8114f4a01000000000000220020e9e86e4823faa62e222ebc858a226636856158f07e69898da3b0d1af0ddb3994c0c62d0000000000220020f3394e1e619b0eca1f91be2fb5ab4dfc59ba5b84ebe014ad1d43a564d012994ad0886a00000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e04004830450221009f16ac85d232e4eddb3fcd750a68ebf0b58e3356eaada45d3513ede7e817bf4c02207c2b043b4e5f971261975406cb955219fa56bffe5d834a833694b5abc1ce4cfd01483045022100e784a66b1588575801e237d35e510fd92a81ae3a4a2a1b90c031ad803d07b3f3022021bc5f16501f167607d63b681442da193eb0a76b4b7fd25c2ed4f8b28fd35b9501475221023da092f6980e58d2c037173180e9a465476026ee50f96695963e8efe436f54eb21030e9f7b623d2ccc7c9bd44d66d5ce21ce504c0acf6385a132cec6d3c39fa711c152ae3e195220",
"RemoteSigHex": "3045022100e784a66b1588575801e237d35e510fd92a81ae3a4a2a1b90c031ad803d07b3f3022021bc5f16501f167607d63b681442da193eb0a76b4b7fd25c2ed4f8b28fd35b95"
},
{
"Name": "commitment tx with one output untrimmed (minimum feerate)",
"LocalBalance": 6988000000,
"RemoteBalance": 3000000000,
"FeePerKw": 6216010,
"UseTestHtlcs": true,
"HtlcDescs": [],
"ExpectedCommitmentTxHex": "02000000000101bef67e4e2fb9ddeeb3461973cd4c62abb35050b1add772995b820b584a488489000000000038b02b80024a01000000000000220020e9e86e4823faa62e222ebc858a226636856158f07e69898da3b0d1af0ddb3994c0c62d0000000000220020f3394e1e619b0eca1f91be2fb5ab4dfc59ba5b84ebe014ad1d43a564d012994a04004830450221009ad80792e3038fe6968d12ff23e6888a565c3ddd065037f357445f01675d63f3022018384915e5f1f4ae157e15debf4f49b61c8d9d2b073c7d6f97c4a68caa3ed4c1014830450221008fd5dbff02e4b59020d4cd23a3c30d3e287065fda75a0a09b402980adf68ccda022001e0b8b620cd915ddff11f1de32addf23d81d51b90e6841b2cb8dcaf3faa5ecf01475221023da092f6980e58d2c037173180e9a465476026ee50f96695963e8efe436f54eb21030e9f7b623d2ccc7c9bd44d66d5ce21ce504c0acf6385a132cec6d3c39fa711c152ae3e195220",
"RemoteSigHex": "30450221008fd5dbff02e4b59020d4cd23a3c30d3e287065fda75a0a09b402980adf68ccda022001e0b8b620cd915ddff11f1de32addf23d81d51b90e6841b2cb8dcaf3faa5ecf"
BOLT 3: add test vectors for htlc-transactions in case where CLTV is used as tie-breaker for sorting (#539) Add a serialized transactions test vector for the edge case of sorting htlc-timeout-tx when there are multiple offered htlc with the same amount and preimage. The test vector reuses previous preimages and creates a case scenario with 1 received htlc and 2 offered, the two offered will have same scriptPubKey and redeemScript, but different CLTV value. It is asserted the order in which the htlc transactions should be kept internally and we assume the same order is used to construct the commitment_signed message. This complements #491 .
2021-03-05 09:10:26 +01:00
},
{
"Name": "commitment tx with 3 htlc outputs, 2 offered having the same amount and preimage",
"LocalBalance": 6988000000,
"RemoteBalance": 3000000000,
"FeePerKw": 253,
"UseTestHtlcs": true,
"HtlcDescs": [
{
"RemoteSigHex": "304402202060a5acb12105e92f27d7b86e6caf1e003d9d82068338e5a8a9a0d14cba11260220030ca4dba8fad24a2e395906220c991eccd5369bc4b0f216d217b5f86d1fc61d",
"ResolutionTxHex": "02000000000101aa443fb63abc1e8c754f98a7b96c27cb02b21d891d1242a16b630dc32c2afe29020000000001000000011e070000000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e050047304402202060a5acb12105e92f27d7b86e6caf1e003d9d82068338e5a8a9a0d14cba11260220030ca4dba8fad24a2e395906220c991eccd5369bc4b0f216d217b5f86d1fc61d83473044022044f5425fe630fa614f349f55642e4a0b76e2583054b21543821660d9e8f3735702207f70424835b541874ca8bf0443cca4028afa2f6c03a17b0688df85d5c44eeefc012001010101010101010101010101010101010101010101010101010101010101018d76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c8201208763a9144b6b2e5444c2639cc0fb7bcea5afba3f3cdce23988527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae677502f501b175ac6851b2756800000000"
},
{
"RemoteSigHex": "304402206fde7eb6d7a47fdc63705d3db2169054e229f10342dea66f150b163381f48a0802201be28509c2de9be4b7ab72c569c6fd51c0ce0904fea459142f31d442cd043eb8",
"ResolutionTxHex": "02000000000101aa443fb63abc1e8c754f98a7b96c27cb02b21d891d1242a16b630dc32c2afe2903000000000100000001e0120000000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e050047304402206fde7eb6d7a47fdc63705d3db2169054e229f10342dea66f150b163381f48a0802201be28509c2de9be4b7ab72c569c6fd51c0ce0904fea459142f31d442cd043eb883483045022100ad0236a78dbd029d3a8f583f7f82ee62892273d45303d00ef5a03fecf8903a36022004b2db33f8ff2f4a08ca6127c9cbfd9144c691a2feb9287e36ae6bc7c83c5a5f01008876a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c820120876475527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae67a9142002cc93ebefbb1b73f0af055dcc27a0b504ad7688ac6851b27568f9010000"
},
{
"RemoteSigHex": "304402205eebc78d8ae6a36c27ef80172359eb757fb18e99fa75b28c37ffe3444b967bc7022060a01c33398d4d8244c42c762fb699e9f61c1f034ff976df2c94350c5a6032a7",
"ResolutionTxHex": "02000000000101aa443fb63abc1e8c754f98a7b96c27cb02b21d891d1242a16b630dc32c2afe2904000000000100000001e0120000000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e050047304402205eebc78d8ae6a36c27ef80172359eb757fb18e99fa75b28c37ffe3444b967bc7022060a01c33398d4d8244c42c762fb699e9f61c1f034ff976df2c94350c5a6032a783483045022100ad3fd523594e1b876316401774a30ee6c48bb7fa0efd768bf9a2d022201311ff02207bed627ed8e01041137f03dbaf03c836970be27a4d50f69d90cf1282ff2815e301008876a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c820120876475527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae67a9142002cc93ebefbb1b73f0af055dcc27a0b504ad7688ac6851b27568fa010000"
}
],
"ExpectedCommitmentTxHex": "02000000000101bef67e4e2fb9ddeeb3461973cd4c62abb35050b1add772995b820b584a488489000000000038b02b80074a010000000000002200202b1b5854183c12d3316565972c4668929d314d81c5dcdbb21cb45fe8a9a8114f4a01000000000000220020e9e86e4823faa62e222ebc858a226636856158f07e69898da3b0d1af0ddb3994d007000000000000220020fe0598d74fee2205cc3672e6e6647706b4f3099713b4661b62482c3addd04a5e881300000000000022002018e40f9072c44350f134bdc887bab4d9bdfc8aa468a25616c80e21757ba5dac7881300000000000022002018e40f9072c44350f134bdc887bab4d9bdfc8aa468a25616c80e21757ba5dac7c0c62d0000000000220020f3394e1e619b0eca1f91be2fb5ab4dfc59ba5b84ebe014ad1d43a564d012994aae9c6a00000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e0400483045022100c37ac4fc8538677631230c4b286f36b6f54c51fb4b34ef0bd0ba219ba47452630220278e09a745454ea380f3694392ed113762c68dd209b48360f547541088be9e4501483045022100c592f6b80d35b4f5d1e3bc9788f51141a0065be6013bad53a1977f7c444651660220278ac06ead9016bfb8dc476f186eabace2b02793b2f308442f5b0d5f24a6894801475221023da092f6980e58d2c037173180e9a465476026ee50f96695963e8efe436f54eb21030e9f7b623d2ccc7c9bd44d66d5ce21ce504c0acf6385a132cec6d3c39fa711c152ae3e195220",
"RemoteSigHex": "3045022100c592f6b80d35b4f5d1e3bc9788f51141a0065be6013bad53a1977f7c444651660220278ac06ead9016bfb8dc476f186eabace2b02793b2f308442f5b0d5f24a68948"
Anchor outputs This commit extends the specification with a new commitment format that adds two anchor outputs to the commitment transaction. Anchor outputs are a safety feature that allows a channel party to unilaterally increase the fee of the commitment transaction using CPFP and ensure timely confirmation on the chain. There is no cooperation required from the remote party.
2020-08-19 12:29:11 +02:00
}
]
```
Add test vectors for option_anchors_zero_fee_htlc_tx (#1018) These are the same test vectors as those found under Appendix F, except that each HTLC has a zero fee transaction instead, resulting in a signature change.
2023-02-28 09:30:50 +01:00
# Appendix G: Commitment and HTLC Transaction Test Vectors (anchors_zero_fee_htlc_tx)
The anchor test vectors are based on the test cases as defined in appendix C.
Note that in appendix C, `to_local_msat` and `to_remote_msat` are balances
before subtraction of:
* Commit fee (funder only)
* Anchor outputs (funder only)
* In-flight htlcs
```yaml
[
{
"Name": "simple commitment tx with no HTLCs",
"LocalBalance": 7000000000,
"RemoteBalance": 3000000000,
"DustLimitSatoshis": 546,
"FeePerKw": 15000,
"UseTestHtlcs": false,
"HtlcDescs": [],
"ExpectedCommitmentTxHex": "02000000000101bef67e4e2fb9ddeeb3461973cd4c62abb35050b1add772995b820b584a488489000000000038b02b80044a010000000000002200202b1b5854183c12d3316565972c4668929d314d81c5dcdbb21cb45fe8a9a8114f4a01000000000000220020e9e86e4823faa62e222ebc858a226636856158f07e69898da3b0d1af0ddb3994c0c62d0000000000220020f3394e1e619b0eca1f91be2fb5ab4dfc59ba5b84ebe014ad1d43a564d012994a508b6a00000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e04004830450221008266ac6db5ea71aac3c95d97b0e172ff596844851a3216eb88382a8dddfd33d2022050e240974cfd5d708708b4365574517c18e7ae535ef732a3484d43d0d82be9f701483045022100f89034eba16b2be0e5581f750a0a6309192b75cce0f202f0ee2b4ec0cc394850022076c65dc507fe42276152b7a3d90e961e678adbe966e916ecfe85e64d430e75f301475221023da092f6980e58d2c037173180e9a465476026ee50f96695963e8efe436f54eb21030e9f7b623d2ccc7c9bd44d66d5ce21ce504c0acf6385a132cec6d3c39fa711c152ae3e195220",
"RemoteSigHex": "3045022100f89034eba16b2be0e5581f750a0a6309192b75cce0f202f0ee2b4ec0cc394850022076c65dc507fe42276152b7a3d90e961e678adbe966e916ecfe85e64d430e75f3"
},
{
"Name": "simple commitment tx with no HTLCs and single anchor",
"LocalBalance": 10000000000,
"RemoteBalance": 0,
"DustLimitSatoshis": 546,
"FeePerKw": 15000,
"UseTestHtlcs": false,
"HtlcDescs": [],
"ExpectedCommitmentTxHex": "02000000000101bef67e4e2fb9ddeeb3461973cd4c62abb35050b1add772995b820b584a488489000000000038b02b80024a010000000000002200202b1b5854183c12d3316565972c4668929d314d81c5dcdbb21cb45fe8a9a8114f10529800000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e0400473044022007cf6b405e9c9b4f527b0ecad9d8bb661fabb8b12abf7d1c0b3ad1855db3ed490220616d5c1eeadccc63bd775a131149455d62d95a42c2a1b01cc7821fc42dce7778014730440220655bf909fb6fa81d086f1336ac72c97906dce29d1b166e305c99152d810e26e1022051f577faa46412c46707aaac46b65d50053550a66334e00a44af2706f27a865801475221023da092f6980e58d2c037173180e9a465476026ee50f96695963e8efe436f54eb21030e9f7b623d2ccc7c9bd44d66d5ce21ce504c0acf6385a132cec6d3c39fa711c152ae3e195220",
"RemoteSigHex": "30440220655bf909fb6fa81d086f1336ac72c97906dce29d1b166e305c99152d810e26e1022051f577faa46412c46707aaac46b65d50053550a66334e00a44af2706f27a8658"
},
{
"Name": "commitment tx with seven outputs untrimmed",
"LocalBalance": 6988000000,
"RemoteBalance": 3000000000,
"DustLimitSatoshis": 546,
"FeePerKw": 644,
"UseTestHtlcs": true,
"HtlcDescs": [
{
"RemoteSigHex": "30440220746dc89a593e1b50915db63359b50c3c404f8324f78075c87708c866ccefda2502202a11062012dc8607b17e8c46ea4eefdfcc6b89a35440de99432ba12788d7bb17",
"ResolutionTxHex": "02000000000101b8cefef62ea66f5178b9361b2371be0759cbc8c689bcfa7a8e6746d497ec221a02000000000100000001e8030000000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e05004730440220746dc89a593e1b50915db63359b50c3c404f8324f78075c87708c866ccefda2502202a11062012dc8607b17e8c46ea4eefdfcc6b89a35440de99432ba12788d7bb1783473044022036f77f88b49bd03dc16d3a015efcc7acffc2a93b213324035d77a716f79013ff02203c218eb882a40402a8bb05dbb751a442345a4e56307be76b214b6d4db9ed3c92012000000000000000000000000000000000000000000000000000000000000000008d76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c8201208763a914b8bcb07f6344b42ab04250c86a6e8b75d3fdbbc688527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae677502f401b175ac6851b2756800000000"
},
{
"RemoteSigHex": "3045022100a847bc3b8cf2441013725ae32dc589c419835d069afd6d7f3d9834d8be7cea6e02204ce9d35ec7f0788da80e4d62e810c4ccd13617e58fa10832e38fb7ae87bdf338",
"ResolutionTxHex": "02000000000101b8cefef62ea66f5178b9361b2371be0759cbc8c689bcfa7a8e6746d497ec221a03000000000100000001d0070000000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e0500483045022100a847bc3b8cf2441013725ae32dc589c419835d069afd6d7f3d9834d8be7cea6e02204ce9d35ec7f0788da80e4d62e810c4ccd13617e58fa10832e38fb7ae87bdf33883473044022026739b1adbfa34c485bf0e5a19e0cf7532f64545bcc5c95b95643ccc2d351e1902201743bb1b34f00e031cc15f6eff0f8ab764508d2681ff965ba62e76e540bca1e801008876a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c820120876475527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae67a914b43e1b38138a41b37f7cd9a1d274bc63e3a9b5d188ac6851b27568f6010000"
},
{
"RemoteSigHex": "3044022035977f2aa6d6ae12f1dae3366440faa17558e9c88c3188bfc8df7e276c6c65410220659f1f9070c725d9d46e43b99a36fc6d711d36069704add2d57fc1fa2818cf12",
"ResolutionTxHex": "02000000000101b8cefef62ea66f5178b9361b2371be0759cbc8c689bcfa7a8e6746d497ec221a04000000000100000001d0070000000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e0500473044022035977f2aa6d6ae12f1dae3366440faa17558e9c88c3188bfc8df7e276c6c65410220659f1f9070c725d9d46e43b99a36fc6d711d36069704add2d57fc1fa2818cf12834730440220191ba44e57b1601a59d99f85971d4801b286d428de275487c87ceeb8df1a4811022002215875d92833df0c9615c9096cf97152f87139ed9f82718bbb5b8b3d312524012001010101010101010101010101010101010101010101010101010101010101018d76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c8201208763a9144b6b2e5444c2639cc0fb7bcea5afba3f3cdce23988527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae677502f501b175ac6851b2756800000000"
},
{
"RemoteSigHex": "3044022002f3ff9a31270092c214d3d5b8b4f826599404bba64b87f7536ef6324d41551b022079dc4cb25f7ecd84b49f5cce03eae7e2655b59f39d543765daef0d4f11c93fa2",
"ResolutionTxHex": "02000000000101b8cefef62ea66f5178b9361b2371be0759cbc8c689bcfa7a8e6746d497ec221a05000000000100000001b80b0000000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e0500473044022002f3ff9a31270092c214d3d5b8b4f826599404bba64b87f7536ef6324d41551b022079dc4cb25f7ecd84b49f5cce03eae7e2655b59f39d543765daef0d4f11c93fa283483045022100f03047e38bc0aae2d80d53424b8c1d1b8139120e2bf09ad31a2803978745e6e102205b74c0eef0b472710b98c77e619ee9d0cc47a9dd786f4f214a564f44d79f9b9a01008876a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c820120876475527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae67a9148a486ff2e31d6158bf39e2608864d63fefd09d5b88ac6851b27568f7010000"
},
{
"RemoteSigHex": "30440220547937564288f64fb3e3c945a1348b912471f0c1c4cc7dc8ceca15a4cbd299b6022053c4f8e30832b13dfbe31e4091e313428625e0b5ac61eecba93f8f11c1e26225",
"ResolutionTxHex": "02000000000101b8cefef62ea66f5178b9361b2371be0759cbc8c689bcfa7a8e6746d497ec221a06000000000100000001a00f0000000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e05004730440220547937564288f64fb3e3c945a1348b912471f0c1c4cc7dc8ceca15a4cbd299b6022053c4f8e30832b13dfbe31e4091e313428625e0b5ac61eecba93f8f11c1e2622583473044022022604660234aef9bd21284598ec50f070ac82a3a0152e0af5e98a02cd6e8976f022042b0b9112ee00806b856dff6de52a82c98b036a4fe14bb5fd2926725e2fc8191012004040404040404040404040404040404040404040404040404040404040404048d76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c8201208763a91418bc1a114ccf9c052d3d23e28d3b0a9d1227434288527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae677502f801b175ac6851b2756800000000"
}
],
"ExpectedCommitmentTxHex": "02000000000101bef67e4e2fb9ddeeb3461973cd4c62abb35050b1add772995b820b584a488489000000000038b02b80094a010000000000002200202b1b5854183c12d3316565972c4668929d314d81c5dcdbb21cb45fe8a9a8114f4a01000000000000220020e9e86e4823faa62e222ebc858a226636856158f07e69898da3b0d1af0ddb3994e80300000000000022002010f88bf09e56f14fb4543fd26e47b0db50ea5de9cf3fc46434792471082621aed0070000000000002200203e68115ae0b15b8de75b6c6bc9af5ac9f01391544e0870dae443a1e8fe7837ead007000000000000220020fe0598d74fee2205cc3672e6e6647706b4f3099713b4661b62482c3addd04a5eb80b000000000000220020f96d0334feb64a4f40eb272031d07afcb038db56aa57446d60308c9f8ccadef9a00f000000000000220020ce6e751274836ff59622a0d1e07f8831d80bd6730bd48581398bfadd2bb8da9ac0c62d0000000000220020f3394e1e619b0eca1f91be2fb5ab4dfc59ba5b84ebe014ad1d43a564d012994a4f996a00000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e0400483045022100ef82a405364bfc4007e63a7cc82925a513d79065bdbc216d60b6a4223a323f8a02200716730b8561f3c6d362eaf47f202e99fb30d0557b61b92b5f9134f8e2de368101483045022100e0106830467a558c07544a3de7715610c1147062e7d091deeebe8b5c661cda9402202ad049c1a6d04834317a78483f723c205c9f638d17222aafc620800cc1b6ae3501475221023da092f6980e58d2c037173180e9a465476026ee50f96695963e8efe436f54eb21030e9f7b623d2ccc7c9bd44d66d5ce21ce504c0acf6385a132cec6d3c39fa711c152ae3e195220",
"RemoteSigHex": "3045022100e0106830467a558c07544a3de7715610c1147062e7d091deeebe8b5c661cda9402202ad049c1a6d04834317a78483f723c205c9f638d17222aafc620800cc1b6ae35"
},
{
"Name": "commitment tx with six outputs untrimmed (minimum dust limit)",
"LocalBalance": 6988000000,
"RemoteBalance": 3000000000,
"DustLimitSatoshis": 1001,
"FeePerKw": 645,
"UseTestHtlcs": true,
"HtlcDescs": [
{
"RemoteSigHex": "3045022100e04d160a326432659fe9fb127304c1d348dfeaba840081bdc57d8efd902a48d8022008a824e7cf5492b97e4d9e03c06a09f822775a44f6b5b2533a2088904abfc282",
"ResolutionTxHex": "02000000000101104f394af4c4fad78337f95e3e9f802f4c0d86ab231853af09b285348561320002000000000100000001d0070000000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e0500483045022100e04d160a326432659fe9fb127304c1d348dfeaba840081bdc57d8efd902a48d8022008a824e7cf5492b97e4d9e03c06a09f822775a44f6b5b2533a2088904abfc28283483045022100b7c49846466b13b190ff739bbe3005c105482fc55539e55b1c561f76b6982b6c02200e5c35808619cf543c8405cff9fedd25f333a4a2f6f6d5e8af8150090c40ef0901008876a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c820120876475527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae67a914b43e1b38138a41b37f7cd9a1d274bc63e3a9b5d188ac6851b27568f6010000"
},
{
"RemoteSigHex": "3045022100fbdc3c367ce3bf30796025cc590ee1f2ce0e72ae1ac19f5986d6d0a4fc76211f02207e45ae9267e8e820d188569604f71d1abd11bd385d58853dd7dc034cdb3e9a6e",
"ResolutionTxHex": "02000000000101104f394af4c4fad78337f95e3e9f802f4c0d86ab231853af09b285348561320003000000000100000001d0070000000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e0500483045022100fbdc3c367ce3bf30796025cc590ee1f2ce0e72ae1ac19f5986d6d0a4fc76211f02207e45ae9267e8e820d188569604f71d1abd11bd385d58853dd7dc034cdb3e9a6e83483045022100d29330f24db213b262068706099b39c15fa7e070c3fcdf8836c09723fc4d365602203ce57d01e9f28601e461a0b5c4a50119b270bde8b70148d133a6849c70b115ac012001010101010101010101010101010101010101010101010101010101010101018d76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c8201208763a9144b6b2e5444c2639cc0fb7bcea5afba3f3cdce23988527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae677502f501b175ac6851b2756800000000"
},
{
"RemoteSigHex": "3044022066c5ef625cee3ddd2bc7b6bfb354b5834cf1cc6d52dd972fb41b7b225437ae4a022066cb85647df65c6b87a54e416dcdcca778a776c36a9643d2b5dc793c9b29f4c1",
"ResolutionTxHex": "02000000000101104f394af4c4fad78337f95e3e9f802f4c0d86ab231853af09b285348561320004000000000100000001b80b0000000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e0500473044022066c5ef625cee3ddd2bc7b6bfb354b5834cf1cc6d52dd972fb41b7b225437ae4a022066cb85647df65c6b87a54e416dcdcca778a776c36a9643d2b5dc793c9b29f4c18347304402202d4ce515cd9000ec37575972d70b8d24f73909fb7012e8ebd8c2066ef6fe187902202830b53e64ea565fecd0f398100691da6bb2a5cf9bb0d1926f1d71d05828a11e01008876a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c820120876475527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae67a9148a486ff2e31d6158bf39e2608864d63fefd09d5b88ac6851b27568f7010000"
},
{
"RemoteSigHex": "3044022022c7e11595c53ee89a57ca76baf0aed730da035952d6ab3fe6459f5eff3b337a022075e10cc5f5fd724a35ce4087a5d03cd616698626c69814032132b50bb97dc615",
"ResolutionTxHex": "02000000000101104f394af4c4fad78337f95e3e9f802f4c0d86ab231853af09b285348561320005000000000100000001a00f0000000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e0500473044022022c7e11595c53ee89a57ca76baf0aed730da035952d6ab3fe6459f5eff3b337a022075e10cc5f5fd724a35ce4087a5d03cd616698626c69814032132b50bb97dc61583483045022100b20cd63e0587d1711beaebda4730775c4ac8b8b2ec78fe18a0c44c3f168c25230220079abb7fc4924e2fca5950842e5b9e416735585026914570078c4ef62f286226012004040404040404040404040404040404040404040404040404040404040404048d76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c8201208763a91418bc1a114ccf9c052d3d23e28d3b0a9d1227434288527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae677502f801b175ac6851b2756800000000"
}
],
"ExpectedCommitmentTxHex": "02000000000101bef67e4e2fb9ddeeb3461973cd4c62abb35050b1add772995b820b584a488489000000000038b02b80084a010000000000002200202b1b5854183c12d3316565972c4668929d314d81c5dcdbb21cb45fe8a9a8114f4a01000000000000220020e9e86e4823faa62e222ebc858a226636856158f07e69898da3b0d1af0ddb3994d0070000000000002200203e68115ae0b15b8de75b6c6bc9af5ac9f01391544e0870dae443a1e8fe7837ead007000000000000220020fe0598d74fee2205cc3672e6e6647706b4f3099713b4661b62482c3addd04a5eb80b000000000000220020f96d0334feb64a4f40eb272031d07afcb038db56aa57446d60308c9f8ccadef9a00f000000000000220020ce6e751274836ff59622a0d1e07f8831d80bd6730bd48581398bfadd2bb8da9ac0c62d0000000000220020f3394e1e619b0eca1f91be2fb5ab4dfc59ba5b84ebe014ad1d43a564d012994abc996a00000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e0400483045022100d57697c707b6f6d053febf24b98e8989f186eea42e37e9e91663ec2c70bb8f70022079b0715a472118f262f43016a674f59c015d9cafccec885968e76d9d9c5d005101473044022025d97466c8049e955a5afce28e322f4b34d2561118e52332fb400f9b908cc0a402205dc6fba3a0d67ee142c428c535580cd1f2ff42e2f89b47e0c8a01847caffc31201475221023da092f6980e58d2c037173180e9a465476026ee50f96695963e8efe436f54eb21030e9f7b623d2ccc7c9bd44d66d5ce21ce504c0acf6385a132cec6d3c39fa711c152ae3e195220",
"RemoteSigHex": "3044022025d97466c8049e955a5afce28e322f4b34d2561118e52332fb400f9b908cc0a402205dc6fba3a0d67ee142c428c535580cd1f2ff42e2f89b47e0c8a01847caffc312"
},
{
"Name": "commitment tx with four outputs untrimmed (minimum dust limit)",
"LocalBalance": 6988000000,
"RemoteBalance": 3000000000,
"DustLimitSatoshis": 2001,
"FeePerKw": 2185,
"UseTestHtlcs": true,
"HtlcDescs": [
{
"RemoteSigHex": "304402206870514a72ad6e723ff7f1e0370d7a33c1cd2a0b9272674143ebaf6a1d02dee102205bd953c34faf5e7322e9a1c0103581cb090280fda4f1039ee8552668afa90ebb",
"ResolutionTxHex": "02000000000101ac13a7715f80b8e52dda43c6929cade5521bdced3a405da02b443f1ffb1e33cc02000000000100000001b80b0000000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e050047304402206870514a72ad6e723ff7f1e0370d7a33c1cd2a0b9272674143ebaf6a1d02dee102205bd953c34faf5e7322e9a1c0103581cb090280fda4f1039ee8552668afa90ebb834730440220669de9ca7910eff65a7773ebd14a9fc371fe88cde5b8e2a81609d85c87ac939b02201ac29472fa4067322e92d75b624942d60be5050139b20bb363db75be79eb946f01008876a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c820120876475527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae67a9148a486ff2e31d6158bf39e2608864d63fefd09d5b88ac6851b27568f7010000"
},
{
"RemoteSigHex": "3045022100949e8dd938da56445b1cdfdebe1b7efea086edd05d89910d205a1e2e033ce47102202cbd68b5262ab144d9ec12653f87dfb0bb6bd05d1f58ae1e523f028eaefd7271",
"ResolutionTxHex": "02000000000101ac13a7715f80b8e52dda43c6929cade5521bdced3a405da02b443f1ffb1e33cc03000000000100000001a00f0000000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e0500483045022100949e8dd938da56445b1cdfdebe1b7efea086edd05d89910d205a1e2e033ce47102202cbd68b5262ab144d9ec12653f87dfb0bb6bd05d1f58ae1e523f028eaefd727183483045022100e3104ed8b239f8019e5f0a1a73d7782a94a8c36e7984f476c3a0b3cb0e62e27902207e3d52884600985f8a2098e53a5c30dd6a5e857733acfaa07ab2162421ed2688012004040404040404040404040404040404040404040404040404040404040404048d76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c8201208763a91418bc1a114ccf9c052d3d23e28d3b0a9d1227434288527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae677502f801b175ac6851b2756800000000"
}
],
"ExpectedCommitmentTxHex": "02000000000101bef67e4e2fb9ddeeb3461973cd4c62abb35050b1add772995b820b584a488489000000000038b02b80064a010000000000002200202b1b5854183c12d3316565972c4668929d314d81c5dcdbb21cb45fe8a9a8114f4a01000000000000220020e9e86e4823faa62e222ebc858a226636856158f07e69898da3b0d1af0ddb3994b80b000000000000220020f96d0334feb64a4f40eb272031d07afcb038db56aa57446d60308c9f8ccadef9a00f000000000000220020ce6e751274836ff59622a0d1e07f8831d80bd6730bd48581398bfadd2bb8da9ac0c62d0000000000220020f3394e1e619b0eca1f91be2fb5ab4dfc59ba5b84ebe014ad1d43a564d012994ac5916a00000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e0400483045022100cd8479cfe1edb1e5a1d487391e0451a469c7171e51e680183f19eb4321f20e9b02204eab7d5a6384b1b08e03baa6e4d9748dfd2b5ab2bae7e39604a0d0055bbffdd501473044022040f63a16148cf35c8d3d41827f5ae7f7c3746885bb64d4d1b895892a83812b3e02202fcf95c2bf02c466163b3fa3ced6a24926fbb4035095a96842ef516e86ba54c001475221023da092f6980e58d2c037173180e9a465476026ee50f96695963e8efe436f54eb21030e9f7b623d2ccc7c9bd44d66d5ce21ce504c0acf6385a132cec6d3c39fa711c152ae3e195220",
"RemoteSigHex": "3044022040f63a16148cf35c8d3d41827f5ae7f7c3746885bb64d4d1b895892a83812b3e02202fcf95c2bf02c466163b3fa3ced6a24926fbb4035095a96842ef516e86ba54c0"
},
{
"Name": "commitment tx with three outputs untrimmed (minimum dust limit)",
"LocalBalance": 6988000000,
"RemoteBalance": 3000000000,
"DustLimitSatoshis": 3001,
"FeePerKw": 3687,
"UseTestHtlcs": true,
"HtlcDescs": [
{
"RemoteSigHex": "3044022017b558a3cf5f0cb94269e2e927b29ed22bd2416abb8a7ce6de4d1256f359b93602202e9ca2b1a23ea3e69f433c704e327739e219804b8c188b1d52f74fd5a9de954c",
"ResolutionTxHex": "02000000000101542562b326c08e3a076d9cfca2be175041366591da334d8d513ff1686fd95a6002000000000100000001a00f0000000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e0500473044022017b558a3cf5f0cb94269e2e927b29ed22bd2416abb8a7ce6de4d1256f359b93602202e9ca2b1a23ea3e69f433c704e327739e219804b8c188b1d52f74fd5a9de954c83483045022100af7a8b7c7ff2080c68995254cb66d64d9954edcc5baac3bb4f27ed2d29aaa6120220421c27da7a60574a9263f271e0f3bd34594ec6011095190022b3b54596ea03de012004040404040404040404040404040404040404040404040404040404040404048d76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c8201208763a91418bc1a114ccf9c052d3d23e28d3b0a9d1227434288527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae677502f801b175ac6851b2756800000000"
}
],
"ExpectedCommitmentTxHex": "02000000000101bef67e4e2fb9ddeeb3461973cd4c62abb35050b1add772995b820b584a488489000000000038b02b80054a010000000000002200202b1b5854183c12d3316565972c4668929d314d81c5dcdbb21cb45fe8a9a8114f4a01000000000000220020e9e86e4823faa62e222ebc858a226636856158f07e69898da3b0d1af0ddb3994a00f000000000000220020ce6e751274836ff59622a0d1e07f8831d80bd6730bd48581398bfadd2bb8da9ac0c62d0000000000220020f3394e1e619b0eca1f91be2fb5ab4dfc59ba5b84ebe014ad1d43a564d012994aa28b6a00000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e0400483045022100c970799bcb33f43179eb43b3378a0a61991cf2923f69b36ef12548c3df0e6d500220413dc27d2e39ee583093adfcb7799be680141738babb31cc7b0669a777a31f5d01483045022100ad6c71569856b2d7ff42e838b4abe74a713426b37f22fa667a195a4c88908c6902202b37272b02a42dc6d9f4f82cab3eaf84ac882d9ed762859e1e75455c2c22837701475221023da092f6980e58d2c037173180e9a465476026ee50f96695963e8efe436f54eb21030e9f7b623d2ccc7c9bd44d66d5ce21ce504c0acf6385a132cec6d3c39fa711c152ae3e195220",
"RemoteSigHex": "3045022100ad6c71569856b2d7ff42e838b4abe74a713426b37f22fa667a195a4c88908c6902202b37272b02a42dc6d9f4f82cab3eaf84ac882d9ed762859e1e75455c2c228377"
},
{
"Name": "commitment tx with two outputs untrimmed (minimum dust limit)",
"LocalBalance": 6988000000,
"RemoteBalance": 3000000000,
"DustLimitSatoshis": 4001,
"FeePerKw": 4894,
"UseTestHtlcs": true,
"HtlcDescs": [],
"ExpectedCommitmentTxHex": "02000000000101bef67e4e2fb9ddeeb3461973cd4c62abb35050b1add772995b820b584a488489000000000038b02b80044a010000000000002200202b1b5854183c12d3316565972c4668929d314d81c5dcdbb21cb45fe8a9a8114f4a01000000000000220020e9e86e4823faa62e222ebc858a226636856158f07e69898da3b0d1af0ddb3994c0c62d0000000000220020f3394e1e619b0eca1f91be2fb5ab4dfc59ba5b84ebe014ad1d43a564d012994ad0886a00000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e04004830450221009f16ac85d232e4eddb3fcd750a68ebf0b58e3356eaada45d3513ede7e817bf4c02207c2b043b4e5f971261975406cb955219fa56bffe5d834a833694b5abc1ce4cfd01483045022100e784a66b1588575801e237d35e510fd92a81ae3a4a2a1b90c031ad803d07b3f3022021bc5f16501f167607d63b681442da193eb0a76b4b7fd25c2ed4f8b28fd35b9501475221023da092f6980e58d2c037173180e9a465476026ee50f96695963e8efe436f54eb21030e9f7b623d2ccc7c9bd44d66d5ce21ce504c0acf6385a132cec6d3c39fa711c152ae3e195220",
"RemoteSigHex": "3045022100e784a66b1588575801e237d35e510fd92a81ae3a4a2a1b90c031ad803d07b3f3022021bc5f16501f167607d63b681442da193eb0a76b4b7fd25c2ed4f8b28fd35b95"
},
{
"Name": "commitment tx with one output untrimmed (minimum dust limit)",
"LocalBalance": 6988000000,
"RemoteBalance": 3000000000,
"DustLimitSatoshis": 4001,
"FeePerKw": 6216010,
"UseTestHtlcs": true,
"HtlcDescs": [],
"ExpectedCommitmentTxHex": "02000000000101bef67e4e2fb9ddeeb3461973cd4c62abb35050b1add772995b820b584a488489000000000038b02b80024a01000000000000220020e9e86e4823faa62e222ebc858a226636856158f07e69898da3b0d1af0ddb3994c0c62d0000000000220020f3394e1e619b0eca1f91be2fb5ab4dfc59ba5b84ebe014ad1d43a564d012994a04004830450221009ad80792e3038fe6968d12ff23e6888a565c3ddd065037f357445f01675d63f3022018384915e5f1f4ae157e15debf4f49b61c8d9d2b073c7d6f97c4a68caa3ed4c1014830450221008fd5dbff02e4b59020d4cd23a3c30d3e287065fda75a0a09b402980adf68ccda022001e0b8b620cd915ddff11f1de32addf23d81d51b90e6841b2cb8dcaf3faa5ecf01475221023da092f6980e58d2c037173180e9a465476026ee50f96695963e8efe436f54eb21030e9f7b623d2ccc7c9bd44d66d5ce21ce504c0acf6385a132cec6d3c39fa711c152ae3e195220",
"RemoteSigHex": "30450221008fd5dbff02e4b59020d4cd23a3c30d3e287065fda75a0a09b402980adf68ccda022001e0b8b620cd915ddff11f1de32addf23d81d51b90e6841b2cb8dcaf3faa5ecf"
},
{
"Name": "commitment tx with 3 htlc outputs, 2 offered having the same amount and preimage",
"LocalBalance": 6987999999,
"RemoteBalance": 3000000000,
"DustLimitSatoshis": 546,
"FeePerKw": 253,
"UseTestHtlcs": true,
"HtlcDescs": [
{
"RemoteSigHex": "30440220078fe5343dab88c348a3a8a9c1a9293259dbf35507ae971702cc39dd623ea9af022011ed0c0f35243cd0bb4d9ca3c772379b2b5f4af93140e9fdc5600dfec1cdb0c2",
"ResolutionTxHex": "020000000001013d060d0305c9616eaabc21d41fae85bcb5477b5d7f1c92aa429cf15339bbe1c402000000000100000001d0070000000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e05004730440220078fe5343dab88c348a3a8a9c1a9293259dbf35507ae971702cc39dd623ea9af022011ed0c0f35243cd0bb4d9ca3c772379b2b5f4af93140e9fdc5600dfec1cdb0c28347304402205df665e2908c7690d2d33eb70e6e119958c28febe141a94ed0dd9a55ce7c8cfc0220364d02663a5d019af35c5cd5fda9465d985d85bbd12db207738d61163449a424012001010101010101010101010101010101010101010101010101010101010101018d76a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c8201208763a9144b6b2e5444c2639cc0fb7bcea5afba3f3cdce23988527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae677502f501b175ac6851b2756800000000"
},
{
"RemoteSigHex": "304402202df6bf0f98a42cfd0172a16bded7d1b16c14f5f42ba23f5c54648c14b647531302200fe1508626817f23925bb56951d5e4b2654c751743ab6db48a6cce7dda17c01c",
"ResolutionTxHex": "020000000001013d060d0305c9616eaabc21d41fae85bcb5477b5d7f1c92aa429cf15339bbe1c40300000000010000000188130000000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e050047304402202df6bf0f98a42cfd0172a16bded7d1b16c14f5f42ba23f5c54648c14b647531302200fe1508626817f23925bb56951d5e4b2654c751743ab6db48a6cce7dda17c01c8347304402203f99ec05cdd89558a23683b471c1dcce8f6a92295f1fff3b0b5d21be4d4f97ea022019d29070690fc2c126fe27cc4ab2f503f289d362721b2efa7418e7fddb939a5b01008876a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c820120876475527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae67a9142002cc93ebefbb1b73f0af055dcc27a0b504ad7688ac6851b27568f9010000"
},
{
"RemoteSigHex": "3045022100bd206b420c495f3aa714d3ea4766cbe95441deacb5d2f737f1913349aee7c2ae02200249d2c950dd3b15326bf378ae5d2b871d33d6737f5d70735f3de8383140f2a1",
"ResolutionTxHex": "020000000001013d060d0305c9616eaabc21d41fae85bcb5477b5d7f1c92aa429cf15339bbe1c40400000000010000000188130000000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e0500483045022100bd206b420c495f3aa714d3ea4766cbe95441deacb5d2f737f1913349aee7c2ae02200249d2c950dd3b15326bf378ae5d2b871d33d6737f5d70735f3de8383140f2a183483045022100f2cd35e385b9b7e15b92a5d78d120b6b2c5af4e974bc01e884c5facb3bb5966c0220706e0506477ce809a40022d6de8e041e9ef13136c45abee9c36f58a01fdb188b01008876a91414011f7254d96b819c76986c277d115efce6f7b58763ac67210394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b7c820120876475527c21030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e752ae67a9142002cc93ebefbb1b73f0af055dcc27a0b504ad7688ac6851b27568fa010000"
}
],
"ExpectedCommitmentTxHex": "02000000000101bef67e4e2fb9ddeeb3461973cd4c62abb35050b1add772995b820b584a488489000000000038b02b80074a010000000000002200202b1b5854183c12d3316565972c4668929d314d81c5dcdbb21cb45fe8a9a8114f4a01000000000000220020e9e86e4823faa62e222ebc858a226636856158f07e69898da3b0d1af0ddb3994d007000000000000220020fe0598d74fee2205cc3672e6e6647706b4f3099713b4661b62482c3addd04a5e881300000000000022002018e40f9072c44350f134bdc887bab4d9bdfc8aa468a25616c80e21757ba5dac7881300000000000022002018e40f9072c44350f134bdc887bab4d9bdfc8aa468a25616c80e21757ba5dac7c0c62d0000000000220020f3394e1e619b0eca1f91be2fb5ab4dfc59ba5b84ebe014ad1d43a564d012994aad9c6a00000000002200204adb4e2f00643db396dd120d4e7dc17625f5f2c11a40d857accc862d6b7dd80e0400483045022100b4014970d9d7962853f3f85196144671d7d5d87426250f0a5fdaf9a55292e92502205360910c9abb397467e19dbd63d081deb4a3240903114c98cec0a23591b79b7601473044022027b38dfb654c34032ffb70bb43022981652fce923cbbe3cbe7394e2ade8b34230220584195b78da6e25c2e8da6b4308d9db25b65b64975db9266163ef592abb7c72501475221023da092f6980e58d2c037173180e9a465476026ee50f96695963e8efe436f54eb21030e9f7b623d2ccc7c9bd44d66d5ce21ce504c0acf6385a132cec6d3c39fa711c152ae3e195220",
"RemoteSigHex": "3044022027b38dfb654c34032ffb70bb43022981652fce923cbbe3cbe7394e2ade8b34230220584195b78da6e25c2e8da6b4308d9db25b65b64975db9266163ef592abb7c725"
}
]
```
Transfer from google doc. Minimal markdown and consistency fixes, more to come. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-11-15 02:23:20 +01:00
# References
# Authors
BOLT 1,2,3: first pass copy-edit; BOLT 1,2: minor header spacing fixes BOLT 3: first pass copy edit, according to capitalization, formatting stylesheet guidelines;
2017-11-18 22:04:58 +01:00
[ FIXME: ]
Transfer from google doc. Minimal markdown and consistency fixes, more to come. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-11-15 02:23:20 +01:00
Add CC-BY. Closes: #2 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-11-22 20:52:59 +01:00
![Creative Commons License](https://i.creativecommons.org/l/by/4.0/88x31.png "License CC-BY")
<br>
This work is licensed under a [Creative Commons Attribution 4.0 International License](http://creativecommons.org/licenses/by/4.0/).
Reference in New Issue Copy Permalink