Luke Dashjr [ARCHIVE] on Nostr: 📅 Original date posted:2023-05-08 🗒️ Summary of this message: Bitcoin Core ...
📅 Original date posted:2023-05-08
🗒️ Summary of this message: Bitcoin Core should have extended spam filters to Taproot transactions. A bugfix can address this issue, and censorship at the node level is an alternative.
📝 Original message: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>;
🗒️ Summary of this message: Bitcoin Core should have extended spam filters to Taproot transactions. A bugfix can address this issue, and censorship at the node level is an alternative.
📝 Original message: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>;