From: "Luke-Jr" <luke@dashjr.org>
To: =?utf-8?q?Far=C3=A9?= <fahree@gmail.com>
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: <CAN7nBXdW3H3fWHji0Hcem-eFnAxBYzmtrLBkYekVM=9DZBJVVw@mail.gmail.com>
In-Reply-To: <CAN7nBXdW3H3fWHji0Hcem-eFnAxBYzmtrLBkYekVM=9DZBJVVw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Message-Id: <201308211200.50200.luke@dashjr.org>
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Making bitcoin traceability harder
Precedence: list

=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