Re: [bitcoin-dev] [Mempool spam] Should we as developers reject non-standard Taproot transactions from full nodes?

From: Luke Dashjr <luke@dashjr•org>
To: Ali Sherief <ali@notatether•com>,
	Bitcoin Protocol Discussion
	<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] [Mempool spam] Should we as developers reject non-standard Taproot transactions from full nodes?
Date: Mon, 8 May 2023 18:37:34 -0400	[thread overview]
Message-ID: <0aea4ec5-7d6a-f358-3c20-854001588031@dashjr.org> (raw)
In-Reply-To: <Lm_5F74G9G21ydrFPovvmtHWpNXcbVzZibmU80oNqFRehJjcll89-t7OXqS5Fooe0cTNxGreIREMql3Li2xUCe2T5NVyss3-CrLzISO09HY=@notatether.com>

[-- Attachment #1: Type: text/plain, Size: 3128 bytes --]

Action should have been taken months ago. Spam filtration has been a 
standard part of Bitcoin Core since day 1. It's a mistake that the 
existing filters weren't extended to Taproot transactions. We can 
address that, or try a more narrow approach like OP_RETURN (ie, what 
"Ordisrespector" does). Since this is a bugfix, it doesn't really even 
need to wait for a major release.

(We already have pruning. It's not an alternative to spam filtering.)

Luke

On 5/7/23 13:22, Ali Sherief via bitcoin-dev 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/ 
> <https://www.coindesk.com/consensus-magazine/2023/05/05/pump-the-brcs-the-promise-and-peril-of-bitcoin-backed-tokens/?outputType=amp>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[-- Attachment #2: Type: text/html, Size: 5989 bytes --]