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

Can't wait til a granny-safe version of this is ready!

Indeed.  I'm just about to do a testing release, which has most of the Armory feature list implemented -- including address sweeping and importing.  In fact, the design of that dialog was based on this thread!  I had to disable zero-confirmation transactions until I have time to put in the "correct" solution, but just about everything else is working, or at least usable.  

I've already pulled in a bunch of VanityGen addresses and use it to manage donations.  Then I used the key-backup dialog to print out a list of imported keys onto a single sheet of paper, and tucked away in a safe place so I can never lose them.  

And yes, it supports mini-private key format, and the Base58 private key format [0x80 + 32-byte-priv-key + 4-byte-chksum], as well as raw hex dumps of private keys, and it even makes sure the private key is in the right endianness (assuming you know what the Base58 address is supposed to look like)!  

Now that offline transactions are working, I'll be releasing build-instructions shortly!

Just in case anyone here did not see the new Armory client or note its features. It includes a pretty nifty sweep/import feature.
thread here; https://bitcointalksearch.org/topic/armory-discussion-thread-56424

This.

Doesn't this just need a flag on an address that indicates whether it should be swept periodically (starting with right now)? You should be able to tag any address with this flag as it's probably useful for various situations. I could see the flag having a minimum value. In fact, simply a "sweep when" value attached to each address would do. When zero it has no effect but above zero it sweeps if funds arrive/accumulate. Maybe you set this threshold when you import according to how you created and will use that key.

That makes sense.

I could see auto-sweep web services being an alternative solution.  You provide a webservice one or more private keys and a public address from a secure wallet.  The service could continually auto-sweep funds for a small fee. Granted there is an element of trust but given that any theft would be obvious and at any time the service would only have access to funds in transit the risk is less than say an ewallet.

+1 sounds nice

Agreed.  But for above-mentioned reasons, all keys that have been swept should be kept hidden in an advanced interface somewhere, where you can periodically (or automatically) check and see if funds have been added to any of them.

What if I sweep the private key and transfer my 20 BTC, at a later date you assume you can send me an additional payment using the same public address as before, but I no longer have the private key? Of course, YOU personally wouldn't do this, but people might.  This is why I'd like to keep the insecure private keys around to check/resweep them at a later date, if necessary.

Easy.  I generate a (secure) vanity address to receive donations.  I publish the address all over the place and people start donating to it.  I then inadvertantly/unthinkingly/stupidly email the private key as plain text to myself for whatever reason.  The private key is now no longer secure, but I would still like to keep sweeping it to get any additional funds sent to it.  Even if I change my public donation address, it is cached all over the place and people have it saved, etc, so I will keep receiving donations there for some time or even indefinitely. 

Emailing the private key as plain text is only one example. What if the computer storing your unencrypted wallet.dat gets a virus/trojan?  What if the computer gets stolen?  I know you and I would never mail a plain text private key, not would we ever get viruses (we're careful, after all), but there are dozens of scenarios where the secure private keys that correspond to public keys that may continue to receive funds could become compromised and fall into the "insecure" private key category.

I've generated multiple wallets over the year, created on different machines, with different client versions, with different levels of trust. I've transfered those funds to my latest and greatest secure wallets, but every once in a while I go through this corpus of wallets looking for coins. I have no specific reason not to trust those old keys, but for example, one was made on a Windows machine at work when I was very new to bitcoin. It doesn't have the same level of security in my mind as my wallet on an offline private Linux box.

I will likely import and merge all of my old wallets into a single untrusted/old wallet. But it really should not be difficult to continually sweep those keys. I think it's a reasonable use case, with a relaxed definition of 'insecure'.


You are taking my 'off the top of my head' example too far. But yet you admit the problem of social engineering through code. You can't prevent users from doing what they want. You should give them tools they don't need to break, but might learn to understand.

That would be insecure.  While you could do that if the wallet didn't make it easy to do so you likely wouldn't and thus would choose some mechanism that is secure. 

In essence the user is incorrectly trusting a key which shouldn't be trusted.   Since the user doesn't realize the risk wouldn't he simply IMPORT it

Trusted Key = IMPORT
Untrusted Key = SWEEP

Granted that would be bad too but not much worse and maybe a warning on the import option makes him pick a more secure way to handle payments.

If something is a security risk, or it's a pain in the ass to code without any immediate benefit, that's fair, but I do not like the question "Is it something we want to support and encourage?"

Rather than the recipient republishing an address received from an unknown untrusted entity, you could vaguely imagine cases where trusted (but potentially incompetent) users share some fund. Suppose my girlfriend and I have a bake sale and share an address, either one of us could sweep the keys. Of course there may be better ways to handle this particular instance, but I only use it as an example legitimate case.

Not even close.  A private key someone else has access to is ABSOLUTELY INSECURE.  Period.  It has absolutely no security value what so ever.  Funds can be stolen at will and that action would be anonymous, impossible to prove, and irrevocable. 

To avoid theft, or fraud you are simply trusting the person(s) who had access to the key won't choose to rob you.  They might but it won't be due to any cryptographic strength.

btc_artist, what if the client maintained a wallet.dat and untrusted.dat? The coins in untrusted.dat would never appear in the client balance. A menu option would allow for 'Sweep Untrusted Keys'. An opt-in automatic asynchronous process could sweep periodically. If you wanted to interact with the keys directly, you could simply backup and rename untrusted.dat.



It IS published in the block chain. Who knows where else it may exist in print.



I think you are putting too much emphasis on 'insecure'. In PGP parlance, it would only not be ULTIMATELY trusted.

Let us not be limited to use cases we can currently imagine.

Why would you do that?

If the private key is INSECURE why would you publish it for future payments?
If the private key is SECURE why do you need to sweep it (just import it as a "full trust" private key)?

We are talking about a key that is simultaneously insecure and published for future payment. The question would be why?  It would be like me selling you a partially used prepaid phone card (the pincode has been scratched off).   You have no security.  While you may use it for the current phone call (and thus end our risk) it is another thing to think you would save that phone card so you can recharge it later (put future funds at risk).  Just buy a new phone card. 

An example in case I am being unclear:
I owe you 20 BTC.  I fund a private key w/ 20 BTC, print it out and give it to you.  This being an unsecure private key you sweep it, and throw the private key away.  One use, never use it again like a spent gift card or prepaid phone card.  Your risk is limited to the current transaction (like any unverified transaction).    The same day you decide to make a donation address.  You take a DIFFERENT SECURE address generated by your wallet and publish that one.  By throwing away the insecure address and using secure addresses for publishing you ensure the wallet remains secure not just now but in the future as well.

You seem to indicate you would do this instead:
I owe you 20 BTC.  I fund a private key w/ 20 BTC, print it out and give it to you.  I know the private key and can steal funds from it at anytime.  Despite the very obvious security risk, you generate a public Bitcoin address from the insecure key and decide to publish this one as a donation address.  You now have no security.  Any future funds sent to that address can be stolen at will.

Can you imagine a realistic scenario where someone would take an insecure private key, generate a public address from it, publish that so there may be future funds coming in and then sweep it, and need to keep track of that insecure private key into perpetuity?  Is it common enough to build that functionality into a wallet?  Is it something we want to support and encourage?

The abstraction was definitely intentional, but I'm not sure it was good. It works well for casual users (the majority), but for one has fundamental privacy concerns.  So for some (most?) it would be noise, and for others it would be essential.  I don't see the problem with having the funds to address breakdown in an advanced tab that casual users can ignore. 

I assume a redeemed phone card can never have funds placed in it again.  If I were to publish an address for payment, then sweep the private key to get the funds, who is to say that someone will never send funds to that (published) address again?

I would have problem with that but it seems excessive.  I mean it would be like when I use a prepaid card for a cellphone my phone showing my current balance, transactions, and expiration and then having a separate section which shows me all the prepaid codes and their current value ($0.00).

Can you think of any instance where you would receive an insecure funded private key and you anticipate someone sending you funds there in the future? Why? Why not just use a new "disposable" funded private key? 

I really think most users have no reason to look at a list of spent 0 BTC insecure private keys anymore than they keep track of spent giftcard or phone cards.

Well "bills" are an incomplete abstraction of wealth.  They only come in certain sizes, you need to deal w/ counterfeits, you can accidentally give the wrong one, you can make mistakes when making change, etc.

None of those concerns are relevent w/ Bitcoin.  For 99% of users the per address value of their wealth distribution isn't material.  They only want to know three things
1) how much wealth do I have?
2) did that transaction clear?
3) are my funds safe?

The abstraction of addresses into a wallet was intentional and good IMHO.  There may be isolated cases where knowing you have 1.28928392729873894 BTC in address a, 0.1827789347389 BTC in address b ...  (hundreds if not more addresses later) .... etc  is valuable but for most people it is just noise.  It doesn't answer the three questions above.

I agree mostly.  Why not have:

1. IMPORT and keep the key as a first-class citizen in your wallet.
2. SWEEP key and TRANSFER any funds to your wallet (or another arbitrary address). There would be a separate interface (completely independent from the wallet) in the program showing a list of all keys that have been swept, and showing any balance in each of them. This would not be included in the wallets balance, unless you SWEEP them again.

This is my way of thinking as well. But we must admit that we are not the typical user. I have little understanding of the average user's mental model (of any technology, whether email or electricity) and I imagine they have none at all but it is hopeless to try to educate them at this phase. Shouldn't the 'coin control' patch give you what you want?

I'm actually pretty cool with the idea of a 'trusted wallet' and an 'untrusted wallet'. I would like a service that does pull/sweep untrusted keys periodically. In fact, I'd like a service that randomly scrambles all of my coins while I am sleeping. These features are possible but perhaps none of them are on topic with respect to 'sweep/import private keys'.