Scaling Lightning Safely With Feerate-Dependent Timelocks

Scaling Lightning Safely With Feerate-Dependent Timelocks

Posted on: December 22, 2023 01:25 UTC

In a recent exchange between programmers, the intricacies of transaction inclusion in blockchain and how it is affected by window alignment and fee rate constraints were discussed.

The conversation dove into the specifics of when a transaction can be included in the blockchain, emphasizing that there are two conditions that must be met: firstly, the aligned window W should start only after certain timelocks are satisfied. Secondly, within this window, the number of blocks with a median fee rate exceeding a specific threshold must be less than the stipulated block count.

The definition of a median fee rate for a block was clarified, stating that it's the largest fee rate such that at least 2 million vbytes of transactions in the block have that fee rate or higher. The dialogue then extended to a proposed rule set requiring a wait until a certain time T before waiting for the start of an aligned window W. This window must not only begin no earlier than time T but also must contain fewer than a predetermined number of blocks with a median fee rate above a certain value.

Further discussion explored the Fee Delay Transaction (FDT) proposal, analyzing its implications for conflicting transactions and mining preferences. There was particular attention paid to how FDTs could potentially secure Hash Time-Locked Contracts (HTLCs) and ensure the proper ordering and timing of transactions across multiple hops in a Lightning Network payment. By introducing a 'claim_grace_period', the possibility of better managing these transactions was contemplated. This additional period would prevent premature execution of transactions, thus allowing for a more predictable sequence of events, especially in scenarios where race conditions might exist.

Another point of consideration was the technical cost associated with implementing such FDT parameters. The current storage requirements for the starting block of an aligned window were deemed manageable, but concerns were raised about the potential increase in memory demands if an additional parameter, such as 'number_of_windows', were to be added. Despite the potential increase in required storage, the concept was viewed positively as it could enhance the security of the Lightning Network's channel and factory protocols while also addressing safety concerns for HTLCs.

The discourse concluded with an open invitation for further thoughts on the 'number_of_windows' concept and suggestions for fortifying HTLCs, reflecting a collaborative approach to improving blockchain technology and its applications. The email ended with a note that it was sent using Proton Mail, an email service known for its strong security features.