The bitcloud project is at the very early stages of conception. I wouldn't spend too much time criticizing it unless you also intend to work on developing the project with them. I imagine that in 3 months the ideas will look very different and hold up to more substantial criticism. Right now, they are well aware of the gaps in their ideas. On Fri, Jan 24, 2014 at 4:48 AM, fred concklin <fredconcklin@gmail.com>wrote:

Slight typo, banks issue tokens, not reserves. :)

On Fri, Jan 24, 2014 at 5:45 AM, fred concklin <fredconcklin@gmail.com>wrote:

...

from https://github.com/wetube/bitcloud/blob/master/bitcloud.org#protected-routin... —proof-of-bandwidth "Basically, the law is applied by judging (checking) that every node and client is doing the work as it should, so, when asked, it should answer with the truth of what is asked. If it is found that the node or client is lying, it is penalized or banned, and its transactions rejected are not included in the blockchain.

Laws are written in the source code in the form of *generics* and the corresponding *methods*. A *method* is a specific application of a *generic*. For example, for the *generic* of the Law of Bandwidth there are going to be several *methods* for judging nodes, users and publishers."

----------------

It all breaks down there. You can attack by polluting the network with nodes that share no bandwidth but report fraudulent bandwidth statistics of honest nodes. Moreover, fraudulent node collections can overreport their bandwidth capabilities, thus funneling all traffic into chokepoints. You can disrupt the network as well as build attacker controlled majority routes for traffic analysis and subsequent deanonymization of hidden service protocols and/or onion routing. They are describing a MIX network but they've removed the routing properties of an effective MIX network with their prioritization of nodes (thus partitioning traffic heavily in a nonuniform manner as it passes through the MIX). If they are not mixing and instead onion routing they sacrifice the beneficial property of onion routes being difficult for an adversary to observe by performing route selection in a geospatially indiscriminate manner.

In a system like Bitcoin, there is a set of transactions + the merkle tree hash of the prior blocks. The mining of a coin is computing the double SHA-256 sum of that data + an unknown Nonce such that the output is equal to a predetermined 2xSHA-256 sum output. The proof of work is guessing Nonce values and hashing.

In this system there is no known value that nodes race to compute. There is an assumption that there is some QoS snapshot that all nodes will agree upon. However, all nodes must collectively remark on bandwidth of other nodes while having no penalties and/or proportional voting power relative to bandwidth. There is no computational proof of bandwidth that can be proved and synchronized across the global network state. This system therefore does not possess Byzantine Fault Tolerance. Having failed to meet this condition, the notion of anything provable in the face of an adversary upon which value can be based should be met with a high degree of skepticism.

The inclusion/exclusion of transactions in the Bitcoin blockchain is based on the cryptographic integrity of the transaction (signed). In this system a blockchain entry is based on "whether or not the node is dishonest." If a node can fool the network for the duration necessary to get into a blockchain transaction (and transactions are atomic) then they have earned "value" while successfully defrauding the network.

This is from a cursory review. Rebuttals welcome.

Essentially, the authors presuppose that bandwidth can be mutually agreed upon by all nodes even in the presence of malicious actors. However, to determine a bandwidth metric upon which value is based, sets of heuristics are offered up in place of a definitive measure that cannot be tampered with / subverted.

-----------------

A piece of advice for people looking to extend anonymity protocols having to do with decentralized value transfer systems: consider the context in which the author(s) created the Bitcoin protocol and question whether or not a given objective was achieved. One possibility is that Bitcoin was an attempt to rectify the dependence upon physical commodities in digital bearer share systems such as eCache. In that sense it was successful. However, it may have failed in that running a digital bearer share system with reserves in Bitcoin is problematic for a number of reasons.

Try taking a crack at building a digital bearer share system in which Bitcoin is the reserve currency and there is a mapping of digital bearer shares to reserves in a manner such that the bank can not defraud clients by misreporting the reserves issued at any point in time.

If you build a system where two separate banks can operate with reserves in Bitcoin and the client can audit the number of reserves issued without implicit trust in the bank you'll have something very impressive. You may find it is difficult to solve this lack of trust in token issuers without recursively embedding a Bitcoin model at the bank level (w.r.t shares issued).

Such a system would provide low latency transactions, allow for fully anonymous banks, and provide financial transactions for clients with a higher degree of privacy enhancement than that currently offered by Bitcoin. Users of two separate banks could exchange currencies directly without ever touching the block chain. It simplifies the evasion of coin traceability and there could be both public and highly private collections of banks (where all you see is one [or more] bitcoin addresses [e.g., no real indication of their existence without prior awareness / infiltration]).

On Fri, Jan 24, 2014 at 3:27 AM, Rich Jones <rich@openwatch.net> wrote:

...

Tor-like anonymity network, but backed by a new cryptocurrency in order to pay for the relay bandwidth. It's a nice thought!

https://github.com/wetube/bitcloud http://www.reddit.com/r/bitcloud http://talk.bitcloudproject.org/ Meat: https://github.com/wetube/bitcloud/blob/master/bitcloud.org

More logos of the 'loading' interface than actual code at this point, which is certainly a bad sign, but people are at least enthusiastic about the idea. As an approach to solving the autonomy problem, though, I think I'm more interested in radios than new overlay networks..

R

On Fri, Jan 24, 2014 at 05:45:13AM -0500, fred concklin wrote:

from https://github.com/wetube/bitcloud/blob/master/bitcloud.org#protected-routin... —proof-of-bandwidth "Basically, the law is applied by judging (checking) that every node and client is doing the work as it should, so, when asked, it should answer with the truth of what is asked. If it is found that the node or client is lying, it is penalized or banned, and its transactions rejected are not included in the blockchain.

Laws are written in the source code in the form of *generics* and the corresponding *methods*. A *method* is a specific application of a *generic*. For example, for the *generic* of the Law of Bandwidth there are going to be several *methods* for judging nodes, users and publishers."

----------------

It all breaks down there. You can attack by polluting the network with nodes that share no bandwidth but report fraudulent bandwidth statistics of honest nodes. Moreover, fraudulent node collections can overreport their bandwidth capabilities, thus funneling all traffic into chokepoints. You can disrupt the network as well as build attacker controlled majority routes for traffic analysis and subsequent deanonymization of hidden service protocols and/or onion routing. They are describing a MIX network but they've removed the routing properties of an effective MIX network with their prioritization of nodes (thus partitioning traffic heavily in a nonuniform manner as it passes through the MIX). If they are not mixing and instead onion routing they sacrifice the beneficial property of onion routes being difficult for an adversary to observe by performing route selection in a geospatially indiscriminate manner.

I'm convinced (for the moment) that the anonymity cost is going to kill the project. For http://minco.me (which I wrote in a fit of political speech), I came to the conclusion that there must be some sort of 'local authority' as a 'method' to evaluate human-usable proof-of-work, and this would have to utilize the pre-existing legal and court infrastructure. If you can sue the operator of a node fraudulently collecting 'proof of bandwidth' rewards for theft, it might work. However, in a global network with no clear idea where (or who) the node operators are, it's going to take a lot more human mathematical and crypto work to prove bandwidth. All that being said, I'm encouraged that there is wild-eyed optimism and excitement about what's possible, so between my pet project for per-packet micropayments (I might as well call it IPv7), and bitcloud, we might collective make enough mistakes to learn how to make it happen.