In related news the entire NASDAQ must run on a single server because it is impossible for trading engines to span multiple servers.

That assumes
That assumes no other transactions on the network.  As tx volume increases legit users will raise their fees to ensure they are included in blocks in a timely manner.  That means you would need to start paying fees (and then increasing amount of fees) or find your tx excluded.  However yes with a "principal" of 144,0000 BTC you could add 1,000 tx to each block assuming you also could afford sufficient tx fees to "buy" enough space for them.

I am buying all the US one dollar bills you don't want.  
Offering $0.50 each (or equivalent in BTC or bullion).  Please PM me for mailing address.

Yeah me either.  My first development job was a glorified code monkey and it still sounds lightyears better than that place.  Never even seen a professional salary contract which involves docking ones pay.  Screw up bad enough and you might get terminated but even then I have never seen "take backs" on salary.

No there is some NDA stuff in there.  The paraphrased version is something like

Coinbase transactions (block rewards) from the roughly 25 orphaned blocks in the v0.8 chain.  It was important to resolve this before either chain was more than 100 blocks past the fork as then those coins would be spendable which would have been "chaotic".

To prevent/reduce spam creating a new wiki account requires a Bitcoin donation before you can edit.  0.001? BTC IIRC.

https://en.bitcoin.it/wiki/BitcoinPayment

That is false (or at best incomplete).  Spammy tx are spammy regardless of age and thus always low priority and thus always require a fee to be included by miners or relayed by nodes using the reference client rules.

How are you going to "fix" something you don't understand?

Transactions are valid on both branches of the fork.  You send 1000 BTC to a merchant on v0.8 it is seen by the merchant on v0.7 so when you attempt to double spend it is rejected by the merchant and/or every relay node.

The fork was on BLOCKS not transactions.  All the transactions (except coinbase tx which are unspendable for 100 blocks) on the v0.8 branch are visible on v0.7 branch and vice versa.

No.  It may take a very long time to be confirmed.  If you bypass the spam rules (required modifying client source code, using patched versions, or building transactions manually using raw transaction API) it is possible to create a transaction which is INVALID and that will never confirm.

However as long as you have the private keys you can "fix" that by removing the bad transaction from the wallet and waiting for the network to forget about it and then spending those coins again.

You are intentionally ignoring the real consequence.  It isn't that users are "forced to upgrade".  Devs have recommended security upgrades in the past.   It is that users who didn't upgrade (possibly because they are unaware) would have been easily "robbed".  Downgrading v0.8 has no lasting security implications.  Allowing the network to remain forked presented a real threat to the security of user's transactions.  It would be asinine to chose anything over the security of the network.  The news of this fork has been relatively muted.  Can you imagine if the decision to force through v0.8 had been made and thousands of users were robbed for millions of dollars worth of Bitcoins in 51% attack, accepting bogus generated coins, and even trivial no-hash power double spends. 

Which presents a real THREAT to the trust in the network.   The need to upgrade or lack thereof is a strawman.   My guess is you will now make another strawman attack about needing to upgrade as you have done twice now.  Don't worry I won't see it so you an "winz the internets".

Shows a lack of understanding of how Bitcoin works.

There are no coins so there is nothing which can be "gone".  MtGox has the private key and hasn't lost or compromised itso either:
a) the tx will eventually be confirmed and then every node will "see" it.
b) the tx was flawed and will be forgotten by the network in time however in that case MtGox will still have the unspent output (value) used in this transaction.

There is no scenario where coins can just be "gone" unless you lose the private key (or send them to an address where the private key is unknown).

Gweedo has been butt hurt for a long time that Gavin can collect a salary for his skills.  There aren't a lot of people which share his opinion.  Don't let one loud butt hurt troll make you think it is a representative sample of the community.

I mean it is just an asinine reaction.  All software projects have bugs.  Salaries are for work not perfection.  The idea that any entity anywhere would retroactively seize one's pay because of a bug is just ... well stupid.

It was never a founding principal for greater hashing power to resolve hard forks.  Hard forks by definition can't EVER be resolved by hashing power.  If a single node remains on an incompatible fork it exists as a parallel implementation of Bitcoin.  Creating a precedent for using hashing power to fork the network is horribly dangerous and will lead to intentionally putting bugs into the codebase to force a fork for profit.


You are completely uninformed.  v0.7 nodes didn't crash they simply rejected the block.  The risk is that v0.7 nodes would be vulnerable to attacks by double spends, 51% attacks and accepting newly generated coins from the incompatible v0.7 generation blocks.

The rational for rolling back to v0.7 was to prevent massive chaos, and loss of confidence and scammers and fraudsters looted the users of running older nodes.  Nobody is saying we will remain on BDB forever but the transistion can be better managed.

A v0.81 can be released which uses the new db format but prevents incompatible blocks.  older version users can be strongly encouraged to upgrade to the new version and warned of potential risks in staying with incompatible older version.  Where a vast super majority (not of miners but of ALL stakeholders, users, exchanges, merchants, service providers) are on the new platform a final critical warning can be released notifying users of older version they face significant risk of being forked away if they don't upgrade and then the incompatible block rules can be introduced.

TL/DR a planned transition instead of a "fork it and if people get fucked in the chaos, well too bad" attitude.  Which do you think will destroy trust in the Bitcoin network?

Then do it.  Take the codebase fork it and produce BlinkCoin.  Let the market decide which one is superior. STFU or do it.   Here is my challenge to you.  "You can't. You absolutely and completely lack that skills to accomplish what you claim".  Prove me wrong.

Should google or amazon have trading hours too?  Should email only work 9-5 M-F?  Should the blockchain have processing hours?

Trading hours like banking hours are just an anachronism from a time when those activities were highly manual.  There is no reason to not have 24 hours exchanges just like there is no reason for banks to not process bank wires 24/7.  They don't need to have a branch open to process a fedwire (which is no more technically complex then an email).  However 5:01PM EST and like magic bank wires instantly halt until the next business day.  Why?  They have a monopoly.  Monopolies don't have to offer better value to customers.  If the bank won't take your bank wire at 5:01 PM EST what are you going to do?  Hop on a plane with a bag of cash and hand deliver it?

An exchange which implements trading hours will quickly lose business to those who don't.

There seems to be some confusion on why a call to rollback to v0.7 was made so hopefully this will dispel some myth.

What happened?
The network hard forked on block 225433.  The block produced by a v0.8 node was rejected by at least some v0.7 nodes.  Contrary to initial claims this was more complex than just "the block was too big".  Blocks right up to the 1MB limit have been created and relayed without issue on testnet.  The BDB used by v0.7 failed to validate the block 225433 due to an inability to handle the number of tx inputs (not to be confused with block size or number of transactions) and rejected it.  This was an undocumented issue with v0.7 ("bug").

At this point a hard fork existed.  The mining nodes running v0.8 built upon the block 225433 and extended their chain.  The nodes running v0.7 rejected the block 225433 and eventually produced an alternative and incompatible block "225433a".   Since the deviation was uni-direction in theory v0.7 could eventually surpass v0.8 chain and re-unify the network however v0.8 chain had a significant majority of hashing power and that never happened.  By the time the issue was being analyzed v0.8 was over 5 blocks ahead and pulling further ahead with time.

Why was the fork time critical?
The users on v0.7 fork would never rejoin the network.  If all those users shutdown their clients and didn't accept any transactions there was no real risk for them.  However in time as hashing power fled the v0.7 fork remaining nodes would become more and more vulnerable to a variety of attacks.  Not just from a potential 51% attack, but also from accepting generated coins which were valid on the v0.8 blocks and even non hashpower related double spends. 

Why not just let "most hashing power wins"?
The "most hashing power wins" concept is used to solve splits/reorgs not hard forks.  It would create a bad precedent.  Essentially miners on v0.8 node would be leaving potential v0.7 users vulnerable to attack to save a few block rewards.  Since non-mining nodes (users) running v0.7 would never accept the #225433 block produced by v0.8 they would have no method to rejoin the longest chain short of upgrading.  v0.8 users (non miners) would accept blocks produced by v0.7.  By having a few miners downgrade to v0.7 it "reunified" the network in the shortest period of time with the smallest number of changes required.

What if developers/pool operators couldn't reach a consensus?  Would this have destroyed Bitcoin?
No.  The v0.8 chain would continue.  v0.7 users would be urged to immediately stop all transactions and upgrade.  Users on v0.7 clients would remain (increasingly) vulnerable to a variety of attacks if actively engaging in transactions until they upgraded.  Eventually all users would upgrade and the network would have continued with the v0.7 branch being an oprhaned sidechain.  The potential threat to active v0.7 users would make this less than optimal but the network as a whole was never in any danger of failure.

Was there a real risk of 51% attack on the major chain?
Not really.  The v0.8 chain had roughly 60% of the hashing power so to double spend that chain would require more hashing power than 60% of the Bitcoin network.  While 60% is less than 100% it is still a staggering amount of hashing power.  Any malicous actor building out a network that large wouldn't stop and wait for the remote chance that 60% would be enough.  Anyone with that amount of time and resources would be planning to outbuild the full network and attack.

What risks were there for users on v0.7 fork?
The largest risk would be from a 51% attack.  Initially the v0.7 fork was relatively well protected but had it been abandoned in favor of extending the v0.8 chain that hash power would have dropped over time.  The longer a user remained active on the v0.7 network the more danger they would be in.  Eventually hashing power would fall to a level where even a small pool could have easily executed double spends.  

Users on the v0.7 would eventually (100 blocks after the fork) be at risk of bring double spent by newly generated coins.  The coins would confirm but once they upgraded to v0.8 that transaction would never exist (as the block producing it also never existed).  v0.7 users who heeded the alert key warning and stopped all transactions were never in any significant danger.  

Lastly a smart attacker with good timing could have executed a "no hashing power" double spend against vulnerable v0.7 users (who continued to engage in active transactions despite the alert key warning).  A simplified version of this attack would work like this.  As hashing power on v0.7 fork fell, the block generation rate would slow and the number of transactions in the memory pool would increase.  An attacker could exploit this differential by creating a large number of low/ no fee transactions and wait for some of them to be accepted into v0.8 blocks.  The Bitcoin network will eventually forget about unconfirmed transactions as they get old enough to fall out of the memory pool.  Normally a client will rebroadcast an unconfirmed transaction periodically but in this case the attacker's client would see the transaction as confirmed.  The attacker could speed up this process but producing a large number of unrelated transactions.  When the tx in v0.8 blocks were dropped from the v0.7 memory pool the attack could double spend victims on the v0.7 network.

What trust was lost?  The network proved its resilience.  A downgrade wasn't even necessary.  The majority could have stayed on v0.8 and it would have forced all v0.7 users to upgrade.  Of course that would have left them vulnerable until they did.  Even if no downgrade was possible the network would have survived just fine.

Worst idea in the last 24 hours.  That is pretty amazing given the pretty much nonstop run of bad ideas.  There will not and should not EVER be a forced upgrade option for Bitcoin.  Not today, not tomorrow, not a century from now.  Your idea would be a "kill bitcoin" button available to anyone with the resources (either financial or through use of force) to push it.