Using the receiver's dust limit implies a naive node can be fooled
(by a peer with massive dust limit) into not getting its own output.
Using our own opens the possibility of creating different transactions,
so we explicitly allow the tractable case, while accepting failure on
the case where disagreement is real.
Closes: #128
Reported-by: Pierre-Marie Padiou
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We didn't update it for 394da29189
"BOLT 3: fix test vector derivation."
This doesn't actually change any results, just fixes an intermediate
calculation.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We can no longer allow 511 each way; reduce it to match our calculations
so we can always create a single standard penalty transaction.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
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>
At cost of a few extra bytes between peers, this avoids the whole "oops, we were on a chain fork" problem, and simplifies generation of temporary channel-ids (just pick a random one).
Now we move the announcement_signature exchange to at least 6 confirms, which makes re-xmit tricky; I resolved that by insisting on reconnect that we send if we haven't received, and reply to the first one.
The term "channel shortid" wasn't used anywhere, so I removed it; it's now a gossip-only thing anyway.
One subtle change: pkt_error on unknown channels is now "MUST ignore"; this section was reworked anyway, and we'll want this if the #120 goes through, where one side might have forgotten unformed channels).
Closes: #114
Suggested-by: Olaoluwa Osuntokun <laolu32@gmail.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
* FIXUP! Two bytes for funding-output-index.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
* FIXUP! Channel-id rework, temp ids, 32 bits only.
Re-add the idea of temporary channel ids: far simpler since they're now
big enough we can just fill with noise.
Remove the alignment issues by combining txid and outnum using XOR; we
could reduce to 128 bit if we really wanted to, but we don't.
Error handling is now simple again, but while editing I changed the
behaviour for unknown channels to MUST ignore (this is important for
Change the 8-byte gossip channel id to `short-channel-id`.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
* FIXUP! Minor text tweaks from Pierre-Marie and Christian
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
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>
