2

Transactions in Bitcoin network don't have the finality property -- it is never (theoretically) true that a transaction can't be reversed some time in the future. Thus whether a transaction was confirmed or not is not a binary property.

The validity of a transaction as far as full-nodes are concerned is binary. However, looking at the specification of how light-nodes verify transactions, they use the number of confirmations as a proxy for validity. Since validity in this case is a function of confirmations it appears that it has no finality either -- from the light-node's point of view it is never (theoretically) true that a transaction can't be invalidated some time in the future.

Is this correct? I know that there is a heuristic of 6 confirmations, but that is arbitrary.

Improve this question
1
  • 1
    I’m voting to close this question because it does not relate to a practical problem that someone faces but seems to be about a personal view of the fluidity of language. Commented Apr 8 at 10:41

1 Answer 1

Reset to default
0

I think validity in general is a somewhat ambiguous term. On one hand, a node verifies a transaction using a list of criteria. If all the criteria are met, the transaction is considered valid. One such criterion is: “For each input, the referenced output must exist and cannot already be spent” (Antonopoulos, Mastering Bitcoin, p. 235). So if all the inputs of the new transactions are UTXOs the criterion is checked.

At the same time, when discussing the “51% attack,” Antonopoulos notes that “The more confirmations elapse, the harder it becomes to invalidate a transaction with a 51% attack.” This implies that a transaction can be invalidated through a chain reorganization.

So, from a miner’s point of view, the validity of a transaction is a binary property. However, from the broader network’s perspective, it is probabilistic.

Improve this answer
9
  • Majority attackers can't invalidate valid txs. Commented Apr 11 at 22:14
  • @Mercedes a transaction T has X UTXO as its input; T gets mined in block B100 because it is valid (not a double-spend, etc); attacker remines from B100 using X as input to another transaction T'; because of the reorg T goes to the disconnect pool, which is then revalidated before its transactions are added to the mempool; T is a double-spend now, so it is not valid. Commented Apr 23 at 13:40
  • Majority attackers can't invalidate valid txs. Your scenario merely transforms the status of a tx. Commented Apr 24 at 14:19
  • @Mercedes and then it gets included in the next block even though its input was spent? Commented Apr 24 at 16:06
  • Possibly. One confirmation is not enough. Commented Apr 24 at 20:26

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.