1

I have seen transactions on a block explorer where the transaction is in mempool (unconfirmed) but one of the outputs already appears as spent, I am curious how this works. This question is a duplicate of this question, but the answer there doesn't quite satisfy my confusion. I am thinking about how this process is permissible in conjunction with the protocol rules for 'tx' messages listed here, particularly rule 9, 10, 12.

  1. For each input, if the referenced output exists in any other tx in the pool, reject this transaction.

  2. For each input, look in the main branch and the transaction pool to find the referenced output transaction. If the output transaction is missing for any input, this will be an orphan transaction. Add to the orphan transactions, if a matching transaction is not in there already.

  1. For each input, if the referenced output does not exist (e.g. never existed or has already been spent), reject this transaction

Questions:

  1. Part of what might be causing confusion is the definition of "spent" on the block explorer - when it claims an output is spent does this equate to "there exists a transaction at least in mempool that uses the output as an input"?
  2. The ability to broadcast a tx message that uses the output of an unconfirmed tx as an input seems to explicitly violate rule 9. Does it not?
  3. Rule 9 & 10 seem to be at odds with each other. Rule 9 says to reject if the output is in a tx in mempool, rule 10 says to check mempool for the output (as though it is permissible). Are they not?
  4. It is my belief that full nodes keep a "UTXO" set for validating some of these criterium - is the UTXO set updated once a transaction hits mempool (i.e not waiting for a confirmation)?
  5. Is mempool relative to one node? I.e, if I broadcast a transaction and a node accepts it as valid does it then pass the transaction around so that other nodes can add it to "their" mempool, or is there somehow a "central mempool" that any validated transaction can get sent to.
  6. Is it possible to cancel a tx message that has been added to mempool? I am not asking if typical software has this feature - but is it theoretically possible for a power user or is it "permissible behavior" within the bitcoin protocol.
1

There is no rule requiring a transaction to have a confirmation before being spent.

  1. Yes, the mempool matters. That's also how double-spends are detected. So it's crucial nodes check the mempool and not just previous blocks.
  2. No it does not violate the rule, they are referring to double-spends being rejected if the SAME output exists in the mempool.
  3. IDK, maybe ask the original poster what they meant?
  4. Yes, no need for any confirmations to become an unspent transaction output.
  5. Mempools from node-to-node are not always identical. For example, some nodes have different minimum relay rules that may include extremely low fee transactions. There is no central mempool.
  6. Not really. I haven't done it recently but lets say you broadcast a transaction with a 0 fee. The transaction would likely get stuck in the mempool and not get confirmed. After 14 days if it doesn't get included in a block it "expires". Once expired/dropped I could craft a new transaction using the same UTXOs that I used in the original.

Here's a related question that you will probably find interesting:
What happens to transactions in the mempool when their parent transaction expires?

3
  • Thanks, and also thanks for the link. I thought I did my research before posting but I didn't find that one. So when block explorers show the size of mempool what are they showing? Just the mempool relative to the full node they are running, which is presumed to be a good representative for total mempool? – Prince M Mar 30 at 3:25
  • Although I'm making an assumption it's extremely likely they are showing the mempool of their own node(s). – m1xolyd1an Mar 30 at 3:31
  • Thanks, assumptions are fine for that question. – Prince M Mar 30 at 3:32
0

Point 9 means: In a mempool , if there are two transactions having input that refer to same output, then reject the transaction that arrived later. Technically, every node checks this condition before adding the transaction in mempool. This prevents Double Spending.

Point 10 simply node stores that transaction whose input refers to the output of unconfirmed transaction (i.e, present inside the pool). If the node cannot find the parent transaction, then the current transaction is stored in orphaned transaction's pool.

Point 12 is same as point 9 except in this step the node searches the previous block to reject this transaction in case of double check.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.