That sounds good 
One last question, you said earlier that
How then does one keep track of the coins they have, especially if they have quite a number? Is it the client that knows and only it knows?
yes, the client needs to store that information encrypted on your account
1 Like
cheers @neo and all the others, this was quite an interesting discussion I learnt a lot from all of you. Thanks. Im signing off though for tonight. This has cost a few hours of routing work, and there still is work to be doneā¦ @Viv is going to kick my *** tomorrow 
5 Likes
I mean groups of people can companies that deal with much data.
1 Like
Interesting concept.
It is a bit like my travel card - I feed it pounds and it returns journeys. It could definitely work well.
However, I do wonder whether this is all adding complexity to circumvent a problem of having currency units which are too large. If we just had smaller units to start with, we could just have an integer representing network credits on your account, which map directly to safecoins.
While I understand that having units which are very small also makes trading them a bit unwieldy, we can group these smaller denominations together and call them larger denomination names (e.g. satoshis vs Bitcoin, but on the other side of the decimal place)
I also understand it could make transfers more chatty as transactions would be made up of many micro-penny sized transfers. However, this may be a price worth paying for simplicity, especially as it would give an easy āout of the boxā solution for micro payments.
We will have a single opportunity to set the denomination size at the start and everything beyond that point will have to work around this. I think we need to be very careful not to create a rod for our own backs.
2 Likes
It is fun to have a comment launch a long discussion over stuff that matters. 
The āChatty transactionsā issue seems like it could be an issue. At a penny a coin, If I want to spend 10 bucks that means 1000 coins and I am going to need consensus from 28000 managers. With latency etc, it seems like they would come down rather randomly like pennies going into a vending machine slotā¦ Probably not a big deal unless you have several transactions occurring at onceā¦ Its also not quite as crazy as having every transaction confirmed by a network larger than the 500 biggest supercomputers or whatever, but still quite āChattyā
1 Like
The inflation problem could be avoided using the minting function. Instead of āreturning that Safecoin to the network for renewed farmingā, the Safecoin used in a variable account are āFrozenā in a minted Safecoin. This minted Safecoin are hold by the ClientManager group.
As a mInted Safecoin is an open transaction without a designated recipient anyone may ask re-convert an account value into standard Safecoin.
I wonderā¦ Would it be possible to group pennies into coins, with the group representing the Safecoin, rather than the actual pennies?
In this could be achieved, the group could essentially be a structured data type, mapping all the pennies associated with it. Then, to transfer a bunch of pennies would be just a case of transferring the Safecoin group structured data element.
In theory, this could mean that larger payments would be far less chatty, while retaining micro payments at the network level (i.e. accessible to any app, without an interim token system). You could start with 2^64 or some super high number too then.
Perhaps the pennies themselves would never even need to move, with just the Safecoin group element moving instead?
You could also sweep pennies from other groups or split them up. Potentially, you could create a group with the exact transactional value (say, 3999 pennies) , prior to transferring it to someone else.
Would this be possible/feasible and has anyone looked into it as an option?
Edit: to add, I think the chatty part would at least be distributed without any of the above. I suspect that it would scale well, even if there appeared to be a lot going on.
If I remember correctly, the amount of resource you get when you convert a Safecoin is dependent on the rate of the network and the cost in resource of putting data stays the same. If Iām correct, why isnāt it the other way around? The amount of resource you would get stays the same but the cost of putting data change based on the rate of the network?
This way, you could convert back from resource to Safecoin without ever gaining any benefit and also send your resource to someone else to pay as a micro-payment without the risk of creating arbitrage opportunities?
1 Like
Thereās a problem with this approach. When the network has used a 1 Safecoinās worth on Put actions itās necessary to unfreeze one Safecoin. Not only when another user that wants re-convert an account.
true, the āfuture-acting SDā brainstormed about above can solve this, but they would need to keep more state, which is undesirable for a long-lasting state, such a client account.
Will there be only an account balance (as double or another type), or a chain of annotations similar to a ledger?
A chain of annotations has the problem that could overflow the capacity of a StructureData. And an account balance could have security problems of ārepeatā attack and double spending.
you can keep a fixed-length history of the account 
which actually isnāt a bad idea at all
@BenMS - what do you think of this: Safecoin divisibility - #48 by Traktion
Curious to know if possible.
Iām wondering if in this case it is not easier to flip the problem around. Itās not possible to ask the network to exchange 100 pennies for 1 coin. Even if the math adds up; the network cannot guarantee to mint a coin on demand, nor can we violate atomic actions otherwise double spending is possible.
So only an exchange is an option. To achieve this youād have to put all pennies in a locked escrow state (owned by you, your counterpart and a ājudgeā); your counterpart also needs to put his safecoin in the mirrored locked escrow state. Both parties can verify this.
The open question is then, who will be the judge. It can either classically be a trusted party or exchange. The interesting question is whether we can have the network be that judge. We can imagine using the group consensus, but it is not that simpleā¦ this is where I crash; the furthest Iāve gotten.
Note that you can put all your coins in a new account, and instead of transferring the pennies/coin, you can pass on the private key; very efficient, but very unsafe.
1 Like
Why is this not possible? Iād have thought that if pennies can only be issued in exchange for a Safecoin its fine: I want pennies, I sign over a Safecoin to the network and the network issues me the pennies. The network holds the coin now, where it sits until someone signs over the requisite number of pennies to obtain a Safecoin.
Obviously this needs everything that handles Safecoin transactions to be able to mix and match with pennies, but in theory at least it appears possible?
Im not sure it is possible in theory (at least within the current logical framework established); some problems:
- the network canāt deterministically mint new coins/pennies; itās a probabilistic process - not sure you want to burn 1 safecoin to get 98, 74, or 13 pennies, based on the current penny-farming rate
- every element of information involves (at least) one group; so converting 1 safecoin to a 100 pennies, requires minimally 101 (or a multiple of that if itās a multi step process) of groups; so weāre talking 3200 nodes involved;
- for the network maintaining a safecoin is maintaining one structured data element; maintaining one penny is maintaining one structured data of similar size. The overhead cost for pennies is 100 times bigger than for safecoins. This is not a question of overloading the network, but a question of inefficiency.
I can only state that for a long time have (most of the preceding year) have explored the issue of fractions of safecoin; I actually coined them atom coins, being a 10 billionth of a safecoin (but then the inefficiency is even worse ). I have diverted from this path currently; I donāt see it as advantageous until safecoin is far too expensive for normal people worldwide to use
7 Likes
Of course the other issue is the total number of SAFEcoins. If as we would like, the network grows to having a billion or more people/accounts then the number of SAFEcoins will become an important factor.
Imagine having only 4 SAFEcoins possible per account holding coins.
Even 100 million people presents an issue with only 43 coins possible per person. There will be many with their 10s or even 100s of thousands of coins hoarded.
I am just saying that the price will not be the only determining factor, since the price could be a mere few dollars at that time.
1 Like
Could it be possible that when a SAFEcoin is split into pennies (100 or 1000 or 10,000 or ???) it is frozen by the system and when one wants to convert back to a SAFEcoin then a FROZEN coin is transfer to that person. There must always be enough SAFEcoins to match the number of pennies out there.
So even if a āpennyā is 1 millionth or less there will not be the total number possible in existence but rather a much much much smaller number
If people āloseā their pennies then the equivalent in SAFEcoins of those lost will effectively be lost too.
3 Likes
My thought would be to make the network currency a much smaller unit from the start. If we anticipate having to split coins in the future anyway, why not just get this out the way now?
Even this initial use case for network usage is hitting an issue with the smallest denomination being too large, which makes me think there will be many other use cases. Do we really want to deal with the complexity of having smaller, per app, credits in many places to deal with this?
Moreover, my idea of groups wouldnāt be so much that 100 micros make up one major denomination. It would be more that the groups could be any number (1 to x). The primary intention would be to always transfer using groups (of any size) rather than using the base currency directly. The intention being to reduce the network traffic as well as provide a convenient way to represent groups of small currency units.
I know that currently the actual safecoin move, but I suppose I am wondering if that is needed. Much like chunks are just referenced by the data maps, couldnāt safecoin just be referenced via heir assigned group?
I donāt understand the low levels enough to know whether this is a great/terrible idea, but it could potentially mean that a transaction of any amount (1 or 99999999 etc) would always just be a single operation - just the group could be assigned to another account. Likewise, the groups could be split up, re-formed etc, to suit the requirement (e.g. 100 coin groups may be convenient).
Just thoughts anyway, but not having small enough change is very much an economics problem and one we will hit quite soon, I think. Having ways to group tiny units may be simpler than attempting to split large units after launch.
Edit:
Maybe a clearer way to explain is having a CoinContainer, which coins can be put in. Transactions would always involve transferring CoinContainers, rather than the coins themselves. CoinContainers would contain 1 to X coins.
3 Likes