# State of the transaction privacy work in Bitcoin **URL:** \ **Category:** Protocol Design\ **Tags:** privacy, coinjoin\ **Created:** [June 18, 2026, 9:27pm UTC](https://delvingbitcoin.org/t/state-of-the-transaction-privacy-work-in-bitcoin/2622 "2026-06-18T21:27:51Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![nkaretnikov](https://delvingbitcoin.org/letter_avatar_proxy/v4/letter/n/ecd19e/32.png) [@nkaretnikov](https://delvingbitcoin.org/u/nkaretnikov)\ **Post date:** [June 18, 2026, 9:27pm UTC](https://delvingbitcoin.org/t/state-of-the-transaction-privacy-work-in-bitcoin/2622/1 "2026-06-18T21:27:51Z")
I would like to better understand what’s happening around transaction privacy in Bitcoin. My perception is that it’s all happening in sidechains, L2s, or requires wallet support. Examples: Confidential Transactions (sidechain), Silent Payments (wallet), PayJoin (wallet), CoinJoin (wallet). There is also related work, like Cross-Input Signature Aggregation, that would make CoinJoin cheaper, but isn’t a privacy feature by itself. I assume people moved on from L1 privacy work for several reasons: - Lightning is popular, and offers some privacy that many consider sufficient - Implementation complexity, plus a focus on transparency and a fixed supply (see past inflation/counterfeiting bugs in privacy-coin implementations) - Concerns about regulatory pressure if transactions become untraceable. Is this now mostly a wallet-layer concern, or are there protocol-level gaps worth filling (like CISA)? Anything else with a realistic shot at adoption that I’ve missed? ---
**Author:** ![nkaretnikov](https://delvingbitcoin.org/letter_avatar_proxy/v4/letter/n/ecd19e/32.png) [@nkaretnikov](https://delvingbitcoin.org/u/nkaretnikov)\ **Post date:** [June 20, 2026, 7:30pm UTC](https://delvingbitcoin.org/t/state-of-the-transaction-privacy-work-in-bitcoin/2622/2 "2026-06-20T19:30:56Z")
It seems there’s ongoing work on CoinSwap. Summary of the protocol: > **[Advancements in On-Chain Privacy](https://opensats.org/blog/developing-advancements-in-onchain-privacy)** > > An impact report from the front-lines of bitcoin development. > **[Coinswap - OpenSats Topics](https://opensats.org/topics/coinswap)** > > Atomic multi-hop swaps that move coins through intermediate keys so the spender of an input cannot be linked to the receiver of the final output. An actively developed implementation: > **[GitHub - citadel-tech/coinswap: Functioning, minimal-viable binaries and libraries...](https://github.com/citadel-tech/coinswap)** > > Functioning, minimal-viable binaries and libraries to perform a trustless, p2p Maxwell-Belcher Coinswap Protocol > **[citadel-tech/coinswap](https://github.com/citadel-tech/coinswap/milestone/1)** > > Functioning, minimal-viable binaries and libraries to perform a trustless, p2p Maxwell-Belcher Coinswap Protocol - citadel-tech/coinswap Protocol spec: > **[GitHub - citadel-tech/Coinswap-Protocol-Specification: Detailed protocol and other technical...](https://github.com/citadel-tech/Coinswap-Protocol-Specification)** > > Detailed protocol and other technical dcumentations of Coinswap. > **[CoinSwap: Transaction graph disjoint trustless trading](https://bitcointalk.org/index.php?topic=321228.0)** > > CoinSwap: Transaction graph disjoint trustless trading An older PoC from Chris Belcher: > **[GitHub - bitcoin-teleport/teleport-transactions: CoinSwap implementation](https://github.com/bitcoin-teleport/teleport-transactions)** > > CoinSwap implementation ---
**Author:** ![nkaretnikov](https://delvingbitcoin.org/letter_avatar_proxy/v4/letter/n/ecd19e/32.png) [@nkaretnikov](https://delvingbitcoin.org/u/nkaretnikov)\ **Post date:** [June 20, 2026, 8:23pm UTC](https://delvingbitcoin.org/t/state-of-the-transaction-privacy-work-in-bitcoin/2622/3 "2026-06-20T20:23:14Z")
Physical devices that allow you to pass Bitcoin offline, like cash. Not a protocol, but worth mentioning. > **[OPENDIME™ – World's First Bitcoin Credit Stick Wallet](https://opendime.com/)** > > The Bitcoin Credit Stick > **[SATSCARD™ – Put SATSCARD in your pocket](https://satscard.com/)** > > SATSCARD puts a stack of sats in your hand. ---
**Author:** ![light](https://delvingbitcoin.org/user_avatar/delvingbitcoin.org/light/32/350_2.png) [@light](https://delvingbitcoin.org/u/light)\ **Post date:** [June 20, 2026, 8:24pm UTC](https://delvingbitcoin.org/t/state-of-the-transaction-privacy-work-in-bitcoin/2622/4 "2026-06-20T20:24:25Z")
Shielded CSV: [https://eprint.iacr.org/2025/068](https://eprint.iacr.org/2025/068) Needs a soft fork that supports building a trustless bridge (e.g. BIP-441) in order to be used trustlessly with BTC. ---
**Author:** ![cmp\_ancp](https://delvingbitcoin.org/letter_avatar_proxy/v4/letter/c/b3f665/32.png) [@cmp\_ancp](https://delvingbitcoin.org/u/cmp_ancp)\ **Post date:** [June 20, 2026, 8:54pm UTC](https://delvingbitcoin.org/t/state-of-the-transaction-privacy-work-in-bitcoin/2622/5 "2026-06-20T20:54:41Z")
There is an interesting project concerning coinjoin coordination in nostr, making it descentralized and avoiding regulatory pressures. joinstr [joinstr](https://share.google/MhV0i0CeMvv1x0RnB) Also, you commented about LN superficially, but there are different concepts and protocols inside LN that aren’t broad used or implemented today and can bring more privacy in the future. Taproot channels, PTLCs, maybe a gossip that doesn’t doxx UTXOs, LN over Ark, blinded payments over BOLT12 (maybe the most important BOLT12 feature in respect to privacy and one of the least implemented among wallets), trampoline nodes, splices, LSP spec, neutrino and filter based sync tech, etc. LN over Ark may be the UX killer, resolving the inbound liquidity problem and cheapenning multiple channel maintanance (something that increases privacy). ---
**Author:** ![nkaretnikov](https://delvingbitcoin.org/letter_avatar_proxy/v4/letter/n/ecd19e/32.png) [@nkaretnikov](https://delvingbitcoin.org/u/nkaretnikov)\ **Post date:** [June 21, 2026, 12:38am UTC](https://delvingbitcoin.org/t/state-of-the-transaction-privacy-work-in-bitcoin/2622/6 "2026-06-21T00:38:32Z")
PathCoin: > > **[GitHub - AdamISZ/pathcoin-poc: PathCoin (transfer bitcoin without network...](https://github.com/AdamISZ/pathcoin-poc)** > > PathCoin (transfer bitcoin without network interaction) - proof of concept demonstration ---
**Author:** ![Kruw](https://delvingbitcoin.org/user_avatar/delvingbitcoin.org/kruw/32/915_2.png) [@Kruw](https://delvingbitcoin.org/u/Kruw)\ **Post date:** [June 21, 2026, 2:38pm UTC](https://delvingbitcoin.org/t/state-of-the-transaction-privacy-work-in-bitcoin/2622/7 "2026-06-21T14:38:43Z")
> [@nkaretnikov](#): > > My perception is that it’s all happening in sidechains, L2s, or requires wallet support. Examples: Confidential Transactions (sidechain), Silent Payments (wallet), PayJoin (wallet), CoinJoin (wallet). Coinjoin does not require wallet support in the same way as Silent Payments or Payjoins. Receivers of coinjoin payments can use any wallet, while SPs and PJs require software support for both the sender and receiver. Coinjoin is the only transaction type out of your list that provides full privacy. The others leak information: **- Payjoins only hide the common input ownership heuristic from third party observers.** It does not prevent the sender or receiver from tracking each other’s addresses. Unfortunately, PJ actually introduces a privacy footgun: The receiver shares one of their existing UTXOs with the sender to merge with the payment. This gives additional data to the sender that would not necessarily be revealed in a later consolidation. - Alice pays Bob’s bc1paddressx123 - Charlie payjoins with Bob, who reveals he previously received coins at bc1paddressx123 - Bob now has bc1paddressx456 which is a consolidation of Alice and Charlie’s payments - Charlie has now become a custodian of Bob’s secret data (The origin address and value of Alice’s payment) Worse, if Charlie is using an Electrum based mobile wallet to payjoin, Bob’s linked address data also gets [harvested by third parties.](https://x.com/Kruwed/status/2062195325561938295) **- Silent Payments only generate new receiver addresses automatically,** it’s mainly a UX improvement for donations. Unfortunately, SP addresses actually introduce a new privacy footgun: A receiver who shares the same sp1… address with different senders leaks their common on chain identity with off chain data. - Alice pays Bob’s sp1addressx123 (Robert’s pseudonym) - Charlie pays Robert’s sp1addressx123 (Bob’s real name) Even if Bob is careful not to merge these inputs in future payments, Alice and Charlie can each compare the silent payment addresses they have previously sent to and reveal that Robert’s pseudonym is actually Bob. Worse, this leak occurs passively if Alice and Charlie both use the same custodian. The custodian is able to correlate payment relationships between Alice, Bob, and Charlie even if Alice and Charlie don’t know each other. **- Confidential Transactions only hide the value of coins being transferred.** It does not prevent the sender or receiver from tracking each other’s addresses using common input ownership or change heuristics. > [@nkaretnikov](#): > > There is also related work, like Cross-Input Signature Aggregation, that would make CoinJoin cheaper, but isn’t a privacy feature by itself. Similarly, confidential transactions also eliminates the higher relative cost of coinjoins compared to regular payments since creation of even-denomination outputs would no longer be necessary. ---
**Author:** ![nkaretnikov](https://delvingbitcoin.org/letter_avatar_proxy/v4/letter/n/ecd19e/32.png) [@nkaretnikov](https://delvingbitcoin.org/u/nkaretnikov)\ **Post date:** [June 21, 2026, 9:24pm UTC](https://delvingbitcoin.org/t/state-of-the-transaction-privacy-work-in-bitcoin/2622/8 "2026-06-21T21:24:14Z")
I think there are some inaccuracies in what you said. Please correct me if I’m wrong. > [@Kruw](#): > > Coinjoin is the only transaction type out of your list that provides full privacy. “Full privacy” is an overstatement. CoinJoin is a mixing scheme. If the anonymity set is not good, then privacy is not good. It can be vulnerable to amount correlation, post-mix consolidation, address reuse, and timing/Sybil attacks. > [@Kruw](#): > > Unfortunately, PJ actually introduces a privacy footgun: The receiver shares one of their existing UTXOs with the sender to merge with the payment. This is a valid observation, but PayJoin still can be used to improve privacy if: - Bob uses a UTXO that doesn’t deanonymize a different counterparty (e.g., Bob’s own transfer from an exchange) - Bob uses a UTXO already associated with Charlie. This breaks the common-input-ownership heuristic, obscures the payment amount, and can mislead change-identification heuristics. The example you provide is the worst case example. It’s not a PayJoin issue, but rather a UX issue with UTXO management and privacy. But it’s a fair point for real world usage. So I’m glad you pointed it out. > [@Kruw](#): > > Worse, if Charlie is using an Electrum based mobile wallet to payjoin, Bob’s common input ownership data also gets [harvested by third parties.](https://x.com/Kruwed/status/2062195325561938295) Not a PayJoin issue, but an important point for real world usage. Appreciate you mentioning this. > [@Kruw](#): > > **Silent Payments just generate new receiver addresses automatically,** it’s mainly a UX improvement for donations. The word “just” makes it seem like a convenience feature. Making it easier to use the same address without linking transactions is huge for privacy. As a side effect, this also reduces public key exposure for unspent outputs. Exposed public keys can become an issue with quantum computers. ---
**Author:** ![Kruw](https://delvingbitcoin.org/user_avatar/delvingbitcoin.org/kruw/32/915_2.png) [@Kruw](https://delvingbitcoin.org/u/Kruw)\ **Post date:** [June 21, 2026, 11:33pm UTC](https://delvingbitcoin.org/t/state-of-the-transaction-privacy-work-in-bitcoin/2622/9 "2026-06-21T23:33:39Z")
> [@nkaretnikov](#): > > “Full privacy” is an overstatement. CoinJoin is a mixing scheme. If the anonymity set is not good, then privacy is not good. It can be vulnerable to amount correlation, post-mix consolidation, address reuse, and timing/Sybil attacks. These issues are solvable when using the WabiSabi coinjoin protocol. Papers measuring coinjoin data can be found here, which shows that the anonymity set continuously increases over time from remixes: [Analysis of input-output mappings in coinjoin transactions with arbitrary values by Jiri Gavenda, Petr Svenda, Stanislav Bobon, and Vladimir Sedlacek (Masaryk University, Czechia)](https://arxiv.org/pdf/2510.17284) [CoinJoin ecosystem insights for Wasabi 1.x, Wasabi 2.x and Whirlpool coordinator-based privacy mixers by Petr Svenda + Jiri Gavenda (Masaryk University, Czechia) and Vasilios Mavroudis + Chris Hicks (The Alan Turing Institute)](https://petsymposium.org/popets/2026/popets-2026-0061.pdf) > [@nkaretnikov](#): > > This is a valid observation, but PayJoin still can be used to improve privacy if: Bob uses a UTXO that doesn’t deanonymize a different counterparty (e.g., Bob’s own transfer from an exchange) Changing Alice’s name to MtGox in the example doesn’t make any difference, an exchange is still a counterparty. > [@nkaretnikov](#): > > Bob uses a UTXO already associated with Charlie. This breaks the common-input-ownership heuristic, obscures the payment amount, and can mislead change-identification heuristics. Those heuristics are broken from a third party perspective, but using Payjoin in this scenario doesn’t make any difference for the conventional threat model: Bob can already consolidate these two UTXOs without revealing any new information to Charlie. > [@nkaretnikov](#): > > Not a PayJoin issue, but an important point for real world usage. Appreciate you mentioning this. It is a Payjoin issue - If Bob accepts a regular payment from Charlie’s mobile wallet instead of a payjoin, less data will be revealed to Charlie (and end up in the hands of surveillance companies). > [@nkaretnikov](#): > > The word “just” makes it seem like a convenience feature. Making it easier to use the same address without linking transactions is huge for privacy. Silent payments have no privacy advantages compared to a payment sent to a new address that was generated manually. It’s strictly a convenience improvement that allows reuse in two specific scenarios: 1. Receiving non-public donations 2. Receiving multiple payments from the same entity. > [@nkaretnikov](#): > > As a side effect, this also reduces public key exposure for unspent outputs. Exposed public keys can become an issue with quantum computers. This is incorrect. Silent payment outputs use Taproot keys, which are exposed onchain. ---
**Author:** ![AdamISZ](https://delvingbitcoin.org/user_avatar/delvingbitcoin.org/adamisz/32/418_2.png) [@AdamISZ](https://delvingbitcoin.org/u/AdamISZ)\ **Post date:** [June 22, 2026, 11:21am UTC](https://delvingbitcoin.org/t/state-of-the-transaction-privacy-work-in-bitcoin/2622/10 "2026-06-22T11:21:16Z")
> [@Kruw](#): > > These issues are solvable when using the WabiSabi coinjoin protocol. Seems way overstated. I agree with @nkaretnikov . First, you cannot solve the problem with a central server: the central server has an unstoppable ability to near-fully Sybil you in any given join. It’s true that that risk is not as bad as it seems at first glance, given all the “natural” circumstantial defenses that exist (in particular probing the server with anonymous entities), but it always exists to some extent or other. Then there’s the fact that for actually _using_ bitcoin, denomination matters. WabiSabi is a huge leap forward from Wasabi 1 in that respect, it’s a great innovation, but, transactions that make actual payments are not close to fully solved with this denomination splitting [1]. Then there’s the fact that coinjoin at big anon sets simply does not scale (and at small anon sets does not give good anonymization ofc). Where I do think you have a very solid basis for the gist of your claim is: large enough anon sets (as we have seen with recent Wasabi) means you push outside feasible computation limits; the coinjoins do really become a black box (in general; there can always be specific failures ofc). That’s an important observation but as per above (1) it can’t scale far and (2) it doesn’t remove the other problems (\*) with onchain transactions, especially if people don’t pay each other inside the joins. (\*) timing correlation, amount correlation, wallet fingerprinting, network level trace and a bunch of other fingerprints, combined with the unreasonable effectiveness element from set-intersection, make it obviously false to claim any onchain privacy technique, even the best one, is going to let you say “solved”. Offchain it’s much more defensible to say “solved”, I think. [1] Little side note: as many of us who studied coinjoin over the years, I became very interested in the ‘one participant pays other inside the coinjoin’ model; it counters the unscalability of ‘useless extra transactions’, it breaks surveillance of the flows etc. But it is not just ironic but telling, that exactly this model is the one where you lose the property you noted upthread: it means the receiver now _does_ need new software. ---
**Author:** ![Kruw](https://delvingbitcoin.org/user_avatar/delvingbitcoin.org/kruw/32/915_2.png) [@Kruw](https://delvingbitcoin.org/u/Kruw)\ **Post date:** [June 22, 2026, 2:32pm UTC](https://delvingbitcoin.org/t/state-of-the-transaction-privacy-work-in-bitcoin/2622/11 "2026-06-22T14:32:35Z")
> [@AdamISZ](#): > > Seems way overstated. “Solvable” is not an overstatement imo, I tried to choose my words carefully here so I don’t spread too much optimism on a technical board. The claim “These issues are **solved** when using the WabiSabi coinjoin protocol” would be inaccurate since there’s still work to do on improving the current implementation. The claim “These issues are solvable when **participating in a WabiSabi coinjoin transaction** ” would also be inaccurate because a single transaction is not guaranteed to enhance privacy. Whales face a relative disadvantage compared to smaller participants, so they will need to pay for and wait for additional remixes. > [@AdamISZ](#): > > First, you cannot solve the problem with a central server: the central server has an unstoppable ability to near-fully Sybil you in any given join. You are somewhat correct, WabiSabi assumes server availability as a premise: ![575447450-81ba6df2-da81-4333-b87f-631a5e2feb9b](https://delvingbitcoin.org/uploads/default/original/2X/6/647ca328c3401df2a2d32bbeaa2eaff17eb93eea.png) An unstable server can slowly partition users by dropping connections and preventing rounds from ever completing. Each failed round leaks some metadata off chain, and if the server disappears permanently then there’s extra friction while users switch to a new coordinator. As the paper mentions, the incentives for clients and servers are already aligned since coordinators may profit from successful rounds: My coordinator server has a higher % uptime than both Zcash’s Orchard pool and Litecoin’s MWEB chain. However, I would argue that the WabiSabi protocol is uniquely resistant to Sybil attacks, for the exact reason you mentioned: > [@AdamISZ](#): > > It’s true that that risk is not as bad as it seems at first glance, given all the “natural” circumstantial defenses that exist (in particular probing the server with anonymous entities), but it always exists to some extent or other. Expanding my above claim with a comparison to other coinjoin protocols: - Whirlpool is uniquely vulnerable to Sybil attacks: The coordinator chooses all inputs for the round. - JoinMarket defends takers against Sybil attacks with fidelity bonds. - WabiSabi coordinators can’t execute a Sybil attack against a target input without being detected since the user would notice their other inputs are not included in the round. Excluded users would migrate their liquidity to a new coordinator, and the malicious one would die off. > [@AdamISZ](#): > > Then there’s the fact that for actually _using_ bitcoin, denomination matters. WabiSabi is a huge leap forward from Wasabi 1 in that respect, it’s a great innovation, but, transactions that make actual payments are not close to fully solved with this denomination splitting [1]. Wasabi v2.8 is yet another huge leap forward over previous implementations of WabiSabi because it adds the Pay in Coinjoin feature to the GUI: ![HKKAnF-WsAA9UEV](https://delvingbitcoin.org/uploads/default/original/2X/3/32128a057b48edc427e258399df8ae4174fa05fe.png) This tactic eliminates multiple privacy concerns: - The age of the sender’s inputs is not revealed - The number of inputs consolidated by the sender to make the payment is not revealed - The origin rounds of inputs consolidated by the sender are not revealed - The value of the sender’s leftover change is not revealed - The sender can batch multiple payments without revealing a common origin Even newbies who don’t understand the concept of UTXOs don’t need any further instruction to use Bitcoin anonymously (pending UX issue[\*](https://github.com/WalletWasabi/WalletWasabi/issues/14664)). > [@AdamISZ](#): > > Then there’s the fact that coinjoin at big anon sets simply does not scale The base layer simply does not scale in general. Kukks made a prototype for sending anonymous coinjoin credentials directly to the end user, turning the coinjoin round into a non custodial ecash layer 2: [Kompaktor](https://github.com/Kukks/Kompaktor) > [@AdamISZ](#): > > That’s an important observation but as per above (1) it can’t scale far and (2) it doesn’t remove the other problems (\*) with onchain transactions, especially if people don’t pay each other inside the joins. Even ignoring the potential benefits of CISA and CT, coinjoins can be scaled reasonably. My average coinjoin size over the past year was 270 inputs, 325 outputs, 30k vBytes. The largest coinjoin was 498 inputs, 51k vBytes. Considering the standard relay limit for individual transactions is 100k vBytes, there’s relatively little room left for optimization. 100k isn’t the scaling limit though. After a round becomes full, coordinators optimize the liquidity by running two rounds simultaneously: One for whales, and one for smaller users. When clients sort themselves by relative value, you can squeeze out even more performance. > [@AdamISZ](#): > > [1] Little side note: as many of us who studied coinjoin over the years, I became very interested in the ‘one participant pays other inside the coinjoin’ model; it counters the unscalability of ‘useless extra transactions’, it breaks surveillance of the flows etc. But it is not just ironic but telling, that exactly this model is the one where you lose the property you noted upthread: it means the receiver now _does_ need new software. Yes, JoinMarket benefits strongly if the recipient is also a JoinMarket user. A trail of consecutive payjoin transactions also gradually decays possible analysis. Also, the downsides of payjoin are eliminated if both participants are using coinjoined outputs for their payjoin inputs. ---
**Author:** ![AdamISZ](https://delvingbitcoin.org/user_avatar/delvingbitcoin.org/adamisz/32/418_2.png) [@AdamISZ](https://delvingbitcoin.org/u/AdamISZ)\ **Post date:** [June 22, 2026, 3:02pm UTC](https://delvingbitcoin.org/t/state-of-the-transaction-privacy-work-in-bitcoin/2622/12 "2026-06-22T15:02:32Z")
> [@Kruw](#): > > “Solvable” is not an overstatement imo, I tried to choose my words carefully here so I don’t spread too much optimism on a technical board. > > The claim “These issues are **solved** when using the WabiSabi coinjoin protocol” would be inaccurate since there’s still work to do on improving the current implementation. Funnily enough I was about to write a much more agreeing-with-you post where I pointed out that you’d said “solvable” and not “solved” 😆 … before deciding that no, it’s too pedantic and it ultimately is not realistic to say it’s “in the process of being solved”. Your counterpoints are noted - good information - but I still think you’re significantly overstating with the term “solvable”. Disagree. ---
**Author:** ![Kruw](https://delvingbitcoin.org/user_avatar/delvingbitcoin.org/kruw/32/915_2.png) [@Kruw](https://delvingbitcoin.org/u/Kruw)\ **Post date:** [June 22, 2026, 3:24pm UTC](https://delvingbitcoin.org/t/state-of-the-transaction-privacy-work-in-bitcoin/2622/13 "2026-06-22T15:24:01Z")
> [@AdamISZ](#): > > Your counterpoints are noted - good information - but I still think you’re significantly overstating with the term “solvable”. Disagree. Could you be more specific about what your remaining concerns are? Are they privacy related or scaling related? ---
**Author:** ![craigraw](https://delvingbitcoin.org/user_avatar/delvingbitcoin.org/craigraw/32/1660_2.png) [@craigraw](https://delvingbitcoin.org/u/craigraw)\ **Post date:** [June 23, 2026, 6:05am UTC](https://delvingbitcoin.org/t/state-of-the-transaction-privacy-work-in-bitcoin/2622/14 "2026-06-23T06:05:26Z")
> [@Kruw](#): > > **Silent Payments only generate new receiver addresses automatically,** it’s mainly a UX improvement for donations… Alice pays Bob’s sp1addressx123 (Robert’s pseudonym), Charlie pays Robert’s sp1addressx123 (Bob’s real name) This is at best a confused analysis which misses the fact that it is trivial to create a second account (e.g. m/352’/0’/'1) with a second and unlinkable silent payments address for Bob. ---
**Author:** ![Kruw](https://delvingbitcoin.org/user_avatar/delvingbitcoin.org/kruw/32/915_2.png) [@Kruw](https://delvingbitcoin.org/u/Kruw)\ **Post date:** [June 23, 2026, 8:10am UTC](https://delvingbitcoin.org/t/state-of-the-transaction-privacy-work-in-bitcoin/2622/15 "2026-06-23T08:10:33Z")
> [@craigraw](#): > > This is at best a confused analysis which misses the fact that it is trivial to create a second account (e.g. m/352’/0’/'1) with a second and unlinkable silent payments address for Bob. You seem even more confused: Generating a new unlinkable address is already the status quo for privacy, the point of a silent payment address is that **you can reuse it.** In practice, you can only reuse it for two specific scenarios: > [@Kruw](#): > > 1. Receiving non-public donations > 2. Receiving multiple payments from the same entity. ---
**Author:** ![craigraw](https://delvingbitcoin.org/user_avatar/delvingbitcoin.org/craigraw/32/1660_2.png) [@craigraw](https://delvingbitcoin.org/u/craigraw)\ **Post date:** [June 23, 2026, 9:40am UTC](https://delvingbitcoin.org/t/state-of-the-transaction-privacy-work-in-bitcoin/2622/16 "2026-06-23T09:40:30Z")
You are conflating two completely different things - having two entities with two static reusable addresses, and the status quo of needing a new onchain address for every payment to maintain privacy. If you go to the trouble of creating a pseudonym, creating a second unlinkable static address is a trivial step. That second static address can then privately receive an unlimited number of payments from any number of different entities. In order words, address reuse with privacy. I’m not sure why you claim this is only useful for receiving multiple payments from the same entity. This is untrue. ---
**Author:** ![Kruw](https://delvingbitcoin.org/user_avatar/delvingbitcoin.org/kruw/32/915_2.png) [@Kruw](https://delvingbitcoin.org/u/Kruw)\ **Post date:** [June 23, 2026, 9:53am UTC](https://delvingbitcoin.org/t/state-of-the-transaction-privacy-work-in-bitcoin/2622/17 "2026-06-23T09:53:40Z")
> [@craigraw](#): > > If you go to the trouble of creating a pseudonym, creating a second unlinkable static address is a trivial step. The fact that generating a new address is trivial is one that undermines the argument for silent payments, not strengthens it. As I already said: The current status quo is that every transaction gets its own pseudonym. > [@craigraw](#): > > That second static address can then privately receive an unlimited number of payments from any number of different entities. … I’m not sure why you claim this is only useful for receiving multiple payments from the same entity. This is untrue. It is true, I already explained why this behavior is risky: > [@Kruw](#): > > Worse, this leak occurs passively if Alice and Charlie both use the same custodian. The custodian is able to correlate payment relationships between Alice, Bob, and Charlie even if Alice and Charlie don’t know each other. ---
**Author:** ![craigraw](https://delvingbitcoin.org/user_avatar/delvingbitcoin.org/craigraw/32/1660_2.png) [@craigraw](https://delvingbitcoin.org/u/craigraw)\ **Post date:** [June 23, 2026, 10:42am UTC](https://delvingbitcoin.org/t/state-of-the-transaction-privacy-work-in-bitcoin/2622/18 "2026-06-23T10:42:57Z")
> [@Kruw](#): > > The fact that generating a new address is trivial is one that undermines the argument for silent payments, not strengthens it. This is just nonsense. > Worse, this leak occurs passively if Alice and Charlie both use the same custodian. Well, of course if a single entity has a complete view of all the transaction history for all parties they can see payment relationships. Stating this as a risk for Silent Payments is nonsensical. If a single entity has all the transaction history for all parties using coinjoin wallets the same fact is true. ---
**Author:** ![Kruw](https://delvingbitcoin.org/user_avatar/delvingbitcoin.org/kruw/32/915_2.png) [@Kruw](https://delvingbitcoin.org/u/Kruw)\ **Post date:** [June 23, 2026, 10:47am UTC](https://delvingbitcoin.org/t/state-of-the-transaction-privacy-work-in-bitcoin/2622/19 "2026-06-23T10:47:35Z")
> [@craigraw](#): > > This is just nonsense. What is “nonsense”? You just spent the past 2 posts repeating that generating new addresses is trivial, and I agreed with you: It is trivial. > [@craigraw](#): > > Well, of course if a single entity has a complete view of all the transaction history for all parties they can see payment relationships. Again, you are confused: **Bob is not a user of the custodian in the scenario.** If Bob uses regular addresses, the custodian does not know that Alice and Charlie sent payments to the same person. If Bob uses a silent payment address, the custodian learns his common input ownership information immediately, even if the UTXOs are never consolidated in a later payment. ---
**Author:** ![craigraw](https://delvingbitcoin.org/user_avatar/delvingbitcoin.org/craigraw/32/1660_2.png) [@craigraw](https://delvingbitcoin.org/u/craigraw)\ **Post date:** [June 23, 2026, 11:00am UTC](https://delvingbitcoin.org/t/state-of-the-transaction-privacy-work-in-bitcoin/2622/20 "2026-06-23T11:00:35Z")
> [@Kruw](#): > > If Bob uses regular addresses, the custodian does not know that Alice and Charlie sent payments to the same person. If Bob uses a silent payment address, the custodian learns his common input ownership information immediately Ah, I see your point more clearly now, but there is still a fundamental misunderstanding. The addresses that Bob receives on can be calculated locally by the wallet software running on Alice/Charlie’s computer - there is no need for the custodian to have any record of the silent payments addresses. In any case, all this rather misses the point. Address reuse is currently near 70% because it’s difficult to share/validate a new address for every payment. Silent Payments removes this problem, and if you can’t see the difference between a new address for every payment and a new address for every persona, I don’t think we are ever going to agree. [Next page](https://delvingbitcoin.org/t/state-of-the-transaction-privacy-work-in-bitcoin/2622.md?page=2)