RFC for sure. Safecoin implementation will be coming up so this would be nice to see in detail. We have been slack wiht RFC’s because of recent push, but these will become critical and the way to improve the system. I also think that repo should be considered part of core dev and core dev payments, to make it clear how important it is.
Thanks for the ideas, they look very interesting indeed.
Did you notice I said 16 billion billion = 16,000,000,000,000,000,000[quote=“Tim87, post:20, topic:7944”]
The bad news is that I can’t see a way to “un-split” coins: it’s unlikely the two halves would end up in the same hands ever again, so: once split, always split.
[/quote]
By freezing the coin when its split does two things
Alright. Then “vaster than just 16 billion billion” 
One coin can be divided into 452,312,848,583,266,388,373,324,160,190,187,140,051,835,877,600,158,453,279,131,187,530,910,662,656 pieces 
I’m not gonna lie, I have no idea what the safe dust thing means. But I guess yea, the system must know which coins are in circulation (whole or split, doesn’t matter) for the scarcity thing to work.
Ah we were at cross meanings, the 16 billion billion was the binary division using an SD each.
You were talking of my proposal.
Yes a hella of a lot more 
Its just a matter of using 32 bits gives a max of 9 usable digits and for our purposes is more than enough, but considering the SD has plenty of space, I considered that 64 bits would totally future proof any conceivable situation. 128 bits is just scary, and would outlast computers as we know them.
Imagine the 9 digits situation and now the core charges and transacts micro payments, so it charges for each PUT and pays on each GET rather than the averaging system it emulates now.
if FR is very low then it may be paying less than 1/10^10 per GET, it already can and much much lower if avail space is very high. Like 1 coin for every 2^64 GETS. So if we move over to farmers getting micro payments then we need to get close at least to that. So that reason combined with calls be others that 9 places is not enough long term, 64 bit signed integer was a logical choice to hold the fixed point decimal number.
that was just a word, for want of a better one, to call the SD holding the partial coin fragment.
So if I buy something for 1.25 coins and I don’t have the 0.25
Now if some pays me 0.9 coins (ignoring what happens on their side)
Hope that helps
SAFEdust === coin fragment SD === fraction of coin SD === whatever name best suits.
I really like that idea but does that mean we all should settle that 1 safecoin = 1gb, and then safedust = 1mb?
That’s the biggest hurdle I see to date. Somebody did mention about the multiply goblin cups (harry potter) problem.
How can we make a determination that safedust does not equal to 1gb?
Imagine the 9 digits situation and now the core charges and transacts
micro payments, so it charges for each PUT and pays on each GET rather
than the averaging system it emulates now.
You’re gonna have to explain this more. Or if you want, just link to what you already said in the other thread.
NOPE.
It is essential to the network that it is never fixed. That would remove the ability for the network to attract new farmers when space gets low.
So if FR is 0.0001 then that results in 1 coin per 10000 GETS then if farming rewards was transferred over to micropayments then each GET will give the farmer 0.0001 coins.
That is what FR (farming rate) really is “how much of a coin per GET)”
Ohh okay, this is actually a much better approach. +1
FR can get a bit lower than 0.0000000000000000001 and as high as 1.0
Now if you want to do micro payments [to the framer] when its that low then you would need to have that many digits in your fraction of a coin.
So if SAFE went to micropayments then we would that many places.
So if use 32 bits to hold the subdivision then we simply could not do that.
Thus 64 bits is the next logical step, and the core simply makes the lowest FR to match the precision, which is barely a change to the lowest amount.
I really like this and hope it can be done. I find it difficult to get people to understand the “lottery” part of the FR
The man himself is interested and asking you to write it up as an RFC, @neo Are you planning to do this?
This seems extremely important, and I definitely hope we see it materialize as an RFC.
Let me know if you want any help
Yes, I have a couple of things to think through. I will have to study up further on the SAFEcon transaction process since my very 1st idea was to just send SDs around with fractions of a coin, but that is susceptible to the balloon attack where someone just keeps dividing the coin and we are back to the billion upon billions of SDs out there. So how to send the fraction of coin to the receiver. Maybe we have to charge the sender a PUT cost to create any SDs needed in the transaction.
Hey I think that is the solution, the sender is charged the PUT cost if a SD needs to be created. It the sender already has a SD for fractions of coin then no cost. So someone who does enough microtransactions will not have to pay anything, and farmers just have their account’s SD to receive the fractions stored with the vault.
I am busy for about a week and I will get into it and perhaps start a topic for some to pick holes in it. (some have like the balloon attack)
I have seen a few things like this, should go to RFC process but require a PRE - RFC discussion to ping ideas around and shape the proposal. Perhaps it would help if we had a PRE-RFC topic and actively move threads with such ideas there as they develop from a basic thought to a more thought out discussed potential solution? @moderators
It would mean the RFC’s have more than one person pushing them when they go through the process, which will hopefully speed it up.
We have a RFC sub-category under the development category RFCs - Safe Network Forum
Personally I feel that the moderators should not instigate (move posts to) a (PRE-)RFC topic because without a motivated person to write and push the idea it may die prematurely.
The coin division idea of mine is certainly going to get a PRE-RFC topic in about a week or two, with the holidays coming up I will either have plenty of time or be entertaining grandkids.
The idea is ticking in the background of my mind and I think the balloon attack problem was solved just above.
Wowz. You all just blew me away with your technical knowledge having read this whole thread. I still don’t understand how many actual SAFE coins there will ever be in existence! Or am i thinking about this entire thing in the wrong way?
Ah 2^32 or 4294967296 in total, but recycled continually and possibly (very likely) to be also divisible.
Thanks Mr Irvine. All clear!