Orchid: a new surveillance-free layer on top of the existing Internet
Ok, I wasted a few hours reading the whitepaper. It was just as idiotic as you&#x27;d expect. Here are a few notes:<p>It seems like this takes Bitcoin and Ethereum electrical power waste to a whole new level<p><pre><code>  To produce a medallion, a peer takes a public
  key K , and the most recent Ethereum block hash
  E , then (iteratively or in parallel) locates a
  salt S such that H ( K, E, S ) ≥ N ,  where N
  is some difficulty scaling factor.
</code></pre>
And with all that &quot;an <i>anonymous</i>&quot; network <i>does not provide payment anonymity</i> (while amount paid correlated with amount of data sent). So this will disclose how much data each user put into the network. This is valuable if you can observe large amounts of data out of the exit nodes (like a government-scale actor might). This might even allow correlation between data and users.<p><pre><code>  We will argue that The Orchid Payments
  (section 7.12) fulfill all but the
  anonymity requirement.
</code></pre>
Yup... not anonymous at all...<p><pre><code>  The pseudo-anonymity of Orchid payments
  is equivalent to what can be achieved in
  regular Ethereum transactions

</code></pre>
But it gets better. While you can use anyone as a relay, you PREPAY them before they do any work for you. This is claimed to solve the problem of nonpayment, but nobody mentions the opposite problem: I take your money and do no work for you. The money cannot be taken back - I own it now. cool.<p><pre><code>  If there is some setup cost to Alice and
  Bob’s relationship ( S Alice , S Bob s.t.
  S Alice &gt; xy, S Bob &gt; xy ), the answer is
  yes.
</code></pre>
And for fun, it also messes with SSL. Allegedly only &quot;for good&quot;, but who&#x27;ll notice when this changes?<p><pre><code>  (see the entire section 10 in whitepaper)
</code></pre>
And then there is the completely not scalable method to prove you will route as required by the network. For that you need to literally get EVERY node on the network to sign off on the fact that you can route to them. So the size of this proof, its computational cost, and the time to complete it will grow as the network does. Total work done just to provide for network joining grows as N^2. Oh, and god help you in case of temporary partitions (like has happened in the internet a number of times when various underwater cables were cut). For extra fun, nobody mandates you actually <i>do</i> route anything. Only that you prove you can. I see nothing in there that prevents packets from being purposefully dropped after collecting payment for &quot;forwarding&quot; them.<p><pre><code>  (see whitepaper section 11.5)
</code></pre>
Oh, and if you thought this will provide <i>INTERNET</i> access, you are mistaken. Apparently HTTP w&#x2F; DNS only. As per whitepaper, exit nodes can filter based on domain. I am not even going to mention that running an exit node without a whitelist is idiotic (one user downloads CP, you go to jail). So everyone must have a whitelist? And just how big do you figure a typical &quot;whitelist&quot; of safe domains is? 100GB, 1000GB? Good thing you need to send it as a reply to <i>Get Offers</i> request.<p><pre><code>  (see whitepaper section 11.9)
</code></pre>
Blocking this is easy (as the whitepaper concedes) by DPI and blocking Ethereum. Whitepaper claims &quot;this will be solved later&quot; but offers not even a handwavy explanation of how this will happen while remaining compatible with mainline Ethereum clients...<p><pre><code>  (see whitepaper sections 12.3 &amp; 15.3)
</code></pre>
Of course, besides handwaving on &quot;it will totally be ok&quot;(tm), there are no real world performance numbers.<p><pre><code>  (see whitepaper section 13.3)



</code></pre>
But funny most of all, these guys didn&#x27;t address the simplest attack of all. Pretend to be an exit node, &#x2F;dev&#x2F;null the traffic, pocket the payment.<p>My guess: the scheme is simply to raise an ICO and laugh their way to the bank. (as always)