A Path to Cold Minting
A request for comments (RFC) is a design process, standardized by Rust, intended to provide a consistent method for making substantial changes to protocol. The Peercoin RFCs are therefore potential protocol advancements to be discussed by developers and interested members of the community. Currently, the majority of RFCs are aimed at development of an important enhancement: Cold Minting, in which coin holders can mint while keeping their coins in cold storage for safety. A provably secure minting option like this is expected to greatly increase the participation by minters, and thereby improve confidence in the chain. RFCs 0002, 0003, and 0004 are inter-related and have a common drive towards the end practical application of cold minting. There are many potential side benefits and effects, each of which need to be weighed in turn. This article will attempt to get the reader well versed enough to start considering the consequences of these potential changes.
RFC0004: Remove Transaction Timestamp
In Peercoin, the timestamp is important because it is linked to the fundamental Proof-of-Stake (PoS) concept of ‘coindays’. In order to know how many days a particular output has accumulated, the protocol currently refers to the timestamp of the transaction. Unfortunately, there is no way to enforce an accurate transaction timestamp beyond requiring that it exceed the timestamp of its inputs. The transactor can thereby manipulate their timestamps to their advantage. To fix this variable, RFC0004 proposes to remove the timestamp from the transaction entirely and simply refer to the timestamp of the block that includes the transaction.
Now that we know RFC0004 is a proposal to remove the transaction timestamp, we can look at some of the effects. Firstly, it is worth noting that Bitcoin transactions don’t include the timestamp, so moving in this direction will actually be a move toward simplicity when inducting Bitcoin’s software and infrastructure. One of the next things that jumps out is that transactions no longer have a timestamp related to their creation, allowing for more complex structures that we will ultimately use for cold minting.
Original Block Layout:
RFC0002: Split Coinstake Transaction
For this RFC, we will look at the structure of the core transactions in the block. The coinbase transaction is included in a Bitcoin block as well as Peercoin, and contains information about the block as well as carrying the Proof-of-Work (PoW) block reward. PoS blocks also have a coinbase transaction, but they have an additional coinstake transaction that does most of the heavy lifting as far as the minting and block reward are concerned. This transaction is responsible for the block signature, as well as consuming coindays and freezing the outputs as ‘stake’ for some time. Currently, the coinstake transaction also merges the block reward with the minted output. RFC0002 would move the PoS block reward into the coinbase transaction, separating out the two functions of ‘monetary creation’ via the coinbase and ‘coinage consumption’ via the coinstake transaction. In some ways, this RFC is about aligning the reward in PoS blocks with the one in PoW blocks. From this perspective, this RFC is also a boon for porting infrastructure from the Bitcoin ecosystem.
RFC0002 generates some complications regarding usable outputs. The block reward can no longer be merged with the stake, because they are in separate transactions, so you wind up with a small output on its own that will likely never mint. This tiny output can be recombined in future coinstake transactions to avoid propagating this issue.
Split Block Layout:
When taken along with RFC0004, we see that the coinstake transaction would contain no time-sensitive information. A clear road to cold minting is laid out in forming multiple signature coinstake transactions that are signed in advance by a cold storage key to be used by a minter with access to only one private key (see RFC0003).
RFC0003: Multisig Minting
To satisfy the cryptographic constraints for multiple parties, RFC0003 proposes using a 2-of-3 multiple signature transaction format that will allow the minter to provide the finishing signature on the block at the moment of creation without ever touching the cold keys. This is a natural precaution, where the cold keys can be used to presign a coinstake transaction in advance of block creation. If a hot key and a presigned transaction are both stolen, the worst the attacker can do is consume the coindays and claim the one time reward.
Cold Minting
Hardware cold storage wallets typically require a physical button push to sign a transaction, which is impractical with current protocol as validation of the transaction is required at the time of block creation. The series of protocol enhancements laid out by these RFCs would allow coin holders to keep their coins in cold storage while actively trying to mint by allowing the cold wallet to sign in advance, even while offline. We hope that, if implemented, cold minting will drastically increase the participation of minters on the network.
The best way to support this effort is to comment and make pull requests on these Requests for Comments. You can also support the Peercoin community at large via the chat or the forum.
