Recently I read some concerns about BIP150/151 and its âidentity systemâ.I think we should take those concerns seriously and I wrote somecomments for some of the concerns I'm aware of. In my opinion, most ofthese worries are unfounded.

Concern 1: BIP150 introduces a identity system that could partition thenetwork

- Users already filtering/authenticate peers by IP tables, âaddnodeâcommand, peer banning in app-layer. Fast block relay is a good example(example: FIBRE).- BIP150 allows to switch from IP based authentication (which isobviously not ideal) to a secure form of authentication with pre-sharedkeys (ECDH).- We canât stop peer operators to selectively manage peers and there arevalid reasons to do that

Concern 2: But BIP150 makes it simpler and increase the risk of networkpartitioning

- What is simpler, presharing a pubkey over a secure channel (PGP /Signal) and store in on both peers or calling a âaddnode <ip>â, orâiptables-DROP <ip>â?

Concern 3: Identity is not something we want in Bitcoin

#######################################################

- BIP150 introduces an **optional** authentication over a EC pubkey. TheEC pubkey can be changed. Itâs different per network interface. You onlyreveal it to peers that already have proven the know your identity.- IP addresses are also a form of identity and way more inflexible anddifferent to hide.

- Without BIP151 encryption, everyone can hook into the stream and readwhatâs going on. With BIP151, an attacker needs to actively substituteephemeral keys in both direction. This attack is A) more complex toachieve and B) itâs an active attack (no excuse of âI just made somestatisticsâ), C) it requires the attacker to accept the risk of beingdetected.

- C) is true because an optional authentication (can be BIP150 ordifferent) would reveal the attack.

- Some attacks are worthless if you have to take the risk mentioned in C)

- If you use one of the todays available SPV clients, you will revealyour complete wallet content (â~all your addresses") to every networkobserver between you and the node you have connected to. This means, ifyou pay for a coffee (while being on the owners WIFI), the coffee ownerand all the involved ISPs can correlate your wallet with your otherinternet behavior. Same is true for your cellphone provider if you usecellular.

- They still can, if you donât have a trusted node, by performing theattack that involves the risk mentioned in Concern 6.

Concern 8: If you want to have a light client, you should use adifferent channel to communicate with your full node then the p2p layer

- From an end userâs perspective, this is undesirable (enabled differentport, lack of a (RPC / ZMQ, etc.) standard, no fallback option if thetrusted node is down, hard to setup)

- Using the p2p channel as the todays SPV do, seems very reasonable tome. Keep the users on the p2p layer! If we donât want the users on thatchannel, we automatically form a different layer, the wallet-com wild-west.

- Keeping the users on the p2p layer also allows future changes wherethey can help the network in some ways.

- Using the p2p layer for a trusted connection also allows to fallbackanytime to non-trusted nodes (if your trusted node is no longerreachable). If your SPV peer needs to catch up a couple of hours whileyour trusted peer was done, fine, download full blocks or change yourbloom filters FP rate significant (or sacrifices your privacy in this case).

Post by Jonas Schnelli via bitcoin-dev- If you use one of the todays available SPV clients, you will revealyour complete wallet content („~all your addresses") to every networkobserver between you and the node you have connected to. This means, ifyou pay for a coffee (while being on the owners WIFI), the coffee ownerand all the involved ISPs can correlate your wallet with your otherinternet behavior. Same is true for your cellphone provider if you usecellular.

What about allowing trusted users connecting on a different connection. Muchlike the RPC one.Make that one encrypted. Different usecase, different connection.

Post by Jonas Schnelli via bitcoin-dev- If you use one of the todays available SPV clients, you will revealyour complete wallet content (â~all your addresses") to every networkobserver between you and the node you have connected to. This means, ifyou pay for a coffee (while being on the owners WIFI), the coffee ownerand all the involved ISPs can correlate your wallet with your otherinternet behavior. Same is true for your cellphone provider if you usecellular.

What about allowing trusted users connecting on a different connection. Muchlike the RPC one.Make that one encrypted. Different usecase, different connection.

- What protocol would you use? The same p2p protocol but different portand/or different process? Why?- If not the p2p protocol, how would you form a standard? Would it beworth doing a standard?- Could you fall back to the current SPV model against random untrustedpeers if you additional channel is not available?- What are the downsides using current p2p network?- Would this also solve the security problem of creating designatedchannels between peers (the "addnode" thing is based on IPs)?

Post by Jonas Schnelli via bitcoin-dev- If you use one of the todays available SPV clients, you will revealyour complete wallet content („~all your addresses") to every networkobserver between you and the node you have connected to. This means, ifyou pay for a coffee (while being on the owners WIFI), the coffee ownerand all the involved ISPs can correlate your wallet with your otherinternet behavior. Same is true for your cellphone provider if you usecellular.

What about allowing trusted users connecting on a different connection.Much like the RPC one.Make that one encrypted. Different usecase, different connection.