Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YJ0rb-00045H-Sa for bitcoin-development@lists.sourceforge.net; Wed, 04 Feb 2015 14:23:31 +0000 X-ACL-Warn: Received: from quidecco.de ([81.169.136.15]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1YJ0ra-0008Jz-K4 for bitcoin-development@lists.sourceforge.net; Wed, 04 Feb 2015 14:23:31 +0000 Received: from localhost (localhost [127.0.0.1]) by quidecco.de (Postfix) with SMTP id DEC4BE2DCDE; Wed, 4 Feb 2015 15:23:23 +0100 (CET) From: Isidor Zeuner Content-Type: text/plain; charset=UTF-8; format=flowed To: Bitcoin Development Message-Id: <20150204142323.DEC4BE2DCDE@quidecco.de> Date: Wed, 4 Feb 2015 15:23:23 +0100 (CET) X-Spam-Score: -0.0 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain 0.0 AWL AWL: Adjusted score from AWL reputation of From: address X-Headers-End: 1YJ0ra-0008Jz-K4 Subject: [Bitcoin-development] determining change addresses using the least significant digits 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: Wed, 04 Feb 2015 14:23:32 -0000 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. Any thoughts? Best regards, Isidor