schmidty

#bitcoin blocking and tackling at @bitcoinoptech. cypherpunks write checks at @bitcoinbrink. Party planner @bitcoincoreorg.

Public Key

npub1zsu6h4pfsyt9atxv6prt64j645vlyv22jwkeh5y6mqlrxs47ex0svkk4em

Profile Code

nprofile1qqspgwdt6s5cz9j74nxdq34a2ed26x0jx99f8tvm6zdds03ng2lvn8cpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0ds00cxyx

Publishing to

relay.damus.io

nos.lol

Author Public Key

npub1zsu6h4pfsyt9atxv6prt64j645vlyv22jwkeh5y6mqlrxs47ex0svkk4em

Show more details

Last Notes

2026-07-31 13:28:20 GMT

Optech newsletter this morning covers the COLDCARD vulnerabilities, including urgent calls to action.
As this is somewhat "breaking" news, if you have an important correction or clarification for this segment of the newsletter, please message me directly.
As this is an evolving situation, and additional information is likely to emerge after this newsletter’s publication.
https://image.nostr.build/82b2f0c40afe3dcf4bba8da582917c0540060c907550710669752b1036a7b347.jpg
#nevent1q…fadv

2026-07-22 16:14:51 GMT

Brink is excited to announce that Martin Zumsande has (re)joined Brink to continue his work on Bitcoin Core including P2P networking, validation, testing, and review!
Martin will focus on researching address relay propagation, improving block download reliability, closing a privacy leak in wallet transaction rebroadcast, and expanding validation fuzz testing, in addition to continued code review.
https://brink.dev/blog/2026/07/22/martin-zumsande/
https://image.nostr.build/8f5f1898bf7cc231aa67c3a8059742c8c5b45dee330eb580faef37fce77b002c.jpg

2026-06-18 13:30:05 GMT

Toby Sharp joined Brink engineers to present Hornet, an executable specification for Bitcoin consensus.
In his presentation, he discussed:
* “The code is the spec”
* How Hornet differs from libbitcoinkernel
* Properties of a good specification
* The 35 semantic rules that define block validity
* A declarative C++ implementation of the rules
* A custom UTXO database designed for Bitcoin
* Approaches to block validation
* Ideas of a domain specific language (DSL) for consensus
* Differential and adversarial testing
* Q&A with the audience
https://brink.dev/blog/2026/06/18/eng-call-toby-sharp-hornet/

2026-06-06 12:32:44 GMT

Brink has always funded remote engineers, since our inception.
Our London office is there for those who want an in-person space to collaborate, but it's always been optional.
In fact, most of the engineers we've funded over the years have worked remotely. The mix shifts over time. Right now it's 5 in office and 4 remote.
Wherever you are and whatever lets you do your best work on Bitcoin is what we're here to support.

2026-05-29 14:51:31 GMT

Two research interns, Dongjia Zhang and Stratos, recently wrapped up their 3 months of work on fuzz testing for Bitcoin Core.
Under the guidance of Niklas Gögge, each conducted independent research & experimentation on Fuzzamoto.
Dongjia is a Ph.D. researcher specializing in software security and fuzzing, and is the maintainer of LibAFL, a popular fuzzing framework. His extensive background in fuzzing made him well suited to contribute to several of Fuzzamoto’s engineering and testing challenges.
Stratos is a vulnerability researcher and approached Bitcoin Core security from a systems and protocol security perspective.
Both engineers made meaningful contributions to Fuzzamoto. Their work extended protocol support, improved benchmarking infrastructure, scaled coverage analysis, and broadened target coverage for the testing platform.
Read more on their achievements during the internship:
https://brink.dev/blog/2026/05/29/fuzz-testing-research-interns/
Thank you Dongjia and Stratos for your contributions!

2026-05-26 14:25:47 GMT

We published Brink's annual financial and organizational report for the community. Feedback and questions welcome.
https://brink.dev/blog/2026/05/26/2025-annual-report/

2026-04-26 09:34:20 GMT

Sebastian is a beast. Unafraid of difficult-to-review changes and jumping into the underlying cryptography.
Thank you for 5 years of Bitcoin open source contributions, theStack!🥂
https://brink.dev/blog/2026/04/26/sebastians-five-years/

2026-04-10 12:44:47 GMT

- reply

What’s your favorite Bitcoin “progress” that Optech has “stalled”

2026-04-10 11:08:37 GMT

400 Bitcoin Optech newsletters!
Thank you to all who have contributed over these 8 years: Optech contributors, researchers whose work we have covered, engineers joining us on the podcast, and readers/listeners. 🧡
(Yes, its actually 401 newsletters, we started at Newsletter #0)
#nevent1q…dwkx

2026-04-03 14:35:53 GMT

With an increasing number of discussions around the BIP54 “Consensus Cleanup” soft fork proposal, I helped put together an information site about BIP54.
“Bitcoin has four known vulnerabilities that have gone unfixed for 15 years. BIP54, "Consensus Cleanup", proposes four narrowly-scoped changes to address these issues in Bitcoin's consensus rules that date back to the original version of Bitcoin in 2009.”
https://bip54.org/

2026-03-26 09:42:10 GMT

Today we’re publishing Brink's 2025 Engineering Impact Report covering the work of the eight Bitcoin Core engineers we funded last year and why we think this work is important.
https://brink.dev/blog/2026/03/26/engineering-impact-report-2025/
We highlight the broader categories of work that Brink engineers performed in 2025 including:
* Code Review
* Testing and Bug Fixes
* Fuzzamoto
* The First Independent Security Audit of Bitcoin Core
* Release Management
* Build System
* Libsecp256k1
* Bitcoin Kernel
* Building on Bitcoin's Existing Capabilities
We’ve included a selection of highlighted contributions for each engineer we fund:
* Marco De Leon
* Sebastian Falbesoner
* Michael Ford
* Niklas Gögge
* Fabian Jahr
* Eugene Siegel
* Hennadii Stepanov
* Stéphan Vuylsteke
The full report includes more details on the projects, PRs, and accomplishments of each Brink engineer in 2025 and why we think this work is important and impactful to Bitcoin.
https://brink.dev/assets/files/brink-engineering-report-2025.pdf
For those wanting an even deeper look, we have compiled companion reports for each engineer:
* A markdown file explaining all authored PRs
* A CSV containing each authored PR
* A CSV linking to each PR reviewed
None of this work would be possible without the generosity of Bitcoiners who share our mission of strengthening Bitcoin by ensuring that Bitcoin's codebase continues to be maintained, tested, reviewed, and improved in a “Move slow, fix things” fashion. Thank you.

2026-02-25 20:14:50 GMT

https://image.nostr.build/4166e719c4887e0f0092e2bba00ab0bb490f535ce1275a7e5d074d6d7452c3c4.jpg

2026-01-07 15:39:47 GMT

Fuzzamoto is a fuzz testing tool for Bitcoin full nodes. For the last year, Niklas Gögge (@npub1m78…7h66) has been building Fuzzamoto with the goal of:
“an external testing suite that gets as close as possible to taking production binaries as input and producing bugs as output”
Part 1 of Brink’s blog series on Fuzzamoto provides an introduction of Fuzzamoto including its motivation, a design overview, and the first bugs found.
https://brink.dev/blog/2026/01/07/fuzzamoto-introduction/
See our previous discussion with Niklas for further background on fuzz testing:
https://brink.dev/blog/2023/07/14/fuzzing/

2025-12-24 18:19:35 GMT

- reply

Running in pruned mode

2025-12-19 15:41:20 GMT

Its that time of the year again
Bitcoin Optech's 2025 Year-in-Review
https://image.nostr.build/6aea70c7045c01e3079e77d79dacc209d599a30709170b3864bffaecc78b2524.jpg
#note158q…tzm3

2025-12-17 19:54:42 GMT

- reply

Congrats Max and team!

2025-12-10 15:33:19 GMT

Murch and I cover a lot of Bitcoin technical developments on the
Bitcoin Optech podcast each week.
But there is a lot going on in Bitcoin that we don’t cover.
What are you curious about? Drop a question below and join us for a Twitter/X Space tomorrow and we will get to as many as we can.
https://x.com/i/spaces/1OwxWeWXMoVGQ

2025-11-29 15:11:24 GMT

- reply

Got it. I personally don’t have any time to allocate for that. But I’d be happy to chat with a group that gets established for this if it would help

2025-11-28 17:06:42 GMT

- reply

What did you have in mind?

2025-11-19 16:08:44 GMT

- reply

They did BSV https://github.com/trailofbits/publications?tab=readme-ov-file#bitcoin--derivatives

2025-11-19 14:14:47 GMT

As part of Brink's mission to ensure the safety and robustness of the open-source Bitcoin Core software, we recently sponsored an independent security audit of the Bitcoin Core codebase.
This represents the first public, third-party audit of Bitcoin Core.
https://brink.dev/blog/2025/11/19/bitcoin-core-security-audit/
The assessment was conducted by Quarkslab and was coordinated with the help of the Open Source Technology Improvement Fund (OSTIF). Funding was provided by Brink with the support of our donors, with technical collaboration from Brink engineer, Niklas Gögge, and Chaincode Labs engineer, Antoine Poinsot.
Why Brink funded this work
The project has a strong security track record, but it has never undergone an external security assessment. We wanted to provide an additional layer of assurance for developers, node operators, holders, and businesses who rely on Bitcoin Core every day
What the audit involved
The focus was on the most security-critical components of the software, including the peer-to-peer networking layer, mempool, chain management, and consensus logic and included:
- Manual code review
- Static and dynamic analysis
- Advanced fuzz testing
What the auditors found
The auditors at Quarkslab reported no critical, high, or medium-severity issues. They identified two low-severity findings and thirteen informational recommendations, none of which were classified as security vulnerabilities under Bitcoin Core’s criteria.
Funding independent reviews like this is just one way we help ensure Bitcoin doesn’t break and continues to serve the world as a secure, reliable monetary network.
Independent review only strengthens that confidence.
Thank you to Quarkslab, the OSTIF, Niklas, and Antoine for their work on this project.
The full report is publicly available here:
https://ostif.org/wp-content/uploads/2025/11/25-05-2133-REP-bitcoincore-security-assessment-V1.3.pdf

2025-11-07 18:52:01 GMT

Meanwhile…
The decade-long engineering efforts toward libsecp256k1, a minimal from scratch Bitcoin-specific library, result in an 800% speed up over OpenSSL while also:
- removing a problematic dependency
- avoiding side channel attacks
- being fully deterministic
Sebastian Falbesoner via
https://bitcoinops.org/en/newsletters/2025/11/07/#comparing-performance-of-ecdsa-signature-validation-in-openssl-vs-libsecp256k1

2025-11-06 13:51:28 GMT

- reply

https://image.nostr.build/4e49823a78a82e1978d184d6e4e8fef411356b892afeaf028c42c1a8ae378464.jpg

2025-11-05 17:11:59 GMT

“Where is the public roadmap for Bitcoin Core?”
This sentiment from Zach is common and Ill give my own thoughts on it
https://x.com/zachherbert/status/1976726178376696016
The subprojects that individual Bitcoin Core engineers contribute to reflect the project’s *software development priorities* which can include things like testing improvements, refactors, features, maintenance, or performance improvements.
These software engineering efforts are distinct from the Bitcoin *protocol*, whose consensus rules change only through broad community agreement and network adoption, not by decisions made exclusively within the Bitcoin Core repository.
If I were looking to derive a shorter term “public roadmap for Bitcoin Core” (again, the Bitcoin Core software, not Bitcoin protocol), there are a few places to look.
**Working Groups**
Contributors actively working on similar efforts form working groups to implement and review projects in Bitcoin Core. A list of the current working groups is on the Bitcoin Core Wiki:
https://github.com/bitcoin-core/bitcoin-devwiki/wiki/Working-Groups#current-working-groups
From here we can see interest in: Erlay, Fuzzing, Kernel, Benchmarking, Silent Payments, Cluster Mempool, Stratum v2, Multiprocess, QML GUI, and Net Split
These working groups also provide updates at the weekly Bitcoin Core developer meetings on IRC: https://bitcoincore.org/en/meetings/ This is another place to see current work.
**Tracking issues**
Many subprojects within Bitcoin Core have a place to track a todo list of code changes that roll up into that project.
Here are just a few examples (search the GitHub for “tracking issue” for more):
Multiprocess - https://github.com/bitcoin/bitcoin/issues/28722
Mining interface - https://github.com/bitcoin/bitcoin/issues/33777
MuSig2 - https://github.com/bitcoin/bitcoin/issues/31246
Cluster mempool - https://github.com/bitcoin/bitcoin/issues/30289
Erlay - https://github.com/bitcoin/bitcoin/issues/30249
Bitcoin Kernel Library - https://github.com/bitcoin/bitcoin/issues/27587
SENDTEMPLATE - https://github.com/bitcoin/bitcoin/issues/33691
**Core Dev meetups**
What developers discuss at recent in-person meetings is another data point. Here are transcripts from the
October 2025 meeting - https://btctranscripts.com/bitcoin-core-dev-tech/2025-10
February 2025 meeting - https://btctranscripts.com/bitcoin-core-dev-tech/2025-02
**Merged PRs**
As code changes are merged into the Bitcoin Core GitHub before the next release you can see precisely what will be in the upcoming release. These code changes include PRs related to projects above, but also more general changes unrelated to a particular project, like maintenance work, additional testing, one-off features, etc.
https://github.com/bitcoin/bitcoin/pulls?q=is%3Apr+is%3Amerged
Likewise Optech has a weekly notable code segment that picks interesting code merges to cover: https://bitcoinops.org/
**Release Milestones**
As Bitcoin Core progresses toward a new release, PRs can be tagged with a milestone representing that release.
For example, here are the items tagged for the previous v30 release:
https://github.com/bitcoin/bitcoin/pulls?q=is%3Apr+milestone%3A30.0
And here are considerations for the v31 release: https://github.com/bitcoin/bitcoin/pulls?q=is%3Apr+milestone%3A31.0
**TLDR, just tell me what will be in v31**
Sorry, there isn’t a definitive authoritative answer for a decentralized open source project like this. But also in the spirit of decentralization, I can provide my own guesses of what might be in there.
Kernel API - modular use of Bitcoin’s consensus and validation logic outside the full node
MuSig2 (in wallet) - fee-efficient, privacy-preserving multi-signature support
Cluster mempool - makes transaction relay and block assembly more efficient, predictable, and network reliability.
ASMap - help diversify peer connections, strengthening network resilience against eclipse attacks
Static builds - reproducible, portable binaries that enhance security, verifiability, and ease of deployment
I’ll emphasize that while these projects took a ton of work to get where they are, there will also be a majority of PRs in v31 that will not be part of a “project”. They will simply be general improvements, bug fixes, and maintenance work (see https://x.com/bitschmidty/status/1976692672023667057 for examples)

2025-10-31 17:50:51 GMT

Last week many Bitcoin Core developers met up in Frankfurt, Germany as part of their regular twice-yearly in person meetings.
Attendees volunteered to take notes on the unconference-style sessions and I have a pull request to add the notes to the BTC transcripts website:
- ASMap
- Batch Validation
- Secp256k1 and quantum
- CISA
- Cluster mempool
- CMake
- CoreCheck
- Debugging
- Fuzzamoto
- Libsha
- Multiprocess and Mining Interface
- Fingerprinting
- Net / net_processing split
- Package relay
- Private broadcast
- Security audit
- Subject matter experts and working groups
- Sockets abstraction
Additional informal discussions, code reviews, working groups, or other sessions occurred on:
- BIP 3
- Wallet priorities
- Compact Block prefills
- Silent Payments
- btck
- CI
- SwiftSync
- Benchmarking and IBD
- When do Bitcoin Core users upgrade?
- MuSig2
- Kernel
- Working in-person
- Complications with fuzz testing
- BlockTemplateManager
- QML GUI
- Shared Templates BIP
- Headers-first sync
- Batch Validation
- FIBRE
- Consensus Cleanup
- Silent payments libsecp256k1 light client
- Better communicating with the broad community
- Discussion on block 920138 and Bitcoin Core #33687
- Mempool and relay policy
- CI with CTest and CDash
This meeting was sponsored by BTrust who provided the funding for the venue, food, supplies, etc to facilitate the meeting (thank you!).
JD (from localhost research), Emily (from Brink) and myself organized.
A list of previous meetings is here: https://coredev.tech
The PR to the http://btctranscripts.com website is open here, pending approval:
https://github.com/bitcointranscripts/bitcointranscripts/pull/593

2025-10-10 17:48:00 GMT

Bitcoin Core v30: a deeper look
Link to the tweet
https://x.com/bitschmidty/status/1976692672023667057
Non Twitter link
https://twitter-thread.com/t/1976692672023667057

2025-10-07 23:04:14 GMT

- reply

Yeah that title was a bit dramatic based on the content we actually covered

2025-09-27 13:55:46 GMT

- reply

https://www.youtube.com/watch?v=6BCTVfxxBlc

2025-09-26 12:10:33 GMT

- reply

I know there is work on differential fuzzing for Bitcoin node implementations to surface incompatibilities. Same for Lightning I think. I dont know about SRI/SV2 work in this regard.

2025-09-26 11:32:36 GMT

- reply

A literal phd in fuzzing. Pretty incredible.

2025-09-26 10:59:18 GMT

Fuzz testing and Bitcoin Core...
We received a pretty overwhelming response to our recent job post for a Bitcoin Core Fuzzing Internship at Brink.
Brink received over 70 applications for the role with many qualified candidates.
After the results of a coding challenge, we decided to actually move forward with two engineers for the 3 month role.
Dongjia Zhang is a Ph.D. fuzzing researcher and maintainer of the LibAFL fuzzing library used to fuzz test Bitcoin Core.
Stratos has a background in vulnerability research and will join Dongjia in working with Niklas (@dergoegge) in the coming months to enhance the fuzz testing capabilities in Bitcoin Core.
Fuzz testing is the idea of throwing a bunch of quasi-random inputs at various functions of a codebase and seeing if anything abnormal happens. Think of it like mining for bugs.
There is work in both the Bitcoin Core codebase as well as fuzz tooling (like fuzzamoto) in order to test more and more of Bitcoin Core in this way.
Here is a bit more about fuzz testing in Bitcoin Core: https://brink.dev/blog/2023/07/14/fuzzing/
Here is a conversation we had with Matt Morehouse on fuzz testing the Lightning Network:
https://brink.dev/blog/2024/06/25/eng-call-fuzz-testing-lightning/
Marco (@macrohead7) recently completed his year long onsite fuzzing fellowship at Brink and provided some thoughts as well: https://brink.dev/blog/2025/07/31/marco-fuzzing-fellowship/
Brink is proud to support the build out of further fuzzing capabilities in the Bitcoin Core codebase as well as other ecosystem softwares. We have not had intern roles before either and are excited to see how it works out.
Welcome Dongjia and Stratos!
https://blossom.primal.net/067d426abb7c010aa4ed085543397dbc54a9be01dcaee4988c1e9e7c453ed6c1.png

2025-09-25 13:56:44 GMT

- reply

A real example and opportunity of non-development contributions.
Jan B just created a testing guide for the Bitcoin Core v30 release. It outlines the updates in the release as well instructions for testing each.
Testing is an important aspect of software development that anyone can participate in.
https://blossom.primal.net/b5ad383f40cde39499374bf7b081c96126751d45f25f3c1ffc6db2aef6811841.png
The Bitcoin Core v30.0 Release Candidate Testing Guide:
https://github.com/bitcoin-core/bitcoin-devwiki/wiki/30.0-Release-Candidate-Testing-Guide/
#nevent1q…yx0n

2025-09-25 11:42:30 GMT

- reply

Nice. Did you happen to use the testing guide?
https://github.com/bitcoin-core/bitcoin-devwiki/wiki/30.0-Release-Candidate-Testing-Guide/

2025-09-24 19:23:15 GMT

- reply

https://bitcoin.design/

2025-09-24 19:12:01 GMT

- reply

This was pointed out on Twitter as well. It’s true.

2025-09-24 14:08:22 GMT

The topic of non-developer contributions to Bitcoin and Bitcoin Core came up in a thread the other day. So I wanted to elevate this list, in case people are interested.
Ways to contribute other than code:
Education / Outreach
Optech
Conferences
Saving Satoshi
Fundraising
Bitdevs
User feedback
Reproducing issues
Priorities?
Security
Dependency auditing
CVE disclosure
Mailing list
Pen testing
Dev Tooling
CI
Signet
Fuzzing
Drahtbot
Corecheck,dev
Bitcoin dev wiki
Mentoring
Developer hubs
Review clubs
Release Process
Testing guide
Building binaries
Signing binaries
translations
Packaging for distro
Monitoring
b10c stuff etc
Standardization
BIPs
Bolts etc
Events
Coredev
Online communication channels
Mailing list
Delving
IRC
Twitter / etc
Stack exchange
http://bitcoincore.org
Backups of stuff
Dev Infrastructure
Fuzzing
Devops stuff
Dns seeds
User feedback
Outward
Talk to miners? Exchanges? Surveys
Research
BRW
Janitor work
Reproducing
Other items listed:
Coredev
conference
BIPs (review, reading)
Stack exchange
CI
Fuzzer machines
Devops
Monitoring
http://bitcoincore.org maintaining/hosting
Signet / inquisition
Utilities for interacting with Bitcoin (Core)
Educational stuff like saving satoshi
Delving
Mailing list
Backup of delving/mailing list/github comments
IRC and logs
Drahtbot / meetingbot
Bitcoinacks (?)
Fundraising
Developer hubs
Review clubs
Technical talks / podcasts / outreach
Bitdevs
Deterministic builds (running)
Dns seed
Dependency auditing/pruning
Architecture CI doesn’t account for
Reproducing issues
Moderation of github
Research Week
Twitter threads
Translations
Security
Security mailing list
CVE management / disclosure etc
Pen testing
http://Corecheck.dev
Core dev wiki
Bitcoin wiki
Summaries of communal knowledge
Optech
Release packaging for distros
Janitoring old issues/PRs
BOSS program
Summer of Bitcoin
Original: https://btctranscripts.com/bitcoin-core-dev-tech/2025-02/non-development-contributions

2025-09-20 11:46:54 GMT

- reply

I’m saying people like myself “throw out” (use) the term “maintenance” but we rarely discuss what it actually encompasses.
Gloria has been at Chaincode for about 6 months.

2025-09-20 11:37:05 GMT

- reply

This post is about minimizing dependencies

2025-09-20 11:36:18 GMT

- reply

This post isn’t about op_return
And we don’t fund Gloria

2025-09-19 15:30:08 GMT

- reply

The English parts were mine. The “cctools-port, libtapi, and ld64 to llvm binutils and lld” parts were you know who

2025-09-19 15:23:16 GMT

Many people, myself included, tout the importance of software maintenance in the context of Bitcoin Core. It is easy to throw out "maintenance!" and most people will nod their head in agreement, but I think its helpful to have some examples to understand the depth of this work and risks of not doing it.
There are many categories of maintenance work, today I am just going to zoom in on one: minimizing dependencies.
Recently someone attempted to put in a backdoor into XZ, a library used by softwares in hundreds of millions of computers around the world. Even a couple weeks ago hackers slipped malicious code into dozens of NPM packages that receive millions of downloads each week.
Bitcoin Core and other Bitcoin software are not immune to these kinds of attacks. While Bitcoin Core has a robust culture of code review and testing, Bitcoin Core uses third-party libraries as well. Code from these libraries is run, in addition to Bitcoin Core's code, when you are running your node.
Any bug, vulnerability, or performance issue in these libraries (dependencies) can cause issues for Bitcoin Core. Updates to these dependencies of Bitcoin Core are a potential risk and need to be regularly tracked and reviewed. From a security perspective, these dependencies should also be minimized and eliminated where possible.
Bitcoin Core developers have spent years minimizing the number of dependencies of the project. In some cases replacing them with minimal, in-house alternatives that achieve the same function in order to reduce attack surface.
In this latest Brink blog, we outline the risks of using dependencies as well as several examples of Bitcoin Core removing problematic or unnecessary dependencies of the project.
https://brink.dev/blog/2025/09/19/minimizing-dependencies/

2025-09-08 21:29:15 GMT

- reply

Apologies for this being late. We ran into technical troubles during the first recording attempt

2025-08-07 14:57:53 GMT

Russell O’Connor joined Brink to explain his work on formal verification of software, the process of mathematically proving that a program satisfies its specification.
- Overview of formal verification of software
- Walkthrough w/ libsecp256k1
- Coq, Rocq, Clightgen
- SafeGCD
- Q&A
https://brink.dev/blog/2025/08/07/eng-call-russell-oconnor-formal-verification/

2025-08-06 16:28:47 GMT

Jameson Lopp and Tim Ruffing on quantum
Steven Roose on the OP_TEMPLATEHASH soft fork bundle
David Gumberg on compact block prefilling
Lauren Shareshian from Block on mempool fee estimation
#note1m07…7wma

2025-07-31 14:11:40 GMT

One year ago Marco De Leon embarked on a year long Brink fellowship in our London office. Today, after a year of progress and contributions, we’re happy to bring him on as a full-time Bitcoin Core engineer!
"The idea of diving into a codebase as critical and complex as Bitcoin Core’s was intimidating, and frankly, I was a bit worried I didn’t have enough experience to contribute meaningfully. The fellowship provided the perfect bridge..."
https://brink.dev/blog/2025/07/31/marco-fuzzing-fellowship/
Marco, with guidance from his mentor Niklas Gögge, focused his fellowship on fuzz testing, a technique for catching subtle bugs and security vulnerabilities.
https://brink.dev/blog/2023/07/14/fuzzing/
His work took him from improving existing fuzz tests, to removing the longstanding mainnet checkpoints, to improving type safety in the Bitcoin Core codebase.
We are proud of Marco and Niklas for their efforts this past year. Bitcoin is more secure because of Marco's contributions and Bitcoin is stronger with another experienced engineer working on security into the future.
If you're interested in fuzzing and a career as an open source Bitcoin engineer, like Marco, we are pleased to offer, in addition to the fellowship, a new Bitcoin Core Fuzzing Internship at Brink
Join us and contribute to Bitcoin security through fuzzing!
https://bitcoinerjobs.com/job/1801236-bitcoin-core-fuzzing-internship

2025-07-10 14:49:18 GMT

The CTV and CSFS open letter segment got a little spicy with some real talk
We really dug in on Tadge's commit/reveal scheme for quantum as well
#note1qre…2kra

2025-06-17 13:38:18 GMT

- reply

Also, glozow has an extended checklist that builds on that release process:
https://github.com/glozow/bitcoin-notes/blob/master/release_checklist.md

2025-06-17 13:37:21 GMT

What is Bitcoin Core's release process for managing release candidates, minor releases, and major releases?
Bitcoin Core's Release Process doc:
https://github.com/bitcoin/bitcoin/blob/master/doc/release-process.md

2025-06-17 10:48:41 GMT

Eric Voskuil joined Bitcoin engineers to discuss architectural and performance differences between libbitcoin and Bitcoin Core:
- libbitcoin’s history/latest updates
- libbitcoin architecture
- Initial block download (IBD) performance
- IBD workflow
- SwiftSync
- Q&A
Watch the 90 minute discussion:
https://brink.dev/blog/2025/06/17/eng-call-eric-voskuil-utxo-model/

2025-06-12 21:10:05 GMT

- reply

Bad bot

2025-06-12 19:22:55 GMT

Optech's "Changing Consensus" monthly segment always makes for an interesting recap podcast
#note1leu…l6p8

2025-05-15 12:00:59 GMT

- reply

I think Optech has done a great job of surfacing and summarizing "RTFM"-type content from from the mailing list, github, delving, etc. But two points on that:
1. There are communications/informations that Optech wouldnt typically cover that could still be valuable for a wider audience. In the OP_RETURN skirmish example: information around moderation policies, who are the moderators, what is a "BAN", etc.
2. As Bitcoin grows, the Optech content becomes less accessible or even reachable for the "average" Bitcoiner and Optech summary content itself becomes "RTFM" in need of translation for a wider audience.
I agree with your thoughts, and am really just adding my $.02 on the "has been adequately disseminated" point.

2025-05-14 23:41:31 GMT

- reply

What do you suggest?

2025-05-14 16:28:23 GMT

- reply

I think, in this specific case, if the broader Bitcoin community knew about things like Bitcoin Core’s perspectives on mempool and relay policy (how many actually read/listened to Optech’s “Waiting for confirmation“ series?), documented moderation policies, where engineers expect debate to happen (not GitHub), who the moderators are, the voluminous work done to prevent miner centralization, who active Bitcoin Core developers are (not Lopp), what a “ban” means on the repo (24hrs in this case not permanent), etc, then any kind of criticism honest or not would at least be able to be more focused on the facts and specific areas of disagreement and less “noise”.

2025-05-14 12:50:44 GMT

- reply

Anyone that can help amplify signal would be valuable!

2025-05-14 12:48:51 GMT

- reply

I think communication helps focus the discussion on the actual disagreements so deeper and better debate can happen, whatever the result.

2025-05-14 12:31:39 GMT

There is a lot going on in the OP_RETURN debate, but I definitely agree with this:
"What the OP_RETURN debate has demonstrated is that Bitcoin Core and the Bitcoin technical community have not done a good job communicating their value – not to mention the rationale behind their decisions – to the average bitcoin user."
https://blockspace.media/insight/op_return-debate-the-influencers-vs-the-devs/
The Bitcoin Core developers have produced artifacts and content on these matters already, but those of us closely observing need to do a better job of disseminating that information to a broader set of Bitcoin ecosystem participants.
"The single biggest problem in communication is the illusion that it has taken place."
I need to do better.

2025-05-03 13:10:43 GMT

- reply

@nprofile…d0r5 and @nprofile…t75r will be on the Optech podcast this Tuesday, covering the OP_RETURN discussions among other topics
16:30 UTC Tuesday this week
#nevent1q…urtz

2025-04-09 12:19:37 GMT

Is there a way to stream video via RTMP to nostr?

2025-04-08 20:49:40 GMT

- reply

😬

2025-04-08 20:45:35 GMT

- reply

(if/when quantum computers become powerful enough to allow stealing bitcoins):
Pieter suggests the bitcoins that are still vulnerable are confiscated/locked/destroyed/made unspendable.
Parker suggests allowing the vulnerable bitcoins to be stolen.

2025-04-08 17:05:03 GMT

Which way, quantum Bitcoiner?
https://m.primal.net/QIlo.png

2025-04-07 13:49:03 GMT

- reply

stay humble and stack theStack
https://primal.net/e/nevent1qqsx4kc9cfys76te8peq9v6xrxdqdcj4kswaxz79qu23gdh30zafp8cr54lhd

2025-04-07 13:48:10 GMT

After years of contributing to Bitcoin on nights and weekends, Sebastian Falbesoner has left his job to focus 100% of his time on Bitcoin open source development.
"After years of contributing part-time, I'm thrilled to fully commit myself to improving the Bitcoin ecosystem. A big thanks to Brink for providing the ideal environment to make this dream a reality! 🫡 " - Sebastian
Brink is proud to enable Sebastian's move to full time, but the credit goes to our supporters.
Thank you Samara Asset Group, Lightspark, Stakwork, Ledger, Bitwise, VanEck, and Jack Dorsey whose multi-year pledges show engineers that open source development can be a sustainable career!
https://m.primal.net/QHTj.png

2025-04-04 18:43:55 GMT

- reply

Unchained did a write up about this structure which might help
https://www.unchained.com/donor-advised-funds

2025-04-04 17:11:38 GMT

Brink just received our first donation from a Bitcoin Donor-Advised Fund.
The donation was in BTC and made using a multisig onchain transaction.
This donation was made through Unchained's Bitcoin DAF and will be held in our reserves to fund Bitcoin development into the future.
🚀

2025-04-04 16:19:09 GMT

- reply

Get cozy, its a long #Bitcoin Optech newsletter this week
#nevent1q…mrg9

2025-04-02 15:51:21 GMT

Brink is excited to announce that Eugene Siegel has joined us as an open source engineer working on fuzz testing and Bitcoin Core development!
https://m.primal.net/QBty.png
With a background as a security engineer working on Lightning and already disclosing multiple Bitcoin Core security vulnerabilities, we're excited for Eugene to help ensure the long-term security, resilience & decentralization of Bitcoin.
Welcome Eugene!
https://brink.dev/blog/2025/04/01/eugene/

2025-03-28 19:39:07 GMT

Today we celebrate Hennadii Stepanov's 4 year anniversary as a Bitcoin Core engineer at Brink 🎉
From a simple fixup because of an old laptop, to one of the most prolific contributors to Bitcoin Core today...
https://brink.dev/blog/2025/03/28/hebastos-brink-epoch/
Whether that is the build system, operating system compatibility, the GUI, or language translations, hebasto’s efforts have been aimed at making Bitcoin secure, accessible, and user-friendly.
Hebasto led a project to migrate the build system to a modern, CMake-based one, enhancing efficiency and paving the way for future development. The migration to CMake took nearly 300 pull requests, a dozen people, and two years of review and testing.
https://bitcoinops.org/en/newsletters/2024/09/06/#bitcoin-core-30454
Since his initial contribution, hebasto has 1800+ (!) commits to his name.
But it isn't just his own work...in the last year alone hebasto also provided nearly 1,700 review comments.
https://github.com/bitcoin/bitcoin/graphs/contributors
Brink and the Bitcoin community are lucky to have hebasto on our team.
Thank you for your open source #Bitcoin contributions, Hennadii 🚀

2025-03-27 18:07:24 GMT

Moisturized. Unbothered. In his lane. Flourishing. https://image.nostr.build/6c6ac76b6ea06a6dbcd29bb791a4e6f47cbace2eb8c32634024599a161a71d69.jpg

2025-03-26 17:47:49 GMT

- reply

Marco does a good job explaining the context of checkpoints and their relation to things like assumevalid. Checkout from this timestamp:
https://bitcoinops.org/en/podcast/2025/03/25/#bitcoin-core-31649

2025-03-26 17:38:18 GMT

Consensus Cleanup soft fork BIP draft dropped
https://github.com/bitcoin/bips/pull/1800

2025-03-26 15:33:41 GMT

What is coming in Bitcoin Core 29.0?
Demand Pool is deploying Cluster Mempool to production soon?
What happens with no checkpoints in Bitcoin Core? #note169c…q278

2025-03-24 15:30:42 GMT

- reply

Cc: @fountain_app

2025-03-24 15:29:48 GMT

Podcast platforms used by Bitcoin Optech listeners. Pretty unusual stats, I'd think https://image.nostr.build/aa9abf84124c69ba073bd3adf351675c1f733f0926b210098878f7741bba2d56.jpg

2025-03-03 22:25:19 GMT

- reply

Onion though?

2025-03-03 17:05:07 GMT

Making the Presidio Bitcoin Pilgrimage this week.
Come say hi if you're there on Thursday or for SF Bitdevs!

2025-02-24 17:25:22 GMT

Simanta Gautam joined Brink engineers to discuss SNARKS, ZK Rollups & BitVM2 in a Bitcoin context:
- Verifiable compute w/SNARKS
- 2-way pegs, bridges, BitVM, trust minimization
- Bitcoin's state machine
- Sovereign ZK rollups
- Use cases
https://brink.dev/blog/2025/02/23/eng-call-alpen-zkrollups/

2025-02-21 12:40:09 GMT

Brink is happy to announce a $50,000 contribution to our open source Bitcoin development efforts from VanEck!
Thank you to VanEck for supporting open source 🧡
https://m.primal.net/PFWU.jpg

2025-02-20 00:09:03 GMT

- reply

It’s a good mad

2025-02-19 21:24:59 GMT

- reply

“What’s Matt mad at now” is brilliant. Look forward to more in this series

2025-02-18 22:08:40 GMT

- reply

Yeah I got a new mic but the office echo still seems to overpower it

2025-02-18 20:07:49 GMT

- reply

Just @nprofile…d0r5 and I today, but I thought it was a good one...
#nevent1q…3pv4

2025-02-18 19:29:13 GMT

- reply

The Lightning Torch, but with Satoshi's identity.

2025-02-18 18:36:33 GMT

Brink is grateful to receive a $50,000 contribution, in BTC, from Bitwise, to support our Bitcoin open source development work.
Bitwise donated $150,000 across Brink, HRF, and OpenSats for Bitcoin open source developers.
Thank you to @nprofile…hxmx , Hunter Horsley, and the Bitwise team for supporting Bitcoin open source! 🧡
https://m.primal.net/PBsX.png

2025-02-15 10:09:16 GMT

"Open Source Software and Corporate Influence"
https://www.alilleybrinker.com/blog/open-source-software-and-corporate-influence/

2025-02-15 10:08:21 GMT

- reply

What a line up with 8 guests on Bitcoin Optech this week!
Each of the segments in this podcast was really a podcast in itself. Something for everyone in the timestamps.
#nevent1q…z6ka

2025-02-15 10:05:11 GMT

- reply

Down for keeps!
Delivered within just a few days, thank you, @nprofile…04uy !
Check out the Bitcoin Block Reorg Calculator:
https://t.co/drsdVJ8Pbt
#nevent1q…60ex

2025-02-07 11:38:31 GMT

Is it the longest weekly optech newsletter? #note164c…8ty6

2025-02-07 10:16:23 GMT

"For a sixth year running, regular Bitcoin Core contributors received a survey to surface priorities and ensure that people feel that they can contribute effectively. Below is a summary of the results in a format similar to previous years’ surveys."
PRs Opened and Merged by Year
https://m.primal.net/OUYS.jpg
https://m.primal.net/OUYU.png
Regarding Goals/Priorities for 2025
https://m.primal.net/OUYY.png
Areas of frustration/disappointment in 2024 https://m.primal.net/OUYZ.png
Changes to improve the process/project
https://m.primal.net/OUYd.png
Check out the the full post:
https://adamjonas.com/bitcoin/coredev/retro/coredev-2024-retro/
Thanks @nprofile…z4ak for putting this together

2025-02-06 18:25:10 GMT

Brink renews our financial support for all of our 8 Bitcoin Core engineers through 2025!
Thank you to Michael Ford (fanquake), Gloria Zhao, Hennadii Stepanov, Sebastian Falbesoner, Niklas Gögge, Stéphan Vuylsteke, Fabian Jahr, and Marco De Leon for your amazing work on Bitcoin and we are proud to support you. 🙏
If you're curious about the work these engineers are doing, we have a detailed annual report in the works.
In the meantime check out last year's annual report
https://brink.dev/blog/2024/09/25/2023-annual-report/

2025-02-06 15:36:03 GMT

Up for grabs!
Bitcoin Optech would like to add a Block Reorg Calculator to our site.
If you would like to implement the (corrected) calculations outlined in chapter 11 of the Bitcoin white paper, we are looking for external contributions!
Inquire within:
https://github.com/bitcoinops/bitcoinops.github.io/issues/2156

2025-02-05 16:43:58 GMT

This week's Bitcoin Core PR review club PR is #31363, "Cluster mempool: introduce TxGraph", authored by Pieter Wuille and hosted by
and hosted by Gloria Zhao.
Notes and questions are available on the website, including a gentle introduction to cluster mempool and mempool architecture
Starting in 15 minutes!
https://bitcoincore.reviews/31363

2025-01-08 16:17:41 GMT

Listen to:
- Yuval Kogman’s disclosed coinjoin vulnerabilities
- Jeremy Rubin's thoughts on soft fork proposals
- the BDK 1.0.0 release with Steve Myers
- transitory soft fork discussion
https://bitcoinops.org/en/podcast/2025/01/07/

2025-01-08 16:15:16 GMT

- reply

Nailed the @npub1syl…6ksu tagging here

2025-01-03 16:16:07 GMT

Please take a moment to provide Optech feedback on how we are doing by filling out a short survey 🙏 #note1n98…hasj

2025-01-03 15:40:24 GMT

New Optech monthly segment:
"A new monthly section summarizing proposals and discussion about changing Bitcoin’s consensus rules." #note1j9x…krkt

2024-12-27 13:22:01 GMT

- reply

Incredible! Let me know how it goes for you

2024-12-26 22:13:49 GMT

- reply

You could try rust?
https://btcdemy.thinkific.com/courses/intro-to-rust

2024-12-26 20:52:49 GMT

- reply

There are some materials for the seminars that are on the same site which are very useful as well. But you’ll miss the teammates, coaches, and accountability pieces.