<p>Philosophically, Bitcoin supposedly relies on Nash's game theory to balance usage within capacity. Nash assumes rational players in his games. The BRC20 transaction flood exists outside this. Specifically, when transaction volume exceeds capacity, confirmation delays inhibit new transactions, and a feedback loop of increasing fees accentuates the situation</p>
<p>But BRC20 is a marketplace of pump-and-dump sociopaths external to Bitcoin. While that market returns profits which are greater than the Bitcoin fees paid to inscribe the BRC20 tokens on Bitcoin's blockchain, those sociopaths are not deterred by high Bitcoin fees</p>
<p>We've seen these speculative tokens booming and crashing on Ethereum for 6 years. The Ordinals protocol is an innovation which allows non-fungible tagging without an ETH contract. Combine this with the long-running high-fee problem on ETH. BRC20 allows the creation of new tokens with 90% less effort compared to the ETH equivalent</p>
<p>But the easier they are to create, the faster they should crash. There are signs that this speculative market has already crashed. All the panic is pointless</p>
<p>Technically, these &quot;inscriptions&quot; were enabled by an innovation external to Bitcoin. Ordinals is a development which assigns a unique reference number to every Satoshi ever mined. This allows for non-fungible tagging of Bitcoin transactions. The other part (inscriptions) has always been possible in Bitcoin, due to Bitcoin txinputs being scripts. Bitcoin has had this feature since launch in January 2009</p>
<p>There have been knee-jerk demands for filtering &quot;non-standard&quot; scripts. These suggestions are foolish. Bitcoin Script is a function-rich programming language. If there is one way to inscribe arbitrary data, there are trillions of ways. They can not all be blocked</p>

CC BY-SA 4.0
2023-05-11T16:06:40.953Z
2023-05-11T16:06:40.953Z
Louis Thompson
<blockquote>
<p>Do we currently see a DDoS attack on Bitcoin as the mempool is flooded
with low value transactions incl. BRC-20, ordinals etc. (where the
transaction fee exceeds the transferred value)?</p>
</blockquote>
<p>No. Mike has some good criteria outlining why. Mainly that this currently does not prevent people from running full nodes. With that said, this can change if the behavior of the arbitrary data becomes more socially objectionable, or technical issues arise that cause full nodes to misbehave as a result (<a href="https://github.com/bitcoin/bitcoin/issues/27586" rel="nofollow noreferrer">CPU DoS on mainnet for example</a>).</p>
<p>Therefore, hoping for the best and preparing for the worst is probably a good strategy for everyone involved.</p>
<blockquote>
<p>What can / should be done to stop that or is that against the Bitcoin
censorship resistance ethos?</p>
</blockquote>
<p>There is a lot of precedent surrounding the issue of arbitrary data.</p>
<p>Changing standardness rules to increase the cost of this unwanted behavior has been done before, it can be done again.</p>
<p>In the extreme a softfork to increase the cost even more could be done, though would likely be contentious and unpopular. (though packaging it with some other features like APO or some other fancy stuff may get it over the line).</p>
<p>But arbitrary data will probably always be possible on Bitcoin. The question of, at what cost, may be up for grabs.</p>
<p>Currently that cost is evidently low.</p>
<p>Individuals can also choose to run Bitcoin consensus affirming full nodes that have differing standardness policies that may punish/filter/increase the costs for these kinds of transactions.</p>
<p>The current angle for this is simple mempool filtering of these transactions with something like the ordinaldisrespecter patch. But there may be more in the pipeline.</p>
<blockquote>
<p>Does a congested BTC mempool and a high fee environment negatively
impact the viability of lightning/layer 2?</p>
</blockquote>
<p>Probably not, if anything it may super charge it. Keep in mind this activity is coming in waves. the mempool does clear or nearly clear on a semi regular basis, giving people more opportunity to open and close channels.</p>
<blockquote>
<p>You need to be able to
close channels for far less than what's in the channel, otherwise the
game theory around punishments doesn't play out, right?</p>
</blockquote>
<p>This may be beyond my scope. But I'm not really sure what you mean by this last part? punishment game theory still works with or without high on chain fees? unless you are talking about very low value channels, in which case you may be right!</p>

CC BY-SA 4.0
2023-05-09T16:42:06.150Z
2023-05-09T16:42:06.150Z
Fiach-Dubh
<p>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</p>

CC BY-SA 4.0
2023-05-15T09:39:24.873Z
Notice that there is no way for us to coerce miners to follow this scheme: the escape ahtch of allowing non-standard txs to exceed 10% means we'd have to prove that there were non-standard txs in flight to invalidate a block for which the miner had picked the higher fee non-standard txs, which we can't do, since that's the whole point of blocks (reaching consensus about the existence of transactions at a certain point in time).
cdecker
CC BY-SA 4.0
2023-05-09T10:52:37.637Z
2023-05-09T10:52:37.637Z
Aleksandr Kwaskoff
<blockquote>
<p>Do we currently see a DDOS attack on Bitcoin as the mempool is flooded with low value Transactions incl. BRC-20, ordinals etc. (where the transaction fee exceeds the transferred value)?</p>
</blockquote>
<p>I get why some people don't like it as it is driving up transaction fees for a use case that many of us see as antithetical to Bitcoin. But it is only driving up transaction fees and filling up blocks, it isn't preventing full nodes from operating or knocking them offline. Hence I personally wouldn't call it a DDOS attack.</p>
<blockquote>
<p>What can / should be done to stop that or is that against the bitcoin censorship resistance ethos?</p>
</blockquote>
<p>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.</p>
<p>Hence in summary I don't think anything will or should be done. Andrew Poelstra also came to a similar conclusion in this bitcoin-dev mailing list <a href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-January/021372.html" rel="nofollow noreferrer">post</a> (January 2023). It was expected that transaction fees would rise eventually through normal onchain transactions and Lightning channel opens and closes. This kind of usage is just driving transaction fees higher prematurely.</p>
<blockquote>
<p>Does a congested BTC mempool and a high fee environment negatively impact the viability of lightning/layer 2? You need to be able to close channels for far less than what's in the channel, otherwise the game theory around punishments doesn't play out, right?</p>
</blockquote>
<p>The micropayment use case (and smaller channels) on Lightning were always going to be exposed to fee spikes. Lightning cannot control the onchain transaction fee to open and close channels. Larger channels with capacities above the current transaction fees can still close, just more expensively. As I said earlier this was always going to happen at some point. It is happening earlier than it otherwise would because of this use case but it was inevitable eventually.</p>

CC BY-SA 4.0
2023-05-07T14:25:20.017Z
Re the policy change, they would simply slightly change the script they use i guess instead of going for miners: if most of the network bans `FALSE IF`, just start using `FALSE IFDUP IF` for instance. It's not tractable to prevent them from doing this.
Antoine Poinsot
CC BY-SA 4.0
2023-05-07T14:30:03.703Z
@AntoinePoinsot: Right, at the very least a never ending game of whack-a-mole. Change default policy, transaction template is changed to meet new rules, change default policy, transaction template is changed to meet new rules etc.
Michael Folkson
CC BY-SA 4.0
2023-05-07T15:02:32.763Z
Not only that but it's also ineffective: one does not simply change network policy. It's a slow process to get most (or a significant share of) nodes to run a new version of bitcoind. Ordinal users will most likely be quicker to shift templates, resulting in no actual disruption for them. And the network would be in a worse state overall with various nodes running incompatible policies.
Antoine Poinsot
CC BY-SA 4.0
2023-05-07T17:55:19.370Z
Its worth noting that you asserted this is not an attack while also asserting that we would have to change policy and or consensus in order to counter it, maybe lets call it a vulnerability then? That is being exploited? Therefore an ATTACK. Its weird to see people so complacent when one of the most important things on earth is being attacked.
Poseidon
CC BY-SA 4.0
2023-05-07T18:05:56.893Z
@Poseidon: I don't like this use case. But they are transactions that meet the consensus rules, policy rules and exceed the market fee rate. From the standpoint of protocol developers there isn't a solution to whatever problem is presented here. I'm not going to call a use case I don't like an attack. Maybe a social attack that is addressed by trying to persuade people that it isn't a good use case. But that isn't a code or running software solution.
Michael Folkson
CC BY-SA 4.0
2023-05-07T18:08:42.123Z
I disagree, we can choose to stop relaying their transactions if we feel they are a dishonest attempt at raising the minimum fee rate beyond the capabilities of the average end user (Bitcoin l1 completely unusable for 2nd world countries at this point). You can remain complacent if you want but just know that if we lose major market adoption and need to teach another generation about PoW PoR NYKNYC etc... that will be at the hands of said complacency.
Poseidon
CC BY-SA 4.0
2023-05-07T18:12:40.800Z
@Poseidon: Your node can stop relaying their transactions, sure. But as the answer and the conversation with Antoine states a default policy change isn't a good idea for a number of reasons including the fact that transactions can be submitted directly to miners bypassing the P2P network. If you've looked at all the possible solutions and they are worse or ineffective compared to the status quo you don't do anything.
Michael Folkson
CC BY-SA 4.0
2023-05-07T18:29:35.460Z
The status quo right now is that people are PISSED that Udi and the Taproot Wizards have managed to make it unreasonable for anyone to broadcast normal transactions. A small group of people has made it unmanageable for the majority of Bitcoin users to transact properly. That status quo will run the improved software which STOPS RELAYING SPAM and then we will have a network that is not affected by the vulnerability. If you don't think lessening spam on the network is a good thing I consider you a bad actor.
Poseidon
CC BY-SA 4.0
2023-05-07T18:30:21.497Z
Thoughts on #3?
BitcoinFanatic
CC BY-SA 4.0
2023-05-07T18:32:05.407Z
The increased fee environment has caused a noticeable impact on lightning channels according to users, there is an increased amount of channel closes due to fees for htlcs making routing fail constantly. The channel close fees are also higher than they should be, people are effectively seeing their lightning related transactions be dumped for spammy ones.
Poseidon
CC BY-SA 4.0
2023-05-07T21:56:11.193Z
Not to mention the core principal behind ANY off chain scaling solution so far is atomic multi-path payments, currently these are being fixed to a timelock scheme, but if you are in a channel with someone who has a lot more money than you they can submit a force close with the full amount from the last commitment and effectively steal your sats by being able to out spend you on the fees.
Poseidon
CC BY-SA 4.0
2023-05-07T14:09:16.793Z
2023-05-08T11:30:42.690Z
2023-05-08T11:30:42.690Z
Michael Folkson
<ol>
<li><p>Do we currently see a DDoS attack on Bitcoin as the mempool is flooded with low value transactions incl. BRC-20, ordinals etc. (where the transaction fee exceeds the transferred value)?</p>
</li>
<li><p>What can / should be done to stop that or is that against the Bitcoin censorship resistance ethos?</p>
</li>
<li><p>Does a congested BTC mempool and a high fee environment negatively impact the  viability of lightning/layer 2? You need to be able to close channels for far less than what's in the channel, otherwise the game theory around punishments doesn't play out, right?</p>
</li>
</ol>

<mempool><attack><ordinals>
DDOS attack via BRC-20 & ordinals on Bitcoin
BitcoinFanatic
# DDOS attack via BRC-20 & ordinals on Bitcoin

(Asked by: username_0 on 2023-05-07)

1. Do we currently see a DDoS attack on Bitcoin as the mempool is flooded with low value transactions incl. BRC-20, ordinals etc. (where the transaction fee exceeds the transferred value)?
2. What can / should be done to stop that or is that against the Bitcoin censorship resistance ethos?
3. Does a congested BTC mempool and a high fee environment negatively impact the viability of lightning/layer 2? You need to be able to close channels for far less than what's in the channel, otherwise the game theory around punishments doesn't play out, right?

**Tags:** mempool, attack, ordinals


---

## 4 answers

### Answer by username_5 on 2023-05-07. Score: 7 | Accepted answer

> Do we currently see a DDOS attack on Bitcoin as the mempool is flooded with low value Transactions incl. BRC-20, ordinals etc. (where the transaction fee exceeds the transferred value)?

I get why some people don't like it as it is driving up transaction fees for a use case that many of us see as antithetical to Bitcoin. But it is only driving up transaction fees and filling up blocks, it isn't preventing full nodes from operating or knocking them offline. Hence I personally wouldn't call it a DDOS attack.

> What can / should be done to stop that or is that against the bitcoin censorship resistance ethos?

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.

Hence in summary I don't think anything will or should be done. Andrew Poelstra also came to a similar conclusion in this bitcoin-dev mailing list [post](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-January/021372.html) (January 2023). It was expected that transaction fees would rise eventually through normal onchain transactions and Lightning channel opens and closes. This kind of usage is just driving transaction fees higher prematurely.

> Does a congested BTC mempool and a high fee environment negatively impact the viability of lightning/layer 2? You need to be able to close channels for far less than what's in the channel, otherwise the game theory around punishments doesn't play out, right?

The micropayment use case (and smaller channels) on Lightning were always going to be exposed to fee spikes. Lightning cannot control the onchain transaction fee to open and close channels. Larger channels with capacities above the current transaction fees can still close, just more expensively. As I said earlier this was always going to happen at some point. It is happening earlier than it otherwise would because of this use case but it was inevitable eventually.

> **Comments:**
> **username_6**: Re the policy change, they would simply slightly change the script they use i guess instead of going for miners: if most of the network bans `FALSE IF`, just start using `FALSE IFDUP IF` for instance. It's not tractable to prevent them from doing this.  
> **username_5**: @username_6: Right, at the very least a never ending game of whack-a-mole. Change default policy, transaction template is changed to meet new rules, change default policy, transaction template is changed to meet new rules etc.  
> **username_6**: Not only that but it's also ineffective: one does not simply change network policy. It's a slow process to get most (or a significant share of) nodes to run a new version of bitcoind. Ordinal users will most likely be quicker to shift templates, resulting in no actual disruption for them. And the network would be in a worse state overall with various nodes running incompatible policies.  
> **username_7**: Its worth noting that you asserted this is not an attack while also asserting that we would have to change policy and or consensus in order to counter it, maybe lets call it a vulnerability then? That is being exploited? Therefore an ATTACK. Its weird to see people so complacent when one of the most important things on earth is being attacked.  
> **username_5**: @username_7: I don't like this use case. But they are transactions that meet the consensus rules, policy rules and exceed the market fee rate. From the standpoint of protocol developers there isn't a solution to whatever problem is presented here. I'm not going to call a use case I don't like an attack. Maybe a social attack that is addressed by trying to persuade people that it isn't a good use case. But that isn't a code or running software solution.  
> **username_7**: I disagree, we can choose to stop relaying their transactions if we feel they are a dishonest attempt at raising the minimum fee rate beyond the capabilities of the average end user (Bitcoin l1 completely unusable for 2nd world countries at this point). You can remain complacent if you want but just know that if we lose major market adoption and need to teach another generation about PoW PoR NYKNYC etc... that will be at the hands of said complacency.  
> **username_5**: @username_7: Your node can stop relaying their transactions, sure. But as the answer and the conversation with username_6 states a default policy change isn't a good idea for a number of reasons including the fact that transactions can be submitted directly to miners bypassing the P2P network. If you've looked at all the possible solutions and they are worse or ineffective compared to the status quo you don't do anything.  
> **username_7**: The status quo right now is that people are PISSED that Udi and the Taproot Wizards have managed to make it unreasonable for anyone to broadcast normal transactions. A small group of people has made it unmanageable for the majority of Bitcoin users to transact properly. That status quo will run the improved software which STOPS RELAYING SPAM and then we will have a network that is not affected by the vulnerability. If you don't think lessening spam on the network is a good thing I consider you a bad actor.  
> **username_0**: Thoughts on #3?  
> **username_7**: The increased fee environment has caused a noticeable impact on lightning channels according to users, there is an increased amount of channel closes due to fees for htlcs making routing fail constantly. The channel close fees are also higher than they should be, people are effectively seeing their lightning related transactions be dumped for spammy ones.  
> **username_7**: Not to mention the core principal behind ANY off chain scaling solution so far is atomic multi-path payments, currently these are being fixed to a timelock scheme, but if you are in a channel with someone who has a lot more money than you they can submit a force close with the full amount from the last commitment and effectively steal your sats by being able to out spend you on the fees.  

---

### Answer by username_1 on 2023-05-11. Score: 0

Philosophically, Bitcoin supposedly relies on Nash's game theory to balance usage within capacity. Nash assumes rational players in his games. The BRC20 transaction flood exists outside this. Specifically, when transaction volume exceeds capacity, confirmation delays inhibit new transactions, and a feedback loop of increasing fees accentuates the situation

But BRC20 is a marketplace of pump-and-dump sociopaths external to Bitcoin. While that market returns profits which are greater than the Bitcoin fees paid to inscribe the BRC20 tokens on Bitcoin's blockchain, those sociopaths are not deterred by high Bitcoin fees

We've seen these speculative tokens booming and crashing on Ethereum for 6 years. The Ordinals protocol is an innovation which allows non-fungible tagging without an ETH contract. Combine this with the long-running high-fee problem on ETH. BRC20 allows the creation of new tokens with 90% less effort compared to the ETH equivalent

But the easier they are to create, the faster they should crash. There are signs that this speculative market has already crashed. All the panic is pointless

Technically, these "inscriptions" were enabled by an innovation external to Bitcoin. Ordinals is a development which assigns a unique reference number to every Satoshi ever mined. This allows for non-fungible tagging of Bitcoin transactions. The other part (inscriptions) has always been possible in Bitcoin, due to Bitcoin txinputs being scripts. Bitcoin has had this feature since launch in January 2009

There have been knee-jerk demands for filtering "non-standard" scripts. These suggestions are foolish. Bitcoin Script is a function-rich programming language. If there is one way to inscribe arbitrary data, there are trillions of ways. They can not all be blocked


---

### Answer by username_2 on 2023-05-09. Score: 0

> Do we currently see a DDoS attack on Bitcoin as the mempool is flooded
> with low value transactions incl. BRC-20, ordinals etc. (where the
> transaction fee exceeds the transferred value)?

No. Mike has some good criteria outlining why. Mainly that this currently does not prevent people from running full nodes. With that said, this can change if the behavior of the arbitrary data becomes more socially objectionable, or technical issues arise that cause full nodes to misbehave as a result ([CPU DoS on mainnet for example](https://github.com/bitcoin/bitcoin/issues/27586)).

Therefore, hoping for the best and preparing for the worst is probably a good strategy for everyone involved.

> What can / should be done to stop that or is that against the Bitcoin
> censorship resistance ethos?

There is a lot of precedent surrounding the issue of arbitrary data.

Changing standardness rules to increase the cost of this unwanted behavior has been done before, it can be done again.

In the extreme a softfork to increase the cost even more could be done, though would likely be contentious and unpopular. (though packaging it with some other features like APO or some other fancy stuff may get it over the line).

But arbitrary data will probably always be possible on Bitcoin. The question of, at what cost, may be up for grabs.

Currently that cost is evidently low.

Individuals can also choose to run Bitcoin consensus affirming full nodes that have differing standardness policies that may punish/filter/increase the costs for these kinds of transactions.

The current angle for this is simple mempool filtering of these transactions with something like the ordinaldisrespecter patch. But there may be more in the pipeline.

> Does a congested BTC mempool and a high fee environment negatively
> impact the viability of lightning/layer 2?

Probably not, if anything it may super charge it. Keep in mind this activity is coming in waves. the mempool does clear or nearly clear on a semi regular basis, giving people more opportunity to open and close channels.

> You need to be able to
> close channels for far less than what's in the channel, otherwise the
> game theory around punishments doesn't play out, right?

This may be beyond my scope. But I'm not really sure what you mean by this last part? punishment game theory still works with or without high on chain fees? unless you are talking about very low value channels, in which case you may be right!


---

### Answer by username_3 on 2023-05-09. Score: -3

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

> **Comments:**
> **username_4**: Notice that there is no way for us to coerce miners to follow this scheme: the escape ahtch of allowing non-standard txs to exceed 10% means we'd have to prove that there were non-standard txs in flight to invalidate a block for which the miner had picked the higher fee non-standard txs, which we can't do, since that's the whole point of blocks (reaching consensus about the existence of transactions at a certain point in time).  

---

