If a node has to fail a channel but knows that its latest commitment transaction is outdated it should not be required to send it but rather wait for the peer to unilaterally close the channel.
The proposed solution is not so clean because it might produce a deadlock in which two peers assume they have outdated state and send `error` back and forth without actually force closing. Maybe in such a scenario we could create a protocol that mutually closes with split balance?
Also replaced the word use with broadcast as it seems more accurate.
Co-authored-by: t-bast <bastuc@hotmail.fr>
Prior to the addition of `warning` messages, BOLT 5 specified a
few cases where users should be warned that funds may have been
lost. However, it used the phrasing "send a warning" which can now
be confused with `warning` messages. Nodes should not generally
inform their counterparty that they have been robbed.
And make most places warn or error. Places where we're operating
on a channel tend to be "warn and close connection" since we want to
forget the mistake they just sent, and closing the connection does that.
We now use the same words everywhere:
1. "fail channel" means to go onchain (if necessary).
2. "send `error`" means to send an error message.
3. "send `warning`" means to send a warning message.
4. "close connection" means close the connection.
These are all spelled out explicitly, rather than having "fail channel"
imply sending an error packet, for example.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
If `option_anchor_outputs` applies, the cheating node can pin spends of its
HTLC-timeout/HTLC-success outputs thanks to SIGHASH_SINGLE malleability.
Using a single penalty transaction for all revoked outputs is thus unsafe as it
could be blocked to propagate long enough for the `_local node's main output_ 's
relative timelock to expire and the cheating party escaping the penalty on this
output.
This commit extends the specification with a new commitment format that
adds two anchor outputs to the commitment transaction. Anchor outputs
are a safety feature that allows a channel party to unilaterally increase
the fee of the commitment transaction using CPFP and ensure timely
confirmation on the chain. There is no cooperation required from the
remote party.
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>
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>
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>
We talked about this below in the Rationale:
The fulfillment of an on-chain HTLC delivers the `payment_preimage`
required to fulfill the incoming HTLC...
Otherwise, it needs to send the `update_fail_htlc` (presumably with
reason `permanent_channel_failure`) as detailed in [BOLT
02](https://github.com/lightningnetwork/lightning-rfc/blob/master/02-peer-protocol.md#forwarding-htlcs).
But we didn't actually *say* you MUST fail incoming HTLCs after reasonable
depth!
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
BOLT 5 only talks in terms out HTLC outputs, but not all HTLCs have outputs.
HTLCs which are dust for both sides are easy, but others require the
commit tx to be buried before we can consider the HTLC failed.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Nasty corner case which I got wrong; we can fulfill but then we risk
a reorg removing it. And anyway, fulfilling reveals that we are
the endpoint in practice.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Attempts to clarify the weight calculation of penalty
transactions, and makes sweeping the `to_remote` output
optional without breaking any existing constraints. Assuming
these figures are correct, the decision to sweep the
`to_remote` _does not_ change the current unidirectional
limit of 483 HTLCs. Thus, the option to do so can be made
independently by either party/implemenation.
The previous equation used to calculate `max_num_htlcs`
slightly underestimated the theoretical maximum weight,
since non-witness data was treated as 1:1 with witness
data. Ultimately, this had no effect on the computed
results, but figured we should be more specific here for
the purpose of properly estimating transaction fees.
This commit also modifies the `to_local_script` to use the
latest construction; the derived weights have been updated
accordingly.
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>
