Yet Another Safecoin Divisibility idea (YASDI) - Network has a wallet - Decimal coins

Autonomi Network Token (incl (e)MAID)
1

I’ve been thinking about this issue a lot lately. Even at the current valuation of SafeCoin it needs to be divisible. I, as I’m sure many others, would love to see it go even higher. Regardless, this issue needs to be solved. On with the idea.

This idea has a few requirements:

  • Non-zero account creation fee
  • Non-zero transaction fee (in some cases - explained below)
  • Rather than the network just “managing” burned coins, it owns them (many implications)
  • Addition of a “frozen” state to coins
  • Creation of new coin for every decimal place you want to extend the value. (1.xxx = 3 new coins, 1.xxxxx = 5 new)

####Why account creation fee?
I believe this has already been planned for a while, but it’s needed in this case to prevent account spam to carry out network-DoS attack using SC. If you were to want to try it, it would cost (thus giving back to the farmers)
####Why only sometimes a transaction fee?
This method would only stress the network when moving low decimal value values when you don’t own any “low decimal currency”. The most stress is created when moving a single lowest denomination from a whole number of coins. Sending .00001 when you have 1 whole coin. You would end up paying a fee for every new decimal place you must “create” coins for. (Stick with me, I’ll try to explain better in a bit)
####Why have the network have it’s own wallet?
The main reason is that if it “owns” them it has to know where they are. In this case, knowing the location of safecoins that it owns so it can send them to other people. This also opens up some interesting ideas including allowing the network to pay for things itself.
####Why a “frozen” state + new currencies?
(Non-fee example)Alice has 1 SC and wants to send .00001 to Bob. Alice signs a message telling the network to freeze her 1 SC, giving her access to 10 SC.1. Then signs a message for the network to freeze one of her SC.1, giving her access to 10 SC.01… Then transfer one SC.00001 to Bob. (I would assume this could all be handled in one /few messages - just demonstrating the logic) The wallet software would request to combine any value greater than 9 decimal currency up to the next, releasing a frozen coin to themselves. So if Bob sent Alice back that .00001, it would release all the way back up to 1 SC.

In the above example, Alice and Bob could stress the network pretty hard just sending that .00001 back and forth to each other with no repercussions without a fee. However, Alice sending Bob .00001 after the first transaction (while she has .99999 SC) is just as trivial as current ideas for sending full SC. Some fee schedule would have to be figured out to make it worth it for the work that goes into the network making those calculations, messages and tranfers. How small the fee could be would depend on how efficiently the above could be coded. My preliminary thought would be an added fee for every decimal place changed (currency used).

Maybe this is how we pay routing nodes? With the transaction fees

By the same token, account creation must have a cost to prevent a whale from wreaking havoc creating tons of accounts and not caring about the (hopefully still miniscule) transaction fees and stressing the network needlessly.

Mining can still happen much the safe way - after a get request an address, if its owned by the network and not frozen, it’s transferred to farmer.

####Pros:
Divisibility
Simplicity - Once SC is implemented, the decimal currencies are all copy-paste
Our autonomous network has autonomy over it’s own money
####Cons
All coins have to be made up front and “given” to the network - Network plays the bank / “money changer” instead of “file manager”
Opens up some more attack vectors for network stress

7 Likes
2

I think this is a clever perspective @wes going to be marinating on this for a bit :slight_smile:

3

Already brought up

1 Like
4

Just wondering how this is better than doing all of what you suggest EXCEPT the core idea of creating coins rather than having each wallet (costs to create) keep a balance.

So rather than move all these new 0.1, 0.001, 0.0001 etc coins around the network, the network simply maintains balances in the wallets of the sender/receiver.

The concept of freezing coins and the network having a “wallet” for these frozen coins all tie into the balance idea. (see my suggestion from a year ago and refined in Jan this year which @anon40790172’s idea is similar)

Really wondering why creating coins is better than keeping a balance of the sub coin amount?

2 Likes
5

@anon81773980 this is very similar to other proposals but I think the sometimes transaction fees and network wallet ideas are quite novel and interesting. I think the sometimes transaction fees actually addresses a unique problem. Or at the least bringing it up and doing some thought experiments on micro transaction abuse and/or spam is good for the conversation before implementation of safecoin.

6

Point was these are not new. And the need for transaction fees is solved by reducing the movement of sub coin amounts to the “network cost” of moving a coin and by having a real PUT cost to have a wallet and maintain it.

When MD updates are going to cost PUT balance then the maintenance of the wallet (creation, adding/removing coins is going to become the inherent transaction fee. While there is no cost to moving a coin there will be at least one or 2 PUT costs to add/remove the coins to/from the wallet. The same for part coin balance.

It is a small cost for ordinary usage and would typically be tons less than anything around the place it does add up for any attack using small amounts. And limiting part coin balances to created wallet data structures make attacks much more costly.

2 Likes
7

I didn’t think about it from the mutable data update PUT cost, good points there. I’ll be excited for when the devs start getting more involved in this conversation but I do think between you @neo and @anon40790172 that a lot has been hashed out.

2 Likes
9

I had forgotten about @anon40790172 post which I had participated in. I must give credit to him as it must have at least started this thought process in my head even if I didn’t consciously remember it while working through this solution.

The main difference is credits vs. “hard money”. A strange concept for something entirely digital, however, I am inherently against the idea of IOUs.

If we’re not going to use “hard money” (direct file access means you own the coin) then safecoin divisibility is really a non-issue and could look like:

Every user has read only access to a network owned appendable data file. When a farmer mines a coin, their appendable data file gets a +1 to the balance.
When Alice sends value, it tells the network to subtract that balance from its file and add it to Bob’s file.
When a coin gets burned to the network, it updates it’s ledger. It knows its ledger balance and can keep it from going over 4.3B

Obviously it’s a little more involved than that. but I feel like we either need to pick a hard money solution or a ledger/IOU system and stick with it. Trying to combine the two just seems to be adding unneeded complications.

2 Likes
10

The balance idea I proposed is like a hard data object for the part coin amount. Just a variable amount rather than a set denomination. A MD must be created/exist to hold the part coin amount. When a coin is used to make a balance MD (Wallet MD) it is frozen and when a balance is > 1.0 then a coin is unfrozen and sent to the wallet address. So effectively automatic recombination. Actually Rene’ borrowed that part from me and I borrowed it from Ben a year ago.

So you propose to have set part coin denominations MDs and the balance idea proposed variable balance MDs tied to a wallet to reduce gaming/attack surface. Just wondering if the increased proliferation of these Denominations is worth the concept of fixed part coin MDs. Remember that micro-transcations will want 0.000001 and much lower denominations. Possibly even pay farming rewards per GET (if win “lottery”)

Considering even if it was a pure balance held without it requiring its hard money MD to hold the balance it would be worth the saving on network load and data storage, The reason being it is solving a different problem to the coin. The network has less work to do to handle part coin amounts and is (almost) infinitely divisible.

And my balance proposal turned the balance in to “hard Money” as you called it by making the balance be stored in an MD held in the Wallet data set for a wallet address.

The balance idea is similar to the denomination idea in that denominations MDs require a safecoin to be held in a frozen state as backing for the denomination “coins”. The balance requires a safecoin to be frozen as backing for the amount. A safecoin worth of denomination “coins” can be removed in exchange for a frozen safecoin. The balance MD will be reduced by a safecoin amount automatically in exchange for a safecoin.

Really the difference is that the denominations require the frozen safecoin to be split entirely into the (requested) denomination MDs and the balance idea only requires the frozen coin to be added to a balance MD. The balance idea require no more MDs than is already needed since you need some sort of data structure to hold a wallet’s coin addresses.

For me the biggest issue with the denomination ideas is that the number of MDs required seem to far outweigh the elegance benefits. Even with the limiting and recombination, I still feel that the number of denomination MDs will be forever increasing and can it ever handle the 0.000001 denominations or as some want 0.000000001 and lower. As the value of the safecoin increases the requirement for smaller and smaller denominations increase. Reasons for milli/micro safecoin transactions today will become the reasons for micro/nano safecoin transactions at a later time.

2 Likes
11

I am quite late to the party, but am rather concerned about this. While I have attempted to get in the loop, I must admit to a lack of complete knowledge. One of the main sticking points in my decision to invest in it, was the promise of a micropayment system that doesn’t require an entire block chain. Anyhow, as mentioned I have read up a bit on some older threads, and have some thoughts that I haven’t seen yet. Perhaps due lack of comprehension on my part.

Instead of focusing on dividing the actual coin. C/Would it not be simpler to double the owners. If Alice wants to send Bob 1/2 a coin, the coin has 2 owners. If Bob ever needs to send 1/2 a coin, he that half ownership is transferred. If Bob sends Charles 1/4 coin, the coin doubles ownership again, leaving Alice with 2 stakes, Bob 1, and Charles 1.

While this does double the workload every halving, it does flatten out the amount of work, and no new addresses are requires. Plus there could be methods of preference that help keep fewer coins from being split. Only doubling ownerships when an owner does not have “change”.

1 Like
12

This has a self defeating limit. The safecoin MD can only hold a limited number of “owners” and their “share” due to MD data object’s 1Mbyte limit. The issue also becomes that coins will be divided over time and when coins are at their limit of dividing then if one of the owners only has that share then they cannot send anything but that share anywhere. So if Jack had 1/2 of a coin and the other 1/2 had been divided so many times there is no space left to divide further. Then if Jack wanted to send 1/5th of a coin then he cannot. What would have to happen is Jack sends the 1/2 coin and hopes the other person is able (or will) send back the 3/10th share of a coin. But if the other person is in the same situation as Jack then they are out of luck.

Better to use the other method of division that freezes coins and use balances in wallet MDs to hold that fraction of a coin balance. Then the coin can be divided 2^63 parts. Since the balance is kept in a network managed wallet MD it can be made as secure as coins and use similar process when sending payment to another person.

2 Likes
13

Well, with the scheme I proposed, if Jack had half a coin, and it was divided so much it couldn’t be divided anymore (max), Jack would have change equal to it’s division. 3/10 exactly would not be possible, as it would be limited to 1/2^n (max). He would have 1/2 x (max) claims on the coin. What is the size of an ownership claim? 8 bytes, 16? If you have some current relevant links I could further inform myself with, I’d appreciate it.

14

Jack would have only the ability to send 1/2 a coin. The other divisions/shares are owned by other people and he has no ability or right to touch the other. So he has to send 1/2 a coin or nothing.

That seems awfully limiting in itself doesn’t it. At least a balance system allows you to send 0.31416 if you wanted without limiting anything.

Well the data required would be at least (in bytes)

  • a division quantity size say 2 bytes,
  • owner ID and that is 16 bytes (and possibly 32 later) So need a ownerID version bit too so later on the ownerID size can be known
  • Options byte (contains at least the ID version flag)
  • security, ah the required overhead of SAFE to enforce owner and fields. Is it 32 or 64 bytes?
  • previous owner (required for consistency with safecoin usage and security. 16 bytes

Also at the moment there is a 100 field limit on MDs and later on we don’t know this limit. But there will be one to help prevent transaction spamming of MDs causing work overload of the group looking after the MD. And a MD is limited to 1MB in size. So say 150 bytes and this gives say 6,500 (approx) divisions 2^12 is the closest and lower so 4,096 divisions. Still does not give micro-transactions unfortunately.

For info please look for MD (Mutable Data) in the forum. I would need to search it out myself again. I haven’t kept the links for myself yet because they are still under development and bound to have the specifics change.

Although the very basics of only being able to have divisibility that only give you a binary fraction is in itself a very limiting method and will have non-tech and many tech people complaining that they specified to receive 0.01 of a coin but the sender can only send slightly more or slightly less but never exactly 0.01 of a coin. As much as we techos love binary we still live in a largely decimal world. even LSD currency gave way to decimal and I can see the demands for a decimal division of safecoin rising if we implemented a binary division method.

still reading :slight_smile: What some have suggested for the short term is a method whereby we add a bit onto the coin address (when required) and every existing coin becomes two. So if you had 10 coins before then after the bit add you would have 20 coins but only worth 1/2 each. This is a form of binary division but still have whole coins. Drawbacks is the obvious transaction load on the network increasing, all the sellers have to double their coin price every time it happens and general confusion.

Personally I still think that a balance idea with freezing coins has the benefits of your suggestion with out the drawbacks of overloading a coin MD with “splits” and having decimal divisibility. Everyone has to have a safecoin wallet data structure to hold the addresses of their coin they own, and it can simply have a balance field that is owned by the same group that looks after the MD and is updated by network whenever it receives some part coin amount or sends some.

1 Like
15

Thanks for the suggestions for search topics. I have read what I believe to be the most up to date suggestions, and they seem to add extra complexity and or different types of coin.

As far as the criticism of binary division is concerned, I think it is better phrased as granularity or division size. You’ll never be able to store analog data in a digital system, just more granulated data. While 2^12 may not be enough, that is an argument worth having, and the size does matter. I do not see binary fractions as being a problem with a high enough level of division. At 2^32 level, you are already at the same level as a standard float… maybe better since it isn’t a floating point.

16

As far as I see binary division and float are basically the same problem. Float after all is only an implementation of binary. A float with 12 bits plus ?? bits of exponent is going to have the same issues.

The balance scheme is perhaps the least complex of the suggestions so far. Everyone who has coins will need something to store their coin addresses in for the coins they own. This is likely to be at least one MD, all the balance idea does is use a MD that is already needed and place a field in it for the balance. And then simply have a network wallet for the frozen coins.

To me it is more complex for the user to understand what all these 1/16 and 1/2048 and 1/4 and … they have and how do I send the guy 0.01 (a safecent) worth of a coin. Keeping a balance keeps the actual coin MDs clean with less ability to game the system and requires any attacker to create wallets to attack safe using fractions of a coin. The attacker has to spend in order to create the wallets in order to attack the system. Also recombining back to safecoin is automatic and whenever a balance amount would go over 1 coin’s worth the system give a coin from its frozen wallet, so the balance remains under 1 coin.

Split coins only requires the attacker to (temporarily) buy up coins and then split them to the max sending them to himself and cash out later on. The attacker then experiences no cost but has multiplied his attack by 4096 times or more. And in the process left the coin system in a fractured state. Only when one person owns all fractions is it possible to defracture it back to a coin.

Then there is the issue after a long time that most times most transactions will require many fractions just to spend a coin or two worth of SAFEcoin. This results in greater transaction load on the network just from normal use. Balance system ony needs one transaction for each whole coin and one for the fraction of a coin amount. (yes there maybe one more if a coin is frozen or unfrozen) This is in contrast to when most coins in circulation is fractured many times.

And the biggest issue is the fundamental principle of destroying coins when you buy PUT balance and creating coin for rewards. How does the system destroy coins when a person pays for their PUTs with a fractured coin because either thats all they have or all coins have reached the fractured state due to “microtransactions” popularity and/or attacks. The complexity mounts.

Floating point maths never satisfies the public or banking system that uses essentially a fixed-point system for keeping your bank balances (which cobol used) and now whatever language they use. And this is what the balance system would use too, so there is no rounding issues. There would be 2^62 parts to a coins and always that many with no rounding ever used.

1 Like
17

I don’t understand why binary division is supposed to be only a down fall for a many owner scheme. It is a computer problem, and it isn’t a really difficult one. The public doesn’t have to be aware of binary division at all, anymore than they already are. 0.01 would be written 0.01, there is no reason to have an infinite series, and it doesn’t matter what scheme it is, as long as it’s on a binary computer, 0.1 and the like is an approximation. There is no 0.01, just like we cannot write pi on a finite paper. And decimal is not without repeating sequences. So even if we decided maidsafe can only run on decimal computers, there are going to be rounding issues.

18

Not for the owners or the programming. But for human acceptance. The vast majority of people we wish to “sell” the concept/usage of SAFEcoin to is the general public who have never had to deal with 1 cent not actually being one cent. To then $19.95 is actually 1995 cents not 1994 or 1996 cents. To then tell them they have to deal in odd binary fractions and sometimes not even close since their share of a coin is in a coin that is fully divided and they have to transact their whole share.[quote=“toa, post:17, topic:13185”]
So even if we decided maidsafe can only run on decimal computers, there are going to be rounding issues.
[/quote]

No why? fixed point arithmetic means that if the transaction is specified for 0.2348748574395764 then it will be for exactly that amount. And that is what the balance concept will do divide the coin into 1/10^18 parts and keep the amounts in balance records. No need to create 10^18 parts/coins/whatever. Just keep the parts as ledger amounts in however many balances.[quote=“toa, post:17, topic:13185”]
The public doesn’t have to be aware of binary division at all, anymore than they already are. 0.01 would be written 0.01
[/quote]

No because they easily see that 100 * 0.01 is 1.00 and if you tell them that now its 101 or 99 they will complain. And rightly so. To transact in decimal you need to use decimal and that is what cobol gave the financial world, decimal (fixed point) maths in a binary world. The only time rounding is needed is for when you have interest calculations and even that is approximated to decimal values, not binary float. The world understands decimal denominations not float denominations and you will get cries of cheating of people cheating them out of those “slightly different amounts” Assuming you could get 1/4096 divisions then the one safecent amounts are some smaller fraction of a safecoin out and people will have a lot of complaints that suggest SAFEcoin is a scam.

WHY do you think bitcoin went to a decimal (fixed point) system? Its built on a binary framework with so much tricky binary maths, yet they divide in decimal.

19

There is an acceptable/set level of precision, which is how we represent non terminating decimal numbers in binary systems. Bitcoin chose a number of bits, and set an arbitrary level of precision. It was chosen because it could be handled by a double (64 bit) number, and not overflow. That makes it not so arbitrary, but good planning. And that also means we could do the exact same thing, with a level of precision set at the same range, with binary division. There is no magic in cobol, there is a set standard level of precision. A non terminating value must terminate to be representable as a value. We choose our level precision, binary division or not. Even in decimal we don’t write out non terminating number forever. If we could have 2^1000000 binary divisions, we could represent decimal numbers with more precision than any banks or cobol. As I said, the amount of divisions matters, not the fact that it is binary division.

20

But that is the point. You can represent decimal places EXACTLY with no error, that is total precision. COBOL did it using “fixed point” arithmetic.

For instance to represent 3 decimal places you take 10 bits and act as if they are an integer with values 0-999 then do integer maths for the fraction part and any over flow adds into the integer maths for the wholes.

For 60 bits you can have 18 decimal places for unsigned.

21

And all I’m saying is, you aren’t forced into anything new with multi owner safecoin. That is more of an implementation detail built on top of a division scheme. The concern isn’t new to multi owner, it is a separate issue in my opinion. It may affect how you implement it, but the main concern with multi owner is size of the data. How many owners while keeping data lower and computation lower.