[0xdeadbeefbabe]

What you say made me think of hamachi, a nice vpn overlay network for windows (at first) from the late 90s, and guess what happened to it?

> For paid subscribers Hamachi runs in the background on idle computers. The feature was previously available to all users, but became restricted to paid subscribers only [0]

More short sighted business practices as usual.

[0] https://en.wikipedia.org/wiki/LogMeIn_Hamachi

[chatmasta]

You should check out the ipop project [0], the technology behind socialvpn and groupvpn. They have an active and extensive github. [1]

The problem with technology like Hamachi, and even IPOP, is that the nature of NAT traversal means that for any given p2p network, "supernodes" will always be required. IPOP uses STUN/TURN (the same technology as WebRTC) for NAT-traversal. According to Google usage stats (can't find the URL right now), about 10% of p2p connetions over STUN/TURN require relaying all packets over the TURN server. So that means for every ten nodes, at least one will need a supernode to connect to the others.

At first glance, the requirement of "supernodes" seems to impede the proliferation of true p2p networks, because it introduces a point of failure into the system controlled by one entity but relied upon by many. The problem is that "supernodes" cost money, and somebody needs to pay for them. So you end up with companies like LogMeIn, happy to provide a "p2p" solution, as long as you pay them to maintain the requisite supernodes.

However, there is no requirement that one centralized entity supply the "supernodes" in a network. It's 2016, we have "the cloud," and anyone can launch a "supernode," aka a cloud server with a public IP that can assist in NAT traversal.

I hope we will see more business models based around a combination of "p2p" and "federated" network architectures, where they are federated in the sense that a group of "super-peers" provides the "supernodes" required for functional NAT traversal on the rest of the strictly p2p network.

[0] http://ipop-project.org/

[1] https://github.com/ipop-project

(Shameless plug: You should also check out my senior thesis, TorCoin: http://dedis.cs.yale.edu/dissent/papers/hotpets14-torpath-ab... -- I've been thinking about this a lot since then, but that was my first real exploration of the ideas I'm trying to express here.)

[0xdeadbeefbabe]

Interesting abstract, but what about just asking for donations?

Freenode does that, and so does public radio, but they seem uniquely positioned to do that. If I were running a bunch of STUN/TURN servers I wonder where I would ask for donations.

Makes me wonder how the Internet came to be. Something about DARPA funding?

[chatmasta]

The cost of a supernode is more than just monetary. There is a cost to the network when one single entity controls all the supernodes, because in almost all cases that means they have some disproportionate level of power over routing or quality of service. You wouldn't want one company running every Tor exit node, because then it's not decentralized.

A business model that relies on donations to one, or a few, entities controlling the supernodes perpetuates the centralization of infrastructure. Not to mention that donations are historically the most cost inefficient solution, especially compared to "market forces." If the efficiency of a decentralized system depends on the number and quality of supernodes, then some economic mechanism must exist to incentivize peers to become "super peers." The competition will ensure that the super peers who survive are the ones with the highest quality nodes at the lowest cost.

Then the question becomes, who pays the cost that gets distributed to the supernodes? In the case of TorCoin, we wanted to avoid the situation where people need to pay to join the Tor network. So our solution was a cryptocurrency with "proof of bandwidth" as its "proof of work." Just like a single Bitcoin represents some amount of CPU power that was expended to "mine" the BitCoin, a single TorCoin would represent some amount of bandwidth that was transferred to "mine" the TorCoin.

The idea was that a TorCoin would have value outside of Tor, and Tor was simply the mechanism used to mine it. So relay operators would mine TorCoins, then sell them on an exchange just like they would any other altcoin. This way they get value from providing bandwidth to Tor users, but the users do not need to pay for the service.

However this gets complicated very fast, because you're not talking about one person mining coins with one CPU, but pairs of people mining coins by transferring bandwidth between each other. So the priority of the paper was addressing the threat of collusion, where two malicious nodes (possibly controlled by the same actor) spoof terabytes of bandwidth between each other, flooding the market with TorCoins. Our key insight was "TorPath," a circuit selection mechanism that ensures every circuit participating in the TorCoin mining scheme is "privately-addressable but publicly verifiable." So each TorCoin (or part of a TorCoin) would represent a circuit that actually existed, and anyone could verify that via a public ledger, without revealing the identity of the circuit participants.

I think the idea of non-CPU "proof of work" schemes is very interesting in general, and bandwidth is one of the most profitable venues to apply it to. For example, imagine if the BGP system were operated along an incentive scheme like this, where instead of "circuits" we are talking about "peering." The path selection mechanism we devised would work in any routing system with multiple participants, not just Tor.