From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id CFEB6C002A for ; Mon, 8 May 2023 16:37:25 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id AF89341DF4 for ; Mon, 8 May 2023 16:37:25 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org AF89341DF4 Authentication-Results: smtp4.osuosl.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20221208 header.b=SoVCckGo 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 Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id scusgjQ0kQSm for ; Mon, 8 May 2023 16:37:24 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org E1BDF41DAE Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) by smtp4.osuosl.org (Postfix) with ESMTPS id E1BDF41DAE for ; Mon, 8 May 2023 16:37:23 +0000 (UTC) Received: by mail-lf1-x131.google.com with SMTP id 2adb3069b0e04-4f13ef4ad91so5477229e87.3 for ; Mon, 08 May 2023 09:37:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1683563842; x=1686155842; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=HNRRZsVujut1Y4fwcraNRjbR8M/90zIYBeyDOlvqv2w=; b=SoVCckGoLfIcmSPpLmLKJrlroj5ZvBwDVbR8ZHYb9k6wJ+AF36cHDtD6DB26qKigWQ Kw4zkdkYOyRYEU5y+l6z7CFk/oow1jNrvWfu0jmit/g8dC5vZYtcZVRvfEsfPjQBZQwz aLqXnMkEMjYDW65iiiar/m5GF91KtcWCtbqUJ9K92Da0oaRrGM6dcaV7uRq4kD1HXpqb 9upYKrg1gtcSXYemCxzi/O1Sb64eQFtvN3UIFumgraL1/gzfLhhxnJpJwXmYTkITPrKV Grtd7xgohaj+7rvNk69ufxLRQEpuQnaMZOkXSDXE+l56R21k9tNEcZBqSoOxAtVV/vrb PRvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683563842; x=1686155842; 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=HNRRZsVujut1Y4fwcraNRjbR8M/90zIYBeyDOlvqv2w=; b=hQCSwrlI7kkH1hHPAFbTfshJ0OJKHvGT0LKKqyNI81Lv4+iG9fYukalegxY8OqpGXP OeePY6ElA5zgsVbLotmV5JzW7Wbuqjy+zpw5e/5YJztl70MpyUVHzZlv3GlhZCN7HsZF pWIPz50NH4oazrCmpzHH3FpLm3RpWHUxcpCJt3iKytVnkw8BampQKK3Ss+FrPUvgA+qD 4MqDaqYA7ZFbK5ByXOijXGFExtQxurAw3Jgti6w9UOwgFh8oqX9rVas/fJ3CYapXLgqF Cq9wAmSeJSKY3tP9sSFOmFRSzGYejdZfFkPsNAcyerbbFlJiN3zDsiOQ3J+10FWBt7qL XL2Q== X-Gm-Message-State: AC+VfDyWpQqLgqEbEL4fGvCPipWm2xXHQZVz4V0kZ52JptnlqPssToNV 5bMgxdgzSgHbKVJqr6ypuc5rnRaq1Ij9ZsJpSwt4fLW8Sp0= X-Google-Smtp-Source: ACHHUZ4Yz0EctevjEdxAJydpCAtWb+EfDpw3dSMvHpwf/44KbkeGQKHyT7h08MKLVgD82UnMkoRdqfyNdMVX+hs1aF0= X-Received: by 2002:ac2:519c:0:b0:4ef:ec94:9674 with SMTP id u28-20020ac2519c000000b004efec949674mr2553527lfi.32.1683563841246; Mon, 08 May 2023 09:37:21 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Melvin Carvalho Date: Mon, 8 May 2023 18:37:07 +0200 Message-ID: To: Ali Sherief , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="000000000000b6df6b05fb314053" X-Mailman-Approved-At: Tue, 09 May 2023 13:33:24 +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 16:37:25 -0000 --000000000000b6df6b05fb314053 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable po 8. 5. 2023 v 13:55 odes=C3=ADlatel Ali Sherief via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> napsal: > 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 intende= d > 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 > 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 - shou= ld > similar action be taken now, in the form of i) BIPs and/or ii) commits in= to > 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 an= d > 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 befor= e. > So we also have a responsibility to do something to ensure that this kind > of congestion can never happen again using Taproot. > This is a nuanced and sensitive topic that has been discussed previously, as far back as 2010, in a conversation between Gavin and Satoshi: https://bitcointalk.org/index.php?topic=3D195.msg1617#msg1617 Gavin: That's a cool feature until it gets popular and somebody decides it would be fun to flood the payment network with millions of transactions to transfer the latest Lady Gaga video to all their friends... Satoshi: That's one of the reasons for transaction fees. There are other things we can do if necessary. High fees could be viewed as disruptive to the network, but less disruptive than regular large reorgs, or a network split. It might be beneficial to brainstorm the "other things we can do if necessary". A simple observation is that increasing the block size could make it more challenging to spam, though it may come at the expense of some decentralization. > -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 > --000000000000b6df6b05fb314053 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
po 8. 5. 2023 v=C2=A013:55 odes=C3=AD= latel Ali Sherief via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> napsal:
Hi guys,

I think everyone on this list knows what = has happened to the Bitcoin mempool during the past 96 hours. Due to side p= rojects 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 th= at 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 (&quo= t;worthless" is not even my word - that's how its creator describe= d 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 no= t die down over the next few weeks, should we take an action? The bitcoin n= etwork is a triumvirate of developers, miners, and users. Considering that = miners are largely the entities at fault for allowing the system to be abus= ed like this, the harmony of Bitcoin transactions is being disrupted right = now. Although this community has a strong history of not putting its finger= s 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 l= oophole in BIP 342 (which defines the validation rules for Taproot scripts)= which has allowed these unintended consequences?

An alternative would be to enforce this &q= uot;censorship" at the node level and introduce a run-time option to i= nstantly prune all non-standard Taproot transactions. This will be easier t= o 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-fre= edom 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, w= hich previously wasn't possible before. So we also have a responsibilit= y to do something to ensure that this kind of congestion can never happen a= gain using Taproot.

This is a nuanced and sensitive topic that has been discussed=20 previously, as far back as 2010, in a conversation between Gavin and=20 Satoshi:

https://bitcointalk.org/index.php?topic=3D195.msg1617#msg1617

Gavin: That's a cool feature until it= gets popular and somebody decides it would be fun to flood the payment net= work with millions of transactions to transfer the latest Lady Gaga video t= o all their friends...
Satoshi: That's one of the reasons for transa= ction fees.=C2=A0 There are other things we can do if necessary.

High fees could be viewed as disruptive to t= he network, but less disruptive than regular large reorgs, or a network spl= it.

It might be beneficial to brainstorm the "other things we can = do if necessary".

A sim= ple observation is that increasing the block size could make it=20 more challenging to spam, though it may come at the expense of some=20 decentralization.


-Ali

---
=
=20
=20
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--000000000000b6df6b05fb314053--