Cold storage minting proposal

[glv]

If I understand correctly, the idea of ppcman and NewMoneyEra is to generate a minting key pair (public + private) and a script signed by the original private key to allow minting with the minting key.

I don’t think it solves the problem of minting key disclosure.
What would prevent some people from giving their minting key pair and the signed script (minting authorization) to a minting pool proposing something like: “Give us your minting keys, we will mint for you and you won’t need to keep a computer running 24/7”?

If such a pool gets a lot of minting keys, it will generate a lot of blocks, and a single entity generating many blocks is bad for the security of the network.

To solve the minting key disclosure issue, we need a system in which the disclosure has drawbacks.
For example:

• the minting reward could be much smaller if you’re minting with a key that isn’t yours (but how to prove that the minting key is yours without using the original private key we’re trying to protect?)
• the node minting a block could decide to what address the reward will be sent (if the pool mints a block, it can keep the reward; that’s an incentive to mint by yourself)

[NewMoneyEra]

[quote=“glv, post:61, topic:2336”]I don’t think it solves the problem of minting key disclosure.
What would prevent some people from giving their minting key pair and the signed script (minting authorization) to a minting pool proposing something like: “Give us your minting keys, we will mint for you and you won’t need to keep a computer running 24/7”?[/quote]

@glv, thanks for your feedback. The SOVERN Minting Protocol has primary incentives to not share keys, but I am not sure how closely you read the original post, because I appreciate that you have offered a solution in the quote below, which happens to be in the original post.

[quote=“glv, post:61, topic:2336”]To solve the minting key disclosure issue, we need a system in which the disclosure has drawbacks.
For example:
……
(if the pool mints a block, it can keep the reward; that’s an incentive to mint by yourself)[/quote]

If you reread the original post SOVERN Minting Proposal above you will find the following:

@NewMoneyEra

Any Peercoin interest generated from minting with this Mint-Key will be deposited into this Mint-Public-Address

The Mint-Key and the Mint-Public-Address are a traditional private key / public key pair therefor the Mint-Key controls spending of funds in the Mint-Public-Address. If you have given away or shared your private key then you have given away or shared your ability to spend those funds. The “reward” or interest paid on minting is deposited in this address, so the pool operator or anyone you may have shared your Mint-Key with can spend these funds.

The SOVERN Minting Protocol already does what you propose as a solution.

But, genuinely, I do appreciate your feedback.

NewMoneyEra

[glv]

[quote=“NewMoneyEra, post:62, topic:2336”]If you reread the original post SOVERN Minting Proposal above you will find the following:

@NewMoneyEra

Any Peercoin interest generated from minting with this Mint-Key will be deposited into this Mint-Public-Address

The Mint-Key and the Mint-Public-Address are a traditional private key / public key pair therefor the Mint-Key controls spending of funds in the Mint-Public-Address. If you have given away or shared your private key then you have given away or shared your ability to spend those funds. The “reward” or interest paid on minting is deposited in this address, so the pool operator or anyone you may have shared your Mint-Key with can spend these funds.[/quote]

Indeed, I didn’t realize right away that the ability for the minting node to spend the reward was in your proposal, my bad…

I think sigmike’s cold minting address proposal can also be modified to integrate this idea.

@sigmike

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.

If we allow the reward to be sent to any address (while the coins must stay in the cold locked minting address), it would also reduce the incentive of giving away your minting key.

[sigmike]

The “Disclose minting key to public” issue affects all the solutions that provide absolutely safe minting. In these solutions you can give your minting abilities to everyone because you’ve nothing to loose and someone may do the minting job for you. This is a big problem because it may fork the network each time this stake is minted.

This problems also appears if you set up multiple minting nodes with the same minting keys. There’s an incentive to do that because if one node fails you still have another one running. But if you do that, each time you’ll find a block you may fork the network.

The problem is not about giving the minting key to someone else. Doing that is fine from the network perspective. The problem only appears when you give the minting key to many people who will mint at the same time.

Requiring the private key to prove this particular minting key is allowed to mint would not solve the problem because people will always do it anyway. If I want to give away my minting key I’ll first allow it to mint.

Reducing the reward may help because it makes the whole solution unattractive. But if you accept the lower reward then there’s still the same incentive to give away your minting keys.

Allowing the reward to be spent by the minter would solve the problem because you will loose your reward if you disclose your minting keys. But it makes pools possible and that leads to centralization. I tried to explain that here:

@sigmike

By allowing the minter to spend the reward we enable this whole variance competition in peercoin too. We make variance reduction pools possible because they will be able to split each reward. It will inevitably lead to centralization because the same “the bigger the better” problem would appear.

I proposed a punitive solution:

@sigmike

Right now when we receive 2 different blocks at the same height from the same previous output, we put the 2nd one on hold. We could put both on hold instead, and move one step backward in the blockchain. So as long as there are multiple clients minting the same coins, the reward would be delayed because the blocks would be rejected. I think that’s enough to defeat the incentive to give away your minting key.

Removing the most recent block may bring some issues so I’m not sure this is the best solution. But it would prevent people from running multiple nodes with the same minting keys.

Another solution would be to allow the reward to be destroyed (or not generated actually). We just have to allow the reward to be between 0 and the standard reward. If you give your minting keys there’s a risk you’ll generate blocks without any reward. But it does not remove the incentive to run multiple nodes.

[mhps]

@sigmike

Requiring the private key to prove this particular minting key is allowed to mint would not solve the problem because people will always do it anyway. If I want to give away my minting key I’ll first allow it to mint.

To some degree this is already possible. One can put private keys in several wallets on several machines and mint in parallel. I posted about it before.

I proposed a punitive solution: [quote="sigmike, post:38, topic:2336"]Right now when we receive 2 different blocks at the same height from the same previous output ...[/quote] Removing the most recent block may bring some issues ...

What is the probability for two instances of the same stake, each residing in a different wallet on two different nodes, to find a block at the same block height ? Is it nearly 100%?

Another solution would be to allow the reward to be destroyed (or not generated actually).

Do you mean the processing node will destroy the reward if it finds there are more than one block that has the same minting key? Since the block arrives sequentially, if the node validates a block then finds another block with the same key, how does the node destroy the reward it has already approved ? How is this better than just discarding the offending blocks that come later? Is it because other nodes may receive the “later” block first and approve them instead? I can see it’s a forking situation but still don’t understand how to destroy a block that has already been approved.

[ppcman]

With regard to minting pools, I don’t think they’d be all that popular…

1. The pool would be able to decide which stake to use, which would cause a bidding war, or it would constantly use the next-most-profitable transaction as stake. So big-coin customer will always win out against small-coin customer on the pool. The incentives don’t work very well when you have the pool having to decide which stake to use

Customers wouldn’t like this, and avoid using the pool as a result.

2. Trusting a pool in general, for all these places that seem to spring up, earn trust, and then run away with funds (or get hacked).

3. If funds can’t be moved with just minting keys, then that means for the pool to earn money it requires users to transfer rewards back to the pool. Pool operators may have trouble trusting their users to pay them accordingly.

4. If the default wallet software doesn’t include a command “dumpprivmintingkey” then most users won’t be technical enough to obtain their private minting key in the first place. lol :))

A little education goes a long way. If you write a warning some where in the wallet “never trust some one else to mint for you (find out why)” with a link to a website as to why it’s bad, terrible, and not a good idea, people will listen to official advice.

With all of the forgoing said, they were will still be persistent idiots that will insist on trusting pool operators. But by no means will it be large scale, and the amount of pools offering the service would a minimum anyway. In addition if they really are going to go against the official word and rule of thumb on this, they won’t know how to get their privatemintingkey any way.

There are probably other reasons I haven’t thought of…

[sigmike]

@mhps

To some degree this is already possible. One can put private keys in several wallets on several machines and mint in parallel. I posted about it before.

Yes. But it’ll be much more tempting if there’s no risk involved.

@mhps

What is the probability for two instances of the same stake, each residing in a different wallet on two different nodes, to find a block at the same block height ? Is it nearly 100%?

It’s exactly 100%. They will find the same valid kernel at the same time.

[quote=“mhps, post:65, topic:2336”]

Another solution would be to allow the reward to be destroyed (or not generated actually).

Do you mean the processing node will destroy the reward if it finds there are more than one block that has the same minting key?[/quote]

No, I mean the protocol would allow anyone to get 0 reward when they mint. The official client would not do that of course, but it would be allowed by the protocol.
So if you give your minting keys to anyone, someone may mint your stake and generate 0 reward (for example to punish you from giving your key to anyone).
So your coins are safe, but you may consume your coin age and loose your rewards. This risk may be enough to dissuade people from publicly disclosing their minting key.

@mhps

Since the block arrives sequentially, if the node validates a block then finds another block with the same key, how does the node destroy the reward it has already approved ? How is this better than just discarding the offending blocks that come later? Is it because other nodes may receive the “later” block first and approve them instead? I can see it’s a forking situation but still don’t understand how to destroy a block that has already been approved.

These questions apply more to my other proposal (the punishing one).
To “destroy” the last block you just remove it from the current chain and apply the same reorganization process that happens when you switch to a different chain (basically you put all the transactions back to the memory pool and update the spent flags). You also add this block to an ignore list to ensure you won’t process it again. You may still accept it though if you ever receive a higher block that depends on it.

It’s better than rejecting only the 2nd block because it’s punitive. If I mint 2 blocks with the same stake, a part of the network will accept the first one, and another part will accept the second one and we get a fork. When a new block comes it will be built on top of one of them and that will decide which is the new chain. Every node that accepted the wrong one will switch to the “right” block. So whatever the chosen block, I end up with a block in the main chain and I get my reward. So it’s only positive from my point of view. But if a lot of people do that we will have constant forks and a very unstable network.
But if my 2 blocks get rejected when I do that then I loose something: I don’t get my reward. It’s not lost though, it’s only delayed because I did not consume my coin age.

This solution may also help to convince people there’s no “nothing at stake” problem because in addition to not really having an incentive to mint forks there would be a slight punishment.

[sigmike]

@ppcman

1) The pool would be able to decide which stake to use, which would cause a bidding war, or it would constantly use the next-most-profitable transaction as stake. So big-coin customer will always win out against small-coin customer on the pool. The incentives don’t work very well when you have the pool having to decide which stake to use

Pools would mint all the stakes all the time. The cost to do that is very light so I don’t see why they would not do it.

@ppcman

3) If funds can’t be moved with just minting keys, then that means for the pool to earn money it requires users to transfer rewards back to the pool. Pool operators may have trouble trusting their users to pay them accordingly.

Yes that’s why I say pools won’t be possible if they can’t spend the reward.
There may be minting service providers though.

@ppcman

4) If the default wallet software doesn’t include a command “dumpprivmintingkey” then most users won’t be technical enough to obtain their private minting key in the first place. lol :))

In my proposal the minting address is just an address like any other so you can dump it with “dumpprivkey”.

[ppcman]

@sigmike

Pools would mint all the stakes all the time. The cost to do that is very light so I don’t see why they would not do it.

Let’s say I have 5,000 users that want me to mint for them.

The first 100 users have over 25,000 PPC each in their wallets.

The next 4,900 have 10 PPC each in their wallets.

I get paid 0.2% minting commission for a successful minted block. Guess who am I’m going to spend all my nodes on? Of course the top 100 richest users.

That’s my point. So the greater majority of users (with smaller amounts of PPC) wouldn’t be attractive to pool operators, and as a result, the centralization problem isn’t as big of a problem in a typical case like this…

@sigmike

In my proposal the minting address is just an address like any other so you can dump it with “dumpprivkey”.

That’s fine if it is an address just like any other. But make the official wallets not have the command to dump the private minting key. This way it becomes more cumbersome and difficult for the general user to hand their minting key to a pool.

If you start telling users “Hi, I am XYZ pool, and in order to get your minting key, you have to download the XYZ wallet which has the dumpmintingkey command”… The majority of people will instantly not trust them and avoid it too…

At some point we have to look at the pro’s and cons:

1. PRO: cold wallets can exist keeping private keys safe, and people can still secure the network.

2. CON: Many people are panicked that it means the majority of users will start running heads over heels to share their 1% reward with minting pools. (1% is low enough of a reward already for some thing people can easily earn by running a peercoin minting client on their desktop that they can easily monitor themselves. Now we expect most people to share those 1% profits with some one else too?)

I think the benefits and PRO outweighs the CON in this case.

The only reason why 51% POW problems exist, is that solo mining PoW with older coins like BTC, and LTC is near impossible for the general user.

The thing about minting, is that it is EASILY DONE by the general user. So why the heck would people use pools in the first place? Do you see my point?

A very small minority may decide to use pools. The majority won’t is what I’m saying by all of this…

[sigmike]

@ppcman

make the official wallets not have the command to dump the private minting key. This way it becomes more cumbersome and difficult for the general user to hand their minting key to a pool.

We need to be able to dump our minting key to put it on our minting node.

[ppcman]

@sigmike

[quote=“ppcman, post:69, topic:2336”]make the official wallets not have the command to dump the private minting key. This way it becomes more cumbersome and difficult for the general user to hand their minting key to a pool.

We need to be able to dump our minting key to put it on our minting node.[/quote]

If it’s in minting.dat along with your transaction data, and there is no command to display it on the screen, then that is enough to stump most people who download binary wallets and binary minters anyway.

[Cybnate]

@ppcman

[quote=“sigmike, post:70, topic:2336”][quote=“ppcman, post:69, topic:2336”]make the official wallets not have the command to dump the private minting key. This way it becomes more cumbersome and difficult for the general user to hand their minting key to a pool.

We need to be able to dump our minting key to put it on our minting node.[/quote]

If it’s in minting.dat along with your transaction data, and there is no command to display it on the screen, then that is enough to stump most people who download binary wallets and binary minters anyway.[/quote]
Not sure about that, it would only be a one time action for most people. There will always be people to help and write down a step-by-step on how to do it. It would make sense if you had to go through the hassle every time again, e.g. after each block. So you would have a one-time minting key.

[mhps]

@sigmike

[quote=“mhps, post:65, topic:2336”]What is the probability for two instances of the same stake, each residing in a different wallet on two different nodes, to find a block at the same block height ? Is it nearly 100%?

It’s exactly 100%. They will find the same valid kernel at the same time.[/quote]

Then aren’t these two blocks identical? If I remember correctly, any node will reject the later one to arrive, thinking that the second one is the first one broadcasted twice…

[sigmike]

@mhps

[quote=“sigmike, post:67, topic:2336”][quote=“mhps, post:65, topic:2336”]What is the probability for two instances of the same stake, each residing in a different wallet on two different nodes, to find a block at the same block height ? Is it nearly 100%?

It’s exactly 100%. They will find the same valid kernel at the same time.[/quote]

Then aren’t these two blocks identical?[/quote]

Not necessarily because they may not include the same transactions.

@mhps

If I remember correctly, any node will reject the later one to arrive, thinking that the second one is the first one broadcasted twice…

Yes the nodes will reject the second block they receive. But some nodes may accept one block while the others accept another one (because they received it first). Then the network is split until another block comes.

[mhps]

@sigmike

[quote=“mhps, post:73, topic:2336”]Then aren’t these two blocks identical?

Not necessarily because they may not include the same transactions.[/quote]

OK even 90% are identical it’s still a serious problem.

[superppc]

i think i found an interesting way to do cold minting without centralisation. sending a recording as i can’t write much because of a physical issue: vocaroo.com/i/s1na6WLGuqnI

[Cybnate]

@superppc

i think i found an interesting way to do cold minting without centralisation. sending a recording as i can’t write much because of a physical issue: Vocaroo | Online voice recorder

I just listened, it is a legit contribution in case someone questioned this somewhat unusual contribution from a newbee. It is 8 minutes of audio. Vocaroo is a legit voice recording service.

[Ben]

Does Vocaroo offer a way to transcribe audio?

[superppc]

not sure but u can also download as mp3

[river]

It’s worth listening to.

Quick summary (I think this is correct), it has two parts:

1. Minting only custom hardware.

2. A proposal to have a minting key but with a twist that removes the incentive for centralization. If your minting key was compromised, you wouldn’t just lose the minted coins but also a small percentage of the actual coins from cold storage. The idea being that if the risk was slightly higher, for example 1-5% of staked coins, then this would discourage centralization as it wouldn’t be worth the risk giving coins to a minting service. In this case, the worst case scenario of a centralized provider stealing your coins would be the minted coins plus a small bit of staked coins, as opposed to just losing the minted coins.

So this may strike a balance of reducing the risk of minting sufficiently so that much more people will mint, but at the same time increasing the risk of using a centralized provider to the point that it is no longer an incentive.