<p>Transactions don't work like that, so this issue does not arise.</p>

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

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

CC BY-SA 3.0
2016-10-06T15:12:35.230Z
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
CC BY-SA 3.0
2017-02-16T12:21:22.023Z
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
CC BY-SA 3.0
2017-02-16T15:55:25.227Z
@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
CC BY-SA 3.0
2016-10-06T13:55:14.883Z
2016-10-06T13:55:14.883Z
Nate Eldredge
<p>Think about a bitcoin transaction:</p>

<p>Inputs: Address1: 2 BTC, Address2: 1 BTC</p>

<p>Output: Address3: 3 BTC</p>

<p>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?</p>

<transactions><address><transaction-verification>
Verify value of input address
Erhard Dinhobl
# Verify value of input address

(Asked by: username_0 on 2016-10-06)

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?

**Tags:** transactions, address, transaction-verification


---

## 1 answers

### Answer by username_1 on 2016-10-06. Score: 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.

> **Comments:**
> **username_0**: 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"?  
> **username_0**: 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.  
> **username_1**: @username_0: 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.  

---

