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

From: jk_14@op•pl
To: "bitcoin-dev@lists•linuxfoundation.org"
	<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] [Mempool spam] Should we as developers reject non-standard Taproot transactions from full nodes?
Date: Tue, 09 May 2023 10:41:13 +0200	[thread overview]
Message-ID: <183080646-e0c2bb9eaf62640f6c5d6c34f66db1d9@pmq7v.m5r2.onet> (raw)

Ok, I need to highlight one important thing well proven by this discussion (like it or not)...

Not the spam itself is the real reason of feeling: "something must be done"
The reason is: $30 fee per transaction (I hope you all agree)

Let me paraphrase some quotes used in this discussion, then:

1. Lack of block subsidy long term and necessity of $40 tx fee to compensate it - "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."

2. "the harmony of Bitcoin transactions is being disrupted right now" due to lack of block subsidy and due to exorbitant $40 tx fees as an effect necessary to keep the network security untouched

3. "Fee spikes aren't fun" and it's obvious that keeping the network security only on enormous tx fees of active users and having passive users as free-riders - isn't fun, too

4. by ignoring Bitcoin long-term security budget problem - "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 tremendous $40 tx fees can never happen again"

5. "Action against exorbitant fees should have been taken months ago. (...) It's a mistake that the" tail emission or other necessary solution - weren't implemented on time

6. "we need to find a solution for long-term horrible fees problem - that fits everyone's common ground."

Yes, we need - instead of being still in a heavy denial state.

No additional comment then, except this little one:
Delay of halving in case of 4 years long network difficulty regression situation.

Regards,
Jaroslaw

W dniu 2023-05-09 00:37:57 użytkownik Luke Dashjr via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> napisał:

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/

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists•linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev