path: root/95/a6979b6a46c8e72839c3c01afb57883802f7ee

Return-Path: <fresheneesz@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 4E2E0C000B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 13 Jun 2021 22:12:41 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id 36BFB40004
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 13 Jun 2021 22:12:41 +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 2KV8AGhqPiKV
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 13 Jun 2021 22:12:39 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com
 [IPv6:2a00:1450:4864:20::530])
 by smtp2.osuosl.org (Postfix) with ESMTPS id 95A5440001
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 13 Jun 2021 22:12:39 +0000 (UTC)
Received: by mail-ed1-x530.google.com with SMTP id u24so43921281edy.11
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 13 Jun 2021 15:12:39 -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=eCsMmBgkiQiL0jlgAWXNdcRKTdwqyOSSnVs7qL2RUTU=;
 b=uZnC38agJ3eX2O8e2IFalWbe5I3C/yjqVEZFx8nLJlv6Ilx/SLG6+fKdLXfvLmb8Fw
 Yfu+TTD2Zbqawq7NyTzH/LCWUB9yJ1p00YQbQKconGahJJ5xBXGmnqdvENC+iiTFSEhe
 RsQ6GJlRs+XbmZUHBG5Xvwx6hJr5+FNHSyXgtEirI40Z7iVo+n6quBYISKinYfI/Qj/n
 w69zDh15XUW5tIQDpWjX6udSJopP+6NQiBMPPsImsRbQAof46/xQ6qhVvBMhanHsvBcB
 Du9VzRsGVp3I0CHT7lYDUiZe2xTICIMvWedKPNrfhk9srUxcfy60WUi3WcAV+r67IsAx
 /QUQ==
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=eCsMmBgkiQiL0jlgAWXNdcRKTdwqyOSSnVs7qL2RUTU=;
 b=U0R7JAHVHm9yj9zzWEMH2CcGXuindvz2CSPQ3U3wKaun8+0SkdQVdchcB74RmbxVX9
 8y88A6jlAqLyKtmnFhTYHq/QBfQH8PVnwVr0aiQDut1Nh98Q7uzmoxpZfy5F6qW89Jl+
 lJ558I2FeyMoK6fjeWvBUb9ddT32QYTFo55r/XKZfy5LhHiVJ3UjRJ1kGlyWv9MQbqOV
 Pj32Cp+iQZHBca/cU10D7tokvCVymlxKcmhGyRhdauCUF/N5J7EyPLgyrWRnA5nb1xfe
 dnOV7zaTA+Sa5cELkMwjugX618K06v4vhGs/L8BBcrivUZOIIGariyq5juA46UeF3WX3
 Uqrg==
X-Gm-Message-State: AOAM533eHPigIp1p0Jy5vJ25lYXWklfJEjcTzfNnsPwZRLqvaJXOtl60
 srB4gh7g6G3PjNn8OrQkwKvBYFgE5drNA5WaJDo=
X-Google-Smtp-Source: ABdhPJzrrdXxMPRtUJeEhk8blYY1r051BJHx3d/N50U1NLQcTRtT8/DcPnN8m1wKHWiEz0MLxau+wgFNV4iajhHWESE=
X-Received: by 2002:a50:b2c5:: with SMTP id p63mr489756edd.5.1623622357430;
 Sun, 13 Jun 2021 15:12:37 -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>
 <CAMZUoKkaRA5mYrpKY1T31qZtHQVAVwSGujf_bJXrj34FES2Drw@mail.gmail.com>
 <CAGpPWDbcnBU62VCym_qS6Xu=nw59BO1Kf31N-S2ckQxU4rjbhg@mail.gmail.com>
In-Reply-To: <CAGpPWDbcnBU62VCym_qS6Xu=nw59BO1Kf31N-S2ckQxU4rjbhg@mail.gmail.com>
From: Billy Tetrud <billy.tetrud@gmail.com>
Date: Sun, 13 Jun 2021 15:12:21 -0700
Message-ID: <CAGpPWDYEyXVxtQhG_H024Gs5st_qVAFmpapSMR3pQO3mXBnp4Q@mail.gmail.com>
To: "Russell O'Connor" <roconnor@blockstream.com>
Content-Type: multipart/alternative; boundary="000000000000dd337005c4ad0974"
X-Mailman-Approved-At: Sun, 13 Jun 2021 22:43:42 +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: Sun, 13 Jun 2021 22:12:41 -0000

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

I've thought of a third mitigation I think might be sufficient for you,
Russell, even if neither changing what receivers of coins define as a
finalized transaction nor disallowing block height from be specified by the
script witness are not sufficient for some reason.

Consider a rule increasing the weight of a transaction using OP_BBV by 1%
for each block within 100 blocks that the transaction is mined into. Eg, if
a spend-path using OP_BBV is mined into a block that is greater than 100
blocks before the expiry, no additional weight is added, if the block is
exactly 100 blocks from expiry the weight is increased by 1%, if the block
is 6 blocks away from expiry the weight is 2.54 times as large (1.01^94),
etc. This way, if someone tried to program the passive auto-double-spend
wallet, they'd have to spend over 2 times as much in fees as they would
otherwise. Also, since the increase in weight is only about 6% over the
span of 6 blocks, that is unlikely to affect the transaction's
profitability to mine much, so it would be ineffective to program the
auto-double-spend wallet to simply send transactions that expire within 101
blocks, because miners would highly likely still mine in that transaction
in subsequent blocks during a reorg.

In any case, I see 3 different solutions to the attack vector you brought
up (modifying receiver finalization definition, disallowing inputs to the
script to determine block height, and gradual transaction weight increase
near expiry). Any one of them seems to solve the problem you presented.

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

> >  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?
>
> You've misunderstood me. When I said "change what counts as finalization",
> what I meant is for the receiver of coins, not for mining or relay. For
> example, if you buy coffee with an OP_BBV output that expires in the next
> block, the merchant will be able to see that there's one confirmation on
> your transaction. But they should also be able to see a warning saying that
> the transaction has not finalized and they must wait for 6 confirmations
> before treating payment as complete. This way, in the case that a reorg
> happens and it doesn't contain the transaction, the merchant will not have
> given the coffee yet, and their software will be able to tell them that the
> payment has been reversed.
>
> > I think the RBF flag ought to be removed from consideration and every
> transaction should be considered RBFable
>
> I agree with that. Making the assumption that a non-RBF transaction won't
> be replaced isn't a great assumption.
>
> > This indirection is how OP_CLTV and OP_CSV work
>
> I see. Thanks for the explanation.
>
>
> On Sat, Jun 12, 2021 at 8:58 AM Russell O'Connor <roconnor@blockstream.com>
> wrote:
>
>>
>> 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.
>>
>

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

<div dir=3D"ltr">I&#39;ve thought of a third mitigation I think might be su=
fficient for you, Russell, even if neither changing what receivers of coins=
 define as a finalized transaction nor disallowing block height from be spe=
cified by the script witness are not sufficient for some reason.=C2=A0<div>=
<br></div><div>Consider a rule increasing the weight of a transaction using=
 OP_BBV by 1% for each block within 100 blocks that the transaction is mine=
d into. Eg, if a spend-path using OP_BBV is mined into a block that is grea=
ter than 100 blocks before the expiry, no additional weight is added, if th=
e block is exactly 100 blocks from expiry=C2=A0the weight is increased by 1=
%, if the block is 6 blocks away from expiry the weight is 2.54 times as la=
rge (1.01^94), etc. This way, if someone tried to program the passive auto-=
double-spend wallet, they&#39;d have to spend over 2 times as much in fees =
as they would otherwise. Also, since the increase in weight is only about 6=
% over the span of 6 blocks, that=C2=A0is unlikely to affect the transactio=
n&#39;s profitability to mine much, so it would be ineffective to program t=
he auto-double-spend wallet to simply send transactions that expire within =
101 blocks, because miners would highly likely still mine in that transacti=
on in subsequent blocks during a reorg.=C2=A0</div><div><br></div><div>In a=
ny case, I see 3 different solutions to the attack vector you brought up (m=
odifying receiver finalization definition, disallowing inputs to the script=
 to determine block height, and gradual transaction weight increase near ex=
piry). Any one of them seems to solve the problem you presented.=C2=A0</div=
></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr"=
>On Sat, Jun 12, 2021 at 11:48 AM Billy Tetrud &lt;<a href=3D"mailto:billy.=
tetrud@gmail.com" target=3D"_blank">billy.tetrud@gmail.com</a>&gt; wrote:<b=
r></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"ltr">=
<div>&gt;=C2=A0 I&#39;ll just send my about-to-expire transactions directly=
 to miners and they will probably mine them because they are, in fact, vali=
d, and pay fees.=C2=A0 Why wouldn&#39;t they mine it?</div><div><br></div><=
div>You&#39;ve misunderstood me. When I said &quot;change what counts as fi=
nalization&quot;, what I meant is for the receiver of coins, not for mining=
 or relay. For example, if you buy coffee with an OP_BBV output that expire=
s in the next block, the merchant will be able to see that there&#39;s one =
confirmation on your transaction. But they should also be able to see a war=
ning saying that the transaction has not finalized and they must wait for 6=
 confirmations before treating payment as complete. This way, in the case t=
hat a reorg happens and it doesn&#39;t contain=C2=A0the transaction, the me=
rchant will not have given the coffee yet, and their software will be able =
to tell them that the payment has been reversed.=C2=A0</div><div><br></div>=
<div>&gt; I think the RBF flag ought to be removed from consideration and e=
very transaction should be considered RBFable</div><div><br></div><div>I ag=
ree with that. Making the assumption that a non-RBF transaction won&#39;t b=
e replaced isn&#39;t a great assumption.=C2=A0</div><div><br></div><div>&gt=
;=C2=A0This indirection is how OP_CLTV and OP_CSV work<div><br></div><div>I=
 see. Thanks for the explanation.</div><div><br></div><div></div></div></di=
v><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On S=
at, Jun 12, 2021 at 8:58 AM Russell O&#39;Connor &lt;<a href=3D"mailto:roco=
nnor@blockstream.com" target=3D"_blank">roconnor@blockstream.com</a>&gt; wr=
ote:<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=
"ltr"><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">=
On Sat, Jun 12, 2021 at 3:59 AM Billy Tetrud &lt;<a href=3D"mailto:billy.te=
trud@gmail.com" target=3D"_blank">billy.tetrud@gmail.com</a>&gt; wrote:<br>=
</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b=
order-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">&g=
t;=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>
</blockquote></div>
</blockquote></div>

--000000000000dd337005c4ad0974--