Quote from: solex on March 07, 2013, 10:09:19 PM

Thanks retep for this finding. I really did not consider that one transaction could be responsible. Someone "accidentally" paid $4000 to execute a payment. Ouch! What a coincidence that the world's most expensive payment transfer happened just when bitcoin traffic was so busy...

Well if you follow the transaction back a level, the 106BTC input, tx 1a3137bd3962de42a6b01974066e2940e9cd2cd2a393bb87c0e9c7439a702b31, came from Bitcoin-24.com

I don't know exactly what software Bitcoin-24.com uses, but the transactions in that address are all uncompressed pubkeys, and the inputs to the high-fee transaction are also all uncompressed pubkeys. The reference client has used compressed pubkeys by default since 0.6, so it's probably non-ref code that made the mistake. Equally given that the inputs are all recent transactions, I would suspect that we're not seeing someones mistake with a cold storage wallet or something. In addition the fact that one of the outputs is 0.002BTC implies it's some business with custom software.

I found a bunch of transactions before with weirdly high fees and high volume from from address 1JmQN8NvX3XXWWrJW3rEEcKQMQd5DUgkH3; it's still wasting fees. It's also connected to Bitcoin-24's address by one hop, although, that doesn't necessarily mean anything - it's also connected to Mt. Gox by one hop. That said the transactions around 1JmQN8N are also uncompressed keys, so maybe we're seeing common software for all of them? On the other hand, all the fees are even "human" numbers, so maybe it's just someone showing off their wealth.

Long story short: make your custom transaction generating code as robust as possible. Test, log, and audit everything.