YASDI - Bitwise Denominations

Autonomi Network Token (incl (e)MAID)
1

Yet Another Safecoin Divisibility Idea

Bitwise Denominations

In the simplest words, coins with an address starting with 111 are worth half as much as coins starting with 1111 and twice as much as coins starting with 11.

For example

  • 50.0% of coins start with 01XX or 10XX so are relatively ‘low’ value
  • 25.0% of coins start with 001X or 110X so are slightly more valuable
  • 12.5% of coins start with 0001 or 1110 so are slightly more valuable again
    etc

The ‘rarer’ the address space the more valuable the coin.

So the number of consistent leading bits (either 0 or 1) determines the denomination of the coin.

A rough analogy:

  • 1 leading bit = 0.1c
  • 3 leading bits ~ 1c
  • 7 leading bits ~ 10c
  • 10 leading bits ~ $1
  • 13 leading bits ~ $10
  • 17 leading bits ~ $100
  • …
  • 30 leading bits ~ $1M
  • …
  • 64 leading bits ~ too much!!

Difficulties

Valuation

How much value does a wallet hold?

Before denominations it was simply ‘5 safecoin’.

After denominations it becomes more complex. 5 safecoins could be 5 ‘units’ of value, or 20, or 100, depending on the denomination of each of the safecoins in the wallet.

Similarly, a wallet with 1 safecoin may hold more value than a wallet with 1000 safecoin, depending on the denominations in each wallets.

The network should be able to easily look after all this automatically for the user.

Conversion

Conversion between denominations can be initiated by the user. Got too many low denomination coins? Convert them to a higher denomination. Need to pay for something cheap? Change a higher denomination coin to multiple lower ones. The network should be able to make this work automatically.

If the distribution of denominations is becoming problematic (eg one particular denomination is becoming nearly fully utilized), the network may provide incentives to convert to other denominations and balance the distribution of coins.

It may also be possible to reduce the use of many small denomination coins by making it expensive to convert to them.

Farming

The amount of resource provided can be directly related to the denomination of the coin being claimed.

Farmers can claim a low denomination coin with very little work, or claim a large denomination coin with a lot of work.

The network may incentivise ‘waiting’ to farm a higher value coin (thus reducing transaction load on the network) by accepting slightly less work for more valuable denominations than the normal conversion rate. But the incentive structure needs to be carefully thought out, this may encourage unwanted farming practices.

Trading / Exchanges

The price of a safecoin now becomes measured by some ‘standard denomination’, eg the price in USD is the price to buy a coin with 5 leading bits.

Market Cap

I’m not sure how easy / hard it is to work out the market cap with this scheme but it should be simple enough I guess.

Instead of

Price × total coins in circulation

use

Price × total denomination in circulation

Total Issued Coins

Like market cap, the total issued coins and denominations could be easily calculated. But it’s more complex than simply ‘the number of coins with owners’.

Terminology

The ‘standard denomination’ used to price safecoin would probably need a name other than safecoin, since safecoin is currently used to refer to the coin at an address. Whatever the case, there’s some language barriers to investigate.

Merchants / spending

Hopefully the network can totally look after denominations and the user just sees ‘value’ come and go from their wallet. Ideally they shouldn’t even be aware of denominations, and can just send and receive value as needed.

Divisibility

How do we talk about divisibility in this case? What’s the smallest unit? What’s the ‘standard’ denomination to use? I think there’s a need for some simple mathematics to determine the most usable parameters for this.

This is a very fresh idea in my mind and I just wanted to put it out for critique a-la ‘release early release often’.

Related: Yet Another Coin Idea

17 Likes
2

I like this idea because it solves the divisibility problem but also the multiplicity problem with power of ten safe notes: for example, to transfer 2350 safecoins, the transaction doesn’t need 2350 objects but only 10 objects (2 + 3 + 5).

There are many possible distributions, for example, the following one (with French separators):

| Denomination | Number of notes/coins |   Total value |
|-------------:|----------------------:|--------------:|
|      0,00001 |    40 000 000 000 000 |   400 000 000 |
|       0,0001 |     4 000 000 000 000 |   400 000 000 |
|        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 |
|        Total |                       | 4 294 967 295 |

The odds to gain a coin in the farming lottery could be inversely proportional to the coin denomination and winning a 10000 safe note would be like the jackpot. That would be a great incentive for farming, and when such an event occurs media would probably talk about it.

4 Likes
3

The idea is interesting but I see two important drawbacks. The first is that a small network could hardly handle such amount of information (we need several PetaBytes of MD). The second is the conversion of denominations.

The possible solution, to the first drawback, would be to activate the smaller denominations as the network becomes larger.
In order to calculate the type of denomination the bits of the sectors are added at the end. We could group them from four to four bits to have decimal denominations instead of binary ones.

In a perfectly balanced tree:
More than 16 sectors → activate first decimal
More than 256 sectors → activate second decimal
More than 1024 sectors → activate third decimal
More than 65536 sectors → activate forth decimal
More than 1048576 sectors → activate fifth decimal

(This is only one example, we can change the beginning, the numbers of decimals or the group bits size)

In this way we have several benefits:

.-The network is not saturated and the increase of coin MD goes hand in hand with that of Vaults

.-The first farmers have more possibilities of better rewards and encouraging the entry of new farmers.

.-The possibility of winning in the farming is high even if the network becomes very large.

6 Likes
4

I’m not sure where the extra PB of MD is required.

Bitwise Denominations uses exactly the same existing safecoin structure. The only trick bitwise denominations introduces is instead of adding a new field to store the denomination, the network can infer it from the Mutable Data ‘name’ property (referred to as ‘address’ in the original post).

So no extra data is needed to know how much each denomination is worth (relative to other denominations).

Considering at launch about 10% of safecoin will be issued immediately, this could be done within the 1110 or 0001 denomination since this name would have 12.5% of coins. Users could then convert them to higher denominations if desired. Doing this would reduce the number of safecoins on the network, but not the amount of value being stored.

Can you explain where the extra PBs of data is coming from?

I’m not sure what you mean by this. The bits of the sectors are implicit in the coin name field, not added. Can you please explain a bit more what is meant here?

1 Like
5

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

greater than 4.4 x 10^13 objects needed

2 Likes
6

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
7

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
8

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
9

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
10

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
11

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
12

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

13

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 ?

14

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

15

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.

16

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
17

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
18

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
19

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
20

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