I happen to read some posts with similar ideas to resolve similar questions from PPC community, they might be helpful to the topic, honor belongs to @clar

Just quote and add the link here, still not fully understand them though.

https://bitcointalk.org/index.php?topic=115608.msg1319290#msg1319290

Quote from: Jutarul on November 06, 2012, 03:20:01 AM
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.

-----------------------
https://bitcointalk.org/index.php?topic=194054.0

Abstract: A proposal to relieve stake minter the risk of running online hot wallet.

Description: This proposal is simpler than the previous dual-key proposal [1]. A special transaction type called cold-locked transaction is introduced so that a designated spending address is specified in its first output. Protocol enforces that, spending of any of the outputs in the transaction must be sent to this designated address, or to itself (for stake generation purpose). When stake is generated, the stake transaction is also cold-locked and the designated key in stake must match all designated keys where all the inputs come from.

How hot wallet is protected:

By providing a cold-wallet address as the designated spending address in cold-locked transactions, stake minter can now run their entire balance online in a hot wallet to earn 1% annual interest with minimum risk, while providing maximum security to the entire network. This would allow even the exchanges, pools, and other online wallet providers to participate in network protection without risking public assets, and reduce fees or even pay interest to its users.

For public review and discussion.

References:
[1] https://bitcointalk.org/index.php?topic=115608.0

Quote from: HackFisher on December 08, 2013, 02:34:08 am

Good idea! 

I think this idea may also apply to prove of stake, we may use a subkey for the purpose of verifying the owner of stake, this subkey is for this purpose only, cannot do transactions, so we can keep mainkey offline and safe.

Sent from my GT-N7100 using Tapatalk

I don't quite sure if this is technically possible. Sounds nice idea, too!

Further more, I think we could extend this idea of mainkey-subkey to a more common model/service, used to integrate different DAC services, it can separate the risk of lost private key, increase the dynamic flexibility of Keyhotee because key relationship are stored/broadcast through blockchain.

For Keyhotee, I don't know finally how will it be implemented technically. But I think it would be very interesting if not just simple using a subkey for some purpose(e.g. send emails). How about using tag for a subkey, the tag represent some DAC service(e.g. Integrate bitcoin wallet to send BTCs), we may not want to share one key for both email and btc wallet.

We can even import the wallet key of Bitcoin as a subkey of Keyhotee, just binding to some tag and the main key, in that way, we can implement great features like direct send someone BTC just need to know his Keyhotee ID(if he has a bitcoin tag binded), and SSO, keep his btc wallet dat private. This is implemented by query his Bitcoin address by query the subkey bind to "Bitcoin" Tag of Keyhotee ID, balabala...... I can imagine more cases like this, I saw a snapshot of Keyhotee wallet, there seems already have similar feature, I have no idea whether they are implemented this way, maybe its time to views the source codes.

Willing to know more details about this, I have more interest in Keyhotee now,  for its potential to guard the privacy and ability to integrate DACs as ID management.

Quote from: bytemaster on December 06, 2013, 05:46:32 am

Keyhotee asks you for your password when you start the program and will keep your private key in memory only.  On disk it is always encrypted.

In order to process incoming messages your private key needs to be 'live' at all times.  There is no way around that. 

With the wallet system you only need your private key for sending money.

Bottom line, you are relying on the physical security of your computer and OS while Keyhotee is open.    Any bright ideas on how to improve that?

I really want to store the private key offline.
How about this way.

We use 2 private key,mainkey and subkey,with different power(or we can say:usage).
They work like this.

1,I generate a mainkey on an offline PC,then I use it to register my kehotee ID.
mainkey<->kehotee ID

2,I generate a subkey and sign this information(subkey's publickey + "active subkey") with my mainkey on offline pc.
then I broadcast this info to p2pnet.I use subkey to login,decrypt, signature and etc.
mainkey->active subkey
subkey->login
subkey->send mail
subkey->read mail
subkey->delete my mail from p2pnet

3,If my subkey was lost or leaked,I can sign information(subkey's publickey + "destroy subkey") with my mainkey
and  broadcast it to p2pnet.Attacker maybe already see my history mail,but he cannot do anything more
when I destroyed my old subkey and active a new subkey.
Most important thing is,I don't have to destroy my kehotee ID,Specifically my founder ID.And Attacker cannot
destroy my kehotee ID with only subkey too.

mainkey->destroy subkey
mainkey->destroy ID

4,My keyhotee ID is totally safe now.
We can make more function with mainkey and subkey.

:-)

Good idea! 

I think this idea may also apply to prove of stake, we may use a subkey for the purpose of verifying the owner of stake, this subkey is for this purpose only, cannot do transactions, so we can keep mainkey offline and safe.

Sent from my GT-N7100 using Tapatalk

Quote from: HackFisher on December 06, 2013, 06:03:38 am

Is the password some fixed password using md5 stored on disk like Linux OS, or some Encrypt Interface could be customized by users?

I think it may be possible to add 2-factor auth if there is such encrypt interface, ex. using SMS or Google Authenticator. I still have no idea whether it is meaningless to do this.

For the bottom line and OS level, I know there are a lot of software with root/administrator authority to the OS, can hook to api call, and capture datas, including some anti-virus softwares. I don't whether we could to do something to avoid this?

Quote from: bytemaster on December 06, 2013, 05:46:32 am

Keyhotee asks you for your password when you start the program and will keep your private key in memory only.  On disk it is always encrypted.

In order to process incoming messages your private key needs to be 'live' at all times.  There is no way around that. 

With the wallet system you only need your private key for sending money.

Bottom line, you are relying on the physical security of your computer and OS while Keyhotee is open.    Any bright ideas on how to improve that?

Authentication and Encryption are two different things.  Authentication such as google authenticator can answer a 'yes' | 'no' question but does not protect a private key.  So we could add Google Authenticator at launch but an attacker who got a copy of the wallet on your disk would still be searching for the password/key that is protecting it.

OK, I got it, thanks.

Is the password some fixed password using md5 stored on disk like Linux OS, or some Encrypt Interface could be customized by users?

I think it may be possible to add 2-factor auth if there is such encrypt interface, ex. using SMS or Google Authenticator. I still have no idea whether it is meaningless to do this.

For the bottom line and OS level, I know there are a lot of software with root/administrator authority to the OS, can hook to api call, and capture datas, including some anti-virus softwares. I don't whether we could to do something to avoid this?

Keyhotee asks you for your password when you start the program and will keep your private key in memory only.  On disk it is always encrypted.

In order to process incoming messages your private key needs to be 'live' at all times.  There is no way around that. 

With the wallet system you only need your private key for sending money.

Bottom line, you are relying on the physical security of your computer and OS while Keyhotee is open.    Any bright ideas on how to improve that?

I was not able to connnect forum via Tapatalk too, but I try to delete the forum and add again, and re-login, it's ok now.

Ok, to support, I just grant a trust of 2PTS to you, It seems that there still no records on order book.

For a good start, I just order a Bid for 100XRP/PTS, good luck.