[PATCH] First draft of option_simplfied_commitment

Summary:

The Lightning Network protocol is used to enable fast and cheap transactions on top of the Bitcoin blockchain. It involves the creation of a payment channel between two parties using a commitment transaction, with each party committing funds to the channel. A key feature in this process is `option_simplified_commitment`, which simplifies penalty transaction handling and reduces channel state complexity. When both nodes have sent a `funding_locked` message indicating that the funding transaction has reached the minimum depth asked for in `accept_channel`, channels enter normal operating mode. Negotiating fees and updating them with `update_fee` messages are also specified in the document. The fee calculation for both commitment transactions and Hashed Timelock Contracts (HTLCs) 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 for several reasons, so a simplified formula for *expected weight* is used, which assumes that signatures are 73 bytes long, there are a small number of outputs, and there are always both a `to_local` output and a `to_remote` output. If `option_simplified_commitment` applies, there are always both a `to_local_pushme` and `to_remote_pushme` output. Commitment transactions have six types of outputs - local node's main output, delayed pubkey, remote node's main output, remote node's push output, local node's push output, and HTLCs. The local and remote nodes each hold a commitment transaction, which has four types of outputs without `option_simplified_commitment`. However, if `option_simplified_commitment` applies to the commitment transaction, then the to_remote output of each commitment is identically encumbered for fairness. If a node wants to spend any `to_local_pushme` output, it must provide sufficient fees as an incentive to include the commitment transaction in a block. The node should use replace-by-fee or other mechanisms on the spending transaction if it proves insufficient for timely inclusion in a block. A node may monitor the blockchain for unspent `to_local_pushme` and `to_remote_pushme` outputs and try to spend them after 10 confirmations.The document also specifies the requirements for sending and receiving payments using HTLCs. A sending node must not offer an `amount_msat` it cannot pay for in the remote commitment transaction at the current `feerate_per_kw`. If `option_simplified_commitment` applies to this commitment transaction and the sending node is the funder, it must be able to additionally pay for `to_local_pushme` and `to_remote_pushme` above its reserve. Offered and received HTLC outputs can timeout or be fulfilled even though they are within the `to_self_delay` delay.Finally, the document outlines the requirements for closing channels. The closing transaction should pay a premium fee, but there is limited risk if the closing transaction is delayed. Nodes should fail the channel if they receive an `amount_msat` equal to 0 or less than their own `htlc_minimum_msat`, or if they receive 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.

Updated on: 2023-05-20T09:08:14.884029+00:00