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 risksit is worth having an open discussionweighting pros and consbefore finalizing the integration in our codebase.

A technical document that describes the proposed systemhighlighting threats and opportunitiescan be found here:
https://github.com/random-zebra/PIV...per-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 powerand to make sure their is always enough 'hot' staking to keep the network extremely securewe need to set the Cold Staking Rewards to a much lower value. Is that true?

[EDIT: Following added.]

Question: Will sporks be used?

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

I do like thishelpful and complete write up too.
I didnt quite understand the last partis 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 concernwould it be possible to have a portion of the stake automatically given to the coinstakerthat 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 workits 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 docwhen stakingthe 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 contractwhich is exactly the same as the one being spent during the stake (so the cold-staker can keep staking the new utxoonce maturedbut only the coin-owner can spend it).

coin-owners receive the whole stake

Click to expand...

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.
Ideallya staker still has to maintain a hot node online for himselfhe 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 handI don’t want the cold-staker to have any portion of the block reward becauseif cold-staking providers happen to become a realityI want to keep their profit margins as low as possible (they will have to adopt a “pay in advance” modellike 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 considereda more effective solution could be to promote the use of self managed cold-staking nodesproviding easier ways to set them up (for example with one-click installers and/or accessible and detailed documentation).

Click to expand...

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 said:

Finally as a privacy concernwould it be possible to have a portion of the stake automatically given to the coinstakerthat 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.

Click to expand...

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

vampyren said:

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.

Click to expand...

The staking power is the ability to create new blocks.
When only one entity is able to gain 51% of itbad 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.
Sothe 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. Howeverat 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. Soonce cold staking is availablewill 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 said:

There is another risk.

We see that there are almost 1,600 Masternodes. Howeverat 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. Soonce cold staking is availablewill 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?

Click to expand...

Wouldn't the movement just be determined by market forces based on profitability? I doubt that will change. As for the reward structure changeeither 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. Thoughthis 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 yeahkeep it simple I say. Even with the same reward structureby making it more secure to stakemore may be willing to stake PIVX now. And with the new GUI providing easier setup of masternodesmore MNs may get created as well. In turnMN 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. Heckdue to the ease of delegating a certain amount of coins or UTXOs to a certain cold-staking nodeit may even result in more individual full staking nodes than right now! (e.g. for someone with a lot of PIVthey 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!

AnywaysI'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 securitythat'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 waythen they are on their own to figure it outsince 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 anywaysso just don't mention it in official documents.

Alsoby 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 convenientwithout even realizing that there's another way to do it.

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

So if someone bricks their phone trying to jailbreak itthey 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 providerthey 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 whileand 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 networkand could provide means to further mitigate the risks of centralized staking; it also may encourage more masternodes as wellas more full nodes staking will distribute the staking rewards wider.... essentially a tweak to the staking algorithm to provide an age factorwhich would encourage smaller stakes (those less likely to feel compelled to keep their coins coldand 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 morebut with that infrastructure design that I'm envisioningit 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 said:

(e.g. for someone with a lot of PIVthey 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!

Click to expand...

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 stakingsame keys in wallets on multiple systemsso if one goes down I'm still staking from the other node(s).

With cold stakingthe 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 said:

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 stakingsame keys in wallets on multiple systemsso if one goes down I'm still staking from the other node(s).

With cold stakingthe 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?

Click to expand...

That would actually be interesting as in theoryyou 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 said:

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?

Click to expand...

First off we should use the same convention to name thingsas in the docotherwise 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 addressand the delegator whitelist) can be runas Jaki saysby multiple cold-stakers to provide redundancy.

random.zebra said:

First off we should use the same convention to name thingsas in the docotherwise 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 addressand the delegator whitelist) can be runas Jaki saysby multiple cold-stakers to provide redundancy.

Click to expand...

Thank youand 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 said:

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?

Click to expand...

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 personalself-managed staker node).
If otherwisea 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 providerthoughwould be much more dangerous. Masternodes don’t create blocks.

On the other handI 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 CLIand no edit to the config files is required either.
They can keep the hot-node on their home PC and use the GUIsame as they were doing before.


* One note about hardware walletssuch as Ledger or Trezor.

Of course their wallet softwares don’t support this feature (and probably won’t in the near feature).
This meansthat it will be still possible to use their addresses as ownerAddr in the stake delegationbut the process will need to be started from a Core Wallet first. In other wordsthe coins will have to be in a Core Walletfrom 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 coinsbut to do sohe 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 SPMTto enable the access to cold staking features directly from the hardware wallets which will solve this issue in the future.

random.zebra said:

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

Click to expand...

AwesomeI'm leading our 'Zephyr' (PIVX Electrum) light wallet build and would be pretty interested in finding out how this would be possible for hardware walletswith 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 memberand we were wondering if it would be a good idea from a privacy perspective to add Denoms for cold stakingas 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 pivit may make small changes to the frequency of winning blocksbut is the privacy gained worthwhile?