RFC Refactor PR: Modular Rewrite of Mix Protocol Specification #158

AkshayaMani · 2025-05-19T10:43:05Z

This PR rewrites the Mix Protocol RFC for clarity, layering, and implementability. It reorganizes the spec into a modular structure aligned with RFC 7322 and RFC 2119, with clean separation between protocol logic, integration, and pluggable components.

Goals

Clearly define Mix as a message-based routing protocol, not a transport or application-layer solution.
Support per-message anonymity via a mixify flag and external integration through Entry and Exit layers.
Adopt a clean, layered structure: motivation → integration → routing model → cryptographic structure → node behavior.
Use correct RFC formatting, keywords, and SEMBR for implementation clarity.

Changes Completed in This PR

Sections 0–5: Foundational Structure and Protocol Layering

Abstract: Concise, non-repetitive summary of protocol purpose and scope.
§1 Introduction: Cleanly describes protocol role, document scope, and integration model.
§2 Terminology: Defines all key terms; includes correct use of MUST, SHOULD, and informal variants.
§3 Motivation and Background: Articulates need for sender anonymity in libp2p; includes §3.1 Comparison with Tor.

Section 4 Mixing Strategy and Packet Format

§4.1 Mixing Strategy: Defines continuous-time mixing; justifies choice over batching.
§4.2 Packet Format Overview: Defines what a mix packet must achieve; outlines Sphinx format properties and rationale.

Section 5 Protocol Overview and Integration

§5 Protocol Overview: Clean, layered walkthrough of core protocol behavior and layering in libp2p.
§5.1 Integration with Origin Protocols: External interface components (Mix Entry/Exit layers).
§5.2 Mixify Option: Per-message flag defined.
§5.3 Why a Protocol, Not a Transport: Explains why Mix is layered as a libp2p protocol, not a transport.
§5.4 Protocol Interaction Flow: Three-phase diagram and explanation (entry → routing → exit).

Section 6 Pluggable Components

Discovery: advertise Mix support via ENR, X25519 key
Delay strategy: sender-defined per-hop delay
Spam protection: PoW/VDF/RLN options, exit node validation
Cover traffic: periodic loops for unobservability
Incentivization: nodes MUST participate to send

Section 7 Core Mix Protocol Responsibilities

Define Sender, Intermediary, Exit node roles
Specify lifecycle and message flow per role

Section 8 Sphinx Packet Format (Detailed Spec)

Full field definitions (α, β, γ, δ, delays, MACs)
Encoding and padding behavior

Section 9 Node Behavior (Mix Protocol Handler)

Describe sender node logic: path selection, packet wrapping
Describe intermediary/exit node behavior: decryption, delay, forwarding

Section 10 Limitations and Future Work

SURB-based reply support (unimplemented)
DoS/Sybil attack surface
Path overlap, message reordering, end-to-end acks

Appendices

Appendix A: Proof-of-Work Example
Appendix B: ENR-Based Discovery Example

Ben-PH · 2025-06-18T11:22:14Z

vac/raw/mix.md

+### 5.1 Integration with Origin Protocols

-   - Derive the AES key and IV:
+libp2p protocols that wish to anonymize messages MUST do so by integrating with the Mix Protocol
+via the Mix Entry and Exit layers.

-     $`\text{δ\_aes\_key}_{i} = KDF(\text{"δ\_aes\_key"}\ |\ s_{i})`$
+- The **Mix Entry Layer** receives messages to be _mixified_ from an origin protocol and forwards them
+to the local Mix Protocol instance.

-     $`\text{δ\_iv}_{i} = H(\text{"δ\_iv"}\ |\ s_{i})`$ (truncated to 128 bits)
+- The **Mix Exit Layer** receives the final decrypted message from a Mix Protocol instance and
+forwards it to the appropriate origin protocol instance at the destination over a client-only connection.

-   - If $i = L-1$ (_i.e.,_ exit node):
+This integration is external to the Mix Protocol and is not handled by mix nodes themselves.

-     $`\delta_i = \text{AES-CTR}(\text{δ\_aes\_key}_{i},\ \text{δ\_iv}_{i},
-     \ 0_{\kappa}\ |\ m)`$, where $m$ is the `message`.
+### 5.2 Mixify Option


This is problematic. This requires functionality changes to the client protocol, and causes several issues:

bugs: when a bug occurs, it's less clear if it's due to the mix code base, or the code-base of the client protocol

responsibilities: this puts responsibility on the client protocol to provide mix-behavior

tight coupling: this approach means that mix can only be used with one implimentation of the client protocol.

The alternative should be a means for client protocols to provide specific behaviors that can be hooked into. If a protocol needs to anonymize a message, it would be able to provide some sort of functionality as specified by the mix imprementation, that would allow any given mix-message to have said functionality hooked into. For example:

mix.message(.....).withEntryHook(....).dispatch(....)

With this approach:

If there is a bug that appears to be due to the modified entry-behavior, testing can remove the hook, or replace the provided hook with one known to be working

The only requirement of a libp2p implementation is to provide an interface that allows for pre-routing through mix, as opposed to intrusive modification of the implementation

the hooks themselves could theoretically be defined through language agnostic means, making nim-mix compatable with any libp2p implementation that is able to provide the means to do the hooks (this is somewhat dubious)

…om Entry/Exit layers - Clarified that the Mix protocol handles message-based mixnet routing only - Rewrote Section 2.1 to retain sender/intermediary/exit roles with clearer boundaries - Explicitly separated responsibilities of Entry and Exit layers from Mix protocol logic - Moved Background section to follow protocol overview for better flow - Added additional mixing strategy and pluggable component sections

…tions

…protection, cover traffic, incentivization)

…valid link for Appendix A

seugu

thank you.

seugu

Thank you again.

This PR rewrites the Mix Protocol RFC for clarity, layering, and implementability. It reorganizes the spec into a modular structure aligned with RFC 7322 and RFC 2119, with clean separation between protocol logic, integration, and pluggable components. ### Goals - Clearly define Mix as a **message-based routing protocol**, not a transport or application-layer solution. - Support **per-message anonymity** via a `mixify` flag and **external integration** through Entry and Exit layers. - Adopt a clean, layered structure: motivation → integration → routing model → cryptographic structure → node behavior. - Use correct RFC formatting, keywords, and SEMBR for implementation clarity. ### Changes Completed in This PR #### Sections 0–5: Foundational Structure and Protocol Layering * [x] **Abstract**: Concise, non-repetitive summary of protocol purpose and scope. * [x] **§1 Introduction**: Cleanly describes protocol role, document scope, and integration model. * [x] **§2 Terminology**: Defines all key terms; includes correct use of `MUST`, `SHOULD`, and informal variants. * [x] **§3 Motivation and Background**: Articulates need for sender anonymity in libp2p; includes `§3.1 Comparison with Tor`. #### Section 4 Mixing Strategy and Packet Format * [x] **§4.1 Mixing Strategy**: Defines continuous-time mixing; justifies choice over batching. * [x] **§4.2 Packet Format Overview**: Defines what a mix packet must achieve; outlines Sphinx format properties and rationale. #### Section 5 Protocol Overview and Integration * [x] **§5 Protocol Overview**: Clean, layered walkthrough of core protocol behavior and layering in libp2p. * [x] **§5.1 Integration with Origin Protocols**: External interface components (Mix Entry/Exit layers). * [x] **§5.2 Mixify Option**: Per-message flag defined. * [x] **§5.3 Why a Protocol, Not a Transport**: Explains why Mix is layered as a libp2p protocol, not a transport. * [x] **§5.4 Protocol Interaction Flow**: Three-phase diagram and explanation (entry → routing → exit). #### Section 6 Pluggable Components * [x] Discovery: advertise Mix support via ENR, X25519 key * [x] Delay strategy: sender-defined per-hop delay * [x] Spam protection: PoW/VDF/RLN options, exit node validation * [x] Cover traffic: periodic loops for unobservability * [x] Incentivization: nodes MUST participate to send #### Section 7 Core Mix Protocol Responsibilities * [x] Define Sender, Intermediary, Exit node roles * [x] Specify lifecycle and message flow per role #### Section 8 Sphinx Packet Format (Detailed Spec) * [ ] Full field definitions (α, β, γ, δ, delays, MACs) * [ ] Encoding and padding behavior #### Section 9 Node Behavior (Mix Protocol Handler) * [ ] Describe sender node logic: path selection, packet wrapping * [ ] Describe intermediary/exit node behavior: decryption, delay, forwarding #### Section 10 Limitations and Future Work * [ ] SURB-based reply support (unimplemented) * [ ] DoS/Sybil attack surface * [ ] Path overlap, message reordering, end-to-end acks #### Appendices * [ ] Appendix A: Proof-of-Work Example * [ ] Appendix B: ENR-Based Discovery Example

Ben-PH reviewed Jun 18, 2025

View reviewed changes

AkshayaMani added 7 commits June 27, 2025 10:44

Add finalized abstract, introduction, terminology, and motivation sec…

f7fc7ad

…tions

Add finalized sections 3.1 to 5.4

296e425

Fix typos and add section transition

c0d54ad

Add Section 6: Pluggable Components (discovery, delay strategy, spam …

9aa5198

…protection, cover traffic, incentivization)

Add Section 7: Core Mix Protocol Responsibilities

74e016d

Add finalized Sections 5.4, 8-8.2

c91c502

AkshayaMani force-pushed the mix-rev1 branch from 8c1ba2a to c91c502 Compare June 27, 2025 14:52

AkshayaMani added 3 commits June 27, 2025 12:30

Wrap lines to comply with markdownlint max line length and removed in…

a704c43

…valid link for Appendix A

Fix indendation

0313171

Merge branch 'main' into mix-rev1

096fd7a

seugu reviewed Jun 27, 2025

View reviewed changes

seugu approved these changes Jun 27, 2025

View reviewed changes

AkshayaMani merged commit 5e3b478 into main Jun 27, 2025
2 checks passed

AkshayaMani deleted the mix-rev1 branch June 27, 2025 18:03

AkshayaMani mentioned this pull request Aug 11, 2025

RFC Refactor: Sphinx Packet Format #173

Merged

14 tasks

AkshayaMani mentioned this pull request Sep 29, 2025

RFC Addition: Section 9 Security Considerations #194

Open

6 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

RFC Refactor PR: Modular Rewrite of Mix Protocol Specification #158

RFC Refactor PR: Modular Rewrite of Mix Protocol Specification #158

Uh oh!

AkshayaMani commented May 19, 2025 •

edited

Loading

Uh oh!

Ben-PH Jun 18, 2025

Uh oh!

seugu left a comment

Uh oh!

seugu left a comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

RFC Refactor PR: Modular Rewrite of Mix Protocol Specification #158

RFC Refactor PR: Modular Rewrite of Mix Protocol Specification #158

Uh oh!

Conversation

AkshayaMani commented May 19, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Goals

Changes Completed in This PR

Sections 0–5: Foundational Structure and Protocol Layering

Section 4 Mixing Strategy and Packet Format

Section 5 Protocol Overview and Integration

Section 6 Pluggable Components

Section 7 Core Mix Protocol Responsibilities

Section 8 Sphinx Packet Format (Detailed Spec)

Section 9 Node Behavior (Mix Protocol Handler)

Section 10 Limitations and Future Work

Appendices

Uh oh!

Ben-PH Jun 18, 2025

Choose a reason for hiding this comment

Uh oh!

seugu left a comment

Choose a reason for hiding this comment

Uh oh!

seugu left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

AkshayaMani commented May 19, 2025 •

edited

Loading