<p>You can think of a &quot;locking script&quot; as function definition, and the &quot;unlocking script&quot; as function arguments that will make the function evaluate to true.</p>
<p>The commonly used P2PKH address is really a little program attached to the UTXO which has a function definition like <code>f_p2pkh(public_key, signature, sighash_flags)</code>. An UTXO keeps some BTC locked with that function. The spender then creates a transaction which references a particular instance of the function <code>f_p2pkh</code> and provides the 3 arguments <code>public_key</code>, <code>signature</code>, and <code>sighash_flags</code>.</p>
<p>Here the function definition hard-codes the public key hash so you can't sign with any key but must use the specific key defined as a constant in the function itself.</p>
<p>But what &quot;message&quot; does the signature sign? The function will call a native function (OP_CHECKSIG) which constructs a message from the transaction context it's being spent in using the instruction encoded in the &quot;sighash_flag&quot; argument. This lets the spender not just unlock the UTXO but also decide exactly where the unlocked BTC can move to (new outputs).</p>
<p>The signature &quot;message&quot; is constructed from the transaction body according to supported recipes, encoded by <a href="https://btcinformation.org/en/developer-guide#term-signature-hash" rel="nofollow noreferrer">sighash flags</a>. With P2PKH, the spender gets to choose the recipe - which allows for some flexibility in what outputs to require: SIGHASH_ALL, SIGHASH_NONE, SIGHASH_SINGLE, and also gives signer the option to allow others to add more inputs by using SIGHASH_ANYONECANPAY.</p>
<p>Each UTXO is like a little box that holds some BTC and locked with a smart lock, and our function definition is the lock's firmware, and the firmware can &quot;see&quot; other parts of the transaction. We spend by feeding the smart lock the information required to open, which then releases the BTC and moves it to some new boxes.</p>

CC BY-SA 4.0
2022-11-02T11:13:39.127Z
2022-11-02T11:13:39.127Z
bca-0353f40e
<p>I am trying to learn Bitcoin in some technical details, but I don't really understand the process of locking and unlocking scripts. I know that for what they are using, but can someone explain me some technical details. For example: Firstly wallet encrypt this transaction with private key etc...</p>
<p>I would be very grateful for good explanation.</p>

CC BY-SA 4.0
2022-02-11T21:46:24.347Z
Perhaps take a look at https://learnmeabitcoin.com/beginners/transactions
Murch
<transactions><blockchain><script><cryptography>
How transactions script work?
Dev Per
# How transactions script work?

(Asked by: username_0 on 2022-02-11)

I am trying to learn Bitcoin in some technical details, but I don't really understand the process of locking and unlocking scripts. I know that for what they are using, but can someone explain me some technical details. For example: Firstly wallet encrypt this transaction with private key etc...

I would be very grateful for good explanation.

**Tags:** transactions, blockchain, script, cryptography

> **Comments:**
> **username_1**: Perhaps take a look at https://learnmeabitcoin.com/beginners/transactions  

---

## 1 answers

### Answer by username_2 on 2022-11-02. Score: 1

You can think of a "locking script" as function definition, and the "unlocking script" as function arguments that will make the function evaluate to true.

The commonly used P2PKH address is really a little program attached to the UTXO which has a function definition like `f_p2pkh(public_key, signature, sighash_flags)`. An UTXO keeps some BTC locked with that function. The spender then creates a transaction which references a particular instance of the function `f_p2pkh` and provides the 3 arguments `public_key`, `signature`, and `sighash_flags`.

Here the function definition hard-codes the public key hash so you can't sign with any key but must use the specific key defined as a constant in the function itself.

But what "message" does the signature sign? The function will call a native function (OP\_CHECKSIG) which constructs a message from the transaction context it's being spent in using the instruction encoded in the "sighash\_flag" argument. This lets the spender not just unlock the UTXO but also decide exactly where the unlocked BTC can move to (new outputs).

The signature "message" is constructed from the transaction body according to supported recipes, encoded by [sighash flags](https://btcinformation.org/en/developer-guide#term-signature-hash). With P2PKH, the spender gets to choose the recipe - which allows for some flexibility in what outputs to require: SIGHASH\_ALL, SIGHASH\_NONE, SIGHASH\_SINGLE, and also gives signer the option to allow others to add more inputs by using SIGHASH\_ANYONECANPAY.

Each UTXO is like a little box that holds some BTC and locked with a smart lock, and our function definition is the lock's firmware, and the firmware can "see" other parts of the transaction. We spend by feeding the smart lock the information required to open, which then releases the BTC and moves it to some new boxes.


---

