>> Good point. >> I have mentioned this now in the BIP but I think the BIP should allow >> message > 16 MiB. >> I leave the max. message length up to the implementation while keeping >> the 4 byte length on the protocol level. > > I expect the implementation defined max size to work (SSH 2.0 does this > after all), but I want to make sure my suggestion is understood > completely. > > There is a length field for the encrypted data, and length field(s) > inside of the encrypted data to indicate the length of the plaintext > Bitcoin messages. I am suggesting that the outter (encrypted) length > field be reduced, which will _not limit_ the length of Bitcoin > messages. For example, if a 1 GiB Bitcoin message needed to be sent > and the encrypted length field was 3 bytes - the sender is forced to > send a minimum of 64 MACs for this message. The tradeoff is allowing > the receiver to detect malformed data sooner and have a lower max > buffering window **against** slightly higher bandwidth and CPU > requirements due to the additional headers+MACs (the CPU requirements > should primarily be in "finalizing each Poly1305"). Okay. Got your point. The current BIPs assumption is that an encrypted package/message can contain 1..n bitcoin messages (a single bitcoin message distributed over multiple encrypted messages/packages was not specified). But right, this could make sense. Let me think this through.... > An alternative way to think about the suggestion is tunnelling Bitcoin > messages over TLS or SSH. TLS 1.2 has a 2-byte length field and SSH 2.0 > a 4-byte length field, but neither prevents larger Bitcoin messages from > being tunnelled; the lengths are independent. TLS/SSH tunneling is already possible with third party software like stunnel. Also there is promising projects that would encrypt the traffic "on a deeper layer" (see CurveCP). I think what we want is a simple, openssl-independent traffic encryption built into the core p2p layer. IMO the risk of screwing up the implementation is moderate. The implementation is not utterly-complex: OpenSSH chacha20: https://github.com/openssh/openssh-portable/blob/0235a5fa67fcac51adb564cba69011a535f86f6b/chacha.c Chacha20-Poly1305: https://github.com/openssh/openssh-portable/blob/0235a5fa67fcac51adb564cba69011a535f86f6b/cipher-chachapoly.c Sure. Before an implementation will be deployed to the endusers it will require intense cryptoanalysis first.