0
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?
2
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"? – Erhard Dinhobl – 2016-10-06T15:12:35.230
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. – Erhard Dinhobl – 2017-02-16T12:21:22.023
@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. – Nate Eldredge – 2017-02-16T15:55:25.227