Skip to main content
JoinMarket Lead Adam Gibson Sees A Bright Future For Bitcoin Mixing
Skip to main content
Tag: Coinjoin
Skip to main content
Reflecting On The Year In Bitcoin: Our Progress And What We Take For Granted
Skip to main content
A Comprehensive Bitcoin CoinJoin Guide
Skip to main content
JoinMarket Vs. ZeroLink And The Road To Decentralized Bitcoin Privacy Through CoinJoin
Skip to main content
This Tool Can Protect Your Privacy When Using Bitcoin
There is a new privacy tool coming to town: coinswaps on statechains. The original statechain design was proposed by Ruben Somsen at Scaling Bitcoin 2018 in Tokyo. I will summarize quickly, but Aaron van Wirdum has a very thorough explainer of the original concept here. The general idea is to have a facilitating entity (the statechain operator) create a 2-of-2 multisig address with a user to facilitate the off-chain transfer of a UTXO. The user then transfers their private key for the 2-of-2 to a new user. The statechain entity would be informed of when this happens and at that point will only allow the new owner to transfer the funds out. So the whole idea is to transact by literally transferring the private key itself and have the state chain operator enforce current ownership.
And just like Lightning Network channels, each user has a pre-signed transaction allowing them to take unilateral control of the UTXO after a time lock has expired. This way if the statechain operator were to disappear, the funds wouldn’t be trapped in that 2-of-2 forever. But this backup option has to be balanced against the risk of one of the parties trying to misuse their pre-signed transaction to steal the funds. Somsen’s proposal depends on eltoo in order to facilitate the new owner replacing the previous owner’s pre-signed closure transaction in the event that the previous owner tries to steal back the funds. The last major part of the statechain design is a chain of signatures from one owner to another that starts with the original owner and goes all the way to the current one. This is passed from one owner to another and appended in parallel with each transaction so everyone can keep a local copy proving legitimate transfer and, in the case of the current owner, that they are in fact the legitimate owner.
Because of the dependence on eltoo and the fact that soft forks tend not to happen overnight, CommerceBlock began work on implementing a variant of statechains in 2020 that does not depend on eltoo. In place of eltoo allowing the most recent transaction to replace prior ones, they have implemented a decrementing nLocktime scheme called Mercury. The idea is that the original owner’s closure transaction is timelocked to a period of x blocks into the future; they cannot execute their transaction to take back the funds until the blockchain has reached this threshold. And then on the next ownership transfer, the new owner’s transaction is timelocked to x-1. This allows the current owner to submit their closure transaction to the chain before the original owner’s becomes valid to submit. As further ownership transfers take place, the timelocks continue decrementing (x-2, x-3, etc), guaranteeing that the current owner can always act before any of the previous owners’ transactions unlock. This removes the requirement for eltoo, but introduces a limitation in transferring statechains between owners: you can only decrement the timelocks so many times before it cannot be lowered anymore; at some point, the future, minus some amount of time (blocks), becomes equal to the present (the nLocktime is the current blockheight). At this point users must close out the statechain or older owners will be able to steal the coins as those earlier nLocktime transactions reach their locktime maturity and become valid.
Another key difference between Somsen’s original design and Mercury is how the key generation is handled. Instead of using an obvious 2-of-2 multisig script, Mercury implements ECDSA-MPC (elliptic curve digital signature algorithm multi-party computation). You can think of this as functionally similar to a MuSig address using Schnorr, except in Schnorr’s case users simply add two public keys together in order to create an address both are required to sign for. With ECDSA-MPC, the key generation is a more interactive process with multiple steps. In the end they functionally produce the same result: a single public key that is not obviously a multisig and where both parties involved have a share of the matching private key needed to sign a transaction.
The transfer process utilizing ECDSA-MPC is an interactive process where instead of the original owner explicitly transferring an existing private key as described in Somsen’s proposal, the statechain operator and the sender collaborate through ECDSA-MPC to generate a private key via keyshares. Crucially, there is more than one set of possible keyshares that can generate that same private key. So the statechain operator then recreates the private key with the recipient, but by making different keyshares. The statechain operator then deletes the keyshare they held that corresponds to the previous owner. CommerceBlock enforces this with an HSM (hardware security module), although this doesn’t remove all trust. This way if the statechain is operating honestly, it is literally incapable of signing a closure transaction with a past owner because the keyshare it currently holds does not work with past owner’s keyshare to create a valid signature. Also in the case of such collusion, public proof would be publishable showing that the statechain entity has acted dishonestly. This is a reputational disincentive to do so.
How does the public proof work? CommerceBlock has previously designed a variation of Opentimestamps called Mainstay. Opentimestamps is just a protocol for taking any arbitrary data and including it in a very large merkle tree with the root committed to a Bitcoin transaction. The problem with Opentimestamps is that the tree is completely unordered; things just get added to the end of the tree as they come in. This means it provides no guarantees that conflicting information isn’t committed to by the same anchoring transaction in the blockchain. What Mainstay does is effectively assign canonical “slots” in the merkle tree for specific pieces of data, for example an oracle attesting to the outcome of a sports game. Everyone can know which “slot” to check for that specific oracle and can then ignore any conflicting timestamps not in that slot. This allows people to attest to something with a timestamp without leaving open the possibility of timestamping conflicting things to reveal selectively (if you can write anywhere in the merkle tree, you could have the real timestamp in one place while pointing to a bogus one elsewhere). Every transfer of a Mercury statechain is attested to in a specific mainstay slot in order to provide a timestamped proof of current ownership that can be published if the statechain entity acts dishonestly.
Now that the details of the statechain implementation are out of the way, onto the interesting part: coinswaps. The general distinction historically made between coinjoins and coinswaps are that a coinjoin is an explicit and publicly visible use of privacy enhancing techniques occurring in a single transaction, while a coinswap is generally thought of as covert and, in the cooperative case of success, not a publicly-visible use of a privacy technique occurring across multiple separate transactions. The whole world can see when a UTXO goes into a coinjoin, but if implemented as generally discussed previously, no one except the participants would know when a UTXO is involved in a coinswap.
The coinswap implementation built on top of Mercury statechains breaks this clear distinction between coinjoins and coinswaps in terms of this overt versus covert privacy property. Transfers of statechains are recorded in the Mainstay commitments, so adversarially you have to assume that it’s public knowledge each time a statechain changes owners. But each transfer could also be a coinswap with any other statechain transferred in the same block interval. So in terms of anonymity tools, this becomes a sort of Frankenstein’s monster combining the anonymity properties of coinjoins while using the mechanism of a coinswap to conduct the exchange of UTXOs off chain. It uses a “coinswap” off chain on top of a statechain to emulate similar anonymity properties of a coinjoin without incurring an on-chain fee for each swap.
Coinswaps on Mercury statechains are essentially just regular statechain transfers with some fun cryptographic magic to make them anonymous. When you register a UTXO for a typical coinjoin (like Whirlpool or Wasabi), you register a UTXO as an input and then receive a blinded cryptographic credential you can use to create an output in the coinjoin to get your coins back over a new network connection to protect your privacy against the coordinator. This same coordination is approximated in Mercury’s scheme by registering statechains, receiving blind tokens and then querying the coordinator to be randomly assigned a new address to transfer their statechain to. There is even a chance of receiving your own statechain back to yourself. It’s random. After that it’s essentially just everyone signing off on their statechain transfers atomically, just like a coinjoin.
In the end what we have here is something very counterintuitive and at a strange point in the “trust spectrum” of Bitcoin tools that people probably aren’t used to considering deeply. Strictly speaking on a technical level, what is happening is a coinswap; coins are covertly being swapped without leaving a direct on-chain fingerprint that a swap of UTXOs is happening. But because of the Mainstay commitment to all transfers and the heuristic analysis potential of which statechains transferred owners in different time periods, you can infer the coinswap occurred, thereby reducing the anonymity set gains to be equivalent to a standard coinjoin. But you don’t have to pay fees on chain for each “coinjoin.”
To really drive home the point of the “strange point,” arguably with a single entity functioning as the statechain operator you could view this as approximating a custodial arrangement. But because of the HSM-enforced keyshare deletion, Mainstay attestations and the pre-signed closure transactions, users always have a path of unilateral exit from the system as long as the operator doesn’t collaborate with a prior statechain owner to defraud the legitimate owner.
The best way I can think to describe the trust model is to paraphrase Tom Trevethan from CommerceBlock: “This aims to occupy the middle ground between a fully custodial mixer and a fully trustless coinjoin in terms of privacy tools.” There is undeniably some degree of trust in the statechain operator, in this case CommerceBlock, to act honestly. But there are also mechanisms in place to publicly alert users of dishonest behavior from them and clear privacy benefits to be gained with a potential fee saving versus pure on-chain coinjoins.
It’s not quite trustless, but it’s also not quite completely trust based. It’s a new spot in the spectrum in terms of privacy tools. Personally, given the underappreciated fact of how widely used centralized mixers still are, I’m interested in seeing where this fits into that ecosystem. There’s a new kid in town.
This is a guest post by Shinobi. Opinions expressed are entirely their own and do not necessarily reflect those of BTC, Inc. or Bitcoin Magazine.
Sparrow Bitcoin Wallet Adds Support To Whirlpool CoinJoin
The open-source desktop wallet now allows users to CoinJoin directly to cold storage after a configurable number of mixing rounds.
Sparrow Wallet, an open-source Bitcoin wallet focused on self-sovereignty and usability, has added support for the Whirlpool CoinJoin implementation in its newest release. Sparrow 1.5.0 allows users to mix unspent transaction outputs (UTXOs) via the new integration, both on the mainnet and testnet Bitcoin networks.
Whirlpool is a Chaumian CoinJoin implementation built by the developers of Samourai Wallet. Like other implementations, it allows Bitcoin users to enjoy forward-looking privacy by breaking assumptions blockchain observers may have about their coins and ownership.
At its core, a CoinJoin is a Bitcoin transaction, albeit a special one, in which different people trustlessly combine their inputs into the same transaction, later receiving their dutiful outputs. It seeks to break transaction heuristics that chain analysis companies use to cluster addresses together in the hopes of breaking the pseudonymity provided by Bitcoin.
By implementing Whirlpool, Sparrow increases the reach of that CoinJoin implementation into more users hence helping increase liquidity in the protocol and, at large, improve the fungibility of all bitcoin. Fungibility is a central aspect of money that prevents two coins, or UTXOs in Bitcoin, from being distinguished from each other or preferred over one another.
Sparrow’s new release also allows users to send their CoinJoin outputs to an external, open wallet after a configurable number of mixing rounds, for example, a cold storage wallet, and an option to optimize transactions for privacy (with Stonewall) or efficiency. Additionally, the desktop wallet now provides a simple privacy analysis of a constructed transaction before sending and a better UX for its Tor integration.
As a censorship-resistant technology, ensuring the fungibility of coins and the privacy of users of the Bitcoin network is paramount to prevent coercion and secure individual liberties. Whereas totalitarian governments have for centuries been able to enforce arbitrary rules due to their control over people’s money, Bitcoin provides people with the power to fight for human rights causes and protect personal freedom.
New Implementation For Bitcoin Mixing Service CoinJoin Improves Sybil Resistance
The Bitcoin Optech newsletter provides readers with a top-level summary of the most important technical news happening in Bitcoin, along with resources that help them learn more. To help our readers stay up-to-date with Bitcoin, we’re republishing the latest issue of this newsletter below. Remember to subscribe to receive this content straight to your inbox.
This week’s newsletter follows up on a previous description about fidelity bonds in JoinMarket and includes our regular sections with the summary of a Bitcoin Core PR Review Club meeting, suggestions for preparing for taproot, announcements of releases and release candidates, and descriptions of notable changes to popular infrastructure projects.
News
- Implementation of fidelity bonds: the JoinMarket 0.9.0 implementation of coinjoin includes support for fidelity bonds. As previously described in Newsletter #57, the bonds improve the sybil resistance of the JoinMarket system, increasing the ability for coinjoin initiators (“takers”) to choose unique liquidity providers (“makers”). Within days of release, over 50 BTC (currently valued at over $2 million USD) had been placed in timelocked fidelity bonds.
Although the specific implementation is unique to JoinMarket, the overall design may be useful in other decentralized protocols built on top of Bitcoin.
Bitcoin Core PR Review Club
In this monthly section, we summarize a recent Bitcoin Core PR Review Club meeting, highlighting some of the important questions and answers. Click on a question below to see a summary of the answer from the meeting.
Prefer to use txindex if available for GetTransaction is a PR by Jameson Lopp which improves the performance of GetTransaction (and, by extension, the getrawtransaction RPC for users) by utilizing the transaction index (txindex) when possible. This change fixes an unexpected performance loss in which a call to getrawtransaction on a txindex-enabled node is significantly slower when called with the hash of the block that includes the transaction. The review club evaluated the cause of this performance issue by comparing the steps to retrieve a transaction with and without txindex.
- What are the different ways GetTransaction can retrieve a transaction from disk?
The transaction can be retrieved from the mempool (if unconfirmed), by retrieving the entire block from disk and searching for the transaction, or by using txindex to fetch the transaction from disk by itself. - Why do you think that performance is worse when the block hash is provided (when txindex is enabled)?
Participants guessed that the bottleneck was in the deserialization of the block. Another process unique to fetching the entire block – albeit less time-consuming – is a linear search through the entire list of transactions. - If we are looking up the transaction by block hash, what are the steps? How much data is deserialized?
We first use the block index to find the file and byte offset necessary for accessing the block. We then fetch and deserialize the entire block and scan through the list of transactions until we find a match. This involves deserializing about 1-2MB of data. - If we are looking up the transaction using the txindex, what are the steps? How much data is deserialized?
The txindex maps from transaction id to the file, block position (similar to the block index), and the offset within the blk*.dat file where the transaction starts. We fetch and deserialize the block header and transaction. The header is 80B and allows us to return the block hash to the user (which is information not stored in the txindex). The transaction can be any size but is typically thousands of times smaller than the block. - The first version of this PR included a behavior change: when an incorrect block_index is provided to GetTransaction, find and return the tx anyway using the txindex. Do you think this change is an improvement, and should it be included in this PR?
Participants agreed that it could be helpful but misleading, and that notifying the user of the incorrect block hash input would be better. They also noted that a performance improvement and behavior change would be best split into separate PRs.
Preparing For Taproot #8: Multisignature Nonces
A weekly series about how developers and service providers can prepare for the upcoming activation of taproot at block height 709,632.
In last week’s column, we wrote about multisignatures and gave an example using MuSig2. Our description appears to have been technically correct, but several cryptographers who contributed to MuSig2 worried that the way we suggested using it was dangerous. We updated our description to address their immediate concerns and then began researching the issue more thoroughly. In this post, we’ll look at what we learned may be the greatest challenge for safely implementing multisignatures: avoiding nonce reuse.
To validate a signature in Bitcoin, you fill out a publicly known equation with the signature, the message that was signed (e.g. a transaction), your public key, and a public nonce. It’s only possible for you to balance that equation if you know your private key and the private form of the nonce. Thus anyone seeing such a balanced equation considers the signature for that message and public key to be valid.
The motivation for including the signature and the message in the equation is obvious. The public key is a stand-in for your private key. What’s the public nonce for? If it wasn’t there, every other value in the equation except for your private key would be known, meaning we could use basic algebra to solve for that single unknown value. But algebra can’t solve for two unknown values, so the private form of the nonce serves to keep your private key secret. And, just as your public key is a stand-in for your private key in the signature equation, the public form of the nonce stands in for its private form.
Nonces in this context are not only numbers used once but numbers that must only ever be used once. If you reuse the same nonce with two different signatures, the two signature equations can be combined, the nonce can be canceled out, and someone can again solve for the only remaining unknown value—your private key. If you use BIP32 standard derivation (non-hardened derivation), which likely nearly all multisignature wallets will do, then the revelation of one private key means the reveal of every other private key in the same BIP32 path (and possibly in other paths as well). That means a multisignature wallet which has received bitcoins to a hundred different addresses will have every one of those addresses compromised for the signer who reuses even a single nonce.
Single-sig wallets, or those using script-based multisig, can use a simple trick to avoid reusing nonces: they make their nonce dependent on the message they’re signing. If there’s any change to the message, the nonce changes, and so they never reuse a nonce.
Multisignatures can’t use this trick. They require each cosigner contribute not just a partial signature but also a partial public nonce. The partial public nonces are combined together to produce an aggregated public nonce which is included with the message to sign.
That means it’s not safe to use the same partial nonce more than once even if the transaction stays the same. If, the second time you sign, one of your cosigners changed their partial nonce (changing the aggregated nonce), your second partial signature will effectively be for a different message. That reveals your private key. Since it’s impossibly circular for every party to make their private nonce dependent on all the other party’s partial public nonces, there’s no simple trick to avoid nonce reuse in multisignatures.
At first glance, this doesn’t seem like a big problem. Just have signers generate a new random nonce each time they need to sign something. This is harder to get right than it sounds—since at least 2012, people have been finding bitcoin-losing bugs in wallets that depended on generating random nonces.
But even if a wallet does generate high-quality random nonces, it has to ensure each nonce is only used a maximum of a single time. That can be a real challenge. In the original version of our column last week, we described a MuSig2-compatible cold wallet or hardware signing device that would create a large number of nonces on its first run. The wallet or device would then need to ensure each of those nonces was never used with more than one partial signature. Although that sounds simple—just increment a counter each time a nonce is used—it can be a real challenge when dealing with all the ways software and hardware can fail by accident, not to mention how they can be affected by external and possibly malicious intervention.
Perhaps the easiest way for a wallet to reduce its risk of nonce reuse is to store nonces for as short a time as possible. Our example from last week suggested storing nonces for months or years, which not only creates a lot of opportunity for something to go wrong but also requires recording nonces to a persistent storage medium which may be backed up and restored or otherwise put into an unexpected state. An alternative way to use MuSig2 would be to only create nonces on demand, such as when a PSBT is received. The nonces could be kept in volatile memory for the short time they were needed and so be automatically destroyed (made unreusable) in several cases of the unexpected happening, such as a software crash or a loss of power.
Still, the cryptographers working on this problem seem very concerned about the lack of foolproof way to prevent nonce reuse in the original MuSig protocol (MuSig1) and MuSig2. MuSig-DN (deterministic nonce) does offer a solution, but it’s complex and slow (an alpha implementation takes almost a second to create a nonce proof on a 2.9 GHz Intel i7; it’s unknown to us how long that might take on a 16 MHz hardware signing device with a much less sophisticated processor).
Our advice to anyone implementing multisignature signing is to consider stopping by the #secp256k1 IRC room or another place where Bitcoin cryptographers congregate and describe your plans before you make any major investments of time or resources.
Releases And Release Candidates
New releases and release candidates for popular Bitcoin infrastructure projects. Please consider upgrading to new releases or helping to test release candidates.
- C-Lightning 0.10.1 is a release that contains a number of new features, several bug fixes, and a few updates to developing protocols (including dual funding and offers).
- Bitcoin Core 22.0rc2 is a release candidate for the next major version of this full node implementation and its associated wallet and other software. Major changes in this new version include support for I2P connections, removal of support for version 2 Tor connections, and enhanced support for hardware wallets.
Notable code and documentation changes
Notable changes this week in Bitcoin Core, C-Lightning, Eclair, LND, Rust-Lightning, libsecp256k1, Hardware Wallet Interface (HWI), Rust Bitcoin, BTCPay Server, Bitcoin Improvement Proposals (BIPs), and Lightning BOLTs.
- Bitcoin Core #21528 aims to improve the p2p propagation of full node listening addresses. Exposure to a diverse set of addresses is important for nodes to be protected against network partitions such as eclipse attacks. When Bitcoin Core nodes receive an address message containing 10 or fewer addresses, they forward it to 1 or 2 peers. This is the primary technique used to self-advertise addresses, so sending to peers that would not relay these addresses would effectively stop or “black hole” the propagation through the network. Although propagation failures cannot be prevented in the malicious case, this patch improves address propagation for the honest cases, such as for block-relay-only connections or light clients.
This update identifies whether or not an inbound connection is a candidate for forwarding addresses based on whether it has sent an address related message over the connection, such as addr, addrv2, or getaddr. This behavior change could be problematic if there is software on the network that relies on receiving address messages but never initiates an address-related message. Therefore, the author took care to circulate this proposed change before it was merged, including posting it to the mailing list and researching other open source clients to confirm compatibility. - LND #5484 allows storing all data in a single external Etcd database. This improves high-availability deployments by making cluster leadership changes instantaneous. The corresponding LND clustering documentation was previously covered in Newsletter #157.
- Rust-Lightning #1004 adds a new event for PaymentForwarded that allows tracking when a payment has been successfully forwarded. Since successful forwarding may earn fees for the node, this allows tracking that income for the user’s accounting records.
- BTCPay Server #2730 makes the amount optional when generating invoices. This simplifies the payment flow in cases where the operator delegates the choice of the amount to the user, e.g. when topping up an account.
Find the original post here.
Please subscribe to the Bitcoin Optech newsletter directly to receive this content straight to your inbox every month.
The Wasabi Wallet 2.0 Planned Rollout
After much anticipation, the Wasabi Wallet team unveils the planned rollout for Wasabi Wallet 2.0.
Wasabi Wallet 2.0, a highly anticipated update to the Bitcoin privacy wallet, is set to rollout in the next 5 to 14 weeks, according to a blog post sent to Bitcoin Magazine. The post also laid out a detailed rollout plan that dictates this time estimation, and is defined by a set of milestones that must be reached in order to be released.
“We’ve created three milestones before Wasabi Wallet 2.0 is released in its complete and final version:
- Wasabi Wallet 2.0 Preview will contain a minimal subset of features, only the most fundamental ones. This milestone aims to have a rudimentary version of the software released so as to start testing and fix all the initial bugs. This should only be used on the Bitcoin Testnet network.
- Wasabi Wallet 2.0 Release Candidate will include all features and will be available to the public for reviewing and testing. We will work on this version until the quality of the software is sufficient.
- Wasabi Wallet 2.0 Final Release (Series) will be the first version of the 2.0 series.”
Wasabi, a free and open source wallet, utilizes CoinJoin mixing to enhance user privacy and obscure transactions. This privacy centered focus is expanded upon in the coming release: “We are aiming to offer privacy for everyone and to make privacy the default.”
The update will also include a full replacement of the user interface, “which will be much more intuitive,” according to the release.
In addition to the milestones and time estimation, the release also contained a video demonstration of the updated UI, and a discussion of current progress.
Wasabi Wallet has also published the research paper for the WabiSabi CoinJoin protocol, which you can find here.
In a previous announcement of the update, Wasabi Wallet stated, “Wasabi 2.0 is a next-generation Bitcoin privacy wallet that will finally bring confidentiality within reach of any Bitcoin users, not just the technically inclined. Wasabi 2.0 may be Bitcoin’s last stand in the fight for becoming ‘good money.’”
A Privacy Standard In Bitcoin, And How It Will Protect Bitcoin Users
There exists a security problem inherent to Bitcoin’s transparency that needs to be addressed by the community.
Bitcoin has a fungibility issue; it is transparent, which can be both good and bad. Transparency allows everyone to check how many bitcoin are in circulation and to ensure that nobody is cheating.
But it also allows bad actors (such as governments) to monitor the chain and compromise users’ privacy.
When a new user buys bitcoin using a regulated, know your customer (KYC) exchange, his information (including Bitcoin address, government ID and other identifying information) is being provided to his local government. This information allows them to view the activity of his wallet, since his coins are linked to his identity. It also allows easier seizure in case of a government ban on bitcoin.
This is obviously dangerous, especially if you live under an authoritarian government. There are options available for buying bitcoin without revealing your identity and compromising your privacy, but those are less popular and are usually harder to follow.
This calls for a privacy standard in Bitcoin: Where a majority of wallets enable privacy features by default, making it much harder for chain analysis firms to link transactions and wallets to real-life identities and/or previous transactions. Users must make sure each and every one of our transactions are private. This can be achieved by utilizing tools like CoinJoins, PayJoins and other privacy enhancing techniques. While these tools are no silver bullet, using them in the right way can allow users to achieve a remarkable amount of privacy. Stealth addresses also have an important role in the privacy standard, as they allow users to share their addresses without needing to worry about them being linked to their digital or physical identity. Running your own node will also play an important part, dramatically reducing the possibility that a node will be used to link your transaction history to your real-life IP address, which can be used to deanonymize your transactions.
If we are able to do that, we will be able to disarm chain analysis companies. Chain analysis firms specialize in invading Bitcoin users’ privacy. They do it using publicly available on-chain data and then cross reference it with other data, such as KYC records, in order to establish a deterministic link between a user’s wallet activity and his real-life identity.
The worst thing about those companies is that they don’t work exclusively for governments, they work with whoever is willing to pay them. Whether it’s a government, advertising company or a creepy stalker, it doesn’t matter to them. Those companies are pure poison for Bitcoin and are completely unnecessary in the Bitcoin ecosystem; they only bring harm and suffering to it.
There are plenty of users that are targeted by these companies simply because they stated they hate the idea of chain surveillance; a good example for this would be DarkDotFail’s donation address being flagged in multiple exchanges that have a partnership with these companies. Chain surveillance is not about money laundering, crime or any other illegal activity, it’s about creating an age where nobody has the right to keep their finances private. A Bitcoin privacy standard aims to kill these purely evil companies; but this requires the Bitcoin community to come together, put the ego aside and work together to create, use and promote tools that will enable this effort.
The hardest part of standardizing Bitcoin privacy would be making people acknowledge Bitcoin’s faults when it comes to privacy. Many will just avoid talking about it, and some don’t even know it exists! Creating such a standard would require large community consensus, not because we need to change the protocol, but because we need to make people acknowledge the fact that their privacy is being compromised. A privacy standard would also discourage discrimination against those who want to keep their bitcoin finances private (see this post).
They can censor a minority but not a majority.
We need more wallets like this, and more enthusiasm toward building and using Bitcoin privacy tools. Number-go-up is not all that matters in this peaceful revolution; privacy matters too.
This is a guest post by Yonatan. Opinions expressed are entirely their own and do not necessarily reflect those of BTC, Inc. or Bitcoin Magazine.
What are Bitcoin mixers, and why do exchanges ban them?
One of the original allures of cryptocurrency is the narrative that using them provides the sender or recipient anonymously, but this is a common misconception within the sector.
In reality, Bitcoin (BTC) and many other cryptocurrencies are easily traceable.
Proof of this came earlier this week when on April 27, U.S. authorities arrested the mastermind of Bitcoin Fog, a darknet-based BTC mixing service. Authorities were able to capture the operator after analyzing ten years of blockchain data.
One doesn’t need to be a forensic analyst to know that every single transaction is tied up to addresses on the blockchain and that they will stay there forever. While government agencies cannot determine the IP address or personal data from the address, these coins usually end up being used for products or service payments. This is the trail that leads back to the sender and recipient.
In the case of Bitcoin Fog, law enforcement was able to identify server hosting expenses paid using digital currency. Bitcoin mixing services such as Bitcoin Fog allow users to mix their coins with other users, making it almost impossible to detect the destination addresses. This obfuscates the ties between the inputs and output addresses, providing a better level of privacy.
Mixing services are offered in a wide range of methods, including fully centralized solutions where trust is required, to Coinjoin mixers, which depend on a large group of users to self cooperate and act simultaneously. There’s even the possibility of trading on decentralized exchanges (DEX) to virtually eliminate any possible tracing.
Mixers do present a few risks
Centralized mixers offer the obvious single point of failure problem. Even if one trusts that the entity is using multisig addresses, if the service is willing to share its data or has been breached, their users will lose their privacy.
CoinJoin solved this problem by combining the inputs of multiple users into a single transaction. The service will then take those coins, craft them into a transaction, and have each participant sign before broadcasting it to the network. These transactions are then merged into one, and each user gets the original quantity in return. However, no one can see the origin of those coins, not even the entity that merges the transaction.
Even though CoinJoin isn’t exactly untraceable, it provides plausible deniability, as no one can point out which entity owns each output. The larger the number of participants, the higher the degree of deniability.
Some cryptocurrency users also require anonymity for sending tokens to their wallets, and Wasabi Wallet has long been used for its embedded CoinJoin functionalities.
While its infrastructure is technically centralized, its design assures that the operators cannot deanonymize users or steal any funds. At the moment, the Wasabi wallet is only available for desktop solutions, so as is the case with anything in cryptocurrency, beware of clones!
A similar service is provided by Samourai wallet, which also offers a Chaumian CoinJoin mixing service, called Whirlpool. To achieve a full-privacy solution, users have to connect the Samourai wallet to their own full Bitcoin node. However, it does offer desktop and mobile versions.
Even though these mixing services aren’t illegal in most jurisdictions, some exchanges and services might refuse users linked to addresses associated with coin mixing activities.
As more people realize the importance of achieving a certain degree of privacy for self-protection, the fewer incentives companies will have to deny their clients to use mixers.
The views and opinions expressed here are solely those of the author and do not necessarily reflect the views of Cointelegraph.com. Every investment and trading move involves risk, you should conduct your own research when making a decision.