<blockquote>
<p>Are these scripts agreed upon by all the clients? i.e There is a known catalogue of scripts that will be supported?</p>
</blockquote>
<p>An individual (wallet or script constructor) defines the script that the funds are sent to or locked up by. This individual can decide unilaterally what that script is with two constraints: they use opcodes or script building blocks that are recognized by the rest of the network (consensus rules, you can't redefine these on the fly) and if they want the recipient's wallet to recognize it as an incoming transaction the recipient needs to be able to spend from it. For example, a merchant is not going to hand over a good or service unless the funds have been sent to a script that they can spend from.</p>
<blockquote>
<p>If #1 is true, then this seems to be more for future proofing or for independent networks trying to solve a custom problem.</p>
</blockquote>
<p>It is certainly true that some sidechains and altcoins have different consensus rules to Bitcoin. If you need access to a different set of consensus rules to Bitcoin's these may present a solution. Bitcoin's consensus rules (e.g. script building blocks) can only change with a network soft fork (or hard fork) that generally happen infrequently.</p>

CC BY-SA 4.0
2021-08-10T14:07:43.247Z
Understood. My takeaway here:

"if they want the recipient's wallet to recognize it as an incoming transaction the recipient needs to be able to spend from it "  --> There will be validations happening on the script as part of consensus.

Will that be right thing to say?
Praneeth Reddy
CC BY-SA 4.0
2021-08-10T14:17:03.187Z
No the recipient's wallet software will determine whether they can spend from the script (that the funds were sent to) and hence whether to increase their effective wallet balance by that amount. Then when the recipient comes to spend those funds the network consensus rules will determine whether the recipient successfully unlocked those funds to spend them. The recipient's wallet cares whether a specific recipient has control over funds, the network consensus rules don't care. The consensus rules just care that spending rules are followed.
Michael Folkson
CC BY-SA 4.0
2021-08-10T11:50:22.890Z
2021-08-10T11:50:22.890Z
Michael Folkson
<blockquote>
<p>What if a bad client decided to add a script that never lets the owner to claim the UTXO?</p>
</blockquote>
<p>A UTXO script is defined by whoever previously owned the money. If they want to make the funds be unspendable, unreasonable, or implausible to recover, so be it. There's no reason or method for preventing that from happening.</p>
<blockquote>
<p>Are these scripts agreed upon by all the clients?</p>
</blockquote>
<p>No.</p>
<blockquote>
<p>There is a known catalogue of scripts that will be supported?</p>
</blockquote>
<p>No.</p>

CC BY-SA 4.0
2021-08-10T14:01:29.160Z
Assume if A is sending 1 BTC to B. Now, if A is adding a script that makes that 1 BTC unspendable  by B (If the the script always return false, B might never be able to claim that UTXO, but the transaction might still be confirmed.) Wouldn't that be like B receiving nothing ? 

Am I missing something here?
Praneeth Reddy
CC BY-SA 4.0
2021-08-10T14:08:05.373Z
You have the flow around the wrong way. B produces the script, A has nothing to do with the process other than paying to that script. If B decides to add other restrictions to the script, they have no longer paid A at all.
Claris
CC BY-SA 4.0
2021-08-10T10:36:00.600Z
2021-08-10T10:36:00.600Z
Claris
<p>Novice here trying to understand blockchain and transactions.</p>
<p>I was reading about the scripts to verify the ownership of UTXO and understand that, this script actually can be client-defined. What if a bad client decided to add a script that never lets the owner to  claim the UTXO? Something which just would always return false (OP_RETURN, maybe?)</p>
<p>My questions are:</p>
<ol>
<li><p>Are these scripts agreed upon by all the clients? i.e There is a known catalogue of scripts that will be supported?</p>
</li>
<li><p>If #1 is true, then this seems to be more for future proofing or for independent networks trying to solve a custom problem.</p>
</li>
</ol>
<p>Are above statements true?</p>
<p>Thanks in advance.</p>

<client><script>
How can blockchain prevent bad transaction script
Praneeth Reddy
# How can blockchain prevent bad transaction script

(Asked by: username_0 on 2021-08-10)

Novice here trying to understand blockchain and transactions.

I was reading about the scripts to verify the ownership of UTXO and understand that, this script actually can be client-defined. What if a bad client decided to add a script that never lets the owner to claim the UTXO? Something which just would always return false (OP\_RETURN, maybe?)

My questions are:

1. Are these scripts agreed upon by all the clients? i.e There is a known catalogue of scripts that will be supported?
2. If #1 is true, then this seems to be more for future proofing or for independent networks trying to solve a custom problem.

Are above statements true?

Thanks in advance.

**Tags:** client, script


---

## 2 answers

### Answer by username_1 on 2021-08-10. Score: 0 | Accepted answer

> Are these scripts agreed upon by all the clients? i.e There is a known catalogue of scripts that will be supported?

An individual (wallet or script constructor) defines the script that the funds are sent to or locked up by. This individual can decide unilaterally what that script is with two constraints: they use opcodes or script building blocks that are recognized by the rest of the network (consensus rules, you can't redefine these on the fly) and if they want the recipient's wallet to recognize it as an incoming transaction the recipient needs to be able to spend from it. For example, a merchant is not going to hand over a good or service unless the funds have been sent to a script that they can spend from.

> If #1 is true, then this seems to be more for future proofing or for independent networks trying to solve a custom problem.

It is certainly true that some sidechains and altcoins have different consensus rules to Bitcoin. If you need access to a different set of consensus rules to Bitcoin's these may present a solution. Bitcoin's consensus rules (e.g. script building blocks) can only change with a network soft fork (or hard fork) that generally happen infrequently.

> **Comments:**
> **username_0**: Understood. My takeaway here:  "if they want the recipient's wallet to recognize it as an incoming transaction the recipient needs to be able to spend from it "  --> There will be validations happening on the script as part of consensus.  Will that be right thing to say?  
> **username_1**: No the recipient's wallet software will determine whether they can spend from the script (that the funds were sent to) and hence whether to increase their effective wallet balance by that amount. Then when the recipient comes to spend those funds the network consensus rules will determine whether the recipient successfully unlocked those funds to spend them. The recipient's wallet cares whether a specific recipient has control over funds, the network consensus rules don't care. The consensus rules just care that spending rules are followed.  

---

### Answer by username_2 on 2021-08-10. Score: 1

> What if a bad client decided to add a script that never lets the owner to claim the UTXO?

A UTXO script is defined by whoever previously owned the money. If they want to make the funds be unspendable, unreasonable, or implausible to recover, so be it. There's no reason or method for preventing that from happening.

> Are these scripts agreed upon by all the clients?

No.

> There is a known catalogue of scripts that will be supported?

No.

> **Comments:**
> **username_0**: Assume if A is sending 1 BTC to B. Now, if A is adding a script that makes that 1 BTC unspendable  by B (If the the script always return false, B might never be able to claim that UTXO, but the transaction might still be confirmed.) Wouldn't that be like B receiving nothing ?   Am I missing something here?  
> **username_2**: You have the flow around the wrong way. B produces the script, A has nothing to do with the process other than paying to that script. If B decides to add other restrictions to the script, they have no longer paid A at all.  

---

