Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

feature: define option_zero_htlc_tx_fee (feature 22/23) #824

Merged
merged 2 commits into from
Aug 30, 2021
Merged

feature: define option_zero_htlc_tx_fee (feature 22/23) #824

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
77dfee2
feature: define option_zero_fee_second_stage
halseth Dec 8, 2020
75a4cde
fixup! feature: define option_zero_fee_second_stage
halseth Feb 25, 2021
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
51 changes: 35 additions & 16 deletions 02-peer-protocol.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -378,10 +378,14 @@ This message introduces the `channel_id` to identify the channel. It's derived f
#### Requirements

Both peers:
- if `option_static_remotekey` or `option_anchor_outputs` was negotiated:
- `option_static_remotekey` or `option_anchor_outputs` applies to all commitment transactions
- if `option_static_remotekey`, `option_anchor_outputs` or
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

since option_anchors has been added to cover _outputs and _zero_fee_htlc_tx, why is it not used here?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Worse, you don't define what the effect is if both are negotiated!

- if `option_anchors_zero_fee_htlc_tx` was negotiated:
  - `option_anchor_outputs` is ignored.
...
Rationale:
`option_anchors_zero_fee_htlc_tx` is considered superior to `option_anchor_outputs`, so is favored if both are negotiated.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If both are negotiated, then both can apply which I don't think is a problem since the latter is a superset of features.

I added a rationale and also specified option_anchors the places where option_static_remotekey defines behavior (since technically option_anchors_zero_fee_htlc_tx does no longer depend on option_static_remotekey): 75a4cde

`option_anchors_zero_fee_htlc_tx` was negotiated:
- `option_static_remotekey`, `option_anchor_outputs` or
`option_anchors_zero_fee_htlc_tx` applies to all commitment transactions
- otherwise:
- `option_static_remotekey` or `option_anchor_outputs` does not apply to any commitment transactions
- `option_static_remotekey`, `option_anchor_outputs` or
`option_anchors_zero_fee_htlc_tx` does not apply to any commitment
transactions

The sender MUST set:
- `channel_id` by exclusive-OR of the `funding_txid` and the `funding_output_index` from the `funding_created` message.
Expand All @@ -396,10 +400,19 @@ The recipient:

#### Rationale

We decide on `option_static_remotekey` or `option_anchor_outputs` at this point when we first have to generate the commitment
transaction. The feature bits that were communicated in the `init` message exchange for the current connection determine
the channel commitment format for the total lifetime of the channel. Even if a later reconnection does not negotiate this parameter,
this channel will continue to use `option_static_remotekey` or `option_anchor_outputs`; we don't support "downgrading".
We decide on `option_static_remotekey`, `option_anchor_outputs` or
`option_anchors_zero_fee_htlc_tx` at this point when we first have to generate
the commitment transaction. The feature bits that were communicated in the
`init` message exchange for the current connection determine the channel
commitment format for the total lifetime of the channel. Even if a later
reconnection does not negotiate this parameter, this channel will continue to
use `option_static_remotekey`, `option_anchor_outputs` or
`option_anchors_zero_fee_htlc_tx`; we don't support "downgrading".

`option_anchors_zero_fee_htlc_tx` is considered superior to
`option_anchor_outputs`, which again is considered superior to
`option_static_remotekey`, and the superior one is is favored if more than one
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: s/is//g

is negotiated.

### The `funding_locked` Message

Expand Down Expand Up @@ -814,7 +827,7 @@ A sending node:
transaction, it cannot pay the fee for either the local or remote commitment
transaction at the current `feerate_per_kw` while maintaining its channel
reserve (see [Updating Fees](#updating-fees-update_fee)).
- if `option_anchor_outputs` applies to this commitment transaction and the sending
- if `option_anchors` applies to this commitment transaction and the sending
node is the funder:
- MUST be able to additionally pay for `to_local_anchor` and
`to_remote_anchor` above its reserve.
Expand Down Expand Up @@ -1039,9 +1052,13 @@ offline until after sending `commitment_signed`. Once
those HTLCs, and cannot fail the related incoming HTLCs until the
output HTLCs are fully resolved.

Note that the `htlc_signature` implicitly enforces the time-lock mechanism in the case of offered HTLCs being timed out or received HTLCs being spent. This is done to reduce fees by creating smaller scripts compared to explicitly stating time-locks on HTLC outputs.
Note that the `htlc_signature` implicitly enforces the time-lock mechanism in
the case of offered HTLCs being timed out or received HTLCs being spent. This
is done to reduce fees by creating smaller scripts compared to explicitly
stating time-locks on HTLC outputs.

The `option_anchor_outputs` allows HTLC transactions to "bring their own fees" by attaching other inputs and outputs, hence the modified signature flags.
The `option_anchors` allows HTLC transactions to "bring their own fees" by
attaching other inputs and outputs, hence the modified signature flags.

### Completing the Transition to the Updated State: `revoke_and_ack`

Expand Down Expand Up @@ -1128,10 +1145,10 @@ A receiving node:
#### Rationale

Bitcoin fees are required for unilateral closes to be effective.
With `option_anchor_outputs`, `feerate_per_kw` is not as critical anymore to
guarantee confirmation as it was in the legacy commitment format, but it still
needs to be enough to be able to enter the mempool (satisfy min relay fee and
mempool min fee).
With `option_anchors`, `feerate_per_kw` is not as critical anymore to guarantee
confirmation as it was in the legacy commitment format, but it still needs to
be enough to be able to enter the mempool (satisfy min relay fee and mempool
min fee).

For the legacy commitment format, there is no general method for the
broadcasting node to use child-pays-for-parent to increase its effective fee.
Expand Down Expand Up @@ -1222,7 +1239,8 @@ The sending node:
next `commitment_signed` it expects to receive.
- MUST set `next_revocation_number` to the commitment number of the
next `revoke_and_ack` message it expects to receive.
- if `option_static_remotekey` applies to the commitment transaction:
- if `option_static_remotekey` or `option_anchors` applies to the commitment
transaction:
- MUST set `my_current_per_commitment_point` to a valid point.
- otherwise:
- MUST set `my_current_per_commitment_point` to its commitment point for
Expand Down Expand Up @@ -1269,7 +1287,8 @@ A node:
- SHOULD fail the channel.

A receiving node:
- if `option_static_remotekey` applies to the commitment transaction:
- if `option_static_remotekey` or `option_anchors` applies to the commitment
transaction:
- if `next_revocation_number` is greater than expected above, AND
`your_last_per_commitment_secret` is correct for that
`next_revocation_number` minus 1:
Expand Down
Loading