Published on: 2016-06-01T06:47:33+00:00
The discussion centers around the dual-tx approach and its backward compatibility in relaying payments with old setups. Nodes need to publish their HTLC time subtraction despite the revocation value being a private arrangement. Initially, the prototype used times for calculations but later switched to blocks due to complexity. Active nodes prioritize block counts, especially for tight timings. However, transacting sub-dust amounts becomes significantly more difficult using this approach as one may end up paying more than 500 satoshis for a 1 satoshi payment on-chain.To address the issue of high refund times and low revocation times, the dual-tx approach has been proposed. The basic schema involves routing each payment and refund through an intermediate 2-of-2 transaction instead of directly to their respective owners. In order to redeem a payment, one must broadcast the Redeem-TX, while for a Refund-TX, one must wait for the agreed refund time. This approach allows for separate values for revocation delay and payment timeouts. However, there are two downsides: clearing a payment on the blockchain becomes more expensive, and updating the commitment transaction requires producing and sending a new signature for each currently included payment. Despite these drawbacks, the approach remains backward compatible, allowing for the relaying of payments with the old setup, albeit with longer refund times. Payments optimized for dual-tx cannot be relayed over hops that do not support it, but the old schema can still be used for low-amount payments.Mats Jerratsch has proposed a solution to the coupling problem between revocation delay and payment timeouts using SegWit. The proposed solution involves having each payment and refund directed to an intermediate 2-of-2 transaction, securing the funds on the condition that an old commitment transaction has not been used fraudulently. This enables the setting of separate values for revocation delay and payment timeouts. However, the approach also comes with the downsides of increased expense for clearing a payment on the blockchain and the need to produce and send a new signature for each currently included payment when updating the commitment transaction. More information and the proposed solution can be found at https://github.com/blockchain/thundernetwork/releases, as well as on the GitHub pages for Thunder Network (https://github.com/blockchain/thundernetwork) and Blockchain (https://blockchain.com/thunder). Rusty commended Mats on the idea and suggested that it deserves its own email.In summary, the Lightning Network developer has proposed a solution to address the coupling problem between revocation delay and payment timeouts using SegWit. The approach involves routing payments and refunds through an intermediate 2-of-2 transaction, allowing for separate values for revocation delay and payment timeouts. While there are drawbacks such as increased expense for clearing payments on the blockchain and the need for new signatures when updating the commitment transaction, the developer believes that this clean solution is worth the trade-offs in solving the issue of high refund times and low revocation times.
Updated on: 2023-07-31T19:00:58.687734+00:00