path: root/dc/ee67923a63309eafc8c896856abfc4907b7f02

Return-Path: <fresheneesz@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id F0B66C000B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 10 Jun 2021 22:20:16 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id D896883DC8
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 10 Jun 2021 22:20:16 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 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_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=gmail.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 33HSSK4OiOMc
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 10 Jun 2021 22:20:15 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com
 [IPv6:2a00:1450:4864:20::635])
 by smtp1.osuosl.org (Postfix) with ESMTPS id 742FA83DC2
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 10 Jun 2021 22:20:15 +0000 (UTC)
Received: by mail-ej1-x635.google.com with SMTP id k25so1452137eja.9
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 10 Jun 2021 15:20:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=qhdYV7gP3iw7yaBhDN9PHs/4OzleUUqYXioEo/Gx8OE=;
 b=f5Zsg5uCUj68LMVvHHfLVM1wL/px/NcQlAEoSxhWxhdcXjWCz70ssiZeEuFXv8zuA/
 3xemJrXZDeKXy0RN4bEDxSYlzLOq0To/ygpU4MWOe48zdsOrT1zasyRWUgeFxZ5svJuN
 FjM/eQOVNePPN+0lT0Z4wGjSL79bsZFxdg1U0ZLjuxXB4NudzqYTmyOk5XoUXA9Xa/gx
 LwVTq411mt1Ha7lP38zt1P25yMcX7jVUxcVgLz8N6zJYE32ZWv5iFNQGU1tfJdsesAfC
 D9af0bC5arqKV+RoW+AIX8gSUAtn+8aRXVF8sXAMG4248asp4rAG69fMBW3XpEZ/eo7k
 W3rQ==
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=qhdYV7gP3iw7yaBhDN9PHs/4OzleUUqYXioEo/Gx8OE=;
 b=kfr8YhNsVXmnvbd67zWsgiPncQ9SSgSA+s2ChD3WuXtA5fcKWl/QS2NVBbln/5Rd2z
 trCeLJtv8AF40FFe1mz97TLddFxk3qlY8DRXZKmH2pbDL0V2Qxdnm+KGMscVdtYhS94o
 fb0414Aqz4Zg1E27L/1Qg181/ZMJcUkRvANCz7FlG4SV30lXBUsNdRf2UaeO79u8bXud
 J9iJk+uv1Q/Oz/JFRtnQ4wmpJa1kg266mnY6WOnP3A3w+9XgtwBso9eAsnWLI1FQeaGS
 bx7aHLOPylngtw0okrNP+YHO9X45Re3LwbBI54PWgUsus8PboDJ/LFk4Rk7DttIbXwGK
 AM6A==
X-Gm-Message-State: AOAM531iqWqwsYUrHxPJeSn5oFvdBhyWnQKF6lRSVKi2h9lJQB2BRGNK
 Q2pR48P9SeKowtZwRJXUUVUhV0gm/MlXVYAXPmE=
X-Google-Smtp-Source: ABdhPJyeO4NwhGcJUr3OlZqQwRwE4Mm+XU8soc6yQt6GmQwbkuBtKKknp20H4e/CrFmYQGgL4AjKJXn7cS0mhQEsZAk=
X-Received: by 2002:a17:907:38c:: with SMTP id
 ss12mr618041ejb.401.1623363613534; 
 Thu, 10 Jun 2021 15:20:13 -0700 (PDT)
MIME-Version: 1.0
References: <CAGpPWDYRcR1U-zwmM_jUA_49LRMsAC5h+DpNFjn5nGniQpN29w@mail.gmail.com>
 <CAMZUoK=1Rw-rzYPh24VLaH2HmmEO-B2ipf_9ymPb1RQQGUzjvw@mail.gmail.com>
In-Reply-To: <CAMZUoK=1Rw-rzYPh24VLaH2HmmEO-B2ipf_9ymPb1RQQGUzjvw@mail.gmail.com>
From: Billy Tetrud <billy.tetrud@gmail.com>
Date: Thu, 10 Jun 2021 15:19:55 -0700
Message-ID: <CAGpPWDb4sp4XoQjb7qOfNK3BQTS3zNrx6SQ3s7N=HM+ZaiLPLw@mail.gmail.com>
To: "Russell O'Connor" <roconnor@blockstream.com>
Content-Type: multipart/alternative; boundary="00000000000086afb005c470cb50"
X-Mailman-Approved-At: Thu, 10 Jun 2021 22:22:57 +0000
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 22:20:17 -0000

--00000000000086afb005c470cb50
Content-Type: text/plain; charset="UTF-8"

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

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

<div dir=3D"ltr">@Russell In that thread, you quoted Satoshi there, but nei=
ther he nor you really deeply explained the concern. Would you mind elabora=
ting on a situation that calls=C2=A0for concern here? Some deeper explanati=
on 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 brou=
ght up in the BIP as well.=C2=A0<br></div><br><div class=3D"gmail_quote"><d=
iv dir=3D"ltr" class=3D"gmail_attr">On Thu, Jun 10, 2021 at 11:35 AM Russel=
l O&#39;Connor &lt;<a href=3D"mailto:roconnor@blockstream.com">roconnor@blo=
ckstream.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddin=
g-left:1ex"><div dir=3D"ltr"><div>This is a continuation of the thread at <=
a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-Apri=
l/018760.html" target=3D"_blank">https://lists.linuxfoundation.org/pipermai=
l/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 the &quot;reor=
g 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" 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@lists.linuxfoundation.org" target=3D"_blank">bit=
coin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid r=
gb(204,204,204);padding-left:1ex"><div dir=3D"ltr">Hi Everyone,<div><br></d=
iv><div>I&#39;d like to open a discussion of an opcode I call OP_BEFOREBLOC=
KVERIFY (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);f=
ont-family:verdana,sans-serif;font-size:13px">OP_BLOCKNUMBER)</span>. The o=
pcode is very simple: the it takes as a parameter a number representing a b=
lock height, and marks the transaction invalid if the current block the tra=
nsaction 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/blob/main/bbv/bip-beforeblock=
verify.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 t=
ransactions. 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 particu=
lar block one person can spend, and after that block a different person can=
 spend. This can allow doing things like expiring payments or reversible pa=
yments in a cheaper way. Currently, things like that require a sequence of =
multiple transactions, however OP_BBV can do it in a single transaction, ma=
king 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) advice to start off this disc=
ussion with something a bit more bite sized and manageable. So I want to ke=
ep this discussion to OP_BBV and steer away from the specifics of the walle=
t vaults I&#39;m thinking of (which are more involved, requiring other new =
opcodes that I think makes more sense to discuss in a different thread).</d=
iv><div><br></div><div>The main thing I&#39;d like to discuss is the histor=
ical avoidance of and stigma toward opcodes that can cause a valid transact=
ion to become invalid. </div><div><br></div><div>It seems there are two con=
cerns:</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 t=
ransactions containing this opcode.</div><div>2. that an opcode like this c=
ould cause &quot;bad&quot; reorg behavior, where in a reorg, transactions t=
hat were spent become not spend and not spendable because they were mined t=
oo 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* opcodes like that are safe - in=
 particular OP_BBV. In the context of OP_BBV specifically, it seems to me l=
ike 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 f=
or 6 confirmations and software can warn the user to wait for 6 confirmatio=
ns in relevant scenarios where a 6-block reorg might reverse the transactio=
n. I discuss this in detail in the=C2=A0<a href=3D"https://github.com/fresh=
eneesz/bip-efficient-bitcoin-vaults/blob/main/bbv/bip-beforeblockverify.md#=
transaction-expiry" target=3D"_blank">Design Tradeoffs and Risks</a>=C2=A0s=
ection of the document I wrote for OP_BBV. I&#39;d love to hear thoughts fr=
om others on here about these things and especially 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>
</blockquote></div>

--00000000000086afb005c470cb50--