Getting the benefit of Tor, for all blockchains, without the problems of Tor

Tor stinks. Like a stinky onion. But we don't need it anymore. Blockchains solve half of the anonymisation circuit pathway already.

It occurred to me as I was looking over my recent post, that a very big idea that I have had, has not been addressed by itself. I have been thinking a lot about the blockchain-like behaviour of Bitmessage, and I realised that it solves the problem of one half of the circuit.

Actually, as I was falling asleep some hours back, I was thinking to myself I needed to explain the Light Nodes idea a bit more and expand it. I was going to get up and write about it, but I figured, 'nah, I'll remember this, it's a big one'.

The light node is the blockchain equivalent of a caching proxy. I realised that first of all, it needs to be taking in every new broadcast block that gets sent around the network. This way it doesn't look like it's taking requests for a user. When a user makes a request, if it is in this size-limited primary cache of recent blocks, the block gets reassigned to live in a 'requested items' cache. This cache is kept separately, and grows much slower and needs trimming less often because a lot of the data the user will look at frequently for some time and it will mainly be what the user has put up, what they have read and commented on, and so on.

Light nodes pull all new data off the network continuously, but only store data for longer if the user has queried for it previously.

So there is a feed cache, that keeps some amount of data up to the latest broadcast. When items are pulled out, they go into a secondary cache that is the user's frequent items. Thus the user does not need to hold the entire blockchain, just keep up to date with it and move items from users that are followed and items that are looked at. The requests are cross-checked with random queries from other nodes, when they are requested, to ensure the data is not poisoned.

This way, it is impossible for someone without privy access to the contents of a users light node viewed items cache, what the user is looking at. The node does not selectively query other nodes, and when it does, it won't be often, because most data is going to be located in the recent blocks cache. It will distribute its queries across a wide number of available RPC endpoints as well, so each individual witness RPC node only knows a little of what the small amount of queried data of the user's light node specifically looks at, and rarely, because most of the time it has already migrated to the query cache.

Only transaction posts reveal location information of the user. This should be obscured.

So, then, the only question of maintaining privacy for a light node operator (the idea would be to integrate this to link locally with apps that query the database, a complete app, or just a post/vote app, or just the wallet manager) is that when the user pushes content out to the network, it should not appear as though the new request came from anything directly traceable to the user's IP addresses.

Just to clarify, as I have pointed out, if you run a full node, or one of these caching light nodes, the inbound path for data is already completely mixed with the network traffic. There is no, or very few, specific queries originating from a users' IP address, that can be used by malicious nodes to establish a profile on the user other than what they have published.

So, all that is required is a way to tunnel transaction posts (new posts, edits, votes, etc) through an indeterminate number of other witness nodes. Because this data traffic is quite small in volume compared to the post distribution for verification and blockchain integration, it should be virtually cost free. But having said that, it could also be possible for access to RPC to be purchased with a method that does not reveal the identity of the requesting party, in order to pay for this onion routed transaction broadcasting obfuscation.

If setting up a full witness node was relatively easy, it would also be possible to configure the light node to have 'trusted' nodes, which the user knows for certain (as certain as possible) that these nodes are not potential network poisoners or traffic sniffers. You would only have to run one of your own full nodes, and especially when you are on the same LAN with it, nobody else is going to see the query traffic anyway. This further protects you against traffic correlation attacks, because you know your node isn't gathering data for someone else. Your light nodes on your laptop, smartphone, whatever, will synchronise from your nodes first if it can find them on its local network.

To add the traffic analysis protection of Tor to any blockchain, you just have to add a relay protocol for transaction posting.

Thus, your node knows of some, say 20 full nodes it can broadcast to. It selects 1, 2, 3 or more intermediary nodes to route through. The packet is encrypted to the destination, then a routing header, and encryption to the second last, etc, until you have the one that goes to the 'entry' relay you will first send to. The full nodes relay this request, without knowing where the request originally originates, only knowing from where it came and to where it is going, this takes place some number of times (3 is the minimum, but 1, 2 and more than 3 could be mixed up to further reduce patterning). The final node that receives the actual transaction packet, it is nearly impossible without knowing more than 2/3 of the intervening hops, by timing, where the packet could have originated.

With this addition to blockchains, the obfuscation of post origin, plus light nodes that can draw from trusted full nodes, you don't need Tor at all.

It is even possible that there could be a reward for providing this routing service, so long as it is designed to make it impossible for the router to know who paid for the session certificate.

The same principles apply equally to bitcoin, steem, ethereum, dogecoin, litecoin, and any other persistent, immutable blockchain, as well as Bitmessage, and derivatives like my Light Node concept, and the idea of a lighter-weight short message equivalent of bitmessage. Routing the requests is the only thing required, along with a light node proxy cache, and traffic analysis on the network is for all practical purposes, impossible.

EDIT:

I just wanted to add a couple of notes. Being that I use a custom CSS filter on my Steemit viewing, I made my post header image using a png, with a transparent background. So it will look good no matter what the background is, unless it's red, I guess. And a tip: the picture should be around 16:10 aspect ratio, so that it does not get trimmed in the feed views, and the image appears whole.

I designed the image to convey in a somewhat amusing form, the essence of my idea, which is to obsolete Tor as a way to protect people from correlations to location. The steem logo resembles a waft of vapours. So I think what I am trying to say is, Onion routing is no more. Blockchains don't require obfuscation of the back channel. Only the broadcast of new packets.