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