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.
-
non-existant
Self describing, No SAFEcoin MD object exists for the coin address -
active
Coin exists and has the owner address set to a wallet ID. -
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
-
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. -
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. -
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 -
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