Quote from: casascius on December 25, 2011, 07:35:08 AM

Was thinking a bit... about what would happen in the event of a 51% attack.

Imagine a 51% attack against Bitcoin that was begun in secret, to create a large alternate chain that simply reversed a very large number of blocks, and persistently prevented any transactions from confirming. The chain would be published all at once as a surprise and would propagate across the network faster than any worm.

Even if many of us could deal with that, the news would say "BITCOIN HACKED", that would be the end of Bitcoin as we know it, at least for a short while, until we all scattered around and figured out what to do about it.

The problem with a 51% attack done this way is its effects would be sudden and instant. The repair would be several days while the developers figure out what to do, and several more while the bugs get fixed, and plenty more time while people download it, repair their block chains, backport the patch to their customized clients, get back in business... meanwhile, we'd have lots of angry miners whose mining work on the fake chain got reversed, etc...

I would like to propose a couple simple things now relating to checkpointing so that the solution is known and the disaster preventable all the way in advance.

Basically, what I am proposing is that a) trusted entities put signed checkpoints in the block chain - which are nothing more than assertions that "I have seen the block with hash x", and b) that the client have some sort of list of trusted public keys (modifiable by power users, but otherwise pre-seeded by client authors) so that trusted parties can be recognized but also removed if needed.

Signatures would appear periodically in blocks, which would be part of real or dummy transactions. MtGox, for example, may occasionally initiate a transaction to itself (or embed in one of its payout transactions) a signature referencing the hash of a prior block, simply to say "I saw this". MtGox need not sign every single block - since each signature acknowledges all blocks before it, there will be other signers participating, and the scheme is mainly targeted at attacks on 6+ blocks, the signatures could be done three or ten or any other reasonable number of blocks apart.

Mining pools would do the same except would likely use the coinbase transaction as the location for their signature.

Very simply - if I as a client have block X, which I know has been seen by MtGox, TradeHill, and a dozen mining pools and trusted parties... I can quickly and confidently reject block Y which purports to replace block X with a higher proof of work.

To implement this proposal, all that would need to happen is:

client gets a mini database to track trusted public keys, possibly kept in wallet.dat, but pre-seeded from hardcoded values in the client
client gets an RPC call to modify this database for power users
definition of "standard transaction" amended to include one that packs an OP_DROPped signature so that trusted parties can count on their stamps of approval being relayed
the logic for handling chain reorgs more than 3 blocks deep is revised such that blocks known to have been seen by a majority of the trusted crowd are impervious to being preempted by blocks that have not.

The vast majority of client users would be using the default list of trusted public keys and would be unlikely to modify it, so the onus would be on the authors of clients to appropriately judge who belongs to be on the list. The idea of allowing the client author to update the list remotely isn't out of the question - a suggestion probably not appropriate for the reference client - but entirely plausible for smaller-time clients whose users could just quit using if the authors were up to shenanigans.

Casascius, I really don't think people understand how important it is to understand what your proposal is saying. For me when thinking about it, it says exactly what will be the doom of Bitcoin it this in some way wont get implemented in the future.

I am sure that your proposal of checkpoints of trusted entities is pretty much unnecessary when the total market cap of Bitcoin is $100M or even as much as $1 Billion, but the question is what this does if and when the market cap is nearing $10 Billion? Bitcoin is going head to head against central banks, politicians, all fiat money and the status quo of everything that the average joe knows and accepts about rules of finance and economics in the world. When something like Bitcoin comes in and changes this, trust me, let me repeal that, TRUST ME the establishment will do anything to prevent Bitcoin to get to higher adoption. And one way of doing this is a 51 % attack, it is very effective and for them probably not that expensive way of destroying the hole Bitcoin project.

Just some thoughts. The trusted entities that you choose is probably good ones, but I think they are very few in number. Maybe it should be as much as 349 trusted entities /persons (we have to see BTC as a global phenomenon and because of that 349 or even more trusted entities are necessary) and there should be a voting system that chooses these persons, like once every year or two like a parliament. Everyone should have the opportunity to get elected, and the election can take place on the Bitcoin.org site. You vote with your BTC, Every BTC in the wallet that it is sent from is one vote, and you send one satoshi as a way of showing the person/entities you want to vote for. All entities tells the Bitcoin community who they are and what they stand for.

Also one more big point is that this checkpoints of this trusted entities is not something that is hard coded in the client, the way it works right now will be enough with hard coding with every new client the development team releases, BUT when and if there is a 51 % attack then we should have this emergency checkpoint system come in in to work and only then when there is a 51 % attack that he Bitcoin community didn't know about and recognize as a 51 % attack this parliament will get activated and the checkpoints of this parliament will be the ones that will get hard coded in to the client. This is a way of telling any government that any attack will not get Bitcoin on the knees.

Any thoughts?