Skip to content

BOLT 2: closing tx fee clarifications #194

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

Merged
rustyrussell merged 2 commits into from
Jul 11, 2017
Merged

BOLT 2: closing tx fee clarifications #194

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
91ae099
BOLT 2: make it clear that we set fee, *then* eliminate outputs.
rustyrussell Jun 28, 2017
b8d22e5
BOLT 2: closing fee is based on final commitment "base fee" not actua…
rustyrussell Jun 30, 2017
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
6 changes: 3 additions & 3 deletions 02-peer-protocol.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -408,15 +408,15 @@ Nodes SHOULD send a `closing_signed` message after `shutdown` has
been received and no HTLCs remain in either commitment transaction.

A sending node MUST set `fee_satoshis` lower than or equal to the
fee of the final commitment transaction.
base fee of the final commitment transaction as calculated in [BOLT #3](03-transactions.md#fee-calculation).

The sender SHOULD set the initial `fee_satoshis` according to its
estimate of cost of inclusion in a block.

The sender MUST set `signature` to the Bitcoin signature of the close
transaction with the node responsible for paying the bitcoin fee
paying `fee_satoshis`, without populating any output which is below
its own `dust_limit_satoshis`. The sender MAY also eliminate its own
paying `fee_satoshis`, then removing any output which is below
its own `dust_limit_satoshis`. The sender MAY then also eliminate its own
Copy link
Copy Markdown
Collaborator

@pm47 pm47 Jul 3, 2017 •
edited
Loading

Choose a reason for hiding this comment

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

My brain hurts... 😣

Doesn't this invalidate the second either clause of the following paragraph?

Copy link
Copy Markdown
Contributor

@halseth halseth Jul 5, 2017

Choose a reason for hiding this comment

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

To me this reads as "create signature for transaction before removing output" ... "then remove the output".

Wouldn't it be better to add something similar to your comment, @rustyrussell: "we calculate fee then remove outputs, not remove outputs then calculate fee." That is much less ambiguous :)

Copy link
Copy Markdown
Collaborator

@Roasbeef Roasbeef Jul 10, 2017

Choose a reason for hiding this comment

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

Agreed that this paragraph is pretty confusing. Here's a slightly re-worked version that I think we'll all find mouc more explicit:

The sender MUST set signature to the Bitcoin signature of the channel
closure transaction. The set fee_satoshi fee should be subtracted from
the output of the node that was responsible for paying the bitcoin fees
during the lifetime of the channel. When calculating the amount of
satoshis to subtract from the fee payer's output the absolute fee should
be calculated first, then any trimmed outputs removed. Each trimmed output
should contribute to (reduce the) the fee value explicitly subtracted from
the fee payer's output. The sender MAY also eliminate its own output
from the mutual close transaction.

Copy link
Copy Markdown
Collaborator Author

@rustyrussell rustyrussell Jul 11, 2017

Choose a reason for hiding this comment

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

@Roasbeef Hmm, that's backwards from what I meant. Trimming dust doesn't change inputs, so yeah, it effectively ups the fee paid. This is the same logic we use for commit txs.

But as agreed, will merge, and then the move to BOLT 3, and re-open another PR for clarification if we still need it...

output from the mutual close transaction.

The receiver MUST check `signature` is valid for either the close
Expand Down