path: root/f8/b3fa5dac5f8509c2bc6466fb0af8c5c32df6b6

Return-Path: <fresheneesz@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id CECD6C000B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 10 Jun 2021 17:35:46 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id B6D4C40118
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 10 Jun 2021 17:35:46 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 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_PASS=-0.001]
 autolearn=ham autolearn_force=no
Authentication-Results: smtp2.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
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 as-IUh6jHoCq
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 10 Jun 2021 17:35:45 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com
 [IPv6:2a00:1450:4864:20::535])
 by smtp2.osuosl.org (Postfix) with ESMTPS id 840F2400F3
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 10 Jun 2021 17:35:45 +0000 (UTC)
Received: by mail-ed1-x535.google.com with SMTP id ba2so32254878edb.2
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 10 Jun 2021 10:35:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:from:date:message-id:subject:to;
 bh=nEXNlsWTGF89S+UaEevRty4WEPR/igkcEjgwFNgFYY8=;
 b=f8gOvrj56QXmYzzDpVjog8WIaa1QCjrVTT5ytaFdk98SBfypzTzTQRETdG5taVORoS
 altQ21l4Tt5sLTeXL+wldGsRrrF3P+4Qn3pW3dRCNHxImTzGuvqFMajVYyh2M7NkH6Q4
 fgaIhaVGlqH0R3a4SdiJMfsQXrvo0zl6Lv3kwYUO4t4aZ08417lxlQcav/Z/qee+4zXL
 CCvO14XGtIr9vd+CU0Wgmp9E7LAui+ssbdnITdVsPSACttsVe/wwhy4uCAF5BS2RipbK
 ymXoieQqE7SCdoRMR9UohWTHPdTnz8Ik5KtPY5DsEe4W0O49u1xw7dhQE8pDeKMe2dtE
 dAUA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
 bh=nEXNlsWTGF89S+UaEevRty4WEPR/igkcEjgwFNgFYY8=;
 b=kvTTOQdAEH06BQyruZzb1onLj+ykxr8v2hs/EYKDc7doDqQyo1GfoMIxsmvBbRHlZu
 3HwZye6Z9VPNAA+3DMlVaVY5O9OWSMptTQrg0P/5HViB/eTFvLkKg336L6Eq8RTXg0Is
 Gvh+pd4JfZwO5uBgWIfZYsNdCnwDKKHJMZNY4QtygQ5mCzI8VqgxfT3xG6s3m/WDiRQ9
 aIdM+ja84kGWIVDoH7rDt+nz4o2YhC6i55aZ/rrBcLaDUhsl9ZTu3I6NkF6rYDQgnu9m
 0oUP+Zsp6JCSG0a4jPBzimxs+4yx4yJ6eUWnMrgWPGNW4OcoVIBzl2+1LiRAMt7P+Inp
 ONng==
X-Gm-Message-State: AOAM531IJyMAVd95rEVt65EkYykmXOOK6Z4Bvmeh1Knxg5w1ieDnip/6
 zizfTG3VmAHejUQknLhPNme/yJ38ZCyGv5u1+wwnHREMLMW0Yw==
X-Google-Smtp-Source: ABdhPJz2TirjRotYk/Jk7TpzykhVDkYLHjq4Dm+mvdmd3eJ3+TzGf3bcKOwWTqXDAK93xYfxvEfbLqGnXsrcLi3Fx1k=
X-Received: by 2002:aa7:d388:: with SMTP id x8mr599878edq.338.1623346543008;
 Thu, 10 Jun 2021 10:35:43 -0700 (PDT)
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"
X-Mailman-Approved-At: Thu, 10 Jun 2021 17:56:42 +0000
Subject: [bitcoin-dev] OP_BEFOREBLOCKVERIFY - discussing and opcode that
 invalidates a spend path after a certain block
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, 10 Jun 2021 17:35:46 -0000

--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--