Even with push_msat, we need to make sure that funder can pay the fees,
so require that.
Also require that there be some funds above reserve on one side, otherwise
the channel is useless, and we risk that all outputs are dust.
Note: a side *may* reject the channel if funding_satoshis is too small
already, but this sets a clear minimum bar.
Fixes: #393
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Add requirements on accept_channel, so each side doesn't consider the
*other* reserve dust either.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
After more consideration, I believe that this is sufficient to ensure
one reserve is always non-dust.
The races which make us dig into the reserves can't currently take from
the fundee's reserve, so either the fundee has sufficient reserves, or
it can't add HTLCs which means no race.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Clarify that field `channel_reestablish`.`your_last_per_commitment_secret`
should be set to an all-zero array when no `per_commitment_secret` has
been received yet.
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>
I got an unexpected update_fee message after `shutdown` exchange,
which is currently legal:
A: shutdown (no htlcs)
B: receive shutdown
B: reply with shutdown & closing_signed
A: send update_fee & commitment_signed
A: receive shutdown
Simplest to ban any updates (currently, just update_fee) from adding a
new commitment tx while we're at the end of shutdown.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Fixed warnings:
.copy-edit-stylesheet-checklist.md: 49: MD030/list-marker-space Spaces after list markers [Expected: 1; Actual: 0]
.copy-edit-stylesheet-checklist.md: 1: MD041/first-line-h1 First line in file should be a top level header [Context: "Basic checklist/stylesheet use..."]
02-peer-protocol.md: 161: MD018/no-missing-space-atx No space after hash on atx style header [Context: "#7](07-routing-gossip.md#bolt-..."]
Usually the counterparty would only hurt itself if it chooses too low a `dust_limit`, but in the specific scenario of a data loss, we want the counterparty's commitment tx to be relayed and confirmed on the network.
Some slightly larger scale revisions for BOLT-2, notably including a reorganization of the "open_channel" function with the introduction of two missing arguments.
Also, the addition of MSAT to the glossary in BOLT-0.
This is Fabrice's #243 "BOLT2, BOLT3: reduce attack surface", split
out with minor polishing:
- Made it an optional feature (we can insist on it if we choose even bit).
- Rename from "final_scriptpubkey" to "shutdown_scriptpubkey".
- Make requirements the same as shutdown's scriptpubkey, or zero-len.
- Leave shutdown's scriptpubkey, just make sure it's the same or fail.
- Add to accept_channel as well as open_channel.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
It *is* 2R+G+S, which is 7, not six. It's also identical to the previous one,
so just say that.
Reported-by: Shannon Appelcline <shannona@skotos.net>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
update stylesheet to reflect appropriate structure of Requirement sub-items and format of digits, numerations, and quantities;
copy edit BOLTs 0,1,2 to adhere to these changes;
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>
This is the best I could come up with. You can't know future
revocation secrets, so if you send onw I know you're ahead of me
somehow. That means I *MUST NOT* broadcast my latest commitment
transaction, but at least if you're not malicious I'll salvage
something.
We adapt BOLT 5 in a fairly trivial way to specify to say you should
try to handle as much as you can (in fact, you should always be able
to collect their commitment transaction's direct-to-you output).
Fixes: #209
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
