WIP: First draft of option_simplified_commitment: #513
Conversation
- Option is sticky; it set at open time, it stays with channel - I didn't want to have to handle penalty txs on channels which switch - We could, however, upgrade on splice. - Feerate is fixed at 253 - `feerate_per_kw` is still in open /accept (just ignored): multifund may want it. - closing tx negotiates *upwards* not *downwards* - Starting from base fee of commitment tx = 282 satoshi. - to_remote output is always CSV delayed. - pushme outputs are paid for by funder, but only exist if the matching to_local/remote output exists. - After 10 blocks, they become anyone-can-spend (they need to see the to-local/remote witness script though). - remotepubkey is not rotated. - You must spend your pushme output; you may sweep for others. Signed-off-by: Rusty Russell <[email protected]>
03-transactions.md
Outdated
|
|
||
| The `<pubkey>` is `<local_delayedpubkey>` to `to_local_pushme` and | ||
| `<remote_delayedpubkey>` for `to_remote_pushme`. The output amount is | ||
| 1000 satoshi, to encourage spending of the output. Once the |
There was a problem hiding this comment.
Can you add a rationale for these two ways of spending it?
- Why not only let the output's owner spend it?
- Why not let anybody spend it always, with no timelock?
There was a problem hiding this comment.
Updated. Thanks!
Reported-by: @halseth Signed-off-by: Rusty Russell <[email protected]>
Signed-off-by: Rusty Russell <[email protected]>
|
|
||
| #### `to_local_pushme` and `to_remote_pushme` Output (option_simplified_commitment) | ||
|
|
||
| This output can be spent by the local and remote nodes respectively to provide incentive to mine the transaction, using child-pays-for-parent. They are only added if the `to_local` and `to_remote` outputs exist, respectively. |
There was a problem hiding this comment.
"They are only added if the to_local and to_remote outputs exist, respectively." Hmmmm...I think we need to move to a world where dust limit must be <= channel_reserve + fee on commitment tx, then. If you imagine adding a number of HTLCs to increase the absolute fee and then add a large HTLC it could drop the to_local/to_remote output, but you'll still need to be able to get the tx confirmed using CPFP to broadcast it on HTLC timeout/claim.
There was a problem hiding this comment.
So, 'funder must keep >= dust-limit + worst-case commitment tx fees'? (as well as the standard reserve requirements)? This would mean that even if fundee adds 483 HTLCs at once (a case which currently can potentially dip into funders' reserves to pay fees) the funder's output would not be dust.
This is probably OK with the minimal feerate proposed here (21323 satoshi), but @Roasbeef wanted to separate "fixed minimal fee" from "simplified commitment" option so we weren't so reliant on propagation changes to make this work. But I guess in that case we could ignore this corner case anyway...
02-peer-protocol.md
Outdated
| @@ -508,8 +523,11 @@ The funding node: | |||
| - SHOULD send a `closing_signed` message. | |||
|
|
|||
| The sending node: | |||
| - MUST set `fee_satoshis` less than or equal to the | |||
| base fee of the final commitment transaction, as calculated in [BOLT #3](03-transactions.md#fee-calculation). | |||
| - if `option_upfront_shutdown_script` applies to the final commitment transaction: | |||
There was a problem hiding this comment.
The receiving node section also needs updating here?
There was a problem hiding this comment.
Good catch. I also used the wrong option name here, both fixed...
Receiving side also needed updating, and wrong option name was used. Reported-by: @TheBlueMatt Signed-off-by: Rusty Russell <[email protected]>
…ent. It's no pain to include `your_last_per_commitment_secret` field, so make it compulsory, but otherwise option_simplified_commitment overrides option_data_loss_protect. Signed-off-by: Rusty Russell <[email protected]>
| transaction itself are minimal (it is assumed that a child transaction will | ||
| supply additional fee incentive), so that forms a floor for negotiation. | ||
| [BOLT #3](03-transactions.md#fee-calculation), gives 282 satoshis (1116 | ||
| weight, 254 `feerate_per_kw`). |
There was a problem hiding this comment.
Shouldn't this be 253 feerate_per_kw instead of 254? 254 doesn't seem consistent with the calculation (yields 283 satoshis) and with the previous logic (253 for all commitment transactions).
| [BOLT #3](03-transactions.md#fee-calculation): | ||
| - MUST fail the connection. | ||
| - if `option_simplified_commitment` applies to the final commitment transaction: | ||
| - if `fee_satoshis` greater less than 282. |
There was a problem hiding this comment.
Nit: wasn't that meant to be 'greater than 282'?
|
Can you elaborate on "closing tx negotiates upwards not downwards"? It would be nice to expand on its negotiation when option_simplified_commitment is in use, maybe in closing_signed. |
|
Is a bit unclear where do the pushme_outputs go in the case of a cooperative close, will they be returned to the funder? |
cdecker
changed the title
cdecker
changed the title
feerate_per_kwis still in open /accept (just ignored): multifund may want it.to_local/remote output exists.
to-local/remote witness script though).
New:
Signed-off-by: Rusty Russell [email protected]