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?
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#GenerationHere's the coinbase transaction for the first block of that March 11th blockchain fork.
-
https://blockchain.info/tx/9bfae0ea23bc15db2b0cfba42926e32a396103ca080baa73349936f38c6ab7b0The 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.
They will "mine" not for new coins anymore but instead just for the, um, confirmation/validation/encryption of the new blocks of transactions.
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).
Hmm, two miners (unintentionally or deliberately) creating divergent block chains force entities to make a choice; the majority win.
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.
In the earlier moments of a hard fork (who's job is it to be watchful and broadcast the alert?),
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.
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.
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.
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.
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.
Show Posts
that was a big problem. It is mostly resolved with v0.8.
