path: root/47/2535fc356f9e15a2cb18e99e666ca5e356a266

Return-Path: <roconnor@blockstream.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 2B06BC000B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 12 Jun 2021 15:58:44 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id 0293D403AF
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 12 Jun 2021 15:58:44 +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 Dql7nk8mUTps
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 12 Jun 2021 15:58:42 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com
 [IPv6:2607:f8b0:4864:20::82a])
 by smtp4.osuosl.org (Postfix) with ESMTPS id 2522340398
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 12 Jun 2021 15:58:42 +0000 (UTC)
Received: by mail-qt1-x82a.google.com with SMTP id v6so5084744qta.9
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 12 Jun 2021 08:58:41 -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=fckyegheuFdVmChDeBf1ZsaCkyzpNKBwnJxrV1IWrI8=;
 b=qaXnBurVjIlZbu71rqX2JGcFj7FvtyIeI7gaeC3s17aYmRMLB18sXuPdbTeqND0liO
 5Q7qB9fcxAYaQ0BbCdm7aWPlDDEkAdefi4vafdgNO8CCH5tAm1+JYgagh8ueuql+i2Zk
 6aNDf+GSP/4swOq7wW0G1u9Kj8ervlwKIMqiSFT/DYDEYtiPLPkiWVrp4Yp+EDRmh25o
 yzPDjw3Rs+64wMvAjtFd/tqWa1bm9t9zNr+FiMJe6z4zJrxZBCRjXVkqEWcCHft9QZtI
 ROSSfk+HpjkQpEA2/2hdFSCzn+CSDLETK+CYmWFIfeDPAZwhtIUgJHjxoc0Dh9Cw62b3
 gxEQ==
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=fckyegheuFdVmChDeBf1ZsaCkyzpNKBwnJxrV1IWrI8=;
 b=exUxBCZ9oLtgegu14qqTbQ8+wY8NmaxaHysysySMGkPV9b6meGZVUtCAWuyrVWNFYD
 efQSifcW6NpgU0EnNjptlKNL2/2V6ESthzc+s2bkD4aO6u/9S0yIgK3xW1GcJEcOru/U
 nZwzffx1phT3Aus1QGEdqXm/my1yjTIw92WxytyScOEBVkLQwsZ1Cyguujki3gp0LauY
 thhKCngl6AikFP3kyzLUrDUVTiPH1KzjfPMxO/PwIFJyPCHT4OuiJ2e1ya7ZHvvoO4Rs
 erpJf+rNxCEyqdBsZppldcuKlx8wR5Q8WtdLXmiHht8SdE1SSLxzrjWb13x/iZ911w6A
 +2jA==
X-Gm-Message-State: AOAM5336UIjX6xJFJTPjPsV/khY6e12mYZJTf+Hl0HeecSkCQ+teuzu6
 +YHYofO2TFUcTkq0E0UetHswumiXEAvC7RC4i0DfJQ==
X-Google-Smtp-Source: ABdhPJx4Z1RR1yBSAgIYMOkod049xnVHCc1DOpdDJin8WxTfxg+KGhfM9w3z2MmIFfSylKleALPKIKfW29yT3VgyIzo=
X-Received: by 2002:a05:622a:15d5:: with SMTP id
 d21mr8902658qty.335.1623513520827; 
 Sat, 12 Jun 2021 08:58:40 -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>
 <CAMZUoK=EM6cN2YYrZ=YxtrAi5GfxTuY5_6nb5HGWD-WL4RNOCg@mail.gmail.com>
 <CAGpPWDZLzV0EghpeL1Hw-_5kToU_-Vzzco5DuxnivKEAS51NHg@mail.gmail.com>
 <CAH+Axy7b8MS92ZeMnPx-TosvNzRv9=34UDQ9ia-fxeLzO_A0+Q@mail.gmail.com>
 <CAMZUoKmytZm5boBKSYbrJdNa0LduxtTyUUheq=tjD1J_GO0TjA@mail.gmail.com>
 <CAGpPWDZaTytZxVwG3D7MKe6kSb4JrSaA46rxEaiAOj2S1G3kOg@mail.gmail.com>
In-Reply-To: <CAGpPWDZaTytZxVwG3D7MKe6kSb4JrSaA46rxEaiAOj2S1G3kOg@mail.gmail.com>
From: "Russell O'Connor" <roconnor@blockstream.com>
Date: Sat, 12 Jun 2021 11:58:29 -0400
Message-ID: <CAMZUoKkaRA5mYrpKY1T31qZtHQVAVwSGujf_bJXrj34FES2Drw@mail.gmail.com>
To: Billy Tetrud <billy.tetrud@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000b2834605c493b26e"
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: Sat, 12 Jun 2021 15:58:44 -0000

--000000000000b2834605c493b26e
Content-Type: text/plain; charset="UTF-8"

On Sat, Jun 12, 2021 at 3:59 AM Billy Tetrud <billy.tetrud@gmail.com> wrote:

> >  taproot annex
>
> From what I can tell, the annex is basically additional inputs to a script
> that might have additional constraints put on it. Is that right? I don't
> quite follow how moving the max height to the annex helps script caching
> here. I wasn't able to find much information on how the annex is envisioned
> to be used. Would you mind elaborating on how this would work?
>
> Also, I think the proposal as it stands already addresses script caching
> (in the Transaction Evaluation section
> <https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/bbv/bip-beforeblockverify.md#transaction-evaluation>).
> The result of the script can be cached as long as the cache item also
> contains information requiring just the OP_BBV to be re-evaluated (for the
> relevant block).
>

The normal approach for this problem would be a design that adds an "annex
field" (where the details on how to delimit annex fields is not yet
standardized) for a maxheight value, and add a consensus rule that
transaction with one (or more?) maxheight fields are invalid in blocks
whose height exceeds this (or any) maxheight value.  Then you could/would
add an OP code to push a copy of the (smallest) maxheight value from the
annex onto the stack or maybe an opcode to compare a stack item with this
(every) maxheight value from the annex.  This indirection is how OP_CLTV
and OP_CSV work and this indirection makes script validity cacheable
because script remains a function of the transaction data only.  Since
transaction data doesn't change, neither does the outcome of script
evaluation. The rule that invalidates late transactions looks only at the
annex and is independent of any script evaluation considerations.


> > this auto-double-spend wallet would send every payment with an annex value
> that limits the payment to being valid only up to the next block
>
> One possible solution to that would be to require that the input to OP_BBV
> to be in the script itself and not originate from the witness.
>
> Regardless, I think the ideal solution is to not have any of these such
> rules if we can simply change the definition for what counts as
> finalization to account for the fact that BBV transactions mined close to
> their expiration. Is there a reason this finalization-redefinition is not
> an adequate solution?
>

Generally speaking, you cannot solve security problems through optional and
completely voluntary transaction relay policy.  I'll just send my
about-to-expire transactions directly to miners and they will probably mine
them because they are, in fact, valid, and pay fees.  Why wouldn't they
mine it?

(Yes, I know this logic also applies to RBF flagged transactions.  Indeed,
you cannot rely on an RBF flag to prevent double spending,  Yes I think the
RBF flag ought to be removed from consideration and every transaction
should be considered RBFable.  Maybe that even happens to be my own node's
relay policy.)

I apologize, but I don't think I have further time to engage in an idea
that I don't consider likely to achieve broad community support.

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

<div dir=3D"ltr"><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"g=
mail_attr">On Sat, Jun 12, 2021 at 3:59 AM Billy Tetrud &lt;<a href=3D"mail=
to:billy.tetrud@gmail.com">billy.tetrud@gmail.com</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">&gt;=C2=
=A0

<span>taproot</span>=C2=A0<span>annex</span><div><span><br></span></div><di=
v><span>From what I can tell, the annex is basically additional inputs to a=
 script that might have additional constraints put on it. Is that right? I =
don&#39;t quite follow how moving the max height to the annex helps script =
caching here. I wasn&#39;t able to find much information on how the annex i=
s envisioned to be used. Would you mind elaborating on how this would work?=
</span></div><div><span><br></span></div><div>Also, I think the proposal as=
 it stands already addresses script caching (in the <a href=3D"https://gith=
ub.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/bbv/bip-beforeblo=
ckverify.md#transaction-evaluation" target=3D"_blank">Transaction Evaluatio=
n section</a>). The result of the script can be cached as long as the cache=
 item also contains information requiring just the OP_BBV to be re-evaluate=
d (for the relevant block).</div></div></blockquote><div>=C2=A0</div><div>T=
he normal approach for this problem would be a design that adds an &quot;an=
nex field&quot; (where the details on how to delimit annex fields is not ye=
t standardized) for a maxheight value, and add a consensus rule that transa=
ction with one (or more?) maxheight fields are invalid in blocks whose heig=
ht exceeds this (or any) maxheight value.=C2=A0 Then you could/would add an=
 OP code to push a copy of the (smallest) maxheight value from the annex on=
to the stack or maybe an opcode to compare a stack item with this (every) m=
axheight value from the annex.=C2=A0 This indirection is how OP_CLTV and OP=
_CSV work and this indirection makes script validity cacheable because scri=
pt remains a function of the transaction data only.=C2=A0 Since transaction=
 data doesn&#39;t change, neither does the outcome of script evaluation. Th=
e rule that invalidates late transactions looks only at the annex and is in=
dependent of any script evaluation considerations.<br></div><div>=C2=A0</di=
v><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;borde=
r-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div><=
span>&gt; this=C2=A0</span>auto-double-spend wallet would send every paymen=
t with an=C2=A0<span>annex</span>=C2=A0value that limits the payment to bei=
ng valid only up to the next block</div><div><br></div><div>One possible so=
lution to that would be to require that the input to OP_BBV to be in the sc=
ript itself and not originate from the witness.=C2=A0</div><div><br></div><=
div>Regardless, I think the ideal solution is to not have any of these such=
 rules if we can simply change the definition for what counts as finalizati=
on to account for the fact that BBV transactions mined close to their expir=
ation. Is there a reason this finalization-redefinition is not an adequate =
solution?</div></div></blockquote><div><br></div><div>Generally speaking, y=
ou cannot solve security problems through optional and completely voluntary=
 transaction relay policy.=C2=A0 I&#39;ll just send my about-to-expire tran=
sactions directly to miners and they will probably mine them because they a=
re, in fact, valid, and pay fees.=C2=A0 Why wouldn&#39;t they mine it?</div=
><div><br></div><div>(Yes, I know this logic also applies to RBF flagged tr=
ansactions.=C2=A0 Indeed, you cannot rely on an RBF flag to prevent double =
spending,=C2=A0 Yes I think the RBF flag ought to be removed from considera=
tion and every transaction should be considered RBFable.=C2=A0 Maybe that e=
ven happens to be my own node&#39;s relay policy.)</div><div><br></div><div=
>I apologize, but I don&#39;t think I have further time to engage in an ide=
a that I don&#39;t consider likely to achieve broad community support.<br><=
/div></div></div>

--000000000000b2834605c493b26e--