RFC 57: Safecoin Revised

[Zoki]

@zeroflaw

Step 5. Buy PUTs <----- At this point you’ll need to explain PUTs.

Am glad you pointed this out.

[zeroflaw]

My point is if people don’t RTFM. Then up to the point they buy PUTs everything has a reverse step. The chances are someone will make a mistake and then start complaining.

People complaining is not good for adoption. PUTs are a liability.

[drehb]

@zeroflaw

pre-pay for 36+ months worth of PUTs

It wouldn’t necessarily be possible to pre-pay for PUTs if they are used. Again going back to Ethereum analogy to GAS, users don’t have a GAS balance… It is just paid at the time of each transaction, with the user specifying how much ETH per GAS they are willing to pay.

Side note that someone did figure out how to tokenize GAS by using a contract that utilized operations that gave a refund for freeing up space.

[zeroflaw]

The current way PUTs are expected to work is that they are pre-paid. As they were a solution to the divisibility problem. I suppose individual accounts could be limited to a small amount of PUTs such as 1000?

Ideally everyone will aim to hold as close to zero PUTs as possible (apart from a natural disaster / outside event as described above). As the norm would be for the value of PUTs to trend towards 0 (obviously never reaching it). You would only want to covert to PUTs at the last possible moment. And if it’s just going to become an automated part of a file upload transaction, what’s the point of having PUTs at all? thats just implementation complexity for the sake of having a thing called PUTs.

If Safecoin can be divisible, PUTs aren’t required.

[dirvine]

@zeroflaw

If Safecoin can be divisible, PUTs aren’t required.

This is correct, all you need is a bit of a safecoin balance, the network will deduct some of that per put at the time of put. Or at least we will start that way and see how it goes during testing, ofc we are all open to all ideas moving forward.

[Traktion]

@dirvine

This is correct, all you need is a bit of a safecoin balance, the network will deduct some of that per put at the time of put. Or at least we will start that way and see how it goes during testing, ofc we are all open to all ideas moving forward

This seems like a good idea and adds simplicity.

It is also a strong argument for having tiny units of SAFECoin from the start.

[Mendrit]

Without PUT with proposal reward system we can work with micro Safecoins, because only if 100% of all nodes are not full, the StoreCost with large amount of nodes will enable lot of chunks (n nodes = n chunks/SafeCoin).

But definition of StoreCost is not clear yet and not only that.

We should set base targets, set algorithm and than deal with all details. I am not sure at all what is still valid from the past.

[andyypants]

I think the psychology will be different here. With a blockchain its seen as a medium of exchange or a store of value and the mining fees are just like a little tax to keep those use cases enabled. With safecoin I think we will see a much higher percentage being used for network fees because you are getting a whole lot more then just verify a public ledger of ownership.

[oetyng]

@Antifragile

Is there somewhere separate thread for farming only?

I was thinking this as well, and we should probably have an RFC for the farming algorithm itself.
I’ve always suspected that there will be a lot (a lot) of considerations to be done there to get something optimally designed.

So, if Safecoin RFC treats only how it is represented, stored, transacted and recycled, the Farming RFC would be focused on the farming algorithm and enabling its prerequisites (thinking about input data).

If we can assure that we can quickly and reliably upgrade the farming algo, then I’m all for going with a very simple first version that isn’t obviously causing malfunction of the system - all in the spirit of iterative development and focusing on getting something working out there.
If we are not so sure upgrades will be easy and simple to do initially, then we really must go deep in the farming algo design now.

I know @JoeSmithJr has laid out a few elementary components (would like to see you put those together into a proposal if you feel up to it). @mav for sure has plenty of ideas going on. I made some suggestions right here above. But we would really need to get some concrete stuff going to start trying them out.

@anon86652309, what do you say about farming algo RFC? Is there one on its way or should we maybe get one going?

[TylerAbeoJordan]

@zeroflaw

Step 5. Buy PUTs <----- At this point you’ll need to explain PUTs.

This is a marketing issue IMO … if your hard drive fills up, you have to buy another hard drive – pay for drive space … most people who use computers get that.

So instead of ‘puts’ we just say, hey there, thanks for joining the safe network, if you want to store some data on the network, please purchase some Safe-drive-space to get started.

IMO, that will make sense to most people.

@dirvine

This is correct, all you need is a bit of a safecoin balance, the network will deduct some of that per put at the time of put.

yes, or allow users to allocate some safecoin for storage. That way they can put a cap on it and regulate it better.

@Antifragile

The problem this makes is that nano coin (64 bits) is not enough without PUTs.

@Antifragile so why not just buy a block of puts or allocate safecoin for storage?

[mav]

@dirvine

all you need is a bit of a safecoin balance, the network will deduct some of that per put at the time of put.

Thanks for clarifying. Gonna be a lot of legacy documentation / topics with PUT balance mentioned, will be a long time before this one sinks back into the void. Good to have it clarified though!

[neo]

@dirvine

all you need is a bit of a safecoin balance, the network will deduct some of that per put at the time of put.

@mav

Thanks for clarifying. Gonna be a lot of legacy documentation / topics with PUT balance mentioned, will be a long time before this one sinks back into the void. Good to have it clarified though

Yes it is good to have clarification. Now I made some erroneous comments above, sorry to all who believed me.

[dirvine]

@neo

Yes it is good to have clarification. Now I made some erroneous comments above, sorry to all who believed me.

You were not totally wrong. This current scheme of no Put balance is part of the current push to farming algorithm impl 1.0. It is likely to change. My feeling right now is there are too many moving parts and coupled thinking. Therefore we pushed for a simplified algorithm, for now, to allow the whole network to exist in a rudimentary form. At that time we can have many more considered conversations and include the Engineers in MaidSafe a bit more. Currently, we have all been working in different parts of the system with limited crossover, that means they are all very busy, but not all with visibility of the complete network. This change recently is to get 100% of the people involved in SAFE talking about the whole network and doing so with some data from test networks/releases etc.

So @neo you were not causing confusion, that was me and the current push in maidsafe to get a network out that has all the moving parts. It has meant us internally saying OK this is not the final X algorithm, but it will work to allow us to measure and then optimise what we must for the full launch.

[oetyng]

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)

[dirvine]

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

@oetyng

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

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).

@oetyng

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.

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.

[Mendrit]

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.

[oetyng]

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.

[drirmbda]

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.

[Toivo]

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.