Author: Rusty Russell 2019-03-14 23:55:02
Published on: 2019-03-14T23:55:02+00:00
In this update, Rusty Russell has suggested splitting up option_simplified_commitment since it is fairly ambitious. Roasbeef wanted the static remote_key feature as soon as possible and Christian agreed. The author chose to add the symmetric output which affects the same output and resolves the gaming around "no, you close please, no you close". There is no PR yet, but the link is available in the mentioned Github commit.The article explains that `option_static_remotekey` applies to all commitment transactions if it was negotiated, otherwise, it does not apply to any commitment transactions. The `channel_id` identifies the channel, and it's derived from the funding_txid and the funding_output_index from the funding_created message. The sender must set `channel_id` by exclusive-OR, and the recipient must broadcast the funding transaction on receipt of a valid funding_signed.The article further explains that we decide on `option_static_remotekey` when we first have to generate the commitment transaction. Even if a later reconnection does not negotiate this parameter, this channel will honor it. This simplifies channel state, particularly penalty transaction handling. The article also describes the option of fall-behind detection with the addition of `option_static_remotekey`. It removes the changing `to_remote` key, so the `my_current_per_commitment_point` is unnecessary and thus removed. However, the disclosure of previous secret still allows fall-behind detection. An implementation can offer both, however, and fall back to the `option_data_loss_protect` behavior if `option_simplified_commitment` is not negotiated.Finally, the article explains that the `to_remote` output sends funds to the other peer and is not encumbered by a revocation private key. If `option_static_remotekey` applies to the commitment transaction, the `to_remote` output is delayed similarly to the `to_local` output, and is to a fixed key. Otherwise, this output is a simple P2WPKH to `remotepubkey`.The document provides details on the expected weights and fees for commitment transactions in the Lightning Network. The base fee for a commitment transaction depends on the `feerate_per_kw` and the number of untrimmed HTLC outputs. The document provides an example of how to calculate the fee for a given scenario. The base commitment transaction fees and amounts for `to_local_pushme` and `to_remote_pushme` outputs are extracted from the funder's amount.The keys used in each commitment transaction are unique and derived using per-commitment secrets that are generated from a single seed. The expected weight of a commitment transaction is calculated based on the number of HTLC outputs and the type of output. Finally, the derivation of `remotepubkey` and `revocationpubkey` is explained.
Updated on: 2023-06-01T18:09:27.030062+00:00