path: root/60/a6df6222da0387d11a157f32243a9986e0a38a

Return-Path: <eric@voskuil.org>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 6C6D1C0037
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <eric@voskuil.org>
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: <nZN2P44mvXo6bYYYjnqBiXNPE1z9nFJ9UP_uvlVYzXt75NcNvmcuAqrVKVkCFDWhS461M3zwEudaXh22x8U5e5ixNe58M7HY9HcWUUZUnoE=@protonmail.com>
In-Reply-To: <nZN2P44mvXo6bYYYjnqBiXNPE1z9nFJ9UP_uvlVYzXt75NcNvmcuAqrVKVkCFDWhS461M3zwEudaXh22x8U5e5ixNe58M7HY9HcWUUZUnoE=@protonmail.com>
To: jlspc <jlspc@protonmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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 <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: 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

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D=
utf-8"></head><body dir=3D"auto"><div dir=3D"ltr"></div><div dir=3D"ltr">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.</div><div dir=3D"ltr"><br></d=
iv><div dir=3D"ltr">e</div><div dir=3D"ltr"><br><blockquote type=3D"cite">On=
 Dec 22, 2023, at 09:24, jlspc via bitcoin-dev &lt;bitcoin-dev@lists.linuxfo=
undation.org&gt; wrote:<br><br></blockquote></div><blockquote type=3D"cite">=
<div dir=3D"ltr">=EF=BB=BF<div style=3D"font-family: Arial, sans-serif; font=
-size: 14px;"><pre style=3D"overflow-wrap:break-word;white-space:pre-wrap">H=
i Antoine,

Thanks for your thoughtful response.

Comments inline below:

&gt; Hi John,

&gt; While the idea of using sliding reaction window for blockchain congesti=
on
&gt; detection has been present in the "smart contract" space at large [0] a=
nd
&gt; this has been discussed informally among Lightning devs and covenant
&gt; designers few times [1] [2], this is the first and best formalization o=
f
&gt; sliding-time-locks in function of block fee rates for Bitcoin I'm aware=

&gt; off, to the best of my knowledge.

Thanks!

&gt; Here my understanding of the feerate-dependent timelock proposal.

&gt; A transaction cannot be included in a block:
&gt; - height-based or epoch-based absolute or relative timelocks are not
&gt; satisfied according to current consensus rules (bip68 and bip 113 and
&gt; implementation details)
&gt; - less than `block_count` has a block median-feerate above the
&gt; 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).

&gt; A median feerate is computed for each block.
&gt; (This is unclear to me if this is the feerate for half of the block's
&gt; weight or the median feerate with all weight units included in the
&gt; 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.

&gt; =46rom then, you have 3 parameters included in the nSequence field.
&gt; - feerate_value_bound
&gt; - window_size
&gt; - block_count

&gt; Those parameters can be selected by the transaction builder (and
&gt; committed with a signature or hash chain-based covenant).
&gt; As such, off-chain construction counterparties can select the
&gt; feerate_value_bound at which their time-sensitive transaction
&gt; confirmation will be delayed.

&gt; E.g let's say you have a LN-penalty Alice-Bob channel. Second-stage
&gt; HTLC transactions are pre-signed with feerate_value_bound at 100 sat /
&gt; vbytes.
&gt; The window_size selected is 100 blocks and the block_count is 70 (this
&gt; guarantees tampering-robustness of the feerate_value_bound in face of
&gt; miners coalitions).

&gt; There is 1 BTC offered HTLC pending with expiration time T, from Alice t=
o Bob.

&gt; If at time T, the per-block median feerate of at least 70 blocks over
&gt; the latest 100 block is above 100 sat / vbytes, any Alice's
&gt; 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.)

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

Great!

&gt; I think you have few design caveats to be aware off:
&gt; - for current LN-penalty, the revokeable scripts should be modified to
&gt; ensure the CSV opcode inspect the enforcement of FDT's parameters, as
&gt; those revokeable scripts are committed by all parties

Yes, definitely.

&gt; - there should be a delay period at the advantage of one party
&gt; otherwise you still a feerate-race if the revocation bip68 timelock
&gt; has expired during the FDT delay

&gt; As such, I believe the FDT parameters should be enriched with another
&gt; parameter : `claim_grace_period`, a new type of relative timelock of
&gt; 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?

&gt; I think it works in terms of consensus chain state, validation
&gt; resources and reorg-safety are all the parameters that are
&gt; self-contained in the spent FDT-encumbered transaction itself.
&gt; If the per-block feerate fluctuates, the validity of the ulterior
&gt; FDT-locked transactions changes too, though this is already the case
&gt; with timelock-encumbered transactions.

&gt; (One corollary for Lightning, it sounds like all the channels carrying
&gt; on a HTLC along a payment path should have the same FDT-parameters to
&gt; avoid off-chain HTLC double-spend, a risk not clearly articulated in
&gt; 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.)

&gt; Given the one more additional parameter `claim_grace_period`, I think
&gt; it would be wiser design to move all the FDT parameters in the bip341
&gt; annex.
&gt; There is more free bits room there and additionally you can have
&gt; different FDT parameters for each of your HTLC outputs in a single LN
&gt; transaction, if combined with future covenant mechanisms like HTLC
&gt; aggregation [3].
&gt; (The current annex design draft has been designed among others to
&gt; 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.

&gt; I cannot assert that the FDT proposal makes the timeout-tree protocol
&gt; more efficient than state-of-the-art channel factories and payment
&gt; pool constructions.
&gt; Still from my understanding, all those constructions are sharing
&gt; frailties in face of blockchain congestion and they would need
&gt; 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.

&gt; I'm truly rejoicing at the idea that we have now the start of a
&gt; proposal solving one of the most imperative issues of Lightning and
&gt; 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</pre><br></div><div style=3D"font-family: Arial, sans-serif; font-size:=
 14px;"><br></div>
<div class=3D"protonmail_signature_block" style=3D"font-family: Arial, sans-=
serif; font-size: 14px;">
    <div class=3D"protonmail_signature_block-user protonmail_signature_block=
-empty">
       =20
            </div>
   =20
            <div class=3D"protonmail_signature_block-proton">
        Sent with <a target=3D"_blank" href=3D"https://proton.me/" rel=3D"no=
opener noreferrer">Proton Mail</a> secure email.
    </div>
</div>
<div style=3D"font-family: Arial, sans-serif; font-size: 14px;"><br></div><d=
iv class=3D"protonmail_quote">
        On Sunday, December 17th, 2023 at 3:01 PM, Antoine Riard &lt;antoine=
.riard@gmail.com&gt; wrote:<br><br>
        <blockquote class=3D"protonmail_quote" type=3D"cite">
            <div dir=3D"ltr"><font face=3D"arial, sans-serif">Hi John,</font=
><div><span style=3D"font-family: arial, sans-serif; white-space: pre-wrap; c=
olor: rgb(0, 0, 0);"><br></span></div><div><span style=3D"font-family: arial=
, sans-serif; white-space: pre-wrap; color: rgb(0, 0, 0);">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.</sp=
an></div><div><pre style=3D"white-space: pre-wrap; color: rgb(0, 0, 0);"><fo=
nt face=3D"arial, sans-serif">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] <a href=3D"https://fc22.ifca.ai/preproceedings/119.pdf" rel=3D"noreferre=
r nofollow noopener" target=3D"_blank">https://fc22.ifca.ai/preproceedings/1=
19.pdf</a>
[1] <a href=3D"https://github.com/ariard/bitcoin-contracting-primitives-wg/b=
lob/main/meetings/meetings-18-04.md" rel=3D"noreferrer nofollow noopener" ta=
rget=3D"_blank">https://github.com/ariard/bitcoin-contracting-primitives-wg/=
blob/main/meetings/meetings-18-04.md</a>
[2] <a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-=
November/022180.html" rel=3D"noreferrer nofollow noopener" target=3D"_blank"=
>https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-November/02218=
0.html</a>
[3] <a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-=
October/022093.html" rel=3D"noreferrer nofollow noopener" target=3D"_blank">=
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-October/022093.=
html</a>
[4] <a href=3D"https://github.com/bitcoin-inquisition/bitcoin/pull/9" rel=3D=
"noreferrer nofollow noopener" target=3D"_blank">https://github.com/bitcoin-=
inquisition/bitcoin/pull/9</a></font></pre><pre style=3D"white-space: pre-wr=
ap; color: rgb(0, 0, 0);"><span style=3D"font-family:arial,sans-serif">[5] <=
/span><span style=3D"font-family:arial,sans-serif"><a href=3D"https://github=
.com/bitcoin/bips/pull/1381" rel=3D"noreferrer nofollow noopener" target=3D"=
_blank">https://github.com/bitcoin/bips/pull/1381</a></span><span style=3D"f=
ont-family:arial,sans-serif"> </span></pre></div></div><br><div class=3D"gma=
il_quote"><div class=3D"gmail_attr" dir=3D"ltr">Le ven. 15 d=C3=A9c. 2023 =C3=
=A0 09:20, jlspc via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.lin=
uxfoundation.org" rel=3D"noreferrer nofollow noopener" target=3D"_blank">bit=
coin-dev@lists.linuxfoundation.org</a>&gt; a =C3=A9crit :<br></div><blockquo=
te style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style=
:solid;border-left-color:rgb(204,204,204);padding-left:1ex" class=3D"gmail_q=
uote"><div style=3D"font-family:Arial,sans-serif;font-size:14px"><pre style=3D=
"white-space:pre-wrap">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 </pre></div><br>
</blockquote></div>

        </blockquote><br>
    </div><span>_______________________________________________</span><br><s=
pan>bitcoin-dev mailing list</span><br><span>bitcoin-dev@lists.linuxfoundati=
on.org</span><br><span>https://lists.linuxfoundation.org/mailman/listinfo/bi=
tcoin-dev</span><br></div></blockquote></body></html>=

--Apple-Mail-6E3A7BA2-573A-491E-91EF-6FF6BAC414A8--