Topic: Sweep/import private key feature request - page 4. (Read 10318 times)

I'd like to see sweep and import in the current client. "Sweep" for more typical uses like paper wallets and coupons etc. And "Import" so I can once again create vanity addresses and get them into my wallet easily.

Right now, due to encryption there seems to be no way to add a vanity address (is there?). I'd also be fine with a revert encryption option to turn it off so pywallet could once again be used to import, and then turn on encryption again. I personally don't mind using an "advanced" tool but I'm irritated that there is no way to import a vanity address now.

+1

Me too.
If you're concerned about less advanced users going crazy, just add a command line switch to enable the feature, please.
It will serve a good purpose.

Same here.

I'm really looking forward to when this is in the mainline client.

I think this is true in theory, but not in practice.  If I receive a private key in a birthday card, or from a website that sends it to me in the clear, I have no reason to expect that someone (money elves?) are going to think they should send me payments that, heaven forbid, will be lost if I don't have some automatic means to ensure they can be claimed.

I believe that the vast majority of the time a private key is passed from person to person, it's intended as a single use.  It won't be long, people will catch on to the fact that anyone who knows their private key can spend their money, and that this will be understood not as a scandal, but as part of how the system works, just like people understand that anyone who has their car keys (or functional copies thereof) can drive their car, and that that's not Honda's fault.

It reminds me of the debate over what example address should be used in the Wikipedia article about Bitcoin - until it was settled on an invalid address, people were getting caught up over making sure that the address in the article wasn't usable for accepting payments, because it would be unfair, so it was said, for someone to have their address in the Wikipedia article, because they would be the lucky but undeserving recipients of all the payments that people would be supposedly be sending there just to test their Bitcoin clients.

I think people have an inflated perception of how many people (or "money elves") out there are just looking to send money somewhere just for the sake of doing so.  I think that making an effort to ensure that payments made by money elves is as misguided as putting up sticky spiderweb nets in one's front yard just to catch ten dollar bills that people might be throwing in the street during a windstorm.  And that the worry that someone somewhere is just looking to blindly send you money to an address you never gave out as your own is totally overblown.

I agree.  It the way users think of other "codes".  Get a prepaid phone card, scratch to reveal the code, enter the code and you phone has the "value" the card is worthless.  Someone send you an Amazon giftcard, enter the code into your Amazon account and it now has the value.  The code is now worthless.

Granted there are other edge cases but it is the most common scenario and it should be simple to do in the client.  Say someday physical stores started carrying Cascius coins or other physical bitcoin manifestation.   There should be a simple mechanism to transfer that "value" from the coin to their wallet just like users do everyday w/ giftcards, xbox live cards, phone cards, etc.

Then I suggest thinking about ways to making the functionality a one-time sweep - i.e. Enter "code" to redeem/transfer stored coins to your wallet.  It shouldn't be suggested that the bitcoin address from a physical token should be reused for any reason.  The balance could just be reported by the sweep function, i.e. "You have redeemed 10 BTC that have been sent to your wallet", just like an Amazon gift code is credited to your account.  There is no need to keep the private key in the users wallet file at all - make a second wallet temporarily, rescan, submit the transaction to transfer it to an address in the users wallet and throw the temp one away. This is the manual process I have used in the past, I'm sure it could be simplified in the client.

The attack window is very small on Amazon gift code.  Once you use it (by attaching it to an amazon account) the code is worthless.

Not true w/ a private key.  Just importing private key into wallet leaves it open for attack so the attack window is no much longer (potentially months or years).  Worse if the client isn't aware this is a potentially compromised key the user could use the corresponding public key to receive funds.  So even if the address had a value 0 when attacker found private key he could keep searching block chain and steal coins into the future.

The Amazon gift code IMHO is a good counter example.  Any functionality in the client should perform similarly.

I'd send an Amazon gift code in email, how is that any different?

What about the security of users who have to futz around with swapping wallets and or scripts to move around bitcoin?  It's very tempting to just use a third party tool which lets you import private keys into an online wallet, but telling new users to trust a 3rd party is even worse given the history of mybitcoin, etc.

I think sharing a private key, be it a pass-phrase to be hashed, or a more securely generated key, is the easiest way to send bitcoin anywhere without worrying about any of the security issues present in cyberspace.  Sure, someone may eavesdrop, but the functionality benefits far outweigh the *potential* security risks.  Importing private keys manually (via sweep at the least) should definitely be an option in the client.

If anonymity is important, the ability to easily transfer and later redeem coins OUTSIDE of the blockchain (via privkey xfer) is just as important as transferring them within the network.

I'm not sure this qualifies as something we should be protecting people against, similar to what Netrin mentioned about preventing people from tying their own shoelaces together.

If someone sends a private key, or a MoneyPak card number, or their mother's maiden name over an encrypted channel, that's not Bitcoin's problem, or GreenDot's problem, or their mother's problem.  If someone gets their bitcoins stolen out of their plaintext e-mail, the situation will self-correct for the future, much like in the case where someone ties their shoes together.

... and that's exactly why I discourage people from doing things like that. It is too easy for two "copies" of a wallet to get out-of-sync.

You have to be a geek and muck around with copying the wallet.dat file from one place to another to get into trouble, and that is by design. I have no problem at all with geeky tools that let you do dangerous things (like PyWallet).

The JSON-RPC interface is trickier, because adding dangerous functionality there might encourage web services to do not-so-smart things like sending private keys over unencrypted/unprotected channels ("Email the private key as a Christmas gift" works great for a while, and then the bad guys start looking for privkeys in traffic they're sniffing and spend them before your Dad can....)

For two parties with accepting services, Mt. Gox redeemable codes are much easier and faster to transfer than real bitcoins, but would offer no benefit over private key import/export.

Could someone please explain how a 'sweep' is more simple and less confusing than 'import and transfer'?

I realise the blockchain is slow. That is an issue. But it won't be solved by complicating local key management.

This can already happen, say, if a person has a copy of their wallet on their Linux partition and another on their Windows partition. If you spend the money on the Linux partition, and then a few days later boot to Windows, it will appear you are richer than you are until the blocks all download.

And correct me if I'm wrong, but the person being sent the nonresistant half bitcoin would never see the transaction, right?

woot, bitcoin coupons accepted everywhere even in the satoshi client (key sweep), mtgox have it already

Where may be to just log on to Silk Road and type the code there for instant credit, like a gift card, which will represent a use case even average joe can understand and appreciate.

Then they will use the funds to purchase a ten dollar bill discreetly mailed to them.

I still feel that import should be a feature embedded in the main client, even if only when compiled with special switches and/or limited to the RPC. This is something I see as very important for my business ideas, but only as part of a server infrastructure.

When it comes to the client side, the GUI, then I most certainly think that import could be completely avoided by the use of sweeping. I would even argue 'KISS' and no auto resweeping should be implemented... if you know more funds are going that key way, just resweep it yourself. Since the block chain is already in the client and we can know what balance exists in that key, we could completely skip the importing and thus display of any transaction log related to the swept key, which would make things very clear to users, even the "lower grade" ones.

+1 for getting sweep in asap, it will make things easier for everyone. The only thing missing then is the (very dangerous) ability to export a private key without keeping it in wallet on the UI, so users can generate an address to send someone (like bitaddress.org does using JS), print QR code, email, whatever and then simply send funds to that address.

We can already do that last part using external tools, but these are prone to a number of attacks, scams and the like. If 'regular joe' is able to send dad some funds using a private key he generated, we'll start seeing a much, much easier way of giving away bitcoins *before* educating people about it... perception of value:

- Hey, why don't you go to this website, read about this new uber crypto pseudo-anonymous currency, browse the forum where many, many users are talking about scams, crypto algorithms, FPGAs, scams, politics and scams, then install the software, wait 2 days for the block chain to download, generate an address for me which by the way will keep changing in the UI and I can try to explain why but without knowing the basic concept behind this it will all sound very complicated and THEN I'll send you 10 btc to get you started.
.. versus ..
- Hey, here's a voucher for 10 bitcoins. You already have the "cash", now you just need to .

So while the effort is exactly the same, the latter gives you the value immediately and you are much more likely to jump the hoops

I do see the absence of these very simple axiomatic key functions as show stoppers. Why do I have to be a guru to wrap up a card to be opened in ten days which reads:


And more importantly, why must my Dad be an über-geek to receive my paper coins?

I would agree that the "sweep" should be the more general use case: someone wanting to cash in a physical bitcoin, or a "Ron Paul Cheque" or whatever else they might have received.

Sweep will keep their ledger making the most sense: they'll appear to have received funds at the time they did the sweep, not at the time that the physical bitcoin was manufactured.

Sweep is also vital for website operators to be able to accept private keys directly.  I believe this little feature will open up Bitcoin immensely, as it will free the average joe user from ever having to use software or an online wallet - he can keep all his bitcoins on paper, safe from theft or digital loss.  One can buy bitcoins at retail, and go directly to an online merchant and spend them, without any need for exchanges - a HUGE simplification.

Import is something I see as more of an advanced feature.  If we got sweep into the mainline client, and import was something that had to be patched in, I would consider it a victory.  Import is nice if (a) you like maintaining your own paper wallets and like seeing your own transactions appear in your history, and (b) if you'd like to spend straight from the paper wallet and avoid transaction fees (since a "sweep" will consume all the fee-eliminating "bitcoin days" your coins earned sitting on paper).

However, the lack of either of these isn't a show stopper - the sweep function will give the greatest utility with the least complexity.  We need the index it depends on, and then the RPC command, and then something added to the UI.

Then it appears to me that this sweep 'solution' is more confusing, error prone and retarded than anything it's trying to solve.

I believe there are only two general use case categories: (1) I created two wallets myself and want to merge them for convenience or (2) I obtained a private key or a wallet from a third party and want to merge them into my existing wallet.

The 'confusion' due to case (1) is silly. I can't even articulate in a short paragraph how someone could be confused after merging their own wallets. As for (2), perhaps some users might not realize there is a double spend (race to spend) condition, so it is wise to suggest that the user immediately transfers the funds to a new address. After doing so, life should move on; All keys should behave similarly. If another party sends money to the imported key, no problem. If the original creator of the private key forgets that he gave the key away, no problem. How is this user, the one importing, going to get confused? Because there's an earlier history?