<p>Signatures cover inputs and outputs.</p>

<p>If someone changes one of the outputs in a transaction, a new signature is required. Effectively your signature signs "permit using my UTXO X to send A BTC to B, C BTC to D, ...".</p>

CC BY-SA 3.0
2018-01-10T07:39:53.547Z
Then my question is what is really signed in a bitcoin unlocking script. I was doing some research on the bitcoin script.  And for a P2PKH TX,  the stack pre final state is a pubkey,  a signature and OP_CHECKVERIFY, No mention of which data was signed or to be verified.
Eddy
CC BY-SA 3.0
2018-01-10T07:48:26.090Z
The search term for that is the "sighash". It's a hash of a (modified version of) the spending transaction. It's modified because the signature would need to sign itself if it was included. BIP143 changes the sighash scheme.
Pieter Wuille
CC BY-SA 3.0
2018-01-10T07:48:59.813Z
But conceptually, you can say that most signatures effectively sign the entire spending transaction.
Pieter Wuille
CC BY-SA 3.0
2018-01-10T08:00:58.187Z
"But conceptually, you can say that most signatures effectively sign the entire spending transaction”      Does that mean the signed data is the SHA 256 (TXOs) ? If so we might have a transaction with identical TXOs which might end up giving the same message digest.
Eddy
CC BY-SA 3.0
2018-01-10T08:03:14.967Z
What does TXO stand for? You can say that what is signed is the entire transaction (all inputs, all outputs), excluding the signatures themselves.
Pieter Wuille
CC BY-SA 3.0
2018-01-10T08:17:52.747Z
I have just got to understand what really happens. Nevertheless Blockchains are currently poorly documented. I'm really thankful for the time you dedicate in explaining these technologies.
Eddy
CC BY-SA 3.0
2018-01-10T08:54:17.157Z
Here is a specification for the signature hashing scheme used in witness v0 spends: https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki#Specification
Pieter Wuille
CC BY-SA 3.0
2018-01-10T07:33:43.207Z
2018-01-10T07:33:43.207Z
Pieter Wuille
<blockquote>
  <p>Because in my understanding I may provide a signature to unlock a txo
  and someone uses my signature to change the locking scripts of those
  TXs.</p>
</blockquote>

<p>Taking a "P2PKH tx", the unlockscript requires some operations to be executed while spending a tx:</p>

<pre><code>&lt;sig&gt;&lt;pubkey&gt;&lt;OP_DUP&gt;&lt;OP_HASH160&gt;pk hash&lt;OP_EQUALVERIFY&gt;&lt;OP_CHECKSIG&gt;
</code></pre>

<p>I have three scenarios here, when changing parts of the script fields:</p>

<p><strong>1.) change <code>&lt;sig&gt;</code> and <code>&lt;pubkey&gt;</code></strong></p>

<p>a miner changes the  part with a new signature and pubkey. Assuming the block raelly gets "through", the spender of the funds has a problem, cause his  would not match to the hash of the  anymore.</p>

<p><strong>2.) change only the <code>&lt;sig&gt;</code></strong></p>

<p>a miner changes only the  part with a new signature. Now the spender's  would match the hash of the . However the last command <code>&lt;OP_CHECKSIG&gt;</code> would check the remaining parts on the stack (<code>&lt;new sig&gt;&lt;pubkey&gt;</code>), and this would (obviously) fail.</p>

<p><strong>3.) change the pubkey script</strong></p>

<p>when anything in the pubkey script is changed, then the signature process will fail. During creat
ion of the signed transaction, the sigscipt area is filled with the pubkey script, and then signe
d. Later on, before transmitting the tx, the sciptsig area is replaced with <code>&lt;signature&gt;&lt;pubkey&gt;</code>.
So when the block would be propagated to other nodes, they would verify this block and it's tx in
side, and discover a signature mismatch. </p>

<p>Pieter explained details here of the scriptsig here:
<a href="https://bitcoin.stackexchange.com/questions/57644/what-are-the-parts-of-a-bitcoin-transaction-input-script">What are the parts of a Bitcoin Transaction &quot;Input&quot; script?</a></p>

<p>and two references that further help to understand:</p>

<p>1) <a href="http://www.righto.com/2014/02/bitcoins-hard-way-using-raw-bitcoin.html" rel="nofollow noreferrer">http://www.righto.com/2014/02/bitcoins-hard-way-using-raw-bitcoin.html</a></p>

<p>2) Andreas' book "Mastering Bitcoin", 2nd Edition, page 135ff</p>

CC BY-SA 3.0
2018-01-10T14:44:00.430Z
2018-01-10T21:59:13.287Z
2018-01-10T21:59:13.287Z
pebwindkraft
<p>In many cryptocurrencies a TX is composed of an array of TX inputs and TX outputs. </p>

<p>When a TX is submitted to the network, it already has the signature (in the unlocking script). </p>

<p>So my question is, what does prevent a miner or anyone on the network to use the already present unlocking and change the locking scripts of the transactions and then propagate the transaction. </p>

<p>Because in my understanding I may provide a signature to unlock a txo and someone uses my signature to change the locking scripts of those TXs.</p>

<transactions><bitcoin-core><security>
What prevents a miner to change the locking scripts of an unconfirmed transaction
Eddy
# What prevents a miner to change the locking scripts of an unconfirmed transaction

(Asked by: username_0 on 2018-01-10)

In many cryptocurrencies a TX is composed of an array of TX inputs and TX outputs.

When a TX is submitted to the network, it already has the signature (in the unlocking script).

So my question is, what does prevent a miner or anyone on the network to use the already present unlocking and change the locking scripts of the transactions and then propagate the transaction.

Because in my understanding I may provide a signature to unlock a txo and someone uses my signature to change the locking scripts of those TXs.

**Tags:** transactions, bitcoin-core, security


---

## 2 answers

### Answer by username_1 on 2018-01-10. Score: 3

Signatures cover inputs and outputs.

If someone changes one of the outputs in a transaction, a new signature is required. Effectively your signature signs "permit using my UTXO X to send A BTC to B, C BTC to D, ...".

> **Comments:**
> **username_0**: Then my question is what is really signed in a bitcoin unlocking script. I was doing some research on the bitcoin script.  And for a P2PKH TX,  the stack pre final state is a pubkey,  a signature and OP_CHECKVERIFY, No mention of which data was signed or to be verified.  
> **username_1**: The search term for that is the "sighash". It's a hash of a (modified version of) the spending transaction. It's modified because the signature would need to sign itself if it was included. BIP143 changes the sighash scheme.  
> **username_1**: But conceptually, you can say that most signatures effectively sign the entire spending transaction.  
> **username_0**: "But conceptually, you can say that most signatures effectively sign the entire spending transaction”      Does that mean the signed data is the SHA 256 (TXOs) ? If so we might have a transaction with identical TXOs which might end up giving the same message digest.  
> **username_1**: What does TXO stand for? You can say that what is signed is the entire transaction (all inputs, all outputs), excluding the signatures themselves.  
> **username_0**: I have just got to understand what really happens. Nevertheless Blockchains are currently poorly documented. I'm really thankful for the time you dedicate in explaining these technologies.  
> **username_1**: Here is a specification for the signature hashing scheme used in witness v0 spends: https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki#Specification  

---

### Answer by username_2 on 2018-01-10. Score: 2

> Because in my understanding I may provide a signature to unlock a txo
> and someone uses my signature to change the locking scripts of those
> TXs.

Taking a "P2PKH tx", the unlockscript requires some operations to be executed while spending a tx:

```
<sig><pubkey><OP_DUP><OP_HASH160>pk hash<OP_EQUALVERIFY><OP_CHECKSIG>

```

I have three scenarios here, when changing parts of the script fields:

**1.) change `<sig>` and `<pubkey>`**

a miner changes the part with a new signature and pubkey. Assuming the block raelly gets "through", the spender of the funds has a problem, cause his would not match to the hash of the anymore.

**2.) change only the `<sig>`**

a miner changes only the part with a new signature. Now the spender's would match the hash of the . However the last command `<OP_CHECKSIG>` would check the remaining parts on the stack (`<new sig><pubkey>`), and this would (obviously) fail.

**3.) change the pubkey script**

when anything in the pubkey script is changed, then the signature process will fail. During creat
ion of the signed transaction, the sigscipt area is filled with the pubkey script, and then signe
d. Later on, before transmitting the tx, the sciptsig area is replaced with `<signature><pubkey>`.
So when the block would be propagated to other nodes, they would verify this block and it's tx in
side, and discover a signature mismatch.

username_1 explained details here of the scriptsig here:
[What are the parts of a Bitcoin Transaction "Input" script?](https://bitcoin.stackexchange.com/questions/57644/what-are-the-parts-of-a-bitcoin-transaction-input-script)

and two references that further help to understand:

1) <http://www.righto.com/2014/02/bitcoins-hard-way-using-raw-bitcoin.html>

2) Andreas' book "Mastering Bitcoin", 2nd Edition, page 135ff


---

