Implement changes requested by @rustyrussell: wording change, structure requirements according to whether nodes are sending or receiving;
Correct grammar, punctuation, capitalization, and style for correctness, concision, clarity, comprehension, and consistency;
Implement changes requested by @rustyrussell: wording change, structure requirements according to whether nodes are sending or receiving;
Correct grammar, punctuation, capitalization, and style for correctness, concision, clarity, comprehension, and consistency;
Edit 01-messaging copy for clarity (minor rephrasing, punctuation),
correctness (grammar, capitalization, punctuation),
consision (minimizing wordiness, redundancy),
and consistency (document style, e.g. 1 space between sentences,
capitalization of headers, etc.)
Edit 00-introduction copy for clarity (minor rephrasing, punctuation),
correctness (grammar, capitalization, punctuation),
consision (minimizing wordiness, redundancy),
and consistency (document style, e.g. 1 space between sentences,
capitalization of headers, etc.)
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>
Added an optional `c` field in the payment request specifying the
minimum `cltv_expiry` to use for the last htlc in the route. If
not provided, default value is 9.
This commit also clarifies how `channel_update` messages are only
to be used in the context of relaying payments, and how both htlc
amounts and expiries are to be calculated backwards from the values
provided in the payment request.
Not needing the `channel_update` for the first channel in a route also
means that it is possible to make a payment through a channel which
hasn't had any announcements yet.
This is a partial response to #250. Reordering the HMAC and Encrypt
steps do not give us much, but we might want to hide the route
length. So we suggest that the node should continue unwrapping until
the maximum route length of 20 is reached.
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>
An 0x01 byte is appended to the end of private keys in the test
vectors to mark them as using compressed serialization to derive the
pubkeys. Two of the private keys have two 0x01 bytes appended,
presumably by accident.
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.
This is unofficial, since we don't have IANA tag, but it doesn't
clash with any existing one. We'll see if this turns out to be something
people want.
Closes: #206
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>
* BOLT 04: increase max size of onion payload messages
This commit increases the max size of the encapsulated onion error
messages. This is a follow up change to the recent change that added a
`chain_hash` field to the `channel_update` message. With the addition of
this field, the largest payload encoded within the onion errors has
expanded to 138 bytes:
* msat_amount || 2_byte_len || channel_update.
As a result, the old fixed limit (including padding) is now
insufficient. We use 256 bytes here in order to give us room for future
message expansions.
