Topic: ppcoin offline coinstake creation (Read 13879 times)

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.

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]

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.

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

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)

good point.

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.


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.

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

I think you need to consider this 'feature' more carefully before raising a bounty. It may be a serious 'bug' if implemented poorly.

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.

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

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.  

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 optionally encrypted. They should have both the low risk private key and the high risk private key online. These wallets cannot provide PoS if they are encrypted.

Users can shift coins back and forth as needed. This is a good improvement for three reasons.

1) It makes stake provision safer

2) It makes the currency safer to use in general (i.e. now it would be like you can call the credit company and report your private key stolen. Think how many unlucky bitcoin users have wanted to do this at some point.)

3) Convenience is maintained because the spending wallet still provides the traditional functionality.

I'd gladly contribute to this development. However, my schedule is packed with other stuff right now, so I don't see myself working on this issue before December.

Maybe we should organize a bounty for this? I'd be willing to pledge a few PPC for a decent proposal, which provides the basic feature of key-mining separation. Even a work-around would be acceptable. Target for the bounty should be $500-$1000? Condition is that the person provides the necessary instructions and/or code to implement the feature and that the proposal actually works as intended.

Not recently. For me I probably would revisit this topic after new year. If some of you are good with bitcoin tx scripts and various advanced transactions feel free to make some proposals as to how stake key can be managed separately from spend key.

(bump)

Has there been any development in the direction of a more secure way to generate proof-of-stake blocks, i.e. remove private keys for stake from the mining computer?

I don't see any downside to temporary key separation either. Just make sure it isn't permanent. The stake key should be "refreshed" whenever the send key is used. You don't want people to be able to sell their stake keys to others.

There shouldn't be any negative effect on proof-of-stake. Users would have the additional option to leave only the stake key online and move all other private keys to a cold-storage wallet. This would greatly reduce the risk of losing coins to hackers thus encourage more users to participate in stake generation. So it should help strengthen proof-of-stake.

Although this is just an idea at the moment and lot of work is probably needed to come up with a concrete design proposal, including maybe a full review of bitcoin's scripting engine which I haven't done before.

Right, if we did this, how would this negate the positive effects of PoS vs a 51% attack?

The signing key must belong to the stake owner. If in the future a separation of spending key and stake key can be implemented then block can be signed by stake owner's stake key.

Yeah, Solidcoin 2.0 made this mistake when implementing their trusted blocks.

I see. Even though the attacker would not get the benefit of the POS reward, he could utilize it as mining power. Is there a reason why the key for the coinstake transaction has to be the same as the key for block signing?

This was explained in the design paper, if block is not signed an attacker can reuse other blocks' coinstake in his own block.

(bump)

I didn't notice that. That certainly complicates things.
Sorry for my ignorance - where does this block signing take place? All I see is a SignSignature of the coinstake transaction under CreateCoinStake(...). Found it: key.Sign(GetHash(), vchBlockSig);

Would you be so kind to explain why the block needs to be signed as well? It seems to be a feature of ppcoin, because I don't see it in bitcoin.

That sounds like a good idea. That transaction type would be interesting for more than one reasons. The way I understand it, it's a restrictive branch-transaction type, where the choice of the key determines which PPC address gets the coins. (The only risk I see there is that an entity can steal "stake-mining power" and the owner may not be easily aware of that. The simple solution would be to move the coins to a new PPC address once in a while.)
However, as far as I understand the scrypting framework, the scriptPubKey only unlocks the coins. It cannot control the downstream coin flow. Thus it's not simply a new transaction type. It would have to be hardcoded into the client behavior. Am I wrong?

I think the separation of the two keys is the way to do this.

It's not just the coinstake, block needs to be signed as well.

One possibility is that some special transaction type can be introduced and there will be a separation of spending key and stake key. Stake key can only 'refresh' the coin by moving the coin to the same address (spending key). So stake key is online to mint block and spending key is in cold storage.