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.
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>
Complete rewrite, including a routing example and the new
min_final_cltv expirt. I hope this makes it clear.
(Thanks to everyone who reviewed and gave feedback; you rock!)
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
1. We say you can't fail an HTLC until it's removed outgoing; make it clear
that this could also be on-chain.
2. Insist that you fail an expired HTLC (we never actually said this!)
3. You MUST fulfill an incoming HTLC for which the output was fulfilled
(otherwise you'll lose money), and of course, even if fulfilled on-chain.
Add an explanation paragraph to BOLT 5 as well, where it discusses on-chain
HTLC output cases (though the requirements about what to do about incoming
HTLCs is actually in BOLT 2).
[ Extra wording clarification thanks to roasbeef ]
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit modifies the glossary to add a new entry which defines the
usage of `chain_hash` throughout the remainder of the documents.
Additionally, we now also specify which chain hash we expect for
Bitcoin within the glossary.
This commit also modifies BOLT #2 and #7 to omit the definition of the
expected `chain_hash` value for Bitcoin.
1. Change descriptions of closing tx construction to references to BOLT 3.
2. Recipient *should* check the fee offer has improved in closing_signed.
3. Therefore, sender *must* improve closing offer.
4. Offers do not persist across reconnection, so no state req'd, and
also helps if fee has changed.
5. You don't need to re-send `shutdown` if you received `closing_signed`
(implicit acknowledgement).
6. You don't have to accept a `channel_reestablish` which requests the last
revoke_and_ack be retransmitted if you've already received `closing_signed`
(which is an implicit acknowledgement).
Closes: #201Closes: #199
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
The actual fee of the final tx may include eliminated outputs, which can
differ between one side and the other (since they have different thresholds).
Simplify this corner case by using our base fee calculation as the upper bound;
it should be close enough we don't care, but disagreement here could cause
negotiation breakdown.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
You can't eliminate an output and also guarantee a certain fee, so
we need to define exactly how to do this.
Since the output is (presumably) dust, we might as well just discard it
(effectively increasing the fee). This avoids the peer directly benefiting
from the elimination as well.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This adds a message for each channel reconnect (after we've
sent/received `funding_signed`, ie. when we rememeber the channel),
which says exactly how many `commitment_signed` and `revoke_and_ack`
we've received. Really, we could use one bit for each (they could
only be missing the last one), but better to be clear.
This leaves the "rollback if didn't get commitment_signed"
requirement, but avoids any need to handle update duplicates or wonder
what update number a `commitment_signed` applies to after reconnect.
Many thanks to pm47 and roasbeef especially for constructive feedback
which made this far better than I originally had.
Closes: #172
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We can't do that, so allow "write, then send". That fails on the side of
timing out, rather than having a channel which can't be used.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit gives peers the ability to signal their intent to make a
channel private in the `open_channel` message. This differs from the
current method as now peers are able to create multiple channels with
heterogeneous announcement policies _without_ disconnecting and
re-connecting in-between each channel funding. The prior requirement
for the nodes to re-connect was burdensome and unnecessary.
[ Minor tweaks from feedback folded in -- RR ]
This commit modifies the “Normal Operation” summarization by including
a link to BOLT #7 when mentioning the `announcement_signature` message.
Previously a reader would need to search other documents to figure out
what an `announcement_signature` was, and its purpose.
We had 4 byte fields for amounts because people have no ability to assess
risk, and this limited the damage to $70 at a time.
But then that means $1 maximum HTLCs on Litecoin, which isn't enough
for a cup of (decent) coffee.
Rather than have boutique hacks for Litecoin we enlarge the fields now,
and simply have a bitcoin-specific restriction that the upper 4 bytes be 0.
The ctlv_expiry field is moved down in update_add_htlc, to preserve alignment.
Suggested-by: Olaoluwa Osuntokun <laolu32@gmail.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
1. Tell the node when to broadcast the funding tx (we didn't do this!).
2. Allow timeouts generally if no progress is made (originally this
was just when waiting for funding_locked, but it applies generally).
3. Use `funding_signed` as the commitment point: before this, we forget,
after this, we remember. If lost, we'll timeout.
4. The core of the retransmission requirements now only applies to
the normal and shutdown states, and will be revised separately
depending on #172
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit fixes an advisory error in the current spec draft. We
currently use `fee-per-kw` where `kw = 1000` weight to determine the
proper fee to pay for commitment transactions. Currently, the spec
advises implementer to take the typical sat/Kb at _multiply_ by 4. This
will result in implementations overpaying for commitment transactions
as the scaling should actually be in the _opposite_ direction. As the
weight is scaled up by 4, for fee-per-kw should be scaled down by 4.
So: sat/Kb * 1/4, instead of sat/Kb * 4.
[Minor fixup: "1/4th" to "1/4", better english, and doesn't trip spellcheck. -- RR]
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>
1. Only one per-hop thing, called `per-hop`, or `hops_data` when in aggregate.
2. Move HMAC to the end of stuff it covers, both of the packet itself, and the per-hop.
3. Use `channel-id` instead of RIPEMD(nodepubkey).
4. Use 4 byte amounts.
5. This is all for realm "0", we can have future realms. We also have 16
bytes of unused padding.
6. No longer need the `gamma` key, but document the `_um_` key used for
errors.
7. Use normal 32-byte HMAC, not truncated 20-bytes, which more than eats
up the room we saved.
The result is that the onion is now 1366 not 1254 bytes, but simpler.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
`channel-id` which identifies , which is derived
=>
`channel-id` to identify the channel, which is derived
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
It was never mentioned, but fulfilling a timedout HTLC means a race
between timing out and fulfilling, which is bad.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
