Executive Summary:

Theta Labs should implement, at the base protocol layer of the blockchain, the ability to lock a resource with a predetermined release address. This will place resources out-of-reach for the general hacker. Implementing such a functionality will immediately raise the bar for how assets are secured in the industry.

Situation: 

The complexity of blockchain technology and the trusting gullibility of humans has created a windfall of illicit profits for hackers and scammers as they target access to people’s wallets. If a hacker gets access to a wallet, the current security protocols allow them access to all that wallet’s resources. These protocols are built around the principle – ‘not your keys, not your coins,’ yet it doesn’t provide protection if two people own the private keys at the same time.  

This proposal suggests a mitigation strategy that can help build more confidence for users of the Theta Blockchain by explicitly protecting resources before an attack. 

Consider: 

The staking functionality, as implemented on the Theta blockchain, introduces a new ‘locked’ state to the resources owned by the wallet. The resources are owned by the wallet but unable to be used. In order for those resources to be available for use, they must first be withdrawn and complete their ‘pending release’ timeout. 

The ‘locked’ state of the resource is what is important here. 

The complication is that anyone with access to the wallet can just unlock a resource and have their way with it. The first thing that the bad actor will do is transfer the resource to a wallet where only they own the private key. 

Mitigation: 

The core network code should provide a ‘locked resource’ functionality that mirrors staking, but has one key difference: It has a pre-registered ‘transfer to’ address that will receive the unlocked resources. This effectively means that after the pending period but before the coins are ‘returned’ to the owning wallet, they are transferred to the unlock address.  

By allowing this type of functionality if the owning account’s private keys are compromised, the hacker only has access to the non-locked resources of the wallet.  

This same protection can be extended to staked coins/tokens by simply requiring a ‘transfer to’ address when or before the coins are staked.  

Note that if a resource is locked, the ‘transfer too’ address cannot be changed, this prevents a bad actor from rerouting resources after a hack. 

By providing functionality like this, it would be a fiduciary duty to all entities on the network that manage funds for other people to lock some reasonable amount of the resources so that they are out of reach from this common type of security vulnerability. 

Extension:

If this type of functionality is available to the network, it would be logical to apply this towards other unique resources held in a wallet. In the wallet, rather than ‘wrapping’ or ‘staking’ they would ‘lock’ that resource. When in this state, wallet utilities should be able to see the resource, but a send operation would fail. And, again, the unlock operation would result in the predetermined send operation to the backup wallet.

This functionality may be extended to a smart contract and should also be considered for TNT-20 tokens. Specifically in light of the fact that MetaChain subsystems will also need to hold collateral for longer periods of time and any large treasury becomes a de facto target.

Comments from Discord:

The following are some comments from discord after the above idea was presented. The quotes are from discord, my comments are not.

“Certainly interesting. One side effect of this (if extended to staked tokens) would also be that staked tokens would be viewed as safer, possibly increasing the likelihood of one staking their tokens, therefore assisting in securing network.”

• Actually, any locked resource.

“So the general idea is to add a second address while staking so that if the first address is compromised you can change the recipient of the tokens to the second address?”

• The ‘release too’ address must be pre-registered.

“If this is possible it would really help many rest easier.”

• Agreed.

“Liking the lockupabble (sp or is it even a word?) idea. Also, I think there are practices that I see encouraged in other projects including. Guidance for how many and for what purposes you should use multiple wallets. Multi-sig wallets(even 1 of 2 can be useful for couples). Always create a new address whenever receiving tokens. Only transacting against a node in your local network(no exposing your addresses and activity to 3rd parties). Using VPN to obfuscate your IP when interacting with wallets and explorers. Using multi-party transactions of equal value to obfuscate which tokens belong to who. The list goes on… Point being, we as a community need to take on a broader responsibility to educate new and old to the potentials of things going wrong and how to mitigate them and their effects.”

• “That’s it! The value. This goes back to the segment I mentioned about the front end. How do we unlock that value besides just the red lettering. Example would be a video, maybe earn 1 or 2 tfuel for watching it. Incentivize them to watch the short security clip (ironic we’re dealing with Theta). To end the claim, I also believe there is more to be desired in that particular area as well.”
• Incentivized learning is cool here too!