Think about a bitcoin transaction:

Inputs: Address1: 2 BTC, Address2: 1 BTC

Output: Address3: 3 BTC

So the value of Address1 is because of two previous transactions where every one of those 2 transactions sent 1 BTC to Address1. How is a full node now be able to verify that the amount of "2" is correct for the transaction?

1 Answer 1


Transactions don't work like that, so this issue does not arise.

Inputs of a transaction don't specify addresses, they specify previous transactions; more precisely, a particular output from a previous transaction. The data included in an input is a transaction ID and an output index.

So in the example you cite, the transaction would have to have three inputs: one for each of the two Address1 transctions, and a third for the Address2 transaction.

  • Ok, so we can get a step forward. Think about the transaction X with value 2. The input references a transaction and we actually do not know in which block the referenced transaction is. How to prove that value of "2"? Oct 6, 2016 at 15:12
  • Edleredge: I know how transactions work, but you did not get my question. Some guys only want to get attention with the minimum amount of time spending in the answer. Feb 16, 2017 at 12:21
  • @ErhardDinhobl: Sorry I missed your previous comment. We have to actually find the referenced transaction in a block (or in the memory pool). This can be done very efficiently by a standard full node because it creates an index of all validated transactions, mapping a txid hash to the block, and offset within the block, where the transaction itself can be found. Feb 16, 2017 at 15:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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