MIME-Version: 1.0
References: <CAGpPWDYRcR1U-zwmM_jUA_49LRMsAC5h+DpNFjn5nGniQpN29w@mail.gmail.com>
In-Reply-To: <CAGpPWDYRcR1U-zwmM_jUA_49LRMsAC5h+DpNFjn5nGniQpN29w@mail.gmail.com>
From: "Russell O'Connor" <roconnor@blockstream.com>
Date: Thu, 10 Jun 2021 14:35:41 -0400
Message-ID: <CAMZUoK=1Rw-rzYPh24VLaH2HmmEO-B2ipf_9ymPb1RQQGUzjvw@mail.gmail.com>
To: Billy Tetrud <billy.tetrud@gmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000002b9f5605c46da9f7"
Subject: Re: [bitcoin-dev] OP_BEFOREBLOCKVERIFY - discussing and opcode that
 invalidates a spend path after a certain block
Precedence: list

--0000000000002b9f5605c46da9f7
Content-Type: text/plain; charset="UTF-8"

This is a continuation of the thread at
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018760.html
on this topic.

I still remain unconvinced that we ought to give up on the "reorg safety"
property that is explicitly part of Bitcoin's design.

On Thu, Jun 10, 2021 at 1:56 PM Billy Tetrud via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> 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
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr"><div>This is a continuation of the thread at <a href=3D"ht=
tps://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018760.htm=
l">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/01876=
0.html</a> on this topic.</div><div><br></div><div>I still remain unconvinc=
ed that we ought to give up on the &quot;reorg safety&quot; property that i=
s explicitly part of Bitcoin&#39;s design.<br></div></div><br><div class=3D=
"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, Jun 10, 2021 at=
 1:56 PM Billy Tetrud via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lis=
ts.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote=
:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.=
8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"lt=
r">Hi Everyone,<div><br></div><div>I&#39;d like to open a discussion of an =
opcode I call OP_BEFOREBLOCKVERIFY (OP_BBV) which is similar to ones that h=
ave 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 paramete=
r a number representing a block height, and marks the transaction invalid i=
f the current block the transaction is being evaluated=C2=A0for is greater =
than or equal to that block height, the transaction is invalid. I wrote up =
a <a href=3D"https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/bl=
ob/main/bbv/bip-beforeblockverify.md" target=3D"_blank">bip for OP_BBV here=
</a>.</div><div><br></div><div>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_CHECKSEQUENCEVERI=
FY so that before a particular block one person can spend, and after that b=
lock a different person can spend. This can allow doing things like expirin=
g 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.=C2=A0</div><div><br></div><div>The particular application I&#39;m=
 most interested in is more efficient wallet vaults. However, wallet vaults=
 requires other new opcodes, and I&#39;ve been given the (good, I think) ad=
vice 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&#39;m thinking of (which are more inv=
olved, 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 li=
ke to 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 opcod=
e like 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.=
 that an opcode like this could cause &quot;bad&quot; reorg behavior, where=
 in a reorg, transactions that were spent become not spend and not spendabl=
e because they were mined too near their expiry point.=C2=A0</div><div><br>=
</div><div>While I don&#39;t want to claim anything about opcodes that can =
cause spend paths to expire in general, I do want to claim that *some* opco=
des like that are safe - in particular OP_BBV. In the context of OP_BBV spe=
cifically, it seems to me like item 1 (mempool handling) is a solvable prob=
lem and that point 2 (reorg issues) is not really a problem since people sh=
ould generally be waiting for 6 confirmations and software can warn the use=
r to wait for 6 confirmations in relevant scenarios where a 6-block reorg m=
ight reverse the transaction. I discuss this in detail in the=C2=A0<a href=
=3D"https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/b=
bv/bip-beforeblockverify.md#transaction-expiry" target=3D"_blank">Design Tr=
adeoffs and Risks</a>=C2=A0section of the document I wrote for OP_BBV. I=
9;d love to hear thoughts from others on here about these things and especi=
ally the discussion of these issues in the document I linked to.=C2=A0</div=
><div><br></div><div>Thanks,</div><div>BT</div><div><br></div></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--0000000000002b9f5605c46da9f7--