Bitcoin Forum

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.

As long as the blocks contain adequate proof of work, they are all eligible to be accepted. It's not a beauty contest where the one with the highest proof of work wins. The reasoning works if we replace "block" with "blockchain" on the basis that longer blockchains are preferred.

Suppose the bitcoin network divides into two roughly equal portions in terms of hashing power and trusted parties but without any attack. Life goes on for a while at roughly half the block rate and with half the trusted signatures missing. When the network reconnects what happens to the losing chain and the trusted parties' signatures of the losing chain's block hashes?

ByteCoin

The signatures only mean "I saw block X".  If block X is unknown or ends up being rejected, the signature then means nothing. the signature doesn't sign the block it is in, it simply acknowledges receipt of some other (earlier) block and is still a valid transaction in any block it gets put in.

In the event of a bona fide net split, where exactly half the trusted parties get separated from the other half, neither chain will meet the threshold of having a sufficient majority if the threshold is set any higher than half - so the longest proof of work would win as it does now.

So if those few "trusted parties" are malicious then they can carry out a double-spending attack even though they have a tiny proportion of the total hash power, by preparing their own fork and signing it? I think that this is a bad idea, both in a technical sense, and from a PR standpoint.

For example it could take those malicious parties one day to prepare a secret fork of 6 blocks, while the rest of the network generated 144 blocks during that time, and still the malicious fork of 6 blocks will win?

You didn't describe which threshold of trusted parties would be needed? If all the parties are required then a single malicious party could cancel the entire scheme, and if a majority of the trusted party is required then a malicous majority can double-spend, etc.

And equating mining pools with trusted parties is a step in the wrong direction imho, it would be better to think of ways to enhance security of the overall bitcoin network by decentralizing the power of mining pools, rather than giving them more power. This was discussed at https://bitcointalk.org/index.php?topic=9137.0 , as well as p2pool, and there's also the idea of preventing mining pools at protocol level by requiring that if you have (privkey,pubkey)=(sk,pk) and block reward address corresponds to pk then you try to generate the block by: hash(txns,nonce,sign_sk(txns,nonce))

Edit: on a more basic level, if we officially condone having an easily modifiable list of trusted nodes as being a correct behavior of honest clients, then in the scenario where the mining power is truly decentralized it means that it becomes easier to have clients who don't follow the same rules, i.e. more possibilities for forking the chain.

Most of those trusted parties aren't mining, so they wouldn't really have the means to carry out the attack.  Remember, they'd already have to have 51% of the mining power, and in my proposal, they'd have to have 51% of the "trust" (however that is allocated).  This ups the ante even more.  A lot of other trusted people simply won't sign a new chain of replacement blocks that just show up out of nowhere, as a matter of policy.

Someone with a policy of "I sign the first thing I see right away as I see it, and I am trusted only so long as I continue to do so" will have self-prohibited himself from signing an alternate chain that replaces blocks, because by doing so he would have met the conditions to delete himself as a trusted person.  Decentralization doesn't mean "trust nobody"...could you see MtGox or Gavin trying to do a double spending attack?


I expect there should be far more trusted parties than to make this feasible.  But let's suppose that happened.  We would know exactly who those parties were, we'd dump them from the trust list, and then they would never have a second opportunity.  Sure, Bitcoin might get some bad press, but it would also prove that the contingency plan worked.  They wouldn't gain anything in the process.


I left it vague on purpose.  A majority, sure.  But remember there's more factors that a client can use to weigh two competing chains of blocks - Gavin enumerated a few on another thread.  A flexible algorithm would be desirable over a hard and fast rule.  If I have chain A and chain B competing with one another, and chain B is longer, doesn't contain any double spends against A, and contains everything from chain A, I (as an algorithm) probably should just consider choosing chain B without worrying much about majorities.  On the other hand, if 6 blocks come along and purport to be better than 144 they want to replace, they may merit needing a much higher percentage of the trust than even 51% to be acceptable.


Trust doesn't mean a block is assumed valid just because it was signed by someone special (unlike SSL for example, which does work this way, much to our demise).  In this sense, a signature only means "I saw this block".  I as a client should prefer a chain that I know has been seen by a lot of stakeholders, over one that has been seen by none.  Having mining pools sign blocks helps everyone confirm that the mining pools are still in contact with one another and that there isn't a "net split".



I don't see how it follows.  This proposal doesn't create forks, it simply provides an element of human control over how to deal with forks if and when they happen.  They have to happen first on their own, either deliberately as part of an attack, or unintentionally if there are disconnects in the network.

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?  

Trusted parties should be people who have an ownership stake in the system. If you want to identify who truly wants bitcoin to succeed, ask who is willing to bet money on its success. The trustworthy people will plunk their money down. Proof-of-stake. Ownership and control in the same hands, not separated. It's that simple. Anything else can and will be gamed.

Having the pools include a signture within the blocks they produce is a very good starting point.

It dosn't harm the network in any-way... However makes the post 51% attack 'cleanup' much easier.

This has been a problem that has been on the back of my mind for a very long time also.

The core component is that this will provide a 2nd line of security against attacks based upon a web-of-trust style of security model, rather than the absolute ‘who hashes the most’ security model.

From the start-out the web-of-trust and computational problem security models have different ‘qualities of truth statements.’
The quality of the security that a cryptographic problem provides is a provable solution, which is non-relative.  All parties in the system will come to the same exact solution.  It can be summarised as the quality statement:  “This is absolutely true for everyone”
In legal terms it may be said as:  “This is true without any doubt”
This can be dramatically contrasted with the quality of the security that a web-of-trust provides.  A web-of-trust gives a relative prospective for the solution.   Each party may or may not come to the exact same conclusion, based upon whom they trust.  It can be summarised as: “This is good enough for me”
In legal terms it may be said as:  “This is true enough for my purposes”

Now…  Having such a strong truth statement comes at a much higher cost that a ‘less rigorous’ truth statement.   The cost in the case for bitcoin is that there is no ‘human’ element in deciding what chain is valid or not…. Instead it is entirely left up to ‘whoever can gather the most hashing power.’
Economically, such a high level of truth statement is affordable to protect bitcoin against internal attacks, (people within the bitcoin community).  Namely those whom want to seal through double spending bitcoins.
However, the economics doesn’t provide any natural protection against an externally motivated attacker.  The attacker whom gains the finance through taxation, or the protection of established systems that bitcoin competes with.

Much higher levels of security can be gained far more cheaply by lowering the required truth statement.
Think?  Is the precise order of the transactions important; if the network is being attacked by an attacker who stops all the transactions????

This is where casascius gets his idea of a ‘trust’ based system to protect against the 51% attack…  It is more important that we gain an “Extremely High” level of security against a motivated 51% attack, than maintain our “Extremely Strong” level of truth statement.

PS.  For a long time, I have been conceptually designing a ‘web-of-trust’ coin… However I’ve never came up with a good way to ‘issue’ the new coins… However It could work as a low-cost security backend for a pre-allocated *coin.

My proposal:

1.   Miners release signatures of their blocks by-default.  If they want to remain anon, either don’t release one… or use a new identity for every block.
2.   Bitcoin will display a warning if the current chain contains a very unexpectedly long time without any blocks from its ‘favourite’ miners.
3.   Bitcoin also displays warning when ‘favourite miner’ blocks consistently get orphaned.
4.   Upon detecting an active alternative fork, that contains many blocks made by the nodes ‘favourite’ miners, an option will be given to the user to move to the forked chain.


Edit:  By ‘Favourite’ I mean, whoever the developer of the particular client decides are trusted.
The user should be provided with a clear and simple way to change the ‘default’ favourite miners.

I'm not sure if anything like this is feasible or not but is there perhaps a way that some sort of voting by standard clients (rather than miners) could be used in order to decide about checkpoints (perhaps by unique IP addresses)?

A web-of-trust based system will never work without two main features:

1.   Active Human Thinking Trusted Parties.
2.   Cryptographically Secure Announcement of Trust Relationships

You cannot have a secure web-of-trust without active human maintenance… figuratively you are trading computational security through the proof-of-work.  With trust gained by human interactions.

AKA... You cannot have your cake and eat it.

Edit: I suggest that using Unique IP address would be a poor security model against a motivated 51% attack.  As it would tend to lead to many different solutions, as the attacker would also flood the network with malicious nodes.  (Remember that a 51% attacker must be externally motivated to the bitcoin network)… Therefor it is likely that the attacker would have many times the financial resources disposable than the entire bitcoin network can use to defend against it.

I was thinking about this last night and I was wondering, what would happen if we added another stricter block-validity rule that says if more than half of blocks of all the blocks created within a day are created by 1 IP, the IP get's ignored by the rest for the next 24h?

Nothing... the attacker will just use bounces, many IP addresses, connect to different nodes block, or mines over TOR.  The latency for release of the attacking chain that has been mined with 51% hashing power isn't important in the long run.

What if they couldn't change their IP, would that rule solve the problem?

I think you have a large misunderstanding on how bitcoin operates.  How would you enforce this, when you want the network to remain opon for new miners?

2nd IP addresses are very very poor at identifying a node. IP black lists will never work.

A human coalition of trust is a good idea. However, it must also be able to recognise when a friendly ally comes online with additional hashing power that is enough to offset the 51% attack. OTOH how would you know if there even was an attack until after the damage was done? You wouldn't be able to just roll back the transactions. It might be best to stop worrying about it and let Bitcoin trust the competetive nature of man to maintain a balance of power.

If there is a way to recognize blocks by their owners and we can determine that a certain owners is finding a lot of blocks, we can simply put in place a rule that once you find a certain amount of blocks out of all the blocks found in a certain time period you get a forced break from getting your blocks accepted by the rest.

The blockchain exists as a copy in every single client. Meaning that because of our decentralization, just because someone has over 51% of hashing power, there's nothing that forces the 49% to accept their blocks into their copy of the blockchain, they do it voluntarily.

What I'm suggesting is to solve this problem with ostracism. Simply ignore blocks found by someone having too much hashing power. Yes, this would create a fork, but the owner of the over 51% of hashing power will find himself all alone in his fork while the rest of us carry on as if nothing happened.

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.

Umm yes, proof-of-work might lose all credibility, but there would still be proof-of-stake standing untarnished. No need to get rid of blockchains altogether, that is throwing the baby out with the bath water.

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?

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.

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 (http://www.slideshare.net/dakami/bitcoin-8776098)

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 (https://en.bitcoin.it/wiki/Proof_of_Stake)

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

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

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.

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.

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.

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.

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-

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.

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.

+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.

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

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"

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).

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.


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


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?

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.

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

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:


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.

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.

I thought about this a bit more and I came up with a revised rule:

Coupled with the above rule we add another rule. If more than half the new blocks in a time period are created by IP addresses that didn't appear in a certain already elapsed time period, for the next x blocks only blocks from IPs that have found blocks in that same time period but didn't find more than half are valid.

So even if someone amasses over 51% and is switching IPs he'll get ignored by the legitimate part of the network because a) he is finding too many blocks from his IP and b) he is finding too many blocks from previously unknown IPs

This way the proof of work stays valid as a mechanism to limit the supply of bitcoins and also gets protected from malicious intent by someone with more than 51% hashing power.


Comments?

So? All someone mining more than 50% needs to do then is implement two IP addresses, certainly less difficult for the miner than the validation through the network. I see no benefit in that idea.

Right after I wrote my post I thought of that too but then I wasn't sure if it is actually the same if you have two clients with 26% of hashing power running the same malicious rules as having 1 with 52%?

Could a potential 51% attacker start out at half power to be recognized as legit, and then switch to full power?

Could an attacker DDOS the major pools, forcing more than 51% of the hashing power to get new IP's at once and granting a temporary oligopoly to the remaining pools?

I'd be most worried about both at once, a "set, spike" attack where even everyone honest mining at a loss (for network defense) isn't enough to stop a 26% attack.

As soon as he reaches 51% he'd start breaking my first rule and get ignored. DDoSing pools does nothing since miners connecting to pools still have the option to solo mine.

Sorry, I didn't answer your previous question: running two nodes with 26% is the same as one with 52%. The important part is that they're controlled by the same malicious party - an organized group could still coordinate a 51% attack.

Suddenly solo miners would constitute previously unknown IP's, so their blocks would be ignored.

Yeah you are right, nvm then :P  :-[

As already mentioned you can relay your block through a proxy but that's actually not necessary because every node is a proxy already. Let's say I create lots of blocks. They probably don't go directly to you because it's pretty unlikely that we have a connection to each other. I send the blocks to the nodes im connected to and they send them further until they reach you. So you will only know the IP of the node you got the block from and not the IP of the creator of the block (me).

Any update on this, will this get implemented in the near future (less than a couple of months)?

Is there a BIP or wiki to describe this? I think I misunderstood this post from Gavin, but it looks to me like a reconciliation for forks?

Would it be possible to shift the entire mining process to a system similar to p2pool that would include a signature based on it's own tree?  Then just accept blocks that are also signed by THE decentralized mining pool so everyone has to use it.  I guess it's a "one true way" approach.

I'm loosely thinking about something like what p2pmining.com is attempting to do.  Perhaps existing pools would submit blocks through the main p2p pool where they would be signed, maybe paying a small fee that is distributed to miners in the process.  Basically all miners/the masses would work together in a single p2p mining pool as gatekeepers to the actual blockchain.  External pools could still exist but would need to still submit blocks through the main p2p mining pool and pay a small fee of each blockreward to be signed and accepted.  I know there would be a lot of complexities to work out, I'm just thinking out loud and wondering if it would even be possible and what the potential problems would be.

Very interesting.

Both of the proposed implementations of PoS (Cunicula's and Meni's) are combined with PoW. In Cunicula's system, difficulty is adjusted by stake, such that a miner with a higher stake gets to use a lower difficulty for PoW. Meni's system uses straight PoW, but PoS is used independently to verify certain checkpoint blocks that the whole network can fall back on in case of a dispute.

The main disadvantage of Cunicula's system is that only a single miner signs each block, which makes it hard/impossible for decentralized pools to contribute. Also, the way his system weighs stake doesn't allow for the "trustworthiness" of signatures to be gauged based on how many blocks they have contributed or any other relevant figures. It also has the unintended side effect that having a larger stake leads to a higher chance of generating a block (and thus collecting the coins from it).

The main disadvantage of Meni's system is that signature blocks can be signed by anyone with a stake, so each checkpoint block might end up with millions of signatures. This also makes it hard to provide any incentive for signing.

I had the idea to have the contributors of each pool sign the blocks it creates, and then only signatures that appear on previous blocks can be used on checkpoint blocks, each weighted by, say, the number of blocks the sig appears on and the amount of BTC in the signing account. That would prevent a 51% attack unless the attacker both had 51% of the computing power and a huge stake, and it would take a considerable amount of time for their signatures to gain the weight needed to overthrow the main blockchain. The main problem is figuring out how to keep the size of signatures down as in Meni's system.

Another thing that occurs to me is that, in the thread on tx replacement, it was briefly mentioned that a new protocol rule could be included that would invalidate any block containing a double spend attempt. If there is any conceivable way that a 51% or other forking attack could be used to effect a (very large) double spend, then a protocol rule would invalidate that chain automatically even if it does happen to be longer. They would be limited to DoS, or they would have to put most of the other miners out of business before the network would accept their attack (if at all). In that case, the network (and bitcoin) would probably be destroyed (if the clients still throw flags) before a double spend would succeed. As long as there's some contingency for a major DoS attack, it shouldn't be a major issue, however.

Any progress on this proposal?

Asking again because I think this is very important, especially because of the 25 BTC change at the end of the year, many legit miners will leave and the bots will remain, thus making Bitcoin vulnerable to a 51 % attack.  Gavin and others, any progress or information on this?

So if I bet 49 BTC on my block it should win? ;)

Proof of stake can be gamed as well - the block hashing ITSELF is proof of stake; you need to stake your computer.


Casacious idea would protect the chain against sudden reversal, but NOT transaction blocking.


The ONLY defense against 51% attack is blocking certain IPs - ALL of them except a few trusted parties if necessary.

If you want to be preemptive about it, build it into the client, a block/allow list simply. Let the wallet owners decide who is spewing crap chains.

No

This is a good idea :)

I have some thoughts on the 51% (even >>50%) attack problem which may be of interest to those following this thread. Rather than duplicate them here I'll just give an intra-forum link: Proof of stake - done right - is maybe, just maybe, the way to eliminate 51% (even 90%!) attack worries altogether! https://bitcointalk.org/index.php?topic=68213.msg920853#msg920853 (https://bitcointalk.org/index.php?topic=68213.msg920853#msg920853)

(Note that it's not, yet, a specific technically detailed proposal. It's more the launching of a new paradigm for how to design proposal(s) for standing up to attacks that go over the 50% mark. I hope it's of some interest to someone!)

He doesn't see that. The proof of stake idea is no more secure than the proof of work system. This has boiled down to a philosophical argument about *who* should be responsible for the integrity of the Bitcoin Network. Should it be the elitist technocrats or the the unwashed masses?

It's like the employer that sees his employees as assets that are worthless without his money. In fact, employees are actually talented contractors willing to take less pay for not having to deal with capital management. This analogy applies to Bitcoin, because we the people must take responsibility for managing not only our own bank, but the banking system itself. Satoshi gave us an easy way to do this and we should recognise the significance of this. We are all bankers, with better hours.

Furthermore, if we give up our responsibility to run this easy-peas network for a little extra security, then we don't deserve Bitcoin.

Why would the network be more vulnerable to a 51% attack by botnets then "legit miners"?  Hashing power is hashing power.  Botnet operators profit (unethical or not) be keeping the network secure.