RFC 57: Safecoin Revised

Hey @dirvine,
I didn’t know which topic to put this in, but since you are mentioning this cross company focus on simplest possible solutions to get a working network up, I’d thought I wrote it here.

I’ve never understood why RDF is essential for the MVP. I thought this already when RDF was announced as new component of the project. But I thought it again when AppendableData was said to be necessary for RDF.
Now we have a whole bunch of new data types, which were just now in a dev update said to be necessary for RDF. And as happy as I was over the explosion of creativity and the power of the network I could see with these types, my experience told me: here be dragons. Meaning, that’s a whole lot of new considerations and edge cases and changes. That stuff takes time. A lot of time.

But now again, why do we need RDF for the MVP?

Getting the full network with MD and ImD, imperfect as they may be, seems like a MUCH shorter path. There we can run PARSEC, there we can run secure message relay, vaults at home, farming and Safecoin. All the important pieces.

To me, RDF just seems like a certain way to store data. But I cannot at all see why it is necessary to have it in this push for MVP network. Could you explain why it is?

Thanks
(And sorry again for not finding better topic for this post)

7 Likes

No worries, we are moving fast so happy to find any more speed.

The answer is we don’t, but also we do need some kind of data representation for some apps. This is a point we are looking at, but it very much depends on the resource we have in those tasks. If the resource does not affect critical path to MVP then it may be OK, but it is under consideration along with many other pieces (such as above).

It very well may be. I will ping @Nadia to keep this in mind as she is questioning the Engineers continually to find what we absolutely need.

10 Likes

Just to show what will make with StoreCost formula if StoreCost represent number of chunks per one nanoSafeCoin.

SC=1/G + F/N

SC = StoreCost (in this sample nanoSafeCoin/Chunk)
N = Total number of nodes
F = number of full nodes
G = N - F

A) 0% full nodes
Nodes 1k ; 100k ; 10M
TB per SafeCoin 953 674 ; 95 367 432 ; 9 536 743 164

B)1% full nodes
Nodes 1k ; 100k ; 10M
TB per SafeCoin 86 618 ; 95 271 ; 95 366

C)10% full nodes
Nodes 1k ; 100k ; 10M
TB per SafeCoin 9 432 ; 9 536 ; 9 537

D)50% full nodes
Nodes 1k ; 100k ; 10M
TB per SafeCoin 1 900 ; 1 907 ; 1 907

You can see that with only few full nodes the number of TB per one SafeCoin can explode. Also when network grow, there is only little difference between 100k nodes and 100 times more.

2 Likes

Ok super, thanks a lot for that fast answer.
I’m thinking that with first MVPs there will be plenty of important adjustments to work with as it is with the core parts of PARSEC, msgs, farming etc. which would presumably be easier with less new parts to analyse and fine-tune. And then the boost from being at that place (having a running MVP, fixing the things that show up, showing the world that this works etc.) I imagine will make it much easier to add, work with and focus on the slightly less essential parts, than it is now.
Anyway thanks again, you rock.

13 Likes

A post was merged into an existing topic: RFC - Decentralised Naming System II - continuous auction (by Seneca)

I am also interested in separating core goals from nice to have features and from goals that could be built based on the core goals.

It will help us, community members at least, to focus to get right what matters most first.

I started the dissection of SAFE Network goals here: Core Goals of the first iteration of SAFE Network at launch

RDF is one example of a nice to have feature but storage of knowledge and building ontologies etc is a whole other huge topic. Interesting but a distraction.

3 Likes

I think there would be at least one good reason to have untransferable PUTs: with untransferable PUT balance, companies & other groups could spread the capacity to store data to individual members without giving incentive to steal the balance. The worst thing a dishonest worker / member could do is to use all the PUT’s to store random data, but this is unlikely, because there is not much benefit to himself. Also the accounts with only PUT balances would not need to be so well secured against hacking etc. because they cannot be stolen. This could be advantage for network adoption.

2 Likes

That’s a bit fringe to turn into a fundamental network feature.

1 Like

Yes and another is a major one in that if we go back to PUT balance then it becomes a gamable feature.

Big holder of safecoin monitors the PUT price and buys up tons of PUTs (multiple accounts if needed) while the price is really low and since buying PUTs does not affect space (only change in free space does) they can spend all their coins.

Then when the price jumps up real high due to space running out they can “sell” their PUTs and profit off SAFE. SAFE’s goal is to give lowest price possible but this ability to transfer PUTs allows that to be bypassed

And another major damaging factor for SAFE would be the ability to buy real cheap then hammer the network when space is low.

Put balances should not be transferable, it is not a fringe issue (that example was maybe fringe), it bypasses SAFE’s goal to provide the lowest price possible at the time.

Although @Toivo’s example would be a way for a company to handle the companies adhoc storage costs or maybe even most of it.

6 Likes

I think a simple safecoin allocation for puts is enough – a separate safecoin variable that cannot exceed your safecoin balance. You could also use this to allocate a fixed percentage - a nice feature.

So you don’t purchase in advance, yet you can allocate and cap for future purchases - thus giving you control over your ‘putting’. This takes away the gamefication but still gives users flexibility and control.

4 Likes

This is a great point and a strong argument for buying resource directly with SAFECoin (or equiv. to).

If people want to get cheap storage, they can still try to get maximum SAFECoin for their money. That is an external market instead of an internal one, which seems more sensible.

Edit: more importantly, it is one instead of two markets. Much easier to model and manage.

2 Likes

The original non transferable PUT balance was fine because you could only buy the balance (1 coin == full 2^64 balance) then the put cost at the time was subtracted from that balance.

This meant

  • could not hoard PUT balance
  • could not make a market of balances
  • one account had a max of 1 safecoin divided into 2^64 balance value
  • the balance is not the # of puts but the one safecoin divided into 2^64 parts and the cost of a put was subtracted from it
    • if PUT cost was 2^62 then you got 4 PUTs from that balance
    • the PUT cost could change a lot and the appropriate amount subtracted from the balance
    • so you were not buying PUTs but just having a coin divided into 2^64 parts and the PUT costs taken from that each time.
6 Likes

Thought this might fit here :joy:

12 Likes

The problem is that u128 is not well supported by compilers. It should be a set of four 32 bit unsigned integers…128 bit just like divisibility of ipv6.

Why not just go crazy and do 8 unsigned ints (insignificant to total user storage). This allows each wallet balance to work in divs or decs depending on the user’s preference. Bankers can do decimal, philosopher geeks get to have fun with binary. This also satisfies the original statements made at crowdsale that there would never be more than 2^32 SC and each would be divisible to at least 2^32.

1 Like

If we do get rid of PUTs and use micro/nano safecoin deductions, i’d like to control my spending and still ring fence safcecoins as a PUT balance.
In this way, if my “PUT balance” still has safecoins, I could sell them.

2 Likes

Rust has official support for 128 bit ints, thus it is generating all the plumbing for you on architectures that do not support 128 bit ints. Just as it does with 64bit ints on systems that aren’t able to do 64 bit math.

edit: rusts support for different platforms: Redirecting...

9 Likes

Nice. Rust! However, there might be future bugs in rusty plumbing. IMO it would be beneficial to have a low level dedicated/minimalist safecoin add and subtract library.

1 Like

You mean for other langs? Or do you think, that you can make a 3. party 128bit int math package for rust, that has higher code quality that rust itself? For rust this should be already handled by the NanoCoin, MilliCoin, … types

1 Like

In any case making a simple 128 bit add/subtract routine is easy.

3 Likes

No. 20 chars…

3 Likes