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.
Topic: The attack on the network is not hostile (Read 1948 times)
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.
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!
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!
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?
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.
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?
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?
One possibility is that the current "stress test" is being done by holders in order to pump their coins before a sell.
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.
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.
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. 
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.
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
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.
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.
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
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
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.
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 themarket 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.
---
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
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.
The attacker has already harmed the blockchain... just not by much.
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!
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.Is there any analysis on this?
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.
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.Is there any analysis on this?
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
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
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.
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
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 ?
Jump to: