Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 9D0CCC000B for ; Sat, 12 Jun 2021 07:59:36 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 7EF00605E7 for ; Sat, 12 Jun 2021 07:59:36 +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: smtp3.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A42slBr7n9cs for ; Sat, 12 Jun 2021 07:59:35 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com [IPv6:2a00:1450:4864:20::62c]) by smtp3.osuosl.org (Postfix) with ESMTPS id 17BAF605D2 for ; Sat, 12 Jun 2021 07:59:34 +0000 (UTC) Received: by mail-ej1-x62c.google.com with SMTP id my49so7995178ejc.7 for ; Sat, 12 Jun 2021 00:59:34 -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=Y/wdNDx4zv/TNNkW38tRuBTVHMsY+sxJjEZqTq21DzI=; b=Ial4t0KtLS9O3UZg+3yRSeFI7Htxa3X4EO107W/JAo5mccqfzzZVCrbdyAZBrkVpFC 2kuTjunwpN+e8Z1PxmGCqOE6V/Bf9BKbTI5IDLkG3oG1CL3boaLbdN7Mav8bXq3wmfmK d6ovDyTs01wDJvl94WNjdUbP0SJfqos61raS+9OV/BHyKR5Oat8ROBeCc7Vw5BparYOz nC2nu8jJ3tPHHpWDLq126F4/6usMHhu02cOhEKL2hl93BiYEJ3X2vaDSDQfdectt/pQX Guz4dq9mfdZdpg4EWLa1E+c36KewL+hCtIAYLDyUyZlFyPBjh6pve788HDntzasW59Qq zekw== 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=Y/wdNDx4zv/TNNkW38tRuBTVHMsY+sxJjEZqTq21DzI=; b=ISdzr+XH5Zf1YIkxt20tOfP1YCUuzkIe8V1B4gFMRlzcdlNC80v5p0iKjEFHvolef2 VQEVyIEK2OoJK39aLQ+BFsvyMExJcZTeDJ+CZ3kgLW9K4eFPQFXmmhytsz4BFBIG9dIS pehNGG0P7Flr7KFKaHeicxoQtqLGWF85qPTd6b2C5zOmDxBkeN2r9dBwZ22ufX/mbtIz NpsrLtyzOe0ZsmaZwQGI6IV99Osh4BtD2s0VAqp1y0pVVzj6yYQZQshK0nmv/mkqGo07 P0byp6Ll1/46Y1XSBYtJvBlEhaVRz15e/FJQsnBSakZXa9qLVA8em4AEWe3zrj32d4iD 4RBw== X-Gm-Message-State: AOAM5308ea2TTauvmDxSnkVI2H6XEG4mx3hjZ7A4BA6mgXw4YhrKPUxG JIY7+neu3jsxWY8XQqp15ibUCiyBMNaYYgjr9uE= X-Google-Smtp-Source: ABdhPJzy3LwAFNfxdf109H9RZzEfhTiZcEBv4PC2amJSSE5GDhhzTMdkSMnbeMGDtLLzUvG7+X/b8MfxabBcr7hrs3k= X-Received: by 2002:a17:906:1e15:: with SMTP id g21mr6949357ejj.241.1623484773079; Sat, 12 Jun 2021 00:59:33 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Billy Tetrud Date: Sat, 12 Jun 2021 00:59:16 -0700 Message-ID: To: "Russell O'Connor" , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="000000000000329d7805c48d01bf" X-Mailman-Approved-At: Sat, 12 Jun 2021 08:23:15 +0000 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jun 2021 07:59:36 -0000 --000000000000329d7805c48d01bf Content-Type: text/plain; charset="UTF-8" > 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 ). 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). > 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? On Fri, Jun 11, 2021 at 4:44 AM Russell O'Connor via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > > On Fri, Jun 11, 2021 at 7:12 AM James MacWhyte 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. > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --000000000000329d7805c48d01bf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
>=C2=A0 taproot=C2=A0annex

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 i= s 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 Evaluatio= n section). 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).

>= ; this=C2=A0auto-double-spend wallet would send every payment with a= n=C2=A0annex=C2=A0value that limits the payment to being valid= only up to the next block

One possible solution t= o that would be to require that the input to OP_BBV to be in the script its= elf and not originate from the witness.=C2=A0

Rega= rdless, I think the ideal solution is to not have any of these such rules i= f we can simply change the definition for what counts as finalization to ac= count for the fact that BBV transactions mined close to their expiration. I= s there a reason this finalization-redefinition is not an adequate solution= ?

On Fri, Jun 11, 2021 at 4:44 AM Russell O'Connor via bitcoin-dev= <bitcoin-dev@lists.linuxfoundation.org> wrote:


On Fri, Jun 11, 2021 at 7:12 AM James MacWhyte <macwhyte@gmail.com> wrote:
<= /div>
@Bi= lly I like the idea. It is very obvious how useful an opcode like this woul= d be! (My background is in wallet implementation)

@Russe= ll I do understand your concerns of monotonism, however I'm having a ha= rd time really coming up with an attack vector. You said "one can desi= gn a wallet to passively take advantage of reorgs by always spending throug= h 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 us= ing 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=C2=A0happens. Doe= s this mean the theoretical double-spend wallet you are proposing would hav= e to send two transactions every time you make a single payment, doubling t= he transaction fees and adding more uncertainty around when the second tran= saction would get confirmed?

Assuming the proposal is rewritten to place the maxheight into the taproo= t 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 resign it with t= he annex incremented to the next block, and repeat.
=C2=A0
= In a normal double spend scenario, there is no cost to a failed attempt, bu= t much to gain from a success. With your design, there is a real cost to ev= ery single attempt (transaction fees) and no evidence that the rate of succ= ess 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 wi= th 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 rel= ay rules forced a minimum OP_BBV value in order to protect against reorg do= uble spends.

The inclusion of a= tx with 0 transaction fee in a block is not in of itself an abuse.=C2=A0 T= here is nothing wrong with blocks containing such transactions.=C2=A0 The *= relay* of 0 transaction fee transactions is what is an abuse because it all= ows one to usurp Bitcoin's gossip network for their own arbitrary commu= nications platform without cost.=C2=A0 Most Bitcoin users aren't signin= g 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 limitation on abuse= .
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--000000000000329d7805c48d01bf--