BitCloud

fred concklin fredconcklin at gmail.com
Fri Jan 24 02:48:25 PST 2014


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: 10651 bytes
Desc: not available
URL: <http://lists.cpunks.org/pipermail/cypherpunks/attachments/20140124/5f4c3ac2/attachment-0001.txt>


More information about the cypherpunks mailing list