Idea for divisible Safecoins

Autonomi Network Token (incl (e)MAID)
1

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
  • 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.

Who’s involved?
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
  • Owned
  • Frozen

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 :stuck_out_tongue:. 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 :kissing_smiling_eyes:.

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.

23 Likes
2

Great minds think alike :slight_smile:

7 Likes
3

Yes I did read others work as well ;-).

5 Likes
4

Lol yeah @neo was on my mind when I was reading this. Did he release his notes yet?

5

Nope, but I read it again and indeed that was what me got thinking about it. I mention @neo in the OP now as well as it’s quite close to each other (sorry, should’ve done before :nerd:). The difference is in the client_managers and how they handle the “credit” part. It’s also close to David’s “burn to PUT” idea where you can buy low (burn a coin when the price is low) and use later on, if I understand correct:

This idea might violate the 4.3 billion Safecoin limit when it’s done with “cash”. For data not really a problem I think. Could be quite smart actually.

1 Like
6

But It’s not gonna be a solution for the divisibility of the coin. The coin still won’t be divisible, right? Or am I missing something?

/edit oh now I see, you mean it’s a good solution for storage, but won’t work for coins, right?

7

No the real coins can’t be split. But do they need to? Think of it as a piece of gold. You put it in a safe somewhere and trade IOU’s which give people the right to obtain the real gold if they have 1 unit gold of IOU’s. So in this case, if you have 1 Safecoin “credit” somewhere you could trade it for the “real” Safecoin as it becomes un-frozen and owned by you. And because on SAFE everything is protected with encryption and ownership is signed over by groups it’s almost impossible to fool this system. The coins in the form of “credit” work like the balance in your real bank account. The real Safecoins work more like gold.

The idea to buy “storage space” by burning a Safecoin works great for data. But if you implement it with Safecoin you shouldn’t burn a coin to get credit. You need extra protection in the form of freezing a coin.

5 Likes
8

Yeah, I get that. I was confused with the data thingy, nvm. I think your Idea is pretty interesting! I haven’t had much time to think about it yet, but I also didn’t find a flaw so far. But I assume theres more to think about than I a aware of right now. Great revival of the topic, it’s a very important one for me.

1 Like
9

If I only have 1 safecoin and need to send .01 safecoin I end up with a frozen .99 safecoin? Is my safecoin address frozen and I’m given a credit of .99?

Does the credit link back to the original - now frozen - address? What if that credit is partially spent again? (.50 spent then that’s split .25/.25 and again .125/.125/.125/.125 all those link back to the frozen address? How does one partial credit manager know that another credit manager didn’t didn’t do something funky?

Now lets take this a few steps further. Safecoin is worth $100 (we can dream right?) and no one uses full coin for much of anything. I have 100 SC all made up or .01 SC credits from 10000 different addresses. I personally am keeping 10000 addresses from being farmed even though I only have only 100 addresses worth of coin. I have never spent any, so I don’t have any frozen addresses of my own to merge into to free up space. How are all of these managers keeping track of all the other partial coin managers? I feel that before too long farming would start to crawl because addresses aren’t being freed up fast enough as all there partial credits get passed around and address spaces are all getting frozen.

I read your write up twice and its very possible that I missed something but I feel that this proposal gets out of hand very quickly. We’re going from address locations (pointers) to pointers of address locations (pointers of pointers), and partial pointers of pointers at that. Anyone who’s done some C programming knows that pointers get tricky pretty fast when you start over using them.

I agree that this is an issue that needs to be worked out. We need to have something in place that isn’t going to break SAFE when we try to fix this if we explode into the market that we I know we all think we can.

If I missed something, please let me know. I think it’s a good concept, and maybe with some tweaking (or simply me having a better understanding of how this would work) could work.

8 Likes
10

Yes, that’s the idea. Split 1 coin and have 1 coin “credit”. If you spend 0.01 you end up with 0.99.

No, that would imply a huge number of “owners” for the same credit. The credit is owned by you. Now you make thousands of micro payments and the credit is gone. So you end up with a frozen coin and 0 credit. The people that got your credit now have all a very small amount. Next you might get 6.55 Safecoin from a person (that’s 0.55 credit) and someone else gives you 1.55 Safecoin. So now you have 1.1 Safecoin as credit and 7 complete Safecoins. You could keep it that way or merge the 1.1 Safecoin back to 1 Safecoin and 0.10 credit. And understand that this credit wasn’t even the stuff you got from splitting a coin in the first place, as your old-credit is now in the hands of thousands of people. But the network doesn’t care if you split foreign credit back to 1 Safecoin or your own credit. As long as the numbers add up.

This can’t be done. You could split up 10 Safecoins and move it to 10.000 nodes in micro-payments. Now 10.000 nodes have a bit of credit which they can use as well. The 10 Safecoins can’t be farmed which is the same as if they were whole. The only one that could merge back a coin is you. And you could do it with completely different credit that came from different people.

They reach consensus. It’s a whole disjoint group responsible. And we could even add another group for extra protection. They won’t allow you to merge 0.99 credit back to 1 Safecoin. But if you have 1 credit they would allow you to.

The idea is not to use pointers. A group of owners responsible for a Safecoin could just freeze a Safecoin and group-sign to your client_managers that you now have 1 credit of Safecoin. And the credit could move from 1 group of client_managers to the other as long as you ask them to.

I keep thinking about this stuff as well. Maybe I missed somethingl. This stuff get’s quite mental quite fast. But the logic is quite simple if you ask me. And the Disjoint Groups RFC is what makes me comfortable. It’s extremely hard to fool a close group or a group of nodes responsible for your Safecoin. So this (indeed with some changes) should work. So if you’re part of a close group of client_managers. And some other group of client_managers sends you a piece of credit for a node. How big is the change that it’s corrupt?? I think the change is extremely small.

6 Likes
11

First, english isn’t my first language, so please excuse any mistakes

Why not use SafeCoin already embedded systems but with two denominations (like Dollar/Euro and Cents) (and maybe more in the future when it’s needed)

1 SafeCoin = 1000 SafeCent AND 1 SafeCent = 1000 Safexxx…

You have 4.3 billion SafeCoin addresses and 4300 bilion SafeCent addresses in the network (And in the future 4300 000 bilion Safexxx addresses…)

To create 1000 SafeCent you “BANK” 1 safeCoin and to create 1 safecoin you “BANK” 1000 safecent

BANK = Central Function on the network that has the task to “Freeze” and “UnFreeze” Safexxx

When you BANK 1 SafeCoin you Freeze the safecoin address in the bank and UnFreeze 1000 SafeCent addresses from the bank.

When the network starts all Safecents addresses are frozzen!

If you then want to expand you create 4300 000 bilion froozen Safexxx addresses…

With the above method, we reuse all of the features that already exist and do not need to create new features in future

/ Nimos

2 Likes
12

I get what you are saying though I believe this may be convoluted, as the farming algorithm will have to keep track of multiple different stuctured data types and farming rates for each of them.

3 Likes
13

No, the farming algo only nead to keep track of Safecoins

One frozen safecoin is the same ass one owned safecoin…

So the network will always be worth the sum of all SafeCoin owned, even if you manage several denominations.

Only Safecoin can be farmed and burned in the begining.

And If the value of SafeCoin in the future goes up too much over $ 1,000 you can change to pay out in Safecents instead. This can be done by creating a buffer in farming Algon, freeze 1 safecoin and pay farmers 1000 Safecent.

still there can only be 4.3 bilion SafeCoin in the network

/Nimos

2 Likes
14

I like this idea. Typed a lot trying to find holes but they mostly closed themselves up.

Here’s my unresolved questions:

  1. Fees

    4.3B safecoins was decided as a compromise between the convenience of having lots of units vs the computational cost to the network when transferring lots of coins.

    Credits become a ledger system (effectively tracking tx amounts rather than coin units). This isn’t free for the network to look after. If a coin is split into a million pieces, then recombined, it’s a very simple and cheap attack (infeasible with safecoin). If there’s fees for using credits I think this attack may become too expensive to be feasible. But I’m cautious of huge numbers of credits being used as an attack vector since it may become very low cost to create a huge amount of work for the network.

  2. UX

    How does a wallet manage credits and coins? How do users come to understand this difference? Is there additional cognitive load for the user? How do fees work? Is there a coin vs credit selection preference when transferring? Are credits automatically converted to safecoin where possible?

    It seems surmountable but there’s definitely an increase in complexity here. I would say users would probably prefer to only use credits, since it’s much easier to reason about.

  3. Benefits

    Safecoin: can be used to buy anything, but isn’t granular

    Credits: can be used to buy anything except network storage but is extremely granular

    I think I know which one most users will prefer! Credits are much more useful than safecoins when presented this way. This isn’t just about this specific ‘credits’ proposal; any non-safecoin token used for higher granularity will have this same difference.

    Is this a bad thing? Probably not since credits are always fully backed by safecoin. Just want to make sure the economic incentives for farming aren’t compromised. It seems not.

4 Likes
15

The problem with having 1000 SAFEcent and so on is that each would be a SD and if someone sent 100 SAFEcoin’s worth in SAFEcents then the transaction load on the network is 1000 times. The principle was that the load can handle SAFEcoin transactions easy enough because even transferring 1/10 of the potential worth is ~400 million transactions. But if you transfer 1/10 of the potential worth in safecxxx (1/1000000) then that is 400000 Billion transactions the network has to do. I realise that is an extreme case, but an attacker can simply send nanocents and only needs 1 safecoin’s worth being sent between two of their wallets repetitively to slow down the network.

Divisibility has then to be able to provide a lot of divisibility without multiplying the transaction load. Thus this idea of @anon40790172 allows for one extra transaction if there is a fraction of a coin to be transferred whereas cents/milli/micro/xxx means that if someone sends all the amount in the small amounts then the transaction load multiplies. Even sending .999999 would entail 999999 transactions potentially.

6 Likes
16

Right, this was my point in responding to @Nimos that each different denomination would be a different SD that the algorithm would have to be coded to handle, but you are a bit more elequent and in depth in your explanations @neo

3 Likes
17

yes this was the part I wasn’t understanding with the OP either

18

If I split 1 coin into credit, sent the credit to someone else and destroyed my password? Wouldn’t there be credit and a Frozen coin for eternity?

2 Likes
19

The same is said for SAFEcoins themselves. Its an issue that lives with us since money was invented. Lose your $1 note (say ends up in rubbish tip) then its lost forever too

3 Likes
20

Yes, but in your scenario, there wouldn’t be any credit “left over”.