ppcoin offline coinstake creation

[Jutarul]

Giving away a copy of the stake signing key has no risk for the user whatsoever, but the signing keys are valuable to an attacker. Therefore, an attacker could purchase up all the signing keys really cheap and attack the network. The attack could not be stopped. (attacker could refuse to allow anyone to include txns that revoke the sign key). This must be avoided. Offline stake creation also seems like a bad idea for similar reasons.

good point.

Stake signing should not be a risk-free process. Risk-free private keys should not exist.

Sure. But right now it's an All-in approach.

Right now the best procedure to mitigate the risk would be a round-robin style protocol for performing proof-of-stake mining:
1) Spread the available stake across 10 addresses on a secure machine (air gaped)
2) Only have one stake address active on the mining machine at any time. You can activate a stake by simply typing in the private key from a paper wallet.
3) Once you have generated stake, wait for it to be available to be spend and move it to a new target address which you generated on the air gaped system.
4) Rinse and repeat.

It's quite tedious - but a small price to pay for having a practical cold storage solution. Point 3) can be automized as a cron job IMHO. It would be a process which constantly tries to move any balance to a pre-determined list of addresses.

If a hack occurs you should be able to notice it and you will loose at maximum the current stake, since once you have moved the matured stake to a new address, the attacker has missed the opportunity.

A better solution is to make two keys: one high-functionality high-risk key, one low-functionality low-risk key.

a) The high risk key can do anything. The high risk key can also move all the coins at once, invalidating the low risk key.

b) The low risk private key can spend 0.1% of its balance per block. Enforce this as follows. Every txn signed by the low risk key must send at least 1000 coins to its own public key address for every 1 coin sent to another address or used as a txn fee. The low risk key can also provide proof-of-stake. This key can then be depleted at a maximum rate of 1% per day. You can expose this key to the network. You might share it with a well-trusted party. You shouldn't share this key with an anonymous individual however.  

I think high-risk should be avoided at all cost. A reasonable secure system always requires physical access to do significant damage. And for protecting the system from physical access, you can employ more traditional means.

Each wallet should list two types of balances: Spending and saving

1) Savings wallets are unencytped. Savings wallets have low risk private keys online and unencrypted and high risk private keys in cold storage. Savings wallets try to provide PoS.

2) Spending wallets are encrypted. They should have both the low risk private key and the high risk private key online. These wallets cannot provide PoS because they are encrypted.

Users can shift coins back and forth as needed (i.e. if the low risk savings key gets stolen, they only lose 1% per day until they rescue it and nothing after that.)

I don't understand how you would implement high-risk and low-risk keys. That would require a hard-fork, correct?

[cunicula]

I don't understand how you would implement high-risk and low-risk keys. That would require a hard-fork, correct?

Yes, so?

It is a useful innovation. It doesn't exist in bitcoin. Bitcoin can't copy it because it is too big to be flexible.
Do you think PPCoin will take off right now without some more added value?

The PoS component may only become immediately useful in 10 or more years from now. People are too short sighted. You need to do stuff that people perceive to be valuable right now.
 
As long as a hard fork makes everyone better off it is best to make it happen. Especially while the coin is still young and upgrading is a manageable problem (e.g. 2 pools, 1 exchange, large handful of users)

[Jutarul]

A better solution is to make two keys: one high-functionality high-risk key, one low-functionality low-risk key.

a) The high risk key can do anything. The high risk key can also move all the coins at once, invalidating the low risk key.

b) The low risk private key can spend 0.01% of its balance per block. Enforce this as follows. Every txn signed by the low risk key must send at least 10000 satoshis to its own public key address for every 1 satoshi sent to another address or used as a txn fee. [this is a block validity rule; txns that don't obey this cannot be included in blocks] This key can then be depleted at a maximum rate of about 1.5% per day.The low risk key can also provide proof-of-stake.  You can expose this key to the network at low risk. You might share it with a well-trusted party. You wouldn't share this key with an anonymous individual however. 

As far as I understand this still doesn't mitigate the problem of an attacker getting access to all the stake mining power at once. E.g. the procedure I proposed above mitigates both risks at once. However, user interaction is required.

I don't understand how you would implement high-risk and low-risk keys. That would require a hard-fork, correct?

Yes, so?

It is a useful innovation. It doesn't exist in bitcoin. Bitcoin can't copy it because it is too big to be flexible.
Do you think PPCoin will take off right now without some more added value?

The PoS component may only become immediately useful in 10 or more years from now. People are too short sighted. You need to do stuff that people perceive to be valuable right now.
 
As long as a hard fork makes everyone better off it is best to make it happen. Especially while the coin is still young and upgrading is a manageable problem (e.g. 2 pools, 1 exchange, large handful of users)

No problem with that. Just wanted to make clear that this change would result in a change of the client behavior.

[cunicula]

As far as I understand this still doesn't mitigate the problem of an attacker getting access to all the stake mining power at once. E.g. the procedure I proposed above mitigates both risks at once. However, user interaction is required.

You can always use your procedure. I am not saying it is bad, just inconvenient for many users. It is good to keep options open, while allowing for alternatives that are potentially more convenient.

Ideally, I would like to kill two birds with one stone.

1st bird: leaving keys completely exposed to sign blocks is too risky.

2nd bird: (unrelated to proof of stake) Keeping your money in a hot wallet is too risky. Keeping your money in a cold wallet is too inconvenient. Constantly rebalancing between your hot wallet and your cold wallet is also too inconvenient. Ideally, one wallet should be able to perform both hot and cold functions.

My idea for the stake key was bad because it wasn't useful as a hot wallet. 0.01% is too small to be usefully spent in most cases. Here is a new idea.

Suppose that 5% loss is an acceptable risk level for a one-off theft of the stake key.

How about the following txn rule for the stake key:
Amount Returned in Change to Public Key >= all coins sent to other addresses * { max (k, k*(t/accumulated coin-age on public key) }

k and t are positive constants. Coin age is measured in years. So if k=19 and t=1/12 (i.e. one month), ...

You can spend up to 5% of the a mature balance immediately and then about 0.001% per block afterwards. Theft loss is limited at close to 5%.

I think 5% will often allow you to use the key as a mixed hot/cold wallet.

Another nice thing is that the risk is self-limiting. 5% is fine for small balances but likely too much for large balances.
If you have a huge balance and mine PoS blocks less than once a month your risk will be less than 5%. Thus keeping a large balance online all the time is less risky. Bringing it online occasionally is more risky. This is very good for network security.

(e.g. if you mine PoS blocks once per day then your theft risk will be limited to about 0.166%; if you have the same balance and mine once per month, your theft risk increases to 5%.)  

It would be nice if the parameters k and t could be user-specified (e.g. listed in the public key address (e.g. PCpzxSXGBLVuLEr2EAyxEnQH1QYvUKN9kuinsert k and t here)
They would have to have some minimum values to prevent stake signers from protecting themselves from too much risk. (i.e. if k>19 or t>1/12 then the key can't be used to sign for PoS)
Such a key could still be useful as a hot wallet though.

If you were running a business then you would want a very low value for t. That would allow your spending capabilities to recharge quickly, but keep your ability to spend per day limited.

[Edit: Fixed some algebraic errors]

[MPOE-PR]

As far as I understand this still doesn't mitigate the problem of an attacker getting access to all the stake mining power at once. E.g. the procedure I proposed above mitigates both risks at once. However, user interaction is required.

You can always use your procedure. I am not saying it is bad, just inconvenient for many users. It is good to keep options open, while allowing for alternatives that are potentially more convenient.

Ideally, I would like to kill two birds with one stone.

1st bird: leaving keys completely exposed to sign blocks is too risky.

2nd bird: (unrelated to proof of stake) Keeping your money in a hot wallet is too risky. Keeping your money in a cold wallet is too inconvenient. Constantly rebalancing between your hot wallet and your cold wallet is also too inconvenient. Ideally, one wallet should be able to perform both hot and cold functions.

My idea for the stake key was bad because it wasn't useful as a hot wallet. 0.01% is too small to be usefully spent in most cases. Here is a new idea.

Suppose that 5% loss is an acceptable risk level for a one-off theft of the stake key.

How about the following txn rule for the stake key:
Amount Returned in Change to Public Key >= all coins sent to other addresses * { max (k, k*(t/accumulated coin-age on public key) }

k and t are positive constants. Coin age is measured in years. So if k=19 and t=1/12 (i.e. one month), ...

You can spend up to 5% of the a mature balance immediately and then about 0.001% per block afterwards. Theft loss is limited at close to 5%.

I think 5% will often allow you to use the key as a mixed hot/cold wallet.

Another nice thing is that the risk is self-limiting. 5% is fine for small balances but likely too much for large balances.
If you have a huge balance and mine PoS blocks less than once a month your risk will be less than 5%. Thus keeping a large balance online all the time is less risky. Bringing it online occasionally is more risky. This is very good for network security.

(e.g. if you mine PoS blocks once per day then your theft risk will be limited to about 0.166%; if you have the same balance and mine once per month, your theft risk increases to 5%.)  

It would be nice if the parameters k and t could be user-specified (e.g. listed in the public key address (e.g. PCpzxSXGBLVuLEr2EAyxEnQH1QYvUKN9kuinsert k and t here)
They would have to have some minimum values to prevent stake signers from protecting themselves from too much risk. (i.e. if k>19 or t>1/12 then the key can't be used to sign for PoS)
Such a key could still be useful as a hot wallet though.

If you were running a business then you would want a very low value for t. That would allow your spending capabilities to recharge quickly, but keep your ability to spend per day limited.

[Edit: Fixed some algebraic errors]

I fail to see what benefits this offers. Someone deposits 5k BTC to buy MPOE bonds. 100% of the 5k should be locked somewhere until the next (last Friday of a month). At that point up to 100% of the 5k should be available, in case the person wants to cash in. Your proposed system serves neither of these, paper wallets do.