spiral

bitcoin

![](https://m.stacker.news/96148)

CoinJoin doesn’t guarantee privacy—it just buys you a chance at privacy. One slip post-mix, and intersection attacks can trace you all the way back. Leaks compound fast, and even “perfect” mixes can collapse under real-world pressure.

Check out this post written by Spiral’s Bitcoin Wizard [@not_nothingmuch](https://x.com/not_nothingmuch). Like the previous post in The Scroll series, this one accompanies and elaborates on a [video presentation](https://www.youtube.com/watch?v=oQk87s0N3BU).

---------------------------------------------------------------------------------------------------------
**Subscribe to Spiral's Substack for weekly updates about our team, carefully disguised as entertainment, delivered directly to your inbox: https://spiralbtc.substack.com/**

The Scroll #4: Intersection Attacks on CoinJoin Anonymity

![](https://m.stacker.news/95125)

------------------------------------------------------------------------------------------------------
**Subscribe to our Substack for weekly updates about our team, carefully disguised as entertainment, delivered directly to your inbox: https://spiralbtc.substack.com/**  

------------------------------------------------------------------------------------------------------
In our latest Spiral newsletter, new recruit [Mat Balez](https://x.com/matbalez) brings us dispatches from the bitcoin product front. With many years of PM work already under his belt, this inaugural edition is all about how he sees his profession expanding into the open-source space in the months and years ahead.  
**What is there left to say about bitcoin?**
In the wake of Bitcoin 2025, it feels like every possible nook and cranny of bitcoin’s inner workings, outer workings, utilization, and financialization have all been thoroughly keynoted, panel-discussed, and blasted out to the world. And outside of the conference circuit, there’s no shortage of bitcoin content being churned out across X, Nostr, podcasts, and newsletters. Hell, Spiral already has five action-packed newsletters running regularly.  
**Do we really need one more?**. 
Well, “need” is a strong word.

But as I wade into the bitcoin open-source product ecosystem, I think it might be interesting, at least for the product-inclined amongst you, to ride shotgun with me while I zoom around learning and thinking and nudging and connecting and advocating and battling and prototyping and testing and questioning and debating and documenting and explaining and consensus-building and energizing*, as well as all the other verb-ing things that product managers do that escape me right now.

This is just as well since, in many respects, bitcoin is designed to resist direct product “management.”

Unlike big tech companies or even small tech companies, in bitcoin open-source, no one is calling the shots, and there exists a healthy disregard for authority of any kind. This is as it should be. Bitcoin’s resilience depends on adversarial thinking, self-sovereignty, and the decentralization of all of its constituent parts—from nodes to hashpower to custody to software development to decision-making and influence.

The trick, I’ve learned, is to acknowledge that there’s nothing and no one to “manage” and that the right way to PM in bitcoin is just to be as helpful as you can be to others by putting in work that they can’t tackle themselves. (This is the secret to all good PM work, TBH.)

But it’s one thing to want to be helpful, you’ve gotta pick your battles: helpful how, and to what end?

For me, the endgame I want to help work towards is one in which bitcoin has become, yes, ubiquitous everyday money, but more than that, part of how we build new experiences, how everyone participates in those new experiences, how we all interact with AIs, how AIs interact with each other, and how we reshape everything around us once value can be fairly measured, freely transferred and safely stored without asking.

That’ll be a better world. But how do we get from here to there?

Currently, the two product themes with perhaps the highest leverage are (1) simplicity and (2) creativity.

(Expect these themes to become pillars of this newsletter—real-world examples, thorny problems, fun musings, frontier products, early prototypes, and interesting people with their interesting perspectives will all be featured.)   
**On Simplicity**
To welcome bitcoin’s next billion users, bitcoin needs to become radically simpler to use.

Today, far too much of the technical architecture still bleeds through in the UX. There are too many competing standards for sending and receiving, too many concepts to understand, too many footguns, and far too much uncertainty.

But getting to ‘simple’ is never easy. It takes energy, prioritizing use cases, identifying problems, powering through bike-shedding, sweating the details (they matter), driving adoption of best practices, anticipating edge cases, considering localization, testing with real users, and building that ever-elusive rough consensus.**

Even if many within bitcoin are already pushing toward an easier user experience, having one more person helping push can’t hurt. Already, the open source Bitcoin Design Community is out front, applying good design thinking to tame both long-standing and newly-emerging complexity. But I think we can elevate the work and have Design as a function play an even bigger role in advocating for users, especially those that have yet to arrive. Let’s design a simpler bitcoin.  
**On Creativity**
We are at a creative inflection point. Via vibe coding, AI coding agents are unleashing an army of new developers (people like me) building a limitless tool chest of new things, big and small.

Bitcoin’s infrastructure, the related tooling, and the interoperability of various L2s are finally at, or at least near, the stage where mere mortals can use them to embed permissionless, instantaneous, borderless value transfer into whatever they build.

I foresee an explosion of new ideas and apps. Some of these will merely be familiar ideas made more interesting with bitcoin in the mix. Some will be further augmented by AI magic. Others, and this is where I get really excited, will be things made newly possible by what bitcoin and AI unlock together. We recently saw a glimpse at this future during Presidio Bitcoin’s hackathon in May. What will be the first product to break through to the whole world because of bitcoin? I can’t wait to find out.

And maybe the best thing about this foreseen explosion of creative new ways to use bitcoin in creative new product experiences is that it will make evident a critical yet often overlooked fact: you can’t use bitcoin if you don’t own bitcoin. Put differently, many will be reminded that ETFs and stocks are very different from bitcoin regarding how they’re owned and used. This is an opportunity for real bitcoin products to show, not just tell, the real utility of this new money.

Anyway, all of this is the long way of saying that I, as a brand new open-source PM, want to be on this wave with other bitcoin product builders, helping to connect the dots that make it all possible while finding and isolating and ironing out the trouble spots in the dev experience, championing the best projects, highlighting the best tools, trying lots of stuff myself, and showing everyone what’s possible.***

It’ll be exciting. It’ll be fun.

Taken together, a radically simpler bitcoin combined with a giant community of new builders unleashing a creative tsunami should mean we get to truly ubiquitous bitcoin just a little bit faster than we might have otherwise. I’ll be doing my best to do my product-ey part while documenting it all here.

Until next time 👋

There Is (Almost) Nothing Left to Say About Bitcoin

![](https://m.stacker.news/91834)

Subscribe to our Substack for weekly updates about our team, carefully disguised as entertainment, delivered directly to your [inbox](https://spiralbtc.substack.com).  
If you’re among the millions or billions of people following our newsletters, you’re probably already up to speed on Plushie Confidential #1 and #2. If you aren’t, you might want to take a brief sojourn back in time to read [Bitty’s genesis story](https://open.substack.com/pub/spiralbtc/p/plushie-confidential-1-big-start?r=53cq2n&utm_campaign=post&utm_medium=web&showWelcomeOnShare=false) and follow that up with [Itty Bitty’s](https://open.substack.com/pub/spiralbtc/p/plushie-confidential-2-rooting-for?r=53cq2n&utm_campaign=post&utm_medium=web&showWelcomeOnShare=false). ChatGPT can probably summarize if reading premium bitcoin content isn’t for you.  
But these are preambles. While this post doesn’t have much to do with earlier Plushie Confidential, it does have much to do with Japanese culture and their collective love for all things cute, cuddly, and quintessential.  
If you’ve never been to Japan (statistically, you probably haven’t), one of the first things to strike you during your long march from the plane to immigration will be the presence of extremely large Pokémon. Not unfriendly stares from bossy TSA agents, Pokémon—big goddamn Pokémon.  
While we can’t speak for every terminal at NRT or HND, the ones I’ve always been into are Pokémon, Pokémon, Pokémon. Pikachu, Charmander, and Bulbasaur—they’re all there. And if you’re fortunate, you’ll see one of the Pokémon branded Boeing 767s sitting on the tarmac. (They’re a lot like this hallway but with fixed wings and jet engines).   
Anyway, Tokyo… whatta town.

![](https://m.stacker.news/91828)

Our team landed in Tokyo in mid-September for two reasons:  
Rally for our semi-annual team offsite, where engineers gab for ten hours a day while the creative team huddles anywhere else.  
Attend Bitcoin Tokyo 2024, Tokyo’s first bitcoin only conference.  
Going into the conference, we had been asked by several sellers whether they could use our Bitty and Itty Bitty stickers to create merch. Of course, they could, since one of our earliest goals with the Here Comes Bitcoin project was to make our Here Comes Bitcoin assets as open-source as Bitcoin’s code. This meant that anyone could use any of our assets for anything they wanted: tote bags, stickers, pins, wallets, chocolates, fine art, and so on and so on.  
And, hoo boy, the good people of Japan delivered. Here’s just a small sample of what people produced using Here Comes Bitcoin.

![](https://m.stacker.news/91829)
![](https://m.stacker.news/91830)
![](https://m.stacker.news/91832)

When we launched Here Comes Bitcoin, we focused on the United States, where we saw people using our assets to launch their own products. But this was nothing like we saw in Tokyo.  
For context, at Bitcoin 2024 in Nashville, we sold roughly 25% of our Itty Bitty stock. Not bad, but not great either. At Bitcoin Tokyo, we sold over 80%, and for the remainder of the conference, we saw men and women running around and tightly squeezing their Itty Bitties.  
As the subtitle of this Plushie Confidential post makes clear, sometimes your audience finds you. We didn’t know that would happen. When we launched Here Comes Bitcoin, it never occurred to us that a single geographical region would dominate every other one. In the US, we got a lot of pushback about why Itty Bitty and Bitty himself seemed so grumpy (grumpy is lovable; ask half the Muppets). In Japan, everyone got what we were going for… immediately.  
So what’s next for Bitty and Itty Bitty and the entire Here Comes Bitcoin project in Japan? Hopefully everything.  
Our plan is to double, triple, and quadruple down on Japan since that’s where the most interest is. One of our plans is to work with university students to proliferate Itty Bitty to engineering students who might someday want to work on Bitcoin development. Another plan is to get Itty Bitty into retail stores, where it should sell like bright orange hotcakes if the conference was any indicator.  
One of the goals of Here Comes Bitcoin was to make Bitcoin funnier, friendlier, and more accessible, not just in the country where we primarily operate, the US, but everywhere. But we have to start somewhere. Japan and Korea are two of the foremost creators of culture in the world today. Their games, art, fashion, and entertainment are nothing short of ubiquitous, being two of the world’s biggest exports. So, while our plan to head on to the United States didn’t work, we had a different plan: to re-enter the States and Europe through Japan.  
Oh, and it won’t be Itty Bitty doing this alone. His dad will be helping, too. As popular as Itty Bitty was in Japan, he was more than rivaled by his father figure, who was larger than life and made a big splash throughout Tokyo.  
In a country where everything has a mascot (cars, vegetables, towns, train lines, cat food), it stands to reason that Bitcoin, in a country that is rapidly embracing Bitcoin, would have one.

![](https://m.stacker.news/91833)

Next time on Plushie Confidential:Logistics, Retail, and Assembling a Team.  
Subscribe to our Substack for weekly updates about our team, carefully disguised as entertainment, delivered directly to your [inbox](https://spiralbtc.substack.com). 

Plushie Confidential #3: The Tokyo Connection, Sometimes Your Market Finds You

![](https://m.stacker.news/90773)

Matt Corallo's back at it, and this time, he’s madder than ever.

Tomorrow, May 8, I’ll be giving a talk at [bitcoin++ about MEVPool](https://btcpp.dev/conf/atx25/talks#atx_mevpool) and the best (but terrible) outcomes if MEVil proliferates on bitcoin. On a seemingly dissimilar but related note, last week, the bitcoin ecosystem was abuzz about another topic: Bitcoin Core standardness rules. I’ll let others dissect moderation policies and the (in)effectiveness of standardness as a deterrent to “bad” uses of bitcoin. Still, it’s worth discussing the impacts of restrictive standardness rules in the context of MEVil and their impact on mining centralization.  
In case you don’t know, [MEVil](https://bluematt.bitcoin.ninja/2024/04/16/stop-calling-it-mev/) arises from bitcoin use cases that drive mining centralization by increasing the fixed costs associated with mining. MEVil might take the form of complicated smart contracts that force miners to become high-frequency traders in order to get competitive revenue (costing tens of millions in upfront costs unrelated to their mining operation), or as technologies that require miners to sign up with centralized parties to access high-value transactions and maximize revenue per hash.
These issues are no joke—mining is almost a perfectly competitive global industry with often quite compressed margins. An increase in revenue of 1% might not sound like a lot, but if your margin is only 5 or 10%, that might represent 10 or 20% more profit. In practice, this allows you to expand, increase your hash rate, reduce the margin for all miners, and put your competition at risk of bankruptcy.
It should go without saying that mining decentralization is [one of the most important features of bitcoin](https://bluematt.bitcoin.ninja/2016/01/14/decentralization/), one which is [at great risk](https://bluematt.bitcoin.ninja/2024/05/11/bitcoins-precarious-position/), representing a major threat to bitcoin's longevity.  
Thus, anything that results in some miners persistently getting a few percent more revenue per hash would represent a significant risk to bitcoin's longevity and its credible neutrality.
Today, miners get nearly all the transactions they include in a block from the public bitcoin peer-to-peer network, which provides a nontrivial (though not currently particularly high) portion of their income from the fees these transactions pay. As the block reward dwindles, these transactions will make up a more critical portion of miner revenue.  
Some large miners have set up proprietary APIs or run custom software to allow transactions that generally do not propagate through the regular bitcoin P2P network to reach them. MARA's Slipstream product is the classic example of this, where many "nonstandard" transactions can be submitted to them via an HTTP API and, for the right price, can be included in a block that MARA mines. There are also various patches to Bitcoin Core, which some miners have run. These can remove standardness rules and tweak the structure of the P2P network to receive additional transactions.  
Luckily, the total revenue change created by these types of activities is trivial, at least at this time. Because few transaction creators wish to use nonstandard transactions, the impact on mining centralization pressure is minimal. Still, the fact that some miners have found it worth the cost to build these systems should highlight their substantial risk to bitcoin.  
If Bitcoin Core were to restrict standardness rules further while the ecosystem creates more and more inventive uses for bitcoin (some of which may or may not be good for bitcoin as a currency), driving nonstandard transaction creation, centralization pressure from dwindling block subsidies would become immense. To compete, a small miner would have to hire engineers to build a Slipstream-like system, patching Bitcoin Core where appropriate (without introducing bugs!) and then convincing transactors to use their proprietary system for transaction submission. This would make it all but impossible for a new miner to get off the ground.  
Certainly, there are many valid reasons why standardness rules exist. Some prevent DoS against the block creation logic or mempool (e.g., the limit on maximum transaction size and number of dependent transactions ensure that Bitcoin Core can efficiently manage the mempool and create a competitive block template). However, standardness rules to prevent types of transactions that many people want to create only serve to encourage proprietary relay systems. These may not be felt in the form of short-term mining centralization. But as the block subsidy decreases, they certainly would be, all but dooming bitcoin's censorship resistance and neutrality.


What's Matt Mad at Now? The MEVil of Relay Policy

Written by Spiral's Bitcoin Wizard, [not_nothingmuch](https://x.com/not_nothingmuch).    
Read below or subscribe to [Spiral's Substack](https://spiralbtc.substack.com/).  
Our [previous post](https://spiralbtc.substack.com/p/the-scroll-2-wallet-clustering-basics) in this series introduced the basic idea behind wallet or address clustering, the trivial case of address reuse, and the merging of clusters based on the common input ownership heuristic (CIOH), also known as the multi-input heuristic.

Today, we’ll expand on more sophisticated clustering methods, briefly summarizing several notable papers. The content here mostly overlaps with a [live stream](https://www.youtube.com/watch?v=ndgSQlLIfI4) on this topic, which is a companion to this series. Note that the list of works cited is by no means exhaustive.  
**Early Observational Studies - 2011-2013**
As far as I’m aware, the earliest published academic study that deals with clustering is Fergal Reid and Martin Harrigan’s [An Analysis of Anonymity in the Bitcoin System](https://link.springer.com/chapter/10.1007/978-1-4614-4139-7_10) (PDF). This work, which studies the anonymity properties of bitcoin more broadly, in its discussion of the on-chain transaction graph, introduced the notion of a “User Network” to model the relatedness of a single user’s coins based on CIOH. Using this model, the authors critically examined WikiLeak’s claim that it “[accepts anonymous Bitcoin donations](https://twitter.com/wikileaks/status/80774521350668288).”

Another study that was not published as a paper was [Bitcoin - An Analysis](https://fahrplan.events.ccc.de/congress/2011/Fahrplan/events/4746.en.html) (YouTube) by Kay Hamacher and Stefan Katzenbeisser, presented at 28c3. They studied money flows using transaction graph data and made some remarkably prescient observations about bitcoin.

In [Quantitative Analysis of the Full Bitcoin Transaction Graph](https://link.springer.com/chapter/10.1007/978-3-642-39884-1_2) (PDF), Dorit Ron and Adi Shamir analyzed a snapshot of the entire transaction graph. Among other things, they note a curious pattern, which may be an early attempt at subverting CIOH:  
"We discovered that almost all these large transactions were the descendants of a single large transaction involving 90,000 bitcoins [presumably b9a0961c07ea9a28…] which took place on November 8th, 2010, and that the subgraph of these transactions contains many strange looking chains and fork-merge structures, in which a large balance is either transferred within a few hours through hundreds of temporary intermediate accounts, or split into many small amounts which are sent to different accounts only in order to be recombined shortly afterward into essentially the same amount in a new account."  
Another early confounding of this pattern was due to MtGox, which [allowed users to upload their private keys](https://en.bitcoin.it/wiki/MtGox/API/HTTP/v1#redeem_a_wallet.dat). Many users’ keys were used as inputs to batch sweeping transactions constructed by MtGox to service this unusual pattern of deposits. The naive application of CIOH to those transactions resulted in cluster collapse, specifically the cluster previously known as [MtGoxAndOthers](https://www.walletexplorer.com/wallet/MtGoxAndOthers) on walletexplorer.com (now known as CoinJoinMess). Ron and Shamir seem to note this, too:  
"However, there is a huge variance in [these] statistics, and in fact one entity is associated with 156,722 different addresses. By analyzing some of these addresses and following their transactions, it is easy to determine that this entity is Mt.Gox."  
Although change identification is mentioned (Ron & Shamir refer to these as “internal” transfers), the first attempt at formalization appears to be in [Evaluating User Privacy in Bitcoin](https://link.springer.com/chapter/10.1007/978-3-642-39884-1_4) (PDF) by Elli Androulaki, Ghassan O. Karame, Marc Roeschlin, Tobias Scherer, and Srdjan Capkun. They used the term “Shadow Addresses,” which these days are more commonly referred to as “change outputs.” This refers to self-spend outputs, typically one per transaction, controlled by the same entity as the inputs of the containing transaction. The paper introduces a heuristic for identifying such outputs to cluster them with the inputs. Subsequent work has iterated on this idea extensively, with several proposed variations. One example based on the amounts in 2 output transactions is if an output’s value is close to a round number when denominated in USD (based on historical exchange rates), that output is likely to be a payment, indicating the other production is the change.

This early phase of Bitcoin privacy research saw the theory of wallet clustering become established as a foundational tool for the study of Bitcoin privacy. While this wasn’t entirely theoretical, evidential support was limited, necessitating relatively strong assumptions to interpret the observable data.  
**Empirical Results - 2013-2017**
Although researchers attempted to validate the conclusions of these papers, for example, by interviewing Bitcoin users and asking them to confirm the accuracy of the clustering of their wallets or using simulations as in Androulaki et al.’s work, little information was available about the countermeasures users were utilizing.

[A fistful of bitcoins: characterizing payments among men with no names](https://dl.acm.org/doi/abs/10.1145/2504730.2504747) (PDFs: 1, 2) by Sarah Meiklejohn, Marjori Pomarole, Grant Jordan, Kirill Levchenko, Damon McCoy, Geoffrey M. Voelker, and Stefan Savage examined the use of Bitcoin mixers, and put the heuristics to the test by actually using such services with real Bitcoin. On the more theoretical side, they defined a more general and accurate change identification heuristic than previous work.

In his thesis, [Data-Driven De-Anonymization in Bitcoin](https://www.research-collection.ethz.ch/bitstream/handle/20.500.11850/155286/eth-48205-01.pdf), Jonas Nick was able to validate the CIOH and change identification heuristics using information obtained from a privacy bug in the implementation of BIP 37 bloom filters, mainly used by light clients built with bitcoinj. The underlying privacy leak was described in [On the privacy provisions of Bloom filters in lightweight bitcoin clients](https://dl.acm.org/doi/abs/10.1145/2664243.2664267) (PDF) by Arthur Gervais, Srdjan Capkun, Ghassan O. Karame, and Damian Gruber. The leak demonstrated that the clustering heuristics were rather powerful, a finding which was elaborated on in Martin Harrigan and Christoph Fretter’s [The Unreasonable Effectiveness of Address Clustering](https://ieeexplore.ieee.org/abstract/document/7816867) (PDF).

Attackers have also been observed sending bitcoin, not through a mixer as in the fistful of bitcoins papers, but small amounts sent to addresses that have already appeared on-chain. This behavior is called dusting or dust attacks and can deanonymize the victim in two ways. First, the receiving wallet may spend the funds, resulting in address reuse. Second, older versions of Bitcoin Core [used to](https://github.com/bitcoin/bitcoin/pull/18038) rebroadcast received transactions, so an attacker who was also connected to many nodes on the p2p network could observe if any node was rebroadcasting its dusting transactions and that node’s IP address to the cluster.

Although [Is Bitcoin gathering dust? An analysis of low-amount Bitcoin transactions](https://link.springer.com/article/10.1007/s41109-023-00557-4) (PDF) by Matteo Loporchio, Anna Bernasconi, Damiano Di Francesco Maesa, and Laura Ricci offered insights in 2023, exploring dust attacks, the data set they analyzed only extends to 2017. This work looked at the effectiveness of such attacks in revealing clusters:  
"This means that the dust attack transactions, despite being only 4.86% of all dust creating transactions, allow to cluster 66.43% of all dust induced clustered addresses. Considering the whole data set, the transactions suspected of being part of dust attacks are only 0.008% of all transactions but allow to cluster 0.14% of all addresses that would have otherwise remained isolated."  
This period of research was marked by a more critical examination of the theory of wallet clustering. It became increasingly clear that, in some cases, users’ behaviors can be easily and reliably observed and that privacy assurances are far from perfect, not just in theory but also based on a growing body of scientific evidence.  
**Wallet Fingerprinting - 2021-2024**
Wallet fingerprints are identifiable patterns in transaction data that may indicate using particular wallet software. In recent years, researchers have applied wallet fingerprinting techniques to wallet clustering. A single wallet cluster is typically created using the same software throughout, so any observable fingerprints should be fairly consistent within the cluster.

As a simple example of wallet fingerprinting, every transaction has an nLockTime field, which can be used to post-date transactions. This can be done by specifying a height or a time. When no post-dating is required, any value representing a point in time that is already in the past can be used, typically 0, but such transactions haven’t been post-dated when they were signed. To avoid revealing intended behavior and address the [fee sniping concern](https://bitcoinops.org/en/topics/fee-sniping/), some wallets will randomly specify a more recent nLockTime value. However, since some wallets always specify a value of 0, when it’s not clear which output of a transaction is a payment and which is change, that information might be revealed by subsequent transactions. For example, suppose all of the transactions associated with the input coins specify nLockTime of 0, but the spending transaction of one of the outputs does not, in this case it would be reasonable to conclude that output was a payment to a different user.

There are many other known fingerprints. [Wallet Fingerprints: Detection & Analysis](https://ishaana.com/blog/wallet_fingerprinting/) by Ishaana Misra is a comprehensive account.

Malte Möser and Arvind Narayanan’s [Resurrecting Address Clustering in Bitcoin](https://link.springer.com/chapter/10.1007/978-3-031-18283-9_19) (PDF) applied fingerprinting to the clustering problem. They used it as the basis for refinements to change identification. They relied on fingerprints to train and evaluate improved change identification using machine learning techniques (random forests).

Shortly thereafter, in [How to Peel a Million: Validating and Expanding Bitcoin Clusters](https://www.usenix.org/conference/usenixsecurity22/presentation/kappos) (PDF), George Kappos, Haaroon Yousaf, Rainer Stütz, Sofia Rollet, Bernhard Haslhofer and Sarah Meiklejohn extended and validated this approach using cluster data for a sample of transactions provided by a chain analytics company, indicating that the wallet fingerprinting approach is dramatically more accurate than only using CIOH and simpler change identification heuristics. Taking fingerprints into account when clustering makes deanonymization much easier. Likewise, taking fingerprints into account in wallet software can improve privacy.

A recent paper, [Exploring Unconfirmed Transactions for Effective Bitcoin Address Clustering](https://dl.acm.org/doi/abs/10.1145/3589334.3645684) (PDF) by Kai Wang, Yakun Cheng, Michael Wen Tong, Zhenghao Niu, Jun Pang, and Weili Han analyzed patterns in the broadcast of transactions before they are confirmed. For example, different fee-bumping behaviors can be observed, both via [replacement](https://bitcoinops.org/en/topics/replace-by-fee/) or with [child-pays-for-parent](https://bitcoinops.org/en/topics/cpfp/). Such patterns, while not strictly fingerprints derived from the transaction data, can still be thought of as wallet fingerprints but about more ephemeral patterns related to certain wallet software, observable when connected to the Bitcoin P2P network but not apparent in the confirmed transaction history that is recorded in the blockchain.

Similar to the Bitcoin P2P layer, the Lightning network’s gossip layer shares information about publicly announced channels. This is not typically framed as a wallet fingerprint but might be loosely considered as such, in addition to the on-chain fingerprint lightning transactions have. Lightning channels are UTXOs, and they form the edges of a graph connecting Lightning nodes, which are identified by their public key. Since a node may be associated with several channels, and channels are coins, this is somewhat analogous to address reuse. Christian Decker has publicly archived historical graph data. One study that looks at clustering in this context is [Cross-Layer Deanonymization Methods in the Lightning Protocol](https://link.springer.com/chapter/10.1007/978-3-662-64322-8_9) (PDF) by Matteo Romiti, Friedhelm Victor, Pedro Moreno-Sanchez, Peter Sebastian Nordholt, Bernhard Haslhofer, and Matteo Maffei.

Clustering techniques have improved dramatically over the last decade and a half. Unfortunately, widespread adoption of Bitcoin privacy technologies is still far from being a reality. Even if it was, the software has not yet caught up to the state of the art in attack research.  
**Not The Whole Story**
As we have seen, starting from the humble beginnings of address reuse and the CIOH described by Satoshi, wallet clustering is a foundational idea in Bitcoin privacy that has seen many developments over the years. A wealth of academic literature has called into question some of the overly optimistic characterizations of Bitcoin privacy, starting with WikiLeaks describing donations as anonymous in 2011. There are also many opportunities for further study and for the development of privacy protections.

Something to bear in mind is that clustering techniques will only continue to improve over time. “[R]emember: attacks always get better, they never get worse.” Given the nature of the blockchain, patterns in the transaction graph will be preserved for anyone to examine more or less forever. Light wallets that use the Electrum protocol will leak address clusters to their Electrum servers. Ones that submit [xpubs](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki) to a service will leak clustering information of all past and future transactions in a single query. Given the nature of the blockchain analysis industry, proprietary techniques are at a significant advantage, likely benefiting from access to KYC information labeling a large subset of transactions. This and other kinds of blockchain-extrinsic clustering information are especially challenging to account for since, despite being shared with 3rd parties, this information is not made public, unlike clustering based on on-chain data. Hence, these leaks aren’t as widely observable.

Also, bear in mind that control over one’s privacy isn’t entirely in the hands of the individual. When one user’s privacy is lost, that degrades the privacy of all other users. Through the process of elimination, which suggests a linear progression of privacy decay, every successfully deanonymized user can be discounted as a possible candidate when attempting to deanonymize the transactions of the remaining users. In other words, even if you take precautions to protect your privacy, there will be no crowd to blend into if others don't take precautions, too.

However, as we shall see, assuming linear decay of privacy is often too optimistic; exponential decay is a safer assumption. This is because divide-and-conquer tactics also apply to wallet clustering, much like in the game of 20 questions. CoinJoins transactions are designed to confound the CIOH, and the topic of the next post will be a paper that combines wallet clustering with intersection attacks, a concept borrowed from the mixnet privacy literature, to deanonymize CoinJoins.  
Subscribe to [Spiral's Substack](https://spiralbtc.substack.com/). 

A Brief History of Wallet Clustering by @not_nothingmuch

April’s Nerd of the Month is [the_charlatan_](https://x.com/the_charlatan_), a Spiral grantee whose work on Bitcoin Core’s build system, validation engine, and long-term architectural challenges is overdue for the spotlight. We’ll be placing special emphasis on his main project, the [bitcoinkernel library](https://github.com/bitcoin/bitcoin/issues/27587). Prepare for a deep one.  
**Happy Sweet 16, Bitcoin Core**
Bitcoin Core, the codebase that powers the Bitcoin Network, has expanded significantly over the past 16 years… to put it mildly. What started as the important, experimental work of a single shadowy super coder now has dozens contributing to it with trillions of dollars riding on their success.
At the heart of Core lies the validation engine, which checks whether a transaction or a block of transactions is valid. However, the lines separating the engine’s primary functionality and secondary features have become increasingly blurred. This is where the the_charlatan_’s work, and why they are a grantee, not to mention our Nerd of the Month, comes into focus.  
**Bitcoinkernel Library Objectives** 
The [bitcoinkernel library’s](https://github.com/bitcoin/bitcoin/issues/27587) main objective is to improve code organization within Bitcoin Core while isolating its primary functionality. 
Its secondary objective is to expose validation logic to external users. This is achieved by [PR #30595,](https://github.com/bitcoin/bitcoin/pull/30595) which introduces a C header as an API for the validation code. Then, this [Rust crate](https://github.com/TheCharlatan/rust-bitcoinkernel) and a separate [Python package](https://github.com/stickies-v/py-bitcoinkernel) demonstrate how to use its API for external bindings. 80% of this newsletter’s readers probably dropped off towards this paragraph’s end, but hey, to the remaining 20%, thanks for sticking around. You’re probably who Nerd of the Month is for.  
**Bitcoinkernel in the Wild**
Bitcoinkernel’s benefits can already be seen throughout bitcoin’s development ecosystem. The library’s external language bindings have inspired initial users to create their own [primitive full nodes](https://github.com/TheCharlatan/kernel-node) written in Rust and a [mining pool data analysis](https://github.com/ismaelsadeeq/mining-analysis) project written in Python. These demonstrate the usefulness of the library for developers implementing alternative bitcoin clients while powering analytics directly on Bitcoin Core's data stores. Experiments have also been conducted using the [index-building](https://github.com/josibake/electrs/commits/electrs-kernel-integration) API for Electrum servers and [script debugging.](https://github.com/bitcoin/bitcoin/commit/997c2ccc920adb0d1c9d8e82dbe94374cfb3c78b)  
    **When You Stare into Core, Core Stares into You**
This initial API represents an evolution that should, over the years, reveal more robust Bitcoin Core validation features. It does not yet incorporate separate header syncing, and lacks flexible support for alternate validation models, such as [Utreexo.](https://bitcoinops.org/en/topics/utreexo) However, it does include opinionated features like [assumeUTXO](https://bitcoinops.org/en/topics/assumeutxo/) and assumevalid, which can be controlled or disabled but are challenging to re-implement as part of an alternate implementation.
Recently, there have been discussions among Bitcoin Core developers regarding the project's scope. Increasing technical debt has become progressively more challenging for Core to manage with its current structure. New features and interfaces must be justified at every step, and the bitcoinkernel library's API is no exception. This is why the library must be beneficial not only for external users but for internal functions.    
  **It’s Not Called Nerd of the Month for Nothing**
We warned you, this one was deep in the weeds. Regardless, whether you caught all that or just some, the bitcoinkernel project is uniquely situated to open up Bitcoin Core's most important code to a wide audience, foster faster prototyping and innovation, and become a tool for academic research. That’s why we back the_charlatan_, not in cash money or bitcoin like you might expect, but in the holy nerd sustenance trifecta: energy drinks, sweatpants, and an entire warehouse worth of standing desks.  
**Enjoy this Content?**
Subscribe to our Substack for weekly updates about our team, carefully disguised as entertainment, delivered directly to your inbox: https://spiralbtc.substack.com/ 



Spiral Nerd of the Month: Bitcoinkernel Library

With our new multi-part newsletter comes a new approach to writing quarterly updates, introducing cutting-edge, streamlined technologies called bullet points. Gone are the days of 1,500+ word, 20+ paragraph blog posts that no one, including us, ever read. With these new quarterly Spiral Progress Reports, we’ll be providing you with only the highest-level updates, summaries, and regrettable jokes that we included because we started late and ran out of time to workshop them.  

[Subscribe to our Substack](https://spiralbtc.substack.com/) for weekly updates about our team carefully disguised as entertainment delivered directly to your inbox.    

**More than Code**

A lot is happening at Spiral HQ besides people contributing little green squares to LDK’s GitHub repository. Here’s a taste of what else we’re doing to make bitcoin the planet’s preferred currency:
 
* @HBerkoe and @moneyball poured about a million hours into helping launch [Presidio Bitcoin](https://www.presidiobitcoin.org/), the Bay Area's first bitcoin co-working and events space.
* Check out the [panel about open source’s value filmed at Presidio Bitcoin](https://youtu.be/VXYJtFY7wi0?si=llUvaetIIa51elSr&t=1) that Spiral Lead Steve Lee moderated. It features Jack Dorsey, David Marcus, and Alex Gladstein.
* Steve, DK, and @MaxAWebster started a weekly podcast called ["Presidio Bitcoin Jam,"](https://presidiobitcoin.substack.com/podcast) or, as we prefer to call it, “PBJ.” The show explores the latest bitcoin topics, simplifies technical concepts, and describes use cases and bitcoin’s effect on the financial system. Tune in every Friday at 12PM PT on [YouTube](https://www.youtube.com/@PresidioBitcoin/streams), or subscribe on [Spotify](https://open.spotify.com/show/0N8ZFqAkTwxNmjDXdIo7cT_) and [Apple Podcasts](https://podcasts.apple.com/us/podcast/presidio-bitcoin-jam/id1804198027).
* Speaking of podcasts filmed at Presidio Bitcoin, Haley launched [“21 in 21,"](https://youtu.be/0PaV_6vjkXI?si=MZLaxuhW9D86sWrH_) where she asks tech and bitcoin personalities visiting Presidio Bitcoin 21 questions in 21 minutes, with Jack Dorsey being the latest to take the hot seat. Reach out to haley@spiral.xyz if you’d like the Internet to watch you be grilled by one of bitcoin’s smallest people for 21 minutes. Subscribe on [Spotify](https://open.spotify.com/show/4UPEsVaAbtQsBtvbKt1RPn?si=2e5efe8f58094c2c&nd=1&dlsi=468bce5b4b514d3d) and [Apple Podcasts](https://podcasts.apple.com/us/podcast/21-in-21/id1804684052).
* @ConorOkus appeared on [Stephan Livera’s show](https://stephanlivera.com/episode/646/) to discuss improving bitcoin payment UX.
Steve’s been making the rounds, visiting Citadel Dispatch to talk about the trade-offs of Bitkey, potential improvements to the platform, and soft fork proposals for bitcoin vault functionality.
* @TheBlueMatt and @theinstagibbs are scheduled to speak at bitcoin++ on May 7-9 in Austin, while @theinstagibbs will also speak at OPNEXT on April 11–12 in Tysons, Virginia. 
* We renewed grants for the Bitcoin Design Foundation, Bitcoin Dev Kit Foundation, Justin Moeller, whilst a new grantee, Leo, was welcomed into the Spiral Extended Crew.
* We’re considering making everyone on the team run a Bitaxe. [Please steal this idea](https://x.com/spiralbtc/status/1904627596593377539).  


**Lumpy and Grumpy**

Grumpy-cute. Not only is it a thing, it’s a good thing. And nowhere is it more of a thing than with bitcoin’s furriest open-source mascots, Bitty and [Itty Bitty](https://www.uncute.com/collections/everything-else/products/here-comes-bitcoin).  
* This quarter, with the launch of our new multi-newsletter platform, we published two issues of Plushie Confidential. The first highlighted [Bitty's development](https://spiralbtc.substack.com/p/plushie-confidential-1-big-start), and the second explored the [story behind Itty Bitty](https://spiralbtc.substack.com/p/plushie-confidential-2-rooting-for), his “just a little guy” variant. 
* 20 more [Here Comes Bitcoin](https://www.herecomesbitcoin.org/) character stickers are in development, which should shortly be followed by another 20. As always, some will collaborate with bitcoin brands while others will continue being inspired by sci-fi, fantasy, or whatever is cool to us then. Sometimes, we worry that when banks and other corporate entities begin building strategic Bitcoin reserves, bitcoin will lose some of the weirdness that has served it so well since its invention. So, we’re doing our part to keep it weird. 
* We shipped a big box of plushies to Japan, the country where Bitty and Itty Bitty have gotten perhaps the most love, for the Tokyo Bitcoin Base’s grand opening at the end of April.


**Buncha Nerds**

No matter how many sports they play or Patagonia vests they wear, at its core, our team is a bunch of nerds. While our creative team’s obsession with Warhammer 40K grows alongside their Pusheen collections, the rest of our nerds have been diving into the sorts of technical bitcoin topics that define a different but equally obsessive kind of nerddom.
* Spiral’s Bitcoin Wizards, @theinstagibbs and not_nothingmuch, posted two articles about bitcoin [UTXO sharing](https://spiralbtc.substack.com/p/the-scroll-utxo-sharing) and [Wallet Clustering Basics](https://spiralbtc.substack.com/p/the-scroll-2-wallet-clustering-basics).
* Yuval spoke about Wallet Clustering on the [Bitcoin Developer’s Channel](https://www.youtube.com/live/ndgSQlLIfI4?si=KiebJm-RFbaMAP03&t=78). 
* Conor added to our growing comms presence by[ writing a solid feature piece about Payjoin Dev Kit](https://payjoindevkit.org/2025/03/18/the-evolution-of-payjoin/). Payjoin improves blockspace efficiency and preserves privacy without requiring protocol changes. To find out more or just to see how of a nerd you really are, just read the dang article or listen to [Steve yap about it on PBJ.](https://youtu.be/fC09DPICG7k?si=fyjG0sLxPWlB4Cta) 
* The Lightning Development Kit released a new feature, VSS, and G8XSU [wrote all about it](https://lightningdevkit.org/blog/announcing-vss/). 
* Speaking of newsletters, everyone’s favorite impassioned Twitter poster and bitcoin developer, Matt Corallo, got a newsletter all to himself. In it, he’ll be getting mad once a month about a different topic in bitcoin’s orbit. This month’s angry newsletter was about [custodial solutions](https://spiralbtc.substack.com/p/custodial-solutions-are-not-solutions). 


2025 Q1 Spiral Progress Report

![](https://m.stacker.news/83169)

The [Lightning Development Kit (LDK)](https://lightningdevkit.org/) is a library that makes it easier for developers to build custom Lightning nodes from scratch. This post was released on lightningdevkit.org a couple of days ago, but they forgot that [Spiral also has a newsletter](https://spiralbtc.substack.com/) for LDK-related things like VSS. Fortunately for our readers, we didn’t forget.

**What Is VSS?**
The [Versioned Storage Service (VSS)](https://github.com/lightningdevkit/vss-server/tree/main) provides a server-side storage solution for non-custodial mobile, web, and hosted wallets. VSS significantly simplifies the wallet development process by offering a reliable, secure, and robust framework that stores and manages the various forms of state data required for the Lightning Network and Bitcoin applications.

**VSS primarily serves two core functionalities:**
*Recovery: VSS enables the restoration of states and wallet access, helping users regain their funds and control even in device or data loss scenarios.

*Multi-device Access: While this isn’t available now, future phases will allow the same wallet app across multiple devices to securely share and access the LN state, leading to consistent access to funds.

*Clients can also leverage VSS for general application metadata storage, which includes payment history, user metadata, and more.

**Why VSS?**
VSS aims to lower the barriers to high-quality LN wallet development. Wallet builders can host the VSS service in-house for straightforward interaction with the service or use reliable third-party VSS providers, if available.

VSS was designed with privacy in mind, offering features such as client-side encryption, key-obfuscation, and robust authorization. It also ensures data and version number verifiability and will support multi-device access in the future. The software ensures modularity for seamless integration with different storage backend technologies. Additionally, VSS can work with various applications with different key-level versioning and data-integrity mechanisms and even allows disabling versioning for single-device wallet usage.

**Why do we need VSS as primary storage for lightning wallets?**
Keeping VSS in sync with the latest Lightning state isn’t optional; if the server’s version lags and the user loses the device, there is a risk of funds loss. That’s why VSS-powered wallets must be designed to hold off advancing the lightning state until everything’s securely updated on the server.

The on-device state of a Lightning wallet changes every time a user sends or receives payments. While some backup options offer frequency-based backups, these can lead to data being out of sync and do not ensure full funds or channel recovery if the device is lost. Protocols that sync asynchronously based on intervals inherently have insufficient data for complete recovery by design.

Using VSS as the primary storage ensures that every state change is securely stored in real-time, enabling full recovery of funds and channels regardless of device loss.

**Customization**
While VSS can be readily used, it is intended to be customized based on specific requirements. For example, clients might need to implement custom authorization, encryption, or backend database integration with different cloud providers. With the accurate facilitation of the API contract, wallets can easily switch between different instances of VSS. For example, a wallet can easily switch from VSS-Provider-A to VSS-Provider-B by downloading the whole state and uploading it to the new provider.

By default, VSS incorporates a PostgreSQL implementation and can be hosted on preferred infrastructure/cloud providers such as AWS, GCP, and others. Its backend storage can be interchanged with other implementations for KeyValueStore if necessary.

**Usage**
**Using With LDK Node:**
LDK Node can be easily configured to run with VSS as primary storage. It is integrated into LDK Node (written in Rust) using VSS-rust-client, and there is also support for other languages such as Swift, Kotlin, and Python through UniFFI bindings.

**Using With Other Applications**
VSS is designed to store application-related metadata. Clients can use the VSS-rust-client directly for this purpose. This can help provide a complete user data recovery solution for applications and enable turn-key multi-device support in the future.

**Hosting**
VSS can either be self-hosted or deployed in the cloud. A service provider hosting VSS for multiple users must be configured with HTTPS, Authentication/Authorization, and rate-limiting.

Application/wallet vendors can either self-host VSS instances or use one of the existing hosted VSS providers.

**Authentication & Authorization**
Currently, the VSS-server supports JWT based authentication and authorization, and can run without authentication for local testing or in trusted setups. The VSS-rust-client supports LNURL-auth & JWT based authentication and authorization. Switching to simple HTTP header authentication is straightforward by adding another implementation. Note that authentication security relies heavily on using HTTPS for all requests.

**Scaling**
VSS itself is stateless and can be horizontally scaled easily. VSS can be configured to point to a PostgreSQL cluster, and further scaling considerations need to be addressed in the PostgreSQL cluster.

**Project Status**
VSS execution is split into two phases: Phase I prioritizes recovery and single-device use, whereas Phase II covers multi-device use. Phase I is ready to use and integrated within LDK Node. Phase II will be subject to monitoring for demand from wallets and may slip to a later date. Refer to LDK-Roadmap for more details.

**Implementation**
Currently, the VSS server has Java and Rust-based implementations and is ready to use. VSS-rust-client is a Rust-based client with support for client-side encryption, key obfuscation, retry mechanisms, and LNURL-auth. VSS is also integrated with LDK Node v0.4.x as alpha support.

**Future**
In the future, LDK and VSS will introduce multi-device support. This will enable users to access the same Lightning node across multiple devices seamlessly.

With synchronized updates and real-time access, users can manage their Lightning wallet from any preferred device, enhancing convenience and accessibility while maintaining consistency across platforms.

**Conclusion**
VSS provides an open-source, server-side cloud storage solution explicitly optimized for non-custodial Lightning/Bitcoin wallets and auxiliary application storage needs. Its key features include multi-device access, recovery capabilities, user privacy protection, and data verifiability. With VSS, wallet developers can focus on creating innovative Lightning wallets without the extra burden of crafting complex live backup storage solutions from scratch.

**Resources**
1. vss-server: A Java and Rust implementation of VSS server with PostgreSQL as the default storage backend.
2. vss-rust-client: A rust client for VSS, with in-built support for retries, client-side encryption and custom auth mechanism.
3. LDK Node: VSS is integrated with LDK Node and has alpha/experimental support.
4. Bindings: On the client side, VSS is also usable with existing LDK Node bindings in Kotlin/swift/python.

**Support**
If you encounter any issues or have questions, open an issue on the GitHub repository. For further assistance or to discuss the development of VSS, you can reach out to us in the LDK Discord in the #vss channel.

LDK: Announcing Versioned Storage Service (VSS)

![](https://m.stacker.news/81855)
**The Scroll #2: Wallet Clustering Basics**
Written by [@not_nothingmuch](https://x.com/not_nothingmuch)

In this new recurring newsletter, The Scroll, we’ll be highlighting the highly technical concepts happening within bitcoin. If this is the type of stuff you nerd for, as it happens, we are still in the market for a [third wizard](https://block.xyz/careers/jobs/4256254008).

The Bitcoin transaction graph has various observable patterns. Some of these patterns have been studied and used to link coins from the same wallet, both in theory and practice.

Every transaction consists of a list of inputs (where the sats are taken from) and outputs (where the input sats are distributed). Inputs refer to the outputs of previous transactions, such as connecting transactions. Outputs lock some amount of Bitcoin with certain spending conditions (i.e., the "address," public key, or output script). Linking coins means identifying the entity that controls the keys to a collection of transaction outputs, spent or unspent.

Section 10 of the Bitcoin Whitepaper, "Privacy,” briefly discusses linking:

"A new key pair should be used for each transaction to keep them from being linked to a common owner."

When the same public key controls more than one coin, these coins are trivially linked since only one entity is supposed to know the private key.

However, address reuse is not the only concern. The paper continues:

"Some linking is still unavoidable with multi-input transactions, which necessarily reveal that their inputs were owned by the same owner."

This is often referred to as the "common input ownership heuristic," CIOH, or the "multi-input heuristic." It's only a heuristic because, unlike the implication in the quote above, counter-examples exist. Although it isn't always true, it often is.

Over the years, more sophisticated methods for clustering have been developed, for example, telling apart change outputs from payments or using larger structures in the transaction graph than just individual transactions. Some of these have been described in academic work, while others remain proprietary. Improved methods can link to more coins or avoid so-called "cluster collapse," where coins belonging to different users are incorrectly connected. Commercial offerings often benefit from additional sources of information, such as KYC data; they don’t necessarily depend on just the privacy leaks that occur in the Bitcoin protocol, but clustering is still the central theme.

This motivates an adversarial framing of privacy, where a deanonymization attack attempts to assign coins to clusters. From this perspective, defending privacy means making it more difficult for the adversary to succeed in correctly assigning coins to clusters. The most notable examples involve collaborative transaction construction, whether it is overtly difficult to guess, as in CoinJoin, or covertly as in PayJoin, or perhaps most prominently just a part of how the software works as with Lightning node transactions, in all cases the simplistic assumption breaks down necessitating a more nuanced analysis.

The adversarial framing also makes it explicit that different adversaries have different capabilities, with the appropriate adversarial model depending on the user’s threat model: Are you more worried about surveillance by an oppressive government or snooping by your transaction’s counterparties?

Future posts will go into more detail on these subjects.

The Scroll #2: Wallet Clustering Basics

Plushie Confidential #2: Rooting for the Little Guy

![](https://m.stacker.news/78333)

Legendary bitcoin developer and Spiral team member Matt Corallo is never short on opinions. In this latest post newsletter following the Great Reshuffling blog of our blog, he’s turned his ire on every solution that isn’t self-custody.

Custodial Solutions Are Not Solutions

Spiral Presents: The Scroll, UTXO Sharing

Spiral's Nerd of the Month: Payjoin

How we got into the bitcoin plushie business, part 1:

Only if and when the single Bitaxe we have running in our silverware drawer mines a block.

Spiral Is Breaking up… Our Blog, that Is

Purchase a Bitkey for 20% off and get a free plushie (promo ends tonight)

Spiral is Hiring Engineers

![](https://m.stacker.news/52714)

Use them as GIFs for whatever you’re up to by searching “herecomesbitcoin” on GIPHY. Or visit herecomesbitcoin.org to download them all. Click "Signal" and "Telegram" at the top to spam your friends into liking you even less.
