The Hackathon

For those unfamiliar, we run a hackathon at nearly every Bitcoin++ conference. This time around (Exploits Edition) we split things into two tracks: our classic hackathon track where teams build projects (with bonus points for anything security or exploit themed), and a brand new bug bounty track where the objective was simple: find real bugs in real, open-source Bitcoin software.

We were nervous about this one. We had no idea if people would actually find meaningful bugs in 22 hours. By the end of the hackathon, 10 real, meaningful bugs were found in open-source Bitcoin projects. Ten. In a single day.

22 hours, ~60 participants, 21 projects submitted, 10 meaningful bugs found.

Projects

There were many impressive projects, but here’s few standouts:

MineExploit won first overall. Think Metasploit, but purpose-built for Bitcoin mining tooling. The team didn’t just demo it either. They ran it against several codebases and turned up three bugs in real StratumV2 repos.

LocalProbe won second place, a project that demonstrated how Firefox can be used to fingerprint open ports on a machine. 0xB10C showed that simply navigating to a malicious website could allow an attacker to spam a Bitcoin node by firing HTTP requests at its open ports. On stage, he had the audience DDoS his node, evicting other peers. Nasty stuff, and exactly the kind of research this hackathon was designed to surface.

Another team used fuzzing techniques to go after Alpen Labs’ codebase and found a critical vulnerability that a professional security auditor had missed just three weeks earlier. Read that again. A team at a 22-hour hackathon, fuzzing on the fly, caught something that a paid audit didn’t. That alone should make you think about how much untapped value there is in getting more eyes on Bitcoin infrastructure.

Check out all the projects here.

Conclusion

Here’s the thing we keep coming back to: this hackathon produced tangible, lasting improvements to Bitcoin’s security infrastructure in under 24 hours. Critical bugs found, new offensive security tooling built, and novel attack vectors documented. If you’re an organization that funds Bitcoin development through grants, we’d encourage you to look at what a single hackathon can produce and compare that to what a typical grant cycle yields. The return on investment here is hard to ignore.

We’re already thinking about how to level up the bug bounty format for next time. Giving participants more time to study target projects ahead of the event, working more closely with specific projects to provide better scoping, and generally adding more structure to make the bounty track even more productive. If the first attempt is any indication, this format has serious legs.

One of the greatest challenges of running a Lightning Network node is liquidity management. For those that are not familiar with this concept, liquidity means having sats available to be pushed to, or pulled from, the other peer in a lightning channel. You need enough sats ready to be pushed in order to complete a payment. This is “liquidity”, and making sure you have enough sats available when needed is the “management” part of it.

A node operator has to maintain his public channels to allow for payment routing to happen constantly. Rebalancing needs to happen as payments are completed and sats are moved. Rebalancing means adjusting the channel balances so that a lightning node has enough satoshis in the right configuration to forward payments. Most lightning node operators use specific services or have to manually monitor their channel balances to keep them liquid.

What if there was a project that could allow a user to put the Lightning node on autopilot?

Enters CLBOSS

CLBOSS is an automated liquidity manager for Core-lightning routing nodes. The program uses a set of heuristics that continuously monitor the node’s channel balances and the state of its peers to adapt to changes in available liquidity as payment are routed through its channels. CLBOSS’s goal is to make it such that running a Lightning Network node is as simple as installing some software, funding a wallet, and provide internet and power to some hardware. That’s it.

CLBOSS is built from many components, called modules. Each module handles a specific responsibility and communicates over a shared event bus. A bus is a a communication channel that allows different parts of a program to exchange information and data. Components publish messages to the bus and subscribe to the messages they need for their internal processing, allowing them to remain loosely coupled while coordinating their behavior.

As of 2025, the project, originally designed by Lightning developer ZmnSCPxj, is being maintained by Ken Sedgwick and a small group of Lightning enthusiasts.

While CLBOSS does not allow for complete automatic management (yet), it can already perform some impressive operations on a CLN node:

• It can open channels to other nodes when on-chain fees are low and funds are available. A specific set of modules in CLBOSS can propose a candidate node to open a channel to. CLBOSS then assess the health of the proposed node based on its uptime.

• It can buy inbound liquidity through boltz.exchange, swapping off-chain funds with on-chain bitcoins swaps. This feature is triggered when CLBOSS detects that the total amount of inbound liquidity is lower than a desired threshold.

• It can rebalance open channels by leveraging circular self-payments, using either just-in-time rebalancing, which rebalances liquidity on-demand right before forwarding, or earnings rebalancing, which proactively looks for rebalancing opportunities based on earnings. This means it’ll initiate a payment to itself along a route, pushing the sats in the nodes inbound and outbound channels into a new configuration.

• It can adjust forwarding fees to support channel balance and to be competitive on the market. It monitors both the current fee market and its internal state through a set of heuristics, which will be discussed below.

Let’s take a deeper look at how these fee adjustments get made.

Adjusting Fees

The last point above is, in my personal opinion, the most interesting. CLBOSS performs a series of actions to maintain the fees to an optimal price, based on both market signals and internal states.

Basically, CLBOSS works as an automated market actor, adapting the price of its liquidity to changes in competitors fees, relative size of capacity with respect to its peers, channel balance, and past earnings.

There are four aspects of the pricing algorithm: baseline fees, a size multiplier, a balance multiplier, and something ZmnSCPxj called the “Price Theory” multiplier. Let’s break these down.

Baseline Fees

The baseline fee rates for a channel are decided by looking at channel fees set by all the other channels of your partner. CLBOSS checks all the incoming directions of every channel of the peer and computes the median of their baseline and proportional fee rates weighted by each inspected channel’s size.

Here, CLBOSS is working as an entrepreneur. It checks what the competition is charging for their liquidity and sets a baseline price for its own node. This way it is making sure to enter the market with a price that is deemed attractive by the network, compared to its competitors.

Size Multiplier

There are three multipliers that are then applied to the baseline fees.

The first multiplier is based on the relative size of the node’s total capacity with respect to its peers’. CLBOSS will apply a lower multiplier when the node is smaller compared to its peers, and a higher one if it is bigger.

In particular, CLBOSS discriminates according whether the node is larger or smaller than the median. In the former case, the resulting multiplier will be determined by a logarithmic function, in the latter by a square root function.

The idea is to apply a discount on the fee rate to drive more demand to the node if you’re smaller than your peers. On the other hand, a bigger node could leverage its higher routing capabilities (i.e. being able to route large payments without issues) to earn more from fees, so we charge a bit more, comparatively.

Balance Multiplier

Another multiplier used to modulate the fee rate is based on the balance of the channel.

The balance multiplier allows the fees to swiftly react to changes in the channel liquidity, following a simple supply-demand principle. CLBOSS will apply a premium in case the channel has low balance while applying a discount on the fee rate when the balance is almost full.

CLBOSS is applying the law of diminishing marginal utility. In fact, CLBOSS finds more utility in the last sats left on the channel balance, selling them at a premium, than in the sats belonging to a full channel, which can be discounted to obtain more inbound liquidity.

Price Theory Multiplier

The last pricing strategy used by CLBOSS to determine fees is based on an iterative feedback mechanism which tries to maximize routing profits. The algorithm is based on price theory which presumes that there are no local optima but rather a single global optimum price.

The algorithm works in the following way:

1. At the first iteration, the price is set to 0 ;

2. A small “deck of cards” is initialized with price - 2, price - 1, price, price + 1, and price + 2 values and shuffled. Shuffling is necessary to prevent locking onto some regular periodic phenomenon on the network:

3. The topmost card is picked and the multiplier is set according to price on the card. It will be equal to 0.8^ (-price) in case of negative value and 1.2^price in case of positive one. Every forwarding fee earned while the card is active, is recorded;

4. After 2 days, another card is picked and the multiplier is set according to the new price ;

5. When the deck is empty, the card with highest earnings is chosen as the new central price point, a new deck is created and the algorithm starts over.

CLBOSS is actively doing price discovery. Once the deck is empty we set the new central price point on the level that maximized our earnings, which means on the fee rate at which our node performed better in terms of profits. This means that in the successive iteration, we will explore the space around the new price , trying to converge to the global optimum.

While the effect of this approach tends to be slower with respect to the other strategies, it allows to correct the behavior of the fee rate to maximize for earnings.

Principles of Economics in Action

According to the theory of the Austrian school of economics, prices are nothing more than signals, a mechanism to convey information about what actors are willing to pay for resources or services.

In this context, CLBOSS works as an automated market actor, adapting the price of liquidity (the fee rate) to signal the rest of the network about changes in the market and in its internal state or willingness to exchange liquidity. In the following image is possible to visualize when each of the different adjustments acts to modulate the advertised fee for the node.

CLBOSS does so while minimizing the amount of internal information about the node leaked to the public. In fact, peers will not need to know that the balance of the node dropped, they will just receive the signal given by the change in the fee rate and will react deciding either to find a cheaper path or to accept the higher fee.

Interested in learning more about how open protocols are building free markets? Join us in Vienna, Austria this coming May 27+28 for our first ever bitcoin++ economics edition.

Another narrative was that altcoins like Ethereum and Zcash were merely science experiments, testing ideas that would eventually make their way back to Bitcoin. That prophecy largely failed to materialize.

Until 2023, the year that the only other use case for blockchains – gambling on JPEGs and tokens – returned to Bitcoin in the form of inscriptions and runes. These protocols have made up the majority of Bitcoin transactions over the past few years, while more traditional monetary uses have yet to consistently outbid them for blockspace.

This matters, because blockspace demand is Bitcoin’s long-term security model. ETH maxis have long worried about Bitcoin’s security budget, and what will happen to miners incentives when the block subsidy ends in 114 years. Despite them having no idea what will happen with their chain in the next 3 months, it’s a criticism that merits our careful consideration.

Bitcoin’s blocks are full, but miners fees are low. By 2036 (3 halvings away) the block subsidy alone will be a mere 0.390625 BTC (at today’s prices, $1.7B USD/year seems a touch too light to secure the global economy). It is an open question if the subsidy will be enough to secure Bitcoin, especially if it continues to be seen as just “digital gold”, on-chain activity could be too low to pay our hard-working miners.

Fortunately, there is reason to be optimistic that miner incentives will not be an issue: a new demand for blockspace is coming in the form of rollups, the true inheritor of Blockstream’s promise of a functional 2-way peg..

Rollups

Since 2020, the Ethereum project has been working on a roadmap that focuses on rollups being the primary scaling solution for their chain. Meanwhile, Bitcoin devs have been focused on channel-based scaling (lightning network), sidechains (Liquid, Rootstock), and centralized custodial solutions (eCash, Bitcoin banks). More recently, there has been a resurgence in co-signing protocols (ark/statechains) which allow for more concentrated liquidity than channels, with fewer custodial tradeoffs.

Most Bitcoiners, myself included, lack a clear understanding of rollups, largely because rollups were long considered impossible on Bitcoin. The invention of BitVM changes that, and it’s time we start paying attention.

Rollups combined with BitVM are one proposal for how to scale Bitcoin, with their own tradeoffs. Let’s look at how they work, and what those tradeoffs are. The standards for building on Bitcoin are high. Do these rollup designs live up to those standards?

What makes something an L2?

It’s very simple:

Every user can get their money back on to Layer 1 even if the L2 is malicious, either by playing dead, attempting to steal, or any other misbehavior.

What projects currently meet this requirement?

• Lightning

• Ark

• Statechains

Does a BitVM rollup meet these two requirements?

Not exactly no… But don’t despair! It’s not far off! In a BitVM rollup you require at least 1 of the bridge operators to be acting rationally and you can withdraw. (If the sequencer lets you, more on that later.)

Rollups, on Bitcoin

A rollup is a blockchain that executes transactions off-chain and submits proofs of state transitions to the underlying blockchain for validation. The rollup commits state diffs (or summaries of the changes made in the last set of off-chain transactions) to the L1. Posting the state diffs to the L1 allows anyone to reconstruct the rollup’s state by applying each batch’s state diff in order from genesis.

Let’s go through the components needed to create a rollup, and then move on to how BitVM, the Turing-complete scripting virtual machine fits in. There are different approaches and designs (Citrea, Alpen), but here we give a general overview.

A rollup has several components, the sequencer, the prover, full nodes and a DA or Data Availability layer,. In our case, the Bitcoin blockchain is the Data Availability layer.

The Sequencer

At the heart of every rollup sits the sequencer. The sequencer receives rollup transactions and assembles them into blocks, deciding ordering and inclusion.

You can think of it like a single miner with a private mempool.

The sequencer sets the speed of block generation on the rollup. Blocks are created as quickly as the rollup design decides, and this is configurable. In practice, it’s usually a few seconds (Citrea has 2-second block times).

Bitcoin is slow to make new blocks, and blockspace is scarce, so the sequencer doesn’t post every block on bitcoin L1, it “rolls up” blocks and submits them together. This batch of blocks also includes the state diff and a small piece of data called a proof, which proves the block followed the rules of the rollup.

Some rollups post data on-chain before the proof is ready, to pre-commit to the outcome (Citrea commitment TX). Others post a checkpoint that includes both the commitment to the rollup blocks and the proof that those blocks are valid (Citrea Proof TX). This gives the rollup an L1 anchor for a set of rollup blocks.

The rollup batch size is configurable. It can be triggered after a certain amount of blocks, or earlier if the overall state diff reaches a certain size.

In these designs, rollup blocks are signed by the sequencer and full nodes/provers validate those signatures. Only state diffs/proofs go on Bitcoin; rollup full nodes still fetch rollup blocks from the sequencer or other rollup node peers. However it is entirely possible to sync a rollup full node using the state diffs posted on bitcoin.

The proof is mainly used for light clients and bridge operators to verify that a rollup transaction was included in a rollup block and finalized on to bitcoin.

The Prover

In the Bitcoin network, once a block is mined and sent to full nodes, the nodes verify that the block follows all the Bitcoin rules. Nodes execute every script in every transaction in the block, checking signatures and amounts along the way. This is relatively fast and easy to do.

On the rollup chain, full nodes do the same job. However, to reach a globally agreed upon state that light clients and bridge operators can use to quickly verify transactions, a prover needs to post the proof of the block’s execution on‑chain. Anyone can create the proof, but it requires specialized software and a lot of computation, which can take time. So most systems use a dedicated service (”the prover”) to generate proofs.

To create the proof, the prover takes a rollup commitment from the sequencer, and the blocks in the range of commitments, re‑executing them, and producing a proof that can be posted to the Bitcoin blockchain, typically via an inscription‑style envelope. Once the proof is posted on L1 and sufficiently confirmed by 6 or more blocks, the rollup nodes accept this as a finalized state transition. A Bitcoin transaction reaches 6 confirmations to be considered final; a Rollup proof gets posted to the L1 for the transactions in that batch to be considered final.

The proof used in Citrea and Alpen is a ZK proof, but we won’t get into that here. You can just think of the proof as a way for bridges/light clients to verify the rollup state without replaying everything on a rollup node. Full nodes still re‑execute blocks themselves.

The Fullnode

So it turns out that mastering Ethereum was actually a Bitcoin book after all. Alpen and Citrea both use the Ethereum Virtual Machine (EVM) as the execution environment for their rollup.

Fees on the rollup are paid with bitcoin that’s been bridged to the rollup chain. It acts similar to WBTC (wrapped bitcoin). As the rollup is using the ethereum virtual machine, fees are paid in “gas”, but instead of using ethereum, you use the bridged wrapped bitcoin instead.

Users and wallets send transactions to the sequencer, typically via a full node’s RPC interface. Full nodes poll the sequencer for new blocks, verify them as an Ethereum node would, and update their local state. Block times are determined by the sequencer.

Since all state diffs are committed to Bitcoin alongside proofs, a full node can also sync entirely from the Bitcoin L1: they go through the L1 blockdata to find all of the rollup’s published state diffs, and apply each one, in order, from the rollup’s genesis. The end result should match the current rollup state. No reliance on the sequencer required.

Until a proof is posted and confirmed on L1, blocks are only soft‑confirmed by the sequencer. They’re accepted locally, but until the proof has 6 blocks or so, the state is not considered finalized.

A lot of applications that are running on the rollup will be fine with using the sequencer’s block data directly. For example if your contract was a game, then you can probably trust the sequencer alone, which makes the applications very quick. However, if you were making a large trade on a decentralized exchange contract, then you may want to wait for the block to be included in a proof on the Bitcoin blockchain.

Risk Factors

The prevalence of centralized sequencers is among the biggest safety risks for rollup users. Billions of dollars trust similar centralized setups in the ethereum world; and I’m happy about that for them. It would shock the conscience for Bitcoiners to agree to a similar threat model. So I don’t think they will.

Maybe I am biased. After all, I’m working on the char.network, which is essentially a decentralized sequencer for Bitcoin based rollups. And, most rollups state clearly that moving to a decentralized sequencer is a part of their roadmap.

Some projects, such as Starknet, are already using a decentralized sequencer architecture. For Starknet this means 3 nodes run by 3 operators whose names all seem to begin with Stark and end with Net.

This also affects bridge operation (which we will get into next). The sequencer can always refuse to include the transaction that kicks off your bridge withdrawal. And if that transaction never makes it into a rollup block, there’s no path to getting your bitcoin back to the mainchain.

Ethereum rollups try to mitigate this with “forced transactions“ (a way to bypass the sequencer and still get included). Forced transactions are still an open research problem that Bitcoin rollup projects are working on.

Another point to make is that whoever is privileged enough to run the centralized sequencer, makes a lot of money in transaction fees and MEV. You could say they are incentivised to play honestly, but they can still easily censor transactions and bridged bitcoin withdrawal requests.

One last risk users bear under this rollup architecture is the expense of committing to the state diff and proof data to the L1. Who knows what the blockspace fee market will look like in a few years? It could be incredibly expensive to commit these proofs to the Bitcoin chain. Rollups paying high fees is good problem for Bitcoin itself, but if the rollups are not getting used much, then paying high fees to commit data would not make economic sense, and users would be stuck with a pricey bill to remove their funds.

Sequencers, provers, rollup full nodes, and the EVM explain how the rollup is architected, but how does the “two-way” peg to the L1 work? How do we move bitcoin back and forth between the two systems?

The Bridge

Most Bitcoin bridges that exist today (Liquid, WBTC, etc.) rely on a federated multi-sig, where you need a threshold of signers to allow you to withdraw your bitcoin. We call this a 1-way peg, since you can send your bitcoin into the contract, but need help from enough of the multi-sig signers to get it back out again.

A BitVM-style bridge is also a 1-way peg, but the number of participants needed is different: you only need one active operator who plays by the rules to withdraw your bitcoin. There could be 100 operators in theory, so you can see how this gets interesting – as long as one of these operators is acting rationally, and is still online, you are able to get your bitcoin back to the mainchain. Maybe we can call it a 1.5-way peg.

You also rely on a challenger who can step in and prove fraud if an operator tries to cheat.

In a BitVM bridge, there are operators, signers, and challengers*.

• Signers exist to “lock in” the bridge rules during setup. Signers create an emulated covenant by pre-signing the only valid spend paths and then delete their keys. As long as at least one signer is honest and deletes their key, nobody can later create an alternate withdrawal path and send the money anywhere they like.

• Operators do the day-to-day work during rollup operation: they watch the rollup, front withdrawals, and later claim reimbursement from the bridge.

• Challengers keep operators honest by watching proofs posted to the L1 and challenging bad claims.

*Citrea uses the concept of watchtowers, which is a permissioned set of challengers. We won’t get into that here though.

For simplicity, I’m going to assume the bridge signers and operators are the same group of entities, even though conceptually they’re different roles. The signer role could be removed entirely if Bitcoin had some kind of covenant opcode (ctv btw). Citrea’s bridge does follow a slightly different security model, which allows the signer to be upgraded.

Operators create and manage BitVM instances. They run a SNARK prover off-chain, and use pre-signed Bitcoin transactions (plus a challenge window) to enforce a fraud-proof game around the prover’s output.

Depositing, or Pegging In

For each new deposit, a new BitVM instance is created. A deposit is expected to be around 0.5 to 100 BTC. The average user would most likely enter/exit via atomic swaps / liquidity providers (similar to how Liquid/Lightning get used today), and power users would deposit and withdraw large amounts of bitcoin from the bridge.

First, a user deposits their bitcoin into a staging address. This address allows the bridge operators to sweep the bitcoin into the bridge. If they do not initiate a bridge deposit, the user can withdraw their funds after a timelock.

The bridge operators deposit bitcoin into the bridge by creating an L1 transaction that locks their deposit funds into a BitVM bridge contract, or UTXO, on the L1 Bitcoin chain. The key property of this UTXO is that it’s pre-locked to a specific transaction flow created during setup, assuming at least one signer performed his role honestly, as mentioned previously. In other words, unless 100% of the signers cheated, the BTC can only move along the pre-defined “bridge rules”, which allows the transaction to be challenged if the operators are suspected of breaking the rules.

Once the deposit transaction is confirmed on Bitcoin, users or operators can call a rollup smart contract that emulates a Bitcoin light client, verifies the deposit is included in a Bitcoin block, and mints wrapped BTC to the user’s rollup address.

Withdrawing, or Pegging Out

Withdrawing is simple as long as one operator is active, and there’s at least one party willing to challenge fraud if needed.

Here’s the steps a user would follow to withdraw their bitcoin from the rollup back to the Bitcoin L1.

1. Burn on rollup - The user burns their wrapped BTC on the rollup (making it unspendable on the rollup).

2. Operator fronts the Bitcoin withdrawal - The user creates an incomplete Bitcoin withdrawal transaction using an ANYONECANPAY-style sighash so that an operator can attach their own BTC input. Operators compete to front the BTC and publish the completed withdrawal transaction (they do this to earn a fee). One operator wins and the user receives their BTC on Bitcoin.

3. Operator claims reimbursement from the bridge - This is where the BitVM game begins.
   Once the operator has fronted the withdrawal, it broadcasts a claim transaction that pays itself the same amount from the bridge deposits. This starts a challenge period.

4. Operator creates a BTC bond as collateral - Depending on the implementation this is done during the claim process, or when the BitVM instance was created. This bond can be slashed.

• Anyone (including other operators, the user, or any third party watching) can verify whether the operator processed the withdrawal correctly, that the rollup burn happened and the corresponding Bitcoin withdrawal is truthful.

• If nobody challenges within the window (1-2 weeks), the withdrawal finalizes and the operator gets reimbursed.

• If the withdrawal is for less than the original bridged amount, then the remaining bitcoin goes back to the bridge. (The operators will need to make a new BitVM instance for this amount).

• If someone challenges and the operator is proven wrong, the operator’s bond is slashed: a portion is sent to an unspendable output (effectively burned via an op_return), and the remainder is paid out as a bounty to whoever posts/completes the disprove transaction (often the challenger).

The BitVM Game

Unlike the EVM rollup chain, the Bitcoin blockchain has no way of verifying a proof directly. This is where BitVM comes into play.

Operators run a prover program (similar to a Bitcoin light client) to which they pass in the following inputs:

• A previously known bitcoin block hash

• A Bitcoin block hash from after the withdrawal transaction was broadcast

• The L1 withdrawal transaction used to front the payout

• A rollup proof that was committed to Bitcoin, that proves the wrapped bitcoin was burned on the rollup

The output of the program is a proof that can be used to verify that the operator’s withdrawal was included between the blockhashes and paid out to the user on the Bitcoin L1.

Then the operator posts a reimbursement claim on Bitcoin with this proof.

• If nobody challenges during the window, the operator finalizes and gets reimbursed

• If challenged, the operator has to commit to more details (Assert TX), and the challenger can force the protocol to check a piece of the verification logic on-chain (Disprove TX); if it fails, then the operator has lied and they get slashed (lose the bitcoin they put into the bond).

With BitVM2, the transactions posted on-chain are very large. The Assert TX is 2 MB, and the disprove TX is 4 MB (close to a full block). However, recent discoveries using Garbled Circuits and Conditional Disclosure of Secrets (see Delbrag, Garbled Locks, BitVM3, BABE, and Argo) should reduce these transactions to only 80 KB of data in total.

What’s next?

Rollups combined with BitVM allow us to create what is very close to the two-way peg that Blockstream envisioned all that time ago. There are still some trade-offs (centralized sequencers, operator assisted withdrawals) that do not quite make them the holy grail of Bitcoin scaling, but new discoveries and breakthroughs are happening all the time.

Citrea launched their BitVM2 rollup this week. Alpen is working on a BitVM3 implementation, and several other teams are building BitVM bridges.

If only a few of these rollups exist and become popular, their demand for blockspace will greatly increase Bitcoin’s security model for the foreseeable future.

Mitigations are being developed to the risks we mentioned earlier. Several teams – including Char Network – are explicitly focused on removing the sequencer trust assumption, which may turn out to be the final step that separates “interesting experiments” from true Bitcoin L2s.

The closer we get to a trustless two-way peg, the closer we are to having private, scalable digital cash. This is an exciting step towards that goal. An EVM rollup is just one example. Once we have a trustless bridge, the possibilities are endless. For example, ZKcoins is a very promising private, client side scaling solution that needs a BitVM-like bridge.

Anyway, I hope this helped explain what these rollups are and how BitVM fits in.

In conclusion, let’s activate drivechains.

Catch in person at bitcoin++ exploits edition in Florianopolis next month, talking about “building bridges to north korea” or how chain bridges have historically been exploited. Get a ticket with code INSIDER for 10% off!

Join us in Floripa!

Thanks to Niftynei, SuperTestnet, Otaliptus, Ponzini, ecurrencyhodler, Liran, Janusz and Jeremy Rubin for reading drafts of this, and Paul Sportz for the closing sentence.

A guest article from Yashraj

Bitcoin’s blockchain is transparent. Activity around any on-chain address is easy to inspect by using free, publicly-available blockchain explorers. As a result, existing on-chain transaction UX in privacy-conscious wallets revolves around one major concern: avoiding address reuse. This pre-occupation has given rise to certain UX patterns that are standard in practically every self-custody wallet. Issuing (and communicating) new addresses for every transaction is inefficient and unintuitive. Users adapt to this routine over time, but the friction is significant. This friction becomes apparent when you consider steps taken outside of the wallet app itself.

Let’s walk through the steps new addresses require.

• the receiver must 1) open their wallet app 2) click on Receive button 3) copy the on-chain address 4) share it with the sender.

• the sender must 1) ask the receiver for a fresh address, 2) obtain it from the receiver, then 3) enter this address into their wallet’s Send page (and construct the transaction) and 4) briefly review it before broadcast

These steps are repeated for every single payment. Contrast this with other payment or communication protocols we use: email addresses, phone numbers and bank account information – you exchange this information once, and can use it repeatedly.

Bitcoin should be similarly easier to use, while still preserving privacy. New protocols like silent payments and payjoin provide an opportunity to re-examine (and maybe improve) on-chain transaction UX. In this post, we will do just that.

Enter silent payments

We discussed how avoiding address reuse is the basis for existing on-chain transaction UX. For example, a prominent Receive button allows the user to generate new on-chain addresses with each use. Send flows involve (and often start with) entering the recipient’s address.

Silent payments is a protocol that was created to prevent address reuse. It gives us a new type of address that never appears on-chain, but is used by the wallet app to programmatically derive unique on-chain addresses during the transaction process. Silent payment addresses are meant to be reused. As many times as needed.

The 4 step process (as a recipient) to simply share a fresh address with the sender? Gone. Share your silent payment address once, and you’re done! Remember asking the receiver for a fresh address every single time you want to pay them? No more; just get their silent payment address once, and save it for future use. Silent payments is Efficiency Go Up technology!

Not just that, silent payments (along with BOLT 12 and BIP-353) make using bitcoin as easy as sending an email or making a phone call. With silent payments, wallet apps can provide Contacts functionality to its users, storing this reusable payment information. Adding a Contacts module allows applications to tap into a highly intuitive, long-established user pattern, while ensuring address re-use is prevented. Apps like Phoenix have already started doing this for BOLT 12 offers.

Of-course, silent payments can also fit into existing send flows, as existing implementations have done. But in this author’s view, existing user flows don’t do justice to silent payments... and to users frankly.

One-shot payment flow…

In spite of the cumbersome user steps described at the beginning of this post, one feature of the existing interaction model is that users are able to complete their actions within a single sitting.

After the receiver has shared their address, they are not required to do anything further. They never have to sign or review anything. This is a logical and familiar experience for the recipient of the payment.

The sender only comes online after they’ve received the address from the recipient. They are able to construct, review and broadcast the transaction in a single session too, usually taking less than a minute.

A one-shot payment flow. Nice. Except payjoin disrupts it!

Enter payjoin

Matters get more complicated when it comes to payjoin. In payjoin, both the sender and the receiver work together to construct a privacy-friendly transaction (see why). To do so, they pass around transaction drafts, to which each party adds their coins and signatures. With async payjoin, this procedure can be done without either party having to run a server (to facilitate this coordination), or both parties needing to be online at the same time. Elimination of these constraints puts privacy within the reach of non-technical users, while also allowing it to be used in a wider set of scenarios.

For e.g. Alice and Bob decide to go to a bitcoin conference in Las Vegas for the first time. Alice buys the flight tickets for both of them. Bob has recently orange-pilled her, so she agrees to be paid back in bitcoin. Alice opens her bitcoin wallet and shares an invoice with Bob over chat. By the time he’s online to act on it, she’s on a flight. With async payjoin, they can still do a privacy-friendly transaction.

However, async payjoin comes with tradeoffs, specifically extra steps and potential delays. I wrote about this in my post about payjoin UX challenges.

Long story short, async payjoin adds bells & whistles to the process of sending or receiving bitcoin, such as:

1. receivers need tomust come online in the middle of the payjoin process

2. receivers may have to pay fees

3. senders must sign twice (once for initial draft, once after receiver adds their inputs), and come online to do so

4. both parties must wait for each other to come online and sign

5. this process (likely) spans multiple sessions for each user – breaking the one-shot payment flow

These situations don’t fit very well within existing send/receive flows. Additionally, the above points are unlikely to be obvious to anyone, but the most tech-savvy users. The application must inform, assist or encourage users about these aspects. Payjoin transactions not only include additional manual steps, their async nature also means they might take a long time (hours) to execute. Where hardware signers and/or multi-sig setups are involved, the effort or just the situation might make it too onerous for the user to pursue a payjoin transaction. This highlights the need to help users form an appropriate mental model for payjoin, complete with optionality, feedback and suitable communication through the UI.

Furthermore, payjoin enables features (such as payment batching and timelock refresh) that might not fit into existing user flows.

Overall, it seems clear that new UI and user flows are needed for good UX and full-featured payjoin implementations. Shoehorning payjoin into existing UX seems barely possible and not desirable.

Wrapping up

Many consider bitcoin hard to use. The existing on-chain send/receive flows lend credence to this view, as we saw above. Silent payments can change this perception by helping match on-chain UX with that of email or fiat fintech by using a safely reusable payment method, transforming on-chain UX in the process.

Privacy is another area that’s not a strong suit for bitcoin. Payjoin addresses this, helping users to protect their privacy during the course of making/receiving a payment. However, as discussed above, async payjoin does not play well with prevailing on-chain UX.

The writing is on the wall – existing transaction UX leaves a lot to be desired. It’s time to move past it.

Bitcoin is a decentralized ledger. Its power comes from its ability to move value between any two people that are using the protocol, without having to ask a third party for permission to transact. To achieve this modern marvel, Satoshi Nakamoto invented a novel form of consensus, one that works so long as 51% of the network maintains their independence via mining.

The bitcoin protocol, unlike most other protocols like http or tcp which run the internet, doesn’t have a written specification. Instead the rules of how bitcoin works is embedded into code. That codebase we call bitcoin core.

Bitcoin core, as a project, is tasked with the responsibility of maintaining the network in an operational state. There are a few guiding principles which go into maintaining bitcoin’s implementation. These principles are occasionally tested.

For example, the blocksize wars was a test of the principles that bitcoin should follow from a resource consumption standpoint. That is to say, what kind of hardware would an individual need to personally own in order to be able to download and verify every block on the network. Some people believed that the ability of every man to run a node was less important than the number of transactions that bitcoin can handle in a second.

Others, the winning faction I should point out, believed that bitcoin could not be a success without keeping the storage requirements within the grasp of a man with a few hundred dollars they were willing to spend on a computer.

Decentralization at the node runner level was decidedly a central principle of the Bitcoin project. The blocksize wars were fought and the winners came out in favor of accessibility and “cockroach like” proliferation of nodes instead of transaction throughput.

For example, Jameson Lopp famously would publish reports on his attempts to start an Ethereum node from scratch. The hardware required was in the thousands of dollars. I’m not sure he successfully managed to sync the chain.

This is exactly the type of thing we want to avoid in bitcoin.

Which brings us to our current conundrum around op-return. The goal of changing the op-return rules is to preserve the ability of anyone to run a node. What’s the connection? Well, people want to put information inside of bitcoin transactions. You may disagree with this idea, but for them there is an economic rationale for doing it. They’re willing to pay good money to publish this information, much like someone might publish a classified ad in a newspaper.

The only problem is that how they choose to publish the data has real costs to the hardware required to run a node successfully (the amount of storage space and RAM your computer has). So bitcoin devs, in their desire to maintain the project in a state where it was still accessible to run, made a special carve out for data-only. This is called op-return.

It works because it allows nodes to effectively ignore the information contained in an op-return. This reduces the total amount of data a node needs to keep track of in working memory, which reduces the RAM requirements.

For the record, more people holding bitcoin, and more UTXOs being created, contributes to the resource requirements of a node. The goal is to get people to hold bitcoin but not use UTXOs for data. Op-return fixes this.

Except people couldn’t fit all the data they needed into 80-bytes, so they reverted to more resource intensive ways of publishing data. So the maintainers of bitcoin core, in order to head off potential loss of accessibility to running a node, opted to remove the relay restriction on op-returns.

I get that having data in blocks may be undesirable, but it’s not anything that can be stopped. Bitcoin core’s maintainers are working to preserve the ability of anyone to run a node, for the foreseeable future.

More people are running nodes now, because they want to make a statement about autonomy and choice. That ability is one that was fought for and continues to be defended by the maintainers of core. The recent op-return decision is one more example of the maintainers prioritizing ability to run nodes on cheap and accessible hardware over all other considerations.

More people are running nodes because of their decision to change op-return. That ability to spin a node up is exactly what the maintainers are safe guarding.

Speaking of decentralization, I think it’s quite ironic that more people are running nodes now in order to filter out transactions, because the act of filtering actually makes it harder for independent miners to compete for blocks.

By running a node that prevents the relay of transactions that are profitable for miners, you’re making it less likely that other nodes will be able to quickly verify blocks.

Every time a new bitcoin block is found, your node has to first get a copy of every transaction in the block. It verifies each of the transactions and then sends the block on to the next node in the network.

If you’ve ever played Base58’s Bitcoin at Work(shop), you’ve done this by hand. If transactions are missing from your node’s mempool, you’d have to request them from other nodes on the network. Until you’ve found them all, you can’t mark the block as valid. You can’t start mining on top of a block until you know it’s valid.

Not having transactions readily available means that your node is at a time disadvantage in hunting for the next block. As is any miner waiting for you to notify them of the current valid block. Requesting transactions means blocks move through the network slower, giving small miners less time to try finding a new block before more centralized miners that keep every transaction in their mempool.

OCEAN claims they’re aiming to help make mining more decentralized, and I believe they mean to do this. However their suggestion to filter out transactions leaves smaller nodes and Bitaxes at a disadvantage in terms of finding a block. Unfortunately this contributes to giving preference to larger miners who are more likely to have every transaction and be connected to more nodes so that they hear about blocks sooner.

Building your own block template is a great opportunity to filter out transactions. At the relay level, however, you’re only undermining the goals you set out to accomplish.

I fully believe in decentralized systems, as does every Bitcoiner I know. It’s incredible to watch the node running community grow and people feel empowered by helping keep bitcoin decentralized. If you’re not already running a Bitaxe, I’d recommend it. Filter the transactions going into your blocks your Bitaxe is mining if you want to have a say in data on bitcoin.

For the sake of maintaining bitcoin as decentralized system, however, I’d strongly suggest you reconsider filtering the mempool and restricting op-return data.

Presidio Bitcoin, a Bitcoin-only co-working space in San Francisco, held a summit last week about Quantum Bitcoin. @roasbeef, lead maintainer of `btcd` and `lnd` and CTO of Lightning Labs, presented a proposal for adding a post-quantum signature scheme to Bitcoin, SPHINCS+. In today’s edition, Insider’s protocol-expert @niftynei breaks down the proposal.

The Quantum Problem

Most coins on chain in Bitcoin are secured with private keys. To move Bitcoins around on-chain, you prove that you have permission to spend them by creating a signature. A valid signature can only be produced by someone who possesses the correct private key.

In some sense, Bitcoin is “security by obscurity”, where the obscurity is how hard it is to guess your private key. The number of possible private keys is astronomically large. Guessing all the private keys would take more time and energy than anyone has access to in a reasonable timeframe (think hundreds of years).

However, current Bitcoin keys rely on math equations that are based on elliptic curves. Elliptic curves are a clever system to rely on for creating public and private keys, as they’re generally more secure and smaller than prime factorization (another ‘math system’ that public/private key cryptography is often based on).

Elliptic curve cryptography has a problem, however. Shor’s algorithm, invented in 1994 by Peter Shor based on Fourier Transforms, means that a quantum computer with enough qubits can quickly compute the private key of any public key.

Shor’s algorithm means we know how to break elliptic curve cryptography, the tools to do it just don’t exist yet. Whether they will exist, and when, is a topic of much debate not just in bitcoin circles, but the wider cryptographic ecosystem. The security of every private key in bitcoin depends on the tools to execute Shor’s algorithm remaining out of reach of everyone for the indefinite future.

General consensus is that at some point, bitcoin will need to transition to a post-quantum cryptosystem for public and private keys. @roasbeef’s proposal at Presidio Bitcoin last week is based on the SPHINCS+ hash-based signature scheme. Let’s dig in briefly to how it works and why it’s potentially a good fit for securing bitcoins.

Quantum secure but data heavy

SPHINCS+ is a signature construction that’s built on hashes. At its core, it relies on cryptographic hashes to construct public keys and verify signatures, rather than elegant elliptic curve equations or hiding in large number prime factorization. Hash-based crypto schemes are safe from Shor’s algorithm because they don’t use functional math systems under the hood for their one-way functions. Instead, they rely on brute force data mashing of preimages. Brute force has no mathematical relationships or short cuts that are vulnerable to quantum computer Fourier transformations, of the likes that Shor’s algorithm uses.

A downside to mashed data, aka hash functions, is that their public keys and signatures require much more data to be shared. Elliptic curves were chosen for blockchains by Satoshi himself, precisely because of how little data needed to be shared to confirm a signature or lock coins up to a public key. I like to say that Bitcoin was the killer app of elliptic curve cryptography; prior to Satoshi’s use of secp256k1 in the protocol, the majority of cryptosystems used RSA, or prime factorization, as their underlying math system. According to the SEC 2 parameters paper, a 128-bit secure RSA signature would require 3072 bits for a public key; the elliptic curve equivalent only requires 256 bits.

Using very little data is important in blockchain systems, as any data that is added to the chain must be stored and sent to every single peer on the network. Compact signatures and public keys mean that more transactions can fit into the same amount of data. Size savings is arguably the reason why Satoshi chose to use elliptic curves instead of RSA cryptography for bitcoin.

Post-quantum cryptosystems are impossibly large in comparison. SPHINCS+ systems have equivalent sized public keys to the current Bitcoin key system at 32-bytes but the signature sizes are thousands of bytes larger. A Segwit v1 Schnorr signature is 64-bytes of onchain data; comparable SPHINCS+ benchmark sigs are 3-7k bytes.

SPHINCS+

SPHINCS+ is a complex signature scheme, built using several layers of post-quantum signature ‘widgets’. When combined, SPHINCS+ produces a single quantum safe public / private keypair which can be used to sign many messages safely. Unlike XMSS (eXtended Merkle Signature Schemes), a prior post-quantum signature scheme that SPHINCS+ is an improvement over, you don’t need to remember anything about prior signatures made with the keypair for any subsequent signatures.

One SPHINCS+ “structure” produces a single pubkey that can safely sign many messages without revealing the secret key.

A SPHINCS+ 'structure’ is constructed of three different pieces:

• FORS, or “Forest of Random Subsets”. This is at the bottom of the SPHINCS+ “structure” and is where the message is used to choose a series of preimages to reveal. This set of revealed preimages becomes the base of the SPHINCS+ signature. In SPHINCS+, the message is effectively ‘signed’ using FORS. The next pieces are used to tie the FORS signature to the root public key for the SPHINCS+ superstructure, as I’m choosing to call it.

• WOTS+, or “Winternitz One Time Signatures+”. This is a post-quantum hash based signing algorithm that can sign one message securely. SPHINCS+ uses WOTS+ signatures to tie the revealed preimages in the FORS into layered-XMSS Merkle trees. The root of the layered Merkle trees is the SPHINCS+ pubkey. (The only difference between WOTS and WOTS+ is that the + variant includes a random prefix in every hash operation, which mitigates multi-target hash attacks. The ‘+’ in SPHINCS+ also means that every hash in the SPHINCS+ includes a randomly generated prefix.)

• XMSS Merkle trees. An XMSS Merkle tree has WOTS+ public keys as each of the leaves. SPHINCS+ builds huge pyramid-like structures out of layers of XMSS Merkle trees. Trees on top of trees are also commonly referred to as “hypertrees”. Each leaf of the parent tree is a WOTS+ public key. The key is used to sign the root of the tree underneath itself in the structure. This ties the trees together. How many trees and how many layers are changeable depending on the desired size of the signature for a SPHINCS+ ‘superstructure’. The smaller the signature, the more hashing will have to be done to verify and produce signatures. Each leaf at the very bottom of all the trees is a FORS. Many layers of many Merkle trees means many many many FORS at the base of the pyramid that can be used for making secure signatures with very little possibility of reuse.

The general work of producing a SPHINCS+ public key is to generate all of the WOTS+ public keys that are at the root of the tree, and then calculate the Merkle root for that tree. The root of the top tree is the SPHINCS+ public key. The root of a Merkle tree is the same size as the hash function used to calculate the root. Typically we use SHA256 as the chosen hash function, which output 256-bits. This means that the root for such a Merkle tree is 32-bytes. This is where the SPHINCS+ public key comes from.

Creating a signature for SPHINCS+ requires using a hash of the message to randomly pick which sub-tree’s subtree the FORS signature will be connected to the SPHINCS+ ‘hypertree’ at. Once the FORS signature is created, it’s then tied into the SPHINCS+ hypertree by signing the FORS signature with the WOTS+ private key at the randomly selected sub-sub-sub-tree leaf. From there, signatures and Merkle paths are collected until you reach the root SPHINCS+ public key. All of the of WOTS+ signatures, plus the FORS signature, plus the series of Merkle paths to trace from the root SPHINCS+ pubkey to the place where the FORS signature was tied into the structure are the signature of the message. This is a lot of data, as one can imagine, and is why the signatures for SPHINCS+ are orders of magnitude greater than a simple 64-byte elliptic curve equation result and nonce value.

Why SPHINCS+

SPHINCS+ is quite layered. It’s much more kludgey and relies on several different “widgets” to produce signatures: Witnernitz signatures, FORS, and XMSS subtrees.

SPHINCS+’s complexity comes from its powerful set of features. It is a strict improvement on XMSS by itself, another post-quantum signature scheme that allows for signing multiple messages. Unlike XMSS, where you must track each Merkle leaf that has already been used to sign, SPHINCS+ uses randomness generated from the message digest to deterministically select a random sub-leaf in the hypertree.

In Bitcoin, you’re ideally rotating public keys for every transaction, which means generating a new SPHINCS+ superstructure for *every* bitcoin pubkey that you use.

Initially I was confused about why you would want such powerful re-signing capability into what’s (ideally) a single use public key.

Jonas Nick of Blockstream Research pointed out that you would want to be able to re-sign a transaction for fee bumps or if a transaction was lost for some reason; Laolu, aka roasbeef, highlighted that off-chain protocols like Lightning require repeated signing of transactions for tracking private state transitions.

You likely wouldn’t need enormous resigning capability for Bitcoin, which would allow you to build smaller SPHINCS+ super structures under each pubkey. Smaller super structures would mean less data required for each signature, as the Merkle tree path data would be reduced. It also means that there’s less signatures that you can make before beginning to degrade the security. Unlike elliptic curve equations where nonce reuse immediately leaks the private key, over usage of a SPHINCS+ pubkey for signatures merely begins to degrade the security downwards from 128-bits as the FORS at the bottom get partially reused.

After digging into it, I have to say I’m quite a fan of roasbeef’s proposal to use SPHINCS+ as a post-quantum signature scheme. There’s still lots of design work to be done for exact parameters. I expect a draft BIP proposal, which he has indicated is in the works, will help fill in some of the gaps around depth of the super-structure and number of signatures that can safely be made from a single keypair.

Also worth pointing out, as mentioned in roasbeef’s presentation, SPHINCS+ doesn’t allow for seed/child derivation paths. This means that BIP32 hierarchical wallets and would be effectively dead. There’s other options here, but we’d likely lose the ability to describe keys in a wallet using hierarchical derivation paths, as is the custom these days for xpubs and child wallets.

Which way Western man

Bitcoin will move to a post-quantum signature scheme. When, what construction, and with what parameters is likely to be a hot topic of conversation for the next few years.

Roasbeef’s proposal for SPHINCS+ is a compelling option, despite the level of complexity built into the multi-layer tree superstructures. All hash-based post-quantum public key proposals are quite ugly in my opinion. SPHINCS+ is ugly because it offers the most features, specifically the statelessness of repeated signings.

With a better understanding of the role each piece plays in the protocol, I have a strong appreciation for the cleverness that led to it’s very layered setup.

Roasbeef still has his work cut out for him in writing the BIP, particularly in choosing the depth of each tree and the number of sub-tree layers, as well as the size of the Winternitz signatures and the FORS parameters. There’s a tradeoff between the size of signatures and the amount of hashes that are required to produce the signature. Choosing the right balance between computation and on-chain footprint is work that still needs to be done before publishing a formal BIP proposal.

And there’s a last question that remains to be answered:

Would moving to SPHINCS+ mean that Bitcoin is now a pyramid-scheme? Hard to say definitively, but it certainly looks that way.

Credits

Thanks to Jonas Nick and Olaoluwa Osuntokun for their help in explaining the reuse cases and tuning parameters for SPHINCS+.

Further Reading

Want to dig in further? Here’s some excellent resources that we relied on for writing this article

• Laolu’s original presentation given at the Quantum Summit at Presidio Bitcoin on July 17.

• Sphere10’s Winternitz signature explainer unlocked the basics of post quantum signatures for me.

• A deep dive blogpost by software developer Ethan Rahn. Includes great diagrams and covers some of the history of post-quantum signature development.

• Incredibly in-depth presentation on SPHINCS+ by John Kelsey of NIST. The best detailed explainer I’ve seen, but definitely in the weeds.

I think there’s something brewing on the internet. Well, thousands of others do as well, but I will claim that we called it first.

If you’re on Nostr, or the Bird app, you might’ve seen the newly released Bitchat application from Jack Dorsey. It’s quickly gone viral and has caught the attention of a number of devs in the space. Calle, the creator of Cashu, has been building Bitchat’s android implementation and… you guessed it:

A native Ecash wallet is built into the Bitchat mobile application.

Bitchat combined with Chaumian E-cash has the potential to create a new tool for anonymous, offline payments on mobile devices. What used to require pigeons can leverage noise. What used to require paper notes can leverage Chaumian E-cash.

Here’s my take: Bitchat and Cashu are a promising tool for anonymous, offline bitcoin payments. There’s tradeoffs, but in certain situations, they can provide users a convenient way to transmit value offline. This can even be critical infrastructure in times of crisis.

And funnily enough, our team was debating this combination’s capabilities a few hours before the announcement was posted. This piece is a reflection of those discussions.

Breaking down Bitchat

Bitchat is a peer to peer messaging app that uses Bluetooth to send messages to nearby peers. The tech stack for it is built in three different layers: Bluetooth mesh networking for message sending and receiving, the noise protocol for private communications, and ephemeral peer IDs for ensuring identities are only provided to those you trust.

Bluetooth mesh networking

First is a bluetooth mesh networking layer. A mesh network is a local network created between local, co-located peers. Different nodes (mobile phones or laptops with bluetooth chips) find and connect to each other. Once connected via Bluetooth and the networking protocol, they can transfer data amongst themselves.

In a mesh network, each phone is both a sender and a relayer of data packets. This means that a device can either be the recipient of a piece of data, or can relay this piece of data to another recipient in the network. Individual Bluetooth ranges are limited, so this local-peer relay feature extends the reach of each peer in the network past what their device is capable of on its own.

Here’s a quick example. Alice needs to send a message to Charlie, who is 200 yards away. In between them is Bob, who is 100 yards away from each. Alice, Bob, and Charlie are all on the same mesh network. Alice sends the message out over the broadcast band, Bob relays it, and Charlie receives it. Once Charlie has the data, they’re ready to decrypt it and read what’s inside.

For the encryption and decryption of the data packets that are relayed across the network, bitchat uses noise.

Noise protocol

The Noise Protocol was pioneered at OpenWhisper Systems, the founders of encrypted chat app Signal, as a framework for establishing encrypted communications between two peers who want to exchange private messages.

It’s primarily a “handshake protocol” which allows two peers to use the Diffie-Hellman key exchange in order to establish a secure, encrypted connection for ongoing private communications. Using just Diffie-Hellman key exchange, the Noise protocol enables end-to-end encryption, forward secrecy, identity hiding, and authentication.

Bitchat uses a 3-step Noise XX handshake. Users establish a secure channel (known as Noise sessions) between each other, all subsequent messages exchanged between them will be private communications.

To establish this connection, one peer initiates the handshake phase, the other peer responds. After a successful 3-message handshake, the peers are able to continue communicating using a shared encryption key.

The session is rekeyed, or “refreshed”, after 10,000 messages or a timeframe of 1 hour enabling strong forward secrecy.

Ephemeral peer IDs

Bluetooth allows peers to exchange data packets; the Noise handshake protocol allows for peers to encrypt messages into those data packets. Now how do you know who you’re talking to, but maintain anonymity over time?

Insert Ephemeral peer IDs.

Ephemeral peer IDs ensure the rotation of peer IDs within some time frame. This means users’ IDs within a chat change periodically during random intervals. In Bitchat, this happens every 5-15 minutes or when a session terminates. Bitchat’s session management framework ensures that these peer IDs are appropriately discarded after a session has expired.

During a noise handshake, the application links the current ephemeral IDs and maps them to a SHA256 fingerprint of the respective users’ public keys. This ensures that even after a session expires, users who have authenticated their relationship can retain a persistent identity for each other. Users can also assign social names to their peers whose relationship has been authenticated.

Users can maintain secure relationships with their peers, while preventing tracking in the broader network.

Bitchat enables fully offline, private transfers of data

With Bluetooth for mesh networking, Noise for encrypted channels, and ephemeral ids for identity, Bitchat enables users to connect and send encrypted messages through a broader peer-to-peer network. Users do not reveal themselves to network participants unless a secure connection is established.

Bitchat can be useful in a wide range of circumstances. It can be used in situations where internet infrastructure and cell towers are not functioning. Or, it can be used in more mundane circumstances - like when you’re at a concert and your cell signal isn’t coming through.

For the privacy conscious, it provides an alternative to internet-based encrypted chats. Connecting through Bluetooth means that you don’t expose your location to local cell towers.

If only we could maintain that level of opsec when sending bitcoin around…

Combining it with E-cash

Calle demonstrated another use case for Bitchat yesterday: transferring bitcoin-backed tokens across a mesh network while offline.

Calle invented the Cashu protocol in 2022, a Chaumian e-cash payments protocol which enables users to use bearer tokens to transfer funds. Chaumian payment systems rely on a mint, which holds the underlying asset in exchange for e-cash tokens which users can use as payment instruments. Bitcoin-denominated e-cash mints hold user deposits of on-chain Bitcoin. The mint operator is expected to secure the funds until redeemed by e-cash token hodlers and keep the bearer tokens in the mint pegged. Mints are also responsible for not issuing more e-cash tokens than they have bitcoin holdings. It’s expected that the value of e-cash tokens in circulation match 1:1 with the mint’s on-chain bitcoin balance. By removing on-chain custody concerns, e-cash mints lower the barrier to entry for setting up bitcoin custodial services for friends, families, and communities.

The Cashu protocol provides a feature for offline payments. If a sender doesn’t have an internet connection, they can still transact using e-cash by sending the token to the receiver over a communication channel; bluetooth or NFC are both common local comms channels for sending e-cash tokens. But, there is a catch with using e-cash offline. One of the peers in the payment needs to be online to finalize the exchange.

Example 1: Offline receiver, online sender

If the receiver doesn’t have internet access, the sender can lock the tokens to the receiver’s pubkey. Cashu’s Pay-to-Public-Key (P2PK) feature allows users to lock e-cash tokens to a receiver’s public key. Only the receiver’s private key can produce a valid signature to unlock the e-cash.

Let’s walk through an example from the documentation. When a receiver is offline, the sender constructs a transaction to pay to the offline receiver's public key. Then the sender forwards the transaction to the mint with the recipient’s public key embedded as a secret. The mint then provides a blind signature on that secret enforcing that the receiver is the only party that can unlock the funds. The sender takes this transaction, blind signed by the mint, and sends it over to the receiver who can uniquely produce a signature to unlock the E-cash tokens.

{
"amount": 1,
"secret": "[\"P2PK\",{\"nonce\":\"859d4935c4907062a6297cf4e663e2835d90d97ecdd510745d32f6816323a41f\",\"data\":\"0249098aa8b9d2fbec49ff8598feb17b592b986e62319a4fa488a3dc36387157a7\",\"tags\":[[\"sigflag\",\"SIG_INPUTS\"]]}]",
"C": "02698c4e2b5f9534cd0687d87513c759790cf829aa5739184a3e3735471fbda904",
"id": "009a1f293253e41e",
"witness": "{\"signatures\":[\"60f3c9b766770b46caac1d27e1ae6b77c8866ebaeba0b9489fe6a15a837eaa6fcd6eaa825499c72ac342983983fd3ba3a8a41f56677cc99ffd73da68b59e1383\"]}"
}

In the snippet above, we have an “amount”, a “secret”, a “C” or blind signature from the mint, “id”, and “witness” field.

The “amount” is the amount of e-cash being spent in the transaction. In this example we have a value of `1`, which would be 1 satoshi for a bitcoin-denominated note.

The “secret” is the receiver's public key.

When the sender sends the transaction to the mint, the mint produces a blind signature, that is stored in proof “C”. Only the recipient can produce a valid signature to unlock the funds sent to their public key.

Upon coming online, the receiver of the e-cash token produces a signature on the serialized string of data in “secret”, which is then added to the witness field.

In this example, the receiver is unsure if the blind signature in field C is actually a valid signature from the mint. To prove this, we can leverage DLEQ, or Discrete Log Equivalence, proofs for each signature. These proofs allow us to verify the mint’s signature belongs to the mint’s private key, without having to come online and verify the signature with the mint. The receiver can have confidence that the e-cash token she received is a valid token for the mint.

This example requires the sender to be online to send this P2PK transaction, as the mint needs to produce a blind signature that is locked to the recipient’s pubkey.

Example 2: Offline sender, online receiver

I made an error when reviewing the Cashu protocol specs. I assumed that a P2PK transaction could be constructed by an offline sender. This is false. Below is a revised example after discussions with Cashu contributors.

Can the reverse of this be true? Can we use the mint to enforce spending conditions of an offline transfer if the sender is offline?

The short answer is no. Senders cannot construct custom proofs offline. This means they can not construct a P2PK transaction that locks Ecash to a receiver’s pubkey, or split the denominations of their tokens, while in offline mode.

But, senders can still send tokens they hold client-side when they are offline. They take the token, send it to the receiver through an offline channel, and then the receiver is responsible for swapping it with the mint. After the receiver performs the swap with the mint, the transaction is considered finalized.

There is some trust involved. If the receiver doesn’t immediately redeem a new Ecash token with the mint, the sender could double spend them. So, in a scenario where the sender is offline, receivers should look to finalize the transaction as quickly as possible with the mint.

There’s a few other considerations

In both examples, one party needs to be online to finalize the payment. There are also some other considerations for offline payments:

• Users are restricted to the denominations held in their wallets. To split the denominations, you need to directly interact with the mint to create e-cash tokens of different amounts.

• Users can’t spend newly received tokens until they come back online and “melt” the tokens into their wallet balance.

• If the mint operator is also offline, we’re trusting that they have the necessary back ups to come back online.

• If the mint operator is offline, no transactions between peers can be finalized.

So is Cashu over Bitchat a permanent, “we’re offline for months” solution? Probably not. But in certain circumstances, sending E-cash tokens while offline is a viable option for parties who don’t have, or don’t want, access to the internet.

Example #1: I need to pay my friend for a beer at a concert but I have no cell signal cause there's 10000 people. He went to another stage with less people and had service. So I just message him an E-cash token worth a few thousand sats that he can finalize since he’s got some service.

Example #2: A hurricane just hit, and my family doesn’t have gas for our generator. I need to go into town to get some. I go into town, but I forgot the wallet on my phone doesn’t have any E-cash 🤦 So I open a chat with my wife, and the merchant, via Bitchat and have her forward the E-cash to the merchant directly. The gas station has power (their generator is on), so they are able to connect to WiFi. The payment gets finalized with the mint and added to the merchant’s wallet.

Either way, both of these exchanges can be communicated through Bitchat. No internet connection needed for the sender. And, since connecting through the bitchat mesh network is able to extend an offline party’s reach, there are dozens of other scenarios where an offline sender, or receiver, could use the Bitchat/Cashu combination to exchange value.

But we’re all friends and family here… would they really double-spend me?

There seems to be some misconceptions around whether one of the participants in an E-cash transaction needs to be online. Yesterday, I thought both parties could be offline. But after chatting with niftynei and Tuma, and looking through the protocol specifications, I was able to see that one of the parties needs to be connected to the mint to ensure that the transaction can finalize (as pointed out above).

Bitchat enables users to establish secure communication channels with people that they trust: friends, contracts, etc. If you’re communicating or transacting with parties that you trust, you can continue to transact while both parties are offline. As long as the e-cash tokens aren’t duplicated, they can theoretically be exchanged completely offline and redeemed, or melted, into a user’s wallet once reconnected without issues.

What if wallets embedded in the bitchat application allowed offline-to-offline payments between parties that have secure, verified connections with one another? You’d have to trust that each party’s bitchat app wasn’t saving copies of forwarded tokens, but it’d work.

In the hurricane example above, if neither the merchant nor I have an internet connection, we’d be able to use this fully-offline mode of bitchat to create a transaction for me to pay the merchant. The merchant then communicates with the mint when they regain an internet connection to claim the tokens.

The sender needs to be honest in this scenario and not double-spend the receiver if the sender comes online first. And, current wallets may not even allow sending unmelted notes. But if it can work, the example above could be a way for peers to transact, fully offline, in a trusted, communal environment.

Ack the tradeoffs, enjoy the ride, and hell, use it (if you want)

E-cash over Bitchat is a cool experiment. Offline payments are a huge unlock for E-cash, and the synergies with the Bitchat application are promising.

One of the participants in the transfer needs to be online. Through Bitchat’s networking capabilities, we can extend the range that the offline party has to make, or receive a payment. This a new frontier; not just for bitcoin, but for the broader payments application space as a whole.

There’s an explicit tradeoff that bearer tokens used in E-cash are not native bitcoin. We must follow the developers’ lead and continue to honestly tell users that the protocol is custodial. But using bitcoin off of the mainchain is always about tradeoffs.

Within certain circumstances, Bitchat and Chaumian E-cash can provide (maybe at times critical) temporary payments infrastructure. It’s also a user-experience improvement for those who simply don’t have (or want) an internet or cellular connection for a period of time. Offline mode payments would give them the freedom to transact off-chain in an open, albeit trusted, manner.

Cashu and Bitchat are not dependent on each other. Both solutions can continue to be developed and gain more adoption, completely irrespective of their counterparts' success.

But come on, the fact that someone sent an E-cash token through Bitchat makes a kid wonder about the future of fully offline payments.

And can you blame him?

Good afternoon subscribers! Last week, Peter Todd reported that F2Pool is now mining annex-containing transactions, which now brings the total number of known pools mining them to two, including MARA. Here’s a tl;dr on what an annex is and why it’s worth paying attention to. Got questions? Tag us in a tweet or post on Nostr, and we’ll get to answering it 🙂

What is an annex?

An annex on a house is an additional room for extra space or storage or another dining room. The taproot upgrade that went live in 2021 included an “annex” space, which is kind of like a data “attic” on a bitcoin transaction. Currently transactions that include annexes aren’t allowed to be relayed across the network, but if you include one in a block it’s valid.

Where is the annex in taproot?

It’s extra data in the witness stack. You put it at the end of the stack on a taproot spend. It’s unstructured data and practically unlimited in size. It’s only available for script path spends.

From BIP341:

The annex (or the lack thereof) is always covered by the signature and contributes to transaction weight, but is otherwise ignored during taproot validation.

What’s the annex for?

The annex’s use cases are unspecified which is to say there’s no rules or expectations of what to use it for. It’s basically a big data blob. The Taproot spec authors left it unspecified, but they also made including an annex non-standard. This means you can mine a transaction with an annex in a witness stack, but you can’t relay it across the normal mempool gossip network. This is where the F2Pool news comes in — you can send your annex transaction to them directly, and it’ll get included in a block.

The annex data is included in the signature for a taproot spend, so they have data security guarantees (no one can edit your annex data).

Who’s this useful for?

Anyone who wants witness discount “unlimited” data storage on bitcoin. Op-returns have a smaller stack limit (even when removing the 80-byte “datacarrier” limit, the maximum allowed for a bare script is 10k bytes[1]) and pay full price per byte. Annex data is a v1 taproot script. There is no limit on the size of v1 taproot witness scripts; instead you can’t exceed the blocksize limit of 4MB. Annex data is witness data, so it pays 25% of the fees the same data in an op-return or bare script would.

Another nice thing about using annexes for data is that it directly commits data into the chain, without needing to do the commit and reveal two-transactions step that the Ordinals Inscription protocol uses. It’s very similar to OP-RETURNs except it’s lower cost, allows for data up to the blocksize limit, and currently is not allowed to be relayed.

Should I use the Annex?

It is considered risky to add an annex to your transaction, as future softforks may add meaning to the data blobs in the annex, which may result in your funds being unspendable.

There’s a warning to this effect in the specification BIP341:

The annex is a reserved space for future extensions, such as indicating the validation costs of computationally expensive new opcodes in a way that is recognizable without knowing the scriptPubKey of the output being spent. Until the meaning of this field is defined by another softfork, users SHOULD NOT include annex in transactions, or it may lead to PERMANENT FUND LOSS.

I want to send a transaction with an annex. How can I do this?

Use Libre Relay, Peter Todd’s bitcoin-core client with less restrictive relay rules. As rot13maxi notes, however, you’ll need to set the first byte in the annex to 0x00. You can find the most recent Libre Relay code here.

Specific details about the annex can be found the Taproot BIP341:

[1] https://bitcoin.stackexchange.com/a/117595