From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1UZkPQ-000440-TR for bitcoin-development@lists.sourceforge.net; Tue, 07 May 2013 16:06:32 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 74.125.83.43 as permitted sender) client-ip=74.125.83.43; envelope-from=adam.back@gmail.com; helo=mail-ee0-f43.google.com; Received: from mail-ee0-f43.google.com ([74.125.83.43]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1UZkPN-0006AA-4z for bitcoin-development@lists.sourceforge.net; Tue, 07 May 2013 16:06:32 +0000 Received: by mail-ee0-f43.google.com with SMTP id b15so416307eek.30 for ; Tue, 07 May 2013 09:06:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent:x-hashcash:x-hashcash:x-hashcash; bh=OktyJ9Bt71SR0aP8USfXWQAFy4us1jPhU0jMmdggf9w=; b=VZcRfVutsI06izON/awNTo9veUAMYib9QCpkMsMo+gt6nxqOfDOk2DoSyYfPflIipA +1/UiI5AsC/S0hiS7OyUdTHP6lFlUE3noHmPnKvRgqlQzxKfCENXWpCYKIUBBB8QHXU7 CoCjBkSV8q/75yJO/3f72Qj+G2QM+ABKCbpSAoaUSkGCzjDVqlf/AwBKQZrCY8B+5KEd 45e8MWhk5vfgyWgBcv1Yu5Hjt9BGdyhnL6E5EC6DRS9wY63AGib/YD39h+lpera+GvD3 TZIaPkUBPokgs0BC11aEvCmQLWly6Xj5tarreUXnfV8QPzGCaxoPQzlC/Y8wU9u4X8jy gn5A== X-Received: by 10.14.99.198 with SMTP id x46mr6593173eef.38.1367942782790; Tue, 07 May 2013 09:06:22 -0700 (PDT) Received: from netbook (c83-90.i07-21.onvol.net. [92.251.83.90]) by mx.google.com with ESMTPSA id t9sm27717684eeo.11.2013.05.07.09.06.21 for (version=TLSv1.1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 07 May 2013 09:06:21 -0700 (PDT) Received: by netbook (Postfix, from userid 1000) id BD31F2E0619; Tue, 7 May 2013 18:06:19 +0200 (CEST) Received: by flare (hashcash-sendmail, from uid 1000); Tue, 7 May 2013 18:06:17 +0200 Date: Tue, 7 May 2013 18:06:17 +0200 From: Adam Back To: Pieter Wuille Message-ID: <20130507160617.GB14418@netbook.cypherspace.org> References: <20130507121641.GA11770@netbook.cypherspace.org> <20130507131948.GA4231@vps7135.xlshosting.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20130507131948.GA4231@vps7135.xlshosting.net> User-Agent: Mutt/1.5.21 (2010-09-15) X-Hashcash: 1:20:130507:pieter.wuille@gmail.com::LogMqdRtCJFXjqrT:00000000000000 0000000000000000000000000ZzQ X-Hashcash: 1:20:130507:bitcoin-development@lists.sourceforge.net::pKq1/rAP7XE1y tP1:000000000000000000007BEo X-Hashcash: 1:20:130507:adam@cypherspace.org::XW3o2MG2cYu4nV9+:00000000000000000 0000000000000000000000004YuI X-Spam-Score: -1.5 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (adam.back[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record X-Headers-End: 1UZkPN-0006AA-4z Cc: Bitcoin-Dev Subject: Re: [Bitcoin-development] minor bitcoin-qt gripes moving BTC off specific key X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 16:06:33 -0000 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 >