Logic thread between output folders and input transactions

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

vincenzopalazzo

Posted 2019-04-22T10:36:21.533

Reputation: 572

Answers

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 txidto 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.

Mark H

Posted 2019-04-22T10:36:21.533

Reputation: 2 038

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 – 2019-04-22T17:25:37.767

1When 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 – 2019-04-22T18:34:35.083

1The 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 – 2019-04-22T18:40:32.407

So to create the logical thread between output and future input you have to run the script? – vincenzopalazzo – 2019-04-22T18:49:41.470

1The 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 – 2019-04-22T19:04:12.637

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.

Ugam Kamat

Posted 2019-04-22T10:36:21.533

Reputation: 5 180

The question that comes to my answer is the same as the one I gave to the previous post, I avoid duplicating it – vincenzopalazzo – 2019-04-22T17:26:33.963