YASDI - Bitwise Denominations

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

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$

2 Likes

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.

4 Likes

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.

2 Likes