Quote from: iamnotback on December 09, 2016, 09:13:45 PM

Quote from: iamnotback on December 09, 2016, 05:06:57 PM

Subject: Re: Casper = Rchain

Quote from: cryptohunter on December 09, 2016, 10:50:44 AM

I know the above is casper and not exactly Rchain.

Afaics, the betting aspect is the same between both. The difference is Rchain makes bets on partial orders of blocks, instead of entire blocks. But that doesn't matter w.r.t. to the issue of betting incentives Dan is referring to. Afaics, Dan's logic applies equivalently to Rchain.

See page 4 "Consensus Mechanism":

https://docs.google.com/document/d/1xmRvAjJEQ72-sR9luS34TG0BOpPn_6ztZjYBFCByKxo/edit#

You are welcome to quote me or otherwise post this correction. You should not erroneously insinuate that Rchain is significantly different from Casper w.r.t. to the ramifications of using betting for consensus. It strongly appears that it is an equivalent issue for Rchain. Rchain is attempting to make the consensus more granular and composable by betting on portions of blocks instead of only whole blocks, but that is an orthogonal issue to the effects of employing betting for incentivizing consensus.

The bottom line is that the game theory of betting is the everyone has an incentive to collude with the major stakeholders. It is another power vacuum failure mode same as proof-of-work. My whitepaper is all about solving this issue. Thus I remain convinced that I have the only consensus ordering design that solves this issue. Dan is also incorrect to presume/insinuate DPoS solves the issue of a power vacuum disequilibria of stake control. So DPoS has an analogous failure mode as Casper/Rchain/PoW. All those designs suck.

Here is the final nail in the coffin for Casper/Rchain:

https://www.reddit.com/r/ethereum/comments/3flj4x/if_ethereum_adopts_casper_proof_of_stake_it_is/ctqhekg/

And for sure Casper and Rchain are virtually the same thing, as even Vitalik explains that Casper if voting on blocks as partial orders not one monolithic chain:

Quote from: https://blog.ethereum.org/2015/12/28/understanding-serenity-part-2-casper/

One counterintuitive consequence of this mechanism is the fact that a block can remain unconfirmed even when blocks after that block are completely finalized. This may seem like a large hit in efficiency, as if there is one block whose status is flip-flopping with ten blocks on top of it then each flip would entail recalculating state transitions for an entire ten blocks, but note that in a by-chain model the exact same thing can happen between chains as well, and the by-block version actually provides users with more information: if their transaction was confirmed and finalized in block 20101, and they know that regardless of the contents of block 20100 that transaction will have a certain result, then the result that they care about is finalized even though parts of the history before the result are not. By-chain consensus algorithms can never provide this property.