Erlay: Bandwidth-efficient Bitcoin transaction relay protocol

This is an implementation of Erlay , using primitives in the BIP-330 (see the updated spec here ). Please refer to these two to understand the design. My talk on the topic is here .

Erlay uses both flooding (announcing using INV messages to all peers) and reconciliation to announce transactions. Flooding is expensive, so Erlay seeks to use it sparingly and in strategic locations - only well-connected publicly reachable nodes flood transactions to other publicly reachable nodes via outbound connections. Since every unreachable node is directly connected to several reachable nodes, this policy ensures that a transaction is quickly propagated to be within one hop from most of the nodes in the network.

All transactions not propagated through flooding are propagated through efficient set reconciliation. To do this, every node keeps a reconciliation set for each peer, in which transactions are placed which would have been announced using INV messages absent this protocol. Every 2 seconds every node chooses a peer from its outbound connections in a predetermined order to reconcile with, resulting in both sides learning the transactions known to the other side. After every reconciliation round, the corresponding reconciliation set is cleared.

I think both paper and the BIP motives the changes, but I'll mention them briefly once again here:

• save 40% of the bandwidth consumed by a node
• increase network connectivity for almost no bandwidth or latency cost
• improves privacy as a side-effect

Obviously looking for review, let's try to start with a high-level concerns, and keep nits for later.

I also have a nice-to-have list (I will do it at some point, but some help would be really great):

Rebased on #18044

P.S.

Please don't be scared of 8,000 LOC added. 7,000 of them is minisketch added as a subtree.