- If I have spent enough time on the re-implementation of the bitcoin client, this thing could be prevented.
This is the second time you've suggested that the Bitcoin reference code is responsible for your robbery. I inquired about this claim before and I don't believe I got a reply:
https://bitcointalk.org/index.php?topic=81045.msg899922#msg899922 Luke-jr also expressed skepticism:
https://bitcointalk.org/index.php?topic=81045.msg899911#msg899911 I fail to see how any system which has private keys for online realtime 'hot wallet' usage could be defended against an attacker which has root access to the selfsame systems. Even if you used a multisignature wallet and machines inside separate security domains an attacker with that level of access could simply impersonate the web application's legitimate withdraws.
That said if there is some flaw or omission in the reference client which could make high value installations more secure all the developers would love to hear about it.
What I am reasonably confident of is that while you're quite possibly smarter and have more time on your hands than any one of the people developing the publicly available reference software, you're not smarter than all of them combined. ... And a bug that sends 18kBTC into a black hole (as MTGOX's custom code did with a few thousand BTC) is no better than having code stolen.
There are significant advantages in working with a larger user base to test out and harden code before putting it on mission critical systems, and those advantages almost certainly outweigh the many troubles and limitations in the reference client. Moreover, many aspects of Bitcoin security require that you be a part of the majority clique even if the majority is "wrong", if you can be moved onto a minority chain you can be robbed. Because the significant super-majority of the network (users and miners) are using the reference client, its critical that any client be bug for bug compatible with the block rejection rules in the reference client or be at increased risk. So it very much is in your own interest to invest resources in improving the publicly available software than reinventing the wheel.
Thanks for the idea.
This is what I wanted to do:
- Drop the Bitcoin official client and re-implement one.
- Store private keys in the database, AES encrypted with a master key (that is associated with the user).
- Store master key in the database, AES encrypted with another hash of the user password (such as the SHA512 hash in place of the BCrypt hash).
This will be effectively a segregated account for the user. Of course we need to solve some problems (like forget password and forced settlements) but this is the general idea.
I'm a web developer so I feel much more comfortable securing the database rather than the wallet.dat. I never trust direct filesystem operations.