MIME-Version: 1.0
From: Billy Tetrud <billy.tetrud@gmail.com>
Date: Thu, 10 Jun 2021 10:35:25 -0700
Message-ID: <CAGpPWDYRcR1U-zwmM_jUA_49LRMsAC5h+DpNFjn5nGniQpN29w@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000000b1fd205c46cd2c5"
Subject: [bitcoin-dev] OP_BEFOREBLOCKVERIFY - discussing and opcode that
 invalidates a spend path after a certain block
Precedence: list

--0000000000000b1fd205c46cd2c5
Content-Type: text/plain; charset="UTF-8"

Hi Everyone,

I'd like to open a discussion of an opcode I call OP_BEFOREBLOCKVERIFY
(OP_BBV) which is similar to ones that have been discussed before (eg
OP_BLOCKNUMBER). The opcode is very simple: the it takes as a parameter a
number representing a block height, and marks the transaction invalid if
the current block the transaction is being evaluated for is greater than or
equal to that block height, the transaction is invalid. I wrote up a bip
for OP_BBV here
<https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/bbv/bip-beforeblockverify.md>
.

The motivation for this opcode is primarily to do switch-off kinds of
transactions. Eg, an output that contains both a spend path that uses
OP_BBV and a spend path that uses OP_CHECKSEQUENCEVERIFY so that before a
particular block one person can spend, and after that block a different
person can spend. This can allow doing things like expiring payments or
reversible payments in a cheaper way. Currently, things like that require a
sequence of multiple transactions, however OP_BBV can do it in a single
transaction, making these applications a lot more economically feasible.

The particular application I'm most interested in is more efficient wallet
vaults. However, wallet vaults requires other new opcodes, and I've been
given the (good, I think) advice to start off this discussion with
something a bit more bite sized and manageable. So I want to keep this
discussion to OP_BBV and steer away from the specifics of the wallet vaults
I'm thinking of (which are more involved, requiring other new opcodes that
I think makes more sense to discuss in a different thread).

The main thing I'd like to discuss is the historical avoidance of and
stigma toward opcodes that can cause a valid transaction to become invalid.

It seems there are two concerns:

1. that an opcode like might create a DOS vector where a malicious actor
might be able to spam the mempool with transactions containing this opcode.
2. that an opcode like this could cause "bad" reorg behavior, where in a
reorg, transactions that were spent become not spend and not spendable
because they were mined too near their expiry point.

While I don't want to claim anything about opcodes that can cause spend
paths to expire in general, I do want to claim that *some* opcodes like
that are safe - in particular OP_BBV. In the context of OP_BBV
specifically, it seems to me like item 1 (mempool handling) is a solvable
problem and that point 2 (reorg issues) is not really a problem since
people should generally be waiting for 6 confirmations and software can
warn the user to wait for 6 confirmations in relevant scenarios where a
6-block reorg might reverse the transaction. I discuss this in detail in
the Design Tradeoffs and Risks
<https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/bbv/bip-beforeblockverify.md#transaction-expiry>
section
of the document I wrote for OP_BBV. I'd love to hear thoughts from others
on here about these things and especially the discussion of these issues in
the document I linked to.

Thanks,
BT

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

<div dir=3D"ltr">Hi Everyone,<div><br></div><div>I&#39;d like to open a dis=
cussion of an opcode I call OP_BEFOREBLOCKVERIFY (OP_BBV) which is similar =
to ones that have been discussed before (eg=C2=A0<span style=3D"background-=
color:rgb(246,246,246);color:rgb(0,0,0);font-family:verdana,sans-serif;font=
-size:13px">OP_BLOCKNUMBER)</span>. The opcode is very simple: the it takes=
 as a parameter a number representing a block height, and marks the transac=
tion invalid if the current block the transaction is being evaluated=C2=A0f=
or is greater than or equal to that block height, the transaction is invali=
d. I wrote up a <a href=3D"https://github.com/fresheneesz/bip-efficient-bit=
coin-vaults/blob/main/bbv/bip-beforeblockverify.md">bip for OP_BBV here</a>=
.</div><div><br></div><div>The motivation for this opcode is primarily to d=
o switch-off kinds of transactions. Eg, an output that contains both a spen=
d path that uses OP_BBV and a spend path that uses OP_CHECKSEQUENCEVERIFY s=
o that before a particular block one person can spend, and after that block=
 a different person can spend. This can allow doing things like expiring pa=
yments or reversible payments in a cheaper way. Currently, things like that=
 require a sequence of multiple transactions, however OP_BBV can do it in a=
 single transaction, making these applications a lot more economically feas=
ible.=C2=A0</div><div><br></div><div>The particular application I&#39;m mos=
t interested in is more efficient wallet vaults. However, wallet vaults req=
uires other new opcodes, and I&#39;ve been given the (good, I think) advice=
 to start off this discussion with something a bit more bite sized and mana=
geable. So I want to keep this discussion to OP_BBV and steer away from the=
 specifics of the wallet vaults I&#39;m thinking of (which are more involve=
d, requiring other new opcodes that I think makes more sense to discuss in =
a different thread).</div><div><br></div><div>The main thing I&#39;d like t=
o discuss is the historical avoidance of and stigma toward opcodes that can=
 cause a valid transaction to become invalid. </div><div><br></div><div>It =
seems there are two concerns:</div><div><br></div><div>1. that an opcode li=
ke might=C2=A0create a DOS vector where a malicious actor might be able to =
spam the mempool with transactions containing this opcode.</div><div>2. tha=
t an opcode like this could cause &quot;bad&quot; reorg behavior, where in =
a reorg, transactions that were spent become not spend and not spendable be=
cause they were mined too near their expiry point.=C2=A0</div><div><br></di=
v><div>While I don&#39;t want to claim anything about opcodes that can caus=
e spend paths to expire in general, I do want to claim that *some* opcodes =
like that are safe - in particular OP_BBV. In the context of OP_BBV specifi=
cally, it seems to me like item 1 (mempool handling) is a solvable problem =
and that point 2 (reorg issues) is not really a problem since people should=
 generally be waiting for 6 confirmations and software can warn the user to=
 wait for 6 confirmations in relevant scenarios where a 6-block reorg might=
 reverse the transaction. I discuss this in detail in the=C2=A0<a href=3D"h=
ttps://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/bbv/bi=
p-beforeblockverify.md#transaction-expiry">Design Tradeoffs and Risks</a>=
=C2=A0section of the document I wrote for OP_BBV. I&#39;d love to hear thou=
ghts from others on here about these things and especially the discussion o=
f these issues in the document I linked to.=C2=A0</div><div><br></div><div>=
Thanks,</div><div>BT</div><div><br></div></div>

--0000000000000b1fd205c46cd2c5--