[Bitcoin-development] Making bitcoin traceability harder

[Bitcoin-development] Making bitcoin traceability harder

[Faré]

Dear bitcoin developers,

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.

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).

Has this idea already been considered before? Accepted or rejected?

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• 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. — John McCarthy

Re: [Bitcoin-development] Making bitcoin traceability harder

[Luke-Jr]

Faré,

Let me start out by noting that there are plenty of good ideas which could be 
implemented, but haven't been yet, and might take a long time to get to. There 
are only a couple handfuls of Bitcoin developers, and even fewer of us who are 
able to work full-time on Bitcoin development. Perhaps surprisingly, even this 
often isn't the bottleneck to new functionality: we have a terrible shortage 
of testers, needed to make sure improvements don't break things in subtle 
ways. So, while your ideas are appreciated, please keep in mind that it may 
take time to add them, and you can help Bitcoin development much more by 
aiding in testing currently-written-but-untested features.

With regard to your points made specifically, please note that addresses are 
intended to be single-use only. Thus, the "recurrent user of address A/B" are 
not using Bitcoin correctly already, which is why they are so easy to trace. 
As far as keeping change amounts as powers of two, while I would personally 
love to find a justification for power-of-two amounts, I don't see how this 
would help privacy. I think it would actually hurt privacy, as change would 
now be clearly identifiable. Furthermore, it would necessarily have to throw 
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 
individuals!) to use a unique payment address for every transaction. Gavin's 
payment protocol work has been making some great progress toward improving 
usability for this. There is also a general consensus that Bitcoin-Qt's 
"Receive coins" tab could be significantly improved to discourage address 
reuse further. I don't believe it has been discussed to have merchants use 
multiple addresses/coins for a single payment; that might be worth some 
further discussion here as a privacy extension, but I don't think many would 
consider it an urgent issue (it may help, but probably not enough to make it 
worthwhile).

Luke


On Wednesday, August 21, 2013 3:39:12 AM Faré wrote:
> Dear bitcoin developers,
> 
> 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.
> 
> 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).
> 
> Has this idea already been considered before? Accepted or rejected?
> 
> —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics•
> 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. — John McCarthy
> 
> ---------------------------------------------------------------------------
> --- 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=48897511&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Making bitcoin traceability harder

[Faré]

Dear Luke,

thanks for your prompt response.

On Wed, Aug 21, 2013 at 8:00 AM, Luke-Jr <luke@dashjr.org> wrote:
> Let me start out by noting that there are plenty of good ideas which could be
> implemented, but haven't been yet, and might take a long time to get to. There
> are only a couple handfuls of Bitcoin developers, and even fewer of us who are
> able to work full-time on Bitcoin development. Perhaps surprisingly, even this
> often isn't the bottleneck to new functionality: we have a terrible shortage
> of testers, needed to make sure improvements don't break things in subtle
> ways. So, while your ideas are appreciated, please keep in mind that it may
> take time to add them, and you can help Bitcoin development much more by
> aiding in testing currently-written-but-untested features.
>
That's a useful reminder.

> With regard to your points made specifically, please note that addresses are
> intended to be single-use only. Thus, the "recurrent user of address A/B" are
> not using Bitcoin correctly already, which is why they are so easy to trace.
> As far as keeping change amounts as powers of two, while I would personally
> love to find a justification for power-of-two amounts, I don't see how this
> would help privacy. I think it would actually hurt privacy, as change would
> now be clearly identifiable. Furthermore, it would necessarily have to throw
> away excess as a transaction fee - some users would be very upset with this.
>
Even when you don't reuse your address, by considering the amounts in
a transaction, it is often easy to identify what is the main amount
and what is the residual. e.g. "oh, he spent $1.99 worth of bitcoin
out of his big bitcoin address, so the $1.99 is being paid, and the
rest is still the same person", and so trace identities. By using
power-of-two buckets (based on the binary expansion of the amount), it
becomes harder to do amount analysis. Sometimes, buckets are joined or
split, but that still doesn't help much identify how several buckets
combine into one transaction. As for transaction fees — indeed, they
should probably be paid in separate small-bucket transactions. I don't
see any particular difficulty about it.

> As you suggest, it is of course already best practice for merchants (and
> individuals!) to use a unique payment address for every transaction. Gavin's
> payment protocol work has been making some great progress toward improving
> usability for this. There is also a general consensus that Bitcoin-Qt's
> "Receive coins" tab could be significantly improved to discourage address
> reuse further. I don't believe it has been discussed to have merchants use
> multiple addresses/coins for a single payment; that might be worth some
> further discussion here as a privacy extension, but I don't think many would
> consider it an urgent issue (it may help, but probably not enough to make it
> worthwhile).
>
There is nothing urgent indeed. Nevertheless, I fear that the current
usage pattern is too easily traceable, and that tweaks such as the one
I'm proposing could make amount-based tracing much harder.

Thanks for your hard work!

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
He wa'n't no common dog, he wa'n't no mongrel; he was a composite.
A composite dog is a dog that is made up of all the valuable qualities
that's in the dog breed — kind of a syndicate; and a mongrel is made up
of all riffraff that's left over.  — Mark Twain