> I guess my question didn't get across. 
> 
> Why would you want to make your usecase do connections over the peer2peer 
> (net.cpp) connection at all?

First, because there _are_ a hight amount of SPV wallets in the field.
SPV wallets are "dumb-clients" with only a tiny value for the bitcoin
network (they don't validate, they don't relay). They already are
decoupled wallets. We need solution that offers higher privacy and
higher traffic analysis resistance.

Using the p2p channel for communication between full validation peers
and wallet-only-peers makes sense IMO because wallet-only-peers can
slowly validate the chain and create a UTXO set in the background (could
take a couple of weeks) or solve other purposes that increases the
security and/or serving something back to the bitcoin network.

Sure, you can always use client/server wallets (Coinbase / Copay, etc.)
that offers SSL.
But I strongly recommend to improve the communication and interface
possibilities between wallet-nodes (SPV) and full-validation-nodes.

Otherwise we will very likely see centralization regarding end-user
wallets (with all the large risks of disrupting the community in case of
attacks/thefts, etc.).

_If we think Bitcoin should scale, we also need to scale and improve at
the point where users enter the network and start using Bitcoin._

> Mixing messages that are being sent to everyone and encrypted messages is 
> asking for trouble.
> Making your private connection out-of-band would work much better.

The current encryption BIP requires to encrypt the complete traffic.
Having an option to do analysis resistant communication with a remote
peer within the protocol itself is something that is very valuable IMO.


>>> Also, you didn't actually address the attack-vector.
>>
>> Which attack-vector?
> 
> The statistical attack I mentioned earlier.  Which comes from knowing which 
> plain text messages are being sent over the encrypted channel, So as long as 
> you keep saying you want to encrypt data that identical copies of are being 
> sent to other nodes at practically the same time, you will keep being 
> vulnerable to that.

The encryption BIP recommends Chacha20-Poly1305 as encryption AEAD. This
is a very broad used encryption scheme (Google uses it to connect
Android phones with their cloud services).

Completely avoiding side channel on data analysis would probably require
extremely inefficient constant time encrypted datastreams.

Also, the BIP allows combining of multiple plaintext message in one
encrypted message.

Additionally we could extend the enc. BIP by allowing random padding of
encrypted messages or other techniques to reduce side channel analysis.

</jonas>