From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1VC76J-0006b0-CO for bitcoin-development@lists.sourceforge.net; Wed, 21 Aug 2013 12:01:23 +0000 X-ACL-Warn: Received: from zinan.dashjr.org ([173.242.112.54]) by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1VC76C-0003bN-Fi for bitcoin-development@lists.sourceforge.net; Wed, 21 Aug 2013 12:01:23 +0000 Received: from ishibashi.localnet (unknown [IPv6:2001:470:5:265:222:4dff:fe50:4c49]) (Authenticated sender: luke-jr) by zinan.dashjr.org (Postfix) with ESMTPSA id 2E11C27A2965; Wed, 21 Aug 2013 12:01:03 +0000 (UTC) From: "Luke-Jr" To: =?utf-8?q?Far=C3=A9?= Date: Wed, 21 Aug 2013 12:00:48 +0000 User-Agent: KMail/1.13.7 (Linux/3.9.9-gentoo; KDE/4.10.5; x86_64; ; ) References: In-Reply-To: X-PGP-Key-Fingerprint: E463 A93F 5F31 17EE DE6C 7316 BD02 9424 21F4 889F X-PGP-Key-ID: BD02942421F4889F X-PGP-Keyserver: hkp://pgp.mit.edu MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201308211200.50200.luke@dashjr.org> X-Spam-Score: -2.8 (--) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -2.8 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain X-Headers-End: 1VC76C-0003bN-Fi Cc: bitcoin-development@lists.sourceforge.net Subject: Re: [Bitcoin-development] Making bitcoin traceability harder 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, 21 Aug 2013 12:01:23 -0000 =46ar=C3=A9, Let me start out by noting that there are plenty of good ideas which could = be=20 implemented, but haven't been yet, and might take a long time to get to. Th= ere=20 are only a couple handfuls of Bitcoin developers, and even fewer of us who = are=20 able to work full-time on Bitcoin development. Perhaps surprisingly, even t= his=20 often isn't the bottleneck to new functionality: we have a terrible shortag= e=20 of testers, needed to make sure improvements don't break things in subtle=20 ways. So, while your ideas are appreciated, please keep in mind that it may= =20 take time to add them, and you can help Bitcoin development much more by=20 aiding in testing currently-written-but-untested features. With regard to your points made specifically, please note that addresses ar= e=20 intended to be single-use only. Thus, the "recurrent user of address A/B" a= re=20 not using Bitcoin correctly already, which is why they are so easy to trace= =2E=20 As far as keeping change amounts as powers of two, while I would personally= =20 love to find a justification for power-of-two amounts, I don't see how this= =20 would help privacy. I think it would actually hurt privacy, as change would= =20 now be clearly identifiable. Furthermore, it would necessarily have to thro= w=20 away excess as a transaction fee - some users would be very upset with this. As you suggest, it is of course already best practice for merchants (and=20 individuals!) to use a unique payment address for every transaction. Gavin'= s=20 payment protocol work has been making some great progress toward improving= =20 usability for this. There is also a general consensus that Bitcoin-Qt's=20 "Receive coins" tab could be significantly improved to discourage address=20 reuse further. I don't believe it has been discussed to have merchants use= =20 multiple addresses/coins for a single payment; that might be worth some=20 further discussion here as a privacy extension, but I don't think many woul= d=20 consider it an urgent issue (it may help, but probably not enough to make i= t=20 worthwhile). Luke On Wednesday, August 21, 2013 3:39:12 AM Far=C3=A9 wrote: > Dear bitcoin developers, >=20 > trading arbitrary amounts of bitcoins makes it easier to trace who > does what just by observing the amounts being traded, and where the > residual money ends up: e.g. you can identify that obviously, the > recurrent user of address A sent 2.5 bitcoins to the recurrent user of > address B, keeping the rest of his money in A. If instead bitcoin > users practice the discipline, enforced by the client software by > default, of only keeping a power-of-two amount of satoshis in use-once > wallets except where public donation addresses are meant, then tracing > suddenly becomes much harder. >=20 > Whether this particular discipline is the best to implement or not, > shouldn't bitcoin clients enforce SOME discipline that makes tracing > harder? After all we know that uniformed goons are eager to watch > who's trading with whom and to crack down on users. We shouldn't be > making it easy for them, though this will mean slightly higher > transaction cost. Merchants would then generate not one but a series > of new addresses at each transaction, and the customer would send > appropriately sized buckets of satoshis to each of the addresses. > There should just be a standard way to specify an amount and a list of > addresses as a target for payment, that merchants can communicate to > customers (though that might require e.g. higher resolution QR codes). >=20 > Has this idea already been considered before? Accepted or rejected? >=20 > =E2=80=94=E2=99=AF=C6=92 =E2=80=A2 Fran=C3=A7ois-Ren=C3=A9 =C3=90VB Ridea= u =E2=80=A2Reflection&Cybernethics=E2=80=A2 > http://fare.tunes.org Of course, Third World leaders love you. By > ascribing third world ills to First World sins, you absolve them of blame > for their countries' failure to advance. =E2=80=94 John McCarthy >=20 > -------------------------------------------------------------------------= =2D- > --- Introducing Performance Central, a new site from SourceForge and > AppDynamics. Performance Central is your source for news, insights, > analysis and resources for efficient Application Performance Management. > Visit us today! > http://pubads.g.doubleclick.net/gampad/clk?id=3D48897511&iu=3D/4140/ostg.= clktrk > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development