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>
Since our cryptopacket limits us to 2 bytes, and since people will
send 1-message-per-crypto-packet and nobody will test the
multiple-messages-in-one-cryptopacket code, let's just restrict to
64k messages.
1. Make cryptopacket length not include the HMAC, so we can actually send
64k messages.
2. Remove len prefix from packet, make type 2 bytes, note alignment properties.
3. Change message internal lengths/counts from 4 to 2 bytes, since more
is nonsensical anyway, and this removes a need to check before allocating:
- init feature bitfield length
- error message length
- shutdown scriptpubkey length
- commit_sig number of HTLC signatures
- revoke_and_ack number of HTLC-timeout signatures
4. Change max-accepted-htlcs to two bytes, and limit it to 511 to ensure
that commit_sig will always be under 64k.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Calculations are put in 05-onchain.md, and referred to by 02-peer-protocol.
The number is 600, comfortably under the 626 theoretical limit.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
