-
-
Save killerstorm/6f843e1d3ffc38191aebca67d483bd88 to your computer and use it in GitHub Desktop.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| 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