Cold minting

[sigmike]

This pull request includes a few more changes than just cold minting. The cold minting changes are in commit 8df4a03. They do not include any change in the GUI yet, so you can only create cold minting addresses through RPC.

The protocol switch time is set very far in the future until we decide the final time.

The other changes include:

• improvements on the functional test system (11dafc9)
• a fix on duplicate stake rejection (there was problems when a new block was received on top of a rejected block) (7c5e5a3)
• a bitcoin 0.8 protocol change delayed until protocol switch (edd3f09)

[sigmike]

Note that there's no restriction on the CoinStake output when a minting-only key is used. I'll add that shortly.

[sigmike]

Note that there's no restriction on the CoinStake output when a minting-only key is used. I'll add that shortly.

[sigmike]

I was going to add some restrictions on the CoinStake transaction when a minting key was used but I actually found a cleaner way.

I added the restriction checks inside the OP_COINSTAKE opcode (which became OP_MINT). So we are certain the minting key can only be used when all the conditions are met.

The conditions are:

• the transaction is a CoinStake
• all the output and input scripts are the same (so you cannot move the coins, and cannot combine inputs from multiple addresses)
• an no value is destroyed.

[sigmike]

I was going to add some restrictions on the CoinStake transaction when a minting key was used but I actually found a cleaner way.

I added the restriction checks inside the OP_COINSTAKE opcode (which became OP_MINT). So we are certain the minting key can only be used when all the conditions are met.

The conditions are:

• the transaction is a CoinStake
• all the output and input scripts are the same (so you cannot move the coins, and cannot combine inputs from multiple addresses)
• an no value is destroyed.

[Thireus]

Hi sigmike,

Would you mind giving us a brief answer about what security risks could be involved if a single person holds all or more than a certain % of the minting keys (amount % equivalent of 51% of mature coinage)?

I'm asking because there is no risk to the individual for disclosing minting keys (thus no incentive to keep this key private). Since PoS is certainly going to increase with this cold minting feature (or in the future), people will also tend to centralise the minting effort and by that I mean use a third-party to keep minting permanently online.

Thank you!

[Thireus]

Hi sigmike,

Would you mind giving us a brief answer about what security risks could be involved if a single person holds all or more than a certain % of the minting keys (amount % equivalent of 51% of mature coinage)?

I'm asking because there is no risk to the individual for disclosing minting keys (thus no incentive to keep this key private). Since PoS is certainly going to increase with this cold minting feature (or in the future), people will also tend to centralise the minting effort and by that I mean use a third-party to keep minting permanently online.

Thank you!

[sigmike]

what security risks could be involved if a single person holds all or more than a certain % of the minting keys

There would be the same security concerns as if someone holds the same % of the coins.

there is no risk to the individual for disclosing minting keys

With the proposed implementation there are 2 risks:

1. Getting the reward is not enforced by the protocol, so someone with your minting key can finds blocks and drop your reward. You can't loose coins but you can loose the reward.
2. When 2 clients have the same keys there's a risk their block will be rejected by the network, so your reward may be delayed indefinitely if multiple persons have your minting keys

people will also tend to centralise the minting effort and by that I mean use a third-party to keep minting permanently online.

There was some discussions about that in the (long) proposal thread.

The proposed implementation doesn't permit variance reduction pools because the minter cannot merge the stakes. Variance reduction is what leads to centralization because a bigger pool is better than a smaller one, so small pools tend to disappear and the biggest ones tend to always grow. I believe removing that removes the mechanism that leads to centralization. I tried to explain that here, here and probably in other posts in this thread.

[sigmike]

what security risks could be involved if a single person holds all or more than a certain % of the minting keys

There would be the same security concerns as if someone holds the same % of the coins.

there is no risk to the individual for disclosing minting keys

With the proposed implementation there are 2 risks:

1. Getting the reward is not enforced by the protocol, so someone with your minting key can finds blocks and drop your reward. You can't loose coins but you can loose the reward.
2. When 2 clients have the same keys there's a risk their block will be rejected by the network, so your reward may be delayed indefinitely if multiple persons have your minting keys

people will also tend to centralise the minting effort and by that I mean use a third-party to keep minting permanently online.

There was some discussions about that in the (long) proposal thread.

The proposed implementation doesn't permit variance reduction pools because the minter cannot merge the stakes. Variance reduction is what leads to centralization because a bigger pool is better than a smaller one, so small pools tend to disappear and the biggest ones tend to always grow. I believe removing that removes the mechanism that leads to centralization. I tried to explain that here, here and probably in other posts in this thread.

[kac-]

@sigmike is this PR final? Is it still possible to introduce percentage of stake loss due to minting key leakage?

E.g. 5% of stake can be sent to different address in second tx output?

I think that w/o it, it will be impossible to prevent wide and silent key leakage -> disaster.

[kac-]

@sigmike is this PR final? Is it still possible to introduce percentage of stake loss due to minting key leakage?

E.g. 5% of stake can be sent to different address in second tx output?

I think that w/o it, it will be impossible to prevent wide and silent key leakage -> disaster.

[7h0m45]

I don't understand why peercointalk forum members are asking questions here when this topic has been thoroughly discussed for months in the forum. Duplicate stake rejection elegantly solves the "key leakage" problem. lf you disagree, why not post your concerns in the forum for community discussion?

[7h0m45]

I don't understand why peercointalk forum members are asking questions here when this topic has been thoroughly discussed for months in the forum. Duplicate stake rejection elegantly solves the "key leakage" problem. lf you disagree, why not post your concerns in the forum for community discussion?

[sigmike]

is this PR final?

Yes, unless we find issues or the community doesn't want it. But what I understood from the peercointalk discussion is that there's pretty much a consensus for this solution.

Is it still possible to introduce percentage of stake loss due to minting key leakage?

It's possible, but if you allow a percentage to be lost you almost allow everything to be lost because you could loose X% each time a block is found.

I think that w/o it, it will be impossible to prevent wide and silent key leakage -> disaster.

The 2 protections I mentioned above are good enough to prevent that IMO.

You make a minting key to get your reward safely. If someone else gets it you may loose that reward, so you have an incentive to protect it.

[sigmike]

is this PR final?

Yes, unless we find issues or the community doesn't want it. But what I understood from the peercointalk discussion is that there's pretty much a consensus for this solution.

Is it still possible to introduce percentage of stake loss due to minting key leakage?

It's possible, but if you allow a percentage to be lost you almost allow everything to be lost because you could loose X% each time a block is found.

I think that w/o it, it will be impossible to prevent wide and silent key leakage -> disaster.

The 2 protections I mentioned above are good enough to prevent that IMO.

You make a minting key to get your reward safely. If someone else gets it you may loose that reward, so you have an incentive to protect it.

[kac-]

@7h0m45

 Duplicate stake rejection elegantly solves the "key leakage" problem

If it does, there is no risk of x% loss. Cold minted blocks have same weight as hot minted = cold minting keys represent value = using them should be exposed to some risk. Making it „safe” is unhygienic, illogical and leads to bad practices.

 lf you disagree, why not post your concerns in the forum for community discussion?

I've shown my concerns few times on public forum. It's common to discuss PRs using this form.

[kac-]

@7h0m45

 Duplicate stake rejection elegantly solves the "key leakage" problem

If it does, there is no risk of x% loss. Cold minted blocks have same weight as hot minted = cold minting keys represent value = using them should be exposed to some risk. Making it „safe” is unhygienic, illogical and leads to bad practices.

 lf you disagree, why not post your concerns in the forum for community discussion?

I've shown my concerns few times on public forum. It's common to discuss PRs using this form.