script – Callback from computation threads to root UTXO without trusted third party signature


A lot of what is written in the question differs from my understanding of BTC. Which is as follows:

In general1 a transaction spends one or more “coins”. These spent amounts are listed as “inputs” in a transaction and there is also a list of “outputs” which are new amounts typically being placed under the control of someone else.

Each of the inputs are just a reference to an output of a previous transaction in which the current sender received money. The reference is the Transaction-ID of the previous transaction plus the index number (0,1,…) of one of the outputs in that transaction.

Usually one of the outputs is a “change” output returning excess to the sender. Just as when you buy a $4 coffee using a $10 note, you get $6 back in change. You cant spend part of a $10 note, you have to hand over the whole note and expect to receive change back.

A transaction output is often abbreviated TXO. A TXO that has never been referenced by an input of a later confirmed transaction is an Unspent TXO or UTXO. This is what people mean by a coin.

A UTXO that is referenced by an input of a confirmed transaction is no longer unspent and so is now a TXO not a UTXO. The UTXO was destroyed by being used as an input. A TXO cannot be referred to by an input of another transaction. Only UTXOs can be used. A UTXO can only be used once.

The lists of inputs and outputs in a transaction are separate, there is no link between any individual input to an individual output. It is often not possible to say which inputs fed which outputs. It is often not possible to determine which output, if any, represents “change”.

Each output has an associated locking script (“scriptPubKey”). Each input has an associated unlocking script (“ScriptSig”). If the unlocking script is executed it leaves a stack of data values. If the locking script from the referenced prior transaction’s output is then executed, it typically uses the stack data and computes a true/false result. If true the transaction is valid, if false the transaction is invalid and discarded. This way the unlocking script proved the spender has the right to spend, and thereby destroy, these particular UTXOs.

The scripting language used has no means to explicitly refer to other transactions.


From the above, it should be apparent there can be no threads or loops of the sort suggested by the question. At least not in the standard process as I understand it.


1. excluding coinbase

Leave a Reply

Your email address will not be published. Required fields are marked *

Back To Top