Skip to content

Instantly share code, notes, and snippets.

@killerstorm
Created September 15, 2018 23:30
Show Gist options
  • Select an option

  • Save killerstorm/6f843e1d3ffc38191aebca67d483bd88 to your computer and use it in GitHub Desktop.

Select an option

Save killerstorm/6f843e1d3ffc38191aebca67d483bd88 to your computer and use it in GitHub Desktop.
I think you're mistaken about impossibility to implement a better
laundry without advanced crypto.
Here's a simple example (just a concept, likely not practical):
Let's, for simplicity, assume that we just want to redirect coins from
one address to another in a series of simple transactions. I.e.
A->I1
I1 >I2
I2->i3
I3->B
And everybody launders exactly 1 BTC at time.
Suppose we have a pool of people who currently want to launder their
coins. They all should post their public addresses on a public board.
To do a laundry you should pick a public address from this board on
random (or, maybe, many addresses).
Encrypt your transaction source/destination (i.e. A->I1) with that
public address and post (public_address, encrypted_txn) pair on a
public board.
Owner of that address finds this message, decrypts source/destination
and mixes with his own transaction. I.e. we had (A -> I1), (C->J1)
Now we have 2x transaction (A, C) -> (I1, J1).
Then he signs input and obtains signature of other party. (It is a
part of bitcoin distributed contracts.)
Now from this 2x transaction we cannot say whether it was A->I1 or
A->j1. Money got mixed.
After many iterations of such process uncertainties add up to the
point where it's not possible to trace outputs to inputs since they
all are mixed.
Now to obtain this connection we need to get information from all
participants. Assuming that considerable portion of participants are
honest launders and they do not keep any logs, there's still enough
path uncertainty so that transaction cannot be traced.
This protocol requires many iterations, though. (Depending on ratio of
honest launderers.)
It's possible to improve it, however, through multi-way transaction.
Once we obtained 2x transaction (A, C) -> (I1, J1) instead of signing
and submitting it we will obtain another 2x transaction and merge with
it, so we'll get larger txn with 4 inputs and 4 outputs. We can
continue this process until we incorporate all individual
transactions.
Laundry is supposed to add confusion through uncertainty, so it's
natural to measure entropy. Originally with one input and one output
you have 0 entropy, everything is certain.
Merging it with fellow transaction gives you 1 bit of entropy. Doing
another merge gives another bit, and so on.
Entropy gained in one round depends on level on which rat user is
found. I.e. if address you've chosen on random is a rat, you get 0
entropy. If he is honest you get at least 1.
If second degree partner is honest you get one more bit and so on.
Thus knowing rat/honest proportion we can compute average entropy gain
in one round (ae). Entropy over N rounds would be N*ae.
(I don't know whether it is a novel idea, I vaguely remember hearing
about laundry and distributed contracts at the same time.)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment