mirrors/lightning-bolts
1
0
Fork 0
mirror of https://github.com/lightning/bolts.git synced 2025-03-12 10:30:20 +01:00
Code Issues Projects Releases Wiki Activity

Update closing_signed fee requirement (#847)

Browse source 
With anchor outputs, we can keep the commit tx feerate lower than the real
on-chain feerate. That means that when closing the channel, the resulting
fee will not necessarily be lower than the current commit tx fee, this
requirement doesn't make sense to be strict.

Both sides can optionally include a preferred fee range in their
`closing_signed`. This lets their peer know what fees they find acceptable
and simplifies the closing negotiation.
This commit is contained in:
Bastien Teinturier 2021-08-31 09:08:07 +02:00 • committed by GitHub
parent 4372f9d538
commit 498f104fd3
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
1 changed files with 56 additions and 18 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

74
02-peer-protocol.md
View file

@ -600,11 +600,24 @@ the other node then replies similarly, using a fee it thinks is fair. This
exchange continues until both agree on the same fee or when one side fails exchange continues until both agree on the same fee or when one side fails
the channel. the channel.
In the modern method, the funder sends its permissable fee range, and the
non-funder has to pick a fee in this range. If the non-funder chooses the same
value, negotiation is complete after two messages, otherwise the funder will
reply with the same value (completing after three messages).
1. type: 39 (`closing_signed`) 1. type: 39 (`closing_signed`)
2. data: 2. data:
* [`channel_id`:`channel_id`] * [`channel_id`:`channel_id`]
* [`u64`:`fee_satoshis`] * [`u64`:`fee_satoshis`]
* [`signature`:`signature`] * [`signature`:`signature`]
* [`closing_signed_tlvs`:`tlvs`]
1. `tlv_stream`: `closing_signed_tlvs`
2. types:
1. type: 1 (`fee_range`)
2. data:
* [`u64`:`min_fee_satoshis`]
* [`u64`:`max_fee_satoshis`]
#### Requirements #### Requirements
@ -613,12 +626,17 @@ The funding node:
- SHOULD send a `closing_signed` message. - SHOULD send a `closing_signed` message.
The sending node: The sending node:
- MUST set `fee_satoshis` less than or equal to the - SHOULD set the initial `fee_satoshis` according to its estimate of cost of
base fee of the final commitment transaction, as calculated in [BOLT #3](03-transactions.md#fee-calculation). inclusion in a block.
- SHOULD set the initial `fee_satoshis` according to its - SHOULD set `fee_range` according to the minimum and maximum fees it is
estimate of cost of inclusion in a block. prepared to pay for a close transaction.
- MUST set `signature` to the Bitcoin signature of the close - if it doesn't receive a `closing_signed` response after a reasonable amount of time:
transaction, as specified in [BOLT #3](03-transactions.md#closing-transaction). - MUST fail the channel
- if it is not the funder:
- SHOULD set `max_fee_satoshis` to at least the `max_fee_satoshis` received
- SHOULD set `min_fee_satoshis` to a fairly low value
- MUST set `signature` to the Bitcoin signature of the close transaction,
as specified in [BOLT #3](03-transactions.md#closing-transaction).
The receiving node: The receiving node:
- if the `signature` is not valid for either variant of closing transaction - if the `signature` is not valid for either variant of closing transaction
@ -627,31 +645,51 @@ The receiving node:
- if `fee_satoshis` is equal to its previously sent `fee_satoshis`: - if `fee_satoshis` is equal to its previously sent `fee_satoshis`:
- SHOULD sign and broadcast the final closing transaction. - SHOULD sign and broadcast the final closing transaction.
- MAY close the connection. - MAY close the connection.
- otherwise, if `fee_satoshis` is greater than - if `fee_satoshis` matches its previously sent `fee_range`:
the base fee of the final commitment transaction as calculated in - SHOULD use `fee_satoshis` to sign and broadcast the final closing transaction
[BOLT #3](03-transactions.md#fee-calculation): - SHOULD reply with a `closing_signed` with the same `fee_satoshis` value if it is different from its previously sent `fee_satoshis`
- MUST fail the connection. - MAY close the connection.
- if `fee_satoshis` is not strictly - if the message contains a `fee_range`:
between its last-sent `fee_satoshis` and its previously-received - if there is no overlap between that and its own `fee_range`:
`fee_satoshis`, UNLESS it has since reconnected: - SHOULD fail the connection
- MUST fail the channel if it doesn't receive a satisfying `fee_range` after a reasonable amount of time
- otherwise:
- if it is the funder:
- if `fee_satoshis` is not in the overlap between the sent and received `fee_range`:
- MUST fail the channel
- otherwise:
- MUST reply with the same `fee_satoshis`.
- otherwise (it is not the funder):
- if it has already sent a `closing_signed`:
- if `fee_satoshis` is not the same as the value it sent:
- MUST fail the channel
- otherwise:
- MUST propose a `fee_satoshis` in the overlap between received and (about-to-be) sent `fee_range`.
- otherwise, if `fee_satoshis` is not strictly between its last-sent `fee_satoshis`
and its previously-received `fee_satoshis`, UNLESS it has since reconnected:
- SHOULD fail the connection. - SHOULD fail the connection.
- if the receiver agrees with the fee: - otherwise, if the receiver agrees with the fee:
- SHOULD reply with a `closing_signed` with the same `fee_satoshis` value. - SHOULD reply with a `closing_signed` with the same `fee_satoshis` value.
- otherwise: - otherwise:
- MUST propose a value "strictly between" the received `fee_satoshis` - MUST propose a value "strictly between" the received `fee_satoshis`
and its previously-sent `fee_satoshis`. and its previously-sent `fee_satoshis`.
#### Rationale #### Rationale
The "strictly between" requirement ensures that forward When `fee_range` is not provided, the "strictly between" requirement ensures
progress is made, even if only by a single satoshi at a time. To avoid that forward progress is made, even if only by a single satoshi at a time.
keeping state and to handle the corner case, where fees have shifted To avoid keeping state and to handle the corner case, where fees have shifted
between disconnection and reconnection, negotiation restarts on reconnection. between disconnection and reconnection, negotiation restarts on reconnection.
Note there is limited risk if the closing transaction is Note there is limited risk if the closing transaction is
delayed, but it will be broadcast very soon; so there is usually no delayed, but it will be broadcast very soon; so there is usually no
reason to pay a premium for rapid processing. reason to pay a premium for rapid processing.
Note that the non-funder is not paying the fee, so there is no reason for it
to have a maximum feerate. It may want a minimum feerate, however, to ensure
that the transaction propagates. It can always use CPFP later to speed up
confirmation if necessary, so that minimum should be low.
## Normal Operation ## Normal Operation
Once both nodes have exchanged `funding_locked` (and optionally [`announcement_signatures`](07-routing-gossip.md#the-announcement_signatures-message)), the channel can be used to make payments via Hashed Time Locked Contracts. Once both nodes have exchanged `funding_locked` (and optionally [`announcement_signatures`](07-routing-gossip.md#the-announcement_signatures-message)), the channel can be used to make payments via Hashed Time Locked Contracts.