Topic: Continuity of support (Read 672 times)

To me it feels like the recent situation was handled very well indeed; it's hard to image it being handled even better.  We risk being spoiled.  Will every future situation be handled as well?  Imagine Bitcoin in the future; the future when Gavin et al own private topical islands and have retired.  Even if they can be called out of retirement, it could delay responsiveness.

I couldn't agree more; each entity with a dependency on Bitcoin really ought to put some effort into formalizing their contingency plans.  Just because a fresh/capable dev team is active today is no guarantee for the future.  Strategic investments aimed at keeping the dev team renewed is a key part of such a plan.  Scrambling to engage properly skilled developers in an emergency is likely to delay the resolution and risks getting a less than great resolution.

Or does Bitcoin reach such a mature state that development literally comes to the end?  Can it ever be considered mature/robust enough to tolerate any and all problems automatically?

Traditional currencies go through phases too.  Once not so long ago there were no US dollars.  Although it is effectively the default global currency for now, just like many other currencies it could eventually be demonetized http://dollardaze.org/blog/?page_id=00017 and be added to the list of historic currencies http://en.wikipedia.org/wiki/List_of_historical_currencies especially if Bitcoin does exceedingly well.

Transactions have inputs (which spend previously unspent transaction outputs) and outputs.  The exception is the first transaction in the block which is for generated coin and fees.  
 - http://en.bitcoin.it/wiki/Transactions#Generation

Here's the coinbase transaction for the first block of that March 11th blockchain fork.
 - https://blockchain.info/tx/9bfae0ea23bc15db2b0cfba42926e32a396103ca080baa73349936f38c6ab7b0
The amount was 26.70259792, which consists of 25 BTC for the generated coin and 1.70259792 which is the total of the fees of transactions in the block.

The miner can't spend this coinbase (neither the generated coin nor the fees received) until it has 120 confirmations.


For the fees.  Right now the fees are a small fraction of the block reward subsidy.  That's why the subsidy is so high, to help get a sufficient level of protection (hashing capacity).


Nope.  Longest chain for the agreed upon protocol wins.

What happened this past week was there was a change to the protocol in v0.8 that nobody realized happened.   Then there had to be a decision -- which side should win, and are there sufficient resources behind the decision that it would succeed.


Well, BitPay was watchful and noticed it, halted their daemon and started investigating.  At least one pool's monitoring detected it however it apparently wasn't acted upon in a timely manner.  I suspect one or more exchanges were watchful and noticed it,.     The v0.7 client automatically detected that it was behind and displayed a warning to its users.   In this case, unfortunately, it was the v0.8 clients that needed to be warned, but since that was the longest chain, they shouldn't have cared as the assumption is that longest chain six or more blocks ahead is final, never to be surpassed.


When the VISA/MC/AMEX payment card systems go down, merchants can't get authorization, but they still fall back to the imprint method (pencil + POS receipt, and scratch the pencil across the receipt on top of the card, makes an imprint of the card on the receipt.)   There's no guarantee the retailer would win in a dispute, so this only works if the customer can be trusted.      

During the time of the accidental hard-fork this past week, there was no reason for a merchant to stop accepting payments from a trusted counterparty.  Those transactions all (or nearly all) got processed in blocks on both chains and no problems occurred for those.   Neither outcome of the decision to go with one side or the other mattered for those transactions.  As far as how long the wait was, the first reports of a problem trickled in at March 11, 2013 at 23:10-ish, and it was only less than an hour later, March 12, 2013 at 00:02 that dev's realized they might be facing a crisis, at 00:06 that they confirmed it, and 3 minutes later Mt. Gox and poolops were alerted.  At 00:30, while devs were still deciding (though nearly all in agreement towards the v0.7 side) the largest pool unilaterally began preparations for switching over to v0.7.  And within a half hour from there that became the decision that was communicated out.

This scenario is a little different from other potential crisis situations but there definitely were some lessons to be learned.   The contingencies list (from the Wiki) didn't cover this specific type of incident but the steps it did have were followed and helped.


I do see how if there ad been one or two of the core developers who were unreachable or unable to help how the outcome could have been worse. (e.g., if Sipa hadn't been able to crank out a band-aid fix for v0.8 so that Slush's v0.8 would work on the chain on the v0.7 side.)  

But remember, there's no "Bitcoin, Inc."   These core developers are volunteers (except for Gavin).   It will probably be the major participants who each build a crisis response strategy suited for their own needs and collaborate where appropriate.

I gather you are not referring to Coinbase https://coinbase.com/ specifically but rather the database of Bitcoins, right?  Does the coin database (is this the block chain?) grow without limit or is there some sort of truncation eventually?

"... a miner's proceeds ..." -- If I understand then you mean the miners will continue to mine even after the last of the 21,000,000 Bitcoins are mined.  They will "mine" not for new coins anymore but instead just for the, um, confirmation/validation/encryption of the new blocks of transactions.  Neat.  So, as long as new transactions continue to flow the miners can still make a living.

Hmm, two miners (unintentionally or deliberately) creating divergent block chains force entities to make a choice; the majority win.  Entities should always desire to be on the winning side otherwise they risk becoming the victims of double spends.

In the earlier moments of a hard fork (who's job is it to be watchful and broadcast the alert?), it might not be clear at all which side will become the winning side.  Entities (at least those in the know) would be wise to wait (for how long?  what if a paid service is life critical?) for the situation to settle down.  Hmm.  It feels like waiting is not acting with authority.

In theory there might not be a central authority per se but in practice continuity of support can potentially provide quicker and higher quality results reducing the risks to the Bitcoin community.

The transaction fees are claimed in the coinbase, so a party refusing to accept a miner's proceeds (by boycotting a corresponding protocol change) means also refusing both the block reward subsidy as well as any transaction fees.

Unfortunately I get the following error when I attempt to register for the Bitcoin Foundation forum;

"The administrator is currently not accepting new membership registrations."


Your responses are keenly on topic and thorough despite a newbie's unschooled groping.

Someday over the rainbow when the last of the 21,000,000 coins is mined then where will the authority come from?

With serious amounts of funds at stake, you are correct.  A post on the Bitcoin Foundation forum might be a good place to raise this topic.


I was giving a "for instance".  I've no knowledge of anything like that being tried.   They definitely have the power to do that though (choose which protocol to use, then communicate that decision to the miners).  


The majority of mining capacity is needed to maintain having the longest chain.  

There's no contract from Mt. Gox to its accounts specifying that mt. Gox must use the longest chain and only that chain.  That is the protocol though and not doing so would probably not be something sane for Mt. Gox to do in most instances.   But let's take the reverse.   Let's say there was a catostrophic security breach at Mt. Gox and they put out code that would hard fork -- making the stolen coins and any that had taint worthless.   If the mining pools went along, they have 51% combined then the protocol would change.  If the mining pools instead ask around, they might conclude that taint would put into question bitcoin's survival and simply forge on without the code "remedy" offered by Mt. Gox.  The community can buy their coins at other exchanges, and then Mt. Gox shrivels into insignificance as a result.     That's a hypothetical, but I use it to describe that the "authority" is not the miners, not any single exchange, but those who will buy the mined coins.  

If Mt. Gox customers would stick with Mt. Gox and Mt. Gox has 80% of investor interest, then Mt. Gox can have a huge influence (as a proxy of its customers).   If investors will bypass Mt. Gox to buy the coins from the miners, then the investors have the authority.

The authority comes from whomever will buy the newly mined coins.

I certainly appreciate your responses.

It seems to me, the time to resolve and the quality of the resolution are improved by having unencumbered communications between vested parties.

Apparently Mt. Gox can dictate to the miners despite the developers.  Is this desirable?  If another entity attempted to dictate to the miners contrary to Mt. Gox then the majority would win, right?

There's a documented release process.  Trying to ram something through without going through the process would raise suspicions.

If it is a patch, that is likely delivered not as a binary but as source code.

Yesterday nobody was pressured to switch over to running new code.  They were pressured to abandon new code which was found to be broken in a way nobody previously had been aware of.


The problem is with situational awareness.  

When on March 12 about 03:00 am UTC when OKPay credited a customer for a deposit worth about $10K USD, the alert had already been broadcast.  There already was a blockchain fork reaching over a dozen blocks.   Either OKPay didn't know about the current situation or got bad information.   They are the ones who have money on the line.  

Once a fork was detected using customized monitoring solutions a "safe mode" switch which was thrown which protected some pools, exchanges and processing services (e.g., BitPay) from accepting transactions or confirmations once the fork occurred.   They and their customers are the ones who make the decisions, and they had the information to halt processing of new transactions and confirmations (or even shut down completely until resolution, like many merchants and exchanges did.)

Let's say the decision from the developers instead had said to stick with v0.8, and all miners, merchants and users on v0.7 and prior would have to upgrade.  

That decision isn't theirs to make.  They can suggest, but they can't make that decision for miners, merchants and users.

If that decision was more harmful than the alternatives, those who acquire new coins would have resisted it.    Miners follow the rules of whomever is taking their coins.  If Mt. Gox had said they were switching to the v0.7 and got word to the v0.8 miners that "your blocks are no good at our exchange", those miners would have switched to v0.7 regardless of the direction recommendations from the developers.  It is an economic certainty.  Choose -- follow the devs recommendations or get paid.   Guess which wins?

So what the process you are describing for protecting continuity of central authority doesn't work -- there is no central authority.

To me it looks like the viability of Bitcoin depends on the availability of lead decision makers to act freely -- how do we detect if a lead decision maker is under duress?  How does decision making reliably transition?

Well, what services are needed for the Bitcoin network to continue?

Yesterday, the services offered included management advice: (obtaining consensus among a small group of trusted individuals (core developers on #Bitcoin-dev) to decide on a plan and then to persuade the parties affected (mining pools, large solo miners, etc) to participate.), communications (the notice on the Bitcoin.org website, the Bitcoin client network alert broadcast, forum post by Sipa, twitter post @GavinAndresen).

If it had involved a software patch, release of that would have been another service the group provided.

If there was just a fraction of the team members available, or they couldn't use IRC and had to communicate via e-mail or something like that I don't know what the outcome would have been.

So there definitely was reliance on a set or people and a method.

The contingency plans touch on some of this:

 - http://en.bitcoin.it/wiki/Contingency_plans

Just like there is a Continuity of government http://en.wikipedia.org/wiki/Continuity_of_government, it seems to me there ought to be a Continuity of support (or whatever it should be called) for the Bitcoin capabilities.