> 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.)
(Note I'm David Salamon, one of the white paper authors.)
I agree with your payment analysis. As you point out, we explicitly disclose that payments need modification before they will be at the level of anonymity required for Orchid. Anonymous payments for the Ethereum platform are being worked on right now by very talented teams. As we don't believe we have anything substantial to add to that conversation, we are deferring to them, and will simply audit and adopt the methods they design as soon as doing so is feasible.
> And for fun, it also messes with SSL. Allegedly only "for good", but who'll notice when this changes?
This is a fully general argument. Even if we didn't check the validity of certificates (which many phone apps don't do but should, hence our adding the feature), couldn't you still claim we might act maliciously in the future without anyone noticing?
(As you don't point out, our software will be AGPL3 licensed / open source. If one person notices and says something, everyone will notice. This is the logic behind trusting Linux, OpenSSL, Tor, etc... Are you aware of a better solution? I'm skeptical one exists.)
> Total work done just to provide for network joining grows as N^2
No, connection proofs are O(routing_table_size * per_element_proof_length). Routing table size is O(log(n)) and per-element proof length is the routing tables of the point-to-point route taken O(log(n)^2), so the proof is O(log(n)^3) -- likely much less in practice, as the successor and predecessor nodes are very likely to share every connection that the joining node needs to make.
This is good feedback, we should explicitly do that calculation in the whitepaper, added to the TODO list. Thanks!
> Blocking this is easy (as the whitepaper concedes) by DPI and blocking Ethereum. Whitepaper claims "this will be solved later" but offers not even a handwavy explanation of ohw this will happen while remaining compatible with mainline Ethereum clients...
The data which needs to be received is already defined by Ethereum's gossip protocol, so in theory adding Ethereum proxy support would be trivial. (Just proxy Ethereum traffic the same as any other traffic.)
We have not specified that, however, because we are worried about the possibility of a malicious proxy hiding some transactions from a customer. Once we feel like we have a good handle on how to analyze these kinds of attacks, and have a solution which mitigates them, we will add a solution to the whitepaper. This is somewhat outside our core product, and so has suffered a bit of neglect. It might be as simple as just receiving gossip from multiple independently chosen Relays, but I'd like to be more sure before making that the official method.
> Of course, besides handwaving on "it will totally be ok"(tm), there are no real world performance numbers.
We felt that publishing real-world performance numbers would be best left until after there was a real-world system.
> But funny most of all, these guys didn't address the simplest attack of all. Pretend to be an exit node, /dev/null the traffic, pocket the payment.
We do in a way. If a proxy behaves this way, Chrome disconnects, resulting in the attacker not being paid beyond a couple of kilobytes. This is not profitable, but still annoying. So the attacker causes a widespread nuisance, spends most of their time waiting for new customers, and suffers the loss of their CPU to proof-of-work. It's not profitable, but I expect some users will still do it for the lulz.
> My guess: the scheme is simply to raise an ICO and laugh their way to the bank. (as always)
(Note I'm not a cofounder)
I joined in spite of not being able to negotiate myself to anywhere near cofounder levels of token ownership -- I would probably have made more by accepting a different job doing mobile A/B testing software company.
I do think some of the cofounders are very much in this for the money, but I also think every single person on this team hates what's happening on the web with respect to privacy and censorship. If that changes, I'll probably end up leaving and working on this separate from them. (Well, or demanding more money?)
So basically: if I don't quit you can conclude they've either paid me to keep quiet, or I still like them. Best I've got for you.
> Ok, I wasted a few hours reading the whitepaper. It was just as idiotic as you'd expect. Here are a few notes:
Thank you very much for your feedback, sorry you felt it wasn't worth the time. Maybe next draft? :p
> Also, what about the other half of my points? ;)
Oh, sure, sorry about that. Did you edit the post I replied to? It looks like I only missed two points:
> 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.
Relays are sitting there burning their CPU while they wait for a customer to show up. This is a continual cost, which makes Relay/Proxy operation unprofitable unless they receive a steady stream of transactions. If they "take the money and run" they only pocket the initial payment, maybe as much as a couple kilobytes of bandwidth in tokens. If they "take the money and stay" they get a stream of payments from the customer. Therefore it's economically irrational for them to run -- the PoW's cost makes them boundedly trustworthy if they are economically rational.
(I sort of covered this in the /dev/null attack you proposed, as it's the same case except /dev/null has the attacker also uploading a bit of useless traffic. I should have been more explicit.)
> Oh, and if you thought this will provide INTERNET access, you are mistaken. Apparently HTTP w/ 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 "whitelist" of safe domains is? 100GB, 1000GB? Good thing you need to send it as a reply to Get Offers request.
Lol, yeah. Whitelists are dumb, but (as we seem to agree) not having them is dumber. I agree with your analysis. If they do become 100GB, etc we'll add queries to mitigate the size issue ("hey, do you support xyz.com?"), or any of the other relatively well studied solutions here (have I finally found a use for bloom filters? Unlikely.)
More broadly on the whitelist issue, my hope is that paying Proxies will result in actual "Orchid Proxy ISPs" springing up, which will have empty whitelists, actual legal protection as ISPs, etc. That's the beauty of real money being involved. Whitelists are there as a stop-gap while the market is being built.
> 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.)