This article is in the public domain. A PDF version of this article is available here.
Abstract
We present a concise method to determining reasonably safe confirmation thresholds for any proof-of-work chain for any amount of value transacted. We do this by assuming a double-spend attacker is a purely profit-seeking entity and will seek to invest the minimum amount of capital in an attack with sufficient risk thresholds and return on investment. We find that for a double-spend attacker to be the most capital efficient, they will rent and/or bribe existing 59% of the existing hash power and incur costs at least 2.88 times the value of a single block. Over sufficiently long settlement times, this asymptotes to be around 50% the block’s value to miners. We call this the “1ConfValue” and analysed this across multiple chains, finding that for most chains that since fees are negligible, the block value is essentially just the block subsidy. This is our final rule-of-thumb, and can be generalised across any PoW chain and transaction value, including strictly in native assets.
The rule-of-thumb is as follows:
confirmationsRequired = (transactionValue)/1ConfValue
transactionValue = sum(all received transactions in block)
1ConfValue = blockValue/2
blockValue = subsidy + fees
PoW Mining
Proof-of-Work (PoW) mining is a stochastic process, where each state transition is dependent only on the state attained in the previous event. Put another way, the likelihood of the next event is “reset” each time. If there are two miners on the network, and one commands 51% hash, and the other 49% hash, then the likelihood of the majority miner finding the next block is always 51%. Additionally, the time required to find the solution is also stochastic (being a continuous-time markov chain), such that at any time, the next block will always be 10 minutes away. These two qualities mean any miner of any hash power can mine on the network and participate in block production and is a fundamentally brilliant part of PoW.
It also means that all miners on the network are subject to events that are only influenced by probability and their weight on the network. This means that no outcome is guaranteed and all behaviour is driven by incentives and risk/reward assessments. It is from this perspective that we reason about Double-spend Events.
Double-spend Events
Here are the confirmation requirement thresholds from Coinbase for accepting transactions:
Exchanges set confirmation requirements on PoW blockchains in order to prevent being victims of “double-spending events”. Bitcoin itself has no concept of “final”, apart from the 100 block (~16.6 hour) coinbase limit which is the period of time after miners can claim coinbase subsidies. Network users typically wait 6 blocks (1 hour) before accepting that a transaction is sufficiently embedded into the chain. This appears to come from a single 2012 paper on Double Spending written by Meni Rosenfeld.
However we believe that this is not an appropriate method for real-world-use and Rosenfeld’s conclusion is more academic than realistic. The following is missing from this research:
- Considering the incentives for a double-spending event
- Considering the mechanism by which majority hash-rate is obtained
- Considering the investment required build a long-enough alternate chain
- Generalising PoW confirmation thresholds for any PoW chain
Rosenfeld only considered whether an attacker could catch up and double-spend, but not how much capital would have to be invested in order to do so. Since we reason that all network participants are rational-actors and always profit-seeking, then we must consider their incentives. In order to derive a sufficiently robust rule-of-thumb, we ask the question “When is it profitable to conduct a double-spend event?” instead of “When is it safe to accept a PoW transaction?”.
Double-spending attacks are actually neither double-spends nor attacks. The Bitcoin protocol chooses the canonical chain to be the chain with the most accumulated difficulty. If a chain is broadcast onto the network with more accumulated difficulty than one that was accepted to be correct by a network participant, then the network participant simply had poor security assumptions, and the new chain is entirely valid.
Bitcoin is an a-moral system, and forms no opinion on the intent of a network participant making transactions. If a payment recipient releases off-chain resources in return for an insecure payment, and that payment is replaced in an alternate — but valid — chain, no properties have changed about Bitcoin, and no transaction is “good” or “bad”.
Anatomy of a Double-spend Event
We will take on the persona of a profit-seeking entity wishing to attack a network participant with poor security assumptions. We will make a large deposit (to an exchange or merchant), exchange it for another currency (or product), and then release an alternate chain to the network that spends the original deposit back to us. If this is successful, we will keep the original deposit, plus the withdrawal/product.
For this to be a successful endeavour we must be making a transaction that is large enough for us to have financial incentive to pull off the event. Mining an alternate chain on a network demands resources, and if the financial gain does not present a return of investment to us, then we won’t complete it.
Importantly, the event does not “cost”, rather it demands an “investment”, which changes the calculus. This is because if our alternate chain is accepted, then the block rewards and transactions fees are paid back to us. Assuming that the cost to produce a block is always less than or equal to its value, then we will be reimbursed for most of our expenses.
Since we have no interest in attacking anyone but our target (to increase the likelihood of global acceptance of our alternate chain), we will preserve all other transactions in the alternate chain. Thus it is a local event only, and global users are unaffected. This is historically why double-spend events have no impact on market price, since no qualities of the chain have been compromised during the event.
Gaining Majority Hash Rate
We consider there to be two distinct methods for us to achieve a double spend event. The first is to accumulate secret hash power, but not to mine publicly on the main chain until it is time to release our alternate chain. The second is to accumulate public hash and after the target transaction is made, switch this public hash to an alternate chain, mining publicly. We look to find which is more capital-efficient.
In both cases, we will only embark on a double-spending endeavour if we have favourable chances, which means our hash (qH) must exceed that of the network’s (pH). This is reinforced by Rosenfeld’s findings that unless qH > pH, we will quickly mount irreconcilable costs as the honest chain leaves our alternate chain behind.
Secret Hash
The scenario is that we source secret hash from another chain or network (Bitcoin SHA256 being applied to BitcoinCash SHA256, or GPU hash coming from a hash-market such as nicehash), and begin mining the alternate chain the same block as the target transaction. Once the alternate chain is longer by one block, then we will broadcast it.
In this case, we must source greater than 100% of the existing hash in order to command collectively more than 51% of the total hash.
If each block has an expected cost “1BlockCost” leading up to the event, then the investment will require at least 2 * 1.1 * 1BlockCost in capital. This does not consider stochastic processes yet.
Public hash
The other scenario is that we have public hash already on the chain and instead of sourcing it elsewhere, simply direct it to our alternate chain (or bribe miners). In this case, it is in our best interest to not switch the hash until after the target transaction is made. This is so the public chain is “starved” of hash and slows down, allowing us to mine two blocks in quick succession on the alternate chain. As long as the alternate chain processes valid blocks and includes all non-target transactions, it will be accepted by the network.
Once again assuming that each block has an expected “1BlockCost” leading up to the event, we only need 2 * 0.51 * 1BlockCost in capital to pull it off. This is the absolute minimum amount of capital required.
Compared to the Secret Hash scenario, it is clear that the Public Hash mechanism requires 50% less investment to achieve. The only disadvantage to the Public Hash mechanism is that the double-spending event will be completely public the entire time, but we do not consider the possibility that the network would not accept it as a valid chain. This is primarily because the alternate chain will include all the transactions the public chain has, and is entirely valid in terms of transaction compliance.
Considering Probabilities
In the Public Hash scenario we accumulate at least 51% of the existing hash, then direct it to mining two blocks in a row such that our alternate chain is one block ahead of the public chain. Since we have to deal with stochastic processes, we do not have a surety of building two blocks for the original’s single block. We must weigh in the risk that despite our greater hash, we fail to find the two blocks or even get one block ahead.
We can work this out by assessing our “edge”, which in the case we have 51% hash to the existing network’s 49% hash, then our edge is 5%. Since we have a 5% edge at each block, and our blocks are 5% faster, then we compound our edge to work out our confidence level of achieving a one block lead after a two blocks.
Since we are a profit seeking entity, we must assess the risk of every endeavour and stick with safe limits. We do not consider any confidence level below 100% a viable option, since we will quickly accumulate unplanned costs if the odds do not favour us and we can’t get one block ahead. We choose the 100% limit to be sure that we have twice the chance as the existing miners. This requires us to accumulate at least 59% of the hash.
Put another way, given our hash advantage, at how many blocks in the future will we be twice as confident as the other miners that we can be one block ahead? We can then multiply our hash costs by the number of blocks to work out how much we should invest. For anything below 59% hash, the costs quickly blow out. At 59% hash we have the lowest cost multiple and yet still fit within our risk tolerances.
Investment Required
We now know that the best possible scenario is to accumulate 59% of the public hash and construct an alternate chain immediately after our target transaction is settled. Our cost multiple is 1.44 that of the existing network, and we need to do this for a minimum of two blocks, for a total cost multiple of 2.88.
We assume we can rent/bribe/build hash power with minimum capital expenditure, so our only investment required is operational expenditure. Given that the cost to mine a block approaches its free market value over time, and that the more urgent our demand of hash power and the less sunk cost we are willing to pay, the closer to the market value of each block we will be required to pay. This makes sense since that is the opportunity cost for the existing miners we are bribing/renting from.
Thus in order to pull off an attack on a target transaction, we need to invest as a minimum 2.88 the value of a single block.
Looking at Bitcoin, we can see that average block values are currently around 12.75 BTC (12.5 subsidy with 0.25 in fees), so this would require us to invest at least 37 BTC in capital (2.88 * 12.75).
Minimum Transaction Values
We now know that we need to invest 37 BTC in order to successfully double-spend a target transaction with our defined risk tolerances. The next question — what size transaction would be high enough to warrant us to invest? This answer is not cut-and-dried due to PoW’s stochastic processes. Even if we have sufficient hash, we could still encounter an unfavourable outcome and quickly rack up much higher costs. Every block we need to mine will cost another 18.5 BTC in investment capital. Given that we have a 100% confidence level (twice as sure that we will mine our blocks faster than the network), we can safely attack a transaction that equals our total investment (37 BTC) and double our money.
We can conceivably also attempt to attack a target transaction that is one third of our investment (and equal to the block value). In this case we would be risking 37 BTC to make 12.75 BTC, at a margin of 34% to our investment. We don’t consider that any lower would present enough of a return to warrant the risk we would be making.
Thus, we settle on a figure of the block value to be the lowest transaction value we would attempt to attack if our target transaction settles with one confirmation. However, if we must wait for longer confirmation settlement of our target transaction, the per-confirmation cost decreases:
Over time the value per confirmation reduces until it is ~50% the Block Value. This is because the first confirmation requires two blocks to be produced, while the second confirmation interval only requires three, so isn’t linear. Plotted out to 100 confirmations:
Considering Sybil Attacks
If we know the target will be monitoring and flagging large transactions, we will be able to counter this by sending the transaction in smaller amounts, but with the intent to have them all confirmed in the same block. We may even use different addresses. The target will assume they are dealing with separate entities, but instead all transactions received are from us.
Thus we can use the entire blockspace to send small-value transactions to a target, and re-direct them all in our alternate chain. The entire value of all transactions will still be worth the investment to us.
Analysis of PoW Chains
Using this surprisingly simple rule-of-thumb, we can compute the minimum 1ConfValues for Bitcoin, Bitcoin Cash, Bitcoin SV, Ethereum, Litecoin, Dash and Dogecoin, in their native asset as well as USD values:
We see that in all chains that fees are negligible except Bitcoin. (Ethereum has varying uncle rewards, but these are counted in the subsidy). Thus for the generalised case, BlockValue = BlockSubsidy.
We finally revisit Coinbase’s confirmation requirements, compare it with our method and calculate it for the maximum of $25,000 deposit (Coinbase daily limit):
We can see that the arbitrary 6 confirmation requirement (most likely derived from Rosenfeld’s research) is far more than is required for a $25,000 Bitcoin deposit. Bitcoin Cash and Ethereum Classic appear to be suitable, but Ethereum, Litecoin and Zcash appear significantly insecure.
Summary
We took on the persona of a rational profit-seeking entity who wished to exploit the poor security assumptions of a target merchant or exchange. We analysed both accumulating secret hash, or just taking over the majority of the public hash, and realised that accumulating 51% of the public hash was more capital-efficient. We settled on a risk tolerance that had a confidence level of 100% and computed the minimum required hash, which was 59%. This required us to invest at least 1.44 the cost of a single block in acquiring the hash at market prices, which was driven by the free market value of each block. We then computed this from 1 to 100 confirmation counts for settlement and realised that it asymptotes to be 50% the value of one block. We call this the “1ConfValue” and analysed this across multiple chains, finding that for most chains fees are negligible, so we only need to consider block subsidies. This is our final rule-of-thumb, and can be generalised across any PoW chain and transaction value, including strictly in native assets.
Thanks to Nic Carter for encouraging me to publish this and Anthony Lusardi for providing feedback about sybil attacks.
Follow me on twitter, I research and write about Bitcoin.
