Issue Details
- Number
- 30249
- Title
- Erlay Project Tracking
- Description
- This issue will be edited frequently to reflect the current status of the project.
**What should I review now?**
👇 👇 👇 👇 👇 👇 👇
#30116
☝️ ☝️ ☝️ ☝️ ☝️ ☝️ ☝️
- [x] Minisketch in Bitcoin Core
- [x] Main feature: #23114
- [x] #23670
- [x] #23496
- [x] #26272
- [x] Subtree updates: #24262, #25502, #26373
- [ ] Peer-to-peer
Full implementation: #30277
- [x] Main feature: #23443
- [x] Follow-up: #26359
- [x] #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](https://github.com/naumenkogs/txrelaysim/issues/7)
- @kcalvinalvin [40% announcement-related bandwidth reduction](https://github.com/naumenkogs/txrelaysim/issues/8#issuecomment-1016075657)
- @0xB10C [31.3% overall bandwidth reduction](https://github.com/naumenkogs/txrelaysim/issues/8#issuecomment-920852514)
- @hebasto: [23.8% overall bandwidth reduction](https://github.com/naumenkogs/txrelaysim/issues/8#issuecomment-1016307869)
- @hebasto: [0.9% overall bandwidth overhead for running 12 connections instead of 8](https://github.com/naumenkogs/txrelaysim/issues/8#issuecomment-1018834268)
- @naumenkogs older experiments — note the current version is less efficient (needed for better security)
- 8 conns [overall 40% bandwidth savings](https://github.com/bitcoin/bitcoin/pull/18261#issuecomment-599241490)
- 16 conns [1.8x erlay; 2.23x non-erlay — overall bandwidth increase compared to 8 conns](https://github.com/bitcoin/bitcoin/pull/18261#issuecomment-600388543)
**Supplementary materials**
[BIP 330](https://github.com/bitcoin/bips/blob/master/bip-0330.mediawiki)
[erlay paper](https://arxiv.org/pdf/1905.10518.pdf)
[minisketch repo](https://github.com/sipa/minisketch)
Ancient PR: #18261
Notes from the review club: [on the main PR](https://bitcoincore.reviews/18261), [on the support signaling PR](https://bitcoincore.reviews/23443).
<details><summary><b>F.A.Q.</b></summary>
<i>1. Are these bandwidth savings worth the added code complexity?</i>
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.
</details>
- URL
-
https://github.com/bitcoin/bitcoin/issue/30249
- Closed by
-
Back to List