Pages:
Author

Topic: ppcoin offline coinstake creation (Read 13886 times)

hero member
Activity: 756
Merit: 522
January 23, 2013, 06:52:39 AM
#25
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.
legendary
Activity: 1050
Merit: 1003
November 06, 2012, 05:19:02 AM
#24
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]
donator
Activity: 994
Merit: 1000
November 06, 2012, 12:43:23 AM
#23
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.
legendary
Activity: 1050
Merit: 1003
November 06, 2012, 12:10:59 AM
#22
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)
donator
Activity: 994
Merit: 1000
November 06, 2012, 12:08:07 AM
#21
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?
legendary
Activity: 1050
Merit: 1003
November 05, 2012, 11:44:48 PM
#20
Maybe we should organize a bounty for this?

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.
donator
Activity: 994
Merit: 1000
November 05, 2012, 10:20:01 PM
#19
(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?

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.
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.
legendary
Activity: 1205
Merit: 1010
November 05, 2012, 10:07:15 PM
#18
(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?

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.
donator
Activity: 994
Merit: 1000
November 05, 2012, 09:54:22 PM
#17
(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?
legendary
Activity: 1050
Merit: 1003
October 10, 2012, 09:14:29 PM
#16
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.
legendary
Activity: 1205
Merit: 1010
October 10, 2012, 09:47:03 AM
#15
Right, if we did this, how would this negate the positive effects of PoS vs a 51% attack?

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.
sr. member
Activity: 448
Merit: 250
October 10, 2012, 05:57:50 AM
#14
This was explained in the design paper, if block is not signed an attacker can reuse other blocks' coinstake in his own block.
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?

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.

Right, if we did this, how would this negate the positive effects of PoS vs a 51% attack?
legendary
Activity: 1205
Merit: 1010
October 09, 2012, 12:40:41 PM
#13
This was explained in the design paper, if block is not signed an attacker can reuse other blocks' coinstake in his own block.
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?

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.
hero member
Activity: 686
Merit: 564
October 09, 2012, 11:54:56 AM
#12
This was explained in the design paper, if block is not signed an attacker can reuse other blocks' coinstake in his own block.
Yeah, Solidcoin 2.0 made this mistake when implementing their trusted blocks.
donator
Activity: 994
Merit: 1000
October 09, 2012, 11:44:13 AM
#11
This was explained in the design paper, if block is not signed an attacker can reuse other blocks' coinstake in his own block.
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?
legendary
Activity: 1205
Merit: 1010
October 09, 2012, 08:04:31 AM
#10
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.
(bump)

This was explained in the design paper, if block is not signed an attacker can reuse other blocks' coinstake in his own block.
donator
Activity: 994
Merit: 1000
October 09, 2012, 12:23:18 AM
#9
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.
(bump)
donator
Activity: 994
Merit: 1000
October 06, 2012, 11:17:11 PM
#8
It's not just the coinstake, block needs to be signed as well.
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.

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.
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?
legendary
Activity: 1050
Merit: 1003
October 06, 2012, 10:19:31 PM
#7
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.

I think the separation of the two keys is the way to do this.
legendary
Activity: 1205
Merit: 1010
October 06, 2012, 10:15:06 PM
#6
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.
Pages:
Jump to: