<p>The reason you have to explicitly state which previous outputs should be claimed by a transaction is simply that you do not want to give users on the network a blank cheque. Say you wanted to transfer 1 bitcoin to from any output available to address A to address B. You would then create a transaction that looks like this:</p>

<pre><code>amount=1|to=B|sign(amount=1|to=B, sign_with=A)
</code></pre>

<p>This transaction would be broadcast to the network and result in the desired result. The main problem is that if you have more than the 1 bitcoin you'd like to spend, there is nothing to prevent the owner of address B to create more transactions that give him all of your bitcoins.</p>

<p>The second problem arises with the change from that transaction, if you do not have outputs that sum exactly to 1 bitcoin, you implicitly create a new output for the change. This brings us to the last problem: picking outputs to spend may not always produce the same outcome. If there are multiple combinations that the new output to B can be constructed then nodes in the network would have to agree on which outputs to spend, which again would require transaction IDs.</p>

<p>Having the owner of the coins specify which ones to spend simplifies all these problems.</p>

CC BY-SA 4.0
2018-06-09T18:07:33.987Z
One way to prevent creation of more transactions would be to add a constraint for unique [source address + tx signature] to blockchain transactions
Thomas C. G. de Vilhena
CC BY-SA 4.0
2018-06-10T13:32:23.130Z
That would create a trivial way to DoS the system...
cdecker
CC BY-SA 3.0
2013-09-25T10:05:24.307Z
2013-09-25T10:05:24.307Z
cdecker
<p>Is it not possible for users to simply sign "send transaction" messages into the blockchain with a value field and an address field, and have the validators do the work of looking through the blockchain and adding up all of the send transactions to validate that the coins actually exist? I am hypothetically assuming coinbase transactions still exist and simply list outputs to recipient addresses, thus crediting these addresses with new coins.</p>

<p>Is a transaction id simply a tool to help achieve scalability? Why do transactions have to reference previous inputs? </p>

CC BY-SA 3.0
2013-09-25T16:44:07.550Z
Related: Ultimate blockchain compression w/ trust-free lite nodes - http://bitcointalk.org/index.php?topic=88208.0 and http://bitcointalk.org/index.php?topic=204283.0
Stephen Gornick
<transactions><blockchain><scalability>
Is the process of indexing transactions by assigning a transaction id necessary, or is it a scalability issue?
bvpx
# Is the process of indexing transactions by assigning a transaction id necessary, or is it a scalability issue?

(Asked by: username_0 on 2013-09-23)

Is it not possible for users to simply sign "send transaction" messages into the blockchain with a value field and an address field, and have the validators do the work of looking through the blockchain and adding up all of the send transactions to validate that the coins actually exist? I am hypothetically assuming coinbase transactions still exist and simply list outputs to recipient addresses, thus crediting these addresses with new coins.

Is a transaction id simply a tool to help achieve scalability? Why do transactions have to reference previous inputs?

**Tags:** transactions, blockchain, scalability

> **Comments:**
> **username_1**: Related: Ultimate blockchain compression w/ trust-free lite nodes - http://bitcointalk.org/index.php?topic=88208.0 and http://bitcointalk.org/index.php?topic=204283.0  

---

## 1 answers

### Answer by username_2 on 2013-09-25. Score: 3 | Accepted answer

The reason you have to explicitly state which previous outputs should be claimed by a transaction is simply that you do not want to give users on the network a blank cheque. Say you wanted to transfer 1 bitcoin to from any output available to address A to address B. You would then create a transaction that looks like this:

```
amount=1|to=B|sign(amount=1|to=B, sign_with=A)

```

This transaction would be broadcast to the network and result in the desired result. The main problem is that if you have more than the 1 bitcoin you'd like to spend, there is nothing to prevent the owner of address B to create more transactions that give him all of your bitcoins.

The second problem arises with the change from that transaction, if you do not have outputs that sum exactly to 1 bitcoin, you implicitly create a new output for the change. This brings us to the last problem: picking outputs to spend may not always produce the same outcome. If there are multiple combinations that the new output to B can be constructed then nodes in the network would have to agree on which outputs to spend, which again would require transaction IDs.

Having the owner of the coins specify which ones to spend simplifies all these problems.

> **Comments:**
> **username_3**: One way to prevent creation of more transactions would be to add a constraint for unique [source address + tx signature] to blockchain transactions  
> **username_2**: That would create a trivial way to DoS the system...  

---

