Proposal: Pre-emptive measures against 51% attacks

[cbeast]

If it is possible for any single player to manage to amass that much computing power relative to the rest of the network, it seems to me that the whole proof-of-work concept is invalidated, fundamentally. We're just back to human webs of trust relations. Those who then claim that bitcoin has been hacked would be right to do so...and perhaps it would be best to abandon the block chain concept altogether.

Having said that, I believe it is possible to modify the proof-of-work algorithm to make it less likely to favor people with a particular type of specialized hardware.

Huh? You make it sound so easy. I suppose that just because The USA got the most medals in the last Olympics that we should just stop having them. Oh, and because the USA has enough nuclear bombs to blow up the world, everyone else should stop building nuclear weapons. Are you afraid of a little competition?

[TT]

cunicula, you're right. I should clarify.

I didn't mean to say that the concept of a public transaction history with a trusted timestamp mechanism should be tossed away. I just meant that proof-of-work as the mechanism for establishing trust would be rendered effectively useless.

You could still have a mechanism based on web-of-trust and reputation.

[TT]

Huh? You make it sound so easy. I suppose that just because The USA got the most medals in the last Olympics that we should just stop having them. Oh, and because the USA has enough nuclear bombs to blow up the world, everyone else should stop building nuclear weapons. Are you afraid of a little competition?

No, but thanks for throwing in a nice strawman.

I'm suggesting something along the lines of what people like Dan Kaminsky have suggested: that it would be possible to have proof-of-work that cannot be massively accelerated with GPUs or ASICs...but that has high memory and serialization dependencies or other resource requirements, too.

http://www.slideshare.net/dakami/bitcoin-8776098

[cunicula]

cunicula, you're right. I should clarify.

I didn't mean to say that the concept of a public transaction history with a trusted timestamp mechanism should be tossed away. I just meant that proof-of-work as the mechanism for establishing trust would be rendered effectively useless.

You could still have a mechanism based on web-of-trust and reputation.

I agree that a web-of-trust and reputation is a solid mechanism for organizing exchange and decision-making, but I made a different point than this...

Another time tested mechanism is to allow voting based on proof-of-ownership. That is how corporations work. They seem to do all right in terms of serving the interests of their shareholders.
I am recommending that bitcoin or an altchain work in the same way. I describe how this voting mechanism could be used to organize a blockchain in the proof-of-stake wiki.

https://en.bitcoin.it/wiki/Proof_of_Stake

You should consider checking it out. It is a really simple design.

[TT]

You seem to have missed the first part of my statement. You might consider checking out the proof-of-stake wiki.

https://en.bitcoin.it/wiki/Proof_of_Stake

Ah, interesting. Yes, you're right...I apologize. I'll take a look at this idea.

[Gavin Andresen]

I started experimenting with user-defined checkpoints (-checkpoint=height,hash multiarg, and 'addcheckpoint <height> <hash>' RPC call) but stopped when higher priority issues came up.

It seems to me that type of low-level mechanism is the right way to go; checkpointing is a good low-level way of identifying which chain you think is "the" chain. And making it command-line/RPC configurable means we don't all have to agree on One True Way of deciding what the right blockchain aught to be; cunicula can write some code that implements proof-of-stake and then tie it into bitcoin/bitcoind using -blocknotify.  etotheipi can write some code that scans the blockchain for well-known miner signatures (or asks miners directly if they produced a new block), etc.

If your argument is "But Gavin, if core Bitcoin doesn't support One True Way of doing I'll never be able to convince miners to do it my way!" then I'd say you need to better express to them how the benefits of your proposal outweigh the costs.

[cunicula]

cunicula can write some code that implements proof-of-stake and then tie it into bitcoin/bitcoind using -blocknotify.  

Haha. I'm an academic economist. I can't code anything beyond 'Matlab code'. Thus, I hope you can understand why I must be all talk and no do.
Someone else has to take my idea and run with it, or it will never happen.

Of course, I'm happy to help in anyway I can, but my help is intrinsically limited.

If you're looking for something that is basically bitcoin compatible and someone who can make it happen, Meni might be the appropriate person to encourage.

My idea is fundamentally incompatible with the current bitcoin reward system. It has to exist as either a hard fork or an altchain.

[cbeast]

If your argument is "But Gavin, if core Bitcoin doesn't support One True Way of doing I'll never be able to convince miners to do it my way!" then I'd say you need to better express to them how the benefits of your proposal outweigh the costs.

This. Math gives us tools to create complex and useful games, but there is no Unified Theory of Finance. Managing the integrity of the blockchain will require whatever-works-at-the-time schemes to check and balance real world complications. Multiple schemes in combination and moderation can be used to adapt the Bitcoin Network if there is a sudden threat to the balance of power. The important thing is that the network propogates fluidly and globally.

Huh? You make it sound so easy. I suppose that just because The USA got the most medals in the last Olympics that we should just stop having them. Oh, and because the USA has enough nuclear bombs to blow up the world, everyone else should stop building nuclear weapons. Are you afraid of a little competition?

No, but thanks for throwing in a nice strawman.

I'm suggesting something along the lines of what people like Dan Kaminsky have suggested: that it would be possible to have proof-of-work that cannot be massively accelerated with GPUs or ASICs...but that has high memory and serialization dependencies or other resource requirements, too.

http://www.slideshare.net/dakami/bitcoin-8776098

My point is that I'm really not afraid of a massive 51% attack because having such a weapon doesn't justify actually using it. It is more likely that someone will have the means of stopping the attack and restoring the game back to a healthy competition. Inventing new technologies that take extreme advantage of anything are the hardest secrets to keep.

[markm]

My idea is fundamentally incompatible with the current bitcoin reward system. It has to exist as either a hard fork or an altchain.

I was thinking an alt chain would be a good place to implement proof of stake, but a hard fork would be interesting since I already have stake in the current block chain.

Maybe you should start a bounty, as that seems to be an effective way to get your ideas coded (several mining projects have been completed in this fashion). Like minded individuals would be able to contribute as well. It would certainly be a giant step towards "do" instead of only "talk".

You mean, like, maybe if he himself had a stake in it people might take the idea more seriously? By his theories that might make sense, afterall if he has no stake maybe he is just gaming us?

-MarkM-

[casascius]

I started experimenting with user-defined checkpoints (-checkpoint=height,hash multiarg, and 'addcheckpoint <height> <hash>' RPC call) but stopped when higher priority issues came up.

It seems to me that type of low-level mechanism is the right way to go; checkpointing is a good low-level way of identifying which chain you think is "the" chain. And making it command-line/RPC configurable means we don't all have to agree on One True Way of deciding what the right blockchain aught to be; cunicula can write some code that implements proof-of-stake and then tie it into bitcoin/bitcoind using -blocknotify.  etotheipi can write some code that scans the blockchain for well-known miner signatures (or asks miners directly if they produced a new block), etc.

If your argument is "But Gavin, if core Bitcoin doesn't support One True Way of doing I'll never be able to convince miners to do it my way!" then I'd say you need to better express to them how the benefits of your proposal outweigh the costs.

If you did something like this, my pet preferred default setting for the majority would be to just auto-checkpoint anything 6 blocks deep as long as the client believes it has had a good streak of good connectivity (e.g. it has been online for at least 24 hours and has received blocks at a rate consistent with their expected creation rate).  And for the client to simply shut down if it receives an attempt to rewrite more than 6 blocks - that is, a shutdown until it is issued an explicit checkpoint command to lock in what the user believes is the correct block chain.

A GUI interface to respond to the shutdown could offer the user two options: 1) a "phone home" option that allows the user to explicitly trust the dev team on a one-time basis to resolve the conflict (it would hit a predetermined URL and look for a signed message), or 2) a textbox in which the user can paste the RPC command supporting the view of his choice (which presumably would be clipped from a forum or whatever news source the user trusts) or a URL leading to a message containing the same.

[cbeast]

My idea is fundamentally incompatible with the current bitcoin reward system. It has to exist as either a hard fork or an altchain.

I was thinking an alt chain would be a good place to implement proof of stake, but a hard fork would be interesting since I already have stake in the current block chain.

Maybe you should start a bounty, as that seems to be an effective way to get your ideas coded (several mining projects have been completed in this fashion). Like minded individuals would be able to contribute as well. It would certainly be a giant step towards "do" instead of only "talk".

You mean, like, maybe if he himself had a stake in it people might take the idea more seriously? By his theories that might make sense, afterall if he has no stake maybe he is just gaming us?

-MarkM-

I would think that if a true PoS was viable, then a VC would have created and monopolized it already. They might call it Google Cash or something like that.

[Steve]

I started experimenting with user-defined checkpoints (-checkpoint=height,hash multiarg, and 'addcheckpoint <height> <hash>' RPC call) but stopped when higher priority issues came up.

It seems to me that type of low-level mechanism is the right way to go; checkpointing is a good low-level way of identifying which chain you think is "the" chain. And making it command-line/RPC configurable means we don't all have to agree on One True Way of deciding what the right blockchain aught to be; cunicula can write some code that implements proof-of-stake and then tie it into bitcoin/bitcoind using -blocknotify.  etotheipi can write some code that scans the blockchain for well-known miner signatures (or asks miners directly if they produced a new block), etc.

If your argument is "But Gavin, if core Bitcoin doesn't support One True Way of doing I'll never be able to convince miners to do it my way!" then I'd say you need to better express to them how the benefits of your proposal outweigh the costs.

If you did something like this, my pet preferred default setting for the majority would be to just auto-checkpoint anything 6 blocks deep as long as the client believes it has had a good streak of good connectivity (e.g. it has been online for at least 24 hours and has received blocks at a rate consistent with their expected creation rate).  And for the client to simply shut down if it receives an attempt to rewrite more than 6 blocks - that is, a shutdown until it is issued an explicit checkpoint command to lock in what the user believes is the correct block chain.

A GUI interface to respond to the shutdown could offer the user two options: 1) a "phone home" option that allows the user to explicitly trust the dev team on a one-time basis to resolve the conflict (it would hit a predetermined URL and look for a signed message), or 2) a textbox in which the user can paste the RPC command supporting the view of his choice (which presumably would be clipped from a forum or whatever news source the user trusts) or a URL leading to a message containing the same.

+1

I suggested the same a while back…basically, stated another way, you don't allow reorgs deeper than 6 blocks.  I think plenty of testing would be in order before making such a change, but it seems like a good solution on the surface.  Such a change would force any would-be attackers out into the open with their hashing power.  And 6 seems like plenty of time to allow miners to get their blocks distributed.  Any subnets cutoff from the main network would have to operate under an assumption that a) their blocks may be invalidated and b) they may have to take manual action to rejoin the main network.  The subnet could continue to mine to ensure the integrity of their own transactions while separated from the main net, but they would have to expect that their block rewards may eventually be rendered invalid.

[jago25_98]

I think it would be easier to disrupt development

This hasn´t happened so I think bitcoin has the nod to continue from the man

[casascius]

Any subnets cutoff from the main network would have to operate under an assumption that a) their blocks may be invalidated and b) they may have to take manual action to rejoin the main network.  The subnet could continue to mine to ensure the integrity of their own transactions while separated from the main net, but they would have to expect that their block rewards may eventually be rendered invalid.

If the 6 block auto-checkpoint were contingent on being connected for 24 hours with a normal incoming stream of blocks at a normal-looking rate, someone separated from the main net would be spared the need to do anything manually to rejoin.  This would be because while they were separated, there would be a big gap between the difficulty and the rate they were seeing blocks, and this would disable their checkpointing.

Above all, it would make us look much better to the media: "Bitcoin Attacked, Contingency Plan Activated, Disruption Minimal, Just Click Button" versus "Bitcoin Hacked, Nobody Saw It Coming, Developers Racing Around Clock, (Untested) Patch Expected Soon, Maybe Bitcoin Was A Bad Idea From the Beginning After All"

[da2ce7]

The problem with proof-of-stake is:

1.   As proposed require a fundamental change in how bitcoin operates.
2.   The security of Bitcoin should be up to those who 'trade' bitcoin, not those who own lots of it... Holding bitcoin is always going to be safe, even under a 51% attack.  The problem lies with trading it.
3.   Why not publicly signing something saying that you own a particular bitcoin address that holds many bitcoins is not enough of evidence that you own bitcoin?

The key point should be that we build the infrastructure that doesn’t change how bitcoin works, that allows us to respond much more effectively to a 51% attack.

The two key things to do are:

1.   A standard way to produce cryptographic signatures showing who made the block.

This will allow website such as blockchain.info to check tell whom is the owner of the block in a much more secure way than just looking at the coin-bases and the IP address that the block was announced from.

2.   The hooks for user-defined checkpoint, so this later on can be used by the user to choose a chain based on any criteria they wish.

Both of these things do-not change how bitcoin operates at all (possibly the mining signature within the block will need some modification to the block format… however I’m not an expert in _how_ one would make cryptographically secure block-signatures, however, I do believe that it is useful and doesn’t change the fundamentals of bitcoin).

[cunicula]

The problem with proof-of-stake is:

1.   As proposed require a fundamental change in how bitcoin operates.

This is true, but that can be applies to any disruptive technological improvement. If we want to make the world a better place, then we have to be willing to change how it operates.

2.   The security of Bitcoin should be up to those who 'trade' bitcoin, not those who own lots of it... Holding bitcoin is always going to be safe, even under a 51% attack.  The problem lies with trading it.

I'll leave this one as an exercise for the reader.

3.   Why not publicly signing something saying that you own a particular bitcoin address that holds many bitcoins is not enough of evidence that you own bitcoin?

Once you make proof-of-stake the main determinant of blockchain validity, then what is proof-of-work for? True, it taxes the user base to transfer money to AMD/FGPA/ASICs manufacturers and oil companies. I wasn't aware that this was a key objective or source of competitive advantage. Is there some other goal besides this that I haven't cottoned on to?

[da2ce7]

If it is possible for any single player to manage to amass that much computing power relative to the rest of the network, it seems to me that the whole proof-of-work concept is invalidated, fundamentally. We're just back to human webs of trust relations. Those who then claim that bitcoin has been hacked would be right to do so...and perhaps it would be best to abandon the block chain concept altogether.

Having said that, I believe it is possible to modify the proof-of-work algorithm to make it less likely to favor people with a particular type of specialized hardware.

The proof-of-work is very good for stopping internal attacks... It however provides no natural defence against attacks that are externally financially motivated.

It is completely reasonable that the internal bitcoin community can decided what miners they trust, and weigh their blocks more than of blocks from unknown miners.   Such a defence is called a ‘web-of-trust,’ and it provides a different quality of security to a proof-of-work.

Since the proof of work is to defend against internal attackers anyway… there is no problem in using a different type of defence to defend against externally motivated attackers.

So a proof-of-work is already secure enough to secure against internaly motivated double spends, why would an external 51% attack completely dis-credit it?
That is akin to saying “Something getting defeated by an attack that it wasn’t designed to defend against, means that the original design was faulty?”  - No it just means that the attack was out of specification.

[cunicula]

So a proof-of-work is already secure enough to secure against internaly motivated double spends, why would an external 51% attack completely dis-credit it?

Because the mechanism against external attacks as you call them also works as a defense against internal attacks. Proof-of-work would be costly and redundant (read uselss).

Useless and costly -> completely discredited

[da2ce7]

Because the mechanism against external attacks as you call them also works as a defense against internal attacks. Proof-of-work would be costly and redundant (read uselss).

You are complexly mixing up the different concepts of 'quantity of security' and 'quality of security'

If is like having a huge poorly trained army (that may be able to defend a country from external war)...
However you need special elite forces to defend against internal and sensitive disputes (such as dealing with spy's).

By your logic, because the special forces cannot defend an entire country against an invasion, they are:

Useless and costly -> completely discredited

I’m arguing that more than one type of security is required…. and for defending against internal attacks, the extremely high ‘quality’ of the security that we have is a good thing.

The problem the proof-of-stake is that it requires TRUST.  You must trust the people who have large numbers of bitcoin, to be both active, and not malicious with their investment.  With the current proof-of-work… being stakeholder counts for nill… as you don’t need defence, if you are not transacting your bitcoins.


A web-of-trust, (or even a proof-of-stake, a type of web-of-trust), that provides a lower grade of security, but at a much lower cost (so we can afford a very large quantity), is good for the 2nd line of defence, that we use against 51% attacks…

However I do not agree that the proof-of-work is made irrelevant by the proof-of-stake idea.  Rather I think that they provide solutions to different problems.

[gmaxwell]

a type of web-of-trust), that provides a lower grade of security, but at a much lower cost (so we can afford a very large quantity), is good for the 2nd line of defence, that we use against 51% attacks…

However I do not agree that the proof-of-work is made irrelevant by the proof-of-stake idea.  Rather I think that they provide solutions to different problems.

The fundamental problem here is that these things are not generally additive:  An action which causes different nodes to follow different chains is a forking attack which may be fatal to Bitcoin.

Say you have two distinct perfect security measures: A and B.  They both do a nearly perfect job of selecting the best chain.  But they are distinct and can select different chains.  Some users use A and some use B (or some A, some B some A&B) then an attacker just has to do something to make them differ— that something may even hardly be an attack and then Bitcoin is forked in a way which is irreparably without manual intervention. Rapidly people will double spend on each of the forks and within a dozen blocks or two any repair will be a difficult selection of which of two enormous groups of people gets robbed more.

Even the cases where the node just shuts down in response to reorgs— which is much better than the above— still is no help.   In a sane attack the reorg you see is the reorg moving you back onto the real chain— by the time you get any evidence that something is wrong it's too late.  You can't ignore that reorg without forever losing the ability to trade with everyone else.  The shutdown just helps you avoid getting exploited again shortly thereafter.   But even that isn't much help— because at the same time you've exposed yourself to a nice DOS that you were immune to before.    If miners adopt software that shuts down on reorgs then all sorts of great force multiplying attacks happen where you get >50% active hash power when you really have much less, just by first getting luck enough to trigger a big enough reorg to knock miners offline.