See first #18987 and #18988 for code PoCs
The current networking approach suffers from a wide range of issues with regards to transaction origin inference, counter-measures against key infrastructure attackers, and harder security assumptions of higher-level protocols. Being heavily optimized and at same time trying to solve diverse goals like reasonable network security , tx-relay privacy, hindering block-topology, peer diversity, … a functional networking stack is likely unable to address aforementioned issues without compromising its robustness.
Ideally you want to address scenarios with higher security requirements like an exchange receiving headers-over-DNS to detect tip pinning. A conscientious user always relying on tx-over-radio for each of its coins sends. You can also think about a LN hub willingly to use a HTTPS connection to a block explorer for emergency tx broadcast or an SPV wallet receiving filters-headers-over-obfs4 to defeat local Internet censorship. Of course, you can still rely on external modules or project, but better integrating them with Core to ease deployment and combine them for increased benefits.
Combining may make sense with regards to:
- Solving first-hop transaction relay by easing identityless broadcast as a best-practice through wireless communications or anonymous network without relying on any specific one.
- Increasing block mesh distribution, if you have few power users receiving block from space or long-range radios and beaming them through any link to geographical-near other full-nodes may considerably increase network security by decreasing the chance of network infrastructure disruption.
- Reactive behavior for LN node, you may detect an abnormal block delay by receiving headers-over-LN and use any link available to close your channels
There are more variables at play like user capacities, disruption length, user block-time sensitiveness, disruption amplitude, information leakage. Building a comprehensive model that cover everything is hard, even if there have been few attempts. There are trade-offs, urgency filter-headers fetching from centralized service may prevent your node from being eclipsed at the cost of privacy.
Keeping these in mind, introducing an alternative networking stack as PoC’ed in AltNet may be a long-term solution. While designing such stack, flexibility and modularity should be end-goals while minding per-user requirement, technical capabilities and unknown real-world topology. A generic “drivers” framework, abstracting all of the link oddities seems like an interesting direction to explore. Use of these drivers should never be the default to avoid massive topology modification and be well-documented to let user pick up what suits his/her needs. If we have a robust, fail-safe higher half in the codebase, driver code may be in another repo within the bitcoin-core.org to avoid painful review process.
Some may object that we can rely on Tor to further our goals with regards to anonymity and network censorship-resistant. However, a) Tor DoS is an issue b) bridge dissemination may not suit bitcoin security assumptions c) Tor doesn’t seem to explore wireless communications d) we may still reuse pluggable transports like Snowflake or meek without being forced to pas through monitorable exit nodes.
If this proposal is evaluated as worthy for the project, there are a lot of design issues to address, like Rust vs CPP, architecture integration (new threads vs new process), the fanciness of new fetching logic, how to avoid a review iceberg like #17376 as a first step but instead privileging incremental steps, how driver devs may contribute to the project without understanding of other components allowing them to experiment with the protocol’s unique flow semantic…
Such subject are hard to encompass so it’s likely there are a lot of aspects not raised here. I’m eager to hear people feedback.