-
Notifications
You must be signed in to change notification settings - Fork 555
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cold minting #78
base: develop
Are you sure you want to change the base?
Cold minting #78
Conversation
Users can generate a "cold minting" address from a "minting only" address and a "spending" address with the new RPC "addcoldmintingaddress". Only a wallet having the minting key will be allowed to mint coins sent to this new address. And only a wallet with the spending key will be allowed to send the coins. See src/test/features/cold_minting.feature for example scenarios.
…lready is a super majority on testnet whereas the change has not been released yet
Note that there's no restriction on the CoinStake output when a minting-only key is used. I'll add that shortly. |
OP_COINSTAKE was renamed to OP_MINT because it now also verifies that the transaction is purely minting, and not moving the coins nor destroying them. So using a minting-only key is now only allowed: * inside a CoinStake transaction (like before) * when the input and output scripts are all the same * and when the total output value is greater than or equal to the total input value
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 The conditions are:
|
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! |
There would be the same security concerns as if someone holds the same % of the coins.
With the proposed implementation there are 2 risks:
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 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. |
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? |
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.
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.
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. |
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.
I've shown my concerns few times on public forum. It's common to discuss PRs using this form. |
unity pbinvoice 20140531
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: