From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 6C6D1C0037 for ; Sat, 23 Dec 2023 04:09:30 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 33DAC822B3 for ; Sat, 23 Dec 2023 04:09:30 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 33DAC822B3 Authentication-Results: smtp1.osuosl.org; dkim=pass (2048-bit key) header.d=voskuil-org.20230601.gappssmtp.com header.i=@voskuil-org.20230601.gappssmtp.com header.a=rsa-sha256 header.s=20230601 header.b=t2mrIElA X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.005 X-Spam-Level: X-Spam-Status: No, score=-1.005 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.1, MIME_HTML_ONLY_MULTI=0.001, MIME_QP_LONG_LINE=0.001, MPART_ALT_DIFF=0.79, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uJx72Czm8Yty for ; Sat, 23 Dec 2023 04:09:28 +0000 (UTC) Received: from mail-qv1-xf2e.google.com (mail-qv1-xf2e.google.com [IPv6:2607:f8b0:4864:20::f2e]) by smtp1.osuosl.org (Postfix) with ESMTPS id 1B90D82238 for ; Sat, 23 Dec 2023 04:09:28 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 1B90D82238 Received: by mail-qv1-xf2e.google.com with SMTP id 6a1803df08f44-67f564b4245so5541766d6.1 for ; Fri, 22 Dec 2023 20:09:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=voskuil-org.20230601.gappssmtp.com; s=20230601; t=1703304567; x=1703909367; darn=lists.linuxfoundation.org; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:from:to:cc:subject:date:message-id :reply-to; bh=ZvhBmf8eCOf9ROUGtyUp1kI6j9IYzknWly8C8oa2JTs=; b=t2mrIElAElsLCxbi10BDHRMNepK/ipoZcDjDdXC/JQ1q/UkDx4vwCtnZyrDS0sbkiX pw6DJ2kfEMY4bIlX4pyJmJPvWKjtiicFIC3WNgrHA/3t3qS9qLjIct5WaK/bFqRJU5Ta C8LyK/ukPNlCxduiX5K8hydrqjcdpjf1/FDgVeyVVtp6P+VbFQYyMKTDMOpKuGx8ZJlQ w42RKvy5X70qDekTSrQVI1CGzelqPvLzKxQ9xoWaE19vVLuscVp7b+NbBsGhTrNter7O vYckrPwfOu7Ll0EDc7v2tGYbRSoHXLrEHD7CQVHjRKFK3Ma0gkKKcG1gUe5Z5VBRicl/ 6JLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1703304567; x=1703909367; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=ZvhBmf8eCOf9ROUGtyUp1kI6j9IYzknWly8C8oa2JTs=; b=fUS2/UbRmqbFVJn9L0ilYZMl0GjRpfydpAe62eWLj4/jpTyuwzBR+Rue1S2sJ2a9pR /tr8h/pS9BNs1i+FXpi9bynHJZc6plsnHMDNioo9T10Nwo787ZWWiPAwDa4x7iEz11dB d/NG1z7YFFO6AxRTRaRXOZbHNP52Szwi9YxQjIQRFu3gKeZjyRmdFcHRg/B/I3ypowOe My34pVOgQJZv7+Y6/IQr+x2dqLimNDqtH9rR1c740iOeXetvJpCh/LYrb0brbYAdbEwa GJlp5RHsu3Yc6CkkiWsjEdOjJGglF0z1LgVgbH8TVWd/2YTkcrtmXvgEJiOqSvy6l/do UqNQ== X-Gm-Message-State: AOJu0YxbQVCSXmelsHTKgXQATUrwCYB/fDrH4OO8kkIU2f1KEVc9DqWM aYDyDBII35BBn/U2NHSW0DPu8XkYC58F2ceDrSDep+z7EvU= X-Google-Smtp-Source: AGHT+IGs7Tr40V1U6zyyop3/BEaOMCq9Wxme49kbQB8wbdDHKWE50pFRUWkB5hhm3QjTIENLL118rQ== X-Received: by 2002:a05:620a:46a3:b0:781:22ad:c89d with SMTP id bq35-20020a05620a46a300b0078122adc89dmr5144924qkb.4.1703304566555; Fri, 22 Dec 2023 20:09:26 -0800 (PST) Received: from smtpclient.apple ([2601:188:cc7f:e751:c50c:c269:8388:ad65]) by smtp.gmail.com with ESMTPSA id bj5-20020a05620a190500b0078118b6cd18sm1781197qkb.43.2023.12.22.20.09.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 22 Dec 2023 20:09:26 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-6E3A7BA2-573A-491E-91EF-6FF6BAC414A8 Content-Transfer-Encoding: 7bit From: Eric Voskuil Mime-Version: 1.0 (1.0) Date: Fri, 22 Dec 2023 23:09:15 -0500 Message-Id: <6B73AF52-FB69-45A3-92BC-CC09204DB64D@voskuil.org> References: In-Reply-To: To: jlspc , Bitcoin Protocol Discussion X-Mailer: iPhone Mail (21B101) 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: Sat, 23 Dec 2023 04:09:30 -0000 --Apple-Mail-6E3A7BA2-573A-491E-91EF-6FF6BAC414A8 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
The= fees paid to mine the set of transactions in a given block are known only t= o the miner that produced the block. Assuming that tx inputs less outputs re= presents an actual economic force is an error.

e

On= Dec 22, 2023, at 09:24, jlspc via bitcoin-dev <bitcoin-dev@lists.linuxfo= undation.org> wrote:

=
=EF=BB=BF
H=
i Antoine,

Thanks for your thoughtful response.

Comments inline below:

> Hi John,

> While the idea of using sliding reaction window for blockchain congesti=
on
> detection has been present in the "smart contract" space at large [0] a=
nd
> this has been discussed informally among Lightning devs and covenant
> designers few times [1] [2], this is the first and best formalization o=
f
> 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 w=
indow 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 t=
he aligned window.
However, once such an aligned window exists in the blockchain, the transacti=
on can appear at any later time (and not just within a window that itself me=
ets 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 s=
uch that the total size of the transactions in B with feerate greater or equ=
al to F is at least 2 million vbytes.

> =46rom 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 t=
o 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 bloc=
ks that starts no earlier than T and that has fewer than 70 blocks with medi=
an feerate above 100 sats/vbyte.
(The values 100, 70, and 100 cannot actually be selected in the implementati=
on in the paper, but that's a technical detail and could be changed if the FD=
T is specified in the annex, as you propose.)

> =46rom 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 addition=
al claim_grace_period in order to allow conflicting transactions from the ot=
her party to win the race?
For example, assume the HTLC-success transaction has a higher feerate than t=
he feerate_value_bound, and the conflicting HTLC-timeout transaction has an =
FDT with the feerate_value_bound (and suitable window_size and block_count p=
arameters to defend against miner attacks).
In this case, is the worry that the HTLC-success and HTLC-timeout transactio=
ns could both be delayed until there is a window W that meets the FDT's feer=
ate_value_bound, window_size and block_count parameters, at which point they=
 would race against each other and either could win?
Is the reason to delay the HTLC-timeout by an additional claim_grace_period t=
o guarantee that the HTLC-success transaction will win the race?
If so, I don't think it's needed, given the exact definition of the FDT prop=
osal.
This is because *during* the window W that meets the FDT's requirements, the=
 HTLC-success transaction should get mined into one of the blocks in W that h=
as a median feerate no larger than feerate_value_bound, assuming honest mine=
rs.
The assumption of honest miners is resolved by setting the window_size and b=
lock_count parameters appropriately.
Does that make sense?

> 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).

It's interesting that you focused on securing HTLCs, as I was focused on sec=
uring LN channel state (e.g., getting the right Commitment tx) and factory s=
tate.
The challenge with using FDTs to secure HTLCs is that you need a way to spec=
ify a sequence of FDTs (corresponding to the hops in a LN payment) that expi=
re with enough time between them and with a low feerate period between them.=

For example, consider a payment with n hops, where hop i has an HTLC that ex=
pires at time T_i, and where hop n is the last hop.
Without FDTs, one would select expiries such that T_i + cltv_expiry_delta_i &=
lt; T_(i-1).
With FDTs, one can't just use the same T_i's and add an FDT that follows tha=
t T_i, because the feerate could be high until well after the first few T_i'=
s are reached.
For example, assume T_n, T_(n-1) and T_(n-2) all occur before feerates fall b=
elow the feerate_value_bound.
In this case, the HTLC-timeout TXs for hops n, n-1 and n-2 would all be dela=
yed until the feerates fell, and then they would all be able to be put oncha=
in at the same time (without the required cltv_expiry_deltas between them).

One attempt to solve this would be to add another parameter that specifies h=
ow many blocks to wait after fees have falled below the feerate_value_bound (=
like the claim_grace_perid, if I understand it correctly).
However, that doesn't solve the problem because the congestion could start, a=
nd the feerate_value_bound could be exceeded, at any time.
For example, the feerate_value_bound could first be exceeded just after T_(n=
-1), in which case the fees would be too high to put the HTLC-success transa=
ction onchain in hop T_(n-2).

What we really need is the ability to ensure that there have been enough low=
 feerate expiries, each separated by the required cltv_expiry_delta.
This can be achieved by adding a new parameter, number_of_windows, that spec=
ifies how many low feerate windows W_1, W_2, etc., are required, all of whic=
h meet the feerate_value_bound, window_size and block_count parameters (and a=
ll of which start no later than when the standard absolute and relative time=
locks have been satisfied).
With this new parameter, lower numbered hops (closer to the sender) can use l=
arger values of number_of_windows in order to guarantee low feerate periods t=
hat meet the required cltv_expiry_deltas.

For example, assume feerate_value_bound is 256 sats/vbyte, window_size is 25=
6, and block_count is 64.
Then, give the HTLC-timeout transaction in hop i an absolute timelock of T_n=
 (the timelock for hop n) and an FDT with number_of_windows equal to (n-i+1)=
 (and with feerate_value_bound, window_size and block_count as above).
In this case, as long as each cltv_expiry_delta is less than window_size - b=
lock_count =3D 192, then in each hop the party offered the HTLC can put thei=
r HTLC-success transaction onchain in a low feerate block after they have se=
en the hash preimage for at least cltv_expiry_delta blocks.
(In practice, the parameters could be tweaked a bit to break the association=
 between hops, such as by using more restrictive feerate_value_bounds and/or=
 block_counts as one gets closer to the source, and by increasing the number=
_of_windows parameter by more than one per hop as one gets closer to the sou=
rce.)

> 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 like your idea of putting the FDT parameters in the annex.
This is required if we add the number_of_windows parameter that I mentioned a=
bove.

In addition to finding enough bits in the transaction to hold the FDT parame=
ters, there is a cost to increasing the parameters, namely the memory requir=
ed to verify transactions with FDTs.
In the proposal in the paper, FDTs could be specified with 14 bits, so there=
 were only 2^14 =3D 16k different values for which the starting block of the=
 most recent aligned window satisfying those parameters has to be stored in o=
rder to quickly verify FDTs.
Assuming 4 bytes to store the starting block of a window, that's just 64k by=
tes of DRAM.
If we add a 6-bit number_of_windows parameter, that increases the storage by=
 a factor of 64 to 4MB.
That's still pretty small, but we have to be careful to not make this too ex=
pensive.

> 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 agree that FDTs don't make timeout-trees more competitive against any othe=
r factory protoocol.
I also agree that FDTs can be used to make all of the LN channel and factory=
 protocools safer.
If we extend the idea to include a number_of_windows parameter, then we shou=
ld even be able to make HTLCs safer.

> 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.

I'm very happy you see it that way.
Please let me know what you think of the number_of_windows idea, and if you h=
ave any other ideas for making HTLCs safer.

Regards,
John


=20
=20
Sent with Proton Mail secure email.

On Sunday, December 17th, 2023 at 3:01 PM, Antoine Riard <antoine= .riard@gmail.com> wrote:

Hi John,

While the idea of= using sliding reaction window for blockchain congestion detection has been p= resent in the "smart contract" space at large [0] and this has been discusse= d informally among Lightning devs and covenant designers few times [1] [2], t= his 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 satisfi=
ed according to current consensus rules (bip68 and bip 113 and implementatio=
n details)
- less than `block_count` has a block median-feerate above the median-feerat=
e 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 sa=
mple)

=46rom 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 w=
ith 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 tra=
nsactions 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 guara=
ntees tampering-robustness of the feerate_value_bound in face of miners coal=
itions).

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

If at time T, the per-block median feerate of at least 70 blocks over the la=
test 100 block is above 100 sat / vbytes, any Alice's HTLC-timeout or Bob's H=
TLC-preimage cannot be included in the chain.

=46rom my understanding, Feerate-Dependent Timelocks effectively constitute t=
he lineaments of a solution to the "Forced Expiration Spam" as described in t=
he LN paper.

I think you have few design caveats to be aware off:
- for current LN-penalty, the revokeable scripts should be modified to ensur=
e the CSV opcode inspect the enforcement of FDT's parameters, as those revok=
eable 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 th=
e FDT delay

As such, I believe the FDT parameters should be enriched with another parame=
ter : `claim_grace_period`, a new type of relative timelock of which the end=
point 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 FD=
T-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-enc=
umbered transactions.

(One corollary for Lightning, it sounds like all the channels carrying on a H=
TLC along a payment path should have the same FDT-parameters to avoid off-ch=
ain HTLC double-spend, a risk not clearly articulated in the LN paper).

Given the one more additional parameter `claim_grace_period`, I think it wou=
ld 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 FD=
T parameters for each of your HTLC outputs in a single LN transaction, if co=
mbined with future covenant mechanisms like HTLC aggregation [3].
(The current annex design draft has been designed among others to enable suc=
h "block-feerate-lock-point" [4] [5])

I cannot assert that the FDT proposal makes the timeout-tree protocol more e=
fficient than state-of-the-art channel factories and payment pool constructi=
ons.
Still from my understanding, all those constructions are sharing frailties i=
n 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 sol=
ving 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 c=
ollusion / coalition, as I think the introduction of a `claim_grace_period` i=
s modifying the fundamentals).

Best,
Antoine

[0] https://fc22.ifca.ai/preproceedings/1=
19.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/02218=
0.html
[3] =
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-October/022093.=
html
[4] https://github.com/bitcoin-=
inquisition/bitcoin/pull/9
[5] <=
/span>https://github.com/bitcoin/bips/pull/1381

Le ven. 15 d=C3=A9c. 2023 =C3= =A0 09:20, jlspc via bitcoin-dev <bit= coin-dev@lists.linuxfoundation.org> a =C3=A9crit :
TL;DR
=3D=3D=3D=3D=3D
* All known Lightning channel and factory protocols are susceptible to force=
d expiration spam attacks, in which an attacker floods the blockchain with t=
ransactions 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 be=
tween capital efficiency and safety.
  - If a dishonest user attempts a forced expiration spam attack, feerates i=
ncrease 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 d=
ishonest miners.
* Of separate interest, an exact analysis of the risk of double spend attack=
s 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 c=
hannel state, Lightning users could lose their funds if they're unable to pu=
t their transactions onchain quickly enough.
The original Lightning paper [1] states that "[f]orced expiration of many tr=
ansactions may be the greatest systemic risk when using the Lightning Networ=
k" and it uses the term "forced expiration spam" for an attack in which a ma=
licious 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 "spammin=
g the blockchain to encourage transactions to timeout" is "imperative" [1].

Channel factories that create multiple Lightning channels with a single onch=
ain transaction [2][3][4][5] increase this risk in two ways.
First, factories allow more channels to be created, thus increasing the pote=
ntial for many channels to require onchain transactions at the same time.
Second, channel factories themselves use timelocks, and thus are vulnerable t=
o a "forced expiration spam" attack.

In fact, the timelocks in Lightning channels and factories are risky even wi=
thout an attack from a malicious party.
Blockchain congestion is highly variable and new applications (such as ordin=
als) can cause a sudden spike in congestion at any time.
As a result, timelocks that were set when congestion was low can be too shor=
t when congestion spikes.
Even worse, a spike in congestion could be self-reinforcing if it causes mal=
icious parties to attack opportunistically and honest parties to put their c=
hannels onchain due to the heightened risk.

One way to reduce the risk of a


_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundati= on.org
https://lists.linuxfoundation.org/mailman/listinfo/bi= tcoin-dev
= --Apple-Mail-6E3A7BA2-573A-491E-91EF-6FF6BAC414A8--