I'v seen an unconfirmed transaction in the blockchain.com and one of its outputs is currently spent. How it this possible for coin to be spent before the transaction is written on the blockchain?
Add a comment
|
2 Answers
How it this possible for coin to be spent before the transaction is written on the blockchain?
It isn't possible.
The first transaction e491e326cae4fa2071ebf2c977f6f945e7cb8fe450d489d4c97a97b2a717908a sent money to 17 addresses, the fifth of those outputs was spent in another transaction 47223eccf8253a9f58f8f76cd7cb16de979978e6dff15ea661b80453cfbf32ad
However both transactions were in block 739266.
It might be that the software, that showed you that the first transaction as unconfirmed, was simply waiting for a specific number of confirmations before marking that transaction as confirmed. It might, at the same time have marked the outputs as spent if they were already present in a transaction. In other words it might be an inconsistency in the way the specific software application is configured to apply the labels "unconfirmed" and "spent".
answered Jun 4, 2022 at 17:04
-
It sounds as if you understood the question to be whether a child transaction could be confirmed before the parent is confirmed. I don't think that the asker indicated that, though. I assume that both transactions were still unconfirmed.– Murch ♦Jun 5, 2022 at 14:00
I think you're looking at a chain of unconfirmed transactions.
Since transactions are immutable¹ after they are submitted to the network, you know what transaction outputs will be created before the transaction is confirmed. As it's clear what the transaction output will look like, it can already be referenced in another transaction that spends one of these expected outputs. There is a limit to the viable length of these unconfirmed chains. Nodes on the network will only transactions that have at most 25 unconfirmed ancestors or at most a total of 101 kvB of weight across their ancestry plus themselves.
Descendant transactions can only be included in a block after their ancestors are included since the transaction outputs they're spending must exist. This means that ancestors have to either have been included in a previous block or stand earlier in the same block as the descendant. This dependency is for example leveraged when reprioritizing transactions via "child-pays-for-parent": the child has a greater fee which incentivizes the miner to include the parent so that they can include the child.
¹ The intended outcome of the transaction cannot be changed, but it's not yet certain that the transaction will be included in a block. It could also be superseded by a conflicting transaction.
