The network is flooded with spam

[piotr_n]

All the time there are like 20KB, but sometimes even 99KB txs that are going across the network - and they are just a spam.

I know it's not an issue, but believe me, that if someone will decide to use it as a DoS attack method and will bother to implement this method, it will quickly become an issue. And how are you going to solve it then - how many days/weeks/months will you need in order to adopt a protocol to this specific threat?

It's quite amazing that after finding recently that node's memory can be attacked by sending him big txs, nobody has even bothered to try thinking of if, instead of just "oh, as long as it's the same size as it is, I'm fine with downloading processing, storing and even routing forward, all this spam".

[grue]

You do realize that those 99kb transactions need a shitload of fees to be accepted right? So it's not possible to spam for free, at least. And they are removed the moment the transaction is confirmed, or whenever bitcoind restarts.

[piotr_n]

You do realize that those 99kb transactions need a shitload of fees to be accepted right? So it's not possible to spam for free, at least. And they are removed the moment the transaction is confirmed, or whenever bitcoind restarts.

Do you understand that before they get mined (which is usually never), or you restart your node, you keep them in your system memory?
There is definitely enough small outputs out there to increase your memory pool size to X GB - where X is how someone bothers and has enough outputs to spend on making spam transactions.

And why is someone still sending small amounts to this horse something address? It looks like a part of a bigger plan. I wonder how it will go.
Everybody knows the key to these outputs, so we will all be able to spam the network - what a great world to live in

[jl2012]

All the time there are like 20KB, but sometimes even 99KB txs that are going across the network - and they are just a spam.

I know it's not an issue, but believe me, that if someone will decide to use it as a DoS attack method and will bother to implement this method, it will quickly become an issue. And how are you going to solve it then - how many days/weeks/months will you need in order to adopt a protocol to this specific threat?

It's quite amazing that after finding recently that node's memory can be attacked by sending him big txs, nobody has even bothered to try thinking of if, instead of just "oh, as long as it's the same size as it is, I'm fine with downloading processing, storing and even routing forward, all this spam".

I think those are not relayed by default if they are not paying enough fee

[piotr_n]

All the time there are like 20KB, but sometimes even 99KB txs that are going across the network - and they are just a spam.

I know it's not an issue, but believe me, that if someone will decide to use it as a DoS attack method and will bother to implement this method, it will quickly become an issue. And how are you going to solve it then - how many days/weeks/months will you need in order to adopt a protocol to this specific threat?

It's quite amazing that after finding recently that node's memory can be attacked by sending him big txs, nobody has even bothered to try thinking of if, instead of just "oh, as long as it's the same size as it is, I'm fine with downloading processing, storing and even routing forward, all this spam".

I think those are not relayed by default if they are not paying enough fee

But they are "paying" enough fee.
You only need 0.01 fee to route 100KB transaction.
And since they don't get mined (thanks god), you don't even get to pay this fee at the end.
Moreover, currently the node stores and routes even txs that use zero-confirmation outputs, so you can basicaly use the same coins to stuff all the nodes' memory with spam - just by generating tons of 99KB txs, where one uses outputs from previous ones, none of which is even mined...

If there was an option in the bitcoin client to list all the txs in your memory pool (with their sizes, volume, fee, etc.) you would quickly notice what I am talking about; the spam occupies like 95% of your memory pool and its growing so fast that soon it will be 99.99%..
I just wonder what will be the limit where the core devs will finally admit that is might already be an issue and initiate a new BIP flowchart to implement an over complicated solution against this specific attack... it's unlikely though IMO that it would happen before December

[grue]

Do you understand that before they get mined (which is usually never), or you restart your node, you keep them in your system memory?
There is definitely enough small outputs out there to increase your memory pool size to X GB - where X is how someone bothers and has enough outputs to spend on making spam transactions.

And why is someone still sending small amounts to this horse something address? It looks like a part of a bigger plan. I wonder how it will go.
Everybody knows the key to these outputs, so we will all be able to spam the network - what a great world to live in

oh noes, 100kb of your memory is used! unless you're running on a raspberry pi, it's hardly an issue. If you don't want that much "spam", set your relay policy to higher fees.

Also, let's (for sake of argument), assume that a spammer is creating these transactions. He's paying $1 to "spam" 0.1 MB. Not exactly cheap.

[piotr_n]

Sure, whatever man.

As I said, this is exactly a response I had expected: there is no problem...
It is just some stupid sucker spending fees on stuffing our memory pools with huge txs that barely ever get mined.
It is absolutely impossible to turn this horse staple spam into an efficient attack - keep saying it to yourself.

[piotr_n]

Or since its still such a not an issue, allow me to ask this way:
Will it help if I release a tool that is able to consume all the node's system memory (with lets say 50% success rate) within an hour?
I think I can do it
With the horse inputs I can generate many 99KB txs and using <5KB txs with no valid inputs at all, I can do the rest.

This protocol has so many holes that one can exploit, that it just comes very hard for me to believe that nobody really gives a shit about it.

[DannyHamilton]

Or since its still such a not an issue, allow me to ask this way:
Will it help if I release a tool that is able to consume all the node's system memory (with lets say 50% success rate) within an hour?
I think I can do it
With the horse inputs I can generate many 99KB txs and using <5KB txs with no valid inputs at all, I can do the rest.

This protocol has so many holes that one can exploit, that it just comes very hard for me to believe that nobody really gives a shit about it.

Sounds like a great idea. Give it a try. It might not be as easy as you think.

Any transaction that has an output less than 0.01 BTC will require a fee of 0.0001 BTC per kilobyte, or peers will simply ignore it.
Any transaction that has a priority less than 57,600,000 will require a fee of 0.0001 BTC per kilobyte, or peers will simply ignore it.
Any transaction that is larger than 10 kilobytes will require a fee of 0.0001 BTC per kilobyte, or peers will simply ignore it.

If your tool doesn't pay the fees, then it won't have much of an effect on any peer running the reference protocol.

If your tool does pay the fees, then the transactions will most likely become confirmed by miners which will remove them from the memory pool.

I have 4GB of system memory.  That's a bit over 4 million kilobytes.  If you want to spend 400 BTC over the course of an hour to consume 100% of my system memory until the transactions are confirmed, go right ahead.

[piotr_n]

No, the nodes don't quite ignore them.
They just don't relay some of them.
But there are no actual protection in the node from being flooded with bogus transactions.
Not to mention the protocol.
Really, it's terrible. My webpage has better protection, and nobody except me cares about it either

[TierNolan]

No, the nodes don't quite ignore them.

So your proposal is that tx's that a node doesn't relay shouldn't be added to the memory pool at all?

This could cause issues where a node ends up verifying a tx over and over.  At minimum, the hash of verified but not accepted transactions should be kept, so that a node can just discard the transaction if received later.

[Gavin Andresen]

The problem is that there is a mismatch between the criteria used to accept a transaction into the memory pool / relayed and the criteria most miners use to choose transactions for their blocks.

The fix is not conceptually hard; just modify the memory pool code so the memory pool is treated like it is an extra-large block, and only relay/store the transactions that are likely to be mined in the next few blocks.

That hasn't been implemented yet because it just hasn't been a high priority.

[piotr_n]

No, the nodes don't quite ignore them.

So your proposal is that tx's that a node doesn't relay shouldn't be added to the memory pool at all?

This could cause issues where a node ends up verifying a tx over and over.  At minimum, the hash of verified but not accepted transactions should be kept, so that a node can just discard the transaction if received later.

My proposal is to better start thinking of it and try to find some long term solution, so an attack on nodes memory was not possible. Nor CPU, if possible.
If you like complicated solutions, I recommend web of trust

There are many measures that you can try against memory pool attacks, none of which is going to be implemented in a near future, at least from what I know.
Unless I build and release some tool to make it an issue - but then I will have to suffer consequences of being an evil guy who releases tools that DoS the network.
But either way, sooner or later, I will suffer the consequences - because someone will make such a tool, if I don't do anything to prevent it

[cbeast]

Rather than think of this as a weakness, can it be turned into a strength? WoT is just another word for subscription based transaction clearing houses. The network will evolve into that eventually. In the meantime, is there something useful that can be created from this exploit?

[piotr_n]

In the meantime, is there something useful that can be created from this exploit?

I could think of at least one. Insider trading on buying stocks of companies that manufacture memory chips