Scaling, Decentralization, Security of Distributed Ledgers

in cryptocurrency •  6 months ago

There’s no design published on the public Internet for a blockchain, DAG, or other variant of a distributed ledger which has all three qualities: scalable, decentralized, and secure. Also we’d like real-time, sub-second transaction confirmations. Bitcoin certainly can’t scale-out decentralized. Bitcoin was designed to be a surreptitious winner-take-all paradigm. Lightning Networks also won’t scale-out decentralized.

Here’s my compendium of research and analysis of the various extant, published attempts to design a secure, decentralized, and scalable ledger consensus system. I’ll reveal some of my formerly secret designs, insights, and exemplify the depth of my expertise. But I will withhold some of my best gems for just a little while longer.

I’ve been needing to write this blog for some time now given that I was researching this topic since 2013 with the intent to design a solution to this challenging problem. I’ve been slowed down considerably by a chronic health ailment (c.f. also).

This blog was instigated by a recent discussion with @‍tenpoundsterling, which was followed by a myopic, incorrect Medium blog extolling QuarkChain as a worthy design.

Refutation of the QuarkChain Whitepaper

The essence of the security of the QuarkChain ledger consensus system is presented in §3.4 Consensus Algorithm on pg. 19 of the whitepaper.

In 2015, I had contemplated this (c.f. also) exact design of a root (master) layer proof-of-work blockchain controlling numerous proof-of-work blockchain shards. I quickly discarded the design idea because it’s so egregiously insecure.

And sub-seconds confirmations aren’t possible in proof-of-work because the block period must be orders-of-magnitude greater than the network latency (and network latency isn’t scaling by Moore’s law). Otherwise the orphan rate becomes too high (c.f. the derivation) such that the chain might not even converge on a longest.

The QuarkChain whitepaper claims that the percentage of hashrate needed to double-spend drops from just over 50% in Bitcoin’s Nakamoto proof-of-work to (at worst1) just over 25%, which is already a horrible reduction in security (and selfish mining would be 17%). But the actual security is even worse.

There are numerous game theory security vulnerabilities related to incentives compatibility, transaction fees, and the ability of the miners to move their hashrate around at-will between root chain and any of the shards. Which include vulnerabilities similar to those that Byzcoin attempts but fails to fix about Nakamoto proof-of-work, as well as the failure modes of Byzcoin which I cited in my analysis of OmniLedger. Additionally I describe another vulnerability as follows.

Unlike with Nakamoto proof-of-work where all miners have a vested interest in not defecting and they all thus validate the blocks of each other, QuarkChain destroys that Nash Equilibrium because with control just over 50% of the hashrate of a shard, the attacker can censor shard transactions and/or extort high transaction fees. With 10 shards splitting 50% of the system hashrate that remains from the 50% for the root chain, the attacker would only need 5% of the system hashrate to wreck such havoc. With 50 shards, the attacker only needs 1% of the system hashrate. Rented hashrate attacks on proof-of-work altcoins are quite plausible. Verge is a recent example that such attacks aren’t just theoretical.

To prevent DoS attacks which destroy the scalability of the sharding wherein an attacker simultaneously issues a transaction to spend on every shard (note for scalability that shards don’t validate other shards and root chain miners don’t validate any shards), the hostage UTXO must only be spent on another shard after recording in the root chain a lock commitment. The committed shard can then validate the hostage UTXO lineage before accepting the transaction. Yet the attacker’s hashrate could move to the targeted shard to sustain the censorship/extortion indefinitely.

The double-spending protection claimed by the QuarkChain whitepaper is impotent against the above attack, because it only records the shard’s block hashes in the root chain. Only the shard’s miners validate and determine the contents of the blocks in the shard.

Merkle tree based fraud proofs issued by honest observers can’t prove anything about censorship of transactions.

Presumably as a coordination mechanism to override the above attack, QuarkChain proposes the mechanism of super-nodes in §5.1 Horizontal Anti-Centralization Scalability Expansion on pg. 24 with the union of super-nodes providing validation for the root and all shards. What the QuarkChain designers apparently don’t realize (or don’t want us to realize) is that these super-nodes must collectively possess just over 50% of the system hashrate for their decisions on validation to be adhered to. So in essence QuarkChain must be run by an oligarchy of whales who coordinate their validation of the entire system. Centralizing a ledger is a way of obtaining scalability, yet a distributed and centralized database isn’t accomplishing anything for trustlessness and permissionlessness. The antifragility vulnerabilities of centralized cartel control are:

  • a single-point of weakness that can be attacked, e.g. by the government regulators.

  • the cartel wants to maximize the extraction of rents from the system.

  • such maximization may turn against the best interest and desired features the users of the system want and need.

OmniLedger which I analyze below resolves this problem by creating shards which have a PBFT consensus algorithm instead of proof-of-work (which has a higher security threshold of 67%) and the set of validators is randomized2 so that the attacker can’t target a specific shard so as to weaken the security below that of the root chain’s 50% proof-of-work security threshold. One disadvantage of the OmniLedger design is that the liveness drops to 33% which is one of the weakness of any deterministic Byzantine agreement protocol such as PBFT.

As shocked as I am that (Ethereum's Casper design team lead by) Vitalik expended 3+ years to produce a totally flawed slashing proof-of-stake design (c.f. also), I am perhaps even more shocked at the blatantly obvious insecurity of the Quark[Quack]Chain design considering the number of PhDs listed in the §9 Development Team on pg. 35 and §Advisors on pg. 37. But really this should be expected from an opportunity cost economics analysis in the current gold-rush FOMO (fear-of-missing-out) race to extract a slice of the greater fool, agape n00bs speculative bubble. Even dozens of celebrities are pimped in the gold-rush.

Seriously, QuarkChain is more or less as useful as any of the series of shitcoin parodies such as the 100% Useless Token and those [ANN]ounced by the outrageously hilarious Gleb Gamow, which include the Bitcoin Pussy “The Wife of Dick” and YuTü.Co.in “Catering to YouTube 📷 Creators”.

As I proceed below responding to the QuarkChain whitepaper’s summary analysis of competing attempts to design a scalable, decentralized, secure ledger consensus system, I’ll explain the tradeoffs in the extant, published designs for other projects such as Bitcoin (Nakamoto proof-of-work), Lightning Networks, Ethereum, EOS (DPoS including STEEM) , OmniLedger, and other proof-of-stake derivatives such as NEM, Nxt, NEO, Qtum, etc.. And hybrids such as Dash and PIVX.

In a subsequent section I’ll cover the DAGs such as Byteball, Hashgraph’s Swirlds, Iota, and SPECTRE. And finally hopefully I will add a section on reputation-based designs such as Radix (formerly named Emunie) and Stellar’s SCIP consensus systems.

1 The 25% presumes a large number of reasonably equivalently hashrate weighted shards that divides the other 50% into a very small percentage. Thus the 25% rises to for example ~30% if there are only 10 shards. That is in the presumptions of their (incomplete and inadequate) conceptual security model.

2 Note it wouldn’t be secure to randomize the validator sets for the proof-of-work shards of QuarkChain because unlike deterministic Byzantine agreement protocols, proof-of-work isn’t one vote per cryptographic identity (i.e. per validator). There’s no way to limit or know the hashrate of each such identity and that’s why it’s useless to even assign identity to miner validators in proof-of-work.

Decentralization

Quoting from §2.2 Decentralization issue on pg. 12:

The mining pool encourages centralization and becomes a risk for decentralized POW blockchains.

Incorrect. POW mining pools (such as for Bitcoin) are not winner-take-all nor are they a sustained 51% attack risk, because individual miners can change pools. There’s even the getblocktemplate pool protocol which can enable the individual miners to choose which transactions go into the block they mine. Also there’s P2Pool but it can in theory be DDoS delayed and would have non-optimal performance if attacked. Yet none of these decentralization protocols are significantly used because they’re unnecessary per my first sentence and the more straightforward protocols work best.

Rather as I explained why recently for @tenpoundsterling, the economics of POW and the inherent game theory of blocks is the fundamental paradigmatic reason that POW blockchains (such as Bitcoin) trend towards centralization and are winner-take-all end games. I researched this intensely since 2013 and I've concluded that it’s impossible for there to be any change to POW which would prevent the winner-take-all outcome. Satoshi never claimed that Bitcoin’s end game was decentralized (although Bitcoin was initially decentralized when launched), only claimed that POW is “distributed”, and stated an expectation that Bitcoin mining would become dominated by large commercial entities. I wrote:

The thing is, you can't centralize something that is inherently distributed

Nonsense. Understand the distinction between the meaning of the terms ‘decentralized’ and ‘distributed’. Decentralization refers to the concept of who controls what. Distributed refers to the topology of the nodes of the network. If 51% those nodes are surreptitiously controlled by the same entity, then the blockchain is entirely centralized. With selfish mining that threshold drops to 33%.

Also I debunked the POW as space heaters argument in an excerpt from a late 2016 rough draft of the CRED project’s forthcoming whitepaper. I also explained the aforementioned power vacuum economics as an abstract macro-economics concept.

This combined with other factors such as:

Are why I have concluded that “Satoshi Nakamoto” was a pseudonym obscuring a secret task force of the “Satan’s global elite” and Bitcoin was mostly likely designed by the global elite in order to surreptitiously foist a world central bank by way of creative destruction of their own nation-state central banks. Note the natural law’s (i.e. collective human nature and physics of the universe) “Satan” wants to own your soul with the coming 666 system and thus Satan’s global elite always must give you your free will and allow you to choose to enslave yourself. Thus Satoshi never outright lied, but rather employed double-speak and deceptive truths. He was perfectly accurate with exquisite, meticulous attention to detail.

Click all my links if you want to more deeply grok the summary I have written here.

Secure, DEX (Decentralized Exchange)

Quoting from §2.3.1 Multiple blockchains on pg. 13:

Having multiple blockchains also limits cross-chain transactions to [centralized] cryptocurrency exchanges which charge trading fees, have long processing times, and are notoriously unsecure[insecure].

Not entirely correct. Secure and decentralized cross-chain transactions can be achieved:

  1. A cut-and-choose protocol can be employed to enable decentralized verification that there’s no fractional reserves and centralized exchanges actually control the tokens which they claim they do. But that doesn’t prevent the centralized exchange from being hacked (by itself lol). The insecurity of cryptocurrency held (for any appreciable length of time) by centralized cryptocurrency exchanges can be fixed with an innovation I contemplated but have not yet implemented. A Hashed Time Locked Contract (HTLC) can be employed which only allows the committed tokens to be spent to the exchange and no other third party. Essentially this is analogous to a dedicated Lightning Networks (LN) connection between the exchange user and the exchange. The user can then trade these tokens instantly on the exchange by issuing a signed transaction to the exchange. Due to the HTLC commitment, the exchange knows the funds can’t be double-spent to another party before that transaction is confirmed in the blockchain which thus enables instantaneous confirmation upon receipt of the signed transaction from the user.

    However, in that simplistic design the exchange has possession of the tokens for brief time until it issues a corresponding HTLC payout of the traded tokens to both (all) parties of the trade. More ideally would be cross-chain implementation of the LN protocol which would remove ownership control from the exchange and merely have it acting as a liquidity provider hub to facilitate the HTLC channel trade transactions between the end users. This however will introduce a different form of risk in that the security becomes vulnerable to either of the blockchains in the transaction becoming compromised by an attacker. Yet that risk is probably small when trading between secure pairs. And this security risk doesn’t metastasize as a domino insecurity effect through all trades ever completed as is the case for side-chains that share the same (i.e. fungible) token. Deploying LN for his use case seems to be beneficial unlike the problems with the general deployment of LN discussed in this blog. ZigZag is an example implementation purportedly employing the LN protocol for the exchange so that the traded tokens instantly change hands on both sides of the trade without the exchange ever having ownership control. Regulated exchanges may not be able to adopt the current LN protocol because of lack of KYC/AML compliance, although this LN protocol design perhaps could be altered to carry KYC information.

  2. The aforementioned LN solution for exchanges has the advantage of fast, highly liquid trades, but it has the disadvantage of relying on a centralized hub to serve as the liquidity provider which means it will take fees and it could enforce KYC, break anonymity, and otherwise be regulated by authorities, even though it would be secure.

    I had explained in early 2016 that @‍TierNolan’s proposed decentralized, atomic, cross-chain transaction protocol could be indefinitely jammable because a race condition existed wherein there was no way to prevent the attacker from repeatedly refusing to release the signed transaction and re-entering every transaction the honest party offers. I rebuked the proposed solutions:

    • Forfeiting a deposit risks the honest party’s deposit because there’s no 100% reliable/objective way to differentiate between a network outage and an attacker that refuses to send. Moreover, the jamming problem arises also on the commitment of the deposit to the specific trade, so it solves nothing.

    • Requiring all parties to have reputation (and Coin Days Destroyed) equates a newbie with an attacker and prevents them achieving a reputation. Also reputation is centralizing too-big-to-fail and domino-effect antifragile as I explained to @‍tenpoundsterling in the context of rebuking the Hashgraph concept.

    If the jamming problem of the commitment of the deposit could be solved (but I highly doubt that), then a proposed solution could be that newbies risk deposits (to presumably rare network outages) in order to obtain reputations, after which time they wouldn’t need to deposit. But reputation breaks anonymity, which is important for even for businesses who don’t want the competition tracking all their trades and potentially for achieving their privacy policy. It might be possible to achieve homomorphic encryption of reputation analogous to how Zcash works for transaction data, but even if this vaporware is possible it would not a protocol which every blockchain would support now and the overhead of such technology is currently onerous.

    Viable Trustless Cross-chain DEX Protocol

    In early 2017, I devised a simplified protocol for truly trustless, decentralized cross-chain trades which removes the jammable race condition. I publish it widely now for the first time (had originally published it to a Pastebin which I think not very many people were aware of). The HTLC escrow requires OP_CHECKLOCKTIMEVERIFY (OP_CLTV) (which was introduced into Bitcoin by SegWit) on every blockchain for the token of the bidders. This protocol can’t be achieved with nLockTime. The ask side of the trade must be on a blockchain (or any form of decentralized ledger) which implements the following protocol. The asker issues an ask offer open to all bidders and this is confirmed by the ledger. The ledger is then able to automate the release of tokens being offered by the asker if a bidder’s transaction is confirmed. Thus the bidder has no risk of the asker jamming the trade by refusing to release the signed transaction.

    Multiple bidders may commit to a HTLC on the blockchain for the token they’re offering. Bidders which are not chosen to complete the trade are refunded automatically by the HTLC. The ledger for the ask side selects and commits to one of the bidders. The chosen bidder must release the signed transaction before the ledger for the ask will release the tokens. The bidder can trust the ledger because by definition a decentralized ledger is trustless and always fulfills the protocol.

    The bidder could fail to release (and obtain a refund via the HTLC) but this is not the race condition of @‍TierNolan’s protocol, because there’s already a list of alternative bids confirmed on the bidders’ blockchain which the ledger for the ask side can opt to next. The attacker would have to get to the back of the line to re-enter the same attack. Thus if even one of the bidders is honest, then presuming the time lock duration is sufficient to try all the bidders, then the trade will succeed (after some delay) and not be indefinitely jammed.

    Also my proposal requires only very little delay to wait on the bidder to release the HTLC solution, thus can cycle through the bids much faster. Also the bidder's funds are locked up for some time before they are refunded so this isn't cost free (time opportunity cost) for the attacker. Also bids in the same block could be prioritized by the ones with the longest refund time, so that time opportunity cost can be ramped up as needed to squelch attacks. This is a clever solution to @‍TierNolan’s ingenuous but flawed concept.

  3. The aforementioned LN solution for exchanges also has the disadvantage compared to centralized exchanges that many traders want to employ leveraged margin and/or to sell short. So the greatest liquidity will be on exchanges that offer margin and short-selling, but DEX isn’t compatible with these features for the analogous reason that pegs aren’t stable.

    • Must have another token to borrow to go long, and to sell to (or at least a price feed for settlement) for long and short margin trading respectively. A blockchain could have two tokens, but that would really be the same as different assets. Bitshares' tried to solve this problem by pegging external assets but all pegs are unstable and eventually fail.

    • Settlement ordering of trades (and also w.r.t. to who is providing price feeds if using those as documented as problematic in Steem’s whitepaper) can be gamed by the witness, miners, or whom ever is ordering the transactions in blocks. Because settlement order moves prices, etc..

    • Too much leverage in the system can cause margins to be exceeded and those who loaned tokens can lose some tokens. This is analogous to debt defaults due to excess extension of leverage in the fiat world.

    The idea of pegged assets (e.g. BitBTC, BitLTC, BitUSD) trading on the same blockchain as a form of DEX is flawed because no peg since antiquity has ever remained stable long-term because pegs increase the profits of those who arbitrage externalities against the peg because stable pricing is not normal so there’s profit to be made in betting against stability. The peg can be attacked by for example taking a leveraged short or long position and then overwhelming the liquidity that maintains the peg. For example, when speculators were expecting a collapse in the price of STEEM, there was an exodus into STEEM DOLLARS (SBD) causing the peg to break. StableCoins proposes to instead allow a band of volatility in the peg in order to reduce the liquidity required to maintain the peg. That has a potential of maintaining the peg longer, but eventually there will be an arbitrage opportunity which overwhelms any meaningful parameters chosen.

    Thus Tether (USDT) is corrupt. One can surmise that the likely way they got exchanges to use it, is by sharing the fractional reserve pie with the exchanges. When USDT fails that could cause another cryptowinter.

    Plausibility of DEX Usership

    Without short-selling, the OTC (i.e. DEX) markets can go no bid. While OTC markets function well during normal times, their lack of transparency can cause a vicious circle to develop during times of financial stress, as was the case during the 2007-08 global credit crisis. Mortgage-backed securities and other derivatives such as CDOs and CMOs, which were traded solely in the OTC markets, could not be priced reliably as liquidity totally dried up in the absence of buyers. This resulted in an increasing number of dealers withdrawing from their market-making functions, exacerbating the liquidity problem and causing a worldwide credit crunch.

    OTC markets will have huge spreads at times.

    People only use OTC markets when they have no other choice, such as to avoid regulations or the only place where certain assets are traded. Because OTC markets have inferior liquidity, spreads, and pricing information (transparency). Thus OTC markets will only be popular when normal exchanges are too painful. If ever exchanges become too regulated to the point where a large number of people want OTC markets, then a DEX will be viable. But not until then.

    Leveraged trading is impossible in DEX (will always fail eventually). Thus it is interesting to note that OTC is plausible only in a scenario where centralized exchanges are no longer viable, i.e. seems to correlate well with the slow death of fungible money over the coming decades. So perhaps DEX will become important in coming years. Banning short selling is the fungible money fiat system in its death throes.

  4. Bitsquare is not trustless and requires reputation and security deposits— all of which can fail as already explained.

Lightning Network (LN)

Quoting from §2.3.2 Lightning Network on pg. 13:

The basic idea is to defer frequent transactions among a fixed group of parties until all parties are finalized with the transactions.

Actually LN can’t function that impractical way where any fixed group (i.e. subset of users of the blockchain) all coordinate to open LN channels (which are variants of the aforementioned HLTC) on the blockchain, such that they’re all reachable to each other within their respective liquidity balances. Payment systems function because anyone can pay to anyone at-will. Instead the only viable way LN can function is (as I @‍iamnotback explained to the creator of Bitbay David Zimbeck) with the centralization of “Mt.Box” hubs (a term that was coined by the LN’s progenitor) that will allow for existence of fractional reserves analogous to centralized exchanges such as Coinbase. Also the LN routing algorithms are undecidable (or at least impractical) in any purely decentralized formulation. And LN can plausibly steal your funds (c.f. also) even without a 51% attack.

I wrote:

You’re missing the point that LN will not function correctly with many small overlapping circles providing the chain of connectivity from end-to-end for any user-to-any-user. The routing algorithms are implausible in that configuration. And there’s a bottleneck in liquidity because the distribution of fungible resources is not uniform nor even a bell curve in nature, but rather power-law distributed. So these chains of illiquid circles can’t handle the require liquidity surges. Also in order to significantly reduce the load on the blockchain, then there needs to be huge centralizing “Mt.Box” hubs […] that will allow for existence of fractional reserves analogous to centralized exchanges such as Coinbase […] For these and many other reasons, LN is a centralizing, fractional reserve system that can significantly accelerate the inevitable “winner-take-all” centralization of Bitcoin.

In an excerpt from a late 2016 rough draft of the CRED project’s forthcoming whitepaper, I cited explanations of these points which provide more detail and also the fact that settlement to the blockchain also requires coordination otherwise chaos could result such as random spike transaction loads which are higher than without LN.

Additionally as I had pointed out in one of my 2016 blogs, the SegWit “anyone can spend” addresses incentivize the formation of mining cartels because the 51% attack is amplified from formerly being only able to censor transactions3 to stealing the SegWit transactions. This potential theft of LN transactions is distinct from the risk which I already mentioned (before the quote above). Possibly LN can be designed not to employ SegWit but even so there’s nonzero risk in such a complex design of some inherent game theory or protocol design flaw could amplify the 51% attack to theft capability is another way as exemplified when I discovered that @‍TierNolan’s cut-and-choose protocol so elevated the 51% attack to theft capability.

3 Don’t equate a 51% attack which attempts to change the protocol with one which steals, because the former is an objectively visible fork which users can choose to not follow and the latter is not objectively discernible (← links to an excerpt from a late 2016 rough draft of the CRED project’s forthcoming whitepaper). With enough users complaining that their funds were stolen or with evidence of a very long-range chain rollback, the community might presume an attack has occurred but it can’t be unarguably and objectively proven that the users are not lying. The attacker’s fork may present many other users and alternative community archives of chain history which show they’re being stolen from if the orphaned chain were to be followed. The only objective truth is the longest chain.

Then one of the parties would just post the final result without incurring multiple historical transactions on chain.

LN really doesn’t propose the perfection of only one on chain settlement transaction per grouping. Rather it proposes that the number of on chain settlement transactions will be much lower on average than would have been required otherwise. Note my aforementioned issue with spike loads potentially being higher, especially if highly centralized “Mt.Box” hubs aren’t coordinating their on chain settlements.

However, the Lightning Network is only suitable for frequent transactions among a fixed group of parties, while it is inefficient if a user’s transaction target is random and happens sporadically.

That’s correct, except centralized “Mt.Box” hubs can make it suitably efficient but at the detriment of the loss of antifragility via centralization, fractional reserves, and thus eventually loss of funds via bank runs, theft, or government confiscation/regulation of hubs.

This prompts the question whether it is necessary to build another centralized payment method when there are already many out there.

Of course it’s necessary because it’s the competition over whom is going to winner-take-all the Bitcoin blockchain which is perhaps the future international reserve currency (or one of the currencies/commodities that will be in the an IMF weighted basket). Understand the actual game ongoing. The Bitcoin blockchain has international scale and wrecks jurisdictional arbitrage havoc with the regulations of nation-states.

Sharding and Side-chains

Ethereum

Quoting from §2.3.3 Sharding on pg. 14:

Ethereum has adopted sharding technology to scale out, and its phase one development is near completion.

In addition to sharding, Ethereum is[was?] also planning to adopt a variant of proof-of-stake originally name Casper which has a slashing design that proposes to confirm concurrent blocks presumably to lower the confirmation time and increase throughput. However, yesterday I wrote five shocking comments (1, 2, 3, 4, 5) on Vitalik’s Medium blogs about this technology. My aforementioned linked comments explain in sufficient detail that Ethereum’s proposed slashing and concurrent blocks confirmation algorithm is fundamentally and irreparably insecure and would also diverge into innumerable forks.

So unless I am mistake in my analyses, before Ethereum can even attempt to institute sharding, they must completely redesign their proof-of-stake consensus algorithm which has already consumed more than 2 years in research. Or adopt some extant scalable consensus algorithm such as DPoS which powers Bitshares, Steem, and EOS. Or OmniLedger. Yet those extant consensus algorithms are also flawed with limitations such as on how low the confirmation latency can realistically be, and flaws of lacking security, antifragility, permissionlessness/trustlessness, decentralization, and/or viable political economics.

Cosmos, Blockstack

However to adopt sharding on an existing blockchain is complicated, and it is estimate to have 3 to 5 more years to go before Ethereum can fully support other fundamental sharding features, such as cross-shard transactions. The main challenges for sharding include cross-shard transactions, security issues like single shard take-over, and further scalability issues.

As I have explained in greater detail within my aforementioned linked Medium comments, in my numerous comments (under my various usernames including @‍eca.sh, @‍TPTB_need_war, @‍iamnotback, @‍Hyperme.sh, and @‍CRED.me) in the Ethereum Paradox and DECENTRALIZED crypto currency threads at bitcointalk.com, in a Medium post about Blockstack, and in two threads (#46 and #47) I had started at the Cosmos project’s Github, sharding is inherently insecure against double-spends if there’s one deterministically validated total order (i.e. one consensus) for all the shards. Or stated in another way which will be important for understanding what is different about the consensus algorithm I designed, all shards must be validated by all of the validators from all the shards that participate in the same total ordering (of shards)— which is a requirement that one would think always defeats the entire scalability of sharding. And all the said validators must have sufficient economic, game theoretic incentive not to defect from correct consensus.

I explained in one of my Medium comments that security deposits aren’t a robust security solution because they don’t resolve the nothing-at-stake problem of proof-of-stake. Thus the security of proof-of-stake depends on trusting the whales who control it, i.e. proof-of-stake (including DPoS) are centralized (and distinguish decentralized from distributed) and not trustless, nor permissionless systems.

Sharding exacerbates this weakness because it attains scaling by not requiring every full node to validate every transaction from every shard. Thus sharding introduces the need for full nodes to trust each other. Since security deposits don’t provide a trustless solution when combined with cross-shard (or even cross-side-chain) fraud proofs, we are no longer trusting one oligarchy of whales controlling one shard, but instead trusting potentially different competing or upstart oligarchies who control the full nodes for each shard. Thus sharding is prone to shards forking off the main ledger and chaotic results. Imagine the block size scaling forking wars from 2017 but ongoing and amplified by a factor of 10 or 100 forks. Simpletons would presume that malfeasance can be revealed with fraud proofs, the miscreants punished, and the chain restored to pristine condition. But it’s not that simple. For example, fraud proofs may arrive too late and then there’s downstream and/or conflicting transactions involving innocent parties which depend on not reverting the fraud. The range of potential security and consensus divergence issues are too detailed and numerous to summarize here. My Medium comment elaborates on some divergence scenarios.

These technological problems really are not solvable in any of the designs currently contemplated. Even OmniLedger’s white paper admits it lacks formal vetting on game theory incentives. So sharding is a lie hyped to agape n00b speculators— which experts such as myself know really won’t work unless all the shards are controlled by a centralized cartel. The form of scaling that we’re more likely to get if something like my design doesn’t pan out, is the DPoS-variant in which we trust an oligarchy of whales to duplicate Facebook’s centralized infrastructure and pretend we have decentralization when all we really have is a distributed ledger under centralized cartel control. The antifragility vulnerabilities of centralized cartel control are:

  • a single-point of weakness that can be attacked, e.g. by the government regulators.

  • the cartel wants to maximize the extraction of rents from the system.

  • such maximization may turn against the best interest and desired features the users of the system want and need.

There are also different proposals such as OmniLedger which claims to reach about 100,000 TPS by introducing intricate consensus protocols.

OmniLedger is essentially the same design which I conceived of in early 2016 but which I discarded for a superior design I formulated for the CRED project I’m working on. The summary of my detailed analysis of OmniLedger explains the insecurity and other flaws lurking in the design of OmniLedger. The Byteball Flaws section in Part 2 of this blog elaborates on OmniLedger and DPoS.

In some other cases, a user account is partitioned by introducing sharding; as a result, users may end up having multiple accounts in order to make transactions with others.

Any secure variant of this design such as Elastico (c.f. also) will prevent cross-shard transactions, so it is essentially the same as having tokens on different blockchains.

Any attempt at cross-shard transactions (employing deterministic validation) such side-chain tokens will either be centralized, not be fungible in exchange value between side-chains due to not enforcing a total order, or not secure against losses due to double-spends if there’s one total order (i.e. one consensus) for all the shards!

For example, Raiblocks which Bitcoin Core developer Gregory Maxwell, @‍monsterer, and myself had debunked in 2015 as being a silly insecure and unsound design.

DASH, PIVX

The masternode scam, non-antifragility, and insecurity.

I won’t waste more ink on that “what’s the most egregious fraud/scam/shitcoin design can we get neophyte greater fools to think is the greatest thing since baloney on sliced bread?” Or IOW, “how much lipstick makes a pig[Dash soda vending machine] fly?”

For anyone with a functioning technological brainstem, it’s cringe worthy amazement that grown men can still be sold snake oil. And what’s more amazing is when they shamelessly defend and promote their unsubstantiated idealism analogous to over enthusiastic, fanatical, evangelizing born again Christians that just rediscovered God.

This blog isn’t about the “To Da Moon” FOMO pump-n-dump speculation value of shitcoins. Masternode deposits tend to lock up much of the token supply thus causing FOMO demand to outstrip token supply on the exchanges, leading to rising prices.

Aleph Ledger

I was sent a draft research paper for this proposed new consensus ledger system. The technobabble in the paper about particles and partial orders may effectively fool agape n00bs, but the key admission that the design must be entirely centralized is in §4. Total ordering of particles on pg. 11:

An important fact to note here is that we are working now on top of the protocol of validating transactions that was built in the previous section, which deals with any fork and double-spending attacks. The only concern of the following algorithm is the exact timings of transactions, not their validity. The algorithm does not require an exchange of any additional information among nodes, the total ordering is computed locally by each node by using only combinatorial properties of posets.

Then by definition different nodes can have different perspectives and thus different versions of the total ordering as is always the case in an asynchronous model which the paper admits in a prior section as follows:

In a non-synchronized network, several consensus participants can create a block at nearly the same time due latency and network topology. Subsets of the network receive and propagate their version of the “valid” block to peers which then leads to a fork […] On the other hand, since Aleph is leaderless, then no single consensus participant will be responsible for establishing the total order. Instead, a committee will agree upon the total ordering according to the rules of the protocol […] This allows particles to validate other particles which are high below them which allows us to validate transactions contained in each particle […] However, some applications require a total order on the particles; hence, we introduce the notion of timing particles that allows us to define a total order. The Aleph Ledger builds on the Aleph protocol by choosing a committee consisting of entrusted users responsible for maintaining constant information exchange, i.e. keeping the stream of particles flowing. Committee composition is updated based on all the users’ votes

So because of the inviolable nothing-at-stake issue that will plague all of (archived) these non-proof-of-work consensus systems, Aleph Ledger is centralized with user voting analogous to the non-antifragile centralization of DPoS consensus system that corrupts Steem, EOS, Lisk, and Bitshares. Readers may read my blog archive if they still do not understand that voting is centralization.

If elections, voting and democracy actually worked, then why are our Western nations so incredibly fucked with corruption, war mongering, debt-to-GDP ratios exceeding 100–300%, tax cuts for the poor, and imminent global economic collapse.

EOS, STEEM, Bitshares, Lisk

In addition to what I wrote about the DPoS consensus system in the last two paragraphs of the prior Aleph Ledger section, the voting paradigm in DPoS favors the adversaries and oligarchies. The inventor of DPOS Dan Larimer years ago purportedly admitted that he doesn’t believe in the possibility of decentralization.

The “free” transaction fee design of the DPoS consensus system that powers these projects such as EOS and STEEM, is actually not free, is a centralization feature, and is an incorrect design which I characterize as a bug.

Also I wrote on Medium:

The minimum latency for OmniLedger will be several seconds for acceptable error rates at the current network presumptions in the decentralized case.

I'm working on an improved design (which doesn't employ proof-of-work and isn't purely proof-of-stake) that obtains instantaneous sub-second latency (~0.05 seconds) for achieving the sort of interactivity we normally experience when interacting with a centralized database such as Facebook. Whereas, the DPoS-variant in EOS also barely obtains 0.5 second latency which requires forsaking antifragility and decentralization (and note that distributed isn’t the same as decentralized).

The Byteball Flaws section in Part 2 of this blog elaborates on OmniLedger and DPoS. All proof-of-stake systems are so inherently flawed (c.f. also) that they must exist only as oligarchy run systems that extract maximum value (rents) out of the system.

I participated in some debates about EOS at bitcointalk.org before I was perma-banned. For example, c.f. a reply to @chryspano who retaliated by censoring my Steemit blog “Consortium blockchains” (e.g. DPoS & Tendermint) can’t Internet scale. Examples of consortium blockchains also include EOS and STEEM. C.f. also a reply to @‍scaryvirus.

Nimiq

My Medium post.


Directed Acyclic Graphs (DAGs)

Click Here to continue reading Part 2 this blog.


The linked webpages and whitepapers cited in this blog have been archived at archive.is and/or archive.org.

Authors get paid when people like you upvote their post.
If you enjoyed what you read here, create your account today and start earning FREE STEEM!
Sort Order:  

I did not read it all yet, and it is probably above my level as usual.
I did notice that you imply that Byteball has some problems aside from its method of distribution which is the only thing about it that I know is bad.
I asked you about Byteball in the past, but you are busy.
Maybe now is a better opportunity.
What is wrong about Byteball?

Loading...
·

You got a 28.57% upvote from @luckyvotes courtesy of @stimialiti!

·

You got a 11.11% upvote from @sleeplesswhale courtesy of @stimialiti!

·

Byteball, Hashgraph, SPECTRE, Iota, and Dagcoin are now analyzed in Part 2 of this blog. I have provided an extensive tutorial on how Byteball works. I think you will learn a lot by reading that carefully. The flaws are of course listed there. Enjoy!

I did not read it all yet, and it is probably above my level as usual.

I have expounded significantly in Part 1 and added analysis of more projects. I have tried to write it as much as reasonably possible to be accessible to smart laymen, but I am limited by the length of blog and my own time limits in terms of how much verbiage I can add to increase the explanation. So I strove for a balance and that is about the best I can muster right now. In the future, if the CRED project I’m contributing to is launched, I hope we’ll endeavor to work with (even hire) talented writers to make the analysis more accessible to more people.

·

@youtake pulls you up ! This vote was sent to you by @stimialiti!

·

You got upvoted from @adriatik bot! Thank you to you for using our service. We really hope this will hope to promote your quality content!

·

This comment has received a 74.63 % upvote from @steemdiffuser thanks to: @stimialiti.

Bids above 0.1 SBD may get additional upvotes from our trail members.

Get Upvotes, Join Our Trail, or Delegate Some SP

So, whats the "answer"

·

See the Potential Improvement on the Horizon section for the DFINITY analysis in Part 3 of this blog series on extant consensus systems.

This summary on Medium is not nearly as detailed as mine and I think I would quibble with a few of the points in it, but it’s not too bad and will provide an alternative viewpoint.

hi i like coins, maybe i will learn a lot about decentralization, development and mining, verry cool article

My joke of “QuackChain” instead of QuarkChain is because they have so many PhDs yet the algorithmic design and whitepaper if not of academic quality, so I joke that those must be “quack doctors” of science.

Sorry I need to release some of the stress of compiling all this negative information on extant projects. I normally prefer to be focused on creating positive things, not destructively finding all the flaws in other projects (other than as a constructive bug finder/fixer).

@‍monsterer2 (formerly @‍monsterer) from bitcointalk.org sent me a message claiming that BitMex’s XBTUSD contract is a counter example to the claims and explanation in my blog as to why every peg is eventually doomed to market risk factors.

I’m sorry but that’s no counter example. It’s a centralized service that runs a feed and manages the margin deposits of longs and shorts. The market can move discontinuously faster than the system can liquidate the margins and thus the peg breaks. There’s not infinite margin deposited. In my blog I discussed StableCoins’ point that with sufficient reserves against market fluctuation (i.e. the margin deposits), a peg can have a longer lifespan. But there’s always long-tail distribution events that will be outside the normal reserve requirement assumptions.

Also there’s risks of failure and corruption due to it being centralized. And if decentralized then more arbitrage opportunities will be opened as market risk modes that can break the peg.

The generative essence stated in my blog on the instability of pegs is correct.


After writing the above, I read another comment from him:

This pegging system works like interest rates. There are no liquidity walls involved.

When the price is below the peg, longs pay shorts an interest rate, visa versa when the price is above the peg. Long/short positions are naturally encouraged to change their stance in favour of the peg, thus playing the role of inter-exchange arbitrage in the absence of that possibility.

The interest rate is proportional to the disparity of the current price from the desired price.

This introduces differential equations into the model (slow moving, higher inertial mass of interest rate payments with fast moving mass of the exchange rate), which can cause in some situations for long/shorts to do opposite of what the model expects them to do when volatility is very high because of tailing inertial oscillation in such a mathematical model.

And the participants still need to supply margin to cover the costs of what they must pay when their position is going against them.

There’s no mathematical way to remove market risk entirely from a peg. Such a deterministic system would have no uncertainty.

Proof-of-Stake Is Always Flawed

I hope readers found the links in my blog to my Medium posts where I explained the many flaws in the designs that are being planned and contemplated for proof-of-stake (code named Casper) and scaling for Ethereum.

And hope readers visited all the links in my above blog to details about the flaws in the delegated proof-of-stake (DPoS) which powers EOS, STEEM, and other blockchains.

Proof-of-Approval

Additionally I have explained the extant weakness in the proposed Proof-of-Approval variant proof-of-stake consensus system.

I wrote on Medium:

Hello Shunsai Takahashi.

As you know in your bitcointalk.org thread, @‍monsterer2, others, and I discussed some vulnerabilities in your Proof-of-Approval (PoA) consensus system. Specifically I pointed out that in plausible reality there’s not 100% finality because due to the requirement for 50+% of the stake to always be online that PoA analogous to all proof-of-stake systems really only function because they’re run by a 50+% oligarchy. Proof-of-stake does not function well without an oligarchy in control. Thus the 50+% attack is the norm, not the exception. Normally the oligarchy in control is benevolent in terms of double-spending and extracts their rents via other schemes. Some typical figures I’ve seen cited for stake participation are at most 30% of the stake. The implication of this is that the table in your blog which compares your PoA system to Nakamoto proof-of-work seems disingenuous in light of all the details as I explained. Although the end-game of proof-of-work is apparently also an oligarchy. Perhaps your table’s comparison to Ouroboros was at the time of writing this message correct to claim PoA’s advantage of one (1) block transaction confirmation finality compared to Ouroboros’ 100s of blocks because Ouroboros (in the non-delegated mode) also has the same vulnerability of requiring 50+% of the stake to always be online. I need to study Ouroboros more carefully in the future, which I may do for the upcoming Part 3 of my recent blog.

Paul explained that PoA also is vulnerable to the typical nothing-at-stake (NaS aka N@S) flaw which plagues all proof-of-stake systems. The NaS attack only applies to a 50+% attack. The problem is that although Nakamoto proof-of-work is also vulnerable to a 50+% attack, unlike NaS there’s an ongoing cost to attack proof-of-work. In theory it’s plausible to recover the costs of a rented hashrate attack by double-spending, but in practice no one thinks that is very realistic on Bitcoin with its tremendous systemic hashrate. And proof-of-work is permissionless yet proof-of-stake is not.

If we could argue that 50% of the stake is difficult for an attacker to obtain and if the slot and epoch slashing (of conflicting approvals) didn’t have the boundary ambiguity problem, then AFAICT the NaS issue would be somewhat mitigated. But unfortunately, I don’t think 50% of stake is difficult for an attacker to obtain and anyway the presumption that 100% of the stake will always be live is unrealistic.

·

Correction:

If we could argue that 50% of the stake is difficult for an attacker to obtain and if the slot and epoch slashing (of conflicting approvals) didn’t have the boundary ambiguity problem, […]

Question: is the PBFT algo you refer to the one described in this paper?

·

PBFT is Practical Byzantine Fault Tolerance (cited here for example) which “chooses a leader in round-robin fashion.” Note PBFT suffers from the leader being faulty or being DoS attacked, and it can be stalled indefinitely.

Sorry the very late reply. I have extensively edited the original blog and added Part 2 and Part 3. Also I wrote a comment on this page which links of to extensive discussion over at bitcointalk.org.

Those who claim that Bitcoin is almost entirely mined already thus not vulnerable to mining oligarchies, do not understand that miners can take back all that Bitcoin owned by others by dominating the chain.

Those who dispute my Lightning Networks analysis should read my rebuttal.

Those who dispute my points about Decentralizatio and Satoshi’s actual intent for Bitcoin should read my rebuttal here and here.

Those who doubt my blogs here and here about a potential massive miner theft of SegWit tainted Bitcoin hodlings, might want to read my rebuttals and my reply to a Steemian.

Another person wrote about the incompetence of the DPoS design.

A recent blog about 27 issues with Lightning Networks. Note I didn’t have time to vet this blog for accuracy.

You sad: "There’s no design published on the public Internet for a blockchain, DAG, or other variant of a distributed ledger which has all three qualities: scalable, decentralized, and secure".
Do we need it? Or we can use A (decentralized and secure) and B (scalable and secure) together?

·

I don’t see any way to partition the consensus in two parts as you suggest, which wouldn’t have vulnerabilities.

BTW, I noticed your claps for my Medium posts. Ty.

I gained a positive outlook on the impact of total centralization of Bitcoin.

I wrote in the Viable Trustless Cross-chain DEX Protocol section:

This protocol can’t be achieved with nLockTime.

Actually it can be accomplished with nLockTime.

·

Have you seen the recent buzz about Byteball's airdrop for STEEM users?
Will you refuse free money?

https://steemit.com/steem/@steemitblog/welcome-byteball-to-steem
https://steemit.com/steem/@tipu/reciving-byteball-airdrop-tutorial-for-newbies-sending-0-0006-gb-for-verification
https://steemit.com/steemit/@punqtured/official-byteball-airdrop-to-steemians
https://steemit.com/byteball/@acidyo/byteball-airdrop-to-steemians
https://steemit.com/byteball/@jrcornel/want-to-earn-some-free-byteball-i-ll-pay-your-registration-fee-for-free
https://steemit.com/byteball/@gavvet/byteball-looks-like-it-needs-a-little-more-tuning-for-prime-time

On paper, according to its fundamentals that I know about, it is good enough to justify being resteemed or posted on almost everyone's front pages, but look at what I got after I installed it:

" Uncaught exception: TypeError: Cannot read property 'find' of undefined"

And then it went off.
This came after I uninstalled it, because previously I got the same, and when it worked, it was not properly, because I could not get my own receive address, only my device address, and it did not seem the same to another user's screenshot.
After the uninstall and repeated installation, it requires my password, but quits on the exception that I mentioned before or when I try to type my password.
Yes, the version is 2.4.0.
So far the help that I got is as bad as the help that I got when I tried to install Bisque, to join BitShares and to commit a trade on Blocktrades.
I hope that this time it will not stay as bad, but my experience predicts that I will probably stay outside this time too.

Do you have a guess why Byteball,Bisque,Bitshares,Blocktrades fail to work on my PC and what should I do to make them, or at least Byteball work?

·
·

This comment has received a 60.00 % upvote from @steemdiffuser thanks to: @stimialiti.

Bids above 0.1 SBD may get additional upvotes from our trail members.

Get Upvotes, Join Our Trail, or Delegate Some SP

·
·

I have no time to look at this. I will ask someone else to look into it.

·
·

You got a 56.71% upvote from @luckyvotes courtesy of @stimialiti!

·
·

You got a 100.00% upvote from @sleeplesswhale courtesy of @stimialiti!