Slight typo, banks issue tokens, not reserves. :)
On Fri, Jan 24, 2014 at 5:45 AM, fred concklin <[email protected]>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 <[email protected]> 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 >> > >
