bcwallet: A /dev/wallet for Bitcoin

#1

Post by midas » Mon, Mar 21, 2016, 7:26 PM UTC

bcwallet: A /dev/wallet for Bitcoin
blog.blockcypher.com

Re: bcwallet: A /dev/wallet for Bitcoin

#2

Post by vessenes » Mon, Mar 21, 2016, 8:20 PM UTC

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.

Re: bcwallet: A /dev/wallet for Bitcoin

#3

Post by vessenes » Mon, Mar 21, 2016, 8:22 PM UTC

vessenes wrote: post #2

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…

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.

Re: bcwallet: A /dev/wallet for Bitcoin

#4

Post by midas » Mon, Mar 21, 2016, 8:40 PM UTC

vessenes wrote: post #2

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…

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.

Re: bcwallet: A /dev/wallet for Bitcoin

#5

Post by ryan-c » Mon, Mar 21, 2016, 9:14 PM UTC

vessenes wrote: post #3

vessenes wrote: post #2

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…

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.

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.

Re: bcwallet: A /dev/wallet for Bitcoin

#6

Post by buss » Mon, Mar 21, 2016, 9:17 PM UTC

This looks great! (And I'm glad my library, bitmerchant, is getting some use!)

Re: bcwallet: A /dev/wallet for Bitcoin

#7

Post by midas » Mon, Mar 21, 2016, 9:20 PM UTC

buss wrote: post #6

This looks great! (And I'm glad my library, bitmerchant, is getting some use!)

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

Re: bcwallet: A /dev/wallet for Bitcoin

#8

Post by ecma » Mon, Mar 21, 2016, 9:21 PM UTC

You realize that /dev/ is for devices, not developers, right? The title of the OP is fairly misleading because of that.

Otherwise, an interesting project. I'd be interested to know why you chose Python and if/how you protect against code poisoning on the user's machine.

Re: bcwallet: A /dev/wallet for Bitcoin

#9

Post by ape4 » Mon, Mar 21, 2016, 9:24 PM UTC

ecma wrote: post #8

You realize that /dev/ is for devices, not developers, right? The title of the OP is fairly misleading because of that. Otherwise, an interesting project. I'd be interested to know why you chose Python and if/how you protect against code poisoning on the user's machine.

I was expecting

    echo give 5 bitcoin to mike > /dev/bitcoin
    head /dev/bitcoin       shows recent translations

Re: bcwallet: A /dev/wallet for Bitcoin

#10

Post by midas » Mon, Mar 21, 2016, 9:35 PM UTC

ryan-c wrote: post #5

vessenes wrote: post #3

Earlier quoted context omitted.

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.

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…

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