Cost of a 51% attack for different cryptocurrencies?(crypto51.app) |
Cost of a 51% attack for different cryptocurrencies?(crypto51.app) |
You can see here[1] that nicehash has about 500 PH/s (500,000 TH/s) available for rent. However, Bitcoin's total hash rate right now is 100,000,000 TH/s[2]. This means that if you rented out the entire nicehash market, you'd have 0.5% of the hash rate you need.
Could you get the other 99.5% by buying lots of mining hardware? Theoretically yes, but realistically no. Bitmain is a major supplier of this kind of hardware, so let's use their prices as a reference. They're currently promoting a 67 TH/s unit for $1585 [3]. You would need more than 1.4 million of these units, at a cost of over $2.2 billion dollars. Not that any supplier can fill an order like that quickly.
And we haven't even gotten to the power and operations costs. You'd need dozens of huge data centers to run all this hardware, each one consuming astronomical amounts of electricity. You'd probably pick your data center locations based on availability of cheap power and labor, and you'd become a major commercial presence in each of those towns. The local papers would have photos of you shaking hands with the mayor as your data centers open up. Everyone would know what you're doing, including the FBI.
[1] https://www.nicehash.com/my/marketplace/SHA256 [2] https://www.blockchain.com/en/charts/hash-rate [3] https://shop.bitmain.com/product/detail?pid=0002020011715132...
You are correct - the nicehash-able column represents the amount of necessary hash power that is available via nicehash. If it's below 100% the attack cost is also greyed out.
Disclaimer: I build crypto51.
However.
You don't need 51% of the hashes to have the longest chain. The longest chain is a lottery. If you had 25% of the TH/s out there, there are 3x as many hashes you don't control as do. The odds are 1:3 that you will still find the next hash. If that weren't the case, there'd be no point at all in me having .0001% of the TH/s. I'd be better off setting the money on fire to heat my house.
Bitcoin doesn't have a consensus algorithm on two counts. The obvious one is that everyone takes the longest chain, regardless of whether everyone already agreed to a shorter chain. In Raft, your history can roll back if there's a partition. In Bitcoin, things can be rolled back even if everyone is online. I need one attack (rewrite history), not two (rewrite history + DOS attack), and because of that, nobody but my pocketbook notices if I try and fail.
The second one is that there is no consensus on what transactions to include in the next hash. Any hasher could blacklist transactions that are unfavorable to them without really affecting their odds of finding the next hash. I think it's assumed that it's not in the interest of either mining hardware owners or frequent cryptocurrency spenders to do this, as they would destabilize their own investment. That only borrowed hardware would be used that way, and on short bursts of purchases. But is that really true? Or is there a zero-day attack out there already being used or waiting to be found?
I'm thinking of the epic embezzling scandals that have turned up. How many people out there were never caught, or were insufficiently prosecuted? Employees are usually subject to the laws where the office is located. These people could be on the other side of the world.
If you're already assuming criminality, go all out! BGP route hijack the unencrypted, unauthenticated mining traffic and call it your own.
Cost is basically nothing to do so, other than some jail time.
That's why miners can't steal a pool's solutions to begin with.
I suppose it might fall under wire fraud... Like some hacking does?
I always wondered whether storage could be used as proof of stake. It might use less energy and it probably will have much better effect on the IT industry as a whole. First, mining ASICs are not general computational devices and cannot be used for anything useful. On the other hand, storage is storage and can be repurposed. Second, it will up the prices for storage hardware, but that is probably a good thing in the long run. (Consider how super-cheap storage enabled unlimited surveillance and software bloat, for example.)
I don't know whether access to storage can solve all the problems a blockchain solves, but it can solve some. Like proving that you're a real actor in the system, rather than a temporary fake.
Some random ideas I had about how this could work:
If you want to transact with someone, they send you a challenge that consists of a set of addresses in a large file. You must respond with a hash of data at those addresses, problematically proving that you have the entire file.
This is the foundation. There are obvious challenges to how useful this is. Many of them are solvable.
With Bitcoin, for example, a smart malicious actor could infiltrate the Core development team and through their social capital make certain malicious pull requests get merged. This way, if the chain ever splits (let's say, due to a bug you planted), you can actually also influence miners to hop onto a minor chain without you ever owning any hashing power!
To see how this is done, look at the 2013 Bitcoin fork and see how a couple developers steered large miners away from the majority chain: https://freedom-to-tinker.com/2015/07/28/analyzing-the-2013-...
The only counter-argument to this is how code reviews should catch this, but history has clearly shown that bugs (including supply-inflation-causing ones) make it into cryptocurrencies all the time: https://en.bitcoin.it/wiki/Common_Vulnerabilities_and_Exposu...
Hash Rate is security theatre.
For very large value transfers exchanges are expected to wait for 100 confirmations (~17 hours) until they credit balance.
It's all probabilistic.
Finally, Bitcoin PoW is not security theatre, it is just one piece of the complex security system.
If you're just saying that PoW isn't painting the whole picture, I agree with you.
Is there enough supply readily available to satisfy a doubling of global demand? How much would it cost to bring such computing power online? How quickly could it be done? Wouldn't the price of computing power skyrocket?
EDIT: Meekro's comment elsewhere on this page makes essentially the same point in a more concrete manner: https://news.ycombinator.com/item?id=22161500 -- I think his comment is better; read it. Also, see bencxr's analogy with trying to control 51% of global oil supply: https://news.ycombinator.com/item?id=22161575
2) There are mechanisms to offer smaller cryptocurrencies Bitcoin level security, like Komodo's Delayed Proof of Work (https://komodoplatform.com/security-delayed-proof-of-work-dp...)
Would it though, really? Why?
On the contrary, someone performing a 51% attack can and will freeze out all other miners, leaving them operating at a pure loss. If the attacker manages to keep up the attack, he will be able to bankrupt the competing miners, forcing them to turn off their hash power, and thus lowering the cost for himself.
Blockchain don't have a centralized entity to "validate" and secure each transaction, so had to come with a solution to securely do so in a decentralized manner... Most blockchain use Proof of Work to do so : to participate on the validation process you have to "pay", by working on some mathematical problem... If you control more than 50% of the working power you can "control" the validation process...
In the case of DeepOnion, it costs $3 to buy enough computer power to control the validation process for one hour(by controlling more than 50% of the working power). You can use it to rewrite some transaction, and spend 2 times the same crypto.
Take bitcoin, a 105Billion cap can be subverted for just 700K per hour?
Not to mention DeepOnion for 3 bucks an hour. I can see people do that just for lulz.
The nice-hashable column on the site shows how much hash power is available for purchase.
To read the page naively would be a little like claiming one could hoard 51% of the oil supply given today's price at the pump. In reality, as soon as you started buying in large quantities, the price would skyrocket (making that attack very much more costly), suppliers would cut you off, and others would notice.
Another caveat: It's potentially cheaper to attack these coins than the number shown on this site since you receive block rewards from the time period when you attack a coin. In a lot of cases this will recover a majority of the money you spend on the attack. That said, this isn't guaranteed, and you are forced to put up this amount of money in order to carry out the attack.
Disclaimer: I built crypto51 ~a year ago
Edit: you can also create multiple forks and switch between them. External viewers will see both forks and if they don’t or can’t handle the difference they could experience a double spend.
That being said any miner has the ability to sort transaction any way they want which can give them an advantage. So if someone has a lot of hashing power they can use that ability to delay certain transactions or to give preference to others.
(Largest transaction you can cash out at exchanges) * (1 - (The decrease in value of the currency you attacked)) + (Block rewards earned).
Basically you get someone to give you cash in return for your cryptoX and then the attack lets you undo the transaction that gave them the cryptoX (but you still have the cash you got). The second term handles the fact that the attack may have cause the value of cryptoX to decrease which hurts you since you still hold the cryptoX you double spent.
This is an academic paper that looks into the details more closely https://faculty.chicagobooth.edu/eric.budish/research/Econom...
Do they take into account that during an attack the attacker will earn block rewards and transaction fees?
Because if not, then they vastly overestimate the costs.
This sounds like it is based on the some energy price that would be needed to do 51% of Bitcoins hashing.
Doing so could very well be profitable.
The reason it would be hard to do is that the attacker would have to gather a ton of hardware that way way exceeds the energy costs.
So 7$ is the nicehash cost? But isn't nicehash an out of the box solution? So if I wanted to actually execute a 51% attack I'd have to deploy my own malicious mining software to the nodes, that then issued an invalid transaction and forced consensus on it ... is that the idea? Can someone who knows a little bit more about this fill me in?
https://thenextweb.com/hardfork/2020/01/27/bitcoin-gold-51-p...
https://blog.coinbase.com/how-coinbase-views-proof-of-work-s...
Also, Ethereum is transitioning to proof of stake which will make attacks much more expensive because an attacker must acquire large amounts of ETH for each attack.
Can you prove that one copy of your data is being stored? Yes.
Can you prove that three copies of your data are being stored? I haven't seen any scheme that can detect if I'm pretending to be multiple people, serving files from the same disk array over multiple network connections.
In the context of IPFS, I'm not sure.
If you want to use the (crypto) network as distributed storage, you can shard and encrypt the data (at you 3x or whatever redundancy) and the storage provider is forced to store all of it, at least once.
Some incentives on data durability and availability may be enough to get a reasonable baseline.
It's literally what it says it is, proof of work. Consumption of electrical power in a way that can't be re-used for anything else.
> If you want to transact with someone, they send you a challenge that consists of a set of addresses in a large file. You must respond with a hash of data at those addresses, problematically proving that you have the entire file.
I'll cheat by making my "large file" the output of a PRNG, meaning I don't have to store any of it, but other people do because they don't know the seed.
This will work, but only until the file is sufficicently changed/expanded by the networks as the result of transactions.
(I probably should have said it explicitly: the file would be shared by all participants.)
You can also generate the file by recording something random everyone can observe, like records of a stock market, temperature of some location, etc. I don't see any reason it would have to be perfectly, cryptograhically random.
And yes, a single participant could "help" other nodes by responding to challenges instead of them. But think about the economics of how that would work over time.
I'm not saying that what I described is a full, working, tamper-proof protocol, but I think something interesting can be built based on the core idea.
The next problem is that this calculation is based on the current hash-rate cost. However, you don't have that much hardware and it'll be close to impossible to rent half of bitcoin mining rate. So such an attack will be order of magnitudes more expensive if even possible.
This mechanism lets you double your money (minus the cost of the 51% attack)
That's what the "NiceHash-able" column is for. To put it simply, if it is less than 100%, you are going to have trouble renting enough hashing power, and conducting the attack will be impossible in practice, or at least much more expensive than the listed price.
Merchants who worry about reversing transactions are advised to wait for a few hours before transferring the thing of value, this reduces the ability for someone to deploy a 51% attack and if they did, it would be pretty visible.
I would add that if an attack on bitcoin is detected, there would be some answer to it, and the actual cost of the attack would really rise
There is also some complexities to get your hand on enough material for doing it during enough time...
A 51% attack on bitcoin would be easily noticeable. If a 51% attack was really "viable", it means that essentially bitcoin would have $0 value, because all of its value is based on the trust that the blockchain is real and verified. The community at large would essentially just ignore the rogue chain, or rather probably boost other existing resources to back it out.
Also, if the community does ignore the rogue chain, what's to stop the attackers from switching their attack to the other non-rogue chains as soon as they seem to gain traction? If they can hypothetically reliably sustain 51%+ power for weeks, they could potentially perform a DoS on an entire currency. And you're right, Bitcoin would probably soon reach close to $0 (though would probably slowly bounce back once/if the attack seems to be permanently thwarted).
If I'm understanding your last sentence right ("probably boost other existing resources to back it out"), then I also think that'd be the most likely scenario. A serious sustained 51% attack (lasting beyond several days) would turn into a Dragonball Z-like battle, with both sides firing continuous energy beams at each other in parallel. Each side would be trying to increase the magnitude of their beams to keep the other side's beam from collapsing theirs. I think the legitimate mining team would have a lot more energy in reserve (e.g. good samaritans who start mining for the first time to help push away the attackers - kind of like Goku's Spirit Bomb, which Frieza can't replicate) and would probably win. However, if for some reason the attackers can win for weeks at a time, then it'd be a serious DoS.
Disclaimer: I might be misunderstanding something important here. Not a cryptocurrency expert whatsoever.
Of course, the problem with this is that there is no exchange that you can trust enough to actually do this.
1. You deposit BTC at an exchange. The exchange credits you the amount in their non-BTC ledger.
2. You send off a chain of blocks overwriting the the original deposit so that you never did it.
3. You fill in the form to withdraw your credited amount from the exchange.
Now you have 2x the coins.
Of course there are a LOT of details to this that I won't get into, and a number of mitigations for the exchange. But that's the basic outline.
However, the largest risk is from the software side. The physical owner of the hardware spends money, a hacker only spends their opportunity costs.
Note that, until the 2-week boundary where difficulty adjusts, they only get 100% of the roughly 45% less frequent rewards, since the 45% orphan rate will slow down overall progress.
When you make a valid transaction, you have the necessary details for both that valid transaction and no transaction at all. Just because you can't make invalid transactions doesn't mean you can't effectively steal.
This is why lightning network is a shitshow, because you have to be constantly alert for that behaviour.
https://u.today/guides/blockchain/bitcoin-51-attack-how-it-w...
> The hash rate is currently about six exahashes per seconds. Considering the most efficient ASIC miner with a hash rate of about 13,000 GHS (using the SHA-256 algorithm) being sold for about $2,100, an attacker will require about 500,000 hardware units and this will amount to about $1,005,000,000. When we factor in the cost of electricity and cooling daily, this figure rises to $1,006,000,000.
https://cryptoslate.com/analysis-bitcoin-costs-1-4-billion-t...
> To successfully conduct a 51 percent attack on the Bitcoin network would cost an incredible $1.4 billion. This massive network supports over 5 million specialized ASIC mining computers, consuming a total of 29 Terawatt hours of electricity a year—as much as the entire country of Morocco. One of the underpinnings of the Bitcoin network is...
https://gobitcoin.io/tools/cost-51-attack/
> $17,562,078,097, Hardware cost only, at cheapest rate. The attack would consume 241,478,573.839 kWh per day. (12,073,928.692$ per day)
I am not talking about my own pocket, but rich people or powerful entities. This is the cost of a military drone or something.
Imagine a nation adopting Bitcoin then another nation taking over that infrastructure.
We are talking about controlling the entire Bitcoin universe, everyone has to accept what the attacker considers "correct"
And no, a miner can not "easily" ignore previous blocks.
And blocks with invalid transactions get ignored by everyone anyhow.
1. Buy a whole bunch of QKC and wait for your receipt of the QKC to clearly be part of the winning chain.
2. Make a copy of the blockchain. Keep it to yourself.
3. Start adding mining blocks* to your copy, in private; do not release your private copy of the chain at all, just keep piling on mining blocks. You must outpace the world's ('public chain') rate at which they are piling blocks on, hence why you need over 50% of total hashing power to do this and guarantee that your private copy ends up with more mining blocks than the public copy.
4. Whilst you are mining your own private copy, spend spend spend. Spend ALLLLL your QKC, getting goods and services in return, or simply other cryptocurrencies.
5. Eventually, when you've spent all your QKC and your private copy clearly has more mining blocks on it than the fork of the public chain everyone currently agrees upon... release it.
6. The protocols and papers all state that now your erstwhile secret, private copy is now the new consensus view; after all, it has the most mining blocks on it.
7. That means that none of your QKC is actually spent. Effectively you get all your spent QKC back. In addition, whatever wallet has been doing all that mining just earned a bunch of QKC as a reward for doing all that mining effort, so you now have more QKC than you started with, AND you have all the goods (or other cryptocurrencies, or services, or whatnot) that you bought with your QKC whilst you were secretly mining.
Exactly how much time you need to spend all your QKC and ensure that your private copy of the chain definitely will win any consensus fight with any other fork is beyond my understanding of cryptocurrencies.
There are out-of-band mitigations possible; if it is abundantly clear what's going on and sufficient amounts of those who control major nodes all agree to just hardcode in their copy of the software that your chain, no matter how many blocks it has, is never selected as the consensus, then all your work is for naught. Etherium has run into a variant of this problem (it wasn't a 51% attack but something else). Everything happened just as I write: the majority of ethereum network movers and shakers chatted on forums and the like and decided to update their software (and their personal 'belief' of which of the many forks is the consensus fork) to disregard the one where a lot of eth was 'stolen'. But not quite everybody; a few decided not to update their software and stick with the rule that the one with the most is the consensus. That is now called 'etherium classic'.
*) Mining blocks are just blocks confirming all is well; they contain a proof of work which involves a random number added to the message. A mining block is valid if, when you hash it, the hash ends in a whole bunch of zeroes. The idea is that the only way to do this is to generate billions of random numbers, keep hashing the results, until you hit the jackpot and your hash ends up by sheer coincidence to end in the desired # of zeroes. At which point you publish this mining block on the chain. As part of doing that, the 'network' itself gives you some coin to pay you for your efforts, and the 'fork' that you put this block on is now more robust, in that the rule is that the consensus block is the one with the most mining blocks on it.
For these small coins like DeepOnion you'll crash the market completely if you try to sell even a moderate amount of coins. There's simply not enough demand to move a big amount of coins at this price.
Bitcoin Gold is not seriously used by anyone.
The larger currencies are slightly more reasonable but even then the valuation is unhinged because, for example, a lot of Bitcoin has probably been permanently lost.
I guess some people still think DeepOnion have potential in the future...
Assuming you can repeat your "totally legit" setup transactions until you succeed, with minimal cost other than rent, you would need to take more than either the opportunity cost (otherwise it's better to just mine), or the renting cost (otherwise you're still losing money).
Opportunity cost is the foregone block rewards that you lose because you didn't submit your blocks, because you were holding them hoping to build a long enough chain to double spend. When you fail, that reward that you would have earned is gone forever.
Renting cost is the actual $ outlay that it costs you to rent the hash power necessary to perform the attack.
I can do something reminiscent of "m of n" control tools, FEC or striping algorithms, but now the client is doing multiple fetches and matrix multiplication on every single request.
If I'm just trying to make sure there are 3 copies of my home page on IPFS, then I need 3 copies of the same file in three locations. And those locations all need to be online when I want to challenge them.
The Bitcoin protocol is designed around low availability of individual nodes and inference of consensus. Any 'proof' has to be uploaded while you're connected. Uploading a proof (of work, stake, whatever) to the network proves you did something, there is no need to challenge that fact, and you can disappear for hours or forever. No voting, no challenges.
Proof of storage requires challenges, which requires availability (well, storage also requires availability, otherwise what's the point?). If you insist that almost everyone is online, then you open the door to other consensus algorithms. Ones that can, for instance, handle non-repudiation.
The more confirmations you have to unwind, the more work you have to do to catch up with the long chain.
All that will happen is exchanges require a greater number of confirmations before allowing you to trade deposits.
And yes, reportedly exchanges have increased the number of confirmations required to confirm a deposit as a result. But it's too late for the ones who got ripped off by the double spend!
Edit for more info:
https://monerobenchmarks.info/
According to this site, an overclocked Titan RTX gets about the same hash rate as a stock AMD FX8370E at nearly half the TDP.
From the POV of the recipient, when the split branch becomes the "non-true" branch, it looks like they got the money but then it disappeared.
> If you mean the traffic of mining pools communicating their solutions to the pool's "mother brain", those are already cryptographically attached to a solution that pays out to specified addresses.
That's not correct in practice. There's no authentication of the work going to the miner at all, so an attacker can just change the destination before the miner even sees the work.
I know there had been guides on how to set up your mining rigs, setup the batch files etc. These were all guides written by other people and I could see how in this newly created space there was room for nefarious actors to try to convince people to mine in a pool, but not give them the rewards they deserved or scammed them in some other way.
I also thought about someone hacking entire pools' hash-rates to be used for their own purposes rather than trying to figure out the next block on whatever chain it was running. This would allow someone to 'steal' the hash power of expensive rigs and redirect the power to their own wallets.
My understanding of all these protocols is very limited to what is regurgitated from others. When it comes to reading the bitcoin whitepaper I was only able to comprehend up until section 11 on page 6 where it got into the calculations, at which point I got lost as I am not that good at math.
Thank you for the insight.
But would I ever know if you lied about the pool's GH/s rate and kept half of the coins?
>>If you mean the traffic of mining pools communicating their solutions to the pool's "mother brain", those are already cryptographically attached to a solution that pays out to specified addresses.
>That's not correct in practice. There's no authentication of the work going to the miner at all, so an attacker can just change the destination before the miner even sees the work.
I was referring here to the solutions the miners send out. That does not need to be authenticated because it's already attached to the block they were solving for -- i.e. it is a proof of work valid only for a specific block. If they received the correct block and nonce range to check, then the solutions are useless to anyone else. Diverting their traffic would just reduce the mining pool's hash power, not give it to anyone else.
So yes, I see how you could steal the miner's hash power if you could replace the assignment the pool head was giving them, and then see the output, but I don't think it's correct to say that solutions are vulnerable to being stolen after getting the correct assignment "because they don't authenticate" -- the proof of work is only valid for that block, and so could only be destroyed, not stolen.
When you connect to a pool, you give them absolute trust over what you're mining using your hardware with the expectation that they will pay you for it later. In a route hijack, an attacker can replace the pool and announce their own work to you, and receive all results you produce. You can not distinguish this with the normal behavior of the pool and will be robbed, and your work can be used to do whatever the attacker wishes.
The output of the work being loosely "authenticated" with the pool by virtue of the work being non-transferable is entirely orthogonal. Nobody is going to be taking that because it's worthless, as you correctly point out. They're going to replace the work that's sent to you in the first place, because that's what makes sense.
But if the (non-principled) value of mining 20 blocks is 20 block rewards, then there we have the cost of buying 20 blocks (assuming miners non-ideologically sell out).
Assume they would not voluntarily sell out, then any flaw in the pooling mechanism (by which miners dilute the rewards into a steady income) which allows 1) other work to be assigned to the miner 2) while still receiving their intended addresses, would allow an attacker who is able to hijack the work assignments, to buy those 20 blocks for the price roughly on the order of ~ 20 block rewards, by 1) hijacking the work assignments 2) payout out the miners the correct expected amounts so that they hopefully don't notice
Is that correct?
Depending on what you consider fat too late, doesn't the pool verify the solutions, and provide OOB statistics, where people would notice over time that they get 0 credits?
"BGP Hijacking for Cryptocurrency Profit" - https://www.secureworks.com/research/bgp-hijacking-for-crypt...
An attack like this could be repurposed to perform reorgs with 51% of the mining power as the stratum pool server decides what previous block to mine on. No idea if mining pools or the stratum protocol has added countermeasures to prevent such an attack in the future.
Not really. There's some discussion about Stratum2 having stronger authentication, and systems like BetterHash to take away a lot of the centralizing impacts of pools by having people create their own work, and only centralizing the payouts for that work. It's a bit of a challenge because there's such a huge range of hardware out there with incomplete implementations of stratum in closed source forks of mining software. You basically have to wait for it to just be obsolete and replaced because there will never be updates.
I specifically agreed that, if you can replace the assignment given to the miners ("replace the pool and announce their own work to you"), and see the output, then you can steal the work. It was in this paragraph:
>>Okay I see what you mean about replacing the work assignments going to the miners -- if you could tell them to solve a different block/fingerprint (hash of new block + previous block) and receive their output, then you can steal their hashing power.
That is an agreement with your:
>In a route hijack, an attacker can replace the pool and announce their own work to you, and receive all results you produce.
That is me communicating agreement that that's the attack that "makes sense" as in your sentence here:
>They're going to replace the work that's sent to you in the first place, because that's what makes sense.
I made my original because it sounded like you were saying a miner not (separately) authenticating their output to the pool would be an issue, which I now see you (always) agreed is orthogronal; my only objection in the follow-up was that your comment was addressing something different than I originally raised:
>>>That's not correct in practice. There's no authentication of the work going to the miner at all, so an attacker can just change the destination before the miner even sees the work.
>>I was referring here to the solutions the miners send out.
So, if I agree with you on every question of what and where the threat is and is not, and said so with slightly different words than you did, what point do you think I'm fundamentally missing?
The obvious thing to do would be to tell everyone that my 500 GH/s pool is 400 GH/s, and reward everyone an 80% share on every hash. If you're sophisticated enough you might notice that my pool is mining blocks about 25% above what you'd expect, but how many data point do you need for that, and it's statistical, so I'll have runs of good or bad luck.
Another option is to dilute the pool of contributors, but again you might be able to detect that either I'm misreporting your hash rate, or the sum of all contributions doesn't line up.
Assuming I give you enough tools to figure any of this out.
Either way, if a user knows his hash rate, he can calculate expected earnings and their presumed share. You could fudge a bit, but go too much, especially on a large pool, and it will be apparent. There are probably lots of users doing calculations, willing to call you out.
err, right. If you want to convince people they're getting a fair share, you have to downplay their contributions, and since they know what they did you have to make the pool bigger, not smaller. How long would it take to notice someone was fluffing the pool by 10%?
My hardest class in college was statistics, and mostly I learned that humans suck at them.
I was binging math videos recently and I got to one where one guy made a list of “random” heads or tails, and then the other guy guessed them and got like 60% right. He was disappointed because he often does better.
Humans, he asserted, will never write more than 3 (or was it 4?) heads in a row because they feel they aren’t random enough. And because if this, over half of the possible patterns are never seen.
Which is also why, when a test that’s failing 10% of the time, my coworker who thinks he just fixed it will run the new version five, ten times and claim victory... only for it to fail four times in a row the next day.