
bcwallet: A /dev/wallet for Bitcoin - midas
https://blog.blockcypher.com/bcwallet-a-dev-wallet-for-bitcoin-b7597d77cff9
======
ecma
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.

~~~
ape4
I was expecting

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

~~~
cyphar
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).

------
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...](https://bitcoinmagazine.com/articles/deterministic-wallets-
advantages-flaw-1385450276)).

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

------
gizi
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! ;-)

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

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

