Mix Protocol Spec

[AkshayaMani]

No description provided.

[rymnc]

Content looks great to me! An amazing RFC, well written and understandable from implementer PoV.

Some questions and notes in-line 👍

[rymnc]

Should we alter the RFC to be agnostic to the transport? I remember that you mentioned it.
cc: @kaiserd

[rymnc]

Can we use a different method of spam prevention here? I understand that RLN may add more overhead but was wondering about the trade-offs and why it might be useful to use PoW here instead :)

[AkshayaMani]

Great question! Yes, we can use a different method of spam prevention, such as RLN. However, given the need for a decentralized, simple, and independent spam prevention mechanism in our custom mix protocol, PoW is the preferred choice.

i. PoW does not require a trusted setup or continuous management. It operates independently without relying on any central or semi-trusted authority.
ii. It does not have dependencies on external systems or blockchains, avoiding the overhead and potential points of failure associated with such integrations. This ensures that our mix protocol remains self-contained and robust.
iii. It provides a straightforward security model by requiring computational effort to send messages. It is simple to implement and understand, making it easier to integrate into our mix protocol without introducing additional complexity.
iv. When implemented properly, PoW scales well. The exit nodes can efficiently verify a large number of incoming messages without significant performance degradation.

In future versions, we can add more complex and robust methods of spam prevention.

[rymnc]

totally understand now, but in the event that there is a malicious actor with large compute capacity, will the network be able to handle the load?
This is what killed whisper

[AkshayaMani]

This is a valid question! Our Mix Protocol improves on Whisper by centralizing PoW verification to exit nodes rather than every node along the message path. This reduces the computational load to a linear relationship between the number of messages and verifications, rather than the multiplicative burden seen in Whisper.

While this design helps mitigate computational strain, exit nodes are still vulnerable to targeted attacks. To counter this, PoW difficulty can be dynamically adjusted based on network load, with updated levels communicated via ENRs. Senders can then perform discovery to obtain the current ENR of the chosen exit node(s), ensuring they use the appropriate PoW difficulty. This would help the network adapt to varying conditions. This approach enhances resistance to spam, though it is worth noting that similar vulnerabilities are faced by other anonymity networks as well.

Despite these limitations, PoW is a practical choice due to its decentralized, simple, and independent nature. While alternative mechanisms might offer more robustness, they require trust or blockchain dependencies. Thus, PoW offers a pragmatic solution for initial deployment and can be refined over time to provide more resistance against high-compute capacity attacks.

[seugu]

Just a note. I am wondering whether using Verifiable Delay Functions(VDFs) may be used as alternative of the PoW which eliminates the parallel computing advantages of the users who have computational power for future versions.

[AkshayaMani]

Using Verifiable Delay Functions (VDFs) as an alternative to Proof of Work (PoW) is an interesting idea. VDFs require sequential computation, which eliminates the parallel computing advantages of users with high computational power, creating a more level playing field. They also provide efficient verification and deterministic output, which can enhance the protocol's performance.
However, implementing VDFs may introduce additional complexity and could require a trusted setup, raising new security considerations. While VDFs are promising for future versions of the Mix protocol, we should carefully evaluate their maturity and practical applications before deciding to integrate them.

[kaiserd]

Let's just call it an interface for pluggable spam protection, and list PoW, VDFs, and (maybe) RLN as potential candidates. (As pointed out by @rymnc below, RLN depends on timestamps; maybe we can modify to compensate for increased time delays.)
I'd maybe not even list this as one of the core components, since there are other components that can be made pluggable, too, like:
peer discovery, and incentivization, cover traffic

[rymnc]

cc'ing @ramsesfv for crypto review

[rymnc]

This is quite interesting, I initially thought RLN could be used for rate limiting in this context but due to the random delays that may be introduced at each intermediary node, verifying RLN proofs becomes difficult since they are strictly coupled to the sender timestamp

[rymnc]

(in the context of waku)

[AkshayaMani]

Even with the PoW, we couple it with the sender timestamp to avoid replay attacks. However, to accommodate delays, we choose a reasonable acceptance time window of 5 minutes or so. We could come up with something similar for RLN as well.

However, the main reason for choosing PoW over other spam prevention mechanisms is its simplicity, and not requiring a trusted setup or dependancy on blockchain and continuous management.

[rymnc]

understood!
cc: @kaiserd for inputs on PoW

[rymnc]

Suggested change

	### normative
	[libp2p](https://libp2p.io)\
	[Sphinx](https://cypherpunks.ca/~iang/pubs/Sphinx_Oakland09.pdf)
	### informative
	[PoW](https://bitcoin.org/bitcoin.pdf)\
	[Sphinx packet size](https://petsymposium.org/popets/2024/popets-2024-0050.pdf)
	### normative
	- [libp2p](https://libp2p.io)\
	- [Sphinx](https://cypherpunks.ca/~iang/pubs/Sphinx_Oakland09.pdf)
	### informative
	- [PoW](https://bitcoin.org/bitcoin.pdf)\
	- [Sphinx packet size](https://petsymposium.org/popets/2024/popets-2024-0050.pdf)

[rymnc]

LGTM, cc: @kaiserd for final review

[seugu]

Just a note. I am wondering whether using Verifiable Delay Functions(VDFs) may be used as alternative of the PoW which eliminates the parallel computing advantages of the users who have computational power for future versions.

[seugu]

In case there is no enough mixnodes in a network, may it cause some anonymity leakages for mixnodes? If so, is there any theroetical threshold percentage for being safe?

[AkshayaMani]

You raise an important point. Indeed, having too few mix nodes can potentially lead to anonymity leakages, and this is not exclusive to our mix protocol but a general concern for all mix networks. While there's no universally agreed-upon threshold, the general principle is that more mix nodes provide better anonymity.

To mitigate risks in smaller networks, we could consider (in the later versions):

1. Implementing stricter node selection criteria
2. Introducing additional cover traffic

We should keep this in mind as we develop and deploy the protocol.

[seugu]

Is there any specific reason to use CTR mode?

[AkshayaMani]

While other secure stream ciphers could potentially be used, AES-CTR provides a good balance of security, efficiency, and ease of implementation for the Mix protocol's requirements.

[kaiserd]

Thanks a lot for the progress on this spec.
I left some comments inline.

Generally, we should introduce the spec parlance "MUST", "SHOULD" etc in the specification section.

The spec is ready to be merged as a first raw version.
This will allow us to get early feedback from the community.

Nit: There some markdown linter issues that need to be fixed.

We can open a new PR updating this spec right after merging, to continue refining this spec.

[kaiserd]

Let's just call it an interface for pluggable spam protection, and list PoW, VDFs, and (maybe) RLN as potential candidates. (As pointed out by @rymnc below, RLN depends on timestamps; maybe we can modify to compensate for increased time delays.)
I'd maybe not even list this as one of the core components, since there are other components that can be made pluggable, too, like:
peer discovery, and incentivization, cover traffic

[AkshayaMani]

New PR can be found here: libp2p Mix Protocol Spec Draft #97