-
Notifications
You must be signed in to change notification settings - Fork 37.7k
Description
This issue will be edited frequently to reflect the current status of the project.
What should I review now?
👇 👇 👇 👇 👇 👇 👇
#30116
☝️ ☝️ ☝️ ☝️ ☝️ ☝️ ☝️
- Minisketch in Bitcoin Core
- Main feature: Add minisketch subtree and integrate into build/test #23114
- build: Build minisketch test in
make check
, not inmake
#23670 - fuzz: Add minisketch fuzz test #23496
- test: Prevent UB in
minisketch_tests.cpp
#26272 - Subtree updates: upstream: Update minisketch subtree #24262, upstream: update minisketch subtree #25502, Update minisketch subtree to latest upstream #26373
- Peer-to-peer
Full implementation: Erlay: bandwidth-efficient transaction relay protocol #21515- Main feature: p2p: Erlay support signaling #23443
- Follow-up: p2p: Erlay support signaling follow-ups #26359
- rpc, net: add erlay status in
getpeerinfo
#27797 - Main feature: p2p: Fill reconciliation sets and request reconciliation (Erlay) #26283
- p2p: Fill reconciliation sets (Erlay) #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
- my 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.
F.A.Q.
1. Are these bandwidth savings worth the added code complexity?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.