Show Posts
See here why the first stress test was not as successful as planned: CLICK
The result was roughly 12 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 ~80 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 setup 32 Bitcoin servers that will send approximately 1 transactions per second each (up from 10 servers sending 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 30.
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 13:00 GMT Monday June 29, the mempool of standard fee transactions will be 10mb By 24:00 GMT Monday June 29nd, the mempool of standard fee transactions will be 130mb By 13:00 GMT Tuesday June 30, 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.
