BitCloud

[fred concklin]

from
https://github.com/wetube/bitcloud/blob/master/bitcloud.org#protected-routing
—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 at 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
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/html
Size: 10149 bytes
Desc: not available
URL: <http://lists.cpunks.org/pipermail/cypherpunks/attachments/20140124/20dbba60/attachment-0001.txt>