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

I found it
https://bitcointalksearch.org/topic/m.12623681
May be it's this...

Maybe someone is simply testing how well the network can react on that. I think the nodes still need to keep all these transactions in RAM. Which might be a problem.

I wonder if it is related to the max blocksize limit debate.

UP

https://tradeblock.com/bitcoin/

Now again 92K transactions
but now 99% from theirs now have a fewest fee/Kb
Is it bad mixer? Or new stress test?
Now it's not big problem because there 99% of all transactions have < 1 satoshi/byte fee. But it's not good for some centralized software of blockchain - blockchain.info site (max request errors), biteasy.com + blocktrail.com (lagging of indexed blockchain), Mycelium wallet (long time syncing and lagging of wallet balances)...

Well , "biased" here doesn't mean his reasoning isn't valid, maybe the word is wrong. A person here has asked about what's the current state of blocksize debate, Jorge answered in a manner which clearly shows his attitude towards blocksize naysayers (nearly accusing them of conspiracy because of their employment at Blockstream). I just wanted to argue that it's likely not a no-brainer situation (that is my opinion on which I and Jorge disagree) and pointed the reader to the mailing list discussion so he can make his own opinion.

I don't think there's anything left to discuss with regards to my post.

Actually, according to Jorge's signature, (which I have no reason to believe is inaccurate), he does not have any kind of stake in Bitcoin, bitcoin, nor the block size debate. While JorgeStolfi has echoed the same opinion multiple times, it has always been back by logic and valid reasoning.

Well, yes, they agreed to 8MB, in a document signed and sealed with red star stamps and all.  However, they added afterwards that they do not like the idea of switching to XT, and hope that the Core devs and Gavin&Co will reach an agreement.

Someone with nothing better to do

We are obviously under a stress test, well, call it attack:


https://blockchain.info/address/1mtgoxNrDZgrs6zP1MdEToSNTAeeeU2VH

If this isn't a huge spamfest attack then i don't know what it is. I wonder who is the low life running this kind of shit all day.

For the tiny fees to be incentive for mining, bitcoin prices must reach new limits. Its possible.. just saying. Current prices won't support it.

I don't think fee saturation is necessary/beneficial until the block solve reward has halved several more times.  Right now fees are such a small percentage of the total block reward that they could, essentially, be ignored.

That's your opinion, I get it. But I strongly disagree with you on calling their "excuses" FUD. I also don't get the Blockstream argument. It's a serious accusation, in fact. Still, I don't want to start a flame war here.

The attacks only come occassionally, which lowers the percent even more. I mean people will fear that a spam attack can start everytime and will use higher fees even without attacks. The stop and go is simply a cheaper way of raising the overall fee.

I think the fee might be a reason, even though some say that theory is debunked. Even with the spammer having a disadvantage against nonspammy miners, maybe the spammer has ways to create their mining hardware cheaper than competition. Getting more money will lead to more miners and might still outcompete the upgrades of the nonspammy competition.

Besides that, it might be someone trying to lower the bitcoin price.

By the way. I found this site incredibly useful for finding out how much fee to pay: http://www.cointape.com/ It can show when spam attacks go on too of course.

Thank you for the heads up on the situation.

Is blockstream inc relevant to having small blocks?

I think the saturation idea is stupid. That would hinder adoption effectively and would kill bitcoin in the long run. The fees needed to, for exampl back up the block halving through that way, are way too high to let bitcoin survive. Following that idea would be plain stupid.

But i think there is no problem. Chinese miners, who are the most, already agreed on 8MB. Case closed.

.

I am not "biased a bit". I think that raising the blocksize LIMIT is necessary and urgent to avoid severe degradation of bitcoins usability.  It should have been a no-brainer non-event, if the developers affiliated with Blockstream had not dumped a huge mountain of FUD in its way.  

From all that I read, I concluded that the arguments against it, like the alleged risk of centralization, are ridiculous excuses.  To me it is obvious that the Blockstream guys simply want the network to become saturated, as soon as possible and at any cost, and don't give a damn about what that would mean for its users.  In fact they want to convert the network from its original goal (peer-to-peer payments without the need of trusted middlemen) to a totally different purpose (the settlement layer of their overlay network) without the knowledge, much less the consent, of all the other players -- by abusing their control of the Core implementation.  

Perhaps the Blockstream guys genuinely believe that the Lightning Network will be viable and working in six month's time, and will be much better than bitcoin as it is now.  However, I am increasingly doubtful of that.  They cannot be so naive.  Perhaps they just intend to push all users to companies like Coinbase and Circle.

I don't have particular admiration for Gavin, Mike Hearn, or Jeff Garzik, but I believe that in this issue they are just trying to do what the Core devs should be doing:  keep bitcoin usable for its original purpose, at least as well as it has worked so far, for a few more years.  

If interested, bitcoin-dev mailing list might be a good read. A lot of pro's and con's are being discussed there on a daily basis.

With all the respect to JorgeStolfi, I believe he's biased a bit towards raising the blocksize sooner rather than later. Yet there are some solid arguments against it, e.g. those related to centralization (we still don't have proper simulations of different scenarios of blocksizes and their effects of incentives). The differences might be ideological, I don't know. I don't want to discuss it there anyways.

No sign of consensus as of yesterday.  The "old devs" (Gavin, Mike Hearn, Jeff Garzik) want to increase the limit before the traffic gets close to saturation.  The "new devs" (Adam Back, Greg Maxwell, Peter Wuille, Luke-Jr, and others -- most of them working for Blockstream Inc) want instead to see the network saturate so that a "fee market" develops.  Since it is a discrete (binary, boolean) choice, no compromise is possible.

Gavin backed down from his original 20 MB proposal to 8 MB, starting early next year, with automatic increases afterwards. Jeff proposed a "compromise" plan with 2 MB blocks.  Peter Wuillie made a counter-proposal to increase the limit only in 2017 -- that is, no compromise.

Not really: even with low traffic, the expected time to the first confirmation woud still be 10 minutes.

However, if traffic keeps increasing at the current pace, in 6 months time it will hit the 1 MB ceiling. Then there will be frequent "traffic jams".  No matter what fees clients use, the average wait time then may be hours. Raising the limit to 8 MB would postpone saturation for several years.  "Traffic jams" could also be created by "spam attacks", but they will be much more expensive and less effective with 8 MB limit rather than with 1 MB.

I'm not as connected as some people are to the reddits and githubs and IRC rooms where a lot of the bigwigs talk about this stuff.  Does anyone know if consensus is anywhere close on this block size increase issue?  It doesn't seem off topic here to ask given the direct relation between the attacks/tests and the potential increase.  I know the debate has been rancorous, I wonder if anyone has a gauge on where we stand at the moment on this.


I think it's not entirely clear what you mean by "transaction times".  If you mean "time to block inclusion/first confirmation for a lower fee transaction during a high volume moment" then yes, that's what he's saying.  If you mean the time it takes for a transaction to be propogated by the network, then I don't think so, if anything, passing larger blocks around might add latency to the network (but I'm no expert, I'm just guessing).  What do you mean by "transaction times"?

Would raising it to 8 also speed up transaction times?

Indeed most (all?) of the ~80'000 "test" transactions in the queue have 0.2 mBTC/kB fee, so if you pay more than that you should get confirmed in the next block or two -- as used to be the case before the stress test, even with minimum fee.

However, there are several hundred transactions with fee 0.4 mBTC/kB, and another few hundred paying 0.5.   It is not clear whether they were issued by the tester, too, or by normal clients who raised their fees to bypass the backlog.


The fact that most transactions pay the same low fee seems to make it a "brutal test" rather than an outright attack.  That is, the tester is not really trying to block the network (he woudl have to kep raising the fees to do that), but does not give a damn about the ~12'000 transactions that are caught in the backlog with fees below 0.2 mBTC/kB, whose issuers probably have no idea of what is going on.


There is no way to prevent a spam attack by someone who has a large enough budget.  All one can do is make such attacks more expensive, hence less likely.

Increasing the block size to 8 MB would make a similar attack 15-20 times more expensive.  It would also clear the backlog 15-20 times faster.