
This article continues the discussion started in "AML Terrorism: The Dark Side of Transaction Monitoring". In that piece I examined how commercial AML systems work, why their methodologies are opaque, and how their "terror" affects ordinary users. Here I will not repeat those arguments but instead develop one specific idea that has recently turned into a daily operational challenge for us at Rabbit.io. It is the "dirty bitcoin" epidemic: how AML algorithms have tainted almost every Bitcoin address, and what users can do about it.
In classical sociology there is the "six degrees of separation" theory: any two people on Earth are connected through a chain of no more than five mutual acquaintances. AML systems apply a similar logic to Bitcoin - but with destructive consequences. Instead of connections spreading through the network, it is risk contamination that spreads.
The algorithms used by companies such as Chainalysis, Crystal, or Elliptic operate on a principle similar to infection. If your address receives funds from an address associated with something illicit, your address also becomes toxic ("high-risk" label). If you later send bitcoin to someone else, their address inherits part of that risk as well. And so on. The "high-risk" label spreads through chains of intermediate addresses like a virus.

In theory, this mechanism could be useful: it prevents criminals from simply passing funds through a few intermediaries to wash away their history. In practice, when applied without context, the transaction graph gradually pulls more and more addresses to the "dark side", including those whose owners have done absolutely nothing illegal.
The situation becomes even worse because completely ordinary transactions often fall into the high-risk category.

At rabbit.io, we see how problems related to this phenomenon are increasingly interfering with real-world operations. In the past, seeing a client address marked as "high risk" was a rare exception. Now we encounter it two or three times a day. But only in Bitcoin. In other blockchains we support, we do not see such abnormal AML alerts.
The explanation is simple: Bitcoin has been monitored longer and more closely than anything else. It is the oldest public blockchain, and the entire blockchain analytics industry historically grew around it. The database of labeled addresses is therefore largest here.
Bitcoin's UTXO architecture also lends itself perfectly to clustering heuristics, unlike account-based blockchains (Ethereum, Solana, Tron, etc.) where relationships are less obvious. In Bitcoin, a single transaction with multiple inputs can automatically merge dozens of previously independent addresses into one cluster.
Some Bitcoin users treat an address like a bank account and use the same one for years. This habit turns the address into a persistent public identifier that gradually accumulates everything: transaction history, connections with services, and labels added by third parties. When an AML checker later interprets those connections in the most aggressive possible way, that history becomes a dossier - and the dossier receives a stamp: "high risk".
The growing number of addresses failing AML checks cannot be explained by a sudden surge of criminals among Bitcoin users. A far more plausible explanation is that a critical mass has been reached, and the contamination network has become so dense that finding a completely "clean" address - one that has never interacted with anything suspicious - may already be difficult. And in the long run, if AML methodologies do not change, such addresses may disappear entirely.
Every time a client exchanges something with Rabbit.io for bitcoin and the AML checker shows a red flag for the client's Bitcoin address, we face a dilemma.
Ignoring the flag is not an option. If we send funds to a flagged address, our own cluster of addresses may be marked as having interacted with a high-risk counterparty. That would create problems for other clients who have nothing to do with the situation. We cannot allow that.
The only solution is to ask the client for another address. But this is where things become absurd. The client's second address may also be flagged. And this is not a hypothetical scenario. These are real cases from our daily practice.
The bitcoins exist. The receiving address exists. But we may not send the coins.
Has Bitcoin reached a dead end? Not at all. The solution to this problem has existed in the protocol since its earliest days. Some users simply overlook it.
Never use the same Bitcoin address twice.
This rule was formulated by Satoshi Nakamoto himself back in 2009. The Bitcoin Wiki, maintained by the community since the early years of Bitcoin, explicitly notes that the term "bitcoin address" is somewhat misleading because it creates the impression that it can be reused indefinitely like an email address. In reality, each address should be treated more like a one-time payment invoice: use it once and forget it.
Consider how AML clustering works. One of its main tools is the common-input ownership heuristic: if a transaction uses multiple addresses as inputs, the system assumes they belong to the same owner. Another is the change heuristic: the system attempts to identify which output is change and attaches that new address to the sender's cluster.
Both heuristics rely on connections.
A fresh address is a blank page - no history and no connections. If we check such an address in rabbit.io before sending funds, its risk score will be zero. Our system will automatically send the bitcoins there, and the exchange will proceed as quickly and smoothly as possible.
Not all wallets are equally helpful here.
Type one: wallets that cannot do this
This category includes paper wallets: you generate one address, write down its private key on paper, receive all your bitcoins there, and never spend them. From an AML perspective this is the worst option. Your address accumulates the entire history of incoming payments, along with all the questions that may arise about them - questions that AML systems rarely ask before applying the "high-risk" label.
A similar situation exists with many custodial services and exchanges that assign a user a single static deposit address and do not allow it to be changed. If someone sends something questionable to that address, the address may become unusable in many contexts.
It should be noted that some exchanges periodically rotate deposit addresses. Coinbase generates a new address after each transaction, and Kraken allows users to create new addresses manually. But on exchanges such as Bitstamp and BitMEX the deposit address is assigned without the possibility of independent change.
Type two: wallets where a new address requires user action
Non-custodial software wallets usually support generating new addresses, but some of them do so only when requested by the user. The wallet displays the current address and next to it a button "Get new address". This requires discipline.
Bitcoin Core - the reference implementation of Bitcoin - falls into this category. Technically it allows full control over addresses. But the interface does not actively encourage address rotation: you must consciously press the button each time.
Type three: wallets that do it automatically
For many users these wallets are the standard. Each time you open the "Receive" tab, the wallet shows a newly generated address. The previous one remains in the history but is no longer offered for incoming payments. The user does not need to think about it: protection is automatic.
All addresses in such wallets are derived from a single seed phrase. In other words, "many addresses" does not mean "many backups". Each address has its own key, but one seed phrase and one backup can restore them all.
Examples include the desktop wallets Sparrow Wallet, Wasabi Wallet, and Electrum, as well as the mobile wallet BlueWallet. I mention these specifically because their interfaces are designed to discourage address reuse: previously used addresses are moved out of view. In reality, there are many more wallets that automatically generate new addresses after each incoming transaction.
For a long time I naively assumed that everyone used wallets like this. But the exchange activity I see - where users repeatedly provide addresses with long transaction histories - suggests otherwise. That is why I decided to discuss these wallets in more detail.
But what if the bitcoins are already sitting on an address that has been labeled high risk? In that case the problem is no longer just receiving funds. It is sending them. No regulated platform wants to accept funds from it. What can you do?
Bitcoin offers a solution for this scenario as well: the Lightning Network. Transactions in Lightning are not recorded on the public Bitcoin blockchain. AML systems that analyze the transaction graph cannot see them. Your funds move from the "tainted" on-chain environment into a layer where they once again behave like electronic cash, without a public dossier or AML flags.
To use this solution you need to open a Lightning payment channel to a node whose operator is willing to interact with your on-chain address. This could be someone you know or any Lightning enthusiast who does not intend to bring those coins back to the base layer and therefore is not concerned about potential AML issues in on-chain transactions. Thanks to such enthusiasts, Bitcoin still preserves its core property of fungibility: 1 BTC always equals 1 BTC, regardless of what commercial AML systems attempt to impose.

Nodes you can open Lightning channels to can be found on specialized websites such as 1ML, Magma, and Lightning Network Plus. In some cases you must first arrange the channel with the node operator, while in others you can open a channel without prior coordination.
Once your bitcoins are in the Lightning Network, you can freely exchange them for any other crypto asset on rabbit.io. You will not face any additional inconvenience on our side.
We have reached an absurd situation. By continuously expanding their databases of "risky" addresses, AML systems are beginning to suffocate the normal use of Bitcoin itself.
This is probably not malicious intent. More likely it is the result of short-sighted design - an inevitable consequence of systems that blindly propagate "high-risk" labels combined with many years of continuous monitoring of the oldest blockchain.
There is no point in trying to fight AML systems directly. They also attempt to serve a purpose. But it is possible to adapt to their shortcomings, and the tools for doing so are built into Bitcoin itself.
Make one simple rule a habit: one address - one incoming transaction. Choose a wallet that enforces this automatically. And remember that the Lightning Network can always help when the on-chain environment becomes too constrained.
This is how you help keep Bitcoin free and liquid despite all attempts to surround it with red flags.