Newsletters: add 385, the 2025 year-in-review special #2574
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Contributor
|
pushed I might still need to edit them, but putting out a draft early, will look at "Erlay update" next |
Collaborator
|
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.
|
LarryRuane
reviewed
Dec 10, 2025
|
|
||
| - **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 |
Collaborator
There was a problem hiding this comment.
Suggested change
| 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 |
Comment on lines
+94
to
+95
| [filtering based on transaction knowledge][erlay knowledge] not mattering as | ||
| much as expected. He also experimented with selecting [how many peers should |
Collaborator
There was a problem hiding this comment.
Suggested change
| [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 |
Collaborator
There was a problem hiding this comment.
Suggested change
| 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. |
Collaborator
There was a problem hiding this comment.
Suggested change
| 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. |
Collaborator
There was a problem hiding this comment.
Suggested change
| 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 |
Collaborator
There was a problem hiding this comment.
Suggested change
| Kirck-Cohen in collaboration with Clara Shikhelman and elnosh had updated the | |
| Kirck-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 |
Collaborator
There was a problem hiding this comment.
Suggested change
| outgoing channels, and resources being limited on incoming channels. With | |
| outgoing channels, and tracking incoming channel resource limitations. With |
Comment on lines
+243
to
+244
| improvements over the decade and if so did libsecp256k1 keep up. What | ||
| Falbesoner found was that over the years libsecp256k1 had improved |
Collaborator
There was a problem hiding this comment.
Suggested change
| 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 |
Collaborator
There was a problem hiding this comment.
Suggested change
| significantly whereas OpenSSL had remained the same. He also concluded that | |
| significantly, whereas OpenSSL had remained the same. He also concluded that |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Quantum callout
Soft fork proposals callout - @reardencode
January
February
March - @TumaBitcoiner
April
May
June
July
August
September
October
November