Content-Type: multipart/alternative;
 boundary="===============0333453674442322640=="
MIME-Version: 1.0
From: vjudeu@gazeta.pl
To: "Peter Todd <pete@petertodd.org>,
 Bitcoin Protocol Discussion" <bitcoin-dev@lists.linuxfoundation.org>,
 Antoine Riard <antoine.riard@gmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <ZTMWrJ6DjxtslJBn@petertodd.org>
Date: Sun, 22 Oct 2023 10:30:01 +0200
Message-Id: <193770517-370d11da072c35721a528135516153d7@pmq5v.m5r2.onet>
Cc: 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
Precedence: list

This is a multi-part message in MIME format.
--===============0333453674442322640==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

> By redefining a bit of the nVersion field, eg the most significant bit, w=
e can apply coinbase-like txout handling to arbitrary transactions.
=C2=A0
We already have that in OP_CHECKSEQUENCEVERIFY. You can have a system with =
no coinbase transactions at all, and use only OP_CHECKSEQUENCEVERIFY on the=
 first transaction, and set sequence numbers to put a relative locktime of =
100 blocks. Also, if you think some soft-fork is needed anyway, then I reco=
mmend building it around already existing OP_CHECKSEQUENCEVERIFY, than rein=
vent the wheel.
=C2=A0
> Redefining an existing OP_Nop opcode, OP_Expire would terminate script ev=
aluation with an error
=C2=A0
This one is also already there. We have reserved opcodes, like OP_RESERVED.=
 You can do something like "<condition> OP_IF OP_RESERVED OP_ENDIF", and th=
en, if "<condition>" is triggered in the Script, the whole transaction is m=
arked as invalid. But if that condition is false, then everything is fine, =
and you can continue executing next opcodes. Again, the situation is the sa=
me as in previous case: build it around OP_RESERVED, that is just "OP_EXPIR=
E" with a different name than you want, and then the only thing you need, i=
s soft-forking a proper condition on the stack.
=C2=A0
On 2023-10-21 02:09:55 user Peter Todd via bitcoin-dev <bitcoin-dev@lists.l=
inuxfoundation.org> wrote:
On Mon, Oct 16, 2023 at 05:57:36PM +0100, Antoine Riard via bitcoin-dev wro=
te: > Here enter a replacement cycling attack. A malicious channel counterp=
arty > can broadcast its HTLC-preimage transaction with a higher absolute f=
ee and > higher feerate than the honest HTLC-timeout of the victim lightnin=
g node > and triggers a replacement. Both for legacy and anchor output chan=
nels, a > HTLC-preimage on a counterparty commitment transaction is malleab=
le, i.e > additional inputs or outputs can be added. The HTLC-preimage spen=
ds an > unconfirmed and unrelated to the channel parent transaction M and c=
onflicts > its child. The basic problem here is after the HTLC-timeout path=
 becomes spendable, the HTLC-preimage path remains spendable. That's bad, b=
ecause in this case we want spending the HTLC-preimage - if possible - to h=
ave 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 - rem=
ain valid forever. We do this because we don't want transactions to become =
impossible to mine in the event of a large reorganization. A notable exampl=
e of this design philosophy is seen in Bitcoin's rules around coinbase outp=
uts: they only become spendable after 100 more blocks have been found; a 10=
0 block reorg is quite unlikely. Enter the OP_Expire and the Coinbase Bit s=
oft-fork upgrade. # Coinbase Bit By redefining a bit of the nVersion field,=
 eg the most significant bit, we can apply coinbase-like txout handling to =
arbitrary transactions. Such a transaction's outputs would be treated simil=
arly to a coinbase transaction, and would be spendable only after 100 more =
blocks had been mined. Due to this requirement, these transactions will pos=
e no greater risk to reorg safety than the existing hazard of coinbase tran=
sactions themselves becoming invalid. Note how such a transaction is non-st=
andard 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 AntiCheckLock=
TimeVerify: where CLTV _allows_ a txout to become spendable in a particular=
 way in the future, Expire _prevents_ a txout from being spent in a particu=
lar way. Since OP_Expire requires the Coinbase Bit to be set, the reorg sec=
urity of OP_Expire-using transactions is no worse than transactions spendin=
g 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 Expire Drop Hash EqualVerify CheckSig El=
seIf # 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 the blockchain itself, or they fail to=
 get the preimage mined in time, reverting control to the other party who c=
an spend the HTLC output at their leisure, without strict time constraints.=
 Since the HTLC-expired branch does *not* execute OP_Expire, the transactio=
n spending the HTLC-expired branch does *not* need to set the Coinbase Bit.=
 Thus it can be spent in a perfectly normal transaction, without restrictio=
ns. # 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 this 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 p=
eriod 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 expi=
ration 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. W=
hile Lightning's HTLC-success transactions currently use nLockTime=3D0, AFA=
IK there is no reason why they could not set nLockTime to be valid in the n=
ext block, allowing delta encoding to be used. ## Reusing Time-Based nLockT=
ime Reusing time-based nLockTime's prior to some pre-2009 genesis point for=
 expiration is another possibility (similar to how Lightning makes use of t=
ime-based nLockTime for signalling). However I believe this is not as desir=
able 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 s=
till 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-expi=
ring transactions. One notable consideration is that nodes should require h=
igher minimum relay fees for transactions close to their expiration height =
to ensure we don't waste bandwidth on transactions that have no potential t=
o be mined. Considering the primary use-case, it is probably acceptable to =
always require a fee rate high enough to be mined in the next block. -- htt=
ps://petertodd.org 'peter'[:-1]@petertodd.org _____________________________=
__________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundati=
on.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--===============0333453674442322640==
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

<div>
<div>&gt; By redefining a bit of the nVersion field, eg the most significan=
t bit, we can apply coinbase-like txout handling to arbitrary transactions.=
</div>
<div>&nbsp;</div>
<div>We already have that in OP_CHECKSEQUENCEVERIFY. You can have a system =
with no coinbase transactions at all, and use only OP_CHECKSEQUENCEVERIFY o=
n the first transaction, and set sequence numbers to put a relative locktim=
e of 100 blocks. Also, if you think some soft-fork is needed anyway, then I=
 recommend building it around already existing OP_CHECKSEQUENCEVERIFY, than=
 reinvent the wheel.</div>
<div>&nbsp;</div>
<div>&gt; Redefining an existing OP_Nop opcode, OP_Expire would terminate s=
cript evaluation with an error</div>
<div>&nbsp;</div>
<div>This one is also already there. We have reserved opcodes, like OP_RESE=
RVED. You can do something like "&lt;condition&gt; OP_IF OP_RESERVED OP_END=
IF", and then, if "&lt;condition&gt;" is triggered in the Script, the whole=
 transaction is marked as invalid. But if that condition is false, then eve=
rything is fine, and you can continue executing next opcodes. Again, the si=
tuation is the same as in previous case: build it around OP_RESERVED, that =
is just "OP_EXPIRE" with a different name than you want, and then the only =
thing you need, is soft-forking a proper condition on the stack.</div>
<br /><br /></div>
<div>&nbsp;</div>
<div>On 2023-10-21 02:09:55 user Peter Todd via bitcoin-dev &lt;bitcoin-dev=
@lists.linuxfoundation.org&gt; wrote:</div>
<blockquote style=3D"margin-right: 0; margin-left: 7px; border-left: 2px so=
lid orange; padding-left: 8px;">
<pre>On Mon, Oct 16, 2023 at 05:57:36PM +0100, Antoine Riard via bitcoin-de=
v wrote:
&gt; Here enter a replacement cycling attack. A malicious channel counterpa=
rty
&gt; can broadcast its HTLC-preimage transaction with a higher absolute fee=
 and
&gt; higher feerate than the honest HTLC-timeout of the victim lightning no=
de
&gt; and triggers a replacement. Both for legacy and anchor output channels=
, a
&gt; HTLC-preimage on a counterparty commitment transaction is malleable, i=
.e
&gt; additional inputs or outputs can be added. The HTLC-preimage spends an
&gt; unconfirmed and unrelated to the channel parent transaction M and conf=
licts
&gt; 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 w=
ant
spending the HTLC-preimage - if possible - to have an urgency attached to i=
t 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 t=
ried
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 even=
t of
a large reorganization.

A notable example of this design philosophy is seen in Bitcoin's rules arou=
nd
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, we =
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 t=
han
the existing hazard of coinbase transactions themselves becoming invalid.

Note how such a transaction is non-standard right now, ensuring compatibili=
ty
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 &gt;=3D the block height of the containing=
 block

This is conceptually an AntiCheckLockTimeVerify: where CLTV _allows_ a txou=
t to
become spendable in a particular way in the future, Expire _prevents_ a txo=
ut
from being spent in a particular way.

Since OP_Expire requires the Coinbase Bit to be set, the reorg security of
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 functio=
ning
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
         Expire Drop
        Hash  EqualVerify
         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 the
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 transaction
spending the HTLC-expired branch does *not* need to set the Coinbase Bit. T=
hus
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 enco=
de
the expiration height as a delta against a block-height nLockTime. In this
variant, OP_Expire would work similarly to OP_CheckLockTimeVerify, by check=
ing
that the absolute expiration height was &lt;=3D the requested expiration, a=
llowing
multiple HTLC preimage outputs to be spent in one transaction.

If the top 16-bits were used, the maximum period a transaction could be val=
id
would be:

    2^16 blocks / 144 blocks/day =3D 455 days

In this variant, a non-zero expiration delta would enable expiration behavi=
or,
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, AF=
AIK
there is no reason why they could not set nLockTime to be valid in the next
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 transact=
ions
from using block nLockTime and expiration at the same time. It would also s=
till
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 th=
at
nodes should require higher minimum relay fees for transactions close to th=
eir
expiration height to ensure we don't waste bandwidth on transactions that h=
ave
no potential to be mined. Considering the primary use-case, it is probably
acceptable to always require a fee rate high enough to be mined in the next
block.

-- =

https://petertodd.org 'peter'[:-1]@petertodd.org
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
</pre>
</blockquote>

--===============0333453674442322640==--