<p>There is no definitive answer here, and you'd need to ask the system's creator to be sure.</p>

<p>My guess is that it was due to interaction with a feature that we're now calling 'delegation': the ability for someone to presign a transaction, and add a new unlocking script- effectively delegating the right to sign to someone else under certain circumstances.</p>

<p>Elements of the script language that point in this direction include the existence of OP_CODESEPARATOR, and the original execution model of running scriptSig + scriptPubKey in one go, rather than separately as is done now.</p>

CC BY-SA 3.0
2017-01-05T16:49:13.903Z
But what about security - am I right, that before the transaction will be included into the block, miner can edit unlocking script + unlocking script lenght, and transaction will still be valid?
Sergey Potekhin
CC BY-SA 3.0
2017-01-05T17:03:51.597Z
Yes, that's called malleability, and it is possible. However, it cannot be avoided, as we can't have signatures that sign themselves (as they are in the unlocking script). A way around it is the Segregated Witness proposal, which does not prevent malleability, but makes the unlocking script not contribute to txid calculation.
Pieter Wuille
CC BY-SA 3.0
2017-01-05T04:07:08.843Z
2017-01-05T04:07:08.843Z
Pieter Wuille
<p>Finally, I've successfully made a raw transaction with Python and this is the last thing, which is totally mistic for me. </p>

<p>In my case, <a href="https://blockchain.info/tx/60ee91bc1563e44866c66937b141e9ef4615a272fa9d764b9468c2a673c55e01" rel="nofollow noreferrer">here's</a> the input transaction and it's locking script is:</p>

<pre><code>OP_DUP OP_HASH160 dab3cccc50d7ff2d1d2926ec85ca186e61aef105 OP_EQUALVERIFY OP_CHECKSIG
</code></pre>

<p>Why it's necessary to set up the <strong>unlocking script</strong> to the input's <strong>locking script</strong> before signing? In my understanding, all the stuff should work well even with blank locking script, because in fact we're signing only other parameters. <code>Unlocking script</code> and <code>unlocking script lenght</code> will be changed anyway, so what's the reason?</p>

<script><signature><ecdsa>
Why transaction is signed with locking script from the input transaction?
Sergey Potekhin
# Why transaction is signed with locking script from the input transaction?

(Asked by: username_0 on 2017-01-04)

Finally, I've successfully made a raw transaction with Python and this is the last thing, which is totally mistic for me. 
In my case, here's the input transaction and it's locking script is:
OP_DUP OP_HASH160 dab3cccc50d7ff2d1d2926ec85ca186e61aef105 OP_EQUALVERIFY OP_CHECKSIG

Why it's necessary to set up the unlocking script to the input's locking script before signing? In my understanding, all the stuff should work well even with blank locking script, because in fact we're signing only other parameters. Unlocking script and unlocking script lenght will be changed anyway, so what's the reason?

**Tags:** script, signature, ecdsa


---

## 1 answers

### Answer by username_1 on 2017-01-05. Score: 3 | Accepted answer

There is no definitive answer here, and you'd need to ask the system's creator to be sure.

My guess is that it was due to interaction with a feature that we're now calling 'delegation': the ability for someone to presign a transaction, and add a new unlocking script- effectively delegating the right to sign to someone else under certain circumstances.

Elements of the script language that point in this direction include the existence of OP\_CODESEPARATOR, and the original execution model of running scriptSig + scriptPubKey in one go, rather than separately as is done now.

> **Comments:**
> **username_0**: But what about security - am I right, that before the transaction will be included into the block, miner can edit unlocking script + unlocking script lenght, and transaction will still be valid?  
> **username_1**: Yes, that's called malleability, and it is possible. However, it cannot be avoided, as we can't have signatures that sign themselves (as they are in the unlocking script). A way around it is the Segregated Witness proposal, which does not prevent malleability, but makes the unlocking script not contribute to txid calculation.  

---

