Topic: Idea for increasing privacy in trasanctions: Onion Routing+SwarmMasking Payments (Read 1271 times)
February 15, 2018, 04:50:43 PM
I know that the post above is an aswer in a 7 year old thread (seems that the poster is beating the dead horse or necroposting), but after I have read the old posts from 2011, it seems that the idea in the thread (sendig coins thru hops (nodes) in a network) is similar (at least a bit) to the Lightning Network which is under development now. I also read somewhere that Satoshi was also thinking about a solution similar to the LN, so I'm just amazed that those peple were just thinking about increasing the privacy of the bitcoin network (or just add another network to increase it) and it's really similar to LN.
February 12, 2018, 11:36:04 AM
I think that true privacy will be a dealbreaker for any coin that is looking for a decent use case. Imagine a scenario where you want to have unchangeable records with the help of a DLT, but dont want these information to be visible to everybody (think health or insurance data). Without robust privacy features, many use cases are simply impossible.
March 19, 2011, 08:30:02 AM
How would they be able to transfer the money to the next hop without being capable of spending them?
March 18, 2011, 07:16:57 PM
Obviouslly there is the risk unscrupulouslly coded clients could choose to not relay transfers and keep the money
Ah, but those clients would also have to have the private key corresponding to the public key contained in the transaction. Without the private key, you can't spend the coins.
March 18, 2011, 05:34:58 PM
I think anything that increases privacy is good and people would be willing to pay a bit for it.
That being said it should be option for those that don't care / need it and want to save the money.
That being said it should be option for those that don't care / need it and want to save the money.
March 18, 2011, 05: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?
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?
Jump to: