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.

please note that we at Delft University of Technology have been working on a similar bandwidth-as-a-currency system since August 2007.

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.

(1)

In general some of the hardest problems / known weaknesses of the protocol at this stage is:

* Client bootstrap - what entry nodes to connect to? (saurik answered this in response to other questions)

* Current software connects to Ethereum nodes using an Ethereum light client, as Ethereum network traffic is not hardened it can easily be fingerprinted and blocked by GFW and others.

* Difficulty of medallion Proof-of-Work, basically it boils down to that if it's easy to join the network as a relay or exit node, then it's easy for a large attacker to join with many nodes. Making it harder for attackers to join / maintain active position in the network also makes it harder / more expensive for regular nodes.

* Payment anonymity. Currently it's as pseudo-anonymous as regular Ethereum transactions. Whitepaper has some discussion on future improvements there.

(2) The main driver here is economics - relay and exit nodes are paid by users for their bandwidth and relay of traffic. This forms an emergent, decentralized market that hopefully will find an equilibrium where there is plenty of overlay/secure bandwidth available at what the market prices it.

So far our models and simulations on this are limited, so we cannot make strong statements on how this will scale in practice. However, if we look at Bitcoin/Ethereum transaction (miner) fees, we see a live example of a working decentralized market that is very responsive and adjusts to supply/demand without any central intervention/control.

The 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)

Hi, another author from the paper here.

> 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.)

I'll bite with the simple one - How is this different from Tor?

(IMO this and the 'how do you plan to make money for investors' should be in the FAQ)

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'm not going to read through a 50 page whitepaper before I decide if it's worth it."

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.

> 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.

If only there was a document describing the details of the design that you could read

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?

I'm not forcing anyone to do anything here.

Yeah, I have the same problem. My solution has been to ask specific questions, saurik is good at answering those.

That isn't very precise.

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?

How do you solve the problem of penetrating NATs and firewalls without relying on a central coordination server?

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.

>The concept of Orchid seems nice but the actual implementation seems very hand-wavy.

Yes that was also my conclusion.

Is this anonymous like tor or i2p? if so, how do you do it?

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)!

https://orchidprotocol.com/whitepaper.pdf

The whitepaper is way over my head

How about a more specific question. If someone uses Orchid to accesse a website, can the website identify their IP address?

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).

Thank you for your answer.

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

I've seen your name somewhere before..

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.

FWIW, my name was pretty prominently in Cydia, so if you ever used it, you saw it a lot ;P.

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?".

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))