PIVX Cold Staking

Hello all.
I'm opening this thread to collect feedback and possible concerns on the "Cold Staking" upgrade proposed for the PIVX network.
As it is a feature that provides indubitable benefits but also carries possible risks, it is worth having an open discussion, weighting pros and cons, before finalizing the integration in our codebase.

A technical document that describes the proposed system, highlighting threats and opportunities, can be found here:
https://github.com/random-zebra/PIVX-Wiki/blob/master/Developer-Documentation/Specs/ColdStaking.mediawiki

The implementation code can be checked in the submitted PR here:
https://github.com/PIVX-Project/PIVX/pull/955

To sum it up:
PROS:

• users can stake coins safely storing the private keys in "cold storage".
  CONS:
• it could centralize the staking power in the hands of "cold staking service" providers if such services were to become predominant.

First off - THANKS for initiating this discussion!

Awesome work. Glad to see this new functionality being added!

Question: What are the plans for the rewards?

I would think that to mitigate the above listed CON of centralized power, and to make sure their is always enough 'hot' staking to keep the network extremely secure, we need to set the Cold Staking Rewards to a much lower value. Is that true?

Question: Will sporks be used?

Can we code the network to use sporks to adjust the rewards without a protocol update, if the hot staking amounts drop too low causing concerns with network security? Eventually, once there is confidence in the rewards properly balancing cold/hot wallet amounts, such sporks could be removed I presume.

I do like this, helpful and complete write up too.
I didnt quite understand the last part, is it intended that cold staking is released with 4.0.0 or after?

Also i didnt see a mention of the staking amount being paid to cold stakers? Will it be identical to the amount recieved by hot stakers? I feel it should be slightly less for incentive purposes. Though i dont know how much added work that would be? I assume considerable.

Finally as a privacy concern, would it be possible to have a portion of the stake automatically given to the coinstaker, that way the coin staker doesny need to communicate with the coin owner at all ever. It reduces the need or ability to ever conduct KYC.

Thanks for your work, its appreciated.

Overall good proposal. Also missing the info about "staking amount being paid to cold stakers ".
And i dont get the Cons part. How is it different from current system? They cant still stake even today just using a wallet. Dont see a huge different beside convenience.

As explained in the doc, when staking, the cold-staker can only send to the same P2CS script. That means that the original value of the stake input plus the stake reward of 2 PIV “goes into” a contract, which is exactly the same as the one being spent during the stake (so the cold-staker can keep staking the new utxo, once matured, but only the coin-owner can spend it).

coin-owners receive the whole stake

This is by design.

I don’t want to penalise the coin-owner (lowering the reward for him) because I want to encourage this system.
Ideally, a staker still has to maintain a hot node online for himself, he just keeps the keys offline (coin-owner and cold-staker are primarily supposed to be the same person with two wallets).

The process is similar to what we have with masternodes… do we discourage the hot-cold setup in favor of the “all-in-one” masternode solution? No we do the opposite. We suggest to keep the collateral in a (possibly offline) controller.

On the other hand, I don’t want the cold-staker to have any portion of the block reward because, if cold-staking providers happen to become a reality, I want to keep their profit margins as low as possible (they will have to adopt a “pay in advance” model, like masternode hosting providers do).

I think there are different ways to encourage the use of self-managed cold-stakers:

changing the fee structure or the reward distribution might be considered, a more effective solution could be to promote the use of self managed cold-staking nodes, providing easier ways to set them up (for example with one-click installers and/or accessible and detailed documentation).

I do like Eric’s idea of sporks though.
We could introduce one spork to disable the cold-staked blocks (but still allow spending from the coin-owners) for a limited period of time to see how the network responds.

@Cryptosi:
Finally as a privacy concern, would it be possible to have a portion of the stake automatically given to the coinstaker, that way the coin staker doesny need to communicate with the coin owner at all ever. It reduces the need or ability to ever conduct KYC.

Guess that the above answers this question as well.
I'm not sure how this would prevent communication between the actors though, or why KYC would be involved.

@vampyren:
And i dont get the Cons part. How is it different from current system? They cant still stake even today just using a wallet. Dont see a huge different beside convenience.

The staking power is the ability to create new blocks.
When only one entity is able to gain 51% of it, bad things can happen.
It's the same problem as with hash power and mining pools in PoW cryptocurrencies.
With this system you don't transfer the ownership of the coins but you give (possibly to a 3rd party) the staking power that comes with your coins.
So, the risk is that a "cold-staking service provider" might show up and become so popular to be a threat for the network.

There is another risk.

We see that there are almost 1,600 Masternodes. However, at most - for popular proposals - there typically 550 votes. That means there are just over 1,000 Masternodes that are basically 'cold staking' albeit in a more complex way. So, once cold staking is available, will those 1,000 Masternodes simply drop from the network to reduce their overhead/running costs and cold stake? Will a 65% drop in Masternode count be an issue?

@Eric_Stanek:
There is another risk.

We see that there are almost 1,600 Masternodes. However, at most - for popular proposals - there typically 550 votes. That means there are just over 1,000 Masternodes that are basically 'cold staking' albeit in a more complex way. So, once cold staking is available, will those 1,000 Masternodes simply drop from the network to reduce their overhead/running costs and cold stake? Will a 65% drop in Masternode count be an issue?

Wouldn't the movement just be determined by market forces based on profitability? I doubt that will change. As for the reward structure change, either don't change it (in order to maintain 30%+ vote rate of over 500 votes) or flip the 3:2 to 2:3 to increase the pool of stakers. Though, this does not guarantee an increase in staking full-node count on the PoS side as each staking node has no limit to how many coins it can stake unlike the 10k limit per MN on the masternode side.

So yeah, keep it simple I say. Even with the same reward structure, by making it more secure to stake, more may be willing to stake PIVX now. And with the new GUI providing easier setup of masternodes, more MNs may get created as well. In turn, MN vs stake ratio (thus ROI%) will remain roughly the same but both their count could increase. Changing the reward structure with PoS bias over MN will only be felt during the first few days or so before they level out again. (and not necessarily with more staking nodes)

I expect this cold staking feature to not cause any extra centralization in the network as it is far easier to setup & maintain than a masternode. (especially if you have more than 10k PIV) This will in turn make people just setup their own cold staking node (as they only just need 1) instead of needing to look for a paid-service cold-staking node. Heck, due to the ease of delegating a certain amount of coins or UTXOs to a certain cold-staking node, it may even result in more individual full staking nodes than right now! (e.g. for someone with a lot of PIV, they could create staking redundancy by delegating half of their balance to 1 node (e.g. VPS) while delegating the other half to another node (e.g. another VPS) ALL while keeping the entire coin balance in a single offline wallet or address!

Anyways, I'm really looking forward to this feature and I think it's a must have addition that provides extra security for PIVX stakers while also making the coins potentially more accessible/portable. (as the coins can even be sent to and held on a mobile wallet address while they stake via a remote staking node!!) (as for mobile wallet security, that's another matter lol)

I like the idea of PIVX promoting/highly recommending the use of self-managed cold staking nodes. Videos and instruction manuals made by PIVX can easily leave out any mention on how to do staking services and maybe even suggest against it. If someone wants to do it that way, then they are on their own to figure it out, since PIVX only supports the self-managed version for network security reasons.

Most newbies and non-tech savvy people like myself will simply follow the official directions and suggestions without question anyways, so just don't mention it in official documents.

Also, by making the self-managed cold staking nodes super simple to set up (one click installers like random-zebra mentioned) most will do what is easiest and most convenient, without even realizing that there's another way to do it.

The example that came to mind, that may fit, is when people (usually only tech savvy types) want to jail break their phone and put modified versions of Android/ iOS on it, they get absolutely NO support from Google or Apple to do it, and the companies actually strongly suggest against it, and may even void warranties.

So if someone bricks their phone trying to jailbreak it, they can't call Google for support because they know that they were warned against it. Same applies with people who have problems with a cold staking service provider, they should not expect help from the PIVX support team other than a reminder that that PIVX only officially supports self-managed cold staking nodes. To do otherwise is at your own risk.

I have been toying with an idea for a little while, and this implementation spurred me to move to a low level design of my idea. I have written up notes and I will propose it in the next couple of days to see if it's something that would be desired. It is designed to encourage more full nodes to be on the network, and could provide means to further mitigate the risks of centralized staking; it also may encourage more masternodes as well, as more full nodes staking will distribute the staking rewards wider.... essentially a tweak to the staking algorithm to provide an age factor, which would encourage smaller stakes (those less likely to feel compelled to keep their coins cold, and those less likely to want to pay for cold staking services) to actively participate in the network.

I also just recently began toying with thoughts of dynamic changes via sporks. I still need to think that through more, but with that infrastructure design that I'm envisioning, it would open the possibility of adjustments to reward values without the need for releases and protocol change enforcement; but rather using the historical record of when spork values were written to the chain; rather than having to hard code changes in large if/then/else code sections determining what the 'rule' was at any given block height. That idea needs much more floating around in my head before coming up with a concrete design; a few more things to take care of first.

@jakiman:
(e.g. for someone with a lot of PIV, they could create staking redundancy by delegating half of their balance to 1 node (e.g. VPS) while delegating the other half to another node (e.g. another VPS) ALL while keeping the entire coin balance in a single offline wallet or address!

This just prompted a question. One thing I do a lot of with coins that have very little intrinsic value (and thus i'm not concerned with keeping the keys contained behind my firewall); I run redundant staking, same keys in wallets on multiple systems, so if one goes down I'm still staking from the other node(s).

With cold staking, the risk to the principal is mitigated. random.zebra; apologies that I haven't ramped up on your code as much as I had hoped to today (e.g. tl;dr :).; Does your implementation limit the coin owner to a 1 to 1 relationship with the hot wallet; or can the owner authorize multiple (redundant) cold stakers?

(Edit: Corrected terminology)

@CaveSpectre:
This just prompted a question. One thing I do a lot of with coins that have very little intrinsic value (and thus i'm not concerned with keeping the keys contained behind my firewall); I run redundant staking, same keys in wallets on multiple systems, so if one goes down I'm still staking from the other node(s).

With cold staking, the risk to the principal is mitigated. random.zebra; apologies that I haven't ramped up on your code as much as I had hoped to today (e.g. tl;dr :).; Does your implementation limit the cold staker to a 1 to 1 relationship with the hot wallet; or can the cold staker authorize multiple (redundant) hot wallets to provide the staking?

That would actually be interesting as in theory, you could have more than 1 staking nodes for a single set of UTXOs.
I assume that will work if you run the same wallet.dat that has generated the same stakerAddr on multiple nodes?

@CaveSpectre:
Does your implementation limit the cold staker to a 1 to 1 relationship with the hot wallet; or can the cold staker authorize multiple (redundant) hot wallets to provide the staking?

First off we should use the same convention to name things, as in the doc, otherwise we generate confusion.

• the cold-staker is the one that stakes. It's the online node.. (so the "hot" node) we call it cold-staker because it's staking "cold" coins (spending keys are presumably offline).
• the other actor is the coin-owner (the actual owner of the spending keys).

The coin-owner can delegate coins to a staking address (so they can be staked -but not spent- with the corresponding keys).
The same wallet.dat (with the keys to the staking address, and the delegator whitelist) can be run, as Jaki says, by multiple cold-stakers to provide redundancy.

@random.zebra:
First off we should use the same convention to name things, as in the doc, otherwise we generate confusion.

The coin-owner can delegate coins to a staking address (so they can be staked -but not spent- with the corresponding keys).
The same wallet.dat (with the keys to the staking address, and the delegator whitelist) can be run, as Jaki says, by multiple cold-stakers to provide redundancy.

Thank you, and my apologies.... Yes; that's the redundancy I am asking about. one owner to many stakers.

If I understand this correctly this is a neat work-around that will allow hardware wallet users to keep an empty online wallet to stake on behalf of their hardware wallet balance. I don't see any downside to this - how would it make Pivx more attackable?

@voluntary:
If I understand this correctly this is a neat work-around that will allow hardware wallet users to keep an empty online wallet to stake on behalf of their hardware wallet balance. I don't see any downside to this - how would it make Pivx more attackable?

It would not make the network any more vulnerable if we keep the same level of decentralization (i.e. if each coin-owner keeps his personal, self-managed staker node).
If otherwise, a considerable number of stakers decides to use a service (so to not have to keep any node online) that would be a problem.
We’ve seen this already with the “hot” part of the masternode setup.
A centralization of staking power in a single provider, though, would be much more dangerous. Masternodes don’t create blocks.

On the other hand, I see this as a remote possibility because:
A) the business model would be more complex (comparing to masternode hosting providers) and profit margin lower.
B) it is much easier for users to set up self-managed stakers than masternodes: a public IP is not needed, so they are not forced to rent a VPS and use the CLI, and no edit to the config files is required either.
They can keep the hot-node on their home PC and use the GUI, same as they were doing before.

***** One note about hardware wallets, such as Ledger or Trezor.

Of course their wallet softwares don’t support this feature (and probably won’t in the near feature).
This means, that it will be still possible to use their addresses as ownerAddr in the stake delegation, but the process will need to be started from a Core Wallet first. In other words, the coins will have to be in a Core Wallet, from where they will be selected as inputs for a stake delegation tx (with ownerAddr belonging to the hardware wallet).
At that point only the owner of the keys to the ownerAddr will be able to spend those coins, but to do so, he will have to import those keys in a Core Wallet because Ledger/Trezor applications can’t sign P2CS inputs yet.

I plan to build a tool similar to SPMT, to enable the access to cold staking features directly from the hardware wallets which will solve this issue in the future.

@random.zebra:
I plan to build a tool similar to SPMT, to enable the access to cold staking features directly from the hardware wallets which will solve this issue in the future.

Awesome, I'm leading our 'Zephyr' (PIVX Electrum) light wallet build and would be pretty interested in finding out how this would be possible for hardware wallets, with the assumption that a similar-ish approach would enable light wallets to become cold stakers.

Also I would like to bring the topic of Sporks here (to the forum), as we discussed on Discord that we could enable Sporks to protect the network in case of any contingencies. I would like this especially if we can find a way to implement the sporks so that they do not deny Coin holders access to their coins.
This would be good to have for the first year or so as you suggested in discord.

The Spork has been proposed here: https://github.com/PIVX-Project/PIVX/pull/975

@random.zebra , I was discussing private staking with a community member, and we were wondering if it would be a good idea from a privacy perspective to add Denoms for cold staking, as combining that with stealth addresses for the payouts and whatever privacy we go with moving forwards cough - range proofs - cough , would give us a private staking option pretty much as soon as privacy is released? what are your thoughts? staking in groups of 5k,1k,100,50 piv, it may make small changes to the frequency of winning blocks, but is the privacy gained worthwhile?