BitCloud

Fri Jan 24 06:08:41 PST 2014

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 at gmail.com>wrote:

> Slight typo, banks issue tokens, not reserves. :)
>
>
> On Fri, Jan 24, 2014 at 5:45 AM, fred concklin <fredconcklin at gmail.com>wrote:
>
>> 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: 11409 bytes
Desc: not available
URL: <http://lists.cpunks.org/pipermail/cypherpunks/attachments/20140124/f76c1f3b/attachment-0001.txt>