Security calculation of finality headers

[Tym]

Hello there,

I created a calculation for the "security (in terms of $) of 6 finality headers". I wanted to ask for some feedback/thoughts - and I'd love to read suggestions or maybe different approaches on this topic ("how secure are n finality headers").

The goal is to point out a certain amount of $ that an attacker has to pay to create a chain of fake-blocks (so that block X final). The scenario: Be sure that block X is part of the actual bitcoin blockchain without knowing every block header - but only checking the finality of block X with a certain amount of finality headers.

Imagine we want to change a transaction of block X and prove that this block is correct (even though it is not). An attacker has to calculate a chain of fake-blocks (block X and 6 finality). This results in a total of 7 fake-blocks to mine. The calculation is based on assumptions and averages.

Assume that the attacker has 10% of the total mining power. This would mean he needs around 100 minutes to mine 1 block (average block time of Bitcoin is 10 minutes) and around 700 minutes to mine 7 blocks. While mining fake-blocks, the attacker loses his chance of earning block rewards. Assuming that we would have been able to mine 7 blocks, with a current block reward of 6.25 BTC and $11,400 per Bitcoin at the time of writing:

7 * 6.25 BTC = 43.75 BTC

43.75 BTC * ($11,400 / 1 BTC) = $498,750

Furthermore, the attacker needs to achieve 10% of the mining power. With a current total hash rate of 120 EH/s, this would mean 12 EH/s. There are two options: buying the hardware or renting the mining power from others. A new Antminer S9 with 14 TH/s can be bought for $3,000.(https://www.buybitcoinworldwide.com/mining/hardware/) This would mean an attacker has to pay $2,568,000,000 to buy so many of these miners to reach 12 EH/s. The costs for electricity, storage room and cooling still needs to be added.


Hashing power can also be rented online. Obviously nobody is offering to lend 12 EH/s of hashing power – but for this calculation we assume that an attacker is still able to rent this amount of hashing power. The website https://www.nicehash.com/marketplace is offering 1 PH/s for 0.0098 BTC (for 24 hours).

1 PH/s = 0.0098 BTC

12 EH/s = 117.6 BTC

Assuming it is possible to rent it for 700 minutes only (which would be 48.6% of one day).

117.6 BTC * 0.486 = 57.15 BTC

57.15 BTC * ($11,400 / 1 BTC) = $651,510

Total: $498,750 + $651,510 = $1,150,260


Therefore, 6 finality headers provide a security of estimated $1,150,260 in total. Meaning that I can trust the information that a server gave me about my transaction, in case the transaction that is part of a block with 6 finality headers and where the transfered $ is less than 1,150,260. If the amount was greater than that, it would be worth it for an attacker to mine a chain of fake-blocks to manipulate block X (and for example fake-include my transaction).


Thank you for your attention!
Tym

[1715410458]

1715410458

[1715410458]

1715410458

[1715410458]

1715410458

[NotATether]

I like your calculations but it assumes that miners' profit is proportional to their hash rate. This is only true for cloud mining, and that type of mining doesn't allow you to generate your own block headers. Normal mining has an unpredictable block generation time that is entirely based on luck. This implies their block rewards are also gained at irregular intervals and it's impossible for attackers to make fake blocks when cloud mining because they cannot include their own transactions in some other company's mining operation.

What is necessary is a calculation involving mining farms (not pools that distribute the rewards to multiple people). Your calculation is good up to this point:

7 * 6.25 BTC = 43.75 BTC

43.75 BTC * ($11,400 / 1 BTC) = $498,750

Furthermore, the attacker needs to achieve 10% of the mining power. With a current total hash rate of 120 EH/s, this would mean 12 EH/s. There are two options: buying the hardware or renting the mining power from others. A new Antminer S9 with 14 TH/s can be bought for $3,000.(https://www.buybitcoinworldwide.com/mining/hardware/) This would mean an attacker has to pay $2,568,000,000 to buy so many of these miners to reach 12 EH/s. The costs for electricity, storage room and cooling still needs to be added.
~

The first value is how much BTC they're wasting by mining fake blocks, so attackers won't be interested in stealing any value lower than this (for they could solo mine and legitimately gain the quoted amount). We need to think of the feasibility of mining fake blocks in terms of how many miners can be bought. I'm no authority on mining though so maybe an knowledgeable person in that field can weigh in on this. What I do know is that it's possible to buy mining farms stashed with miners much cheaper than this, those will give you a few dozen PH/s of hash power.

By the way, about your Antminer S9 link: It seems that buybitcoinworldwide vastly overpriced the S9, you can buy ones directly from Bitmain for less than $100. It's infeasible for someone to get 12 EH/14 TH = a little under 1,000,000 S9 miners because there aren't that many in stock. The new Antminer S19 Pro does around 110 TH/s, so would require only 100,000 of them, and sells for $2400 on Bitmain, but they keep selling out and even if you supplement them with miners from resellers you still aren't going to reach enough miners to muster 12 EH/s. And, the total hashrate goes up whenever miners with bigger hashrates are made. So an attacker will never be able to catch up and get enough miners, and the malicious miner problem will remain theoretical.

No one group ever managed to get a 51% hash rate except for Ghash.io in July 2014, that that was when the global hashrate was around 120 PH/s so that means Ghash had 60 PH/s most likely as a result of having scores of Antminers (which back then performed between hundreds of GH/s, and a few TH/s). Miners stopped mining at their pool in protest, and Ghash even got DDoS'ed because people were afraid they would carry out a 51% attack, and Ghash slowly faded to non-existence.
https://en.wikipedia.org/wiki/Ghash.io

So you can safely assume this is what's going to happen to anyone who has the potential to broadcast fake blocks to the majority.

Nevertheless, a calculation of maximum BTC safe with x confirmations must involve estimating the rewards the miners make. So for the reward you'd need to use some kind of function that randomly gives off a 0 (for missed block) or 1 (for hit block), multiply that by block reward and an average of transaction fees, and sum them all up. Again, I'm not a mining expert so I'd like to hear if there are any existing functions for estimating block rewards.

I think the the number of finality headers * block reward (your 7 * 6.25 BTC = 43.75 BTC above) is all you need for the whole calculation. As the number of confirmations increases, the amount of BTC that's safe to transfer increases by the block reward amount. It doesn't take earned tx fees into account, though fees are big enough to warrant adding the block reward to an average tx fee per block, but it's simple enough.

[odolvlobo]

The scenario: Be sure that block X is part of the actual bitcoin blockchain without knowing every block header - but only checking the finality of block X with a certain amount of finality headers.

Is your scenario realistic? It ignores the longest-chain rule.

[Tym]

Is your scenario realistic? It ignores the longest-chain rule.

I think my scenario is realistic. I don't know exactly what you mean to be honest. Maybe you can explain it in more detail.



@NotATether
Thank you for you feedback! I will take you suggestions into account (that I'm missing the transaction fees, the story with Ghash.io, and the lower price for the Antminer as well).

I'm still wondering if someone is able to give a function to calculate the estimated costs for creating a chain of n fake-blocks. Or maybe a similar calculation that I've shown - with different assumptions/approaches. This would help to get a better idea on how much it actually costs by taking different calculations into account (to possibly form the average).

[odolvlobo]

Is your scenario realistic? It ignores the longest-chain rule.

I think my scenario is realistic. I don't know exactly what you mean to be honest. Maybe you can explain it in more detail.

Perhaps I am misunderstanding you.

If a node sees two branches in the block chain, it will choose the longer branch and reject the other one.

In your scenario, the attacker has 10% of the total hash power, so for every block the attacker adds to its branch, the main chain will add 9 blocks. The attacker's branch will be rejected by every node in the network long before the attacker can add 6 blocks.

Note: In reality, the accumulated difficulty is compared, and not the number of blocks, but the result is the same unless the difficulty changes.

[LoyceV]

In your scenario, the attacker has 10% of the total hash power, so for every block the attacker adds to its branch, the main chain will add 9 blocks. The attacker's branch will be rejected by every node in the network long before the attacker can add 6 blocks.

This makes a 10% attack quite useless, and it's the reason why such an attack is usually referred to as a 51% attack.

With some luck though, someone with less than 50% of hashing power can find the a block before the majority finds one. Let's assume someone tries a 40% attack. That gives him:
40% chance to be the first to find 1 block.
16% chance to be the firstt to find 2 blocks.
6.4% chance to be the first to find 3 blocks.
2.6% chance to be the first to find 4 blocks
1% chance to be the first to find 5 blocks.
0.4% chance to be the first to find 6 blocks.

And that's with 40% of hashing power. With 10%, there's a 0.0001% chance to reach 6 blocks faster than the other miners. That makes paying a million dollars to rent 10% of all hashing power for 10 hours a complete waste of money. If, however, you can get your hands on 5 times more hashing power for just 2 hours, you stand a pretty good chance at rewinding a few blocks.

[Tym]

I think I got a little missunderstood there.

Lets say the current block is at height 648,940. An actor of the network (no full node, no light node, even smaller than a light node) who does not store a chain of blocks neither a chain of block headers (like spv-clients does). This actor wants to verify the existence and correctness of a block by checking the finality.

For example: He requests the block header of block 600,000 and 6 finality headers to make sure that this block is correct. If the responding node is able to provide 6 (or even more) finality headers, the actor can be very sure that this block is correct and part of the actual Bitcoin blockchain.

Attack scenario: An attacker modifys block 600,000 (removes or adds a tx) - to prove the actor that this block is correct, the attacker has to provide 6 finality headers. He's not competing with anyone - he's secretly mining his chain of fake-blocks. But he should better be fast, because the actor won't wait too long for a response.


Now back to the original question: Its very expensive for an attacker to put his mining power into mining such a chain of fake-blocks. So if the actor wants to verify a transaction worth of $100,000 that is part of block 600,000 it might be worth it for an attacker trying to manipulate that block and deliver a chain of fake-blocks so that the actor verifies a wrong block. But this is only worth it up to the amount the attacker has to pay for this attack.

Up to which amount of $ can the actor trust the result of the server? (As long as the transaction is smaller than the costs for this attack the actor can pretty sure that the sever delivers a correct block + correct finality headers).

Therefore: How expensive is it for an attacker to create such a chain of fake-blocks?
(Modify block 600,000 and provide 6 finality headers - since the client does not store the whole chain, he cannot check against other information - so he would trust the wrong result).


Thank you for further responses!

[LoyceV]

Lets say the current block is at height 648,940. An actor of the network (no full node, no light node, even smaller than a light node) who does not store a chain of blocks neither a chain of block headers (like spv-clients does). This actor wants to verify the existence and correctness of a block by checking the finality.

For example: He requests the block header of block 600,000 and 6 finality headers to make sure that this block is correct. If the responding node is able to provide 6 (or even more) finality headers, the actor can be very sure that this block is correct and part of the actual Bitcoin blockchain.

That's the risk of using a SPV wallet: you must trust a third party. It doesn't make sense to ask for a specific block, and makes even less sense for them to create an old side chain.

A very simple solution to avoid this is to run your own full node.

[NotATether]

That makes paying a million dollars to rent 10% of all hashing power for 10 hours a complete waste of money. If, however, you can get your hands on 5 times more hashing power for just 2 hours, you stand a pretty good chance at rewinding a few blocks.

You can't just rent hashpower for that short of a period. I already explained that you can't use rented hashpower per se to create blocks, you need to rent physical miners or mining farms. And to get enough miners to obtain 10% of the total hashpower, you'd have to make business deals with dozens of mining farm operators, because they aren't coordinated each deal will be completed a few days apart (and this is a very optimistic estimate, normally this kind of physical deal would take weeks), so even if they technically pay a discounted price for the farm compared to renting hashpower directly, attackers will run their partial equipment for several hours/days while they wait for the rest of the farms to rent out, and that will drain their pockets.

Also, I suspect if operators think that the buyer wants to perform a 51% attack using their farm, nobody will lease their farms to them!


Perhaps the question we should be thinking about, instead of how much bitcoin in a tx is safe from reversing at <x> block depth, is how much bitcoin is safe for a given tx fee, mempool size and time waited. This has a practical usecase since unconfirmed transactions can be diverted with RBF. (Here we are trying to discourage third parties, not miners, from stealing bitcoins, by not making the transaction look too fat and standing out from the rest in the mempool for too long.)

[LoyceV]

Perhaps the question we should be thinking about, instead of how much bitcoin in a tx is safe from reversing at <x> block depth, is how much bitcoin is safe for a given tx fee, mempool size and time waited.

That's easy: 0 BTC Unconfirmed transactions are never completely safe.
Even though most nodes don't relay double spends, there's always a possibility that a miner includes such a transaction (even without RBF), just like they can include zero-fee transactions.

This has a practical usecase since unconfirmed transactions can be diverted with RBF. (Here we are trying to discourage third parties, not miners, from stealing bitcoins, by not making the transaction look too fat and standing out from the rest in the mempool for too long.)

I'd be totally fine accepting an unconfirmed low-fee payment from someone I trust. As long as I'm not in a rush to spend it, I don't mind if it takes days to confirm. But if it's someone I don't know, I'll wait for at least one confirmation before completing my end of the deal.

[NotATether]

Perhaps the question we should be thinking about, instead of how much bitcoin in a tx is safe from reversing at <x> block depth, is how much bitcoin is safe for a given tx fee, mempool size and time waited.

That's easy: 0 BTC Unconfirmed transactions are never completely safe.
Even though most nodes don't relay double spends, there's always a possibility that a miner includes such a transaction (even without RBF), just like they can include zero-fee transactions.

I guess I should've said the probability of a transaction of a certain BTC value <y> (& mempool size/tx fee/etc.) being hijacked. I know that all unconfirmed transactions can be reversed, but if an attacker leaves a tx alone because it's small and isn't interested in it for financial reasons, then we can say it has less probability of being diverted.