Topic: Almost no one understands the 51% Attack (Read 814 times)

That's why Bitcoin block time is set to 10 minutes, not seconds. And also: if you have a coin, where "uncle block" is a valid thing, then it is a completely different situation. Ethereum simply lowered their block time, without understanding the consequences.

Many coin creators decreased their block time from the default 10 minutes, but when I tried to build my network, I did the opposite, and actually increased it (for example into one hour, one day, or even two weeks). For example: if you want to have decentralized DNS, then you don't really need to update your naming indexes every 10 minutes. Establishing a domain is a long process, so you are not in a hurry, even in the centralized model, so there is no reason for giving for example 50 new names every 10 minutes, you can do that every hour, or every day, and that system would be better.

First, many altcoins rejected double SHA-256, and tried something else. And then, suddenly, they were protected from attacks from Bitcoin miners, but at the same time, they opened their network for the new attacks, from the new, unexplored hashing algorithms. And then, they are suddenly surprised, that they don't have the largest base of miners on their side.

Just use Merged Mining properly, and it can deal with those things, if you manage to calculate the global difficulty correctly (not like NameCoin, which only counts their own difficulty, without considering global hashrate). Collect all valid headers, to compute the real global chainwork, even without collecting block data from altcoins (just headers are enough).

As far as I know, no chain did that properly, not even Bitcoin. Because BTC is safe, when forks have something like 1% of double SHA-256 global hashrate. But it won't be safe, if you are on that "1% side". However, it could be fixed, and I wonder, why no altcoin implemented those kinds of protections, and instead, they are all blindly calculating only their own difficulty. It is like closing your eyes, and pretending that BTC doesn't exist, if you still allow mining a new block, for providing 1% of the global hashrate.

I agree with the title, but I don't agree with why no one understands the 51% attack.

Too many people think that the method of 51% attacks is detectable while it's in progress because of how it's described in the Bitcoin whitepaper.

The actual method that nearly all successful 51% attacks on PoW networks have occurred is via withholding attacks, which are undetectable until the moment they execute.

e.g. The Aug 2020 attack on Ethereum PoW where 4000 blocks were reorged at the same time without prior detection. Reorgs attacks don't happen block by block. They happen all at once.

One moment the blockchain is safe; the next second, 50 blocks are reorged all at once and it takes a whole day for honest miners to fight back, assuming they can even muster the mining power to do so.

you obviously didnt read.. if the prev hash doesnt match then its not part of the chain (hint: 'orphan'(unknown parent))
also look into how altcoins fork off, it doesnt require the genuine honest network needing to change. its just where there is a mismatch of chain of hashes, for a new lineage to proposer the new lineage has to do things to continue building on and not reject(by banning the honest pools/nodes broadcasts)

so without a army of nodes on the malicious pools side the malicious pool has to do some extra things to not only produce blocks but also try to get its ancestry of differing 'previous hash' to be accepted by honest nodes without ending up rejected and treated as a solo pool altcoin with no community

there is more to block acceptance than just your theory of valid transactions.. such as the changetip work whereby to also try to win the height competition the malicious pool would need more than equal power to be able to do more work in less time to show a higher 'proof work', difficulty to be accepted as the more worked on chain, because the 51% is more of a minimum not a target. because anything below 51% would probably be working on a lower difficulty to create fast blocks and just rejected based on less proof work or would not be solving as many blocks so never overtake the honest network in height or difficulty

This is an entirely different scenario. In the case with an attacker accumulating 51% of the hash power, then he can reach the threshold on any fork where the same mining algorithm is used. In your case, some people hardforked, e.g., Bitcoin Cash, the fork experienced a mining pool with >50% of the hash power, and people simply sold their BCH for BTC. However, in this thread, we're talking about an entity reaching 51% of the hash power of BTC.

---

The real issue arises if a malicious entity controls 51% of the total hash power, not when a mining pool tries to use its clients' hash power for an attack; that could be quickly mitigated.

It would not be rejected because we assume that the malicious branch is valid and nodes would have all of its blocks. So the incoming malicious block would have a previous hash that matches a block in the malicious branch. When the malicious branch becomes longest, there is a reorg.

A malicious block would be accepted because its previous hash matches a block in the malicious branch. Their are no invalid blocks so none are rejected.

In order for honest nodes to reject the malicious branch, which we assume is the longest valid chain, the consensus rules would have to be changed so that a block in the malicious branch becomes invalid. That would require all honest node operators to install a new version of the software with the new rules. The attacker doesn't have to incentivize anyone. As long as the attacker continues to make the longest valid chain with its majority hash power, honest nodes will follow it.

at the +1 height difference nodes see the previous hash doesnt match their own and do reject it, because its not working ontop of their chain
..
im trying to simplify things down because a simple person has already cried that i explained too much how why when what and he just wanted simple answers.. but the indepth answer is that unless there is a heck of alot of hashrate advantage above 51% the ability to go back and then forward is scuppered due to other mitigating factors like changetip work, which would need a malicious pool to be working at an even higher hashrate with higher difficulty to show a bigger changetip to win the re-org
(it would be great to get into the deeper details.. but we are still in baby steps of some of the more basic mitigating factors which legiteum keeps passing by and not taking onboard with all of his offshoot whataboutisms of different/new attacks to avoid discussing the basics already spoke about of a specific attack scenario)

but if all honest nodes are working on a honest chain. no matter what direction/node you send a block with a non-matching 'previous hash' all honest nodes would query it



i never said everyone need to install a new node to reject the malicious chain... i said the malicious community would need to incentivise an army of new nodes that will accept it and keep the malicious lineage alive(altcoin), where it would be best for them that even current economic nodes would need to also adapt to keep a new set of blocks to keep the malicious lineage alive..

But, reorgs are normal and expected. Nodes can't reject a block simply because it causes a reorg.



But, nodes are connected to several others, so even if one node won't send the "malicious" block to my node, there are others that will. It only takes one node.



I don't see that as a viable outcome. Some entity attempts to take over the block chain via 51% and so everyone installs a new node to reject the malicious chain as you suggest. What would prevent the entity from doing it again?

so many people dont understand bitcoin and instead want junk and bloat for the sake or de-censorship

however bitcoin was designed to have rules to make sure bitcoin stayed lean, clean and functional, where each byte why validated to ensure it was meeting requirements. it had rules and validations that actually checked(emphasis had(past tense)) all the data of a tx.. but some rules have been softened and allowed bloat and unchecked data, aswell as bypassing some validation processes completely.. which is a security risk

there is a difference between having validation rules vs calling it censorship..
what word you should be using is non-discriminatory rules where by 2 things that are deemed valid and should be validated that are then censored due to political, bias reasons

bitcoin has always had some level of security of validation to avoid certain things getting put into the blockchain.. the main one is that a transaction should never be added to a block if it doesnt satisfy the signature proof of key ownership of utxo being spent.. however even lately those rules are getting softened due to "privacy" and "censorship" where some devs believe full nodes should not get to know whom signed what and if nodes should even retain the signature proofs(witness).. (nodes doing 'isvalid' on transactions that are flagged as 'anyonecanspend')

in a situation of re-org when a malicious pool finally overtakes the honest network to broadcast a new higher height block. the nodes will see the newest blocks 'previous hash' does not compare to the current hash of the honest network


it doesnt take one node to spread.. initially the malicious pool that creates a block has to broadcast it to other nodes, then those nodes broadcast it further out to other nodes if the block is valid and suitable. or if not, within the inner layer of the spiders web would not broadcast it out and so the outer layers wont see it
what nodes do is if say honest network had 861203 and one of its peers(malicious) had 861204 the honest node would request the ..204 block, however the peer that had it has to have accepted it to update its own height. if the honest node gets it and rejects it, the honest node stays at ..203 and so its own other peers wont see a height update from the honest node so doesnt ask for a new block because they too are still on ..203
 

there would need to be a different in the nodes of whats acceptable and whats rejectable.. and if there is a difference. an altcoin is made where differing chain of blocks from different pools doing different chain of 'prev block' hashes compared to the other set

as said if its just one malicious pool and the malicious entity has not got a army of nodes to back it, especially not the economic nodes of the major services/exchanges.. that altcoin would be a waste of resources no one sees bar the malicious entity. the honest network would have seen the ancestry of many previous blocks dont match the chain they support so would just reject it

the only way a malicious pool could re-org by editing a previous confirmed block is to not go back very far. and then have WAY MORE then equal hash to honest network to catch up and over take super fast to get under the threshold of acceptable number of block ancestry that can be replaced

It will lead to censorship that we don't want.

They can say they censor this transaction with following reasons, other transactions with other reasons, and at the end Bitcoin blockchain will become a centralized, censored blockchain which I don't want to use.

Censorship on the Bitcoin network
Six OFAC-sanctioned transactions missing - A pool from Asia is the first to comply with US sanctions?
Non-US Bitcoin Miner Gets Caught Censoring Transactions

Censorship will lead to a day when all Bitcoin waiting transactions will be checked and approved by DOJ, OFAC, before Bitcoin mining pools and their miners confirm these "approved after censorship" waiting transactions.

Help me understand:

The only identifying information in a block is what the miner chooses to provide. How would a pool or node recognize that a block is from an anonymous malicious miner?

It only takes one node for the blocks to spread to the rest of the network. How are nodes prevented from receiving blocks from a malicious miner?

If a portion of the network rejects valid blocks, then the result would be a hard fork. What would be the impact of the hard fork, and how would it be mitigated?

ban man is part of the node.. how much more transparent can those words be
the node is the interface for many functions of bitcoin.. users dont need to build/download anything separate.


as for how its handled and how the network reacts for instance
pool managers dont want to waste resources communicating with silly temporary nodes of users, they instead have a white list of nodes they communicate with such as economic nodes and super nodes alowing those node peers to then get data first and then distribute it out further
like a spiders web spreading out

if you mapped the network out you would see pools at the center mainly connecting to each other to compete with each other to start new attempts as fast as possible after receiving a block and then also sending their confirmed blocks to economic/super nodes. who then distribute the data out to other nodes, where by several layers out there are then the stripped and pruned nodes and then the litenodes

so when for instance a economic node or a competing pool node gets a block from a malicious pool misbehaving. the honest node rejects the block for particular reasons and doesnt transmit it to its downstream peers and takes the node that sent the mebehaving block off its connection list and so doesnt tell other peers about the malicious node so no one downstream gets a list that includes the malicious node connection list

---

as for your new attack method about the peer connection gossip list. you can try and learn about the DNS seed nodes. and this is managed by core too. where they have the initial set of nodes which you would connect to initially which then when connecting to those nodes the connected nodes then share their versions of nodes(kept connected to) by which you wont see the malicious nodes in the list thus not connect to those thus banned

yes a attack vector would be to hack core devs personal servers to change the dns seed lists.. but the core devs monitor those and can just change the data back, so you would need to do things like a brute force continual attack to keep the list in your favour, by which time the dns seed node would just firewall you out of connecting to it.. in seconds.. thus defeat your attempts

you could try a brute force DDoS to prevent nodes getting access to the dns seed, but now your migrating down a different attack rabbit hole whilst still unsure of the basics of the mitigating factors of the primary topic of 51% attack

I'm not sure if you are being obtuse on purpose, or that's just how it's coming out, but I'll try to ask this question a different way.

What will it accomplish if I, one of millions of Bitcoin holders, downloaded banman and banned some nodes I read about--if I am one of the only ones doing this? How would the millions of Bitcoin wallet holders know to do this? I would imagine that 95% of wallet holders have never used GitHub, and don't have access to a build system where they could build it, and then they wouldn't know which nodes to ban (where would they find this out?). Indeed, I suspect most Bitcoin holders don't get day-to-day Bitcoin news, and wouldn't update their wallet's node list for weeks, if ever. Then what?

If the thing defending the Bitcoin network is a "gossip network", then obviously the attackers would generate their own gossip and tell people to ban the good nodes.

(That you keep resorting to personal attacks isn't helping your argument either).

banman is a feature within a node.. but you just wanted a simple answer without explanation

ban man not only disconnects misbehaving node from yours but you also take it off the 'gossip' list of peers which you would share with your other connections so that other peers then avoid connecting to it.. basically creates a whitelist of honest nodes you gossip to your peers about so they all share a list of good nodes to connect to

as for asking about why dont attackers just ban honest nodes... hmm.. thats called creating an altcoin.. but if its just a malicious pool banning all honest nodes. then that mining pool has no one to talk to, so is just left talking to itself.. basically wasting time and money and a sure fire way to get its mining community to jump away from it and find their own other pools to join that the honest network is part of, so they cn atleast try to get some ROI on their hardware and energy investment

if however not only would you have 51% of network hashrate but you would need to coerce majority of economic nodes(services like CEX's) to be on your side for you to be able to keep your attack alive.. yep if you dont have the economic nodes on your side and they instead stay honest and ban your misbehaviour node(s) you get thrown off the network and left as a soulless altcoin no service sees or interacts with.
...
you seem to just want to hope someone gives you a answer that meets your narrative you pre-decided before making this topic, and want to ignore anything said that doesnt fit your narrative

if you however did want to learn about ban man and what it is and does you can go to the bitcoin github and learned about it, you would have learned more and not need to ask more questions you dont want answers to

so please go learn about bitcoin and all the mitigating factors that debunk your risk threat fantasy.. as it seems you dont understand much about the 51% attack nor the risk and effect and possibility of it all
(in the 13 hours between your 2 questions, you could have researched and looked this stuff up in like 20 minutes and learned all this stuff,plus more all by yourself)

So somebody just downloads banman, builds it, and any node on the Bitcoin network you want to be banned is... banned?

So why wouldn't the attackers simply ban nodes that aren't part of their attack?

simple answer

banman     aka ban manager (search it in bitcoin github)

but next time dont ask who why what how in same sentence if you dont want a lengthy answer

Do you even... I really don't understand if we are even talking about the same thing. If I owned a big mining farm, I will turn off the power. Why would I need FBI or Satoshi to do it? Hack my server, I switch off the power. Why would I let you run my rigs and I pay for your bills? What on earth are you talking about man?

Or like @hd49728 says, I would just reconfigure and put my hash to another pool.

And then 'Russia' or whoever it is in your scenario would be, what, out of costs spending on the hack and MAYBE built 10 blocks. Hooray?

Again, successful means profitable. You ignore this again and again.

Look, I just had a simple question. How are nodes banned?

ok first lets zoom into just one attack vector.. re-orging a chain of old blocks...

if a malicious pool went back say 6 blocks and then had 60% of network would still require ~55 blocks to catch up and get ahead of the honest network to even be able to sway the network to change its history.. but here is the thing
core nodes have a "banman" (ban manager) that looks at the changetips and header data and would reject blocks that dont match its history and then give the nodes sending such blocks a score whereby if the persistence of sending dodgy blocks continues to uprate the score then the node will ban the peer sending it
the node would also ignore/drop/reject/stale/orphan/evict the block(s) in question

if you spent some time looking at these things you will see that there are many mitigating factors involved that stop a malicious/misbehaving actor from sending data that does not correspond to the honest chain

my personal node for instance checks the block hash Id (and the 'chainwork' and othe things) of the current chain and if a new block appears with a new height. but its previous block hash does no match the one i have, nor does its previous or its previous for 6 blocks.. then my node just treats it as misbehaving and rejects it if the ancestry does not match within 6 block heights
thus my node sticks to the 6 confirm rule and not allow a chain re-org older than 6 confirms

thus if a malicious actor who did try to go back 6 blocks to its previous.. and then tried to catch up.. meaning it had a new chain of 55 blocks of different hashes compared to the honest chain i follow. it has no chance

it cant simply just go back one block edit it and then broadcast the edited block. as the honest network is already ~2 blocks ahead of the malicious pool, so the malicious pools broadcast would just get rejected as a lower height with a non matching block hash..
it would need to add more blocks and catch up overtake the honest network blockheight to have a height bigger then the honest network to even get a chance to be seen.

if a mining pool went one block back to edit one confirmed block.. and with a 60% of network hashrate, it might get to overtake and re-org the network within 10 blocks catchup time.. at very best 5 block catch up time.. thus only affect 6 blocks that get re-orged (5 after the rewind and 1 of the historic change)

if it managed to overtake and get its blockchain of edited blocks accepted, those transactions of the honest chain of parallel height blocks(6) just change from confirmed to unconfirmed and get put back in mempool to be rebroadcast again.. which the malicious pool can decide to just not put into blocks again and leave the network congested whilst the malicious pool "empty blocks"

however at the very minute that it broadcast the blockheight that overtakes the honest chain to make the honest chain drop its own 6 blocks.. the nodes create a log alert that its dropping blocks to then pursue the new version of 6 blocks thus unconfirming transactions back into mempool.. so people would react and notice.. and just affects transactions of upto 6 confirms
economic nodes as already said would and do have configured nodes to know which of its cex platform user accounts database is credited with balance from which utxo was spent and if there was a doublespend they would halt that cex account spending habits within its platform

other services also 'taint' certain utxos deemed unconfirmed again and if the tx is not spend in the same tx manner as the first time to purely re-confirm it again and instead the tx has been altered and replaced by the key holder those analysis services would flag it too

..
but lets concentrate on the nodes themselves.
as hinted at already, each block has a block id of its block and within that block it also has the Id of the previous block.. there are a set of rules in ban manager that can be set to reject blocks where they dont match the set the network already obtained

so not only is a malicious pool limited in how far back it can go due to it requiring more power or time to catch up and overtake.. but also nodes can treat blocks as misbehaving if their block ID's dont match the nodes own ancestry of id's at a certain depth

(there are more mitigating factors but lets atleast get you passed these little spoons first)

Who "banned" these nodes, and why? What did "banning" them mean, exactly? How is a node "banned"?