It would require clients to forbid rollback of blockchain (if the current block number is 1000,
an attacker with 90% hash power cannot restart from block 950 -or 999- and regrow a new blockchain),
solving double spending problem. It would also force blocks from "good" miners into the blockchain.
This poses the problem of blocks commited at almost the same time, or generaly different clients
not seing two candidate blocks arriving in the same order.
Clients would have to rely on a referee for these cases. The referee could not trick anyone,
or marginaly so (if 2 blocks arrive 0.01 seconds appart, it can favor one, but not if
they come 20 seconds appart), without being spotted.
Clients don't have to trust the referee, they can compare with their own result or with another referee.
If the referee gets corrupted or disabled, the clients will have to find a new one through consensus.
Problems:
- agreeing that there's a problem with the current referee, and finding a new referee:
thanks to the winner-takes-all effect (
- not so sure), a general agreement would emerge through observation
of other clients (do they agree with current referee/choice of new referee?) and discussion
over the internet.
- time taken to reach these general agreements (during which there may be a fork):
can be mitigated by use of "secure decentralized networks allowing instant, off-chain payments"
(
https://en.bitcoin.it/wiki/User:Aakselrod/Draft - from blueadept). If you commit 10BTC beforehand
to this network for 1 week e.g., you can securely pay as much as 10BTC, as long as you can have
access to a valid (non forked) blockchain within a week.
Seeing other atempts to solve the "51% attack" problem,
I'm not sure it's so simple, though.
Anyone poking holes in my arguments is welcome!
Vincent
