I say a moderate hard coded increase should be planned for now (this is not a fork) and more complex proposals FULLY evaluated over the next year or so.
How is it not a fork? Correct me if I'm wrong, but older clients will just drop larger blocks, and never be able to sync when one block in the chain is larger then the limit set in their client? 
Topic: The fork - page 6. (Read 5058 times)
As I understand it, Satoshi DID intend to increase the block size, and he intended to do it without a fork.
I think its worth remembering that Satoshi's view ought to get a certain amount of respect just because, he is Satoshi.
Various complex ways of adjusting the blocksize dynamically have been discussed, but mostly these sound too raw to me, and need a much longer period of discussion. The blocksize will likely need to be increased THIS YEAR, or some of the properties of Bitcoin may start to be eroded. Thats the current situation.
I say a moderate hard coded increase should be planned for now (this is not a fork) and more complex proposals FULLY evaluated over the next year or so.
I think its worth remembering that Satoshi's view ought to get a certain amount of respect just because, he is Satoshi.
Various complex ways of adjusting the blocksize dynamically have been discussed, but mostly these sound too raw to me, and need a much longer period of discussion. The blocksize will likely need to be increased THIS YEAR, or some of the properties of Bitcoin may start to be eroded. Thats the current situation.
I say a moderate hard coded increase should be planned for now (this is not a fork) and more complex proposals FULLY evaluated over the next year or so.
i for one would not go along with such a fork. i think many others would agree with me. So long as there are atleast a few other people who agree, a hard fork will not be possible.
This change is (eventually) such a critical and needed change, if we want Bitcoin to be used for small payments as well, that it will simply be done. Anyone who disagrees will form their own payment network.
The alternative scenario is that for some reason the dev team doesn't have the will to do this, and users eventually start to flock to other cryptocurrencies.
This problem can be solved with centralized services. I know this sounds ominous, but since these servers would only be used for transactions that were too small to be efficiently sent through the bitcoin network it really wouldnt be a big deal at all. I would probably only have a tiny fraction of a percent of my assets held in such a system at any given time.
So you feel like 7 transactions/second will always be enough?
i for one would not go along with such a fork. i think many others would agree with me. So long as there are atleast a few other people who agree, a hard fork will not be possible.
This change is (eventually) such a critical and needed change, if we want Bitcoin to be used for small payments as well, that it will simply be done. Anyone who disagrees will form their own payment network.
The alternative scenario is that for some reason the dev team doesn't have the will to do this, and users eventually start to flock to other cryptocurrencies.
This problem can be solved with centralized services. I know this sounds ominous, but since these servers would only be used for transactions that were too small to be efficiently sent through the bitcoin network it really wouldnt be a big deal at all. I would probably only have a tiny fraction of a percent of my assets held in such a system at any given time.
It's also important to note that there are many upgrades that can be done to Bitcoin if a hard fork is needed anyway. It's actually very beneficial. It will allow Bitcoin to stay competitive with smaller and more agile cryptocurrencies.
i for one would not go along with such a fork. i think many others would agree with me. So long as there are atleast a few other people who agree, a hard fork will not be possible.
This change is (eventually) such a critical and needed change, if we want Bitcoin to be used for small payments as well, that it will simply be done. Anyone who disagrees will form their own payment network.
The alternative scenario is that for some reason the dev team doesn't have the will to do this, and users eventually start to flock to other cryptocurrencies.
Does it matter what your point was? You spread manipulative framing, don't do it.
That's just silly. Of course it matters what the point was.
Notig was using Gavin's words to imply that Gavin had a certain intent. The only way to point out that Gavin had a different intent was to point out what that different intent was.
It's pretty clear that the lead developers want to raise the max block size. From what I've read it seems like a good idea because it will improve the network. Anyways...... this requires a hard fork. Do you think the chances of this fork are 100% ? When do you think the fork will be?
edit: [I posted this in here because I don't want it to be a technical discussion. But rather a general discussion of an impeding fork(if that's even possible). That seems a little too important to leave in the developmental forum]
edit: [I posted this in here because I don't want it to be a technical discussion. But rather a general discussion of an impeding fork(if that's even possible). That seems a little too important to leave in the developmental forum]
i for one would not go along with such a fork. i think many others would agree with me. So long as there are atleast a few other people who agree, a hard fork will not be possible.
It's an argument over what ramifications for the security and the decentralization of Bitcoin removing the block size limit would have. Please don't spread Gavin's manipulative reframing. No one in that thread cares if less efficient miners can't "hack it", they all care what that would mean for Bitcoin. And if less efficient miners are part of what makes Bitcoin secure and decentralized then absolutely they need to be thought off when considering a hard fork type change of the protocol.
The point wasn't to spread manipulative framing. Does it matter what your point was? You spread manipulative framing, don't do it.
The block size limit will most certainly need to be raised either as a "one time" event or changed to a dynamically changing limit, if a suitable method for that can be agreed upon. It's not a matter of if, it's a matter of when. If we don't do anything about it, Bitcoin will actually start shrinking in usage, because it will only be usable for high value transactions.
SatoshiDice has nothing to do with it. It has only accelerated the need for this. Killing SatoshiDice would delay the need but it would not remove it.
SatoshiDice has nothing to do with it. It has only accelerated the need for this. Killing SatoshiDice would delay the need but it would not remove it.
DDOS SatoshiDice out of existence. Problem solved.
It's an argument over what ramifications for the security and the decentralization of Bitcoin removing the block size limit would have. Please don't spread Gavin's manipulative reframing. No one in that thread cares if less efficient miners can't "hack it", they all care what that would mean for Bitcoin. And if less efficient miners are part of what makes Bitcoin secure and decentralized then absolutely they need to be thought off when considering a hard fork type change of the protocol.
The point wasn't to spread manipulative framing. The point was to respond to notig's use of Gavin's words to claim that "It's pretty clear that the lead developers want to raise the max block size".Notig was claiming that Gavin was arguing for a need (or desire) to increase blocksize. As I saw it, Gavin was arguing that a loss of decentralization isn't enough reason to avoid increasing blocksize. I don't see those two as being identical, do you?
The quotes you posted appear to be used as an argument against a particular reasoning that blocksize has to remain small forever for the sake of inefficient miners.
It's an argument over what ramifications for the security and the decentralization of Bitcoin removing the block size limit would have. Please don't spread Gavin's manipulative reframing. No one in that thread cares if less efficient miners can't "hack it", they all care what that would mean for Bitcoin. And if less efficient miners are part of what makes Bitcoin secure and decentralized then absolutely they need to be thought off when considering a hard fork type change of the protocol.
Really? Why do you say that?
Quote
I think we should put users first. What do users want? They want low transaction fees and fast confirmations. Lets design for that case, because THE USERS are who ultimately give Bitcoin value. - Gavin Andersen
Did I completely misunderstand him when he said this is another thread? Doesn't lower transaction fees and fast confirmations mean a larger block size?
Quote
Really? Improve it how?
Quote
You seem to be saying that we should subsidize inefficient miners by limiting the block size, therefore driving up fees and making users pay for their inefficiency. - Gavin Andersen
Once again........ am I completely misunderstanding what he is saying here? He is saying limiting the block size (as it is currently ) drives up fees and makes users pay for their inefficiency. Does this not mean that Gavin is for raising the block size limit which means a fork?
From that same conversation, I see the following qote from that same person:
- snip -
So, as I've said before: we're running up against the artificial 250K block size limit now, I would like to see what happens. There are lots of moving pieces here, so I don't think ANYBODY really knows what will happen
- snip -
So, as I've said before: we're running up against the artificial 250K block size limit now, I would like to see what happens. There are lots of moving pieces here, so I don't think ANYBODY really knows what will happen
- snip -
That would seem to indicate to me that there hasn't been any decision to increase block size any time soon. As a matter of fact, the blocksize has been artificially decreased for many miners to gain knowledge on which to base future decisions.
The quotes you posted appear to be used as an argument against a particular reasoning that blocksize has to remain small forever for the sake of inefficient miners. This is in no way an argument that the blocksize needs to increase soon, only that the possibility of raising it in the future shouldn't be eliminated.
If it happens, then my prediction is that it will be when there is less than a 75% chance of getting a 1kb or smaller transaction with inputs totaling more than 0.1 BTC included in the next block with a fee of 2%.*
*This is a completely arbitrary and unsubstantiated claim that I've made up on the spot simply because it sounded good to me.
I guess (hope) you mean more or less a flat rate which would be around 2% on a .1 BTC transaction?
If so, I've always thought that Bitcoin's best hope is to become something of a 'reserve currency' in which largish base transactions can occur. So it is not something I'd be particularly opposed to as one path forward for Bitcoin.
If not, and a 2% transaction fee is in the ballpark of what people are gunning for, I believe it would pretty rapidly suck the life out of the economic actors who are not capable of providing actual infrastructure support...and the barrier to entry here is rapidly making this non-tenable for most. Such a solution would be no more desirable than current mainstream financial institutions to my way of thinking.
First of all I'd just like to say I posted this in here because I don't want it to be a technical discussion. But rather a general discussion of an impeding fork. That seems a little too important to leave in the developmental forum.
Really? Why do you asy that?
Did I completely misunderstand him when he said this is another thread? Doesn't lower transaction fees and fast confirmations mean a larger block size?
Once again........ am I completely misunderstanding what he is saying here? He is saying limiting the block size (as it is currently ) drives up fees and makes users pay for their inefficiency. Does this not mean that Gavin is for raising the block size limit which means a fork?
Really? Why do you asy that?
Quote
I think we should put users first. What do users want? They want low transaction fees and fast confirmations. Lets design for that case, because THE USERS are who ultimately give Bitcoin value. - Gavin Andersen
Did I completely misunderstand him when he said this is another thread? Doesn't lower transaction fees and fast confirmations mean a larger block size?
Quote
Really? Improve it how?
Quote
You seem to be saying that we should subsidize inefficient miners by limiting the block size, therefore driving up fees and making users pay for their inefficiency. - Gavin Andersen
Once again........ am I completely misunderstanding what he is saying here? He is saying limiting the block size (as it is currently ) drives up fees and makes users pay for their inefficiency. Does this not mean that Gavin is for raising the block size limit which means a fork?
It's pretty clear that the lead developers want to raise the max block size.
Really? Why do you say that?
From what I've read it seems like a good idea because it will improve the network.
Really? Improve it how?
Anyways...... this requires a hard fork. Do you think the chances of this fork are 100% ?
No.
When do you think the fork will be?
If it happens, then my prediction is that it will be when there is less than a 75% chance of getting a 1kb or smaller transaction with inputs totaling more than 0.1 BTC included in the next block with a fee of 2%.*
*This is a completely arbitrary and unsubstantiated claim that I've made up on the spot simply because it sounded good to me.
There is no indications that any core developer want to change the block size. Maybe when you can't get a transaction in the next block by paying an adequate fee it might be time to consider such a change. There was just one thread with a whole bunch of me too responses from people who think they should get to spam the network with their martingale bot. That's where your post should have been added.
It's pretty clear that the lead developers want to raise the max block size. From what I've read it seems like a good idea because it will improve the network. Anyways...... this requires a hard fork. Do you think the chances of this fork are 100% ? When do you think the fork will be?
edit: [I posted this in here because I don't want it to be a technical discussion. But rather a general discussion of an impeding fork(if that's even possible). That seems a little too important to leave in the developmental forum]
edit2:
Yes, I believe they would. So far, most miners and pools are VERY conservative; I think the idea that they will create huge blocks that have a significant risk of being rejected, just so they MIGHT get an advantage over marginal miners that can't process them fast enough, is loony.
But I might be wrong.
So I'd like to wait a little while, think deeply some more, and see how miners and merchants and users react with the system we've got as transaction volume increases.
BTC
edit: [I posted this in here because I don't want it to be a technical discussion. But rather a general discussion of an impeding fork(if that's even possible). That seems a little too important to leave in the developmental forum]
edit2:
Why wouldn't miners reject interactions with miners who set the block size too high, for instance?
Yes, I believe they would. So far, most miners and pools are VERY conservative; I think the idea that they will create huge blocks that have a significant risk of being rejected, just so they MIGHT get an advantage over marginal miners that can't process them fast enough, is loony.
But I might be wrong.
So I'd like to wait a little while, think deeply some more, and see how miners and merchants and users react with the system we've got as transaction volume increases.
BTC
Jump to: