Proposal: Pre-emptive measures against 51% attacks

[hazek]

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?

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?

[1713554764]

1713554764

[1713554764]

1713554764

[1713554764]

1713554764

[1713554764]

1713554764

[wogaut]

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?

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.

[hazek]

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?

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%?

[Explodicle]

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?

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?

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.

[hazek]

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.

[Explodicle]

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.

[hazek]

Yeah you are right, nvm then  

[wabber]

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

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

[fastandfurious]

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.

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

[cbeast]

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.

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?

[coretechs]

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.

[fastandfurious]

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.

[Haplo]

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.

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.

[fastandfurious]

Any progress on this proposal?

[fastandfurious]

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?

[Realpra]

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.

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.

[cunicula]

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

No

[HostFat]

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.

This is a good idea

[iain]

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

(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!)

[cbeast]

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

No

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.