Topic: Ultimate Bitcoin Stress Test - Monday June 22nd - 13:00 GMT - page 12. (Read 21455 times)

Since testnet coins are designed to have zero economic value, any economic experiments with testnet coins should not yield any valid results.

I do agree that bitcoin will continue working just fine while (and after) this test is being done, and yes they are being an asshole to anyone trying to spend bitcoin while they are doing this test, however I would argue that a real world example as to how the fee market would react to consistently full blocks would give us a better idea as to what will eventually happen if the max block size is not increased.

I will however point out that the company that is claimed to be behind the stress test does not actually have an [ann] thread on bitcointalk and a google search for them yields very few results. I would also point out that the domain coinwallet.eu appears to be registered only a little over a month ago. I think there is a fairly good chance that this is actually a somewhat elaborate scam to try to get peope to sign up for their wallet service, deposit money so they can run away with such money

You think that is free market? To flood the network for maybe a 3 day backlog of unconfirmed transactions?

Yeah, you are right.
Lets also charge billions of penny transactions/per second through the visa/mastercard system and when they shut it down and freeze it due to fraud and ddos, we'll just shake our fist and be like "hey yous.. free market guyz".

I love all the "WHY CANT U DO THIS ON TESTNET YOU JERKS!" messages.

Can you imagine if an organization who hated Bitcoin like the big banks, a government, or mastercard spent cash to clog up the bitcoin network for weeks? You think they'd care that you called them mean names?

They are paying the necessary fees to use the network, even if you consider it spam. Welcome to the free market.

Even though I highly support stress tests because they show real world effects due to the flooding,
I'm not too sure I support lagging the system for 1.5 to 3 days (theoretically).
A backlog of that long has repercussions that could hurt users in unexpected ways (ex. merchants).

Why can this not be done on the testnet? 3 day long backlog is too long for an active used network.

Ah so this is why my transactions are taking so long, thanks guys  

But seriously though, thanks for taking the initiative to test this with your own resources, this is great that someone in the bitcoin community wants to spend their own money on research to improve the technology

Idiots. Bitcoin will certainly survive this, but all you will accomplish by this is

#1 you wasted your own money on fees
#2 you are an asshole for everyone trying to spend coins durring that period.

If you want to test something use the testnet or create a model, no sane person does tests on a live system.

It's clear that we need to raise blocksize, but this test should put to rest this notion of "omg it's the apocalipse if we reach 1mb limit". Let's see what happens June 22 and if nothing happens then that means we are safe to stay with 1mb for longer than expected while the perfect solution is found.
Im also worried about microtransactions but they should go through. Miners can't selectively choose what or not they process afaik.

This is an interesting test, and I'll be waiting for numbers if you actually do it... But I question myself if the chaos that this test will, in theory, provoke will justify the results obtained!

Seems interesting. Will be looking forward to the results of the stress test.

The conclusions you draw from your premise are based on circular reasoning, while in fact your argument proves that a block size increase is not a proper solution to the problem:

If a large scale spam attack on the network is simple and can be achieved with 10 Bitcoin servers at 1 MB max_blocksize, it will be achievable with 200 Bitcoin servers at 20 MB max_blocksize, which is still a negligible amount of resources.

Spam attacks like yours will only become unviable if transaction fees rise steeply in relation to transaction size. So what we need first and foremost is more fee pressure.

ya.ya.yo!

Then Bitcoin price should fall during the test. It is necessary to put a buy order.
Or am I wrong?

So if my bitcoin salary is late this month I should blame you guys  

I'm by no means an expert on the tech details so I'm on the fence in regards to the increasing of the block size but sounds like this experiment will provide valuable information in this regard.

Also thanks for this post, gave me a better understanding of what can happen if we do not increase the block size.

They aren't in petty arguments. There is consensus among the developers that something needs to be done to increase scalability. They all agree that the block size should be raised, but they disagree how much and how it should be done.

When will the large transactions be sent? How often?
100 blocks is not 32 hours worth of blocks, it is only 16.67 hours. 144 blocks are generated daily, so this number is incorrect.

This is an interesting experiment, but it can and probably will disrupt a lot of trade going on through bitcoin right now. Also, since your transactions are pretty much dust and microtransactions, I think that miners will drop a lot of them and ignore your spam.

Can you show us the results from your other tests?

Three days ago, CoinWallet.eu initiated a relatively limited stress test on the Bitcoin blockchain to determine whether or not we alone could have a large impact on the ecosystem as a whole. While our initial tests merely created full blocks for a multiple hour period, transaction confirmation times remained within 6 blocks for most transactions. This test was both limited and basic.

Today we undertook a similar testing initiative once again, this time with a modified methodology. The result was roughly 3 hours of full blocks combined with increased confirmation times for many Bitcoin transactions. By selecting random transactions that were not initiated by our team, we were able to determine that many standard fee transactions were taking 2-5 blocks before receiving a single confirmation.

Bitcoin is at a breaking point, yet the core developers are too wound up in petty arguments to create the required modifications for long term sustainability. If nothing is done, Bitcoin will never be anything more than a costly science project. By stress testing the system, we hope to make a clear case for the increased block size by demonstrating the simplicity of a large scale spam attack on the network.

The plan - We have setup 10 Bitcoin servers that will send approximately 2 transactions per second each - Each of these transactions will be approximately 3kb in size and will each spend to 10-20 addresses - The outputs will then be combined to create large 15-30kb transactions automatically pointing back to the original Bitcoin servers.
Example: https://blockchain.info/tx/888c5ccbe3261dac4ac0ba5a64747777871b7b983e2ca1dd17e9fc8afb962519

•    Certain servers will be configured to include marginally larger than standard fees, thus guaranteeing delays from standard SPV wallets.

The target will be to generate 1mb worth of transaction data every 5 minutes. At a cost of 0.0001 per kb (as per standard fees) this stress test will cost approximately 0.1 BTC every five minutes. Another way to look at the cost is 0.1 BTC per full block that we generate. We have allocated 20 BTC for this test, and therefore will be able to single handedly fill 100 blocks, or 32 hours worth of blocks. However, we will stop pushing transactions after 24 hours at 13:00 GMT Tuesday June 23.

Predictions

•    Our above estimates are based on 1 block being mined every 10 minutes. This is standard, however deviations are likely to create temporary blips in our testing, in particular when there is an hour gap between confirmations.
•    The above calculations are based on each block being exactly 1mb and no other transactions appearing in the blocks. This is obviously unrealistic due to the fact that the average block size without our intervention is approximately 600kb. Furthermore, at least 30% of miners continue to cap blocks at 731kb. Others cap at 976kb.

Conclusions

For the sake of avoiding un-necessary calculations, lets assume that each block is 926kb in size, the average normal Bitcoin transaction volume is 600kb per block, and CoinWallet.eu will be pushing 2mb of transaction data into the network every 10 minutes. Under these conditions, the amount of transaction data being pushed to the network every 10 minutes (or every average block) will be ~2600kb. This will result in a 1674 kb backlog every 10 minutes.

By 14:00 GMT Monday June 22, the mempool of standard fee transactions will be 10mb By 24:00 GMT Monday June 22nd, the mempool of standard fee transactions will be 130mb By 13:00 GMT Tuesday June 22rd, the mempool of standard fee transactions will be 241mb

At this point the backlog of transactions will be approximately 241 blocks, or 1.67 days. When the average new transactions are factored into the equation, the backlog could drag on for 2-3 days. At this point, questions are raised such as whether or not this will cause a "crash landing." It is impossible to know with certainty, however we are anxiously looking forward to Monday.