 |
March 18, 2011, 10:14:25 PM |
|
In some cases it can be possible to analyze the blockchain and trace the moneyflow; what if the final target of a a transfer got encoded like the destination on onion routing, each hop in the path only decryptable by the previous hop, each hop peeling away one layer (and for increased security, everynow and then adding a hop or two in the sequence, but less often than the "package" changes hops, otherwise it will never reach the final goal), and with the client relaying the onion routed trasfers whenever it gets one.
Obviouslly there is the risk unscrupulouslly coded clients could choose to not relay transfers and keep the money, for dealing with that, one way could be a distributed database of addresses and their respective reliability, whenever the netowrk acknoledges an address has received and sent a or'red package it's reliability goes up, and whenever it doesn't the reliability goes down (the final transfer wouldn't be considered onion routed, it would not have further hop payload; clients that send the initial transfer would create the path using random addresses found in the distributed database that got reliability above a given threshold (asking for a bigger threshold would likelly increase the difficulty in find a big number of nodes, and might also make the whole process take longer if too many people are using the same intermediaries, but going with the threshold set too low increases the odds the money will get lost before reaching the target. Solving conflicts when the database disagrees between peers would work kinda like chainsplits are delt with, the more peers agree with one version the more that version can be relied on (and perhaps whenever a client gets one version significantly more unreliable than others it would analyze the blockchain and calculate it's own database checking what matches and what is differerhaps an opptmization would be to onlyr verify the parts that don't match between the different versions of the database seen.
An additional benefit for running nodes could be a onion routing fee, whenever a client peels a layer and passes it on it could receive a percetntage or fixed value comming out from the money transfered, the reliability algorithm would need to take in consideration how big the fee offered was defined in the transactions and how much each node took from the package, raking negativelly those that take more than what was offered; the fee would have to stay outside, or be included in each layer so all clients can see it without needing to be able to decrypt the whole onion. And of course, running an exit node would provide you with plausible deniability for any payment you make since those payments could actually have been done by someone else and just existed the onion router network by our node.
Actually, forget the bit about nodes randomlly adding more hops, that would allow cheating (perhaps some sort of signing of each layer would be necessary so only the original sender can define the hops); though either way the transaction would get lost)
Of course this would mutiply the time for a payment to reach it's intended destination, but i wouldn't doubt some people would be willing to wait a little longer inorder to get more privacy.
What do you think?
|
