Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YrAQd-00023A-1O for bitcoin-development@lists.sourceforge.net; Sat, 09 May 2015 19:28:51 +0000 X-ACL-Warn: Received: from mail-wi0-f172.google.com ([209.85.212.172]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YrAQa-0003Jh-Qf for bitcoin-development@lists.sourceforge.net; Sat, 09 May 2015 19:28:51 +0000 Received: by wief7 with SMTP id f7so58200615wie.0 for ; Sat, 09 May 2015 12:28:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=TVwJ5XZrUGI4AEcXZBP6MUYhF7OaviLdPU3k4tcfark=; b=P1DAOwMt+1Qq5zgUad+5qLifWdsMWE3AuXE7hPyKoKsIKGVWqehTmmflRJJcWUJS13 3bcoVVgxFSEMpZJm5kSk6XVhb/r8j40qzd92qaJpSbY65Q7zBrZehu4SDHyy/Qlb3IYk 9GqgjI2jrZHz0KG5mEyULGlwtQIRWcZBWb2vVPkDNSEquAWvJVIsi9eubWrbVxKomOOF mKBstUC3QdSI7iFmkjPZARxmQb0GwxAr8ozRfSt3iR/Urug2zPaERQigPdCt6AIIGLlX nXVIXd6lkDevxpA8DWdm4yS+3piV4tjuSQ3FxbBKEchZ5omsFnr8pONvSffS7+Dbg1E+ Qw3g== X-Gm-Message-State: ALoCoQlvdkFjOiLbVWBlYWQRggZIfLSQ7CxV4rv8KBdIVNkaQsntErxPm8p+OZvP/XjzADglYzC0 X-Received: by 10.194.157.194 with SMTP id wo2mr6983754wjb.103.1431199722852; Sat, 09 May 2015 12:28:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.246.69 with HTTP; Sat, 9 May 2015 12:28:12 -0700 (PDT) In-Reply-To: <8029969D-FD22-43F7-930D-CEC7A87CEAD5@newcastle.ac.uk> References: <3862E01F-FD0F-48F5-A6D9-F8E0FB0AB68F@newcastle.ac.uk> <8029969D-FD22-43F7-930D-CEC7A87CEAD5@newcastle.ac.uk> From: Jim Phillips Date: Sat, 9 May 2015 14:28:12 -0500 Message-ID: To: "Patrick Mccorry (PGR)" , bitcoin-development@lists.sourceforge.net Content-Type: multipart/alternative; boundary=089e013c673c156af30515ab2797 X-Spam-Score: 1.1 (+) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 1.0 HTML_MESSAGE BODY: HTML included in message 0.1 AWL AWL: Adjusted score from AWL reputation of From: address X-Headers-End: 1YrAQa-0003Jh-Qf Subject: Re: [Bitcoin-development] A suggestion for reducing the size of the UTXO database 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: Sat, 09 May 2015 19:28:51 -0000 --089e013c673c156af30515ab2797 Content-Type: text/plain; charset=UTF-8 On Sat, May 9, 2015 at 2:12 PM, Patrick Mccorry (PGR) < patrick.mccorry@newcastle.ac.uk> wrote: > Not necessarily. If you want to ensure privacy, you could limit the > selection of UTXOs to a single address, and even go so far as to send > change back to that same address. This wouldn't be as effective as > combining the UTXOs from multiple addresses, but it would help. The key is > to do everything that can be done when building a transaction to ensure > that as many inputs as possible are consolidated into as few outputs as > possible. > > > I would agree if you have multiple utxo for a single address then it > makes sense since there is no privacy loss. However sending the change back > to the same address would damage privacy (Hive does this) as it is then > obvious from looking at the transaction which output is change and which > output is sending funds. > I tend to agree with you here. But the change output could just as easily be sent to a new change address. > Also not everyone is concerned with their own privacy, and I'm not aware > of any HD-wallet implementations that won't already combine inputs from > multiple addresses within that wallet without user input. > > > For people who do not care for privacy then it would work fine. But > adding it into the wallet as default behaviour would deter those who do > care for privacy - and making it a customisable option just adds complexity > for the users. Wallets do need to combine utxo at times to spend bitcoins > which is how people can be tracked today, using the minimum set of utxo > tries to reduce the risk. > > Different wallets are targeted at different demographics. Some are geared towards more mainstream users (for whom the privacy issue is less a concern) and some (such as DarkWallet) are geared more towards the privacy advocates. These wallets may choose to set their defaults at oposite ends of the spectrum as to how they choose to select and link addresses and UTXOs, but they can all improve on their current algorithms and promote some degree of consolidation. > Additionally, large wallets that have lots of addresses owned by > multiple users like exchanges, blockchain.info, and Coinbase can > consolidate UTXOs very effectively when building transactions > > > That's true - I'm not sure how they would feel about it though. I > imagine they probably are already to minimise key management. > > That's what these discussions are for. Hopefully this thread will be seen by developers of these wallets and give them something to consider. > --089e013c673c156af30515ab2797 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= at, May 9, 2015 at 2:12 PM, Patrick Mccorry (PGR) <patrick.m= ccorry@newcastle.ac.uk> wrote:
Not necessarily. If you want to ensure privacy, you coul= d limit the selection of UTXOs to a single address, and even go so far as t= o send change back to that same address. This wouldn't be as effective as combining the UTXOs from multiple add= resses, but it would help. The key is to do everything that can be done whe= n building a transaction to ensure that as many inputs as possible are cons= olidated into as few outputs as possible. =C2=A0

 I would agree if you have multiple utxo for a single address then it makes = sense since there is no privacy loss. However sending the change back to th= e same address would damage privacy (Hive does this) as it is then obvious = from looking at the transaction which output is change and which output is sending funds.=C2=A0

I tend to agree with you here. But the ch= ange output could just as easily be sent to a new change address.=C2=A0
=C2=A0Also not everyone is conce= rned with their own privacy, and I'm not aware of any HD-wallet impleme= ntations that won't already combine inputs from multiple addresses within that wallet without user input.

For people who do not care for privacy then it would work fine.= But adding it into the wallet as default behaviour would deter those who d= o care for privacy - and making it a customisable option just adds complexi= ty for the users. Wallets do need to combine utxo at times to spend bitcoins which is how people can be tracked today, = using the minimum set of utxo tries to reduce the risk.=C2=A0

Different wallets are t= argeted at different demographics. Some are geared towards more mainstream = users (for whom the privacy issue is less a concern) and some (such as Dark= Wallet) are geared more towards the privacy advocates. These wallets may ch= oose to set their defaults at oposite ends of the spectrum as to how they c= hoose to select and link addresses and UTXOs, but they can all improve on t= heir current algorithms and promote some degree of consolidation.=C2=A0
Additionally, large wallets that have lots of addresses = owned by multiple users like exchanges,=C2=A0blockchain.info, and Coinbase can consolidate UTXOs very effectively when building transactions

That's true - I'm not sure how they would feel about it= though. I imagine they probably are already to minimise key management.=C2= =A0

That's what these d= iscussions are for. Hopefully this thread will be seen by developers of the= se wallets and give them something to consider.=C2=A0

--089e013c673c156af30515ab2797--