Topic: Are we stress testing again? - page 16. (Read 33192 times)

As these [statoshi.info](http://statoshi.info/dashboard/db/transactions?from=1436730481809&to=1436903281810) plots show, the test is still not over.  The input traffic is still high and erratic: 4-10 tx/s, with a few spikes of higher values. The testers are changing the parameters (tx size, fee, tx rate) every now and then.

In normal conditions (before the test), the traffic was ~1.4 tx/s in daily average, with an average transaction size of 540 B/tx; that meant 0.75 kB/s.  
The current effective network capacity seems to be ~720 kB/block x 0.00162 blocks/s = ~1.15 kB/s; so the normal daily average traffic is ~65% of the effective capacity.  

Bt the way, about the theory that some large miner (or mining consortium) is behind this test: the profit of a 20% miner from the extra fees is small by mining standards, but is already more than the declared budget of the testers.  So this COULD become quite lucrative if part or all of the extra revenue of that miner, insted of being pocketed, is "reinvested" to keep the "test" going and thus drive the fees of normal users even higher...

Coinwallet.eu, the somewhat mysterious entity doing the "stress test", said that they had 5000 EUR budgeted for it.  Transaction fees were ~20 BTC/day just before the test; they have increased by 10 + 25 + 30 + 22 + 22 = 107 BTC over the 5 days since it started, with would be ~30'000 EUR (or USD) at the current price.  However, many client have had to increase the fees on their own transactions in order to get them through the backlog.  So it is possible that Coinwallet only spent 5000 EUR while the legitimate users spent 25'000 EUR.


I can think of many possible motivations for this test, besides technical need for it in order to ensure that the system can handle future traffic surges or hostile spam attacks.  That may be another one: a miner, or a group of large miners, trying to force an increase in the fees for their profit.  

Given the above numbers, and assuming that clients will continue to pay an average of 10 BTC/day above the normal amount over the next 5 days (that it will take for the backlog to clear), the total extra revenue for all miners resulting from the test would be ~45'000 EUR.  

If Coinwallet was financed by a miner with 20% of the hashpower, that miner would get 9'000 extra revenue, or 4'000 extra profit.  If the sponsors were a coalition of the top 4 Chinese miners, with 60% of the hashrate, their payoff would be ~27'000 EUR, or ~5'500 EUR average profit for each of them.

These profits are rather small considering that the miners all together made ~10'000'000 EUR in those 10 days (2'000'000 EUR for a 20% miner, 6'000'000 for a 60% consortium).  So, if the miners did that for the extra fees, they must have been quite disappointed.

An alternative theory is that Coinwallet.eu was financed by some "benevolent" entity or individual who thinks that the current fees are too low and wanted to force the developers, miners, and nodes to raise them.


Even an 8 MB limit will make the test much more expensive, and its effect more short-lived.  It is more than 8 times, because miners are currently mining blocks with maybe 600 kB only on average, even when there is a backlog; and the normal traffic already uses 2/3 of that.  So there are only 200-300 kB per block available for clearing the backlog, and an attacker needs to issue only more than that amount to create a backlog.  

If the limit were increased to 8 MB, and the minimum fee was raised to an amount that would convince the miners to keep filling at least 60% of that during such jams, there would be ~3200 kB per block available to clear the backlog.  An  attacker would have to issue 10-12 times more transactions per second to create and sustain a backlog, and the backlog would clear 10-12 times faster once the attack stopped.  

What makes you think so? Mind looking at the list of unconfirmed transactions?

I had just recently a Bitcoin event where I tried to convince people to use Bitcoin. I do the same for companies.

Some of them mailed me and complained that their transactions didn't go through. That is pretty bad. Especially when they were seeing at the event how smooth and quick a transaction can go and then they try to convince their family members or co-workers - and puuufff - nothing works as they had expected. Of course I told them to use Bitcoin Core. But of course people go with their mobiles in the app-store for their mobile phones and download whatever is on the first place.

So at the end of the day, this attack IS harming adaption of Bitcoin.

And no, to give you a very short answer: It is not "a bunch of fud".

My 0.0000002BTC: I've been doing transactions during the spam fest with no problems at all. Normal fees, multiple transactions, using Bitcoin Core, Armory, Electrum and Mycelium. No delays whatsoever, all transactions were confirmed in the very next block.

Bitcoin is quietly working as it was intended.

you can still send 0 fee tx. the speed will be at SEPA/Wired level then, which is fine in my opinion. and >3 cent for a tx is still nothing

so this attack raised awareness, that's another big bonus. wasn't that bad and did little harm

Moving to the new bitcoin core release, I'll be testing to see how great are this improvements on .011 most likely a new update would be out pretty soon.

Especially this:


Edit:

How much do you estimate an actual running attack like this would cost?

One may question whether the network is really robust, but the faith of the true bitcoiner will resist any reality attack.   If tomorrow a hacker steals half the coins of the world by exploting some obscure old bug in BitcoinCore that exposed their private keys; or the Chinese miners go on strike and mine only empty blocks, orphaning all other blocks; or the US government blocks all relay nodes except those run by the NSA, that filter out any contributions to Wikileaks or Snowden -- the faithful will still claim that Bitcoin worked as intended.  And they woudl be right...


To be pedantic, this was not an "attack" but a "stress test" -- even if a rude and inconsiderate one.  

The difference is that a hostile attacker would have tried to block even most of the transactions with higer fees, by raising the fees on its own transactions to keep the legitimate ones perpetually off the next block.  And an hostile attacker who decided to do that would probably have a much higher budget, and would prepare his own transactions discreetly months in advance, so that they would be impossible to distinguish from legitimate ones.

I don't know what to think of this test.  Since I am not a user, and I see bitcon as a computer science experiment rather than a product ready for general use, I personally think that it was a valid and necesary "stress test" -- a test that one must do on any novel engineering artifact, meant to understand how it behaves if by accident or malice it is used outside its intended operating range  (like the stress test that VISA does in August every year -- or the test that caused the Chernobyl disaster  ).  Such a test must usually be performed on the real thing, since a test mock-up will always lack some feature of it that would break in the test.  If possible it should be done "without passengers", but that is impossible for large 24/7 systems like VISA, Bitcoin, or the national power grid.  In particular, the goal of the testers of creating a 200 MB backlog on the queues may have been intended to test whether the relay nodes were able to handle queues that big.  (And in fact they broke many programs that work on those queues.)

Trying to put myself in place of the typical user, I would think that many who tried to use Bitcoin these days, and were not aware of the need to pay higher than normal fees, must have concluded that the system was broken, and did what any user of free software would do: gave up on it.  Note that only a few thousand bitcoin users read the forums or the bitcoin "news" sites (an the latter tend to hide or minimize problems).

It is quite possible that the test had other goals besides a purely technical one.  However, it is hard to guess what those intentions could be.  The authors are anonymous, and Coinwallet.eu seems to be a phony site create just to give an excuse for the test.  

Coinwallet.eu earlier had said that they supported Gavin's original proposal to raise the block size limit to 20 MB.  So perhaps they are big-blockians trying to show to the community what a saturated network feels like.  They knew that, thanks to the 1 MB limit and ridiculously low minimum fees, they could create a 200 MB backlog (that will take ~5 days to clear) by spending only 5000 euros or so in fees.  If the block size limit had been 8 MB, the backlog they could have created with that budget would have been much smaller, and would have been cleared ~15 times faster.  However, the test was not very apropriate for that purpose:  they did not try to raise their fees in the same rate that normal clients raised their; and they knew that a 200 MB backlog of low-fee transactions would not be as bad as a 20 MB backlog of real ones.  Moreover, they did not bother to disguise their transactions, and it seems that some nodes started to reject them.

On the other hand, the testers may have been small-blockians impatient to see and demonstrate the "fee market" that (they claim) will make a saturated network even better than an unsaturated one.  Some of the "new devs" invented spiffy tools/toys that they were clearly dying to see in use, but needed a saturated network to work.  And some of these devs are notoriously rude and inconsiderate enough to clog the network for days just to see their toys spin and blink.

Or perhaps the "test" was meant to convince the "true bitcoiners" who use the network directly to move to a hosted wallet provider, like Coinbase or Circle -- or perhaps Coinwallet.eu.  (Coinbase, for example, seems desperate to get new users: they are now offering 25 $ reward (in BTC) for any user who can convince some friend to register and spend 100 $ with them.)  Perhaps even Blockstream is an accomplice of this plan: that would explain why they are so adamantly opposed to any increase in the block size limit, and pretend not to udnerstand what congestion by natural traffic would mean for the usability of Bitcoin...

I'm beginning to think all these 2 days with 0 confirmation reports are just a bunch of fud.

That's the problem with all these people. It's not that they can't use Bitcoin, it's that they don't know how to do it properly.
Hint: pay high enough fees and it works. In this particular situation, Bitcoin works as intended.
PS. It might not work when Bitcoin actually saturates, and that need to be addressed. But this doesn't have much to do with this stupid attack.

I cant believe that some claim that bitcoin is working as intended. Its simply not normal that the forum, reddit and all other places, are full of persons that are annoyed about bitcoin. What should you do with a currency you cant use? Its simply not normal when transactions get stuck because some senior teacher try to teach the community. It brings so much trouble to bitcoin. Even i had a transaction stuck two days until i resetted it. Simply because i did not know that they started spamming again. Nothing is normal.

We want bitcoin being adopted and then trying to punish newbs and users with things they dont care and should care about? This is an attack on a big economy. And even when you would say the big companies simply adjust their fee, there are many complaints and even scam accusations because withdraws didnt happen because of these scams. There will always be transactions stuck when such things starts.

Its so annoying. And they did not stop yet. I wonder when they think they made their point.

I know that and its a bit stupid to go and try to hinder adoption by limiting the use of bitcoins. Centralized exchanges for the poor? Bitcoin was invented as a way to circumvent banks. With min limits as to how much you can or should send this isnt achieved.

Saying that... i dont see a reason why chinese miners shouldnt sit together and decide to only accept transactions with a high fee anymore. They would slow down all other transactions and surely user will raise fees.

I've not looked at the backlog, but the transactions I done so far today have gone as smooth as possible. I was expecting the opposite.

I've one from the 11th though, without any confirmations.

i tried to deal with this by adding a DoS value to ppl transmitting these junk transactions, but that dropped 90% of my connections

and the public relay nodes are godawful slow now, 3-10 seconds late on 3/4ths of the blocks

I wonder if a method of automatically increasing costs to the spammer would help with this. I.E. 1st transaction, normal fee. 2nd transaction in 30seconds double fee, 3rd transaction in one minute double again etc.

I am not sure how we would implement without some central control of some type though.

you don't know the RC release ... of bitcoin core. 
litterally a month before the stable version :

- RC1 : can bug, rare
- RC2 : don't bug, test setting
- RC3 : rock stable, add somes last event setting

Final = normally the RC3 with adjusted setting.

I'm not willing to upgrade now especially during this spam fest. I never upgrade early as there are always loads of bugs & glitches. Wait for the stable version & you'll have no issues.

Traffic rose indeed. Even though the node has to stay up with only 2 GB of ram, it did not crash. Its certainly at its limit though as it dropped connections even durring the tests.

No i do not think we are doing that.