Newsletters: add 385, the 2025 year-in-review special #2574
Conversation
|
pushed I might still need to edit them, but putting out a draft early, will look at "Erlay update" next |
|
Just went through the past year's London BitDevs topics, a few that we covered that might be relevant to include? I'm aware my bias/focus is more on Core related stuff, definitely don't mean to nudge things more that way so feel free to leave out anything that's not high-enough signal of course. Consider this just an additional source of inspiration.
|
|
|
||
| - **Erlay update:** Sergi Delgado made [several posts][erlay optech posts] over | ||
| the last year about his work and progress implementing [Erlay][erlay] for | ||
| Bitcoin Core. In the first post, he gave an overview on the Erlay proposal and |
There was a problem hiding this comment.
| Bitcoin Core. In the first post, he gave an overview on the Erlay proposal and | |
| Bitcoin Core. In the first post, he gave an overview of the Erlay proposal and |
| [filtering based on transaction knowledge][erlay knowledge] not mattering as | ||
| much as expected. He also experimented with selecting [how many peers should |
There was a problem hiding this comment.
| [filtering based on transaction knowledge][erlay knowledge] not mattering as | |
| much as expected. He also experimented with selecting [how many peers should | |
| [filtering based on transaction knowledge][erlay knowledge] not being as impactful as | |
| expected. He also experimented with selecting [how many peers should |
| bandwidth savings with 8 outbound peers and 45% with 12 outbound peers, but | ||
| also found a 240% increase in latency. In his two other experiments, he | ||
| determined the [fanout rate based on how a transaction was | ||
| received][erlay transaction received] and [when to select canidate |
There was a problem hiding this comment.
| received][erlay transaction received] and [when to select canidate | |
| received][erlay transaction received] and [when to select candidate |
|
|
||
| {:#garbledlocks} | ||
| - **Garbled locks:** Robin Linus [posted][bitvm3 post] to Delving Bitcoin to announce a | ||
| significant reduction in the amount of onchain space required by [BitVM][topic acc]-style contracts. Based on an [idea][delbrag rubin] by Jeremy Rubin, the new approach leverages [Garbled Circuits][garbled circuits wiki], a new cryptographic primitive that makes onchain SNARK verification a thousand times more efficient with respect to BitVM2 implementation, at the cost of requiring a multi-terabyte offchain setup. |
There was a problem hiding this comment.
| significant reduction in the amount of onchain space required by [BitVM][topic acc]-style contracts. Based on an [idea][delbrag rubin] by Jeremy Rubin, the new approach leverages [Garbled Circuits][garbled circuits wiki], a new cryptographic primitive that makes onchain SNARK verification a thousand times more efficient with respect to BitVM2 implementation, at the cost of requiring a multi-terabyte offchain setup. | |
| significant reduction in the amount of onchain space required by [BitVM][topic acc]-style contracts. Based on an [idea][delbrag rubin] by Jeremy Rubin, the new approach leverages [Garbled Circuits][garbled circuits wiki], a cryptographic primitive that makes onchain SNARK verification a thousand times more efficient than the BitVM2 implementation, at the cost of requiring a multi-terabyte offchain setup. |
| - **Garbled locks:** Robin Linus [posted][bitvm3 post] to Delving Bitcoin to announce a | ||
| significant reduction in the amount of onchain space required by [BitVM][topic acc]-style contracts. Based on an [idea][delbrag rubin] by Jeremy Rubin, the new approach leverages [Garbled Circuits][garbled circuits wiki], a new cryptographic primitive that makes onchain SNARK verification a thousand times more efficient with respect to BitVM2 implementation, at the cost of requiring a multi-terabyte offchain setup. | ||
|
|
||
| On the same topic, Liam Eagen [posted][eagen ml] to the Bitcoin-Dev mailing list about a [paper][eagen paper] he has written about a new mechanism for creating [accountable computing contracts][topic acc] based on Garbled Circuits, called Glock (Garbled Locks). While the approach is similar, Eagen's research is indipendent from Linus'. According to Eagen, Glock allows for a 550x reduction of onchain data compared to BitVM2. |
There was a problem hiding this comment.
| On the same topic, Liam Eagen [posted][eagen ml] to the Bitcoin-Dev mailing list about a [paper][eagen paper] he has written about a new mechanism for creating [accountable computing contracts][topic acc] based on Garbled Circuits, called Glock (Garbled Locks). While the approach is similar, Eagen's research is indipendent from Linus'. According to Eagen, Glock allows for a 550x reduction of onchain data compared to BitVM2. | |
| On the same topic, Liam Eagen [posted][eagen ml] to the Bitcoin-Dev mailing list about a [paper][eagen paper] he has written about a new mechanism for creating [accountable computing contracts][topic acc] based on Garbled Circuits, called Glock (Garbled Locks). While the approach is similar, Eagen's research is independent from Linus'. According to Eagen, Glock allows for a 550x reduction of onchain data compared to BitVM2. |
| {:#channeljamming} | ||
|
|
||
| - **Channel jamming mitigation simulation results and updates:** Carla | ||
| Kirck-Cohen in collaboration with Clara Shikhelman and elnosh had updated the |
There was a problem hiding this comment.
| Kirck-Cohen in collaboration with Clara Shikhelman and elnosh had updated the | |
| Kirk-Cohen, in collaboration with Clara Shikhelman and elnosh, had updated the |
| Kirck-Cohen in collaboration with Clara Shikhelman and elnosh had updated the | ||
| [lightning jamming simulation results][channel jamming results], and updates | ||
| to their reputation algorithm. The updates included reputation tracking for | ||
| outgoing channels, and resources being limited on incoming channels. With |
There was a problem hiding this comment.
| outgoing channels, and resources being limited on incoming channels. With | |
| outgoing channels, and tracking incoming channel resource limitations. With |
| improvements over the decade and if so did libsecp256k1 keep up. What | ||
| Falbesoner found was that over the years libsecp256k1 had improved |
There was a problem hiding this comment.
| improvements over the decade and if so did libsecp256k1 keep up. What | |
| Falbesoner found was that over the years libsecp256k1 had improved | |
| improvements over the decade, and if so, whether libsecp256k1 had kept up. | |
| Falbesoner found that over the years, libsecp256k1 had improved |
| faster than OpenSSL, but this analysis was done to see if OpenSSL had made any | ||
| improvements over the decade and if so did libsecp256k1 keep up. What | ||
| Falbesoner found was that over the years libsecp256k1 had improved | ||
| significantly whereas OpenSSL had remained the same. He also concluded that |
There was a problem hiding this comment.
| significantly whereas OpenSSL had remained the same. He also concluded that | |
| significantly, whereas OpenSSL had remained the same. He also concluded that |
|
@bitschmidty, when do you plan to merge and publish this? (Maybe you can add that info at the beginning of the description.) I would like to review everything a day or two before then. (I may review before then too, if I have time.) |
Publishing Friday early morning. Thanks for reviewing @LarryRuane ! |
|
Pushed some changes to fix the build. Added December items to quantum and soft forks |
|
Pushed a merge from master to pull in recent newsletters that were being referenced (and failing) |
bitschmidty
left a comment
bitschmidty
left a comment
There was a problem hiding this comment.
Review covering the items so far from @kevkevinpal @reardencode @TumaBitcoiner and @stickies-v
| - **Erlay update:** Sergi Delgado made [several posts][erlay optech posts] over | ||
| the last year about his work and progress implementing [Erlay][erlay] for |
There was a problem hiding this comment.
| - **Erlay update:** Sergi Delgado made [several posts][erlay optech posts] over | |
| the last year about his work and progress implementing [Erlay][erlay] for | |
| - **Erlay update:** Sergi Delgado made [several posts][erlay optech posts] this | |
| year about his work and progress implementing [Erlay][erlay] in |
| the last year about his work and progress implementing [Erlay][erlay] for | ||
| Bitcoin Core. In the first post, he gave an overview on the Erlay proposal and | ||
| how the current transaction relay works (called fanout). In these posts, he | ||
| discusses different results that he found while developing Erlay, such as |
There was a problem hiding this comment.
I think past tense makes sense for this newsletter @kevkevinpal
| discusses different results that he found while developing Erlay, such as | |
| discussed different results that he found while developing Erlay, such as |
| ## March | ||
|
|
||
| {:#forkingguide} | ||
| - **Bitcoin Forking Guide:** Anthony Towns [posted][fork guide post] to Delving |
There was a problem hiding this comment.
| - **Bitcoin Forking Guide:** Anthony Towns [posted][fork guide post] to Delving | |
| - **Bitcoin Forking Guide:** In February, Anthony Towns [posted][fork guide post] to Delving |
| ## March | ||
|
|
||
| {:#forkingguide} | ||
| - **Bitcoin Forking Guide:** Anthony Towns [posted][fork guide post] to Delving |
There was a problem hiding this comment.
@TumaBitcoiner I think we should link to our coverage of these items, where applicable. I think the fork guide post link could link to our newsletter coverage (or add another link and keep both)
|
|
||
| {:#templatemarketplace} | ||
| - **Private block template marketplace to prevent centralizing MEV:** Developers | ||
| Matt Corallo and 7d5x9 [posted][template mrkt post] to Delving Bitcoin a |
There was a problem hiding this comment.
@TumaBitcoiner similar to above, we should make sure we also link to our own newsletter coverage of this
| {:#channeljamming} | ||
| - **Channel jamming mitigation simulation results and updates:** Carla | ||
| Kirck-Cohen in collaboration with Clara Shikhelman and elnosh had updated the | ||
| [lightning jamming simulation results][channel jamming results], and updates |
There was a problem hiding this comment.
| [lightning jamming simulation results][channel jamming results], and updates | |
| [Lightning jamming simulation results][channel jamming results], and updates |
|
|
||
| {:#channeljamming} | ||
| - **Channel jamming mitigation simulation results and updates:** Carla | ||
| Kirck-Cohen in collaboration with Clara Shikhelman and elnosh had updated the |
There was a problem hiding this comment.
It wasnt so much an update as publishing the initial results, right? @kevkevinpal
There was a problem hiding this comment.
Yeah that's correct, initial results to their updated reputation algorithm
There was a problem hiding this comment.
resolved in 63b9e37, let me know if this wording looks good
| [resource][channel jamming resource] and [sink][channel jamming sink] attacks. | ||
| After this round of updates and simulations, they feel that [channel jamming | ||
| attack][channel jamming attack] mitigation has reached a point where it is | ||
| good enough. |
There was a problem hiding this comment.
Maybe we can elaborate slightly. Good enough for what? @kevkevinpal
There was a problem hiding this comment.
In the post itself Carla doesn't really elaborate exactly she means by "Good Enough" which is why I left it as is. Not sure if it is okay for me to guess what she means by that.
| ## November | ||
|
|
||
| {:#secpperformance} | ||
| - **Comparing performance of ECDSA signature validation in OpenSSL vs. libsecp256k1:** Sebastian Falbesoner conducted an |
There was a problem hiding this comment.
I think we should cut down this summary by 50%. I think it is just too many words and can be summarized more succinctly. @kevkevinpal
There was a problem hiding this comment.
resolved in 63b9e37 I removed some of the fluff text
bitschmidty
left a comment
bitschmidty
left a comment
There was a problem hiding this comment.
Review covering the items so far from @kevkevinpal @reardencode @TumaBitcoiner and @stickies-v
bitschmidty
left a comment
bitschmidty
left a comment
There was a problem hiding this comment.
Left a suggestion for @murchandamus
Suggestions for @TumaBitcoiner (and a commit to change some of the simplicity section formatting)
Couple suggestions for @stickies-v Stratum V2 callout
Few suggestions for @kevkevinpal on the stale rates item
| due to node operators manually configuring lower limits. By mid August, [over | ||
| 30% of confirmed transactions][mononautical 32] paid feerates lower than 1 | ||
| s/vB. Bitcoin protocol developers observed that the high rate of non-standard | ||
| transactions was causing increased latency for block propagation and |
There was a problem hiding this comment.
| transactions was causing increased latency for block propagation and | |
| transactions was [causing increased latency for block propagation][0xb10c delving] and |
thoughts @murchandamus ? (link reference also recommended below)
| [news340 lowering feerates]: /en/newsletters/2025/02/07/#discussion-about-lowering-the-minimum-transaction-relay-feerate | ||
| [mononautical 85]: https://x.com/mononautical/status/1949452588992414140 | ||
| [mononautical 32]: https://x.com/mononautical/status/1958559008698085551 | ||
| [news366 lower feerate]: /en/newsletters/2025/08/08/#continued-discussion-about-lowering-the-minimum-relay-feerate |
There was a problem hiding this comment.
| [news366 lower feerate]: /en/newsletters/2025/08/08/#continued-discussion-about-lowering-the-minimum-relay-feerate | |
| [news366 lower feerate]: /en/newsletters/2025/08/08/#continued-discussion-about-lowering-the-minimum-relay-feerate | |
| [0xb10c delving]: https://delvingbitcoin.org/t/stats-on-compact-block-reconstructions/1052/35 |
|
|
||
| {:#simplicity} | ||
| - **Details about the design of Simplicity:** After the release of | ||
| [Simplicity][topic simplicity], Russel O'Connor made three posts to |
There was a problem hiding this comment.
| [Simplicity][topic simplicity], Russel O'Connor made three posts to | |
| [Simplicity][topic simplicity] on the Liquid network, Russel O'Connor made three posts to |
| [posted][Cedarctic post] to Delving Bitcoin about flaws in Border Gateway | ||
| Protocol (BGP) to prevent full nodes from being able to connect to peers, | ||
| which could be used to partition the network or execute an [eclipse | ||
| attack][eclipse attack]. Several mitigations were described by cedarctic, |
There was a problem hiding this comment.
| [posted][Cedarctic post] to Delving Bitcoin about flaws in Border Gateway | |
| Protocol (BGP) to prevent full nodes from being able to connect to peers, | |
| which could be used to partition the network or execute an [eclipse | |
| attack][eclipse attack]. Several mitigations were described by cedarctic, | |
| [posted][Cedarctic post] to Delving Bitcoin about flaws in Border Gateway | |
| Protocol (BGP) which could be used to prevent full nodes from being able to connect to honest peers, | |
| potentially allowing partitioning of the network or execution of [eclipse | |
| attacks][eclipse attack]. Several mitigations were described by cedarctic, |
| which could be used to partition the network or execute an [eclipse | ||
| attack][eclipse attack]. Several mitigations were described by cedarctic, | ||
| with other developers in the discussion describing other mitigations and | ||
| ways to monitor for use of the attack. |
There was a problem hiding this comment.
| ways to monitor for use of the attack. | |
| ways to monitor for the attack. |
| proportional to their share of hashrate. He then outlines two situations in | ||
| which a block goes stale. The situations were either another miner found a | ||
| block before this miner or another miner found a block after this miner. | ||
| Poinsot pointed out that between these two situations a block is more likley |
There was a problem hiding this comment.
| Poinsot pointed out that between these two situations a block is more likley | |
| Poinsot pointed out that between these two situations, a block is more likely |
| which a block goes stale. The situations were either another miner found a | ||
| block before this miner or another miner found a block after this miner. | ||
| Poinsot pointed out that between these two situations a block is more likley | ||
| to become stale in the first one, he suggests that miners prefer to hear about |
There was a problem hiding this comment.
| to become stale in the first one, he suggests that miners prefer to hear about | |
| to become stale in the first one. He suggests that miners prefer to hear about |
| block before this miner or another miner found a block after this miner. | ||
| Poinsot pointed out that between these two situations a block is more likley | ||
| to become stale in the first one, he suggests that miners prefer to hear about | ||
| others' blocks faster than publishing their own. Later in the post he computes |
There was a problem hiding this comment.
| others' blocks faster than publishing their own. Later in the post he computes | |
| others' blocks faster than publishing their own. Later in the post, he computes |
| Poinsot pointed out that between these two situations a block is more likley | ||
| to become stale in the first one, he suggests that miners prefer to hear about | ||
| others' blocks faster than publishing their own. Later in the post he computes | ||
| by exactly how much does the probability increase and found that if a mining |
There was a problem hiding this comment.
| by exactly how much does the probability increase and found that if a mining | |
| how much does the probability increases and found that a mining |
| operation with 5EH/s can expect a revenue of $91M and if blocks took 10 | ||
| seconds to propogate the revenue would increase by $100k. |
There was a problem hiding this comment.
| operation with 5EH/s can expect a revenue of $91M and if blocks took 10 | |
| seconds to propogate the revenue would increase by $100k. | |
| operation with 5EH/s that normally expected $91M of revenue would receive an additional $100k in revenue if blocks took 10 | |
| seconds to propagate. |
|
Added checkboxes to each item in the PR description. Updated the status of each as of the status in this PR as of a few minutes ago. There are some items that are currently still up for grabs. If authors have additional time, let me know. |
| In January, Stefan Richter prompted excitement by [discovering][news340 richter ggt] | ||
| that an efficient algorithm for the _maximum-ratio closure problem_ from a | ||
| 1989 research paper could be applied to cluster linearization. Pieter Wuille | ||
| extended his research to incorporate this minimal-cut-based third approach. |
There was a problem hiding this comment.
Is something out of order here? The ggt paper is mentioned here as a "third approach", but candidate-set search and spanning-forest linearization are only mentioned below.
Also, this paragraph seems to list events across many months, while it's all under a "May" section?
There was a problem hiding this comment.
When theres an item that was mentioned multiple months, we sort of bite the bullet on where that item might live. I think we could reword some of this item for it to fit a bit more naturally in May. Or alternatively, Cluster Mempool could be its own callout (separate from the monthly entries)
There was a problem hiding this comment.
Oh, when I wrote this, I thought it was its own separate callout. I’ll take another look at the “third approach” being used before introducing the other two.
There was a problem hiding this comment.
For reference, cluster mempool callout from last year: https://bitcoinops.org/en/newsletters/2024/12/20/#cluster
|
Pushed a fixup for the build for the splicing section (trailing spaces). Converting from draft for review today. Some items still being authored. |
9 participants
Stratum v2 - location TBD - @stickies-v
Splicing @Gustavojfe we dont have a news item on this but based on notable code merges I think we can add splicing as an item under one of the months. Maybe you can take a look on when merges happened for different implementations, BOLT, etc and we can add splicing to one of the months as an item?
Major releases of popular infrastructure projects callout - @Gustavojfe (see previous year in reviews)
Bitcoin Optech callout - @bitschmidty (see previous year in reviews)
Vulnerabilities callout - @Gustavojfe
January
February
March - @TumaBitcoiner
April
May
June
July
August
September
October
November
December