In your specific case, I’d consider investing a small chunk of the proceeds in a qualified opportunity zone fund. The tax incentives are massive, but there are a lot tradeoffs that you’re unfortunately probably not in the best place to fully work through right now :(
Wallet author here. Thanks @ryan-c for your question.
BlockCypher does get the extended public key, which is necessary for fetching transaction history, balance, and UTXOs. Child private keys never leave your system [0]. I chose against hardened derivation because it doesn't solve any problems and introduces a new one.
Let's say you assume that you have an extended private key A (with a corresponding extended public key). You then use hardened derivation on A to calculate a hardened chain at m/0'. Let's call this extended private key B. We then send all our transactions to addresses calculated by B (m/0'/0, m/0'/1, m/0'/2, etc). Now we're back in our same boat, we have transactions to dozens (or potentially thousands) of addresses created by B and so we use the extended public key of B to ping a third party service to fetch the transaction history/balance/UTXOs. If an attacker gets any child private key of B, and the extended public key of B, they can derive all child keys of B, even though hardened derivation was used. What they can't do, is derive A (or any of its children). In other words, the purpose of hardened derivation is to separate risk between different wallets, not within the same wallet. You could give B to one wallet and know that if you lose funds from A it's not B's fault.
The problem that hardened derivation introduces is that if you set it up to use hardened derivation on your receiving and change chains (as m/0' and m/1' for example), then in order to fetch transaction history/balance/UTXOs, you need to reveal the extended public key for every hardened chain. Besides destroying any benefit of hardening, this is also a UX nightmare. Want to boot your wallet in watch-only mode? With hardened derivation, you need to supply an extended public key for every chain your wallet interacts with.
Wallet author here, thanks @vessenes for the comment.
Yes, as with all HD wallets, an attacker with a single private key and the the extended public key can derive all child private keys. You can read more about that aspect of HD wallets in this blog post here (https://bitcoinmagazine.com/articles/deterministic-wallets-a...).
What's important to keep in mind, is that the child keys never leave your computer. In fact, they aren't even stored in the file system. Transactions are signed locally, and only the signature (which by definition doesn't reveal the private key) is broadcast. If you dump your private keys using the wallet (option 0 for advanced users only after booting the wallet), you will see a big warning to this effect. The app won't let you dump your private keys before confirming you understand the risks.
This only matters of course if you're going into the wallet internals. If you're just using the wallet, you never have to think about this attack.
Do keep in mind from a privacy perspective though that because you're revealing your extended public key to BlockCypher, BlockCypher is able to calculate all your public bitcoin addresses.
I think the attack vector that seems very likely here is an e-mail like this:
User: Initiates Support Request around a transaction that's funky
Naughty BlockCypher Employee: "Let's try to debug this. Can you get me a private key from an early address you sent from, one which you WON'T USE AGAIN? I want to check that we're doing our math correctly. Make sure it's not an address with an existing balance!"
I propose that well over 99% of developers would think "Will I use this address again? If not, should be fine to pass on this private key."
The use of a Materialized View here is clever, but it means that every time you add a new row you have to refresh the view. For an app that accepts user-generated content, this would be very frequent since you wouldn't want users to create content and then test the search and not find it.
I don't know how optimized "refresh materialized view" is, but making this efficient is easy if you do materialized views the "old school" way, with triggers (create a table instead of a materialized view; create triggers to update based on individual rows, and a function to refresh the whole view).
It takes a while to fully understand how blockchain.info works, and how their wallet is very different from something like Coinbase/Circle/Xapo. Once you do, you realize that blockchain.info is an amazing example of the types of things that can be created with cryptocurrency that weren't possible before. They truly embody the spirit of Bitcoin.
Now if only they would support HD wallets so you don't have to backup your wallet after every transaction...
The Bitcoin private keys are created and encrypted on the user's machine, in JavaScript (Chrome extension available).
Those companies have custody of the user's private keys, meaning that there exists the potential for government seizure / hacking theft of users' coins.
In other words, exactly like the first Bitcoin wallet ever created (Satoshi's), but less secure (subject to the JavaScript being MITM'd, something breaking out of its JS sandbox and getting your private keys, keys being recovered from de-allocated memory because they can't be wiped by JS, etc.)
I'm just not a big fan of blockchain.info, so I have a strong reaction to midas's gushing above. What does blockchain.info do that "wasn't possible before"? It can't take credit for Bitcoin itself. It's like an online bank? Doesn't seem very innovative in that sense.
Again, the things that might seem like pluses (being able to access your bitcoins from any computer with an internet connection and a browser; keeping your own keys) are also really dangerous. I'd rather just use an actual application that lets me keep my own keys, without being subject to the browser's attack surface.
Heh, just noticed you work for Blockchain Ltd. I may have been a bit nicer in my last comment had I noticed. Anyway, it's worth noting that your users are still vulnerable to a Lavabit-style seizure (or hack from anyone) of your private keys, with the intent of pushing out modified JS to seize coins or track users. It's my understanding that the purpose of the Chrome extension is to prevent tampering[1], but if the authorities are really serious, they could also coerce/compromise Chrome Web Store into putting out a malicious update, signed by your seized private key.
Which authorities and laws is the company subject to?
I've always been surprised that landlords routinely return security deposits in full. After a decade of renting in multiple cities, I've always received 100% of my deposit back, even in cases where it probably would've been fair to charge me for some minor things (holes in the wall from hanging things, some small stains, etc).
There are penalties in some cases (the letter in this post says in Georgia if you get caught there's a 3x penalty), but I've never heard of those actually enforced.
In other words, there's a lot of incentive for this to happen all the time, especially since landlords don't have much of an online reputation (like restaurants). The fact that it's rare in the US is a great sign for doing business here generally.
The only time I've ever not had my full deposit back was when it was explicitly stated in my lease that I'd produce a receipt for professional carpet cleaning before I left and I didn't bother to do so.
I think in general landlords look at the "reasonable wear and tear" clauses and consider how tenant friendly the courts are. That claim is pretty vague and it's not really worth their time or the legal fees to deal with someone if they get their back up over a handful of smaller charges.
When I was younger a landlord withheld a deposit from my mother inappropriately, she went to small claims court and won and was given the option of 3x damages (she requested only the original deposit rather than the triple damages for whatever reason, but my understanding is that she was definitely given the option). This was in Massachusetts.
