Are we stress testing again?

[bandors]

Would raising it to 8 also speed up transaction times?

[1714104871]

1714104871

[1714104871]

1714104871

[tspacepilot]

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.

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.

Would raising it to 8 also speed up transaction times?

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

[JorgeStolfi]

Would raising it to 8 also speed up transaction times?

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.

[JorgeStolfi]

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.

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.

[RoadTrain]

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.

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.

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.

[JorgeStolfi]

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.

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.  

[SebastianJu]

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.

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.

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.

.

[SebastianJu]

Still, this consortium would be subsidizing other miners. This might be a drop in the bucket, but still it would shift balance towards other miners.

If a consortium has more than 38% of the mining power, subsidizing other miners and getting higher fees is more profitable than not doing so.   And whenever there is legitimate demand for more than half the space in the blocks, you can get higher fees by spamming the block chain.

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.

[RoadTrain]

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.

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.  

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.

[Mikestang]

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.

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.

[Amitabh S]

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.

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.

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.

[pereira4]

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.

[RoboRob]

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.

Someone with nothing better to do

[JorgeStolfi]

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

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.

[Quickseller]

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.

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.

[RoadTrain]

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.

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

[Perlover]

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

[SebastianJu]

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.

[Perlover]

I found it
https://bitcointalk.org/index.php?topic=1175321.msg12623681#msg12623681
May be it's this...

[SebastianJu]

I found it
https://bitcointalk.org/index.php?topic=1175321.msg12623681#msg12623681
May be it's this...

Hm, i wonder why someone tries this. Isn't it that the fees needed to include these transactions are higher than the outputs? If you try to do it with a lower fee than miners would accept then it will be useless. Or the one collecting the funds owns a mining farm and knows that these transactions will be included. But that makes no sense too since a miner of that size would not bother with pennies. And he would lose coins by including these transactions instead transactions that pay a fee.

So the one doing is makes a thing that does not look smart to me.