Re: [Bitcoin-development] minor bitcoin-qt gripes moving BTC off specific key

[Adam Back <adam@cypherspace.org>]

At ZKS other than freedom network (ToR precursor) we had psueudonyms
associated with cookie managers.  The idea was you create pseudonyms for
different purposes to segregate your online linkability.  

	medical
	casual browsing
	social media
	private
	work
	true name

Seems to me that people are always going to make mistakes with individual
keys, even if the feature were there and accidentally link all their coin
sources together.  I presume people saw the analysis of the slush related
25k BTC theft, even seemingly the thief made possible slips while trying
presumably not to:

http://anonymity-in-bitcoin.blogspot.com/2011/07/bitcoin-is-not-anonymous.html

Does the client have any privacy algorithm (to minimise coin source cross
linking) to reach a given payment?

eg consider say I use social media, with a screen name; I collect reddit
tips etc; I pay them out to others, or use them to buy virtual goods
associated with the same purpose.  

It would be rather useful to help people achieve that, there is already the
ability to create addresses, label them.  But I think just for the GUI to
allow you to control which address the payment is from would be enough, it
doesnt seem like such a complicated concept.  And if people dont care, they
only need create one address.

Technically ZKS wasnt anonymous networking like ToR but pseudonymous
networking.  Multiple wallets for different unlinked purposes would be
somewhat analogous to ZKS freedom pseudonymous networking & cookie-jar. 
Because of the pseudonymity in ZKS misbehavers could be blocked by exit
nodes based on pseudonym.  Of course they can always create a new pseudonym
but then they lose their accumulated reputation.  You can even make people
pay for pseudonyms, as I recall users got 5 free pseudonyms but had to pay
for more.

(Though I have to admit the concensus after some years at ZKS was most end
users didnt understand what a pseudonym was!  They just wanted to be
"private" and have the computer magically solve it for them.)

If you want to simplify maybe you could consider normal (linked to AML
trading accounts, orders for physically delivered goods etc), and "private"
analogus to the private browsing mode in various browsers.  Maybe beyond 2
is an advanced feature but still available.

Adam

On Tue, May 07, 2013 at 03:19:50PM +0200, Pieter Wuille wrote:
>On Tue, May 07, 2013 at 02:16:41PM +0200, Adam Back wrote:
>> Hi
>>
>> Three minor security/other issues:
>>
>> 1. please a way to unlock the wallet without displaying wallet password in
>>    console screen (console unlock wallet, to import priv key); or
>
>I think the general solution here is providing a feature-reach Python RPC client,
>which can do things like remember passwords, command history/tab completion,
>perhaps even batch lookups of compound commands (getblock $(getblockhash X, for
>example, ...). The naive RPC client built into bitcoind is not a good fit for
>many features, as they can much more efficiently be developed outside of the
>core binary,
>
>
>> 2. a button to import a private key (and option to transfer it to another
>>    key - if you are not the sole controller the private key)
>
>I'm quite opposed to any per-key fiddling in the GUI. This will inevitably lead
>to (even more) people misunderstanding how wallets work and shooting themself in
>the foot. I don't mind an expert mode ("coin control") that enables such features,
>but in general, we should for entire-wallet export and import rather than
>individual keys.
>
>Import & sweep an address is something else, that sounds safe to.
>
>> 3. a UX way to transfer BTC off a specific adress (eg choose from
>>    address), rather than having to spend the entire wallet onto a new
>>    address, just to get BTC off a specific address.  Doing it that way has
>>    problems: creates more network traffic/bigger packets, higher fees (if
>>    any transactions are young/low confirmation), and generally damages
>>    privacy as all your funds end up linked.
>
>This belongs in coin control, IMHO.
>
>-- 
>Pieter
>