Where does authority lie in a decentralized system?

[tom11011]

So I have been following the news of this fork issue.

I received a message on my bitcoin wallet saying "URGENT: chain fork, stop mining on version 0.8".

I was curious how this message manifested itself?  If there is no central authority, how does this message come about?

Also, in the really long thread describing this situation, it was mentioned several times about the possibility of forcing users from .7 to .8.  Something about a last block for .7.  Again, I have the same question, how would this come about in a system without a central authority?

Thanks.

[theymos]

I was curious how this message manifested itself?  If there is no central authority, how does this message come about?

The alert system is centralized, but it's only a message. It can't force your client do do anything.

Also, in the really long thread describing this situation, it was mentioned several times about the possibility of forcing users from .7 to .8.  Something about a last block for .7.  Again, I have the same question, how would this come about in a system without a central authority?

They can't really be forced to upgrade, but if the vast majority of people had upgraded to 0.8, 0.7 users would have been isolated. They would have needed to upgrade to continue trading with 0.8 users.

[Stephen Gornick]

I was curious how this message manifested itself?  If there is no central authority, how does this message come about?

These people have alert keys and should be contacted ASAP in case of emergencies:
Satoshi
Gavin
theymos

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

Also, in the really long thread describing this situation, it was mentioned several times about the possibility of forcing users from .7 to .8.  Something about a last block for .7.  Again, I have the same question, how would this come about in a system without a central authority?

There is an authority, it comes from the longest chain.  That is reached through consensus.

Right now the longest chain is block 225453:
 - https://blockchain.info/block-index/357985/000000000000031803e492a0103154d243c9945ef78dbdba42a1ecfdb5bc5dbb

So normally a miner would be building off of the block at the greatest height and now working on extending that ... building the next one, 225454.

Except we know that that specific one is created using v0.8.  And it will be orphaned.  And a miner that solves an orphaned block gets 0.0 BTC as a reward for that effort.  Miners can only spend generated coin from blocks once that block has 120 confirmations.

So now a (large) majority of miners are now running using v0.7, and the block with the greatest height that v0.7 client knows of currently is this 225445:
 - https://blockchain.info/block-index/357992/000000000000012966aca980b406faa35b4c7abcc896846794f2c3f6f9b63aa0

So even without an authority ordering miners around, miners do what is in their own best interest.  Everyone on the same blockchain chain.  And to get there, dropping to v0.7 was the quickest way to get there.

[Severian]

Miners can only spend generated coin from blocks once that block has 120 confirmations.

Learn something new everyday. Thanks, Stephen.

[Stephen Gornick]

Ok, if there was some major major bug that happened and people couldn't just revert to an older version, would there be some coder authority as to who was fixing the code?

I'm a little unclear as to how open source projects get worked on.

This was actually a good example to help describe this.

When the plea came for miners to downgrade to v0.7, those pools (and large solo miners) who had already solved the six or so blocks on v0.8 (v0.8 was ahead by about six blocks at that point) had the option of continuing on v0.8 instead of abandoning those blocks (and the bitcoins they would earn) when downgrading to v0.7.  Let's say these miners held their ground in order to try and keep the bitcoins from those six blocks.    

It would soon be apparent that the plea was being ignored by enough miners and that there was still plenty of hashing on v0.8 such that it would take a long time for v0.7 to catch up.  So instead it would then be those mining on v0.7 that would be faced with a decision:
 - a.) Do nothing and continuing to mine against a fork in which every block stays orphaned
 - b.) Upgrade to v0.8 (which could take hours or days to complete)
 - or c.) Implement a fix and start mining using it.

If the BDB issue was fixable, there would likely have been a bunch of frantic development and testing performed and code slipstreamed into production.  (i.e., option "c.)" would have been chosen)

So if there was a fix, that code would have been running by pools and large solo miners before there was even an release published.      Source code containing the patch can be transferred via a pastebin/gist/text file/e-mail attachment in most instances.     It wouldn't be forced on them, but when choices are limited, the path of least resistance is often chosen.   Fixing v0.7.x (again, if it was fixable in a reasonable amount of time) might have been the outcome instead.  

Eventually releases with the fix would be published through the more formal process (built and tested prior to release, etc.) so that even those who don't build directly from the source code themselves can switch over and resume mining on the longest chain.

This process isn't uncommon.  There have been vulnerabilities where the developers share the remedy with pool operators, large miners and others before sharing the fix publicly.  So building from source code is something most pools and large miners are prepared to deal with.