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

option_simple_close (features 60/61) #1096

Open
wants to merge 9 commits into
base: master
Choose a base branch
from
Open

option_simple_close (features 60/61) #1096

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
9 commits
Select commit Hold shift + click to select a range
d299e0d
BOLT 2, 3, 9: option_simple_close.
rustyrussell Jul 17, 2023
aa6deb8
BOLT 2: fix battling requirements for `shutdown`
rustyrussell Jul 17, 2023
62f6b5b
fixup! BOLT 2, 3, 9: option_simple_close.
rustyrussell Jul 31, 2023
c22fd7b
fixup! BOLT 2, 3, 9: option_simple_close.
rustyrussell Jul 31, 2023
4fa6f92
Require non-dust output for closer.
rustyrussell Jul 31, 2023
74f32dc
BOLT 2: Rewrite to use TLV, and only allow the lesser-amount to drop …
rustyrussell Sep 13, 2023
182c77b
BOLT 2: allow standard OP_RETURN as an output type.
rustyrussell Sep 25, 2023
5d3fa98
Feedback from Bastien
rustyrussell Sep 25, 2023
77baa9a
BOLT 2: specify nSequence explicitly.
rustyrussell Dec 4, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
143 changes: 141 additions & 2 deletions 02-peer-protocol.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -16,6 +16,7 @@ operation, and closing.
* [Channel Close](#channel-close)
* [Closing Initiation: `shutdown`](#closing-initiation-shutdown)
* [Closing Negotiation: `closing_signed`](#closing-negotiation-closing_signed)
* [Closing Negotiation: `closing_complete` and `closing_sig`](#closing-negotiation-closing_complete-and-closing_sig)
* [Normal Operation](#normal-operation)
* [Forwarding HTLCs](#forwarding-htlcs)
* [`cltv_expiry_delta` Selection](#cltv_expiry_delta-selection)
Expand Down Expand Up @@ -584,10 +585,24 @@ Closing happens in two stages:
| |<-(?)-- closing_signed Fn----| |
+-------+ +-------+

+-------+ +-------+
t-bast marked this conversation as resolved.
Show resolved Hide resolved
| |--(1)----- shutdown ------->| |
| |<-(2)----- shutdown --------| |
| | | |
| | <complete all pending HTLCs> | |
| A | ... | B |
| | | |
| |--(3a)- closing_complete Fee->| |
| |<-(3b)- closing_complete Fee--| |
| |<-(4a)- closing_sig ----------| |
| |--(4b)- closing_sig --------->| |
Copy link

Choose a reason for hiding this comment

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

This doesn't seem like the typical use case where one side initiates the close and the other signs. Some explanation somewhere is needed:

  • Is the idea here that both sides can contribute to the closing fee if they want?
  • Does B's closing_complete override A's? And in that case, why does B send closing_sig?
  • Did both A and B send closing_complete at the same time, so we have 2 flows happening at once?

Copy link
Collaborator

Choose a reason for hiding this comment

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

There is one flow happening in each direction, where the sender of closing_complete is paying the fee.
Let me know if the proposed diagram here makes it easier to reason about.

Copy link

Choose a reason for hiding this comment

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

There is one flow happening in each direction, where the sender of closing_complete is paying the fee.

Do we really expect dual flows to happen like that in practice? If the other party offers to pay for the closing transaction, why would we want to send closing_complete at all?

Let me know if the proposed diagram here makes it easier to reason about.

Your diagram helps to clarify corner cases but probably still needs some high-level explanation in the spec.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Do we really expect dual flows to happen like that in practice?

I think we do, because each side should independently decide what fee they'd like to pay and immediately send closing_complete (at least that's how I implemented it). Since the channel has already stopped relaying HTLCs at that point, both peers are likely eager to get their funds back asap to reinvest them into another channel.

+-------+ +-------+

### Closing Initiation: `shutdown`

Either node (or both) can send a `shutdown` message to initiate closing,
along with the `scriptpubkey` it wants to be paid to.
along with the `scriptpubkey` it wants to be paid to. This can be
sent multiple times.

1. type: 38 (`shutdown`)
2. data:
Expand All @@ -603,7 +618,6 @@ A sending node:
- MAY send a `shutdown` before a `channel_ready`, i.e. before the funding transaction has reached `minimum_depth`.
- if there are updates pending on the receiving node's commitment transaction:
- MUST NOT send a `shutdown`.
- MUST NOT send multiple `shutdown` messages.
t-bast marked this conversation as resolved.
Show resolved Hide resolved
- MUST NOT send an `update_add_htlc` after a `shutdown`.
- if no HTLCs remain in either commitment transaction (including dust HTLCs)
and neither side has a pending `revoke_and_ack` to send:
Expand All @@ -618,6 +632,10 @@ A sending node:
3. if (and only if) `option_shutdown_anysegwit` is negotiated:
* `OP_1` through `OP_16` inclusive, followed by a single push of 2 to 40 bytes
(witness program versions 1 through 16)
4. if (and only if) `option_simple_close` is negotiated:
* `OP_RETURN` followed by one of:
Copy link
Collaborator

Choose a reason for hiding this comment

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

As of bitcoind 25, when submitted via the sendrawtransaction API (which I assume we all use), the value of an OP_RETURN must be zero unless a new param is set: https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-25.0.md#updated-rpcs

sendrawtransaction has a new, optional argument, maxburnamount with a default value of 0. Any transaction containing an unspendable output with a value greater than maxburnamount will not be submitted. At present, the outputs deemed unspendable are those with scripts that begin with an OP_RETURN code (known as 'datacarriers'), scripts that exceed the maximum script size, and scripts that contain invalid opcodes.

Perhaps we should also recommend that if an OP_RETURN is used as the closing addr, then the output of the sender should always be zero. Otherwise, this could prevent a variant of the co-op close transaction from propagating.

* `6` to `75` inclusive followed by exactly that many bytes
* `76` followed by `76` to `80` followed by exactly that many bytes
rustyrussell marked this conversation as resolved.
Show resolved Hide resolved

A receiving node:
- if it hasn't received a `funding_signed` (if it is a funder) or a `funding_created` (if it is a fundee):
Expand Down Expand Up @@ -776,6 +794,127 @@ satoshis, which is possible if `dust_limit_satoshis` is below 546 satoshis).
No funds are at risk when that happens, but the channel must be force-closed as
the closing transaction will likely never reach miners.

`OP_RETURN` is only standard if followed by PUSH opcodes, and the total script is 83 bytes or less. We are slightly stricter, to only allow a single PUSH, but there are two forms in script: one which pushes up to 75 bytes, and a longer one (OP_PUSHDATA1) which is needed for 76-80 bytes.

### Closing Negotiation: `closing_complete` and `closing_sig`

Once shutdown is complete, the channel is empty of HTLCs, there are no commitments
for which a revocation is owed, and all updates are included on both commitments,
the final current commitment transactions will have no HTLCs.

Each peer says what fee it will pay, and the other side simply signs that transaction. The lesser-paid peer (if either is) can opt to omit their own output from the closing tx.

This process will be repeated every time a `shutdown` message is received, which allows re-negotiation (and RBF).

1. type: 40 (`closing_complete`)
2. data:
* [`channel_id`:`channel_id`]
* [`u64`:`fee_satoshis`]
* [`u32`:`sequence`]
Copy link
Collaborator

Choose a reason for hiding this comment

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

What about also including lockTime like we do in open_channel2?

* [`closing_tlvs`:`tlvs`]

1. `tlv_stream`: `closing_tlvs`
2. types:
1. type: 1 (`closer_no_closee`)
2. data:
* [`signature`:`sig`]
1. type: 2 (`no_closer_closee`)
2. data:
* [`signature`:`sig`]
1. type: 3 (`closer_and_closee`)
2. data:
* [`signature`:`sig`]
Comment on lines +818 to +826
Copy link

Choose a reason for hiding this comment

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

I find it easy to confuse these types with the current naming.

Can we make the names more precise? Something like:

Suggested change
1. type: 1 (`closer_no_closee`)
2. data:
* [`signature`:`sig`]
1. type: 2 (`no_closer_closee`)
2. data:
* [`signature`:`sig`]
1. type: 3 (`closer_and_closee`)
2. data:
* [`signature`:`sig`]
1. type: 1 (`closer_output_only`)
2. data:
* [`signature`:`sig`]
1. type: 2 (`closee_output_only`)
2. data:
* [`signature`:`sig`]
1. type: 3 (`closer_and_closee_outputs`)
2. data:
* [`signature`:`sig`]


1. type: 41 (`closing_sig`)
2. data:
* [`channel_id`:`channel_id`]
* [`closing_tlvs`:`tlvs`]

#### Requirements

Note: the details and requirements for the transaction being signed are in [BOLT 3](03-transactions.md#closing-transaction)).

An output is *dust* if the amount is less than the [Bitcoin Core Dust Thresholds](03-transactions.md#dust-limits).

Both nodes:
- After a `shutdown` has been received, AND no HTLCs remain in either commitment transaction:
- SHOULD send a `closing_complete` message.

The sender of `closing_complete` (aka. "the closer"):
- MUST set `fee_satoshis` to a fee less than or equal to its outstanding balance, rounded down to whole satoshis.
- MUST set `fee_satoshis` so that at least one output is not dust.
- MUST set `sequence` to a value other than 0xFFFFFFFF.
- MUST use the last send and received `shutdown` `scriptpubkey` to generate the closing transaction specified in [BOLT #3](03-transactions.md#closing-transaction).
Copy link
Collaborator

Choose a reason for hiding this comment

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

nit:

Suggested change
- MUST use the last send and received `shutdown` `scriptpubkey` to generate the closing transaction specified in [BOLT #3](03-transactions.md#closing-transaction).
- MUST use the last sent and received `shutdown` `scriptpubkey` to generate the closing transaction specified in [BOLT #3](03-transactions.md#closing-transaction).

- If it sets `signature` fields, MUST set them as valid signature using its `funding_pubkey` of:
Copy link
Collaborator

Choose a reason for hiding this comment

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

In what case wouldn't the signature fields be set?

Also why are three versions needed at all? If by the time we decide to co-op close, I'm the only one that has a non-dust output, then why would I ever send a signature with my output removed?

- `closer_no_closee`: closing transaction with only the local ("closer") output.
- `no_closer_closee`: closing transaction with only the remote ("closee") output.
- `closer_and_closee`: closing transaction with both the closer and closee outputs.
- If the local outstanding balance (in millisatoshi) is less than the remote outstanding balance:
- MUST NOT set `closer_no_closee`.
Copy link
Collaborator

Choose a reason for hiding this comment

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

Having trouble understanding the requirement above (local balance < remote balance): shouldn't this instead state that as along as the remote party has a non-dust output, then closer_no_closee should never be set?

Copy link
Collaborator

Choose a reason for hiding this comment

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

Or is this just saying that they shouldn't burn the closee's settled output as fees to miners?

- MUST set exactly one of `no_closer_closee` or `closer_and_closee`.
- MUST set `no_closer_closee` if the local output amount is dust.
- MAY set `no_closer_closee` if it considers the local output amount uneconomic AND its `scriptpubkey` is not `OP_RETURN`.
Copy link
Collaborator

Choose a reason for hiding this comment

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

Ah ok, reading further, this makes more sense: before we would sort of implicitly decide to remove outputs based on dust values (had some prior ambiguity there w.r.t which dust values were used), but now we make all the cases explicit!

- Otherwise (not lesser amount, cannot remove own output):
- MUST NOT set `no_closer_closee`.
- If the closee's output amount is dust:
- MUST set `closer_no_closee`.
- SHOULD NOT set `closer_and_closee`.
- Otherwise:
- MUST set both `closer_no_closee` and `closer_and_closee`.

The receiver of `closing_complete` (aka. "the closee"):
- If `fee_satoshis` is greater than the closer's outstanding balance:
- MUST either send a `warning` and close the connection, or send an `error` and fail the channel.
Comment on lines +865 to +867
Copy link
Contributor

Choose a reason for hiding this comment

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

Worth noting here that this introduces an edge case if we decide to rip out the original coop-close protocol. This would make it such that if you needed to coop-close the channel as the target of a channel-open that you would have no choice but to force close it. I think that everyone loses in this scenario.

Suggested change
The receiver of `closing_complete` (aka. "the closee"):
- If `fee_satoshis` is greater than the closer's outstanding balance:
- MUST either send a `warning` and close the connection, or send an `error` and fail the channel.
The receiver of `closing_complete` (aka. "the closee"):
- If `fee_satoshis` is greater than the closer's outstanding balance:
- MAY either send a `warning` and close the connection, or send an `error` and fail the channel.
- MAY choose to cover the deficit from their own output.

This way, if the closer tries to grief you by suggesting an insane fee, you can reject it, but otherwise if it's a fee you'd be willing to pay and it beats your fee liability if you have to force close, you come out ahead. Note that the only realistic scenario where this happens is if you just had a channel opened to you, received no inbound satsflow on the channel but you've decided to close the channel for whatever reason. In this case you may still want to be a good actor and coop-close the channel, but this construction (along with the removal of the existing coop-close) would force you to be more aggressive.

Copy link
Contributor

Choose a reason for hiding this comment

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

Withdrawn. I misunderstood some of the other aspects of this protocol.

- If `sequence` is equal to 0xFFFFFFFF:
- MUST either send a `warning` and close the connection, or send an `error` and fail the channel.
- Select a signature for validation:
- if the local output amount is dust:
- MUST use `closer_no_closee`.
- otherwise, if it considers the closee output amount uneconomic AND its `scriptpubkey` is not `OP_RETURN`:
- MUST use `closer_no_closee`.
- otherwise, if `closer_and_closee` is present:
- MUST use `closer_and_closee`.
- otherwise:
- MUST use `no_closer_closee`.
Comment on lines +875 to +878
Copy link
Collaborator

Choose a reason for hiding this comment

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

That is the gentleman's approach, but that isn't the most efficient one for the closee. If the closee receives a proposal that contains no_closer_closee, that is the option that pays the most fees, so the closee has an incentive to choose this one instead of closer_and_closee?

In practice though, if the sender sends no_closer_closee, they won't send closer_and_closee, so those cases are only theoretical?

Copy link
Collaborator

Choose a reason for hiding this comment

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

How can the sender even send no_closer_closee? IIUC, the side sending the closing_complete needs to pay for fees, so if they remove their output (it all goes to fees), then wouldn't they be better off just not sending the sig at all?

- If the selected signature field does not exist:
- MUST either send a `warning` and close the connection, or send an `error` and fail the channel.
- If the signature field is not valid for the corresponding closing transaction specified in [BOLT #3](03-transactions.md#closing-transaction):
- MUST ignore `closing_complete`.
rustyrussell marked this conversation as resolved.
Show resolved Hide resolved
- If the signature field is non-compliant with LOW-S-standard rule<sup>[LOWS](https://github.com/bitcoin/bitcoin/pull/6769)</sup>:
- MUST either send a `warning` and close the connection, or send an `error` and fail the channel.
- MUST sign and broadcast the corresponding closing transaction.
- MUST send `closing_sig` with a single valid signature in the same tlv field as the `closing_complete`.

The receiver of `closing_sig`:
- if `tlvs` does not contain exactly one signature:
- MUST either send a `warning` and close the connection, or send an `error` and fail the channel.
- if `tlvs` does not contain one of the tlv fields sent in `closing_complete`:
- MUST ignore `closing_sig`.
- if the signature field is not valid for the corresponding closing transaction specified in [BOLT #3](03-transactions.md#closing-transaction):
- MUST ignore `closing_complete`.
Copy link
Collaborator

Choose a reason for hiding this comment

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

Suggested change
- MUST ignore `closing_complete`.
- MUST ignore `closing_sig`.

- if the signature field is non-compliant with LOW-S-standard rule<sup>[LOWS](https://github.com/bitcoin/bitcoin/pull/6769)</sup>:
- MUST either send a `warning` and close the connection, or send an `error` and fail the channel.
- otherwise:
- MUST sign and broadcast the corrsponding closing transaction.
Copy link
Collaborator

Choose a reason for hiding this comment

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

Suggested change
- MUST sign and broadcast the corrsponding closing transaction.
- MUST sign and broadcast the corresponding closing transaction.


### Rationale

The close protocol is designed to avoid any failure scenarios caused by fee disagreement, since each side offers to pay its own desired fee.

If one side has less funds than the other, it may choose to omit its own output, and in this case dust MUST be omitted, to ensure the resulting transaction can be broadcast.

The corner case where fees are so high that both outputs are dust is addressed in two ways: paying a low fee to avoid the problem, or using an OP_RETURN (which is never "dust").

Note that there is usually no reason to pay a high fee for rapid processing, since an urgent child could pay the fee on the closing transactions' behalf.
Copy link

Choose a reason for hiding this comment

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

We could also mention RBF of the closing transaction here.

Copy link
Contributor

Choose a reason for hiding this comment

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

Also I fail to understand how we could ever have a transaction be urgent enough to push for confirmation if it involved burning all of the outputs in an OP_RETURN.


However, sending a new `shutdown` message overrides previous ones, so you can negotiate again (even changing the output address) if you want: in this case there's a race where you could receive a `closing_complete` for the previous output address, and the signature won't validate. In this case, ignoring the `closing_complete` is the correct behaviour, as the new `shutdown` will trigger a new `closing_complete` with the correct signature. This assumption that we only remember the last-sent of any message is why so many cases of bad signatures are simply ignored.
Copy link
Contributor

Choose a reason for hiding this comment

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

so you can negotiate again (even changing the output address) if you want

doesn't this override the safety feature of upfront shutdown?

Copy link
Collaborator

Choose a reason for hiding this comment

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

This is of course if you don't have upfront_shutdown activated, we can make that clearer.


If the closer proposes a transaction which will not relay (an output is dust, or the fee rate it proposes is too low), it doesn't harm the closee to sign the transaction.

Similarly, if the closer proposes a high fee, it doesn't harm the closee to sign the transaction, as the closer is paying.

There's a slight game where each side would prefer the other side pay the fee, and proposes a minimal fee. If neither side proposes a fee which will relay, the negotiation can occur again, or the final commitment transaction can be spent. In practice, the opener has an incentive to offer a reasonable closing fee, as they would pay the fee for the commitment transaction, which also costs more to spend.
Copy link

Choose a reason for hiding this comment

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

This discussion of the game theory hints at an issue I've always had with the "opener pays" rule. I do understand the pathological scenario that the rule is meant to avoid (where a malicious node can drain the funds of a victim node by repeatedly opening and abandoning channels to it), but this new proposal creates a perverse incentive.

Olav opens a channel to Kristján. Some time later, Kristján wants the channel closed. Under this new proposal, Kristján's fee-optimal channel-closing strategy would be to transmit a bogus error message to Olav so that Olav will be forced (by protocol convention) to unilaterally close the channel. Thusly, Kristján would obtain an immediately spendable output and would avoid paying any fees.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

That's always true.

But K can also mutual close at <1 sat per byte.

Copy link

Choose a reason for hiding this comment

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

How can any mutual closing transaction use <1 sat/vB fee rate? The transaction would not propagate.

And you're right that it's always true. It has always irked me. I swear I have seen some cases where nodes to which I have opened channels have sent me error messages for no reason other than to get me to unilaterally close. I think it was a design mistake to have commitment transactions reward the non-closing party with an immediately spendable output. I think commitment transactions should time-lock both outputs to discourage baiting a peer into unilaterally closing.

Copy link
Collaborator

Choose a reason for hiding this comment

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

That will disappear once we have package relay, because at that point commitment transactions will pay no fees. The fees will have to be paid using CPFP on an ephemeral anchor. Also, if you send bogus errors, nodes will start blacklisting you at some point and won't accept new channels from you: this isn't the case today, but will definitely be in the future.

Copy link

Choose a reason for hiding this comment

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

The opener should at least be on the hook for whatever the commitment fee is. Otherwise, as the non-opener, it's cheaper to FC and wait out the time lock. Also, if there's nothing on the non-opener side, is FC the only options since there's nothing on that side to pay the fee.

Copy link
Contributor

Choose a reason for hiding this comment

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

I want to challenge this idea of "it's cheaper to FC and wait out the time lock". Having money locked up carries opportunity cost of the entire output. Yes you may save in fees, but your outputs are tied up in chain resolution and that is a cost in its own right.

Also, if there's nothing on the non-opener side, is FC the only options since there's nothing on that side to pay the fee.

Why would a node be concerned about aggressively closing a channel that has no capital tied up in it?

Copy link

Choose a reason for hiding this comment

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

Current coop close is ~168 vB (2 x P2WPKH outputs) to ~192 vB (2 x P2TR outputs). Sweeping the timelock is 121-123 vB.. so ~35-50% smaller tx. I agree with the time cost, but if you are closing due to months of inactivity, what's another up to two weeks. But the opener would be doubly screwed since they would pay the FC (+ anchors) and then have to pay to sweep. I supposed the opener can "deter" this by keeping max commit fees low.

Closing channels should be discouraged, but having dead/inactive channel is worse.

In my mind, game theory would have me coop close at a very low fee if the balance is mostly on the other side or FC if it's mostly on my side and I'm not the opener and commit fee is high enough.

Why would a node be concerned about aggressively closing a channel that has no capital tied up in it?

More of a hypothetical.. how does a closer pay if there's little to nothing on their side.

I agree a change to channel closing is needed, but 100% opener to 100% closer is a pretty drastic change. I would like to see the opener using (some of) the commit fee already reserved and/or splitting the fee based on balance.


## Normal Operation

Once both nodes have exchanged `channel_ready` (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.
Expand Down
36 changes: 35 additions & 1 deletion 03-transactions.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -347,7 +347,9 @@ The witness script for the output is:

To spend this via penalty, the remote node uses a witness stack `<revocationsig> 1`, and to collect the output, the local node uses an input with nSequence `to_self_delay` and a witness stack `<local_delayedsig> 0`.

## Closing Transaction
## Classic Closing Transaction

This variant is used for `closing_signed` messages (i.e. where `option_simple_close` is not negotiated).

Note that there are two possible variants for each node.

Expand Down Expand Up @@ -388,6 +390,37 @@ has been used.
There will be at least one output, if the funding amount is greater
than twice `dust_limit_satoshis`.

## Closing Transaction

This variant is used for `closing_complete` and `closing_sig` messages (i.e. where `option_simple_close` is negotiated).

In this case, the node sending `closing_complete` ("the closer") pays the fees, and the sequence specified to allow RBF. The outputs are ordered as detailed in [Transaction Output Ordering](#transaction-output-ordering).

The side with lesser funds can opt to omit their own output.

* version: 2
* locktime: 0
* txin count: 1
* `txin[0]` outpoint: `txid` and `output_index` from `funding_created` message
* `txin[0]` sequence: `sequence` from `closing_complete` message
* `txin[0]` script bytes: 0
* `txin[0]` witness: `0 <signature_for_pubkey1> <signature_for_pubkey2>`

* txout count: 1 or 2
* The closer output:
* `txout` amount: the final balance for the closer, minus `closing_complete` `fee_satoshis`, rounded down to whole satoshis.
* `txout` script: as specified in that closer's `scriptpubkey` in its `shutdown` message
* The closee output:
* `txout` amount: the final balance for the closee, rounded down to whole satoshis.
* `txout` script: as specified in that closee's `scriptpubkey` in its `shutdown` message

### Requirements

Each node offering a signature:
- MUST round each output down to whole satoshis.
- MUST subtract the fee given by `fee_satoshis` from the closer output.


## Fees

### Fee Calculation
Expand Down Expand Up @@ -505,6 +538,7 @@ Bitcoin Core defines the following dust thresholds:
- pay to witness pubkey hash (p2wpkh): 294 satoshis
- pay to witness script hash (p2wsh): 330 satoshis
- unknown segwit versions: 354 satoshis
- `OP_RETURN` outputs: these are never dust

The rationale of this calculation (implemented [here](https://github.com/bitcoin/bitcoin/blob/0.21/src/policy/policy.cpp))
is explained in the following sections.
Expand Down
2 changes: 2 additions & 0 deletions 09-features.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -48,6 +48,7 @@ The Context column decodes as follows:
| 46/47 | `option_scid_alias` | Supply channel aliases for routing | IN | | [BOLT #2][bolt02-channel-ready] |
| 48/49 | `option_payment_metadata` | Payment metadata in tlv record | 9 | | [BOLT #11](11-payment-encoding.md#tagged-fields) |
| 50/51 | `option_zeroconf` | Understands zeroconf channel types | IN | `option_scid_alias` | [BOLT #2][bolt02-channel-ready] |
| 60/61 | `option_simple_close` | Simplified closing negotiation | IN | `option_shutdown_anysegwit` | [BOLT #2][bolt02-simple-close] |
rustyrussell marked this conversation as resolved.
Show resolved Hide resolved

## Definitions

Expand Down Expand Up @@ -96,6 +97,7 @@ This work is licensed under a [Creative Commons Attribution 4.0 International Li

[bolt02-retransmit]: 02-peer-protocol.md#message-retransmission
[bolt02-open]: 02-peer-protocol.md#the-open_channel-message
[bolt02-simple-close]: 02-peer-protocol.md#closing-negotiation-closing_complete-and-closing_sig
[bolt03-htlc-tx]: 03-transactions.md#htlc-timeout-and-htlc-success-transactions
[bolt02-shutdown]: 02-peer-protocol.md#closing-initiation-shutdown
[bolt02-channel-ready]: 02-peer-protocol.md#the-channel_ready-message
Expand Down