Introducing the Mix Protocol: Enhancing Privacy Across libp2p Networks

[prem]

I agree with @fryorcraken that aspects like discovery, spam protection should be left out of the spec. Maybe a reference can be made to indicate what is expected out of discovery and spam protection layers in the spec.

Adding some context based on my current understanding of spec and current implementation.
There are some deviations from the rfc which have to be identified during implementation. So, looks like the spec will have to be modified to match the implementation. Had a discussion with @haelius yesterday regarding this. Following are some high level deviations:

1. mix is no longer implemented as a libp2p protocol but a libp2p transport. Challenges as to why are documented here
2. Implementation doesn’t have a concept of exit node, rather the destination node is also expected to support mix. There maybe a way to change this, but it may have side-effect wrt anonymity properties.

@fryorcraken

1. Using ENRs and the v4 identity scheme mean that we know have 2 public keys on ENR records secp256k1 for ENR signature, and usually libp2p authentication at connection, and now ed25519 for Sphinx encryption.

I wonder if there is a way to move to a single encryption scheme by having:

• ENR signature
• libp2p auth at connection (libp2p-noise)
• Sphinx encryption

Done with one key, one scheme.

Note it matters because The maximum encoded size of a node record is 300 bytes.

This is a good point. it would be ideal to look for a single scheme to avoid adding more data to ENR. wdyt? @akshaya
But i am wondering that we are anyways going to hit the ENR limits if we have to include mix transport details in the multiaddr field.
We have faced this problem before as well in case of circuit-relay in status where ENR limits were being hit to due multiple multiaddresses being inlcuded. Wondering if is time to take a look at this problem of limited ENR size and address it.
cc @ksr are you aware if any work been done before on this front i.e to increase size of ENR or find an alternative way to keep publishing only diff in the records during changes(as the 300 bytes limitation seems to have been introduced due to records are relayed frequently and may be included in size-constrained protocols such as DNS as mentioned here?

@fryorcraken

(2) supported_protocols (long name) provide a plain text version of each protocol. This can be problematic due to size restriction. It also does not specify the full protocol identifier. See (3)

As state above, since mix is going to be a transport the way a node advertises it supports mix will no longer be via protocol anymore and probably part of a separate field which encapsulates mix transport address or just part of multiaddress field.

@fryorcraken

(3) The RFC does not specify how the Sender should encode the protocol to use for dessimination. What is the role of the supported_protocols information onf the ENR? It seems not needed.

This gets addressed by the deviations i had indicated above where-in mix is no longer a protocol but a transport type.

@fryorcraken

Related to above, it may make sense to keep this out of the scope of the libp2p-mix protocol definition. Meaning that the sender nodes select an exit node that:

• support mix protocol
• fit whatever criteria the consumer requires

This gets modified as per deviation mentioned above that destination node is required to support mix.

@fryorcraken

What is L-1? Would be good to introduce the variable first.

L is supposed to be the path length, but yes…better to introduce the variable in the spec.

@fryorcraken

if the multiaddress is encoded in the packet. Then why performing discovery and not just proceed with connection?

Also, may be better to have multaddresses to allow for several transport protocols.

true, i guess if different transports are to be supported then it would be not possible to embed complete multiaddress but only peerID in the packet which would then require to do discovery. But this would introduce a latency until all paths are formed in the network and anytime a path is chosen where intermediary peers are not connected to each other.
So i guess each approach (filling complete multiaddress or only peerID) has its own tradeoffs.
@akshaya just including the next peerID should also be enough right.

@fryorcraken

(7) If discovery is expected to be used mid-transmission then it may make sense to introduce redundancy in the circuit, meaning a tree-like circuit.

Are you suggesting introducing multiple paths in the circuit at every intermediary node for redundancy? This may work if we are using mix with a libp2p protocol which is not req-resp based i.e gossipsub. But if we have to use with any other protocols such as lightpush/store(which is what we plan to first POC mix with) I see couple of challenges with introducing multiple paths for req-resp protocols:

1. mix is used only as a logical tunnel between initiator and destination peer, not sure if we can consider having multiple paths in between.
2. The reply to a request e.g in case of lightpush is planned to be implemented by the use of Single use reply blocks which from what i understand the node which has initiated the request will include some sort of a header for reply that is used by destination node in order to respond. this would preserve anonymity of initiating node. If we have to use multiple paths at every stage, this would not be feasible as destination node will end up receiving multiple requests to begin with.

To achieve redundancy, the initiator can choose to send same message via multiple paths to achieve redundancy.

@fryorcraken

What does this mean? I could not find reference to the concept of replacement in Sphinx’ paper ,

not sure, maybe @akshaya can answer.

points 9,10: get addressed with my discussion above wrt whether we have to store complete multiaddress in the packet or only peerID.

@akshaya maybe we can update the spec itself as per current implementation since we can’t go back to a protocol approach.