Topic: The math behind confirmations? (Read 361 times)

Maybe modify it to something like:

$1 million = 1 confirmation.
$10 million = 2 confirmations.

If you sent it, you know you're good. If the other person sent it, you can quickly check within 10 seconds to see if there are any attempted double spends as well as to check if a proper minimum transaction fee was used. Also, you have to have some level of trust with the other person anyway for your transaction with them.

Are you selling a car? Are you trading for a house? Or is it just some baby toy or gaming console / robucks / gift card? The house isn't going anywhere, and the lambo probably has GPS on it.

If you are accepting 100 BTC to trade for something physical, then there is that simple act of sending the item or meeting them in person and a 10 minute wait for 1 block is more than enough.

If you are accepting 100 BTC to trade for something not tangible, then ... maybe they can wait a few more minutes after 1 confirmation, or they may be willing to accept that you will wait for 2. Some things might take longer to send than the BTC you are receiving anyway.

There are good incentives on both sides of the transaction to perform an honest trade, even if the other guy is a miner with more than 51% of the hash power, which is very unlikely. They would just do better to mine like any normal miner and get the usual block reward.

I don't think it's worth it for 3 million dollars. I'm not sure about exact numbers in terms of electricity, but renting enough pools to have a good shot at reversing a transaction that is 1 block deep, for just 10 minutes, might actually be more expensive than 3 million dollars, not to speak of 'bribing fees' - after all, it's a big ask to get a mining pool to actually perform an attack. It could give a huge dink to their reputation if someone figures it out.

That's, currently, equivalent to 3 million dollars. If the person you're dealing with, again anonymously and with other necessary conditions so you can't reach him legally, is a miner he's really incentivized to reverse it and gets his 100 BTC back. He could cooperate with a mining pool, which will increase his chances; he may even is a pool.

I'd say that 6 confirmations for anything above a million dollars is a number to sleep easy with.

For all intents and practical purposes up to around 100 BTC or equivalent fiat value, 1 confirmation is good enough.

If you are the one sending from your own wallet (Bitcoin Core, Electrum, Spectre) then you can see your transaction in the mempool and once it has confirmed once or 1 block, you can be sure that whoever you sent it to will get it, even if they want to wait for more than 1 confirmation.

If you are the one receiving it, in your own wallet, same thing.

If you are sending or receiving it using a third party or custodial service, or exchange, then you are subject to whatever number of blocks confirmation they require before they let you use it. Receiving it, may show as pending, and you just wait. Sending it, depending on if they batch your transaction or send it later, you'll also have to wait.

Normally you don't wait more than half an hour to an hour anyway.

To fuss about some transaction not having 6 or 10 confirmations and it's less than the price of a pizza (whether that's back then, or today) is just wasting everyone's time.

Exactly. Even with a third of the hashrate cooperating, and a lot of money on the line, the probability of success will still make it a big gamble to reverse a 6 confirmation transaction.

That's a good point. It would need to be something of very high value that can be transferred with total finality within 6 blocks or roughly one hour's time.

If you have a 1% probability of reversing the last 6 blocks, then you have about 28.5% 19% of the total hash power. This can happen if a big mining pool decides to. So, yeah, it's a big gamble since that is likely to ruin their huge business.

But, what kind of transaction moves so much money and can be successfully double-spent that way, at the same time? I mean, if the USA agreed on paying 10,000 BTC to Putin for, say, buying a lot portion of Russia's gas, and somehow managed to double-spend that, first of all, they wouldn't get any gas since it'd take some days (hundreds of blocks) to deliver, and second, that would probably be the reason to officially set sail to the second cold war.

It makes sense to double-spend only if you do things anonymously or if the seller can't reach you.

Not to speak of the economic cost of this all. If your probability is as low as 0.1% or 1%, it's a big gamble to make, with a lot of money on the line (a big chunk of the mining network in electricity cost for an hour). This only makes sense to double-spend a pretty rare transaction, worth millions or with a very well paying lobbyist / politician (in the case of a censorship-motivated attack).

Definitely, RBF is a much efficient way of saying "I want this confirmed", but I'm just pointing out that, even without RBF, you can still use this "bump" feature, without the danger of trivial double-spending.

They're different, but not completely different. They both satisfy the same need; transaction settlement. And I can compare them, from both merchant's and customer's perspective. What's cheaper for both? Bitcoin, because trust costs. What's more secure for the merchant? Bitcoin, because there are no chargebacks, bank reversal, disputes. What's more private for both? Bitcoin.

Exactly, which is why I said I would approve an unconfirmed <= $300 worth of bitcoin transaction as settled. For a cup of coffee, though, Lightning is a better solution. But, for supermarket fulled cart, that can't be easily paid with Lightning, since there's high chance of routing failure, and where there's rush, the merchant should accept unconfirmed transactions.

I'd be willing to open a channel with my supermarket, if it was possible, though, and make my purchases instantly. But, that's just me, I can't expect the others behave same like.

CPFP is actually a very inefficient way of 'accelerating' a transaction. The user have to either intentionally make a transaction with a higher fee or do so in a subsequent transaction, provided that the next user doesn't care about the unconfirmed output. Mempool seems to accumulate over time and it would be far more expensive to do a CPFP later than to have an RBF now. I'd very much prefer having the flexibility of doing so without incurring additional costs or time. If I'm the merchant, I'm definitely not looking to wait for a transaction to be confirmed in a day or two.

For starters, credit card settlements and Bitcoin transaction finality are completely different and they cannot be equated to be the same. The former has some accountability on both the user and the merchants and there is a case to be contested for most cases, not the main point anyways.

Customers won't be there to defraud you for a cup of coffee or for lunch and it really depends on the risk tolerance. It's either LN or you pay and I make your food, by the time I serve you, the TX should probably be confirmed. I'm not sure if the customers would be willing to do a transaction without RBF, knowing that there is a possibility of the funds being stuck for a while. I won't be comfortable with that and I don't really think it is a good way to manage the risk or neither is it a good trade off, but that might just be me.

---

Any attacker having more hashrate than the rest of the honest network will always be able to mine any number of blocks more than the rest of the network, given time. The 6 confirmation rule is based on game theory and is not a strictly mathematical concept. 6 confirmations can be enough for any other altcoin, so long as you think the amount being transacted is very much less than the cost of the hashrate for 51% of that network.

I don't think the OP is asking about a 51% attack. My understanding of the OP's question is that he is asking about the probability of there being a chain of orphaned blocks that is 6 blocks deep. The OP does use the words "double spend attack", but the context of his question appears to be asking about orphaned blocks.

When a block is found, it will take x amount of time to propagate throughout the network, and if another miner finds a competing block within that time, there is the potential for some of the network to be working on top of one block at height y, and some of the network to be working on top of another block at the time height. If this were to happen, and both parts of the network find block y + 1 within the aforementioned x time, there will be a chain of two orphaned blocks.

Without knowing how long it typically takes for blocks to propagate, it is difficult to calculate the chances of a chain split that is n blocks deep. I do know that the miners, and mining pools have invested heavily in getting their found blocks to the other miners quickly, and over time, the time required for a block to propagate has been reduced.

With the above being said, just because there is a chain of orphaned blocks, it is not necessarily going to be true that there will be a different set of confirmed transactions in each of the blocks. In general, miners will fill their blocks with transactions based on transaction fee rate, so all miners are more or less expected to include the same transaction set in each of their blocks, notwithstanding transactions that were very recently broadcast immediately prior to a block being found.

If they want to spend their output, they can broadcast a child-pays-for-parent transaction and incentivize the miners to include both.

It really depends on the amount transacted. I, as a merchant again, wouldn't be bothered to accept such unconfirmed transaction for an amount less than $300. I don't believe that a customer would choose to defraud me that way, I find it difficult thing to happen, there's still a decent percentage of uncertainty for the double-spending to occur, and I'd, either way, also accept credit card payments which are far easier to reverse and whose finality takes about 6 months more than a bitcoin transaction does.

Furthermore, "the customer is always right". If he asks for unconfirmed transactions, I might dissatisfy him by disagreeing, which is definitely not a smart move.

---

For thousands of dollars worth of bitcoin, you should absolutely require at least 1 confirmation.

I don't recommend people accepting unconfirmed transactions, because you are creating potential problems for yourself and your customer. If it remains unconfirmed for an extended period of time, you won't be able to spend it and neither will the customer be able to spend their change. The latter is more than fine, because you should be accepting confirmed transactions. The volatility of the fees in recent times hasn't been very kind and there is still a good enough possibility for the customer to be able to push it directly to a mining pool, RBF or not. Which is what my point on this "false sense of security" about.

If you absolutely have to accept unconfirmed near instant TXes, do so via lightning network. Though 10 minutes for a confirmation isn't always undesirable.

That's true, just wait for a couple confirmations and you're fine. RBF or not.

Yes, but it also makes it difficult to reverse or replace the transaction. If I was a merchant I'd rather accepting a low-fee unconfirmed non-RBF transaction than a high-fee with RBF enabled, because the latter makes double-spend easygoing.

Not necessary. Disabling RBF does nothing other than preventing another miner from potentially mining a competing transaction by chance. If there is any ill-intent present, then there is no point asking them to disable RBF because they would have gone a little further to try to get their transaction to get double spent. There's this misconception that disabling RBF prevents any easy double spending but that is false; the primary purpose of RBF is to allow users to replace their transaction with another that spends a higher fee and disabling defeats that purpose especially in instances where fees spike were to occur.

The one and only way to be certain is to wait for 3 or more confirmations (if you are that paranoid). Otherwise, there is little to no security benefits. Anyways, stale block candidates are easily detectable with a well-connected node. It isn't a big problem.
Record is about 6 in a very specific scenario, IIRC. Otherwise, normal circumstances would be about 1.

Still, though. Once the chain gets reorged, which happens usually for 1 block, the transactions of the block that was dumped become unconfirmed and return to the mempool. Now they can get mined within the next blocks. If I was going to receive a lot of money, I'd ask to disable RBF and have at least 1 confirmation. Disabling RBF means you can't (practically) double-spend your unconfirmed transaction.

That's true. Chain reorgs, as I've said, usually affect the last block. I don't believe it has ever happened for 2 or more.

Although Bitcoin paper considered an attacker when doing probability calculation, competing blocks can be mined randomly without ill intentions. These competing blocks will be broadcast to the network and someone sending large amount should watch for a possible blockchain reorganization. If my transaction has one or two confirmations and there are no competing blocks that don't have my transaction then I am pretty sure that my transaction went through.

You can still access an archived but fully functioning version of this page here: https://web.archive.org/web/20181231045818/https://people.xiph.org/~greg/attack_success.html

You can play around with the numbers yourself to understand things. In the top box enter the proportion of the hash rate that an attacker has. So if they have 10%, enter 0.1. For 35%, enter 0.35. And so on.
In the second box, enter the number of confirmations they are attempting to reverse.
Multiply the result by 100 to get the chance of an attack being successful.

So if you enter 0.1 and 6, you get 0.0002. This means that an attacker with 10% of the hashrate would have a 0.02% chance to reverse 6 confirmations.

That makes sense, because the largest pool (still F2Pool I believe) only has 13ish% of the total hashrate, so the advice of 6 confirms reflects the reality of the mining landscape.

It would be difficult, but not impossible, for an owner of multiple large pools to make them collude and thus require additional confirmations, but tensions inside the management resisting such an operation keep this a strictly theoretical scenario.

The probability of any miner finding a block is a Poisson process, where the probability of an attacker finding a block is relative to the hashrate that the rest of the network. Hence, you can see that the expected value of the number of blocks being found by an attacker is z(q/p), where for eg. if you have 50% of the hashrate, you are likely to find the next block 50% of the time.

What the rest of the simulation is would be to calculate calculate the probability of the attacker getting the next block given that he has also mined the last z blocks. The reason why Poisson distribution is used, is because the probability of getting a block with q percentage of the hashrate is not an uniform distribution, and hence we have to use Poisson distribution to approximate the number of blocks to catch up.

The point here is that the attacker needs to outpace the network, by catching up with the number of blocks that it is behind on the network. The re-organization has to be strictly mined such that the successive blocks all belongs to the attacker. As such, this calculation assumes that the attacker is simultaneously mining with the network and is able to mine d successive blocks to outrun the network. This assumes that the miner isn't selfish mining, which would skew the probability significantly.

Now, if you observe from the results, 6 confirmations only provide a 0.1% chance of the miner doing a double spend assuming that the attacker only controls 10% of the network hashrate. This number increases with proportion of the network hashrate that the attacker hold. 10% of the hashrate is fairly large, and that is also where game theory comes into play; attackers are unlikely to be willing to waste more than that to double spend a transaction and the probability of success is reasonably low across various proportion of the hashrate as well.

It is not correct that the probability of double spends beyond 6 confirmations is 0.1% at all of the scenarios, but if the attacker controls 51% of the hashrate, it will always be a 100% probability of success because it is always able to generate blocks faster than the rest of the network.

Here is more recent work: https://arxiv.org/pdf/1912.06412.pdf