Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 3045AC002A for ; Mon, 8 May 2023 12:58:43 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id F1825813D4 for ; Mon, 8 May 2023 12:58:42 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org F1825813D4 Authentication-Results: smtp1.osuosl.org; dkim=pass (2048-bit key) header.d=q32-com.20221208.gappssmtp.com header.i=@q32-com.20221208.gappssmtp.com header.a=rsa-sha256 header.s=20221208 header.b=3RAWdbtF X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iz9vdzb-SN_P for ; Mon, 8 May 2023 12:58:41 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org B009981303 Received: from mail-yb1-xb31.google.com (mail-yb1-xb31.google.com [IPv6:2607:f8b0:4864:20::b31]) by smtp1.osuosl.org (Postfix) with ESMTPS id B009981303 for ; Mon, 8 May 2023 12:58:41 +0000 (UTC) Received: by mail-yb1-xb31.google.com with SMTP id 3f1490d57ef6-ba21644874cso356027276.0 for ; Mon, 08 May 2023 05:58:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=q32-com.20221208.gappssmtp.com; s=20221208; t=1683550720; x=1686142720; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=GWqLmEGEcH63Z52ivN04bM+sZWbWYlLbp0DQScR3NFs=; b=3RAWdbtFw0cBNupQkX/YnATo2iz8+z+xE0XwgK1E/0FZ71ua2+nagfhvIj3k/FtyoC a7FfJ//rlbExZGSQM8xnvR+CEZf6471T4U2du3Hh0t2qy7GY6obwddOS2fn48IYR7Yhj 1FHcH8XkD5x6D9EA3SnXSsQJ6UkKDuGTJpxG7FKlVmHDYCEE4SysSi7RaWaugJifCB9i aWyefE46jVmqYQliidoqkys0JeZIuZMMawAkrT0n2aEbu9Vz/mX8T9TAs+nmB/7NrizX aKWLtahZNJDknpOjiixOed0O/Tc+16tV5VZI2mNGnSBA+0nXN0Kfl2UTRrmnw9BVkoHT tiyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683550720; x=1686142720; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=GWqLmEGEcH63Z52ivN04bM+sZWbWYlLbp0DQScR3NFs=; b=iD8FJo9DtSmlOXCOWAf/rky7TT8nAy6acCmYepSknuJxqUS4RTUuV662a8AH53mHLO 9sdqLcWhiePA2jg9YaxxfvRyVXjzxIN/5JL8w30AnJK2+BH8SXXykz2P9+GFTRQcyJO/ +h7+jAQPPDaNgghe3Lt+Kgp8Bu2RQia954/MTD/BWv3joQCpbxqH3oUmyrB+LGZJsVjZ EvJ5bPUam6EHnv9XzcU/84zLUgwmrAYJpuL4BpBh8mGB4VXW74Z1PIWJ9HgPgVjjeyE/ H3vFt+Fnkda75lsUg66fbFcQZJHlSVYjJQTYWlnWG9/BaNmTjRned7b2nZ/7OSaPRLhV f//Q== X-Gm-Message-State: AC+VfDyC9W3664xXUPHY1dtBuIl4eAjoOrxJYWIVN3i1+J/lwKPxQZI5 4fNdWvbt7jeJyZ7+aYJjGpM+9ArzFzXlmIddFnmZn9k= X-Google-Smtp-Source: ACHHUZ6cYr9neYGfrMSw0CCWXaLfEcXx0zu1K1V0UFLhmYq6JwxW4CPk9dbMKnqNMXC0R1QBC9D6Z4jbllJkpmKKvHc= X-Received: by 2002:a25:6841:0:b0:b9e:78fa:8f4e with SMTP id d62-20020a256841000000b00b9e78fa8f4emr11226991ybc.4.1683550720136; Mon, 08 May 2023 05:58:40 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Erik Aronesty Date: Mon, 8 May 2023 08:58:28 -0400 Message-ID: To: Ali Sherief , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="000000000000a29aaf05fb2e3259" X-Mailman-Approved-At: Mon, 08 May 2023 16:07:09 +0000 Subject: Re: [bitcoin-dev] [Mempool spam] Should we as developers reject non-standard Taproot transactions from full nodes? 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: Mon, 08 May 2023 12:58:43 -0000 --000000000000a29aaf05fb2e3259 Content-Type: text/plain; charset="UTF-8" probably easier just to reject any transaction where the fee is higher than the sum of the outputs On Mon, May 8, 2023, 7:55 AM Ali Sherief via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Hi guys, > > I think everyone on this list knows what has happened to the Bitcoin > mempool during the past 96 hours. Due to side projects such as BRC-20 > having such a high volume, real bitcoin transactions are being priced out > and that is what is causing the massive congestion that has arguable not > been seen since December 2017. I do not count the March 2021 congestion > because that was only with 1-5sat/vbyte. > > Such justifiably worthless ("worthless" is not even my word - that's how > its creator described them[1]) tokens threaten the smooth and normal use of > the Bitcoin network as a peer-to-pear digital currency, as it was intended > to be used as. > > If the volume does not die down over the next few weeks, should we take an > action? The bitcoin network is a triumvirate of developers, miners, and > users. Considering that miners are largely the entities at fault for > allowing the system to be abused like this, the harmony of Bitcoin > transactions is being disrupted right now. Although this community has a > strong history of not putting its fingers into pies unless absolutely > necessary - an example being during the block size wars and Segwit - should > similar action be taken now, in the form of i) BIPs and/or ii) commits into > the Bitcoin Core codebase, to curtail the loophole in BIP 342 (which > defines the validation rules for Taproot scripts) which has allowed these > unintended consequences? > > An alternative would be to enforce this "censorship" at the node level and > introduce a run-time option to instantly prune all non-standard Taproot > transactions. This will be easier to implement, but won't hit the road > until minimum next release. > > I know that some people will have their criticisms about this, > absolutists/libertarians/maximum-freedom advocates, which is fine, but we > need to find a solution for this that fits everyone's common ground. We > indirectly allowed this to happen, which previously wasn't possible before. > So we also have a responsibility to do something to ensure that this kind > of congestion can never happen again using Taproot. > > -Ali > > --- > > [1]: > https://www.coindesk.com/consensus-magazine/2023/05/05/pump-the-brcs-the-promise-and-peril-of-bitcoin-backed-tokens/ > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --000000000000a29aaf05fb2e3259 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
probably easier just to reject any transaction where the = fee is higher than the sum of the outputs



On Mon, May 8, 2023, 7:55 AM Ali Sherief via bitcoin-= dev <bitcoin-de= v@lists.linuxfoundation.org> wrote:
Hi guys,=

=
I think everyone= on this list knows what has happened to the Bitcoin mempool during the pas= t 96 hours. Due to side projects such as BRC-20 having such a high volume, = real bitcoin transactions are being priced out and that is what is causing = the massive congestion that has arguable not been seen since December 2017.= I do not count the March 2021 congestion because that was only with 1-5sat= /vbyte.
Such just= ifiably worthless ("worthless" is not even my word - that's h= ow its creator described them[1]) tokens threaten the smooth and normal use= of the Bitcoin network as a peer-to-pear digital currency, as it was inten= ded to be used as.

If the volume does not die down over the next few weeks, should we take a= n action? The bitcoin network is a triumvirate of developers, miners, and u= sers. Considering that miners are largely the entities at fault for allowin= g the system to be abused like this, the harmony of Bitcoin transactions is= being disrupted right now. Although this community has a strong history of= not putting its fingers into pies unless absolutely necessary - an example= being during the block size wars and Segwit - should similar action be tak= en now, in the form of i) BIPs and/or ii) commits into the Bitcoin Core cod= ebase, to curtail the loophole in BIP 342 (which defines the validation rul= es for Taproot scripts) which has allowed these unintended consequences?

An alternative woul= d be to enforce this "censorship" at the node level and introduce= a run-time option to instantly prune all non-standard Taproot transactions= . This will be easier to implement, but won't hit the road until minimu= m next release.

I= know that some people will have their criticisms about this, absolutists/l= ibertarians/maximum-freedom advocates, which is fine, but we need to find a= solution for this that fits everyone's common ground. We indirectly al= lowed this to happen, which previously wasn't possible before. So we al= so have a responsibility to do something to ensure that this kind of conges= tion can never happen again using Taproot.

-Ali

---

=20
=20
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundati= on.org/mailman/listinfo/bitcoin-dev
--000000000000a29aaf05fb2e3259--