Ultimate Bitcoin Stress Test - Monday June 22nd - 13:00 GMT

[turvarya]

I think it actually took a lot of skill to carry this test out, and the results are fascinating now that I'm analyzing them.

The hacker had the same belief as the XT team that Bitcoin is in imminent danger from the blocksize limit, and spent a large sum of money to try and force the situation. There is no direct proof yet though.

Perhaps you should enlighten us on how the limit came into being instead of just saying you know more than I and storming out of the room. That certainly does not prove any point.

Based on some brief research Satoshi did indeed create the blocksize limit. And I definitely have a point regarding increasing transaction fees in the future helping facilitate mining, you just ignored that.

This commit, from July 2010, shows the actual commit that added the MAX_BLOCK_SIZE parameter. The commit doesn't actually even mention that the max block size was added, strangely enough. I suspect that it was done as part of a release that fixed a critical bug, so Satoshi could be sure that everyone would upgrade.

http://bitcoin.stackexchange.com/questions/37292/whats-the-purpose-of-a-maximum-block-size

I make it simple: Look at
https://bitcointalk.org/index.php?topic=1347.msg15366#msg15366
and tell me again, that Satoshi wanted the block size limit never to be raised.

[DooMAD]

but doing this sort of thing is extremely inconsiderate to Bitcoin users. Even if the intentions are to collect data it's still a malicious attack and hurt the Bitcoin economy today, very selfish.

Once again, your logic is proving difficult to follow.  If this short term period of disruption is "inconsiderate", "malicious" and "selfish", how is risking the network frequently running in such a fashion by imposing an artificial bottleneck somehow a reasonable option in your opinion?  Obviously these weren't important transactions because it was a test, so it's inconsequential that they weren't able to continue transacting.  But there will likely come a time when more people start to use Bitcoin for normal transactions.  If the userbase is sufficiently large enough, what we've seen in this test would be the tip of the iceberg.  It will be regular users that are forced to stop sending transactions because of delays or unexpected rises in cost and this will be far more damaging to Bitcoin's longevity than any supposedly malicious test.  If Bitcoin doesn't scale, the users that can't be accommodated comfortably will simply switch to a more convenient payment method.  One that doesn't have varying fees and unexpected delays.

The hacker had the same belief as the XT team that Bitcoin is in imminent danger from the blocksize limit, and spent a large sum of money to try and force the situation. There is no direct proof yet though.

Firstly, "hacker"?  Seriously?  Your attempts to discredit anyone who disagrees with you are laughable.  Secondly, anyone with eyes can see that the blocksize limit is an issue, otherwise there wouldn't be so many threads discussing it.  Not everything is some bizarre conspiracy.  

In fact, I think this proved that Bitcoin naturally responds to such an attack/transaction volume increase naturally and eliminates the problem. Transaction fees simply go up so people stop sending spam/dust transactions and only important transactions. This suggests a blocksize increase isn't necessary.

Just understand that once there are more users, it won't just be spam or dust transactions, it was be all transactions that are subject to these conditions.  You will be paying the extra fees when the network is busy and if people pay a higher fee than you, it's your transactions that might be delayed.  We've never run the network in that fashion before, but if you want to attempt that, then it's your decision to vote that way if you mine or run a node.

[DooMAD]

So you completely fail to see my point that transaction fees will be the only thing keeping mining alive in the future? If we went along with XT Bitcoin would die as block rewards become tiny.

Nope, got it completely backwards again.  If there were no block reward right now, miners would have little incentive to secure the network with the amount of fees currently collected.  

If, hypothetically, there was no block reward right now, based on the transaction volume we are getting now, how much fee would need to be paid on each transaction to give at least the current average level of fees plus the 25 BTC reward?  Last time I bothered to do the math, we were averaging about 750 transactions per block.  By my figures, each transaction would have to have a fee of about .034 BTC just to cover the 25 BTC reward, plus a bit extra for the current fees that are already being paid (so there's no loss of mining revenue).  How many people are going to pay about $8 or $9 USD in fees for every single transaction?  Most would switch to an altcoin in a heartbeat if Bitcoin became that expensive.  If people aren't willing to pay that much, there will be even fewer transactions and that cost will then rise even further.  But increase the number of transactions in the block, rather than limiting it, then you can spread that cost over a greater number of users, making it more affordable.  Obviously we can squeeze in a few more than the 750 we're averaging at the moment, but we genuinely do need more users than the system will currently support to make this thing sustainable in future.  Unless you foresee Bitcoin becoming a niche, elitist, isolated haven for wealthy one-percenters, there is simply no other option than to accommodate more users.  More users equals more fees for miners, not less.

[DooMAD]

Limited block size would absolutely not limit the amount of users, everyone can send as much transactions as they want at any time as long as they pay a fee. Even if it's a few dollars that's still pretty good, especially if bitcoin is well over $1000 by then, and it damn well should be.

Categorically 100% false.  The 1MB limit is currently a hard limit, so by it's very definition, it limits that number of transactions the network can process.  If, for example, there were 20MB worth of transactions waiting, even if everyone paid over $10 dollars in fees, the network is unable to process them all in one go.  It would take 20 blocks to clear them with a 1MB blocksize.  That's likely to be over 3 hours for some of those transactions.  Would you not be annoyed if you paid a fee and still found you had to wait 3 hours because other people had paid a higher fee?  However, with an 8MB blocksize, you will still pay a fee to prioritise your transaction, but we could clear that queue in three blocks.  On average you'd be waiting 30 minutes at most.  This is the part most people don't seem to comprehend.  As the userbase grows, the blocksize must grow to accommodate it.

[unamis76]

It will be interesting to see if this stress test brings about a solution to the block size problem. Hopefully we can find a solution to ensure that the blockchain continues to function without any issues or unnecessary delays.

This test isn't really going to change anything, or bring any solutions... This is only raising awareness of a problem we already know we have, it isn't proposing anything new. It's an interesting test, but with a predictable outcome for which the solution is already in discussion for quite some time, and there is already code ready to be deployed that helps prevent a situation like this.

Yes, the test is meaningless - it's an annoyance aiming at price manipulation.

The solution to stop spam attacks like this is certainly not a max_blocksize increase, because even at 20x times the blocksize the resources needed to perform such an attack are still extremely small for any serious attacker.

The practical solution for now is: Prioritize your transaction by sending it with an adequate fee.

The general solution is: Increase fees for spam transactions, i.e. fees should rise non-linearly (maybe exponentially) for small-value transactions with big data size.

ya.ya.yo!

Uh.. NO. If they wanted to manipulate the price, they wouldn't have announced this; then people might start panicking not knowing who is attacking the system. That will manipulate the price.

Exactly, this was obviously never going to affect the price whatsoever. And I highly doubt it would if it was unannounced

The test data is interesting and useful, but doing this sort of thing is extremely inconsiderate to Bitcoin users. Even if the intentions are to collect data it's still a malicious attack and hurt the Bitcoin economy today, very selfish.

My thoughts exactly.


As for their reddit post... Another test in 7 days? Wasn't this enough? What are these people trying to achieve? They are ruining their own business

And I'll be waiting for that data in the next few hours, it better be good in order to "compensate" for the slow transactions...

[johnyj]

The fee is based on network data usage, not the amount of bitcoin, so it will always benefit the large transactions. To hold the promise of cheap fee for small transactions, block size must be expanded

[bri912678]

...........


As for their reddit post... Another test in 7 days? Wasn't this enough? What are these people trying to achieve? They are ruining their own business

And I'll be waiting for that data in the next few hours, it better be good in order to "compensate" for the slow transactions...

Does anyone know who is really behind their business?

Their website is registered anonymously and their company address is also registered through a service that hides the true owners identity. The company is only a few months old and nobody had heard of it before the stress test. The whole company could be a front for someone with an agenda.

[DooMAD]

Limited block size would absolutely not limit the amount of users, everyone can send as much transactions as they want at any time as long as they pay a fee. Even if it's a few dollars that's still pretty good, especially if bitcoin is well over $1000 by then, and it damn well should be.

Categorically 100% false.  The 1MB limit is currently a hard limit, so by it's very definition, it limits that number of transactions the network can process.  If, for example, there were 20MB worth of transactions waiting, even if everyone paid over $10 dollars in fees, the network is unable to process them all in one go.  It would take 20 blocks to clear them with a 1MB blocksize.  That's likely to be over 3 hours for some of those transactions.  Would you not be annoyed if you paid a fee and still found you had to wait 3 hours because other people had paid a higher fee?  However, with an 8MB blocksize, you will still pay a fee to prioritise your transaction, but we could clear that queue in three blocks.  On average you'd be waiting 30 minutes at most.  This is the part most people don't seem to comprehend.  As the userbase grows, the blocksize must grow to accommodate it.

This is the same flawed thinking that led to Bitcoin XT. Confirmation time will always be on average 10 minutes for transactions with the proper fees.

I can assure you there is no flaw in what I've said, I've simply described how the protocol works.  You're the one who fails to understand it correctly.  The confirmation time for some of the transactions will be on average 10 minutes.  But if there are more than 1MB worth of transactions waiting, even if every single one of those transaction has a fee included, some of those transactions will have to wait for another block with space available if we stick with a 1MB limit.  If that still doesn't make sense to you, then I'm afraid I can't take your arguments seriously.  It's no wonder you're unduly panicked by the whole situation if you haven't taken the time and effort to understand why the fork is being proposed.  If you continue to post unsubstantiated accusations, wild conspiracy theories and outright fallacious statements, it's unlikely anyone else will take you seriously either.

[turvarya]

I think it actually took a lot of skill to carry this test out, and the results are fascinating now that I'm analyzing them.

The hacker had the same belief as the XT team that Bitcoin is in imminent danger from the blocksize limit, and spent a large sum of money to try and force the situation. There is no direct proof yet though.

Perhaps you should enlighten us on how the limit came into being instead of just saying you know more than I and storming out of the room. That certainly does not prove any point.

Based on some brief research Satoshi did indeed create the blocksize limit. And I definitely have a point regarding increasing transaction fees in the future helping facilitate mining, you just ignored that.

This commit, from July 2010, shows the actual commit that added the MAX_BLOCK_SIZE parameter. The commit doesn't actually even mention that the max block size was added, strangely enough. I suspect that it was done as part of a release that fixed a critical bug, so Satoshi could be sure that everyone would upgrade.

http://bitcoin.stackexchange.com/questions/37292/whats-the-purpose-of-a-maximum-block-size

I make it simple: Look at
https://bitcointalk.org/index.php?topic=1347.msg15366#msg15366
and tell me again, that Satoshi wanted the block size limit never to be raised.

So you completely fail to see my point that transaction fees will be the only thing keeping mining alive in the future? If we went along with XT Bitcoin would die as block rewards become tiny.

Regarding Satoshi, he would've changed the limit by now if it was prudent. I think he probably knew before anyone that having a blocksize limit will sustain miner revenue once it becomes an issue decades from now.

Please stop presenting your speculations as fact and please stop pretending like you are one of the chosen ones, who understand Satoshis thoughts.
It's because of people like you, that some people see us Bitcoin users as cult.
If you would do some research, you would actually understand, that Satoshi was not godlike. Read his posts on this forum and you see, that he was making stuff up, while going along.  There is no reason, why he should have "known things, but didn't tell us". Read his posts and see, that he talked freely about his ideas and was very open minded to ideas from others.

[findftp]

Limited block size would absolutely not limit the amount of users, everyone can send as much transactions as they want at any time as long as they pay a fee. Even if it's a few dollars that's still pretty good, especially if bitcoin is well over $1000 by then, and it damn well should be.

Categorically 100% false.  The 1MB limit is currently a hard limit, so by it's very definition, it limits that number of transactions the network can process.  If, for example, there were 20MB worth of transactions waiting, even if everyone paid over $10 dollars in fees, the network is unable to process them all in one go.  It would take 20 blocks to clear them with a 1MB blocksize.  That's likely to be over 3 hours for some of those transactions.  Would you not be annoyed if you paid a fee and still found you had to wait 3 hours because other people had paid a higher fee?  However, with an 8MB blocksize, you will still pay a fee to prioritise your transaction, but we could clear that queue in three blocks.  On average you'd be waiting 30 minutes at most.  This is the part most people don't seem to comprehend.  As the userbase grows, the blocksize must grow to accommodate it.

This is the same flawed thinking that led to Bitcoin XT. Confirmation time will always be on average 10 minutes for transactions with the proper fees.

I can assure you there is no flaw in what I've said, I've simply described how the protocol works.  You're the one who fails to understand it correctly.  The confirmation time for some of the transactions will be on average 10 minutes.  But if there are more than 1MB worth of transactions waiting, even if everyone has paid a fee, some of those transactions will have to wait for another block with space available if we stick with a 1MB limit.  If that still doesn't make sense to you, then I'm afraid I can't take your arguments seriously.  It's no wonder you're unduly panicked by the whole situation if you haven't taken the time and effort to understand why the fork is being proposed.  If you continue to post unsubstantiated accusations, wild conspiracy theories and outright fallacious statements, it's unlikely anyone else will take you seriously either.

He said "on average"
So, If you have to wait for a day to have your transaction confirmed, viewed from a years perspective all transactions will be 10 minutes on average.
Not sure if he meant it like this, but it's true, not?

Eventually spammers will run out of ammo and everything comes back to normal.
Sure, temporarily you have a problem, but it will solve itself in the long run.
Especially when price has to rise due to increase of transaction costs.
Price have to rise because spammers have to buy back their coins when they're out of ammo.


Edit:
Although I don't necessarily like to wait for a day to have my transaction confirmed, I don't see it as a big problem either.
I think native bitcoin will never be used to buy yourself a coffee

[turvarya]

Limited block size would absolutely not limit the amount of users, everyone can send as much transactions as they want at any time as long as they pay a fee. Even if it's a few dollars that's still pretty good, especially if bitcoin is well over $1000 by then, and it damn well should be.

Categorically 100% false.  The 1MB limit is currently a hard limit, so by it's very definition, it limits that number of transactions the network can process.  If, for example, there were 20MB worth of transactions waiting, even if everyone paid over $10 dollars in fees, the network is unable to process them all in one go.  It would take 20 blocks to clear them with a 1MB blocksize.  That's likely to be over 3 hours for some of those transactions.  Would you not be annoyed if you paid a fee and still found you had to wait 3 hours because other people had paid a higher fee?  However, with an 8MB blocksize, you will still pay a fee to prioritise your transaction, but we could clear that queue in three blocks.  On average you'd be waiting 30 minutes at most.  This is the part most people don't seem to comprehend.  As the userbase grows, the blocksize must grow to accommodate it.

This is the same flawed thinking that led to Bitcoin XT. Confirmation time will always be on average 10 minutes for transactions with the proper fees.

I can assure you there is no flaw in what I've said, I've simply described how the protocol works.  You're the one who fails to understand it correctly.  The confirmation time for some of the transactions will be on average 10 minutes.  But if there are more than 1MB worth of transactions waiting, even if everyone has paid a fee, some of those transactions will have to wait for another block with space available if we stick with a 1MB limit.  If that still doesn't make sense to you, then I'm afraid I can't take your arguments seriously.  It's no wonder you're unduly panicked by the whole situation if you haven't taken the time and effort to understand why the fork is being proposed.  If you continue to post unsubstantiated accusations, wild conspiracy theories and outright fallacious statements, it's unlikely anyone else will take you seriously either.

He said "on average"
So, If you have to wait for a day to have your transaction confirmed, viewed from a years perspective all transactions will be 10 minutes on average.
Not sure if he meant it like this, but it's true, not?

Eventually spammers will run out of ammo and everything comes back to normal.
Sure, temporarily you have a problem, but it will solve itself in the long run.
Especially when price has to rise due to increase of transaction costs.
Price have to rise because spammers have to buy back their coins when they're out of ammo.


Edit:
Although I don't necessarily like to wait for a day to have my transaction confirmed, I don't see it as a big problem either.
I think native bitcoin will never be used to buy yourself a coffee

We should make clear, that there are 2 different things, we are talking about: Time to find a block, and the time till a transactions goes into a block. The average 10 min are the time it takes for a block to be found not the time till a transactions goes into a block.

And more importantly: You might not care if it takes a day, for your transaction to be confirmed, but a vendor does. There is a limit how long a unconfirmed transaction remains in the mem pool, after that, it gets deleted and the vendor doesn't get his money.

[DooMAD]

Limited block size would absolutely not limit the amount of users, everyone can send as much transactions as they want at any time as long as they pay a fee. Even if it's a few dollars that's still pretty good, especially if bitcoin is well over $1000 by then, and it damn well should be.

Categorically 100% false.  The 1MB limit is currently a hard limit, so by it's very definition, it limits that number of transactions the network can process.  If, for example, there were 20MB worth of transactions waiting, even if everyone paid over $10 dollars in fees, the network is unable to process them all in one go.  It would take 20 blocks to clear them with a 1MB blocksize.  That's likely to be over 3 hours for some of those transactions.  Would you not be annoyed if you paid a fee and still found you had to wait 3 hours because other people had paid a higher fee?  However, with an 8MB blocksize, you will still pay a fee to prioritise your transaction, but we could clear that queue in three blocks.  On average you'd be waiting 30 minutes at most.  This is the part most people don't seem to comprehend.  As the userbase grows, the blocksize must grow to accommodate it.

This is the same flawed thinking that led to Bitcoin XT. Confirmation time will always be on average 10 minutes for transactions with the proper fees.

I can assure you there is no flaw in what I've said, I've simply described how the protocol works.  You're the one who fails to understand it correctly.  The confirmation time for some of the transactions will be on average 10 minutes.  But if there are more than 1MB worth of transactions waiting, even if everyone has paid a fee, some of those transactions will have to wait for another block with space available if we stick with a 1MB limit.  If that still doesn't make sense to you, then I'm afraid I can't take your arguments seriously.  It's no wonder you're unduly panicked by the whole situation if you haven't taken the time and effort to understand why the fork is being proposed.  If you continue to post unsubstantiated accusations, wild conspiracy theories and outright fallacious statements, it's unlikely anyone else will take you seriously either.

He said "on average"
So, If you have to wait for a day to have your transaction confirmed, viewed from a years perspective all transactions will be 10 minutes on average.
Not sure if he meant it like this, but it's true, not?

Eventually spammers will run out of ammo and everything comes back to normal.
Sure, temporarily you have a problem, but it will solve itself in the long run.
Especially when price has to rise due to increase of transaction costs.
Price have to rise because spammers have to buy back their coins when they're out of ammo.


Edit:
Although I don't necessarily like to wait for a day to have my transaction confirmed, I don't see it as a big problem either.
I think native bitcoin will never be used to buy yourself a coffee

If users had to wait a day to have their transaction confirmed, do you really think they'd continue to use Bitcoin after that?  What's the incentive for a user to continue using Bitcoin if there's another coin that will confirm their transaction faster and with a lower fee?  At the moment, Bitcoin has a reputation for being fast, reliable and cheap.  Are people really willing to jeopardise those three fantastic qualities?  If people start to think of Bitcoin as expensive, unreliable and slow, do you not think there would be less volume on the network and even less fees paid to miners?  No one can say with any certainty how it will play out, but I don't think people will stick to Bitcoin out of loyalty alone if another coin can offer a better service.  In a free market, Bitcoin has to remain competitive to retain its top spot.  

Also, try not to conflate spam and dust transactions with the blocksize issue.  Even if those transactions are forced off the blockchain, there will come a time where the userbase grows to a level where we can easily fill a 1MB block with legitimate, fee-paying transactions.  That's when legitimate transactions start getting delayed and people flock to this forum and other social media to whine and complain about it.  If the users are unhappy, consider how unhappy the merchants will be when they have a business to run and their income is delayed.  Then everyone realises the mistake and tries to rush through a fork at the last minute anyway.  That's not a sustainable path in my view.  It's much less disruptive to get the fork out of the way, before the complaints start to flood in and Bitcoin's reputation takes a massive hit in the process.  The blocksize increase is inevitable, it's just a matter of how painless you'd like the transition to be.

[scarsbergholden]

I can now see why the blocksize issue is a major part in todays talks and issues with bitcoin, took my time reading part of everyone responses and a lot of people are now seeing the light to the blocksize incrementation, I know not everyone was part of the stress test but even with this it shows we could wait a while to get a confirmation.

[findftp]

Edit:
Although I don't necessarily like to wait for a day to have my transaction confirmed, I don't see it as a big problem either.
I think native bitcoin will never be used to buy yourself a coffee

And more importantly: You might not care if it takes a day, for your transaction to be confirmed, but a vendor does. There is a limit how long a unconfirmed transaction remains in the mem pool, after that, it gets deleted and the vendor doesn't get his money.

I see bitcoin as a payment system for long physical distance transfer.
If I buy something from China I usually have to wait 2 or 3 weeks to get my item.
I don't care if it'll take another extra day.
The vendor can prepare the shipment and wait for the confirmation. If it gets removed from the mempool he can send me another payment request.
I assume the vendor usually collects his orders and send them next day.
So then an incidental hickup in the network is not a big deal.

Like I said, I don't see bitcoin being used for day to day local grocery payment.

[monsanto]

I'm not trying to hijack this thread but I am curious: If it costs $5000 to perform this test on bitcoin, how much would it cost for an equivalent stress test on litecoin?

[SuperClam]

two things:
1. Perhaps it was because of the backlash they received here, because they were concerned for innocent bitcoiners as well, that they did not do a full 24 hours as they had originally promised.
2. increasing fees isn't a solution; it'll cause less people to use bitcoin which is detrimental.

Storing data is not "free".
The marginal cost of a transaction is a very real metric; especially in a system that expects that data to be stored by all participants for an extended period of time.
Ignoring this fact, does not make it go away.
The Bitcoin "ledger" and block chain is a globally replicated database.
Expecting to store your transaction data in it for little or no fees is irresponsible and selfish.

And ignoring the fact that as a currency, fees should be sufficiently low does not make it go away. I thought bitcoin wants to succeed as a currency, not just a database storage system?

Pragmatism and cost, simply by being un-ignorable, will always out-weight semantic definitions.

[elrippo]

Maybe the Bitcoin XT developers did this to spread FUD about bitcoin's integrity?

There's been no updates about results even though the test is over, I think their attack was way less harmful than projected and they don't even wanna talk about it, 20 BTC was gone within a few hours since the transaction fees went up and they didn't properly account for that.

There's delays of a few hours sometimes even when the bitcoin network is totally normal, so this didn't prove much. If someone really hated Bitcoin and had a million dollars to blow it wouldn't last more than a day, so it's an unlikely threat.

In fact, I think this proved that Bitcoin naturally responds to such an attack/transaction volume increase naturally and eliminates the problem. Transaction fees simply go up so people stop sending spam/dust transactions and only important transactions. This suggests a blocksize increase isn't necessary.

Real scientists would be happy to have a result and discuss it rather than disappear. This was not done by scientists, the illusion that it was an experiment to better understand Bitcoin is false. Those behind this 'test' only wanted to make Bitcoin look like it needs XT to survive. I'm fairly certain this was a stunt by Gavin and his buddies. If my suspicion is right then we certainly cannot trust the Bitcoin XT devs, they are willing to destabilize the inner workings of Bitcoin and hurt the Bitcoin economy, in order to spread fear among Bitcoiners so that they can gain control of Bitcoin's code. Fortunately it backfired, I think they were willing to delay transactions for over a day and cause some real damage.

Who else would spend 20 Bitcoins on this and try to be completely anonymous? No one...

You are pretty arrogant.
This "Stress Test" simulates an adoption of Bitcoin by 10% of the world population. If 10% of the world population uses Bitcoin, than you are screwed with low fees.
I have no problem with low fees. If your pament is not superduperhyperurgent, i can wait 12 hours for it to be confirmed.
This does not imply that my personal transactions are dust, or your tiny peace of BTC are dust.
Despite this "spamming" or "stress test" on a live system is a good test to show vulnerabilites which are hard to perform on a testsystem, BTC devs voted for an enlargement of the blockchain size. Please remember, BTC is adopted by geeks and people who have a strong interest in keepnig their transactions anonymous, this "stress test" shows one vulnerability of many regarding BTC.
If one entity has more than 51% of the mining power and starts making several transactions as this "stress test" (which failed but will be repeated next monday), BTC will fall apart...
Bitcoin community should rethink the Blocksize change and honor this test or you use XMR Monero where you will not face this kind of problem and the other ones that BTC has  

[KingAfurah]

On monday, CoinWallet.eu conducted a stress test of the Bitcoin blockchain. Not only was our plan to see the outcome, but also to see how easy it would be for a malicious entity or government to create havoc for the Bitcoin community. As you will see from the analysis below, delayed transactions are not the only issue that Bitcoin users experienced.

Surprisingly, executing tens of thousands of transactions that correctly propagate to the network simultaneously is not as easy as we had expected. One of the methods that was used to increase the kb size of our transactions was to send transactions consisting of numerous small outputs (usually 0.0001) to make a single transaction of 0.01. A simple transaction is usually 225-500 bytes, while many of our transactions were 18 kb (A number which limits the blockchain to 5 transactions per minute). In our preliminary testing this was effective, however in practice it caused our servers to crash. Throughout the day and evening, our strategy and methodology changed multiple times.

Initially the plan was to spend 20 BTC on transaction fees to flood the network with as many transactions as possible. Due to technical complications the test was concluded early, with less than 2 BTC spent on fees. The events of yesterday were accomplished with less than €500.

Timeline

    11:57 GMT - Transaction servers initiated. Thousands of 700 kb transactions completed within the first 20 minutes. Transactions were used to break coins into small 0.0001 outputs.
    12:30 GMT - Servers begin sending larger 18kb transactions.
    14:10 GMT - Mempool size increases dramatically. Blockchain.info breaks.
    14:20 GMT - Our servers begin to crash. It becomes apparent that BitcoinD is not well suited to crafting transactions of this size.
    14:30 GMT - Our test transactions are halted while alternate solutions are created. The mempool is at 12 mb.
    17:00 GMT - Alternate transaction sending methods are started. Servers are rebooted. Mempool has fallen to 4mb.
    21:00 GMT - The stress test is stronger than ever. Mempool reaches 15 mb and more than 14000 transactions are backlogged. The situation is made worse by F2Pool selfishly mining two 0kb blocks in a row.
    23:59 GMT - 12 hours after starting, the test is concluded. Less than 2 BTC (€434) is spent on the test in total.

The following graph depicts the entire test from start to finish: https://anduck.net/bitcoin/mempool.png

Observations

Delayed confirmation times and large mempool buildups were not the only observation that came from our testing. Many more services were impacted than we had initially envisioned.

Blockchain.info

Over the past few months, Blockchain.info has become increasingly unreliable, however we are confident that yesterday's stress test had an impact on their website being offline or broken for 1/3 of the day. During periods where we sent excessive transactions, Blockchain.info consistently froze. It appeared as though their nodes were overwhelmed and simply crashed. Each time this occurred, the site would re-emerge 10-30 minutes later only to fail again shortly thereafter. Users of the blockchain wallet were unable to send transactions, login or even view balances during the downtimes. In response to our heavy Bitcoin usage, blockchain.info began to exclude certain transactions from their block explorer. This issue is explored further by the creators of Multibit, who can confirm that some transactions sent from their software were ignored by Blockchain, but were picked up by Blockr.

Bitcoin ATMs

Many ATMs operate as full nodes, however some ATMs rely on third party wallet services to send and receive transactions. The most prominent Bitcoin ATM of this type is Lamassu, which uses the blockchain.info API to push outgoing transactions from a blockchain.info wallet. Due to the blockchain.info issues, all Lamassu ATMs that use blockchain.info's wallet service were unavailable for the day.

MultiBit

Both versions of MultiBit suffered delayed transactions due to the test. Gary and Jim from MultiBit have created a full analysis from Multibit's perspective which can be read at https://multibit.org/blog/2015/06/23/bitcoin-network-stress-test.html

The outcome was that transactions with the standard fee in Multibit HD took as many as 80 blocks to confirm (Approximately 13 hours). Standard 10000 satoshi fee transactions took an average of 9 blocks to get confirmed. Multibit has stated that they will be making modifications to the software to better cope with this type of event in the future.

Tradeblock

With Blockchain.info broken, we frequently referred to Tradeblock to track the backlog. Unfortunately Tradeblock was less than perfectly reliable and often failed to update when a new block had been mined. Regardless, at one point 15,000 unconfirmed transactions were outstanding.

Bitpay

Users reported issues with Bitpay not recognizing transactions during the test.

Price

Increase of $2. Contrary to some predictions, we did not short Bitcoin.

Green Address

While this app was not hindered directly by our test, we did send a series of 0.001 payments to a green address wallet. When attempting to craft a transaction from the wallet, an error occurs stating that it is too large. It appears that the coins that were sent to this wallet may be lost.

Conclusions

From a technical perspective, the test was not a success. Our goal of creating a 200mb backlog was not achieved due to miscalculations and challenges with pushing the number of transactions that we had desired. We believe that future tests may easily achieve this goal by learning from our mistakes. There are also numerous vulnerable services that could be exploited as part of a test, including Bitcoin casinos, on-chain gambling websites, wallets (Coinbase specifically pointed out that a malicious user could take advantage of their hosted wallet to contribute to the flooding), exchanges, and many others. Users could also contribute by sending small amounts to common brain wallets.

We also learned that the situation could have been made worse by sending transactions with larger fees. We sent all transactions with the standard fee of 10000 satoshis per kb. If we had sent with 20000 satoshis per kb, normal transactions would have experienced larger delays. In our future stress tests, these lessons will be used to maximize the impact.

[turvarya]

On monday, CoinWallet.eu conducted a stress test of the Bitcoin blockchain. Not only was our plan to see the outcome, but also to see how easy it would be for a malicious entity or government to create havoc for the Bitcoin community. As you will see from the analysis below, delayed transactions are not the only issue that Bitcoin users experienced.

Surprisingly, executing tens of thousands of transactions that correctly propagate to the network simultaneously is not as easy as we had expected. One of the methods that was used to increase the kb size of our transactions was to send transactions consisting of numerous small outputs (usually 0.0001) to make a single transaction of 0.01. A simple transaction is usually 225-500 bytes, while many of our transactions were 18 kb (A number which limits the blockchain to 5 transactions per minute). In our preliminary testing this was effective, however in practice it caused our servers to crash. Throughout the day and evening, our strategy and methodology changed multiple times.

Initially the plan was to spend 20 BTC on transaction fees to flood the network with as many transactions as possible. Due to technical complications the test was concluded early, with less than 2 BTC spent on fees. The events of yesterday were accomplished with less than €500.

Timeline

    11:57 GMT - Transaction servers initiated. Thousands of 700 kb transactions completed within the first 20 minutes. Transactions were used to break coins into small 0.0001 outputs.
    12:30 GMT - Servers begin sending larger 18kb transactions.
    14:10 GMT - Mempool size increases dramatically. Blockchain.info breaks.
    14:20 GMT - Our servers begin to crash. It becomes apparent that BitcoinD is not well suited to crafting transactions of this size.
    14:30 GMT - Our test transactions are halted while alternate solutions are created. The mempool is at 12 mb.
    17:00 GMT - Alternate transaction sending methods are started. Servers are rebooted. Mempool has fallen to 4mb.
    21:00 GMT - The stress test is stronger than ever. Mempool reaches 15 mb and more than 14000 transactions are backlogged. The situation is made worse by F2Pool selfishly mining two 0kb blocks in a row.
    23:59 GMT - 12 hours after starting, the test is concluded. Less than 2 BTC (€434) is spent on the test in total.

The following graph depicts the entire test from start to finish: https://anduck.net/bitcoin/mempool.png

Observations

Delayed confirmation times and large mempool buildups were not the only observation that came from our testing. Many more services were impacted than we had initially envisioned.

Blockchain.info

Over the past few months, Blockchain.info has become increasingly unreliable, however we are confident that yesterday's stress test had an impact on their website being offline or broken for 1/3 of the day. During periods where we sent excessive transactions, Blockchain.info consistently froze. It appeared as though their nodes were overwhelmed and simply crashed. Each time this occurred, the site would re-emerge 10-30 minutes later only to fail again shortly thereafter. Users of the blockchain wallet were unable to send transactions, login or even view balances during the downtimes. In response to our heavy Bitcoin usage, blockchain.info began to exclude certain transactions from their block explorer. This issue is explored further by the creators of Multibit, who can confirm that some transactions sent from their software were ignored by Blockchain, but were picked up by Blockr.

Bitcoin ATMs

Many ATMs operate as full nodes, however some ATMs rely on third party wallet services to send and receive transactions. The most prominent Bitcoin ATM of this type is Lamassu, which uses the blockchain.info API to push outgoing transactions from a blockchain.info wallet. Due to the blockchain.info issues, all Lamassu ATMs that use blockchain.info's wallet service were unavailable for the day.

MultiBit

Both versions of MultiBit suffered delayed transactions due to the test. Gary and Jim from MultiBit have created a full analysis from Multibit's perspective which can be read at https://multibit.org/blog/2015/06/23/bitcoin-network-stress-test.html

The outcome was that transactions with the standard fee in Multibit HD took as many as 80 blocks to confirm (Approximately 13 hours). Standard 10000 satoshi fee transactions took an average of 9 blocks to get confirmed. Multibit has stated that they will be making modifications to the software to better cope with this type of event in the future.

Tradeblock

With Blockchain.info broken, we frequently referred to Tradeblock to track the backlog. Unfortunately Tradeblock was less than perfectly reliable and often failed to update when a new block had been mined. Regardless, at one point 15,000 unconfirmed transactions were outstanding.

Bitpay

Users reported issues with Bitpay not recognizing transactions during the test.

Price

Increase of $2. Contrary to some predictions, we did not short Bitcoin.

Green Address

While this app was not hindered directly by our test, we did send a series of 0.001 payments to a green address wallet. When attempting to craft a transaction from the wallet, an error occurs stating that it is too large. It appears that the coins that were sent to this wallet may be lost.

Conclusions

From a technical perspective, the test was not a success. Our goal of creating a 200mb backlog was not achieved due to miscalculations and challenges with pushing the number of transactions that we had desired. We believe that future tests may easily achieve this goal by learning from our mistakes. There are also numerous vulnerable services that could be exploited as part of a test, including Bitcoin casinos, on-chain gambling websites, wallets (Coinbase specifically pointed out that a malicious user could take advantage of their hosted wallet to contribute to the flooding), exchanges, and many others. Users could also contribute by sending small amounts to common brain wallets.

We also learned that the situation could have been made worse by sending transactions with larger fees. We sent all transactions with the standard fee of 10000 satoshis per kb. If we had sent with 20000 satoshis per kb, normal transactions would have experienced larger delays. In our future stress tests, these lessons will be used to maximize the impact.

Thanks for your analyses.
Do you already know, when you will do some other tests?
Some people have stated that such a test schould not be announced. What do you think about that?

[sniveling]

When I tried to access blockchain.info I got a cloudflare error stating the blockchain.info itself was offline, and that he problem was nothing to do with the cloudflare service. I tried again after a few minutes and blockchain.info was back online again. Their service was intermittently disrupted by the stress test which must have created problems for the customers.

Will you be doing another test in 7 days or a different time frame?