can a Bitcoin transaction have 2 confirmations and still be reorged?

[coinlary]

How possible it is for a Bitcoin transaction to have 2 confirmations despite ending up on a stale block before being dropped in a typical chain reorganization scenario, or once a transaction has 2 confirmations, does that generally mean it is safe to release funds even if there is a fork.

Trying to understand whether 2 confirmations is enough for every transaction without worrying about a potential chain reorganization. I mean how much protection does 2 confirmations provides against reorg.

Also, how likely is it for a block explorer to miss a fork perhaps just a few seconds or minutes?

[Karl_3000]

The probability that a transaction that has two confirmations will be reversed is very rare but it is possible. 51% attack is the worse where transactions that have more than 3 confirmations can be reversed because of chain reorg. If there is no 51% attack, I prefer 3 to 6 confirmations. But the higher the confirmations the lower the risks of transaction reversion.

[Zaguru12]

How possible it is for a Bitcoin transaction to have 2 confirmations despite ending up on a stale block before being dropped in a typical chain reorganization scenario, or once a transaction has 2 confirmations, does that generally mean it is safe to release funds even if there is a fork.

There is a possibility because the main chain that is considered isn’t based on the number of blocks rather it is base on the number of most accumulated chain work so two blocks can still end up not been part of the most chain work and a chain reorg can possibly happen.

Although the probability increases as the number of blocks increases. The probability has been calculated and explained by Satoshi on the bitcoin white paper page 8

Trying to understand whether 2 confirmations is enough for every transaction without worrying about a potential chain reorganization. I mean how much protection does 2 confirmations provides against reorg.

Also, how likely is it for a block explorer to miss a fork perhaps just a few seconds or minutes?

For a smaller amount transaction I will recommend that 1-3 confirmation is ok but a very higher amount can take six confirmation to erase the doubt totally.

One block chain reorg is common but even with that it’s usually understood that once a stale block is formed after a chain reorg majority of the transactions in this stale block are still added to the replacement block or the next block

[Upgrade00]

One block chain reorg is common but even with that it’s usually understood that once a stale block is formed after a chain reorg majority of the transactions in this stale block are still added to the replacement block or the next block

Also, more often than not, transactions will be present on both the stale block and the active one not needing any recycling back into the mempool to get confirmed. In the few case that it's not added, it will be added to another block.
Transactions from the stale block would have also not gotten to 2 confirmations.

Trying to understand whether 2 confirmations is enough for every transaction without worrying about a potential chain reorganization. I mean how much protection does 2 confirmations provides against reorg.

For almost every 1-2 confirmations is secure. Except you're transacting an amount so high it motivates the receiver to try to directly manipulate the network and still be profitable, then you can wait for about 3-6 to make sure.

[Danish Ali]

How likely is it for a block explorer to miss a fork perhaps just a few seconds or minutes?

Explorers simply present what the latest best-chain-work the backing-node is observing from its perspective. A reorg means there's a slight delay (several seconds, possibly longer) between a node/explorer reporting the stale block as "tip" and the new best chain getting reported by the node/explorer. So maybe a user might flash on "2 confirmations" for a bit until it goes back to "0 confirmations" that's just a user experience thing that has nothing to do with the actual risk of reorg.

Satoshi's paper (Section 11) provides the actual probability of an attacker catching up using a Poisson process, rather than just a simplistic estimate:

Code:

λ = z * (q/p)
P = 1 - Σ (k=0 to z) [ (λ^k * e^-λ / k!) * (1 - (q/p)^(z-k)) ]

Plugging in q=0.10 (10% attacker hashrate):

Code:

z=0  ->  P = 1.0000000
z=1  ->  P = 0.2045873
z=2  ->  P = 0.0509779
z=5  ->  P = 0.0009137
z=6  ->  P = 0.0002428

This directly matches the whitepaper's C-code output. It proves that risk drops exponentially per additional confirmation, which is why 1-2 confirmations are mathematically fine for small transactions, while 6 confirmations became the baseline standard for high value transfers.

[BlackHatCoiner]

The probability of mining a stale block is roughly 0.1%, considering there have been around 50 stale blocks in the past 52,500. That means the that mining a stale block on top of another stale block is about 1 in a million.

I'd be pretty confident with that chance, but you can wait for another 10 minutes if you want to be extra safe.

[coinlary]

Great

Thank you all for your comments

I'd be pretty confident with that chance, but you can wait for another 10 minutes if you want to be extra safe.

That's it, 3 confirmation on another average 10 mins.
Thanks  for the link, i found it  useful.

Btw, does anyone have a link to a news where someone lost some Bitcoin due to a chain reorganization, or has that never happened? Just trying to figure something out. I’m not asserting that a reorg itself directly causes losses(I believe the question is straightforward enough)

[Karl_3000]

Btw, does anyone have a link to a news where someone lost some Bitcoin due to a chain reorganization, or has that never happened? Just trying to figure something out. I’m not asserting that a reorg itself directly causes losses(I believe the question is straightforward enough)

It has actually happened before but the one that I know about was not for a bad intention but an experiment. It was a successful experiment as the coin was double spent.

https://bitcointalk.org/index.php?topic=152348.msg1616747#msg1616747

[coinlary]

https://bitcointalk.org/index.php?topic=152348.msg1616747#msg1616747

Thanks .

[Cricktor]

I've only observed this once in the recent past that a Bitcoin chain reorg made two consecutive blocks stale and rendered them an abandoned chain leaf.

See this topic I started about it: Rare two-block reorg in Bitcoin Mainnet

To be clear, I don't say this happened only once as shown in my example. I don't have the whole history of abandoned Bitcoin chain leafs, the absolute majority seem to be just one block long when I look at fork.observer or request data from my Core full-node via getchaintips command. My Core node also doesn't "see" every chain reorg that happens.

[internetional]

Let's take any transaction that was "lucky" enough to get into this block: https://mempool.guide/block/0000000000000000000169eb6f811ddbd0daf343af7b62180cdb13e7c78dbc16 . This is the first block in the alternative chain created based on BIP-110.

All of these transactions already have four confirmations. However, if work on this chain is stopped, all clients will be forced to sync with the longer blockchain, where their transactions will undergo a reorganization.

On the other hand, the transactions that made it into this block have most likely already been included in some block of the main chain as well. But if there are dependent transactions on top of that data in the short chain, and they have 2 - 3 confirmations, they are definitely bound for a rollback.

[athanred]

However, if work on this chain is stopped, all clients will be forced to sync with the longer blockchain

No. Any user can use any chain. If someone is using BIP-110 client, then it won't automatically "sync with the longer blockchain", it will just stay on a halted chain. I can write a client, which will block all transactions, unless they send some coins to me. Guess what: my halted chain may be unusable, but it will not automatically follow the longer chain: if someone is using a minority consensus rules, then that user is rejecting the longest chain, no matter what.

the transactions that made it into this block have most likely already been included in some block of the main chain as well

Only if they are following the same consensus rules, and relay rules didn't stop them from being included. For example:

BIP-110: https://mempool.guide/tx/507391a74573a08c1f7577c0280efda5ead2ce50ee0d83b6c31a1d716ea91f34
non-BIP-110: https://mempool.space/tx/fd1a2b41fbae10adfcc44b0e3e6d6a4ff8679ac86f1da1386a0ff2263522143e

And now, if BIP-110 chain will be built on top of existing blocks, then these coins will be splitted forever.

[Curious T]

The probability of mining a stale block is roughly 0.1%, considering there have been around 50 stale blocks in the past 52,500. That means the that mining a stale block on top of another stale block is about 1 in a million.  

The chances can even be lower than that, but I'm more bothered about what the OP was asking about 2 confirmations. From what I understand, it takes the network 5-10 seconds to choose a block if two blocks were mined at the same time. So if it takes such a short time to choose a block, how can a transaction be in a stale block within 5 seconds and even get another confirmation, all before the network orphans the block? So is it possible to even have a transaction confirmed in a stale block, let alone two confirmations?

[Cricktor]

From what I understand, it takes the network 5-10 seconds to choose a block if two blocks were mined at the same time. So if it takes such a short time to choose a block, how can a transaction be in a stale block within 5 seconds and even get another confirmation, all before the network orphans the block? So is it possible to even have a transaction confirmed in a stale block, let alone two confirmations?

Mind to explain how you think "it takes the network 5-10 seconds to choose a block if two blocks were mined at the same time"?

Honestly I don't know how this should happen, because if two blocks are mined in such a temporal proximity that the chain splits because one part of the network has seen block A first and their miners mine on top of this one, while another part of the network has seen block B first and those miners mine on top of block B.

This is a chain split or fork with leaf-length of one and commonly the next mined block, either appended to block A or block B, will decide where the chain continues and which of block A or B become stale and abandoned. But this next deciding block can take anywhere from a few seconds to over an hour to be mined (considerably longer than an hour is quite rare but happens from time to time).

As far as I'm aware of it the below situation is extremely rare on Bitcoin mainnet and maybe something that the OP had in mind:


Sources: https://bnoc.xyz/t/two-block-reorg-at-height-941880/97?u=b10c, https://nitter.poast.org/0xB10C/status/2036118084734349542#m

I mentioned the topic I created of this extremely rare two-block stale chain leaf in my previous post here. I didn't find the time to more thoroughly analyse the time sequence of events and how Foundry USA managed to ignore ViaBTC's block on top of AntPool's one or how and why ViaBTC ignored (or didn't see timely) Foundry USA's blocks (they mined seven consecutive blocks which is a feat on its own).

[NotFuzzyWarm]

Re: the OP's topic - unlikely to happen but YES.
That said, if it happens all tx's involved just go back into mempool to be (re)confirmed a little later.

Technically the BTC protocol forces a tx to have >100 confirmations to be fully immutable and therefore spendable. One case where that comes into play is when solo mining on a pool like cksolo or mining direct to your own node: Because the coins are direct coinbase rewards sent to the lucky winners address they cannot move/spend the coins until 101 confirmations of their winning block. Considering that at an average of 10min/block that equates to just 16.8333 hours it is hardly an onerous delay.

That said, most businesses & exchanges will require just 3-5 confs before the coins being moved are considered 'spent/received' and are a valid tx because of the very great odds against a deeper reorg causing problems. Ja the receiving party technically still cannot truly consider the coins as 100% valid and move them until >100 confs, that is more of just an accounting problem vs a significant risk.