Adrian,
I haven’t seen a formal spec for 007. I am assuming Stateful Baking Accounts are being bundled as part of the proposal. And not your Programmable Staking proposal which enables in-protocol lending for bakers which would implode the fee market.
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?
For background the consensus key being spendable matters because it is the primary incentive driving bakers to secure their nodes. The key is a bounty on the node. Having a non-spendable consensus key allows sloppy security setups -like leaving the key on disk rather than HSM- which is detrimental to network security over the long term. Especially with regards to state actors, and rival chains.
Another issue someone brilliant pointed out, if the consensus key is non-spendable you can hand over your consensus key to someone else to bake on your behalf. You are only risking a slashing event, and can probably have a pre-signed key rotation scripted to auto-broadcast, if slashing occurs. We already have a few bakers who sign blocks blindly with remote lite baking, and this new and improved version would be far less friction. A centralization nightmare.
Adrian your initial spec on stateful baking accounts had the consensus key as non-spendable. https://web.archive.org/web/20200509165243/https://medium.com/metastatedev/stateful-baking-accounts-d483a63a173c
After posting the spec on Agora. Issues where raised around the consensus key being non-spendable. Your blog was then silently updated to make the key spendable but you made no mention of it on the Stateful accounts Agora thread, even though you were liking comment supporting a non-spendable consensus key. This comes off as dishonest.
In the spec blog post you added:
“Note that one of the challenges of Stateful Baking Accounts is remaining as backwards compatible as possible in order to make the upgrade path a smooth experience. Thus, the consensus key will remain capable of authenticating spending as well as governance transactions. This ensures that bakers do not have to change their existing infrastructure.”
Unfortunately the consensus key is only spendable for backwards compatibility, and the intent is to still make it a non-spendable key.
So the question remains is the consensus key always spendable in this update, independent of the operator account? If not your proposal is fatal to the chain from a security prospective.
-Justin
