The weights of HTLCs were corrected by Pierre in "fixed htlc weight
calculation": this adjusts the test vectors to match.
This also means that the feerate thresholds change.
In addition, this fixes feerate on "maximum feerate" tests,
and corrects the fee for the htlc-timeout tx.
Reported-by: Fabrice Drouin <fabrice.drouin@acinq.fr>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
The test vectors themselves were fine, but they're supposed to be derived
from known basepoints (and I was actually testing this with some new code).
I accidentally used the *remote* per-commitment-point, instead of the *local*
per-commitment-point to derive the remotekey/remote_privkey; since we are
generating the local transaction, this is wrong. We don't need to know
the remote per-commitment-point at all, in fact.
Thus, the remotekey (and signatures) in the test vectors change.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Christian assumed first bit was 1, I assumed 0. And we should generally
assign in pairs (so an optional understanding can later become compulsory),
though for the initial draft it's unnecessary.
By giving names we avoid smearing values over the spec, containing them in
BOLT 9.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
* BOLT 2&7: Cleaner separation of concerns wrt announcement signatures
So far we did not have any indication on what to do if a node does not
allow announcing the channel and we had a mix of concerns in the
`funding_locked` message, which would also transfer the signatures
needed for the announcement. This is a proposal about splitting the
signatures into their own message, so that simple omission is an
opt-out of announcements, and it does not mix announcement/gossip
stuff into the peer-protocol.
(It also ended up adding a localfeatures flag to opt-into the channel-announcement, and thus creating BOLT 9)
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>
Reorders the `channel-id` and `bitcoin-signature-x` fields so that the
signed part of the message is contiguous. Simplifies the signing logic
not to just simple signatures of a contiguous region of the message,
no need to sign signatures, they all commit to the same payload. This
also removes the chicken and egg problem @pm47 reported in #92.
Furthermore it specifies that the signed payload also includes any
future appended fields.
Not only is it shorter and cheaper, but the rest of the document (including
test vectors and weight calculation) assumed it already.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
The extraction tool was broken for a while, so let's make sure this
doesn't happen in the future. Plus we can start enforcing some
formatting details about the specs.
[ --check-alignment added by Rusty ]
* 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>
Olaoluwa pointed out that peers can make work for us by starting to open
connections then disconnecting: we need to allow timeouts, since it's
the simplest solution.
The comment about remembering `r` values (ie. `payment-preimage`) from
update_fulfill_htlc was also vague: it was meant to simply note that
it's not completely reversible, since the knowledge is (and probably
should be!) used to fulfill an incoming HTLC.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
1) Make it clear that `init` needs to be sent every time.
- This means if you upgrade and no longer support an old connection, it's
clear, plus it simplifies the question of re-transmission of `init`.
2) Spell out the retransmission requirements for reconnection.
- We agreed in Milan to simply use retransmit and ignore-dups.
- This needs actual testing by implementations, but this is my best guess
on exactly how far back to retransmit.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This reduces failure codes to 2 bytes, places them into data itself.
Now we can use the same parsing code for them as we use for normal packets.
BOLT 2 is adjusted to match, and order of args changed to restore sha256
alignment to a nice 8 bytes.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
The most significant byte of the locktime in a commitment transaction
must be set to 0x20. This is to make sure that the locktime value
is always higher than 500,000,000, making it interpreted as a Unix
epoch timestamp, and not a block height. It also makes sure that the
locktime is below the current time, allowing the commitment transaction
to be included in a block.
Since the sequence field in the input of the commitment transaction is
used for the other half of the obscured commitment transaction number,
it will never assume the maxInt value (0xFFFFFFFF) which would disable
locktime checking.
The previous test vectors were using the btcec variant corresponding
to RFC5903 Section 9, only using the X-coord of the result of the
scalar multiplication, whereas libsecp256k1 uses the compressed
serialization format, which includes the sign bit.
* BOLT 2: allow more leniancy with forks during channel establishment.
Christoper points out that two nodes with aggressive minimum-depth settings
may see different blocks and the protocol requires they close the channel
since their funding_locked messages will disagree.
This can also happen when only one side has an aggressive minimum-depth
setting: if it sends funding_locked referring to a block which is orphaned,
it can't update it.
There are three changes here, two optional.
- Allow sending of an updated funding_locked. This fixes this case where
one side is on an orphan and uses a v. low minimum-depth.
- Require accepting of an updated funding_locked.
- Allow waiting instead of immediate failure if funding_lock disagrees.
eg. you might wait another block or two to see if one side reorgs.
Reported-by: Christopher Jämthagen
Closes: #73
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
For now I just generated the wrapping direction since the unwrapping
relies on the steps in reverse. It's a 5-hop onion packet, padded to
the standard 20 hop size. Associated data and per-hop-payloads are
filled with dummy values, not the format described in the bolt.
This commit fixes an oversight within the spec that details the
encryption nonces as being encoded in a big-endian form rather an a
little-endian for as is intended.
Since our internal nonces are 64-bit in order to match with the Noise
spec, we encoded the 96-bit nonce as 32-bits of leading zeroes followed
by the 64-bit little-endian value.
