This seems to be a cause of stuck HTLCs on the network: c-lightning has
done this for a while now (since 0.6.1).
[ Minor wording clarification merged --RR ]
Decided-at: Adelaide Summit 2018
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Although commitment numbers are explained in the
[glossary](00-introduction.md#glossary-and-terminology-guide),
it's helpful to re-iterate at the place that it's first used.
To 'fail a channel' is mentioned multiple places in this
BOLT without any mention or definition of what that means.
This adds a link to the relevant text in BOLT 05 in the
first place that we mention 'fail the channel'.
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.
