Published on: 2015-11-27T09:46:05+00:00
Nicolas Dorier raised concerns about the difficulty of solving a problem related to the inconsistency of dust amounts in the Lightning Network. The dust amount depends on the dynamic minTxRelayFee, which is influenced by the mempool state of each node. However, another person disagrees and suggests that IsDust depends on the global minTxRelayFee from main, which is not dynamic like the one used in the mempool. Decoupling minTxRelayFee from dust is necessary, but implementation has faced challenges due to circular dependency. A proposal was made to tie the definition of dust to the transaction's fee. This discussion took place on the Lightning-dev mailing list.Mats Jerratsch proposed a new approach to deal with micropayments in the Lightning Network. He suggested adding two HTLCs to the commit, allowing for payments like 'I pay you 1.00000001 BTC and you pay me 1 BTC, so effectively I paid you 1 satoshi'. However, this method increases fees and may not work well over multiple hops with different fees. Rusty Russell acknowledged the potential problems with this approach, including the possibility of someone exploiting the system for profit. Russell also mentioned a scenario where dust payments are sent across lightning channels, causing the entire transaction to be rejected. One solution proposed was to account for these payments precisely in the lightning state but approximate the results in the actual commitments. Russell opened an issue on Github to address this problem. Jerratsch suggested modifying the dual HTLC method to make attacks unattractive, but expressed uncertainty about its effectiveness.The issue documented on Github (https://github.com/ElementsProject/lightning/issues/14) revolves around the inconsistency of dust amounts and the need to decouple minTxRelayFee from dust. The proposal to tie the definition of dust to the transaction's fee faced challenges during implementation due to circular dependency. Solving this issue is crucial for the success of the Lightning Network.The Lightning Network aims to enhance Bitcoin's scalability and speed. One challenge it faces is the inability to make micropayments below 546 satoshis, which are considered too small to be valid outputs in transactions. This problem arises when these payments are made through an HTLC output, which the network does not recognize as a legitimate payment. One solution proposed is adding two HTLCs to the commit, allowing microtransactions, but at the cost of increased fees and potential issues with multiple hops. Another suggestion is to weaken the dust protection in the network and allow users to clear the dust after three months if unclaimed, although this may incur additional fees. Ultimately, the most viable option seems to be culling these outputs and letting them go to fees. Finding workarounds and tracking this issue is vital for the success of the Lightning Network.Anthony Towns raised an issue on the Lightning Github page regarding micropayments on the lightning channel. Payments below 546 satoshi hit the IsDust() test and get rejected. Anthony suggests accounting for these payments precisely in the lightning state but approximating the results in the actual commitments. Rusty Russell agrees that there needs to be a rule to avoid creating rejected outputs due to their small size. He also proposes weakening the dust protection in the network, allowing anyone to clear the dust after three months if unclaimed. However, this would require paying to a non-standard script, which may be inconvenient. Both Anthony and Rusty agree that culling these outputs and letting them go to fees is the best solution.In a lightning channel with balances of 2 BTC and 1 BTC, sending a micropayment of 42 satoshi leads to an updated commitment. However, the third output triggers the IsDust() test, resulting in the rejection of the entire transaction and making it impossible to close the channel. One solution proposed is to treat these payments like sub 1-satoshi payments by accounting for them precisely in the lightning state but approximating the results in the commitments. However, adding dust to the commitment may hinder access to funds if the counterparty disappears. Weakening the dust protection in the network and allowing users to clear the dust after three months has been suggested, but this approach may incur additional fees. Additionally, the cost of adding the output to the transaction may outweigh its value.
Updated on: 2023-07-31T18:41:37.996279+00:00