The firm I work for, which has made substantial investment into Bitcoin, has already thought quite a bit about this. This is what we're doing and thinking:
* While this block size issue remains such a big uncertainty, we have drastically slowed our pace of investment and we've shelved some start-ups that were already in progress. We're not stopping or backing out, but we're proceeding much slower and more cautiously until a clearer resolution to this problem appears.
* If we approach the 1MB limit and a solution does not appear forthcoming, we'll cease all new investment.
* If we pass the 1MB limit without a solution, seeing even the slightest hint that Bitcoin's competitive advantages over the conventional banking and payment systems are being eroded due to an inability to scale, we'll dump all our bitcoin assets and holdings.
* If a controversial solution is proposed, with fierce arguments on multiple sides, we will follow Gavin's fork, even if it's not ideal, on all our sites that accept BTC.
* If the fork hits, and there's even the slightest uncertainty as to which will survive, we will immediately dump all our bitcoin assets and holdings. We will remove Bitcoin from all of our sites that accept multiple payment methods -- at least while we wait to see how things play out.
* If one fork kills off the other, we'll adopt that one and go back to business as usual.
* If both forks survive, with both being widely accepted (for example if Mt.Gox begins accepting Bitcoin-A and Bitcoin-B), we'll accept neither, dump everything, and write off blockchain based currencies and too risky and too unstable.
What we really hope to see is a nice, smooth transition to a system that scales, which very large majority of the network, including major service providers, agree to.
Topic: How merchant will behave when there is hard fork & they are not sure who win? - page 3. (Read 3328 times)
February 20, 2013, 05:42:36 PM
February 20, 2013, 05:34:45 PM
A hard fork won't happen unless the vast super-majority of miners support it.
E.g. from my "how to handle upgrades" gist https://gist.github.com/gavinandresen/2355445
E.g. from my "how to handle upgrades" gist https://gist.github.com/gavinandresen/2355445
Quote
Example: increasing MAX_BLOCK_SIZE (a 'hard' blockchain split change)
Increasing the maximum block size beyond the current 1MB per block (perhaps changing it to a floating limit based on a multiple of the median size of the last few hundred blocks) is a likely future change to accomodate more transactions per block. A new maximum block size rule might be rolled out by:
New software creates blocks with a new block.version
Allow greater-than-MAX_BLOCK_SIZE blocks if their version is the new block.version or greater and 100% of the last 1000 blocks are new blocks. (51% of the last 100 blocks if on testnet)
100% of the last 1000 blocks is a straw-man; the actual criteria would probably be different (maybe something like block.timestamp is after 1-Jan-2015 and 99% of the last 2000 blocks are new-version), since this change means the first valid greater-than-MAX_BLOCK_SIZE-block immediately kicks anybody running old software off the main block chain.
Increasing the maximum block size beyond the current 1MB per block (perhaps changing it to a floating limit based on a multiple of the median size of the last few hundred blocks) is a likely future change to accomodate more transactions per block. A new maximum block size rule might be rolled out by:
New software creates blocks with a new block.version
Allow greater-than-MAX_BLOCK_SIZE blocks if their version is the new block.version or greater and 100% of the last 1000 blocks are new blocks. (51% of the last 100 blocks if on testnet)
100% of the last 1000 blocks is a straw-man; the actual criteria would probably be different (maybe something like block.timestamp is after 1-Jan-2015 and 99% of the last 2000 blocks are new-version), since this change means the first valid greater-than-MAX_BLOCK_SIZE-block immediately kicks anybody running old software off the main block chain.
This is an excellent approach to roll out an increase MAX_BLOCK_SIZE; however for it to work properly it needs considerable lead time. My question is: Is there an estimate as to when we will hit the soft 250KB limit and hard 1MB limit?
The ability for Bitcoin to be able to continue process small transactions with a value in the range of say 0.05 USD to say 20.00 USD is crucial in my mind since this is an area where Bitcoin truly shines.
February 20, 2013, 05:24:35 PM
I wouldn't worry about this. A hard fork won't be performed at all if there is not at least a rough concensus. The block size limit issue is controversial and a full concensus possibly can't be reached, but having major services behind it (Gox, Blockchain, Coinbase, BitPay etc) and a large majority of miners and users would probably be enough.
It's a change that has to be done if we want to give Bitcoin any chance of scaling up to a larger amount of transactions, so it will most likely be done in some way. What the exact change and implementation is, and when it will be done, is obviously still unknown and it will take a while to figure that out.
If even a rough concensus can't be reached, then Bitcoin as it is now is completely doomed. So doomed in fact, that all day to day payments would be done with other cryptocurrencies (superior cryptocurrencies, as I see it) or through completely centralized services. It would also make Bitcoin look extremely bad from a media standpoint.
Centralized services handling a larger amount of payments has another drawback that hasn't been discussed much, it's the fact that using a fractional reserve would become much easier. As long as the blockchain itself is the dominant transaction platform, widespread use of fractional reserve is impossible.
It's a change that has to be done if we want to give Bitcoin any chance of scaling up to a larger amount of transactions, so it will most likely be done in some way. What the exact change and implementation is, and when it will be done, is obviously still unknown and it will take a while to figure that out.
If even a rough concensus can't be reached, then Bitcoin as it is now is completely doomed. So doomed in fact, that all day to day payments would be done with other cryptocurrencies (superior cryptocurrencies, as I see it) or through completely centralized services. It would also make Bitcoin look extremely bad from a media standpoint.
Centralized services handling a larger amount of payments has another drawback that hasn't been discussed much, it's the fact that using a fractional reserve would become much easier. As long as the blockchain itself is the dominant transaction platform, widespread use of fractional reserve is impossible.
Applaud for the excellent analysis, yes I agree it is the centralized services (reserve) that enabled fractional reserve.
February 20, 2013, 05:13:24 PM
I wouldn't worry about this. A hard fork won't be performed at all if there is not at least a rough concensus. The block size limit issue is controversial and a full concensus possibly can't be reached, but having major services behind it (Gox, Blockchain, Coinbase, BitPay etc) and a large majority of miners and users would probably be enough.
It's a change that has to be done if we want to give Bitcoin any chance of scaling up to a larger amount of transactions, so it will most likely be done in some way. What the exact change and implementation is, and when it will be done, is obviously still unknown and it will take a while to figure that out.
If even a rough concensus can't be reached, then Bitcoin as it is now is completely doomed. So doomed in fact, that all day to day payments would be done with other cryptocurrencies (superior cryptocurrencies, as I see it) or through completely centralized services. It would also make Bitcoin look extremely bad from a media standpoint.
Centralized services handling a larger amount of payments has another drawback that hasn't been discussed much, it's the fact that using a fractional reserve would become much easier. As long as the blockchain itself is the dominant transaction platform, widespread use of fractional reserve is impossible.
It's a change that has to be done if we want to give Bitcoin any chance of scaling up to a larger amount of transactions, so it will most likely be done in some way. What the exact change and implementation is, and when it will be done, is obviously still unknown and it will take a while to figure that out.
If even a rough concensus can't be reached, then Bitcoin as it is now is completely doomed. So doomed in fact, that all day to day payments would be done with other cryptocurrencies (superior cryptocurrencies, as I see it) or through completely centralized services. It would also make Bitcoin look extremely bad from a media standpoint.
Centralized services handling a larger amount of payments has another drawback that hasn't been discussed much, it's the fact that using a fractional reserve would become much easier. As long as the blockchain itself is the dominant transaction platform, widespread use of fractional reserve is impossible.
February 20, 2013, 05:09:02 PM
A hard fork won't happen unless the vast super-majority of miners support it.
E.g. from my "how to handle upgrades" gist https://gist.github.com/gavinandresen/2355445
E.g. from my "how to handle upgrades" gist https://gist.github.com/gavinandresen/2355445
Quote
Example: increasing MAX_BLOCK_SIZE (a 'hard' blockchain split change)
Increasing the maximum block size beyond the current 1MB per block (perhaps changing it to a floating limit based on a multiple of the median size of the last few hundred blocks) is a likely future change to accomodate more transactions per block. A new maximum block size rule might be rolled out by:
New software creates blocks with a new block.version
Allow greater-than-MAX_BLOCK_SIZE blocks if their version is the new block.version or greater and 100% of the last 1000 blocks are new blocks. (51% of the last 100 blocks if on testnet)
100% of the last 1000 blocks is a straw-man; the actual criteria would probably be different (maybe something like block.timestamp is after 1-Jan-2015 and 99% of the last 2000 blocks are new-version), since this change means the first valid greater-than-MAX_BLOCK_SIZE-block immediately kicks anybody running old software off the main block chain.
Increasing the maximum block size beyond the current 1MB per block (perhaps changing it to a floating limit based on a multiple of the median size of the last few hundred blocks) is a likely future change to accomodate more transactions per block. A new maximum block size rule might be rolled out by:
New software creates blocks with a new block.version
Allow greater-than-MAX_BLOCK_SIZE blocks if their version is the new block.version or greater and 100% of the last 1000 blocks are new blocks. (51% of the last 100 blocks if on testnet)
100% of the last 1000 blocks is a straw-man; the actual criteria would probably be different (maybe something like block.timestamp is after 1-Jan-2015 and 99% of the last 2000 blocks are new-version), since this change means the first valid greater-than-MAX_BLOCK_SIZE-block immediately kicks anybody running old software off the main block chain.
February 20, 2013, 04:56:51 PM
Then no matter how miners behave, [...]
If a lot of miners leave to a different fork, you're into 51%ing trouble. A lot of it (especially with ASICs around).
February 20, 2013, 04:52:11 PM
There is a in depth discussion about the block size limit right now and all focus on its impact IF implemented, but in case of a hard fork, how merchant will behave - merchants who do not care philosophies but their bottom line?
In the event of a hard fork, and in the phase that there is no clear winner , I think merchant would choose to have asking clients paid in both networks in the same amount, this is natural choice and no matter who wins, they still keep their bottom line. Unless transaction cost differential between the two become very extreme, isn't that people will who buy from merchant would agree to do so?
Then no matter how miners behave, how long term impact different fork could be, in the end, the one with the bottleneck would still dominate "bitcoin" properties, and in this way, new hard fork would in a way, not relevant (effetive)?
So as time goes by, the hard fork seems should not win the "classical" fork.
In the event of a hard fork, and in the phase that there is no clear winner , I think merchant would choose to have asking clients paid in both networks in the same amount, this is natural choice and no matter who wins, they still keep their bottom line. Unless transaction cost differential between the two become very extreme, isn't that people will who buy from merchant would agree to do so?
Then no matter how miners behave, how long term impact different fork could be, in the end, the one with the bottleneck would still dominate "bitcoin" properties, and in this way, new hard fork would in a way, not relevant (effetive)?
So as time goes by, the hard fork seems should not win the "classical" fork.
Jump to: