1

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.

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, ...".

  • 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. – OvGeny Jan 10 '18 at 7:39
  • 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 Jan 10 '18 at 7:48
  • But conceptually, you can say that most signatures effectively sign the entire spending transaction. – Pieter Wuille Jan 10 '18 at 7:48
  • "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. – OvGeny Jan 10 '18 at 8:00
  • 1
    Here is a specification for the signature hashing scheme used in witness v0 spends: github.com/bitcoin/bips/blob/master/… – Pieter Wuille Jan 10 '18 at 8:54
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.

Pieter explained details here of the scriptsig here: 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

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.