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>
We talk about failing a channel, or channels, but we never spelled
out what a node does in that case.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Not all of them: sometimes we refer to to-self including HTLCs which we're
spending ourselves, but in three places we're explicitly referring to
the `to_local` output.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
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>
One minor change to refer to field name:
preserves `to_self` delay
to:
preserves `to_self_delay` requirement.
Typo fixes:
1. revocation -> revoke_and_ack
2. ctlv_expiry -> cltv_expiry.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
* BOLT 1: recommend full tx in error pkt if signature fails.
This will usually be the commitment tx, but could also be the HTLC
tx.
Reported-by: pm47 <pm.padiou@gmail.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
* FIX: Feedback
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
* BOLT 1: tighten error message `len` requirement.
Of course it has to match data length exactly.
Reported-by: pm47 <pm.padiou@gmail.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
* BOLT 1, BOLT 2, BOLT 5: commitsig -> commitment_signed.
Consistency FTW.
Reported-by: pm47 <pm.padiou@gmail.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
