mirrors/lightning-bolts
1
0
Fork 0
mirror of https://github.com/lightning/bolts.git synced 2025-01-18 13:22:35 +01:00
Code Issues Projects Releases Wiki Activity

BOLT 7,11: Added an optional min_final_cltv_expiry field in BOLT 11 (#258)

Browse Source 
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 commit is contained in:
Pierre-Marie Padiou 2017-10-18 15:31:31 +02:00 committed by GitHub
parent 1066c31c4b
commit d1fbfd30f8
3 changed files with 27 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1
.aspell.en.pws
View File

@ -103,6 +103,7 @@ hopDataSize
I'th
segwit
htlc
htlcs
ChaCha
len
ciphertext

17
07-routing-gossip.md
View File

@ -282,12 +282,23 @@ padding within `addresses` if they require certain alignment.
## The `channel_update` message
After a channel has been initially announced, each side independently
announces its fees and minimum expiry for HTLCs. It uses the 8-byte
announces the fees and minimum expiry delta it requires to relay HTLCs
through this channel. It uses the 8-byte
channel shortid which matches the `channel_announcement` and one bit
in the `flags` field
to indicate which end this is. It can do this multiple times, if
it wants to change fees.
Note that the `channel_update` message is only useful in the context
of *relaying* payments, not *sending* payments. When making a payment
`A` -> `B` -> `C` -> `D`, only the `channel_update`s related to channels
`B` -> `C` (announced by `B`) and `C` -> `D` (announced by `C`) will
come into play. When building the route, amounts and expiries for htlcs need
to be calculated backwards from the destination to the source. The initial
exact value for `amount_msat` and minimal value for `htlc_expiry`, which are
to be used for the last HTLC in the route, are provided in the payment request
(see [BOLT #11](11-payment-encoding.md#tagged-fields)).
A node MAY still create a `channel_update` to communicate the channel parameters to the other endpoint, even though the channel has not been announced, e.g., because the `announce_channel` bit was not set.
For further privacy such a `channel_update` MUST NOT be forwarded to other peers.
Note that such a `channel_update` that is not preceded by a `channel_announcement` is invalid to any other peer and would be discarded.
@ -422,10 +433,6 @@ Notice that this is a node policy and MUST NOT be enforced by peers, e.g., by cl
## Recommendations for Routing
As the fee is proportional, it must be calculated backwards from the
destination to the source: only the amount required at the final
destination is known initially.
When calculating a route for an HTLC, the `cltv_expiry_delta` and the fee both
need to be considered: the `cltv_expiry_delta` contributes to the time that funds
will be unavailable on worst-case failure. The tradeoff between these

16
11-payment-encoding.md
View File

@ -109,6 +109,7 @@ Currently defined Tagged Fields are:
* `n` (19): `data_length` 53. The 33-byte public key of the payee node.
* `h` (23): `data_length` 52. 256-bit description of purpose of payment (SHA256). This is used to commit to an associated description which is too long to fit, such as may be contained in a web page.
* `x` (6): `data_length` variable. `expiry` time in seconds (big-endian). Default is 3600 (1 hour) if not specified.
* `c` (24): `data_length` variable. `min_final_cltv_expiry` to use for the last HTLC in the route. Default is 9 if not specified.
* `f` (9): `data_length` variable, depending on version. Fallback on-chain address: for bitcoin, this starts with a 5 bit `version`; a witness program or P2PKH or P2SH address.
* `r` (3): `data_length` variable. One or more entries containing extra routing information for a private route; there may be more than one `r` field, too.
* `pubkey` (264 bits)
@ -128,8 +129,12 @@ the purpose of the payment. If included, a writer MUST make the preimage
of the hashed description in `h` available through some unspecified means,
which SHOULD be a complete description of the purpose of the payment.
A writer MAY include one `x` field, which SHOULD use the minimum `data_length`
possible.
A writer MAY include one `x` field.
A writer MAY include one `c` field, which MUST be set to the minimum `cltv_expiry` it
will accept for the last HTLC in the route.
A writer SHOULD use the minimum `data_length` possible for `x` and `c` fields.
A writer MAY include one `n` field, which MUST be set to the public key
used to create the `signature`.
@ -191,6 +196,13 @@ refused; this is mainly to avoid confusion. The default was chosen
to be reasonable for most payments, and allow sufficient time for
on-chain payment if necessary.
The `c` field gives a way for the destination node to require a specific
minimum cltv expiry for its incoming HTLC. Destination nodes may use this
to require a higher, more conservative value than the default one, depending
on their fee estimation policy and their sensitivity to time locks. Note
that other nodes in the route specify their required `cltv_expiry_delta`
in the `channel_update` message, which they can update at all times.
The `f` field allows on-chain fallback. This may not make sense for
tiny or very time-sensitive payments, however. It's possible that new
address forms will appear, and so multiple `f` fields in an implied