So then where is the claim savings on the network? The APP is now making the network check the receiving ID every time a send is done. This is 100% of “x” amount of work (APP checking ID) for the network instead of the network doing a little extra work for the less than 1 in a million that the ID is not there.
So X * 1 compared to Y * 0.000001 And surely Y is not 1 million times the work of X, but maybe a few times.
Yes I now. But my point was there will be different amounts due to farming reward being “X” and APP reward being “X/10” so there are different values even if every section had the same farming reward amount. This means that comment is unneeded.
I agree with @JoeSmithJr here in that it solves the decimal issue and its just the UI that presents the value as coin.part. So an integer that is 2^32*10^9
But I cannot then use it to buy a item for 18 safecoin, I’d have to make up the difference.
AND yes people will be complaining every day because you stole 0.0000001 of a safecoin from them.
Or are you saying that the SAFE network will send a full 18 safecoin if I only have 17.99999992363154888153076171875 safecoin. I doubt it don’t you. And so the friendly client app will be cursed every time this happens.
This is why banks always use fixed point decimal values for all their transactions which often are interest/fees including sub cent amounts. People will cry foul when your rounding means they cannot actually buy something because rounding claimed they had a certain amount of coin but in fact they have less and claim that the APP or SAFE robbed them of that small fraction.
EDIT: I should read it all before commenting shouldn’t I
It’s a differentiating feature that I feel matters. It’s getting right what all the others didn’t. It bridges the gap between the make-belief world of banking, where new money is conjured up from thin air at the press of a button, and the everyday reality of people. Money becomes a (pseudo) physical “thing” again where “I have a coin” has a very tangible meaning.
I don’t want to pretend I presented an airtight argument. All I have is a very strong yet hard to pin down conviction that this may matter a lot in the future, maybe in unexpected ways. I do admit this is not exactly a scientific or technical argument It just feels like a direction to not give up on so easily.
There is one caveat. One size does not fit all, so we would need one of the coin denomination ideas. If we had a controlled supply of coins with decimal, 1-2-5, or maybe binary denominations (though I’m with @neo on that last one) then we could have self-adjusting liquidity, setting the supply so that the number of coins is not a burden on the current size of the network, yet it’s enough for not only network services but also commerce and other uses of money.
Looking beyond Safecoin, the same infrastructure (exchange of value and transfer of ownership without fees) could be used to maintain a number of other currencies, such as community currencies or even digitizing the narrow money of entire countries. These are really small pieces of data but they bring a huge benefit: they turn the Safe Network into the basic fabric of everyday life. (This last part is not strictly tied to the “coin as data” argument.)
I think this is also a great way to ‘burn’ coins. Instead of them going to a void, they will get recycled. Moreover, how do you burn coins without being able to send them to a non-existent address?
Maybe this is a slightly quirky use case, but it is useful.
Agreed and I can vouch for this too. We absolutely must use fixed point decimals if it is to be considered appropriate for accountancy. We would literally be laughed at otherwise.
Moreover, the choice of how to size units is important. We lack the words to express many decimal places easily, especially many preceeding zeros. We really should try to avoid the obvious mistakes made by Bitcoin.
Ofc , there is no perfect size, but assuming that parts should rarely be needed beyond micro transactions is likely a given. As the network grows, they can then gain in use.
A 1000 safecoin chew is much easier to say than a 0.00001 safecoin chew (try it!). We are also used to saying 1K for 1000, at least in western cultures. A 150k is still easy to say, but 0.0015 is a pain.
Bitcoin has attempted to work around this with various naming conventions, but it is a bit of a dog’s dinner.
Has thought been put into how this can work with multisig? IIRC, there were challenges with the original safecoin RFC on this front. This would be a big win if easy to achieve.
If you think of where 100 k comes from, which is just a metric prefix symbol for kilo, we could stick with that theme and use μ for micro amounts? Would that work for micro denominatons and seem similar to the kilo convention rather than going full fledge into decimals?
So what happens when I want to pay someone exactly 18 safecoin but only have 17.99… safecoin but don’t know it/have it because of the friendly client app? Covering up a problem with a UI doesn’t actually solve it. We learned that problem with bitcoin.
In Canada here we did something rather stupid and eliminated the penny because it was more expensive to mint the copper coins than their worth in cents. So now we end up rounding everything to the nearest 5 cent mark when dealing in coin. Now HUMANS can do that and we can deal with the reality that sometimes we’ll lose say up to 5 cents or gain it when doing the odd transaction. It’ll work itself out. But a computer isn’t that flexible.
Any SAFE client will receive PUSH notifications once it’s supported by the network, regardless of what technology you are using. If something is changed or mutated you won’t have to manually ask (pull) the network it will instead send (push) you that info, that’s all that means.
I was always curious why we decided to go with fractions of a coin at all. Why not just make 4 quintillion coins (or whatever the equivalent number would be for the amount of divisibility you want)?
It becomes simpler for the user, because they just have coins. No divisibility, no conversions, no nothing. If you are going the integer/floating point route, its simply a number on a digital ledger with a little bit larger data structure for storage of the integer. If it is a piece of data, it can be a much simpler piece of data then having a coin with every little divisible piece assigned to a different user, leading to super complicated data structures.
If it is a ledger this would be feasible, but in the original proposal where each coin is a separate item of data it would not, because it would create a variable load on the network in proportion to the value of the transaction.
I fail to see the difference. Over time, everyone’s division of coin will be spread over likely millions of different coins, each owning a small division of one coin or another. After a few years of high transaction rates, it’s highly unlikely anyone would own a full coin anymore. Thus, spending a coin will require the reassigning of ownership across tens, hundreds, thousands, or even millions of divisions of coin, much like simply spending 100,000 coin on a transaction.
Perhaps the network will adjust itself on the fly to try to keep as few owners as possible per coin, but that seems computationally unfeasible right now, at least until quantum computers are prevalent.
IMO, the decimal place just makes it more human friendly. Paying 1000 for a chew, 100,000 for a loaf of bread, 1,000,000 for lunch, 10,000,000,000 for a car, etc, just gets a bit big. Ofc, you can then have notations for groups of these (e.g. k), but it is just a bit clunky.
Squirting a decimal place to split big from small units just makes the sums a bit easier for us. That said, having too many decimal places is even more difficult to work with than huge whole numbers. Personally, I think it would be good to start too big and go smaller if/when the coin reaches sufficient demand.
Ofc, the representation could just shift a few bits and call that a safecoin, but it is a bit counter intuitive.
Correct. This is why the different coin denomination ideas came to be. Coins would still be individual pieces of data but they would represent different values.
Denominations would also avoid the problem of having a fixed number of decimals, where the precision is set for eternity, regardless of the value of the unit. Why store 8 or 9 decimals if the whole unit is worth $0.0001?
Another thing about fixed point nubers is about significance. What is the significance of $0.00001 in a $1,200,000 transaction? So, why store it? Yet I need that precision for when I want to pay $0.000012 for a single IoT database query (though I’m not convinced this is a legitimate use case even, but let’s ignore that for now). This is not a problem with coin denominations, where we can pay with 2 or 3 real big coins in the first case and with 2 or 3 tiny ones in the second.
This is an argument I can get behind. Ultimately, we want to do what makes the most sense to the user. Forget code for a second, what would a user want to see? Continuing with the two decimal places may make sense, because that is what many people are used to, at least in the Western world. I wouldn’t say I’m overly familiar with Eastern currencies, but it seems they favor large numbers to decimals, for the most part. Dealing with extreme decimal places is not intuitive or user friendly for anyone, so why would you want to code your brand new coin that way? Make it a straight integer, or a floating with two decimals and leave it at that. Grow the coins produced, not the divisibility of the coin.
This also has another positive effect. There is a psychological component to it as well. People feel better if they have a “whole” of something. If you have a maximum of 4B coins, that’s not even a coin for every person on the planet, and that is assuming they are all in circulation at the same time. Think about psychology and marketing. There is a reason people price things at 99 cents instead of $1. We place undue value on that one cent because it gives us a whole. So why would you want to design a system where not everyone can achieve that psychological satisfaction, instead, opting for how many ever long decimal places which no one likes?
But why divide instead of multiply? You can just as easily have a 1B, 1M and 1K Safecoin denomination as you can a nano, micro and milli-SAFE, or whatever you would call the smaller denominations.
Sure, I see value in this, but if you start with some arbitrarily large number of coin, if that were to need to be exceeded at some point way in the future, the network could just calculate a multiplicative, create more coins, and multiply the coins in each wallet with the new number. No one wants to look at their wallet and see they own 0.0000047148 Safecoin, when they could own 471.48 Safecoin.
I still fail to see why an arbitrarily chosen small denomination is preferable to a large denomination.
If you have a number of larger coins and you add a number of even larger coins, you just inflated the supply. If you add smaller coins, the total value hardly changes.
But it’s also a result of how the network would grow. You’d start with enough money (and, with that, coins) for the needs of the number of users at start. If things work out well, the value of the unit coin would slowly raise as the number of users grew.
The smallest denomination would start to become too big, so it would be time to introduce a new, smaller, denomination to fix this problem. The new denomination would have enough coins (released over time) to raise the total market cap by a certain ratio, for example 20% (under 100% to avoid uncontrolled inflation).
I see what you are doing, now. I didn’t realize when you said denominations, you meant an entirely separate coin, instead of a piece of the data of a Safecoin. I thought you were just calling a division of a Safecoin some arbitrary name.
I see value in that. However, I still think it makes more sense to start with some stupidly high number of possible coins, and use two decimals (or maybe three decimals and make a milli-SAFEcoin). If that has to expand into more divisions in the future, so be it, but at least we start with a place of controlled chaos, instead of having Safecoin divisions down to 10 decimal places.
Design for 1 quadrillion coins or something with some high denominations at the outset. 2^40 is ~1.01 quadrillion.
1k, 10k, 100k, 1m, 10m, 100m, 1bn, 10bn, etc… all pretty easy to represent in an obvious human readable way, without any special names etc. A decent UI could represent these well.
Perhaps if we had done the same with satoshis, it would have been easier than trying to name the decimal places.
Having one huge number would probably be simpler to implement and leaves the door open to add smaller ‘parts’ in the future.
It just feels like a direction to not give up on so easily.