Hi Eric > I haven't seen much discussion here on the rationale behind BIP 151. Apologies if I missed it. I'm trying to understand why libbitcoin (or any node) would want to support it. > > I understand the use, when coupled with a yet-to-be-devised identity system, with Bloom filter features. Yet these features are client-server in nature. Libbitcoin (for example) supports client-server features on an independent port (and implements a variant of CurveCP for encryption and identity). My concern arises with application of identity to the P2P protocol (excluding Bloom filter features). > > It seems to me that the desire to secure against the weaknesses of BF is being casually generalized to the P2P network. That generalization may actually weaken the security of the P2P protocol. One might consider the proper resolution is to move the BF features to a client-server protocol. > > The BIP does not make a case for other scenarios, or contemplate the significant problems associated with key distribution in any identity system. Given that the BIP relies on identity, these considerations should be fully vetted before heading down another blind alley. In my opinion, the question should be "why would you _not_ encrypt". 1) Transaction censorship ISPs, WIFI provider or any other MITM, can holdback/censor unconfirmed transactions. Regardless if you are a miner or a validation/wallet node. 2) Peer censorship MITM can remove or add entries from a "addr" message. 3) Fingerprinting ISPs or any other MITM can intercept/inject fingerprinting relevant messages like "mempool" to analyze the bitcoin network. 4) SPV For obvious reasons regarding BF (see BIP or above). 5) Goundwork for a "client-server" model over the P2P channel Fee estimation, bloom-filters, or any other message type that requires authentication. I would not reduce BIP151 to only solve the BF privacy/censorship problem. If we agree that censorship-resistance is one of the main properties of Bitcoin, then we should definitively use a form of end-to-end encryption between nodes. Built into the network layer. There are plenty of other options to solve this problem. stunnel, Bernsteins CurveCP, VPN, etc. which are available since years. But the reality has shown that most bitcoin traffic is still unencrypted. Example: IIRC non of the available SPV wallets can "speak" on of the possible encryption techniques. Encrypting traffic below the application layer is extremely hard to set up for non-experienced users. On top of that, encryption allows us to drop the SHA256 checksum per p2p message which should result in a better performance on the network layer once BIP151 is deployed. I agree that BIP151 _must_ be deployed together with an authentication scheme (I'm working on that) to protect again MITM during encryption initialization. ---