Update 11 August, 2022

[RedPill22]

@Knosis

When was the last official Testnet and when do we expect the next one?

soon I hope, I don’t have date of last one.

Believe the last Testnet was ~ April 2021?

[Toivo]

Really thorough update, thank you!

Still one thing I’d like to hear about is the work you have done in pruning and prioritizing the different kinds of messages of the network. But I’m in no hurry with this at all. I have just been spying in Github and noticing how this area has been subject to many changes, fine tunings etc.

It might also be an interesting way to describe the network - in terms of the traffic. What kind of traffic it creates to just keep itself going, how is this different from user initiated requests, how these two are balanced, how they affect each other, what other kinds of traffic there is… What are all the things that happen in between the nodes, clients etc?

Just a thought, and only when you are not too busy. I mean, my spying has also revealed, that you have been very busy indeed. Working long hours and in weekends too. Thank you for doing all that. And take care to not exhaust yourself!

[Vort]

@Toivo

It might also be an interesting way to describe the network - in terms of the traffic.

Or in general - in terms of resource usage - CPU, RAM, disk, network.
Also it is interesting to understand how resource usage will correlate with rewards - will user be rewarded at least somehow proportionally to resources, which he will provide to network? How it will be possible to optimize reward amounts?

[Vort]

@dirvine

Clients pay for the storage authorisation (section sig)

What happens when node becomes full?
Will it still receive payments for authorisation?

[MacTyre]

[Michael_Hills]

Half way there, or half way to never? Looks like always half full, if it is a cup, which is a normal amount for any software, as any software is never all the way there, ever… just wait for the next update, for any software… we are almost there…

[dirvine]

@Vort

I’m interested in what happens with transaction data, when nodes goes offline.

I think you mean registers/merkle trees etc. The notion here is you pay for the container. It can have many events in it, but you only pay for the container itself, I.e. you pay the first store, but not updates to that data item. Chunks however are just chunks (parts created by self-encrypt being the most common)

[bridge]

I’ve been watching this project for the past 7 years. It seems certain that the development towards the launch is being completed faster than ever, but if you are in a hurry, it it good to look at yourself whether it is because of your personal situation.

P.S. Let’s enjoy this last calm mode.

[neo]

Good to see progress on the SNT issuance and a potential solution to the issuance of the 70% without POW (of any sort)

@maidsafe

For a DBC to be spent it must be reissued to the public keys of the new owner(s). For this, we pass the Genesis DBC back to the client and have it reissue new DBCs to the nodes - plus one DBC to itself as an incentive. The amount of this incentive needs to be worked out.

Whats to stop a mod to the client code to keep the whole of this DBC passed back to it?

And i won’t repeat the questions @happybeing said which he beat me to (by 12 hours LOLOL), EDIT: which I see were basically answered

[Southside]

@dirvine

It can have many events in it, but you only pay for the container itself, I.e. you pay the first store, but not updates to that data item.

So if I upload tiny.mp3, a 5sec clip of me playing the moothie, then update tiny mp3 so it is now a triple album, how do I get charged?

[Vort]

@dirvine

I think you mean registers/merkle trees etc.

I’m talking about data, which is required for financial mechanisms to work.
Equivalent of blockchain. There were discussions about spentbook some time ago. Not sure if this idea changed since then.
@Southside got the idea correctly:

@Southside

Could we be vulnerable to a dust attack here?

There should be something which limits resource usage.

[dirvine]

@Vort

I’m talking about data, which is required for financial mechanisms to work.

Ah, that data is free to store, if you mean the side effect of transactions? i.e. SpentBook etc.

@Southside

So if I upload tiny.mp3, a 5sec clip of me playing the moothie, then update tiny mp3 so it is now a triple album, how do I get charged?

The new data is new chunks and is a new store cost for that. Your old mp3 is still there. If you point to them via a register, i.e. DNS like then the cost of updating your “DNS” is zero as you paid to store the DNS container. Hope that makes sense.

[happybeing]

So no charge for mutating a Register? That doesn’t seem right.

[dirvine]

Charging for each update would mean each element carries another section key + sig (so a 32 bye field requires 96bytes of authority). It also makes updates much slower as elders need to sign.

Given that it seems that the container costs 1Mb and caps at 1 Mb, any further updates requires us to “link” registers.

[TylerAbeoJordan]

Interesting update! Looks like some big nails are being hammered in now. I’m guessing … just guessing … and my guesses are almost always wrong on this point … but maybe … as a broken clock is right twice a day, just maybe … we will get to beta within a year from now! … there! I said it! lol

Great work team. Keep hammering!

[19eddyjohn75]

Thx 4 the update Maidsafe devs

Super exiting to read “finalising”, this is coming together so nicely. Hopefully soon we’ll have another testnet to play with all these goodies

Keep hacking super ants

[Blindsite2k]

@maidsafe

Finalising network payout of the 70% rewards

70% of SNT will ultimately be created by the network in the process of clients uploading data.

When clients upload data they must first pay the sections where the data will be stored. These payments are shared between the nodes in each section (most likely the elders and adults storing the given data, pro-rata based upon age.

However, a certain proportion (to be decided) of payments will also result in the minting of new SNT in the form of a DBC. The total value of the new DBC will be the same as the payment amount. The new DBC will be shared between all nodes in the section.

To select those payments that will result in a new SNT, a test is carried out, for example some kind of match involving a hash of the payment and the section address prefix. The probability of passing the test will depend on the desired rate of SNT creation (previously the farming rate).

Elders check every payment to see if it passes this test. The incentive for this check (which is fast and requires minimal resources) is the chance to earn SNT. Most payments will not pass the test and will proceed as normal, but when there is a match, the elders use that payment to mint a Genesis DBC. This Genesis DBC is brand new and increases the total amount of SNT available to spend. Its total amount is the same as the amount of the upload payment, and its value is split between all nodes in the section, weighted by node age.

For a DBC to be spent it must be reissued to the public keys of the new owner(s). For this, we pass the Genesis DBC back to the client and have it reissue new DBCs to the nodes - plus one DBC to itself as an incentive. The amount of this incentive needs to be worked out.

Once the DBCs have been reissued, the recipient nodes are notified and can now spend their DBC as and when they wish to.

Minting new SNT only occurs with new data storage. SNT transfers do not result in a new DBC being created.

We will probably change the name Genesis DBC as there are many such DBCs so the word ‘genesis’ is confusing.

Okay to sum up I am not understanding this whole thing clearly. Too many of the terms are being used interchangably and the logic of why this is being done is unclear. Where has the other 30% gone anyway? A new DBC is created to be minted and then voted on and split collectively? For what purpose? Sorry this is all getting very confusing. The farming system I understood but this is downright confusing. Where are the SNT coming from and where are they going. Please explain from the top.

[TylerAbeoJordan]

@Blindsite2k

Where has the other 30% gone anyway?

The other 30% are already accounted for - they go to specific parties as per the original distribution. These 70% are the reserve DBC-SNT that will be released by the network over time.

What is being discussed and worked upon here is the method for performing that distribution.

See: https://forum.autonomi.community/t/rfc-0061-safe-network-token-distribution/

For more information. But TLDR, nothing has really changed from the original, just methods of making it all work/function/happen.

[Dimitar]

Thank you for the heavy work team MaidSafe! I add the translations in the first post

Safe Network новини 🇧🇬 11.8.2022

Actualités du développement Safe 🇫🇷 11 août 2022

Actualización de Safe Network Dev 🇪🇸 11 agosto 2022

Safe Network Entwickler Update 🇩🇪 11. August 2022

Обновление Safe Network 🇷🇺 11 августа 2022 г

---

Privacy. Security. Freedom

[Bogard]

@maidsafe

However, a certain proportion (to be decided) of payments will also result in the minting of new SNT in the form of a DBC. The total value of the new DBC will be the same as the payment amount. The new DBC will be shared between all nodes in the section.

To select those payments that will result in a new SNT, a test is carried out, for example some kind of match involving a hash of the payment and the section address prefix. The probability of passing the test will depend on the desired rate of SNT creation (previously the farming rate).

Elders check every payment to see if it passes this test. The incentive for this check (which is fast and requires minimal resources) is the chance to earn SNT. Most payments will not pass the test and will proceed as normal, but when there is a match, the elders use that payment to mint a Genesis DBC. This Genesis DBC is brand new and increases the total amount of SNT available to spend. Its total amount is the same as the amount of the upload payment, and its value is split between all nodes in the section, weighted by node age.

For a DBC to be spent it must be reissued to the public keys of the new owner(s). For this, we pass the Genesis DBC back to the client and have it reissue new DBCs to the nodes - plus one DBC to itself as an incentive. The amount of this incentive needs to be worked out.

Once the DBCs have been reissued, the recipient nodes are notified and can now spend their DBC as and when they wish to.

Minting new SNT only occurs with new data storage. SNT transfers do not result in a new DBC being created.

I like this a lot. Satisfies decentralization and provides an opportunity for fair participation to everyone (if the schedule is extended far into the future, it’ll be a resource that even future generations can mine). Hopefully questions around security and abuse prevention can be addressed to allow for its implementation.