WIP notes #20
WIP notes #20
Conversation
| ``` | ||
| common(G,H) = members(G) ∩ members(nearest(G,H)) | ||
| ``` | ||
| > TODO - this definition doesn't take into account additions between `common(G, H)` and `H` |
There was a problem hiding this comment.
This is what I'm confused by
There was a problem hiding this comment.
Yes, "common" is not "intersection". What this definition captures is the set of "remaining" members. If there is a bifurcation in the epochs, we need to go back to the common predecessor, look at its members, and see what those members have to do regarding the bifurcation. They are the ones who witnessed the bifurcation happening, and they have data that helps them decide which fork to select as the most preferred.
The reason this doesn't work as
common(G,H) = members(G) ∩ members(H)
is because common(G,H) = common(H,G) is always true, which means rule 4.4. is always applied. Also common(L,R) ⊂ common(R,L) is never true, which means rule 4.5. is never applied. And common(L,R) △ common(R,L) is always empty, which means rule 4.6. is never applied.
So this means we only have rule 4.4., which says to only use tie-breaking rule to select the preferred epoch. This doesn't work in some cases, see e.g.
graph TB;
zero[X: a,b,c,d]
zero--"b excludes d"-->L[L: a,b,c]
zero--"a excludes c,d"-->R[R: a,b]
Suppose L is the tie-breaking winner. Then a and b decide to go to L, where c is, but a doesn't want c in the group! Do they have to re-remove c? And who performs that action? a or b? If it's both, then you may end up with forks again.
The case above may seem simple to fix: we just have to make 4.5. be the rule members(L) ⊂ members(R) instead of common(L,R) ⊂ common(R,L), but then we are incorrectly taking into consideration members that were freshly added to either side. Those fresh members kind of don't matter when it comes to choosing forks. We want to know what is the forked epoch that has most excluded members, and jump to that one, but we can only talk about exclusions if we refer to the original (thus the common predecessor) context.
|
|
||
| It is RECOMMENDED that epoch `G` is the "most preferred epoch" among all the | ||
| epochs that `a` is a member of, which succeed a certain epoch zero. | ||
| > - TODO what is the `tangles.group` + `tangles.member` for these `group/add-member` |
There was a problem hiding this comment.
I think if we pin down the tangles right, we can do really tidy quick lookups for the memberships of each epoch
README.md
Outdated
| @@ -184,6 +190,7 @@ Section 3.2.2. | |||
| * 4.1.3. `a` MUST publish a `group/init` message on `Ha`, as described in the | |||
| [private-group-spec], with the exception that: | |||
| * 4.1.3.A. the `tangles.group.previous` field MUST be epoch `G`'s ID, and | |||
| > - TODO what's the ID? is it the previous `group/init` message id, or a cloakedId, or ...? | |||
|
Would be nice if you could extract some of the consensus snippets that we arrived in the discussions above, and make each a PR. |
|
We could use subscripts which might read easier ... test: Ga |
|
This WIP notes PR has now been fully superceeded by children |
I'm only half way through. This is a mishmash of notes as I go, suggestions, questions.
My major question is around the definition of
commonat the moment.I may keep reading to see if it resolves itself but have run out of steam today