Cold storage minting proposal

Could a hardware wallet such as the trezor modified to automatically sign proof of stake blocks but reject (wait for physical button press) every other type of transaction?

Hi,

I’ve thought of a way to solve the “double minting” problem that also provide a solution for cold minting as a side effect.
Could you please take a look here: https://gist.github.com/mquandalle/4727a429d60aad916821 ?

[quote=“mquandalle, post:44, topic:2336”]Hi,

I’ve thought of a way to solve the “double minting” problem that also provide a solution for cold minting as a side effect.
Could you please take a look here: https://gist.github.com/mquandalle/4727a429d60aad916821 ?[/quote]

This is very close to TAPOS: http://the-iland.net/static/downloads/TransactionsAsProofOfStake.pdf
Instead of having a separate transaction just have each txout have a coin-age chain vote so sending to yourself is the same as publishing just a stake transaction.

Edit: I should clarify further. Any transaction can be migrated to a different chain if it is still valid, but the coin-age vote only counts if the tx is on the chain it references.

This still has some problems with fork resolution and pure TAPOS requires unrealistic guarantees about network connectivity.
You can still use TAPOS for long-term security and manual hard-fork resolution, but short-term security requires a block production mechanism on top. Ripple and NXT have good ideas in this space. We learned from all those and now we are trying DPOS: http://bitshares.org/security/delegated-proof-of-stake.php

The new [font=courier]OP_COINSTAKE[/font] proposal by sigmike is a better solution than mine for cold minting in peercoin 0.5.
My proposition goal is to solve the “nothing at stake” issue, and only as a side effect and among with other changes (timestamp reference, block signatures…) it could work for cold minting. I should have open a separate thread instead of posting here :slight_smile:

I am glad to see this discussion advancing!

I like the proposal because the incentive to send the minting key to a “minting pool” is not high, as everyone can mint with almost 100% safety creating both keys offline and never publishing the “sending” private key, and the “minting pool” would not be able to accumulate coins and coin-age in single addresses. So why would you give the minting key away to a pool? The only reason I can think of is that you don’t have a computer online 24h.

There is a possibility that a cold-minting solution like this could be tested first in a peercoin fork, the Communitycoin devs seem open to discuss it.

Yes we can build that.
I was also thinking about writing the most simple software that would only be able to mint.
Both would still need the full private key though. So it’s safer but the key is still exposed somehow.

I agree we should provide tools to increase security. But there’s a large need for the safest option which is cold storage.
People with large stake won’t risk it to get 1% reward. And we need them to secure the network.

[quote=“sigmike, post:48, topic:2336”]I agree we should provide tools to increase security. But there’s a large need for the safest option which is cold storage.
People with large stake won’t risk it to get 1% reward. And we need them to secure the network.[/quote]
Maybe two parallel minting schemes:
A) 1% cold storage minting
B) variable(voting?) % hot wallet minting (also variable coindays coefficient)

People with large stake can afford to use 10 different security schemes, the probability that more than one will fail at a time is minimal, thus they risk only 10% to get 1% - quite reasonable. Probably we need to create some kind of “security wars”, an equivalent of “ASIC wars”, to create those 10 security schemes. PoW coin distribution worked great as initial distribution mechanism but I think it’s too early to shutdown printing press and sleep happily with paper wallet growing steadily. Risking and loosing coins is essential for security evolution and should be treated as natural part of distribution. To push holders to the point where they risk we need to increase incentive(or punishment - inflation) to that point, arbitrary value won’t work well so some kind of consensus is needed, voting is one of possibilities.

Security schemes created by “security wars” will also serve on other than financial fields - identity, privacy etc.

can the minted coins be accessed by the minting private key address only…is that right?

has anyone thought of having 2 keys, one private to mint and get 1%, and another key for minting on behalf which will give out smaller reward like 0.3%, in order to encourage user to solo minting while giving an option for user who wants no risk to participate.

There wouldn’t be any risk for putting coins at stake. So you can’t sell that.
The only service you could sell is to keep other people’s stake online 24/7 to keep variance at the minimum possible.[/quote]
Ok, true, I stand corrected on this one.

Yes larger scale can reduce the costs and provide cheaper service. But the difference will be very thin considering the very low cost to entry.
The point is the attractiveness of a provider is not directly related to its size. So some convergence may happen, but it’s not an inevitable consequence of the system, unlike with pools.[/quote]
I think d5000 beat me to this in this thread. There is still the cost of a computer/raspberry and the power to keep it 24/7 online. Might be minimal but not negligible.
I’m sure there will be people looking at the convience factor versus the cost + hassle.

I don’t understand how that “the bigger the better” problem surfaces again here.[/quote]
See previous item

Yes the scenario is someone gives his minting keys to many people (or even publicly) in the hope someone will mint his coins so he doesn’t have to do it. It’s safe because the reward is still sent to his address.
If he does that then many people will find a block with his stake at the same time and it will be a problem for the network. And at the end he gives minting power to the person with the best network connectivity.[/quote]
There are already some interesting solution in this thread on this one.

Thanks for taking the time to address the concerns and looking for solutions. I think it is a healthy debate as it would be a major change in the way the network operates.
The suggestion to try it out on another network is an interesting one, although I think you won’t be able to test the scale of the Peercoin network, at best observe the behaviour of major stakeholders.

I do like Romerun’s idea of having different rewards for minting with private key and with minting key. This compensates for the attractive proposition of major stakeholders all going to that very convenient, hassle-free service of that large provider with very cheap VPSs and a relatively low fee without risking their coins.

I think sigmike’s proposal is actually quite close to what I proposed for cold-locked transaction, the difference is to store the extra information needed in block chain through the multi-sig and scripts system.

If the integration with multi-sig can be done relatively cleanly with good modularity I could favor this over my earlier proposal.

There are two additional issues raised in this thread:

  1. Disclose minting key to public
  2. Centralization of minting through the use of minting service providers

I think 1 is a much more serious issue to the security of the network. If minting keys of a large portion of the participating stake are known publicly, it would compromise the security of the network.

Good work sigmike and everyone! :slight_smile:

[quote=“Sunny King, post:53, topic:2336”]I think sigmike’s proposal is actually quite close to what I proposed for cold-locked transaction, the difference is to store the extra information needed in block chain through the multi-sig and scripts system.

If the integration with multi-sig can be done relatively cleanly with good modularity I could favor this over my earlier proposal.

There are two additional issues raised in this thread:

  1. Disclose minting key to public
  2. Centralization of minting through the use of minting service providers

I think 1 is a much more serious issue to the security of the network. If minting keys of a large portion of the participating stake are known publicly, it would compromise the security of the network.

Good work sigmike and everyone! :)[/quote]

Great to see Sunny joins the discussion. I can see the potential damage 1 can have, but at least it better than disclosing the private key to public.
I will not worry too much about 2 because I can not see the need to have those so called minting service providers, since now days everyone can access to a basic computer or just a Raspberry Pi. However, it will
help to reduce issue 2 if we can make the minting process as easy as possible.

Hey Sunny, are you planning to add the cold locked minting to PPC0.5? also when are you going to release 0.5? Thanks.

Here is an alternative solution to increase the number of on-line minters by MoD:

It doesn’t introduce additional risks as mentioned above. Not sure whether it is technically feasible though. Probably needs some more thoughts. Please join the other thread for discussing increasing rewards of minters as a solution.

(Just wrote a whole story around it, but browser took it all away in some clumsy copy and cut before I could post it :grave:)

Is it possible to encrypt (with the minting key) the private key for the reward address in a message inside the block? This way everyone that knows the minting key can take/steal the reward.

Sigmike has suggested a two key system: a spending key and a minting key and they are associated together through the multisig system.

Sunny has confirmed what petar87 and others have earlier said, paraphrased, if there is a minting key then it must be held private and not be shared by the stake owner or network security will be diminished.

The core of the problem, as I see it, is: How can the Peercoin protocol know who is putting forward the minting key signed request to authorize minting the stake? Is the minting request made by the stake owner, or is it someone else?

If a minting request is made by a party who is not the stake owner then no minting should take place.

To address this issue, I offer for your criticism the following:

[size=10pt]Stake Owner Verified, Evaluated Request Network MINTING PROTOCOL[/size]

AKA

[size=15pt]The SOVERN Minting Protocol[/size]

[size=11pt]There is at least one stake Spend-Key it is a traditional private key or it may also be one private key of several multisig private keys. This stake Spend-Key easily generates a Stake-Public-Address which holds Peercoin.

There is a second private key, it is the Mint-Key. This Mint-Keyis not a multisig key and is not yet associated with the Stake-Public-Address.

The private Mint-Key generates its own public address called the Mint-Public-Address. Any Peercoin interest generated from minting with this Mint-Key will be deposited into this Mint-Public-Address (without transaction fee penalty or sufficiently greater amount to negate the fee, either way).

A special new kind of transaction called a Mint-Transaction-Request is generated (most securely offline) then put online to request participation in minting.

The Mint-Transaction-Request contains at least the public keys that are the Mint-Public-Address and the Stake-Public-Address. Crucially, the Mint-Transaction-Request contains a script signed by the Spend-Key that then was signed by the Mint-Key.

Peercoin protocol can verify in reverse order first that there is a script signed by the Mint-Key and second that this script was signed by the Spend-Key.

In this way the Peercoin protocol has determined that the Mint-Transaction-Request must have been made by the stake owner because the stake owner had to possess the Spend-Key to sign its script that was signed by the Mint-Key. If this does not check true, then no minting takes place. The network remains secure.

Essentially, for the user, this boils down to you only have to possess the Spend-Key to spend your Peercoin but you have to possess both the Mint-Key and the Spend-Key to mint your stake.

An offline computer can generate the Mint-Transaction-Request which can then be brought online for minting. Thus, the all-important private Spend-Key can remain securely offline.[/size]

Edit: 19 May 2014, For clarity made Bold the five primary elements of the proposed protocol.
1. Spend-Key
2. Stake-Public-Address
3. Mint-Key
4. Mint-Public-Address
5. Mint-Transaction-Request

Edit: 16 May 2014, A little grammar, and also the following:

I hope my inherent ignorance in being a non-coder does not glare too awfully, especially to those most in the know, for whom I have the greatest respect. That said, please, do not hesitate to tear into these ideas. That is how we will hopefully arrive at a sufficiently good solution. I hope these ideas rise to be worthy of your criticism. So, if they are worth your time - TEAR EM UP BOYS! :wink:

That said, if any idea in here could act as a successful seed to those smarter than myself, I would be most delighted.

Thank you for your review.

NewMoneyEra

Just wanted to make sure people realized NewMoneyEra submitted something above.

Yep, could someone confirms that it is feasible and that it dismisses the “Disclose minting key to public” issue Sunny has raised ?

I could then mint a bit more than my 10 PPC tip I got after setting up my Raspberry Pi full node :slight_smile:

Re-reading what NewMoneyEra wrote, it appears on the surface that he re-articulated my mint-by-proxy system.

(Private Key authorizes a Mint-Key via a special transaction before going into cold storage)

Of course I like the idea. :smiley:

[quote=“Sunny King, post:53, topic:2336”]There are two additional issues raised in this thread:

  1. Disclose minting key to public
  2. Centralization of minting through the use of minting service providers

I think 1 is a much more serious issue to the security of the network. If minting keys of a large portion of the participating stake are known publicly, it would compromise the security of the network.[/quote]

I wish I knew which post Sunny was referring to when some one said they were disclosing minting [private] keys to the public.

From my understanding, no one advocating disclosing minting keys in special transactions or other wise.

If I did, I should clarify that wasn’t the intention of my minting-by-proxy design. I simply wanted to disclose the public-minting-wallet address that was allowed to receive coins on behalf of the pre-authorized minting key pair.

  1. Public wallet address (signed by private key) going into cold storage.

  2. Your regular private key signs a special transaction which basically says:

    a) I am going in cold storage, therefore I am now creating a new minting key/pair MINTWALLET / MINTKEY

    b) I hereby authorize new public-minting-address MINTWALLET to mint coins (but not spend them) in transactions that were previously sent to mine.

  3. This new publicly disclosed public-minting-address now can mint coins and reference the special transaction in the blockchain as proof it is allowed to mint (but not spend) these coins

  4. When these coins are to be moved, the original private key comes back and says in a special transaction, “I am out of cold storage, and I am moving these coins”

This is getting complex. It is no wonder why Sunny didn’t have cold locked transactions in the early phases of Peercoin’s design. He probably thought of it, and figured, let’s just see how the network performs in its most basic form before we start getting all complex.

I’m interested in Sigmike’s response after reading what sunny wrote about Disclose minting key to public. Was that in reference to Sigmike’s solution? Or mine? Or ?

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)

[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:

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