path: root/91/531296d37d3656cbe1ac8fc05fcadf3c2813e2

Return-Path: <roconnor@blockstream.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id ACF88C000B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 10 Jun 2021 23:20:34 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id 91DC24066E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 10 Jun 2021 23:20:34 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001]
 autolearn=ham autolearn_force=no
Authentication-Results: smtp4.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key)
 header.d=blockstream-com.20150623.gappssmtp.com
Received: from smtp4.osuosl.org ([127.0.0.1])
 by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id vBC2LHu110-h
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 10 Jun 2021 23:20:32 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-qv1-xf2b.google.com (mail-qv1-xf2b.google.com
 [IPv6:2607:f8b0:4864:20::f2b])
 by smtp4.osuosl.org (Postfix) with ESMTPS id 518F440669
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 10 Jun 2021 23:20:32 +0000 (UTC)
Received: by mail-qv1-xf2b.google.com with SMTP id e18so15614594qvm.10
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 10 Jun 2021 16:20:32 -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
 :cc; bh=q7HMqmJLxNmu+qduuxNQmqzhOIbnxb20wO0kESCgxow=;
 b=QxXNLbcVKhOWSXYZgOSbAMAuRLELo6cvdPbCdH7sv/8Y8t1IT+PYF3PQiYi+f4sRaN
 3nyNII/ocuLwnQEUenL8kYMaTEGPytdt896p19H3EatSb2s4yJWe9u0wiWwRLgAabCif
 DVa8ubjiLvKsXE7AWZOpv3kPjwjAH+c09fvdYTvdRi+r/vaeDIhaRZpA0bJu7yyZT4RX
 ygdyI//nKX4O+NPqlDV1LzpwaSd/Rv9CCdXeeQy/xxoiYp1YtY6tGo2t89I3qMv8vP5G
 HnwOEtfiy6Cx0B2p9qY60iPEeTL2XohqkRFCJJDUu8bR3AHtLL4j0N/p4KrJOiCHFVGB
 hciA==
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:cc;
 bh=q7HMqmJLxNmu+qduuxNQmqzhOIbnxb20wO0kESCgxow=;
 b=DEHcdU9X3DXNe2soAGiSPUM52ZXtFscxkdA3pm13vqMUtXFXishdFSgnnxPTJCm/D1
 8GZO1FfD5tCieoEngOLr/p6pL//0wOi0zjdII3EqsUBXJrjwwPF5XAVoMgRN3Ze57eaV
 PKfScytsd8Y/CAUZ0DaIpObblPS2TZCjMJVrhBocDIp4/DrNd43OL1XuzGNo0mYa5YpD
 ZyA0WxgLNTjGTCh9lFdRtZM98wK+KguPIDdNEF/1U4KR1Vj7Wlx21b2E/6gNTl4o32h0
 DmIhlhlICp0UCajU9iDnHKwDuOPqzhaDWSYHt245wWLhHdzaZliU7kNIb4rPmYpTIMWy
 NmsA==
X-Gm-Message-State: AOAM531dX4oMKB11D82sziRG7E/ljx7VXwK5b7S+tS+kkOWknJeIx46P
 DhDrrTKyAwaDW4tTCMs9zGgdnq4/6xlUFk91kGzbPA==
X-Google-Smtp-Source: ABdhPJyr1qXzwRobaEMeu1xkzXWKT4AS0XtzdRwotYLEabJJvjfRm/kRx34gXZDq4f1Ej2TSOQIcYHVo6yYqNUifMwY=
X-Received: by 2002:ad4:4c51:: with SMTP id cs17mr2055677qvb.57.1623367231023; 
 Thu, 10 Jun 2021 16:20:31 -0700 (PDT)
MIME-Version: 1.0
References: <CAGpPWDYRcR1U-zwmM_jUA_49LRMsAC5h+DpNFjn5nGniQpN29w@mail.gmail.com>
 <CAMZUoK=1Rw-rzYPh24VLaH2HmmEO-B2ipf_9ymPb1RQQGUzjvw@mail.gmail.com>
 <CAGpPWDb4sp4XoQjb7qOfNK3BQTS3zNrx6SQ3s7N=HM+ZaiLPLw@mail.gmail.com>
In-Reply-To: <CAGpPWDb4sp4XoQjb7qOfNK3BQTS3zNrx6SQ3s7N=HM+ZaiLPLw@mail.gmail.com>
From: "Russell O'Connor" <roconnor@blockstream.com>
Date: Thu, 10 Jun 2021 19:20:19 -0400
Message-ID: <CAMZUoK=EM6cN2YYrZ=YxtrAi5GfxTuY5_6nb5HGWD-WL4RNOCg@mail.gmail.com>
To: Billy Tetrud <billy.tetrud@gmail.com>
Content-Type: multipart/alternative; boundary="00000000000025446505c471a30d"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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 23:20:34 -0000

--00000000000025446505c471a30d
Content-Type: text/plain; charset="UTF-8"

As it stands today, in order to double spend a transaction during a reorg,
one must take an active role of recognizing that a reorg has happened, hope
that the new branch has completely omitted your spending transaction, and
then quickly broadcast a replacement transaction with a higher fee to
outbid your previous transaction.

However with, pretty much any change to Bitcoin that leads to non-monotonic
validity rules, that is any rule where transactions that are valid at one
tip, can become invalid at a latter tip through some other means than their
inputs being spent, such as OP_BBV, one can design a wallet to passively
take advantage of reorgs by always spending through an OP_BBV that is on
the verge of becoming invalid.  Then you just have to sit back and wait for
a suitable reorg to take back your UTXO for you without any work.  I would
probably attempt to build such a wallet for myself should any OP_BBV-like
proposal be implemented.  Think of it as an auto-double spend wallet.

Some people hold the opinion that there is no meaningful distinction
between the active and passive roles in these two scenarios.  I'm not
convinced.  I see a material difference between needing to actively
broadcast a replacement transaction and passively waiting for your
transaction to fall out of validity.  I also see a material difference
between needing the transaction to be completely omitted from the reorging
chain versus just having the transaction fail a height qualification in the
reorging chain.

(There are a few other lesser problems with an OP_BBV proposal, including
the fact that Bitcoin software tends to cache script validity so you'd want
to use the taproot annex instead of pure script; and a possible issue that
the proposal defeats limits on transaction replacement because now instead
of meeting minimum thresholds for fee bumping you can just let the previous
transaction expire and bump the fee by a fraction (though you are
effectively rate limited so maybe that is considered sufficiently
mitigated?).  But there is little point in addressing these lesser concerns
if the main concern is outstanding.)

On Thu, Jun 10, 2021 at 6:20 PM Billy Tetrud <billy.tetrud@gmail.com> wrote:

> @Russell In that thread, you quoted Satoshi there, but neither he nor you
> really deeply explained the concern. Would you mind elaborating on a
> situation that calls for concern here? Some deeper explanation of the
> "reorg safety" property would also be helpful. I'd very much like to know
> what your thoughts are on the specific points I brought up in the BIP as
> well.
>
> On Thu, Jun 10, 2021 at 11:35 AM Russell O'Connor <
> roconnor@blockstream.com> wrote:
>
>> 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
>>>
>>

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

<div dir=3D"ltr"><div>As it stands today, in order to double spend a transa=
ction during a reorg, one must take an active role of recognizing that a re=
org has happened, hope that the new branch has completely omitted your spen=
ding transaction, and then quickly broadcast a replacement transaction with=
 a higher fee to outbid your previous transaction.</div><div><br></div><div=
>However with, pretty much any change to Bitcoin that leads to non-monotoni=
c validity rules, that is any rule where transactions that are valid at one=
 tip, can become invalid at a latter tip through some other means than thei=
r inputs being spent, such as OP_BBV, one can design a wallet to passively =
take advantage of reorgs by always spending through an OP_BBV that is on th=
e verge of becoming invalid.=C2=A0 Then you just have to sit back and wait =
for a suitable reorg to take back your UTXO for you without any work.=C2=A0=
 I would probably attempt to build such a wallet for myself should any OP_B=
BV-like proposal be implemented.=C2=A0 Think of it as an auto-double spend =
wallet.</div><div><br></div><div>Some people hold the opinion that there is=
 no meaningful distinction between the active and passive roles in these tw=
o scenarios.=C2=A0 I&#39;m not convinced.=C2=A0 I see a material difference=
 between needing to actively broadcast a replacement transaction and passiv=
ely waiting for your transaction to fall out of validity.=C2=A0 I also see =
a material difference between needing the transaction to be completely omit=
ted from the reorging chain versus just having the transaction fail a heigh=
t qualification in the reorging chain.<br></div><div><br></div><div>(There =
are a few other lesser problems with an OP_BBV proposal, including the fact=
 that Bitcoin software tends to cache script validity so you&#39;d want to =
use the taproot annex instead of pure script; and a possible issue that the=
 proposal defeats limits on transaction replacement because now instead of =
meeting minimum thresholds for fee bumping you can just let the previous tr=
ansaction expire and bump the fee by a fraction (though you are effectively=
 rate limited so maybe that is considered sufficiently mitigated?).=C2=A0 B=
ut there is little point in addressing these lesser concerns if the main co=
ncern is outstanding.)<br></div></div><br><div class=3D"gmail_quote"><div d=
ir=3D"ltr" class=3D"gmail_attr">On Thu, Jun 10, 2021 at 6:20 PM Billy Tetru=
d &lt;<a href=3D"mailto:billy.tetrud@gmail.com">billy.tetrud@gmail.com</a>&=
gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div =
dir=3D"ltr">@Russell In that thread, you quoted Satoshi there, but neither =
he nor you really deeply explained the concern. Would you mind elaborating =
on a situation that calls=C2=A0for concern here? Some deeper explanation of=
 the &quot;reorg safety&quot; property would also be helpful. I&#39;d very =
much like to know what your thoughts are on the specific points I brought u=
p in the BIP as well.=C2=A0<br></div><br><div class=3D"gmail_quote"><div di=
r=3D"ltr" class=3D"gmail_attr">On Thu, Jun 10, 2021 at 11:35 AM Russell O&#=
39;Connor &lt;<a href=3D"mailto:roconnor@blockstream.com" target=3D"_blank"=
>roconnor@blockstream.com</a>&gt; wrote:<br></div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,20=
4,204);padding-left:1ex"><div dir=3D"ltr"><div>This is a continuation of th=
e thread at <a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-=
dev/2021-April/018760.html" target=3D"_blank">https://lists.linuxfoundation=
.org/pipermail/bitcoin-dev/2021-April/018760.html</a> on this topic.</div><=
div><br></div><div>I still remain unconvinced that we ought to give up on t=
he &quot;reorg safety&quot; property that is explicitly part of Bitcoin&#39=
;s design.<br></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" c=
lass=3D"gmail_attr">On Thu, Jun 10, 2021 at 1:56 PM Billy Tetrud via bitcoi=
n-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=
=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">Hi Everyo=
ne,<div><br></div><div>I&#39;d like to open a discussion of an opcode I cal=
l OP_BEFOREBLOCKVERIFY (OP_BBV) which is similar to ones that have been dis=
cussed before (eg=C2=A0<span style=3D"background-color:rgb(246,246,246);col=
or: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 r=
epresenting a block height, and marks the transaction invalid if the curren=
t block the transaction is being evaluated=C2=A0for is greater than or equa=
l to that block height, the transaction is invalid. I wrote up a <a href=3D=
"https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/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 t=
hat uses OP_BBV and a spend path that uses OP_CHECKSEQUENCEVERIFY so that b=
efore a particular block one person can spend, and after that block a diffe=
rent person can spend. This can allow doing things like expiring payments o=
r 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 intere=
sted in is more efficient wallet vaults. However, wallet vaults requires ot=
her new opcodes, and I&#39;ve been given the (good, I think) advice to star=
t 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 specifi=
cs of the wallet vaults I&#39;m thinking of (which are more involved, requi=
ring other new opcodes that I think makes more sense to discuss in a differ=
ent thread).</div><div><br></div><div>The main thing I&#39;d like to discus=
s 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 th=
ere are two concerns:</div><div><br></div><div>1. that an opcode 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 opc=
ode like this could cause &quot;bad&quot; reorg behavior, where in a reorg,=
 transactions that were spent become not spend and not spendable because th=
ey were mined too near their expiry point.=C2=A0</div><div><br></div><div>W=
hile 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* opcodes like tha=
t are safe - in particular OP_BBV. In the context of OP_BBV specifically, i=
t 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 general=
ly be waiting for 6 confirmations and software can warn the user to wait fo=
r 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"https://g=
ithub.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/bbv/bip-before=
blockverify.md#transaction-expiry" target=3D"_blank">Design Tradeoffs and R=
isks</a>=C2=A0section of the document I wrote for OP_BBV. I&#39;d love to h=
ear thoughts from others on here about these things and especially the disc=
ussion of these issues in the document I linked to.=C2=A0</div><div><br></d=
iv><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>
</blockquote></div>
</blockquote></div>

--00000000000025446505c471a30d--