I’m not so sure that this is necessary. We’re talking about such extremely small units that if you set the wallet to always round down, rather than up, for its display, it means that the spender will be carrying the difference of, what, .000000000001th of a safecoin at the worst, rounding to the closest decimal representation.
I’d say that it the key is really which is easier and most efficient at the core level.
If it’s about money, efficiency takes a backseat to precision.
Binary isn’t any less precise than decimal in the general sense, but that it can’t express the values we use with absolute precision as required.
Books must balance in accounting terms. Losing stray decimal places is really not good. As it is avoidable, we should avoid it and use a suitable type.
It may not be a big deal for a basic user, but it would be a huge deal big businesses, finance sector, etc.
Good point. I concede. 
I think the 2^32 safecoins is kind of set in stone since it’s what was claimed at the crowdsale and MAIDs will be exchanged one-for-one for safecoins. If we suddenly changed this, the entire market cap of MAID would suddenly change by orders of magnitudes and that would be quite unacceptable.
I think this entire question won’t really be a problem once the network is out because there is an easy workaround:
say 1 safecoin ~ 1$, then people would just use safecoins when referring day-to-day transactions
say 1 safecoin ~ 1000$, then people (and apps) can count their money in millisafe.
You can go microsafe, nanosafe, picosafe… You can even give them cute names like 1 millisafe == 1 fraser or whatnot 
So basically, where the coma goes is hard to predict when designing the protocols as it will depend on market cap and that will vary; but humans can always pick the right divider and mostly think in whole units 
I don’t think anyone would really care, as long as they got the percentage of Safecoins they are entitled to. For every MAID, just exchange it for ~240K Safecoins.
I don’t see why it would change the market cap of MAID. It has nothing to do with MAID.
This was kind of my point to begin with. Users don’t want to see numbers with 10 decimal places. People don’t inherently understand divisibility as well as they do large numbers. People won’t inherently understand the value written like 1 Safecoin, 220 millisafe, 440 microsafe, and 880 nanosafe in their wallet, and large numbers are much more psychologically pleasing than seeing 1.220440880. They would understand 1,220,440,880. The psychological differences of owning a whole coin and a partial coin are documented and substantial. You would give people a more positive feeling about the project with more coin, even if it just equates to a shift of decimals.
Maybe nitpicking, but picosafe isn’t possible with the current rfc where ‘parts’ is 32 bits long
There are a couple of points here. If we’re transferring coin and expect a response from the network, we’d likely expect a response under all circumstances, not just failure. Otherwise how long does the client wait to be sure a failure response isn’t coming and assume success? I don’t think this would be acceptable for many clients. So we’d end up sending responses 100% of the time.
Even if we do send responses, I’d expect we’d still have to implement the ability for either client (sender or receiver) to query the network anyway to establish whether the transaction succeeded. This would be to cover the case where a client’s connection drops at the critical point of waiting for a response.
There may well be use cases where the sender won’t even need to query the network after sending, since the recipient app may well confirm receipt of payment outside of the network.
Ah - I see how I’ve created confusion now! Just as a reminder, the comment is from the “Unresolved questions” section and states:
If payment rates weren’t variable from section to section, we could omit the
Coinfield from the requests which MaidManagers send to DataManagers.
What I meant here was how much a user will pay to store e.g. 1MB of data, nothing to do with farming rates. I should probably change the phrase “payment rates” to “charges for network resources” or similar. I’m anticiapting that payment rates may well be calculated locally, so if the charges are calculated by the MaidManagers, they need to tell the DataManagers how much they’ve charged client. However, if we have just a fixed charge of x safecoin per MB across the whole network, then the MaidManagers, wouldn’t have to tell the DataManagers how much they’d charged; the DataManagers would be able to calculate the same result themselves. It’s a fairly minor point really I suppose, but I’ll rephrase it anyway
@mav As always, a nice distillation of the key concepts!
I think the only nitpick I’d make is the use of the term “ledger”. I’m no accountant, but to me that implies a record of transactions. One of the nice things here is that the network makes no effort to maintain a ledger.
The network as a whole “knows” the balance of farmed vs unfarmed; i.e. where the coin is currently; but there’s no permanent record kept of transactions. Even the short-term, temporary transaction history is reasonably anonymised - the recipient only knows that x coins were transferred in a transaction with reference number y. So even if someone wants to try and maintain an off-network ledger relating to their account, it’ll have to associate incoming payments with something other than the payer’s actual CoinAccount.
I think it would be a shame to make a less intuitive and more complex system, just because an arbitrary magic number set by the crowd sale. So much has changed since then and as long as the share of the total remains the same, I don’t see why it should be important; if you ask me whether I want 5/10 or 1/2 it really doesn’t matter.
Whole numbers are easier to work with as humans. Why add complexity and require special naming?
I guess I sort of see your point, but I’m not overly convinced I’m afraid! For me, the technical wins of this approach outweigh the notion of physical coins, and I’d think client apps could maybe convey that notion to users somehow, regardless of how safecoin is actually implemented under the hood.
As a wise man once said:
Or 4 instead of 1 billion. With 1 unit a quarter nano Safecoin.
In the interests purely of nitpicking and backing up my French colleage, I’d call that 250 picosafes! 
(the Auld Alliance is alive and well!)
Unless they trot their horses over our crops again We have a habit of killing our allies for bad manners 
Yes the UI will take the integer value and present it the way people want. If people want 2^32 coins and 10^9 parts then the UI does that. If people want 2^32*1000 coins then the UI can present that. But it cannot really be changed part way through the network’s life, just look at what happens when a country changes currency, it can get dirty real quick.
My thought is if this proposal is used then we have 2^32*10^9 parts and maybe 2^32*1000 coins so the maidsafecoin is exchanged for 1000 safecoin. and then we have the ability to have micro safecoin transactions.
The UI can present the value in the users desired fashion
I am sure. Very sure. Absolutely sure. This is financial terms here and you get roasted if you have 17.99999 being told its 18 and when you go to buy a 18 coin item, you find out you cannot not because the UI LIED to you.
Yes I am very sure with some years working such systems.
fixed point 1 billion parts is just as easy, yes just as easy as binary and simpler for the UI too. And then just having the whole amount as one integer is even simpler at the core level. One value to manipulate rather than 2 separate values.
Basic truth here.
If it is explained that the exchange will still be 10% of the total then it should not be a problem. And this larger figure could be presented close to the exchange time to minimise the problems and people can just hold for the couple of months if they don’t want to play the market cap. Remember the market cap is a made up figure really and just one transaction on an exchange can wipe or add billion to the market cap for mere thousands of a transaction.
The trick will be to explain properly that the exchange of MAID to safecoin will be at a rate that ensures that people get their proportion of the total.
But there is no need really if you have 10^9 places in the decimal. Look at bitcoin with only “8” places (only 5 or 6 really usable)
This is the beauty of a UI, it can have options for how the amount in their coin account is presented.
This was about returning the coin to the sending account if the receiving ID does not exist rather than recycling the send amount. Not a response. Getting a little mixed on the issue we are.
Imagine someone sends 1000 coins worth many dollars each and the ID was cut and pasted wrongly and you simply recycle the coins. The SAFE network would die very quickly being used as a payment system. And Maidsafe would not look good either since they did the algorithm.
You have to return the amount even if its a little extra network work. In this case the network has to help out the user and cannot expect perfect users (or APPs)
@Traktion @wydileie
We have a long past thread on this idea of increasing the number of Safecoins. A lot of people weighed in on it and it seems as though people at the time (2014) were against it overall - but more for touchy-feely reasons and not any hard technical or economic reason. I’m personally still for it though. So long as the percentages are the same no one will really care and if it makes Safecoin technically easier to accomplish, then just do it!
https://forum.autonomi.community/t/increasing-the-total-supply-of-safecoin
I think the mood has changed somewhat and the coin is now spread across more people now with many new people and so the resistance is potentially a lot less.
It’s unclear at the moment how to discourage spamming the network with
CoinTransferrequests for tiny amounts without doing something like charging a minimal amount for handling transfers.
Can rate limiting be used?
I think a fee makes sense but it’s nice to offer free transactions.
Could the improved efficiency also allow reward for caching? I guess this is more about the ‘farming algorithm’ than the ‘safecoin implementation’ but being able to issue very small amounts makes the overall economic design much more interesting.
Are parsec blocks formed from single transfer events or are they formed from groups of transfer events?
Would the farming data be included with the network membership chain or a separate chain?
Assuming blocks are batches of events, how big will parsec blocks get? Do they need to include (but not store forever) all transactions that are used to form that block (ie to verifiably update the total farmed value)? I guess the block needs to have data for a) the successful farm attempts b) the recycle events c) the failed transfer events.
Since the order of blocks is not instant, what does an attempted double spend now look like and how does double spend detection work?
Am I understanding the implications of parsec consensus on safecoin correctly?
I think a list of the benefits vs drawbacks is handy
Benefits over RFC-0012
from Motivation section
Drawbacks compared to RFC-0012
Uncertain
What do you mean here?
Under safecoins as MDs there was wallets needed to store the coin addresses belonging to a “wallet” ID. In fact I can see this is less since both need a MD for the coin address and the safecoin as MDs potentially needed additional MDs to store the coin addresses if they had a very large number of coins
So nobody wants to deal in 2^32 troons or ayrs eh?
This isn’t the first time neo has fought against binary. 
Yep, I’m not binary but all shades. 
But for very good reasons that others like @Traktion pointed out better than myself.