bcwallet: A /dev/wallet for Bitcoin(blog.blockcypher.com) |
bcwallet: A /dev/wallet for Bitcoin(blog.blockcypher.com) |
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.
echo give 5 bitcoin to mike > /dev/bitcoin
head /dev/bitcoin shows recent translationsI 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.
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.
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."
But it would be great to get a blockcypher dev here to say for certain what the risk model is.
> 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.
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! ;-)
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