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.
Doesn't take any more space (we could actually reduce millionths to 24 bits,
but that starts to look silly), but it's simpler and allows for cases where
there's no payment amount.
Closes: #296
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
In this commit, we modify the cooperative closing transaction to use
version 2. Currently eclair and lnd already use version 2, while
c-lightning uses version 1. The commitment transaction already uses
version 2, so making this additional transaction (which spends the
funding output) also use version 2 would be consistent. Additionally,
as a best practice, we should be using the highest currently
defined/use transaction version.
HTLC outputs can be resolved by (1) using revocation key,
(2) timeout/preimage use if that's possible, or (3) the cheating party's
HTLC-success/HTLC-timeout tx (which we also specify that you have to
spend using revocation key).
Hopefully this is now clearer.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This got a little messy as some changes now needed to be applied in
two places, and other wording has been completely removed. Another
pass on top will be required.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
The proof-readers rightly noted how confusing the current treatment of
HTLCs is. There are four different cases, but I tried to address them
in two separate sections, with conditionals.
This expands it out, separating sections for Our Commitment Tx and
Their Commitment Tx, then subsections for our HTLCs and their HTLCs
in each one.
It means some duplicated requirements and rationales, but it should now
be very clear.
As a side effect, we no longer refer to A and B at all: it's all US and THEM.
This needs further clearing up, but for now makes it clear what *we* need to do
for all cases.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
second pass copy edit to line 253, according to stylesheet
update node terminology to remove ambiguity; update conventions section and implement consistent usage of terms: origin node, final node, processing node, hop, sending peer, and receiving peer
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.
I named the first option `option209` but that was too ugly to live.
Nonetheless, this wording lived on.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Somehow this got lost in merging; pre-approved at meeting 2017-11-27.
Reported-by: Pierre-Marie Padiou
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
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 was always going to break when we started adding options, unless we
add padding. As no implementation requires alignment, let's skip it.
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>
