[PATCH] First draft of option_simplfied_commitment

Summary:

The Lightning Network protocol has specific rules for channel management that include negotiation of transaction fees between nodes. Fees on the commitment transaction are minimal in the `option_simplified_commitment` case but typically pay a premium fee otherwise. Negotiation restarts on reconnection to avoid keeping state and to handle corner cases where fees have shifted. Each commitment transaction uses a unique set of keys generated from a series of per-commitment secrets that are generated from a single seed to improve network performance.The HTLC-success and HTLC-timeout transactions use `local_delayedpubkey` and `revocationpubkey`. This key change is to enable trustless watching for revoked transactions. Changing the `localpubkey` every time ensures that the commitment transaction ID cannot be guessed except in the trivial case where there is no `to_local` output, as every commitment transaction uses an ID in its output script. The sending node is required to set the initial `fee_satoshis` according to its estimate of the cost of inclusion in a block and MUST set signature to the Bitcoin signature of the close transaction. The `channel reserve` is specified by the peer's `channel_reserve_satoshis`, which is 1% of the channel capacity but can be set as high as 16777216 satoshis. If `option_simplified_commitment` applies to all commitment and HTLC transactions, it will apply; otherwise, it does not apply to any commitment or HTLC transactions. The funding transaction becomes valid once both nodes have sent a `funding_locked` message.If `option_upfront_shutdown_script` applies to the final commitment transaction, the sender must set `fee_satoshis` greater than or equal to 282. Otherwise, the sender must set `fee_satoshis` less than or equal to the base fee of the final commitment transaction. The to_remote output sends funds to the other peer and is a simple P2WPKH to `remotepubkey`. The `to_local` output sends funds to the local wallet and encumbers the output with an absolute CSV-delayed (CSV) spend by the remote node's revocation key. To update fees, an `update_fee` message is sent by the node responsible for paying the Bitcoin fee. If `option_simplified_commitment` applies to the commitment transaction, then `update_fee` is never used. If the commitment transaction does not use this option, the node should send `update_fee` to ensure the current fee rate is sufficient, by a significant margin, for timely processing of the commitment transaction. Otherwise, it should not send `update_fee`.A receiving node should fail the channel if it receives an `amount_msat` equal to 0 or less than its own `htlc_minimum_msat`. It should also fail the channel if it receives an `amount_msat` that the sending node cannot afford at the current `feerate_per_kw`, while maintaining its channel reserve and any `to_local_pushme` and `to_remote_pushme` fees. A receiving node must not update the `feerate_per_kw` if `option_simplified_commitment` applies to the commitment transaction. It should fail the channel if the `update_fee` is too low for timely processing OR is unreasonably large.The Lightning Network protocol specifies that each commitment transaction should use a unique set of keys generated from a series of per-commitment secrets that are generated from a single seed to improve network performance. The `to_remote` output is delayed similarly to the `to_local` output if `option_simplified_commitment` applies to the commitment transaction. The `to_remote` output is delayed by `to_self_delay` OP_CSV OP_DROP and spent by a transaction with the `nSequence` field set to `to_self_delay` (which can only be valid after that duration has passed) and witness.

Updated on: 2023-05-25T17:34:21.380684+00:00