Recipe for limiting bitcoin trackability

[wwh]

Recipe for Bitcoin limiting trackability

- Fred has 10 BTC addresses with 1 BTC each
- He wants to buy a widget from Sally for 2 BTC.
- Fred creates a transaction where the 10 BTC from his account are sent to
  10 different BTC addresses.
- 2 of those addresses are generated by Sally
- 8 of those addresses are generated by Fred
- Fred and Sally can now create new bitcoin addresses,
  one address for each coin, and send their coins to the new addresses.
- The laundering transactions can be sent at random time
- The amount of coins laundered in each laundering transaction can
  either be random or at amounts common to other transaction on the network
- Neith Fred or Sally would be able to know if the coins were being spent
  or just laundered

Anyone see any holes in this strategy?  I'm thinking about implementing it as an interface on top of the Bitcoin client.

Thanks!

[1715399872]

1715399872

[1715399872]

1715399872

[1715399872]

1715399872

[wwh]

Also, assume addresses are only used once and the parties forget the addresses they previously created for themselves.

[wwh]

Also, assume a large number of transactions are done this way on the network.

[Gavin Andresen]

Start here for possible holes:
  http://scholar.google.com/scholar?q=%22mix+networks%22

[ByteCoin]

Recipe for Bitcoin limiting trackability
...
Anyone see any holes in this strategy?  I'm thinking about implementing it as an interface on top of the Bitcoin client.

The scheme outlined in http://forum.bitcoin.org/index.php?topic=5965.0 gives much better anonymity guarantees than any solution based on mix nets. Mix nets also inflate the number of transactions needed to transfer bitcoins.

There's a strong tendency to succumb to the "not invented here" syndrome when choosing what technology to implement. Fight it!

ByteCoin

[wwh]

Gavin, "Go read some academic literature to find out" sounds much more promising than "I can easily see through that technique by doing X", thanks.

ByteCoin, your technique is interesting.  It's more efficient with addresses than what I came up with, and it can limit tracking of transactions to/from publicly published bitcoin addresses.  However, the parties to the transaction have at least some ability to link the other's future transactions(see the example below).

1. Sender sends 100 BTC to receiver through the transfer address.
2. Receiver moves the 100 BTC from the transfer address to a new address they control(address1).
3. Receiver makes a payment to 3rd-party address with "change" going to a new address(address2) receiver controls.
4. Sender can see the transaction but they have to guess which address belongs to receiver.  They don't know who 3rd-party is, either.
5. Sender makes a second payment to receiver via transfer address.
6. Receiver moves the second payment to address3.
7. Receiver makes a payment to 4th-party using address2 and address3 with the "change" going to address4.
8. Sender can now link address2 to receiver.

So far it seems to me that the best way to limit block chain tracking without using a third party "proxy" is to split a transaction into smaller "network standard size" chunks that get sent to multiple addresses.

[wwh]

I thought more about my proposition, and transaction fees throw a wrench in the plan.

I came up with a new idea, though.  Currently, the each block includes a list of transactions like this:

trans1, fee, from accts/amts, to accts/amts
trans2, fee, from accts/amts, to accts/amts
... etc

Wouldn't it be nice if the block chain looks like this:

from acct1, amt
from acct2, amt
from acct3, amt
to acct4, amt
to acct5, amt
to acct6, amt
fee
fee
fee



Not sure how to do this without trusting the systems generating the block chain, though.  Group coordination while trusting no one is hard work!