Minting while having your ppc in cold storage

General
23

Well if I wanted to stop you from having access to your own coins temporarily, I could mint a block for you force them to be used towards stake for a 520 block confirmation. Luckily today, the wallet needs to be unencrypted for the StakeMinter process to read your transactions and make the necessary adjustments to wallet.dat after it mints a block.

Some people may want to maintain a “reserve balance”, so those particular coins will not be used towards minting a proof-of-stake block.

That’s why my mint-by-proxy solution theoretically works, but I’m sure there is a simplified way of doing it. All I wanted to do was throw it out there. I know Sunny reads these forums occasionally, so if he stumbles across it, it might give some food for thought.

Also this is the year we may be assembling a larger DEV team to help Sunny after 0.4 is out, so lots of things on the horizon coming this way. :slight_smile:

Minting seems to have every one’s attention, any thing we can do to improve that aspect of Peercoin helps us become more attractive to new potential investors.

24

Well if I wanted to stop you from having access to your own coins temporarily, I could mint a block for you force them to be used towards stake for a 520 block confirmation. Luckily today, the wallet needs to be unencrypted for the StakeMinter process to read your transactions and make the necessary adjustments to wallet.dat after it mints a block.[/quote]

OK that is a potential issue, although perhaps a relatively minor one compared with having to expose all your savings online while minting.

Minting seems to have every one's attention, any thing we can do to improve that aspect of Peercoin helps us become more attractive to new potential investors.

I got into PPC because I wanted to see POS working with my coins. Unfortunately I have yet found a POS block. :frowning:

25

Suppose I have a Trezor device, and it works for Peercoin. Then, the private keys controlling my stake never leave the device: I can sign a coinstake transaction with almost the same peace of mind I would have by keeping them in a cold wallet.

26

[quote=“ppcman, post:15, topic:1772”][quote=“petar87, post:13, topic:1772”]Imagine this, if you can mint risk-free then you won’t care much if somebody steals your credentials as he can just mint a block for you. Then people could give their keys in public so others can mint for them, and those minters would have potential to double spend then.

Now I think cold storage minting is not possible?[/quote]

With my proxy proposal:

How could they double spend? They still cause the original coins used as stake for 520 block informations. The only person who can spend, is the holder of the private key to that wallet.[/quote]

Your proposal has one fatal flaw.

What can hacker do if is able to “hacks your minter”?

[quote=“ppcman, post:6, topic:1772”]3) Even if someone “hacks your minter”, the only thing they can do is:
a) Mint for you (which is stupid, why bother)
b) unlock your cold storage and stop your proxy-minting capability but not gain access to your private keys to your wallet, because they are offline and inaccessible.[/quote]

Then why wouldn’t you just give it to some online service to mint for you so you don’t have to hassle with it?
That service would become centralized point with very important role to create new blocks and with thousands of holders credentials they could double spend easily.

Minting a block with private (spending) key is a MUST. That is the only way to ensure that no delegating to third-party is possible, or any form of centralized pools.

I agree best possible way would be to have specialized hardware devices which would be “unhackable”.

27

[quote=“petar87, post:13, topic:1772”]Hm, I gave it some more thoughts and that’s actually bad idea to have separate key for minting :(.

Imagine this, if you can mint risk-free then you won’t care much if somebody steals your credentials as he can just mint a block for you. Then people could give their keys in public so others can mint for them, and those minters would have potential to double spend then.

Now I think cold storage minting is not possible?[/quote]What about this: the holder of the minting key gets the ability to spend the block reward from the minted block, but not the ability to spend the stake. Then, you would still care if someone steals your minting key, because then they can still “steal” your 1% reward. However, the private key for the stake coins can be kept in cold storage. Does anyone see a flaw with this idea?

28

Hi All,

I do not know how I missed this very interesting thread. There have been many thought provoking posts.

SigMike has not weighed in here yet on this subject. I hold SigMike in extremely high regard: in my mind he is up there at the top just below Sunny in his overall understanding of Peercoin code and the dynamics of the protocol.

On an unrelated thread, a while back, I did ask SigMike about this subject. Here, quoted below, was my crude question and his insightful response:

[quote=“sigmike”][quote=“NewMoneyEra”]Because, unfortunately, I am not a coder here is something I am reduced to just wonder about:
Paper Wallet Proof-of-Stake minting?
Could software be designed to be a PoS-minting Watch-only wallet? That is could a wallet possibly have a PPC Public Address but not have the Private Key and still participate in PoS minting? Perhaps if the Private Key has signed to allow minting?[/quote]

I think Sunny King is already planning a solution but I don’t know if he mentioned how or when.

For the network to be secure, you need to prove you own aged coins to generate a PoS block (otherwise anyone could easily destroy the network by generating as many blocks as they want). Right now the only way to prove that you own them is by signing a transaction with the private key of your coins.

But the bitcoin system is very flexible so we can quite easily change the protocol to allow special transaction (that was done to allow multisig for example).

Most of the transactions are simple “pay to address”. That means they have a script attached that says “you can do whatever you want with these coins if you can sign with the private key of address X.”
On multisig transactions, the script says (for example) “you can do whatever you want if you can sign with 2 private keys of addresses X, Y and Z.”

In our case we could allow transactions with a script that says “you can generate a PoS block if you can sign with the private key of address X, and whatever you want if you can sign with the private key of address Y.”
This way you could have a private key that can only be used as PoS. You could keep it unlocked without too much risk.

We would have to force the output to be the same as the input in this PoS block (which is not the case right now: you can change your client to make it move your coin when it finds a PoS block).

I don’t know if there already are such transactions in bitcoin where a signature is only valid in a specific context. I think it should work. It’d probably require a new script “word” (something like “are we doing PoS?”).

It would also help on the issue mentioned above where you don’t know which coins are really used for minting.

Building a good user interface for that may take some time.

I think that’s one possible solution. There are certainly others.

Anyway I think we can’t implement a solution only on the client side because when you received your coin it was explicitly said that only your private key can use them and the protocol obeys that even during PoS. We need to change the protocol (i.e. all clients).[/quote]

SigMike’s excellent analysis is what led me to post the following question in the Questions for Sunny thread:

Does anyone have any thoughts or comments on SigMike’s analysis?

Or, suggestions on how the above quoted question to Sunny could be improved?

29

I think Sigmike’s solution has this weakness, as discussed.

Sigmike writes:

Too many wallet holders would publicly share their minting keys, in order to not have to worry about minting for themselves. This would degrade the security of the network (I think). That is why I propose that the holder of the minting key would have the ability to take the mint reward, but not the original stake. This proposal does, however, require a hard fork. Thoughts?

30

[quote=“Chronos, post:29, topic:1772”]I think Sigmike’s solution has this weakness, as discussed.

The Private Key allowing spending is NEVER online. How can there be a problem with double spending? Or, for that matter any kind of spending?

I wouldn’t be sharing my minting key, but if I did, why would someone else be inclined to mint at their expense and effort only for my benefit?

For arguments sake, assuming advantage in what you propose that I do not at this point see, let’s assume the minting key is willy-nilly traded around or in some way exchanged between humans, how do you propose the network would know who to give the minting reward to? The network has no idea who the human holder is. The reward can only go to one of the two possible public addresses at issue. Your human holder of the minting key only holds a publicly compromised minting key that cannot spend. How do you propose the network would reward this person?

31

I don’t think holders will publicly share their minting key. They would deliberately decrease the security of the network (and thus the value of their stake) for an insignificant gain: not having to mint themselves.
Minting would require so little power and risk that I don’t see why people would do that considering the risk.

Also I think that sharing a private key will be psychologically frightening. You’ll think twice before you it, so you must have a good reason.

Yes it would be a problem for the security because you give others the ability to mint more blocks than they could if they only had their own stake to mint. They would have more chances to mint multiple blocks in a row.

But if you give the key to everybody then the risk is reduced because even if you have the key it may be someone else’s block that ends up propagated.

This is feasible and it would certainly dissuade people to share their minting key (if this is needed).
And it can be added to my proposition. What I suggest is a technical solution to enable minting-only keys. We can add other rules on top of that.

I don’t think there’s a solution to this problem that wouldn’t require a hard fork.

32

Small stake holders have very little chance to find a block in a long time. It may take years. Pooled minting will guarantee a return in an given period. But you are right – the pool has to have some motivation to do it if it can’t get hold of the stakes. Maybe they can claim part of the POS reward in exchange of the service.

Also I think that sharing a private key will be psychologically frightening. You'll think twice before you it, so you must have a good reason.

If everyone does it, many will not think twice doing it – Just like most people don’t realize putting the money in the bank is legally giving the money to the bank in exchange of a promise.

That said, I still think mint-only key is a good idea. The pros outweigh the cons.

33

[quote=“petar87, post:13, topic:1772”]Hm, I gave it some more thoughts and that’s actually bad idea to have separate key for minting :(.

Imagine this, if you can mint risk-free then you won’t care much if somebody steals your credentials as he can just mint a block for you. Then people could give their keys in public so others can mint for them, and those minters would have potential to double spend then.

Now I think cold storage minting is not possible?[/quote]

Unfortunately, I have to agree to this. Proof of stake needs something to be at stake. There must be a strong enough incentive for the stakeholder to stay online and mint and not to delegate the minting to other party (which could attempt double-spend or perform other attacks having nothing to lose). These two points are main sources of security of the network. As Ben wrote,

and I tried to address elsewhere, the PPC protocol probably lacks the proper motivation for staying online, since the reward is only compound interest. So in short:

  1. There should be a disadvantage for not staying online minting.
  2. There should be a disadvantage for delegating minting.

I think this is step in the right direction to fulfill the point 2. The problem here is that possible losing of 1% of profits is, IMHO, not sufficient motivation not to delegate the minting to a third party. If someone offers me promise to pay me 0.9% (while keeping the 0.1% for himself) and mint for me, I will gladly give him my minting key knowing I do not really risk much. (My stake is 100% safe.) But consider this: What if the minting key (signed by the spending key) would allow owner to one-time destroy (or one-time spend) 10% of the wallet’s peercoins? Then losing the minting key would be serious problem, but still much better than when the spending key would be lost (100% loss). This form of possible “punishment” would discourage people from delegating their key, but it would significantly (by 90%) reduce the costs of the would-be hacker attack. (Before you dismiss it - consider it is still 90% improvement compared to the situation as is today.)

Also, I think that we really need to address the point 1 somehow. (Preferably in some way that allows small stakeholders to collect their 1% if they mint, but strips people who no dot mint most of the time of it.) But that is probably very different discussion.

I know that it might be hard to digest and probably also hard to sell to investors, but I think that “softer” solutions are at the cost of security and decentralization of the network.

34

I was definitely not suggesting to increase penalty for not-minting above that 1%. It is just fine where it is. But you are not losing 1%. If you decide to mint, let’s say, after 2 years, when you’ll find the POS block, you will be paid the reward for whole 2 years. (Reward is not capped after 90 days). Which means you will gain 2%. If you were online whole time, you would actually get 2.02% because of compounding. So your loss is actually only 0.02%, which seems not enough to me. 1% loss by inflation would seem fair trade for being safer cold wallet holder, which probably was the original idea of the design.

35

Do we know how much time it takes on average to mint a block using 90 days old 1k ppc stake?

6 × 24 × 365 = 52 560 blocks per year
Suppose each user mint 4 blocks per year
52 560 ÷ 4 = 13 140
13k users need to use their privkey 4 times a year to maintain the network? Doable in fully secure way. Nah, hard to achieve.

There is an incentive(security,electricity) for big stakeholders to consolidate stake and mint occasionally, 1M PPC stake used once a year adds nearly ZERO security to the network. Limit GetProofOfStakeReward to 0.xxx% of moneysupply ? https://github.com/ppcoin/ppcoin/blob/master/src/main.cpp#L862

36

I don’t think you would actually do this because it would make your stake NOT 100% safe. You would know you would be diminishing or destroying the network security upon which your entire stake depends.

I expect the big money coming towards Peercoin won’t be that dumb. That said sometimes people do make such dumb decisions so we need to plan for this contingency.

10% might be too high. The big money people headed our way would be scared snotless with the concept of losing 2 or 3% I would think.

I’m not competent enough yet to tell if this is technically possible, but I definitely applaud it for creative thinking and problem solving. :slight_smile:

37

Punitive actions aren’t something that I feel needs to be decided by the protocol. Abstaining from something, and therefore an not gaining a reward is one thing, but to actively penalize is a whole different story.

@Ken:

I wonder still though about that. I've asked many times over the months what would happen if I minted after 5 years and some people say you never will get more than 1% (else people could amass too much power), others say you will get 5% (because it's owed to you). I still am unsure what the right answer is.

You would get 5%, if you minted a block after five years. Your chance to solve that block at that point, on Day 1825, however, is no better than it was on Day 90.

Compounding would really make a difference if the block reward for solving with proof-of-stake was equal to 1% of the stake, regardless of the coin days (so the reward for minting a block with a 100 PPC stake on Day 31 would be 1 PPC, just as minting that same block at Day 365 would be 1%). In that case, you’d be motivated to mint as often as possible, because if you could solve two blocks in a year, you’d see a better compounding.

Note: I’m not necessarily advocating for this change. Personally, as someone who keeps my wallet minting, I’d love to generate a better return over the course of year. As it stands, I’m making far less minting, per year, than I am mining with my modest 180GH/s.

38

If this is reaction to my post, I probably only chose poor wording. When I first read about proof of stake, the proposal introduced penalty for not minting. This seemed quite bad to me. What Peercoin does, with 1% reward for minting, looks much, much better. Although 1% penalty for not minting or 1% reward for minting are technically the same thing, 1% reward is much more pleasant. What I am saying is only there should be some advantage for those actively minting (and only for them - point 1) and some real motivation for people not to delegate the minting. I agree there should not be any punitive actions involved. You could also look at my idea about point 2 so that there is (probably) viable implementation of safe minting that protects 90% (or similar number) of your coins from hacker’s attacks. (While remaining 10% are still protected by your minting private key really well, if you keep it secret - the same way you keep your spending key now.) So I’m sorry if I wrote my post too crudely - I was thinking in terms of incentives and security and I probably forgot to sell the idea properly.

This is nice option, although it 1 PPC for 100 PPC after 30 days would correspond to 12.8% p.a., which is quite inflatory. (For small stakeholders, getting POS block award every 30 days is very improbable, but big stakeholders could easily do it.) If one would like to keep interest 1% p.a., the reward would be 0.082 PPC per 100 PPC after 30 days. Equivalently, one could also award for coindays as now, but cap the reward at 90 days the same way the probability is now. It would slightly hurt small stakeholders who cannot find the block every 90 days, but it would solve the problem.

39

I have had a very similar idea to the concepts discussed here. I had started a thread but missed to find this one here, so I have deleted the thread an quoting myself here:

[quote="“d5000"”]I had recently an idea how it could be possible to allow to do PoS minting with the coin-age of a “cold wallet”, that would be probably simpler than Sunny King’s “cold locked transaction” feature. It would allow to store most of your coins in a secure offline wallet and at the same time benefit from the coins in it.

(For those who don’t know about the “cold locked transaction” concept: You have two private keys/addresses, “cold” address and “hot” address. The “hot” address is connected to the Internet for PoS minting/forging. But you may want to have most of your coins in your secure, “cold” address with the private key hold in cold storage. Now you can do a “cold-locked” transaction from the cold address to hot address, so you can use the coin-age of these coins to generate PoS coins. The coins sent in a cold-locked transaction can only be spent on the address that sent them (= your “cold” address). So you can have “cold” address in cold storage (without connection) as it’s the only address at risk, and “hot” address can happily mint PoS coins.

We can say that in this kind of transaction we have transfered the “coin-age” of the “cold” address to the “hot” address to benefit from PoS minting without putting the coins at risk. In other words, it’s a way to demonstrate to the system that we have the private key of both addresses and want only one of them to be connected to the network for PoS minting, so the other private key is not at risk.)

Now possibly there is a simpler way to do this:

Instead of doing a special transaction (the “cold-locked transaction”) of some coins from the “cold” address to the “hot” address, we could add only the coin-age of the “cold” address to the “hot” address. In other words, we would register the “cold” address with the client which contains the “hot” address, but without to give it access to the private key of the “cold” address. For this purpose, we would send the client a message signed with the private key of the “cold” address which would be stored in the blockchain like a transaction, but without moving any coins. When other clients connected to the network see this message, they would then add automatically the coin-age of the “cold” address to the coin-age of “hot” address.

Respect to the original “cold-locked transaction” proposal, I think this approach has the advantage that we don’t need to deal with two different kinds of transactions in the core PPC system. Only the “PoS algorithm” of the clients would have to deal with the coin-age of the “cold” address. There would be no “different kind of coins” in the hot address like the coins transferred in a cold-locked transaction which cannot be spent freely.

The PoS algorithm of the client would have to check the (actualized) coin-age of all “cold” addresses at every block, but no client would have access to the coins in it (=not having access to the private key), only to the message signed with this key. When we move the coins from the “cold” address, the network would register this and the “hot” address would lose the coin-age transferred to it from the “cold” address.

Also there must be a mechanism to avoid that someone tries to PoS mint with both addresses. So the PoS algorithm would have to block addresses which have transferred their coin-age to another address.

What do you think? Is this alternative simpler to implement than the original cold-locked-transaction concept? Or does it have a problem somewhere?

The only disadvantage I see is that the PoS algorithm would probably be a bit more complex having to check multiple addresses for one unit of “coin-age”, but a the other hand the transaction system itself would not have to be modified.[/quote]

@ppcman:

Your proposal is pretty similar to mine, with two differences:

  • the transaction fee
  • the “blocking” of the coins in cold storage. In my variant the PoS algorithm would have to check the cold-storage address’ balance (and coin-days) permanently as coins can be moved anytime.

Your proposal is more similar to Sunny King’s “cold-locked transaction” approach, as coins are “locked” and “unlocked” with a special transaction, but it differs from it in that the balance will not form part of the balance of the “hot wallet”.

40

I bump this thread with a comment I made in the “removal of checkpointing” thread. For the cold-locked minting feature there are several ideas now.

To remember: cold-locked minting feature must meet at least these conditions:

  • the main private key can be hold in offline cold storage, so there is no risk to get the coins hacked,
  • the incentive to run a online client permanently must not be affected (very important!)
  • it should not add new attack vectors on PPC.

There are several proposals now for this issue:

Sunny’s proposal is most likely to be included in one of the next releases, he mentioned it briefly in the last chat here. But I think it’s worth discussing and comparing the other proposals too, perhaps one of them is easier to implement or has some other advantage.

41

d5000

Thanks for the summary. Can you explain: are the above proposals merely ideas or theories at this stage, or are they achievable?

In other words, is there a known solution to the conundrum of minting coins while in cold storage, or is this an, as yet, untested, hope?

42

They are theories but I think they are achievable too :slight_smile: I see no logical problems with them, only it’s a bit of work to implement it securely without new attack vectors.

The cold-locked-transaction proposal (Sunny’s) is some months around there. Sunny had even said in December or January that he wanted to include it in the next release (which is now rescheduled to 0.5). Would be nice if he could confirm it.

I think he reads these threads and if one of the other proposals is easier to implement, he perhaps will take it into account.