path: root/25/356424836401b88029c10c0f50cccc666e7aa8

Return-Path: <eric@voskuil.org>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 1940AC0037
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 28 Dec 2023 18:42:55 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id D407E60BFD
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 28 Dec 2023 18:42:54 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org D407E60BFD
Authentication-Results: smtp3.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=fpvZJTmK
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 smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id nWDw6-9RhDpr
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 28 Dec 2023 18:42:53 +0000 (UTC)
Received: from mail-ot1-x32a.google.com (mail-ot1-x32a.google.com
 [IPv6:2607:f8b0:4864:20::32a])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 09CA460BEA
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 28 Dec 2023 18:42:52 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 09CA460BEA
Received: by mail-ot1-x32a.google.com with SMTP id
 46e09a7af769-6dc08cc6b9cso83779a34.1
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 28 Dec 2023 10:42:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=voskuil-org.20230601.gappssmtp.com; s=20230601; t=1703788972; x=1704393772;
 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=THlKfKxWAVUlMwuRWjYWbUTXwJlfUg4PpSdzFCntW18=;
 b=fpvZJTmKFJmGRFK2aa5Zx1dDqvDCU6Z6dz0HYsQIayEG3ygSjjV23gSDDnLizsQUei
 kVWUkoeQkl2hV+Vq6UMKUpvvGGnXKbkabcr31oQjC0PluwcaHJOzPOmcu09FTgVTjfoU
 PoIKLNcwJuFFpfdzCuM3pzjvxLbaZ9gTVFEFko/giPaUXV/b8VG796rRLo7KNXMsNhJb
 FmiGceT5aWEEdo0TUrHgcX+blicQhdA8xCNLl3A7MNozm2yBphUYc+xV4XbN6zN5wmqx
 VZWberQW4GTnD2tCrfzlrBZoImGIoAIcQjWe1W/v+OirwMSE1NlF6cw1udMXuVLVLoxq
 BOcQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1703788972; x=1704393772;
 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=THlKfKxWAVUlMwuRWjYWbUTXwJlfUg4PpSdzFCntW18=;
 b=wDuaPDh8Mj7aacLm0sY8RA9M/J/9HmD8HSfNMeOusEZ7Xutx6TM0lRaSqN3pQ4w+lI
 YkbB5SrBpeur/c0aflkvU8xDAj4opzhtEKQH4tPcXr0+ll2Dr3WDNNg42EcRk6h1We5+
 KVynJRz4Ocs8zeEiDKVvUwC/Hlx88kIYOPbRjHJG5zjQwCMrvtNGQ8CB/YF47ONhwMiq
 B0LfGKdVJXtmTiQYjIbe2zfB+Wij1gQQREVo7mvEfV0xDCyWMQgVE0GFxwTfT7wISVi+
 HzWx/8km7VRHVg8fWq7vGR/+WIRAWeVTsUC5LEhWbMLGLP2OwXR4dqtSWuo3YyLHrxua
 liNQ==
X-Gm-Message-State: AOJu0Yy1vmCIMhKwfTEa2L49VB3mRBr3L2tKLeVfy2sfsj9OJW4hnJkB
 7Z/VD/rOXLmHP6kI1gnzPS7lPlQOE23Wg7IaNy+VvhdBhRM=
X-Google-Smtp-Source: AGHT+IHWVGA8HsWdsDD+zGTwsNMDlp8cjNn86FQi1NjS3KSqoVIXvq7UQ2pY9CoFdkE4NoBGSBmBFg==
X-Received: by 2002:a05:6820:1f90:b0:594:8f66:bca8 with SMTP id
 eq16-20020a0568201f9000b005948f66bca8mr9619439oob.0.1703788971756; 
 Thu, 28 Dec 2023 10:42:51 -0800 (PST)
Received: from smtpclient.apple ([2601:188:cc7f:e751:58f0:395c:2dfc:731e])
 by smtp.gmail.com with ESMTPSA id
 bs24-20020ac86f18000000b00427e36e21d9sm2887567qtb.64.2023.12.28.10.42.50
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 28 Dec 2023 10:42:50 -0800 (PST)
Content-Type: multipart/alternative;
 boundary=Apple-Mail-4263EB55-B3F3-46D8-B3D8-895A72C4966F
Content-Transfer-Encoding: 7bit
From: Eric Voskuil <eric@voskuil.org>
Mime-Version: 1.0 (1.0)
Date: Thu, 28 Dec 2023 13:42:39 -0500
Message-Id: <8656E5B3-EDC7-4C00-93AB-C61AC6C22563@voskuil.org>
References: <dkAxjJIFndwa9WN8Hgrp92I3l3IH0SGRhheMntDfaaDjGTOOnv0s8zIivWE0yiHhh9ty0TQ_IUvkg9Zrs2KFjdSoH1_DrvCymhxA9hF-6Ko=@protonmail.com>
In-Reply-To: <dkAxjJIFndwa9WN8Hgrp92I3l3IH0SGRhheMntDfaaDjGTOOnv0s8zIivWE0yiHhh9ty0TQ_IUvkg9Zrs2KFjdSoH1_DrvCymhxA9hF-6Ko=@protonmail.com>
To: jlspc <jlspc@protonmail.com>
X-Mailer: iPhone Mail (21B101)
Cc: Antoine Riard <antoine.riard@gmail.com>,
 Bitcoin Protocol Discussion <bitcoin-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: Thu, 28 Dec 2023 18:42:55 -0000


--Apple-Mail-4263EB55-B3F3-46D8-B3D8-895A72C4966F
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">Hi J=
ohn,</div><div dir=3D"ltr"><br></div><div dir=3D"ltr">Honest is a misnomer, w=
hich is underpinning the concept. There is nothing dishonest about such paym=
ents. The downside is that the payer forgoes anonymity relative to the miner=
, but this is not dishonest, nor is mining one=E2=80=99s own transactions (w=
here the represented =E2=80=9Cfee=E2=80=9D implies nothing). Assuming a =E2=80=
=9Csufficient fraction=E2=80=9D of one of several economically rational beha=
viors is a design flaw.</div><div dir=3D"ltr"><br></div><div dir=3D"ltr">e</=
div><div dir=3D"ltr"><br><blockquote type=3D"cite">On Dec 28, 2023, at 13:19=
, jlspc &lt;jlspc@protonmail.com&gt; wrote:<br><br></blockquote></div><block=
quote type=3D"cite"><div dir=3D"ltr">=EF=BB=BF<div style=3D"font-family: Ari=
al, sans-serif; font-size: 14px;">Hi Eric,</div><div style=3D"font-family: A=
rial, sans-serif; font-size: 14px;"><br></div><div style=3D"font-family: Ari=
al, sans-serif; font-size: 14px;">I agree that users can pay miners offchain=
 and miners can create blocks where the difference between inputs and output=
s exceeds the fees paid (by mining their own transactions). I model that beh=
avior as dishonest mining. Onchain fees seem to reflect congestion for now, b=
ut it's true that FDTs rely on having a sufficient fraction of honest miners=
.</div><div style=3D"font-family: Arial, sans-serif; font-size: 14px;"><br><=
/div><div style=3D"font-family: Arial, sans-serif; font-size: 14px;">Regards=
,</div><div style=3D"font-family: Arial, sans-serif; font-size: 14px;">John<=
/div><div style=3D"font-family: Arial, sans-serif; font-size: 14px;"><br></d=
iv>
<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 Friday, December 22nd, 2023 at 8:09 PM, Eric Voskuil &lt;eric@vos=
kuil.org&gt; wrote:<br><br>
        <blockquote class=3D"protonmail_quote" type=3D"cite">
            <div dir=3D"ltr"></div><div dir=3D"ltr">The fees paid to mine th=
e set of transactions in a given block are known only to the miner that prod=
uced the block. Assuming that tx inputs less outputs represents an actual ec=
onomic force is an error.</div><div dir=3D"ltr"><br></div><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.linuxfoundation.org&gt; wrot=
e:<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 styl=
e=3D"overflow-wrap:break-word;white-space:pre-wrap">Hi 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 style=3D"font-family: Arial, sans-serif; font-size: 14px;" class=3D"pro=
tonmail_signature_block">
    <div class=3D"protonmail_signature_block-user protonmail_signature_block=
-empty">

            </div>

            <div class=3D"protonmail_signature_block-proton">
        Sent with <a rel=3D"noreferrer nofollow noopener" href=3D"https://pr=
oton.me/" target=3D"_blank">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 type=3D"cite" class=3D"protonmail_quote">
            <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 target=3D"_blank" rel=3D"noreferrer nofollow noopener" href=3D"https:=
//fc22.ifca.ai/preproceedings/119.pdf">https://fc22.ifca.ai/preproceedings/1=
19.pdf</a>
[1] <a target=3D"_blank" rel=3D"noreferrer nofollow noopener" href=3D"https:=
//github.com/ariard/bitcoin-contracting-primitives-wg/blob/main/meetings/mee=
tings-18-04.md">https://github.com/ariard/bitcoin-contracting-primitives-wg/=
blob/main/meetings/meetings-18-04.md</a>
[2] <a target=3D"_blank" rel=3D"noreferrer nofollow noopener" href=3D"https:=
//lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-November/022180.html"=
>https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-November/02218=
0.html</a>
[3] <a target=3D"_blank" rel=3D"noreferrer nofollow noopener" href=3D"https:=
//lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-October/022093.html">=
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-October/022093.=
html</a>
[4] <a target=3D"_blank" rel=3D"noreferrer nofollow noopener" href=3D"https:=
//github.com/bitcoin-inquisition/bitcoin/pull/9">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 target=3D"_blank" rel=3D=
"noreferrer nofollow noopener" href=3D"https://github.com/bitcoin/bips/pull/=
1381">https://github.com/bitcoin/bips/pull/1381</a></span><span style=3D"fon=
t-family:arial,sans-serif"> </span></pre></div></div><br><div class=3D"gmail=
_quote"><div dir=3D"ltr" class=3D"gmail_attr">Le ven. 15 d=C3=A9c. 2023 =C3=A0=
 09:20, jlspc via bitcoin-dev &lt;<a target=3D"_blank" rel=3D"noreferrer nof=
ollow noopener" href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoi=
n-dev@lists.linuxfoundation.org</a>&gt; a =C3=A9crit :<br></div><blockquote c=
lass=3D"gmail_quote" 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=
"><div style=3D"font-family:Arial,sans-serif;font-size:14px"><pre style=3D"w=
hite-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>
        </blockquote><br>
    </div></div></blockquote></body></html>=

--Apple-Mail-4263EB55-B3F3-46D8-B3D8-895A72C4966F--