<p>An attack of this nature would be equivalent to resolving an NP-Complete problem. If the hacker has resolved the P=NP conjecture or is Peter Shor working on a secret quantum computer, then perhaps, but honestly this isn't a concern. ECDSA is secure and used in the NSA's suite B protocols. </p>

<p>That said, there is the notion of a 51% attack, which could become real if BTCGuild continues to grow, yet I believe the guys at the open source Bitcoin project have hard coded certain solutions in the blockchain to mitigate some of these issues. </p>

CC BY-SA 3.0
2013-04-18T02:45:37.060Z
2013-04-18T02:45:37.060Z
Charles Hoskinson
<p>Transactions are signed with ECDSA. Incidentally, bitcoin addresses are hashes of the ECDSA public key that can spend them. You can't spend somebody else's coins unless you 1) do a bruteforce search to find their private key or 2) find a public key that hashes out to the same thing. Both are much, much harder than doing a double spend attack.</p>

CC BY-SA 3.0
2013-02-06T03:17:49.243Z
Yes I understand that, but that public key verification is done by the miner who submits the transaction into the block and eventually to the block chain. So what if the miner makes something up to put in the body of the block (a false transaction) who verifies the miner? Your answer only ensures the non miners cannot easily steal.
Patrick Lorio
CC BY-SA 3.0
2013-02-06T03:20:29.913Z
@PatrickLorio, everybody who downloads the blockchain verifies the signatures. There wouldn't be much point in including the signatures in the blockchain if nobody checked them, now would there?
Nick ODell
CC BY-SA 3.0
2013-02-06T03:34:55.277Z
For some reason I thought the transactions placed in the block were decrypted plain-text. It makes a lot more sense that they're not. Thanks, that was really bugging me.
Patrick Lorio
CC BY-SA 3.0
2013-02-06T11:36:54.593Z
@PatrickLorio, Signing != Encrypting
Stephen Gornick
CC BY-SA 3.0
2013-02-06T03:01:41.443Z
2013-02-06T03:01:41.443Z
Nick ODell
<p>I've been reading around: <a href="https://en.bitcoin.it/wiki/How_bitcoin_works">https://en.bitcoin.it/wiki/How_bitcoin_works</a></p>

<p>What prevents a miner's block from being accepted across the network if the hash checks out when miner forges transactions in the block?</p>

<p>For example, lets say I'm mining and I want to steal money from address A and put it into my address B. So I build a block with the A->B transaction along with some requested transactions. Now if I can compute a hash for the block before anyone else, and send off to peers in the network, how could they reject it? How would they know that's not a real transaction? If bitcoin clients record requests to verify, maybe this request was blocked by some NAT issue.</p>

<p>I can't think of a good way of fixing this and I didn't find anything about in documentation. Any insight would be appreciated. Thanks.</p>

<security><mining-theory><attack>
Could miners steal money?
Patrick Lorio
# Could miners steal money?

(Asked by: username_0 on 2013-02-06)

I've been reading around: <https://en.bitcoin.it/wiki/How_bitcoin_works>

What prevents a miner's block from being accepted across the network if the hash checks out when miner forges transactions in the block?

For example, lets say I'm mining and I want to steal money from address A and put it into my address B. So I build a block with the A->B transaction along with some requested transactions. Now if I can compute a hash for the block before anyone else, and send off to peers in the network, how could they reject it? How would they know that's not a real transaction? If bitcoin clients record requests to verify, maybe this request was blocked by some NAT issue.

I can't think of a good way of fixing this and I didn't find anything about in documentation. Any insight would be appreciated. Thanks.

**Tags:** security, mining-theory, attack


---

## 2 answers

### Answer by username_2 on 2013-02-06. Score: 8 | Accepted answer

Transactions are signed with ECDSA. Incidentally, bitcoin addresses are hashes of the ECDSA public key that can spend them. You can't spend somebody else's coins unless you 1) do a bruteforce search to find their private key or 2) find a public key that hashes out to the same thing. Both are much, much harder than doing a double spend attack.

> **Comments:**
> **username_0**: Yes I understand that, but that public key verification is done by the miner who submits the transaction into the block and eventually to the block chain. So what if the miner makes something up to put in the body of the block (a false transaction) who verifies the miner? Your answer only ensures the non miners cannot easily steal.  
> **username_2**: @username_0, everybody who downloads the blockchain verifies the signatures. There wouldn't be much point in including the signatures in the blockchain if nobody checked them, now would there?  
> **username_0**: For some reason I thought the transactions placed in the block were decrypted plain-text. It makes a lot more sense that they're not. Thanks, that was really bugging me.  
> **username_3**: @username_0, Signing != Encrypting  

---

### Answer by username_1 on 2013-04-18. Score: 2

An attack of this nature would be equivalent to resolving an NP-Complete problem. If the hacker has resolved the P=NP conjecture or is Peter Shor working on a secret quantum computer, then perhaps, but honestly this isn't a concern. ECDSA is secure and used in the NSA's suite B protocols.

That said, there is the notion of a 51% attack, which could become real if BTCGuild continues to grow, yet I believe the guys at the open source Bitcoin project have hard coded certain solutions in the blockchain to mitigate some of these issues.


---

