And this fixes another issue the Bitcoin has had for a long time ― no encryption or authentication! Jonas Schnelli has created bips 150/151 to add encryption/authentication to Bitcoin, but it hasn't been implemented. Neither does it optimize the handshake in the same way that QUIC does as it just adds yet more handshakes to the protocol. Further it's a very non-standard encryption/authentication protocol whereas QUIC just uses TLS 1.3. If we had QUIC you could pretty easily securely connect your mobile SPV wallet to your home node (or any other trusted node) just by importing the IP address and public key/certificate into your phone. Today this isn't possible without hacking your wallet to connect to a hidden service (which I've done), but it's so slow it's basically unusable. Finally, QUIC uses a forward error correction protocol which transmits some extra data which allows for a receiving node to re-construct any lost packets without re-transmission, speeding up transmission further. I should also add that since QUIC is a UDP based transport it opens up the ability to use various UDP hole punching techniques to improve p2p network connectivity with nodes behind firewalls that you can't currently do with TCP. The result of these optimizations is Google sees up to an 8% improvement in search latency when using QUIC instead of TCP. Which is rather large when you consider how optimized search is already. My plan is to add QUIC as a transport option in OpenBazaar alongside TCP later this year. If all goes well I'll probably just drop TCP support altogether. So what would it take to get it into Bitcoin Cash? Well, ideally it would start as just an experiment in one of the lesser used implementations. My personal preference would be for a Go implementation as it's easy to quickly prototype in that language and has good QUIC support. The only real issue I see with the Bitcoin protocol is the Network Address message that is used by the protocol is very inflexible. The way it distinguishes between IPv4, IPv6, and onion is by prefixing the addresses. But since the space is only 16 bytes, you'd have no way to specify QUIC over IPv6 as the protocol just assumes IPv6 is always TCP. Bumping the protocol version and adding an additional byte to the Network Address to signal what transport is used would probably be relatively easy.