An international effort could easily deploy reflective materials here to reduce solar radiation on Earth. Though I wonder how much it would cost to achieve even a 0.01% reduction in radiation, as well as what material would be most cost-effective to deploy.
I'll bite: such users are more likely to want to run an Orchid relay or exit node, with default settings, than actually use Orchid to access the Internet (source node).
Internet users who may be less technical and may not care about surveillance or Internet freedom would still be interested when they hear "hey if you install this app you get a few $ (worth of tokens) per month just for sharing your bandwidth"
Because people currently pay for VPNs, and Orchid effectively provides some of the features of VPNs, with the added benefit that there is no central VPN provider who logs your (meta) data and sells it for profit.
And as Orchid is a P2P market place with no middlemen or fees, it should find a market equilibrium that is more efficient than VPNs, with a lower price per data relayed.
>people currently pay for VPNs, and Orchid effectively provides some of the features of VPNs, with the added benefit that there is no central VPN provider who logs your (meta) data and sells it for profit.
When you roll Orchid for use, I think this should be stated prominently on the web page as a way of selling it. Something like "If you are like millions of people, you use a vpn. But vpns have some problems" and so on.
Good question, especially since we made it clear to them that we have no business model and no plans to ever have one.
There is a fixed number of Orchid Tokens that are used for payments within the network of relayed traffic (source nodes pay relay and exit nodes).
The only way for anyone to gain financially is for these tokens to appreciate in value, which is tied to the utility of the network.
So there's no exit, rather it's a continuous token incentive for all stakeholders similar to the Ethereum network which was funded by selling the promise of future tokens.
Anyone who wants to access the Internet without being surveilled or censored, and for anyone who wants to earn tokens by offering their bandwidth for relaying such traffic.
While not very well described in the whitepaper, the system actually uses token commitments to verify source nodes. Relay and exit nodes verify that the connecting source node has enough token committed (locked up in an Ethereum smart contract) before and after accepting connections / payments.
The only two operational systems I'm aware of using probabilistic payments is blockchain Proof-of-Work, where mining rewards can be viewed as probabilistic (though with annoyingly high variance) and blockchain-based lotteries.
IMO probabilistic payments can replace payment channels in quite a few blockchain-based systems such as https://gridplus.io/ (basically in systems/apps where a service is provided that is (very) granular and continuous (video streaming would be another example))
What's wrong with raising money? Is it more ethical to build systems while living of one's savings?
One of the reasons why there's is a lot of Ethereum-based projects currently raising a lot of money is because token-based systems avoid relying on the traditional financial system for payments and value transfers. If your app is using traditional payments it can be shut down by your payment provider.
Blockchain-based tokens allow users to be in control of their own funds and not have their payments tracked or tied to their identity. I'd say that's a pretty big win.
Moreover ERC20-based tokens allows for engineering of incentives in a way that is far more efficient than company shares. It can accelerate network effects in a way that was simply not possible before blockchain technology.
Raising money to fund work is not the issue in my view. But raising money from venture capital firms has implications that I find hard to reconcile with the stated goals of this particular project.
Venture capital funds many projects in the hope that a tiny share of them will pay for all the others and a profit on top of it. So for this project to meet the expectations of its owners it would have to be extremely lucrative way beyond funding the work put into it.
Is that really the right structure to fund a foundational protocol with non-commercial goals that are potentially in conflict with very powerful interests?
Even worse: VC still expect even the "failed" projects to maximize their return. They don't fund things pro bono, and they will force every project to make decisions that put investor returns before sanity and basic human decency.
Yes. But I think what we don't know is what the agreements really look like in this case. I don't know what a SAFT (Simple Agreement for Future Tokens) is. So maybe this investment is structured differently than regular venture capital deals.
That's fair, and as this is one of the first SAFTs (link below) sold to SV VCs, there's quite a bit of new ground in the thinking and incentives.
Basically, the deal is that our investors bought the right to future Orchid Tokens, which is a new token used for payments within the Orchid Network. Since it's a utility token it's value should be driven by the utility of the network - the size, health and of course user count of the network.
Since there is a huge market for VPNs which overlaps with the utility of Orchid in terms of enabling access where there is censorship, if Orchid can grab a small part of this market then the utility of the network would drive the price of the token.
Whether this is the right model remains to be seen, and like any project there could be a conflict of interest if investors push for features that are not aligned with the project vision.
The difference is that, unlike traditional startups that are in control of their IP and the deployment of their software, once the Orchid Network is deployed, no one controls it but the users who run nodes. They choose what software to run for their source, relay and exit nodes, and no one can force them to upgrade to some new version. This is similar to other decentralized networks such as Bitcoin and Ethereum.
In practice the developers and teams behind decentralized networks do hold some power of software upgrades from their reputation and control of github repos, etc. But if push comes to show and for example we try to add payment fees or adds or other types of monetization, then users are very likely to simply reject such upgrades or even outright fork client software (thus effectively forking the network once such clients are deployed).
It is my hope that this is a structure that allows for both raising money from VCs and still end up with a truly decentralized network. We'd love to get feedback on this and understand what we can do to ensure that the network remains controlled by it's users and not (too much) influenced by any specific group.
There's nothing wrong with raising money. One reason open source projects without large corporate sponsors haven't succeeded in attaining mass consumer adoption is that they haven't had effective compensation and incentivization mechanisms. With cryptocurrency/ERC20-based-tokens, now they do.
In general some of the hardest problems / known weaknesses of the protocol at this stage is:
* Client bootstrap - what entry nodes to connect to? (saurik answered this in response to other questions)
* Current software connects to Ethereum nodes using an Ethereum light client, as Ethereum network traffic is not hardened it can easily be fingerprinted and blocked by GFW and others.
* Difficulty of medallion Proof-of-Work, basically it boils down to that if it's easy to join the network as a relay or exit node, then it's easy for a large attacker to join with many nodes. Making it harder for attackers to join / maintain active position in the network also makes it harder / more expensive for regular nodes.
* Payment anonymity. Currently it's as pseudo-anonymous as regular Ethereum transactions. Whitepaper has some discussion on future improvements there.
(2) The main driver here is economics - relay and exit nodes are paid by users for their bandwidth and relay of traffic. This forms an emergent, decentralized market that hopefully will find an equilibrium where there is plenty of overlay/secure bandwidth available at what the market prices it.
So far our models and simulations on this are limited, so we cannot make strong statements on how this will scale in practice. However, if we look at Bitcoin/Ethereum transaction (miner) fees, we see a live example of a working decentralized market that is very responsive and adjusts to supply/demand without any central intervention/control.
The actual payment tickets (a small data structured signed by the sender) may be sent every 100 packets - we have yet to configure this. The cool thing is that we could send one ticket per packet, but likely that would be too much CPU overhead (ECDSA verification is bottleneck when verifying a ticket)
> Whitepaper abstract says you use "A blockchain-based stochastic payment mechanism with transaction costs on the order of a packet". But how is such a blockchain transaction scalable to the entire internet when considering that it does a transaction for every packet? (pretend you're talking to someone who won't read the article).
I'd like to add to Mr. Simonsson's excellent answer that stochastic payments allow you to remove "dust-type" transactions from the blockchain.
Imagine I wanted to send you $0.01 100 million times, for a total of $1 million dollars. Let's also imagine that the transaction fees associated with 100 million blockchain payments are high enough that we'd like to control them. If instead of actually sending you $0.01 each time I send payment, I send you a provably fair lottery ticket with an expected value of $0.01 (for example, a lottery ticket with a 1/10,000 chance of being worth $100), this doesn't change the number of payments I need to send you, or your expected profit, but will decrease the number of transactions which need to be committed to the blockchain by the inverse win-rate (in our example, we'd reduce the number of transactions by a factor of 10,000). This allows the effective transaction costs to be arbitrarily low, down to the order of a packet (as at that point, physically sending you the lottery ticket starts to dominate the transaction costs.)
Certainly incomplete as it is still a draft, though I'd contest "dishearteningly". Also, why do you find it disingenuous? We're not shying away from what entry nodes and bootstrap of user clients is one of the hardest problems to solve.
An international effort could easily deploy reflective materials here to reduce solar radiation on Earth. Though I wonder how much it would cost to achieve even a 0.01% reduction in radiation, as well as what material would be most cost-effective to deploy.