Topic: How merchant will behave when there is hard fork & they are not sure who win? (Read 3328 times)

How? Old version reject block bigger than the limit, you new version generate one and ask older version to accept? You discovered a vulnerability/bug in the old version?

That realization about the impossibility of raising the maximum block size via a hard fork worried me enough to the point where I actually think that my statement that it would require a hard fork might be wrong. 

But seriously, I think that I've come up with a soft-fork version of accomplishing the same thing. A soft-fork would allow us to deploy the rules for increasing the maximum block size in less then a month instead of several years, assuming it was coded ahead of time and it was considered extremely high priority. It's a terrible hack job, but to the users it would be fairly seamless. Not to give too much away just yet, but it'll be fully backwards compatible functionality wise down to version 0.6.0. I'll post the technical details in the next few days.

Do you have anything by way of actual evidence of this?  Not that I do or don't believe it, but it is easy and common on this forum for people to pull shit like this right out of their ass.

Why did the limit get set as it is knowing that it was going to be a nightmare if/when it ever was to be changed (if you have any real clue?)

Do you have anything by way of actual evidence of this?  Not that I do or don't believe it, but it is easy and common on this forum for people to pull shit like this right out of their ass.

Why did the limit get set as it is knowing that it was going to be a nightmare if/when it ever was to be changed (if you have any real clue?)

...mit would be raised, but the discussions about whether it would be raised at all with opposition from a significant amount of people. That turned the idea of raising the limit into a complete non-starter since it requires a hard fork, despite the fact that changing the maximum block size has been the plan since the very beginning. ...

...
I find it neither surprising nor unhealthy that the various primary developers have different ideas about what is important.  
...

No hard fork will be introduced unless it's clear who will win.
...

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

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.

So, let me be clear: what set me into panic mode was not the discussions about how the limit would be raised, but the discussions about whether it would be raised at all with opposition from a significant amount of people. That turned the idea of raising the limit into a complete non-starter since it requires a hard fork, despite the fact that changing the maximum block size has been the plan since the very beginning.

Exactly. In fact, BradZimdack's thoughts are exactly same thoughts that I had a few days ago, except my thoughts were on an individual level. So, let me be clear: what set me into panic mode was not the discussions about how the limit would be raised, but the discussions about whether it would be raised at all with opposition from a significant amount of people. That turned the idea of raising the limit into a complete non-starter since it requires a hard fork, despite the fact that changing the maximum block size has been the plan since the very beginning. I can understand not liking Gavin's plan of just allowing the blocksize to be unlimited and having the market sort things out (I don't, either), but I'm sorry, it takes a special kind of stupid to say that no hard forks can happen ever because you "subscribed to the constants" instead of the spirit of Bitcoin like the rest of us did.

If you are arguing for staying at 1 MB/block because that is the constant you would choose today if you pretend that we could reset the constant to whatever we wanted to (whether that be another constant or an algorithm), that's fine. It's a valid choice. I'd be interested to know why you prefer specifically that number over the other options. But to argue that we should keep the limit there because all change is evil is both irrational and stupid. Whatever we decide to do, it's not going to be something that we rush into. Also, you'll notice that in these discussions not a single supporter for this change has even proposed changing the important constants like the total final money supply, so the slippery-slope argument does not apply.

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.