7

  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?

Improve this question

4 Answers 4

Reset to default
8

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

Improve this answer
12
  • 3
    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
    May 7 at 14:25
  • 1
    @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
    May 7 at 14:30
  • 4
    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
    May 7 at 15:02
  • 3
    @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
    May 7 at 18:05
  • 3
    @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
    May 7 at 18:12
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)?

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

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!

Improve this answer
1

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

Improve this answer
-2

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

Improve this answer
1
  • 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
    May 15 at 9:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.