path: root/b9/80507c7bd1ede3d2bd0b2bbc9025d94285771d

Return-Path: <antoine.riard@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 3BB69C0032;
 Thu,  2 Nov 2023 05:24:54 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id 0153D43338;
 Thu,  2 Nov 2023 05:24:54 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 0153D43338
Authentication-Results: smtp2.osuosl.org;
 dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
 header.a=rsa-sha256 header.s=20230601 header.b=XAPvAVqo
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from smtp2.osuosl.org ([127.0.0.1])
 by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 3rcI6NqccpVN; Thu,  2 Nov 2023 05:24:49 +0000 (UTC)
Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com
 [IPv6:2607:f8b0:4864:20::d29])
 by smtp2.osuosl.org (Postfix) with ESMTPS id 905C84002B;
 Thu,  2 Nov 2023 05:24:48 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 905C84002B
Received: by mail-io1-xd29.google.com with SMTP id
 ca18e2360f4ac-7a692658181so23871839f.1; 
 Wed, 01 Nov 2023 22:24:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1698902687; x=1699507487;
 darn=lists.linuxfoundation.org; 
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:from:to:cc:subject:date:message-id:reply-to;
 bh=0z7cCoFGP+WHqlolC7EhWhDMMSF/3/0Oja9xuwx1VKo=;
 b=XAPvAVqoiGUOJcPW0dIDzUvXJGQ1hxu6mi8vMQkK/65SWHc4eu+cemsJsQEYMpRjvJ
 uV24Th4D2ccUsd0KKkrbsQMzZfH/SVvqitLXRPeuAMDcoVP9GuSLieGbqi7VXflYLoJk
 cKXQymOf92WOxldxCKvj+iy7dee1Y4Hbh8vJNB3dAyOqG2zVor1NlW40+Conj7D2k7nl
 X3kGbPKsDJl1+o5y/4vuTjqeIFHXjs6oRt0izutUAncT8kVLVwsb0KDwoleO833lvX9c
 3Ze3YSuADhBO8CjJTM0i/IPs2bogkATkd0ZCsmqJi+Z2P0QpCYFw8CMdRaljuWdfHtiM
 5J8Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1698902687; x=1699507487;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
 :reply-to;
 bh=0z7cCoFGP+WHqlolC7EhWhDMMSF/3/0Oja9xuwx1VKo=;
 b=OI/vRl2FcOFTABOwLFFNwr5YImkI7ihtS4Mvh7fw3C1Q9jjj5nytVK1pSECqnV6VK4
 HwHm57tZa82nWM8Poug7ZVjvoMtFcfSjptPIFc0cJwaPnu+43sGBLBIC2cEq+9+8/y9u
 ZHInyeT8URTbjJHSgRWi2kGUTEmRhcrIRfxT4g7EfZ0jApQk9impdoAGpAB1kjf3file
 8vemLj/YdapXzopvkYQn16oA9uodYy8D4YNnAdkybgrzmxRIV+ypGl8vUf7XEeh3LNbz
 w5CCfRJtU0wCzIo8dhp8IXEsO++hZ0pRCps/SvJto8AR79M9NJL4yM6b712fL9227ptm
 13bQ==
X-Gm-Message-State: AOJu0YxttkpnCVXBkc/CxiqMygYltG1IzyaPWf+btgoEHTcArRdeHpXP
 IDdk0KgmaJGDZsZzS8wZu+ZF5L+gPW1J2md72Ns=
X-Google-Smtp-Source: AGHT+IGtB0hBDV1zDky3uUEOpgqnP+cBwHI5uFNsDBlxJ9gFYi9+Q1jp88R/fItizS3UWu31iUlO2HRuKQ4DMF2mojI=
X-Received: by 2002:a05:6602:2e95:b0:7a9:96aa:e019 with SMTP id
 m21-20020a0566022e9500b007a996aae019mr21287725iow.13.1698902687376; Wed, 01
 Nov 2023 22:24:47 -0700 (PDT)
MIME-Version: 1.0
References: <CALZpt+GdyfDotdhrrVkjTALg5DbxJyiS8ruO2S7Ggmi9Ra5B9g@mail.gmail.com>
 <ZTMWrJ6DjxtslJBn@petertodd.org>
In-Reply-To: <ZTMWrJ6DjxtslJBn@petertodd.org>
From: Antoine Riard <antoine.riard@gmail.com>
Date: Thu, 2 Nov 2023 05:24:36 +0000
Message-ID: <CALZpt+GQ9g-uwAGYogdaJcinVHRxs4=67hML78KbramJg=davA@mail.gmail.com>
To: Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary="000000000000306b130609249bf0"
X-Mailman-Approved-At: Thu, 02 Nov 2023 11:36:06 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
 security@ariard.me, "lightning-dev\\\\@lists.linuxfoundation.org"
 <lightning-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] OP_Expire and Coinbase-Like Behavior: Making
 HTLCs Safer by Letting Transactions Expire Safely
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, 02 Nov 2023 05:24:54 -0000

--000000000000306b130609249bf0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Peter,

> So, why can't we make the HTLC-preimage path expire? Traditionally, we've
tried
> to ensure that transactions - once valid - remain valid forever. We do
this
> because we don't want transactions to become impossible to mine in the
event of
> a large reorganization.

I don't know if reverse time-lock where a lightning spending path becomes
invalid after a block height or epoch point solves the more advanced
replacement cycling attacks, where a malicious commitment transaction
itself replaces out a honest commitment transaction, and the
child-pay-for-parent of this malicious transaction is itself replaced out
by the attacker, leading to the automatic trimming of the malicious
commitment transaction.

I think this attack scenario is exposed here:
https://github.com/ariard/bitcoin/commits/2023-10-test-mempool-2

If this scenario is correct, there is not only a need for a solution that
expires the htlc-preimage spending path, but also channel commitment ones.
I think you have a difficulty as both channel commitments can be
legitimately valid under lightning protocol semantics, where both
counterparties cannot trust the other one to broadcast a commitment state
in a timely fashion, to subsequently claim time-sensitive HTLCs.

Of course, one might come with the observation that the time-sensitive
HTLCs might be safeguarded under the new reverse time-lock semantic, though
I think you're just switching the security risk from one counterparty to
the other one. Now, the forwarding node might receive the preimage
off-chain from the payee, and then block any attempt of the payee to
broadcast its commitment transaction to claim the inbound HTLC, before the
reverse time-lock kicks out.

I believe another line of solution could to remove any counterparty
malleability in the setting of a package total fees and have fee-bumping
reserves pre-committed, though intuitively this sounds to come with the
downside of a high-level of total reserve for each channel.

Best,
Antoine

Le sam. 21 oct. 2023 =C3=A0 01:09, Peter Todd <pete@petertodd.org> a =C3=A9=
crit :

> On Mon, Oct 16, 2023 at 05:57:36PM +0100, Antoine Riard via bitcoin-dev
> wrote:
> > Here enter a replacement cycling attack. A malicious channel counterpar=
ty
> > can broadcast its HTLC-preimage transaction with a higher absolute fee
> and
> > higher feerate than the honest HTLC-timeout of the victim lightning nod=
e
> > and triggers a replacement. Both for legacy and anchor output channels,=
 a
> > HTLC-preimage on a counterparty commitment transaction is malleable, i.=
e
> > additional inputs or outputs can be added. The HTLC-preimage spends an
> > unconfirmed and unrelated to the channel parent transaction M and
> conflicts
> > its child.
>
> The basic problem here is after the HTLC-timeout path becomes spendable,
> the
> HTLC-preimage path remains spendable. That's bad, because in this case we
> want
> spending the HTLC-preimage - if possible - to have an urgency attached to
> it to
> ensure that it happens before the previous HTLC-timeout is mined.
>
> So, why can't we make the HTLC-preimage path expire? Traditionally, we've
> tried
> to ensure that transactions - once valid - remain valid forever. We do th=
is
> because we don't want transactions to become impossible to mine in the
> event of
> a large reorganization.
>
> A notable example of this design philosophy is seen in Bitcoin's rules
> around
> coinbase outputs: they only become spendable after 100 more blocks have
> been
> found; a 100 block reorg is quite unlikely.
>
> Enter the OP_Expire and the Coinbase Bit soft-fork upgrade.
>
>
> # Coinbase Bit
>
> By redefining a bit of the nVersion field, eg the most significant bit, w=
e
> can
> apply coinbase-like txout handling to arbitrary transactions. Such a
> transaction's outputs would be treated similarly to a coinbase
> transaction, and
> would be spendable only after 100 more blocks had been mined. Due to this
> requirement, these transactions will pose no greater risk to reorg safety
> than
> the existing hazard of coinbase transactions themselves becoming invalid.
>
> Note how such a transaction is non-standard right now, ensuring
> compatibility
> with existing nodes in a soft-fork upgrade.
>
>
> # OP_Expire
>
> Redefining an existing OP_Nop opcode, OP_Expire would terminate script
> evaluation with an error if:
>
> 1) the Coinbase Bit was not set; or
> 2) the stack is empty; or
> 3) the top item on the stack was >=3D the block height of the containing
> block
>
> This is conceptually an AntiCheckLockTimeVerify: where CLTV _allows_ a
> txout to
> become spendable in a particular way in the future, Expire _prevents_ a
> txout
> from being spent in a particular way.
>
> Since OP_Expire requires the Coinbase Bit to be set, the reorg security o=
f
> OP_Expire-using transactions is no worse than transactions spending miner
> coinbases.
>
>
> # How HTLC's Would Use OP_Expire
>
> Whenever revealing the preimage on-chain is necessary to the secure
> functioning
> of the HTLC-using protocol, we simply add an appropriate OP_Expire to the
> pre-image branch of the script along the lines of:
>
>     If
>         <expiry height> Expire Drop
>         Hash <digest> EqualVerify
>         <pubkey> CheckSig
>     ElseIf
>         # HTLC Expiration conditions
>         ...
>     EndIf
>
> Now the party receiving the pre-image has a deadline. Either they get a
> transaction spending the preimage mined, notifying the other party via th=
e
> blockchain itself, or they fail to get the preimage mined in time,
> reverting
> control to the other party who can spend the HTLC output at their leisure=
,
> without strict time constraints.
>
> Since the HTLC-expired branch does *not* execute OP_Expire, the transacti=
on
> spending the HTLC-expired branch does *not* need to set the Coinbase Bit.
> Thus
> it can be spent in a perfectly normal transaction, without restrictions.
>
>
> # Delta Encoding Expiration
>
> Rather than having a specific Coinbase Bit, it may also be feasible to
> encode
> the expiration height as a delta against a block-height nLockTime. In thi=
s
> variant, OP_Expire would work similarly to OP_CheckLockTimeVerify, by
> checking
> that the absolute expiration height was <=3D the requested expiration,
> allowing
> multiple HTLC preimage outputs to be spent in one transaction.
>
> If the top 16-bits were used, the maximum period a transaction could be
> valid
> would be:
>
>     2^16 blocks / 144 blocks/day =3D 455 days
>
> In this variant, a non-zero expiration delta would enable expiration
> behavior,
> as well as the coinbase-like output spending restriction. The remaining
> 16-bits
> of nVersion would remain available for other meanings.
>
> Similar to how CLTV and CSV verified nLockTime and nSequence respectively=
,
> verifying an expiration height encoded in the nVersion has the advantage =
of
> making an expiration height easy to detect without validating scripts.
>
> While Lightning's HTLC-success transactions currently use nLockTime=3D0,
> AFAIK
> there is no reason why they could not set nLockTime to be valid in the ne=
xt
> block, allowing delta encoding to be used.
>
>
> ## Reusing Time-Based nLockTime
>
> Reusing time-based nLockTime's prior to some pre-2009 genesis point for
> expiration is another possibility (similar to how Lightning makes use of
> time-based nLockTime for signalling). However I believe this is not as
> desirable as delta encoding or a coinbase bit, as it would prevent
> transactions
> from using block nLockTime and expiration at the same time. It would also
> still
> require a coinbase bit or nVersion increase to ensure expiration-using
> transactions are non-standard.
>
>
> # Mempool Behavior
>
> Obviously, mempool logic will need to handle transactions that can expire
> differently than non-expiring transactions. One notable consideration is
> that
> nodes should require higher minimum relay fees for transactions close to
> their
> expiration height to ensure we don't waste bandwidth on transactions that
> have
> no potential to be mined. Considering the primary use-case, it is probabl=
y
> acceptable to always require a fee rate high enough to be mined in the ne=
xt
> block.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>

--000000000000306b130609249bf0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi Peter,<div><br></div><div>&gt; So, why can&#39;t we mak=
e the HTLC-preimage path expire? Traditionally, we&#39;ve tried<br>&gt; to =
ensure that transactions - once valid - remain valid forever. We do this<br=
>&gt; because we don&#39;t want transactions to become impossible to mine i=
n the event of<br>&gt; a large reorganization.<br></div><div><br></div><div=
>I don&#39;t know if reverse time-lock where a lightning spending path beco=
mes invalid after a block height or epoch point solves the more advanced re=
placement cycling attacks, where a malicious commitment transaction itself =
replaces out a honest commitment transaction, and the child-pay-for-parent =
of this malicious transaction is itself replaced out by the attacker, leadi=
ng to the automatic trimming of the malicious commitment transaction.</div>=
<div><br></div><div>I think this attack scenario is exposed here:</div><div=
><a href=3D"https://github.com/ariard/bitcoin/commits/2023-10-test-mempool-=
2">https://github.com/ariard/bitcoin/commits/2023-10-test-mempool-2</a><br>=
</div><div><br></div><div>If this scenario is correct, there is not only a =
need for a solution that expires the htlc-preimage spending path, but also =
channel commitment ones. I think you have a difficulty=C2=A0as both channel=
 commitments can be legitimately valid under lightning protocol semantics, =
where both counterparties cannot trust the other one to broadcast a commitm=
ent state in a timely fashion, to subsequently claim time-sensitive HTLCs.<=
/div><div><br></div><div>Of course, one might come with the observation tha=
t the time-sensitive HTLCs might be safeguarded under the new reverse time-=
lock semantic, though I think you&#39;re just switching the security risk f=
rom one counterparty to the other one. Now, the forwarding node might recei=
ve the preimage off-chain from the payee, and then block any attempt of the=
 payee to broadcast its commitment transaction to claim the inbound HTLC, b=
efore the reverse time-lock kicks out.</div><div><br></div><div>I believe a=
nother line of solution could to remove any counterparty malleability in th=
e setting of a package total fees and have fee-bumping reserves pre-committ=
ed, though intuitively this sounds to come with the downside of a high-leve=
l of total reserve for each channel.</div><div><br></div><div>Best,</div><d=
iv>Antoine</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=
=3D"gmail_attr">Le=C2=A0sam. 21 oct. 2023 =C3=A0=C2=A001:09, Peter Todd &lt=
;<a href=3D"mailto:pete@petertodd.org">pete@petertodd.org</a>&gt; a =C3=A9c=
rit=C2=A0:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-colo=
r:rgb(204,204,204);padding-left:1ex">On Mon, Oct 16, 2023 at 05:57:36PM +01=
00, Antoine Riard via bitcoin-dev wrote:<br>
&gt; Here enter a replacement cycling attack. A malicious channel counterpa=
rty<br>
&gt; can broadcast its HTLC-preimage transaction with a higher absolute fee=
 and<br>
&gt; higher feerate than the honest HTLC-timeout of the victim lightning no=
de<br>
&gt; and triggers a replacement. Both for legacy and anchor output channels=
, a<br>
&gt; HTLC-preimage on a counterparty commitment transaction is malleable, i=
.e<br>
&gt; additional inputs or outputs can be added. The HTLC-preimage spends an=
<br>
&gt; unconfirmed and unrelated to the channel parent transaction M and conf=
licts<br>
&gt; its child.<br>
<br>
The basic problem here is after the HTLC-timeout path becomes spendable, th=
e<br>
HTLC-preimage path remains spendable. That&#39;s bad, because in this case =
we want<br>
spending the HTLC-preimage - if possible - to have an urgency attached to i=
t to<br>
ensure that it happens before the previous HTLC-timeout is mined.<br>
<br>
So, why can&#39;t we make the HTLC-preimage path expire? Traditionally, we&=
#39;ve tried<br>
to ensure that transactions - once valid - remain valid forever. We do this=
<br>
because we don&#39;t want transactions to become impossible to mine in the =
event of<br>
a large reorganization.<br>
<br>
A notable example of this design philosophy is seen in Bitcoin&#39;s rules =
around<br>
coinbase outputs: they only become spendable after 100 more blocks have bee=
n<br>
found; a 100 block reorg is quite unlikely.<br>
<br>
Enter the OP_Expire and the Coinbase Bit soft-fork upgrade.<br>
<br>
<br>
# Coinbase Bit<br>
<br>
By redefining a bit of the nVersion field, eg the most significant bit, we =
can<br>
apply coinbase-like txout handling to arbitrary transactions. Such a<br>
transaction&#39;s outputs would be treated similarly to a coinbase transact=
ion, and<br>
would be spendable only after 100 more blocks had been mined. Due to this<b=
r>
requirement, these transactions will pose no greater risk to reorg safety t=
han<br>
the existing hazard of coinbase transactions themselves becoming invalid.<b=
r>
<br>
Note how such a transaction is non-standard right now, ensuring compatibili=
ty<br>
with existing nodes in a soft-fork upgrade.<br>
<br>
<br>
# OP_Expire<br>
<br>
Redefining an existing OP_Nop opcode, OP_Expire would terminate script<br>
evaluation with an error if:<br>
<br>
1) the Coinbase Bit was not set; or<br>
2) the stack is empty; or<br>
3) the top item on the stack was &gt;=3D the block height of the containing=
 block<br>
<br>
This is conceptually an AntiCheckLockTimeVerify: where CLTV _allows_ a txou=
t to<br>
become spendable in a particular way in the future, Expire _prevents_ a txo=
ut<br>
from being spent in a particular way.<br>
<br>
Since OP_Expire requires the Coinbase Bit to be set, the reorg security of<=
br>
OP_Expire-using transactions is no worse than transactions spending miner<b=
r>
coinbases.<br>
<br>
<br>
# How HTLC&#39;s Would Use OP_Expire<br>
<br>
Whenever revealing the preimage on-chain is necessary to the secure functio=
ning<br>
of the HTLC-using protocol, we simply add an appropriate OP_Expire to the<b=
r>
pre-image branch of the script along the lines of:<br>
<br>
=C2=A0 =C2=A0 If<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 &lt;expiry height&gt; Expire Drop<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Hash &lt;digest&gt; EqualVerify<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 &lt;pubkey&gt; CheckSig<br>
=C2=A0 =C2=A0 ElseIf<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 # HTLC Expiration conditions<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ...<br>
=C2=A0 =C2=A0 EndIf<br>
<br>
Now the party receiving the pre-image has a deadline. Either they get a<br>
transaction spending the preimage mined, notifying the other party via the<=
br>
blockchain itself, or they fail to get the preimage mined in time, revertin=
g<br>
control to the other party who can spend the HTLC output at their leisure,<=
br>
without strict time constraints.<br>
<br>
Since the HTLC-expired branch does *not* execute OP_Expire, the transaction=
<br>
spending the HTLC-expired branch does *not* need to set the Coinbase Bit. T=
hus<br>
it can be spent in a perfectly normal transaction, without restrictions.<br=
>
<br>
<br>
# Delta Encoding Expiration<br>
<br>
Rather than having a specific Coinbase Bit, it may also be feasible to enco=
de<br>
the expiration height as a delta against a block-height nLockTime. In this<=
br>
variant, OP_Expire would work similarly to OP_CheckLockTimeVerify, by check=
ing<br>
that the absolute expiration height was &lt;=3D the requested expiration, a=
llowing<br>
multiple HTLC preimage outputs to be spent in one transaction.<br>
<br>
If the top 16-bits were used, the maximum period a transaction could be val=
id<br>
would be:<br>
<br>
=C2=A0 =C2=A0 2^16 blocks / 144 blocks/day =3D 455 days<br>
<br>
In this variant, a non-zero expiration delta would enable expiration behavi=
or,<br>
as well as the coinbase-like output spending restriction. The remaining 16-=
bits<br>
of nVersion would remain available for other meanings.<br>
<br>
Similar to how CLTV and CSV verified nLockTime and nSequence respectively,<=
br>
verifying an expiration height encoded in the nVersion has the advantage of=
<br>
making an expiration height easy to detect without validating scripts.<br>
<br>
While Lightning&#39;s HTLC-success transactions currently use nLockTime=3D0=
, AFAIK<br>
there is no reason why they could not set nLockTime to be valid in the next=
<br>
block, allowing delta encoding to be used.<br>
<br>
<br>
## Reusing Time-Based nLockTime<br>
<br>
Reusing time-based nLockTime&#39;s prior to some pre-2009 genesis point for=
<br>
expiration is another possibility (similar to how Lightning makes use of<br=
>
time-based nLockTime for signalling). However I believe this is not as<br>
desirable as delta encoding or a coinbase bit, as it would prevent transact=
ions<br>
from using block nLockTime and expiration at the same time. It would also s=
till<br>
require a coinbase bit or nVersion increase to ensure expiration-using<br>
transactions are non-standard.<br>
<br>
<br>
# Mempool Behavior<br>
<br>
Obviously, mempool logic will need to handle transactions that can expire<b=
r>
differently than non-expiring transactions. One notable consideration is th=
at<br>
nodes should require higher minimum relay fees for transactions close to th=
eir<br>
expiration height to ensure we don&#39;t waste bandwidth on transactions th=
at have<br>
no potential to be mined. Considering the primary use-case, it is probably<=
br>
acceptable to always require a fee rate high enough to be mined in the next=
<br>
block.<br>
<br>
-- <br>
<a href=3D"https://petertodd.org" rel=3D"noreferrer" target=3D"_blank">http=
s://petertodd.org</a> &#39;peter&#39;[:-1]@<a href=3D"http://petertodd.org"=
 rel=3D"noreferrer" target=3D"_blank">petertodd.org</a><br>
</blockquote></div>

--000000000000306b130609249bf0--