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>
