There has been quite some talk about Safecoin and divisibility over the last few years. In this topic I will show a simple idea based on posts by @neo (not public yet) and @dirvine on giving nodes a “credit” to PUT data to the network after they burn 1 Safecoin. I’ll use this mechanism as the basis of divisible Safecoins. I know through some other channels that several members here are thinking about this problem as well so I hope to trigger them to come forward with all ideas ;-).
What’s the problem?
We have around 4.3 billion Safecoins available in the network and each coin has it’s own responsible group for that address. A coin could be “owned” by a node or not. Which means Safecoin addresses can have 2 states:
- Not owned
The divisibility problem shows up when we want to send 0.33 Safecoin to another address. How do we split a coin? At first we need to understand how a transaction takes place.
We have 3 parties involved in 1 single Safecoin transaction:
- The Wallet owner > has the private key to prove ownership of a safecoin address
- The Client_managers > these are the close nodes for the wallet owner.
- The group responsible for the Safecoins address > disjoint group responsible for the address,
A 1 Safecoin transaction looks like this:
Wallet owner wants to spend Safecoin > Client_managers check with responsible group to see if the address is indeed owned by the wallet owner > if true they group_sign a message to the responsible disjoint group to change ownership of the address > wallet owner is no longer the owner of the coin.
This is all solid and could be implemented quite easily if I understand several devs. But how do we make Safecoins divisible without losing security? And how do we keep it fast? and how do we make sure we never pass the limit of the 4.3 billion coins?
I would like to propose an extra state for a Safecoin address. This state is controlled by the disjoint group responsible for the address. That’s the same as for the 2 other states.
Extra state for a safecoin address
- Not Owned
How and why would we freeze an address? The idea is quite simple. We introduce “credit” for a wallet owner. And this credit is controlled by the close nodes (client_managers) of that wallet owner. As we want to respect the maximum 4.3 billions limit, we can’t add “credit” to someone’s wallet without freezing or “burning” a Safecoin. We could add 1 Safecoin of “credit” to a wallet address after the owner burned a Safecoin. But the problem is, the Safecoin address could be farmed again while the credit isn’t spent at all. This would violate the 4.3 billion limit. And even if we burn the Safecoin address after all “credit is spent”, we still violate the 4.3 billion limit. That’s why we need a “Frozen” state to get around this problem. But no worry, this creates a new problem as well . But let’s see how it works so far with 3 possible states for Safecoin.
Move a small amount of Safecoin around.
We own 1 Safecoin in our wallet and want to move 0.33 Safecoin to another wallet:
We send a split_request to our client_managers > they forward that to the disjoint group responsible for the Safecoin address > if I indeed own that address they “freeze” the Safecoin and allow the client_managers to credit me 1 Safecoin as “credit”. I ask my client_managers to move 0.33 Safecoin (credit) to the client_managers of the destination wallet.
So instead of 3 parties involved we now have only 2 parties involved (wallet owner and his client_managers). It could make transactions quite fast and allows for a combination with the “normal” transactions. So moving 6.33 Safecoin to an address only needs 1 “splitted” Safecoin controlled by the client_managers.
There’s only one question we need to answer: What happens to the frozen Safecoin address? It can’t be farmed as it is frozen, and it can’t be spend as it’s frozen. How can we get rid of this state? We need to remove “credit” somewhere before we can un-freeze it. The word somewhere could be taken quite literally.
Send a merge_request for the Safecoin
If we can split a Safecoin to credit, we could also merge one. The idea is again quite simple:
The nodes sends a merge_request for the frozen Safecoin and the client_managers remove 1 Safecoin of credit. The disjoint group responsible for the address un-freezes the Safecoin and all is well.
This way the 4.3 billion Safecoin limit is respected and client_managers can hop “credit” around to other client_managers like it’s nothing. We could add as much digits as we want as this is no problem for the client_managers whatsoever. Want 0.000000000000000000000001 Safecoin? No problem, a node will split a Safecoin and it’s coming your way immediately.
Still some problems to solve
- What if I never splitted a coin, and I got 5 Safecoin as tips for my weblog? This is all “credit” and I can’t merge these coins as I don’t own a frozen Safecoin address. The answer to this one is: just use the “credit” instead of full Safecoins. For you and your wallet it doesn’t matter.
- What if millions of Safecoins are frozen and used as “credit”. This will prevent farmers from farming that address? This is correct but not very different from me owning normal Safecoins. If I own 6 "normal’ Safecoin these can’t be farmed either. Not different if it were 6 splitted safecoins.
- How does this work for multi-sig? Ohw, you got me there. I haven’t really thought about this one.
- How does this work for Vaults? Good question, not really though about this one either.
- Isn’t this less safe? You need to really trust the client_managers? Yes, this is correct. We might want to add another close group for extra security to always have 3 parties involved in any transaction.
So here it is, a simple idea where client_managers hold “credit” for clients after they split a Safecoin. The Safecoin get’s frozen and could be merged back as credit is destroyed. Notice this credit could come from other Safecoins as well. If I split a coin and spend my “credit” to 200 different nodes, it could take some time before “credit” from other splitted coins gets in my wallet for a merge. But the network doesn’t really care which credit is merged where. It only cares about the 4.3 billion Safecoin limit not being violated.
I probably missed several other problems as well, so feel free to shoot at this one .
EDIT: If we use the disjoint group instead of the client_managers for keeping the “credit balance” this could work for Vaults as well. It removes the need to connect a wallet to a client.