Proposal for SAFEcoin division - read datastructure topic first - please discuss

Autonomi Network Token
1
Topic is for the discussion of the particular method for division. Discussions &/or proposal of other methods, such as denominations are for other topics and replies will be moved. Thank you for your understanding

This topic is for discussing the division of SAFEcoin using a method suggested around Easter last year and similar to Rene’s more recent suggestion

The purpose of the discussion is to help formulate a RFC for SAFEcoin division.

Link to datastructure topic Proposal for "wallet" data structure - please discuss

Proposal for SAFEcoin division

When a SAFEcoin is divided, it is “frozen” and the parts will be stored in a balance field located in one or more “Wallet master MD”. Please refer to my suggestion for the SAFEnetwork “Wallet” data structure topic.

In essence when sending part of a SAFEcoin the partcoin amount will be sent to the receiving wallet and added to the balance field. The sending wallet will have its balance reduced by the amount sent.

NOTES: An Account can have many public/private IDs and each of those can have a “wallet”. An Account can also have any number of “wallets” not associated with a public/private ID.

The procedure for an APP sending SAFEcoin to an ID would become

###Terms

  • “Receiving_ID” The ID supplied by the receiver for the sender to send the coins to. This ID must have a SAFEnetwork “Wallet” setup for it. The ID can be a public/private ID or simply a “wallet” ID
  • “Sending_ID” is the ID of the “wallet” sending the coins.
  • “coin” is SAFEcoin.
  • “partcoin” is part of a coin
  • “APP” For the purpose of this description refers to the application that is being used to send the (part)coins
  • “wallet” refers to the Wallet Master MD
  • “wallet.balance” refers specifically to the divided coin balance in the wallet.

###APP Sending process (pseudo code)

if insufficient funds in sending_ID.wallet
{
    ABORT
}
if exists(receiving_ID.wallet) == FALSE
{
    ABORT
}
if transaction involves part coin
{
    if (sending.wallet.balance < send.partcoin)
    {
    Select coin from "wallet"
        API call to divide the coin
    }
    API call to send partcoin
}
for 1 to number coins to send
{
    Select coin from wallet
    API call to send coin
}

###APIs

Divide a coin
    Supply  - coin address  (owner ID must equal wallet ID)
            - Wallet ID
    Results - coin is "frozen"
            - one coin's value is added to wallet.balance
    Returns - success or failure          
.
Send partcoin
    Supply  - sending_ID.Wallet
            - partcoin amount to send
            - receiving_ID.wallet
    Results - Sending_ID.wallet.balance reduced by partcoin amount
            - Receiving_ID.wallet.balance increased by partcoin amount
        - If receiving_ID.wallet.balance > 1 safecoin value then a coin is unfrozen 
              and given to the wallet & wallet.balance is reduced by one coin value.
    Returns - success or failure
.
Send coin (Existing proposed API)
    - transfers one coin from one wallet to another.

###The requirements for additional core code to implement divisibility

The divisibility method here requires similar processing of the balance amount as is used for the secure processing of safecoin transfers. At this stage I have not quantified exactly which managers will handle which function.

The network will have to have “wallets” to hold a balance of a divided coin for the purpose of paying out rewards. If a “wallet” does not currently exist for the ID, then the reward payment will use the payment to pay for the “wallet” Master MD creation. Payments fail if the partcoin balance is at max value. The wallet.balance could hold just over 18 coins worth for the suggested u64 & 1/10^18 minimum amount

The concept of “frozen” coins has to be introduced as a third state of a SAFEcoin.

  1. non-existant
    Self describing, No SAFEcoin MD object exists for the coin address

  2. active
    Coin exists and has the owner address set to a wallet ID.

  3. frozen
    Coin exists, but is flagged as “frozen” which means that its value is held in various wallet.balances

The “frozen” coin owner is the network (Group wallet).

In order to store to “frozen” coins there will need to be one or more wallets owned by the network.

I propose that a suitable system is to have each group “owning” one or more wallets. The reason why multiple wallets might exist is that groups may recombine. If this is a problem then there would be a single wallet for the whole network. The advantage of each group having its own wallet is that less packets/transactions are needed for processing.

When a coin is requested to be divided (basis of API to divide a coin) then processing for the group would be

if request valid
{
    API call to transfer coin to group's wallet
    Mark coin as Frozen  
    Add one coin's value to requester's wallet
}

I propose that the API call to transfer coins requires that “frozen” coins need the request to be validated as coming from a group.

Now the basis for transferring a partcoin is

Validate the request (valid requestor, valid receiver, sufficient funds in balance, etc)
if Invalid request
{
    Abort with unsuccessful result
}
Using atomic process (similar to SAFEcoin transfer)
{
    Subtract the amount from sender_ID.wallet.balance
    Add the Amount to the Receiver_ID.wallet.balance
}
If Receiver_ID.wallet.balance > 1 safecoin
{
    Atomic process
    {
        Unfreeze one coin from Group's wallet (simplistic process as the actual process needs to recursively find a frozen coin from other groups if the group has none)
        Reduce the Receiver_ID.wallet.balance by 1 SAFEcoin worth
        transfer the unfrozen coin to the Reveiver_ID.wallet
    }
}

##Reasoning and considerations

  1. wallet.balance is proposed to be a U64 value.

    32 bits only allows nano-SAFEcoin upto 4 coin’s value. While this would provide a divisibility solution that is 10 times more than bitcoin, it cannot allow minimal rewards payments to be directly paid to a wallet.

    64 bits has no more complexity than 32 bits, allows divisons as low as 1/10^18 but does allow for minimum reward payments and way beyond any reaonable part coin amounts for normal transactions between entities.

    In addition it would be suggested that the minimum SAFE reward be set to 1/10^18 to allow the extra flexibility and only represents a minor difference to minimal reward being 1/2^64

    Having the division as a decimal rather than a binary division means it is human understandable and the way humankind is taught from wee children. The only restriction to the core code is to have minimum SAFE reward as 1/10^18th of a SAFEcoin.

  2. It is proposed that a limit is placed on the size of part coin being sent. And SAFE Rewards can be any size.

    Send partcoin is limited smallest amout. This amount can be made smaller with a update to the core code when there is a need for smaller amounts. The added benefit to limiting the smallest amount is network load when people/IOT are sending very small amounts, the larger the network the better it can handle the quality o transactions when sending minimal amounts.

    Applications that work with or display the wallet balance can display the amount in either the decimal value or a form of denominations or even fractions. It would be expected that APPs would respect the user preferences stored in the wallet datastructure.

  3. It is proposed part coins and potentially all coins can only be sent to an existing wallet.

    The reason for this is to reduce accidential and/or malicious sending of coins and/or part coins to a non-existant ID.

    This ensures that there are no mistakes when sending (part)coins.

    It also help protects against the malicious sending of minimal amounts to (random) IDs in order to cause a flood of transactions which will clog up the network. Now the attacker would have to have wallets set up before hand to receive these small amounts. This setup costs at least one “PUT” cost and there has to be a multitude of these wallets because the network places limits on the rate of sending of coins.

    In effect the attacker has a significant cost to create the huge number of wallet master MDs or have the rate of sending limited. Either way the success of the attack is reduced to ineffectual or very expensive.

    In addition by implementing the limit on the smallest amount that can be sent, cost of the attack is multiplied by perhaps 10^15 times while the smallest amount is 0.001

  4. It is proposed that SAFE rewards be paid using divided coin and payments for network resources (eg PUTs) is paid by divided coin.

    Only change to current proposed calculations for SAFE rewrds is to limit the smallest amount to 1/10^18. This implies that GET rewards would have a minimum of 1/10^17th of a coin and ptd/ptp rewards would have a minumim of 1/10^18th of a coin.

    It is hard to see any need for SAFE rewards to be smaller than the above proposal when the current proposal is to be 1/2^64th of a coin and it only this value because FR (GETs/coin) is calculated using U64 precision.

    There is not a problem with paying minute amounts to a wallet.balance while the smallest transferrable is relatively very large (eg reward 1/10^18 and smallest transferrable amount is 1/10^3 or 1/10^6). The rewards will eventually add up to a usable amount and it allows the user to see his/her balance invrease for each successful GET from their vault. Also it is proposed that paying for resources is also not limited.

    By paying for each GET removes the situation where probability states that there will be the potential for some very unlucky people (vaults) to receive way under the network average. This variance is removed.

    Also the scarcity issue solved by only rewarding a “lottery” win when the coin does not exist, can still be implemented by a very similar system.

    The idea is that when a new coin is needed a pseudo random address is generate (something like as it is in the current SAFEcoin/reward proposal).

    This means that rewards are paid if the coin was created or not paid if coin existed. So coin scarcity will still reduce reward payments as it currently proposed.

    • the address is tested and coin created if possible.
    • If coin created then it is divided and stored in the group’s wallet. And the frozen coin is added to the groups wallet.
    • if coin is not created then a “pseduo balance” is set to one coin’s value
    • When a reward is to be paid by the group it is either paid from the divided balance or simply reduces the “pseudo balance” by the reward amount.

Considerations for using division to pay for PUTs/resources

While the procedure is simply the group transfers the PUT/resource cost to the balance in (one of) the group’s wallet. This would then increase the balance for farming payments, without the need that any coin was “lottery” created.

The issue is not whether its financially sound, because it is. But the issue is the “lottery” creation of new coins. For example if sufficient PUTs were occurring then the payments for rewards would be funded directly by the funds received by the group for PUTs/resources.

It maybe splitting hairs, but could this cause some issues when the SAFEcoin is scarce?

No matter, this can be solved rather easily if it is shown to be a problem with the scarcity “lottery” creation. Because all that is needed is a special field for Group “wallets” similar to the extra field for the pseudo balance for failed “lottery” attempts. So payments would be added to the wallet group receipt balance rather than the normal wallet balance.

Irrespective of which method for receipts is adopted the processing would include the test for the balance being greater than one coins worth. When the balance is > 1.0 then a “frozen” coin is destroyed.

The current SAFEcoin proposal is for payment of one coin the account gets a PUT balance and the coin is destroyed. By doing it with division each PUT is paid for at the current rate and a coin is destroyed when the cumulative total of PUT payments from all Accounts using that Group reaches one coin. This is a smother solution and saves the requirement of the group maintaining a “PUT balance” for every Account connected to the group especially if some accounts only PUT occasionally. The current system could see these “PUT balances” being kept for months for the accounts that rarely do PUTs

22 Likes
2

Have you considered writing an RFC? Or are these all drafts of a future RFC, once SafeCoin has started being developed?

1 Like
3

I wanted to discuss the proposal first and also I will need to ask knowledgeable people about the requirements for the inner core workings.

Yes

Personally I am thinking that since MDs have been developed it simplifies the storage of partcoin balance along with indexes etc in one “Master MD”, that we could even consider the implementation of divided SAFEcoin with the implementation of SAFEcoin itself. Because of the benefits it brings with direct reward payments and payments per PUT rather than the specialised processing that was being proposed currently.

5 Likes
4

One other thought is that for group "wallet"s the so called Master record could be memory based so that there is no fetching the MD on a constant basis. There is no need for that record to be stored and this makes merging groups and their balances much easier and straight forward.

6 Likes
5

Heh. I actually had a same line of thought just like yours. I was working on it on my free time in the last week. Studying the SD again, and other concepts. I nailed it. Now I just need to write it out… And then I saw your post. Then it hit me…This actually applies in more areas than just safecoin. Mine is for a different purpose. It is part of the Micropet DNS, and bitID concept.

Good job writing it up, neo. :slight_smile:

edited: oops, this was for the proposal SafeWALLET topic. oh wellz.

6 Likes
6

Extreme scenario: one coin is split into 10e18 pieces

To transfer one of those pieces a pretty impressive amount of data would need to be processed - wouldn’t it? One piece being one byte of size that would make one exa-byte…?

This distribution is very unlikely but I was a little bit surprised nonetheless when I thought about it …

1 Like
7

The effort to transfer that is the same as transferring any other value. Its one transaction**

The coin is not split into 10^18 pieces

If you had no balance in your sub-safecoin balance then one of your coins is sent to the network to be frozen and added to your balance. So your balance becomes 1.000000000000000000 (max balance can be) then one transaction to send 0.000000000000000001

Then your balance is then 0.999999999999999999

** can be a couple more if a coin is required to be frozen in order to have some balance in the sub-safecoin balance.

1 Like
8

Ah - sorry I was just having micro ledger in mind but the coin itself is a part coin so easy to transfer :hushed: okay - I really need to read all details before I ask more questions xD sorry…

9

For this its not a coin or note being sent but the core code treating the wallet MD (reserved tag type) as a special item. So the sending wallet’s MD has the value removed from its balance and the receiver’s wallet’s MD has the sent value added to its balance.

This way there is no added data structures needed and only one transaction needed.

The spamming of ultra small amounts is limited because of the need to pay for wallet creations. And we may have to introduce a PUT charge to send sub-coin amounts to also help prevent this ultra small sub-safecoin transfer spamming. But that somewhat kills the completely free safecoin transfers.

1 Like
10

True but that cost should be so small nobody would even notice - wouldn’t it…?

Hmhmm - what if 3 people come up with part coin representing 50% of the same coin? =O
… Okay that is part of the implementation when I think about it…

Edit: Oh sorry - there is no connection anymore between the coins and their origin… Stupid me… I just read through your proposal very roughly the other day… And thought the ledger would be connected only to the coin not the owner

1 Like
11

Well a PUT charge is perhaps bigger than the minimum possible sub-coin amount of 1 x 10^-18

In any case my proposal has a limit to how low you can go built into each version. So that will mean when the network is small the limit might be 0.01 and later 0.0001 and so on. As the network can handle more transactions across the network this figure could be reduce to micro then nano and never really get as low as 10^-18 since that is a unintelligible amount to a human except on a conceptual level. But if the network has all computers as nodes then it might.

They cannot. EDIT: just saw your edit so the rest is for others now

To get a sub-safecoin balance or when you want to send more sub-safecoin amount than you have then you have to ask the network to freeze one of your coins (You send the coin to the network in effect) and it then updates (adds to) your wallet’s balance with the equivalent of 1 safecoin (1.000000000000000000)

Thus there is no splitting or coins owned by two or more people. You surrendered a coin to the network and the network becomes the owner and freezes it so the scarcity model of farming rewards success rate is not affected and so there cannot ever be more than 2^32 worth of safecoin existing in circulation. Frozen safecoins are not in circulation and are not counted.

A frozen safecoin is released (sent to) a wallet when the wallet’s balance exceeds one safecoin worth when an amount is added to the balance. This way there is only ever less than or equal too one safecoin worth in the balance and ensures there is the minimum amount of safecoin frozen.

2 Likes
12

Thank you very much for the explanation!
I’m glad my first impression of the idea was skewed =D

1 Like
13

Yes its a real different concept to denominations and often we are thinking of the concept of one data object per value. But this proposal says one data object per sub-safecoin amount is impractical and makes the sub-safecoin an amount in a special MD for wallets. And the advantage of a special MD for a wallet is that the core code can update it without needing to search because the MD’s address is the wallet’s ID (sender/receiver IDs)

2 Likes
14

Could you provide a link to the “datastructure topic”? I can’t seem to find it when searching on the forums.

Thank you! :slight_smile:

15

Wow I did forget to put the link there. Thanks, its there now in the opening post.

2 Likes
16

A few questions came to mind:

  • What happens when the fiat price of SC is so high that an individual cannot purchase one, or in the limit if nearly all safecoins have been frozen? Doesn’t this mean that all transactions would need to be done via wallet to wallet transfers using the uint64 partcoin?

  • If you are going to end up with nearly all frozen coins in the future, and this method is as safe as classic safecoin, why not just freeze them from the start and use your proposal for all transactions day 1? (perhaps using a 2^128, 2^256, or 2^280 bit integer) Is the ico the only reason for not doing this?

EDIT: Perhaps some of these questions may have been addressed here?

17

I seem to have seen this question before or did I dream it?

Anyhow it is unlikely to see all coins frozen.

  • coins are unfrozen whenever any one person accumulates more than one safecoin
  • If the $$$ price is so high then I suspect (through updates) that payments for resources can be made in divided coin amounts (divs) (wallet to wallet)
    • Then the coins will be unfrozen then destroyed as soon as payments that have been made exceed one safecoin’s worth.
    • This would mean coins are unfrozen often and farmers are still rewarded one coin if the farming attempt succeeds
    • Another option will be that (thru upgrades) a system is provided to transfer “PUT” balance from one person to another. A sort of alternative wallet-to-wallet system. The advantage of this is that we can have a market for “PUT” balance too. This can only work when the network is huge to reduce the problems of gaming the network, since things should be more stable when the network is huge. I think its safe to assume the network is huge if $$$ price is huge.
  • If the $$$ price is massively high then I guess farming will convert to being paid in divisions too (wallet-to-wallet) and effectively the network transitions to a wallet to wallet transfer system.
  • once divs are accepted for payment for resources the it will be possible for people to spend 1$ for so many divs and use the network.

I would expect though that when the $$$ price is large to huge, then the network is large/huge and creating 1000 times the coins could be viable. The network will need to be huge to accommodate that many coins. If we go too large then the network is using a lot of its space just to store coins, so the network has to be an appropriate size before that time.

Then the network does a “version” upgrade of coins & wallet data structures and whenever a wallet performs a transaction using the divs value it is upgraded to the next version. This version causes the balance to be multiplied by 1000 (this example) and the “whole” portion of the number is converted to the new coins and the decimals becomes the new divs_v2. The frozen safecoins_v1 will slowly be replaced (destroyed) as the old divs_v1 are returned to the network.

If you send a SAFE_coin_v1 then the receiver gets 1000 SAFEcoins_v2 and the V1 coin is destroyed.

Effectively the network will be accepting safecoin_v1 and SAFEcoin_v2 for payments and only ever giving out V2 coins

Now another way to deal with this is to effectively make SAFEcoins obsolete and go to a pure “balance” system where everything is wallet-to-wallet. Basically don’t change anything other than accept payments in divs and give divs out for rewards.

Even using the predictions it will be decades before we see 90% of coins existing. Using the division system I suggested this will still be the case since coins are unfrozen. This would mean until the price for one coin is excessively high the network will still operate reasonably well and plenty of coins available for rewards and plenty of unfrozen coins.

The major shift will only occur when divs are accepted for resources payments where people can then just purchase as many divs as they need from a friend or market place. But even then coins are being unfrozen all the time as the people buy resources.

To have 2^64 divisions means that even if a coin is worth 2^9 dollars we can still do nano-dollar payments.

I doubt that the network would ever in its wildest dreams see the coin worth a billion dollars per coin in the networks lifetime. So I’d say SAFE_V2 would be brought out before then. And so 64 bits for the balance amount seems to be reasonable for the life of SAFE_V1

3 Likes
18

Thanks for the info. I’m warming up to balances and becoming more “denominations” averse. When it comes down to it I think I’m just a “classic safecoin” kind of guy… but still have some mulling over to do with regard to some of your various pro/con balance method arguments posted throughout the forums before I can add anything to the conversation.

Yes, that’s what it seemed would be in the limit case, based on different bits and pieces I’ve gathered throughout the forum. So thinking in terms of eternity (not that I expect people to be so idealistic), it seems like if this is the eventuality of your proposal then the most logical thing would to start doing it that way from the very beginning. I’m trying to understand why your proposal even needs safecoin for freezing to begin with… you’ve given me more to think about though.

2 Likes
19

To be honest I love the denominations idea.

But I also love the idea of faster than light travel and time travel. Just we cannot do those things now and probably have to have a lot more science and technology before they can. And the same for SAFE, we need a lot more than SAFE has to make denominations a great idea.

Don’t get me wrong this proposal may go through a revision again to make it even better as features are added to SAFE.

But in no way is it an eternal solution and has the constraint of 2^32 physical objects as coins to work with.

I expect (& firmly believe) that by the time we are even half way to the limiting situation, that a SAFE_V2 will have been developed using the ubeaut technology of the day (maybe quantum elements too). This SAFE_V2 would have a new way of rewards and transfer all the data over to it and convert people’s coin holding into the new “coin” system

But its good to know that even if SAFE_V2 never eventuates (almost impossible case) then even at the limits it will still operate efficiently

20

hi, when you talk about safecoin, is that SFE? doest safecoin SFE hace someting with maidsafe?