Cold storage minting proposal

In Peershare we need to allow large shareholders to secure the network while having their private keys in cold storage.
Peercoin also needs this feature so we should use a common solution for that.

So in this message I present my solution and compare it to others in the hope consensus for a final solution can be reached.

Idea

The main idea is the use a new kind of address very similar to multi-signature addresses.

These new addresses would be composed of 2 public keys:

  • a minting key that is only allowed to mint
  • a spending key that is only allowed to move the coins to another address

We could call these addresses “cold minting addresses”.
They will start with a lowercase “p” like multisig addresses.

Any coin sent to a “cold minting address” will only be spendable if you have the spending private key.
And to mint with these coins you only need the minting private key in your wallet.
(In both cases you also need the cold minting address in your wallet, but you can recreate it very easily)

If your minting private key is stolen, the only thing the thief can do is to mint on your behalf. This is not good for the security of the network but it is nothing compared to loosing the coins.

Other solutions

d5000 listed other proposed solutions here: http://www.peercointalk.org/index.php?topic=2467.msg22366#msg22366
Here is a quick comparison:

Sunny King’s cold locked transactions (https://bitcointalk.org/index.php?topic=194054.0):
Idea: You send coins to another address with a special “cold lock” transaction. This other address is only allowed to mint and to unlock the coins back to the original address.
Pro:

  • may imply less changes in the code than my solution
    Con:
  • you must cold lock any new coin you receive, so you must bring back your cold storage private key each time you want to cold lock coins and it costs you the transaction fee
  • you must not loose the minting private key, otherwise you can’t unlock the coins
  • we need a new special UI to lock and unlock coins (my proposal also requires a new UI, but it’s only used at setup time)

NXT leased forging (http://wiki.nxtcrypto.org/wiki/Glossary/fr#Leased_Forging)
Idea: you make a special transaction to say this other address is allowed to mint your coins on your behalf for a given duration. Very similar to cold locked tx but limited in time.
Pro:

  • the duration?
    Con:
  • the purpose is explicitly to let someone else mint, it looks dangerous from the network security perspective
  • you must lease again when you receive new coins or when the leases expires. You must use your cold storage private key each time you do that.
  • the account receiving the lease can do whatever he wants with the reward (though we can implement that differently)

ppcman’s Mint-by-proxy (http://www.peercointalk.org/index.php?topic=2467.msg20540#msg20540):
Idea: unless I misunderstood something, it works exactly like cold locked minting (with a different terminology) except there’s a high fee to lock and unlock (0.05 PPC)
So the same pro and con apply plus:
Pro:

  • the fee? “These fees will be destroyed and be put back into the network, which can increase the coin supply for better rewards than 1%”
    Con:
  • the fee?
  • from the description it looks more complex to implement than cold locked minting, but I’m not sure how they differ exactly.

d5000 (http://www.peercointalk.org/index.php?topic=2467.msg21919#msg21919):
Idea: you send a signed message to other nodes to transfer the coin age from an address to another one. The message is stored in the blockchain.
Pro

  • you don’t need to move the coins and loose coin age to enable cold locked minting on an address
  • “the transaction system itself would not have to be modified”. That’s right but it requires so many other changes I’m not sure this is globally positive.
    Con:
  • we must implement a new message type (but maybe we can use special transactions instead and reuse many existing code)
  • we must keep a new big record to know what coin age was transferred to what address. It looks error prone and not lightweight client friendly (although peercoin is already not very lightweight client friendly)
  • it looks very complex to implement
  • “there must be a mechanism to avoid that someone tries to PoS mint with both addresses”
  • you must have the private key nearby each time you want to transfer coin age

bitbadger (http://www.peercointalk.org/index.php?topic=2580.0)
Actually this proposal has nothing to do with cold storage minting. Although the idea of not loosing coin age when coins are sent is interesting.

jutarul (https://bitcointalk.org/index.php?topic=115608.0):
Idea: we generate CoinStake signatures in advance and use them when we find a block
Con:

  • must be done again after a block has been found
  • actually impractical because you can’t sign the blocks

Also Chronos suggested we allow the minting key to spend the reward, to dissuade people from sharing their minting key or being too loose on security. I’m not sure about that.
The discussion was here: http://www.peercointalk.org/index.php?topic=2467.msg21197#msg21197

Implementation details

We add a new script opcode OP_COINSTAKE that pushes 1 if we’re in a coinstake transaction and 0 otherwise. It’s easy to do because we have access to the transaction when the script is run.

We allow a new standard script that authorizes one key if the transaction is a CoinStake, and the other one in all other situations.
The script could look like this:

OP_DUP
OP_HASH160
OP_COINSTAKE
OP_IF
mintingAddress.GetHash160()
OP_ELSE
spendingAddress.GetHash160()
OP_ENDIF
OP_EQUALVERIFY
OP_CHECKSIG

When a CoinStake transaction is generated, if the kernel is a cold minting address and we know the minting private key then we sign the transaction with this key.

Right now when you find a PoS block you can send the reward and the coins to another address. We must prevent that when a cold minting address is used: the coins and the reward must be sent to the cold minting address. We must also force the output value to be exactly the sum of the inputs + the reward (currently the protocol allows a lower value).

We make the block signature and validation also work when the kernel is a minting address (right now it only supports pay-to-pubkey outputs).

In the GUI we add a new button “New cold minting address” in the “Receive coin” tab. It opens a form asking for the minting address, the spending address and an optional label.

In the RPC server we add a new command “addcoldmintingaddress []”.

We add a new “Minting only balance” in the overview page that displays the amount of coins you cannot spend but you can mint with. This amount should not appear in the balance.

During the CoinStake creation we change the coin selection process to also select the outputs with which we can only mint.

Pull request: https://github.com/peercoin/peercoin/pull/78
Specific commit : https://github.com/peercoin/peercoin/commit/8df4a0360f3917e042cc0185dc39ed894c9f4148

Edit: Added the last 2 elements in the implementation details.
Edit 2: Added requirement for the minting output value to be exactly the sum of the inputs + the reward.
Edit 3 : Added link to the proposed implementation

I like the idea of having two keys of course. :slight_smile:

When I proposed mint-by-proxy, it was with the idea that a special transaction would be needed to the blockchain to authorize a new minting keypair before going into cold storage.

(This way all nodes could verify who was authorized to mint when a coinstake was generated)

Since this was adding to the blockchain, it could also be abused by some one constantly authorizing an de-authorizing a certain minting key before going into cold storage.

So I figure if we made it an expensive cost (0.05) going into cold storage wouldn’t be a frequent event.

…we could have also enjoyed having those extra coins be destroyed and earned back again, increasing the 1% rewards which seem so small. :slight_smile:

With your solution, you don’t need sign a transaction on the blockchain in advance it seems, so there is no special transaction needed to authorize your minting keypair, is that true?

Is if some one wanted to have a “reserve balance”, and some so-called attacker minted for you (lol)… But by having to sign it with the minting private key, that stops other people from minting for you.

The more I write, the more confusing this is sounding. I’ll stop here.

That’s right, you just need to receive coins on this special address.
The usual transaction fee still applies to this transaction though. But you don’t need to pay another fee to after you received the coins.

That's right, you just need to receive coins on this special address.

Mike, in your proposal, am I understanding that there would be three types of addresses available?

[ol][li]A regular, single signature address (the “P” address, today)[/li]
[li]A multi-signature address (the “p” address, today)[/li]
[li]A two-signature, minting address (new)[/li][/ol]

If that’s correct, will I need to move peercoins from my regular or multi-signature addresses to my minting address, to make them available for use by the wallet or daemon?

You’ve proposed a technical solution, but I’m unsure how it works from a user’s perspective.

Could you adjust the following step-by-step template so it’s easy to comprehend without getting too technical.

To break this down in a full cycle, step-by-step in Peercoin terms:

  1. I have 500 Peercoin in my wallet address (public key), and I can move the coins with my hidden private key.

  2. new script opcode OP_COINSTAKE is implented, every one upgrades, now we can see how this works.

  3. I want to go into cold storage and mint after 30 days has lapsed

  4. I do this, and this happens or is the result

  5. that happens

  6. Now 30 days have passed, and I am lucky enough to mint a new block on day 31

  7. The coins go here. Then the coins go there.

  8. I come out of cold storage, and want to spend these new coins, so first I must do this, than that…

  9. Now to go back into cold storage, I repeat step 3

[quote=“Ben, post:4, topic:2336”]Mike, in your proposal, am I understanding that there would be three types of addresses available?

[ol][li]A regular, single signature address (the “P” address, today)[/li]
[li]A multi-signature address (the “p” address, today)[/li]
[li]A two-signature, minting address (new)[/li][/ol][/quote]

Yes. And the new address would also start with a “p”.

Actually in the blockchain you wouldn’t be able to differentiate these addresses from multisig addresses until they are used.

Yes. You must send the coins to this new address to enable the minting only key.

You can use your existing regular address as the spending address if you want. So you’ll still use the same private key to spend the coins. You’ll just have a new key to mint them.

It may be difficult to make this system work with a multisig address as the spending address. It’s probably feasible but may require some work.

You can use your existing regular address as the spending address if you want. So you'll still use the same private key to spend the coins. You'll just have a new key to mint them.

This quote makes it sound as if I have some ability to morph a regular “P” address into a minting “p” address. Based on your previous comments, I believe that I’m the one confused about how these work, but would you mind giving a simple example of what would need to happen in this scenario:

I have 100 PPC come into my wallet, to my regular “P” address. I would like to make these 100 PPC available, after they reach maturity, for use in the minting process.

Do I have to move the coins to a “p” address, or can I somehow morph the “P” address into a “p” address by enabling a secondary signature?

[quote=“ppcman, post:5, topic:2336”]Could you adjust the following step-by-step template so it’s easy to comprehend without getting too technical.

  1. I have 500 Peercoin in my wallet address (public key), and I can move the coins with my hidden private key.

  2. new script opcode OP_COINSTAKE is implented, every one upgrades, now we can see how this works.

  3. I want to go into cold storage and mint after 30 days has lapsed[/quote]

I create my cold storage key as I wish.

I click on “New address” to create my minting only address. I give it the label “minting”.

I click on “New cold minting address”.
In the “Minting address” field I select the “minting” address I just created.
In the “Spending address” field I type the public address of my cold storage key.
In the “Label” field, I type “cold minting”.
I validate the form

My new “cold minting” address appears in my address list. It starts with a lowercase “p”.

I send 500 peercoins to my new “cold minting” address.

(Note that I never had to put my cold storage private key into my wallet.)

Now the balance of my wallet is 0 because I cannot spend these 500 peercoins.
We should probably add a “minting only balance” in the overview tab that would display these 500 peercoins.
These 500 peercoins are used during the minting process.

The 500 coins and the reward are sent to same “cold minting” address.
The amount appears in the “Stake” balance until they mature, as usual.
After they mature the amount (500 + the reward) goes back to the “minting only balance”.

I import the cold storage private key into my wallet.
The “minting only balance” is now 0 and my wallet balance is 500 + the reward.
I can send the coins to any address.

In step 4 I can reuse the “minting” address I already have.

[quote=“Ben, post:7, topic:2336”]I have 100 PPC come into my wallet, to my regular “P” address. I would like to make these 100 PPC available, after they reach maturity, for use in the minting process.

Do I have to move the coins to a “p” address, or can I somehow morph the “P” address into a “p” address by enabling a secondary signature?[/quote]

You must move the coins to the “p” address.
So you should do that before they reach the minimum age, because the age of your coins will be reset in the process.

Creating the “p” address doesn’t change the coins. In the blockchain they are still in the “P” address.

But if you already have your “p” address you can make the coins directly come to your “p” address. And then you don’t have anything else to do.

Sounds like the “near perfect” solution to me. And seems pretty simple to use.

So what’s the roadmap? Is it planned for version 0.5?
I guess all clients will have to be updated as for v0.4, isn’t it?

It would be perfect for my soon to be delivered Rasperry Pi minting station :slight_smile:

I wouldn’t like ppc with risk-free minting. This feature is beneficial to individual but detrimental to coin itself.

For most users it would be even better not to use Rasperry Pi but just to give minting keys in public to some “online minting service”. I would be the first one doing that, just give them private keys don’t bother being online, no installation no anything… And soon that would lead to centralization and that “pool” would have chances to double spend.

I read that nxt implemented this feature as leased forging but I think they will have to remove it with next release if they are serious. Also I saw somewhere how Sunny King was considering this feature before and decided not to have it.

It’s not nice to expose private keys from cold wallet I agree, but that’s the price of this coin security.

I wouldn't like ppc with risk-free minting. This feature is beneficial to individual but detrimental to coin itself.

Can you expand on why risk-free minting would be a bad thing for the coin? More people minting == better network security, no?

Hey Sigmike, did Jordan ever relay the message to you that Sunny wanted to review the design specs before posting them for public comment? I think maybe the message didn’t get to him in time. Too late now, but I sent Sunny a link to this thread anyway. I’d like to hear what he thinks about this solution.

I import the cold storage private key into my wallet.
The “minting only balance” is now 0 and my wallet balance is 500 + the reward.
I can send the coins to any address.

In step 4 I can reuse the “minting” address I already have.[/quote]

After spending some of the coins the rest are in a new change address. Can the old minting address still be used? Was the minting address created based on the old spending/coldstorage address?

Great discussion, really hope Sunny King could take part of this discussion too.

[quote=“petar87, post:11, topic:2336”]I wouldn’t like ppc with risk-free minting. This feature is beneficial to individual but detrimental to coin itself.
…
For most users it would be even better … just to give minting keys in public to some “online minting service”. I would be the first one doing that, just give them private keys don’t bother being online, no installation no anything… And soon that would lead to centralization and that “pool” would have chances to double spend.[/quote]

I don’t believe the minting would be “risk-free” but the risk could be hugely reduced. The risk of losing your coin itself would be essentially eliminated but with Chronos’s idea (which Sigmike referred to in his first post above) you could lose your minted interest or a part of it (which might go to someone else or be destroyed) if you don’t guard your minting key. Thus there would be an incentive to guard your minting key.

In this way the Peercoin network and Proof of Stake protocol remain strong and secure.

Sigmike, Thank You very much for your thorough first post in this thread and all the advanced thought you have put into this matter. In my opinion it is very important to the future of Peercoin, et. al. The handsome reward for this that we discussed long ago is still in effect.

I believe it is crucially important that this system works with “multisig address as the spending address”. Essentially no one is using multisig security right now but this can change almost overnight. The diversity of security advantages possible with multisig spending security is great. Multisig will be widely embraced soon.

If your system can’t be made to work with multisig address as the spending address then I believe this would be a show stopper.

Can you make your advanced system work with a diversity of coming wallet and other applications using multisig spending for enhanced security?

I didn’t get this message. But I sent these specs to Sunny a few weeks ago.

The old minting address won’t have the change so the minting key won’t mint the change. It will be minted (and be spendable) like normal coins.

To make it work you can enable the avatar mode which sends the change back to your address instead of using a new address. Or use coin control if it’s available.

I think it’s feasible. I’d have to test it to be sure.

I see 2 ways to do that:

  • we allow chaining of 2 pay-to-script-hash
  • we enable another kind of address: multisig cold minting address

I’d have to know he details of these coming applications.
If they manipulate and verify raw transactions they will have to adapt their code. We can’t make cold storage minting without changing the protocol so they’ll have to adapt whatever the implementation we choose.