Given that the network will always have a steady supply of Safecoin from Puts to deliver to farmers, content deliverers & developers in whatever split is required, with sufficient divisibility I don’t see the economic need for any dilution of Safecoin beyond the promised 5% for early investors.
Would the network be disadvantaged by not issuing any of the planned 85% of the Safecoins that are not yet allocated, when it’ll have a steady supply to distribute anyway?
It wouldn’t be dilution since 1 MAID gets you 16 SAFEcoin if that was adopted.
But as always these are just ideas and no one is actually wanting the change. Brainstorming and exploration often involves looking at things that cannot be implemented because of external factors and in this case the crowdsale conditions demand certain things.
In any case if done right the increase in safecoins would not invalidate the >400 million MAID being 10% of the total safecoin. In other words 1 MAID gets 16 safe coin and all the MAID combined gets 10% of the safecoin which is the spirit of the crowdsale coin distribution.
NOW I am not suggesting we should do this
Exactly, division will provide the solution. But only if the price of safecoin is high enough (like it is now and going to be). If the safecoin price/value is way too low then division may not really solve much at all.
Bitcoin showed that division solves the low coin count problem. Isn’t BTC limited to around 21 million. And safecoin can have much better division than was implemented for BTC
Yes, I agree with this, but even it would be mathematically equivalent, I am afraid that some people would still complain that the crowdsale terms are not respected.
With the right supply for each denomination, @mav proposition could be implemented while still preserving the letter of the crowdsale, with a total supply of 4,294,967,295 safecoins and 452,552,412 of which reserved for the buyers, at the rate of 1 MaidSafeCoin = 1 SafeCoin.
The supply tables I have provided are 2 examples that respect this constraint, but there is an infinite possible list of such tables.
Very much so which is why I am not suggesting be done, even though I mention it as a possibility.
Yes it is an interesting proposition. But I get the feeling some will object because they see the potential for the few to win big in farming rewards as unfair. Also because they don’t understand how it will be equivalent.
The other thing that concerns me is that I doubt it will give enough division to cater for the future when SAFE coin value is very high and they want true micro-transactions or even nano when SAFE is valued as 1000$
Bitcoin showed that division solves the low coin count problem. Isn’t BTC limited to around 21 million. And safecoin can have much better division than was implemented for BTC
If divisibility can be implemented well, then I’m definitely all for it. In my view doubling the size of the coin identifier is basically equivalent (from a high level economic view) to bitcoin divisibility. We say Bitcoin is divisible, but really the smallest possible transaction is one satoshi, so its still discrete. Its just that a satoshi is so small that we can effectivly treat bitcoins as real numbered values. Really the satoshi is the fundamental unit of bitcoin, and a “bitcoin” is simply a common benchmark number of statoshis that we use to colloquially refer to the currency. At least it seems that way from the perspective of someone who is fairly technical but not a bitcoin expert. If we used a 36 bit id we could even use the same linguistic trick and refer to 16 coin ids as a single SafeCoin. The real problem with this sort of divisibility, as you pointed out earlier, is network performance.
Actually its not 100,000,000 divisions, the discrete amounts are like in terms of 1500 sat. Your point is right though.
And we have a range of options for division with a balance method going to 1/10^18 th discrete units. So micro or nano or pico transactions is more than feasible. The limits will be artificial, since that small of a unit is in practical terms “infinite”. The transaction size limits in usage (not storage) will be for human usage and transaction spam limits.