Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of dashjr.org
	designates 85.234.147.28 as permitted sender)
	client-ip=85.234.147.28; envelope-from=luke@dashjr.org;
	helo=zinan.dashjr.org; 
From: Luke Dashjr <luke@dashjr.org>
To: bitcoin-development@lists.sourceforge.net
Date: Fri, 6 Feb 2015 04:08:42 +0000
User-Agent: KMail/1.13.7 (Linux/3.14.27-gentoo; KDE/4.12.5; x86_64; ; )
References: <20150204142323.DEC4BE2DCDE@quidecco.de>
	<54D431FD.9020904@riseup.net>
In-Reply-To: <54D431FD.9020904@riseup.net>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: 7bit
Message-Id: <201502060408.43700.luke@dashjr.org>
Cc: Justus Ranvier <justusranvier@riseup.net>
Subject: [Bitcoin-development] [SPAM] Re: determining change addresses using
	the least significant digits
Precedence: list

On Friday, February 06, 2015 3:16:13 AM Justus Ranvier wrote:
> On 02/04/2015 02:23 PM, Isidor Zeuner wrote:
> > Hi there,
> > 
> > traditionally, the Bitcoin client strives to hide which output
> > addresses are change addresses going back to the payer. However,
> > especially with today's dynamically calculated miner fees, this may
> > often be ineffective:
> > 
> > A user sending a payment using the Bitcoin client will usually
> > enter the payment amount only up to the number of digits which are
> > considered to be significant enough. So, the least significant
> > digits will often be zero for the payment. With dynamically
> > calculated miner fees, this will often not be the case for the
> > change amount, making it easy for an observer to classify the
> > output addresses.
> > 
> > A possible approach to handle this issue would be to add a
> > randomized offset amount to the payment amount. This offset amount
> > can be small in comparison to the payment amount.
> 
> Another possible approach is to randomize the number of change outputs
> from transaction to transaction.
> 
> Doing this, it would be possible to make change outputs that mimic
> real spends (low number of s.d.)

This uses more data.

Why not just round change down (effectively rounding fee up)?

Luke