Conference Kickoff

Be Robin: A path into Bitcoin Open Source

Everyone wants to be Batman, a superhero with their own marquee project, attracting constant review, funding, and recognition. For newcomers to Bitcoin open source, chasing that ambition straight out of the gate is often a trap. There's a much better opening move: being Robin. Find someone whose project already has momentum, and support them. Why this works and how to pull it off is what this talk is about, including a lot of practical advice.

Reviewing PRS

Why reviewing is a bottleneck and how to become better at it

Hackable by Default: Software that's Really Open Source

Open source software gives you the legal right to modify software - but how often do users actually do this? Can we find something better than the status quo? Could hacking the program happen within the program? This talk aims to answer these questions. Hackability should be a core design philosophy of an open source product, not an afterthought. Modern users have come to expect apps that behave like appliances, and this leaves them locked out of getting the maximum out of their software. With the help of modern tools and AI flattening the learning curve, we have an opportunity to rethink what user-modifiable software looks like. The talk explores Nostr as a distribution layer for software and includes a demo of a Nostr micro-app framework around this philosophy as a proof-of-concept.

Don't Trust Your Node: Policy-Based Signing for Secure Lightning Infrastructure

Lightning nodes are hot wallets by design, signing keys live alongside routing logic, creating a real attack surface for anyone running serious Lightning infrastructure. As a BTrust grantee contributing to Validating Lightning Signer (VLS), this talk breaks down the problem of blind signing, how VLS separates the signer from the node, and how policy rules are enforced before any signature is produced, making it especially relevant for LSPs and Lightning operators scaling across Africa. The presentation will provide a clear picture of the problem VLS solves, how it works in practice, and where the open challenges still are.

Anti-Fee-Sniping and Privacy for Taproot Transactions

BIP326 closes Bitcoin's on-chain privacy gap by normalizing nSequence across Taproot transactions — making Lightning channel closures indistinguishable from regular wallet payments. This talk covers the full specification: MAST, HTLCs vs PTLCs, fee sniping, and absolute vs relative locktimes, culminating in a production Rust implementation using the bdk_tx crate.

Built Here, Used Everywhere: Closing the African Open Source Founder Gap

African developers are now active contributors to open source — but there is a gap between showing up in someone else's repository and starting your own. The continent generates unique challenges that mainstream open source rarely addresses: mobile money infrastructure, offline-first connectivity, governance systems and financial realities that don't map to Western defaults. These aren't bugs to be patched — they're the brief for something entirely new. In this panel, 3 African developers who have made the leap from contributor to founder share what the journey actually looks like: what made them start, the challenges they encountered, and what it takes to build software rooted in African realities that earns a place in the global stack. Proposed Panelists OkJodom - Co-founder Bitsacco & Minmo Wisdom Nji - Co-founder SMSWithoutBorders Tim Akinbo - OG African Bitcoin Developer

Nostr, an open source database?

I'll talk about how nostr is a decentralised open source database - emphasing how (and why) to best make use of it in projects.

LNURL in the Real World: Improving Payment Communication for Africa

Lnurl plays a key role in Lightning payments by enabling communication between wallets, merchants, and service providers beyond what a standard invoice can provide. This workshop explores how description hashing affects wallet interoperability and payment reliability, and examines a proposed LNURL extension for communicating fiat currencies and exchange rates. Through practical examples and discussion, participants will learn how these protocol improvements can create more transparent and user-friendly payment experiences, particularly in African markets where users think in local currencies while paying in sats.

Can AI Help Bitcoin? Responsible Practices for Open-Source Development

AI tools are rapidly reshaping how developers write, review, and ship code but how should Bitcoin open-source contributors approach them? This talk explores the opportunities and risks of integrating AI into Bitcoin development workflows. We'll examine where AI genuinely adds value, where it introduces risk, and the responsible practices every contributor should adopt to maintain the security, rigour, and trust that Bitcoin demands. Whether you are a first-time contributor or a seasoned maintainer, you will leave with a practical framework for using AI as a tool that supports rather than compromises the integrity of open-source Bitcoin development.

Don't Trust, Attest: Enclaves as a Trust-Minimization Tool for Bitcoin Apps

The rise of trust-minimized Bitcoin solutions is enhancing both the capabilities and user experience of Bitcoin, but these systems still often rely on cloud-hosted services. This creates a key requirement: ensuring those services are actually running the intended code, otherwise the model collapses back into blind trust in the operator. Secure enclaves and remote attestation directly close this gap by enabling verifiable execution, protecting sensitive key material, and shifting trust from "trust the operator" to "verify the code." I'll share my experience building an enclave framework with reproducible Nix builds, explain the architecture, and show how an MPC wallet cosigner leverages it in practice. I'll also explore how the Ark Labs Introspector intends to build on the same framework, alongside an honest discussion of the trust assumptions secure enclaves still cannot remove.

Workshop: Building Nostr apps with open source AI tools

In this workshop I will show participants how to use open source AI tools to build open source, decentralized, apps on Nostr. We cover how to use open source at every level of the stack, from the models to the frameworks and tools like Shakespeare and Opencode, to finally how to publish and share your open source app on Nostr with tools like Nsite and Ngit. The workshop will include a presentation portion, setup walkthrough/guide, collaborative building, and time for questions. The workshop will be at an intermediate level, with the expectation that participants are already familiar with the basics of working in the terminal, using git, etc. We will provide AI tokens for the workshop.

The Cognitive Cost of AI-Assisted Open Source

AI has dramatically lowered the barrier to contributing to open source. Pull requests can now be generated in seconds, code explanations are instant, and contribution speed has accelerated across the ecosystem. But as code generation becomes easier, a deeper question emerges: are contributors still developing the understanding required to maintain critical systems like Bitcoin? This talk explores the growing cognitive cost of AI-assisted development, from shallow review culture and low-context contributions to the erosion of systems thinking and technical intuition. Rather than arguing against AI, the session examines how contributors can use these tools without outsourcing the reasoning, verification, and responsibility that meaningful open-source work requires. In Bitcoin, where review quality, caution, and long-term thinking matter more than velocity, contribution integrity becomes essential. This session is a reflection on what it means to remain a thoughtful contributor in an era where generating code is no longer the hard part.

Onion Messages: How Lightning Learned to Talk Beyond Payments

Lightning Network is best known for routing payments, but a quieter revolution has been happening in the open: onion messages. Built on the same onion routing primitives that move sats, onion messages give Lightning a general-purpose, privacy-preserving communication layer — no payment required. This talk walks through the journey from problem to protocol. We'll start with how onion routing works for payments, then explore why the network needed a messaging layer beyond HTLCs — and how the open spec process produced one. We'll cover the core mechanism (how onion messages reuse Sphinx routing for arbitrary data), what they unlock (BOLT12 offers, blinded paths, async payments), and the privacy tradeoffs involved.

Open Source is Dead

AI is changing the tech landscape fast, causing previously devout open source advocates to already start talking about jumping ship. In this talk, I will lay out the threats to open source by AI, and advocate for why it still matters anyways.

Modern Testing and Fuzzing in Bitcoin Core

Bitcoin is a multi-billion dollar open-source protocol that remains exposed to good and bad actors in equal measure. The purpose of this talk is to try and shed light into how various teams try to revamp its resilience against edge cases and malicious inputs. Bitcoin Core testing suite has continued to evolve to multilayered efforts, from standard unit and functional tests to fuzzing and mutation testing. This talk also aims to dive into technicalities of Core Fuzzing, using tools like LibFuzzer to discover vulnerabilities that traditional testing cannot reach.

Implementing Replace-By-Fee (BIP 125) in LDK Node

A walk-through of the implementation of Replace-By-Fee (BIP 125) in LDK Node, a Lightning node library built on top of BDK. Beyond just enabling fee bumping on the onchain wallet, look at maintaining a consistent payment state when a transaction is replaced in the payment store, since a bump produces a new txid, the old one becomes conflicting. The required design for a new store to track and handle these conflicts correctly. The talk covers the design decisions made.

Hackathon Kickoff

Hacking Time

Lightning as Bitcoin’s Translation Layer

This talk explores how Lightning transforms Bitcoin from a settlement network into a usable payments system. Drawing from the experience of building Tando, we will look at what it actually means to build on Lightning Network and bring Bitcoin into everyday commerce.

Proto Fleet

All of Block's business units share one purpose: build simple tools that empower people to participate in the economy. Proto builds tools that make bitcoin mining accessible and sustainable for anyone, regardless of size or location. We see bitcoin as an extraordinary trend toward an open standard for global money transmission — and our focus is on closing the gaps in accessibility and tooling that exist around bitcoin today. Mining is the foundation that keeps that standard open, yet the software to run it has stayed fragmented, proprietary, and locked behind per-rig fees. Proto Fleet is our answer: a free, open-source, self-hosted platform for managing bitcoin mining operations — built to make mining more accessible, resilient, and distributed. In this talk we'll introduce Block and Proto, show why an open source fleet management is the missing piece for operators (real-time fleet health), executives (profitability), and the network as a whole, and walk through how Proto Fleet solves it — dashboards, miner management, bulk actions, sites and racks, curtailment, and repair tracking. We'll then go under the hood on the architecture (on-prem vs. cloud, design-to-code, backend) and close with an honest look at how AI has reshaped the way we design, build, review, and ship software in the open. Come see what it's like to build bitcoin infrastructure in the open — and how you can build alongside us on GitHub (https://github.com/block/proto-fleet).

AI-Powered Product Design for Bitcoin Experiences

Bitcoin is growing fast, but the products built around it haven't always kept up with the people using them. Gaps in user research, unclear journeys and rushed interfaces quietly push users away before they ever see the value. In this workshop, you'll see what a modern AI-powered design process looks like from start to finish. We'll cover prompt engineering for UX research, so you know exactly how to get useful, contextual insights out of AI tools rather than generic outputs. Using tools like Notion, Figma, claude and Cursor, we'll run a design sprint accelerated by AI agents. Whether you're a designer, developer, or product builder, you'll leave with a practical workflow you can apply to your next Bitcoin product immediately.

Anatomy of a Bark VTXO

We dissect the sqlite.db to see how Bark VTXOs really appear on disk.

"Beyond the Barrier: Female African Developers Reimagining Bitcoin Innovation"

Bitcoin doesn’t scale through marketing. It scales through builders. For too long, Bitcoin development has remained concentrated within a small demographic while massive technical talent across emerging markets remained untapped. Dada Devs was built to change that. Through focused pathways in Programming Bitcoin, Lightning, UX, and open-source collaboration, we have trained female African developers to move from first principles to shipping real Bitcoin products and contributing to the ecosystem. This keynote explores how emerging technologies, Bitcoin education, and frontier-market builders are reshaping Bitcoin development from the ground up, not through narratives, but through proof of work.

Cross-Platform Bitcoin Wallets with Flutter & BDK-Dart

Flutter developers can now build bitcoin apps on iOS and Android using bdk-dart. Dart bindings for the Bitcoin Dev Kit. In this lightning talk, I'll show you how to integrate bdk-dart into your Flutter project and walk through the developer reference app, bdk-dart Wallet, which showcases core wallet features including wallet creation (P2WPKH/P2TR), Electrum/Esplora sync, send & receive, and transaction history. Leave with a working mental model of BDK's API surface and a scannable link to run the app yourself.

Bitcoin Transfer

It will presenting first MVP website of a crypto app that will help most South Sudanese change bitcoin to local currency using lightning

Mining Illustrated feat. Mujina Open-Source Firmware

A guided walk through the full data path of Bitcoin mining, from the network down to the silicon and back. We'll trace exactly what moves between the Bitcoin network, a pool, and a miner, then dig into what each side does with it. We'll cover: What a pool receives from the Bitcoin network What a miner receives from a pool What a miner does on the inside What a miner returns to the pool What the pool sends back to the Bitcoin network To make it real, we'll run a complete Bitcoin network in the room and mine against it using Mujina Open-Source Mining Firmware on your laptop, with provided Bitaxe Gammas serving as hashboards. You'll see every layer of the stack running on hardware in front of you.

The Future of Bitcoin Mining is Open

Open source is becoming unstoppable in the age of AI: when intelligence is shared, innovation compounds. The same force that is transforming software will soon reshape Bitcoin mining from the inside out. Closed systems will give way to open infrastructure, faster experimentation, and a new generation of builders. This shift will disrupt operations, energy optimization, automation, and hardware integration across the entire industry. And that disruption is exactly what Bitcoin mining needs: more innovation, more decentralization, stronger security, and a more resilient network.

Why African Designers +Bitcoin = The Future

Bitcoin adoption in Africa isn't bottlenecked by technology. It's bottlenecked by design. 400 million unbanked adults across Sub-Saharan Africa stand to benefit from Bitcoin, but the tools they encounter are built by engineers, for engineers. Confusing onboarding flows, unexplained self-custody, and jargon-heavy interfaces are silently killing adoption before it starts. This talk makes the case that designers, specifically African designers, are the missing layer in Bitcoin's growth story on the continent. Drawing from BitDesigners Africa's experience running community meetups and workshops across Nigerian cities, I'll break down how UX decisions make or break real-world Bitcoin adoption, what happens when you put designers and developers in the same room solving onboarding problems, and the concrete path from curious designer to open-source Bitcoin contributor. This isn't a theoretical pitch. It's a field report from the people building the bridge between Bitcoin and the next hundred million users, and a call to take design as seriously as we take code.

Defining an Open (Human) Agent Network for Bitcoin On/Off-Ramps

## Summary This 45-minute hands-on technical workshop introduces contributors to the Pontmore protocol, showcases the minimum interoperable protocol core, and helps participants produce concrete contribution candidates for the protocol repository. Pontmore is a Nostr-native protocol family for Agent identity, capability discovery, escrow declaration, and swap lifecycle coordination. The workshop focuses on protocol specification work: reading the active PIPs, mapping behavior to the correct protocol surface, identifying ambiguities, and drafting small issues or pull-request-ready text. ## Audience This workshop is intended for: - Nostr builders - Bitcoin and Lightning developers - protocol reviewers - escrow or swap operators - technical contributors interested in Pontmore interoperability Participants should be comfortable reading technical specifications and structured event examples. No Pontmore implementation experience is required. ## Workshop Goals By the end of the workshop, participants should be able to: - explain Pontmore's core protocol model - identify the role of each required PIP - distinguish public protocol state from private or operator-layer data - map swap behavior to the correct PIP - identify valid protocol contribution opportunities - draft a small issue or pull-request-ready clarification ## Required Materials Participants should have access to the Pontmore protocol repository: - `README.md` - `PIP-00-agent-definition.md` - `PIP-01-escrow-descriptor.md` - `PIP-02-swap-state-machine.md` - `PIP-03-dispute-policy.md` Optional: - a GitHub account - a local clone of `https://github.com/pontmore/protocol` - a text editor for drafting issue or PR text ## Core Message Pontmore does not make an application account the identity root. The Nostr identity is the Agent. Applications, dashboards, indexes, operator tools, and databases are implementation overlays that wrap around the protocol rather than redefine it. The public protocol surface is defined by: - Agent definitions - escrow descriptors - swap request and transition events - public evidence references - dispute events - replaceable snapshots Private settlement details, internal operator notes, payment instructions, raw screenshots, KYC data, and application databases are outside the canonical public protocol state unless the PIPs explicitly define a public reference or disclosure boundary. ## Agenda ### 0:00-0:05 - Framing Introduce Pontmore as a Nostr-native protocol family for: - Agent identity and capability discovery - escrow declaration - swap lifecycle coordination - dispute and evidence boundaries Explain that the repository contains the required PIPs for the minimum interoperable core: - `PIP-00`: public Agent capability and discovery record - `PIP-01`: public escrow declaration referenced by Agents and swaps - `PIP-02`: swap request, transition, evidence, dispute, note, and snapshot event lifecycle - `PIP-03`: dispute classes, timeout classes, evidence boundary, and resolution modes ### 0:05-0:12 - Protocol Map Walk through the four required PIPs in dependency order. `PIP-00` answers: - Who is the Agent? - How is the Agent discovered? - What capabilities does the Agent publicly declare? - Which escrow descriptor is the default? `PIP-01` answers: - What escrow mechanism is being used? - Which settlement or invoice networks are supported? - What funding, release, refund, and dispute assumptions apply? - How is the escrow instance referenced? `PIP-02` answers: - What is the immutable swap request? - Which append-only transition events advance the swap? - What evidence is public? - What remains in the companion private message lane? - What role do replaceable snapshots play? `PIP-03` answers: - Which dispute and timeout classes exist? - Which evidence categories can support a dispute? - Which resolution modes can an operator apply? - What belongs in public protocol state versus private operator handling? ### 0:12-0:22 - Showcase: One Swap Through the PIPs Use a simple scenario: A customer wants to swap fiat payment for Bitcoin payout through an Agent using Lightning-based escrow. Ask participants to map each fact to the correct protocol area: ```text Agent supports MZN and Lightning Escrow uses custodial_escrow Raw bank receipt screenshot Public hash of payment proof Swap moved from requested to funded Refund allowed after timeout Operator dashboard queue Agent has profile d tag agent:ke ``` Expected mapping: ```text Agent supports MZN and Lightning -> PIP-00 Escrow uses custodial_escrow -> PIP-01 Raw bank receipt screenshot -> private/operator layer Public hash of payment proof -> PIP-02/PIP-03 evidence reference Swap moved from requested to funded -> PIP-02 transition Refund allowed after timeout -> PIP-01 release/refund rule and PIP-03 timeout class Operator dashboard queue -> implementation overlay Agent has profile d tag agent:ke -> PIP-00 ``` The point of this exercise is to make participants practice the most important contribution skill: deciding where a rule belongs before trying to write it. ### 0:22-0:35 - Hands-On Contribution Exercise Split participants into pairs or small groups. Assign each group one contribution track. #### Track A: Agent Discovery Read `PIP-00-agent-definition.md`. Look for one place where a client implementer might need more precision around: - multiple Agent definitions - `d` tag conventions - default profile behavior - recommended tags Output: - one issue title - the current ambiguity - proposed clarification text Example issue title: ```text PIP-00: Clarify default Agent profile selection when multiple d tags exist ``` #### Track B: Escrow Descriptor Compatibility Read `PIP-01-escrow-descriptor.md`. Review the `networks`, repeated `network` tags, and `custodial_escrow` implementation rules. Prompt: ```text What should a client do if an implementation entry references a network not listed in content.networks? ``` Output: - a testable rule summary - an example invalid descriptor case - optional proposed wording Example issue title: ```text PIP-01: Add invalid custodial implementation example for unsupported networks ``` #### Track C: Swap State and Private Payloads Read `PIP-02-swap-state-machine.md`. Identify which data belongs in public events versus Gift Wrap private messages. Prompt: ```text Draft one example of a public evidence event that references private evidence without exposing it. ``` Output: - a short JSON-style evidence example - a note explaining which private data is intentionally withheld Example issue title: ```text PIP-02: Add evidence reference example for private payment proof ``` #### Track D: Dispute Policy Boundary Read `PIP-03-dispute-policy.md`. Pick one dispute class and define what should be public versus private. Prompt: ```text For payment amount mismatch, what public facts are enough to justify resolution without publishing raw screenshots? ``` Output: - public facts - private evidence - proposed disclosure boundary Example issue title: ```text PIP-03: Clarify public resolution fields for payment amount mismatch ``` ### 0:35-0:42 - Contribution Review Each group presents: - the PIP they touched - the ambiguity or missing example they found - whether the contribution should be an issue, PR, or open question - why it belongs in protocol text rather than an implementation The facilitator should check: - Is this protocol-level? - Is there one primary PIP that should own the rule? - Does it avoid product UX, database, deployment, or SDK assumptions? - Does it preserve the distinction between canonical public protocol state and operator-layer overlays? - Would an independent implementer benefit from the clarification? ### 0:42-0:45 - Close and Contribution Path Close with concrete next steps: 1. Open a GitHub issue with the PIP number in the title. 2. Keep proposals atomic. 3. Include the current ambiguity, proposed wording, and interoperability impact. 4. Avoid implementation-specific details unless they reveal a protocol gap. 5. Prefer documenting draft conventions or open questions over implying false finality. Good contribution titles: ```text PIP-00: Clarify default Agent profile selection when multiple d tags exist PIP-01: Add invalid custodial implementation example for unsupported networks PIP-02: Add evidence reference example for private payment proof PIP-03: Clarify public resolution fields for payment amount mismatch ``` ## Facilitator Notes Keep the workshop focused on specification work. If participants drift into application design, redirect them with this question: ```text Is this canonical public protocol state, or is it an implementation overlay? ``` Valid protocol contributions usually clarify: - event kinds - required fields - public tags - content schema - lifecycle rules - evidence boundaries - dispute and timeout semantics - cross-PIP consistency Contributions should generally avoid: - application UX plans - database schemas - deployment notes - SDK instructions - operator dashboard workflows - product-specific assumptions - private business process details ## Success Criteria The workshop is successful if each participant or group leaves with at least one of: - a concrete GitHub issue draft - a small PR-ready paragraph - a missing example to propose - a documented open question tied to a specific PIP The best contribution candidates are small, specific, and useful to independent implementers.

Plugins, Not Forks: Extending BTCPay Server Without Compromising the Core

BTCPay Server's plugin system turns a self-hosted payment processor into a platform. This workshop walks through the plugin architecture — how it's structured, how plugins hook into the core, and what it takes to build one from scratch. If you run BTCPay or build on it, this is the layer you should understand.

Hackathon Expo

Working on Bitcoin

We invite contributors to bitcoin-core to tell us about their journey working in public.

Stratumv2

Description to come

Building Tapnob: Connecting Lightning to Real-World Payments in Africa

Building Tapnob: Connecting Lightning to Real-World Payments in Africa explores the engineering realities of turning Bitcoin and Lightning into usable payment infrastructure across African markets. While Lightning enables instant global value transfer, real-world payments require much more than moving sats. This talk dives into the systems built around Lightning to support local bank payouts, liquidity orchestration, reconciliation, and fault-tolerant payment processing.

Gating APIs with Lightning: A Hands-On L402 Workshop Using Aperture

L402 is an open standard that turns Lightning into an authentication and payment layer for APIs. Instead of API keys and subscription plans, your service issues a Lightning invoice — the client pays, gets a macaroon, and gains access. It's permissionless, programmable, and built on open-source tooling. In this hands-on workshop, we'll build an L402-gated API from scratch using Aperture, the open-source reverse proxy from the LND ecosystem. Participants will work in a pre-configured regtest environment (Docker-based, no mainnet sats needed) and walk through the full cycle: setting up a backend service, placing it behind Aperture, configuring macaroon-based access, and testing the 402 Payment Required flow from the client side.

Towards Better Privacy Reasoning

Bitcoin is often described as private but in reality it is pseudonymous not anonymous. Leaking even small pieces of information can expose a user’s identity or enable long term tracking. Yet privacy is rarely broken by a single catastrophic failure. More often it degrades gradually as information from different sources is combined over time. This talk explores how modern chain analysis works from clustering heuristics and wallet fingerprinting to intersection attacks and metadata leakage and examines how privacy assumptions can break down in subtle and unexpected ways. Even strong guarantees made within one model may fail to generalize once additional information becomes available to an adversary. Rather than treating privacy as a binary property the talk frames it as a spectrum shaped by assumptions, adversaries, and observable leaks that compound over time. Drawing parallels to side channel attacks, it argues that small leaks can accumulate into significant privacy failures even when individual components appear secure in isolation. The goal is not to argue that privacy is impossible, nor to present a single “magic bullet” solution. Instead the talk encourages more rigorous and holistic thinking about how privacy systems behave in the real world and why small improvements across wallets, protocols, infrastructure and user behavior can meaningfully strengthen privacy over time.

Cashu ecash protocol

A deep walk into the adoption and use of ecash wallets and development of the cashu protocal

Lightning + Mobile Money: Bridging Two Financial Worlds

A deep dive into connecting Bitcoin Lightning payments with African mobile money systems. We’ll discuss settlement design, exchange flows, compliance considerations, liquidity management, and operational challenges when building services that convert between Bitcoin and local currencies seamlessly.

Bitcoin, Demystified: A Live Walkthrough from M-Pesa to Self-Custody

Bitcoin gets talked about more than it gets shown. In this hands-on session, we'll walk through Bitcoin the way it actually works — live. We'll inspect a real block on mempool.space, send an onchain transaction, zap sats across the room over Lightning, and stack our first sats from M-Pesa straight into self-custody with Bitika. No prior technical knowledge is required. You'll leave with a wallet, your first sats, and a working mental model of how Bitcoin really moves.

Sending and Receiving silent payment transactions with bdk-sp

In this workshop participants will be able to send and receive silent payment transactions using the experimental repository bdk-sp. Participants will also be able to get an overview about what are silent payment and how they improve privacy.

The 256 Foundation's Open-Source Mining Stack

In almost every layer of Bitcoin, open source is the default. Mining is the exception: one company dominates ASIC hardware and firmware, four pools direct ~75% of global hashrate, and miners hand multimillion-dollar operations to black-box hardware and software. The 256 Foundation is working to fix that. We'll walk the four pillars of the open-source mining stack end to end: Ember One (hash board), Libre Board (control board), Mujina (firmware), and Hydrapool (pool software). See the hardware in person: a sous vide cooker built from all four. We'll cover how to plug in: solo-mine sovereignly, test new hardware, file issues, contribute code, or show up on the forum. Mining is the last closed layer of Bitcoin. The 256 Foundation is opening it.

Building contributor-friendly repositories with Devenv

Providing a development environment in a code repository lowers the barrier to entry and makes it much more welcoming to contributors. The more contributors a project gets, the more biodiversity of thought and use cases it gains. This workshop introduces Devenv (https://devenv.sh), a Nix-based tool that helps set up reproducible development environments for code repositories. It lets you configure linters, compilers, sidecar services, test runners, and much more. I will also cover the core concepts behind Nix.

Lightning Education as Infrastructure: Scaling Technical Capacity Across Multiple Countries

Lightning adoption depends not only on infrastructure and liquidity, but also on the availability of skilled developers capable of building and maintaining the ecosystem. This talk explores how treating developer education as infrastructure can rapidly scale Lightning capacity across multiple countries, sharing practical lessons from organizing hands-on Lightning bootcamps and building sustainable developer pipelines that continue producing active builders long after training ends.

Bearer Tokens for Bitcoin: A Look at Cashu

Cashu is a Chaumian ecash protocol built on Bitcoin and Lightning, it's a precise cryptographic protocol with a clean spec and growing reference implementations. This talk goes inside the machinery: the Blind Diffie-Hellman Key Exchange that makes mint-side unlinkability possible, how the NUT specifications translate that into a concrete mint/wallet API and why a string of characters can be money.

Don’t Trust, Verify. Reproducible Builds in Bitcoin

Bitcoin is built on the principle of "don’t trust, verify" , yet in practice, most users and even many developers cannot independently verify that released binaries correspond to the published source code. This talk will introduce reproducible builds from a developer’s perspective - what they are - why they matter for Bitcoin software, - how to implement them in their projects ( environment isolation, dependency pinning, deterministic toolchains, and independent verification workflows and a checklist developers can apply to make their own software reproducible.)

Hackathon Finals

Open Sourcing Developer Community

Building open source requires community. We're joined by a few local BitDev community leaders to talk about building the open developer ecosystem in their cities.

Hackathon Awards