<p>Bitcoin uses <a href="https://en.wikipedia.org/wiki/Public-key_cryptography" rel="nofollow noreferrer">public key cryptography</a>, so each address has an associated public key, and private key.</p>

<p>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. </p>

<p>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. </p>

CC BY-SA 3.0
2017-11-30T20:29:17.833Z
So since there could be several input, is a "general" private key generated for all the inputs ?
Arthur Attout
CC BY-SA 3.0
2017-11-30T20:37:24.623Z
@ArthurAttout: No, the transaction is signed with every private key corresponding to each input.
Murch
CC BY-SA 3.0
2017-11-30T20:22:35.343Z
2017-11-30T20:22:35.343Z
chytrik
<p>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.</p>

CC BY-SA 3.0
2017-11-30T20:41:24.300Z
2017-11-30T23:59:45.560Z
2017-11-30T23:59:45.560Z
Murch
<blockquote>
  <p>What prevents an attacker from using this address with this public key
  as input of another transaction with different outputs ? </p>
</blockquote>

<p>then the script wouldn't return true on the stack. You would have:</p>

<pre><code>signature
pubkey for original address
Op_DUP
OP_HASH160
</code></pre>

<p>let's assume, this gets executed, we'd have this on stack:</p>

<pre><code>signature
pubkey hash of original address
</code></pre>

<p>now the miner changes the output part. So the stack is with this on top:</p>

<pre><code>signature
pubkey hash of original address
pubkey hash with miner's new address 
OP_EQUALVERIFY
OP_CHECKSIG
</code></pre>

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

<p>@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?</p>

<p>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.</p>

CC BY-SA 3.0
2017-11-30T22:39:43.290Z
2017-11-30T22:39:43.290Z
pebwindkraft
<p>I understood that transactions have one or more addresses as input and one or more addresses as output. </p>

<p>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. </p>

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

<private-key><public-key>
What prevents a miner from stealing inputs when they are still in the working pool ?
Arthur Attout
# What prevents a miner from stealing inputs when they are still in the working pool ?

(Asked by: username_0 on 2017-11-30)

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)

**Tags:** private-key, public-key


---

## 3 answers

### Answer by username_1 on 2017-11-30. Score: 2 | Accepted answer

Bitcoin uses [public key cryptography](https://en.wikipedia.org/wiki/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.

> **Comments:**
> **username_0**: So since there could be several input, is a "general" private key generated for all the inputs ?  
> **username_2**: @username_0: No, the transaction is signed with every private key corresponding to each input.  

---

### Answer by username_2 on 2017-11-30. Score: 1

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.


---

### Answer by username_3 on 2017-11-30. Score: 0

> 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:

```
signature
pubkey for original address
Op_DUP
OP_HASH160

```

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

```
signature
pubkey hash of original address

```

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

```
signature
pubkey hash of original address
pubkey hash with miner's new address 
OP_EQUALVERIFY
OP_CHECKSIG

```

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

@username_2 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.


---

