<p>There are no such things as "in-addresses" or "from addresses", and this has nothing to do with merkle trees, or even blocks.</p>

<p>Bitcoin works by transactions creating outputs and other transactions spending from previous transaction outputs. Each output has an associated value. When you spend Bitcoin, you are spending from previous transaction outputs. Your transaction will include a reference to the output that it is spending: the txid and the index of the output. Since all transactions (except coinbase transactions - the coin generation transaction, not the company) spend from a previous transaction output, the transactions are all chained together. You can walk backwards through this chain of transactions to check that the values of all the transactions are correct.</p>

<p>So when a node receives your transaction, it looks up the outputs that your transaction is spending from and makes sure that no other transaction has spent those outputs already. Then it sums the values of the outputs being spent and makes sure that that sum is greater than or equal to the sum of the values of the outputs being created.</p>

CC BY-SA 3.0
2017-07-05T06:24:02.757Z
Thanks for your answer.. Can you explain how this is done efficiently : `and makes sure that no other transaction has spent those outputs already. ` ?
Ashish Negi
CC BY-SA 3.0
2017-07-05T06:26:31.353Z
And how does it find the bitcoin-value in previous transaction outputs (i think this is what is called in-addresses) ?  Is it encoded in address itself ? (i doubt..)
Ashish Negi
CC BY-SA 3.0
2017-07-05T06:46:05.340Z
The value is in the transaction output itself.
Ava Chow
CC BY-SA 3.0
2017-07-05T06:48:41.157Z
To ensure that no other transaction has spent the outputs spent by a transaction, the node maintains a list of all unspent transaction outputs. It updates this list as it receives new transactions, adding outputs that were created and removing ones that were spent. It can efficiently see if an output was already spent by checking if it is in the list. If it is, the output has not been spent. If it is not, then it has been spent or the transaction does not exist.
Ava Chow
CC BY-SA 3.0
2017-07-05T07:50:39.453Z
I guess it will be a hash-set .. just to be precise as this question is about efficiently finding the information.
Ashish Negi
CC BY-SA 3.0
2017-07-05T17:15:43.040Z
In Bitcoin Core it is called the UTXO set, and stored as a LevelDB database (which is internally several overlapping sorted lists), and cached aggressively in RAM in a hashtable.
Pieter Wuille
CC BY-SA 3.0
2017-07-04T17:46:15.190Z
2017-07-04T17:46:15.190Z
Ava Chow
<p>A transaction has in-bitcoin address. Transaction tells to transfer that address (in fraction or whole) to another address. Since the source of truth is block-chain, how does miner know that in-bitcoin address has said amount of data ? And how does miner check it efficiently ?</p>

<p>I have read about Merkel trees. My understanding is that they help to find whether a transaction is present in specific order in a block. But a block chain will have many blocks. So, how is it done efficiently by miners ?</p>

<p>Will not creating a hashmap from bitcoin-address to amount will be easier ?</p>

<transactions><merkle-tree>
How to efficiently find if in-address in transaction is valid and has required amount of data?
Ashish Negi
# How to efficiently find if in-address in transaction is valid and has required amount of data?

(Asked by: username_0 on 2017-07-04)

A transaction has in-bitcoin address. Transaction tells to transfer that address (in fraction or whole) to another address. Since the source of truth is block-chain, how does miner know that in-bitcoin address has said amount of data ? And how does miner check it efficiently ?

I have read about Merkel trees. My understanding is that they help to find whether a transaction is present in specific order in a block. But a block chain will have many blocks. So, how is it done efficiently by miners ?

Will not creating a hashmap from bitcoin-address to amount will be easier ?

**Tags:** transactions, merkle-tree


---

## 1 answers

### Answer by username_1 on 2017-07-04. Score: 1

There are no such things as "in-addresses" or "from addresses", and this has nothing to do with merkle trees, or even blocks.

Bitcoin works by transactions creating outputs and other transactions spending from previous transaction outputs. Each output has an associated value. When you spend Bitcoin, you are spending from previous transaction outputs. Your transaction will include a reference to the output that it is spending: the txid and the index of the output. Since all transactions (except coinbase transactions - the coin generation transaction, not the company) spend from a previous transaction output, the transactions are all chained together. You can walk backwards through this chain of transactions to check that the values of all the transactions are correct.

So when a node receives your transaction, it looks up the outputs that your transaction is spending from and makes sure that no other transaction has spent those outputs already. Then it sums the values of the outputs being spent and makes sure that that sum is greater than or equal to the sum of the values of the outputs being created.

> **Comments:**
> **username_0**: Thanks for your answer.. Can you explain how this is done efficiently : `and makes sure that no other transaction has spent those outputs already. ` ?  
> **username_0**: And how does it find the bitcoin-value in previous transaction outputs (i think this is what is called in-addresses) ?  Is it encoded in address itself ? (i doubt..)  
> **username_1**: The value is in the transaction output itself.  
> **username_1**: To ensure that no other transaction has spent the outputs spent by a transaction, the node maintains a list of all unspent transaction outputs. It updates this list as it receives new transactions, adding outputs that were created and removing ones that were spent. It can efficiently see if an output was already spent by checking if it is in the list. If it is, the output has not been spent. If it is not, then it has been spent or the transaction does not exist.  
> **username_0**: I guess it will be a hash-set .. just to be precise as this question is about efficiently finding the information.  
> **username_2**: In Bitcoin Core it is called the UTXO set, and stored as a LevelDB database (which is internally several overlapping sorted lists), and cached aggressively in RAM in a hashtable.  

---

