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

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

[Ali Sherief]

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

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)

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

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

[Michael Folkson]

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

Hi Ali

I'd point you to Andrew Poelstra's post from January 2023 [0] and a Bitcoin StackExchange answer I recently posted [1].

> 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.

Miners are as far as I understand including high fee rate, consensus compatible transactions in mined blocks as the system has been set up for them to do. As I say in that StackExchange answer if you don't like it:

"There are theoretically two options: a consensus change or a policy change. A consensus change disallowing a certain kind of transaction that is acceptable under current consensus rules would need a soft fork and hence would be extremely difficult to pull off assuming that it was a considered a good idea by the broader community. Embedding arbitrary data in transactions would still be possible after this hypothetical soft fork and so its effectiveness would be limited. A default policy change (or custom policy option) would attempt to prevent a certain kind of transaction from propagating across the network without needing a consensus change. However, it would still be possible to submit these kinds of consensus compatible transactions directly to miners bypassing the P2P network."

> 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.

It isn't a philosophy or ideology consideration, it is a purely technical one. Congestion can happen using Taproot addresses or pre-Taproot addresses. There is fixed, limited block space and variable demand for that block space. You may not like how that block space is being used but if transactions are consensus compatible and paying fees at the market rate the system is working how it should.

> to curtail the loophole in BIP 342 (which defines the validation rules for Taproot scripts) which has allowed these unintended consequences?

There were technical reasons for the design decisions in BIP 342. As Andrew says in his post [0]:

"If we ban "useless data" then it would be easy for would-be data storers
to instead embed their data inside "useful" data such as dummy
signatures or public keys. Doing so would incur a ~2x cost to them, but
if 2x is enough to disincentivize storage, then there's no need to have
this discussion because they will will be forced to stop due to fee
market competition anyway. (And if not, it means there is little demand
for Bitcoin blockspace, so what's the problem with paying miners to fill
it with data that validators don't even need to perform real computation
on?).

But if we were to ban "useful" data, for example, saying that a witness
can't have more than 20 signatures in it, then we are into the same
problem we had pre-Taproot: that it is effectively impossible construct
signing policies in a general and composeable way, because any software
that does so will need to account for multiple independent limits. We
deliberately replaced such limits with "you need to pay 50 weight for
each signature" to makes this sort of analysis tractable."

I personally get the desire to "do something". Fee spikes aren't fun especially for some Lightning use cases and many of us don't like how people are using the limited block space currently. But a game of whack-a-mole with blunt tools such as policy rules and especially consensus rules is ineffective at best and harmful at worst. You may not like this use case but assuming you embark on a game of whack-a-mole what's to stop a group of people popping up in a year declaring their opposition to your use case and trying to prevent your use case? Consensus rules are set and the rest is left to the market.

Thanks

Michael

[0]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-January/021372.html
[1]: https://bitcoin.stackexchange.com/questions/118197/ddos-attack-via-brc-20-ordinals-on-bitcoin

--
Michael Folkson
Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F

Learn about Bitcoin: https://www.youtube.com/@portofbitcoin

------- Original Message -------
On Sunday, May 7th, 2023 at 18:22, Ali Sherief via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> 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)

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

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

[Erik Aronesty]

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

probably easier just to reject any transaction where the fee is higher than
the sum of the outputs



On Mon, May 8, 2023, 7:55 AM Ali Sherief via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> 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: 4615 bytes --]

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

[Melvin Carvalho]

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

po 8. 5. 2023 v 13:55 odesí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 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.
>

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=195.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/
> <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: 5942 bytes --]

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

[Michael Folkson]

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

> probably easier just to reject any transaction where the fee is higher than the sum of the outputs

And prevent perfectly reasonable transfers of value and attempted Lightning channel closes during fee spikes? If I want​ to close my Lightning channel during a protracted fee spike where I have to pay an onchain transaction fee greater than the amount I am receiving you want to stop me doing that? You are impinging on a valid use case as well as requiring a consensus rule change.

--
Michael Folkson
Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F

Learn about Bitcoin: https://www.youtube.com/@portofbitcoin

------- Original Message -------
On Monday, May 8th, 2023 at 13:58, Erik Aronesty via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:

> probably easier just to reject any transaction where the fee is higher than the sum of the outputs
>
> On Mon, May 8, 2023, 7:55 AM Ali Sherief via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> 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: 9811 bytes --]

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

[Ali Sherief]

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

I think one of the bigger problems facing the broader Bitcoin ecosystem is the lack of Lightning wallets for desktop. Mobile wallets are not really an issue, but as far as I know for desktop builds, there's really only Electrum, and Zap Wallet which support Lightning.

The alternative is interacting with the LN node directly, which probably won't be so bad, but it would be better if they carried GUI wallets like BItcoin Core does. Because windows and buttons help with mass adoption of pretty much everything.

I may even consider developing a Lighting wallet given the circumstances.

-Ali

On Mon, May 8, 2023 at 8:13 PM, Michael Folkson <michaelfolkson@protonmail.com> wrote:

>> probably easier just to reject any transaction where the fee is higher than the sum of the outputs
>
> And prevent perfectly reasonable transfers of value and attempted Lightning channel closes during fee spikes? If I want​ to close my Lightning channel during a protracted fee spike where I have to pay an onchain transaction fee greater than the amount I am receiving you want to stop me doing that? You are impinging on a valid use case as well as requiring a consensus rule change.
>
> --
> Michael Folkson
> Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
> GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F
>
> Learn about Bitcoin: https://www.youtube.com/@portofbitcoin
>
> ------- Original Message -------
> On Monday, May 8th, 2023 at 13:58, Erik Aronesty via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> probably easier just to reject any transaction where the fee is higher than the sum of the outputs
>>
>> On Mon, May 8, 2023, 7:55 AM Ali Sherief via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> 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: 10679 bytes --]

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

[Erik Aronesty]

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

im unclear as to the purpose paying an onchain transaction fee greater than
the amount receiving could possibly serve.

what benefit do you get aside from losing bitcoin?

are there any, non-theoretical, benefits to facilitating dust transactions?

we could, of course, have it be non-consensus (no route dust) to start with





On Mon, May 8, 2023 at 1:13 PM Michael Folkson <
michaelfolkson@protonmail.com> wrote:

> > probably easier just to reject any transaction where the fee is higher
> than the sum of the outputs
>
> And prevent perfectly reasonable transfers of value and attempted
> Lightning channel closes during fee spikes? If I *want*​ to close my
> Lightning channel during a protracted fee spike where I have to pay an
> onchain transaction fee greater than the amount I am receiving you want to
> stop me doing that? You are impinging on a valid use case as well as
> requiring a consensus rule change.
>
> --
> Michael Folkson
> Email: michaelfolkson at protonmail.com
> GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F
>
> Learn about Bitcoin: https://www.youtube.com/@portofbitcoin
>
> ------- Original Message -------
> On Monday, May 8th, 2023 at 13:58, Erik Aronesty via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> probably easier just to reject any transaction where the fee is higher
> than the sum of the outputs
>
>
>
> On Mon, May 8, 2023, 7:55 AM Ali Sherief via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> 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: 11038 bytes --]

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

[Michael Folkson]

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

> im unclear as to the purposepaying an onchain transaction fee greater than the amount receiving could possibly serve.

If you expect fees to continue to rise and be sustained at abnormally high levels for a long period of time you might seek to close your Lightning channel(s) and move whatever value you can from these Lightning channel(s) onchain even if it means paying a higher fee than the amount you are receiving.

I don't necessarily recommend doing this (it would depend on a number of factors, both personal and external) but there is no reason to prevent someone in say the consensus rules from doing this if they wish.

--
Michael Folkson
Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F

Learn about Bitcoin: https://www.youtube.com/@portofbitcoin

------- Original Message -------
On Monday, May 8th, 2023 at 20:47, Erik Aronesty <erik@q32.com> wrote:

> im unclear as to the purpose paying an onchain transaction fee greater than the amount receiving could possibly serve.
>
> what benefit do you get aside from losing bitcoin?
>
> are there any, non-theoretical, benefits to facilitating dust transactions?
>
> we could, of course, have it be non-consensus (no route dust) to start with
>
> On Mon, May 8, 2023 at 1:13 PM Michael Folkson <michaelfolkson@protonmail.com> wrote:
>
>>> probably easier just to reject any transaction where the fee is higher than the sum of the outputs
>>
>> And prevent perfectly reasonable transfers of value and attempted Lightning channel closes during fee spikes? If I want​ to close my Lightning channel during a protracted fee spike where I have to pay an onchain transaction fee greater than the amount I am receiving you want to stop me doing that? You are impinging on a valid use case as well as requiring a consensus rule change.
>>
>> --
>> Michael Folkson
>> Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
>> GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F
>>
>> Learn about Bitcoin: https://www.youtube.com/@portofbitcoin
>>
>> ------- Original Message -------
>> On Monday, May 8th, 2023 at 13:58, Erik Aronesty via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>> probably easier just to reject any transaction where the fee is higher than the sum of the outputs
>>>
>>> On Mon, May 8, 2023, 7:55 AM Ali Sherief via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> 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: 16189 bytes --]

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

[Erik Aronesty]

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

> value you can from these Lightning channel(s) onchain even if it means
paying a higher fee than the amount you are receiving.

in that case, you're not getting any value - you're losing value.   the
only benefit i could imagine would be to prevent the other party from
having access to the funds should the channel expire.

regardless, this is an edge case.   it's clear that a utxo whose value is
less than the fee paid to move it is dust, and we already have plenty of
code to censor dust transactions

> no reason to prevent

the reason to prevent them is to prevent something that has more value than
the bitcoin itself from being stored on-chain.  that is to say:
real-estate ownership, nfts, or any other thing that isn't "using bitcoin
as money"

by going at the "incentive/economic layer", rather than pointlessly forcing
brc-20 and ordinals users to obfuscate their transactions, we can provide a
permanent incentive to keep that stuff off of bitcoin

personally, i'm not sure it's desirable to keep it off of bitcoin, but if
it is, the only sure way to disincentivize it is to go at it in this way or
similar

i suspect all the opcode validation suggestions are just silly.   ordinals
can time their fork to the same moment, and store data in a less efficient,
but still functional, way using any number of mechanisms.   we've had
similar things posted on-chain since 2010 (my favorite was a software
license key - in an attempt to make bitcoin nodes illegal.   it's still in
there)


On Mon, May 8, 2023 at 4:36 PM Michael Folkson <
michaelfolkson@protonmail.com> wrote:

> > im unclear as to the purpose paying an onchain transaction fee greater
> than the amount receiving could possibly serve.
>
> If you expect fees to continue to rise and be sustained at abnormally high
> levels for a long period of time you might seek to close your Lightning
> channel(s) and move whatever value you can from these Lightning channel(s)
> onchain even if it means paying a higher fee than the amount you are
> receiving.
>
> I don't necessarily recommend doing this (it would depend on a number of
> factors, both personal and external) but there is no reason to prevent
> someone in say the consensus rules from doing this if they wish.
>
> --
> Michael Folkson
> Email: michaelfolkson at protonmail.com
> GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F
>
> Learn about Bitcoin: https://www.youtube.com/@portofbitcoin
>
> ------- Original Message -------
> On Monday, May 8th, 2023 at 20:47, Erik Aronesty <erik@q32.com> wrote:
>
> im unclear as to the purpose paying an onchain transaction fee greater
> than the amount receiving could possibly serve.
>
> what benefit do you get aside from losing bitcoin?
>
> are there any, non-theoretical, benefits to facilitating dust transactions?
>
> we could, of course, have it be non-consensus (no route dust) to start with
>
>
>
>
>
> On Mon, May 8, 2023 at 1:13 PM Michael Folkson <
> michaelfolkson@protonmail.com> wrote:
>
>> > probably easier just to reject any transaction where the fee is higher
>> than the sum of the outputs
>>
>> And prevent perfectly reasonable transfers of value and attempted
>> Lightning channel closes during fee spikes? If I *want*​ to close my
>> Lightning channel during a protracted fee spike where I have to pay an
>> onchain transaction fee greater than the amount I am receiving you want to
>> stop me doing that? You are impinging on a valid use case as well as
>> requiring a consensus rule change.
>>
>> --
>> Michael Folkson
>> Email: michaelfolkson at protonmail.com
>> GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F
>>
>> Learn about Bitcoin: https://www.youtube.com/@portofbitcoin
>>
>> ------- Original Message -------
>> On Monday, May 8th, 2023 at 13:58, Erik Aronesty via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>> probably easier just to reject any transaction where the fee is higher
>> than the sum of the outputs
>>
>>
>>
>> On Mon, May 8, 2023, 7:55 AM Ali Sherief via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> 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: 18209 bytes --]

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

[Erik Aronesty]

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

the more i think about it, the more that this is essential.   consider that
bitcoin is secured by mining and mining is secured by fees.   all of that
is relative to the value of bitcoin itself.   but consider the incentive
for a reorg if a single ordinal is worth 1 billion dollars and is being
transferred.  now all the incentive logic is thrown to the wind.
 non-monetary use is quite dangerous to network stability, and the game
theory underpinning it, imo.

On Mon, May 8, 2023 at 4:59 PM Erik Aronesty <erik@q32.com> wrote:

> > value you can from these Lightning channel(s) onchain even if it means
> paying a higher fee than the amount you are receiving.
>
> in that case, you're not getting any value - you're losing value.   the
> only benefit i could imagine would be to prevent the other party from
> having access to the funds should the channel expire.
>
> regardless, this is an edge case.   it's clear that a utxo whose value is
> less than the fee paid to move it is dust, and we already have plenty of
> code to censor dust transactions
>
> > no reason to prevent
>
> the reason to prevent them is to prevent something that has more value
> than the bitcoin itself from being stored on-chain.  that is to say:
> real-estate ownership, nfts, or any other thing that isn't "using bitcoin
> as money"
>
> by going at the "incentive/economic layer", rather than pointlessly
> forcing brc-20 and ordinals users to obfuscate their transactions, we can
> provide a permanent incentive to keep that stuff off of bitcoin
>
> personally, i'm not sure it's desirable to keep it off of bitcoin, but if
> it is, the only sure way to disincentivize it is to go at it in this way or
> similar
>
> i suspect all the opcode validation suggestions are just silly.   ordinals
> can time their fork to the same moment, and store data in a less efficient,
> but still functional, way using any number of mechanisms.   we've had
> similar things posted on-chain since 2010 (my favorite was a software
> license key - in an attempt to make bitcoin nodes illegal.   it's still in
> there)
>
>
> On Mon, May 8, 2023 at 4:36 PM Michael Folkson <
> michaelfolkson@protonmail.com> wrote:
>
>> > im unclear as to the purpose paying an onchain transaction fee greater
>> than the amount receiving could possibly serve.
>>
>> If you expect fees to continue to rise and be sustained at abnormally
>> high levels for a long period of time you might seek to close your
>> Lightning channel(s) and move whatever value you can from these Lightning
>> channel(s) onchain even if it means paying a higher fee than the amount you
>> are receiving.
>>
>> I don't necessarily recommend doing this (it would depend on a number of
>> factors, both personal and external) but there is no reason to prevent
>> someone in say the consensus rules from doing this if they wish.
>>
>> --
>> Michael Folkson
>> Email: michaelfolkson at protonmail.com
>> GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F
>>
>> Learn about Bitcoin: https://www.youtube.com/@portofbitcoin
>>
>> ------- Original Message -------
>> On Monday, May 8th, 2023 at 20:47, Erik Aronesty <erik@q32.com> wrote:
>>
>> im unclear as to the purpose paying an onchain transaction fee greater
>> than the amount receiving could possibly serve.
>>
>> what benefit do you get aside from losing bitcoin?
>>
>> are there any, non-theoretical, benefits to facilitating dust
>> transactions?
>>
>> we could, of course, have it be non-consensus (no route dust) to start
>> with
>>
>>
>>
>>
>>
>> On Mon, May 8, 2023 at 1:13 PM Michael Folkson <
>> michaelfolkson@protonmail.com> wrote:
>>
>>> > probably easier just to reject any transaction where the fee is
>>> higher than the sum of the outputs
>>>
>>> And prevent perfectly reasonable transfers of value and attempted
>>> Lightning channel closes during fee spikes? If I *want* to close my
>>> Lightning channel during a protracted fee spike where I have to pay an
>>> onchain transaction fee greater than the amount I am receiving you want to
>>> stop me doing that? You are impinging on a valid use case as well as
>>> requiring a consensus rule change.
>>>
>>> --
>>> Michael Folkson
>>> Email: michaelfolkson at protonmail.com
>>> GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F
>>>
>>> Learn about Bitcoin: https://www.youtube.com/@portofbitcoin
>>>
>>> ------- Original Message -------
>>> On Monday, May 8th, 2023 at 13:58, Erik Aronesty via bitcoin-dev <
>>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>
>>> probably easier just to reject any transaction where the fee is higher
>>> than the sum of the outputs
>>>
>>>
>>>
>>> On Mon, May 8, 2023, 7:55 AM Ali Sherief via bitcoin-dev <
>>> bitcoin-dev@lists.linuxfoundation.org> 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: 19059 bytes --]

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

[Luke Dashjr]

[-- 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 --]

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

[Peter Todd]

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

On Mon, May 08, 2023 at 06:37:34PM -0400, Luke Dashjr via bitcoin-dev wrote:
> 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.

Miners are making millions of dollars from these inscription transactions.
Miners can and do run their own nodes and interconnect to each other. Many
people like myself will continue to run nodes that do not attempt to block
inscriptions. And of course, the current flood of BRC-20 transactions embed
very little data in the chain per transaction and could easily be adapted to
use OP_RETURN or any number of other data embedding schemes; if they were
modified to embed no data at all they wouldn't be much smaller, and I'm sure
you'd still be complaining that they were spam.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Ali Sherief]

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

Hey guys,

I'm more of the opinion that if this particular format the spam transactions are using is addressed, it will not only cause the mempool to relax, but it will also give us time to regroup and work on Layer 2 before the next onslaught of spam transactions using a (slightly) different format begins.

-Ali

On Tue, May 9, 2023 at 3:02 AM, Peter Todd <pete@petertodd.org> wrote:

> On Mon, May 08, 2023 at 06:37:34PM -0400, Luke Dashjr via bitcoin-dev wrote:
>> 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.
>
> Miners are making millions of dollars from these inscription transactions.
> Miners can and do run their own nodes and interconnect to each other. Many
> people like myself will continue to run nodes that do not attempt to block
> inscriptions. And of course, the current flood of BRC-20 transactions embed
> very little data in the chain per transaction and could easily be adapted to
> use OP_RETURN or any number of other data embedding schemes; if they were
> modified to embed no data at all they wouldn't be much smaller, and I'm sure
> you'd still be complaining that they were spam.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org

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

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

[Tom Harding]

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

> And prevent perfectly reasonable transfers of value


Such a transfer can only be reasonable when off-chain value is attached 
to the coins.  A rule like this is the embodiment of the philosophy that 
the Bitcoin network is for onchain-economic transactions.

Parties could get around the rule by paying miners off-network, and that 
would be an appropriate penalty for using non-onchain-economic transactions.



On 5/8/23 10:13, Michael Folkson via bitcoin-dev wrote:
> > probably easier just to reject any transaction where the fee is 
> higher than the sum of the outputs
>
> And prevent perfectly reasonable transfers of value and attempted 
> Lightning channel closes during fee spikes? If I *want*​ to close my 
> Lightning channel during a protracted fee spike where I have to pay an 
> onchain transaction fee greater than the amount I am receiving you 
> want to stop me doing that? You are impinging on a valid use case as 
> well as requiring a consensus rule change.
>
> -- Michael Folkson
> Email: michaelfolkson at protonmail.com <http://protonmail.com/>
> GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F
> Learn about Bitcoin: https://www.youtube.com/@portofbitcoin
>
> ------- Original Message -------
> On Monday, May 8th, 2023 at 13:58, Erik Aronesty via bitcoin-dev 
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> probably easier just to reject any transaction where the fee is 
>> higher than the sum of the outputs
>>
>>
>>
>> On Mon, May 8, 2023, 7:55 AM Ali Sherief via bitcoin-dev 
>> <bitcoin-dev@lists.linuxfoundation.org> 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
>>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

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

[Erik Aronesty]

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

>
>
> > no data at all


exactly, which is why a relationship between "cpfp-inclusive outputs" and
"fees" makes sense.   it's clear that's a good definition of dust, and not
too hard to get a working pr up for the network-layer.   i get that your
node will still route.   i get that it would break timestamps, indeed, it
would break all non-economic use cases if we made it a consensus change.

but that's the point of the discussion.

the question is whether breaking all non-economic use cases is the right
move, given the game-theory of what underpins bitcoin

i'm sad (honestly) to say that it might be

it may very well be that bitcoin *cannot* be a "global ledger of all
things" in order to remain useful and decentralized, and instead the
monetary use case must be it's only goal

also, i'm not really advocating for this solution so much as i would like a

- rational conversation about the incentives
- whether this solution would be an effective enough barrier to keep most
non-economic tx off bitcoin

obviously it's easy enough to evade if every non-economic user simply keeps
enough bitcoin around and sends it back to himself

so maybe it's a useless idea?   but maybe that's enough of a hassle to stop
people (it certainly breaks ordinals, since it can never be 1 sat)

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

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

[Tom Harding]

On 5/9/23 09:32, Erik Aronesty via bitcoin-dev wrote:

> obviously it's easy enough to evade if every non-economic user simply  > keeps enough bitcoin around and sends it back to himself > > so 
maybeit's a useless idea? but maybe that's enough of a hassle to stop > 
people (it certainly breaks ordinals, since it can never be 1 sat)

Padding the change is not just a hassle, it requires holding extra BTC 
in a hot wallet, which has a cost.

Spenders could also get around the rule by paying miners off-network, 
but having to do so would be an appropriate penalty for broadcasting a 
non-economic transaction.

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

[Keagan McClelland]

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

Erik,

I'm curious about what you believe to be "non-economic" txs. As far as I
can tell, any transaction included in the blockchain is economically
motivated by the very evidence of fees paid. That said, for the sake of
argument if we assume that there exists a category of information that
constitutes "non-economic" information, then so long as there is any
variance in the way to express a single economic intention, there exists a
vector for including "non-economic" information. I'll add beyond this that
there must always be variance in the way to express the same intent because
the signature data must be indistinguishable from entropy for Bitcoin's
security to hold.

Even if we eliminate small UTXOs, OP_RETURN, or whatever other vector of
the day that is currently being used to propagate such "non-economic"
information, we will always have the potential variance in the signature
data to do so. The best you can hope for is to make such means so
inefficient that the real cost-per-bit is expensive enough that there are
fewer distinct use cases. However, this isn't enough to actually *prevent*
the "spam". By increasing the cost-per-bit, it may limit it to only
"non-economic" information of extremely high value (note the
contradiction), it limits the number of use cases while also increasing the
impact of the use cases that make it past that threshold. Thus, it isn't
the impact of spam that is being reduced so much as it is reducing the
number of distinct use cases that result in "spam". Perhaps this is enough
to make spam more intermittent, and maybe on those grounds alone it could
be worth it, but I doubt it.

IMO the proper way to handle things like this isn't to introduce consensus
or relay policy to incentivize the expansion of the chain weight these
"non-economic" use cases require, but rather to reduce the necessary chain
footprint of supposed "economically motivated" transactions, which
incidentally is the entire point of all layered scaling tech. The current
fees we are experiencing are still significantly lower than they need to be
if Bitcoin is going to survive in a post-subsidy era. If our layered
protocols can't survive the current fee environment, the answer is to fix
the layered protocols.

Food for thought.

Stay Inspired,
Keags

On Tue, May 9, 2023 at 12:38 PM Erik Aronesty via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
>> > no data at all
>
>
> exactly, which is why a relationship between "cpfp-inclusive outputs" and
> "fees" makes sense.   it's clear that's a good definition of dust, and not
> too hard to get a working pr up for the network-layer.   i get that your
> node will still route.   i get that it would break timestamps, indeed, it
> would break all non-economic use cases if we made it a consensus change.
>
> but that's the point of the discussion.
>
> the question is whether breaking all non-economic use cases is the right
> move, given the game-theory of what underpins bitcoin
>
> i'm sad (honestly) to say that it might be
>
> it may very well be that bitcoin *cannot* be a "global ledger of all
> things" in order to remain useful and decentralized, and instead the
> monetary use case must be it's only goal
>
> also, i'm not really advocating for this solution so much as i would like
> a
>
> - rational conversation about the incentives
> - whether this solution would be an effective enough barrier to keep most
> non-economic tx off bitcoin
>
> obviously it's easy enough to evade if every non-economic user simply
> keeps enough bitcoin around and sends it back to himself
>
> so maybe it's a useless idea?   but maybe that's enough of a hassle to
> stop people (it certainly breaks ordinals, since it can never be 1 sat)
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

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

[Brad Morrison]

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

Melvin/all, 

You make good points about high network fees being disruptive. 

What is more disruptive are spikes & valleys (instability) that last
longer than the mempool cycle can handle. 

Right now, https://mempool.space/ indicates that there are about 105,000
unconfirmed transactions and that current memory usage is 795 mb of 300
mb. 

We could compare the bitcoin networks' ability to process transactions
to the California Independent System Operator's (CAISO -
https://www.caiso.com/Pages/default.aspx) task of ensuring the CA
electrical grid stays supplied with the least expensive electricity
available and does not get overloaded, nor has to export too much
electrical power to other grids in times of surplus. 

A big part of doing that is noticing past trends and preparing for
future growth, if that is the goal. 

Expanding the block size is the simplest way to expand network capacity
and lower transactional costs. 

Thank you, 

Brad

On 2023-05-08 09:37, Melvin Carvalho via bitcoin-dev wrote:

> po 8. 5. 2023 v 13:55 odesí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 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.
> 
> 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=195.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/ [1] 
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
 

Links:
------
[1]
https://www.coindesk.com/consensus-magazine/2023/05/05/pump-the-brcs-the-promise-and-peril-of-bitcoin-backed-tokens/?outputType=amp

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

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

[Melvin Carvalho]

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

pá 3. 11. 2023 v 11:16 odesílatel Brad Morrison <bradmorrison@sonic.net>
napsal:

> Melvin/all,
>
> You make good points about high network fees being disruptive.
>
> What is more disruptive are spikes & valleys (instability) that last
> longer than the mempool cycle can handle.
>
> Right now, https://mempool.space/ indicates that there are about 105,000
> unconfirmed transactions and that current memory usage is 795 mb of 300 mb.
>
> We could compare the bitcoin networks' ability to process transactions to
> the California Independent System Operator's (CAISO -
> https://www.caiso.com/Pages/default.aspx) task of ensuring the CA
> electrical grid stays supplied with the least expensive electricity
> available and does not get overloaded, nor has to export too much
> electrical power to other grids in times of surplus.
>
> A big part of doing that is noticing past trends and preparing for future
> growth, if that is the goal.
>
> Expanding the block size is the simplest way to expand network capacity
> and lower transactional costs.
>

The block size is a sensitive topic, as it has been used as an attack
vector in the past.  It is now a loaded topic baked into the mythology of
the project.  Discourse on the topic benefit from a dispassionate analysis
of the technical trade-offs and what properties of the network they affect.

There exists an attack on bitcoin where the lowest fee rises to make it
much harder to participate.  You could imagine a well funded attack,
creating fees of, say, 10,000 sats/vbyte, for a period of time.

While this could be viewed as positive from one lens (miners benefit),
there would at least be a vocal minority, legitimately arguing that this is
disruptive to the ordinary function of the network.

It's worth recognizing that a bigger block size makes this kind of
disruptive attack more expensive.

It's a tricky topic because of the history, and because some of the "spam"
may be seen by some as legitimate.

I think in the long-term miners and users will treat the fee auction in new
ways, with the use of AI algorithms.  Trillions are transmitted through the
bitcoin network.  A fraction of that is captured.  As the block subsidy
goes away over the next 2 decades, it might lead to a kind of "AI mexican
standoff" where the highest value transactions pay a bit more for priority
transfers.  AI will likely change the game theory, and we'll find out how,
over the next 2 epochs.

If that is the case, then block size can increase with hardware advances,
while maintaining much valued decentralized properties of the network.  In
this regard we probably would benefit from things like stratumv2 and
utreexo being rolled out first.


> Thank you,
>
> Brad
>
>
>
> On 2023-05-08 09:37, Melvin Carvalho via bitcoin-dev wrote:
>
>
>
> po 8. 5. 2023 v 13:55 odesí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 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.
>>
>
> 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=195.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/
>> <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
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

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

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

[ArmchairCryptologist]

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

While I don't necessarily disagree about the block size limit, efforts to increase it in the past has been effectively stonewalled since, as it turns out, all you have to do to not increase it is nothing.

If we are looking to address the current mempool spam in particular, it looks to me that it isn't specifically caused by exploiting taproot to add large amounts of data to the blockchain, there are just a large amount of spam transactions creating dust and moving it around. To the best of my knowledge, this type of spam could to some extent be mitigated by adding a dynamic dust limit, where in addition to today's fixed limit of 546 sats, UTXOs are considered to be dust if they cannot be economically spent at the fee rate of the transaction creating it.

Of course, it complicates matters somehow that you cannot generally know how much data is required to spend a UTXO, especially with taproot, so you'd need to calculate it by assuming that it will require the typical amount of data for a basic UTXO. With the same assumptions used to define the original dust limit, Ignoring that segwit/taproot can be somewhat cheaper, that would be 182 sats per byte.

Say if a transaction has a fee rate of 100 sat/b - the dust limit for UTXOs this transaction creates would then be increased from 546 sats to 18200 sats. So if you want to spam the blockchain with dust, the higher you push the fees, the more sats you need to leave behind in each UTXO.

There are of course pros and cons to such an approach, and you could argue the need to cap it in various ways, but it feels to me that it would be worth considering, especially considering that it is mempool policy rather than consensus critical.

--
Best,
ArmchairCryptologist

------- Original Message -------
On Friday, November 3rd, 2023 at 11:15 AM, Brad Morrison via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:

> Right now, https://mempool.space/ indicates that there are about 105,000 unconfirmed transactions and that current memory usage is 795 mb of 300 mb.
> ...
> Expanding the block size is the simplest way to expand network capacity and lower transactional costs

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

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

[jk_14]

W dniu 2023-05-11 13:57:11 użytkownik Keagan McClelland via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> napisał:

> The current fees we are experiencing are still significantly lower than they need to be if Bitcoin is going to survive in a post-subsidy era. If our layered protocols can't survive the current fee environment, the answer is to fix the layered protocols.


I also believe that this discussion should be expanded to the problem of Bitcoin's survival in the post-subsidy era, because it's very related, i.e. also directly related to the high transaction fees. The only difference is that the current $30 fee situation is probably temporary, and the future $40 (today's price tag) fee situation in post-subsidy era will be hopeless for change other than to reduce the difficulty of the network and hence its security and the marketcap/price in the end of day.

Because if the current network hashrate (current level of security) would drop e.g. to half of what it was in the past - the Store-of-Value feature simply collapse, while it's one of the most important (if not: the most important) long term feature of Bitcoin and as such advertised...
If you really care about SoV - you can't accept network security regression. Period.

I am a committed supporter of the free market. And Bitcoin is not the e-mail system, where sending is free and therefore spam which costs nothing to the sender - becomes a problem. In Bitcoin, every transaction costs - and in such a situation, distinguishing paid transactions into the good ones and the bad ones - would be a mistake and contradict the idea of the free market.

We should not interfere where the free market intervenes: the same way how small transfers are migrating to LN, the same way "non-economic", low value informations will migrate to Layer2 (RGB, Taro or maybe something else yet)

But, we should intervene there, where there is no free market. And I am not alone in alarming that there is such a place in Bitcoin.
In the post-subsidy era There Is No Free Market between: active users (overtaxed) and pasive users (free riders).

One of possible (very conservative) option to introduce free market there - is to delay halving in case of 4 years network difficulty regression situation.
Such a long-term regression of network difficulty means nothing else that transaction revenue from active users is not able to fund current network security anymore for both active and passive users. Delaying of halving is simply: not introducing additional more damage to the network security (really conservative approach)
Another option is: demurrage (but I'm not very sure it will work fine, at least before "hyperbitcoinzation")

Again, from my almost 50yo experience:
Bitcoin network difficulty can be more-less constant or can be slightly increasing (both options are "good for Bitcoin") but we should do our best - to avoid the network security regression.
I did.


Regards
Jaroslaw

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

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

[Aleksandr Kwaskoff]

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

if we forget about backward compatibility and the impact of other types of
transactions, then the following two options would be possible:
a) allocate only up to 10% of the space in the block for non-standard
transactions - then all senders of non-standard transactions will compete
with each other and it's only 10% with other types of transactions. In the
absence of non-standard transactions, all space of the block will be given
to standard ones. And in the absence of standard transactions - all space
of the block will be given to non-standard ones. If bitcoin-chain was
created primarily for standard transactions, then such a model will have to
be supported by the majority.
b) change the architecture in such a way that the onchain ordinals
transaction became much more expensive, which would force them to go to
their own type of the LN - this would be a kind of justice, like the
displacement of small transactions from the onchain to the LN happening
already now


-- 

Thank you, we will succeed! | Dziękujemy, uda nam się!

President of NGO FinTechAssociation | Prezes organizacji pozarządowej
FinTechStowarzyszenie

*Dipl.-Ing. *Aleksandr Kwaskoff

Telegram t.me/kwaskoff

Poland, Warsaw | Polska, Warszawa





[image: --]

President of NGO FinTechAssociation <http://t.me/finteh>

Aleksandr Kwaskoff
[image: https://]about.me/kwaskoff
<https://about.me/kwaskoff?promo=email_sig&utm_source=email_sig&utm_medium=email_sig&utm_campaign=external_links>

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

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

[Weiji Guo]

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

> I would like to point out that I'm not an advocate for doing anything at
this point aside from working on l2

Speaking of L2, I had recently proposed a new opcode OP_ZKP to enable
payments based on ZKP proof. I wonder if it has drawn enough attention but
it seems to me a viable way to address transaction fee issues, in addition
to enabling more smart contracts. And it will be a Bitcoin native L2, not a
side chain, not pegging.

      scriptPubKey: <hash of the verification key> <scheme_id> OP_ZKP
      scriptSig:         <pubInput_1> <pubInput_2> ... <pubInput_n> <n>
<proof>

I haven't figured out how to use OP_ZKP to incentivize BRC-20, inscription
etc. to move to L2. But I like to bring it up here and I am open to your
feedback and comments.

Thanks,
Weiji

On Tue, May 9, 2023 at 8:51 PM Erik Aronesty via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> I would like to point out that I'm not an advocate for doing anything at
> this point aside from working on l2
>
> just to make it inconvenient for people
>
> I just think the discussion of outputs and fees is interesting and related
> to the game theory portion of Bitcoin
>
>
>
> On Tue, May 9, 2023, 8:23 AM Jaroslaw via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>>
>>
>> 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
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

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

[Erik Aronesty]

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

I would like to point out that I'm not an advocate for doing anything at
this point aside from working on l2

just to make it inconvenient for people

I just think the discussion of outputs and fees is interesting and related
to the game theory portion of Bitcoin



On Tue, May 9, 2023, 8:23 AM Jaroslaw via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
>
> 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
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

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

[jk_14]

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