Question for Peter Vessenes about Mt.Gox accounts after the hard fork

[nikkisnowe]

I thought that you would be most capable of answering this question since you seem to be the spokesperson for both Mt. Gox and Coinlab recently.  My question concerns how Coinlab/MtGox plans on responding to a hard forks on the blockchain.  I am particularly concerned about the upcoming hard fork in relation to the change in the blocksize limit.    The current limit on number of transactions per second is the Achilles-heel to bitcoin and it will be changed.  I think any rational person in the bitcoin community realizes this and the result is going to be a hard fork in the near future.  So my question is what has Mt.Gox/Coinlab done in preparation for this? 

Once the hard fork occurs, there will be two separate blockchains either competing for supremacy or the two will be able to somehow exist separately, though I don’t know how.  In whatever case, once the hard fork occurs there will immediately be Bitcoin-A which can be verified by miners running the new release with the larger blocksize limit, and Bitcoin-B which will continue to be verified by miners who have not, or will not upgrade to the new Bitcoin release.  Anyone who held bitcoins prior to the new release resulting in the hard fork will hold both types of bitcoins. 

So what about Mt. Gox account holders?  They don’t hold bitcoins but instead hold a promissory note to bitcoins until they choose to move them to a personal wallet or if they want to exchange them for some other fiat currency.  Which bitcoin will they hold after the hard fork?  Both types will have value and I can’t believe that Mt.Gox/Coinlab is going to unilaterally decide which type of bitcoin account holders will now have.  I assume that there will be some way that account holders will have two sub-accounts representing the Bitcoins on both block chains.  If not, Mt. Gox/Coinlab is going to have a nice windfall as they are going to have access all of the other bitcoins on the other blockchain not held by the account holder.  I can’t imagine that account holders are going to be too happy with such a situation.  I also wouldn’t doubt that  someone  hasn’t already prepared a draft Complaint and Motion for Class Certification for a class action lawsuit in preparation for when the hard fork occurs, just waiting to fill in the names and dates.

Thanks 

[misterbigg]

Considering that the "hard fork" is far in the future, and that the block size limit is not a problem yet, and that even if it was a problem resolving it immediately is not a pressing need, and considering that to have any chance of being viable the hard fork would need consensus of practically the entire community, the logical strategy for business entities like MtGox, CoinLab, et. al. for "dealing" with it is to simply do nothing at all until a winner emerges. When it does, it will probably have support of 95+ percent of miners, other businesses, and users, at which point all that needs to be done is upgrade to a new version of bitcoind and life goes on.

A better question would be if the principals of those companies are even aware of the max block size "problem".

[acoindr]

You're speaking like a hard fork is a certainty. I don't think it is. A fork only occurs if there is significant difference of opinion about how to continue forward. Gavin, who of course has a lot of influence over that issue, said this:

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.

This route makes sense to me as it's essentially a self-authorizing change. In other words, either the super-majority of miners agree with change or no change happens.

[tvbcof]

I hereby formally give ~vess/Coinlab/Mt.Gox permission to do anything they like with all the BTC in my account vis-a-vis the supposedly impending and supposedly critical hard fork which is so ballyhooed by a contingent of new faces on this forum recently.  Of course, anyone who understand Bitcoin will realize how absurd my 'authorization' is.

I think I may have around 4 BTC there, but it's been a year since I logged on and I'm to lazy to check.  Sent from Bitcoinica, IIRC, when I decided that having more then a few buck at risk there was silly and got done playing (and multiplying my money by 10x through dumb luck.)  Most went to ~goat who claims they funded some enjoyment for needy Thai kids (and who I happen to believe about this...his pictures being more credible than BFL's.)