You are right. Though when bitcoiners really will go ahead and give "their" bitcoin away to a private company, where the development of the blockchain and the wallet is decided to some private persons and that company, then why the heck should miners switch away later? First they take that offer, so i don't see many will switch later.

It's like a vote. If you chose bitcoin xt then you chose a company that will decide what will happen to the bitcoin wallet and the blockchain.

Hearn and co make so much trouble as if the remaining developers doesn't understand the problem. Of course they do. They only don't take part in that fear advertising campaign for a company bitcoin xt. Bitcoin core will be forked for sure. Its simply needed. No real developer will deny that. It only doesn't have to happen now instantly. We have time to find the best solution. But hearn let it sound like tomorrow bitcoin will die. And we all should give his company the power to rule about our coins.

I won't take part in this. But i fear the community is not so united. I fear a damage to the price of bitcoin. Though maybe bitcoin core gets patched fast and bitcoin xt is losing its momentum.

Es wird nicht "verlangt" im in Sinne von "erzwungen". Man kann auch kein Bewerbungsfoto schicken. Es steht ja extra da, dass sie einen "per E-Mail bitten [...] weitere Unterlagen zu schicken".
Es ist immer erlaubt jemanden darum zu bitten, dass es ein Bild von sich schickt.

I don't understand where people are getting this notion that Bitcoin price will do well in an economic crash. It is way to volitile for anyone with sense to put their wealth into.

The biggest con to Bitcoin XT is the fact that Mike Hearn apparently wants to consolidate power over the blockchain via miners, and get the ability to freeze / blacklist bitcoins, as he mentions here:

https://bitcointalk.org/index.php?topic=5979.0

I've been basically 100% Bitcoin for over 2 years now, but if that little proposal becomes reality, I'll be switching back to fiat immediately.

I made it using data from http://btc.blockr.io/ with the help of google sheets https://docs.google.com/spreadsheets/d/1LmBk8_5BqFVvMDLJ2EdhUvkyA_Nea4ZFKCE4jA-VsuA/edit?usp=sharing

Would be easy to make your own table and calculate to verify.

You'd have to raise your transaction fees to well above .001 BTC/kb to cause any noticeable blockade, here is the last test where legit users broke through your blockade easily. And of course you couldn't afford a significant amount of spam at this level.



It's an interesting idea for an attack, but this is why it's never going to be feasible. Based on what I know now I honestly don't give a crap if you do this attack at full force cause it will have barely any impact for people who are properly calculating transaction fees.

I take back what I said about him possibly being anduck, no way to know for sure so not worth starting a war over that.


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

Basically everyone else will send transactions with higher fees than 0.0001 kb and none of the spam will go through until later. Only people that could get fooked are those who send minutes before the spam begins.

Your calculations were way off in the last test and you're using the same ones again??? Transaction fee is way higher than you're estimating once any mempool excess begins.

And btw KingAfurah is likely an alt of Anduck. Now that this person's identity is revealed hopefully they will be more responsible with what they do, instead of trying to spread fear throughout the community. https://bitcointalk.org/index.php?topic=1094865.msg11701281#msg11701281

Has anyone contacted coinwallet.eu to confirm they are behind this? No legit bitcoin exchange would tamper with the bitcoin network, especially over and over again.

Regardless whoever is doing this is trying to blow the negatives way out of proportion. There is little evidence that services were disrupted, yet in their report they say almost every service was crippled without any evidence to back it up. They even claim the market was effected which is super ignorant.

This is mostly being done to make people fearful, which is essentially terrorism.

the stress test carried out by coin wallet eu and funded by the london banking house

seems to have completely unnerved them,  analysis by the Crypto Currency Central Bank

This is not true.....well unless it is assumed that the attacker does not control any mining hardware and only executes his attack with nodes.

If an attacker were to broadcast a particular transaction that is accepted by the nodes and then confirms a valid block that double spends at least one of the inputs from the transaction then the original transaction will no longer be valid and will fall out of the node's memory pool. Another alternative to confirming the double spend themselves would be to pay a pool to confirm a specific tx that happens to double spend at least one input from the unconfirmed transaction in question, I know there at least used to be at least one pool that offered this "service"

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.

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

well those 5 chinese mining pool don't belong to one entity, so bitcoin is indipendent from a single decision, but not from general consensus, for obvious reasons

don't bring the whole "mining is centralized" again, because it isn't


i don't think so, it is just that they find 8 mb the most valid choice, for their business, and since they are situated all in china, they will share similar goals

yet i still believe that something aginst the 51% problem must be done, something that will tell the network to not count the longest chain, but the more legit block, i don't know how it can be implemented

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.

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.


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