path: root/6f/7d7affc10ffadcf53d5d7a113cc89d59eb93a7

Return-Path: <roconnor@blockstream.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id C51AFC000B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 10 Jun 2021 18:35:54 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id B4F4983D61
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 10 Jun 2021 18:35:54 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -0.499
X-Spam-Level: 
X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5
 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp1.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key)
 header.d=blockstream-com.20150623.gappssmtp.com
Received: from smtp1.osuosl.org ([127.0.0.1])
 by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id HWZRFrxTUb3C
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 10 Jun 2021 18:35:53 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-qk1-x732.google.com (mail-qk1-x732.google.com
 [IPv6:2607:f8b0:4864:20::732])
 by smtp1.osuosl.org (Postfix) with ESMTPS id 54D0E83D7B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 10 Jun 2021 18:35:53 +0000 (UTC)
Received: by mail-qk1-x732.google.com with SMTP id d196so23228440qkg.12
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 10 Jun 2021 11:35:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=blockstream-com.20150623.gappssmtp.com; s=20150623;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
 bh=jWjJLFW2sncinscklwG1lYvcBzB9MrZNSPP+BEFE2DY=;
 b=HFLEZLAtL/0mJ9ANzAQezNXVTMBd3CYB3fEKnck/XM/1F8RSw9SENtTak8ZVtFvpYG
 Z7C0fqo1IQv5we7p8eKMJHYDdlL2XX3RDoATAEQfew7I3z9+LVXWEs2KJIpdej17bE3l
 3+14vjqNTfeAOJtURBvIWLr/sPPg8enhw1aoyfqUu2ceayXbLDgiWtL4bzwyvXXi1ii4
 HQtoJmDM57cvN/jUJkaFKOHUJ7/D1zMnM7azVUmJc6TRucerHfj/g8/h3x7ALf5R0o0c
 bHnnpocRHX7EicxTij8nsd5A06HCjmbEccncPoV332hwCLuAyrZYr2fN1tfx0sbGLCGH
 Z23g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to;
 bh=jWjJLFW2sncinscklwG1lYvcBzB9MrZNSPP+BEFE2DY=;
 b=q3p/HGvKy3CKroOAP8noxEucp4JhvCWZXtI/mNO4gx79v0LDdlnz8eCShJqEgI4nId
 RIiOKzx4L6/BvPe8fOFXBcNqO0mv3fKq6N9rGHDiMJTkBVPUFov4RMfp2br2lyX5uaO7
 G0MAJpDlz96NDnvnHthEF65Q2eOFSOBl/q79x5s3o0/JRCF9E5FRKl9U3YWnyHm1x5d0
 QPTL6Sdz9miuRnhHwz4d2O57B3RvEtpVHrjSH8Y5jxZc7Lh47L2k0VHo+4KETaFxFX7p
 lWs4g/hQD4ev8R9rmGlMbeyLi0aggeOCzW7iyw8nhNeKmjrzQ4jQTg+1yZFFomUVfE0N
 w87g==
X-Gm-Message-State: AOAM533U08rGOR2HQ6k2QMQ9Bvd5JLyRWeoXBp0yRu8twGNe5+4SsWG/
 O1i3MUyZrR6D3BW6hlW3Xthb4yubuFcYr1OIOuKh3A==
X-Google-Smtp-Source: ABdhPJzC7EvCtdgXA+40pbYYtRMwOXyylQRRMtRNe8D0Cfi79l87hHp6DAeUAXGELhBxVyYvR6PRTuIcFoLaCYQkZgI=
X-Received: by 2002:a37:9606:: with SMTP id y6mr910725qkd.13.1623350152234;
 Thu, 10 Jun 2021 11:35:52 -0700 (PDT)
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
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 18:35:54 -0000

--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&#3=
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--