<p>A lot of what is written in the question differs from my understanding of BTC. Which is as follows:</p>
<p>In general<sup>1</sup> a transaction spends one or more &quot;coins&quot;. These spent amounts are listed as &quot;inputs&quot; in a transaction and there is also a list of &quot;outputs&quot; which are new amounts typically being placed under the control of someone else.</p>
<p>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.</p>
<p>Usually one of the outputs is a &quot;change&quot; 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.</p>
<p>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.</p>
<p>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.</p>
<p>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 &quot;change&quot;.</p>
<p>Each output has an associated locking script (&quot;scriptPubKey&quot;). Each input has an associated unlocking script (&quot;ScriptSig&quot;). 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.</p>
<p>The scripting language used has no means to explicitly refer to other transactions.</p>
<hr />
<p>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.</p>
<hr />
<p><sub>1. excluding coinbase</sub></p>

CC BY-SA 4.0
2024-02-20T10:06:31.353Z
How I understand it, you can enforce that the "UTXO" can only be signed if you submit the right script to it, and a check can be done that compares what you submit, to a hash. With this, you can enforce specific computation in the next "UTXO", and can easily implement for example a loop. I've considered Ethereum the next step after Bitcoin since 2014, but, it is still interesting to understand why some argue Bitcoin having significant capacity for "smart contracts". And I agree it loops, although it is very cumbersome, & easier to use superior machine https://wiki.bitcoinsv.io/index.php/Script
BipedalJoe
CC BY-SA 4.0
2024-02-20T11:09:24.560Z
@BipedalJoe: An unlocking script cannot affect or constrain any locking script in the same transaction or in any subsequent transaction.  No threads or loops can be formed that way.
RedGrittyBrick
CC BY-SA 4.0
2024-02-20T17:01:37.333Z
Not that into the terminology. But, the locking script, as long as it can push a constant onto the stack (OP_PUSHDATA1), and, as long as it can generate a hash of the new script in the next "UTXO" (with OP_PUSH_TX?), and then push that to the stack as well, it can compare the values with OP_EQUALVERIFY. Is there any step there that you do not agree is possible? It's also mentioned on this Wiki, https://wiki.bitcoinsv.io/index.php/Script.
BipedalJoe
CC BY-SA 4.0
2024-02-21T10:07:17.007Z
There is no OP_PUSH_TX. By the way, your link refers to BSV not BTC.
RedGrittyBrick
CC BY-SA 4.0
2024-02-21T11:58:19.103Z
"OP_PUSH_TX" is that you include the transaction pre-image in sigScript. Not an OPCODE but a technique. scriptPubKey then contains private-public key pair, and script to generate signature. and script finishes with OP_CHECKSIG.. It's described well on that Wiki and there are a few other good articles about it if you use a search engine. I mean, Ethereum was successor to Bitcoin in 2014, I am just interested in understanding the perspective of those who still argue about Bitcoin for "smart contracts".
BipedalJoe
CC BY-SA 4.0
2024-02-21T13:20:27.617Z
OK so that's a hack of OP_CHECKSIG in a UTXO locking script that can be used to constrain the outputs of the transaction that spends the UTXO. Since all the discussion is in the context of BSV I've no idea whether it can apply to BTC and I still don't know what you mean in the question by *"return the result to a "root" UTXO"* or why any of this necessarily involves third-party signatures. If I were you, I'd rewrite the question to explain in detail or move the question somewhere more technical. Sorry.
RedGrittyBrick
CC BY-SA 4.0
2024-02-21T13:49:21.150Z
While Ethereum was clearly successor to Bitcoin back in 2014, I'm interested in understanding the perspective of those who for some reason think it is still impressive that Bitcoin can do script. Instead of just dismissing claims I've heard, I verify them. Such as the claim "it can loop", and well, technically, although very overcomplicated, it seems like it can. And I was interested in the claim that seemed to suggest you could return thread results somehow. I mention in the question that I'm no expert on the terminology, I think it can be understood as it is.
BipedalJoe
CC BY-SA 4.0
2024-02-17T10:52:13.250Z
2024-02-17T11:23:33.470Z
2024-02-17T11:23:33.470Z
RedGrittyBrick
<p>No expert on Bitcoin. How I understand it, loops can be done by UTXO storing a hash of the code it requires to run the next iteration in, and then the next iteration creates a new UTXO and runs it there. And this works for indefinitely long loops as long as someone pays for each step. I assume it can be programmed so that anyone can sign each step (thus removing reliance on certain third parties).</p>
<p>What I'm interested in, is if there is a way to return the result to a &quot;root&quot; UTXO, in a way where it can be authorized that it came from a &quot;thread&quot; that originated from the root, without relying on a trusted third party to sign the callback. I cannot think of a way to do so. This then in analogy to what I described before, the thread itself being able to churn along without specific third parties signing things.</p>

CC BY-SA 4.0
2024-02-20T16:44:53.470Z
Hi Johan, I’m having a hard time trying to figure out what your question is. Are you asking how output scripts are evaluated?
Murch
CC BY-SA 4.0
2024-02-21T14:46:55.387Z
@Murch Hi, guest account. I'm trying to understand a few claims I've heard. I was able to understand the "it actually can loop" claim, as that is based on technique described here, https://xiaohuiliu.medium.com/op-push-tx-3d3d279174c1. A related claim I've heard, is about callbacks and, as I describe in the question, multiple threads returning the "winning" value. Could not see exactly how that would be done, so asked here if there was expert who knew.
BipedalJoe
CC BY-SA 4.0
2024-02-21T15:16:34.717Z
This blog post does not appear to be rooted in reality, there is no way to build a signature hash as described in the context of the input script validation.
Murch
CC BY-SA 4.0
2024-02-22T05:29:07.643Z
Well, I'm no expert, but I have an OK understanding of basic computer engineering. And implementing elliptic curve signature in some arbitrary instruction set should be pretty easy. I've skimmed Bitcoin script (said to be Forth like, and have also looked briefly at Forth), and it seems to have a lot of the normal instructions. Bitwise and arithmetic. If you are convinced it is impossible (as in not reality) to run signature script in Bitcoin, do you know what the constraint is? Is it script size limit? Or is there an instruction you miss?
BipedalJoe
<script>
Callback from computation threads to root UTXO without trusted third party signature
Johan
# Callback from computation threads to root UTXO without trusted third party signature

(Asked by: username_0 on 2024-02-17)

No expert on Bitcoin. How I understand it, loops can be done by UTXO storing a hash of the code it requires to run the next iteration in, and then the next iteration creates a new UTXO and runs it there. And this works for indefinitely long loops as long as someone pays for each step. I assume it can be programmed so that anyone can sign each step (thus removing reliance on certain third parties).

What I'm interested in, is if there is a way to return the result to a "root" UTXO, in a way where it can be authorized that it came from a "thread" that originated from the root, without relying on a trusted third party to sign the callback. I cannot think of a way to do so. This then in analogy to what I described before, the thread itself being able to churn along without specific third parties signing things.

**Tags:** script

> **Comments:**
> **username_1**: Hi username_0, I’m having a hard time trying to figure out what your question is. Are you asking how output scripts are evaluated?  
> **username_2**: @username_1 Hi, guest account. I'm trying to understand a few claims I've heard. I was able to understand the "it actually can loop" claim, as that is based on technique described here, https://xiaohuiliu.medium.com/op-push-tx-3d3d279174c1. A related claim I've heard, is about callbacks and, as I describe in the question, multiple threads returning the "winning" value. Could not see exactly how that would be done, so asked here if there was expert who knew.  
> **username_1**: This blog post does not appear to be rooted in reality, there is no way to build a signature hash as described in the context of the input script validation.  
> **username_2**: Well, I'm no expert, but I have an OK understanding of basic computer engineering. And implementing elliptic curve signature in some arbitrary instruction set should be pretty easy. I've skimmed Bitcoin script (said to be Forth like, and have also looked briefly at Forth), and it seems to have a lot of the normal instructions. Bitwise and arithmetic. If you are convinced it is impossible (as in not reality) to run signature script in Bitcoin, do you know what the constraint is? Is it script size limit? Or is there an instruction you miss?  

---

## 1 answers

### Answer by username_3 on 2024-02-17. Score: 1

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

> **Comments:**
> **username_2**: How I understand it, you can enforce that the "UTXO" can only be signed if you submit the right script to it, and a check can be done that compares what you submit, to a hash. With this, you can enforce specific computation in the next "UTXO", and can easily implement for example a loop. I've considered Ethereum the next step after Bitcoin since 2014, but, it is still interesting to understand why some argue Bitcoin having significant capacity for "smart contracts". And I agree it loops, although it is very cumbersome, & easier to use superior machine https://wiki.bitcoinsv.io/index.php/Script  
> **username_3**: @username_2: An unlocking script cannot affect or constrain any locking script in the same transaction or in any subsequent transaction.  No threads or loops can be formed that way.  
> **username_2**: Not that into the terminology. But, the locking script, as long as it can push a constant onto the stack (OP_PUSHDATA1), and, as long as it can generate a hash of the new script in the next "UTXO" (with OP_PUSH_TX?), and then push that to the stack as well, it can compare the values with OP_EQUALVERIFY. Is there any step there that you do not agree is possible? It's also mentioned on this Wiki, https://wiki.bitcoinsv.io/index.php/Script.  
> **username_3**: There is no OP_PUSH_TX. By the way, your link refers to BSV not BTC.  
> **username_2**: "OP_PUSH_TX" is that you include the transaction pre-image in sigScript. Not an OPCODE but a technique. scriptPubKey then contains private-public key pair, and script to generate signature. and script finishes with OP_CHECKSIG.. It's described well on that Wiki and there are a few other good articles about it if you use a search engine. I mean, Ethereum was successor to Bitcoin in 2014, I am just interested in understanding the perspective of those who still argue about Bitcoin for "smart contracts".  
> **username_3**: OK so that's a hack of OP_CHECKSIG in a UTXO locking script that can be used to constrain the outputs of the transaction that spends the UTXO. Since all the discussion is in the context of BSV I've no idea whether it can apply to BTC and I still don't know what you mean in the question by *"return the result to a "root" UTXO"* or why any of this necessarily involves third-party signatures. If I were you, I'd rewrite the question to explain in detail or move the question somewhere more technical. Sorry.  
> **username_2**: While Ethereum was clearly successor to Bitcoin back in 2014, I'm interested in understanding the perspective of those who for some reason think it is still impressive that Bitcoin can do script. Instead of just dismissing claims I've heard, I verify them. Such as the claim "it can loop", and well, technically, although very overcomplicated, it seems like it can. And I was interested in the claim that seemed to suggest you could return thread results somehow. I mention in the question that I'm no expert on the terminology, I think it can be understood as it is.  

---

