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

Mon May 8 22:37:34 UTC 2023

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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230508/6fa702e3/attachment.html>