Securing the SolarCoin Generator Pool is a top priority of the SolarCoin Foundation for 2016The SolarCoin Foundation would like to present the following Generator Pool Security Framework to the community for comment.
Please refer to the following Security Engineering book as a reference:
http://www.cl.cam.ac.uk/~rja14/book.htmlSome common wallet security practices for crypto-currencies are:
-Cold Storage of wallets (currently implemented for the generator pool)
-Small amount of coin available for issuance at any one point in time (reduce risk by shrinking the size of the target)
-Multi-signature authentication (m of n) from separate resources to access wallets
-Proactive security of posting 100% collateral to access wallets
Generator Pool Security ExamplesSLR Drip 1
- 97.5 B SLR in generator pool is replaced with a 97.5B notional algorithm that “drips” a set amount (X) of SLR to a granting wallet (s) and replenishes it based on granting activity.
- Access to granting wallet requires multi signature authentication from separate sources
- Proactive security measure of posting a high SLR collateral amount to have access to the granting wallet
- The SLR posted collateral to access the granting wallet will be forfeited back to the generator pool if certain predefined activities are not met.
SLR Drip 2
- Same as SLR Drip 1
- 97.5 B SLR in generator pool is transformed in a smart contract to have a waterfall transfer that “drips” a set amount (X) of SLR to a granting wallet (s) and replenishes it based on granting activity.
Please provide feedback on this important security requirement.
Regards,
The SolarCoin Foundation
--------------------------------------------------------------------
Generator Pool Security FrameworkGoals Static
-Non-stop Function (high availability)
-No single actor or point of failure can limit global granting
-Ease of repeated use
-Transparency whenever possible
-Security for at least 40 years
-Fail safe (failure has limited repercussions)
Dynamic
-Future group proof (expanding and rolling control) oversight
-Ability to "reset" system in extreme without hardfork? i.e. transfer all coins to new secure account hardwired with new "secure" system.
-40 year design
-Trusted Control either by people/and machine
-Increasingly "distributed de-centralized " control
Constraint Dimension Static
-Limit outbound flow to 1MWh = 1SLR parity or claimed parity
-Must by consensus community acceptable in terms of "control" and over-rides
-Genesis pool must not be greater than 5% of circulating SLR
-Simple solutions preferred over Complex solutions
Dynamic
-Don't know future location(s) of future lock control of wallets and keys
-Not sure about future wallet technology
-Don’t know future demand
-Don't know future users or "owners" of pool, keys, locks
Ideal end functioning state -Fully decentralized granting
-Automatic granting of verified claims
-No non-verified transactions
-Impervious to external probes / attacks
-Fully transparent security (decentralized nature of ownership)
Failure points/modes Wallet(s) lock holder(s)
Wallet publication
Human compromised (black mail etc.)
actors who want to shut it down economically (macro actors likely TAX/regulate out of existence)
Geo political Threat
-Explicit seizure
-"wealth" taxation
-technical blocking IP
-Wallet Seizure
-key seizure
Wallet loss
Obsolete security (technology overwhelms it Quantum crypto etc.)
-Cracking technology improves
Disburse account (send from) account
Key(s)
-Key theft
-Key publication
-Key loss
-Death of holder/loss
Requestors claimant(affiliate/sub affiliates)
-Community
-Community Suicide "Scarcity gone wild" (kill the generator pool)
-Community Suicide "claims gone wild" (hyper inflation)
-lost wallets
-lost keys
SolarCoin transactions
-Community
-disagrees with grant
-Coin Theft
-Device weaknesses
-IP snooping
-inbuilt wallet weakness BIP100
-Server weakness
-man in the middle type attacks
-Confirmation requirements
SLR Request for claim payment
SolarCoin Blockchain
-Hardfork
-spam/spim
-hackers (halt of inhibit for fun)
SolarCoin blockchain explorer
-Message spoofing
Key Holder(s)
-Blackmail coercion legal tax
-lost keys
-publication of keys
-hack (known)
-hacked unknown
-key transfer
-key distribution
Failure scenarios
-Each element should have a failure scenario (stops functions) what it over-ride protocol and worst failure event.