Safecoin divisibility

Development
141

Agreed,

As a consumer, it would annoy me to “manually” convert Safecoin into smaller divisions each time I pay for something. I just want to pay whatever the amount is, big or small, including micro payments.

As a tech analysis, every element (routing, caching, Safecoin transactions, messaging, group consensus, node managers, client managers, NAE managers) adds to the Networks burden. Individual grains don’t seem like much. But they are able to collapse structures if enough pile on.

The only way I know how to satisfy both (consumer and engineer) is by using a ledger system on the front end, and unit system on the back end. However, it’s hard to implement a conversion system that doesn’t add complexity. We’ll as far as I know, I haven’t seen a solution to it yet…

With Solution #2, I could push X Safecoin (Checking) that I plan to spend each day, month, year, and still have the comfort knowing my Safecoin (Savings) is secure. If we create an automated system, removing the need to manually convert (Savings <~> Checking), that would be even better!

Here’s a brainstorm idea for an automated conversion “integrated” into the transaction process. It uses a ledger front end, and non-divisible data unit back end. I think it adds a little more complexity but may reduce transaction workload while providing divisibility.

[Transaction Process Under the Hood]

Buyer’s balance = 10 Safecoins.
Buyer sends 3.50 Safecoins to the seller. (3 Coins + 0.50 Ledger)
Buyer signs 4 Safecoins because the Network can only transfer whole units of Safecoin. (3 Coins + 1 Ledger)

  • 3 coins transfer to the seller like normal.
  • The 4th coin converts to a ledger balance and obtains a new status called F (Frozen).
  • This means the coin cannot be farmed, only converted/claimed via ledger balance.
  • 0.50 ledger goes to the Buyer, and 0.50 ledger goes to the Seller.

Seller’s balance = 5.75 Safecoins (5 Coins + 0.75 Ledger)
Seller received 3.50 Safecoins (3 Coins + 0.50 Ledger)
Seller’s new balance = 9.25 Safecoins (8 Coins + 1.25 Ledger)

If the ledger balance becomes a whole number, the Network will automatically convert/claim ownership of a coin from the F (Frozen) pool. This happens in the background.

Buyers final balace = 6.50 Safecoins (6 Coins + 0.50 Ledger)
Seller final balance = 9.25 Safecoins (9 Coins + 0.25 Ledger)

… … …

Instead of making Safecoin subdivisions or different Safecoin tiers (mSC, nSC, etc). Both end users only see their Safecoin account balance in decimal form. But under the hood, the “decimal” portion of the balance will be a ledger, while the “whole numbers” are kept in actual Safecoin units. I think this allows infinite divisibility without the added workload transacting thousands of micro coins units.

The end-users don’t have to manually convert anything.
If possible, we can have our cake and eat it too!

6 Likes
142

the cake is a lie ._.

4 Likes
143

How would this handle attaching context to coins, e.g. coloured coins?

Being able to treat every coin as literal digital property is a very powerful concept. If we are converting from one format to another, we are going to lose these 1-1 mappings, which will limit what can be done with them.

If the network can cope with micro payments from the outset, with every micro penny being treated as immutable, identifiable, property, then it will only get easier as the network grows. With each new vault added, the load will be spread.

Moreover, is the burden of updating ownership on 100,000 chunks worse than serving a 1 MB file? How about 10 MB? If it is less onerous than even the latter, it would seem a perfectly reasonable trade of. Even if it meant a transaction fee was needed (to pay farmers for processing the transactions), it would still seem reasonable, IMO (as long as it isn’t excessive - this is why we need a to test though, imo).

2 Likes
144

Just a general point too - many people are interested in safe net, primarily because of Safecoin. It is what encouraged many to invest. It is what many people are waiting for.

For those who didn’t come from the Bitcoin community, this may seem strange. When safe net promises so much, why would people be so obsessed with just the lubricating tokens?

While the network itself has potential to change the internet, the desire to nurture a better crypto currency should not be dismissed. This is a very important feature of safe net.

3 Likes
145

Unfortunately, it would break the colored coin.

Yes it is powerful. But I think we should create alternative SD for that purpose and keep our Safecoin currency clean.

I hope this holds true in the long run.

Yes, we need to test and find out the Networks limitations.

146

100% …(character limit)

4 Likes
147

I would think everyone would like to have Safecoin with a high value. But even if Safecoin becomes just $1.00 (which I think would be fantastic), wouldn’t it make using the services of the network too expensive? The utility of Safecoin is better if the price is low… So are there plans to make Safecoin divisible? I don’t see how Safecoin can have a high value and also be usable on the network otherwise.

1 Like
148

The ID of a safecoin is 64Bytes long, with the most meaningful 32 bits being sequenced index starts from 0 to 4294967295, and the left over part to be fullfiled with all zeros or other pre-defined pattern (to allow coin division).

I think it will be designed that we can always use SAFE even if the price goes to that magic number you named ;-). If the price goes up, a lot of new farmers will join the network to Farm coins. That causes the Farming Rate to go down. So you would get paid less when you deliver chunks. Should all balance out nice.

1 Like
149

Does a ledger imply a blockchain? Meaning that there is a record of transactions that can potentially be traced by ‘bad actors’?

re: worth brainstorming …
Instead of one centralized account, create three that must verify against each other (2/3) before moving anything in/out of these accounts [the network would have special rules for these accounts]. It’s unlikely that more than one account could be hacked simultaneously and the network can regen new keys for these special account regularly to prevent more than one from ultimately being hacked.

1 Like
150

No the ledger is basically a single data unit managed by the close group of its address. Just like there are 32 nodes managing 1 SC data unit… There will be 32 nodes managing the ledger belonging to Joe XXX. Just like the SC data unit, where the old and new owners are updated. The Ledger will update from the old balance to the new balance.

Keep in mind, a group changes after a churn event, so the 32 members are not always the same 32 members after churn.

That is an interesting idea. That could also apply to the ledger accounts for individuals. If it does work, it would reduce Network load and possibly make transactions faster?

But I don’t think we are going down this road. Some of my ideas have not been very popular lately.

1 Like
151

I’ve missed the bus then … what road are we going down? Is there a link for that conversation?

cheers

152

I believe the devs (MaidSafe) want to implement “basic” SC, without divisibility in the beginning… this means 1 SC is the smallest denomination. This thread has brainstormed various ways to make SC divisible.

It seems the development process has evolved into 2 stages…

Stage 1. Post an idea on this forum to let other members hash it out.
Stage 2. If the idea survives opposition, then an RFC is created for the devs to look at it.

Look at the Safecoin GitHub link and Scroll down to a section called “Alternatives.” That is the closest to a divisible SC so far.

https://github.com/maidsafe/rfcs/blob/master/proposed/0012-safecoin-implementation/0012-safecoin-implementation.md#establishing-farming-rate

Here is the link to the alternative solution proposed on this forum.

Basically this means… 1 SC is represented by a “group” of 100 or 1000 data units.

153

Whatever happened to the idea of 1 SafeCoin = 100 SafeCents (etc) = 10000 SafeMicros etc etc

Smaller exchangeable (3rd party? But still on SAFE) coins

1 Like
154

I remember the Increasing the total supply of SafeCoin thread. And it may be on the list of ideas. But right now, I don’t see it as part of the RFC, which tells us what the devs are planning to work on.

@krnelson constantly calls for a “single” currency, divisible by default. I’m inclined to agree with him.

Gold ~> Silver ~> Copper… might seem intuitive to many people because it’s part of a 5000 year history.
My SAFE GB idea uses a similar history (GB being well known) and even that was a bit difficult.

But we are creating a new currency with no reference. It would be easiest for new people to start with just 1 denomination of SC.

4 Likes
155

I’d suggest the difficulty was not in the multi unit currency but in the uncertain worth of one against the other.

The actual metals copper, gold, silver would/do also have difficulty because of their varying rates of worth against each other and base currency.

The reason Dollars & cents work so well is 2 fold.

  • There is a fixed relation between one dollar and one cent
  • It follows simple mathematical rules for its relation and its taught from childhood.

Any division along the lines of “coin - subcoin” where the relationship is fixed and sensible (cents or milli coin/micro coin etc) will have many times the understanding and acceptance than some 8 digit subdivision or variable relation system such as SAFEGB

SAFEGB maybe a terrific system but it lacks understanding by non-tech people who cannot fathom why its value changes in relation to SAFE coin.

Also to keep with SAFE’s design goal to have a fixed number of SAFEcoin any subdivision would require that an equivalent value of SAFEcoins are held frozen. Otherwise the division could become worth many many times the worth of the 2^32 safecoins.

It is a shame that the way SAFEcoin is held as individual coins in the system requires each coin of the transaction to be worked on in any transaction. So to add a division of the coin and remaining with a singular coin system means that you are multiplying the transaction/storage load if the coin is to be kept singular

1 Like
156

Agreed. Hard to argue with that

But my thing was just like a plan b, since they don’t wanna make it divisible

1 Like
157

Yes, that was my idea and I still think it’s a good one. In any case it would give more time before we had to worry about divisibility.

The way I imagined the ‘multiple sub-currency’ thing working for the end-user is that they would be hard-linked to each other in value and the user would only see something like: 127.384.395 Safecoin → where the 127 is the whole safecoin, the 384 is the millisafecoin and the 395 is the mircosafecoin. So, from the end-user perspective is appears as just one coin, not three. Perhaps doing such is too complicated for the devs to consider however, using decimal places with the existing single Safecoin has problems of its own - or at least that is what I took-away from David Irvine’s comments on the subject many months ago.

Frankly, I think starting with a Safecoin pool of the currently proposed size, which isn’t in any way divisible, is going to cause some serious grumbling from the larger community that comes in after launch.

1 Like
158

I agree, unless we can create a ledger currency that is guaranteed to be exchangeable to/from Safecoin at a fixed conversation rate forever.

This was what I put to Keith and I think he’s in agreement.

It would require the network to place and hold Safecoin in escrow when they are converted to ledger currency (which can be denominated sensibly, and further divided as necessary). So 1 SC to 100 Safecents for example. To convert back, one would pay 100 Safecents and be returned one of the escrowed Safecoin.

I don’t know how this would be implemented, but if feasible it could solve this better than either divisibility or a floating ledger currency.

1 Like
159

It was suggested by Ben that this is feasible where the network “freezes” a coin rather than recycles it, and can have it signed over to a new owner when the appropriate amount of smaller coin denomination is returned for recycling.

I have another thought on a possible division system were the division is a ledger system, or promissory note style of thing and only used for Less than a coin amounts. I have a feeling that someone suggested the same or similar thing previously, so I doubt this is “original”

  • These are held in a SD that is handled by the network with similar security and in association with safecoin.
  • The network “freezes” a coin and write a promissory note (SD) with a ledger value of 1.0000000000 (almost 32 bit value)
  • The network can split and combine these values so that any transaction only ever results in whole coins and 1 SD promissory returned to each the sender and receiver of safecurrency.
  • The client keeps track of these SD notes which can be used in any transaction or combined back into one note and coins if total > .9999999999
  • The decimal place can be represented in whatever form the system wishes. cents & milli-cents OR 10 decimal places, or milli, micro, nano coins There is no reason why a person could not set their client to use one representation and another person use another. It would boil back down to simple decimals

For example

  • person A has 100 coins and 2 notes (one for 0.2460000000 and one for 0.1012878723)
  • person B has 23 coins and 1 note for 0.1234567890

Person A pays Person B the amount of 2.30 safe currency

  • client A requests for the network to send 2 safecoins and 0.300000000 (using the two notes for the 0.3)
  • the network sends the 2 coins and one SD note worth 0.3000000000 to client B
  • the network returns to client A the remainder as a SD note with an amount of 0.0472878723 safe coin recorded

The network will always recombine SD notes so a transaction will only send one SD note to the receiver and one SD note for the remainder back to the sender. No SD notes are sent if there is no value to be sent (ie no decimal places in the transaction/remainder)

This means that the network currency

  • keeps SD coins as it does now (a special SD type)
  • There is then added a SD type that holds a 10 decimal place number representing up to 1 coin worth
  • “freezes” coins whenever sub coin amounts are needed
  • The “SD note”, called by many names depending on the clients preferred representation, so for want of a better name I call it a SD Note (Maybe SAFENote might be better)
  • The network only ever sends a max of 1 SD note to the receiver or as a remainder back to sender.
  • Whenever the amounts of combined SD notes result in more than 1 safe coin worth then safecoins are unfrozen.
  • The total amount system wide of SD notes can NEVER be greater than the number of frozen coins, since coins must be frozen to produce 1 coin worth (10 decimal place number)

As far as I can see

  • this would solve divisibility, practically infinite divisibility.
  • It is as secure as safecoins since the same security around coins is around SD notes.
  • The network can never have more than 2^32 worth of SAFEcoin.
  • It does not result in the multiplication of work that actual safe-cents style of division would.
  • There is no practical difference between this and safecents (millicents or whichever)
  • can be added to the safecoin transaction process without changing the security model/protocol. This means it can be added later without redesigning the security or protocol.

Any thoughts?

6 Likes
160

I like your proposal. I think it could also be modded to allow the creation new sub-currencies or unique currencies (linked or unlinked to Safecoin) by the user (keep that under the advanced tab!).

2 Likes