Published on: 2020-01-22T07:41:26+00:00
In a recent email thread, Lightning Network developers discussed the implementation of anchor outputs and their impact on channel opening and closing. The dust limit for Segwit outputs is currently set at 294 satoshis, assuming three times the minfee. Anchor outputs, which are currently set at 294 satoshis, are spendable and cost $3 each if BTC reaches $1M. However, there is a suggestion to lower the anchor size if the BTC/fiat price rises and lowers the dust limit to prevent giving away too much free money.The complexity of the Lightning Network protocol is a concern, and it is suggested to simplify the state machine instead of adding more complexity. One proposal is to introduce a new parameter in the channel opening sequence to set the anchor size, keeping all options open and avoiding future changes.The dust limit exists to prevent non-economical UTXOs from filling the UTXO set when feerates are low. The dust limit is not expected to rise unless the BTC/fiat price drops significantly. Dust limits could decrease or be removed, but this would not affect anchor outputs. It is advised to create anchor outputs that are economical to spend and require negotiable output amounts to compensate for fee rate fluctuations.There is a discussion about the possibility of channels getting stuck due to unbalanced transactions and the use of a hard-coded constant for dust relay fee. To adapt to changes in dustRelayFee, two options are proposed: adding a new anchor_msat field or reusing `dust_limit_satoshis` as the anchor size. It is also suggested to put an anchor output limit of 294 satoshis directly into the spec to avoid potential risks.In terms of commitment transactions, there will never be a commitment tx where the non-initiator pays fees. However, channels can get stuck if there is no reasonable balance. The concern is raised about the possibility of `dustRelayFee` changing in the future, making the hard-coded 294 sat anchors risky for opening new channels. Various proposals are discussed, including each side paying for their own anchor output and rotating anchors. The idea of reusing funding keys for the anchor output is also mentioned.The implementation of anchor outputs and key rotation in the Lightning Network is a topic of discussion. The need for both parties to pay for their own anchors, the dust limit negotiated in the open_channel or accept_channel message, and the possibility of stuck channels are all considered. Suggestions are made to make payment for anchors before fees and to avoid a hard-coded constant for dustRelayFee. The idea of each side paying for their own anchor output and rotating anchors is proposed, along with the suggestion of reusing funding keys for the anchor output.In an email exchange, the Lightning Network developers discuss the implementation of anchor outputs and the possibility of using distinct values. The issue of unbalanced transactions and the use of a hard-coded constant for dust relay fee is raised. It is suggested to introduce a new parameter in the channel opening sequence to set the anchor size and avoid future changes. The possibility of channels getting stuck and the need to adapt to changes in dustRelayFee are also discussed. The idea of reusing `dust_limit_satoshis` or adding a new `anchor_msat` field in the opening messages is proposed. The conversation also touches on the proposal to reuse funding keys for the anchor output to simplify the process.The discussion also includes the proposal of a new commitment format for Lightning Network channels. There is a debate about using a single "to_self_delay" value or allowing distinct values. It is agreed that negotiation during the opening phase is not feasible, but a unification proposal suggests using the maximum of the two settings. The use of anchor outputs and the concerns about insufficient fees and stuck channels are also addressed. The possibility of using a hard-coded constant for dustRelayFee is opposed, and the idea of each side paying for its own anchor output is suggested.The conversation delves into the details of using anchor outputs in the Lightning Network. The possibility of negotiation during the opening phase is discussed, along with the concern of channels getting stuck due to unbalanced transactions. The need for key rotation to prevent watchtower hacks is also addressed. Several proposals are made, including reusing funding keys for the anchor output and simplifying the process by sticking with the original design. The issue of adapting to changes in dustRelayFee is also raised, with suggestions to reuse `dust_limit_satoshis` or add a new `anchor_msat` field in the opening messages.In a mailing list conversation between Rusty Russell and Joost Jager, proposed changes to the Bitcoin rules for Lightning Network's commitment transactions were discussed. One suggestion was to add `1 OP_CHECKSEQUENCEVERIFY OP_DROP` to the non-revocation clause of the HTLC outputs.
Updated on: 2023-07-31T20:52:13.722504+00:00