<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](https://blockchain.info/tx/60ee91bc1563e44866c66937b141e9ef4615a272fa9d764b9468c2a673c55e01) 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.  

---

