The Orchid protocol uses an overlay network built upon the existing Internet, which is driven by a peer-to-peer tokenized bandwidth exchange.
The orchid protocol is an open-source overlay network that runs on top of the Internet. Its fully decentralized, because rather than traffic being routed through central authorities—your ISP or your VPN—it’s instead routed randomly through a network of bandwidth contributors who sign up to share their surplus bandwidth and activate their Internet-connected device as a “node.”
Users that want to access an uncensored Internet (bandwidth consumers) pay the bandwidth contributors in Orchid tokens through a peer-to-peer exchange. Because neither the traffic nor the payments can be monitored by central authorities, both contributors and consumers of bandwidth enjoy a fully anonymous, surveillance-free experience.
Also of note:
Who are the founders?
Stephen Bell: Steve started companies in Europe, the U.S., and China before founding Trilogy VC China, where he spent 10 years backing Chinese seed stage startups.
Brian J. Fox: Brian is an entrepreneur and open-source advocate, the first employee of the Free Software Foundation, and the author of the GNU Bash shell.
Jay Freeman: Jay is a software engineer and the developer of the Cydia software distribution platform used on millions of jailbroken iOS devices.
Gustav Simonsson: Gustav is an engineer and developer who helped launch Ethereum in 2015, working with core protocols, clients, and security auditing.
Dr. Steven Waterhouse: Steven is an experienced investor and entrepreneur, having co-founded RPX Corp, led cryptocurrency projects at Fortress and Pantera Capital, and the Honeycomb product at Sun Microsystems.
[Edit] I _think_ they are trying to create something like Etherium but for decentralized internet.
It's worth noting that a financial incentive does not necessarily equal capitalism; if one were employing wage labour then it would constitute a capitalist system, as the M-C-M' circuit would be fulfilled.
They call it a protocol but this is very much a startup/ICO, having raised nearly $5m in seed. Not that there is anything wrong with this, it seems like a very cool project. But it does seem to be very intentionally presenting itself as something that is closer to a not-for-profit a la Tor.
It is maybe worth noting that we had actually looked into whether we could be registered as a non-profit and still raise money by these means to build out our implementation and market it to the world, and that was simply not possible :/. We are, however, all deeply committed to open source, and are working on how to best ensure that this is enforced in the company's charter (such that even if there are any future changes, there will never be any fear).
All of our work is to be released under the AGPL3; and, while we have filed for a patent, we will be licensing the patent to the world in a manner similar to how Mozilla manages their patent portfolio. Brian Fox, who is in charge of making sure we have a successful and inclusive open source project, was the original developer of the bash shell, was for a while the maintainer of GNU emacs, and was the first employee of the Free Software Foundation (as Richard Stallman was a volunteer), and so is keenly aware of how important it is for technology to be available to everyone.
Hello! My name is Jay Freeman (saurik), and I was both deeply involved in the design of Orchid's protocol as well as in charge of the initial implementation of the networking and routing logic, and am happy to try to answer any questions people might have about what we are working on!
(edit:) g_simonsson, who now has an account on Hacker News and has joined this thread, is Gustav Simonsson, another developer working on this project in charge of our smart contracts and payment logic. He was one of the core developers who worked on Ethereum, specifically focussing on blockchain security.
If I understand your question correctly, and you are looking at "how do we do hole punching and NAT traversal without a way to get your canonical external IP address", in addition to techniques that don't require that kind of functionality (such as modern routers with UPnP port forwarding support), other nodes on the network can run something analogous to ICE servers (we have yet to decide if it should literally be STUN or if we need to integrate it into the security model), so all you will need is the address and public key of another node (which you will need anyway in order to connect to the network).
>so all you will need is the address and public key of another node (which you will need anyway in order to connect to the network).
But this begs the question. How does the user get the public key and address of a node without connecting to a public directory? How does he know he's connecting to something trustworthy?
Oh, I'm sorry: because I have been living and breathing this for months, it is very easy for me to assume context :(. Once you connect to the network, you are able to judge the size of the network to know you aren't on a fake network (this is a scenario similar to judging the size of the longest chain of Bitcoin blocks) and you are able to verify signatures of routing table entries (which have been built up as the network was formed by nodes verifying reachability properties of other nodes), which itself is more trustworthy due to proof-of-work and "cryptographic puzzles" which are used to make the cost of sybil and eclipse attacks prohibitively high.
Given that context, you really just need the address of any node, not the address of a particularly "trustworthy" node, so you can get one from a friend's client or from a random website. We have discussed some alternatives, such as being able to put out a bounty on an existing peer-to-peer cryptocurrency blockchain (one which would have to not itself be fully blocked for you, of course). We also have been getting interest from some people in academia who have a number of other techniques, which again are mostly viable because of the background that "what if we can provide enough mitigations in the network itself and use what has been learned from blockchains to mean you don't need to find a trustworthy node".
Do you have a reference implementation of using WebRTC as a networking layer?
As far as I've researched, I've not seen anything which would enable reliable NAT traversal which wouldn't also make the network traffic trivially identifiable.
STUN works only for certain types of NAT and requires servers which aren't behind NAT.
TURN is an external proxy, so can easily be identified by monitors of the network.
The concept of Orchid seems nice but the actual implementation seems very hand-wavy.
That is a very broad question that I keep looking back to and thinking "I'll answer other questions and get back to this one ;P", but I'm thinking maybe I should simply refer you to the almost 50-page whitepaper on our website. I am here to answer any questions you might still have (and I totally believe you will, as that whitepaper is a draft)!
The website will see the IP address of the exit node connecting to it, not the IP address of the user connecting to the network. You can then ask the question "what if the people running the website are also running nodes on this network and are actively attempting to do various forms of information correlation attacks including active experiments on the traffic flow", then I really am going to have a hard time accurately summarizing the whitepaper.
However, I see now that I didn't bother answering your first question, due to the complexity of the second ;P.
> Is this anonymous like tor or i2p?
The answer to this question is "yes", though we are aiming to be even better than those projects (in different ways).
The FAQ says you can break through the Great Firewall of China. I believe that you can in some limited way now by flying under the radar, but I absolutely do not believe you could maintain that ability if this became widely used and targeted specifically by the authorities. What would you do if they started really cracking down on Orchid?
We actually received that question from a reporter yesterday, and I wrote an answer (one which is in the new version of the FAQ that hasn't been pushed :/) that I vetted against the other security people working on our protocol, so before I write something one-off, I'll copy/paste that and see if it is sufficient (as I'd prefer to not accidentally make any security claims that we are not prepared to stand by ;P).
> We are working on techniques involving "traffic steganography" that will make the the traffic used by Orchid look like "normal" internet traffic (such as web requests and video calls). There are also existing simpler techniques such as "domain fronting", where you send your traffic to a large company such as Amazon--one which uses a CDN to efficiently route traffic--and cause their CDN to forward your traffic to your servers; this has been used successfully against the Great Firewall of China in the past.
> Of course, we also need to hide the list of destination servers, as otherwise these could be collected by the adversary and blocked outright. Our current solution to this involves cycling through large numbers of random IP addresses on various hosting solutions, which we believe will force anyone trying to block our traffic to end up blocking large areas of the internet--such as every server being hosted on Amazon Web Services--which would cause a serious problem for Chinese businesses and residents.
> For more information on this, see our discussion of Firewall Circumvention Features (Section 12) of our whitepaper.
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).
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.)
1. The web page says open source repeatedly. Where's the code repo?
2. What's your privacy policy? What do you log, and what could you log (but swear you aren't)?
3. What's the open source license?
4. What's your code rights assignment document?
5. Does this differ from "Tor, but supported with a cryptocoin to buy exit bandwidth instead of hoping for donations"
6. That's a lot of investors. How long do you expect to have to supply servers and bandwidth before the network reaches self-sufficiency?
7. What are the threat models this addresses?
8. How do you vet new nodes to determine that they are not being controlled by [DC|Beijing|Pyongyang|Ottawa|Moscow|Paris|...]? In particular, if one entity controls more than 50% of the nodes, is it likely that they can trace who is requesting what?
9. Are you planning on making this affordable by civil rights activists in poorer regions of the world? How so?
1) The implementation is not done yet, but the code will be available in the near future (I believe on GitHub, which for people who have met me or seen any of my talks makes me sad, but of course that is where all the cool kids are these days).
2) The network is not a centralized service. Assuming I understand your question (and I probably do not), one may as well ask where the privacy policy is for Bitcoin. When the network launches, there will be nodes run by us, and one could believe they are logging in a way that is different from other nodes. This is something that we are sensitive to, and, if there are any such modifications (and it is not clear that there will be), they will all be available and visible to the public (as even required by our choice of open source license!). Of course, I can make no such claim for nodes run by other people or companies, but that is always the case and we fall back to the underlying security properties of the network.
3) AGPL3
4) This is still being worked on, partially because I think it is incredibly important that we make it extremely clear to anyone who does give us copyright assignment that the code they give us won't one day be forked by some future version of the entity that owns the code to build a closed-source project, and getting that right in a way that it can't ever be changed is legal time we haven't finished allocating.
5) Yes! As one high-level and in my mind very interesting example, Tor actually is a centralized service where nine directory servers are able to decide the state of the network; we are accepting nothing less than a fully-decentralized system.
6) I do not have a particularly precise answer to that question, but the answer I believe in is "not long at all", particularly given that users pay for the bandwidth they are using from other people. Under one argument, we would be self-sufficient instantaneously because any bandwidth being routed through a server we set up to help bootstrap the network would be paid for by a user.
7&8) This is a question that would lead to a very detailed answer, and so I hope I can refer you to our in-progress whitepaper. If you have any further questions, I would be happy to try to get them answered ;P.
9) It is my personal opinion that, as bandwidth is a "wasting good", that it will be extremely cheap to purchase bandwidth. I will refer you to section 7.2 of the whitepaper, "How Much Will a Packet Cost?".
1. Based on the paper, it seems ORCHID by itself (without bandwidth burning. not sure if this is trivial to get right. is there tooling?) is as vulnerable to traffic correlation attacks as one might expect. Are there any other known weaknesses? I would expect a "limitations" section in red letters on the front page, instead of the nebulous and likely wrong "the NSA can't hack it either" claim.
2. Given that todays secure overlay networks generally offer extremely bad performance in the Mbit region compared to using the underlay where 10G uplinks are becoming widespread for servers, and the extra hops increase latency, do you think secure overlays will ever be near enough to underlay speed to become widely used? Do you have experience how well ORCHID scales up? And out?
[edit: Don't mean to sound too harsh. I am very glad you're doing work in this area.]
1) First off, as a fast apology and as mentioned lower in this thread, that FAQ answer about the NSA was rewritten two nights ago and failed to end up on the website; the updated answers have now been pushed (to say "Yes", actually, as the first sentence, instead of "No" with a qualification that essentially changes the answer to "well, yes").
That said, you are absolutely correct, and my colleague and long-time friend David Salamon (the person who has been the lead author of the whitepaper) wants that to be very clear. We are implementing bandwidth burning (and are even discussing some interesting extensions of this scheme involving both Turing-complete-w/-limited-execution-time programmable bandwidth burning as well as a form of global bandwidth burning), so whether you call that a "known weakness" for all of Orchid or not is slightly confusing ;P.
When we have actual software that someone could possibly use I am going to be pretty adamant that there are good disclosures in the UI with respect to the security tradeoffs, and for right now the whitepaper goes into extreme lengths to qualify what is or is not possible, in our current understanding, with and without bandwidth burning in place. (We are also looking into taking aspects of the algorithm and building it out with a proof assistant to have even greater assurances.)
2) One place where Orchid will hopefully shine (in the future tense, as this part is decidedly not yet implemented) is that we are working to allow multiple routes to/from the destination exit node using a scheme similar to MPTCP, which solves a lot of the bottleneck issues you normally find running through an overlay network.
Notes after reading your whitepaper, latency and complexity matter. We copied the Tor packet layout and deployed a simple NAT puncture method to avoid difficulties. Your proposed approach looks like many years of work.
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.
There are a number of differences (which one might say would take an entire whitepaper to describe ;P), but as one high-level and in my mind very interesting example, Tor actually is a centralized service where nine directory servers are able to decide the state of the network; we are accepting nothing less than a fully-decentralized system.
I'd really like to see a comparison to TOR. Because honestly, from randomly clicking through the website I don't see why you're better than TOR and why I should use ORCHID.
I cannot (easily) find answers to pretty much every question I have, and sorry, I'm not going to read through a 50 page whitepaper before I decide if it's worth it.
What is it, onion routing? There's some talk of ethereum, so presumably you can get eth for spending traffic? Exit nodes? hidden services? (I'm not going to run an exit node for obvious reasons)
Maybe I'm just tired or stupid but I can't really find anything that isn't marketing blurbs without going through the whitepaper?
I mean, I already said I know about the whitepaper. I'm very sorry that I ask for a bit more of a tl;dr of it when there's another new hot blockchain startup. Eh, you know, one of those you see every other day. Why not leave it to them to decide if they want to acknowledge my feedback or not?
> It sounds like this project is probably a little too early stage for you then?
> Maybe let people play with it for a couple if years and distill it down a bit. If it still exists maybe try again.
I don't have a problem reading a whitepaper. But there's approx. 12 billion new etherum startups a day. So I just think a little tl;dr would be nice to know if it's something I care about. Because right now I don't know if I should care early stage.
Tor's nine directory servers are not run by tor itself. One employee runs one of the nine, the rest are different people from around the world, with different affiliations who are not under the control of Tor. You must get a majority of the directory servers to block something from the network, before it will be blocked. Its not any one of the nine that can do it, they need to convince five other people, none of whom they control, to also block before it is actually accepted.
How do you plan on dealing with abuse? Sybil attacks, or bad actors on the network?
Using PoW `Medallions' on top of a PoW blockchain to prevent Sybil attacks seems redundant. Why not just require Ether commitments from bandwidth providers? Users can then set a configurable threshold for commitment lengths/amounts according to individual needs.
This is the first I'm hearing of probabilistic payments. Are you aware of any other systems, proposed or operational, using this to pay for bandwidth? It seems like a natural fit.
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))
Hi Jay!
Are you guys planning to take advantage/contribute of/to the libp2p project (https://github.com/libp2p)? Looks to me that some of the introduced standards/formats (e.g. multihash, multiaddr) could be adopted. This again would lead to an increased significance of libp2p.
Regards,
Marc
Not exactly, though I can appreciate why it might seem like that at first glance; we are selling a "utility token". This distinction is interesting and important as we are not selling a token to raise money to do development, instead having taken on seed investors to help us get the right team of developers and advisors to do this initial build out. The sale of tokens will be made after we have this network fully working and launched, meaning that we are really targeting a group of people you might call "customers" who will buy bandwidth tokens (as opposed to "investors", which is the target market of an ICO).
Sustainability isn't even the greatest concern: where there are customers (people who pay for access to the network) there is a database of customers (in order to allow authentication) that has to be kept out of the grasp of government agencies.
Actually, that's the great part about what we are doing: it is all built on Ethereum, so there is no centralized database, and the users are generally pseudonymous! OK, you might then say "isn't that just a decentralized database?", but in addition to a form of "probabilistic micropayments" that ends up shrouding most of the participants, we are also working on integrating other techniques to make the payments fully anonymous (and have brought on a team of advisors which includes a professor of cryptography who specializes in this area).
"Bandwidth contributors simply install Orchid and activate their Internet connected device as a node - either as a relay or proxy - and then they set permissions like sites they want to blacklist or whitelist, and they earn tokens into their Orchid wallet for sharing their bandwidth."
So hopefully the blacklisting will eliminate the problem of nasty content that plagues anonymous networks like Tor.
How so? If it's under individual control, you'll just end up with sub-networks where people will agree to distribute that type of content.
You cannot pair anonymity and security with censorship. They are fundamentally incompatible. So either accept that nasty content will be out there, or acknowledge that you don't actually want perfect anonymity and security.
FWIW, if you look at Tor, Facebook now runs a hidden service that allows people to access Facebook's website. This is essentially the same thing as someone having provided a number of exit nodes that will only route to Facebook. The problem, though, is that this requires the client and maybe even the website to be modified to use the .onion URLs for all accesses back to the site (at least, any absolute URL on the site back to the site will cause a problem). I will personally contend that it is worth it to allow Facebook to do this, or to allow anyone to do this for any website, in order to get more people using the network for everything, as the more users you can get using the service to do normal traffic the more easily you can hide everyone.
This is particularly noticeable given that in some countries, such as the United States where I live, simply accessing the Tor website to download Tor will end up flagging you for further monitoring. If Tor had only as many users and exit nodes as it does right now, but additionally had, for example, a billion people in China accessing Wikipedia through exit nodes that refused to go anywhere but Wikipedia, that makes a world of difference. As it stands, people are actually actively discouraged and even shamed for using Tor to access random websites or ones that use a lot of bandwidth, as that means that they are using (or even "abusing") a limited amount of donated bandwidth that somehow needs to be reserved for those who "really need it" (and thereby, will be targeted just for that).
That is absolutely our intention! While users who run nodes can choose to forward content to anywhere on the Internet, we want to provide people a feeling of control over the usage of their bandwidth, as we believe that (along with being paid to forward traffic!) will increase the number of people who are willing to provide bandwidth to the service. Being able to say "I am only willing to help users get to Wikipedia, or the New York Times" is something that we think is very important to being able to have enough people using the service to provide the levels of security needed for everyone on the network.
> While users who run nodes can choose to forward content to anywhere on the Internet, we want to provide people a feeling of control ...
Are you concerned that,
1. If node operators have the power to control content, they will be held responsible for the content by authorities? For example, consider a node operator in mainland China who allows access to criticism of President Xi.
2. Unpopular content will be censored by node operators just like it is now by more centralized powers?
As these are more answers of opinion rather than factual questions about the network, I'm going to add a massive disclaimer here that "opinions may differ about what is or is not concerning".
1) No, because I would personally advise people in China do not whitelist sites whose purpose is to access such content. It is not even clear to me that people in China would want to run an exit node at all. There are billions of people in the world in countries other than China that can run exit nodes for that content so people in China will be able to access it without fear, and without anyone in China taking on that level of liability.
2) No, but with the great benefit that because everyone is using the same network, even if somehow (and I do not think this will be the case) there are only a small number of nodes willing to access that content (and one would expect that, in the eventual limit, this number should not be smaller than the number of Tor exit nodes that currently exist; though again: I think it will be much larger), then they will be cloaked within the content everyone else is accessing.
Essentially, it doesn't work to say "people who need access to a secure messaging service should use a secure protocol and everyone else can use Snapchat", and it also doesn't work to say "people who need to access criticism of President Xi can use Tor and everyone else can use the regular Internet". I want a billion people who are also doing things that would be considered insane on Tor--like browsing Netflix!--to be using this service, and to pull that off we need lots of exit nodes, which in turn means incentivized traffic and whitelists.
Put another way: I don't care if there are only 0.0001% of nodes that let you access criticism of President Xi if that is 0.0001% of some insanely large number and the result is "at least as many nodes as Tor", as that itself solves the #1 problem using Tor: that even accessing the Tor website already marks you as someone who is suspicious (as it is here in the United States and the surveillance programs we see).
There are only two options. One is all or nothing like tor: if you become a node you have to pass through everything. The other option is node operators can decide what they pass through.
With the tor model you get very few nodes, because most potential operators are afraid of being arrested and/or object to a lot of content. You don't get remotely as many nodes as you need to make the internet free and more safe.
With selection, you get many more nodes and, as saurik points out below, you still will have a few for material that some governments censor. So it seems to me a model with selection is the way to go.
For that purpose I would think optional whitelisting would make more sense. Instead of spyware lists you subscribe to in uBlock Origin, you would subscribe to a vetted, whitelist of known to be generally acceptable Orchid content.
Others might want to have empty filter list to be a complete transit/peer.
Therefore I don't think there's much room for users who want to blacklist but are not rather looking for a whitelist.
The blacklist will grow and grow, while the whitelist size will be pretty stable.
That said, I haven't used it, so the implemented blacklist approach might already support the above cases and be sufficient.
FWIW, as the person who has been doing the initial implementation, I can tell you that we currently only have a whitelist. I can appreciate why the person who was editing the FAQ for the website put in the world "blacklist" as it makes the sentence flow really well, but I agree with you about the issues (and there are also problems doing the distributed hashtable search to find nodes that don't have some property rather than ones that do have some property). I will poke about this to see if I can get it changed ASAP!
I know what you mean, but for this to be more widely used than Tor there is a need for me to know that nodes I operate only process stuff that won't be identified by 3rd party to sue me into a jail or financial ruin.
When I say whitelist, I do assume prefixes in the DHT (or whatever design they're using) can be used, as otherwise the whitelist may also grow too big to be practical. If however it will gain the concept of domains or such (which is also kinda a prefix), a whitelist will also be more practical.
Tor exit nodes are not operated by many in various places where they would/could because of concerns of the exit node addresses being enough to legally ruin operators' lives, even though technically it's a pure transit. Nobody sues the county because someone committed vehicular manslaughter on their public road. But because laws are skewed against the Internet right now, all someone needs is an exit node IP to make you regret.
If, and there's little to analyze/go by right now public, nodes and everyone is totally oblivious to what packets are transmitted; and if also the packets stored on nodes' disks are encrypted/sealed, then one could assume a filterless system to be practical.
This is all speculation, based on the little info there is. I really hope the team has come up with better designs that obliviate the concerns surrounding Tor, and ideally also not suffer from Freenet like slowness.
EDIT: Of course, once you have a filter, you will need to deal with the responsibility like Youtube does. If you do not know what's on disk or passing through, which is the ideal technically, then it would be best for the Internet and free communication. So, I'm not sure if a filter is a good idea, if that means you get subpoena'd and held liable for enabling one too many whitelist subscriptions.
I may be wrong, but my impression is they have more than one target audience. They want to hit the whole public, but also smaller groups who are having problems like government internet censorship.
(edit: When I wrote this answer, the person I was responding to had not yet added "or Tor".)
Freenet builds its own domain of content where people post websites that are hosted in a distributed fashion by the platform. What we are working on with this initial implementation is a fully-decentralized tunneling service to access existing content posted on the internet (so if you were to compare it to an existing technology, you might look at Tor, or the "out-proxies" from I2P).
It seems intended to be more anonymous and decentralized than Tor, and safer thanks to the strength of numbers, but their whitepaper is diseharteningly incomplete and disingenuous, particularly about problems that are shared with Tor.
For example:
"The distribution of Entry Nodes is a difficult topic. If oppressive governments are able to access this list,
they will block user’s abilities to access the list."
Or simply, you know, go after whoever runs entry nodes. Or run their own entry nodes and, even if they can't compromise the network, trace the evil cypherpunks who want to use encryption.
Unfortunately, some practical and political problems cannot be solved with improved cryptography.
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.
There are a number of differences (which one might say would take an entire whitepaper to describe ;P), but as one high-level and in my mind very interesting example, Tor actually is a centralized service where nine directory servers are able to decide the state of the network; we are accepting nothing less than a fully-decentralized system.
Given your question's wording the answer is, at this time and as currently described, "a way of accessing the clearnet", with no already-existing features for hidden services.
There is active discussion of this, which means I am not prepared to say it won't happen or that it can't happen, but I am also not prepared to guarantee it will happen (as then you will ask when ;P).
Differences from Tor include, from what I understand, it is fully decentralized, there are tokens to incentivize people to run nodes, and node operators can choose to use a whitelist.
Also, at least for now, it is not a darknet, it is only for connecting the clearnet.
Very interesting. Visited Noisebridge a while back and there was a post on the door telling visitors what to do when the FBI visits to ask about the TOR exit node. I wonder how this tool avoids the exit node problem.
Also, from the FAQ:
>Can't NSA just hack into this too?
>No. Because of its fully decentralized approach, distributed architecture, and the size of the global network, Orchid cannot be easily hacked by any single government or entity.
That's not really a satisfactory answer. First, it doesn't answer the question. The question was not "can NSA easily hack into this." And I don't think the NSA is necessarily deterred by something being not easy. The bar needs to be higher than not easy, even if "not easy" is a polite understatement. Also relying on the size of the network means there is a bootstrapping problem, right? Hopefully they will get there.
This doesn't mean the system is bad... I'm just saying the FAQ answer is bad.
On the positive side, given the cred of some of the people involved (saurik!) I am optimistic this may well have a shot at working.
Ugh. FWIW: we agree. That FAQ answer was rewritten, and it failed to go on the website.
Here is the updated text that was written a couple nights ago by one of the people who helped design the protocol with me after being confused by the answer on the website.
> Yes. Our initial release targets China as the adversary, which is a more tractable problem. We may implment full Chaumian mixes in the future (which are immune to metadata/traffic analysis), but they are unlikely to be complete for our first public release.
Would you consider changing "China" to something like "Chinese government"? Or, if I'm understanding it correctly, maybe something like "Our initial release operates with a threat model of an authoritarian government's internet censorship, such as those seen in China, Turkey, or Russia."
I agree with this edit and have made a similar change, pushed it to our server, and are poking others for review. Thank you for your feedback: that is a much clearer answer (as otherwise it sounds like China is hacking into places as opposed to "we mean their firewall").
Hopefully not! Ideally token allocations are fair and do not skew ownership towards any individual or entity while still providing good incentives (we're still working on figuring out what good allocations look like)
The main reason there's currently not more details around the SAFT and the token model/allocations is that it would distract from the overall project and tech, given the current hype of blockchains and tokens.
There's certainly economic incentives for all participants, and what I find interesting is that since we're open sourcing all the code, anyone can easily deploy another network with a different token (model).
This puts pressure on us to propose fair token model/allocations else we risk disruption by forks or simply new Orchid networks.
We definitely do not have any centralized servers. The currently-specified mechanism to determine routes is that they are decided by connecting to a distributed peer-to-peer network that is modeled in many ways after a distributed hash table, at which point you do lookups of random keys in the hash space, which results in a randomized scalable lookup. There are mechanisms in play (and which I assume are already described in our in-progress whitepaper) to protect against eclipse attacks, sybil attacks, and some other miscellaneous attacks on the routing infrastructure. That said, this is also some ongoing work, and we are actively engaging with and being reviewed by people both in academia and in the field with respect to our techniques.
At this point it is either a magic buzzword to get investors throwing money at you or actually a smart thought of putting cryptographical proof into something. Usually its the first tho.
Call me zealous, but I'm the same way. I'm wary of the potential for monetary incentives to skew actual demand. I've seen how digital advertising has more or less destroyed much of the internet. Hopefully decentralization will prevent monopolies or oligopolies from forming, but I'm not so sure about that.
At this point, it's hard to say what actual distributions of wealth might look like if people start using cryptocurrencies in their daily lives, for example to route traffic over a network. But at the moment, the distributions of wealth are quite nuts. But if there is an overall "unfair" atmosphere in the crypto-economy, it's could make depending on this system of routing kinda suck in the long term, especially if peoples actual livelihoods are under the pressure of massive ad gaps. People "sell out" when they're perceiving some stress.
If we go 'all-in' on this kind of system, it might actually end up creating the same kinds of de-facto power imbalances we see today with conventional social media.
I'm not anti-cryptocurrency either. I actually own a little bit of cryptocurrency. I'm curious about its potential to dissolve existing dominance relationships non-violently. That said, I don't see it as an end. Moreso, I see it as a potential conduit of healthy, non-violent economic chaos.
I also recognize that this strange new alien could be "out of the frying pan and into the fire".
The main design goal of cryptocurrency protocols and the like is immutability, so that the protocol operates according to formal specs and not according to the whims of economic stakeholders.
This is why the Finnish central bank's paper on Bitcoin called it a 'monopoly without a monopolist'.
I think the immutability of these kinds of protocols is certainly an improvement over the total control that economic stakeholders have in a centralized server-client architecture, with respect to power distribution.
I didn't see that comment as unsubstantive. Although it was definitely brief, it was potent enough to prompt me to respond in a more drawn out way. Part of the reason I love to read hacker news is to get a read on peoples basic sentiments about tech.
Thank you very much for taking time to thoroughly answer questions. that combined with whitepaper and faq has left a very good impression to me, both socially and technologically. Best of luck to your team!
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.
Is there any thought given to the response to a node operator who is detected/proven to be operating the node for surveillance or compromise? What would the response be? Will tokens not be sold to such a node operator?
The goal of our network is to make it so that the network is protected as much as possible from users running compromised nodes. If you are a single node, you should not be able to do anything against the network. As the number of nodes you are in the system increases, the probability you will be able to pull of various forms of attacks against users of the network also increases. We are working on documenting these security tradeoffs in detail in our whitepaper (and any attempt I make to describe them here will be less accurate and thereby dangerous ;P).
However, it is worth noting at a super-super high level that we are hoping to get a large number of nodes running the network and we have parts of our system that involve proof of work in a way similar to a cryptocurrency blockchain like Bitcoin. If a node in the Bitcoin network is operating for the purpose of compromise, it need not be banned from mining blocks: the network is designed in a way to make it so that such a node would not be able to pull off the kinds of attacks that people care about unless it owns a significant percentage of the resources being applied to securing the network. Our network has similar properties.
"We are working on documenting these security tradeoffs in detail in our whitepaper (and any attempt I make to describe them here will be less accurate and thereby dangerous ;P)."
Maybe a whitelist of nodes themselves? (mostly in jest there)
I suppose an agency with funding who can endlessly sockpuppet could gain a substantial portion of network nodes, but if they're unable to censor more than per-random-packet, a surveillance goal seems more likely. While this may not meet conventional definition of 'censorship', I wonder of the chilling effect. I suppose any such move toward a censorship-free network should expect surveillance. c'est la vie.
This is needed but there should be more insight into the current surveillance problem and how Orchid solves it. This seems to be focused on China.
Because surveillance is a potentially serious problem, it should not be used cynically to market some new product that just adds another layer but doesn't really solve the problem.
For the average person its not China or Russia but their own state that is a bigger problem as they have power over them and can interfere with activism, journalism, dissent etc. The intensive profiling by Google, Facebook and others is another problem.
Was the Internet designed to be anonymous? Governments control access and can stomp down at will. ISPs and telcos know who you are, server and vpn providers know who you are, Facebook and Google have a lot of data on you. Only the very committed and technically adept can perhaps attempt any sort of anonymity.
Something like Musk's satellites with some basic free access may perhaps be the first of many steps to some kind of anonymity.
Sorry, but we have not yet finished writing the code for this (let's just say it: "my fault" ;P). Even I am currently unable to start and integrate a new relay into a running network; this should be fixed in the near future and we will have all of our code available as open source under the AGPL3 license, and will be working hard to build up an inclusive community around the project.
I understand the plan is to be open source, but can someone help me understand why it's not developed in the open? I mean, you can tell people you're not accepting external input at this stage, but why not let people watch it being developed? I can't think of any reason that doesn't make me think that the goal may be openness/transparency but not the practice. Or did I miss the link to the repo?
This is an interesting question; one which I feel for greatly, and one which we have been discussing internally. Not having this detail worked out before going public was probably a mistake of ours, particularly as now we keep getting distracted, but we are rapidly working on addressing the issue as quickly as possible. I am going to give you an answer to this but want to stress that this answer has not been vetted through anyone else and is a look behind the curtain (and I hope you can give us a little benefit of the doubt here, at least based on the track record of some of our developers).
One issue is that we have put a lot of effort into the whitepaper, and we really want people to review the concepts in the whitepaper and give us feedback on that, but I will say that it is highly likely (if not a foregone conclusion) that if we have source code available, code which we know isn't done yet as the whitepaper design has been leading ahead of the implementation in the code, that we are going to have people only downloading the code and giving us feedback on the code... but what we really need is feedback on the design, not the first draft implementation :(.
On the other side of this, our team includes someone from the Free Software Foundation who feels some strong moral pulls towards doing all of the development in the open immediately and yesterday. I have made sure that my code is ready to release on a moment's notice and still feel proud about what is out there (though there is one last super high-level thing in the organization of how the code for the network connects with code for services that I want to fix tonight, and issue that will be much easier to deal with fixing at the git level if I didn't think I'd be breaking anyone's clone).
Thank you very much for the response. I empathize with the noise-vs-signal concerns with premature public feedback. Just wanted to share my thoughts because the first thing I look for in these cases is code. While y'all's credentials are clear, we've just seen so much snake oil in the decentralized tech industry.
There is no code. This is a cash grab. The author politely states they needed review of white paper concepts, so no they are not sure it will even be worth writing. The idealology of decentralization also reforms the patent system, so this project will fall like other over hyped icos, will get normalized on listing. Probably a huge discount for "seed".
Yet... there has been no monetizaton mechanism described that doesn't involve us releasing code, as we have been very clear that we refuse to do a token sale until such time as we have a fully working system. So, I am not sure how your theory works out here, but it will be interesting to see if you comment back here once we release code for you to actually run.
As for why we want whitepaper feedback: that is because we believe in peer review of design.
Very good question that I'm curious about as well. The cynic inside me could think of some nefarious reasons, but I can also imagine some legitimate ones, such as taking a cut of the eth made in bandwidth transactions, and opening up markets for other services that were previously impenetrable, such as China.
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.
Are you talking about https://www.torproject.org? We have different standards for websites it seems. That looks like it jumped out of the mid 90s to me.
This sounds like a good idea. One problem with things like tor and i2p is you want to have tons of traffic so as to hide things from the various spies, but it is hard to get enough people to support nodes. Add a token and perhaps that problem will be solved.
A token seems to solve the supply side (relay and exit nodes) but what about the demand side? Why would anyone who doesn't care about subverting censorship or surveillance pay for this?
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.
> This would be a disruptive inconvienance [sic] for Chinese business people, deeply effecting [sic] commerce, as well as quality of life for the average Chinese citizen.
This sentence has two typos. It should be changed to:
> This would be a disruptive inconvenience for Chinese business people, deeply affecting commerce, as well as quality of life for the average Chinese citizen.
But TBH, stating that the lack of WebRTC or VPS web hosting would, "deeply affect the quality of life for the average Chinese citizen," seems like hyperbole. Maybe:
> This would be a disruptive inconvenience for Chinese business people, deeply affecting commerce and web access for millions of Chinese citizens.
You caught this answer right before it was updated with a much longer answer that I had written a couple days ago (and which fixes at least one of those typos). Would you mind reviewing it to see if you still think it is a stretch?
The answer you aren't looking for is probably something like "traffic cloaking" or "connection bootstrap", but my personal answer to that question is "so you sit down at a computer and download our software. you have a wallet full of cash and credit cards... now what?".
There's a lot of projects that sound exactly like this. What they all have in common is that they all use an Ethereum (ERC20/22) token and all have very large amounts of money flowing into them, from private investors, companies, ICOs, etc.
It would be nice to see more projects take routes that projects like tor take, where the founders do not accept millions of dollars of money before they even have a working and complete protocol.
Ethereum has some amazing potential and technology behind it but I lost interest in this the second I saw they had already raised $5M and haven't even done their ICO yet. Their FAQ section seems woefully incomplete given this amount of money.
Here's the tl;dr: a practical encrypted mesh network that can work over the traditional internet protocol (IP) or over real-world links and radio antennas.
Since the parent was deleted and I couldn't comment by the time I finished typing, here's the non-tl;dr:
The main advantage is non-hierarchical routing. Your ip address is in fact the fingerprint of your public key, which is used to encrypt all traffic.
Because of this the address allocation works a lot different and there's no need for a central authority. The lack of a central authority is usually a problem if you ever tried to merge two large internal networks you might have run into the issue that both networks have used 10.0.0.1 for something. This isn't possible in cjdns because you can just generate as many key pairs as you want, which would map to one out of 2^120 possible addresses which are very unlikely to collide. Merging two networks is just a matter of configuring one or more peers and the networks are able to see each other (this is so easy, it might happen by accident).
The main difference to other projects is that you don't need to write code to support it. If your application supports unicast ipv6, your application is able to run on top of cjdns.
Tbh, this doesn't look like something that could scale to Tbps Bandwidths... It seems a lot of processing is required to properly route the packet to the next hop and that happens independently of whether the next hop is even remotely an ideal one.
There are some issues with cjdns with pure DHT on small footprint devices with poor connectivity. The author is hence currently introducing experimental supernodes, which are stable fat nodes with large memory which can build routes quickly.
1. at some point there will be an expensive hop across the ocean, or between cities, that will likely only be built once, then shared. Won't whoever owns that hop have similar centralized control of any non-local traffic, similar to an isp?
2. how meshy should mesh networks be? On one extreme, every computer can be directly connected to every other computer in the world. On the other, every computer can be connected to just one neighbor, and requests are routed through many hops. What is the prevailing wisdom on the optimal amount of peers nodes should have on average in a mesh network?
One question I still haven't found answer to: what's with the name? What does it mean / why is it the way it is?
Should it be read as CJ DNS, i.e. something to do with DNS? Or CJD (author's initials) NS (??? again, name server?)? C (?) J (JavaScript/Node) DNS?
Related, what the hell it is, actually? You say in other comment that it's a mesh network, they say it's a network, but I see a program to install. How a program is a network? What does it do?
Tor is a network, and yet you have to install a program to connect to it. You can think of the cjdns program like a driver that allows you to connect to a cjdns network.
To answer your question on what it does : cjdns is a routing protocol that intends to replace the current IP protocol. Like the standard IP protocol, it needs a way to communicate with another node to function (the default gateway). From there, you can communicate with the rest of the network. Your packets will go to the default gateway, who will then redirect it to the "closest node" recursively, until it reaches its destination.
You can setup cjdns over the current internet (essentially making cjdns an "overlay network" like tor) using UDP, or through an ethernet link.[1]
CJDNS indeed works in a mesh : anyone can route other people's traffic, somewhat similarely to tor. The only difference is that you need to manually configure your "Entry Node" (to lift tor terms). See [0] for the reasoning.
About the name, the creator is Caleb James DeLisle, so I guess CJDNS stands for Caleb James DeLisle's NameServer ? Doesn't really make much sense but I don't see how bad a thing it is.
"One question I still haven't found the answer to: what's with the name?"
"Where did the name cjdns come from?
Cjdns was based on a codebase which was originally intended to handle name resolution (DNS) and so it was a combination of 'cjd' and 'dns'. The project changed direction early on and currently is still lacking DNS resolution but the name stuck. Make up your own acronym for it if you like."
What is it? The author has said it is meant to be a single binary: a router. The router accepts "customized" IPv6 addresses, e.g., each address contains a public key fingerprint. The packets are also custom, each containing a full route to the destination, which might be reminiscent of the bang path in UUCP. The nodejs stuff is just a prototype method of getting data from the router.
I remember watching a video of him explaining this at a cafe a number of years ago. Not sure if that was the first "public announcement". In that video he mentions a concern over censorship via DNS. And then he states that at a certain point he realized routing was easier to do than DNS.
He uses NaCl. As for the name "cjdns" and why he started out experimenting with DNS, my guess was always that the original experimentation he did with NaCl was probably related to encrypting and forwarding DNS packets (or perhaps custom "name system" packets), since encrypting DNS packets was the "PoC" for NaCl.
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.
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.
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.
Projects like bitcoinereum will try to make ICOs more reasonable. You don't preprogram how much the founders get. It's less susceptible to abuse. It's the bitcoin blockchain implemented on ethereum and lets anyone mine by competing with transactions.
Since you brought up TOR and money, I would say one advantage this project has is that since payments are sent with packets, that will provide an stronger incentive for transmitters other than just for goodness of humanity.
I agree with your point . But there is a company out there called Althea-mesh,http://altheamesh.com. They have not raised a dime, however they have proof of concept products. Their next move is building commercial products.
Exactly. I ditched one of these save-the-world projects recently because they did little but talk about fundraising and how to distribute their buttload of tokens to each other.
195 comments
[ 0.28 ms ] story [ 81.3 ms ] threadThe Orchid protocol uses an overlay network built upon the existing Internet, which is driven by a peer-to-peer tokenized bandwidth exchange.
The orchid protocol is an open-source overlay network that runs on top of the Internet. Its fully decentralized, because rather than traffic being routed through central authorities—your ISP or your VPN—it’s instead routed randomly through a network of bandwidth contributors who sign up to share their surplus bandwidth and activate their Internet-connected device as a “node.”
Users that want to access an uncensored Internet (bandwidth consumers) pay the bandwidth contributors in Orchid tokens through a peer-to-peer exchange. Because neither the traffic nor the payments can be monitored by central authorities, both contributors and consumers of bandwidth enjoy a fully anonymous, surveillance-free experience.
Also of note:
Who are the founders?
Stephen Bell: Steve started companies in Europe, the U.S., and China before founding Trilogy VC China, where he spent 10 years backing Chinese seed stage startups.
Brian J. Fox: Brian is an entrepreneur and open-source advocate, the first employee of the Free Software Foundation, and the author of the GNU Bash shell.
Jay Freeman: Jay is a software engineer and the developer of the Cydia software distribution platform used on millions of jailbroken iOS devices.
Gustav Simonsson: Gustav is an engineer and developer who helped launch Ethereum in 2015, working with core protocols, clients, and security auditing.
Dr. Steven Waterhouse: Steven is an experienced investor and entrepreneur, having co-founded RPX Corp, led cryptocurrency projects at Fortress and Pantera Capital, and the Honeycomb product at Sun Microsystems.
[Edit] I _think_ they are trying to create something like Etherium but for decentralized internet.
Financial incentive for running relays.
All of our work is to be released under the AGPL3; and, while we have filed for a patent, we will be licensing the patent to the world in a manner similar to how Mozilla manages their patent portfolio. Brian Fox, who is in charge of making sure we have a successful and inclusive open source project, was the original developer of the bash shell, was for a while the maintainer of GNU emacs, and was the first employee of the Free Software Foundation (as Richard Stallman was a volunteer), and so is keenly aware of how important it is for technology to be available to everyone.
(edit:) g_simonsson, who now has an account on Hacker News and has joined this thread, is Gustav Simonsson, another developer working on this project in charge of our smart contracts and payment logic. He was one of the core developers who worked on Ethereum, specifically focussing on blockchain security.
But this begs the question. How does the user get the public key and address of a node without connecting to a public directory? How does he know he's connecting to something trustworthy?
Given that context, you really just need the address of any node, not the address of a particularly "trustworthy" node, so you can get one from a friend's client or from a random website. We have discussed some alternatives, such as being able to put out a bounty on an existing peer-to-peer cryptocurrency blockchain (one which would have to not itself be fully blocked for you, of course). We also have been getting interest from some people in academia who have a number of other techniques, which again are mostly viable because of the background that "what if we can provide enough mitigations in the network itself and use what has been learned from blockchains to mean you don't need to find a trustworthy node".
As far as I've researched, I've not seen anything which would enable reliable NAT traversal which wouldn't also make the network traffic trivially identifiable.
STUN works only for certain types of NAT and requires servers which aren't behind NAT. TURN is an external proxy, so can easily be identified by monitors of the network.
The concept of Orchid seems nice but the actual implementation seems very hand-wavy.
Yes that was also my conclusion.
https://orchidprotocol.com/whitepaper.pdf
How about a more specific question. If someone uses Orchid to accesse a website, can the website identify their IP address?
However, I see now that I didn't bother answering your first question, due to the complexity of the second ;P.
> Is this anonymous like tor or i2p?
The answer to this question is "yes", though we are aiming to be even better than those projects (in different ways).
> We are working on techniques involving "traffic steganography" that will make the the traffic used by Orchid look like "normal" internet traffic (such as web requests and video calls). There are also existing simpler techniques such as "domain fronting", where you send your traffic to a large company such as Amazon--one which uses a CDN to efficiently route traffic--and cause their CDN to forward your traffic to your servers; this has been used successfully against the Great Firewall of China in the past.
> Of course, we also need to hide the list of destination servers, as otherwise these could be collected by the adversary and blocked outright. Our current solution to this involves cycling through large numbers of random IP addresses on various hosting solutions, which we believe will force anyone trying to block our traffic to end up blocking large areas of the internet--such as every server being hosted on Amazon Web Services--which would cause a serious problem for Chinese businesses and residents.
> For more information on this, see our discussion of Firewall Circumvention Features (Section 12) of our whitepaper.
> 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.)
2. What's your privacy policy? What do you log, and what could you log (but swear you aren't)?
3. What's the open source license?
4. What's your code rights assignment document?
5. Does this differ from "Tor, but supported with a cryptocoin to buy exit bandwidth instead of hoping for donations"
6. That's a lot of investors. How long do you expect to have to supply servers and bandwidth before the network reaches self-sufficiency?
7. What are the threat models this addresses?
8. How do you vet new nodes to determine that they are not being controlled by [DC|Beijing|Pyongyang|Ottawa|Moscow|Paris|...]? In particular, if one entity controls more than 50% of the nodes, is it likely that they can trace who is requesting what?
9. Are you planning on making this affordable by civil rights activists in poorer regions of the world? How so?
2) The network is not a centralized service. Assuming I understand your question (and I probably do not), one may as well ask where the privacy policy is for Bitcoin. When the network launches, there will be nodes run by us, and one could believe they are logging in a way that is different from other nodes. This is something that we are sensitive to, and, if there are any such modifications (and it is not clear that there will be), they will all be available and visible to the public (as even required by our choice of open source license!). Of course, I can make no such claim for nodes run by other people or companies, but that is always the case and we fall back to the underlying security properties of the network.
3) AGPL3
4) This is still being worked on, partially because I think it is incredibly important that we make it extremely clear to anyone who does give us copyright assignment that the code they give us won't one day be forked by some future version of the entity that owns the code to build a closed-source project, and getting that right in a way that it can't ever be changed is legal time we haven't finished allocating.
5) Yes! As one high-level and in my mind very interesting example, Tor actually is a centralized service where nine directory servers are able to decide the state of the network; we are accepting nothing less than a fully-decentralized system.
6) I do not have a particularly precise answer to that question, but the answer I believe in is "not long at all", particularly given that users pay for the bandwidth they are using from other people. Under one argument, we would be self-sufficient instantaneously because any bandwidth being routed through a server we set up to help bootstrap the network would be paid for by a user.
7&8) This is a question that would lead to a very detailed answer, and so I hope I can refer you to our in-progress whitepaper. If you have any further questions, I would be happy to try to get them answered ;P.
9) It is my personal opinion that, as bandwidth is a "wasting good", that it will be extremely cheap to purchase bandwidth. I will refer you to section 7.2 of the whitepaper, "How Much Will a Packet Cost?".
2. Given that todays secure overlay networks generally offer extremely bad performance in the Mbit region compared to using the underlay where 10G uplinks are becoming widespread for servers, and the extra hops increase latency, do you think secure overlays will ever be near enough to underlay speed to become widely used? Do you have experience how well ORCHID scales up? And out?
[edit: Don't mean to sound too harsh. I am very glad you're doing work in this area.]
That said, you are absolutely correct, and my colleague and long-time friend David Salamon (the person who has been the lead author of the whitepaper) wants that to be very clear. We are implementing bandwidth burning (and are even discussing some interesting extensions of this scheme involving both Turing-complete-w/-limited-execution-time programmable bandwidth burning as well as a form of global bandwidth burning), so whether you call that a "known weakness" for all of Orchid or not is slightly confusing ;P.
When we have actual software that someone could possibly use I am going to be pretty adamant that there are good disclosures in the UI with respect to the security tradeoffs, and for right now the whitepaper goes into extreme lengths to qualify what is or is not possible, in our current understanding, with and without bandwidth burning in place. (We are also looking into taking aspects of the algorithm and building it out with a proof assistant to have even greater assurances.)
2) One place where Orchid will hopefully shine (in the future tense, as this part is decidedly not yet implemented) is that we are working to allow multiple routes to/from the destination exit node using a scheme similar to MPTCP, which solves a lot of the bottleneck issues you normally find running through an overlay network.
BBC New article from 2007: http://news.bbc.co.uk/2/hi/technology/6971904.stm Running decentral market code and tech portfolio: https://github.com/Tribler/tribler/wiki
Notes after reading your whitepaper, latency and complexity matter. We copied the Tor packet layout and deployed a simple NAT puncture method to avoid difficulties. Your proposed approach looks like many years of work.
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.
(IMO this and the 'how do you plan to make money for investors' should be in the FAQ)
I cannot (easily) find answers to pretty much every question I have, and sorry, I'm not going to read through a 50 page whitepaper before I decide if it's worth it.
What is it, onion routing? There's some talk of ethereum, so presumably you can get eth for spending traffic? Exit nodes? hidden services? (I'm not going to run an exit node for obvious reasons)
Maybe I'm just tired or stupid but I can't really find anything that isn't marketing blurbs without going through the whitepaper?
I'm not forcing anyone to do anything here.
It sounds like this project is probably a little too early stage for you then?
Maybe let people play with it for a couple if years and distill it down a bit. If it still exists maybe try again.
I don't have a problem reading a whitepaper. But there's approx. 12 billion new etherum startups a day. So I just think a little tl;dr would be nice to know if it's something I care about. Because right now I don't know if I should care early stage.
Tor's nine directory servers are not run by tor itself. One employee runs one of the nine, the rest are different people from around the world, with different affiliations who are not under the control of Tor. You must get a majority of the directory servers to block something from the network, before it will be blocked. Its not any one of the nine that can do it, they need to convince five other people, none of whom they control, to also block before it is actually accepted.
How do you plan on dealing with abuse? Sybil attacks, or bad actors on the network?
Your Wikipedia page shows that you have something to do with Cydia, which is unlikely for me to remember but I guess that's it.
This is the first I'm hearing of probabilistic payments. Are you aware of any other systems, proposed or operational, using this to pay for bandwidth? It seems like a natural fit.
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))
How do they intend to make money?
...and will be at the eventual inquest I’m sure.
https://blog.colony.io/the-colony-token-sale-7ac14c845bc0
"Bandwidth contributors simply install Orchid and activate their Internet connected device as a node - either as a relay or proxy - and then they set permissions like sites they want to blacklist or whitelist, and they earn tokens into their Orchid wallet for sharing their bandwidth."
So hopefully the blacklisting will eliminate the problem of nasty content that plagues anonymous networks like Tor.
You cannot pair anonymity and security with censorship. They are fundamentally incompatible. So either accept that nasty content will be out there, or acknowledge that you don't actually want perfect anonymity and security.
This is particularly noticeable given that in some countries, such as the United States where I live, simply accessing the Tor website to download Tor will end up flagging you for further monitoring. If Tor had only as many users and exit nodes as it does right now, but additionally had, for example, a billion people in China accessing Wikipedia through exit nodes that refused to go anywhere but Wikipedia, that makes a world of difference. As it stands, people are actually actively discouraged and even shamed for using Tor to access random websites or ones that use a lot of bandwidth, as that means that they are using (or even "abusing") a limited amount of donated bandwidth that somehow needs to be reserved for those who "really need it" (and thereby, will be targeted just for that).
https://motherboard.vice.com/en_us/article/d73yd7/how-the-ns...
Are you concerned that,
1. If node operators have the power to control content, they will be held responsible for the content by authorities? For example, consider a node operator in mainland China who allows access to criticism of President Xi.
2. Unpopular content will be censored by node operators just like it is now by more centralized powers?
1) No, because I would personally advise people in China do not whitelist sites whose purpose is to access such content. It is not even clear to me that people in China would want to run an exit node at all. There are billions of people in the world in countries other than China that can run exit nodes for that content so people in China will be able to access it without fear, and without anyone in China taking on that level of liability.
2) No, but with the great benefit that because everyone is using the same network, even if somehow (and I do not think this will be the case) there are only a small number of nodes willing to access that content (and one would expect that, in the eventual limit, this number should not be smaller than the number of Tor exit nodes that currently exist; though again: I think it will be much larger), then they will be cloaked within the content everyone else is accessing.
Essentially, it doesn't work to say "people who need access to a secure messaging service should use a secure protocol and everyone else can use Snapchat", and it also doesn't work to say "people who need to access criticism of President Xi can use Tor and everyone else can use the regular Internet". I want a billion people who are also doing things that would be considered insane on Tor--like browsing Netflix!--to be using this service, and to pull that off we need lots of exit nodes, which in turn means incentivized traffic and whitelists.
Put another way: I don't care if there are only 0.0001% of nodes that let you access criticism of President Xi if that is 0.0001% of some insanely large number and the result is "at least as many nodes as Tor", as that itself solves the #1 problem using Tor: that even accessing the Tor website already marks you as someone who is suspicious (as it is here in the United States and the surveillance programs we see).
https://motherboard.vice.com/en_us/article/d73yd7/how-the-ns...
With the tor model you get very few nodes, because most potential operators are afraid of being arrested and/or object to a lot of content. You don't get remotely as many nodes as you need to make the internet free and more safe.
With selection, you get many more nodes and, as saurik points out below, you still will have a few for material that some governments censor. So it seems to me a model with selection is the way to go.
Others might want to have empty filter list to be a complete transit/peer.
Therefore I don't think there's much room for users who want to blacklist but are not rather looking for a whitelist.
The blacklist will grow and grow, while the whitelist size will be pretty stable.
That said, I haven't used it, so the implemented blacklist approach might already support the above cases and be sufficient.
When I say whitelist, I do assume prefixes in the DHT (or whatever design they're using) can be used, as otherwise the whitelist may also grow too big to be practical. If however it will gain the concept of domains or such (which is also kinda a prefix), a whitelist will also be more practical.
Tor exit nodes are not operated by many in various places where they would/could because of concerns of the exit node addresses being enough to legally ruin operators' lives, even though technically it's a pure transit. Nobody sues the county because someone committed vehicular manslaughter on their public road. But because laws are skewed against the Internet right now, all someone needs is an exit node IP to make you regret.
If, and there's little to analyze/go by right now public, nodes and everyone is totally oblivious to what packets are transmitted; and if also the packets stored on nodes' disks are encrypted/sealed, then one could assume a filterless system to be practical.
This is all speculation, based on the little info there is. I really hope the team has come up with better designs that obliviate the concerns surrounding Tor, and ideally also not suffer from Freenet like slowness.
EDIT: Of course, once you have a filter, you will need to deal with the responsibility like Youtube does. If you do not know what's on disk or passing through, which is the ideal technically, then it would be best for the Internet and free communication. So, I'm not sure if a filter is a good idea, if that means you get subpoena'd and held liable for enabling one too many whitelist subscriptions.
Freenet builds its own domain of content where people post websites that are hosted in a distributed fashion by the platform. What we are working on with this initial implementation is a fully-decentralized tunneling service to access existing content posted on the internet (so if you were to compare it to an existing technology, you might look at Tor, or the "out-proxies" from I2P).
For example:
"The distribution of Entry Nodes is a difficult topic. If oppressive governments are able to access this list, they will block user’s abilities to access the list."
Or simply, you know, go after whoever runs entry nodes. Or run their own entry nodes and, even if they can't compromise the network, trace the evil cypherpunks who want to use encryption.
Unfortunately, some practical and political problems cannot be solved with improved cryptography.
Also, at least for now, it is not a darknet, it is only for connecting the clearnet.
Also, from the FAQ:
>Can't NSA just hack into this too?
>No. Because of its fully decentralized approach, distributed architecture, and the size of the global network, Orchid cannot be easily hacked by any single government or entity.
That's not really a satisfactory answer. First, it doesn't answer the question. The question was not "can NSA easily hack into this." And I don't think the NSA is necessarily deterred by something being not easy. The bar needs to be higher than not easy, even if "not easy" is a polite understatement. Also relying on the size of the network means there is a bootstrapping problem, right? Hopefully they will get there.
This doesn't mean the system is bad... I'm just saying the FAQ answer is bad.
On the positive side, given the cred of some of the people involved (saurik!) I am optimistic this may well have a shot at working.
Here is the updated text that was written a couple nights ago by one of the people who helped design the protocol with me after being confused by the answer on the website.
> Yes. Our initial release targets China as the adversary, which is a more tractable problem. We may implment full Chaumian mixes in the future (which are immune to metadata/traffic analysis), but they are unlikely to be complete for our first public release.
Sorry for nagging, but I'm one of those skeptical of greedy people acting maximally greedy saving the world as a process waste.
Edit: typo
There's certainly economic incentives for all participants, and what I find interesting is that since we're open sourcing all the code, anyone can easily deploy another network with a different token (model).
This puts pressure on us to propose fair token model/allocations else we risk disruption by forks or simply new Orchid networks.
At this point, it's hard to say what actual distributions of wealth might look like if people start using cryptocurrencies in their daily lives, for example to route traffic over a network. But at the moment, the distributions of wealth are quite nuts. But if there is an overall "unfair" atmosphere in the crypto-economy, it's could make depending on this system of routing kinda suck in the long term, especially if peoples actual livelihoods are under the pressure of massive ad gaps. People "sell out" when they're perceiving some stress.
If we go 'all-in' on this kind of system, it might actually end up creating the same kinds of de-facto power imbalances we see today with conventional social media.
I'm not anti-cryptocurrency either. I actually own a little bit of cryptocurrency. I'm curious about its potential to dissolve existing dominance relationships non-violently. That said, I don't see it as an end. Moreso, I see it as a potential conduit of healthy, non-violent economic chaos.
I also recognize that this strange new alien could be "out of the frying pan and into the fire".
It may just be how it will ever be.
This is why the Finnish central bank's paper on Bitcoin called it a 'monopoly without a monopolist'.
I think the immutability of these kinds of protocols is certainly an improvement over the total control that economic stakeholders have in a centralized server-client architecture, with respect to power distribution.
However, it is worth noting at a super-super high level that we are hoping to get a large number of nodes running the network and we have parts of our system that involve proof of work in a way similar to a cryptocurrency blockchain like Bitcoin. If a node in the Bitcoin network is operating for the purpose of compromise, it need not be banned from mining blocks: the network is designed in a way to make it so that such a node would not be able to pull off the kinds of attacks that people care about unless it owns a significant percentage of the resources being applied to securing the network. Our network has similar properties.
Maybe a whitelist of nodes themselves? (mostly in jest there)
I suppose an agency with funding who can endlessly sockpuppet could gain a substantial portion of network nodes, but if they're unable to censor more than per-random-packet, a surveillance goal seems more likely. While this may not meet conventional definition of 'censorship', I wonder of the chilling effect. I suppose any such move toward a censorship-free network should expect surveillance. c'est la vie.
Thank you for taking time to answer my question.
Because surveillance is a potentially serious problem, it should not be used cynically to market some new product that just adds another layer but doesn't really solve the problem.
For the average person its not China or Russia but their own state that is a bigger problem as they have power over them and can interfere with activism, journalism, dissent etc. The intensive profiling by Google, Facebook and others is another problem.
Was the Internet designed to be anonymous? Governments control access and can stomp down at will. ISPs and telcos know who you are, server and vpn providers know who you are, Facebook and Google have a lot of data on you. Only the very committed and technically adept can perhaps attempt any sort of anonymity.
Something like Musk's satellites with some basic free access may perhaps be the first of many steps to some kind of anonymity.
One issue is that we have put a lot of effort into the whitepaper, and we really want people to review the concepts in the whitepaper and give us feedback on that, but I will say that it is highly likely (if not a foregone conclusion) that if we have source code available, code which we know isn't done yet as the whitepaper design has been leading ahead of the implementation in the code, that we are going to have people only downloading the code and giving us feedback on the code... but what we really need is feedback on the design, not the first draft implementation :(.
On the other side of this, our team includes someone from the Free Software Foundation who feels some strong moral pulls towards doing all of the development in the open immediately and yesterday. I have made sure that my code is ready to release on a moment's notice and still feel proud about what is out there (though there is one last super high-level thing in the organization of how the code for the network connects with code for services that I want to fix tonight, and issue that will be much easier to deal with fixing at the git level if I didn't think I'd be breaking anyone's clone).
As for why we want whitepaper feedback: that is because we believe in peer review of design.
What do they get out of it?
How and when do you intend to ‘exit’?
(Apologies for the skeptical tone, I think this seems like a cool idea.)
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.
Sounds like a security.
I think the website could be better if it said right at the top what it actually does and what it offers over competing services.
(Otherwise i fully agree, but the orchid one also looks like a badly implemented modern default theme)
And the design is nothing to scoff at. It’s not hip, but it’s functional and readable.
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.
I'd consider that to be worse than the risk of a semi-trustworthy VPN provider keeping logs, depending on your threat model.
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.
This sentence has two typos. It should be changed to:
> This would be a disruptive inconvenience for Chinese business people, deeply affecting commerce, as well as quality of life for the average Chinese citizen.
But TBH, stating that the lack of WebRTC or VPS web hosting would, "deeply affect the quality of life for the average Chinese citizen," seems like hyperbole. Maybe:
> This would be a disruptive inconvenience for Chinese business people, deeply affecting commerce and web access for millions of Chinese citizens.
It would be nice to see more projects take routes that projects like tor take, where the founders do not accept millions of dollars of money before they even have a working and complete protocol.
Ethereum has some amazing potential and technology behind it but I lost interest in this the second I saw they had already raised $5M and haven't even done their ICO yet. Their FAQ section seems woefully incomplete given this amount of money.
As novel as the idea sounds, i doubt this is it this time but lets hope for the best.
https://github.com/cjdelisle/cjdns
The main advantage is non-hierarchical routing. Your ip address is in fact the fingerprint of your public key, which is used to encrypt all traffic.
Because of this the address allocation works a lot different and there's no need for a central authority. The lack of a central authority is usually a problem if you ever tried to merge two large internal networks you might have run into the issue that both networks have used 10.0.0.1 for something. This isn't possible in cjdns because you can just generate as many key pairs as you want, which would map to one out of 2^120 possible addresses which are very unlikely to collide. Merging two networks is just a matter of configuring one or more peers and the networks are able to see each other (this is so easy, it might happen by accident).
The main difference to other projects is that you don't need to write code to support it. If your application supports unicast ipv6, your application is able to run on top of cjdns.
Supposed I have keypair A at a friend and keypair B for me, how is cjdns going to find the fastest route between me and my friend?
Atleast, as far as I can tell from this page.
1. at some point there will be an expensive hop across the ocean, or between cities, that will likely only be built once, then shared. Won't whoever owns that hop have similar centralized control of any non-local traffic, similar to an isp?
2. how meshy should mesh networks be? On one extreme, every computer can be directly connected to every other computer in the world. On the other, every computer can be connected to just one neighbor, and requests are routed through many hops. What is the prevailing wisdom on the optimal amount of peers nodes should have on average in a mesh network?
http://youtu.be/opKJsVTcofg#t=164 Ask the network for what you want. Not say 'who' you wanna talk to, but say 'what' you want.
Should it be read as CJ DNS, i.e. something to do with DNS? Or CJD (author's initials) NS (??? again, name server?)? C (?) J (JavaScript/Node) DNS?
Related, what the hell it is, actually? You say in other comment that it's a mesh network, they say it's a network, but I see a program to install. How a program is a network? What does it do?
To answer your question on what it does : cjdns is a routing protocol that intends to replace the current IP protocol. Like the standard IP protocol, it needs a way to communicate with another node to function (the default gateway). From there, you can communicate with the rest of the network. Your packets will go to the default gateway, who will then redirect it to the "closest node" recursively, until it reaches its destination.
You can setup cjdns over the current internet (essentially making cjdns an "overlay network" like tor) using UDP, or through an ethernet link.[1]
CJDNS indeed works in a mesh : anyone can route other people's traffic, somewhat similarely to tor. The only difference is that you need to manually configure your "Entry Node" (to lift tor terms). See [0] for the reasoning.
About the name, the creator is Caleb James DeLisle, so I guess CJDNS stands for Caleb James DeLisle's NameServer ? Doesn't really make much sense but I don't see how bad a thing it is.
[0]: https://github.com/cjdelisle/cjdns#2-find-a-friend [1]: https://github.com/cjdelisle/cjdns/blob/master/doc/configure...
"Where did the name cjdns come from?
Cjdns was based on a codebase which was originally intended to handle name resolution (DNS) and so it was a combination of 'cjd' and 'dns'. The project changed direction early on and currently is still lacking DNS resolution but the name stuck. Make up your own acronym for it if you like."
Source: https://github.com/SlashRoot/cjdns
What is it? The author has said it is meant to be a single binary: a router. The router accepts "customized" IPv6 addresses, e.g., each address contains a public key fingerprint. The packets are also custom, each containing a full route to the destination, which might be reminiscent of the bang path in UUCP. The nodejs stuff is just a prototype method of getting data from the router.
I remember watching a video of him explaining this at a cafe a number of years ago. Not sure if that was the first "public announcement". In that video he mentions a concern over censorship via DNS. And then he states that at a certain point he realized routing was easier to do than DNS.
http://www.youtube.com/watch?v=zINQYkl01N8
He uses NaCl. As for the name "cjdns" and why he started out experimenting with DNS, my guess was always that the original experimentation he did with NaCl was probably related to encrypting and forwarding DNS packets (or perhaps custom "name system" packets), since encrypting DNS packets was the "PoC" for NaCl.
Could you name the other projects that you think are better? Given the interest in this article I’m sure others would be interested as well.
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.
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?
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.
https://www.coindesk.com/saft-arrives-simple-investor-agreem...