public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Adam Back <adam@cypherspace.org>
To: Pieter Wuille <pieter.wuille@gmail.com>
Cc: Bitcoin-Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] minor bitcoin-qt gripes moving BTC off specific key
Date: Tue, 7 May 2013 18:06:17 +0200	[thread overview]
Message-ID: <20130507160617.GB14418@netbook.cypherspace.org> (raw)
In-Reply-To: <20130507131948.GA4231@vps7135.xlshosting.net>

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
>



  reply	other threads:[~2013-05-07 16:06 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-07 12:16 [Bitcoin-development] minor bitcoin-qt gripes moving BTC off specific key Adam Back
2013-05-07 12:28 ` Gavin Andresen
2013-05-07 13:14   ` Wladimir
2013-05-07 13:19 ` Pieter Wuille
2013-05-07 16:06   ` Adam Back [this message]
2013-05-07 16:44 ` Craig B Agricola
2013-05-10 15:27 ` Jesus Cea

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130507160617.GB14418@netbook.cypherspace.org \
    --to=adam@cypherspace.org \
    --cc=bitcoin-development@lists.sourceforge.net \
    --cc=pieter.wuille@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox