The attack on the network is not hostile

[Quantus]

It should be clear to everyone by now that the attacker means us no harm.
Its been 5 days now and the transaction back log has leveled off between 40k and 50k.
It is clear the intention of this (ongoing) attack is to increase transaction fees.
If the top mining pools are behind this they might even be turning a profit.


EDIT to help others understand:

If they wanted to inflict damage, real damage they could have sent all that spam at once.
If this was just a "statement about block size" Then the attacker has failed; thus the attacker would ether give up or increase the rate of spam.

[Carlton Banks]

Interesting theory, but it's another way of saying that someone who intended transaction flooding as an attack has only really demonstrated that it's not much of an attack. Like so many of these sorts of things, we could have the proven perpetrator themselves telling us their motive, and we still couldn't prove that motive any more than they could. What's their next move, obtain more bitcoin for a bigger "attack"?

[Quantus]

If they wanted to inflict damage, real damage they could have sent all that spam at once.
But the spam comes in waves starting and stopping to keep the backlog in a target area.

[NewLiberty]

Miner revenue is up, but not by much.  Fees are still a small fraction of the mining reward.

[newIndia]

It should be clear to everyone by now that the attacker means us no harm.
Its been 5 days now and the transaction back log has leveled off between 40k and 50k.
It is clear the intention of this (ongoing) attack is to increase transaction fees.
If the top mining pools are behind this they might even be turning a profit.

It is clear that the intention of the attacker was not to harm bitcoin. They are trying to prove some point. But, that might not be what you guess here. They might be vying for a block size increase as well (I know that does not solve the problem altogether).

[Xialla]

Miner revenue is up, but not by much.  Fees are still a small fraction of the mining reward.

well, considering that majority of blocks are mined by just few companies, obviously for them makes sense to behave like this. Even fee like 0.5BTC per blocks makes difference, if you are mining XY blocks daily..

anyway I agree, that if there will be some harm behind, all this will be focused to single day or even couple of hours. This looks somehow different so far..

[neoneros]

But it is still running and going strong. It was a bit messy, but nothing really bad happened, i have seen bigger problems ocurring with fiat systems. So nothing has been proved other than the blockchain is a robust currency and validates it's existence. Hope it did have some value for the developers, so they can work on it and make  it even better. As long as the chain is not broken.

[Quantus]

But it is still running and going strong. It was a bit messy, but nothing really bad happened, i have seen bigger problems ocurring with fiat systems. So nothing has been proved other than the blockchain is a robust currency and validates it's existence. Hope it did have some value for the developers, so they can work on it and make  it even better. As long as the chain is not broken.

Yes, if this was just a "statement about block size" Then the attacker has failed; thus the attacker would ether give up or increase the rate of spam, right?

sorry for the edits.

[pedrog]

How much is the cost of the attack?

Is there any analysis on this?

[Quantus]

How much is the cost of the attack?

Is there any analysis on this?

I don't trust myself to do the math myself but I read it could be anywhere from 600 to 1600 dollars a day. The higher transaction fees would only cover this if the top 3 pools were working together. (I'm really bad at math)

[NorrisK]

How would them trying to earn a better revenue by sending spam not be considered an attack? It is still a malicious event.

[Q7]

It goes to show that if one day the bitcoin network grows considerably, it won't be able to cope up with all these amount of transactions coming in. It's trying to a prove a point here whether it is intentional or otherwise, the message is clear we are not prepared for all that.

[pedrog]

How much is the cost of the attack?

Is there any analysis on this?

I don't trust myself to do the math myself but I read it could be anywhere from 600 to 1600 dollars a day. The higher transaction fees would only cover this if the top 3 pools were working together. (I'm really bad at math)

That's way too cheap for a billion dollar network, almost anyone can do it...

It goes to show that if one day the bitcoin network grows considerably, it won't be able to cope up with all these amount of transactions coming in. It's trying to a prove a point here whether it is intentional or otherwise, the message is clear we are not prepared for all that.

Changes proposed by Gavin to increase blocksize were meant to be applied in a year or so, I guess they need to speed up the time frame to increase transaction rate.

[spazzdla]

If they wanted to inflict damage, real damage they could have sent all that spam at once.
But the spam comes in waves starting and stopping to keep the backlog in a target area.

HUm perhaps this is a warning we have a flaw and not an attack.. you could be onto something.

NON THE LESS, we need to act.

[NewLiberty]

How would them trying to earn a better revenue by sending spam not be considered an attack? It is still a malicious event.

The cost is going to be greater than the revenue increase, unless this is being performed by all miners equivalently.

I suppose some of it depends on your definition of 'malice', it may be done by a non-miner, no one has confessed to it yet, yes?

[NewLiberty]

If they wanted to inflict damage, real damage they could have sent all that spam at once.
But the spam comes in waves starting and stopping to keep the backlog in a target area.

HUm perhaps this is a warning we have a flaw and not an attack.. you could be onto something.

NON THE LESS, we need to act.

If you MUST ACT:
Raise your fees on your transactions, and move on to something more interesting.

[dothebeats]

Maybe this isn't done and isn't meant to be an attack in the first place, but somehow a test to see how far can the network go as transaction volume raises. It's true that we have lower number of transactions happening per second in our network, but still even in that low number we are already experiencing some slowdowns. What more if the network faces a huge surge of users and transactions if bitcoin is widely adopted?

[pereira4]

It should be clear to everyone by now that the attacker means us no harm.
Its been 5 days now and the transaction back log has leveled off between 40k and 50k.
It is clear the intention of this (ongoing) attack is to increase transaction fees.
If the top mining pools are behind this they might even be turning a profit.


EDIT to help others understand:

If they wanted to inflict damage, real damage they could have sent all that spam at once.
If this was just a "statement about block size" Then the attacker has failed; thus the attacker would ether give up or increase the rate of spam.

How has the attacker failed? we have tons of people here complaining about transaction taking ages, if anything it proves we need blocksize increase and LN as well.

[anderson00673]

Very funny, saying that it is not a hostile attack is like saying that getting mugged is not a hostile attack either.  Hey, the guy just wants some extra spending cash right?  I don't know of any evidence that the mining companies are behind this, but if they are it is a shady way to make a buck.

[OmegaStarScream]

I would really apreciate if someone could finally answser my question , I keep seeing a lot of threads speaking about an"attack" however I don't understand which attack is this .
If I understood the topic right then it's a transaction spam how he is doing it , dosen't that costs him money or he is sending Satoshi's ? :/ and how we could prevent this . a block size increase should do the job , no ? take it easy on me because I don't understand much on block size and fork and those stuff ty

[DarkHyudrA]

If they wanted to inflict damage, real damage they could have sent all that spam at once.
But the spam comes in waves starting and stopping to keep the backlog in a target area.

I don't think so, sending transactions is time consuming(it takes a few seconds), so it would take more machines on and more money on the wallets.

[NeuroticFish]

I would really apreciate if someone could finally answser my question , I keep seeing a lot of threads speaking about an"attack" however I don't understand which attack is this .
If I understood the topic right then it's a transaction spam how he is doing it , dosen't that costs him money or he is sending Satoshi's ? :/ and how we could prevent this . a block size increase should do the job , no ? take it easy on me because I don't understand much on block size and fork and those stuff ty

1. It should, in theory, cost money indeed.
But from I've read, the attacker made a lot of transaction of tiny / dust inputs -> these cost far less than the overhead they make. And the inputs could have been relayed before the attack with no fee.
Also he/they made a lot of transactions with invalid recipients. -> I think that these get eventually rejected (for free).

2. There are other discussions on this, some pools / miners don't actually include transactions until the 1 MB limit. My feeling is that this area needs improvement before the block size increase.

[jbrnt]

I agree that the attack has not been cripling to the network. I do question the point of these waves of attacks or tests? If and when this is over, I hope the "testers" would come out and gives us a report of their findings and explain to us what they are trying to prove.

My personal findings from these attack is that we need the ability to add fees to our sent transactions to speed up confirmation. It's like appending another input and output to an unconfirmed transaction, the difference in the appended input and output would be the added fees.

[Quantus]

Stop calling it a test.

[dothebeats]

Stop calling it a test.

Whatever it is called, they've already proven a point: the network couldn't handle loads of transactions yet. Oh and it costed them money and time also, so all in all nothing is really achieved in here, just the annoying delays of transactions and unconfirmed transaction backlogs.

[OmegaStarScream]

I would really apreciate if someone could finally answser my question , I keep seeing a lot of threads speaking about an"attack" however I don't understand which attack is this .
If I understood the topic right then it's a transaction spam how he is doing it , dosen't that costs him money or he is sending Satoshi's ? :/ and how we could prevent this . a block size increase should do the job , no ? take it easy on me because I don't understand much on block size and fork and those stuff ty

1. It should, in theory, cost money indeed.
But from I've read, the attacker made a lot of transaction of tiny / dust inputs -> these cost far less than the overhead they make. And the inputs could have been relayed before the attack with no fee.
Also he/they made a lot of transactions with invalid recipients. -> I think that these get eventually rejected (for free).

2. There are other discussions on this, some pools / miners don't actually include transactions until the 1 MB limit. My feeling is that this area needs improvement before the block size increase.

But if the attack is basically shitload of transactions , won't that be a problem in the future too? I mean even if there isn't an attacker who is willing to take Bitcoin network down ... when Bitcoin will be mainstream , we will logically and obivously have shitload of transaction too , so basically the same result even if different methods ? 

[Quantus]

I would really apreciate if someone could finally answser my question , I keep seeing a lot of threads speaking about an"attack" however I don't understand which attack is this .
If I understood the topic right then it's a transaction spam how he is doing it , dosen't that costs him money or he is sending Satoshi's ? :/ and how we could prevent this . a block size increase should do the job , no ? take it easy on me because I don't understand much on block size and fork and those stuff ty

1. It should, in theory, cost money indeed.
But from I've read, the attacker made a lot of transaction of tiny / dust inputs -> these cost far less than the overhead they make. And the inputs could have been relayed before the attack with no fee.
Also he/they made a lot of transactions with invalid recipients. -> I think that these get eventually rejected (for free).

2. There are other discussions on this, some pools / miners don't actually include transactions until the 1 MB limit. My feeling is that this area needs improvement before the block size increase.

But if the attack is basically shitload of transactions , won't that be a problem in the future too? I mean even if there isn't an attacker who is willing to take Bitcoin network down ... when Bitcoin will be mainstream , we will logically and obivously have shitload of transaction too , so basically the same result even if different methods ?  

The network should be able too handle up to 10x the current level of transactions in the "unconfirmed transaction memory pool" (the mempool)  before the weaker nodes in the network run out of RAM. The issue is all full nodes in the network (the backbone of bitcoin) have to load the whole freaking mempool into RAM. When a node runs out of ram it will use the HDD or SSD. The issue is the larger the memory pool the longer it takes to verify and propagate transactions in a timely manner.  If the network slows down to much we get lots of little forks in the blockchain.

You see ... the mempool has no overflow and can't be deleted or reset without shutting down every node in the whole world at the same moment.

The only thing keeping unwanted transaction out of the network are "user configured settings" that run on each node that determine the cutoff limit for transactions. Each node decides if it wants to propagate a given transaction. If the fee is to low it won't forward it to the next node.

The current attacker is sending micro transactions with fees, each transaction + fee is = to 1/4 of one cent. But the fee is enough to bypass the networks minimum cut off limits for trash/spam/dust transactions.  Once a transaction is in the unconfirmed memory pool it has to be added to the blockchain but the miners decide when and in what order transactions are added based largely on the amount of fees the sender has attached to the transaction.  As Bitcoin grows in popularity the network will naturally over time adjust the cutoff limits (minimum fees) so in times of heavy load micro transactions (less then 1 cent) will be "put on the back burner" till higher priority (transactions with higher fees) use the network and when things calm down the smaller transactions will be validated.    

Sorry I had to edit this post like 20 times. I hope it helped and sorry for my bad spelling/grammar.

[d4n13]

How much is the cost of the attack?

Is there any analysis on this?

About $20,000 in fees so far, back of the envelope.

Assume 7 days (fix that for me if needed).
Assume 10000 sotoshi's / 1000 bytes which is more than the min, but a general default for low priority (fixed)
Assume attacker is holding the mempool at 50MB in backlog size.
Assume that 1MB blocks are being minted every 10 minutes (fix that for me if needed).

So 50MB worth of TX at 10000 sotoshis / 1000 bytes = 50 million sotoshis = 5 BTC to launch the attack.
6 MB / hour * 24 hours * 7 days = 1 GB of transactions = 100 BTC
====
Total = 105 BTC = $28,000

Honestly though, they could pull it off for $3,000, but the certainly have not spent more than $30k

[d4n13]

Nice infographic.  Chart of Fees for the last 30 days (link)

[pedrog]

How much is the cost of the attack?

Is there any analysis on this?

About $20,000 in fees so far, back of the envelope.

Assume 7 days (fix that for me if needed).
Assume 10000 sotoshi's / 1000 bytes which is more than the min, but a general default for low priority (fixed)
Assume attacker is holding the mempool at 50MB in backlog size.
Assume that 1MB blocks are being minted every 10 minutes (fix that for me if needed).

So 50MB worth of TX at 10000 sotoshis / 1000 bytes = 50 million sotoshis = 5 BTC to launch the attack.
6 MB / hour * 24 hours * 7 days = 1 GB of transactions = 100 BTC
====
Total = 105 BTC = $28,000

Honestly though, they could pull it off for $3,000, but the certainly have not spent more than $30k

Yap, way too cheap for a 4 billion dollar network, something has to change.

[d4n13]

Yap, way too cheap for a 4 billion dollar network, something has to change.

My vote:

• Enforce CPFP as a policy rule (using the secret magic wand)
• Convince the Wallet SW devs to implement CPFP in the wallet SW
• ?
• Profit!

[unamis76]

The attacker has already harmed the blockchain... just not by much.

[Quantus]

This is one of my posts from another thread but I think it could be helpful here as well.
---
A large amount of the transactions on the network are spam in my humble opinion. If you cut out all the transactions under 5 cents that's like 90% of the traffic. (even before the attack)

As Bitcoin grows in popularity the network will naturally over time adjust the cutoff limits (minimum fees) so in times of heavy load micro transactions (less then 1 cent) will be "put on the back burner" till higher priority transactions with higher fees use the network and then when things calm down the smaller transactions will be validated.

I say let the market miners decide the minimum transaction fee rate.  If it gos above 50 cents will have consensus for a small 2MB block increase.

The only risk right now is decoupling of the network (mico forks) because of propagation lag; this would only get worse right now if we increased the block size.

I, for one, welcome our new mining cartel overloads.

A possible fix would be to add optional code into our network nodes to change the minimum fee required per transaction size for propagation based on the current size of the mempool. The best part is its optional and dose not require a hard fork. As the mempool size increases the minimum fees necessary for propagation threw the network would rise accordingly. A simple sliding scale GUI could be added to all Full node clients for easy adjustment or be hard coded but configurable by only more tech savvy people.

[NeuroticFish]

The current attacker is sending micro transactions with fees, each transaction + fee is = to 1/4 of one cent. But the fee is enough to bypass the networks minimum cut off limits for trash/spam/dust transactions.  Once a transaction is in the unconfirmed memory pool it has to be added to the blockchain but the miners decide when and in what order transactions are added based largely on the amount of fees the sender has attached to the transaction.  As Bitcoin grows in popularity the network will naturally over time adjust the cutoff limits (minimum fees) so in times of heavy load micro transactions (less then 1 cent) will be "put on the back burner" till higher priority (transactions with higher fees) use the network and when things calm down the smaller transactions will be validated.    

Allright, it makes sense. However, for some reason, it seems that the old small fee transaction get older and older and the new ones are relayed correctly.
Also, while miners can add them because they didn't reach max block size, they just don't.

I understand now that this may be a speed or memory optimization, but some of those transactions may be legit and still there (unconfirmed), although they payed the required fee.
I have the feeling that the memory optimization just "forgets" the too old transactions in the case of some pools or nodes.

[johnyj]

This is merely a simulation about potential bank attack scenario when bitcoin really take over traditional banking services  

At its extreme, banks could print several billion dollars per day to facilitate magnitudes larger scale attack, in order to totally stop bitcoin network. But this simulation proved 3 things:

1. the attack won't stop the network totally, someone who are willing to pay a higher fee would not be affected, and because majority of coins are used for long term storage, people have the option to wait

2. nodes have certain flexibility to exclude spamming transactions, so that even some nodes were brought down by the excessive loads on mempool, many other nodes will just add some filter based on the attack, so the money spent on attack will basically achieve nothing but enrich miners

3. the exchange rate will jump during the attack, due to transaction capacity now becomes scarce and demand is even higher than before

[Kprawn]

I see it like this... The first two smaller spikes was a test run... They obviously worked out from the smaller "attacks" what the cost implications would be, before they ran the full blown attack.

If it was miners, they might have checked if, the transaction fees increased after the first and second attempt. {People trying to bump their transactions, by increasing their fees} <--- I doubt, if this would have happened so fast.

The fact that this person or persons, have backed away... without causing too much problems, shows me their intent. They want to make a point... I think this is person or a group of people, who want to prove that the block size needs to be increased. This test validated their claims.  

[Quantus]

I see it like this... The first two smaller spikes was a test run... They obviously worked out from the smaller "attacks" what the cost implications would be, before they ran the full blown attack.

If it was miners, they might have checked if, the transaction fees increased after the first and second attempt. {People trying to bump their transactions, by increasing their fees} <--- I doubt, if this would have happened so fast.

The fact that this person or persons, have backed away... without causing too much problems, shows me their intent. They want to make a point... I think this is person or a group of people, who want to prove that the block size needs to be increased. This test validated their claims.  

Its funny because a large number of people would say the exact opposite because the network propagation lag would only go up if we had larger blocks. Which would means more micro forks and more opportunities to scam people by sending a payment with a small fee and then sending the same payment again to another address with a higher fee during a micro fork.  
The bandwidth, speed and processing power (I'm talking about nodes) of the network is still to low for larger blocks at this time. We have to many people running full nodes on raspberry pi's and old laptops connect over wifi; for god sakes we have some 40% of the mining capacity of the network in china connected to the network over fucking copper phone lines.

A 8mb block size would require 150 to 300 confirmations before you could trust a incoming transaction because the network would be so god dam fucking fractured. (out of sync)

As far as China and parts of South America are concerned this is our network.
https://www.youtube.com/watch?v=dudJjUU9Nhs

[d4n13]

A possible fix would be to add optional code into our network nodes to change the minimum fee required per transaction size for propagation based on the current size of the mempool. The best part is its optional and dose not require a hard fork. As the mempool size increases the minimum fees necessary for propagation threw the network would rise accordingly. A simple sliding scale GUI could be added to all Full node clients for easy adjustment or be hard coded but configurable by only more tech savvy people.

I think a more preferable fix is already in the works.  CPFP and RBF.  Both will allow users to pay for a second transaction to "rescue" the first.  Economics will take care of the rest.  Once the mempool floods, users will start sending in high fee "rescue" transactions and all that will be left is the spam at the bottom of the pool.

[Cryddit]

As I write this my unconfirmed transaction pool is 73086 tx, or 182 Mbytes of transactions. 

Bitcoin at default rates, if every miner filled up every block to the 1Mbyte limit, could clear that in a bit over 18 hours - though it would easily take 36 given a "normal" number of tx in addition to the backlog.

As far as I'm concerned we can't get that 20Mbyte limit in place fast enough.

[Cryddit]

One possibility is that the current "stress test" is being done by holders in order to pump their coins before a sell. 

[The Sceptical Chymist]

It seems one needs a degree in computer science here to understand what's going on, and I don't have that.  I'm not even that f-ing intelligent.  Can anyone explain to me what this 'attack' is all about in very simple infant goo-goo talk?

Is this not a good reason to start using some altcoins?  I just did doge and ltc transactions today that went through quite fast.  I'm just asking.

Also, I'm not trying to spread any sort of fear, uncertainty, or doubt, but these transaction times are an absolute deal-breaker for using BTC to pay for anything face to face, like in a restaurant.  Am I right?

[Cryddit]

It seems one needs a degree in computer science here to understand what's going on, and I don't have that.  I'm not even that f-ing intelligent.  Can anyone explain to me what this 'attack' is all about in very simple infant goo-goo talk?

Is this not a good reason to start using some altcoins?  I just did doge and ltc transactions today that went through quite fast.  I'm just asking.

Also, I'm not trying to spread any sort of fear, uncertainty, or doubt, but these transaction times are an absolute deal-breaker for using BTC to pay for anything face to face, like in a restaurant.  Am I right?

In simple terms, the bitcoin network cannot handle more than a certain volume of transactions every hour.  This is in general a result of the system only producing one 'block' on average every ten minutes, and each 'block' containing only 1 Megabyte of space for transactions. 

This so-called "attack" consists of someone creating more than that number of transactions per hour.  The result is that transactions go into the "memory pool" - the set of transactions not yet included in a block - instead of getting quickly included in blocks.  And transactions in the memory pool get kicked out of the pool when the server running that node runs out of memory.  It's very probabilistic, but if your transaction stays in the memory pool long enough (days or weeks) it will probably get kicked out of everywhere and then it will never go through at all.

So if you make a transaction now, your transaction is in danger of going into the memory pool and staying there a long time, or maybe even getting dropped, because right now the memory pool is big enough to keep making blocks for 18 hours not even counting the usual transaction volume. 

If your transaction gets dropped, it'll be like it never happened - the coins will go back to the sender's wallet.

That means that if someone is sending you coins you need to be sure of some confirmations before you give them whatever they're paying for.  Confirmations mean that the transaction actually got into a block and became part of the permanent record of Bitcoin.

And if you're sending someone coins, and don't want to wait days for them to get confirmations and send you the stuff you're paying for, you need to cut in front of all these little transactions, by setting your transaction fees a little higher than those transactions are setting them.  Just a tiny bit (like an extra USAmerican penny) will do it.

Wow.  A 7900 bitcoin transaction just went by on my node.  Holy cow.  That's like, eight slices of Laszlo's pizza.

Anyway, the people making these transactions are paying transaction fees - which means they're paying the miners (a little bit) to include these transactions in the blocks that are being made.  So far they've committed $30K dollars to doing this.  The transactions will therefore stop when they either run out of money, accomplish whatever they're trying to do, or conclusively fail to accomplish whatever they're trying to do.

Anyway, it's not a good reason to start using altcoins.  At least I don't think it is.  It's just something that means that for as long as it lasts a bitcoin transaction will cost you an extra penny or so in fees.

[The Sceptical Chymist]

Cryddit, thank you for taking the time to write that, sir.  I have sent you a few satoshis as a tip, but we'll see if you actually get it.  I will make it a point not to insult you if we cross paths in the future.  As for the rest of the world, watch out.  

That is interesting.  I am a dope and use this faucet from which I got something like 0.004 btc, and it's been stuck in the queue all day long.  I now wonder if it'll ever arrive in my wallet!

[crazyearner]

Wounder what would happen if bigger attacks take place and one day succeed in damaging it. I still think to this day Bitcoin needs a massive re wright in security and its features too, sent a number of ideas over never heard much on them some got implemented and improvements did get made however sill if bitcoin did not have to be dependent on hash power as much or a option where if speed of transactions slows down something kicks in to keep the speed the same and does not effect miners.

[omahapoker]

How can it be NOT an attack when attacker are forcing us to pay higher fees? It's like blocking the road and demanding a fee for crossing.

It might be not a destructive attack but still it's an attack on the bitcoins of all users. And an attack on the free market since it's not so free anymore when someone can set the fees higher when he wants.