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?


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.

  • 1
    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 Jan 5 '17 at 16:49
  • 2
    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 Jan 5 '17 at 17:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.