The attack on the network is not hostile

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