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

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

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.


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

1 Like

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)


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:

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


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?

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


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.


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

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

SFE is a scam coin created a while ago to use the good name of the SAFE network to scam people. SAFEcoin does not exist yet.

1 Like

I may have missed something but any reason why we can’t just use 64 bit for SAFE coins? Most devices are there already and worst case we could have a virtual machine anyway?

That way we’d have
9,223,372,036,854,775,807 max supply of coins
2,147,483,647 max supply of coins

Don’t think we’d be concerned about divisibility anytime soon then. Everyone with 1 maidsafecoin would get 4,294,967,297 SAFE at the point of conversion to keep the supply percentages consistent.

Because each coin is an actual data structure stored on the network. And 2^64 data objects would be way over the top. Even 10% of that is super massive. I mean you would need prety much the storage capacity of the world to store them. 16000 billion billion bytes as the absolute minimum.

Then the transactions needed to send a small amount, because each is its own data structure that needs the owner changed on. So what is one safecoin now would be 4 billion transactions for 1$ worth.

This is where division by the balance method tries to strike a balance between 1 coin one data structure and divided coin to 18 decimal places.


Could we run in 64bit but find a happy medium that’s not necessarily as crazy as 2^64 but more suitable than 2^32?

@neo has hashed these details out with many people over the past few years. (recently myself included)
Search the forum for “divisibility”, this is just one thread of many and I’d hate to see it go off topic.

1 Like

ok tks for the answer! but when safecoin by maid will be launch people will be confuse about the names :confused: i have search many days, does someone know something about sfe, theirs devs or adress? :slight_smile:

1 Like

We know, there are already forum topics on the SFE issue. I think further discussions about SFE would be better in one of those topics. And you will find out what is being done about it there

The current safecoin proposal already uses a u64 int to hold the 32 bit address.

If you read the first few lines of the OP, this isn’t the topic for that concept for a solution. But the major issue is storage space and transaction rate, which would limit expanding the 32 bit address space for safecoin. Also people paid a lot of money on the condition of what SAFEcoin will be and when this expansion of #coins was suggested as a real possibility the howls from some was definite indeed. So it is fraught with danger to go down that path. And each time you increase the #coins the problems appears again and you have to increase again. Cannot increase to say 48 bits straight away because there is unlikely to be the storage for the initial 10% of 2^48 coins let alone any data.

We wouldn’t need to go that crazy but a couple of billion is a little low. There might be some concerns (I’d like to hear them though) from the community however if we do a poll and it’s unanimous then we should seriously consider it.

2^32 → 4.2949673 Gigabytes of storage (this is nothing, even when the network is small)
Safecoins max supply:

2^38 → 274.877907 Gigabytes of storage (still not ridiculous)
Safecoins max supply:

2^39 → 549.755814 Gigabytes of storage
Safecoins max supply:

2^40 → 1 Terrabyte (maybe getting a little excessive now but still manageable considering this is to hold all currency globally that will ever be in existence)
Safecoins max supply:

Personally I’m leaning with 2^39, keeps things simple, 1maidsafecoin becomes around 100 safecoins at conversion and half a terrabyte is a reasonable amount of storage given not everyone has to store it anyway.