<p>There is no way to enforce a rule regarding the nature of an output when an input is spent. You will have to enforce this off chain in some manner, perhaps through multisig schemes where one key is held by a rule engine that will only sign the tx if your requirements are met.</p>

CC BY-SA 4.0
2019-03-30T00:22:31.920Z
Is that what, "Incentivized finding of hash collisions" is ?https://en.bitcoin.it/wiki/Script
nick carraway
CC BY-SA 4.0
2019-03-30T00:28:10.967Z
No, that is a bounty people can claim if they are able to produce two values that hash to the same hash for some hash function in the script. For example, the [bounty for sha1](https://www.reddit.com/r/Bitcoin/comments/5vqd6k/sha1_collision_bounty_has_been_claimed/) was claimed after Google released a collision attack
Raghav Sood
CC BY-SA 4.0
2019-03-30T00:28:50.563Z
The coins can still be sent anywhere, there is no restriction on the destination
Raghav Sood
CC BY-SA 4.0
2019-03-30T01:42:18.600Z
Thanks. I have found the best explanation: http://learnmeabitcoin.com/glossary/script
nick carraway
CC BY-SA 4.0
2019-03-30T08:06:36.103Z
Just wondering. Can't the user create a SIGHASH_ALL | ANYONECANPAY transaction consuming a M BTC input from UTXO, paying X BTC to address Y and M BTC to his own change address.
Ugam Kamat
CC BY-SA 4.0
2019-03-30T08:26:48.993Z
@UgamKamat That would on the condition that the final transaction incorporates that exact signed input. It does not allow you to set the condition from within a Bitcoin Script itself, and it does not prevent someone who has the key for that utxo M from sending it to any other address by simply signing a new tx input.
Raghav Sood
CC BY-SA 4.0
2019-03-30T14:04:30.927Z
This would be detrimental to the system, as it could effectively limit the supply of bitcoins making some bitcoins more valuable than others
Vinnie James
CC BY-SA 4.0
2019-03-30T00:16:33.447Z
2019-03-30T00:16:33.447Z
Raghav Sood
<p>Is there any way to add an opcode to a UTXO that prevents how the coins are spent?</p>

<p>For example, in order to to spend the output, a person must send X number of bitcoin to Y address within the accompanying transaction.</p>

<script><op-return>
In the bitcoin scripting language, how can I access other outputs of the transaction? Or how else can I limit how the coins may be spent?
nick carraway
# In the bitcoin scripting language, how can I access other outputs of the transaction? Or how else can I limit how the coins may be spent?

(Asked by: username_0 on 2019-03-30)

Is there any way to add an opcode to a UTXO that prevents how the coins are spent?

For example, in order to to spend the output, a person must send X number of bitcoin to Y address within the accompanying transaction.

**Tags:** script, op-return


---

## 1 answers

### Answer by username_1 on 2019-03-30. Score: 4 | Accepted answer

There is no way to enforce a rule regarding the nature of an output when an input is spent. You will have to enforce this off chain in some manner, perhaps through multisig schemes where one key is held by a rule engine that will only sign the tx if your requirements are met.

> **Comments:**
> **username_0**: Is that what, "Incentivized finding of hash collisions" is ?https://en.bitcoin.it/wiki/Script  
> **username_1**: No, that is a bounty people can claim if they are able to produce two values that hash to the same hash for some hash function in the script. For example, the [bounty for sha1](https://www.reddit.com/r/Bitcoin/comments/5vqd6k/sha1_collision_bounty_has_been_claimed/) was claimed after Google released a collision attack  
> **username_1**: The coins can still be sent anywhere, there is no restriction on the destination  
> **username_0**: Thanks. I have found the best explanation: http://learnmeabitcoin.com/glossary/script  
> **username_2**: Just wondering. Can't the user create a SIGHASH_ALL | ANYONECANPAY transaction consuming a M BTC input from UTXO, paying X BTC to address Y and M BTC to his own change address.  
> **username_1**: @username_2 That would on the condition that the final transaction incorporates that exact signed input. It does not allow you to set the condition from within a Bitcoin Script itself, and it does not prevent someone who has the key for that utxo M from sending it to any other address by simply signing a new tx input.  
> **username_3**: This would be detrimental to the system, as it could effectively limit the supply of bitcoins making some bitcoins more valuable than others  

---

