The purpose of this post is to outline a potential protocol upgrade that will break minting down into fundamental primitives to increase the flexibility of the Peercoin PoS system. The originator of the concept was @peerchemist. It is still in the conceptual stages as of writing this, so feel free to have at it.
Motivation
Peercoin is designed as a Proof-of-Stake fix on top of the Proof-of-Work system. As Bitcoin advances, it cares not for the functions that Peercoin originally exploited to run its adaptation of the system. To become flexible enough to grow with the changes in Bitcoin, we need to break minting down into its primitives and develop smart-contract-like behaviors that fully encapsulate the minting process. By doing this, we also open the doors to full functionality for concepts like multisig minting, cold minting, and slasher algorithms.
Design
Create a new OP code that allows for the declaration of minting a block in advance of the event. This form of transaction will have a timestamp declaration as well as a signature, removing much of the burden on the coinstake during block creation. When the block is actually formed, only a single signature is needed to sign the completed block.
Reduced Computation Time
By computing the stake intervals in advance, we are able to reduce the required burden on minting nodes. Currently, a node will check each mintable utxo every second for its ability to mint, requiring a rapid locking and unlocking of each private key to hash the coinstake and check against the difficulty. By front-loading the computation, we have the potential to check many stake intervals in advance all at once, as well as to do the computation ahead of time, such that at the moment of block creation your client already knows which stake is ready to mint.
Multisig Minting
By signing the coinstake in advance, participants in a multisig are able to coordinate on human-relevant timescales (such as weeks) to sign the transaction in preparation for block creation. At the moment of block formation, only one representative from the multisig need be online to form, sign, and broadcast the block using the presigned coinstake.
Cold Minting
The simple application goes along these lines: a minter puts their funds in a 2-of-3 multisig. 2 of these keys are cold and remain offline, while one is hot. The minter locates a time interval for minting, and proceeds to sign the mint declaration/coinstake offline with their cold keys. The signed coinstake is then transferred to the hot node in preparation for block creation. When the time comes, the hot key is used to sign the broadcasted block. Thereby, the cold keys need never touch the hot node, and the signed transaction transfer can be done on human-relevant timescales for things like air-gapped systems.
Slasher
If we further require locking of coin upon mint declaration, we now have the opportunity for collateral to ensure that the minter plays fair, potentially defeating any possibility of ‘nothing at stake’. This can be used to ensure that a minter fulfills their block creation duties, or to punish block creation on unsupported forks (just like a slasher algorithm). Ultimately, by separating this function out into its own smart contract, we can apply almost any rules we choose to achieve chain stability. In the beginning, even just the locking mechanism itself can be used to impose a minimal cost of the standard transaction fee if you declare and don’t form a block. Such deterrents should be considered in depth before stepping too deeply into the realm of slasher protocols.
Arbitrary Minting Contracts
By promoting minting into a contract, we have access to a wide variety of potential applications. Beyond simply playing with reward, we would begin to have full access to the stake being used to form the block, such that we can really play any kind of game we want with the system of rewards and punishments. It is a fully flexible system, that can be made to closely approximate the current behaviors, while also allowing for an arbitrary level of control over the minting process. The key here is that all minters must agree on the new rules, whatever they are, as the system is not some kind of abstract turing complete language. Instead, it is a finite protocol with a limited attack surface that we can tune to achieve the desired results.
Open Questions
How does the OP code work, exactly? It is hard to assess vulnerabilities without details on how it works.
What happens with PoS difficulty and predicting things in advance, if some people choose to either miss their allotted time or to declare late? Is it possible that you will declare your intent to mint then the difficulty will be too high for you to follow through? In that case are you penalized?
What kind of UI support will we need for this? Is this more or less intuitive to the standard minter compared with current protocol?
What other ideas are there? Killer app ideas early in the game can fundamentally alter the way this is implemented.
What are the best first steps in this direction, and are they degenerate with the current protocol? i.e. can we move in this direction first with a soft-fork before we make fundamental changes? When we do make fundamental changes, do we need to do everything at once or can we do it in stages? Or is the best approach to just do it once and do it right?
Are all proposed additional features merely soft-forks or client/UI changes once the fundamental changes have occured?
There’s all sorts of stuff here we should revisit: [PPC] [PROPOSAL] PPCoin Online Stake Safety
Closing remarks
This would likely preclude the presence of full-blown mint pools, as it is not as aggressive in disconnecting the keys from the authority as RFC-0012 is.
While it is a lot of work to rewrite and support the new method, it would open a pathway to continue to work with modern Bitcoin code, even going so far as to providing an easy path for Bitcoin to implement PoS on the fly. This is only good for Peercoin, as the originator of PoS.