Pages:
Author

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

donator
Activity: 1218
Merit: 1079
Gerald Davis
December 14, 2011, 09:23:14 PM
#35
What do we mean by re-sweep? Once the private key is imported, rescanned with the full latest block chain, is there any need to re-anything more before another import?
You would need to re-sweep it periodically to get any additional funds sent to it.

This seems to suggest that an swept private key would not be (even after transferring funds to a new address) imported as a first-class citizen like all other private keys in the wallet.

Hence the word SWEEP not IMPORT. 

There is no guarantee that a private key doesn't have another copy known by another party.  While some users may want to treat an external private key as an IMPORT many wouldn't.  They simply want to transfer funds to private keys they know are secure.

IMHO the ultimate (albeit potentially confusing) solution would be to both import OR sweep private keys.
hero member
Activity: 714
Merit: 500
December 14, 2011, 08:50:36 PM
#34
re-sweep brings some latency, i think piuk won't worry about this kind of things.
sr. member
Activity: 322
Merit: 251
FirstBits: 168Bc
December 14, 2011, 07:44:50 PM
#33
What do we mean by re-sweep? Once the private key is imported, rescanned with the full latest block chain, is there any need to re-anything more before another import?
You would need to re-sweep it periodically to get any additional funds sent to it.

This seems to suggest that an swept private key would not be (even after transferring funds to a new address) imported as a first-class citizen like all other private keys in the wallet.
legendary
Activity: 924
Merit: 1004
Firstbits: 1pirata
December 14, 2011, 07:33:35 PM
#32
If you're an uber-geek and know what you're doing, then you should use geeky, dangerous tools like PyWallet to do what you want to do.

Agreed, except those doing web services that might depend on this feature are left with either non-official clients or patching the official ones, which gets complicated to maintain in a stable, well tested way.

The current import patch needs work to be of practical use to web services-- it does a scan of the entire blockchain to find transactions to the newly imported key (and keeps the wallet locked that entire time).  For any sweep/import solution to be useful for more than once-in-a-blue-moon use, an index of pubkeys to transactions involving those keys should be kept.

It seems to me the "sweep now, and re-sweep every once-in-a-while" functionality would work nicely for web services. Can you describe a use case that wouldn't work?

would be possible to have the basic sweep feature implemented ? in some kind of "advanced features" section and all the required warnings. And yes "sweep" seems to be more correct describing the action done with they priv key.
full member
Activity: 154
Merit: 102
Bitcoin!
December 14, 2011, 04:45:28 PM
#31
What do we mean by re-sweep? Once the private key is imported, rescanned with the full latest block chain, is there any need to re-anything more before another import?
You would need to re-sweep it periodically to get any additional funds sent to it.
legendary
Activity: 1540
Merit: 1002
December 14, 2011, 04:37:00 PM
#30
The current import patch needs work to be of practical use to web services-- it does a scan of the entire blockchain to find transactions to the newly imported key (and keeps the wallet locked that entire time).  For any sweep/import solution to be useful for more than once-in-a-blue-moon use, an index of pubkeys to transactions involving those keys should be kept.

It seems to me the "sweep now, and re-sweep every once-in-a-while" functionality would work nicely for web services. Can you describe a use case that wouldn't work?

Yes I can. It's just hard to do so without giving away too much of a potential project idea, but better support trumps business secrecy any day in my book so; I have a storage of priv keys, generated offline, and I need to hot include these on a running server. Now mind you I own these keys, I generated them myself, but they do not exist in a wallet, that would be VERY impractical.

I could take the server down, use pywallet, start with -rescan. But I don't want to HAVE to batch imports, meaning a rescan for each key. Because I know at which time point the key was first used (and most times it will not have been used at all, thus no -rescan is needed), and that is very easy to find when unknown if the blockchain is properly indexed, so I can request a rescan from block nr X.

This is the one case I have where sweep would simply not fit, but for every other case I've come across and use a custom patched client for, sweep would be just fine. Though sweep with an option to keep the key in the wallet but *not* resweep would work just as well.
sr. member
Activity: 322
Merit: 251
FirstBits: 168Bc
December 14, 2011, 04:21:01 PM
#29
What do we mean by re-sweep? Once the private key is imported, rescanned with the full latest block chain, is there any need to re-anything more before another import?
legendary
Activity: 1652
Merit: 2301
Chief Scientist
December 14, 2011, 04:14:02 PM
#28
If you're an uber-geek and know what you're doing, then you should use geeky, dangerous tools like PyWallet to do what you want to do.

Agreed, except those doing web services that might depend on this feature are left with either non-official clients or patching the official ones, which gets complicated to maintain in a stable, well tested way.

The current import patch needs work to be of practical use to web services-- it does a scan of the entire blockchain to find transactions to the newly imported key (and keeps the wallet locked that entire time).  For any sweep/import solution to be useful for more than once-in-a-blue-moon use, an index of pubkeys to transactions involving those keys should be kept.

It seems to me the "sweep now, and re-sweep every once-in-a-while" functionality would work nicely for web services. Can you describe a use case that wouldn't work?
full member
Activity: 176
Merit: 100
December 14, 2011, 04:04:01 PM
#27
If there is a debate on importing/sweeping then how about a limited use case of sending funds to your wallet from a private key.

Call it "deposit balance from private key".
User clicks "deposit balance from private key" from the menu, enters key, and the wallet advises user of the balance w/ a "do you wish to transfer the 123.45 BTC from this private key to your wallet."



Would be useful for "redeeming" physical bitcoins (like Cascius coins).

I think deposit would be the best thing to call it, but it should still collect funds sent to that key and send them to a key generated within the client.
donator
Activity: 1218
Merit: 1079
Gerald Davis
December 14, 2011, 03:56:03 PM
#26
If there is a debate on importing/sweeping then how about a limited use case of sending funds to your wallet from a private key.

Call it "deposit balance from private key".
User clicks "deposit balance from private key" from the menu, enters key, and the wallet advises user of the balance w/ a "do you wish to transfer the 123.45 BTC from this private key to your wallet."



Would be useful for "redeeming" physical bitcoins (like Cascius coins).
sr. member
Activity: 322
Merit: 251
FirstBits: 168Bc
December 14, 2011, 03:52:21 PM
#25
I like "sweep" -- it has very clear semantics that I think users will understand:  "Take all the funds that were sent THERE, and send them to me RIGHT NOW."
I like "sweep" as well, and I think it would meet all the use cases I have for importing, as long as it keeps a copy of the private keys that have been swept and implements "auto sweep" on them fairly often (once a day?).

It would be nice if there were still an option to do a clean import. It can be hidden under an advanced tab, with a checkbox confirming that yes I really understand the implications and yes I know it is not recommended and that a kitten will die.

A sweep to a single address has side effects that a non-guru, but still savvy user, might not appreciate, such as merging all transaction history into a single IDENTITY, throwing out any pretense of plausible anonymity.
donator
Activity: 1218
Merit: 1079
Gerald Davis
December 14, 2011, 03:51:46 PM
#24
Gavin, I think it's important to remember that as developers we will never be able to protect all the stupid people from all the mistakes they might make.  We can and should try an make the product as robust and foolproof as possible, but even more importantly, we need to make the product as powerful and as flexible as possible at the same time.  If there is a clash between the two, we should choose to make the product more powerful, instead of fighting the futile battle of protecting stupid people from themselves.

Or put another way (a classic software development quote...

Quote
Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots.  So far, the Universe is winning.
  ~Rich Cook
legendary
Activity: 1540
Merit: 1002
December 14, 2011, 03:46:42 PM
#23

If you're an uber-geek and know what you're doing, then you should use geeky, dangerous tools like PyWallet to do what you want to do.


Agreed, except those doing web services that might depend on this feature are left with either non-official clients or patching the official ones, which gets complicated to maintain in a stable, well tested way.
full member
Activity: 154
Merit: 102
Bitcoin!
December 14, 2011, 03:43:23 PM
#22
I don't like "import" -- it has muddy semantics that I think users will not understand.  "You kind-of-sort-of own the funds that were sent THERE, unless somebody else happens to have a copy of THERE that you may or may not know about."
I don't quite agree, since if I securely generate a paper wallet, I know I am the only one with the private key.  But, I concede the point.

I like "sweep" -- it has very clear semantics that I think users will understand:  "Take all the funds that were sent THERE, and send them to me RIGHT NOW."

Automatic sweep-every-once-in-a-while functionality would be fine, as long as it was coded properly (sweeps should only be done if you have the full block-chain, not if you're busy catching up, and shouldn't be done immediately to avoid a flurry of accidental double-spends if you have several wallets setup to sweep the same key(s)).
I like "sweep" as well, and I think it would meet all the use cases I have for importing, as long as it keeps a copy of the private keys that have been swept and implements "auto sweep" on them fairly often (once a day?).
sr. member
Activity: 322
Merit: 251
FirstBits: 168Bc
December 14, 2011, 03:38:41 PM
#21
Quote


Would you like to secure these coins with a new private address? This is recommended, especially if you've received coins from another party.

([ Secure! ])    [no]



Default Secure (transfer coins). I see no realistic use case in which a user would be confused, no more than not having this feature (managing multiple wallets is much more confusing than merged wallets).
legendary
Activity: 1652
Merit: 2301
Chief Scientist
December 14, 2011, 03:35:00 PM
#20
I like "sweep" -- it has very clear semantics that I think users will understand:  "Take all the funds that were sent THERE, and send them to me RIGHT NOW."

Automatic sweep-every-once-in-a-while functionality would be fine, as long as it was coded properly (sweeps should only be done if you have the full block-chain, not if you're busy catching up, and shouldn't be done immediately to avoid a flurry of accidental double-spends if you have several wallets setup to sweep the same key(s)).

I don't like "import" -- it has muddy semantics that I think users will not understand.  "You kind-of-sort-of own the funds that were sent THERE, unless somebody else happens to have a copy of THERE that you may or may not know about."

Import is bad because it can lead to a situation like:
 Start up bitcoin, see you have 1 BTC in your wallet (sent to an imported private key in block 111,000)
 So you send half of it to your friend to pay for lunch.
 ... bitcoin chugs away, and it turns out that 1BTC was spent already, in block 190,000.
 User is all "wtf??? where did my BTC go???"

If you're an uber-geek and know what you're doing, then you should use geeky, dangerous tools like PyWallet to do what you want to do.
legendary
Activity: 1540
Merit: 1002
December 14, 2011, 03:20:00 PM
#19
A product with both 'foolproof' and 'powerful' is possible in theory. Let those that are capable of compiling switch the 'advanced' mode on, though of course there will be someone sending ready built 'advanced' versions to foolish users.

Make it a configuration that you have to edit by hand, and make the first run of the client show a bit red flashing 1999-web-page-like dialog stating they WILL screw up eventually, so be careful.

Not giving the option by default is a smart move, maybe even only give using RPC to start with and see how inventive users get. But not giving the option at all because it might be dangerous... I gave a user an address for him to send me 70 coins for some stuff I sold... but I gave one of my *sending* addresses instead of *receiving*. I was stupid, but what allowed this to happen? Was it the copy to clipboard feature? The address book? Should we get rid of both?

full member
Activity: 154
Merit: 102
Bitcoin!
December 14, 2011, 03:13:29 PM
#18
Gavin, I think it's important to remember that as developers we will never be able to protect all the stupid people from all the mistakes they might make.  We can and should try an make the product as robust and foolproof as possible, but even more importantly, we need to make the product as powerful and as flexible as possible at the same time.  If there is a clash between the two, we should choose to make the product more powerful, instead of fighting the futile battle of protecting stupid people from themselves.
sr. member
Activity: 322
Merit: 251
FirstBits: 168Bc
December 14, 2011, 03:13:05 PM
#17
Anyone clever enough to have two wallets is clever enough to understand the implications of merging them. The utility of merging, upgrading backed up wallets, splitting, side-channel transactions, etc far outweighs a bit of potential confusion.
full member
Activity: 154
Merit: 102
Bitcoin!
December 14, 2011, 03:05:15 PM
#16
In either case, you keep the imported private key in the wallet, in case more BTC is sent to it.

So what happens when two users import the same private key into their wallets?
 (or you accidently or on-purpose import the same private key into two of your wallets?)

You can say "Don't Do That", but if they CAN do that, then they WILL.

Then whoever spends them or sends them to another address first keeps them.  I honestly don't see a problem with that-- that's why you'd have the check box to send the funds to a new key if the one being imported may be known to others.
Pages:
Jump to: