Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add document about how Unbonding works and why its crucial for PoS systems #1678

Closed
jackzampolin opened this issue Jul 13, 2018 · 11 comments
Closed
Assignees
Labels
C:x/slashing C:x/staking spec T:Docs Changes and features related to documentation.

Comments

@jackzampolin
Copy link
Member

This is not described anywhere and per @cwgoes is important to understanding the system.

@cwgoes
Copy link
Contributor

cwgoes commented Jul 13, 2018

Specifically, we should discuss the security/economic model of the unbonding period & slashing (as opposed to the implementation, which is documented in the SDK spec).

@cwgoes cwgoes added T:Docs Changes and features related to documentation. spec C:x/staking C:x/slashing labels Jul 13, 2018
@kidinamoto01
Copy link
Contributor

should we put unbonding period in genesis?

@jackzampolin
Copy link
Member Author

jackzampolin commented Jul 24, 2018

@kidinamoto01 That is a great question for the fourm: https://forum.cosmos.network

@ValarDragon
Copy link
Contributor

@kidinamoto01 I believe the plan is to include all parameters that can be set by governance with Parameter Change Proposals in genesis. That will include the unbonding period for example.

@cwgoes cwgoes self-assigned this Jul 25, 2018
@cwgoes
Copy link
Contributor

cwgoes commented Aug 22, 2018

This should include #1440 (comment).

@cwgoes
Copy link
Contributor

cwgoes commented Nov 26, 2018

Addressing this in the upcoming staking/slashing spec/code reconciliation.

@rigelrozanski
Copy link
Contributor

I think this type of documentation doesn't necessarily belong in the spec per say, more in explanatory documentation sections

@cwgoes
Copy link
Contributor

cwgoes commented Nov 27, 2018

Hmm maybe, I guess it's a question of terminology, I think we should have a "design spec" and a "implementation spec" (mostly at the moment we just have the latter).

@cwgoes
Copy link
Contributor

cwgoes commented Mar 12, 2019

I am still very interested in doing this and I think we should formalize Cosmos BPoS into a paper.

Let's plan to discuss further post-launch.

@rigelrozanski
Copy link
Contributor

rigelrozanski commented Mar 12, 2019

@cwgoes - it's not my preference, but I could see the appeal to having much of our documentation organized in papers... maybe an explicit papers folder could be good. The problem I see with papers is the inability for updating the original work... I see standard documentation as dynamic where as papers static (you can publish addendums of course but it's not the same). Additionally, papers are usually "one-offs" so much of the introduction material for instance would be duplicate across papers, which is annoying for reference documentation, but great for publication purposes

I think that papers should exist in compliment to having a nice clean markdown breakdown of everything. But I don't see the problem of having both!

CC @ValarDragon

@cwgoes
Copy link
Contributor

cwgoes commented May 13, 2019

Closing in favor of cosmos/ibc#89, this seems more suited for that repo now.

@cwgoes cwgoes closed this as completed May 13, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C:x/slashing C:x/staking spec T:Docs Changes and features related to documentation.
Projects
None yet
Development

No branches or pull requests

5 participants