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>
