Published on: 2018-06-18T09:22:07+00:00
The current discussion surrounding Bitcoin transactions focuses on the minimum relay fee imposed. Currently, there is a minimum fee of 1000 sat/kbyte, regardless of dynamic blockchain conditions. This poses problems for dynamic fee-paying later on. One issue that arises is when fees are based on having a full week to close a channel, as the default minimums do not account for this. Implementing better dynamic fee systems may require a blockchain-level softfork. However, the SegWit block size increase can help maintain low fees until a more efficient system is developed.There have been instances of channel failures between lnd and c-lightning. This is due to the fact that c-lightning enforces an absolute minimum fee, which results in reduced channel failure if lnd supports the same minimum. Another concern raised in the discussion is the reluctance of nodes to relay Bitcoin transactions if the fees are too low. The Lightning Network has encountered a specific issue with the minimum fee rate of 250 sat/ksipa, which is not accepted by bitcoind nodes. This has caused problems for C-lightning, as they unilaterally close when the counterparty proposes a 250sat/ksipa feerate. Eclair has also faced this issue and has implemented the same solution as C-lightning. Ucoin has a constant of 253 somewhere. On the other hand, lnd and lit have not imposed any minimums, but it is unclear if they have experienced issues with 250 sat/ksipa transactions being propagated on the Bitcoin-level network. Nodes dynamically regulate their minimum fee rates based on the size of their mempools, and even a value of 253 may be too low if there is a large fee spike. To manage these fee issues, utilizing a permanent op_true output seems to be the most viable solution. However, dynamic minimum relay fees present a problem, as many nodes may choose not to relay transactions if the fee is too low. Even with the default 300 MB mempool setting, only about 150 blocks worth of transactions can fit. Another issue arises from the difference in fee computation between Bitcoind and the BOLT spec. C-lightning, Eclair, and ucoin have all implemented a minimum feerate of 253 sat/ksipa to avoid rejection by Bitcoind. However, lnd uses vsize internally for all fee estimation and does not impose this minimum. The current version of Satoshi's client dynamically regulates its minimum fee rate, so setting a static fee floor is only a temporary measure. Utilizing a permanent op_true output seems to be the best solution without liberal sighash flags, although it has its own issues. A feerate of 250 sat/kweight is too low for Bitcoin to broadcast and process in a timely manner. If an attack occurs or nodes have small mempools, even a value of 253 may be too low. In such cases, nodes should fail the channel if the update_fee is too low or unreasonably large. Unilateral closure not only incurs on-chain fees sweeping but also delays due to time locks.In conclusion, C-lightning has imposed a minimum feerate of 253 sat/ksipa due to differences in fee computation between BOLT specifications and bitcoind. This divergence in fee computation causes issues when the counterparty proposes a 250sat/ksipa feerate, leading to unilateral closure. Although C-lightning has recently expanded its ranges, the 253sat/ksipa limit remains a hard limit that triggers unilateral closure if the counterparty provides an update_fee below this threshold.
Updated on: 2023-07-31T20:17:23.443309+00:00