This is a walk through what actually happened, at the level of the code. Which bugs existed, how they were exploited, and how an attacker managed to run away with 4000 Bitcoin.

What Liquid is, and how the peg works

Liquid is a federated sidechain to bitcoin. Instead of proof-of-work, eleven signatures are required to produce a valid block. These signatures are placed by the Liquid functionaries: around fifteen independent businesses running a specialized server, or HSM. The functionaries take turns to propose a block roughly every minute. As long as five functionaries remain honest, no invalid blocks can be produced.

The principal asset that circulates on Liquid is L-BTC, and it is meant to be backed one-to-one by bitcoin held in reserve. The reserve is held in a wallet managed by the same federation of 15 functionaries. Converting Bitcoin to L-BTC is a peg-in: you send Bitcoin to a federation-controlled address on the bitcoin mainchain, and, after enough confirmations, the same amount of L-BTC is credited to you in Liquid. Getting out is a peg-out: you destroy L-BTC on Liquid, and the federation releases the corresponding Bitcoin to you from reserve on the mainchain. Similarly, as long as five functionaries are honest, no one can take more money out of the system than they deserve. Or that was the idea.

Confidential transactions, confidential assets, and range proofs

On bitcoin, every output amount is public. On Liquid, amounts can be hidden. This feature is called Confidential Transactions. In a confidential transaction, the output amount field doesn’t hold a plain number. Instead, it carries a Pedersen commitment, or a curve point that binds the amount behind a blinding factor. The Pedersen commitment hides the amount while still supporting arithmetic. A verifier who cannot see any individual amount can still add up the input commitments, add up the output commitments, and check that the two sides balance. That is the balance proof, and it ensures transactions always have balanced inputs and outputs. In other words, the balance proof confirms that no new Bitcoin were created in the confidential transaction.

Confidential Assets extends the same idea to which asset an output holds, not just the amount. L-BTC, Tether USDt, and every other Liquid asset look alike in the blockchain; a per-output surjection proof ties each output’s asset back to the inputs.

Balance alone is not enough, and this is the crux of the whole incident. Pedersen commitments live in a finite group, so arithmetic wraps around in modulo. A commitment can encode a value so large it behaves like a negative number. If I am allowed to do that, I can build a transaction that balances on paper while minting money:

The thing that forbids this is the range proof. Every confidential output must carry a zero-knowledge proof that proves the hidden amounts lie in a sane, positive range and not in the wrap-around zone. Range proofs are what make hidden inflation impossible.

The cache

Range proofs are big — a few kilobytes each — and expensive to verify. Liquid nodes see the same proof more than once: once when a transaction arrives in the mempool, again when it appears in a block. Re-running the elliptic-curve verification every time is wasteful, so Elements remembers successful verifications in a cache. The idea is simple and, in bitcoin, entirely standard: verify a proof once, remember that this exact proof passed, and skip the math if you see it again.

A cache needs a key. For a signature or a proof, the key is a hash of everything the verification depended on. Get everything into the key and the cache is safe: two verifications collide only when they truly are the same check. Leave something out and you have a problem, because now two different checks can share a key and the cache will happily answer “already valid” for a check it never ran.

That single sentence is the entire vulnerability that got Liquid hacked. The details is which fields went missing, and when.

The 2018 cache key change

The original cache implementation was using an existing function that Bitcoin Core uses to cache transaction signatures. Due to an upstream change to that function, in commit 9572165, a custom cache key function is introduced for range proofs specifically. Here’s the relevant changes:

+    void ComputeEntry(uint256& entry, const std::vector<unsigned char>& proof, const std::vector<unsigned char>& commitment)

+    {

+        CSHA256().Write(nonce.begin(), nonce.size()).Write(proof.data(), proof.size()).Write(commitment.data(), commitment.size()).Finalize(entry.begin());

+    }

-    rangeProofCache.ComputeEntry(entry, uint256(), vchRangeProof, pubkey, vchAssetCommitment, scriptPubKey);

+    rangeProofCache.ComputeEntry(entry, vchRangeProof, vchValueCommitment);

The new cache key is SHA256(nonce || rangeproof || value-commitment). The asset commitment and the scriptPubKey, which were previously there, are gone. The verification function still received them and still verified against them, but the cache no longer remembered that it had. Two range proof checks with the same proof and the same value commitment, but a different asset or a different output script, now would hash to the same cache entry.

This design violates the requirement that all relevant fields for validation must be part of the cache key, so it’s definitely a bug. Let’s look at how it could be exploited.

If the value commitment was a Pedersen commitment to the value alone, it would require breaking the elliptic curve logarithm problem to create an identical commitment to a different value. That means that it is as hard as forging a bitcoin signature. However, because of how Confidential Transactions and Confidential Assets work, the value commitment that is used here, is actually made up of two parts: it contains a commitment to the value, but it’s also mixing in a asset-specific factor so that you can’t blend different assets.

The commitment contains an additional generator H that is calculated from the asset. Now, if we could invent a different asset with generator -H, we can create an identical value commitment for the same amount, but negative.

Choosing our own asset generator would also require breaking our crypto, but we don’t really have to. The validity of the asset generators is checked in what is called the asset “surjection proof”. But, this check only happens after the range proofs are checked. This means that I can just claim to have an output for asset generator -H and a value of 1 BTC. The rangeproof will pass and be stored in the cache. Afterwards, the surjection proof will fail and the transaction will be invalid.

But any node that actually validated this transaction, will have made an entry in its rangeproof cache and will now accept a rangeproof for -1 BTC under asset generator H which allows the same transaction to add an extra output for 1 BTC without having sufficient input value.

What this means in practice is that an attacker could cause inflation if he could make enough functionary nodes first validate (and reject!) an invalid transaction and then propose a block that has an inflationary transaction in it.

The Liquid network has some protections against this sort of behavior: users cannot send transactions directly to the functionaries. All transactions pass through “bridge nodes” that then relay them to the functionaries. While this protects the functionaries somewhat against outside attackers, it still means that anyone with privileged access to the inner network could have exploited this bug and confirmed an inflationary transaction.

Also, if for example a malicious functionary would perform this attack, the entire rest of the network would reject this block because they hadn’t seen the invalid tx preceding it. So while an inflationary exploit was possible, it was pretty hard to execute, would be noticed way faster and could only be performed by Liquid’s inner circle.

Why variable sized fields should always have a prefix

On 1 September 2026, five days before the attack, commit c26d719 fixes the 2018 bug by putting the missing fields like the asset commitment back into the cache key:

-void SignatureCache::ComputeEntryRangeProof(uint256& entry, const std::vector<unsigned char>& proof, const std::vector<unsigned char>& commitment) const {

+void SignatureCache::ComputeEntryRangeProof(uint256& entry, const std::vector<unsigned char>& proof, const std::vector<unsigned char>& commitment, const std::vector<unsigned char>& asset_commitment, const CScript& scriptPubKey) const {

     CSHA256 hasher = m_salted_hasher_range_proof;

-    hasher.Write(proof.data(), proof.size()).Write(commitment.data(), commitment.size()).Finalize(entry.begin());

+    hasher.Write(proof.data(), proof.size()).Write(commitment.data(), commitment.size()).Write(asset_commitment.data(), asset_commitment.size()).Write(scriptPubKey.data(), scriptPubKey.size()).Finalize(entry.begin());

 }

Read that Write chain carefully. The key is now:

SHA256( nonce || proof || commitment || asset_commitment || scriptPubKey )

All four fields are present, which looks like exactly what you want. I wrote above that in the old key, only the range proof field was of variable length, and that’s why a collision could only happen for exactly the same range proof and value commitment. In this new cache key, two fields are of variable length and they are hashed without having a length prefix.

When you glue variable-length fields together without length prefixes, the boundaries between them stop being meaningful. Only the total byte string matters. If I can make the proof longer by the same number of bytes that I make the script shorter, and arrange the bytes in between them to line up, I can produce an identical concatenation for a completely different (proof, commitment, asset, script) tuple.

This implementation lets you create two identical cache keys for a different amount, asset, and script. If you can get a Liquid node to first parse a valid transaction and then an invalid one with a junk proof and a forged amount, but that is carefully crafted so that the cache key for this transaction matches exactly with the cache key of the first one, it won’t even validate the range proof because you convinced it that it has already done that before.

This is a commonly known pitfall in cryptography. Hashing structured data by raw concatenation is unsafe precisely because distinct structures can share a byte encoding. The 2016 signature cache in bitcoin gets away with concatenation because its fields are all fixed length. The moment two variable-length fields sit next to each other, concatenation is a trap.

I remember from my time at Blockstream that whenever we would introduce any new consensus-critical serialization, we would ask Russell O’Connor to review it. Russell has the reputation as the expert in spotting this kind of byte-shifting vulnerabilities.

Here is the field layout, from a diagram mononautical, an engineer at Mempool.space, made while going through the same rabbit hole. The cache key is proof | amount | asset | script. Feed it a genuine “primer” and a crafted “exploit” and the two produce the same 4,301 bytes with the field boundaries in different places:

How to print 4000 L-BTC

The exploit ran in two steps, exactly as the layout predicts. I pulled the raw transactions from the explorer and reconstructed the cache keys byte for byte.

Step one, the primer. In Liquid block 4,050,335 the attacker published two nearly identical transactions: 27117… and 71c93d. Note that just one transaction would have sufficed. The second is presumably insurance.

Each has an output that is an OP_RETURN carrying a genuine, valid range proof, 4,166 bytes, verifiable in its own right. The clever part is the script on that output. It is a 69-byte OP_RETURN whose pushed data is not random: it embeds, byte for byte, the value commitment, asset generator and script head that the second transaction will need. When a node verifies this proof, it computes the cache key over proof || commitment || asset || script and stores a success. The primer’s only job is to plant that entry.

Step two, the exploit. One block later, in 4,050,336, transaction f24a4b… creates an output whose “range proof” is 4,234 bytes that would never pass as a valid range proof. But those 4,234 bytes are not random either: they are the primer’s 4,166-byte proof, followed by the primer’s 33-byte commitment, followed by the 33-byte asset generator, followed by the two script-header bytes 6a 43. In other words, the exploit’s proof field has swallowed the primer’s proof, commitment, asset and script-head. The exploit’s own commitment, asset and a one-byte 6a (OP_RETURN) script then follow in their proper places, as they were encoded in the primer’s OP_RETURN data.

Line up the two cache-key preimages and they are the same string:

primer:   <4166B proof> | <33B comm> | <33B asset> | < 2B head> | <33B comm> | <33B asset> | <1B script>

                                                     └───────────────── 69B script ────────────────────┘

exploit:  <4166B proof> | <33B comm> | <33B asset> | < 2B head> | <33B comm> | <33B asset> | <1B script>

          └───────────────── 4234B “proof” ───────────────────┘

The exploit’s forged output collides with the primer’s cache entry, so the range proof checker short-circuits to “valid” and never looks at the invalid proof. That output hides a massive overflowing amount (the “negative” output from the balance-attack sketch earlier) and a sibling output credits the attacker with a large positive amount. The balance proof, which is real and which the attacker cannot fake, sums to zero. The range proof, which should have stopped it, was answered from cache.

The chain split

Interestingly, the attack did not fool most of the Liquid network. It only fooled nodes whose cache had been poisoned, and because the commit that introduced the buggy fix had not been included in an official Elements release yet, most of the network was not running this version of the Liquid node software. It looks like the Liquid federation decided to first deploy this bugfix release to the internal Liquid infrastructure. This is a common thing to do when deploying security fixes.

But it meant that most of the network actually rejected the attacker’s transaction. They didn’t have the cache key change, so no cache hit and they actually validated the range proof and rejected the transaction, as well as the block that the transaction was relayed in.

These nodes stalled at height 4,050,335: the last block before the exploit. The nodes running the vulnerable build, including the federation’s bridge nodes, accepted 4,050,336 and kept going.

You can still watch this split today. Blockstream’s explorer, blockstream.info, sits above height 4,051,000. mempool.space’s Liquid node, liquid.network, is frozen at exactly 4,050,335.

OrangeSurf published the reproduction recipe: run a build that includes the vulnerable commit, invalidateblock 4050335 to push the primer back into the mempool so the poisoned key gets re-inserted, then reconsiderblock and your node reorgs onto the federation’s inflated chain.

Out the front door: PAK and SideSwap

Inflating L-BTC is only half a heist. The attacker still had to convert unbacked L-BTC into real BTC, and Liquid does not let just anyone pull from the reserve. Peg-outs are gated by PAK, the Pegout Authorization Key system. Each peg-out output must carry a whitelist proof tying the destination to a registered key belonging to a trusted federation member. A peg-out to an unauthorized key is simply invalid as per Liquid’s consensus rules.

So the attacker needed a PAK holder to peg the coins out for them. Enter SideSwap, a Liquid member that runs a peg-out pass-through service: you send it L-BTC, it peg-outs under its own PAK key, and it forwards the resulting BTC to whatever mainchain address you give it. This is a useful product. It is also a good way to render the entire PAK system pointless.

In Liquid block 4,050,349, thirteen blocks after the exploit, the coins were pegged out. On the bitcoin side the federation released the reserve as designed: roughly 3,996 BTC landed at SideSwap’s whitelisted address bc1qgslsydz56d0ed6827hdemfmk5w2f6ldyc6wt7p, which forwarded it on to the attacker’s address bc1ql4mfu6aundtkksxklfajs2h3t9nzcd6gyqjlte.

Because the balance and PAK checks all passed, SideSwap’s node and every functionary treated it as an ordinary authorized withdrawal. Liquid’s own incident report confirms the shape: the validation failure was at the transaction level, before the peg-out, so nothing downstream had reason to object.

The part that should give every system designer pause: neither the peg-out mechanism nor SideSwap had either a built-in time delay or an upper limit on amounts. A single transaction that moved on the order of 4,000 BTC, roughly 400M USD at the time, went straight through: no waiting, no manual review, no velocity check. Before the incident the reserve held about 4,205 BTC. Nothing was in place to prevent 95% of that from leaving the system in about half an hour.

The white hat and the negotiation

Then the story takes a very unexpected turn. Bitcoin heists like this usually are followed by total silence in which the funds stay put, or by transactions showing the attacker is trying to obfuscate his trails and white-wash the coins.

Instead, a few hours after the drain, with a transaction paying 1,000 sats to the federation wallet, the attacker left a note in an OP_RETURN:

> we are whitehats. contact us on chain

Blockstream replied from a known address: “Please contact security@blockstream.com”, then an encrypted message signed with their security key. The attacker agrees to send the funds back to the federation address but demands the bug be fixed first:

> Please fix the bug first. The chain is under risk at latest commit right now. Make sure every node is patched. Then we will transfer the money back safely after confirming the fix.

Blockstream clear-signed ”Yes, thank you,” and later ”Bridge nodes are patched, safe to return the funds.”

On 7 September at 16:09 UTC, the attacker returned exactly 3,400 BTC to the federation’s wallet and kept about 598.5 Bitcoin (roughly 15%) in his own wallet.

That 15% was not an accident, and the tone did not stay collegial. In a later message the attacker dropped his white-hat pose entirely:

Your dereliction of duty is obvious that you allocated only $1.5M (maybe even 0) to secure $5B assets. […] You SHALL pay 10% using your own money as bug bounty or you will cause all your holders a 15% loss for your irresponsibility and stinginess. […] Anyway we are going to publish the private key to decrypt our conversations afterwards.

Whatever you call someone who drains a chain, pegs it out through an unwitting third party, and then negotiates a bounty under threat, “white hat” is not a term I would use. As of writing, Liquid is still paused, the 3,400 BTC is back, and roughly 598 BTC is outstanding while the two sides argue over the difference.

The whole exchange is visible on the bitcoin mainchain, signed and verifiable; Sjors published a script and transcript, that checks the PGP signatures against Blockstream’s published key, and there is a readable viewer where you can follow the entire conversation live.

The real fix, and what it teaches

The actual repair got shipped, as part of Elements release v23.3.4. It stops hashing the cache-key fields by raw concatenation and serializes them through CHashWriter instead, which length-prefixes every field. Once each variable-length field is preceded by its length, the byte-shift trick is dead: a longer proof and a shorter script no longer produce the same encoding, because the lengths themselves are part of the hash. The release also adds a -norangeproofcache switch to turn the cache off entirely.

There are a few lessons here, and none of them are exotic.

A cache key is a security boundary. The instant a verification result is memoized, the key that identifies it inherits the full weight of the check it replaces. Leave a field out and you have silently widened what counts as “the same”.

Simple concatenation is not safe serialization. Gluing variable-length fields together without lengths or safe delimiters is a canonicalization bug waiting for someone with creativity to find a way to abuse it.

Fixes deserve the same fear as features, especially security fixes under time pressure. The recent change was trying to make the key correct and ended up breaking it instead. The dangerous edit was the one that looked like a patch.

And, finally, defense in depth is not optional at the money layer. Bugs happen to all of us, but the loss was 4,000 BTC because a single peg-out with no limit could carry the entire reserve out in half an hour. The consensus bug is fixed. The question of why the pegouts have no delay and no ceiling is the one Blockstream and SideSwap still have to answer.

bitcoin++ Insiders Edition will be in Berlin, this coming October 1 — 3 at the upcoming payments edition bitcoin++ conference. Join us for three days of hacking, talks, and hands-on workshops. Use code INSIDER for 20% off a ticket.

Introduction

It’s 2034 and mid-day on a Thursday. Your mom just called, she needs some urgent help paying a ransom to get access to her emails and bank passwords — someone’s locked her computer. You go to find your hardware wallet only to discover that your dog just destroyed your ‘primary’ signing device. Luckily, you moved your funds back in 2028 to a new key format that Blockstream Research launched in 2026, SHRIMPS, which will let you use your backup key to sign for your funds without a problem and without spending all the available balance for fees.

Backing up wallet state is a big issue for post-quantum hash-based signatures. Blockstream Research’s latest update is a push in the direction of better, stateless backups without giving up gains in conserving blockspace.

The previous Blockstream Research post-quantum signature scheme was reported on by Insider Edition. Our deep dive on SHRINCS, a quantum-resistant scheme combining both stateful and stateless hash-based signatures shows how stateful and stateless schemes can be combined in a single signature. Stateful schemes allow for smaller signatures, at the cost of needing to keep track of which signatures have been already used (this is the ‘state’ you’re tracking).

If the record of what signatures have already been made is lost, like in our opening horror story, you can no longer use the keys without risking compromising their security, which would allow someone else to move your funds.

On the other hand, we have stateless signing schemes. These can be easily restored from a static backup such as a seed phrase, but the signatures they produce are quite large — you trade cheap onchain signatures for a guarantee of being able to use it if lose your device.

SHRINCS, Blockstream Research’s first post-quantum (PQ) signature proposal, fuses a stateful and stateless scheme to give you the best of both worlds. The combined signature scheme uses the stateful scheme which produces smaller signatures for ordinary operations, but falls back to the stateless, more expensive signatures, if your signing history is lost. SHRINCS’s stateless signing mode removes the risk of producing weak or forgeable signatures from lost state, while allowing you to benefit from smaller, stateful signatures in the default case.

On March 27th, Director of Blockstream Research Jonas Nick introduced a new scheme called SHRIMPS on the popular technical forum, Delving Bitcoin. SHRIMPS is another PQ signature scheme proposal. As a product of one of Bitcoin’s most experienced research labs, it aims to improve on the earlier SHRINCS proposal.

By default, a SHRINCS backup signing device would default to using the stateless signing mechanism. In this case, your keys lose the ability to produce smaller signatures, moving from 324 bytes per signature to up to 8KB, a 25x increase in on-chain weight. This is problematic, given that you pay for every byte used in a bitcoin transaction. Backup signing devices, if used, would produce 25x more expensive transactions.

SHRIMPS, the latest proposal, aims to optimize the fallback option of SHRINCS. Instead of having a single fallback option, SHRIMPS would allow user’s backup devices to sign in a compact form until a threshold number of signatures is reached, and only once the limit on smaller signatures is reached, falling back to the more expensive, larger signature signing option.

Basics of SHRIMPS

The construction of SHRIMPS combines two instances of SPHINCS+, a stateless hash-based PQ signature scheme. SPHINCS+ is complex. It’s constructed using several WOTS+ and XMSS nested trees to produce a single quantum safe key-pair. A SPHINCS+ key-pair can be used to sign many messages safely.

The depth of navigating the SPHINCS+ hash tree to locate the public/private key is what contributes to the large size of SPHINCS+ stateless signatures. The statelessness comes from the low probability of ever picking the same path in the tree again, at random. However, there is an upper bound to how many signatures can be produced in a SPHINCS+ tree before the odds of picking the same path again goes above what is considered ‘safe’.

In the SPHINCS+ literature, q_sis this upper limit. It’s the bound on the number of signatures that can be securely produced under a single SPHINCS+ key tree. q_s also governs the depth of the nested SPHINCS+ trees. So a smaller q_s means smaller resulting signatures, as it takes less data to describe the path through the SPHINCS+ forest. A smaller tree means less signatures that can be safely produced, but also less data per signature.

SHRIMPS uses this q_s to create two different SPHINCS+ key trees, and then binds them together into a single key, which can sign using either of the two SPHINCS+ trees. The trees only differ on the value of their q_s parameter: The first instance, referred to as compact path, uses a low q_s, which allows for smaller, but very limited number of signatures; the second instance uses a larger q_s. It produces much larger signatures, but can sign an almost infinite number of times.

Since both options are using SPHINCS+, both tree options are independently stateless. Unlike in SHRINCS where on one path you must remember what you’ve signed, SHRIMPS’ paths only need to remember how many times the lower-bound SPHINCS+ tree has been used.

According to Nick, for the compact instance q_s = 2^10 would be a good, conservative bound — providing around 1024 signatures —, while the fallback instance should be implemented with a sufficiently large parameter, such as q_s = 2^40 or q_s = 2^64 — an upper bound of around 1.85 x 10^19 signatures.

The SHRIMPS public key p_k is the hash of the public keys of each of the two SPHINCS+ treesets. A signature consists of a SPHINCS+ signature under the chosen instance s_k1 and the public key of the other p_k2. The verifier reconstructs the signing instance’s public key p_k1 from the SPHINCS+ signature, hashes p_k1 and p_k2 to reconstruct the combined public key, and compares it to the known SHRIMPS public key, p_k.

When initializing a new device by providing a seed, it will deterministically derive keys for each of the two SPHINCS+ instances. Each device will have its own, independent, persistent state to check whether the compact path has already been used or not.

How Many Signatures?

Assuming that the compact signature can be used to sign at most once for every device, q_s basically becomes the upper limit to the number of devices that could be initialized, n_dev. Setting q_s = n_dev = 2^10 means giving the user the possibility to initialize more than one thousand devices, which seems a lot, even in the most pessimistic cases. Hopefully, no one would lose access or break a device more than one thousand times!

The “budget” could also be expanded to provide each device with more than one compact-path signature to be used. For example, setting n_devsigs = 2^4 would provide the possibility to sign 16 times with the compact instance with each device, nevertheless resulting in a signature smaller than 3KB. In this case, the parameter would be set to q_s = n_dev x n_devsigs .

As we said, each device needs to store an independent counter to decide whether to use the compact signature or not. The counter will be log2⁡(n_devsigs + 1) bits in size, depending on the number of signatures available for each device.

In the simplest case — one device, one compact signature — the signing flow would require to check whether the independent, single-bit counter is 0 or 1. In the first case, the device will sign using the compact SPHINCS+, resulting in a 2.5KB signature at 128bit security. Otherwise, it falls back to the larger instance. In case n_devsigs > 1 , the device will be able to use the compact signatures several time until exhaustion — 16, in case n_devsigs = 2^4.

If the number of compact-path signatures exceeds the q_s budget, security does not break down immediately. Instead, it degrades gradually, as the the table provided by Nick clearly shows. With a budget set to q_s = 2 ^10 , the security of the scheme is 128.0 bits. Using 2^11 signatures doesn’t degrade security, which only start to drop tp 125.1 bits when signing with the compact scheme 2^12 times (i.e. 4 times the available budget).

Putting it all together

As previously said, the aim of SHRIMPS is to improve on the stateful scheme side of SHRINCS to provide a safe path towards funds recovery. When using SHRINCS, if a single signing device is lost, the scheme allows the user to recover its keys using a static backup. However, it will default to use the heavy stateless scheme as soon as the state for the smaller signature scheme is lost.

SHRIMPS provides an intermediate step between the lean stateful signatures (324 bytes) and the huge stateless ones (~8KB), by allowing for a series of devices, each which can track their state independently and produce smaller SPHINCS+ signatures until the counter expires.

Putting together SHRINCS and SHRIMPS would result in the following workflow:

• The first device is initialized, and the stateful scheme is used to sign any transaction. The stateful scheme is used until the state is known, to avoid breaking the cryptographic assumptions of the scheme. Each signature is 324bytes in size.

• Once the state is lost (i.e. first device is no more usable), a new device is initialized. The compact SPHINCS+ instance is used to sign until the budget n_devsig for the device is reached. Each signature is ~2.5KB in size.

• When the whole budget has been drained, the SPHINCS+ with the larger q_s parameter, and thus larger signatures, is used. Each signature would be between ~4KB and ~8KB depending on the exact parameters chosen, but the number of signatures available is high enough to allow for practically unlimited signing.

In the following table, we can see the size of the signatures produces by the different algorithms:

Post-quantum Bitcoin is Moving

Brink recently announced that they had hired quantum cryptography researcher Conduition, to focus on making Bitcoin quantum-secure. His main area of focus will be to make SHRINCS a reality, providing a usable protocol and draft BIP for the signature scheme. This seems to point to the fact that SHRINCS could be a viable solution in a post-quantum future. Building upon this protocol, thus, follows a natural course. SHRIMPS is another clever solution to improve the UX of post-quantum signatures even more.

And earlier this month, following the rash of LLM powered attacks on existing Bitcoin infrastructure, Jonas Nick announced a preliminary C library — libshrincs. It is a handwritten C library implementing WOTS+C, the one-time signature used by SHRINCS for the stateful signing path.

On August 27th Jonas Nick also announced the publication of BIP SHRINCS, the draft proposal specifying all the underlying cryptography needed for the scheme to work. While using SHRINCS in Bitcoin Script would require a separate BIP, this proposal defines the design choices, new parameter set, and improvement on top of the original proposal. The BIP is up for debate and the SHRINCS working group — composed by Conduition, Mike Casey, Ethan Heilman, Remix, Boris Nagaev, Mikhail Kudinov, Oleksandr Kurbatov, and Nick himself— is waiting for feedback on the proposal.

Research on post-quantum signature for scarce resource environments is still at the beginning, but the ball is already moving. Improving on the small signatures, and fallback in case of state loss is another step towards a better experience using Bitcoin securely and cheaply in a post-quantum world.

Intro

I began investigating the Coldcard hack and was immediately shocked. I need to explain why.

When we developers work on code, we organize or code changes into changesets we call “commits.” The purpose of doing so is to show a clear history of what code was changed including why and how.

This is done precisely for instances like this where it appears Bitcoiner’s funds are being stolen en masse, so we can investigate and understand exactly how it could happen.

Good developers write clear commit messages, written notes that go along with the code changes that explain what the specific change is accomplishing.

To make a clear commit message, you typically want to the commit to represent a smaller change of code, so there’s less to comment on.

A good goal as a developer is a high commit message to change ratio. The more lines of code that you change, the more comments explaining why you’re changing the code. More message and less code changes per commit is generally a good idea.

Here is an example chosen randomly from some of my own work.

The commit message is 235 characters, and the commit changes 15 lines of code. That’s a ratio of 235/15 = ~16.

In the cold card, the commit that introduced the low entropy bug is here.

The commit message is 5 characters and is simply the word “runs.” The commit changes 1534 lines of code making the ratio 5/1534 = ~0.003

This is an atrociously bad comment to code change ratio.

There are some rare instances where a low comment ratio is justifiable -- but changing the most important part of the code is not one of those cases!

Code that touches functions critical to the security of the project need to have a higher ratio of comments to changes and more stringent review.

The second commit contributing to the weak entropy issue on Coldcards is here.

The commit message is 1 character: simply the character “x.” The commit changes ~1000 lines of code making the ratio 1/1000 = ~0.001

The Issue

In the commit titled “runs” (ratio: ~0.003), it appears they are importing and configuring C code to make custom micropython code work on the STM32, the board that all Coldcards run on.

STM32 is the most common CPU for small devices like this, and configurations like what this commit introduces are common.

In the ‘runs’ commit, the hardware RNG (Random Number Generation) was disabled with the following line of code.

#define MICROPY_HW_ENABLE_RNG (0)

This is what caused the bug. Setting this value to zero tells the default micropython rng code to not use the hardware RNG device and that it should use the Yasmarang RNG instead.

The developer added an inline comment “explaining” this change

// We have our own version of this code.

The COLDCARD version of this code appears to be in reference to the functions added in rng.h and rng.c

rng.h

MP_DECLARE_CONST_FUN_OBJ_0(pyb_rng_get_obj);

MP_DECLARE_CONST_FUN_OBJ_1(pyb_rng_get_bytes_obj);

These appear to be an attempt to override the stm32 rng library’s `pyb_rng_getobj` function. This approach ran into trouble. The stm32 rng.c file already defines the pyb_rng_et_obj variable and sets the value to `pyb_mg_get`. You can’t have two definitions of the same variable and have it compile.

rng.c

MP_DEFINE_CONST_FUN_OBJ_0(pyb_rng_get_obj, pyb_rng_get);

Expanding the macro and thinking of it logically is just this pseudocode:

var pyb_rng_get_obj = pyb_rng_get

Commit `37e4af5` adds a custom rng.c file, where he copy pasted the same macro definition

MP_DEFINE_CONST_FUN_OBJ_0(pyb_rng_get_obj, pyb_rng_get);

There is now no way for this code to compile. It appears that the developer is naively trying to override the `pyb_rng_get_obj` variable by creating a duplicate version of the variable. C does not work this way. This error would have given him a compiler error of “duplicate symbol pyb_rng_get_obj, because there are now two places where it is defined: the stm32 library, and in the newly added rng.c file.

From here, I assume in a bout of frustration, he set `MICROPY_HW_ENABLE_RNG` to 0, which would have resolved the compiler error.

Sometimes when developers are flailing, they’ll try random things to see if it helps. Setting `MICROPY_HW_ENABLE_RNG to 0 would have made the compiler error go away ***for the wrong reason***.

This swept the compiler error of having two conflicting definitions under the rug.

// We have our own version of this code.

#define MICROPY_HW_ENABLE_RNG (0)

Setting MICROPY_HW_ENABLE_RNG to zero completely removed the code that used the hardware random number generator, or lines 31 to 80 in the stm32 rng.c file. This had the side effect of removing the second definition of pyb_rng_get_obj, which “fixed” the compiler error.

The compiler error was begging the programmer to reconsider his logic. Instead of that happening, the compiler error was just silenced. The compiler was giving the developer one last chance to reconsider what he was about to do, but the alarm was ignored and silenced.

Now everything is lining up. It looks like the developer tried to override the variable, but ran into conflicting definitions. When confronted with a “duplicate symbol” error, tried changing random things to get the code to run.

He discovered that changing `MICROPY_HW_ENABLE_RNG` to 0 made it compile. He probably had no idea why but came up with a theory. We don’t need that anymore because we have our own version of the code.

His definitions of the pyb_rng_get were in place, and the code he was intending not to run had been turned off.

Confusing Call Chains

Coldcard’s firmware is written in C. The application layer, that tells the hardware what to do is written in Python. The Python code calls into the C code. The developer overwrote the pyb_rng_get functions.

Unfortunately for many, the pyb_rng_get functions that his code overwrote weren’t what is actually called from the python code. The Python code in v4.0.0 of the Coldcard calls random.bytes() in their make_new_wallet() function.


async def make_new_wallet():

await ux_dramatic_pause(’Generating...’, 4)

seed = random.bytes(32) # OOPS

assert len(set(seed)) > 4

seed = ngu.hash.sha256s(seed)

await approve_word_list(seed)

Setting `MICROPY_HW_ENABLE_RNG` to 0 turned off the stm32 library provided hardware code, but allowed the developer to set `pyb_rng_get_obj`. Problem is, pyb_rng_get_obj is the Python-visible pyb.rng() callable.

That’s not what the developer is invoking here in the wallet function. Instead, they’re using `random.bytes(32)` which skips the pyb_rng_get callpath entirely and instead calls `rng_get`, which due to the `MICROPY_HW_ENABLE_RNG` being set to zero used the micropython stm32 rng.c definition at L112, which called the insecure Yasmarang, non hardware wallet entropy.

uint32_t rng_get(void) {

return pyb_rng_yasmarang();

}

Simply put: the firmware change overwrites functions that aren’t used when creating a new wallet while, as a side effect of including the python method overrides, turns off the hardware RNG usage in every case, instead using a very weak random number generator.

The final bit of evidence is the commit message itself. It was simply the message “runs.”

Developers, if you are ever in this scenario, please stop. Whatever you’re getting paid is not worth the devastation you might potentially cause for others.

Do not ship code you do not understand.

A curse on micropython

At the core this appears to be a consequence of too many layers of complexity. There’s the micropython library, the bindings between the C code and the Python application, and the new functions that COLDCARD is adding. Was the developer that made this patch actually a python developer who was forced to write and handle C?

Micropython creates the illusion embedded developers do not need to understand C, their CPU, or other advanced concepts to do embedded programming.

That is a lie.

And this catastrophe is the result of believing that lie.

You must understand the code you are shipping. Full stop. There are no excuses. Layers of misdirection make it harder to understand.

If you make changes, make sure that you verify that they are doing what you intend them to do.

The commit messages here tell the real story. Treating the most critical part of your code with the lack of diligence and understanding shown here is inexcusable.

You, as a developer working on Bitcoin, need to take your time to understand your changes, document them clearly, and verify they do what you think.

When people’s lives are ruined, they won’t and shouldn’t give you sympathy. You need to appreciate the funds you are putting at risk. Your task as a bitcoin developer is of the highest importance. I have made mistakes myself in the past, but there are no excuses for a failure to understand what you are shipping when the code is this critical.

I hope that we, as an industry, can learn from this and lean on each other to ship secure code, as a community of developers.

On March 3rd, Blockstream Research demonstrated the use of post-quantum (PQ) signatures on the Liquid Network, the Blockstream powered federated sidechain. Researchers Oleksandr Kurbatov, Viktor Mashtaliar, Dmytrii Kurbatov, Mikhail Kudinov, and stringhandler were able to sign a real Liquid mainnet transaction leveraging Simplicity, Blockstream’s smart contract language, and its capacity to express custom, complex spending conditions to demonstrate what one potential quantum safe signature scheme might look like.

The scheme used for this test transaction was another produce of Blockstream Research: a hash-based algorithm called SHRINCS.

First presented by Director of Research Jonas Nick and cryptography researcher Mikhail Kudinov in December 2025, SHRINCS combines both stateful and stateless hash schemes, attempting to leverage the benefits of stateless signing while reducing the onchain footprint.

Before diving into the technical details, let’s take a moment to define the difference between stateful and stateless cryptographic signatures, highlighting the corresponding trade-offs.

Stateful and Stateless

Stateful hash-based signature schemes, such as XMSS, rely on so-called One-Time Signatures (OTS), where each key-pair must be used exactly once. Reusing a key means breaking the security fundamentals of the cryptographic scheme, allowing attackers to forge signatures and potentially steal funds. Thus, it is crucial to keep track of which keys have already been used (a.k.a. the state) to avoid compromising the funds. This means updating the state after each signature, so that we keep track of which keys have already been used. Holding onto this state introduces a layer of complexity in keys management, making static backups, or ones that aren’t updated after every use, de facto dangerous. Currently, you can find all of your funds from 12 seed words, and can sign for any key under those words without worrying about saving any additional information. A stateful scheme would mean you wouldn’t be able to do this without possibly leaking information and losing funds.

Despite their need to remember every signature, stateful schemes produce smaller size signatures, and require minimal computational effort for verification. The smaller size makes them attractive, particularly when compared to stateless signature schemes.

On the other hand, stateless signature schemes do not need to keep track of which keys have been used, making key management as simple as remembering a static backup, similar to how 12-words work today. The same key-pair can be used multiple times without compromising the safety assumptions behind it. To achieve this, stateless schemes make use of massive, multi-layered trees, which create a pool of possible signatures so large that makes the possibility of using the same key twice statistically irrelevant. As you may have already guessed, this comes at the price of way larger signatures than stateful schemes and a higher computational cost for verification.

SHRINCS: An Hybrid Approach

SHRINCS combines stateful and stateless signature schemes, attempting to take advantage of the strengths of each while mitigating their specific limitations. Specifically, SHRINCS leverages the efficiency in size and verification of a stateful scheme, while allowing users to easily recover their keys and safeguard their funds with a stateless counterpart in case the state is lost.

To achieve this, SHRINCS is built using both a stateless scheme (SPHINCS+) and a stateful scheme (Unbalanced XMSS).

During normal operation, SHRINCS uses the stateful unbalanced XMSS tree, producing a 324 bytes signature, a tiny signature compared to most other PQ signature proposals. The state is updated every time a message is signed and is securely stored, to be sure not to reuse the same key twice.

What happens if we need to restore our keys? As we said, it is not possible to recover a key from a stateful scheme with a static backup, since it would result in compromised security and possible loss of funds. If the state of the keys is ever lost, SHRINCS can fallback to the SPHINCS+ stateless signature scheme instead. Signature size will explode, reaching up to 8KB, but the funds aren’t at risk of being lost or stolen.

Unbalanced XMSS of WOTS

SHRINCS uses a stateful scheme based on an unbalanced XMSS tree of OTSs. This is basically a Merkle tree where each leaves represent an OTS.

To sign, the algorithm chooses a new OTS based on the current state, signs the message, and updates the state to signal that the chosen key should never be used again.

To verify a signature, we have to demonstrate that the OTS we are using belongs to the tree. Thus, the whole authentication path (a.k.a. the Merkle path) need to be provided together with the signature, which requires storing every hash of each sibling node up to the root.

To speed things up, SHRINCS uses an unbalanced tree, which results in a smaller authentication path and, as a consequence, smaller signatures. Moreover, the tree being unbalanced helps simplifying state tracking, since it basically matches the height of the Merkle tree.

The following image helps clarifying this concept. For the first signature, WOTS_1 will be used. The authentication path will be composed only by WOTS_1 sibling hash, while state = 1 . After use, the state will be updated to state = 2 , signaling the algorithm that the next signature would have to use WOTS_2.

To dive deeper in the chosen scheme, let’s analyze each component:

• WOTS+C: WOTS is considered the state of the art and the basis for more complex schemes. It is an hash-based signature function and, as the name suggests, a given key pair cannot be used twice. In particular, SHRINCS leverages an extension of WOTS+, called WOTS+C (which stands for “Compact”), which presents reduced signature size.

• eXtended Merkle Signature Scheme (XMSS) Tree: It is a hash-based signature scheme that combines OTS with a Merkle tree. Each OTS key represents a leaf in the binary tree, which has a predefined height h . The internal nodes of the tree represent the hashes of its children, while the root acts as the global public key. To verify an OTS signature, the authentication path (i.e. the Merkle proof, the sequence of sibling nodes from the chosen leaf up to the root) must be computed.

• Unbalanced Tree: Instead of having all the OTS at the same depth h as in a balanced tree, an unbalanced one allows to minimize the authentication path for the early signatures. In fact, the first OTS will have heigth = 1 , the second one heigth = 2 , and so on, strongly reducing the Merkle proof.

Putting this all together, we obtain the stateful scheme for SHRINCS.

SPHINCS+

The chosen scheme for stateless signing is SPHINCS+, or, as the author suggests, a variant of it.

SPHINCS+ is a complex signature scheme, built using several layers of post-quantum signature utilities, such as WOTSs, Forests Of Random Subsets (FORS), and XMSSs. When combined, SPHINCS+ produces a single quantum safe key-pair which can be used to sign many messages safely. Unlike XMSS, the algorithm doesn’t need to remember anything about prior signatures made with the key-pair for any subsequent signatures. One SPHINCS+ structure produces a single pubkey that can safely sign many messages without revealing the secret key.

This can be achieved because the final structure is huge, and the possibility to choose the same key twice is statistically irrelevant. Of course, this results in heavy signatures compared to those produced by stateful schemes, making them less practical for use in a system with limited space (like blocks).

If you want to know more about this PQ signing scheme, refer to this amazing article by Nifty.

Putting It All Together

To implement SHRINCS, there are four functions that are required: KeyGen, which sets up the initial SHRINCs structure with an Unbalanced XMSS and SPHINCS+ sub-pyramids and returns the top-level public key; Restore, which, given the seed, returns the same public key as KeyGen, and marks the state as LOST; Sign, which returns a valid signature for a message using one of the two sub-schemes (Unbalanced XMSS or SPHINCS+). If the state has been marked as LOST via a call to Restore, it uses SPHINCS+, otherwise, it signs using the Unbalanced XMSS tree. And finally, Verify, which takes a pubkey, a message, and a signature and returns true if the signature verifies, or false if not.

Most signature schemes include a KeyGen, Sign, and Verify methods; Restore is uncommon, as it marks which of the two internal schemes to use.

As outlined by Nick in the Delving post, here’s a more in-depth explanation of how each of the four functions work:

• KeyGen() : The algorithm creates a master seed and derives two secret keys, one for the stateful scheme, sk_1, and one for the stateless, sk_2. From these, the function derives the two public keys, pk_1 and pk_2. The SHRINCS public key is the hash of pk_1 and pk_2 , such that pk = H(pk_1, pk_2) . In the end, the function return the master seed , the master public key pk , and the initial state of the stateful scheme.

• Restore(seed) : This function is responsible for recovering the keys and for setting the state to LOST to signal that the stateful scheme cannot be used anymore.

• Sign(seed, state, m) : The signing algorithm first checks whether state is LOST or not:

  • if (state ≠ LOST) : The stateful scheme is used, thus the algorithm derives sk_1 and pk_2 and signs message m using the current state and sk_1. Then it returns the updated state, state’ along with the signature concatenated with pk_2 .

  • else if (state == LOST) : The stateless scheme is used, thus the algorithm derives sk_2 and pk_1, and signs message m using sk_2 . Then it returns the signature concatenated with pk_1 .

• Verify(pk, m, sig) : The verification algorithm parses sig to obtain the actual signature and the public key concatenated with it. It then verifies the signature according to the signature scheme used, and checks that the two public keys hash to the correct SHRINCS pk .

Algorithmic Agility

A question we could try to give an answer to now is: Is this algorithmic agility?

TL:DR: The short answer is no. Longer answer follows.

The Internet Engineering Task Force (IETF) gives a precise definition of this in RFC7696, which states that “Algorithm agility is achieved when a protocol can easily migrate from one algorithm suite to another more desirable one, over time” due to the fact that “advances in computing power or advances in cryptoanalytic techniques will eventually make any algorithm obsolete”.

Thus, we can see algorithmic agility as the ability for a cryptography-based system to be ready for anything (”in omnia paratus!”) that could happen to the primitives in use.

On the other hand, the goal of the hybrid approach proposed by SHRINCS is not to provide an alternative cryptographic scheme in case the main one gets broken by advancements in research and technology. Instead, it aims to supply users with a fast and efficient signing algorithm, while at the same time providing a safety net that will prevent them from losing their funds due to its already known limitations.

Why Does This Matter?

One of the greatest drawback of PQ signatures scheme is their size. This is not a problem per se, but it becomes so in the context of a decentralized protocol with limited storage capabilities. The smallest PQ signature is 10x larger than the simplest key in use today, allowing for around 3 transactions-per-second (tps), against the 7 tps currently achievable through Schnorr.

SHRINCS is a clever solution, that helps demonstrate the problem space of how to compress known hash-based signature schemes to work for the Bitcoin use case in a PQ world while retaining the current static-backup, 12-word experience that users are accustomed to. The SHRINCS innovation is a great approach for maintaining user experience while balancing the realities of limited blockspace.

On May 12th, Blockstream Research presented a first proposal for a hash-based signature Opcode for Post-Quantum Bitcoin, called OP_CHECKSHRINCS , leveraging SHRINCS as the chosen signature scheme. Research is continuing to prepare a quantum-secure future for Bitcoin.

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