Do not, do not, DO NOT, try writing raw transactions at home. You will fail and you will lose a lot of money.
If you must:
- Use testnet! If you don't know what testnet is, you have no business writing live raw transactions.
- ALWAYS validate your transaction first by having bitcoind pretty-print it, and checking the output carefully, before sending.
> Do not, do not, DO NOT, try writing raw transactions at home. You will fail and you will lose a lot of money.
I don't see the harm in putting a dollar or two into a new wallet just to have some fun. Just be careful not to mix up the private key with your real wallet, if you have one.
The big problem was that you could forget to specify a "change" output, and then any unspend bitcoins would become the transaction fee. For large inputs this could be a disaster.
The 0.9 release candidate of bitcoin-qt now does sanity checks on the transaction fee, so this shouldn't be such a big problem anymore.
Unfortunately, there is no way to spend a multisig (or any other nonstandard) transaction besides using the createrawtransaction API. It would be really nice if somebody implemented a better(safer) interface for them - n-of-m transactions could seriously increase security in many scenarios, but it's hard to get them right.
gwillen isn't deciding anything for anyone. They've provided advice to people so they can save themselves a lot of heartache. Would you be so upset if someone were to post about (let's use a Myth Busters example) sticking your hand in molten lead, and the top comment was "Don't try this at home! If you're off by a few degrees you will seriously injure yourself."?
To elaborate on that. If not very careful, you can end up sending a big fee, since the fee is calculated in the following way:
sum of all inputs values - sum of all outputs values
"Change" is an output that you control to which you will send the remaining amount. Failing to do so will end up sending all remaining value as transaction fee, which then goes to the miners.
If you end up doing that (as I did few months ago) you still have a chance though - through blockchain.info you can get information about who mined the block in which your transaction was included. If you're lucky, it will be one of the big pools. You can then try to contact them and ask to send the amount back to the originating address. In my case BTC Guild was nice enough to do exactly this.
With pools moving towards paying miners the transaction fees it becomes more difficult to recover from mistakes like this. The pool would have to contact the miners that received the fees to recover them.
If you want something in a similar vein, Khan Academy has some good videos describing the protocol and not just a high-level overview (though there is that, too).
Agreed, this is a great reference and high level low level overview. Having though of doing the exact same thing, it's nice to have a guide in case I ever decide to do so. Thanks!
I've always wanted to learn how to query a coin network for things like current difficulty and total hashrate without running a full blown wallet to get a console.
Is this documented anywhere perhaps? I cannot seem to find.
The only reason I might suggest considering this botnet premise is due to hardware mining.
ASICs are pretty much the norm for mining now, and near as I can tell, there hasn't been much discussion regarding all the custom hardware floating around lately.
If you must: - Use testnet! If you don't know what testnet is, you have no business writing live raw transactions. - ALWAYS validate your transaction first by having bitcoind pretty-print it, and checking the output carefully, before sending.