diff options
| author | Nagaev Boris <bnagaev@gmail.com> | 2023-12-22 13:36:56 -0300 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2023-12-22 16:37:37 +0000 |
| commit | 65ee846f41b17134098029d5ebd94e42f6bed41c (patch) | |
| tree | b8055fba8c46488a2af855470f8678d655c9c497 | |
| parent | bd33ea52fd57e621a05a8563a7a650bd0cc4a7e8 (diff) | |
| download | pi-bitcoindev-65ee846f41b17134098029d5ebd94e42f6bed41c.tar.gz pi-bitcoindev-65ee846f41b17134098029d5ebd94e42f6bed41c.zip | |
Re: [bitcoin-dev] Scaling Lightning Safely With Feerate-Dependent Timelocks
| -rw-r--r-- | bc/1a5144d61220e3405bb8925376a5548c37dcfb | 480 |
1 files changed, 480 insertions, 0 deletions
diff --git a/bc/1a5144d61220e3405bb8925376a5548c37dcfb b/bc/1a5144d61220e3405bb8925376a5548c37dcfb new file mode 100644 index 000000000..85ccb2f60 --- /dev/null +++ b/bc/1a5144d61220e3405bb8925376a5548c37dcfb @@ -0,0 +1,480 @@ +Return-Path: <bnagaev@gmail.com> +Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) + by lists.linuxfoundation.org (Postfix) with ESMTP id C4928C0037; + Fri, 22 Dec 2023 16:37:37 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by smtp3.osuosl.org (Postfix) with ESMTP id 8B5FC6F57A; + Fri, 22 Dec 2023 16:37:37 +0000 (UTC) +DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 8B5FC6F57A +Authentication-Results: smtp3.osuosl.org; + dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com + header.a=rsa-sha256 header.s=20230601 header.b=lqG/jb5d +X-Virus-Scanned: amavisd-new at osuosl.org +X-Spam-Flag: NO +X-Spam-Score: -2.099 +X-Spam-Level: +X-Spam-Status: No, score=-2.099 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, + RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] + autolearn=ham autolearn_force=no +Received: from smtp3.osuosl.org ([127.0.0.1]) + by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id z_Iybnwk1345; Fri, 22 Dec 2023 16:37:35 +0000 (UTC) +Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com + [IPv6:2607:f8b0:4864:20::d32]) + by smtp3.osuosl.org (Postfix) with ESMTPS id EFCFA60BE7; + Fri, 22 Dec 2023 16:37:34 +0000 (UTC) +DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org EFCFA60BE7 +Received: by mail-io1-xd32.google.com with SMTP id + ca18e2360f4ac-7b7f9fdc14dso105686439f.0; + Fri, 22 Dec 2023 08:37:34 -0800 (PST) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=gmail.com; s=20230601; t=1703263053; x=1703867853; + darn=lists.linuxfoundation.org; + h=content-transfer-encoding:cc:to:subject:message-id:date:from + :in-reply-to:references:mime-version:from:to:cc:subject:date + :message-id:reply-to; + bh=1wsOHOEFOzL8PJJYwyrL/MBZPvD0Vh8Fxe6wTyeNSV8=; + b=lqG/jb5d90tp7KSyqSnn6BgPuCWncbCpY2+983/Z+X3LIqOWedZYueT7tVhYfhPeJt + af76cehNMo40fdHMkxVhZtl0hAW42URHHF1k+sCH9mdtW2t2suyZ8H9CpE+LshMRQMXf + aZJkQQXKbUhe4SO3/5sfG8Vi6lJb+D0J9OauEjdG7tkwXJ/JlBKYmfyU8owtiM3OAmKR + xasXV7+V7aIf897elX8/Qy2eNpBNhlgdpB05+U97tJLZa23xS+nkJSA426MQQyj+Egg5 + yBWU3znbtkxXz4KQpSsrLsMzXHDFscb18sSnoSlWOHqe5FcphbTMVHkIWmUJ7IkBZUUt + hhvw== +X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=1e100.net; s=20230601; t=1703263053; x=1703867853; + h=content-transfer-encoding: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=1wsOHOEFOzL8PJJYwyrL/MBZPvD0Vh8Fxe6wTyeNSV8=; + b=uqCoiIOvwlkx3RmNNlLzJTwRrrR1RetNnfPFL/xvIxVeiQNzzGhpvRNFpIYQDfLyRl + QD9pyT2gQUCjTgF5au/nGO+RvLtkaTDIiUqFgWtymCDvcO6kvSf3LPkX0AtB1AKrry9G + YOfedxsC5MPQldV4HZhxO5zbEvPnn6z7fTNjbVYks3rRHS/8dUsOF12jvrct82/VRL+8 + g3JlzrUx6MXQlrUlLxHglZHUvd0D45sjHo0Y/cmLxo/vdqVxxPcIUKDMgLCtSM+zEYbc + i8rqDVP1fC9qFdJC8tOE/qUzPhQc/fO0RloB2mjp8nnZPlRjCoONRz7/VIXQPwSObg/2 + +04w== +X-Gm-Message-State: AOJu0YzLh62FQF3IyxZr7aiZ0Vs2j/b6UgliKTUxDxf2JA2z7SlnDahP + wHovZd4nGs1HBa1jAqO2icgMUyxhI0l9LNeSCpt1+WT/iixTKmG3 +X-Google-Smtp-Source: AGHT+IE+PIIqxvYDWYmZJ3Q+AGqHGjji7uAoQJJUJcroscE2vvnV7tmA3XjzFAVGAT/vIxVVHtHJi2QXe2RM6HW9VDA= +X-Received: by 2002:a05:6e02:b41:b0:35f:ca9d:6c4a with SMTP id + f1-20020a056e020b4100b0035fca9d6c4amr1688038ilu.27.1703263053356; Fri, 22 Dec + 2023 08:37:33 -0800 (PST) +MIME-Version: 1.0 +References: <sJXy1yFGGxPpgtCexzW2WZhMMpJonGlOaT0Gb_eyQdUIOKPRXQ8tqrNvvunPF5E19kFEAeq5IHXx7Y7qkAFoEkGBS3JP5Tq3uFtSAVRg4NY=@protonmail.com> +In-Reply-To: <sJXy1yFGGxPpgtCexzW2WZhMMpJonGlOaT0Gb_eyQdUIOKPRXQ8tqrNvvunPF5E19kFEAeq5IHXx7Y7qkAFoEkGBS3JP5Tq3uFtSAVRg4NY=@protonmail.com> +From: Nagaev Boris <bnagaev@gmail.com> +Date: Fri, 22 Dec 2023 13:36:56 -0300 +Message-ID: <CAFC_Vt7yJCN3a8d5dxmsbpz6i50pXAbSBhgA_HvBYifnoJxrQQ@mail.gmail.com> +To: jlspc <jlspc@protonmail.com>, + Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +Content-Type: text/plain; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable +X-Mailman-Approved-At: Sat, 23 Dec 2023 10:25:40 +0000 +Cc: "lightning-dev@lists.linuxfoundation.org" + <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 <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> +X-List-Received-Date: Fri, 22 Dec 2023 16:37:37 -0000 + +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 (=3D 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 <=3D 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=E2=80=AFAM jlspc via bitcoin-dev +<bitcoin-dev@lists.linuxfoundation.org> wrote: +> +> 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 + + + +--=20 +Best regards, +Boris Nagaev + |