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.

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

WIP: First draft of option_simplfied_commitment: #513

Open
wants to merge 8 commits into
base: master
from

Conversation

Projects
None yet
4 participants
@rustyrussell
Copy link
Collaborator

rustyrussell commented Nov 21, 2018

  • 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.

New:

  • Subsume option_dataloss_protect, always send last revocation secret.

Signed-off-by: Rusty Russell rusty@rustcorp.com.au

First draft of option_simplfied_commitment:
- 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 <rusty@rustcorp.com.au>

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

This comment has been minimized.

@halseth

halseth Nov 21, 2018

Contributor

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?

This comment has been minimized.

@rustyrussell

rustyrussell Nov 22, 2018

Collaborator

Updated. Thanks!

rustyrussell added some commits Nov 22, 2018

BOLT3: Explain rationale behind pushme scripts.
Reported-by: @halseth
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Add sighash flags for HTLC transactions, notes on handling.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

#### `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.

This comment has been minimized.

@TheBlueMatt

TheBlueMatt Dec 3, 2018

Contributor

"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.

This comment has been minimized.

@rustyrussell

rustyrussell Dec 10, 2018

Collaborator

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...

@@ -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:

This comment has been minimized.

@TheBlueMatt

TheBlueMatt Dec 3, 2018

Contributor

The receiving node section also needs updating here?

This comment has been minimized.

@rustyrussell

rustyrussell Dec 10, 2018

Collaborator

Good catch. I also used the wrong option name here, both fixed...

rustyrussell added some commits Dec 10, 2018

Complete specification of closing protocol.
Receiving side also needed updating, and wrong option name was used.

Reported-by: @TheBlueMatt
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
BOLT 2: subsume option_data_loss_protect if option_simplified_commitm…
…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 <rusty@rustcorp.com.au>
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`).

This comment has been minimized.

@araspitzu

araspitzu Dec 19, 2018

Contributor

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.

This comment has been minimized.

@araspitzu

araspitzu Jan 10, 2019

Contributor

Nit: wasn't that meant to be 'greater than 282'?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment