What can a dishonest node do (or try to do)?

Question

Except this kind of attacks: https://en.bitcoin.it/wiki/Double-spending

For example can he simply create a new block that includes some invented transactions that steal money from real address? Without possessing the private keys of those addresses?

Answer 1

just off the top of my head, here are some things a dishonest miner can do:

• fail to include one or more transactions in the block. this is not technically 'dishonest', since the protocol does not require that all transmitted transactions be included in the current block. for example it would be considered perfectly ok for a miner to never include a transaction which does not include a mining fee in the current block. however if the transaction does have a fee (the standard behaviour) then a miner can still choose not to include any transaction it likes in a block. to do so would be to deliberately forgo a profit, and so its unlikely, but it is certainly possible. however other miners are unlikely to do the same, so they will include the transaction next time they mine a block.
• appropriate unsigned funds for itself. bitcoin scripts are merely puzzles to be solved in order to spend funds. generally puzzles are signed by the sender's private key, but this is not a requirement (though all wallet software does this by default). if someone is silly enough to manually create an output script which does not contain either an OP_CHECKSIG or OP_CHECKMULTISIG opcode then anything in the transaction can be changed by the miner. for example, say someone creates a transaction with output script OP_1 OP_EQUAL then transmits this to a miner to include in the blockchain. the miner can easily complete the puzzle and appropriate these funds by creating another transaction with input script OP_1. (to verify these scripts, just put the txin and the txout in sequence OP_1 OP_1 OP_EQUAL - 1==1). and the most important thing here is that since there is no signature, anybody can modify the output script in the spending transaction, so the miner can direct the funds to the address of a private key it owns.
• appropriate any SIGHASH_NONE funds. when signing a transaction, the user's wallet software will put a byte on the end of the signature in the txin script in the spending transaction. an 0x02 byte here corresponds to SIGHASH_NONE which means that all of the output scripts are ignored for the purposes of validation. so if someone sends a transaction like this then a miner can simply put their own address into all the txouts and include that modified transaction in a block, effectively sending funds to itself. however wallet software does not set signatures in this manner so someone would have to be deliberately foolish to loose funds to a miner in this manner.
• alter certain transaction hashes via transaction malleability. certain bitcoin transactions are malleable. while a miner is not able to alter the amount of bitcoins you send, or the recipient of these funds, it can modify certain transaction scriptsigs (the txin script) and thereby alter the transaction hash. this occurs because the scriptsig is not signed by the private key. so the miner can alter this scriptsig as long as it does not alter the functionality. note that bip 62 (scheduled for release in bitcoin 0.11) will eliminate transaction malleability for standard scripts, however for certain non-standard scripts malleability will always be a problem. for example if the txout script being spent starts with OP_DROP then any prior stack value (set at the end of the scriptsig) is ignored and so can be altered by a miner without altering the functionality of the transaction. since transaction hashes do include the scriptsig this will alter the transaction hash. any other transactions which were expecting to spend from that hash will be temporarily frustrated and will have to figure out the new hash value to spend from (by following the transaction trail in the blockchain).

Answer 2

No, it can not create any "invented transaction" on behalf of someone else without possessing that other node's private key for that transaction. This is maybe a similar Question.