I suspect many non-technical people in the Bitcoin community have not heard of QUIC. It's a new transport protocol that Google has been working for quite some time. It's designed to address many of the shortcomings of the TCP protocol which has become ubiquitous in the web. What?! What's wrong with TCP? Well it turns out quite a lot actually. Recently I was at the IPFS developer conference in Berlin where Marten Seemann gave a great presentation on QUIC and his implementation in Libp2p. If you have the time I'd encourage you to watch it as it will be worth it.
But to summarize, TCP suffers from several problems. The first one is the fact that data is transmitted serially over wire meaning that if you're downloading a large block, say, it will prevent other messages (like new transactions) from getting through until the block download is finished. There are protocols that overcome this problem by multiplexing the different data over multiple streams. For example:
But TCP is still problematic in this case because if any packet for a given stream is dropped, the TCP protocol will block all other streams (since it doesn't know anything about the streams) until the packet gets re-transmitted. Another issue is the handshake requires multiple round trips if you want to add encryption and authentication to your connection since, again, TCP doesn't know anything about TLS. QUIC on the other hand, does the crypto handshake right in initial handshake, eliminating extra round trips.
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.


6 of 6 reviewers say it's worth paying for

0 of 6 reviewers say it's not worth paying for