From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 6EEFEC0037; Sun, 17 Dec 2023 23:01:39 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 3F43340102; Sun, 17 Dec 2023 23:01:39 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 3F43340102 Authentication-Results: smtp2.osuosl.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20230601 header.b=hh5fAsPK X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J3o29g76wuIp; Sun, 17 Dec 2023 23:01:35 +0000 (UTC) Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) by smtp2.osuosl.org (Postfix) with ESMTPS id 0173C40042; Sun, 17 Dec 2023 23:01:34 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 0173C40042 Received: by mail-io1-xd2e.google.com with SMTP id ca18e2360f4ac-7b701f86c3aso120563339f.3; Sun, 17 Dec 2023 15:01:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1702854093; x=1703458893; darn=lists.linuxfoundation.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=HonXWytN37ubx5XZ8VvJRy1ISuFBPI7ja0RgcorZjOM=; b=hh5fAsPK6p3pqM2XSUMt2+TKlADOslbFmne8RExqoxl2JV5IAZzQioctXstw4kbtgh ofzpItH1xsb4Ki3U+9GEQ3slOkaSYGbVy1B45ThlG2MJ4IlK3+HRDd89ISKo4X5ssyZD tsoUgaYb7Wg9D8HancDZ60Yoj/L3Gup1iqQOKb8vMoTdUIlDpWI1kSu9njAdLcObbHkJ eyKjAVZC3m17CNEq6WRsjBNDncEc8dUeqgzZRWthIu5uhVZlEG7KsulpCbV36l8yvMWS BwVzBtVUjYz/R3umlaoT9ecdZn3rKhUMhbJz9JuYLJtgBWpbOwfq2/yncVABtpenQ0Lt mAbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1702854093; x=1703458893; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=HonXWytN37ubx5XZ8VvJRy1ISuFBPI7ja0RgcorZjOM=; b=mj6tkovdRViwNu/W67fCKfUpunWDZCBjenVb2UY2IJBkU6sWjmS8W7vYjcB76/pXxw /pNGJc7J+ogCUfTUjaxzVVZYY/XRl95T38GB9N4Qca4GguyebfRuoZr3NzaPSddAMeSG Mx/s97vrDHWWCDx6oQRJXUDbIeUPJJwJ2gyz7KQzZ8csTsogYrUAaHfoX4feGmKiHWDM fNS1qpJe1RFWNOw4obzB+T61N1hMho9NzlCTRT3lfrw25Ar1t1PPL9OKRu4kBpg963qR JjwVI3IU66ZMwKibUI+r8vGRHeeof0RG10ck1K52Zn1dAkWuEDwcL/T0BdsumrBrYMDp q9lQ== X-Gm-Message-State: AOJu0Yxs8jqUZeySYg086VEkCZ6+AXZhg5aCnGJ07Yx4t3gMzzOedtEe wfg3D0o7Wh++z/mD/P2H47zCr0p339sF19znS5gE7f3m0vLNXQ== X-Google-Smtp-Source: AGHT+IHRbS+G/DStjUQSP5G/5nJmk4cdl91ofKNy3QCSG3rhX1HeHMcoqMP++yEUSOqoD7eVJ8ergVVRQZAWw+GyO7w= X-Received: by 2002:a05:6602:1547:b0:7b3:92f8:9ef4 with SMTP id h7-20020a056602154700b007b392f89ef4mr20190235iow.2.1702854093139; Sun, 17 Dec 2023 15:01:33 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Antoine Riard Date: Sun, 17 Dec 2023 23:01:22 +0000 Message-ID: To: jlspc , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="00000000000053740c060cbc9d8a" X-Mailman-Approved-At: Mon, 18 Dec 2023 00:35:49 +0000 Cc: "lightning-dev@lists.linuxfoundation.org" Subject: Re: [bitcoin-dev] Scaling Lightning Safely With Feerate-Dependent Timelocks X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Dec 2023 23:01:40 -0000 --00000000000053740c060cbc9d8a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 B= ob. 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/m= eetings/meetings-18-04.md [2] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-November/0= 22180.html [3] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-October/02= 2093.html [4] https://github.com/bitcoin-inquisition/bitcoin/pull/9 [5] https://github.com/bitcoin/bips/pull/1381 Le ven. 15 d=C3=A9c. 2023 =C3=A0 09:20, jlspc via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> a =C3=A9crit : > TL;DR > =3D=3D=3D=3D=3D > * All known Lightning channel and factory protocols are susceptible to fo= rced expiration spam attacks, in which an attacker floods the blockchain wi= th transactions in order to prevent honest users from putting their transac= tions onchain before timelocks expire. > * Feerate-Dependent Timelocks (FDTs) are timelocks that automatically ext= end 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, feerate= s increase and FDTs are extended, thus penalizing the attacker by keeping t= heir capital timelocked for longer. > - FDTs are tunable and can be made to be highly resistant to attacks fr= om dishonest miners. > * Of separate interest, an exact analysis of the risk of double spend att= acks is presented that corrects an error in the original Bitcoin whitepaper= . > > Overview > =3D=3D=3D=3D=3D=3D=3D=3D > > Because the Lightning protocol relies on timelocks to establish the corre= ct 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 Ne= twork" 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 "spam= ming the blockchain to encourage transactions to timeout" is "imperative" [= 1]. > > Channel factories that create multiple Lightning channels with a single o= nchain transaction [2][3][4][5] increase this risk in two ways. > First, factories allow more channels to be created, thus increasing the p= otential for many channels to require onchain transactions at the same time= . > Second, channel factories themselves use timelocks, and thus are vulnerab= le 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 or= dinals) can cause a sudden spike in congestion at any time. > As a result, timelocks that were set when congestion was low can be too s= hort 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 the= ir channels onchain due to the heightened risk. > > One way to reduce the risk of a forced expiration spam attack is to use l= onger timelocks that give honest users more time to put their transactions = onchain. > However, long timelocks limit the ability to dynamically reassign the cha= nnel's (or factory's) funds, thus creating a tradeoff between capital effic= iency and safety [6]. > While long timelocks could maintain safety for small numbers of channels,= supporting billions (or tens of billions) of channels while maintaining sa= fety 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 ve= rsion of the two-party eltoo protocol [8], the fully-factory-optimized prot= ocol [9], and the tunable-penalty channel protocol [10] include such penalt= ies. > In addition, the tunable-penalty and single-commitment factory protocols = [4] support penalties. > However, as was noted in the original Lightning paper [1], penalties don'= t eliminate the risk of a forced expiration spam attack. > Furthermore, existing penalty-based factory protocols [4] have limited sc= alability, as they depend on getting large numbers of casual users to coord= inate and co-sign transactions [11][5]. > > In contrast, the timeout-tree protocol [5] scales via simple covenants (e= nabled by support for CheckTemplateVerify, AnyPrevOut, or a similar change = to the Bitcoin consensus rules). > As a result, a single timeout-tree can support millions of channels and o= ne small transaction per block can fund timeout-trees with tens of billions= of offchain channels [5]. > However, timeout-trees don't support penalties, and like all other known = factory protocols [2][3][4], timeout-trees rely on timelocks. > > Therefore, if the need to protect against forced expiration spam was alre= ady "imperative" for the original Lightning channel protocol [1], the use o= f scalable channel factories will make such protection indispensable. > > This post proposes a change to Bitcoin's consensus rules that allows the = length of a timelock to depend on the feerate being charged for putting tra= nsactions onchain. > Such Feerate-Dependent Timelocks (FDTs) can be used to make the above cha= nnel and factory protocols resistant to sudden spikes in blockchain congest= ion. > In the normal case, when there's no spike in congestion, FDTs don't exten= d the lengths of timelocks and thus don't create a tradeoff between capital= efficiency and safety. > On the other hand, when congestion spikes, FDTs extend the lengths of tim= elocks and thus penalize the owner of the timelocked capital by reducing it= s efficiency. > Therefore, FDTs can be viewed as creating a penalty for spamming the bloc= kchain, thus reducing the likelihood of such an attack even if the channel = (or factory) protocol being used doesn't have an explicit penalty mechanism= . > > FDTs have other uses, including reducing the risk of having to pay unexpe= ctedly high fees during a congestion spike, improving the accuracy of fee-p= enalties [5] and reducing the risk of one-shot receives [12]. > > Of separate interest, the analysis of FDTs given here leads to an exact a= nalysis of the risk of double spend attacks that corrects an error in the o= riginal Bitcoin whitepaper [13]. > > A more complete description and analysis of FDTs is given in a paper [14]= . > > Feerate-Dependent Timelock (FDT) Proposal > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > A Feerate-Dependent Timelock (FDT) is created by encoding a feerate upper= bound in a transaction's nSequence field. > A transaction with an FDT cannot be put onchain until: > 1) its absolute timelock encoded in its nLocktime field (and its relati= ve timelock encoded in the same nSequence field, if present) has been satis= fied, and > 2) the prevailing feerate has fallen below the FDT's feerate upper boun= d. > As a result, FDTs are automatically extended when the feerate for putting= transactions onchain spikes (such as would occur during a forced expiratio= n spam attack). > > In order to determine the prevailing feerate, the median feerate of each = block is calculated as the feerate (in satoshis/vbyte) that is paid for at = least half of the block's vbytes. > > If all miners were honest, a single block with a low median feerate would= be enough to guarantee that congestion is low. > However, even a small fraction of dishonest miners would be able to occas= ionally mine a block with an artificially low feerate. > As a result, it isn't safe to wait for one block (or some other fixed num= ber of blocks) with a low feerate in order to guarantee that honest users h= ave had an opportunity to put their transactions onchain. > > Instead, an FDT requires that some maximum number of blocks within an ali= gned window of consecutive blocks have a high median feerate. > The FDT proposal uses 14 currently masked-off bits in the nSequence field= to express the FDT's three parameters: > * feerate_value, > * window_size, and > * block_count. > An aligned window of window_size blocks satisfies the FDT's parameters if= it has fewer than block_count blocks with median feerate above feerate_val= ue. > A transaction with an FDT can only be put onchain after an aligned window= that satisfies the FDT's parameters and starts no earlier than when the tr= ansaction's absolute timelock (and corresponding relative timelock, if pres= ent) is satisfied. > > In addition, the CheckSequenceVerify (CSV) operator is extended to enforc= e the desired feerate_value, window_size and block_count. > The details are given in the paper [14]. > > Safe Lightning Channels And Factories > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > In order to protect a channel or factory protocol against forced expirati= on spam attacks, the protocol's timelocks are made to be feerate-dependent. > This is done by selecting a feerate_value (such as 4 times the current fe= erate) that would be caused by a forced expiration spam attack, along with = the desired window_size and block_count parameters. > > It's also possible to create multiple conflicting transactions with diffe= rent FDTs (with later timelocks allowing higher feerates) in order to avoid= timelocks that will never expire if feerates remain high permanently. > > Other Uses > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > FDTs have uses in addition to protecting channel and factory protocols fr= om forced expiration spam attacks. > > For example, FDTs can protect users that are racing against timelocks fro= m having to pay an unexpectedly high feerate due to temporary feerate fluct= uations [14]. > In addition, FDTs can be used to improve the accuracy of fee-penalties th= at are assessed when a casual user puts their timeout-tree leaf onchain [14= ](Section 4.10 of [5]). > Finally, FDTs can be used to allow a casual user to submit a transaction = to the blockchain without having to then monitor the blockchain for a sudde= n spike in feerates, thus reducing the risk of one-shot receives [14][12]. > > Analysis > =3D=3D=3D=3D=3D=3D=3D=3D > > FDT Implementation Cost > ----------------------- > In order to verify an FDT, nodes have to determine whether or not there i= s an aligned window with a sufficient number of low-feerate blocks after th= e FDT's absolute timelock (and corresponding relative timelock, if present)= is satisfied. > Therefore, if a node knows the starting block of the most recent aligned = window that satisfies the FDT's feerate_value, window_size, and block_count= parameters, the node can compare that starting block with the FDT's timelo= cks to verify the FDT. > Because the FDT parameters can be expressed using 14 bits, nodes only hav= e to keep track of the starting block for 2^14 =3D 16k different low-feerat= e windows. > The starting block for each such window can be stored in 4 bytes, so 16k = * 4B =3D 64kB of memory allows a node to verify an FDT in constant time. > (In practice, slightly more memory could be used in order to accommodate = a reordering of the most recent 1k blocks.) > Therefore, DRAM that costs less than one cent, plus a small constant numb= er of computations, suffice to verify an FDT. > > FDT Dishonest Miner Attacks > --------------------------- > The window_size and block_count parameters can be selected to balance bet= ween: > 1) latency, > 2) the feerate paid by honest users, and > 3) security against dishonest miners. > At one extreme, if dishonest miners are of no concern, window_size and bl= ock_count can be set to 1, so the FDT can be satisfied when the first block= with a sufficiently low feerate is mined. > At the other extreme, if dishonest miners are of great concern, window_si= ze can be set to 16k and block_count can be set to 1024, in which case dish= onest miners with 45% of the hashpower would have less than a 10^-33 chance= of dishonestly mining enough blocks in a given window to satisfy the FDT p= rior to the honest users being able to get their transactions onchain [14]. > > Double Spend Attacks > -------------------- > While it's unrelated to FDTs, the analysis of FDTs' resistance to dishone= st miner attacks can also be used to analyze the risk of double spend attac= ks. > > The original Bitcoin whitepaper [13] includes an analysis of the probabil= ity of a double spend attack in which a dishonest party colludes with disho= nest miners in order to undo a bitcoin transaction and steal the goods purc= hased with that transaction. > That analysis correctly shows that the probability of success of a double= spend attack falls exponentially with z, the depth of the transaction that= 's being double spent. > However, there are two problems with that analysis: > 1) it is approximate, and > 2) it ignores the possibility of the dishonest miners using pre-mining. > > The first problem was addressed by Grunspan and Perez-Marco [15]. > However, it doesn't appear that the second problem has been addressed pre= viously. > > Exact formulas for the risk of double spend attacks, including pre-mining= , are given in the paper [14] and programs that implement those formulas ar= e available on GitHub [16]. > > The effect of including pre-mining only becomes apparent when a large fra= ction of the miners are dishonest. > For example, Nakamoto estimates the required value of z to guarantee at m= ost a 0.1% chance of a successful double spend, and Grunspan and Perez-Marc= o give exact values assuming no pre-mining. > Those results, plus exact results with pre-mining, are as follows: > > % dishonest Estimated z w/o Exact z w/o Exact z w/ > miners pre-mining [13] pre-mining [15] pre-mining [14] > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > 10 5 6 6 > 15 8 9 9 > 20 11 13 13 > 25 15 20 20 > 30 24 32 33 > 35 41 58 62 > 40 89 133 144 > 45 340 539 589 > > It's important to note that the above results with pre-mining assume that= the time of the double spend attack is not selected by the attacker. > If the attacker can select when to perform the attack, they are guarantee= d to succeed given any value of z, but the expected time required to perfor= m the attack grows exponentially with z [14]. > > Conclusions > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Securing Lightning channels and channel factories against forced expirati= on spam attacks is imperative. > > Feerate-Dependent Timelocks (FDTs) provide this security without forcing = the timelocks to be extended in the typical case, thus avoiding a capital e= fficiency vs. safety tradeoff. > Furthermore, a dishonest user who tries to use a forced expiration spam a= ttack to steal funds is penalized by having their funds timelocked for a lo= nger period, thus discouraging such attacks. > Finally, FDTs can be made to be highly resistant to attacks by dishonest = miners. > > FDTs have other uses, including the reduction of feerate risk and the cal= culation of fee-penalties. > > While implementing FDTs requires some additional DRAM and computation, th= e costs are extremely small. > Given these advantages and their low costs, it's hoped that the Bitcoin c= onsensus rules will be changed to support FDTs. > > Regards, > John > > [1] Poon and Dryja, The Bitcoin Lightning Network, https://lightning.netw= ork/lightning-network-paper.pdf > [2] Burchert, Decker and Wattenhofer, "Scalable Funding of Bitcoin Microp= ayment Channel Networks", http://dx.doi.org/10.1098/rsos.180089 > [3] Decker, Russell and Osuntokun. "eltoo: A Simple Layer2 Protocol for B= itcoin", https://blockstream.com/eltoo.pdf > [4] Law, "Efficient Factories For Lightning Channels", https://github.com= /JohnLaw2/ln-efficient-factories > [5] Law, "Scaling Lightning With Simple Covenants", https://github.com/Jo= hnLaw2/ln-scaling-covenants > [6] Towns, "Re: Scaling Lightning With Simple Covenants", https://lists.l= inuxfoundation.org/pipermail/bitcoin-dev/2023-September/021943.html > [7] Law, "Re: Scaling Lightning With Simple Covenants", https://lists.lin= uxfoundation.org/pipermail/bitcoin-dev/2023-November/022175.html > [8] Towns, "Two-party eltoo w/ punishment", https://lists.linuxfoundation= .org/pipermail/lightning-dev/2022-December/003788.html > [9] Law, "Factory-Optimized Channel Protocols For Lightning", https://git= hub.com/JohnLaw2/ln-factory-optimized > [10] Law, "Lightning Channels With Tunable Penalties", https://github.com= /JohnLaw2/ln-tunable-penalties > [11] Riard, "Solving CoinPool high-interactivity issue with cut-through u= pdate of Taproot leaves", https://lists.linuxfoundation.org/pipermail/bitco= in-dev/2023-September/021969.html > [12] Law, "Watchtower-Free Lightning Channels For Casual Users", https://= github.com/JohnLaw2/ln-watchtower-free > [13] Nakamoto. "Bitcoin: A Peer-to-Peer Electronic Cash System", http://b= itcoin.org/bitcoin.pdf > [14] Law, "Scaling Lightning Safely With Feerate-Dependent Timelocks", ht= tps://github.com/JohnLaw2/ln-fdts > [15] Grunspan and Perez-Marco, "Double Spend Races", CoRR, vol. abs/1702.= 02867, http://arxiv.org/abs/1702.02867v3 > [16] Law, https://github.com/JohnLaw2/ln-fdts > > > > > Sent with Proton Mail secure email. > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --00000000000053740c060cbc9d8a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi John,

While the idea of using sliding reaction w= indow for blockchain congestion detection has been present in the "sma= rt 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 fe= e rates for Bitcoin I'm aware off, to the best of my knowledge.<= /div>
Here my understanding of the feerate-dependent timel=
ock proposal.

A transaction cannot be included in a block:
- height-based or epoch-based absolute or relative timelocks are not satisf=
ied according to current consensus rules (bip68 and bip 113 and implementat=
ion details)
- less than `block_count` has a block median-feerate above the median-feera=
te 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 w=
eight 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 delay=
ed.

E.g let's say you have a LN-penalty Alice-Bob channel. Second-stage HTL=
C 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 guar=
antees tampering-robustness of the feerate_value_bound in face of miners co=
alitions).

There is 1 BTC offered HTLC pending with expiration time T, from Alice to B=
ob.

If at time T, the per-block median feerate of at least 70 blocks over the l=
atest 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 t=
he lineaments of a solution to the "Forced Expiration Spam" as de=
scribed 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 ensu=
re 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 yo=
u 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 param=
eter : `claim_grace_period`, a new type of relative timelock of which the e=
ndpoint should be the `feerate_value_bound` itself.

I think it works in terms of consensus chain state, validation resources an=
d 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-locke=
d transactions changes too, though this is already the case with timelock-e=
ncumbered 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 wo=
uld 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 su=
ch "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 construc=
tions.
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 proposa=
l solving one of the most imperative issues of Lightning and other time-sen=
sitive use-cases.
(Note, I've not reviewed the analysis and game-theory in the face of mi=
ners collusion / coalition, as I think the introduction of a `claim_grace_p=
eriod` is modifying the fundamentals).

Best,
Antoine

[0] https://fc22.if=
ca.ai/preproceedings/119.pdf
[1] https://github.com/ariard/bitcoin-con=
tracting-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-d=
ev/2023-October/022093.html
[4] https=
://github.com/bitcoin-inquisition/bitcoin/pull/9
[5]=C2=A0<=
a href=3D"https://github.com/bitcoin/bips/pull/1381">https://github.com/bit=
coin/bips/pull/1381=

Le=C2=A0ven. 15 d=C3=A9c. 2023 =C3=A0=C2=A009:20, jlspc= via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> a =C3=A9crit=C2=A0:
TL;DR
=3D=3D=3D=3D=3D
* All known Lightning channel and factory protocols are susceptible to forc=
ed expiration spam attacks, in which an attacker floods the blockchain with=
 transactions in order to prevent honest users from putting their transacti=
ons onchain before timelocks expire.
* Feerate-Dependent Timelocks (FDTs) are timelocks that automatically exten=
d when blockchain feerates spike.
=C2=A0 - In the normal case, there's no spike in feerates and thus no t=
radeoff between capital efficiency and safety.
=C2=A0 - If a dishonest user attempts a forced expiration spam attack, feer=
ates increase and FDTs are extended, thus penalizing the attacker by keepin=
g their capital timelocked for longer.
=C2=A0 - 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 attac=
ks is presented that corrects an error in the original Bitcoin whitepaper.

Overview
=3D=3D=3D=3D=3D=3D=3D=3D

Because the Lightning protocol relies on timelocks to establish the correct=
 channel state, Lightning users could lose their funds if they're unabl=
e to put their transactions onchain quickly enough.
The original Lightning paper [1] states that "[f]orced expiration of m=
any 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 "s=
pamming the blockchain to encourage transactions to timeout" is "=
imperative" [1].

Channel factories that create multiple Lightning channels with a single onc=
hain transaction [2][3][4][5] increase this risk in two ways.
First, factories allow more channels to be created, thus increasing the pot=
ential 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 w=
ithout an attack from a malicious party.
Blockchain congestion is highly variable and new applications (such as ordi=
nals) can cause a sudden spike in congestion at any time.
As a result, timelocks that were set when congestion was low can be too sho=
rt when congestion spikes.
Even worse, a spike in congestion could be self-reinforcing if it causes ma=
licious 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 lon=
ger timelocks that give honest users more time to put their transactions on=
chain.
However, long timelocks limit the ability to dynamically reassign the chann=
el'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, s=
upporting billions (or tens of billions) of channels while maintaining safe=
ty 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 vers=
ion of the two-party eltoo protocol [8], the fully-factory-optimized protoc=
ol [9], and the tunable-penalty channel protocol [10] include such penaltie=
s.
In addition, the tunable-penalty and single-commitment factory protocols [4=
] support penalties.
However, as was noted in the original Lightning paper [1], penalties don=
9;t eliminate the risk of a forced expiration spam attack.
Furthermore, existing penalty-based factory protocols [4] have limited scal=
ability, as they depend on getting large numbers of casual users to coordin=
ate and co-sign transactions [11][5].

In contrast, the timeout-tree protocol [5] scales via simple covenants (ena=
bled by support for CheckTemplateVerify, AnyPrevOut, or a similar change to=
 the Bitcoin consensus rules).
As a result, a single timeout-tree can support millions of channels and one=
 small transaction per block can fund timeout-trees with tens of billions o=
f offchain channels [5].
However, timeout-trees don't support penalties, and like all other know=
n factory protocols [2][3][4], timeout-trees rely on timelocks.

Therefore, if the need to protect against forced expiration spam was alread=
y "imperative" for the original Lightning channel protocol [1], t=
he use of scalable channel factories will make such protection indispensabl=
e.

This post proposes a change to Bitcoin's consensus rules that allows th=
e length of a timelock to depend on the feerate being charged for putting t=
ransactions onchain.
Such Feerate-Dependent Timelocks (FDTs) can be used to make the above chann=
el and factory protocols resistant to sudden spikes in blockchain congestio=
n.
In the normal case, when there's no spike in congestion, FDTs don't=
 extend the lengths of timelocks and thus don't create a tradeoff betwe=
en capital efficiency and safety.
On the other hand, when congestion spikes, FDTs extend the lengths of timel=
ocks and thus penalize the owner of the timelocked capital by reducing its =
efficiency.
Therefore, FDTs can be viewed as creating a penalty for spamming the blockc=
hain, thus reducing the likelihood of such an attack even if the channel (o=
r factory) protocol being used doesn't have an explicit penalty mechani=
sm.

FDTs have other uses, including reducing the risk of having to pay unexpect=
edly high fees during a congestion spike, improving the accuracy of fee-pen=
alties [5] and reducing the risk of one-shot receives [12].

Of separate interest, the analysis of FDTs given here leads to an exact ana=
lysis of the risk of double spend attacks that corrects an error in the ori=
ginal Bitcoin whitepaper [13].

A more complete description and analysis of FDTs is given in a paper [14].

Feerate-Dependent Timelock (FDT) Proposal
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

A Feerate-Dependent Timelock (FDT) is created by encoding a feerate upper b=
ound in a transaction's nSequence field.
A transaction with an FDT cannot be put onchain until:
=C2=A0 1) its absolute timelock encoded in its nLocktime field (and its rel=
ative timelock encoded in the same nSequence field, if present) has been sa=
tisfied, and
=C2=A0 2) the prevailing feerate has fallen below the FDT's feerate upp=
er bound.
As a result, FDTs are automatically extended when the feerate for putting t=
ransactions onchain spikes (such as would occur during a forced expiration =
spam attack).

In order to determine the prevailing feerate, the median feerate of each bl=
ock is calculated as the feerate (in satoshis/vbyte) that is paid for at le=
ast half of the block's vbytes.

If all miners were honest, a single block with a low median feerate would b=
e enough to guarantee that congestion is low.
However, even a small fraction of dishonest miners would be able to occasio=
nally mine a block with an artificially low feerate.
As a result, it isn't safe to wait for one block (or some other fixed n=
umber of blocks) with a low feerate in order to guarantee that honest users=
 have had an opportunity to put their transactions onchain.

Instead, an FDT requires that some maximum number of blocks within an align=
ed window of consecutive blocks have a high median feerate.
The FDT proposal uses 14 currently masked-off bits in the nSequence field t=
o express the FDT's three parameters:
=C2=A0 * feerate_value,
=C2=A0 * window_size, and
=C2=A0 * block_count.
An aligned window of window_size blocks satisfies the FDT's parameters =
if it has fewer than block_count blocks with median feerate above feerate_v=
alue.
A transaction with an FDT can only be put onchain after an aligned window t=
hat satisfies the FDT's parameters and starts no earlier than when the =
transaction's absolute timelock (and corresponding relative timelock, i=
f present) is satisfied.

In addition, the CheckSequenceVerify (CSV) operator is extended to enforce =
the desired feerate_value, window_size and block_count.
The details are given in the paper [14].

Safe Lightning Channels And Factories
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

In order to protect a channel or factory protocol against forced expiration=
 spam attacks, the protocol's timelocks are made to be feerate-dependen=
t.
This is done by selecting a feerate_value (such as 4 times the current feer=
ate) that would be caused by a forced expiration spam attack, along with th=
e desired window_size and block_count parameters.

It's also possible to create multiple conflicting transactions with dif=
ferent FDTs (with later timelocks allowing higher feerates) in order to avo=
id timelocks that will never expire if feerates remain high permanently.

Other Uses
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

FDTs have uses in addition to protecting channel and factory protocols from=
 forced expiration spam attacks.

For example, FDTs can protect users that are racing against timelocks from =
having to pay an unexpectedly high feerate due to temporary feerate fluctua=
tions [14].
In addition, FDTs can be used to improve the accuracy of fee-penalties that=
 are assessed when a casual user puts their timeout-tree leaf onchain [14](=
Section 4.10 of [5]).
Finally, FDTs can be used to allow a casual user to submit a transaction to=
 the blockchain without having to then monitor the blockchain for a sudden =
spike in feerates, thus reducing the risk of one-shot receives [14][12].

Analysis
=3D=3D=3D=3D=3D=3D=3D=3D

FDT Implementation Cost
-----------------------
In order to verify an FDT, nodes have to determine whether or not there is =
an aligned window with a sufficient number of low-feerate blocks after the =
FDT's absolute timelock (and corresponding relative timelock, if presen=
t) is satisfied.
Therefore, if a node knows the starting block of the most recent aligned wi=
ndow that satisfies the FDT's feerate_value, window_size, and block_cou=
nt parameters, the node can compare that starting block with the FDT's =
timelocks to verify the FDT.
Because the FDT parameters can be expressed using 14 bits, nodes only have =
to keep track of the starting block for 2^14 =3D 16k different low-feerate =
windows.
The starting block for each such window can be stored in 4 bytes, so 16k * =
4B =3D 64kB of memory allows a node to verify an FDT in constant time.
(In practice, slightly more memory could be used in order to accommodate a =
reordering of the most recent 1k blocks.)
Therefore, DRAM that costs less than one cent, plus a small constant number=
 of computations, suffice to verify an FDT.

FDT Dishonest Miner Attacks
---------------------------
The window_size and block_count parameters can be selected to balance betwe=
en:
=C2=A0 1) latency,
=C2=A0 2) the feerate paid by honest users, and
=C2=A0 3) security against dishonest miners.
At one extreme, if dishonest miners are of no concern, window_size and bloc=
k_count can be set to 1, so the FDT can be satisfied when the first block w=
ith a sufficiently low feerate is mined.
At the other extreme, if dishonest miners are of great concern, window_size=
 can be set to 16k and block_count can be set to 1024, in which case dishon=
est miners with 45% of the hashpower would have less than a 10^-33 chance o=
f dishonestly mining enough blocks in a given window to satisfy the FDT pri=
or to the honest users being able to get their transactions onchain [14].

Double Spend Attacks
--------------------
While it's unrelated to FDTs, the analysis of FDTs' resistance to d=
ishonest miner attacks can also be used to analyze the risk of double spend=
 attacks.

The original Bitcoin whitepaper [13] includes an analysis of the probabilit=
y of a double spend attack in which a dishonest party colludes with dishone=
st miners in order to undo a bitcoin transaction and steal the goods purcha=
sed with that transaction.
That analysis correctly shows that the probability of success of a double s=
pend attack falls exponentially with z, the depth of the transaction that&#=
39;s being double spent.
However, there are two problems with that analysis:
=C2=A0 1) it is approximate, and
=C2=A0 2) it ignores the possibility of the dishonest miners using pre-mini=
ng.

The first problem was addressed by Grunspan and Perez-Marco [15].
However, it doesn't appear that the second problem has been addressed p=
reviously.

Exact formulas for the risk of double spend attacks, including pre-mining, =
are given in the paper [14] and programs that implement those formulas are =
available on GitHub [16].

The effect of including pre-mining only becomes apparent when a large fract=
ion of the miners are dishonest.
For example, Nakamoto estimates the required value of z to guarantee at mos=
t a 0.1% chance of a successful double spend, and Grunspan and Perez-Marco =
give exact values assuming no pre-mining.
Those results, plus exact results with pre-mining, are as follows:

% dishonest =C2=A0Estimated z w/o =C2=A0 =C2=A0 =C2=A0Exact z w/o =C2=A0 =
=C2=A0 =C2=A0 Exact z w/
=C2=A0 =C2=A0 =C2=A0miners =C2=A0pre-mining [13] =C2=A0pre-mining [15] =C2=
=A0pre-mining [14]
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =C2=A0=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D =C2=A0=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =C2=A0=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A010 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A05 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A06=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A06
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A015 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A08 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A09=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A09
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A020 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 11 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 13 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 13
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A025 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 15 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 20 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 20
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A030 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 24 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 32 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 33
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A035 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 41 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 58 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 62
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A040 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 89 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0133 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0144
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A045 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0340 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0539 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0589

It's important to note that the above results with pre-mining assume th=
at the time of the double spend attack is not selected by the attacker.
If the attacker can select when to perform the attack, they are guaranteed =
to succeed given any value of z, but the expected time required to perform =
the attack grows exponentially with z [14].

Conclusions
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Securing Lightning channels and channel factories against forced expiration=
 spam attacks is imperative.

Feerate-Dependent Timelocks (FDTs) provide this security without forcing th=
e timelocks to be extended in the typical case, thus avoiding a capital eff=
iciency vs. safety tradeoff.
Furthermore, a dishonest user who tries to use a forced expiration spam att=
ack to steal funds is penalized by having their funds timelocked for a long=
er period, thus discouraging such attacks.
Finally, FDTs can be made to be highly resistant to attacks by dishonest mi=
ners.

FDTs have other uses, including the reduction of feerate risk and the calcu=
lation of fee-penalties.

While implementing FDTs requires some additional DRAM and computation, the =
costs are extremely small.
Given these advantages and their low costs, it's hoped that the Bitcoin=
 consensus rules will be changed to support FDTs.

Regards,
John

[1] Poon and Dryja, The Bitcoin Lightning Network, https://lightni=
ng.network/lightning-network-paper.pdf
[2] Burchert, Decker and Wattenhofer, "Scalable Funding of Bitcoin Mic=
ropayment Channel Networks", http://dx.doi.org/10.1098/rsos.180089
[3] Decker, Russell and Osuntokun. "eltoo: A Simple Layer2 Protocol fo=
r Bitcoin", https://blockstream.com/eltoo.pdf
[4] Law, "Efficient Factories For Lightning Channels", http=
s://github.com/JohnLaw2/ln-efficient-factories
[5] Law, "Scaling Lightning With Simple Covenants", https://g=
ithub.com/JohnLaw2/ln-scaling-covenants
[6] Towns, "Re: Scaling Lightning With Simple Covenants", https://lists.linuxfoundation.org/pipermail/=
bitcoin-dev/2023-September/021943.html
[7] Law, "Re: Scaling Lightning With Simple Covenants", https://lists.linuxfoundation.org/pipermail/b=
itcoin-dev/2023-November/022175.html
[8] Towns, "Two-party eltoo w/ punishment", https://lists.linuxfoundation.org/pipermail/lightning-dev=
/2022-December/003788.html
[9] Law, "Factory-Optimized Channel Protocols For Lightning", https://github.com/JohnLaw2/ln-factory-optimized
[10] Law, "Lightning Channels With Tunable Penalties", https:=
//github.com/JohnLaw2/ln-tunable-penalties
[11] Riard, "Solving CoinPool high-interactivity issue with cut-throug=
h update of Taproot leaves", htt=
ps://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-September/021969.=
html
[12] Law, "Watchtower-Free Lightning Channels For Casual Users", =
https://github.com/JohnLaw2/ln-watchtower-free
[13] Nakamoto. "Bitcoin: A Peer-to-Peer Electronic Cash System", =
http://bitcoin=
.org/bitcoin.pdf
[14] Law, "Scaling Lightning Safely With Feerate-Dependent Timelocks&q=
uot;, htt=
ps://github.com/JohnLaw2/ln-fdts
[15] Grunspan and Perez-Marco, "Double Spend Races", CoRR, vol. a=
bs/1702.02867, http://arxiv.org/abs/1702.02867v3
[16] Law, https://github.com/JohnLaw2/ln-fdts



=20
=20
Sent with Proton Mail secure email.
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--00000000000053740c060cbc9d8a--