update stylesheet to reflect appropriate structure of Requirement sub-items and format of digits, numerations, and quantities;
copy edit BOLTs 0,1,2 to adhere to these changes;
This is stolen from @sstone's #243 "reduce attack surface".
This breaks compatibility, as agreed at the 2017-11-13 meeting.
Note also that it does not update the test vectors.
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've always specified that fields can be appended, and we're about to
do our first. Make it clear that you can't just send one if we add several
fields as part of the same option.
Change extract-formats to have an optional new field appended: the
input format is to simply add ' (optionname)' in the data
specification.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
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>
