[vessenes]

This is just a public service announcement: depending on implementation of a standard hierarchical wallet, leaking a list of public addresses and a _single_ private key can leak unlimited forward private keys, especially if the public addresses are sequentially generated ones. This was true for some implementations of BIP32, for instance.

I don't know if blockcypher's wallet is vulnerable to this attack, but it's not uncommon for an HD wallet developer's response to this to be "You should never leak a single private key, everyone knows this."

In practice, I have found developers to find this property surprising.

[midas]

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.

[vessenes]

Thanks for the note back.

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."

[vessenes]

Update, after reading the FAQ, I think that because blockcypher knows your public addresses, if they were to learn a single private key, they could regenerate the tree from that point forward.

But it would be great to get a blockcypher dev here to say for certain what the risk model is.

[ryan-c]

From BIP32:

> One weakness that may not be immediately obvious, is that knowledge of a parent extended public key plus any non-hardened private key descending from it is equivalent to knowing the parent extended private key (and thus every private and public key descending from it).

Does blockcypher get the extended public key? Can you use hardened derivation? IIRC the only reason not to use hardened derivation is so that someone else can compute more public addresses for you.

[midas]

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