diff options
| author | Russell O'Connor <roconnor@blockstream.com> | 2021-06-11 07:43:22 -0400 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2021-06-11 11:43:38 +0000 |
| commit | 02588b0d515edbd0fc6ab2fd021bd67008083752 (patch) | |
| tree | 2b8c68141590cdedc236fbd117dbc56204364a1b | |
| parent | 48d5fafc1603749b7fd9658311af2b8b40aff639 (diff) | |
| download | pi-bitcoindev-02588b0d515edbd0fc6ab2fd021bd67008083752.tar.gz pi-bitcoindev-02588b0d515edbd0fc6ab2fd021bd67008083752.zip | |
Re: [bitcoin-dev] OP_BEFOREBLOCKVERIFY - discussing and opcode that invalidates a spend path after a certain block
| -rw-r--r-- | ab/40ed26046b054301c4c6be67f8d71f0f406331 | 198 |
1 files changed, 198 insertions, 0 deletions
diff --git a/ab/40ed26046b054301c4c6be67f8d71f0f406331 b/ab/40ed26046b054301c4c6be67f8d71f0f406331 new file mode 100644 index 000000000..43d5beb89 --- /dev/null +++ b/ab/40ed26046b054301c4c6be67f8d71f0f406331 @@ -0,0 +1,198 @@ +Return-Path: <roconnor@blockstream.com> +Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133]) + by lists.linuxfoundation.org (Postfix) with ESMTP id 3529EC000B + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 11 Jun 2021 11:43:38 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by smtp2.osuosl.org (Postfix) with ESMTP id 2427E40107 + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 11 Jun 2021 11:43:38 +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: smtp2.osuosl.org (amavisd-new); + dkim=pass (2048-bit key) + header.d=blockstream-com.20150623.gappssmtp.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 Z_OQfZCr-fmE + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 11 Jun 2021 11:43:35 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.8.0 +Received: from mail-qv1-xf2d.google.com (mail-qv1-xf2d.google.com + [IPv6:2607:f8b0:4864:20::f2d]) + by smtp2.osuosl.org (Postfix) with ESMTPS id 12CF7400C2 + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 11 Jun 2021 11:43:34 +0000 (UTC) +Received: by mail-qv1-xf2d.google.com with SMTP id 5so6049801qvf.1 + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 11 Jun 2021 04:43:34 -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=w5SAoq7hOKJmu1lY5F0OIV8PX2svfC9NfAsS8UkzKK4=; + b=grwS/XmiU5/JxPCSWygOr1dJGq/ebx2nycxFpUnHKMCT6amEjUxt1VvgA3VY2Z/h06 + 9rf8UVL3rtchudANryZFAI06kkKSdsGo9auuzC5heRRRSwXtYRAMHRkVwpRsJLnwszQK + HeISr05m8jSRLZDhIUIPEC8k/cTAsmIDwlgJ8olUBLsxEvgchorxPXD2Pn0rOqPq3PX3 + SmWec0UCq1tCmX2g/G0ox7RAP5RaHGciKsIb7dmwyo0IPvm30FzG6ho6CjGgjGfK8AKc + KXapvwqDk2/WI1skRerNZ+JOkPbPIum+x0U67EGv8osMAHvEj6ttYooKiNt3nf3kyqpY + TZAg== +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=w5SAoq7hOKJmu1lY5F0OIV8PX2svfC9NfAsS8UkzKK4=; + b=gGEBuvOawlU2C4AFSisJ35j2Z5wl2M/rmLJmTR9VpDRz8Mzspa3jRMv9KGMQ3GXQ3Q + j6yjaP+eW/iLIflI8uqLX+bNZ07VLveLjrpld84VpXVJ4fBWEZWeGCSe6RC1m4pMlfQW + uCwgAtWNCOX8MM9J6KBmDOb1aAfojefDyan35V2LNtjzTR5tOkZo4GkAU5tXgz3ykTXi + Nh7Jok0Uxgm498IVTQhYXFB9/VkeXFTrL2IHxI8E05G+J5nNxH7L6/czpLWbYSeJNAYZ + WC6eLLVH0yQc2AmXWuMBKU7fMyhtsZxMAimwrdU29eKMOuu6zf6dZ9TckaNb7OBCGu3X + WoLQ== +X-Gm-Message-State: AOAM530pnhXEgJv7bd6V0fOOhtzSy6GtMJRBps/yoVpJVGfV4BXDpz8R + LJIrC2kGgIv/cWE8oiG7jDaqBT1E3bg5HZjrfhmAxg== +X-Google-Smtp-Source: ABdhPJzwFKXvIDVa9ThbXeQNNBfVCtLTIqhOyk4C4vfcVNg20tmpbMaux/YYX7gohwwQj8y2yVoieSgtEX/wjCxKjEU= +X-Received: by 2002:a0c:ee8a:: with SMTP id u10mr4302299qvr.13.1623411813716; + Fri, 11 Jun 2021 04:43:33 -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> +In-Reply-To: <CAH+Axy7b8MS92ZeMnPx-TosvNzRv9=34UDQ9ia-fxeLzO_A0+Q@mail.gmail.com> +From: "Russell O'Connor" <roconnor@blockstream.com> +Date: Fri, 11 Jun 2021 07:43:22 -0400 +Message-ID: <CAMZUoKmytZm5boBKSYbrJdNa0LduxtTyUUheq=tjD1J_GO0TjA@mail.gmail.com> +To: James MacWhyte <macwhyte@gmail.com> +Content-Type: multipart/alternative; boundary="0000000000007b2b5c05c47c04ee" +Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>, + Billy Tetrud <billy.tetrud@gmail.com> +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:43:38 -0000 + +--0000000000007b2b5c05c47c04ee +Content-Type: text/plain; charset="UTF-8" + +On Fri, Jun 11, 2021 at 7:12 AM James MacWhyte <macwhyte@gmail.com> wrote: + +> @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? +> + +Assuming the proposal is rewritten to place the maxheight into the taproot +annex in order to address the issue with caching of script validity, then +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. If the +payment doesn't make it into the next block, then resign it with the annex +incremented to the next block, and repeat. + + +> 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. +> + +The inclusion of a tx with 0 transaction fee in a block is not in of itself +an abuse. There is nothing wrong with blocks containing such +transactions. The *relay* of 0 transaction fee transactions is what is an +abuse because it allows one to usurp Bitcoin's gossip network for their own +arbitrary communications platform without cost. Most Bitcoin users aren't +signing up for being a usenet provider. So, by policy, nodes require a +cost to relay transactions so that broadcasting isn't free. Even when that +price is paid to someone else, it still is an effective limitation on abuse. + +--0000000000007b2b5c05c47c04ee +Content-Type: text/html; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">= +<div dir=3D"ltr" class=3D"gmail_attr">On Fri, Jun 11, 2021 at 7:12 AM James= + MacWhyte <<a href=3D"mailto:macwhyte@gmail.com">macwhyte@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">@Billy I like the idea. It is very obvious how useful an opcode= + like this would be! (My background is in wallet implementation)<div><br></= +div><div>@Russell I do understand your concerns of monotonism, however I= +9;m having a hard time really coming up with an attack vector. You said &qu= +ot;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 immedia= +tely spend that output in a new payment to someone else and hope a reorg=C2= +=A0happens. Does this mean the theoretical double-spend wallet you are prop= +osing would have to send two transactions every time you make a single paym= +ent, doubling the transaction fees and adding more uncertainty around when = +the second transaction would get confirmed?<br></div></div></blockquote><di= +v><br></div><div>Assuming the proposal is rewritten to place the maxheight = +into the taproot annex in order to address the issue with caching of script= + validity, then 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.=C2=A0 If the payment doesn't make it into the next block, then r= +esign it with the annex incremented to the next block, and repeat.<br></div= +><div>=C2=A0</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 di= +r=3D"ltr"><div>In a normal double spend scenario, there is no cost to a fai= +led 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 t= +he 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 ne= +w system would actually be less attractive to double spenders than the curr= +ent model!</div><div><br></div><div>I also agree with Billy's idea for = +relay rules. We already have abusable chain rules (e.g. a tx can be include= +d in a block with 0 transaction fee [spam?]) but we add protection with rel= +ay 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 confirmat= +ion and the relay rules forced a minimum OP_BBV value in order to protect a= +gainst reorg double spends.</div></div></blockquote><div><br></div><div>The= + inclusion of a tx with 0 transaction fee in a block is not in of itself an= + abuse.=C2=A0 There is nothing wrong with blocks containing such transactio= +ns.=C2=A0 The *relay* of 0 transaction fee transactions is what is an abuse= + because it allows one to usurp Bitcoin's gossip network for their own = +arbitrary communications platform without cost.=C2=A0 Most Bitcoin users ar= +en't signing up for being a usenet provider.=C2=A0 So, by policy, nodes= + require a cost to relay transactions so that broadcasting isn't free. = +Even when that price is paid to someone else, it still is an effective limi= +tation on abuse.<br></div></div></div> + +--0000000000007b2b5c05c47c04ee-- + |