Yeah I got excited to see the new membership / consensus system being advanced in rapid pace, but it seems it’s not quite there yet either.
But a lot of steps forward in many areas anyway.
And something new for the next comnet too!
8 Likes
I suspect tonights update will be “steady progress all round” and an announcement on ERC-20 Maid but no major network code updates just yet.
That clicketty-clack noise you hear is ducks getting put in a line for the next week or two.
The ERC-20 news will be most welcome but I am more concerned with the actual code than trading.
Anyhow advance congrats to @Sotros25 et al for all their hard work and diligence.
EDIT: OK I was wrong its happened before and it will happen again…
8 Likes
we now have private data in API!
11 Likes
Technically, it hasn’t been approved yet. But I like how people here are all over Github like hungry chickens. 
11 Likes
Not sure we have it 100% yet, that for sure is a fix needed in the api to have access to them, but we still need to review how we are dealing with the encryption keys in terms of the public APIs (and CLI).
14 Likes
Bit late today?
Checks calendar… Yes it IS Thursday, been wrong like that before…
So are the mighty ants still toiling to put together a bumper update for us?
Plenty of GitHub action but maybe its not quite ready for primetime yet…
Agogometer 8.865 (averaged)
4 Likes
Just merged [rubs hands]:
23 Likes
Hell, it’s about time.
23 Likes
Oh yes !!! it was a biggie
21 Likes
Sorry if this is too obvious but… Is the hope here with this latest code, to have a stable testnet… Even with many nodes joining and leaving in quick succession?
8 Likes
The hope is there with every step, but what i suspect you’re asking is, is there an expectation and don’t think anyone can stay that until it’s tested and we see how it works!
12 Likes
This change looks like a precise shot at nasty bug, which was preventing to have stable network.
It is for sure better than making random changes in hopes that bug will go away by itself.
But this change, of course, 1. Will require polishing 2. May be move in wrong direction, producing more problems than solving 3. Even if direction is correct, there may be more work to do to catch other bugs, which have similar effect (bad stability).
10 Likes
I think this hangover should be cleared before any stability can be reached:
9 Likes
Yeh, DKG is still somewhat problematic at times. The current code w/ membership updated is looking much much healthier. It’s been a slog getting there, but the team have done a reaaaallly great job with that.
There are a couple of options w/ handover/dkg that we’re looking at. That’s the next mole to whack! 
19 Likes
I just got a thought. I have never really understood how the section split is supposed to happen. I mean how the SAP can split into two new SAP’s in an asynchronous way, without getting caught up in weird loops, race conditions etc.
But what if section would not split in two, but in three? That way the current SAP (or set of elders) could first “incubate” two new complete sets of elders and when they are ready, just kick them out of the nest and start to hand data / adults over to them. After that, the original section could continue as it was, or maybe disintegrate / relocate etc.
In a way, sections don’t need to split, the just need to give birth to new sections. Or the group of elders don’t need to split, adults maybe do. Or maybe the set of empty adults could be collected ahead of time too?
EDIT: But the risk of getting more than 1/3 of dishonest elders increases with this method, does it?
3 Likes
Or maybe:
This prompted to do a search on BRB, maybe I’ll get to read this interesting article:
7 Likes
I guess I just have to accept that this process of transmitting the authority is just over my head. I can kind of understand, or at least accept, the way how CRDT’s eventually converge to the same result, what the data actually is.
What I don’t understand at all, is the following process:
- We have a group of elders, that rule the section. (This is clear).
- They choose the next elders based on node age. (Fine)
- They form the new sections with these new elders. (And this is where I get in trouble…) It just seems to me, that the possibility that any of these old elders (or new ones as well) might lose their status, drop in node age, in the midst of this process. What happens then?
Like, I can accept that any other knowledge, except node age, can be disagreed until the disagreement is eventually solved. But what if there is a disagreement about the age of a given node? How can a section function during the time it is not agreed on? Or is the age of a specific node always agreed on?
2 Likes
actually @stout77 that’s a precursor draft to the membership that just went in. I’ll tidy that up now 
We are looking at using consensus for the handover step to improve things w/ splits + churn though, so not far off!
Indeed!
Right now we have DKG which does this, with a timeout (as it requires 100% participation). We can see this failing sometimes, for a range of possible reasons. We have some improvements to be made there (how/when to retry)… But we’re also looking at how we might be able to not DKG at all. That’s an early stage idea so just exploring that alongside, but that would really remove the async code / loops / races etc.
I’m not sure more sections is helpful. The idea of a split is that the address space gets more grannular (prefix length increases), so we can’t have a section “remain” so to speak, as it would theoretically be responsible for all its data and the other two “child” sections…
8 Likes