search

hivewallet / hive-mac

Hive Bitcoin wallet for the Mac (UNMAINTAINED)
https://mac.hivewallet.com
GNU General Public License v2.0
286 stars 55 forks source link

add a way to export the private key #368

Closed mackuba closed 10 years ago

mackuba commented 10 years ago

Seriously, this is the single most requested feature, I guess it's time to implement that.

weilu commented 10 years ago

+1

ibcrypto commented 10 years ago

Any idea of an E.T.A.?

Thank You

mackuba commented 10 years ago

I tagged it with "May" which means "let's try to do it this month".

ibcrypto commented 10 years ago

Any update on the ability to export ones private keys?

Thank You

chrismarquardt commented 10 years ago

+5

mackuba commented 10 years ago

Sorry, we didn't have time to do this yet.

ibcrypto commented 10 years ago

Thank you for the response.

Any idea of an estimated ETA? Assuming it gets added will it work for a previously created wallet?

I made the mistake of assuming this wallet included complete control of ones private keys. I need the private keys in order to claim ownership of MadeSafeCoin.

Thank You

mackuba commented 10 years ago

Hard to say, we're kind of busy with Hive Web at the moment. Yes, it would work with existing wallets - the private key can be extracted from the wallet file at any moment given a correct password, there's just no UI currently in Hive which would call the right bitcoinj code.

Currently the easiest method to extract the key is:

The copying is because Multibit has some custom extensions to the file format, and opening the Hive wallet in Multibit makes it inaccessible to Hive.

ibcrypto commented 10 years ago

Thanks for the quick reply and info!

That seems to have worked :-)

Thanks again!

ghost commented 10 years ago

Does this make sense to do given the upcoming switch to BIP32?

https://github.com/hivewallet/hive-osx/issues/106

mackuba commented 10 years ago

@mikehearn do you think such feature makes sense in the context of an HD wallet (to export a specific key from the tree, or perhaps the master key in a different form than the seed phrase)?

mikehearn commented 10 years ago

You should probably allow the user to view their seed words so they can do a paper backup. See WalletTemplate in git master for an example of how to do the GUI for this.

mackuba commented 10 years ago

But other than the seed phrase, does it make sense to let users export the master private key (or a specific leaf private key) as just a string of letters and digits?

mikehearn commented 10 years ago

What's the use case? For advanced users they can always use wallet-tool. It sounds dangerous to allow this given the properties HD wallets have w.r.t. the master public key + a leaf private key == total compromise.

Overall we need people to stop thinking in terms of keys. Long term it's not sustainable as we keep adding features.

weilu commented 10 years ago

I agree with @mikehearn about the long term goal. Where it stands right now, I think there's a use case for exporting leaf node private keys which can then be imported into non-HD wallets, but that should be more of an exist feature rather than a regular feature imho

mackuba commented 10 years ago

Ok, makes sense. I guess I was just looking for a good argument against implementing that :)

It will still probably make sense to have an export feature for that single old key, since people might want to continue using that address after they upgrade, and I'd prefer to keep the wallet BIP32-only.

silverdr commented 10 years ago

Yes, +1 one more voice. I find it really hard to advocate using Hive when the only place they can use their Hive created wallet (actually single key only, which means calling it "wallet" is a bit of overstatement ;-) is one computer. People want to use their set of keys (even static, not a new one for every transaction) on all their devices. Meaning importing/exporting private keys is a "key" feature missing from Hive.

mikehearn commented 10 years ago

No, what you want there is wallet sync, a different feature. It can be approximated today by copying keys around, but it can be dangerous when used with wallets that weren't built for it. People have actually lost money this way. Moving private keys around is just way too low level an operation for sharing money between wallets, but we don't currently have the infrastructure to do this properly.

silverdr commented 10 years ago

Short explanation: I have some coins stored on the address that Hive generated for me. What I want is the private key for that address, period.

Longer one: Why? Because for a good example I want to print it as QR code and use it for spending when I am away of the computer a particular instance of Hive is installed on. Like when I use my phone on the go. I don't need any kind of sophisticated synchronisation. My quasi-cold-storage (QR-printed key) is not only enough but actually exactly what I need. I DON'T WANT to sync private keys because my phone is surely not a safe place to keep them. I want to keep private keys separately, in cold storage and use them only when I need and for the moment I need them to sign the transaction. And I know I am not alone with this kind of workflow.

mikehearn commented 10 years ago

Yes it's a very reasonable thing to want, but like I said, it does not work unless you are amazingly careful about which wallets you use and how.

The problem is people do the following:

What happened is, in the third step the wallet generated a change address and sent the rest of the money there, and the user then destroyed the change address. The money is gone forever. This is just one example of something that can go wrong when you try and get too clever with managing keys individually. It's also one reason why modern wallets like Hive and MultiBit don't use change addresses - people just looooooove to mess around with keys and then lose their money. However this is unsustainable because using a single key eliminates all your privacy. In future all wallets will be HD and will be using randomized change addresses again. Avoiding mistakes will - once more - require weird hacks and heuristics to try and guess if you're moving keys around or restoring from backups or whatever it is you're doing.

It's really just much safer to use entirely separate wallets for now and move money around independently. The right way to implement your security mechanism is to have a regular wallet on your phone and have the qr code or (better) NFC tag contain a long random password. Then you can just touch your phone to your little pad and send money, once the app is shut down the key is gone from memory.

silverdr commented 10 years ago

A very valid point! Actually I also believe that the "new key pair for every transaction/change" should be an opt-in thing. For someone who knows better or tries to hide her tracks. But in any case, until there is a (regular) way to get the key out of Hive - it is hard to advocate its use for anything of a more noticeable value. The whole "you are your bank and you have your money wherever the internet is" just breaks apart without that possibility. Not only you have to drag your computer along wherever you go but also you can't make a paper backup (just-in-case [*]). Summing up - a "key" feature as I wrote before :-)

mikehearn commented 10 years ago

Right. So the plan is (at least for most wallet devs) that post-HD wallets you will be able to export "wallet words", and write down those twelve words with a pen and paper. That's your backup. All keys are derived from those twelve words. Additionally, wallets based on bitcoinj or the default BIP32/BIP39 stuff at least will be able to use the same words and see the same money, and keep in sync with each other via the block chain even when randomised addresses are being used.

So don't worry, we (the bitcoin community) are working on this. The upgrade to HD should not be very hard. However I think Jakub is planning to leave it for now and do other stuff, maybe with a plan to raise funds for this upgrade later.

Once done you should be able to clone wallets between devices (ignoring tx metadata) and not risk losing money. Does that sound OK?

bhuddleston42 commented 10 years ago

"The upgrade to HD should not be very hard. However I think Jakub is planning to leave it for now and do other stuff,"

Aiiighhh! That is not good news. :-)

There really needs to be a desktop HD wallet that can interoperate with something other than itself.

mikehearn commented 10 years ago

Well, you're welcome to do the upgrade yourself ;) I'm not sure how much work it involves. On the backend the upgrade is automatic. But it has implications for things like the address book.

Multibit HD is coming along quite nicely as well. So if Hive went HD with the default bitcoinj code, then it'd be able to interop with Multibit HD and Bitcoin Wallet for Android at least.

silverdr commented 10 years ago

Moving to HD implementation certainly alleviates the problem of interoperability. Yet if you look at it closer, it basically moves the problem from the "bitcoin level" keys to the "master level" keys. The good part is that the implementations are compatible and increase (somewhat) the privacy. The bad one is that this approach "shifts" the problem elsewhere, w/o giving a real solution (except the somewhat increased privacy). Or even makes false promises in terms of security - I am sure you know this for example. But - anyway - we won't solve that wide issue here. Here it is just that if there was a way for (presumably easy to implement function) exporting the key from Hive - that'd help a lot.

bhuddleston42 commented 10 years ago

Yep. I actually did read that when it came out. The "other private keys are derivable" problem has never seemed to be a serious issue unless you really want to do the whole corp governance/family part of HD (which would be cool but not, IMHO, relevant for the consumer wallet space). For the consumer wallet space, it comes down to the same prohibition "don't give people your private keys".

Benefits as I see them:

Downside:

Pure rainbows and unicorns from my perspective. :-)

silverdr commented 10 years ago

@bhuddleston42 : actually I am quite surprised that desktop wallets don't allow this kind of use case. I mean: see all the funds and transactions for all my imported addresses, without importing private keys! This is my primary use case. I do it all the time on both iOS and Android (non-HD implementations) and it works like a charm. I loaded all my active addresses into both iOS and Android devices and I can always track my funds easily. And whenever I want to spend something I grab my "credit card", which is just a printout of my one ("checking" type) private key. One second in front of the phone's lens and voila. Unless something else taps on the camera's output or the wallet is fraudulent itself - I am all happy and reasonably secure. HD (while fine - not a problem if it is there) is not needed for this kind of inter-compatibility. I'd actually be happy with Hive if it kept things simple in such way ;-)

bhuddleston42 commented 10 years ago

No question it is possible if you are willing to do the key management yourself.

HD means every address is used once and only once (which is great for privacy...not everyone cares granted) and it is largely all auto-magical goodness.

That does mean though that unless I want to manually copy/paste, print/scan, visually copy a bunch of keys I'm out of luck.

If there was even one desktop app that would let me do that (as opposed to the embarrassment of riches on the phone side) it would make my life tons easier and it absolutely does not exist (in an inter-operable way) on the Desktop side. Armory uses a different algorithm and Electrum shoves a an extra byte in things. I think Hive could get a lot of adoption if it made that possible.

But anyway, my two cents, you can give it all the consideration a non-contributing member of the peanut gallery deserves. :-)

Thanks for the opportunity to make the case.

On Thu, Sep 4, 2014 at 7:59 PM, silverdr notifications@github.com wrote:

@bhuddleston42 https://github.com/bhuddleston42 : actually I am quite surprised that desktop wallets don't allow this kind of use case. I mean: see all the funds and transactions for all my imported addresses, without importing private keys! This is my primary use case. I do it all the time on both iOS and Android (non-HD implementations) and it works like a charm. I loaded all my active addresses into both iOS and Android devices and I can always track my funds easily. And whenever I want to spend something I grab my "credit card", which is just a printout of my one ("checking" type) private key. One second in front of the phone's lens and voila. Unless something else taps on the camera's output or the wallet is fraudulent itself - I am all happy and reasonably secure. HD (while fine - not a problem if it is there) is not needed for this kind of inter-compatibility. I'd actually be happy with Hive if it kept things simple in such way ;-)

— Reply to this email directly or view it on GitHub https://github.com/hivewallet/hive-osx/issues/368#issuecomment-54566129.

mackuba commented 10 years ago

I want to print it as QR code and use it for spending when I am away of the computer a particular instance of Hive is installed on. Like when I use my phone on the go. I don't need any kind of sophisticated synchronisation. My quasi-cold-storage (QR-printed key) is not only enough but actually exactly what I need. I DON'T WANT to sync private keys because my phone is surely not a safe place to keep them.

To be honest, "I want to print my private key as a QR code to carry around so that I can use it on my mobile, but I don't want to actually import the key to my mobile" sounds like a very power user feature - I wouldn't expect many non-technical users to do such things...

Like @mikehearn says, long term the right solution is an HD wallet, copying keys manually is just a (possibly dangerous) hack. But I still want to add the export feature for the "legacy" key, if only to let people keep using the address created in Hive elsewhere.

Like both Hive and Multibit authors abandon their projects at some point and a system (or Java) update renders the existing version(s) unusable..

It's all open source, so if that happens, the worst case scenario is that someone then has to take Mike's command line wallet tool and wrap it in an easy to use GUI for extracting keys from any bitcoinj-compatible wallet files.

"The upgrade to HD should not be very hard. However I think Jakub is planning to leave it for now and do other stuff,"

Aiiighhh! That is not good news. :-)

Yeah, I had to slow down with the development now - but BIP32 is something that I definitely still have on my list (and not the "maybe someday in a perfect world" list, but the "I really plan to do this" list). The roadmap right now is more or less:

silverdr commented 10 years ago

I still want to add the export feature for the "legacy" key, if only to let people keep using the address created in Hive elsewhere.

Well, that's the important thing - thanks.

To be honest, "I want to print my private key as a QR code to carry around so that I can use it on my mobile, but I don't want to actually import the key to my mobile" sounds like a very power user feature - I wouldn't expect many non-technical users to do such things...

In fact a number of non-technical users I introduced to Bitcoin do just that and find it much more easy and understandable than everything else. That's a relatively flat learning curve when compared to what all the desktop wallets (admittedly - except Hive) throw at their faces when they first try. The explanation is so simple:

Remember that anyone who has the card, has full access to your funds, the same as if you gave her the regular debit card and the pin-code. This means keep copies of it in safe places and don't leave it anywhere where someone else can find it, including your phone or tablet or even computer.

And - guess what? - people understand this, and in minutes rather than hours (or never) they are ready to roll. Then - once they grasp the basics - you can introduce other things like increased quasi-privacy and so on.

To be completely frank - I believe that if Hive could make it the way I described above it could win hearts and coins of John Doe users. There are already many implementations that don't do that. IMHO Hive has the best potential to be the first that does if steered that direction.

But that's a discussion out of context here. Thank you, Jakub once more for having this ticket in mind.

mackuba commented 10 years ago

So when you want to pay with your mobile, you enter payment details, press a "pay" button, then a QR code scanner shows up, you pull out the printed QR code with the private key, scan it, and it signs and sends the transaction and immediately discards the scanned key? Did I get that right? Which mobile wallets have such feature?

silverdr commented 10 years ago

You got it right (well, order of actions may differ depending on the implementation) and it really is that simple. Mycelium is a good example here. There are other with slightly more difficult workflow (the key doesn't automatically get discarded for example) but when people understand the basics as described above, they also use it w/o problems. "bitWallet™" is a good example for the latter.

bhuddleston42 commented 10 years ago

"Yeah, I had to slow down with the development now - but BIP32 is something that I definitely still have on my list (and not the "maybe someday in a perfect world" list, but the "I really plan to do this" list)."

Awesome. I am glad to hear it.

mackuba commented 10 years ago

What's the current support for BIP38 in various wallets, anyone? I've tried Multibit now and it exported the encrypted key in some weird format which doesn't look like BIP38 at all, so I'm assuming it's some custom format that only Multibit supports... What would be the preferred format(s), how are other wallets handling this? I guess it'd need two options, unencrypted (WIF) / encrypted with BIP38 to be chosen by the user in the dialog?

silverdr commented 10 years ago

I believe WIF to be the most widely accepted and I find it most important to have in the first place. Given that currently there is no option at all - it will be already a huge difference. Of course I don't have anything against supporting other formats later on. If that proves to be more important than other features.

mackuba commented 10 years ago

Done, will be available in 1.4.1:

silverdr commented 10 years ago

Excellent! :-)