Just confirming, for PODC UTXO Reward Chart (Staking),
where you need 50,000 BBP in a wallet to receive 100% rewards from PODC
Chart here: http://wiki.biblepay.org/index.php?title=Distributed_Computing#Proof-of-Distributed-Computing
The coins have to be in an unlocked wallet? (specifically the wallet that has the CPID/Burn with 1 mining thread running)
Thats not toooo bad, just a little extra work to secure your coins,
could just use another PC or $5/month cloud machine and periodically send rewards to your main encrypted wallet.
Yes, correct, the issue is in order to exercise ones UTXOWeight, the core must be able to "stake" up to 50K in a coinstake, at least once per day to associate its tasks with its UTXO coins. So of course that means if the wallet is encrypted and locked, the core cant create a coinstake, and cant sign CPIDs either.
So let me cover the most Dangerous aspect of this so you can get a feel for the attack vectors:
Lets pretend you have 6.5 MILLION BBP, and 4 cold sanctuaries and you want to stake from the controller wallet on your home PC.
So you encrypted and locked the home wallet.
Now you unlock the wallet with a passphrase for 9999 seconds so that PODC update can work.
The attack vectors are:
- Physical security - an intruder - a Wife, Husband, Sister, Brother, Or physical break in gains access to the machine and Sends coins out of the machine while the machine is unlocked
- Firewall security - a hacker breaches the firewall, compromises the password of the RPC port - and sends coins out with an RPC command
- Compromised Machine - Virus - A virus or botnet compromises the machine, and sends coins out of the running wallet - This type of attack could also copy the entire wallet.dat off the machine
- Fradulent Software Copy - A Very advanced virus, designed to mutate memory, is embedded on the machine altering the running state of the code - forcing the wallet to send out BBP
- Fraudulent Memory Reader - A Very advanced virus, copies the running memory of the machine and attempts to scan it for private keys in memory
As you can see with these attack vectors, a locked wallet would have prevented : Physical security, Firewall Security, Compromised Machine, Fraudulent Software and Fraudulent Memory Reader. A locked for Staking wallet would prevent: physical security, firewall, compromised machine, but possibly would fail on the last two.
I ended up going with a feature that pops up when the user boots - asking for their wallet password (if they desire) and can be disabled with a config setting. It stores the wallet password in a SecureString in memory (thats sort of like a non readable encrypted string that prevents reading the string from memory since it is not clear text), then when the wallet needs to Sign a CPID OR send a PODCUpdate, If that string is populated with a value, it unlocks the wallet, does the operation then locks the wallet again.
So this is as strong as I can make it with as much convenience as I can imagine, then for those who do not wish to break up the controller wallet into two pieces can still feel relatively at ease as long as they are running the binary. In my case myself Ill probably use it, for my sanctuary set up on my home windows wallet, since I still need the ability to easily vote with the locked funds, maintain my start-stop of my sancs, its of higher security for me to keep that wallet available at home than on any rented VPS service.
But yes if you sent the 50K out to a VPS, you would need your CPID rewards to go to that VPS, and then you could leave the wallet unencrypted/unlocked in the VPS.