That isn't as large of a limitation as you might be thinking, at least not in most applications.  The hardened keys are used to produce the major "branches" and then unhardened keys are used to leafs.  There aren't many scenarios where you would compromise just a few but not too many of the leaf keys AND not also compromise the parent (branch) key at the same time.   Still the OP is an interesting academic concept but I agree with gmaxwell in that scenarios where it would provide additional security is limited.

Crypto is one of those things you don't want to "roll yourself".  It is very easy to make a system which you believe is secure and isn't.   As pointed out a RNG is insufficient what you need is a cryptographically secure random number generator (CSRNG).   The RNG in database applications (and many other places) are not designed or verified to produce numbers which can't be broken.

What I would recommend is you some existing wallet export just the public keys and import those into your database.   Then assign them to customers invoices as needed.   There is no reason for the database to hold private keys.

That is not correct in all scenarios.  Private keys can either be hardened or normal.  Hardened private keys can not leak the parent key.    Even with unhardened private keys the leak of the key alone is insufficient to leak the parent as well.  You need to leak a child private key AND parent public key to compromise the parent private key.

There is no monopoly.  You keep using that word but I don't think you know what it means.    You can mine new coins right now.  You can sell goods or services for Bitcoins.   You can take some of your non crypto wealth and trade it for Bitcoins.   There is no monopoly to access.

That is the reality.   Bitcoin is voluntarism at its finest.  People can't be forced to use it.  So people only use it IF it is better than the alternatives.  People are forced to use fiat and that forced use in the fiat world directly contributes to the unequal advantage a tiny minority have over the super majority.   That unearned and unfair advantage is what drives and reinforces the unequal wealth distribution.  
Unequal wealth distribution in the fiat world isn't the problem it is the symptom.   The problem is a system which gives the privileged (forget the 1% we are talking the 0.01%) a benefit and that benefit isn't free it is fully paid by the unprivileged and the worst part is you are forced into that system through a monopoly on violence.

(Edited for clarity)

You base this on what?  People read your first post but you leap to unsupported conclusions because of a misunderstanding of terminology.
1 address =/= 1 wallet =/= 1 person. Due to the way that Bitcoin creates transactions most wallets will have more than one "funded" address.  They will also have addresses with a mix of value (some larger, some smaller, some left over change so small they may never be spent).   You assume that because there are 46 million non zero addresses that means there are 46 million unique entities and 95% of them have less than 1% of the total coins.  No it only means that there is a huge amount of spam in the network.   Most of those outputs below 1000 satoshis will never be spent and come from a period in time when the network had no anti-spam provisions.  As an example one company would send betters a single satoshi for each losing bet to provide confirmation that the bet was processed and lost.  Millions upon millions of them.  You treat each of those spam transactions as a single PERSON!




For the sake of the argument lets assume the distribution is as bad. You also indirectly assume that distribution won't widen.   At block 1 a single person owned 100% of the Bitcoins and now that is no longer true.  The Bitcoin money supply is ~$4B. The total wealth on earth is $263T.   Bitcoin is roughly .001% of the total wealth and is used by more than 0.001% of the planet.  

The rise in value of the Bitcoin money supply is directly linked to a wider distribution.   There is no scenario where Bitcoin will be worth tens of trillions of dollars and the same x people control 62% (your claim) of that.   It is a self solving problem.  Either the distribution widens (though commerce, speculation, and yes theft/scams/fraud) or the system won't increase in value.

Possession is not ownership*.  The major exchanges hold a lot of coins but those coins (legally) belong to the depositors. This can't be reflected by looking at the address distribution.  Using the graph you used to illustrate a point would be like graphing where all the US dollars are and showing that 5 "people" (BofA, Citibank, etc) have 95% of the dollars.  Yes their is unequal wealth distribution in the US (and everywhere) but simply looking at who is currently "holding" the assets as a bailor is pointless.

* That being said if you don't have the private key for "your" bitcoins then you don't have any bitcoins.  At best you have an IOU for some bitcoins owed to you which hopefully will be paid on demand in the future.

Corrected.  It hindsight it makes sense.  This is no more effective at spamming than large low value "normal" outputs (which are also non-standard not invalid).  Spam/bloat prevention wouldn't be improved by making one method invalid and the other non-standard. Attacker will simply use the method which is available.

Of course one can only hope non-malicious miners would see the burden of a bloated UTXO set and thus not include those types of transactions.   At least their interests are aligned with general users.

True but it is generally considered poor practice to embed hundreds of bytes instead of just embedding a hash.  Personally given that one can encode data in "fake" transactions (which are not prunable) I wish there was no limit on OP_RETURN at all but that ship has sailed.  My point was that fees are per KB and that means the OP should be able to "price" the txn the same as any other txn.

The flip side is Bitcoin is the anti NSA.  It is like a canary in the coal mine for crypto flaws.  A while back there was a flaw in the PRNG used by the Android OS.  Now this affected a huge number of crypto applications beyond just Bitcoin but to a hacker who discovered this the easiest and most immediate payoff was to steal coins from insecure transactions.  A relatively few Bitcoins were stolen and the OS patched.  It is very likely this was a development error and not an intentional flaw but either way it has now been fixed and everyone (even non Bitcoiners) are safer because of it.

In the absence of a public compromise, the more widely a cryptographic system is used and the more direct the payoff the more assurance I would place in the system over less used systems of similar security.  For that reason I trust the secp256k1 curve more than other ECC curves.  I trust ECDSA a lot more than RSA and I would trust SHA-2 family of hashes more than other hashing algorithms.  The $4B in the Bitcoin network is one giant canary.

Correct.  The security of ECDSA requires that all signatures from the same private key have a unique secret k value.  If the k value is the same for two signatures involving the same private key then with some simple math the private key can be computed from the public key and signature.  The k only has to be unique and secret large number not random but the most common way to get a unique and secret large number is to generate one randomly.

There is a solution which is deterministic signatures (RFC 6979).  It is more widely used than two years ago but it is not universal.  IIRC the reference client still uses random k values.  https://tools.ietf.org/html/rfc6979

The bad news is that RRNG weaknesses can either be accidental or intentional and sometimes nearly impossible to detect.   The good news is that with HD wallets, deterministic signatures, and some manual entropy source (dice, deck of cards, flipping coins, etc) it is possible to create a wallet and a lifetime of transactions which never uses a single bit from a potentially compromised PRNG.

It is also possible someone built a quantum computer and used Shor's algorithm to break the private key from the public key.   Both scenarios are possible but improbable.  The easiest way to get a private key is to get the private key.  Gain unauthorized access to the server, copy wallet, transfer coins.

http://en.wikipedia.org/wiki/Occam%27s_razor

Correct.  The only true hard limit is that blocks are currently limited to 1MB.  Changing that will require a fork (and a super majority to support it).  It will also need to be extensively tested and will break existing clients (who will see larger blocks as invalid) so it will require a pretty involved process over the course of months.   The 7 tps is often quotes like it is written in stone but only the 1MB limit is.

The actual transaction rates depends on what the average transaction size ends up being.  Honestly I think the 7tps is a little generous.  It requires the average transaction size to be 238 bytes (1,000,000 / 600 / 7 = 238).   While the mode is probably around 200-300 bytes the less frequent but much larger transactions bring up the average to around 500 bytes.  That would mean an average "full" block having 2,000 transactions or 3.3 tps (2,000 /600 = 3.3 tps).  Note this isn't necessarily a bad thing.   Paying multiple withdraws as a single transaction for example will result in less transactions which are on average larger but the bytes per withdraw is less and thus the block is being used more efficiently.

The reality is that writing a wallet (just wallet functionality depending on a compliant node) is relatively easy however writing a full node is very complex and the risk is very high because it must exactly match the network facing behavior of the reference client.  Currently the code for running a node is intermixed with the code for running a wallet.   One can thank Satoshi's original design for that.  This means decoupling a wallet from the reference client is difficult.   The core developers have worked hard to separate out the node logic from the client logic.

Optimally there would be node library and that node library is used to create the reference node and other implementations.  Then the client/wallet would communicate with a node (either locally or remotely).  This would vastly reduce the complexity of writing a custom wallet as the scope would be limited solely to wallet functionality instead of building the entire stack as a monolithic project.  I have no doubt eventually it will happen just no idea how long it will take.

Not necessarily but it does require some common sense.  Just because someone has $100,000 in cash doesn't mean they should stuff it all in their wallet and walk around with it everyday.  The funny thing is that nobody does and they don't even consider it however they do exactly that with Bitcoin.  Likewise it wouldn't really make sense to keep all of your money in a safety deposit box either.  "Oops need to buy a candy bar let me drive to the bank, show ID, wait for the guard, sign out my safety deposit box at the bank, remove $1, lock the box, drive to the store and buy the candy bar".  That scenario is also equally dumb and nobody would even consider doing that in the fiat world.   Why?  Most people would use common sense.  Somehow people know how to keep cash secure and part of that means limiting the amount which can be stolen while not making it excessively inconvenient.  Keep daily needs in wallet, an emergency amount in home safe, and bulk of cash strongly secured in safety deposit box (or federally insured bank).   People instinctively know how to do it when it is dollars or euros but soon as you say Bitcoin all the common sense goes out the window. 

Yes that is correct 1 in 2 out (OP RETURN+ change) is the most common.  It can also be "combined" with a normal transaction to reduce cost so that would be 1 or more inputs, plus 1 or more "paying" outputs (including change) plus the OP_RETURN.  Fee shouldn't need to be more than any other transaction.  The minimum is 1,000 satoshis per KB.  If you upgrade to v0.10 of the client there is an RPC call which estimates the fee required to be quickly confirmed.  It can be used for any transaction (including those with OP_RETURN outputs).

In the past this was done by dumping the data into a "normal" output which would be unspent.  Please don't do this as the network has no way of knowing that output is "fake" and thus it remains in the UTXO set forever.  OP_RETURN allows you to create an output which is included in a block but is marked as unspendable thus not bloating the UTXO (a more critical resource often ignored by most).

Three important points to consider about OP_RETURN:
1) More than one OP_RETURN output in a transaction is invalid non-standard (and won't be relayed by most nodes).
2) A "payload" of more than 40 bytes in the OP RETURN output is invalid non-standard as well.
3) Any value assigned to the OP_RETURN output is unspendable so the "coins" are effectively destroyed.  Unless you intentionally want to destroy some coins, you should ensure the OP_RETURN outputs always have a value of zero.

Some additional info:
http://bitcoin.stackexchange.com/questions/29554/explanation-of-what-an-op-return-transaction-looks-like

On edit: Thanks Gavin for non-standard vs invalid and routine counting correction.
 

 The word fake is biased.   Fake indicates someone created those transactions for the purpose of misleading someone.   The reality is that anytime a coin is "moved" it is a transaction.  Not all transactions are "economic" in the sense of a change of ownership or payments for goods and services.   For example a well run exchange may generate number of transactions internally.   Depositing should go the cold wallet, periodically they are consolidated to reduce key management and security concerns, a portion is transferred to hot wallet, hot wallet pays out withdraws, customer may change wallets, and then later may deposit back to the exchange using same deposit address.   That may be 5 or more transactions per cycle.  Was all of that "economic" (in the sense of velocity)?  No but it wasn't "fake" either.

To my knowledge no with the exception of so called "brain wallets".  Humans are amazingly bad at generating entropy and will very often vastly overestimate the amount of entropy in a password or passphrase.  Many brainwallets even those not hacked "yet" are vulnerable to brute force attacks.

What is the rush?  Transactions are irreversible.   In prior hacks attackers have waited days or even weeks before they starting obfuscating the trail.


The assumption is the address containing the stolen coins is not controlled by BitStamp but is instead under the control of the hacker.

+1 for a creative way to answer something asked for the 157,248th time.