bandors
Newbie
Offline
Activity: 1
Merit: 0
|
|
August 05, 2015, 04:47:26 AM |
|
Would raising it to 8 also speed up transaction times?
|
|
|
|
tspacepilot
Legendary
Offline
Activity: 1456
Merit: 1081
I may write code in exchange for bitcoins.
|
|
August 05, 2015, 05:46:05 AM |
|
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
|
|
August 05, 2015, 06:11:30 AM |
|
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.
|
Academic interest in bitcoin only. Not owner, not trader, very skeptical of its longterm success.
|
|
|
JorgeStolfi
|
|
August 05, 2015, 06:28:02 AM |
|
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.
|
Academic interest in bitcoin only. Not owner, not trader, very skeptical of its longterm success.
|
|
|
RoadTrain
Legendary
Offline
Activity: 1386
Merit: 1009
|
|
August 05, 2015, 11:55:46 AM |
|
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
|
|
August 05, 2015, 06:29:42 PM |
|
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.
|
Academic interest in bitcoin only. Not owner, not trader, very skeptical of its longterm success.
|
|
|
SebastianJu
Legendary
Offline
Activity: 2674
Merit: 1083
Legendary Escrow Service - Tip Jar in Profile
|
|
August 05, 2015, 08:14:12 PM Last edit: August 08, 2015, 04:12:24 PM by 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. .
|
Please ALWAYS contact me through bitcointalk pm before sending someone coins.
|
|
|
SebastianJu
Legendary
Offline
Activity: 2674
Merit: 1083
Legendary Escrow Service - Tip Jar in Profile
|
|
August 05, 2015, 08:18:03 PM |
|
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.
|
Please ALWAYS contact me through bitcointalk pm before sending someone coins.
|
|
|
RoadTrain
Legendary
Offline
Activity: 1386
Merit: 1009
|
|
August 05, 2015, 08:42:23 PM |
|
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
Legendary
Offline
Activity: 1274
Merit: 1000
|
|
August 05, 2015, 09:44:01 PM |
|
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
Legendary
Offline
Activity: 1001
Merit: 1005
|
|
August 05, 2015, 09:51:41 PM |
|
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.
|
|
|
|
|
RoboRob
Member
Offline
Activity: 75
Merit: 10
|
|
August 05, 2015, 10:11:42 PM |
|
Someone with nothing better to do
|
|
|
|
JorgeStolfi
|
|
August 06, 2015, 04:06:39 AM |
|
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.
|
Academic interest in bitcoin only. Not owner, not trader, very skeptical of its longterm success.
|
|
|
Quickseller
Copper Member
Legendary
Offline
Activity: 2982
Merit: 2371
|
|
August 06, 2015, 05:07:52 AM |
|
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
Legendary
Offline
Activity: 1386
Merit: 1009
|
|
August 06, 2015, 11:28:16 AM |
|
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
|
|
October 09, 2015, 10:10:10 AM |
|
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
Legendary
Offline
Activity: 2674
Merit: 1083
Legendary Escrow Service - Tip Jar in Profile
|
|
October 09, 2015, 10:45:59 AM |
|
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.
|
Please ALWAYS contact me through bitcointalk pm before sending someone coins.
|
|
|
|
SebastianJu
Legendary
Offline
Activity: 2674
Merit: 1083
Legendary Escrow Service - Tip Jar in Profile
|
|
October 09, 2015, 11:34:10 AM |
|
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.
|
Please ALWAYS contact me through bitcointalk pm before sending someone coins.
|
|
|
|