[PATCH] First draft of option_simplfied_commitment

Summary:

Matt Corallo and Rusty Russell were discussing the implementation of a policy hack for Lightning Network in November 2018. The idea was to allow the carve-out exception of "last tx in a package, which has only one unconfirmed ancestor" to always be available for the "honest party" when broadcasting a commitment transaction. A CSV delay of 1 block on HTLC transaction outputs is necessary for implementing this policy as otherwise those transactions could count as the carve-out tx. The option is sticky and fixed at open time. The feerate is treated as 253 for all transactions if `option_simplified_commitment` is negotiated.Closing tx negotiates upwards not downwards starting from base fee of commitment tx = 282 satoshi. To_remote output is always CSV delayed. Pushme outputs are paid for by funder but only exist if the matching to_local/remote output exists. After 10 blocks, they become anyone-can-spend. Remotepubkey is not rotated. You must spend your pushme output, but you may sweep for others.The `feerate_per_kw` is generally only of concern to the sender (who pays the fees), but there is also the fee rate paid by HTLC transactions; thus, unreasonably large fee rates can also penalize the recipient, although it is ignored for `option_simplified_commitment`. Separating the `htlc_basepoint` from the `payment_basepoint` improves security: a node needs the secret associated with the `htlc_basepoint` to produce HTLC signatures for the protocol, but the secret for the `payment_basepoint` can be in cold storage.Both peers need to negotiate `option_simplified_commitment`. If it is negotiated, it applies to all commitment and HTLC transactions, otherwise, it does not apply to any commitment or HTLC transactions. The sender must set `channel_id` by exclusive-OR of the `funding_txid` and the `funding_output_index` from the `funding_created` message. The recipient should broadcast the funding transaction on receipt of a valid `funding_signed`. The `funding_locked` message in Lightning Network indicates that the funding transaction has reached the minimum depth asked for in `accept_channel`. Once both nodes have sent this, the channel enters normal operating mode.The funding node should send a `closing_signed` message. The sending node must set `fee_satoshis` less than or equal to the base fee of the final commitment transaction as calculated in BOLT #3. In case `option_upfront_shutdown_script` applies to the final commitment transaction, the sending node must set `fee_satoshis` greater than or equal to 282, otherwise, it must set `fee_satoshis` less than or equal to the base fee of the final commitment transaction, as calculated in BOLT #3. During normal operation, a sending node must not offer `amount_msat` it cannot pay for in the remote commitment transaction at the current `feerate_per_kw` while maintaining its channel reserve. 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. A receiving node can fail the channel if it receives an `amount_msat` equal to zero or less than its own `htlc_minimum_msat`, or 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.An `update_fee` message is sent by the node which is paying the Bitcoin fee. If `option_simplified_commitment` applies to the commitment transaction, `update_fee` is never used, but the funder also pays 2000 satoshi for the `to_local_pushme` and `to_remote_pushme` outputs. If not, the node responsible for paying the Bitcoin fee should send `update_fee` to ensure the current fee rate is sufficient (by a significant margin) for timely processing of the commitment transaction. Fee adjustments are unnecessary for `option_simplified_commitment`, which relies on "pushme" outputs and a child transaction that will provide additional fee incentive. Without this option, bitcoin fees are required for unilateral closes to be effective.The separate transaction stage for HTLC outputs allows for timeout or fulfillment of HTLCs even if they are within the 'to_self_delay' delay. The 'to_local' and 'to_remote' outputs of the commitment transaction must be rounded down to whole satoshis, and if this amount minus the fees for the HTLC transaction is less than the dust limit satoshis set by the owner of the commitment transaction, the output must not be produced.

Updated on: 2023-05-20T09:18:40.228011+00:00