Commitment Transaction Format Update Proposals

Commitment transactions are huge part of the penalty system Lightning enforces to make sure everyone plays nicely with one another, it make sure that if someone in the channel broadcasts an older transaction, thus trying to scam the other party, the commitment transaction will allow the first party access to the scamming party’s coins.

There were recently a few proposals to edit the commitment transaction, mainly the edits are about the format. Making the CLTV timeout symmetrical to avoid trying to pressure the peer into closing, making the remotepubkey BIP-32 styled and using the OP-TRUE style output to allow Child Pays For Parent fee dependancy.


Rusty Russell Thu, 11 Oct 2018 21:58:02 -0700

Hi all,

There have been a number of suggested changes to the commitment
transaction format:

1. Rather than trying to agree on what fees will be in the future, we
   should use an OP_TRUE-style output to allow CPFP (Roasbeef)
2. The `remotepubkey` should be a BIP-32-style, to avoid the
   option_data_loss_protect "please tell me your current
   per_commitment_point" problem[1]
3. The CLTV timeout should be symmetrical to avoid trying to game the
   peer into closing. (Connor IIRC?).

It makes sense to combine these into a single `commitment_style2`
feature, rather than having a testing matrix of all these disabled and
enabled.

BOLT #2:

- If `commitment_style2` negotiated, update_fee is a protocol error.

This mainly changes BOLT #3:

- The feerate for commitment transactions is always 253 satoshi/Sipa.
- Commitment tx always has a P2WSH OP_TRUE output of 1000 satoshi.
- Fees, OP_TRUE are always paid by the initial funder, because it's simple,
  unless they don't have funds (eg. push_msat can do this, unless we remove it?)
- HTLC-timeout and HTLC-success txs sigs are 
  SIGHASH_ANYONECANPAY|SIGHASH_SINGLE, so you can Bring Your Own Fees.
- `localpubkey`, `remotepubkey`, `local_htlcpubkey`,
  `remote_htlcpubkey`, `local_delayedpubkey`, and `remote_delayedpubkey`
  derivation now uses a two-stage unhardened BIP-32 derivation based on
  the commitment number.  Two-stage because we can have 2^48 txs and
  BIP-32 only supports 2^31: the first 17 bits are used to derive the
  parent for the next 31 bits?
- `to_self_delay` for both sides is the maximum of either the
  `open_channel` or `accept_channel`.
- `to_remote` is now a P2WSH of:
        `to_self_delay` OP_CSV OP_DROP  OP_CHECKSIG

Comments powered by Talkyard.