bcwallet: A /dev/wallet for Bitcoin | Hacker News Reader

wallet for Bitcoin

blog.blockcypher.com

58 pointsmidas12 comments

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

Someone should write that. It shouldn't be too bad (but it would be ugly, since you'd probably have to write either something in FUSE and do some horrible bindmount magic or create a kernel module that would then have to call out to userspace).

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.

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.

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

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.

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

bcwallet is a cli with an interactive user interface. I never use a cli program that possibly could start waiting for user input. It could cause a "halting problem" in the script that incorporates it. That is literally a show stopper. Waiting for user input in a commandline script, is bug. It is not a feature. That bcwallet thing is simply full of bugs.

Browsers and things like that are valid interactive user interfaces. The cli/shell mostly exists to test stuff so that you can add it to a script, which you can add again to another script, ad nauseam ;-)

The actually interesting part in all of this has been done by bitmerchant.

Unfortunately, bitmerchant has no simple cli program attached. You need to deal with python instead, even if you have nothing to do with python. That is also a show stopper. Please, also learn haskell, ocaml, perl, lua, and two other undecisive motherfuckers, just because you want to incorporate one or two cli actions written in another scripting vernacular, into your own script.

I don't want to know in what it was written. If I cannot ignore in what it was written, I will probably avoid using it.

So, we almost had a functioning solution.

Of course, a simple man page would have been phanthastick. But ok, we are not going to incessantly demand that people work for free! ;-)

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.

Reply on news.ycombinator.com