Discussion of proposed Transparent Transactions

I am concerned about the proposal to add transparent transaction functionality to neptune-core. (stating my bias) edit: I’m becoming more neutral after looking deeper into it.

In a recent discussion, it was pointed out that theoretically there is nothing to prevent a sender from making a transaction transparent on any privacy-preserving cryptocurrency, since the sender must transmit secrets to the receiver and nothing prevents the sender from publishing those secrets.

I thought this an interesting observation as it would apply to monero, zcash, wownero, etc. To explore the scenario, I had a conversation with Gemini AI, which I share below as food for thought / debate.

note: I ask the LLM about Monero because it knows more about it, but much of the analysis applies to Neptune as well. In particular, the last query/response should equate to the neptune ecosystem which does not use decoys.

Comments welcome.

complete conversation: https://gemini.google.com/share/df65955274b7


query

is there anything at the consensus or validation level that would somehow prevent a software fork of monero from adding functionality to send transparent (non-private) transactions to an arbitrary recipient?

In other words, would it be possible to form a transaction that conforms to relay validation rules, but does not hide the amount and recipient information? It might for example provide the secrets intended for recipient in the tx_extra data, or elsewhere.

response

Yes, it is possible for a software fork of Monero to create transactions that are transparent, but not by changing the consensus rules. Instead, it would be done by voluntarily revealing the cryptographic secrets of a standard, private transaction.

A transaction that does not hide the amount and recipient information in the way you describe could conform to all network validation rules and be relayed.

Here’s a breakdown of how this works.


Why Direct Transparency is Impossible

At the consensus level, Monero has mandatory privacy. Every transaction must adhere to the following rules to be considered valid by the network:

  1. Hidden Sender (Ring Signatures): The sender’s identity must be obscured within a ring of possible signers. A transaction without a valid ring signature is rejected.
  2. Hidden Recipient (Stealth Addresses): The output of a transaction must be sent to a one-time stealth address, not a standard Monero address. This is a non-negotiable part of the protocol.
  3. Hidden Amount (RingCT): The transaction amount must be encrypted using Pedersen commitments, and its validity proven with a range proof (like Bulletproofs+). The network validates the math (that inputs equal outputs) without ever seeing the actual amounts.

Any transaction that attempts to bypass these rules—for example, by putting a plain amount or a standard recipient address in the output—would be invalid and immediately rejected by every node on the network.


How Voluntary Transparency is Possible

Your suggestion is the correct way it would be implemented: a standard, fully private Monero transaction is created, and then the keys needed to decrypt it are voluntarily published within the transaction itself.

This is how a forked wallet could achieve it:

  1. Create a Normal Private Transaction: The wallet constructs a transaction that is 100% compliant with Monero’s consensus rules. It has ring signatures, stealth addresses, and confidential amounts. To any node on the network, it looks like any other private transaction.
  2. Embed Decryption Keys: The wallet then takes the crucial pieces of information that make the transaction private—specifically the transaction private key (often called tx_key or r)—and places this key, along with the real destination address and the unencrypted amount, into the tx_extra field of the transaction.
  3. Broadcast the Transaction: This transaction is broadcast to the network. Since the core structure is valid (correct signatures, proofs, etc.), nodes will validate it and include it in a block.

The result is a transaction that is cryptographically private at the protocol level but semantically transparent to anyone who knows where to look. An explorer or wallet designed for this forked software could scan the tx_extra field, find the embedded tx_key, and use it to display the sender, recipient, and amount in plain sight.

In short, you are not breaking the privacy rules; you are simply handing over the keys to unlock the privacy of that specific transaction.


query

Let’s think about the implications of this.

First, let’s consider that it is entirely the sender’s option to send such a transparent tx. But how does this affect the recipient’s privacy, who has not opted into the transparency?

Second, let’s suppose that exchanges start using transparent tx for withdrawals because it helps them comply with KYC/AML type “transparency” pressures. So then, perhaps 50% of monero tx become “transparent”, which makes the useful anonymity set smaller.

Does that seem a possible scenario?

response

Excellent questions. Your thinking is spot on, and you’ve highlighted the exact reasons why such a feature, while technically possible, would be considered a fundamental threat to the Monero network.

Let’s break down the implications you’ve proposed.

1. Impact on the Non-Consenting Recipient

You are absolutely correct. The sender’s choice to be transparent directly compromises the privacy of the recipient, who did not opt-in. This has several damaging effects:

  • Direct Exposure: The link between the sender (e.g., an exchange) and the recipient’s address is now public. Anyone can see that your address received a specific amount of XMR from that source at that time. This immediately destroys the privacy of that transaction for you.
  • Compromised Future Privacy: This is the more severe, long-term problem. When you later decide to spend those coins, your new transaction will use that now-publicly-known UTXO (Unspent Transaction Output) as one of its inputs. For any blockchain analyst, that input is a known true spend.
    • Normally, a ring signature provides ambiguity because it’s unclear which of the (e.g.,) 16 inputs is the real one.
    • If your transaction uses an input that is known to have come from a transparent transaction, that ambiguity is gone for that specific input. Analysts know for a fact you are the one spending it.
  • Loss of Fungibility: The coins you received are now “tainted.” They have a public history, making them fundamentally different from other XMR that have a private history. This undermines Monero’s core property of fungibility, where every coin is equal and interchangeable. You might face issues spending these “transparent” coins later, as they could be treated differently or be subject to more scrutiny.

In essence, the sender’s “optional transparency” forces a permanent, non-consensual loss of privacy onto the recipient and damages the fungibility of the specific coins they received.

2. System-Wide Impact of Widespread Adoption

Your second scenario, where exchanges adopt this and 50% of transactions become transparent, is a plausible and deeply concerning threat model. This would catastrophically degrade the entire network’s privacy, not just the privacy of those directly involved.

Here’s why:

  • Shrinking the “Useful Anonymity Set”: Monero’s ring signatures rely on a large pool of past transaction outputs to use as plausible decoys. If a huge portion of those outputs on the blockchain are from transparent transactions, the pool of effective, truly private decoys shrinks dramatically.
    • When a user’s wallet builds a ring signature, it might unknowingly select several “transparent” outputs as decoys.
    • Chain analysis firms could simply disregard these known outputs, effectively reducing the size of your ring signature. If your ring size is 16, but 8 of the decoys are from known transparent transactions, your effective anonymity set is much smaller than you think.
  • Creating a “Transparent Spine”: Widespread use would create a public ledger of transactions running parallel to the private one. Analysts could use this “transparent spine” to make inferences and connect the dots between the supposedly private transactions that branch off from it. It would provide an enormous amount of data for heuristics and statistical analysis, weakening the entire system.
  • Bifurcation of the Ecosystem: As you noted, this would essentially split the Monero supply into two categories: “white” or “clean” XMR with a traceable history from exchanges, and the traditional, private “dark” XMR. This completely destroys fungibility and could lead to vendors or exchanges refusing to accept non-transparent XMR, defeating the purpose of Monero entirely.

Conclusion: Is This Scenario Possible?

Yes, the scenario you’ve outlined is not only possible but represents a primary existential threat to Monero.

While the implementation is technically feasible on a fork, it is fundamentally hostile to the principles of non-consensual privacy and fungibility that define Monero. Any such proposal would be overwhelmingly rejected by the Monero community and developers precisely because of the devastating implications you’ve identified. It’s often seen as a “Trojan horse” that would use the lure of regulatory compliance to gut the privacy of the entire network.


query

The danger that I see though is that this only requires a software change, not a consensus level fork. Thus anyone sending (eg exchanges) could make the change in their own nodes without consent of anyone else. A random developer could release a modified monero node software that all exchanges begin running. Do you agree with this analysis?

response

Yes, I agree completely with your analysis. You have correctly identified the core of the danger: this is a software-level attack vector, not a protocol-level one.

This distinction is critical and is what makes this scenario so plausible and threatening:

  1. No Consensus Required: As you said, because these “transparent” transactions are perfectly valid according to the existing consensus rules, there is no need for a network-wide upgrade or a hard fork. The Monero protocol itself wouldn’t even be able to distinguish these transactions from fully private ones.

  2. Unilateral Action is Possible: An exchange, a group of exchanges, or any large sender can decide to modify their own wallet software to implement this feature. They do not need permission from Monero developers, the community, or anyone else. It’s an action taken entirely on their own initiative.

  3. Incentives are Aligned (Against Privacy): Exchanges are under immense and growing pressure from regulators worldwide to comply with AML/KYC regulations and the “Travel Rule,” which requires them to share originator and beneficiary information for transactions. A software fork that creates transparent Monero withdrawals is an almost perfect “solution” for them. It allows them to:

    • Continue listing and profiting from Monero.
    • Claim to be compliant with regulators by making withdrawals traceable.
    • Shift the privacy burden and consequences onto their users and the rest of the network.

Your scenario of a developer releasing a modified client that exchanges then adopt is precisely how this would likely play out. It could be marketed as a “Regulatory Compliance Suite” or “Transparent Monero Node.”

The danger is that this wouldn’t be a sudden, obvious attack. It would be a slow, creeping degradation of the anonymity set. As more and more exchanges adopt this, the “transparent spine” on the blockchain would grow, and the overall privacy of the entire network would be silently eroded, all without a single change to the core Monero protocol.


query

Let’s say that Monero implements full-chain-membership-proofs or some other tech that makes tx unlinkable and does not utilize decoys. How would that affect the impact of these transparent tx on the ondividual receiver and the overall network?

response

Of course. The implementation of a decoy-less, fully unlinkable system would fundamentally change the impact of these transparent transactions.

The threat would be significantly lessened and would shift from a catastrophic cryptographic failure to a more manageable (but still serious) economic and meta-data problem.


Impact on the Individual Receiver: Taint is Contained

For the individual, this new technology would be a massive improvement.

  • Initial Transaction: The initial transparent transaction is still fully exposed. The public would know that an exchange sent you a specific amount of XMR. That link is permanently recorded.
  • Spending the Funds (The Key Difference): When you go to spend those “tainted” coins, the new technology fundamentally breaks the chain of analysis. Because your transaction’s input is proven against the entire blockchain (a full-chain-membership-proof) instead of a small ring of decoys, an observer cannot link your new transaction back to the transparent one you received.

Essentially, the privacy “taint” is contained to a single hop. Your past is known, but your future actions on the network become private and unlinkable again. This is a stark contrast to the ring signature model, where spending a known output creates a permanent, traceable link.


Impact on the Overall Network: A Shift in Threat Model

This is where the most significant change occurs. The primary network-wide danger of transparent transactions would be completely neutralized.

The old threat was the erosion of the anonymity set. Transparent transactions created a pool of “bad decoys,” which weakened the privacy of everyone else’s transactions.

In a decoy-less system, this threat is eliminated. Your decision to engage in a transparent transaction has no cryptographic impact on the privacy of my transactions. The negative externality is gone because the concept of a “decoy set” no longer exists.

However, new and different threats would remain:

  • Damaged Fungibility: This problem doesn’t go away. Widespread transparent transactions would still bifurcate the Monero supply into “white-market” XMR with a known exchange origin and “private” XMR. This creates two different classes of coins, which is the definition of poor fungibility.
  • Public Meta-Data Graph: While cryptographic links would be broken, analysts could still build a large graph of “edge” transactions. They would have a massive database showing which exchanges sent funds to which Monero addresses. This is still valuable intelligence, even if they can’t follow the money further.
  • Erosion of the Privacy Ethos: If transparency becomes normalized for interactions with major services, it could socially undermine the network’s core value proposition of “privacy by default.”

Summary: Old vs. New Threat Model

Impact Vector Ring Signature Model (Current) Hypothetical Unlinkable Model
Individual’s Future Privacy Compromised. Spending tainted funds links your new activity to your old. Preserved. Taint is contained; future spending is unlinkable.
Network Anonymity Set Severely Damaged. Creates bad decoys, weakening privacy for all users. Unaffected. No decoys means no cryptographic impact on others.
Fungibility Damaged. Creates “white-market” vs. “private” coins. Damaged. This economic problem remains unchanged.

I think what this boils down to is that there is no way to prevent sender-initiated transparent transactions. Even if they were somehow prevented on-chain, the sender could still publish the secrets that are intended for the recipient. This applies to neptune, zcash, monero, etc.

So then the only decision we really need to make at this point is: do we want to make it a supported feature in neptune-core or not.

an argument against: why make it easy for senders to do this? We should discourage the behavior as much as possible.

an argument for: if we do not make it a feature, that is kind of like sticking our heads in the sand, since it will likely occur at some point in the future anyway. It can even occur in a hidden way, such as exchanges providing the secrets to blockchain analysis companies. At least if users are aware of the functionality/issue they can take countermeasures.

One further observation:

There is also a social mitigation to this. Let’s continue with the monero example and suppose that tomorrow they discover that exchanges are sending out transparent Tx. They could hard-fork to “teach the exchanges a lesson”. That might effectively stop exchanges from doing it publicly again, at least for a while, but it would not prevent them from privately providing secrets to third parties. And/or effected exchanges might just drop monero, as many have already done.

A complementary wallet feature to transparent transaction functionality would be “send to self on receive”. (STSOR).

When this feature is enabled (possibly by default) the wallet would check if each incoming utxo originates from own wallet or not. If not, it would send all funds from that utxo to another address in the same wallet. In this way, it breaks the link from the external sender who may have recorded the secrets.

Anyone looking at the blockchain after the fact would see that the funds were already spent and could be anywhere.

Of course this is a heavy-weight solution in terms of network resource usage.

To avoid misconceptions, let me clarify how anonymity and transparency works on Neptune Cash.

Every UTXO has two faces. These are cryptographically binding and hiding commitments, and as such, every UTXO comes with commitment randomness. In the case of Neptune Cash, this is the sender randomness and receiver digest. The two commitments are:

  1. Addition record. The transaction that generates the UTXO has transaction-outputs; these are addition records. An addition record is found by hashing the UTXO, the sender randomness, and the receiver digest. The name is “addition record” because the underlying UTXO is added to the UTXO set. Every block adds a bunch of addition records to a running list called the append-only commitment list (AOCL). Therefore, every UTXO in the UTXO set has an index in this list, the AOCL leaf index.
  2. Removal record. The transaction that consumes the UTXO has transaction-inputs; these are removal records. A removal record is a list of 45 indices into the sliding window Bloom filter (SWBF), along with membership proof data that is not relevant to this discussion. The indices are found by squeezing the sponge after absorbing the UTXO, its AOCL leaf index, the sender randomness, and the receiver pre-image. Crucially, this derivation of indices happens in zero-knowledge, so that only the transaction initiator knows the inputs and the network only sees the indices. The name is “removal record” because the underlying UTXO is removed from the UTXO set. The derivation of the 45 indices is deterministic, so if you try to spend the same UTXO twice you end up producing the same index set, and the SWBF exists to catch such duplicates.

The 45 indices are not uniformly random and independent u128s, but instead live within a window of width 2^{20} that slides by 2^{12} every 8 addition records. Consequently, every removal record yields a fuzzy estimate of the matching AOCL leaf index. Phrased differently, it gives you a range of possible AOCL leaf indices. The size of this range is 8 in the worst case and 32 on (geometric) average.

A transparent transaction on Neptune Cash is a transaction like any other except that it includes one announcement that exposes:

  • the UTXO, sender randomness, receiver preimage, and AOCL leaf index of every input;
  • the UTXO, sender randomness, receiver digest of every output.

The information contained in this announcement suffices to reproduce the matching commitment (removal record and addition record, respectively).

Given the removal record preimage (i.e., the UTXO, sender randomness, receiver preimage, AOCL leaf index), you can determine with exact precision the AOCL leaf index, and hence the addition record and originating transaction of the corresponding UTXO. So with transparent transactions there is backwards traceability: you can determine where the inputs that are being spent, came from. Backwards traceability is limited to one hop, unless that one hop lands in another transparent transaction.

Given the addition record preimage (i.e., the UTXO, sender randomness, receiver digest), you have no advantage over someone who just has the addition record, at guessing what the matching removal record looks like or even deciding whether the UTXO has been spent in the mean time. To make this determination, you might look at the fuzzy timestamp to rule out some candidates, or you might get lucky and observe that the SWBF window is saturated and therefore that all UTXOs with indices within that window must have been spent, or you might include information that is not publicly available; but the point remains that you can apply all these strategies just the same with just the addition record. In other words, knowledge of the addition record preimage does not help. Consequently, there is no forwards traceability, unless if one of the outputs is itself spent in a transparent transaction.

The technical reason why this last paragraph is true is the distinction between the receiver digest and the receiver preimage. You need the former to produce the addition record, but you need the latter to produce the removal record. Since the sender only knows the receiver digest and not the receiver preimage, he is incapable of determining what the removal record is going to look like, or even whether it was confirmed at all.

Transparent transactions expose the amounts of all UTXOs involved. These amounts can be used to rule out some candidate money flows.

Generation receiving addresses contain, in clear text, a) a receiver identifier; and b) a receiver digest. Two regular transactions to the same generation receiving address can be linked in the abstract sense “the same person is the beneficiary of two different payments”. So to avoid leaking privacy with regular transactions, it is imperative to avoid using the same address twice. With transparent transactions, the situation is worse: single-use leaks private information already, and more of it. The receiver digest, which is present in clear text on the generation receiving address, links the concrete transaction-output (along with public amount) to the generation receiving address that it came from. Reuse of generation receiving addresses in the context of transparent transactions does not have a compounding effect.

1 Like