Are there going to be different choices proposed for 007 (separated out) or is it going to be one big amendment / take it or leave it scenario?
First, of course, the community has a say! Development teams do monitor community platforms like agora, reddit, riot or slack. We also keep in touch with smart contract developers and language teams, as well as bakers and other users. The channels used to coordinate the proposals are also open and transparent, such as Gitlab. However, the final cut on what gets in the proposal that we build and endorse (as opposed to what gets rejected or delayed) is mostly a matter of engineering and code quality. And then of course, the last word goes to the voters, which has an impact on the choices we make about the features on which we concentrate our efforts.
The current plan is to have 3 different proposals: one with baking accounts only, one with sapling only and one with both. All of them will include the same smaller changes.
The first year the foundation was by far the largest actor in the network, so the fact that there are new services adopting Tezos is actually a sign that the network is more decentralized now. With more adoption will come more diversity.
Will the consensus key retain the right to spend in 007, independent of the operator account?
My question on your Stateful Baking Account proposal is will the consensus key always be spendable, in and of itself, independent of the operator account? […] So the question remains is the consensus key always spendable in this update, independent of the operator account?
- As described in the blog post the implementation of stateful baking accounts maintains the consensus key as spendable in order to be as backwards compatible as possible with the existing tooling, such as payout tooling.
If not your proposal is fatal to the chain from a security prospective.
- The proposal for stateful baking accounts contains a spendable consensus key as described in the above bullet point.
Does Nomadic have someone watching Riot?
I know Adrian is in there but he doesn’t count. Many of us have been bringing up security concerns with giving bakers smart contracts, and breaking out key roles, since Adrian first announced his ideas over a year ago.
The issue is that nowhere does Cryptum Labs now Metastate consider down stream negative effects.
Their blogs are often hyped and inaccurate at critical points. Nor do they take time engage in conversation to defend their ideas. From example I wrote a micro-economic critique of Adrian’s programmable staking proposal over a year ago, after spending a week trying to talk to Awa and him. No concerns were ever addressed. https://medium.com/@MindsFiction/cryptium-labs-swings-a-death-blow-at-tezos-964e4123888b
This leads to questions like what does Nomadic think about Adrian’s wild ideas? If any answer is given its usually Awa reassuring the community that they are working with Nomadic. Which isn’t an answer but it does allow her to use your reputation.
Can Nomadic have a developer in Riot? At the moment Adrian is viewed as Core development which is a problem for those of us who value the chains security.
P.S. I’m looking forward to Sapling. Its been a long time coming. Well done.
But they said they would “pass” every single proposals.
Before the giants Coinbase, Kraken and others were there, the voting power of all “small” bakers had much more power. I feel like now, at the current state, the giant bakers are too powerful and I believe it is a threat for Tezos and its decentralised governance.
You did not answer the question. Nor could you because you don’t understand it. This is why I asked Adrian.
Yet your response is just a boilerplate of the flawed blog post. For example the “consensus key will remain capable of authenticating spending” but its just 1 of N in the operator accounts multisig. One could make it 2 of 2 multisig and the consensus key is no longer spendable in and of itself.
Which is a security fail the reasons I already highlighted.
I was thinking specifically about protocol releases. Would be great to have all the various efforts documented in one centralized spot - creates more visibility on what to expect in the coming months/years.
Answer to Justin please.
This is a question to Cryptium Labs/ Metastate :
How many times are you going to propose “bond pooling” with different names? This proposal looks like Burebrot 3.0 and you guys are still insisting about an idea vastly refused by the community during years.
Also, please specify if you are receiving grants for “bond poooling” / “programmable staking” developing.
Finally, as granted dev team, I think you should be ultra-mega-clear about the specs of your future proposals. Please no more several blogs entries for describing a unique proposal prototype.
Hey @gholadr, this is something we could try to present/organize on Agora if you’re interested. What would you specifically like to see?
Thanks for your questions.
See our reply below, #1 and #2.
Yet your response is just a boilerplate of the flawed blog post. For example the “consensus key will remain capable of authenticating spending” but its just 1 of N in the operator accounts multisig. One could make it 2 of 2 multisig and the consensus key is no longer spendable in and of itself.– Justin / seinca / MindsFiction
As explained in detail in the blogpost , that you only partially quoted, the consensus key is able to authenticate spending, as well as governance transactions independently of the operator multisig. To quote directly from the blogpost:
Thus, the consensus key will remain capable of authenticating spending as well as governance transactions.
This sentence can be found in the last paragraph of the section “The design of stateful baking accounts”.
Which is a security fail the reasons I already highlighted. – Justin / seinca / MindsFiction
The current implementation of stateful baking accounts maintains the consensus key as spendable and able to authenticate governance transactions. Due to this fact, your concern is not relevant towards the discussion around the possible
007 proposals, and hence beyond the scope of this AMA.
However, for the sake of clarity it is important to point out that your security analysis of LPoS, which is a specific instantiation of PoS, is flawed and that the security of LPoS does not derive from the fact that the consensus key is spendable. A spendable consensus key is a nice cherry on-top for LPoS, however LPoS is secure due to having slashable security deposits (from committing consensus faults, such as double-signing consensus messages). Some suggested reading to gain a better understanding of PoS security can be found in these references:
- Vitalik Buterin - On Stake : https://blog.ethereum.org/2014/07/05/stake/
- Vitalik Buterin - Weak Subjectivity: https://blog.ethereum.org/2014/11/25/proof-stake-learned-love-weak-subjectivity/
- Enhancing Baking Accounts: https://medium.com/metastatedev/meanwhile-at-cryptium-labs-2-part-1-enhancing-baking-accounts-4c9ad61d4ef5
- What is at Stake in the Tezos Protocol?: https://medium.com/cryptium/half-baked-is-always-better-than-double-baked-what-is-at-stake-in-the-tezos-protocol-6619ce4a5f87
Again, even if this is out of scope, for the sake of clarity, let’s perform a thought experiment:
If the security of PoS in general, and LPoS specifically, was only derived from the fact that the consensus key is spendable, then it could be trivially broken today using trusted execution environments, such as the Intel SGX. An Intel SGX could allow you to generate a consensus key, which can sign blocks and endorsements but requires a multi-signature input in order to sign transfers. Using this system, one can simulate a non-spendable consensus key today. Due to this, if your analysis was correct, it would not only imply that almost every PoS chain (Cosmos, Polkadot, NEAR, and eventually ETH2.0) is insecure, but also Tezos.
Nevertheless, LPoS and Tezos are fundamentally secure today, even in a world with trusted execution environments, because the security of LPoS and PoS is derived from slashable stake and not from whether a consensus key is spendable or not.
Finally, it is important to stress again that the implementation of stateful baking accounts for
007 maintains the consensus key’s ability to authenticate spending as well as governance transactions.
Thank you, Justin, for participating!
sure why not @governancy! I think we should identify core development players, ie dev teams working on the protocol itself and try to present a clear representation of who is doing what, with expected/anticipated delivery dates.
then, find a home where to present this information on a regular basis, maybe monthly or weekly if there is enough momentum to warrant it. I’m guessing this forum would be the preferred way to share the ‘roadmap’ but I’m not married to it so open to suggestions.
Yes, I like it! I always thought about a “timeline” where the teams can integrate milestones by themselves and make transparent when a specific feature/product will be released!
Lets recap. You posted your Stateful Baking Accounts proposal on May 6th. In which the consensus key was non-spendable. This matches your gitlab merg request for Stateful Baking Accounts which has the consensus key as non-spendable.
Both your initial code and your blog spec had the consensus key as non-spendable.
At this point many of us raised concerns about having a non-spendable consensus key. Documented on this agora thread. Then you silently updated your blog to make the key spendable. This was dishonest. You should have told the community directly on the Agora thread which you were engaging on. Nothing wrong with changing ones mind.
However your blog states that you made key spendable for “backwards compatibility”.
Which likely meant you were going to have the consensus key be 1 of N on the multisig contract- easy to implement. The problem with this is if you set the multisig to 2 of 2 you get the same security issues as having a non-spendable key.
This is why I asked specifically “consensus key always be spendable, in and of itself, independent of the operator account?” while fully quoting your blog post in the initial question. So we could get the key changed to always spendable independent of the multisig. Initially you didn’t understand the question, so I had to ask again with an example, and quoted the part that mattered. Of course you lied about the quoting.
At this point the community has burned several weeks getting the proposal tweaked to be more secure, and therefore passable. People have been ignored, gaslighted or given non-answers while on the backside those who are connected see our comments and get Andrian to fix his proposal.
This is a critical point, notice none of the big bakers are here in the AMA asking questions. Why are they absent at this critical juncture? The answer is Awa and Adrian deal with them in private chats and private conversations. This is the Tezos cartel.
This informal cartel is also why Metastate gaslights people and pretends they already made the changes even though the public record shows otherwise. It’s to maintain an illusion of authority. They don’t need the plebs they already have built the support in private channels.
Even now, Metastate has no clue about security nor the implications of their changes. They spam non related links while still arguing for a non-spendable consensus key. This strawman argument doesn’t even pass a smell test.
I’ve consistently stated that there are many incentives that secure the network. One of which is having the consensus key spendable because it is a bounty on the node. Node operators secure the node to defend against hackers making the Tezos ledger more secure in the process. Second slashing exists to punish bad baker behavior, not for node security. These are separate incentives that work together to help secure the network. Yet Metastate clearly shows they do not get it by arguing for only slashing.
The other obvious issue that Metastate ignores is the centralizing aspect of non-spendable consensus keys. Which is perhaps the most critical.
Digging further into Metastates merg request you can also see Adrian championing an implicit feature of having one physical baker for multiple operator accounts. Again this is a security fail as it allows any physical baker to grow without capital constrain, also incentivizes fewer nodes to run.
Up until this point I’ve been trying to get their proposal functional by pointing out issues but given Metastate is not ethical, I cant trust their code. Given they don’t understand basic security, again, I can’t trust their code. Even if we keep getting them to fix all obvious issues, I doubt Adrian has thought of all corner cases.
This proposal is high risk and low reward even though bakers need the ability to change their key.
Both your initial code and your blog spec had the consensus key as non-spendable.
At this point many of us raised concerns about having a non-spendable consensus key. Documented on this agora thread. Then you silently updated your blog to make the key spendable. This was dishonest.
It is absolutely not the job of developers to hide their features when there’s a disagreement with the community. You are being paid, start acting like it.