midas

Notes field appears to be encrypted!

How do you explain that gold is worth so much more than bitcoin and is barely ever used in transactions?

I wrote this comprehensive guide that sums up what I’ve learned in the years since I found myself having to solve this (awesome) problem: https://medium.com/@michaelflaxman/how-to-preserve-and-grow-...

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.

Does that make sense?

You can also read more in our FAQ [1].

Thanks!

[0] https://news.ycombinator.com/item?id=11331789 [1] https://github.com/blockcypher/bcwallet#faqs

Thanks @buss for your library! It's very well written, I recommend it to people all the time.

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.

You can read more in the FAQs here: https://github.com/blockcypher/bcwallet#faqs

Feel free to ask more questions anytime!

Edits: minor grammar tweaks.

Keep in mind that bitcoin transactions are not reversible, so any refund would require the merchant's approval.

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.