This issue will be edited frequently to reflect the current status of the project.
What should I review now? 👇 👇 👇 👇 👇 👇 👇 #30116 ☝️ ☝️ ☝️ ☝️ ☝️ ☝️ ☝️
- Minisketch in Bitcoin Core
- Peer-to-peer
Full implementation: #30277
- Main feature: #23443
- Follow-up: #26359
- #27797
- Main feature: #26283
- #28765
- Tx reconciliation request
- Main feature: Tx reconciliation response (sending and handling)
- Main feature: Tx reconciliation extension request
- Main feature: Tx reconciliation extension response (sending and handling)
- Test: Full integration functional test
Performance research results
- How to understand bandwidth savings
- @kcalvinalvin 40% announcement-related bandwidth reduction
- @0xB10C 31.3% overall bandwidth reduction
- @hebasto: 23.8% overall bandwidth reduction
- @hebasto: 0.9% overall bandwidth overhead for running 12 connections instead of 8
- @naumenkogs older experiments — note the current version is less efficient (needed for better security)
Supplementary materials BIP 330 erlay paper minisketch repo Ancient PR: #18261 Notes from the review club: on the main PR, on the support signaling PR.
The project has received Concept ACK from many contributors, and no NACKs. I am unlikely to invent a bulletproof argument, so I leave it up to each reviewer to compare the risks and review costs to the benefits.
I personally think that the added code is pretty straightforward because it communicates with a legacy code through a thin interface (100 LOC in net_processing.cpp to collect transactions instead of relaying them immediately, although the reconciliation code is 500 LOC – excluding comments and minisketch). Hence it is acceptable to pay for the given optimization.
If you suggest any experiment that will convince you, I will do my best to execute it.