[Rendezvous] Is a PoW requirement useful?

[thomaseizinger]

Originally raised by @burdges in libp2p/rust-libp2p#2107 (comment).

I think DDoS adversaries are botnets, so they often have massive untapped CPU, GPU, and even hard drive. I'd think honest peers cannot quickly solve a challenge within a difficulty level that presents an obstacle for adversaries.

You should probably make applications choose their rendezvous points and simply document that they should do so carefully using their own deterministic randomness. We'll eventually use a rendezvous-like protocol in polkadot, but we'll dictate the rendezvous point by VRF. Tor also dictates introduction points also via deterministic randomness, not a VRF per se but is satisfies their security properties, including being anonymous to the rendezvous point.

[thomaseizinger]

According to #334 (comment), we don't actually want PoW in the protocol.

I'll leave this ticket open to track that the spec needs to be changed to clarify that, in particular I think we should:

• State the idea of using verifiable randomness to choose a rendezvous node among a fleet of nodes. This should properly address the DDoS concern. The exact behaviour is TBD.
• Include an "alternative designs considered" section that explains why things like PoW are not useful.

[burdges]

Any deterministic/verifiable randomness sounds application specific, but that's fine given the applications being build on libp2p. I only gave examples with a radomness beacon, but anyone without one could consider H("app" ++ date ++ dest_pk) if dest_pk stays hidden from the network, or somehow VRF.Sign(sk, "app" ++ date) and VRF.Verify(pk, "app" ++ date) if pk is public.