YASDI - Bitwise Denominations

Look at @tfa’s table to which he was replying about.

greater than 4.4 x 10^13 objects needed

2 Likes

The concert about the number of MD is from the @tfa idea not yours. Forget to point it out, sorry.

The big problem with your idea is the conversion. If the safecoin price increase, as we expect to happen, the number of small denominations are extremely low and a shortage seems inevitable. This would seriously damage the reputation of the network.

There are other problem and is that the possibility to win in the farming decreases if the number of farmers increases. The ideal is find a solution that suits this possibility. It is what I have tried to do with the activation of decimals in stages.

2 Likes

I suppose a big issue is the availability of the lower denomination coins.

Is the network now going to act as an exchange to exchange a 1.0 coin for 100 of the 0.01 coins? If so then it is going to have to create those 0.01 coins and destroy the 1.0 coin? This adds to the complexity and transaction cost.

Or is it going to be a case where the network looks for wallets with more than 100 of the 0.01 coins and “rob” that wallet giving that wallet the 1.0 coin for the 100 coins it robbed? What if there are no more 0.01 coins to be created? We need to plan for when the network is mature and people are dealing a LOT in the lower denominations. We cannot guarantee the availability. Its not like $$$ where the minting presses stamp out more when the circulating coins are low. In SAFE there would be a limit and the limit is not all that high for a world market. With 7 billion potential users and many more accounts/wallets the division has to allow for each to have many low denomination amounts. This is why I favor the balance idea since it allows near practically infinite divisibility

3 Likes

Actually on the point of planning for a mature network.

If there is only 4 billion coins possible then there is the real risk that there sill not be enough for 1/2 or more of the people to even have a coin.

So either the max coin count has to be increased by some method. Say increasing from 32 bits to more bits in the coin address, or have a supplementary coin for lower denominations. OR we adopt some sort of balance design where we can have 64 bit value hold the smaller than a coin amount in a wallet.

3 Likes

Using bitwise denominations, 4 billion safecoins gives about 66 billion ‘lowest denomination units’, so is only an improvement of about 15x, which is not a very big increase in divisibility. I think the idea possibly has merit even though the specific implementation in the OP is especially not useful.

Even though total safecoin is fixed at 2 ^ 32 bits, we can still explore the effect of increasing the number of safecoins to see how (in)effective bitwise denominations is:

total lowest denomination units = 2(bits-1) × (bits-1)

factor of improvement = (bits-1) / 2

So for example, using 64 bits would give 31.5 times more lowest denomination units than safecoins, which is still not even 3 extra decimal places compared to just using safecoin in the first place.

I think existing divisibility ideas are still the best way to go. But maybe the idea of bitwise denomination will help inspire some other thinking in the field of divisibility.

3 Likes

I guess my point was that if you have just 4 billion safecoins total. Who cares the worth of any of them, that still means that out of 7 billion people then at least 3 billion cannot get a coin. (assuming all the coins were issued)

This means that we need to move beyond 32 bits for the coins or have a balance system for wallets to hold the amount less than a coin’s worth.

So eventually everyone’s wallet would have coins and/or a balance for the “less than a safecoin’s worth” amount. Could even use your idea above so that we can have more than 4 billion safecoin’s worth in the system and leave the less than a coin’s worth for a balance in the wallet. This way every one of the 7 billion people in the world can have safecoin to transact (even if < 1 safecoin worth).

If you went to 64 bits then no need for your system as far as micro-transactions are concerned. This is ignoring the fact that I doubt the network could handle that. So maybe less bits and your system could handle it. Although your system still helps with large amounts (less transactions to send large amounts)

I think though that there is some worth in exploring a combination of your idea for >= 1 coin worth with balance for < 1 coin worth.

Of course this would violate the crowdsale agreement and destroy the 10% MAID somewhat. Any idea would need to have the total worth of the coins at 4 billion SAFEcoin’s worth in the short term and later on a mechanism that any increase in the numerical number of “safecoin” would also include existing coin owners having their holdings adjusted so that they have the same actual value.

2 Likes

These objects won’t be created at day one, but progressively when safecoins are farmed. Later they will be a balance between destroyed and created objects, but I recognized that there might be potentially a lot of objects.

With a safecoin around 20…30 cents ($ or €) the lower denominations I proposed earlier are not needed and the following table would be more appropriated:

| Denomination | Number of notes/coins |   Total value |
|-------------:|----------------------:|--------------:|
|        0,001 |       400 000 000 000 |   400 000 000 |
|         0,01 |        40 000 000 000 |   400 000 000 |
|          0,1 |         4 000 000 000 |   400 000 000 |
|            1 |           694 967 295 |   694 967 295 |
|           10 |            40 000 000 |   400 000 000 |
|          100 |             4 000 000 |   400 000 000 |
|        1 000 |               400 000 |   400 000 000 |
|       10 000 |                40 000 |   400 000 000 |
|      100 000 |                 4 000 |   400 000 000 |
|    1 000 000 |                   400 |   400 000 000 |
|        Total |       444 739 411 695 | 4 294 967 295 |

There are only 4.4 10^11 objects, Additionally, $250000 jackpots are better incentives for farming.

2 Likes

Yes good point.

I really was just pointing out where @digipl got his PB of MDs from.

Still seems an expensive (in storage) way to get division but interesting none the less

Technically I don’t know if this idea is easy implement, and it is not my role to discuss it.
What I can say is I find this idea fascinating.

Besides, I am pretty sure some of these coins will trade at a premium to others over the counter , especially the larger dénominations.

Something I didn’t quite understand is:
Will the higher denomination carry more data than the lowest one ?
Could you help me wrap my head around this ?

Its based on the OP

Each “coin”'s denomination is based on address. There is no data as such needed.

Each coin has the owner etc, but that is not strictly data

but then if there is no utility/data associated with coin, why would a coin denominated 0.01 worth less than one with denomination 1’000 ?

Economically speaking what gives more value to one compared to another ? scarcity ?
I don’t get it.

The SAFE software makes the distinction, since it handles the coins.

So a high denomination will buy corresponding more resources than a lower one. Also when wallets work out the transaction they know the difference.

Although if someone was to accept a 0.01 coin as a 1000.0 coin then thats possible I guess but they cannot expect others to do the same.

As you can read in the OP and @tfa’s posts the higher denomination coins are far fewer than the lower denominations. So scarcity is certainly part of it.

Maybe better just to think of it as with Fiat notes/coins. If the public wished to consider the 100$ notes as 1$ and the 1$ notes as 100$ then they could and the banks have little to say. BUT the banks will not give 100 x $100 notes for a $1 note will they. And that is the same for the network resources If this was to be adopted.

7 Likes

It does seem like increasing the address space is a good idea. We are running out of 32 bit IP addresses, and I don’t see how a successful SafeNET would avoid a similar problem. Obviously that could be sad news for people holding MaidSafeCoin, so the conversion rate would have to be adjusted.

3 Likes

I am of two minds over this. Increasing address space is an increase in transaction load but gives more physical coins that can be held.

Then compared to bitcoins 20 or so million coins, there doesn’t seem a problem and SAFEcoin has 4 + billion coins. It boils down to divisibility. When divisibility is introduced then the need for extra coins really evaporates. Although if the price/value of SAFEcoin drops to very low levels then there maybe an issue for external markets in that you need a lot of SAFEcoin to buy that cookie and there would not be enough to go around. So you would need more actual coins.

But we expect that the price/value will be much higher once its usability is established. And that means like bitcoin divisibility (thinking of balance method, but any should work) safecoin will have more than enough coins to do what we want.

Having said that I would be in favor of having 36 bits for safecoin address and the exchange rate being 1 MAID == 16 safecoin. Then implement divisibility. This increase in coins really helps while the price is very low, like now, because there is enough coins to actually go around and allow people to accumulate enough to buy useful expensive things off others using safecoin

3 Likes

For the mathematically challenged, 36 bits corresponds to 68,719,476,736 coins (2^36, or 16x the original proposed amount of SAFE, as neo mentioned).
I think that’s the simplest way of starting out at least.

3 Likes

68 billion coins seriously ?
that’s a lot.

I think that MAID is undervalued right now because of delays in delivering and it won’t help the image of the project if we don’t comply with terms of the crowd sale. Don’t like too much coin dilution and I think I am not alone. People will start comparing us to DOGE in terms of supply. :smiley:

1 Like

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

1 Like

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

2 Likes

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.

3 Likes