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

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

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

2829: <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>
 4070: <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>
 2306: <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>
