Bitcoin transaction signature

[eugene111]

Hi guys
I have a question regarding the bitcoin transaction signature
In the TX output locking script we don't deal with the Receiver Public key use actually only the Receiver  Bitcoin address (<pubKeyHash> in the script below - as I understand):

OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG

And when the Receiver tries to use the output he must provide the unlocking script:
<sig> <pub key>
where <sig> - is a newly created TX signature with the Receiver Private key and <pub key> - is the Receiver public key (derived from the Private key)

But imagine that some bad guy wants to use my UTXO.
This bad guy has
1. His Private Key,
2. His Public key (Derived from the Private key)
3. He knows my Bitcoin address (this is quite public info)

Now the bad guy creates a transaction, signs it with his Private Key and generates an Unlocking script <bad guy TX sig> <Bad guy Public Key>
On the stage of verification we connect the unlocking and unlocking scrips:
 <bad guy TX sig> <Bad guy Public Key>     OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG

Of course the script fails on the stage of OP_EQUALVERIFY  because the  Bitcoin address generated from the swindler Public Key is not equal to the <pubKeyHash> of the Receiver (specified in the locking sctipt)
But ... let's imagine(just hypothetically) that this verification passed
and we went to the next step - Transaction verification with OP_CHECKSIG.  And my main confusion is that I realize that OP_CHECKSIG verification will always pass because what was signed with the bad  Private key will be always verified correctly with his Public key because regardless of the bad guy intentions - his Public - Private key pair is a valid pair.
So as I see OP_CHECKSIG does not make any sense (it always true) at all and only a Bitcoin address verification assures that the Receivers address derives from his Public key - but it looks too weak
Please explain/correct me where I'm wrong.
Thanks a lot.
 

[achow101]

Signature verification has a two-fold effect. First it ensures that the person who is spending the UTXO proves that they have the private key associated with the public key that hashes to the provided hash. Secondly, and possibly most importantly, a signature commits to the data in the transaction - i.e. it ensures that the transaction itself has not been modified without the spender knowing.

A digital signature requires two things: the private/public keypair, and a message to sign. So in the case of Bitcoin transactions, the message to sign is the transaction itself (in most cases) but without signatures because a signature can't sign itself. With OP_CHECKSIG, if the transaction itself has been modified in some way (e.g. inputs added, outputs added, output values changed, etc.), then the signature will fail to validate because the message that is being used to validate the signature with has changed.

[Xynerise]

Hi guys
I have a question regarding the bitcoin transaction signature
In the TX output locking script we don't deal with the Receiver Public key use actually only the Receiver  Bitcoin address (<pubKeyHash> in the script below - as I understand):

Yes, with P2PKH, you don't deal with Public keys prima facie when you're sending bitcoins to someone, you just need the hash of their public key (i.e bitcoin address), however when the recipient wants to spend the UTXO you sent then s/he has to provide the public key that hashes to the address specified in the locking script (scriptPubkey) of the transaction.

OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG

And when the Receiver tries to use the output he must provide the unlocking script:
<sig> <pub key>
where <sig> - is a newly created TX signature with the Receiver Private key and <pub key> - is the Receiver public key (derived from the Private key)

Yes, this is correct.

But imagine that some bad guy wants to use my UTXO.
This bad guy has
1. His Private Key,
2. His Public key (Derived from the Private key)
3. He knows my Bitcoin address (this is quite public info)

If you've used the address before to send a transaction (redeem a UTXO), then he has your public key too because you need to provide it before you can spend any UTXO.
However having all these won't help as long as he doesn't have your private key.

Now the bad guy creates a transaction, signs it with his Private Key and generates an Unlocking script <bad guy TX sig> <Bad guy Public Key>
On the stage of verification we connect the unlocking and unlocking scrips:
 <bad guy TX sig> <Bad guy Public Key>     OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG

Of course the script fails on the stage of OP_EQUALVERIFY  because the  Bitcoin address generated from the swindler Public Key is not equal to the <pubKeyHash> of the Receiver (specified in the locking sctipt)
But ... let's imagine(just hypothetically) that this verification passed

Like I said earlier, whenever you spend bitcoins received to an address, then your public key is revealed, but that's okay because it's a PUBLIC key, and it has to be revealed without any loss in security (barring a functional quantum computer)
So that stage can pass because he has your public key.

and we went to the next step - Transaction verification with OP_CHECKSIG.  And my main confusion is that I realize that OP_CHECKSIG verification will always pass because what was signed with the bad  Private key will be always verified correctly with his Public key because regardless of the bad guy intentions - his Public - Private key pair is a valid pair.

Absolutely NOT.
Bitcoins are a chain of UTXOs.
Any bitcoins you're spending has to specify the requirements for the recipient to unlock to spend also.
With P2PKH it's the public key of the address provided and the signature of the transaction being spent.
So if he has HIS private key, with HIS public key, then he CAN'T spend YOUR UTXO because HIS public key WAS NOT specified in the locking script (scriptPubkey) of the transaction he's spending.
A bitcoin transaction from A -> B simply states: let B spend this UTXO iff he provides the public key for this address, and if he signs the transaction AGAINST the public key provided.
So since he's using HIS public key and not yours, then there's is frankly NO Utco that can be spent because it does NOT exist.
The existing UTXO is the one with YOUR bitcoin address, and hence YOUR public key.
If HIS public key is hashed it will result in a DIFFERENT bitcoin address entirely, barring a collision which means SHA256 & RIPEMD are broken.
So in essence he'll actually be spending HIS bitcoins and not yours because he's providing HIS public key and address.

Another scenario: let's say you've spent from an address before and now your public key is revealed.
The attacker now has your public key and inserts it in a transaction.
The first part verifies because the public key provided (yours) hashes to the bitcoin address specified in the UTXO to be spent (also yours)
The signature part however will fail if he doesn't have your private key, because the transaction he creates HAS to be signed by a private key, and the signed TX MUST verify against the public key provided.

So as I see OP_CHECKSIG does not make any sense (it always true) at all and only a Bitcoin address verification assures that the Receivers address derives from his Public key - but it looks too weak
Please explain/correct me where I'm wrong.
Thanks a lot.
 

If a digital signature wasn't required then anyone could spend anyone else's UTXOs with just the public key because when an address makes a transaction  the public key of the address is revealed.

For you to sign a digital signature you'll need the PRIVATE KEY of the associated public key. If the attacker has only your public key (this is revealed when you make a transaction), then he can't spend your UTXOs because he needs to sign the transaction itself with the private key of the public key provided, and the signed transaction is verified against the public key.

[pebwindkraft]

The bitcoin system has a locking and unlocking mechanism. The locking mechanism is in the pubkey script (some refer to it also as the spending condition), where you need to provide the pubkey to a corresponding hash. The author of a tx defines the target address (to whom the tx shall go), and the spending condition(s). When then the receiver of the tx wants to spend the tx, he/she/it needs to fulfill the condition (usually by showing the pubkey in hex format). And the unlocking is done with the sigscript of the transaction: signing the tx  with the priv key. 

Your point seems to play with the condition placed in the pubkey Script. You got it correctly: the OP_EQUALVERIFY would leave a false value on the stack, and as such the tx would not be processed furher.

So as I see OP_CHECKSIG does not make any sense

This statement is only true, if - and only if - there is a possibility to circumvent the previous step in bitcoin logic, which basically means to find a hash for the previous condition (to satisfy the OP_EQUALVERIFY). Clearly this is impossible to today's knowledge. At that time you would have broken bitcoins security concept for transactions.

So, what happens when you have messed around with the transaction, and you place another sig/pubkey into the tx. You would have to send this tx to another node, and then eventually to a miner. Both of them would do transaction justification along the rules: point 16 here: https://en.bitcoin.it/wiki/Protocol_rules#.22tx.22_messages. Now let's assume the first forwarding node and the miner have "non validating software" installed, and forward the malicious tx to others. Then other nodes will mark the tx as invalid, and the miner has the risk of creating a false block and loosing his incentive. And on top, other nodes might even ban these malicious nodes, by blacklisting them (not accepting further tx).

Also very good reading: Andreas' book "Mastering Bitcoin" in section 6 "Transactions".

[eugene111]

This statement is only true, if - and only if - there is a possibility to circumvent the previous step in bitcoin logic, which basically means to find a hash for the previous condition (to satisfy the OP_EQUALVERIFY). Clearly this is impossible to today's knowledge. At that time you would have broken bitcoins security concept for transactions.

Agree but then OP_CHECKSIG does not look a necessary step anyway. The thief can provide his Private+Public key - the this verification passes and he also can provide the true Receiver's public key. So all the security mechanism does not use Digital Signeture for verification - it is only based on two things -  1. The right sequence of locking and unlocking script operators and 2. The fact that the bitcoin address derives from the Receiver Public Key.

Again imagine the thief has the followed info:
1. HIS (thief's) valid Private and Public keys
2. The Receiver's PUBLIC KEY

Cosider two attaks:

1. The attacker constructs the unlocking script in a followed way:
<the newly created TX signature generated with HIS Private key> <HIS public key> <the Receiver public key>
with this script the OP_EQUALVERIFY passes. But then OF COURSE the OP_CHECKSIG will fail because the incorrect of order of values on stack (but not due to some cryptographic verification)

2. The attacker constructs the unlocking script in a followed way:
<the newly created TX signature generated with HIS Private key> <HIS public key>
Then OP_EQUALVERIFY fails.

But anyway no place to a Digital Signature verification

In my view it will be more logical if:
1. The Sender knows the Receiver Public key
2. When Sender creates an Output - he encrypts this SINGLE OUTPUT with the Receiver Public Key and puts this encrypted output as and additional field (with name HASH for example)
3. When the Receiver wants to spend the Output - he decrypts the HASH field with his Private Key and compares the encrypted bytes with the output bytes - if they equals - means the Receiver can use the Output
Or maybe the Sender can sign the Output with the Receiver Public key(but I'm not sure that it would work ...)

I'm pretty sure that bitcoin transactions are very safe the only thing what confuses me - is a bit complex mechanism of verification)

[DannyHamilton]

Consider two attacks:

1. The attacker constructs the unlocking script in a followed way:
<the newly created TX signature generated with HIS Private key> <HIS public key> <the Receiver public key>
with this script the OP_EQUALVERIFY passes. But then OF COURSE the OP_CHECKSIG will fail because the incorrect of order of values on stack (but not due to some cryptographic verification)

2. The attacker constructs the unlocking script in a followed way:
<the newly created TX signature generated with HIS Private key> <HIS public key>
Then OP_EQUALVERIFY fails.

Consider a third attack:

3. The attacker constructs the unlocking script in the following way:
<the newly created TX signature generated with HIS Private key> <the Receiver public key>
With this script, the OP_EQUALVERIFY passes, but then the OP_CHECKSIG will fail because the signature can NOT pass cryptographic verification with the provided public key.


More importantly, notice that the ONLY way to succeed in unlocking is with an unlocking script in the following way:
<the newly created TX signature generated with the RECEIVER's Private Key><the RECEIVER's Public Key>
With this script, the OP_EQUALVERIFY passes because it is the correct public key for the locking hash AND the OP_CHECKSIG passes because the signature DOES pass cryptographic verification with the provided public key.


If you change ANYTHING about the script it will fail.  It will either fail because it si the wrong script, or it will fail because the script contains the wrong data.

• Provide an invalid Public Key, OP_EQUALVERIFY fails
• Provide an invalid signature, OP_CHECKSIG fails
• Provide extra values or values in a different order, script fails because of the incorrect of order of values on stack

There are many ways to fail.  There is only one way to succeed.

[achow101]

In my view it will be more logical if:
1. The Sender knows the Receiver Public key
2. When Sender creates an Output - he encrypts this SINGLE OUTPUT with the Receiver Public Key and puts this encrypted output as and additional field (with name HASH for example)
3. When the Receiver wants to spend the Output - he decrypts the HASH field with his Private Key and compares the encrypted bytes with the output bytes - if they equals - means the Receiver can use the Output
Or maybe the Sender can sign the Output with the Receiver Public key(but I'm not sure that it would work ...)

I'm pretty sure that bitcoin transactions are very safe the only thing what confuses me - is a bit complex mechanism of verification)

This is no publicly verifiable and thus cannot work. A transaction needs to be verifiable by everyone, not just by one person.


You are failing to consider the case where an address is reused and the public keys are thus revealed to the world. Without a signature check, anyone could spend from an output that has an output script that was reused (i.e. reused addresses). You are also failing to consider the integrity aspect of signatures.

[eugene111]

This is no publicly verifiable and thus cannot work. A transaction needs to be verifiable by everyone, not just by one person.

So verification scrips are executed not only by a wallet software but also during the verification process when trasactions are mined into blocks?

You are failing to consider the case where an address is reused and the public keys are thus revealed to the world. Without a signature check, anyone could spend from an output that has an output script that was reused (i.e. reused addresses). You are also failing to consider the integrity aspect of signatures.

Yes I really thought that reusing of a bitcoin address and sharing the public key is a quite normal prctice but now I read that it is not

And one more question then - if we try to use a new new bitcoin address for each transaction then the publik key is also new each time? But the private keys is the same? So multiple public keys can be derived from the same private key?

[DannyHamilton]

So verification scrips are executed not only by a wallet software but also during the verification process when trasactions are mined into blocks?

Yes, the verification scripts are for the purpose of verification.

They are executed by EVERY node on the entire network before that node adds the transaction to its own mempool and before it relays the transaction to any other node.  If the verification fails, then the node does not add it to its own mempool AND it does not share it with any other peer.

They are executed by EVERY solo miner and mining pool operator as well.  Transactions that are invalid are not included in blocks.

The purpose of the transactions is that EVERY NODE can verify EVERY TRANSACTION and EVERY BLOCK for themselves.  That way a malicious node can not feed them any invalid data.

Yes I really thought that reusing of a bitcoin address and sharing the public key is a quite normal prctice but now I read that it is not

It is not recommended to re-use addresses.  However, it happens, and it is valid.

And one more question then - if we try to use a new new bitcoin address for each transaction then the publik key is also new each time?

Yes.

But the private keys is the same?

No.  There is a 1-to-1 relationship between public keys and private keys.  Every public key has exactly 1 private key.  Every private key has exactly 1 public key.

So multiple public keys can be derived from the same private key?

No.

Since an address is actually a representation of a script, it is possible (but unusual) to use the same private key for different addresses, but the private key will still have the same public key.

[pebwindkraft]

...
But the private keys is the same? So multiple public keys can be derived from the same private key?

edit as per comment from DannyHamilton below, unstructured comment, wrong quotes, low level, low quality and misleading - standing guilty :-)

This is true for non deterministic wallets/keys.
More standard today is use of HD keys, that allow to derive a set of public keys from a single private key.
It is also referred to as extended pubkeys. More on it can be found under the keywords "HD Wallets" and "BIP-32" or "BIP-44". Without going into details (this thread is about signatures), a quick research in the forum reveals all the details, and as usual Andreas' book "Mastering Bitcoin", section 5 "Wallets".

[DannyHamilton]

...
But the private keys is the same? So multiple public keys can be derived from the same private key?

This is true for non deterministic wallets/keys.

NO.  IT IS NOT.

More standard today is use of HD keys, that allow to derive a set of public keys from a single private key.

THIS IS ALSO A NOT TRUE.

HD keys allow you to derive a set of PRIVATE keys from a single seed.

You still only get one public key from each private key.

It is also referred to as extended pubkeys. More on it can be found under the keywords "HD Wallets" and "BIP-32" or "BIP-44". Without going into details (this thread is about signatures), a quick research in the forum reveals all the details, and as usual Andreas' book "Mastering Bitcoin", section 5 "Wallets".

Great.  Go do that research.  Then come back when you are ready to give good advice.