Update 11 November, 2021

Your credentials are not stored on the network. They are only used when accessing your account. The credentials you enter generate an address and decode key. The account ?blob? is retrieved from the address and decoded with the key. The credentials are not stored on any device or network

1 Like

Yeah good spot :+1: - that’s out of date. It’s now pay on PUT.


From the primer (page 28):

“The reason for moving to ‘pay on PUT’ is that pay on GET would require complex Section wallets and maintaining state, which is what the move to Anti-Entropy and BRB is designed to avoid.”

Could someone from the team (@oetyng ?) define exactly what is meant by “maintaining state”. I want to make sure that my understanding of the reason for the current change from PoG to PoP is correct.

On page 32:

“If five Elders see a Node leave (and generate a new key A) and five see another Node join (and
generate a new key B) there must be a minimum of three Elders that see both versions. Under BFT at least one of these Elders must be honest. Therefore, both keys A and B are rejected and a new round of DKG takes place.”

More description here would be helpful. Do these three remaining Elders in the middle have a vote or can any one of the elders cry foul. It currently reads like any of the 3 Elders can cry foul. If so, what happens if one of the malicious actors cry foul?

Page 37 (Anti Entropy sequence) :
The graphic looks like the client only communicates with Elders, and that Elders pass the data chunk from the PUT on to the Adults. This should be explicitly stated in the text for clarity. Maybe I missed it?


Ahh, I have no got that far yet. :+1:

Please ignore, I was looking at an older version, Aug 2020. Weird, haven’t visited the site in ages, maybe the hosting was serving a cached version. (looks like @Sascha had the same issue)

1 Like

It only worked after I cleared the cookies on Firefox.

Mm, so in principal, a payment could be made exactly as it is done when uploading. The difference is that while that dance is carried out once for an upload, it will continue perpetually for gets.
So, there’s a performance impact of it.
On the other hand, most data would not be retrieved very often, so for that data it is perhaps double the impact (as paying on upload is still needed).
Also, it is not completely alien to imagine that the very popular data that would be requested a lot, is perceived to be worth paying [something, i.e. > 0] for by the requesters.

And if not paying on get, that means the Elders maintain state as to receive and later distribute what was paid on upload.

Then, when we consider that no chunk is currently ever served by more than at most 7 nodes (if the Elders cache the chunks, otherwise 4 Adults), we realise that there must be some additional solution implemented (since there is a lot of content that is more popular than what could be handled by only 7 machines).
There has been talk of torrenty things run by clients, to address that limitation. And so, that’s another dimension to take into account for a potential payment on gets. (Edit: also, there is a fundamental of the network, stating that gets should be free…).

So far there has not been much exploration of the options there, and a single payment on upload is the simplest way to get something up and running.


I see your problem right there…

Use Brave Brave Browser Download | Brave and Duckduckgo search engine. Choose the adverts you want to see, earn BAT (https://basicattentiontoken.org/) and donate them to @Dimitar’s Community Marketing Fund. Combine this with a pi-hole https://pi-hole.net for an ad-free secure browsing experience that is about as good as it can get until SAFE becomes a reality.


Ctrl-Shift-R worked in Firefox (desktop).


Nice update Maid team! Also great work @JPL :wink:

Just some random thoughts on the farming/payments/churn @oetyng

Why not pay on churn/rotation? So every so often data is moved and assuming all data that was supposed to be there IS there, then payment is made to the farmer.

Also I suspect there must be a way to rate/rank a farm over time so there could be bonus pay to reliable farms.

As for popular data, why is there a set limit of 7 machines/farms? Magic numbers == bad right? An algo here would be better IMO, e.g. 100 requests/copy/(some network cycles/time system) - I realize that’s just more magic numbers in the algo, but more flexible I think? In which case, as data becomes more popular, elders just automatically make more copies on more farms - insuring copy number based on current popularity.

Presuming elders act as fiduciaries they just need to maintain enough of a balance to pay each churn … finding that optimal data charge price for the uploader is linked somehow to supply of potential farms and farm space advertised to the elders by the farmers. Maybe elders could also stake some token to provide liquidity here if needed.


This is a result of removing relaying between sections. Before, a client would have a single section it would connect to, and that section would relay the msg to the closest responsible section, which in turn did the same. Then any response would be sent back to the client the same way.
This meant that data could be cached on the route, and ultimately, it would spread out to sit near those clients that requested it, which could be any number (x) of sections and thus x times 7 machines serving any given chunk.

Now though, clients connect directly to a section responsible for the data/op/payment etc. So there is no relaying, and no caching. A single chunk is by that always accessed through the same 7 Elders.

This change was made before AE, and was done because sections were having a difficult time of keeping track of other sections. Maybe now with AE it wouldn’t be a problem. There would be more msgs that way though.

The way transfers works are from sender to recipient. Elders don’t own any tokens.
So, what they would need to do then is obscure all the txs until churn and then reveal it to the recipient. It’s unclear though if it’s worth the added faff and what the benefit is.


How does this affect DDoS attacks, as caching chunks was an important mitigation?


It would be easier to do.
It also means any client quite soon has a fairly up-to-date list of all IP addresses of all Elders in the network (as those are obtained during the course of uploading and paying).


Concern confirmed! What to do?


Will have to attend to some cooking here now, but there are a couple of options discussed briefly and probably more available as we haven’t looked into it much yet.


No worries, enjoy your meal. Something this project teaches those who have committed to support it is… patience :wink:


Possible PoChurn Benefits?:

  1. farmers are paid continuously for storing data, so even though for the user it’s a one-time store fee, for the farmer, they are always getting a reward commensurate with their costs - they don’t have to worry about the long term cost of indefinite storage. While the latter may be true anyway as the user will just pay whatever the farmer demands, I think the psychological comfort of a continuous payout is MUCH better for the farmer. Especially now that pay on get is going away presumably.

  2. built-in long term data holding incentive - farmer isn’t paid until end of cycle, so no risk of getting paid then flushing. I know the process of getting to the farming level is long and their is a strong incentive to keep data, but this adds another even stronger incentive.

  3. separation of client and farmer is perhaps good legally. If there is some way to unmask the client and the farmer who stored their data but the farmer is paid by the network, and not directly by the client, then there is a reasonable denial of responsibility for the storing of data that a particular government may find repugnant. Also direct payment to the farmer by the client could possibly be useful is such an unmasking attack in the first place.

Hmm, so that may negate that last benefit I thought was there - as payment will still be from client to farmer, not elder to farmer … it’s just a cached payment. I don’t think that’s gonna work for a pay on churn anyway as pay on churn means unlimited payments, not a one-time payment. So elders must be able to hold actual tokens themselves for pay on churn, in the same way as pay on get.

I appreciate going for the simplicity of no relaying or caching.

I don’t grok the Seven though … 7 … days in a week? Why Seven? Why not a fluid adaptation with some hard limits at either end based on insufficient elders at the low end and networking limits at the upper end? If this were a human group I could understand as there are severe limits to human communication, and this is also true for computer messaging, but seven seems a very small number (as the hard limit) for computer networking. Even if it were to be a fixed number of elders, why not 70, or 700? I’m curious as to the reasoning here? … @dirvine

I wonder if a small or known/fixed limit might aid attackers somehow … just my crappy intuition though. Perhaps it’s too late in the game to be considering these things, IDK.

Well there ya go … score one for my intuition! :wink:

I assume that elders are being pushed out (euthanized!! lol) and adults are replacing them regularly - doesn’t this mitigate such an issue? Also goes back the 7 number I suppose … more may be better in terms of adult-elder rotation.

Farmers, adults & elders may want to use a VPN for the sake of better anonymity in the end. It’s an extra hop which would add to network latency, but that would probably to worse if extra hops were internal to the network as professional VPN’s are pretty good for speed.

On the surface I think this has good merit, but many clients may have data and/or bandwidth limits … plus there is no reward mechanism for doing this. It’s one thing in a network of torrenters who are sharing and there is no payment involved, it’s another thing when you are paying to store your data forever and then the network just can’t seem to do the job without a continuous lend of your resources … it doesn’t inspire confidence.

Perhaps if there were to be a PoChurn and/or PoGet, and many more elders in a section then network could replicate data on demand to have a much stronger torrent-like effect.

10 posts were split to a new topic: Why this many Elders? I don’t grok the Seven

Regarding the primer, in the third line of the “Major changes since last update”, it reads:

Implementation of conflict-free data types (CRDTs)

Shouldn’t it be “Implementation of conflict-free replicated data types (CRDTs)”?


“Anything new hands on to play with soon?”

  • somebody watching from afar :eyes: