{"action":"created","issue":{"url":"https://api.github.com/repos/cosmos/cosmos/issues/43","repository_url":"https://api.github.com/repos/cosmos/cosmos","labels_url":"https://api.github.com/repos/cosmos/cosmos/issues/43/labels{/name}","comments_url":"https://api.github.com/repos/cosmos/cosmos/issues/43/comments","events_url":"https://api.github.com/repos/cosmos/cosmos/issues/43/events","html_url":"https://github.com/cosmos/cosmos/issues/43","id":191652549,"number":43,"title":"[Whitepaper] Incorrect claims around BitShares","user":{"login":"xeroc","id":117800,"avatar_url":"https://avatars.githubusercontent.com/u/117800?v=3","gravatar_id":"","url":"https://api.github.com/users/xeroc","html_url":"https://github.com/xeroc","followers_url":"https://api.github.com/users/xeroc/followers","following_url":"https://api.github.com/users/xeroc/following{/other_user}","gists_url":"https://api.github.com/users/xeroc/gists{/gist_id}","starred_url":"https://api.github.com/users/xeroc/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/xeroc/subscriptions","organizations_url":"https://api.github.com/users/xeroc/orgs","repos_url":"https://api.github.com/users/xeroc/repos","events_url":"https://api.github.com/users/xeroc/events{/privacy}","received_events_url":"https://api.github.com/users/xeroc/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":4,"created_at":"2016-11-25T08:57:11Z","updated_at":"2016-11-27T04:44:02Z","closed_at":null,"body":"Hello there,\r\nI recently went through the cosmos whitepaper and am quite impressed by your work. Adding collateral to block producers is a great idea to keep them honest. This is certainly an improvement over DPOS as used in BitShares. However, I would like to request correction of the nothing-at-stake problem you claim exists in BitShares, because it does not. [Here is why](https://bitsharestalk.org/index.php?topic=6584.0):\r\n\r\n> The Nothing At Stake problem assumes certain properties of POS based upon the Peercoin design. \r\n>\r\n> It is impossible for DPOS to produce an alternative longer chain without collusion of 51% of the delegates.  With 51% collusion you are back to the 51% attack that all systems are subject to.\r\n>\r\n> In this case the delegates also have something at stake:  their job.   \r\n>\r\n> So how has DPOS changed the game?\r\n>\r\n> 1) \"Miners\" are now generally public, known individuals rather than anonymous individuals.\r\n> 2) Secret attacks are no longer possible\r\n> 3) Alternative chains are not possible\r\n> 4) In the time it takes Bitcoin to generate 1 confirmation (10 mins on average) dozens of witnesses would have confirmed a block in BitShares/DPOS already\r\n\r\n[Some more details](http://bytemaster.github.io/article/2015/01/08/Nothing-at-Stake-Nothing-to-Fear/)\r\n\r\nThus, the claims in the whitepaper:\r\n\r\n>  By using and improving upon proven BFT algorithms developed at MIT in 1988 [20], the Tendermint team was the first to conceptually demonstrate a proof-of-stake cryptocurrency that addresses the nothing-at-stake problem suffered by first-generation proof-of-stake cryptocurrencies such as NXT and BitShares.\r\n\r\nand\r\n\r\n> Though BitShares achieves high performance (100k tx/s, 1s latency) in ideal conditions, it is subject to double spend attacks by malicious witnesses which fork the blockchain without suffering an explicit economic punishment -- it suffers from the \"nothing-at-stake\" problem.\r\n\r\n... are inaccurate. Besides that, you correctly noticed that forks are restricted to a certain maximum length by means of TaPOS (Transactions as proof of stake) by referring to the blockhash in each transactions.\r\n\r\nFurthermore, there has been made a rather easy change that affects the whole discussion immensely and should maybe added to cosmo/tendermint aswell and that is *irreversible block*. Basically, once 2/3 (66%) -- or 75% if you want -- of the block producers have signed a block (by adding a block ontop of a particular fork) then the block is called **irreversible**. The software cannot revert/reorg the blockchain beyond this point. This makes an irreversible block become a **checkpoint** (in terms of bitcoin). If you compare pow with dpos, then you see that while bitcoin's pow generates 1 confirmation after 10 minutes (on avg.) which makes a reorg **unlikely** after 6 confirmations (60minutes), BitShares' DPOS makes a reorg **impossible** after ~60 seconds (30 witnesses, 2/3 makes it 20 witnesses, 3 seconds per block). A \"fork\" can thus be at most 60 seconds old. A double spend is only possible within these 60 seconds then. We have a similar recommendation to the \"wait for 6 confirmations\" on bitcoin which goes like this: \"Use the irreversible head block to be on the safe side\".\r\n\r\n(Also, it is the **committee** that can change blockchain parameters, not the delegates.)\r\n\r\nWhile I understand that you paper wants to highlight the improvements of cosmos/tendermint over existing blockchain technologies, I would kindly request to consider correcting the whitepaper for the sake of correctness.\r\n\r\nKind regards and thanks for reading my issue\r\n -- Fabian"},"comment":{"url":"https://api.github.com/repos/cosmos/cosmos/issues/comments/263102151","html_url":"https://github.com/cosmos/cosmos/issues/43#issuecomment-263102151","issue_url":"https://api.github.com/repos/cosmos/cosmos/issues/43","id":263102151,"user":{"login":"jaekwon","id":53785,"avatar_url":"https://avatars.githubusercontent.com/u/53785?v=3","gravatar_id":"","url":"https://api.github.com/users/jaekwon","html_url":"https://github.com/jaekwon","followers_url":"https://api.github.com/users/jaekwon/followers","following_url":"https://api.github.com/users/jaekwon/following{/other_user}","gists_url":"https://api.github.com/users/jaekwon/gists{/gist_id}","starred_url":"https://api.github.com/users/jaekwon/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jaekwon/subscriptions","organizations_url":"https://api.github.com/users/jaekwon/orgs","repos_url":"https://api.github.com/users/jaekwon/repos","events_url":"https://api.github.com/users/jaekwon/events{/privacy}","received_events_url":"https://api.github.com/users/jaekwon/received_events","type":"User","site_admin":false},"created_at":"2016-11-27T04:44:02Z","updated_at":"2016-11-27T04:44:02Z","body":"When the Tendermint whitepaper was out, in early 2014 it described how to incorporate a classical BFT algo into a blockchain to ensure that validators can come to agreement about the next block, safely with tolerance for up to 1/3 of Byzantine nodes, prior to signing commit votes that finalized the block.  To become a validator, nodes have to post significant collateral, and there would be an unbonding period prior to the tokens being transferrable.  The solution split the problem into short range and long range problems and provided a solution for the first, and a way to circumvent the second.\r\n\r\nWhile Tendermint was published, Bitshares DPOS had no BFT algo nor unbonding period.  The only thing at stake, as you said, was the job of the 101 chosen delegates, which you could get by paying a small application fee, and getting voted by the token holders.  The problem with such a scheme is that general users of a platform don't have much information to go by in voting for or against candidates, and in fact I recall that quite a few of the chosen delegates were chosen by virtue of advertising some incentive for users to vote for them.  Users didn't have much at stake either, regardless of who they vote for.  And as I just mentioned, the application fee to become a candidate was low, only to prevent spam.  So, strictly speaking, nothing much was at stake.\r\n\r\nThe second paragraph you quoted was referring to the graphene system.  You mentioned something about irreversible blocks, I'd like to see a reference to a spec for that, if it applies to graphene.\r\n\r\nEvery block in Tendermint is final.  We can get finality on the order of 1 second, depending on the number of validators.  Each validator can have huge collateral behind it, and it does not get punished for as long as it follows the rules of the protocol.  You can't get these properties without building around a solid BFT algorithm that can provide you with absolute fork accountability.\r\n\r\nIf you want to protest, please first post a link to a proof of safety and liveness, and the minimal conditions in which a fork or halt would happen.  And finally, a proof of fork accountability, so proof that you can determine who are responsible for a fork or halt condition.  "}}
{"actor":{"display_login":"jaekwon"}}