[PATCH] First draft of option_simplfied_commitment

Summary:

The Lightning Network development team is currently working on implementing the RBF policy hack from Adelaide. To ensure that the carve-out exception of "last tx in a package, which has only one unconfirmed ancestor" is always available for the "honest party" when broadcasting a commitment transaction, they need at least a CSV delay of 1 block on the HTLC transaction outputs. Rusty Russell is starting to implement this and he provided an original version of the code on Github. When constructing commitment transactions and HTLC transactions, the fee calculation for both types of transactions is based on the current `feerate_per_kw` and the expected weight of the transaction. If `option_simplified_commitment` applies to the commitment transaction, then `feerate_per_kw` is 253. The expected weights vary due to DER-encoded signatures, number of outputs, and presence of `to_local_pushme` and `to_remote_pushme` outputs. After calculating the base commitment transaction fee, it is subtracted from the funder's output.The commitment transaction uses unique keys derived from a per-commitment secret generated from a seed. Keys are generated by addition from their base points: `localpubkey`, `local_htlcpubkey`, `remote_htlcpubkey`, `local_delayedpubkey`, and `remote_delayedpubkey`. The `remotepubkey` is calculated using the remote node's `payment_basepoint` unless `option_simplified_commitment` is negotiated, in which case it is simply the remote node's `payment_basepoint`. The `revocationpubkey` is a blinded key derived from the local node's `revocation_basepoint`.The commitment transaction includes offered HTLC outputs and received HTLC outputs. If the `to_local` amount is greater or equal to `dust_limit_satoshis`, a `to_local` output is added. Similarly, if the `to_remote` amount is greater or equal to `dust_limit_satoshis`, a `to_remote` output is added. If `option_simplified_commitment` applies to the commitment transaction, `to_local_pushme` and `to_remote_pushme` are also added. Outputs are sorted into BIP 69 order.If the commitment transaction is 10 blocks deep, anyone can spend it. The expected weight of a commitment transaction is calculated based on the size of different types of outputs. The transaction has four types of outputs without `option_simplified_commitment`, and six with it. These include the local and remote nodes' main outputs, 0 or 1 push outputs for each node, and 0 or more HTLCs for each node. The transaction is encumbered by an `OP_CHECKSEQUENCEVERIFY` relative timeout on some outputs, depending on whether `option_simplified_commitment` applies.The purpose of `option_simplified_commitment` is to simplify commitment transactions, making them easier to manage and less expensive. Without `option_simplified_commitment`, the commitment transaction may require a child transaction to cause it to be mined. When sending or receiving an amount in a channel, there are certain rules that must be followed. One must not offer more than what they can pay for in the remote commitment transaction at the current `feerate_per_kw`, while maintaining their channel reserve. If `option_simplified_commitment` applies to this commitment transaction and the sending node is the funder, they must be able to additionally pay for `to_local_pushme` and `to_remote_pushme` above their reserve. Otherwise, they must offer an amount greater than 0, and not below the receiving node's `htlc_minimum_msat`. If the sender offers an amount that they cannot afford at the current `feerate_per_kw` (while maintaining their channel reserve and any `to_local_pushme` and `to_remote_pushme` fees), the channel should be failed. Bitcoin fees are required for unilateral closes to be effective, particularly since there is no general method for the broadcasting node to use child-pays-for-parent to increase its effective fee. Fee adjustments are unnecessary for `option_simplified_commitment` which relies on "pushme" outputs and a child transaction which will provide additional fee incentive which can be calculated at the time it is spent, and replaced by higher-fee children if required.There are also `to_local_pushme` and `to_remote_pushme` outputs which 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. A node may spend any `to_local_pushme` output, providing sufficient fees as incentive to include the commitment transaction in a block. It should use replace-by-fee or other mechanisms on the spending transaction if it proves insufficient for timely inclusion in a block.

Updated on: 2023-05-20T09:12:13.762800+00:00