Re: [Lightning-dev] [bitcoin-dev] Scaling Lightning Safely With Feerate-Dependent Timelocks
Hi Eric, I agree that users can pay miners offchain and miners can create blocks where the difference between inputs and outputs exceeds the fees paid (by mining their own transactions). I model that behavior as dishonest mining. Onchain fees seem to reflect congestion for now, but it's true that FDTs rely on having a sufficient fraction of honest miners. Regards, John Sent with [Proton Mail](https://proton.me/) secure email. On Friday, December 22nd, 2023 at 8:09 PM, Eric Voskuil wrote: > The fees paid to mine the set of transactions in a given block are known only > to the miner that produced the block. Assuming that tx inputs less outputs > represents an actual economic force is an error. > > e > >> On Dec 22, 2023, at 09:24, jlspc via bitcoin-dev >> wrote: > >> >> >> Hi Antoine, >> >> Thanks for your thoughtful response. >> >> Comments inline below: >> >>> Hi John, >> >>> While the idea of using sliding reaction window for blockchain congestion >>> detection has been present in the "smart contract" space at large [0] and >>> this has been discussed informally among Lightning devs and covenant >>> designers few times [1] [2], this is the first and best formalization of >>> sliding-time-locks in function of block fee rates for Bitcoin I'm aware >>> off, to the best of my knowledge. >> >> Thanks! >> >>> Here my understanding of the feerate-dependent timelock proposal. >> >>> A transaction cannot be included in a block: >>> - height-based or epoch-based absolute or relative timelocks are not >>> satisfied according to current consensus rules (bip68 and bip 113 and >>> implementation details) >>> - less than `block_count` has a block median-feerate above the >>> median-feerate of the `window_size` period >> >> It's a little bit different from that. >> The transaction cannot be included in the blockchain until after an aligned >> window W of window_size blocks where: >> 1) W starts no sooner than when the height-based or epoch-based absolute >> and/or relative timelocks have been satisfied, and >> 2) W contains fewer than block_count blocks with median feerate greater than >> feerate_value_bound. >> >> Note that the aligned window cannot start until the absolute and/or relative >> timelocks have been satisfied and the transaction itself has to come after >> the aligned window. >> However, once such an aligned window exists in the blockchain, the >> transaction can appear at any later time (and not just within a window that >> itself meets the block_count and feerate_value_bound limitations). >> >>> A median feerate is computed for each block. >>> (This is unclear to me if this is the feerate for half of the block's >>> weight or the median feerate with all weight units included in the >>> block as the sample) >> >> A feerate F is the median feerate of a block B if F is the largest feerate >> such that the total size of the transactions in B with feerate greater or >> equal to F is at least 2 million vbytes. >> >>> From then, you have 3 parameters included in the nSequence field. >>> - feerate_value_bound >>> - window_size >>> - block_count >> >>> Those parameters can be selected by the transaction builder (and >>> committed with a signature or hash chain-based covenant). >>> As such, off-chain construction counterparties can select the >>> feerate_value_bound at which their time-sensitive transaction >>> confirmation will be delayed. >> >>> E.g let's say you have a LN-penalty Alice-Bob channel. Second-stage >>> HTLC transactions are pre-signed with feerate_value_bound at 100 sat / >>> vbytes. >>> The window_size selected is 100 blocks and the block_count is 70 (this >>> guarantees tampering-robustness of the feerate_value_bound in face of >>> miners coalitions). >> >>> There is 1 BTC offered HTLC pending with expiration time T, from Alice to >>> Bob. >> >>> If at time T, the per-block median feerate of at least 70 blocks over >>> the latest 100 block is above 100 sat / vbytes, any Alice's >>> HTLC-timeout or Bob's HTLC-preimage cannot be included in the chain. >> >> The rules are actually: >> 1) wait until time T, then >> 2) wait until the start of a full aligned window W with 100 consecutive >> blocks that starts no earlier than T and that has fewer than 70 blocks with >> median feerate above 100 sats/vbyte. >> (The values 100, 70, and 100 cannot actually be selected in the >> implementation in the paper, but that's a technical detail and could be >> changed if the FDT is specified in the annex, as you propose.) >> >>> From my understanding, Feerate-Dependent Timelocks effectively >>> constitute the lineaments of a solution to the "Forced Expiration >>> Spam" as described in the LN paper. >> >> Great! >> >>> I think you have few design caveats to be aware off: >>> - for current LN-penalty, the revokeable scripts should be modified to >>> ensure the CSV opcode inspect the enforcement of FDT's parameters, as >>> those revokeable scripts are committed by all parties >> >> Yes, de
Re: [Lightning-dev] [bitcoin-dev] Scaling Lightning Safely With Feerate-Dependent Timelocks
On 2023-12-28 08:06, jlspc via bitcoin-dev wrote: On Friday, December 22nd, 2023 at 8:36 AM, Nagaev Boris wrote: To validate a transaction with FDT [...] a light client would have to determine the median fee rate of the recent blocks. To do that without involving trust, it has to download the blocks. What do you think about including median feerate as a required OP_RETURN output in coinbase transaction? Yes, I think that's a great idea! I think this points to a small challenge of implementing this soft fork for pruned full nodes. Let's say a fee-dependent timelock (FDT) soft fork goes into effect at time/block _t_. Both before and for a while after _t_, Alice is running an older pruned full node that did not contain any FDT-aware code, so it prunes blocks after _t_ without storing any median feerate information about them (not even commitments in the coinbase transaction). Later, well after _t_, Alice upgrades her node to one that is aware of FDTs. Unfortunately, as a pruned node, it doesn't have earlier blocks, so it can't validate FDTs without downloading those earlier blocks. I think the simplest solution would be for a recently-upgrade node to begin collecting median feerates for new blocks going forward and to only enforce FDTs for which it has the data. That would mean anyone depending on FDTs should be a little more careful about them near activation time, as even some node versions that nominally enforced FDT consensus rules might not actually be enforcing them yet. Of course, if the above solution isn't satisfactory, upgraded pruned nodes could simply redownload old blocks or, with extensions to the P2P protocol, just the relevant parts of them (i.e., coinbase transactions or, with a soft fork, even just commitments made in coinbase transactions[1]). -Dave [1] An idea discussed for the segwit soft fork was requiring the witness merkle root OP_RETURN to be the final output of the coinbase transaction so that all chunks of the coinbase transaction before it could be "compressed" into a SHA midstate and then the midstate could be extended with the bytes of the OP_RETURN commitment to produce the coinbase transaction's txid, which could then be connected to the block header using the standard Bitcoin-style merkle inclusion proof. This would allow trailing commitments in even a very large coinbase transaction to be communicated in just a few hundred bytes (not including the size of the commitments themselves). This idea was left out of segwit because at least one contemporary model of ASIC miner had a hardware-enforced requirement to put a mining reward payout in the final output. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] [bitcoin-dev] Scaling Lightning Safely With Feerate-Dependent Timelocks
Hi Boris, Responses inline below: Sent with Proton Mail secure email. On Friday, December 22nd, 2023 at 8:36 AM, Nagaev Boris wrote: > Hi John! > > I have two questions regarding the window, which are related. > > 1. Why is the window aligned? IIUC, this means that the blocks mined > since the latest block whose height is divisible by window_size do not > affect transaction's validity. So a recent change of fees does not > reflect if a transaction can be confirmed. FDTs are not based on the most recent window; instead, an FDT requires that there exist *some* aligned window between when the child transaction's absolute and relative timelocks were satisfied and the current block. The alignment requirement allows one to prove tighter security bounds over a given time period. For example, 2 consecutive aligned 64-block windows give dishonest miners 2 chances to create artificial aligned low-feerate windows, but 65 chances to create such windows if alignment isn't required. > > 2. Does it make sense to have a global window_size? This would save > space in FDT (= in transaction) and simplify verification, especially > for a non-aligned window case (see 1). An array of integers of size > window_size would be sufficient to give answer to a question if there > were at least x blocks among window_size latest blocks with median fee > rate <= y, using O(1) time per query. > The ability to tune the window size allows for a trade-off between latency and security (also, see my response above about alignment). > Moving on to another topic, what are the implications for light > clients? A light client can validate current timelocks without > downloading whole blocks, because they depend on timestamps and block > height only, the information from block headers. To validate a > transaction with FDT or to choose FDT parameters for its own > transaction, a light client would have to determine the median fee > rate of the recent blocks. To do that without involving trust, it has > to download the blocks. What do you think about including median > feerate as a required OP_RETURN output in coinbase transaction? A > block without it would be invalid (new consensus rule). A light client > can rely on median feerate value from coinbase transaction, > downloading only one tx instead of the whole block. Yes, I think that's a great idea! Regards, John > > On Fri, Dec 15, 2023 at 6:20 AM jlspc via bitcoin-dev > bitcoin-...@lists.linuxfoundation.org wrote: > > > TL;DR > > = > > * All known Lightning channel and factory protocols are susceptible to > > forced expiration spam attacks, in which an attacker floods the blockchain > > with transactions in order to prevent honest users from putting their > > transactions onchain before timelocks expire. > > * Feerate-Dependent Timelocks (FDTs) are timelocks that automatically > > extend when blockchain feerates spike. > > - In the normal case, there's no spike in feerates and thus no tradeoff > > between capital efficiency and safety. > > - If a dishonest user attempts a forced expiration spam attack, feerates > > increase and FDTs are extended, thus penalizing the attacker by keeping > > their capital timelocked for longer. > > - FDTs are tunable and can be made to be highly resistant to attacks from > > dishonest miners. > > * Of separate interest, an exact analysis of the risk of double spend > > attacks is presented that corrects an error in the original Bitcoin > > whitepaper. > > > > Overview > > > > > > Because the Lightning protocol relies on timelocks to establish the correct > > channel state, Lightning users could lose their funds if they're unable to > > put their transactions onchain quickly enough. > > The original Lightning paper [1] states that "[f]orced expiration of many > > transactions may be the greatest systemic risk when using the Lightning > > Network" and it uses the term "forced expiration spam" for an attack in > > which a malicious party "creates many channels and forces them all to > > expire at once", thus allowing timelocked transactions to become valid. > > That paper also says that the creation of a credible threat against > > "spamming the blockchain to encourage transactions to timeout" is > > "imperative" [1]. > > > > Channel factories that create multiple Lightning channels with a single > > onchain transaction [2][3][4][5] increase this risk in two ways. > > First, factories allow more channels to be created, thus increasing the > > potential for many channels to require onchain transactions at the same > > time. > > Second, channel factories themselves use timelocks, and thus are vulnerable > > to a "forced expiration spam" attack. > > > > In fact, the timelocks in Lightning channels and factories are risky even > > without an attack from a malicious party. > > Blockchain congestion is highly variable and new applications (such as > > ordinals) can cause a sudden spike in congestion at a
Re: [Lightning-dev] [bitcoin-dev] Scaling Lightning Safely With Feerate-Dependent Timelocks
Hi John,Honest is a misnomer, which is underpinning the concept. There is nothing dishonest about such payments. The downside is that the payer forgoes anonymity relative to the miner, but this is not dishonest, nor is mining one’s own transactions (where the represented “fee” implies nothing). Assuming a “sufficient fraction” of one of several economically rational behaviors is a design flaw.eOn Dec 28, 2023, at 13:19, jlspc wrote:Hi Eric,I agree that users can pay miners offchain and miners can create blocks where the difference between inputs and outputs exceeds the fees paid (by mining their own transactions). I model that behavior as dishonest mining. Onchain fees seem to reflect congestion for now, but it's true that FDTs rely on having a sufficient fraction of honest miners.Regards,John Sent with Proton Mail secure email. On Friday, December 22nd, 2023 at 8:09 PM, Eric Voskuil wrote: The fees paid to mine the set of transactions in a given block are known only to the miner that produced the block. Assuming that tx inputs less outputs represents an actual economic force is an error.eOn Dec 22, 2023, at 09:24, jlspc via bitcoin-dev wrote:Hi Antoine, Thanks for your thoughtful response. Comments inline below: > Hi John, > While the idea of using sliding reaction window for blockchain congestion > detection has been present in the "smart contract" space at large [0] and > this has been discussed informally among Lightning devs and covenant > designers few times [1] [2], this is the first and best formalization of > sliding-time-locks in function of block fee rates for Bitcoin I'm aware > off, to the best of my knowledge. Thanks! > Here my understanding of the feerate-dependent timelock proposal. > A transaction cannot be included in a block: > - height-based or epoch-based absolute or relative timelocks are not > satisfied according to current consensus rules (bip68 and bip 113 and > implementation details) > - less than `block_count` has a block median-feerate above the > median-feerate of the `window_size` period It's a little bit different from that. The transaction cannot be included in the blockchain until after an aligned window W of window_size blocks where: 1) W starts no sooner than when the height-based or epoch-based absolute and/or relative timelocks have been satisfied, and 2) W contains fewer than block_count blocks with median feerate greater than feerate_value_bound. Note that the aligned window cannot start until the absolute and/or relative timelocks have been satisfied and the transaction itself has to come after the aligned window. However, once such an aligned window exists in the blockchain, the transaction can appear at any later time (and not just within a window that itself meets the block_count and feerate_value_bound limitations). > A median feerate is computed for each block. > (This is unclear to me if this is the feerate for half of the block's > weight or the median feerate with all weight units included in the > block as the sample) A feerate F is the median feerate of a block B if F is the largest feerate such that the total size of the transactions in B with feerate greater or equal to F is at least 2 million vbytes. > From then, you have 3 parameters included in the nSequence field. > - feerate_value_bound > - window_size > - block_count > Those parameters can be selected by the transaction builder (and > committed with a signature or hash chain-based covenant). > As such, off-chain construction counterparties can select the > feerate_value_bound at which their time-sensitive transaction > confirmation will be delayed. > E.g let's say you have a LN-penalty Alice-Bob channel. Second-stage > HTLC transactions are pre-signed with feerate_value_bound at 100 sat / > vbytes. > The window_size selected is 100 blocks and the block_count is 70 (this > guarantees tampering-robustness of the feerate_value_bound in face of > miners coalitions). > There is 1 BTC offered HTLC pending with expiration time T, from Alice to Bob. > If at time T, the per-block median feerate of at least 70 blocks over > the latest 100 block is above 100 sat / vbytes, any Alice's > HTLC-timeout or Bob's HTLC-preimage cannot be included in the chain. The rules are actually: 1) wait until time T, then 2) wait until the start of a full aligned window W with 100 consecutive blocks that starts no earlier than T and that has fewer than 70 blocks with median feerate above 100 sats/vbyte. (The values 100, 70, and 100 cannot actually be selected in the implementation in the paper, but that's a technical detail and could be changed if the FDT is specified in the annex, as you propose.) > From my understanding, Feerate-Dependent Timelocks effectively > constitute the lineaments of a solution to the "Forced Expiration > Spam" as described in the LN paper. Great! > I think you have few design caveats to b
Re: [Lightning-dev] [bitcoin-dev] Scaling Lightning Safely With Feerate-Dependent Timelocks
Hi Antoine, Thanks for your thoughtful response. Comments inline below: > Hi John, > While the idea of using sliding reaction window for blockchain congestion > detection has been present in the "smart contract" space at large [0] and > this has been discussed informally among Lightning devs and covenant > designers few times [1] [2], this is the first and best formalization of > sliding-time-locks in function of block fee rates for Bitcoin I'm aware > off, to the best of my knowledge. Thanks! > Here my understanding of the feerate-dependent timelock proposal. > A transaction cannot be included in a block: > - height-based or epoch-based absolute or relative timelocks are not > satisfied according to current consensus rules (bip68 and bip 113 and > implementation details) > - less than `block_count` has a block median-feerate above the > median-feerate of the `window_size` period It's a little bit different from that. The transaction cannot be included in the blockchain until after an aligned window W of window_size blocks where: 1) W starts no sooner than when the height-based or epoch-based absolute and/or relative timelocks have been satisfied, and 2) W contains fewer than block_count blocks with median feerate greater than feerate_value_bound. Note that the aligned window cannot start until the absolute and/or relative timelocks have been satisfied and the transaction itself has to come after the aligned window. However, once such an aligned window exists in the blockchain, the transaction can appear at any later time (and not just within a window that itself meets the block_count and feerate_value_bound limitations). > A median feerate is computed for each block. > (This is unclear to me if this is the feerate for half of the block's > weight or the median feerate with all weight units included in the > block as the sample) A feerate F is the median feerate of a block B if F is the largest feerate such that the total size of the transactions in B with feerate greater or equal to F is at least 2 million vbytes. > From then, you have 3 parameters included in the nSequence field. > - feerate_value_bound > - window_size > - block_count > Those parameters can be selected by the transaction builder (and > committed with a signature or hash chain-based covenant). > As such, off-chain construction counterparties can select the > feerate_value_bound at which their time-sensitive transaction > confirmation will be delayed. > E.g let's say you have a LN-penalty Alice-Bob channel. Second-stage > HTLC transactions are pre-signed with feerate_value_bound at 100 sat / > vbytes. > The window_size selected is 100 blocks and the block_count is 70 (this > guarantees tampering-robustness of the feerate_value_bound in face of > miners coalitions). > There is 1 BTC offered HTLC pending with expiration time T, from Alice to Bob. > If at time T, the per-block median feerate of at least 70 blocks over > the latest 100 block is above 100 sat / vbytes, any Alice's > HTLC-timeout or Bob's HTLC-preimage cannot be included in the chain. The rules are actually: 1) wait until time T, then 2) wait until the start of a full aligned window W with 100 consecutive blocks that starts no earlier than T and that has fewer than 70 blocks with median feerate above 100 sats/vbyte. (The values 100, 70, and 100 cannot actually be selected in the implementation in the paper, but that's a technical detail and could be changed if the FDT is specified in the annex, as you propose.) > From my understanding, Feerate-Dependent Timelocks effectively > constitute the lineaments of a solution to the "Forced Expiration > Spam" as described in the LN paper. Great! > I think you have few design caveats to be aware off: > - for current LN-penalty, the revokeable scripts should be modified to > ensure the CSV opcode inspect the enforcement of FDT's parameters, as > those revokeable scripts are committed by all parties Yes, definitely. > - there should be a delay period at the advantage of one party > otherwise you still a feerate-race if the revocation bip68 timelock > has expired during the FDT delay > As such, I believe the FDT parameters should be enriched with another > parameter : `claim_grace_period`, a new type of relative timelock of > which the endpoint should be the `feerate_value_bound` itself. I'm not sure I'm following your proposal. Are you suggesting that the transaction with the FDT has to wait an additional claim_grace_period in order to allow conflicting transactions from the other party to win the race? For example, assume the HTLC-success transaction has a higher feerate than the feerate_value_bound, and the conflicting HTLC-timeout transaction has an FDT with the feerate_value_bound (and suitable window_size and block_count parameters to defend against miner attacks). In this case, is the worry that the HTLC-success and HTLC-timeout transactions could both be delayed until there is a window W that
Re: [Lightning-dev] [bitcoin-dev] Scaling Lightning Safely With Feerate-Dependent Timelocks
The fees paid to mine the set of transactions in a given block are known only to the miner that produced the block. Assuming that tx inputs less outputs represents an actual economic force is an error.eOn Dec 22, 2023, at 09:24, jlspc via bitcoin-dev wrote:Hi Antoine, Thanks for your thoughtful response. Comments inline below: > Hi John, > While the idea of using sliding reaction window for blockchain congestion > detection has been present in the "smart contract" space at large [0] and > this has been discussed informally among Lightning devs and covenant > designers few times [1] [2], this is the first and best formalization of > sliding-time-locks in function of block fee rates for Bitcoin I'm aware > off, to the best of my knowledge. Thanks! > Here my understanding of the feerate-dependent timelock proposal. > A transaction cannot be included in a block: > - height-based or epoch-based absolute or relative timelocks are not > satisfied according to current consensus rules (bip68 and bip 113 and > implementation details) > - less than `block_count` has a block median-feerate above the > median-feerate of the `window_size` period It's a little bit different from that. The transaction cannot be included in the blockchain until after an aligned window W of window_size blocks where: 1) W starts no sooner than when the height-based or epoch-based absolute and/or relative timelocks have been satisfied, and 2) W contains fewer than block_count blocks with median feerate greater than feerate_value_bound. Note that the aligned window cannot start until the absolute and/or relative timelocks have been satisfied and the transaction itself has to come after the aligned window. However, once such an aligned window exists in the blockchain, the transaction can appear at any later time (and not just within a window that itself meets the block_count and feerate_value_bound limitations). > A median feerate is computed for each block. > (This is unclear to me if this is the feerate for half of the block's > weight or the median feerate with all weight units included in the > block as the sample) A feerate F is the median feerate of a block B if F is the largest feerate such that the total size of the transactions in B with feerate greater or equal to F is at least 2 million vbytes. > From then, you have 3 parameters included in the nSequence field. > - feerate_value_bound > - window_size > - block_count > Those parameters can be selected by the transaction builder (and > committed with a signature or hash chain-based covenant). > As such, off-chain construction counterparties can select the > feerate_value_bound at which their time-sensitive transaction > confirmation will be delayed. > E.g let's say you have a LN-penalty Alice-Bob channel. Second-stage > HTLC transactions are pre-signed with feerate_value_bound at 100 sat / > vbytes. > The window_size selected is 100 blocks and the block_count is 70 (this > guarantees tampering-robustness of the feerate_value_bound in face of > miners coalitions). > There is 1 BTC offered HTLC pending with expiration time T, from Alice to Bob. > If at time T, the per-block median feerate of at least 70 blocks over > the latest 100 block is above 100 sat / vbytes, any Alice's > HTLC-timeout or Bob's HTLC-preimage cannot be included in the chain. The rules are actually: 1) wait until time T, then 2) wait until the start of a full aligned window W with 100 consecutive blocks that starts no earlier than T and that has fewer than 70 blocks with median feerate above 100 sats/vbyte. (The values 100, 70, and 100 cannot actually be selected in the implementation in the paper, but that's a technical detail and could be changed if the FDT is specified in the annex, as you propose.) > From my understanding, Feerate-Dependent Timelocks effectively > constitute the lineaments of a solution to the "Forced Expiration > Spam" as described in the LN paper. Great! > I think you have few design caveats to be aware off: > - for current LN-penalty, the revokeable scripts should be modified to > ensure the CSV opcode inspect the enforcement of FDT's parameters, as > those revokeable scripts are committed by all parties Yes, definitely. > - there should be a delay period at the advantage of one party > otherwise you still a feerate-race if the revocation bip68 timelock > has expired during the FDT delay > As such, I believe the FDT parameters should be enriched with another > parameter : `claim_grace_period`, a new type of relative timelock of > which the endpoint should be the `feerate_value_bound` itself. I'm not sure I'm following your proposal. Are you suggesting that the transaction with the FDT has to wait an additional claim_grace_period in order to allow conflicting transactions from the other party to win the race? For example, assume the HTLC-success transaction has a higher feerate than the feerate_value_bound, and the conflicting HTLC-timeout transaction has an FDT with th
Re: [Lightning-dev] [bitcoin-dev] Scaling Lightning Safely With Feerate-Dependent Timelocks
Hi John! I have two questions regarding the window, which are related. 1. Why is the window aligned? IIUC, this means that the blocks mined since the latest block whose height is divisible by window_size do not affect transaction's validity. So a recent change of fees does not reflect if a transaction can be confirmed. 2. Does it make sense to have a global window_size? This would save space in FDT (= in transaction) and simplify verification, especially for a non-aligned window case (see 1). An array of integers of size window_size would be sufficient to give answer to a question if there were at least x blocks among window_size latest blocks with median fee rate <= y, using O(1) time per query. Moving on to another topic, what are the implications for light clients? A light client can validate current timelocks without downloading whole blocks, because they depend on timestamps and block height only, the information from block headers. To validate a transaction with FDT or to choose FDT parameters for its own transaction, a light client would have to determine the median fee rate of the recent blocks. To do that without involving trust, it has to download the blocks. What do you think about including median feerate as a required OP_RETURN output in coinbase transaction? A block without it would be invalid (new consensus rule). A light client can rely on median feerate value from coinbase transaction, downloading only one tx instead of the whole block. On Fri, Dec 15, 2023 at 6:20 AM jlspc via bitcoin-dev wrote: > > TL;DR > = > * All known Lightning channel and factory protocols are susceptible to forced > expiration spam attacks, in which an attacker floods the blockchain with > transactions in order to prevent honest users from putting their transactions > onchain before timelocks expire. > * Feerate-Dependent Timelocks (FDTs) are timelocks that automatically extend > when blockchain feerates spike. > - In the normal case, there's no spike in feerates and thus no tradeoff > between capital efficiency and safety. > - If a dishonest user attempts a forced expiration spam attack, feerates > increase and FDTs are extended, thus penalizing the attacker by keeping their > capital timelocked for longer. > - FDTs are tunable and can be made to be highly resistant to attacks from > dishonest miners. > * Of separate interest, an exact analysis of the risk of double spend attacks > is presented that corrects an error in the original Bitcoin whitepaper. > > Overview > > > Because the Lightning protocol relies on timelocks to establish the correct > channel state, Lightning users could lose their funds if they're unable to > put their transactions onchain quickly enough. > The original Lightning paper [1] states that "[f]orced expiration of many > transactions may be the greatest systemic risk when using the Lightning > Network" and it uses the term "forced expiration spam" for an attack in which > a malicious party "creates many channels and forces them all to expire at > once", thus allowing timelocked transactions to become valid. > That paper also says that the creation of a credible threat against "spamming > the blockchain to encourage transactions to timeout" is "imperative" [1]. > > Channel factories that create multiple Lightning channels with a single > onchain transaction [2][3][4][5] increase this risk in two ways. > First, factories allow more channels to be created, thus increasing the > potential for many channels to require onchain transactions at the same time. > Second, channel factories themselves use timelocks, and thus are vulnerable > to a "forced expiration spam" attack. > > In fact, the timelocks in Lightning channels and factories are risky even > without an attack from a malicious party. > Blockchain congestion is highly variable and new applications (such as > ordinals) can cause a sudden spike in congestion at any time. > As a result, timelocks that were set when congestion was low can be too short > when congestion spikes. > Even worse, a spike in congestion could be self-reinforcing if it causes > malicious parties to attack opportunistically and honest parties to put their > channels onchain due to the heightened risk. > > One way to reduce the risk of a forced expiration spam attack is to use > longer timelocks that give honest users more time to put their transactions > onchain. > However, long timelocks limit the ability to dynamically reassign the > channel's (or factory's) funds, thus creating a tradeoff between capital > efficiency and safety [6]. > While long timelocks could maintain safety for small numbers of channels, > supporting billions (or tens of billions) of channels while maintaining > safety is probably impossible [7]. > > Another way to reduce risk is to impose a penalty on an attacker. > Some channel protocols, such as the original Lightning protocol [1], a > version of the two-party eltoo protocol [8], the ful
Re: [Lightning-dev] [bitcoin-dev] Scaling Lightning Safely With Feerate-Dependent Timelocks
Hi John, While the idea of using sliding reaction window for blockchain congestion detection has been present in the "smart contract" space at large [0] and this has been discussed informally among Lightning devs and covenant designers few times [1] [2], this is the first and best formalization of sliding-time-locks in function of block fee rates for Bitcoin I'm aware off, to the best of my knowledge. Here my understanding of the feerate-dependent timelock proposal. A transaction cannot be included in a block: - height-based or epoch-based absolute or relative timelocks are not satisfied according to current consensus rules (bip68 and bip 113 and implementation details) - less than `block_count` has a block median-feerate above the median-feerate of the `window_size` period A median feerate is computed for each block. (This is unclear to me if this is the feerate for half of the block's weight or the median feerate with all weight units included in the block as the sample) >From then, you have 3 parameters included in the nSequence field. - feerate_value_bound - window_size - block_count Those parameters can be selected by the transaction builder (and committed with a signature or hash chain-based covenant). As such, off-chain construction counterparties can select the feerate_value_bound at which their time-sensitive transaction confirmation will be delayed. E.g let's say you have a LN-penalty Alice-Bob channel. Second-stage HTLC transactions are pre-signed with feerate_value_bound at 100 sat / vbytes. The window_size selected is 100 blocks and the block_count is 70 (this guarantees tampering-robustness of the feerate_value_bound in face of miners coalitions). There is 1 BTC offered HTLC pending with expiration time T, from Alice to Bob. If at time T, the per-block median feerate of at least 70 blocks over the latest 100 block is above 100 sat / vbytes, any Alice's HTLC-timeout or Bob's HTLC-preimage cannot be included in the chain. >From my understanding, Feerate-Dependent Timelocks effectively constitute the lineaments of a solution to the "Forced Expiration Spam" as described in the LN paper. I think you have few design caveats to be aware off: - for current LN-penalty, the revokeable scripts should be modified to ensure the CSV opcode inspect the enforcement of FDT's parameters, as those revokeable scripts are committed by all parties - there should be a delay period at the advantage of one party otherwise you still a feerate-race if the revocation bip68 timelock has expired during the FDT delay As such, I believe the FDT parameters should be enriched with another parameter : `claim_grace_period`, a new type of relative timelock of which the endpoint should be the `feerate_value_bound` itself. I think it works in terms of consensus chain state, validation resources and reorg-safety are all the parameters that are self-contained in the spent FDT-encumbered transaction itself. If the per-block feerate fluctuates, the validity of the ulterior FDT-locked transactions changes too, though this is already the case with timelock-encumbered transactions. (One corollary for Lightning, it sounds like all the channels carrying on a HTLC along a payment path should have the same FDT-parameters to avoid off-chain HTLC double-spend, a risk not clearly articulated in the LN paper). Given the one more additional parameter `claim_grace_period`, I think it would be wiser design to move all the FDT parameters in the bip341 annex. There is more free bits room there and additionally you can have different FDT parameters for each of your HTLC outputs in a single LN transaction, if combined with future covenant mechanisms like HTLC aggregation [3]. (The current annex design draft has been designed among others to enable such "block-feerate-lock-point" [4] [5]) I cannot assert that the FDT proposal makes the timeout-tree protocol more efficient than state-of-the-art channel factories and payment pool constructions. Still from my understanding, all those constructions are sharing frailties in face of blockchain congestion and they would need something like FDT. I'm truly rejoicing at the idea that we have now the start of a proposal solving one of the most imperative issues of Lightning and other time-sensitive use-cases. (Note, I've not reviewed the analysis and game-theory in the face of miners collusion / coalition, as I think the introduction of a `claim_grace_period` is modifying the fundamentals). Best, Antoine [0] https://fc22.ifca.ai/preproceedings/119.pdf [1] https://github.com/ariard/bitcoin-contracting-primitives-wg/blob/main/meetings/meetings-18-04.md [2] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-November/022180.html [3] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-October/022093.html [4] https://github.com/bitcoin-inquisition/bitcoin/pull/9 [5] https://github.com/bitcoin/bips/pull/1381 Le ven. 15 déc. 2023 à 09:20, jlspc via bitcoin-dev < bitcoin-...@list
