I understood that transactions have one or more addresses as input and one or more addresses as output.

When an address is specified as input in a transaction in the working pool (pending to be confirmed), it means that the digitally signed address with it's public key is still in an unconfirmed state.

What prevents an attacker from using this address with this public key as input of another transaction with different outputs ? (his ones, for example)

| improve this question | | | | |

Bitcoin uses public key cryptography, so each address has an associated public key, and private key.

A transaction is signed using the private key of the inputs, without knowing the private key, you cannot move coins. So if someone (a miner) wants to change the outputs of your transaction to steal coins, their modified transaction would be rejected due to invalid signatures.

For their attack to be successful, they would need to know your private key, so that they could use it to properly sign a transaction to output addresses that they control.

| improve this answer | | | | |
  • So since there could be several input, is a "general" private key generated for all the inputs ? – Arthur Attout Nov 30 '17 at 20:29
  • @ArthurAttout: No, the transaction is signed with every private key corresponding to each input. – Murch Nov 30 '17 at 20:37

Transactions are signed with each private key corresponding to an input. Since the signature covers the complete content of the transaction, the transaction cannot be changed without invalidating the signature. This means that the recipients of a transaction cannot be changed by a third party.

| improve this answer | | | | |

What prevents an attacker from using this address with this public key as input of another transaction with different outputs ?

then the script wouldn't return true on the stack. You would have:

pubkey for original address

let's assume, this gets executed, we'd have this on stack:

pubkey hash of original address

now the miner changes the output part. So the stack is with this on top:

pubkey hash of original address
pubkey hash with miner's new address 

And this script would break at the point, where OP_EQUALVERIFY finds a mismatch between both pubkey hashes.

@murch and chytric: is the sig somehow checked before this script runs? I was always of the assumption, that the sig is checked as last item?

OP_CHECKSIG: The entire transaction's outputs, inputs, and script (from the most recently-executed OP_CODESEPARATOR to the end) are hashed. The signature used by OP_CHECKSIG must be a valid signature for this hash and public key.

| improve this answer | | | | |

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.