Skip to content

Eight protocol ideas, run against a 311 node import - #1

Open
A13xB0 wants to merge 10 commits into
mainfrom
eight-protocol-ideas
Open

A13xB0 wants to merge 10 commits into
mainfrom
eight-protocol-ideas

Conversation

@A13xB0

@A13xB0 A13xB0 commented Aug 12, 2026

Copy link
Copy Markdown
Collaborator

Eight ideas read from MeshCore at the commit repeater-v1.17.0 points at, each proposed from a specific line of the firmware, pre-registered before running, and run against an unmodified control on the Scotland and Ireland import.

Each report carries the mechanism, a diagram, what was predicted, what happened, why, and an adopt or do-not-adopt verdict with the reasoning on both sides.

Worth adopting: 8 on the evidence here, 5 and 7 on reasoning the evidence could not reach.
Not as written: 1 costs nine points of reach, 2 costs 19% more airtime, 3 is unsound at the hash width the protocol uses, 4 needs a bounded constant.

Three arms returned identical numbers. Every run records the SHA-256 prefix of each binary it attached, so that is verifiably four different builds converging rather than one build run four times - see METHOD.md. That provenance was added to the simulator during this work because its absence made the question unanswerable.

The MeshCore branches are local and are not pushed anywhere.

Each report: where the idea comes from in the firmware, the change, what was
predicted before running it, what happened, why it came out that way, and
whether it should be adopted with the pros and cons behind that.

Ideas 1 to 4. Three of the four should not be adopted as written, and the most
useful result is a negative control that failed: rejecting a repeated path hash
costs eighteen points of reach because path hashes are one byte, so 311 nodes
share 256 values and legitimate paths collide constantly.

The control arm produced 573 transmissions and 4,830 receptions in every sweep,
which is what makes the deltas attributable to the firmware. Raw MeshBench
exports are under evidence/.
Ideas 03, 05 and 06 produced the same five metrics to the digit from three
verifiably different binaries. The harness has stopped applying the arm
firmware, so those deltas measure nothing.

The control did its job: it reproduced exactly in every sweep, which is what
made the duplicate arm values obvious rather than plausible. A discriminating
run of two known-different arms with no control is queued to confirm the cause.
Idea 08 ran last, after every suspect arm, and produced distinct numbers. A
harness that had stopped applying arm firmware would have given it the stuck
value as well.

The honest statement is narrower: three arms coincide exactly and four do not,
and three changes that truncate a flood at the same depth would produce exactly
that on a deterministic simulator. The discriminating run decides it.
The series is sound. Four arms return identical numbers because three of them
depend on conditions this workload never creates, not because one binary ran
four times, and every run now carries the checksum of each binary it attached to
prove it.
Each report: the line of firmware the idea came from, the change, what was
predicted before it ran, what happened, why it came out that way, and whether it
should be adopted with the reasoning on both sides.

Three are worth adopting. Three changed nothing measurable, and in every case
the reason is more useful than the number: two depend on a transmit budget this
workload never exhausts, and one needs request and response traffic the study
does not generate. One is a good mechanism at a bad constant. One cost eighteen
points of reach and, in doing so, established that a one byte path hash cannot
carry an identity comparison.

The control produced 573 transmissions and 4,830 receptions in all eight sweeps.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants