<p>When Bob sells coffee, Alice first constructs a transaction spending one of her available inputs to an address owned by Bob. The resulting transaction gets put into a block and is given a <code>txid</code>to identify it. The <code>txid</code> is the double-SHA256 of the serialized transaction. </p>

<p>Within the transaction, there may be multiple outputs - one of these will be the output which is locked with the hash of Bob's public key. The output is referenced by its index within the transaction, called the <code>outputIndex</code>. Collectively, the <code>txid</code> and the <code>outputIndex</code> make up the <code>outPoint</code>.</p>

<p>The output which now belongs to bob is an unspent transaction output (UTXO). The bitcoin client keeps a map of all UTXOs in a memory-mapped database, so that they can efficiently be found from their <code>outPoint</code>.</p>

<p>If Bob wishes to later spend the UTXO, he creates a transaction with the input using this <code>outPoint</code> and the outputs containing a (eg P2PKH) script for where the money gets spent. He signs the transaction, and inserts the signature into the <code>scriptSig</code> for the input being spent.</p>

<p>The validator of this new transaction will look into the UTXO set to find the previous transaction where Alice paid Bob, and will extract the <code>txout</code> from it. They will validate the amount being spent, and the <code>scriptPubKey</code> will be evaluated to make sure Bob can spend it. If the transaction is valid, the new transaction outputs will be added to the UTXO set and the original transaction where Alice paid Bob will be removed from the UTXO set.</p>

<p>This makes normal operation of the bitcoin protocol efficient, but it is inefficient for querying historical data as block explorers do for example. The main reason is because the <code>txids</code> are not stored in the blockchain data, only in the UTXO set. To find a <code>txid</code> not in the UTXO set would require scanning the entire blockchain and recomputing the <code>txid</code> for each transaction until you find the one you're interested in.</p>

<p>For that reason, block explorers, or similar software, will maintain a completely separate transaction index from the blockchain archive, where they can discover any transaction based on its <code>txid</code> and find where it is located in the chain. If you are re-indexing the blockchain in such way, it is also possible to add relationships in the forward direction, so that you can find the transaction input which spent a particular output. You would need a lot of additional storage for the txids and their indices.</p>

CC BY-SA 4.0
2019-04-22T17:25:37.767Z
A stupid question, when bob output is spent and then removed from the bitcoin map of all UTXOs how can it recognize that unspent output belongs to bob? I think that the body of the scriptPubKey and the script sing that bob goes to create when it spends the transaction of alice are the same, but I'm wrong right?
vincenzopalazzo
CC BY-SA 4.0
2019-04-22T18:34:35.083Z
When Alice pays Bob, she embeds his public key hash (the pay-to address) into the `scriptPubKey` in the transaction output. When Bob later wishes to spend this money, he must digitally sign the spending transaction with the private key corresponding to this public key. He puts his public key and the digital signature into the `scriptSig` of the input. This signature can be verified by anybody that it matches the public key, and that the public key given matches the hashed one which Alice previous put in the `txout`.
Mark H
CC BY-SA 4.0
2019-04-22T18:40:32.407Z
The signature and public key from the `scriptSig` are both pushed onto the stack, then the `scriptPubKey` is evaluated with this stack. The `pubKey` is first duplicated (`OP_DUP`), then hashed (`OP_HASH160`), compared for equality against the PKH embedded in the script (`OP_EQUALVERIFY`), and finally the signature check is performed (`OP_CHECKSIG`). If the script evaluates true, it can mean only Bob was able to spend it because only he could've created the signature.
Mark H
CC BY-SA 4.0
2019-04-22T18:49:41.470Z
So to create the logical thread between output and future input you have to run the script?
vincenzopalazzo
CC BY-SA 4.0
2019-04-22T19:04:12.637Z
The link between next input and previous output is defined by the `outPoint` in the `txin`, but is verified by running the `scriptSig` of the next input followed by the `scriptPubKey` of the previous output.
Mark H
CC BY-SA 4.0
2019-04-22T11:30:51.143Z
2019-04-22T11:35:58.470Z
2019-04-22T11:35:58.470Z
Mark H
<p>Let us illustrate this using the example given in Mastering Bitcoin.</p>

<p>Joe sent 0.1 BTC to Alice in the transaction having <code>txid = 7957a35fe64f80d234d76d83a2a8f1a0d8149a41d81de548f0a65a8a999f6f18</code>. Below are the outputs of that transaction:</p>

<pre><code>vout": [
    {
        "value": 0.10000000,
        "n": 0,
        "scriptPubKey": {
            "asm": "OP_DUP OP_HASH160 7f9b1a7fb68d60c536c2fd8aeaa53a8f3cc025a8 OP_EQUALVERIFY OP_CHECKSIG",
            "hex": "76a9147f9b1a7fb68d60c536c2fd8aeaa53a8f3cc025a888ac",
            "reqSigs": 1,
            "type": "pubkeyhash",
            "addresses": [
                "1Cdid9KFAaatwczBwBttQcwXYCpvK8h7FK"
            ]
    }
]
</code></pre>

<p>When Alice spends these earnt bitcoins to Bob Cafe, she references this transaction in the input. Note that the input includes the <code>txid</code> of the transaction through which she earnt her bitcoins and the <code>n=0</code> which shows output number of that transactions that was directed to the address she controls.</p>

<pre><code>"vin": [
        {
            "txid": "7957a35fe64f80d234d76d83a2a8f1a0d8149a41d81de548f0a65a8a999f6f18",
            "vout": 0,
            "scriptSig": {
                "asm": "3045022100884d142d86652a3f47ba4746ec719bbfbd040a570b1deccbb6498c75c4ae24cb02204b9f039ff08df09cbe9f6addac960298cad530a863ea8f53982c09db8f6e3813[ALL] 0484ecc0d46f1918b30928fa0e4ed99f16a0fb4fde0735e7ade8416ab9fe423cc5412336376789d172787ec3457eee41c04f4938de5cc17b4a10fa336a8d752adf",
                "hex": "483045022100884d142d86652a3f47ba4746ec719bbfbd040a570b1deccbb6498c75c4ae24cb02204b9f039ff08df09cbe9f6addac960298cad530a863ea8f53982c09db8f6e381301410484ecc0d46f1918b30928fa0e4ed99f16a0fb4fde0735e7ade8416ab9fe423cc5412336376789d172787ec3457eee41c04f4938de5cc17b4a10fa336a8d752adf"
            },
            "sequence": 4294967295
        }
    ],
</code></pre>

<p>Full nodes maintain a UTXO set through which they can easily cross-verify this data to ensure, the <code>txid</code> and <code>n</code> referenced by Alice has not been spent previously. If Alice wanted to spend more than 0.1 BTC to Bob Cafe, she would have had to reference multiple transactions as the <code>txid</code> and <code>n</code> she referenced only has access to 0.1 BTC. </p>

CC BY-SA 4.0
2019-04-22T17:26:33.963Z
The question that comes to my answer is the same as the one I gave to the previous post, I avoid duplicating it
vincenzopalazzo
CC BY-SA 4.0
2019-04-22T11:23:42.343Z
2019-04-22T11:23:42.343Z
Ugam Kamat
<p>I'm studying the bitcoin protocol and I don't have very clear things, for example the logical thread that exists between an output transaction and a subsequent input transaction, where that output is direct.</p>

<p>I realized that the input transaction contains the reference to the output transaction through the Outpoint type, but now how could the input transaction related to the output transaction be identified?</p>

<p>an example</p>

<p>Bob sells a coffee to Alice and Alice pays in bitcoins, then bob spends his input transaction coming from the alice output transaction, Now I want to find and the two Rawtransactions where the alice transaction information and the bob information are contained for connect the two RawTransactions.
I believe that I haven't understood any important steps to do this</p>

<p>Sorry for my terrible English but I'm learning</p>

<transactions><bitcoin-core>
Logic thread between output folders and input transactions
vincenzopalazzo
# Logic thread between output folders and input transactions

(Asked by: username_0 on 2019-04-22)

I'm studying the bitcoin protocol and I don't have very clear things, for example the logical thread that exists between an output transaction and a subsequent input transaction, where that output is direct.

I realized that the input transaction contains the reference to the output transaction through the Outpoint type, but now how could the input transaction related to the output transaction be identified?

an example

Bob sells a coffee to Alice and Alice pays in bitcoins, then bob spends his input transaction coming from the alice output transaction, Now I want to find and the two Rawtransactions where the alice transaction information and the bob information are contained for connect the two RawTransactions.
I believe that I haven't understood any important steps to do this

Sorry for my terrible English but I'm learning

**Tags:** transactions, bitcoin-core


---

## 2 answers

### Answer by username_1 on 2019-04-22. Score: 1 | Accepted answer

When Bob sells coffee, Alice first constructs a transaction spending one of her available inputs to an address owned by Bob. The resulting transaction gets put into a block and is given a `txid`to identify it. The `txid` is the double-SHA256 of the serialized transaction.

Within the transaction, there may be multiple outputs - one of these will be the output which is locked with the hash of Bob's public key. The output is referenced by its index within the transaction, called the `outputIndex`. Collectively, the `txid` and the `outputIndex` make up the `outPoint`.

The output which now belongs to bob is an unspent transaction output (UTXO). The bitcoin client keeps a map of all UTXOs in a memory-mapped database, so that they can efficiently be found from their `outPoint`.

If Bob wishes to later spend the UTXO, he creates a transaction with the input using this `outPoint` and the outputs containing a (eg P2PKH) script for where the money gets spent. He signs the transaction, and inserts the signature into the `scriptSig` for the input being spent.

The validator of this new transaction will look into the UTXO set to find the previous transaction where Alice paid Bob, and will extract the `txout` from it. They will validate the amount being spent, and the `scriptPubKey` will be evaluated to make sure Bob can spend it. If the transaction is valid, the new transaction outputs will be added to the UTXO set and the original transaction where Alice paid Bob will be removed from the UTXO set.

This makes normal operation of the bitcoin protocol efficient, but it is inefficient for querying historical data as block explorers do for example. The main reason is because the `txids` are not stored in the blockchain data, only in the UTXO set. To find a `txid` not in the UTXO set would require scanning the entire blockchain and recomputing the `txid` for each transaction until you find the one you're interested in.

For that reason, block explorers, or similar software, will maintain a completely separate transaction index from the blockchain archive, where they can discover any transaction based on its `txid` and find where it is located in the chain. If you are re-indexing the blockchain in such way, it is also possible to add relationships in the forward direction, so that you can find the transaction input which spent a particular output. You would need a lot of additional storage for the txids and their indices.

> **Comments:**
> **username_0**: A stupid question, when bob output is spent and then removed from the bitcoin map of all UTXOs how can it recognize that unspent output belongs to bob? I think that the body of the scriptPubKey and the script sing that bob goes to create when it spends the transaction of alice are the same, but I'm wrong right?  
> **username_1**: When Alice pays Bob, she embeds his public key hash (the pay-to address) into the `scriptPubKey` in the transaction output. When Bob later wishes to spend this money, he must digitally sign the spending transaction with the private key corresponding to this public key. He puts his public key and the digital signature into the `scriptSig` of the input. This signature can be verified by anybody that it matches the public key, and that the public key given matches the hashed one which Alice previous put in the `txout`.  
> **username_1**: The signature and public key from the `scriptSig` are both pushed onto the stack, then the `scriptPubKey` is evaluated with this stack. The `pubKey` is first duplicated (`OP_DUP`), then hashed (`OP_HASH160`), compared for equality against the PKH embedded in the script (`OP_EQUALVERIFY`), and finally the signature check is performed (`OP_CHECKSIG`). If the script evaluates true, it can mean only Bob was able to spend it because only he could've created the signature.  
> **username_0**: So to create the logical thread between output and future input you have to run the script?  
> **username_1**: The link between next input and previous output is defined by the `outPoint` in the `txin`, but is verified by running the `scriptSig` of the next input followed by the `scriptPubKey` of the previous output.  

---

### Answer by username_2 on 2019-04-22. Score: 1

Let us illustrate this using the example given in Mastering Bitcoin.

Joe sent 0.1 BTC to Alice in the transaction having `txid = 7957a35fe64f80d234d76d83a2a8f1a0d8149a41d81de548f0a65a8a999f6f18`. Below are the outputs of that transaction:

```
vout": [
    {
        "value": 0.10000000,
        "n": 0,
        "scriptPubKey": {
            "asm": "OP_DUP OP_HASH160 7f9b1a7fb68d60c536c2fd8aeaa53a8f3cc025a8 OP_EQUALVERIFY OP_CHECKSIG",
            "hex": "76a9147f9b1a7fb68d60c536c2fd8aeaa53a8f3cc025a888ac",
            "reqSigs": 1,
            "type": "pubkeyhash",
            "addresses": [
                "1Cdid9KFAaatwczBwBttQcwXYCpvK8h7FK"
            ]
    }
]

```

When Alice spends these earnt bitcoins to Bob Cafe, she references this transaction in the input. Note that the input includes the `txid` of the transaction through which she earnt her bitcoins and the `n=0` which shows output number of that transactions that was directed to the address she controls.

```
"vin": [
        {
            "txid": "7957a35fe64f80d234d76d83a2a8f1a0d8149a41d81de548f0a65a8a999f6f18",
            "vout": 0,
            "scriptSig": {
                "asm": "3045022100884d142d86652a3f47ba4746ec719bbfbd040a570b1deccbb6498c75c4ae24cb02204b9f039ff08df09cbe9f6addac960298cad530a863ea8f53982c09db8f6e3813[ALL] 0484ecc0d46f1918b30928fa0e4ed99f16a0fb4fde0735e7ade8416ab9fe423cc5412336376789d172787ec3457eee41c04f4938de5cc17b4a10fa336a8d752adf",
                "hex": "483045022100884d142d86652a3f47ba4746ec719bbfbd040a570b1deccbb6498c75c4ae24cb02204b9f039ff08df09cbe9f6addac960298cad530a863ea8f53982c09db8f6e381301410484ecc0d46f1918b30928fa0e4ed99f16a0fb4fde0735e7ade8416ab9fe423cc5412336376789d172787ec3457eee41c04f4938de5cc17b4a10fa336a8d752adf"
            },
            "sequence": 4294967295
        }
    ],

```

Full nodes maintain a UTXO set through which they can easily cross-verify this data to ensure, the `txid` and `n` referenced by Alice has not been spent previously. If Alice wanted to spend more than 0.1 BTC to Bob Cafe, she would have had to reference multiple transactions as the `txid` and `n` she referenced only has access to 0.1 BTC.

> **Comments:**
> **username_0**: The question that comes to my answer is the same as the one I gave to the previous post, I avoid duplicating it  

---

