Spendable consensus keys?

As part of proposal 007 we will be able to rotate the baking key, which is great. There will be a new key - consensus key - whose job is primarily to make baking and endorsement operations.

Based on recent AMA I understand the consensus key will be spendable, so it won’t be different from the baking key as of today - except the ability to rotate it. But moving forward, should the consensus key become non-spendable ? Meaning, it can only sign baking and endorsements, but not transfers ?

The case has been made that it should remain spendable. The argument for it, as far as I understand it, is two-fold:

  1. having the consensus key spendable makes it a “bounty”, meaning, it’s a high-value target for attack, in which the attacker walks away with valuable tokens. So it encourages people to secure their setup as they do today. A non-spendable consensus key is not a target for an attacker motivated by financial gain, but it is still a target for someone wanting to cause harm to the network. It would lead bakers to sloppiness.

  2. a non-spendable consensus key can be transferred to a third-party, giving the possibility for bakers to outsource their operations. This represents a centralization risk, as we may see intermediary entities emerge which have control over a large stake of the network.

I would like to present a contrarian view:

Against argument 1: a spendable consensus key should be handled with extreme care, so it may shy people away from setting up an independent baking operation due to “fear of messing up”. Also, in computer security, making the argument that the attack surface should NOT be reduced in order not to induce sloppiness is counter productive, not unlike the “security by obscurity” argument.

Against argument 2: the vast majority of tokens are in custody today (look at the top 3 bakers). Some bakers outsourcing their operation to intermediaries by shipping them a non-spendable consensus key on a regular basis may encourage people to take custody of their assets.
The distribution of stake in a world where a non-spendable consensus key exists will be between custodians, baking intermediaries, and independent bakers, which is more decentralized than today.

6 Likes

On point 1 I would also like to add that a vast majority of the funds on consensus keys today are non-spendable, since they are locked in security deposits. An example from the Everstake baker is that the security only about 13% (249,236/1,904,348) of the funds are actually spendable and the rest are locked up. However these security deposits are still at risk, since if an attacker takes over a baker, the attacker can claim 50% of the deposits as a reward and the other 50% will be burnt. So right now Everstake has about 1,655,112 XTZ (or about 4,468,802.4 USD) worth of incentives to secure their consensus key regardless of whether it is spendable or not, because if their key is compromised they will lose the full amount.

On point 2 I would like to add that only incredibly gullible bakers would outsource this, because whoever controls the consensus key has the ability to fully slash all funds in the bakery (as illustrated in the above paragraph). I would further argue that people that outsource this, should get punished because they clearly don’t understand what makes PoS secure.

4 Likes

Slashing is punishment for bad behavior which is not equivalent to signing with a spendable consensus key. This isn’t about best practices in computer security otherwise we would be in agreement. The difference between signing a block and signing a block with all of your money at risk is trust. Trust created through distributed consensus. Trust ensures data written to the ledger has the highest level of integrity which is how value is created “digital money”. You should never let anyone print money unless they have the highest level of trust. You can remove it but then it would only be a blockchain.

The individual who will shy away from baking is controlled by the same invisible force that stops a large baker from endlessly growing. While you stated removing the ability to spend would further distribute the network larger bakers with lower risk would grow centralizing it. The risk of binding them together is a self-regulating mechanism that is cheap, scalable, and effective. Derisking systems without offset has consequences that can not be managed using punishments. Just understand that it becomes controversial when a suggested change fails to acknowledge this relationship. If a change this critical can not be clearly articulated including how it works and the underlying effects then we are taking someone’s word. Don’t trust, verify.

If we were serious about growing the network the roll size should have been lowered already. We might agree to disagree but I have these questions:

  1. Do you believe a spendable and unspendable key are equivalent?
  2. Do you believe this is only a computer science problem?
  3. Are you a large baker, intermediary, or exchange?
  4. If it is not money what vision are the core developers building towards?

This is exactly the point I was trying to make in the other thread.

+1

The difference between signing a block and signing a block with all of your money at risk is trust. Trust created through distributed consensus.

This would be true if signing a block did not put your funds at risk, and it does. Why would anyone trust their non-spendable baking keys to a third party that could double-bake with them? Furthermore, the kind of trust that would be needed for anyone to share keys with others is not the same type as “Trust created through distributed consensus.” You’re mixing governance with individual trust over wallet keys.

The individual who will shy away from baking is controlled by the same invisible force that stops a large baker from endlessly growing

We have helped some of our delegates to bake on their own after we openly offered the help, do you think they were holding back because they didn’t trust their setup and were anxious about their keys getting stolen? Far from the truth, they just aren’t tech-savvy and dealing with Linux and Kiln and command-line interfaces scare them, is a lot easier to delegate. So is on us stakeholders that they do not have yet one easy way to put up a safe node, we just need to abstract the system enough so that is safe and easy to use.

If we were serious about growing the network the roll size should have been lowered already

Smaller stakeholders will bake when is convenient, right now is not even cost-efficient to bake with one roll at 8k:

Current rolls baking: 82468

Actual costs of running a very very basic node at actual prices:
~50 xtz in hardware, one shot
~10 xtz / month in upkeep (constant connection, human time, electricity…)
so, first year costs ~ 150xtz to round it down.

1 roll annual income (1 roll = 8k xtz) =~ 510xtz with current inflation

a 10% fee baker will take 51xtz of your 510xtz income, against 3x the number + the work to do it on your own. Why would you open a baker with a roll worth even less than the current value? Makes no economic sense. You can do it for the glory and honor but we know the world does not work like that.

Do you believe a spendable and unspendable key are equivalent?

No, I believe non-spendable keys will let us sleep better at night, having a spendable key at the baker anyone “knows” where it is and can find a way, also physically, to attack you.

Do you believe this is only a computer science problem?

The answer above clearly explains why this is not only a computer science problem.

Are you a large baker, intermediary, or exchange?

You’re giving for granted that lots of smaller stakeholders will flock to services hosted by big third parties, which just isn’t the case, au contraire, smaller stakeholders are leaving their stake on exchanges because they work as custodians of the spendable key and believe they do not need to worry about losing funds because they feel “safe” (or simply lazy, which can’t be fought by lowring the roll size)

If it is not money what vision are the core developers building towards?

Can’t answer this for devs, but please would you elaborate on what are you trying to infer?

1 Like

This would be true if signing a block did not put your funds at risk, and it does. Why would anyone trust their non-spendable baking keys to a third party that could double-bake with them? Furthermore, the kind of trust that would be needed for anyone to share keys with others is not the same type as “Trust created through distributed consensus.” You’re mixing governance with individual trust over wallet keys.

I do not believe bakers would trust their non-spendable baking keys to a third-party and didn’t think my statement implied it. Yes, slashing is enough where I don’t see it as a concern with outsourcing keys. If there are any changes made to this relationship between consensus and spending this is one view or close to that of some people opposing it. It’s not a black and white situation. The second half I’ll hold off on responding to because it depends on that being my view.

We have helped some of our delegates to bake on their own after we openly offered the help, do you think they were holding back because they didn’t trust their setup and were anxious about their keys getting stolen? Far from the truth, they just aren’t tech-savvy, and dealing with Linux and Kiln and command-line interfaces scare them, is a lot easier to delegate. So is on us stakeholders that they do not have yet one easy way to put up a safe node, we just need to abstract the system enough so that is safe and easy to use.

Read hodl.farm’s original post where he mentions that fear of losing their funds held people back. Yes, I helped bootstrap numerous nodes and get to talk to many people when they first learn about Tezos. I agree that the number one barrier to entry is the learning curve on Linux and Docker. If you recall a knowledgable person in Riot mentioned around network launch that these barriers would also prevent insecure setups. I think most did ok in beta but over time we do need more distribution on the network. There are a few efforts towards improving that experience without sacrificing security. A discussion on abstracting the system would be great we should start one.

To state explicitly:

  1. Technical barriers (Always first)
  2. Funds at risk

You can do it for the glory and honor but we know the world does not work like that.

Yes, if small decisions that favor larger holders continue it will erode the foundation due to variance, difficulty, and poor experience. There are likely many with the necessary skills to bake but don’t because of cost or opportunity cost drives them away. You also won’t get feedback from them because they already know the barrier is too high for them, might move on quietly, or passively delegate.

Small and medium bakers are the independent voters that let us sleep at night. People discuss their desire to add a roll or two all the time. So no I don’t think they should delegate to entitled whales. Perhaps lowering the roll size should be seriously discussed.

No, I believe non-spendable keys will let us sleep better at night, having a spendable key at the baker anyone “knows” where it is and can find a way, also physically, to attack you.

You are not masking your setup with private nodes and a VPN? Can you explain how your location is compromised by signing with a spendable key?

The answer above clearly explains why this is not only a computer science problem.

We agree then it is more complicated than a surface level issue.

You’re giving for granted that lots of smaller stakeholders will flock to services hosted by big third parties, which just isn’t the case, au contraire, smaller stakeholders are leaving their stake on exchanges because they work as custodians of the spendable key and believe they do not need to worry about losing funds because they feel “safe” (or simply lazy, which can’t be fought by lowring the roll size)

No, I’m not for the third or fourth time this is not my position on outsourcing because it is offset by slashing. However yes large bakers, intermediaries, and exchanges/custodians appear to favor these changes. It would lower their risk and some of these changes will happen but is this the right implementation? This would allow bakers to increase bonds worrying less about overexposure. There are some other questions that might change my opinion but this is why open discussion leads to consensus. When you leave people out or until the last minute they become concerned. I only worry about a hack with custodians but less on voting for the time being.

Can’t answer this for devs, but please would you elaborate on what are you trying to infer?

It means ¯_(ツ)_/¯ what are you working towards? Tezos is built to change over time. There are decisions that affect security and distribution how do you prioritize? How are these decisions evaluated? Maybe explaining their own vision, different core teams, it would make more sense to take this approach.

1 Like

I totally agree with you, I’m sorry I didn’t say it on the AMA thread.

What Justing did not mention is that the consensus key is as sensitive as the current “spending key” because of risk due to slashing. I know it’s not the same as seeing your funds being stolen but it’s a tragedy for a baker and so I’m in favor of non-spendable consensus keys.

For a smoother upgrade from 006 to 007 it’s better to keep it spendable but I would vote in favor of a change in 008.

1 Like

Adrian,

Wrong, the funds on today’s keys are fully spendable. In the event a hacker takes a baker’s key. They get the immediately available funds, and then proceed to race the baker in draining the rest as the bonds unfreeze. Game over for the insecure baker and bounty paid to the hacker.

Adrian you run the largest bonding pool company in Tezos. The Cryptium Labs baker is bank rolled by other peoples coins. Somewhat ironic to argue that out sourcing the consensus key is bad when that’s basically your business model. You just do it by borrowing coins.

So the big question, why do you want the consensus key non-spendable?

You keep arguing for a non-spendable key, while at the same time arguing that it doesn’t matter security wise because the same amount of funds are at risk. This is logically inconsistent.

To understand why there is inconsistency in Adrian’s argument you have to know his incentives. You can’t trust people but you can trust them to act on their incentives. This is true of nearly everyone.

Adrian’s bonding pool company Cryptium Labs is likely his primary source of income, not the developer grant.

He wants to de-risk his bonding pool by having the consensus key made non-spendable. So he doesn’t have worry about data center staff, his own staff, or a hacker stealing the key. Adrian knows that it is extremely unlikely any of these parties will setup a baker and coordinate a slashing event in such a way that they are likely to get the rewards. However long term non-spendable keys leads to insecure setups. Like bakers storing the keys on disk, which opens us up to state actors and rival chain attacks. Fatal.

Making the consensus key non-spendable removes skin in the game by allowing those with less than immaculate security setups to sleep easy at night. These are almost always bonding pool companies as is the case with Adrian and Andrew or others running similar centralizing businesses like hodl.farm.

Adrian’s support of hodl.farm makes his statements on security and decentralization once again logically inconsistent. Hodl is a baking as a service (BaaS) company. They charge a monthly fee, in return they send users blocks and endorsements which the users then blindly sign remotely.

This is bad for network security as these signers are not doing validation. If BaaS ever hit scale, as it may well do if the consensus key becomes non-spendable, then we will see fewer network validators undermining the networks security. BaaS is security rent-seeking, get paid without doing the work.

Its usually impossible to get someone to understand something when its against their incentives. So whenever someone is advocating for a non-spendable key look at their incentives.

The majority of the community is using Tezos to store wealth for the future. However a minority of centralizing services like some bonding pool companies, and BaaS companies are optimizing to extract wealth today rather than store for the future. Having a non-spendable consensus key allows them to do that easier.

While Adrian has added value in the past. I do not believe that anymore community funds should go to his team. At this point nearly all his protocol development efforts are geared towards his own personal business incentives, be it giving bakers smart contracts or non-spendable consensus keys. These are network centralizing proposals. That are at the expanse of the majority of users who are trying to use Tezos to store and transfer value for which security is everything.

-Justin

The incentives for protecting spendable and non-spendable consensus keys will be different. The spendable part you mention is obviously one reason, but there are also other reasons.

However these security deposits are still at risk, since if an attacker takes over a baker, the attacker can claim 50% of the deposits as a reward and the other 50% will be burnt.

The attacker can claim 50% of the deposit, but it is also possible that the baker is able to recover nearly 50% of the deposit. A compromised consensus key will basically start a race where anyone with the consensus key can try to grab a portion of the deposit.

Since compromising a spendable consensus key is more profitable for an attacker, it increases the threat and consequences* for bakers. This will mean that the risk for spendable consensus keys are higher, which bakers will have to mitigate with an overall higher security. How non-spendable consensus keys would affect the network security and what the trade-offs are would need to be considered carefully.

*I’m actually not sure if the consequences of an attack with non-spendable consensus keys would be lower. As you mentioned, bakers often keep a very small part spendable. A compromised spendable consensus keys would create a similar race between baker and attacker, but about trying to grab unfrozen rewards instead? In that case the baker should be able to recover a larger portion of the funds since less of it would be burnt.

Looking forward to a very interesting (and complex) discussion if non-spendable consensus keys are proposed in the future.

1 Like

Unless there is a problematic shortage of baker staking capacity, would prefer to see bond pooling not get any easier or safer through any proposals, no matter how much additional friction it creates.

Also believe it’s up to the proposers of amendments to curry favor with the community by going out of their way to communicate the details of their proposals in terms that everyday users/delegators (and press/media) can understand and debate before forming an educated opinion that can then be communicated to their baker in time for the upvoting period.

If the people coding the amendments don’t have the communication or people skills to do it, perhaps find someone who is comfortable doing that and also engaging in a back and forth with both bakers and delegators until all positions are clear and questions are answered.

1 Like

For me the most strong argument is:

“By allowing non-spendable consensus keys not only do you reward insecure baker setups but you empower business like baking as a services (BaaS) which Adrian is supporting in Agora.

BaaS makes it possible to have one validator run for the entire network. While this is an extreme example, we should not be making protocol changes that disincentivize bakers from running their own nodes.” (Mindsfiction)

People may start to share their consensus key for better returns. For bakers they would then not be tight to one baking address. Dispersed ownership starts to make things unclean.

==> we re complexifying things to solve a problem that has not been voiced by the community, leading to possible side effects that can (will) reduce security.

A baking proposal that could lower the share of exchanges (eg lower roll size), that s something i could get behind. I fail to see how this proposal would help that, however.

Ps: for the athens proposal, we used a site to capture pros and cons easily. It could be useful for this proposal too. Forgot the link though

Mootjes, the site we used to compare our options for Athens was Kialo. If there is interest it would help organize the ideas being shared and define the tradeoffs being proposed.

1 Like