path: root/31/38a70bfe3871077f7fb2e4fcdb15c0824fc4ea

Return-Path: <keatonatron@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 9CCD4C000B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 11 Jun 2021 11:12:47 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id 8B90040173
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 11 Jun 2021 11:12:47 +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 LI-Hfm8WtGB2
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 11 Jun 2021 11:12:45 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com
 [IPv6:2a00:1450:4864:20::22f])
 by smtp2.osuosl.org (Postfix) with ESMTPS id D9317400C2
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 11 Jun 2021 11:12:44 +0000 (UTC)
Received: by mail-lj1-x22f.google.com with SMTP id x14so9129403ljp.7
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 11 Jun 2021 04:12:44 -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=TdYOGdFKc8Xpm8RtkOcvPZXdfBzhnALoYrBzBsTe7aM=;
 b=b6Ap6KD3T4AbY5VHX5ATG3/4U2tHNNTRRkCMWKjeS73jRivlya3YOOxIszdTwNV5fC
 ZffRKY7yx19bdX/GTjN3jiWQ1XXxxDYjEQsJdIR65zzYoNjjHga39KWRltocltcKwJwr
 NXcSC1tSanPnhwKjuyBQ23HgD20jyEmBr7Il9ZZeGCD71vZm/HVgp/0Ahksl/50vLsgg
 NSTRO9MK0EhadlLM1wwgmewv5xPYdcrCqHMYQ7JtDJr8jq0XpPkAX4+11oVdIhytcT8I
 ttKAKPxOdNdwB9q6DDw7GJnVq2adKXue+jyV+AS0JIcCMrGSV2XZlTc6yyus2F7VOov7
 RCnQ==
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=TdYOGdFKc8Xpm8RtkOcvPZXdfBzhnALoYrBzBsTe7aM=;
 b=t8dPMY97UE2Qgx5+xc6D+xh+VgqAIhqk6xsSWZ+RRisnI0/S24iNYpzKWbvuFckQni
 8NkQb4mCtT5HwovVfQ0xsgqrSH2xJGaoh3Ocn3KI9xeJxRGF3fgm+wFDPJ6xNpI2HX35
 B8CsAvI/wKFo0+LvR9PNYob/I2L0PyEw78zmcyTXUEY8KE+YRSXLYnm2xvFXgUXx9fsj
 LBVQdWssX6rabIg32HXdi1bEu8WMVhpfDdoYgSRq6IwBggv3lyiIZjBZEyysMI8MJbSg
 7Dv8tNQYS9fej3rwaaPFM+ADeS1HD+qyC83cfDbk1+a5E1qCBPTXn51zjLPcjjn1mMfi
 +CUw==
X-Gm-Message-State: AOAM531zOodZEk+Z+0eikruTavcXwuiuy77Y5BXGU/s1PALc8R8wqlEs
 i2EmXnw6q4Q39OQgDK9wwsTBpSpz1IkyshewSV4=
X-Google-Smtp-Source: ABdhPJzuhLz2IdSr6g9e4Xy0rfxhoO/9pOshiTOnhw3lc4qWaeJ15O15df7VTIeST03zcXu1fP32YSh58lklU/6MMTk=
X-Received: by 2002:a2e:9a87:: with SMTP id p7mr2653111lji.477.1623409962599; 
 Fri, 11 Jun 2021 04:12:42 -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>
In-Reply-To: <CAGpPWDZLzV0EghpeL1Hw-_5kToU_-Vzzco5DuxnivKEAS51NHg@mail.gmail.com>
From: James MacWhyte <macwhyte@gmail.com>
Date: Fri, 11 Jun 2021 13:12:16 +0200
Message-ID: <CAH+Axy7b8MS92ZeMnPx-TosvNzRv9=34UDQ9ia-fxeLzO_A0+Q@mail.gmail.com>
To: Billy Tetrud <billy.tetrud@gmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000254bd005c47b9635"
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: Fri, 11 Jun 2021 11:12:47 -0000

--000000000000254bd005c47b9635
Content-Type: text/plain; charset="UTF-8"

@Billy I like the idea. It is very obvious how useful an opcode like this
would be! (My background is in wallet implementation)

@Russell I do understand your concerns of monotonism, however I'm having a
hard time really coming up with an attack vector. You said "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." Unless I'm mistaken,
this means you would need to send yourself a fresh transaction using OP_BBV
set to, say, 2 blocks in the future, then immediately spend that output in
a new payment to someone else and hope a reorg happens. Does this mean the
theoretical double-spend wallet you are proposing would have to send two
transactions every time you make a single payment, doubling the transaction
fees and adding more uncertainty around when the second transaction would
get confirmed?

In a normal double spend scenario, there is no cost to a failed attempt,
but much to gain from a success. With your design, there is a real cost to
every single attempt (transaction fees) and no evidence that the rate of
success would be higher (you still have to bet on the reorg not including
your transaction in the first few blocks). It sounds like this new system
would actually be less attractive to double spenders than the current model!

I also agree with Billy's idea for relay rules. We already have abusable
chain rules (e.g. a tx can be included in a block with 0 transaction fee
[spam?]) but we add protection with relay rules (e.g. minimum fee to
relay). I don't see how this would be any different, if the chain rules
only enforced the block height for confirmation and the relay rules forced
a minimum OP_BBV value in order to protect against reorg double spends.

James


On Fri, Jun 11, 2021 at 11:00 AM Billy Tetrud via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> >  one can design a wallet to passively take advantage of reorgs
>
> It does sound like this is the central issue. I can certainly see that
> it's materially different than current double spending ability. Double
> spending via reorgs today requires either active participation and
> above-average connection to miners or luck.
>
> The easiest method of double spending I can think of is the following.
> Consider if a user broadcasts an RBF transaction as soon as the original
> transaction is mined. I assume the transaction won't propagate through the
> network because any node that has received the newest block will see it as
> an invalid transaction, is that right? Is there no significant possibility
> that enough of the network hasn't seen the block yet to transmit the RBF
> transaction widely enough to get incorporated into a reorg? This would
> certainly be something wallets could do automatically. It certainly does
> seem like at very least this would have a much lower success rate than your
> auto-double-spend wallet.
>
> In any case, what if we apply the same logic to non-monotonic
> transactions? What if we program nodes to reject such transactions that are
> too close to the borderline? For example, if nodes rejected transactions
> that could expire within 100 blocks, it would be much less likely for this
> kind of thing to be done at point of sale, and there would be a much higher
> chance that whatever recipient that's willing to wait 100 blocks would be
> willing to wait 6 blocks more to be sure no reorg happens. It would also be
> a lot more likely that the transaction is confirmed well before it might
> expire. Not a perfect solution, to be sure. But it could substantially
> limit the cases and likelihoods that passive double-spend attempts would
> succeed. But miners could still get and include transactions in blocks
> regardless of this, and they have an incentive to (to maximize the fees
> they collect). It at least seems plausible that those incentives would
> undermine this solution.
>
> But it seems like all this is only a problem for people who are
> considering 1 confirmation to be effectively finalized. Users and
> programmatic systems alike simply wait for some condition to be true to
> recognize payment as having completed. Systems could simply be programmed
> so the condition is at least 6 confirmations for any non-monotonic
> transaction, or all transactions. 6 confirmations is the accepted standard
> of finalization, isn't it? Users looking at their software should be able
> to see that a confirmation has happened but that this isn't enough to be
> considered finalized. As long as this is standard, no problem should really
> exist, right? Except within incorrectly written software or people taking
> it upon themselves to define finalization on their own. People who accept
> 0-conf transactions are similarly using a non-standard definition of
> finalization and are putting themselves at even greater risk for double
> spends. How would this be any different?
>
> >  there is little point in addressing these lesser concerns if the main
> concern is outstanding
>
> I agree, it makes the most sense to discuss the above points rather than
> getting into the weeds about more minor issues.
>
> On Thu, Jun 10, 2021 at 4:20 PM Russell O'Connor <roconnor@blockstream.com>
> wrote:
>
>> 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
>>>>>
>>>> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr">@Billy I like the idea. It is very obvious how useful an o=
pcode like this would be! (My background is in wallet implementation)<div><=
br></div><div>@Russell I do understand your concerns of monotonism, however=
 I&#39;m having a hard time really coming up with an attack vector. You sai=
d &quot;one can design a wallet to passively take advantage of reorgs by al=
ways spending through an OP_BBV that is on the verge of becoming invalid.&q=
uot; Unless I&#39;m mistaken, this means you would need to send yourself a =
fresh transaction using OP_BBV set to, say, 2 blocks in the future, then im=
mediately spend that output in a new payment to someone else and hope a reo=
rg=C2=A0happens. Does this mean the theoretical double-spend wallet you are=
 proposing would have to send two transactions every time you make a single=
 payment, doubling the transaction fees and adding more uncertainty around =
when the second transaction would get confirmed?<br><br>In a normal double =
spend scenario, there is no cost to a failed attempt, but much to gain from=
 a success. With your design, there is a real cost to every single attempt =
(transaction fees) and no evidence that the rate of success would be higher=
 (you still have to bet on the reorg not including your transaction in the =
first few blocks). It sounds like this new system would actually be less at=
tractive to double spenders than the current model!</div><div><br></div><di=
v>I also agree with Billy&#39;s idea for relay rules. We already have abusa=
ble chain rules (e.g. a tx can be included in a block with 0 transaction fe=
e [spam?]) but we add protection with relay rules (e.g. minimum fee to rela=
y). I don&#39;t see how this would be any different, if the chain rules onl=
y enforced the block height for confirmation and the relay rules forced a m=
inimum OP_BBV value in order to protect against reorg double spends.</div><=
div><div><div dir=3D"ltr"><div dir=3D"ltr"><br></div></div></div></div><div=
><div dir=3D"ltr" class=3D"gmail_signature" data-smartmail=3D"gmail_signatu=
re"><div dir=3D"ltr"><div>James<br></div></div></div></div><br></div><br><d=
iv class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, Jun =
11, 2021 at 11:00 AM Billy Tetrud via bitcoin-dev &lt;<a href=3D"mailto:bit=
coin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</=
a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><d=
iv dir=3D"ltr">&gt;=C2=A0

one can design a wallet to passively take advantage of reorgs<div><br></div=
><div>It does sound like this is the central issue. I can certainly see tha=
t it&#39;s materially different than current double spending ability. Doubl=
e spending via reorgs today requires either active participation and above-=
average connection to miners or luck.</div><div><br></div><div>The easiest =
method of double spending I can think of is the following. Consider if a us=
er broadcasts an RBF transaction as soon as the original transaction is min=
ed. I assume the transaction won&#39;t propagate through the network becaus=
e any node that has received the newest block will see it as an invalid tra=
nsaction, is that right? Is there no significant possibility that enough of=
 the network hasn&#39;t seen the block yet to transmit the RBF transaction =
widely enough to get incorporated into a reorg? This would certainly be som=
ething wallets could do automatically. It certainly does seem like at very =
least this would have=C2=A0a much lower success rate than your auto-double-=
spend wallet.=C2=A0</div><div><br></div><div>In any case, what if we apply =
the same logic to non-monotonic transactions? What if we program nodes to r=
eject such transactions that are too close to the borderline? For example, =
if nodes rejected transactions that could expire within 100 blocks, it woul=
d be much less likely for this kind of thing to be done at point of sale, a=
nd there would be a much higher chance that whatever recipient that&#39;s w=
illing to wait 100 blocks would be willing to wait 6 blocks more to be sure=
 no reorg happens. It would also be a lot more likely that the transaction =
is confirmed well before it might expire. Not a perfect solution, to be sur=
e. But it could substantially limit the cases and likelihoods that passive =
double-spend attempts would succeed. But miners could still get and include=
 transactions in blocks regardless of this, and they have an incentive to (=
to maximize the fees they collect). It at least seems plausible that those =
incentives would undermine this solution.=C2=A0</div><div><br></div><div>Bu=
t it seems like all this is only a problem for people who are considering 1=
 confirmation to be effectively finalized. Users and programmatic systems a=
like simply wait for some condition to be true to recognize payment as havi=
ng completed. Systems could simply be programmed so the condition is at lea=
st 6 confirmations for any non-monotonic transaction,=C2=A0or all transacti=
ons. 6 confirmations is the accepted standard of finalization, isn&#39;t it=
? Users looking at their software should be able to see that a confirmation=
 has happened but that this isn&#39;t enough to be considered finalized. As=
 long as this is standard, no problem should really exist, right? Except wi=
thin incorrectly written software or people taking it upon themselves to de=
fine finalization on their own. People who accept 0-conf transactions are s=
imilarly using a non-standard definition of finalization and are putting th=
emselves at even greater risk for double spends. How would this be any diff=
erent?=C2=A0</div><div><br></div><div>&gt;=C2=A0 there is little point in a=
ddressing these lesser concerns if the main concern is outstanding</div><di=
v><br></div><div>I agree, it makes the most sense to discuss the above poin=
ts rather than getting into the weeds about more minor issues.=C2=A0</div><=
/div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">O=
n Thu, Jun 10, 2021 at 4:20 PM Russell O&#39;Connor &lt;<a href=3D"mailto:r=
oconnor@blockstream.com" target=3D"_blank">roconnor@blockstream.com</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"ltr"><div>As it stands today, in order to double spend a transaction du=
ring 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 tra=
nsaction, and then quickly broadcast a replacement transaction with a highe=
r fee to outbid your previous transaction.</div><div><br></div><div>However=
 with, pretty much any change to Bitcoin that leads to non-monotonic validi=
ty rules, that is any rule where transactions that are valid at one tip, ca=
n 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 adv=
antage of reorgs by always spending through an OP_BBV that is on the verge =
of becoming invalid.=C2=A0 Then you just have to sit back and wait for a su=
itable 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_BBV-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 mean=
ingful distinction between the active and passive roles in these two scenar=
ios.=C2=A0 I&#39;m not convinced.=C2=A0 I see a material difference between=
 needing to actively broadcast a replacement transaction and passively wait=
ing for your transaction to fall out of validity.=C2=A0 I also see a materi=
al difference between needing the transaction to be completely omitted from=
 the reorging chain versus just having the transaction fail a height qualif=
ication in the reorging chain.<br></div><div><br></div><div>(There are a fe=
w other lesser problems with an OP_BBV proposal, including the fact that Bi=
tcoin 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 proposa=
l defeats limits on transaction replacement because now instead of meeting =
minimum thresholds for fee bumping you can just let the previous transactio=
n expire and bump the fee by a fraction (though you are effectively rate li=
mited so maybe that is considered sufficiently mitigated?).=C2=A0 But there=
 is little point in addressing these lesser concerns if the main concern is=
 outstanding.)<br></div></div><br><div class=3D"gmail_quote"><div dir=3D"lt=
r" class=3D"gmail_attr">On Thu, Jun 10, 2021 at 6:20 PM Billy Tetrud &lt;<a=
 href=3D"mailto:billy.tetrud@gmail.com" target=3D"_blank">billy.tetrud@gmai=
l.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0px 0px 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, bu=
t neither he nor you really deeply explained the concern. Would you mind el=
aborating on a situation that calls=C2=A0for concern here? Some deeper expl=
anation 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 up in the BIP as well.=C2=A0<br></div><br><div class=3D"gmail_quot=
e"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, Jun 10, 2021 at 11:35 AM R=
ussell O&#39;Connor &lt;<a href=3D"mailto:roconnor@blockstream.com" target=
=3D"_blank">roconnor@blockstream.com</a>&gt; wrote:<br></div><blockquote cl=
ass=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>This is a continu=
ation of the thread at <a href=3D"https://lists.linuxfoundation.org/piperma=
il/bitcoin-dev/2021-April/018760.html" target=3D"_blank">https://lists.linu=
xfoundation.org/pipermail/bitcoin-dev/2021-April/018760.html</a> on this to=
pic.</div><div><br></div><div>I still remain unconvinced that we ought to g=
ive up on the &quot;reorg safety&quot; property that is explicitly part of =
Bitcoin&#39;s design.<br></div></div><br><div class=3D"gmail_quote"><div di=
r=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.or=
g" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</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">=
Hi Everyone,<div><br></div><div>I&#39;d like to open a discussion of an opc=
ode I call OP_BEFOREBLOCKVERIFY (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);font-family:verdana,sans-serif;font-size:13px">OP_BL=
OCKNUMBER)</span>. The opcode is very simple: the it takes as a parameter a=
 number representing a block height, and marks the transaction invalid if t=
he current block the transaction is being evaluated=C2=A0for is greater tha=
n 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-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 spe=
nd 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 bloc=
k a different person can spend. This can allow doing things like expiring p=
ayments or reversible payments in a cheaper way. Currently, things like tha=
t require a sequence of multiple transactions, however OP_BBV can do it in =
a single transaction, making these applications a lot more economically fea=
sible.=C2=A0</div><div><br></div><div>The particular application I&#39;m mo=
st interested in is more efficient wallet vaults. However, wallet vaults re=
quires other new opcodes, and I&#39;ve been given the (good, I think) advic=
e to start off this discussion with something a bit more bite sized and man=
ageable. So I want to keep this discussion to OP_BBV and steer away from th=
e specifics of the wallet vaults I&#39;m thinking of (which are more involv=
ed, 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 like =
to discuss is the historical avoidance of and stigma toward opcodes that ca=
n 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 opcode l=
ike 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. th=
at an opcode like this could cause &quot;bad&quot; reorg behavior, where in=
 a reorg, transactions that were spent become not spend and not spendable b=
ecause they were mined too near their expiry point.=C2=A0</div><div><br></d=
iv><div>While I don&#39;t want to claim anything about opcodes that can cau=
se 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 specif=
ically, 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 shoul=
d generally be waiting for 6 confirmations and software can warn the user t=
o wait for 6 confirmations in relevant scenarios where a 6-block reorg migh=
t 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/bbv/b=
ip-beforeblockverify.md#transaction-expiry" target=3D"_blank">Design Tradeo=
ffs and Risks</a>=C2=A0section of the document I wrote for OP_BBV. I&#39;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.=C2=A0</div><di=
v><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>
</blockquote></div>
</blockquote></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>

--000000000000254bd005c47b9635--