Announcing ICPP - A protocol for P2P privacy-enabled transactions on the Internet Computer

Developers
,
62

Thank you very much for your supporting words. I believe in the ICP tech and its possibilities, ICPP being one of them, although I am unsure many do care.

I also believe in the impact it could have on ICP price, by stimulating demand. From its current price point, at the margin that could be substantial. However, I’ve seen little if any amplification, and most KOLs are just playing around the B they are likely paid to promote. The only way to put ICP on the radar is to make the price blip. It’s not going to happen otherwise, frankly.

I’m also not too sure it’ll be Caffeine. I do get the idea, but think it my have come a bit late to the fray. The market is quite saturated, and the idea that the future is one where everyone will be coding seems far fetched. People have already busy and complicated lives as it stands (work, family, the dog, kids school, you name it) so not sure how much bandwidth there is for folks to Caffeinate their day to day, so to say. Maybe the young ones like my 12 yo son, but the teen/young adult age bracket is not one where income (earned or otherwise) is of any significance. And again, you may find the next Steve Jobs somewhere in the AI ocean, but it’s now very busy, very competitive, very contested, so the odds he’ll land on your ship are not great. Add into the picture the fact that AI economics don’t quite stack up.

Perhaps a sign is this marketing mantra of “self writing Internet” which pretty much everyone I spoke to, and I’m talking about seriously clever people, had difficulties either understanding (hearing “what the F is that?” 7 out of 10 times) or making sense of other than a short-legged gimmick to attempt at some differentiation (the other 3). I do hope it works, I really do, just that I can’t see how and numbers so far seem to confirm that trend. It hasn’t brought the “ooomph” many expected, and time is not on ICP’s side.

Privacy coins are neither new: ZEC, XMR, some would argue DASH (although it’ not) and a few minor testimonials. But if ICPP gains a place it’ll be 3 in the over 1 billion MarCap crypto segment. Compare that to the offering in the AI space. That’s my metric.

But for that DFINITY needs to play ball. I cannot do it on my own.

Just my 2c. At the very least, I hope it serves a purpose if anything to bring to ICP some of the essence of crypto, which is about preserving privacy.

Hey, thanks for this, appreciate your suggestion. I have some observations though…

1. ICPP already has cryptographic unlinkability. The RDMPF layer provides NP-hard content protection which is independent of infrastructure. I think you assume ICPP privacy is purely architecturally-driven? In fact, it isn’t.

2. Key images are permanent artifacts. As you know, ring signatures require nullifiers and key images to prevent double-spending, and these persist. Even if the canister is destroyed, the key images were observed, logged, and transmitted. My feel is that this strategy reintroduces exactly what ICPP has been able to eliminate.

3. Epoch-based batching means all transfers in an epoch share a timing window, introducing (quite obviously) timing correlation. OTOH per-transfer ephemerality in ICPP means each transfer’s infrastructure is independent. With epoch batching an observer knows “these N transfers occurred in epoch E.” That’s a correlation vector that ICPP doesn’t have.

4. With UTXO you reintroduce amount fingerprinting. Although ring signatures hide which input you’re spending, amounts and UTXO graph structure leak information. Just think about Monero’s decade of research on decoy selection as proof of how hard this is. By contrast, ICPP’s randomized chunking into a shared pool eliminates the UTXO graph entirely, because there’s no structure to analyze.

5. Last but not least, ring signature privacy degrades catastrophically with poor decoy selection. Monero has repeatedly patched selection algorithms as attacks emerged. So why importing this problem wholesale on ICPP?

Just my 2c here.

63

Don’t forget to let your voice be heard if you care about this.

image
image457×138 16.1 KB

64

I did. And did my bit on X :wink:

Poked Jan initially, because he’s still an authoritative and respected voice in the cryptography space, and to Dom in the immediate follow up.

65

that was directed at the readers. :wink:

66

Sorry..! That’s faux pas is entirely on me.
:grin: :grin:

67

Asking you these questions helps me understand how the protocol works, hope you dont mind. Besides it’s a good puzzle.

What I meant by cryptographic unlinkability in this case, which you pointed in the paper: “Any single compromised ephemeral component cannot link Alice to Bob. Collusion of both I1 and I2
(or broad network compromise) is out of scope and would defeat path unlinkability.”

It will probably be really hard to find two subnets, which don’t share a single node provider.
So I was hoping ring signatures can help in that case, but really, it was just a quick idea.

By “compromise” do you mean 1/3 attack, 2/3 attack or just single node in each subnet recording all transactions, I suppose the last one?

68

It’ absolutely fine and I really do appreciate the questions; I had today to update the submission as I found a few scattered typos, but what will come out maybe tonight is clean.

That quote I used was to highlight that broad network compromise (basically, a failure in the way the network operates) would be, first and foremost, the end for ICP and DFINITY even before that of ICPP. If you have doubts about the network’s integrity you just have to go and build elsewhere. That’s the “out of scope” mention, as there is nothing anyone can do.

Hence let me elaborate on what “compromise” means here, which, as you have correctly guesed, is single node passive observation (not Byzantine attacks on consensus).

As we all know, ICP subnets run BFT with 13-40 nodes, and every node in a subnet sees all canister state and all messages. A single malicious node operator can log everything without affecting consensus or triggering any detection. That’s not on ICPP, it’s infrastructure hardening.

Complete provider disjointness between two subnets is unlikely. ICPP’s Factory canister requests distinct subnets, but “distinct subnet” is not the same as “zero node provider overlap.”

Back to ring signatures, they would hide which ephemeral principal spent which deposit. However

1. Key images persist (logged by the observing node).

2. The timing correlation remains (deposit and retrieval in observable windows).

3. Decoy selection in a small anonymity set (single epoch) is weak, as I mentioned earlier.

What’s left? Operational mitigation. But that’s infrastructure hardening, not cryptographic: an attacker would learn that a transfer occurred between two ephemeral identities, not who those identities are or what was transferred.

69

Ok, for clarity: I’ve never actually used a privacy layer - I’m just curious about how it works. Thanks for helping me (and possibly others) understand it better. Personally, I’d be really happy if someone jumped into one of my threads to review it and ask challenging questions like these.

I think what you’re working on is genuinely good, and I’m happy to have you around pushing innovation. I’d also be much more suspicious if a thread like this existed and nobody challenged it. So I’ve taken on that role - partly to help stress-test the ideas, and partly because it’s challenging.

Correct me if I’m wrong on the following understanding of ICPP (related only to what’s seen in the ledger, both versions suppose the rest of ICPP works the same):

  • Alice sends to a Router → everyone can tell Alice is using a privacy layer.
    (Since the Router has deposit addresses and all tokens end up in the pool after one hop, this can be inferred.)
  • Bob receives from the pool → everyone can tell Bob is using a privacy layer.

— An alternative approach:

  • There is no Router and no pool address.
  • There is no easy, obvious connection between Alice, Bob, and a “privacy layer.”

Instead:

  • Alice sends to unbounded set of addresses controlled by a canister.
  • ICP addresses owned by a canister have legacy addresses in history - they are not expressed as {owner; subaccount} pairs like in newer SNS ledgers.
  • Observers cannot easily tell which addresses a canister owns or how many tokens it controls*(except node providers).
  • There is no general ledger-history observability that links an address to a canister, unlike EVM chains where everything is explicitly public.
  • A canister can move tokens between its own addresses over time using timers, adding noise.

Instead of sending from a single pool, the canister could send to Bob from random addresses over time.

For example:

  • Alice deposits tokens,
  • two hours later John deposits,
  • four hours later Bob withdraws,
  • seven hours later Peter withdraws,
  • plus hundreds of other users or a buffer of protocol-owned ICP in between.

From the ledger alone, it becomes hard to link deposits and withdrawals.

What’s good about this approach is also what’s bad about it.
If Bob does something malicious with the ICP he receives and those funds are later linked (not to Alice, but to John), then John could be blamed. Ironically, John may not even be able to prove that he used a privacy layer at all.

That same “structurelessness” could also enable statistical analysis over time - though I’m not entirely sure how strong that effect would be.

–

On the infrastructure side, it’s conceivable that execution, state, and keys could eventually run under a TEE, so node providers couldn’t read them at all. These subnets would likely be more expensive and slower, but we might see them in a year or two.

If that happens, ICPP becomes significantly more powerful without requiring any protocol changes at all.

70

Interesting, but (if I understand you correctly) it misses the point completely. Your focus seems to be on ledger-level address obfuscation. IMHO the ledger question is cosmetic. But let me try dissect the points you raise.

1. Everyone can tell Alice is using a privacy layer: So? The content is RDMPF-protected. Knowing someone used a privacy engine tells you nothing about what, to whom, or how much.

2. Legacy addresses hide canister ownership: Meaning security through obscurity? Node providers can see everything, hence you’re just one protocol upgrade away from irrelevance.

3. Canister can move tokens with timers, adding noise: Those movements are logged, and statistical analysis works on exactly this kind of noise.

4. Send to Bob from random addresses over time: That’s timing plus amount correlation. The exact attack vector that ICPP’s randomized chunking plus shared pool eliminates.

5. Hard to link deposits and withdrawals from ledger alone: ICPP already achieves this via functional subaccounts with chunking.

I think (but correct me if I’m wrong) that your core threat model are ledger observers correlating addresses. But ICPP’s threat model is broader:

  • Honest-but-curious intermediaries
  • Node providers with full state visibility
  • Retroactive cryptanalysis of persisted data
  • Infrastructure collusion

I’m afraid hiding canister ownership in ledger history addresses none of these.

Concerning your “taint” analysis or “John gets blamed” scenario, well, it’s not novel. It’s precisely the standard problem all mixers face. And ICPP’s chunking model means the “taint” is fragmented across random splits, not traceable outputs. IMHO what the suggestion would actually produce is a weaker, more complex system. Why?

  • It relies on ICP-specific address format trivia
  • It creates analyzable on-chain movement patterns
  • It provides no cryptographic content protection
  • It leaves state intact for retroactive analysis

ICPP already has ledger unlinkability via functional subaccounts and randomized chunking. Therefore I’m afraid you’re adding complexity while subtracting security.

71

Well, It’s not really missing the point, it’s another perspective on the point. We already established there is no cryptographic linkability under certain circumstances.

When I know Alice and Bob used ICPP privacy protocol, I already know something more than not knowing anything :D, so privacy leaks there.

2 - Your whole chunking system is made to hide ledger observability. Tho I am not quite getting how exactly Alice → router canister deposit addres → chunked icp → pool is hiding much, when one could just go and see that the router deposit address has 5x transactions to pool and that Alice sent them at specific time.

5 - Hiding canister ownership actually solves all of these problems the protocol seems to have now. Yes nodes can read it same way they can read intermediaries, it`s another defense layer.
But right now it seems:
Alice (personal account) sends 15 ICP → unique ICPP router deposit account (15 ICP) → chunked send → Pool.
Then later, Bob takes ~15 ICP from the pool.
With the alternative I suggested, there is zero connection on the ledger between their accounts. Alice sends to some address. From completely different unrelated address loaded weeks ago tokens go to Bob.

72

By your logic, then, every privacy system fails. Using Tor means you’re hiding something. Using Signal means you want private messaging. Using Zcash means you want private transactions. Knowing someone used a privacy layer is not a privacy leak: it’s the baseline. I would pose instead the following question: what do you learn beyond that? With ICPP you learn nothing: content is RDMPF-protected, path is compartmentalized, state is destroyed.

I also think you got the chunking wrong. Here’s what actually happens:

  • Alice sends to Router.subaccount(deposit_id) derived from deposit_id, not from Alice’s principal
  • Chunks go from that subaccount to Router.mixer_pool
  • Bob withdraws from Router.mixer_pool to his account

An observer cannot determine:

  • Which deposit this is (hash preimage)
  • Who the payer was (deleted from transient HashMap)
  • What stage this represents (domain-separated derivation)
  • Any relationship to other subaccounts (independent derivations)

After completion, the Router deletes the deposit_id from memory. The mapping subaccount to deposit to payer no longer exists anywhere. The subaccount is an orphaned hash with no inverse.

An observer does not see Alice’s “5 transfers”. They see transfers from a deposit-specific subaccount. Hundreds of deposit-specific subaccounts feed into the same pool with randomized chunking. The pool aggregates everything. And in relation to Bob’s pulling from the pool, the amounts are decorrelated.

You suggest that “hiding canister ownership” should, perhaps, be the way forward. Think you have in mind a single canister holding funds in multiple addresses and shuffling them over time. A canister seeing every deposit and every withdrawal. A sort of trusted mixer with extra steps.

But on ICPP no single component sees both Alice and Bob. Content is cryptographically protected. State is destroyed.

You add “from completely different unrelated address loaded weeks ago tokens go to Bob”.

Hold on: those addresses are all controlled by the same canister, which logged every movement. Node providers logged every movement. This requires maintaining a mapping from address to purpose, and you’re suggesting that mapping to persist. But that’s precisely providing the attack surface on a silver platter..!

Unrelatedness, as you suggest, exists only from the perspective of a naive ledger observer who doesn’t know which addresses the canister controls. That’s security through obscurity. You need just one analysis tool that maps canister-controlled addresses and the entire scheme collapses like a house of cards.

What does ICPP do? Derive addresses cryptographically, use them once, and delete the derivation key. No mapping survives. As I said earlier, the subaccount that exists on the ledger is a naked hash with no context.

My POV is that you’re trying to solve a different problem (call it “ledger aesthetics”) with a weaker tool (address shuffling) while ignoring what ICPP actually provides (cryptographic content protection, architectural path unlinkability, state destruction).

73

Screenshot 2025-12-30 at 4.02.04
Screenshot 2025-12-30 at 4.02.041556×690 10.7 KB

This should be how ICPP transactions work. Obviously there will be delays on transactions, also other users doing the same, but someone knowing how ICPP works, will be able to tell, Alice sent 15 ICP to the pool. The fact you derive fresh new deposit id doesn’t look like it helps anything privacy related. I also dont get what the router and chunking helps with? Perhaps only if someone doesn’t know how ICPP works, but given all deposits will follow that pattern, it can be quickly figured out. The privacy of Alice and Bob it will be exacly the same if Alice deposited directly to the pool.

They do see it - if they know how to protocol works. Since the only way Alice participates is from a deposit account, that means you could just ignore the deposit accounts and declare 15ICP went into the pool, even before they even get there, because they were sent to the deposit account.

Not following, how recording intermediary canisters is not security by obscurity, but a node recording what addresses a canister owns to improve the protocol by removing the pool address is, while keeping the rest the same? Also what is the difference between something staying in the state for 1 nanosec and 1 week when they were recorded? For more than 1 week it makes sense - so other node providers cant see it as well.

There can’t be such a tool.

Maybe I am being hard to understand, but I am not ignoring what ICPP is solving, just pointing out its flaws so whoever is using it knows what the risks are. Yes, you are solving a lot, I am not talking about what you solve, but what you aren’t solving atm :smiley: Additionally pointing out alternatives on how you handle your ledger transfers to improve privacy. It is a different privacy problem.

74

Right… let me say this loud and clear: you have been unable to point at any substantial flaw with any rigor, and my POV is that your proposals bring nothing to the plate and are a regression both operationally and cryptographically.

You assert that flaws exist but never specify: which assumption fails, which proof is wrong, which mechanism leaks what, to whom, and under what conditions.

In fact, you are conflating “knowing the protocol exists” with “breaking the protocol”. This, my friend, is Kerckhoffs’s principle inverted.

I’ve answered every question you posed as clearly as I could and in a substantiated way, explaining clearly why I think you got your facts wrong.

Concerning your proposed changes, IMHO they are borderline naive. Why? Your entire proposal relies on obscurity that evaporates at the infrastructure layer.

Now, if you think there are flaws (which is fair enough) I would be glad to hear your structured formalization of the alternative. Basically, provide the requisite assumptions, maths backing them up, formal proofs, and implementation strategy reflecting your formal model, so that you can demonstrate to the community why you think your approach is better at eliminating the “flaws” you identified.

Otherwise, when you speak about “what the risks are” (just because you think there are risks) but offer no formal justification (only “beliefs”) as to where and how those risks manifest, you are just opinionating. I’m sorry.

All said, if you can specify a concrete attack (adversary observes X, computes Y, learns Z about Alice/Bob with probability P) then I’m genuinely interested. That’s how we improve protocols. But just asserting “there are risks” without specification is not only unactionable: it’s irresponsible and helps no one.

If you can formally prove to have a superior alternative it would be great if you build it, for the benefit of the community. Honestly.

75

Speaking of which as I finish some stuff with Monday Night Football in the background :grin: (are the Rams cooked?) the ICPP paper (as I expected) has been now published by ArXiV.

76

Later, thanks to my questions and research, a few things became clear in this thread:

  1. Replica nodes / subnet observation
    The protocol relies on two intermediary canisters on different subnets. If an adversary can record traffic/metadata for both intermediaries, privacy collapses (this is also acknowledged in the whitepaper as “broad compromise/collusion defeats unlinkability”). In practice, there are no such two subnets that will support the protocol. Dfinity is in all and even if they weren’t, very likely other NPs would be in both. There aren’t two subnets that exist where a single node provider cannot observe both.
  2. Boundary nodes / network metadata
    Boundary nodes can very likely log metadata IPs, messages. If the same user (or same network identity) interacts with both deposit and retrieval sides, correlation becomes straightforward. Mitigation would require users to use network privacy (VPN/Tor) and avoid reusing network identifiers. This isn’t mentioned in the dapp UX or the announcement post.
  3. Correlation from logs + timestamps
    Boundary-nodes provide public access logs - hashed IPs, canister - method calls & timestamps are available to anyone (no special priviledges), an attacker could correlate boundary-node timestamps with ledger transaction timestamps to attribute ICPP interactions and potentially cluster wallets.
  4. Ledger-level “usage disclosure”
    Anyone reading ICP ledger history can still infer that Alice and Bob used ICPP (because deposits go to Router-controlled deposit subaccounts and then to the shared pool; withdrawals come from the pool). You may consider this acceptable leakage, but it’s still a privacy leak.
  5. Deposit ↔ withdrawal linkage via amounts
    From the ledger, it appears possible to correlate: “Alice deposited 15 ICP into the ICPP flow” and “Bob withdrew 15 ICP from the pool.” The Router + chunking mechanism doesn’t prevent correlation here. It’s observed in the ledger and permanent, doesn’t matter what’s deleted from the canister memory; The pool is primarily funded by identifiable deposit subaccounts, and withdrawals mirror those amounts, correlation looks easy unless everyone transfers the exact same amount, which they wont.

I’m not going to write a formal proof for the deductions one can make after reading the documentation and getting familiar with the IC. Maybe the protocol is sound in theory (except the ledger part), but with the current implementation and today’s infrastructure constraints, I believe the practical privacy is near zero. The first obstacles are (5) and (3), which seem to enable deposit ↔ withdrawal correlation without special privileges—just analysis.

I’m raising these issues to help harden your protocol. I’m happy to be corrected if any of the above statements are wrong.

77

Thanks for this structured answer, which makes my reply so much easier. Let’s go point by point:

Points 1-3: These are ICP’s infrastructure constraints affecting all applications, which, by the way, are acknowledged in the paper. Nothing new under the sun, it’s the explicitly stated threat model for ICPP.

That said, on ICPP content remains RDMPF-protected even under full subnet compromise. Path unlinkability degrades, but content confidentiality does not. Let me go a step further: should that happen, any application relying on (operational) privacy guarantees is cooked, meaning ICP is thrown to the gutter, and you may as well go build elsewhere. And by the way, your proposal (pre-funded addresses shuffled over time scheme) runs on those same subnets. With the same node providers, same boundary nodes, and same timestamp logs.

More importantly: while ICPP provides content protection even under observation, your proposal provides nothing. Zip, zero. The canister sees both sides, the state persists, and the content is unencrypted.

In summary: you identified ICP infrastructure constraints which are explicitly acknowledged (and addressed) in the paper, then blame ICPP for them, and propose alternatives that are strictly more vulnerable to every single attack you’ve listed.

Specifically about Point 2: you’re making a narrow point buried in confusion. If Alice and Bob are the same person (self-transfer for privacy washing) and they use the same IP for both deposit and retrieval, and an adversary correlates boundary logs, there’s potential metadata leakage. But that goes against the most elementary operational hygiene. Still, ICPP at protocol level already provides concrete mitigation:

  • Ephemeral principals (not long-term identity)
  • Separate canisters
  • Pull-based retrieval (Bob retrieves when Bob decides, not when Alice deposits)

In fact, network-layer privacy is orthogonal to application-layer privacy: Tor doesn’t protect your Signal messages, and Signal doesn’t protect your IP. These are separate concerns. ICPP solves application-layer privacy. Network-layer privacy is operational hygiene.

Point 4: I’ve addressed it repeatedly, but let me try again. Knowing someone used a privacy protocol is not a privacy leak by any standard cryptographic definition. By this logic, Tor, Signal, Zcash, and Monero all have privacy leaks. If you don’t understand this, or refuse to, there’s nothing more I can say.

Being now more specific: you’re conflating “can identify the Router’s principal” with “can link Alice to Bob.” These are unrelated. Even with full knowledge that Alice sent to a Router subaccount, an observer only sees a 32-byte blob. They cannot determine:

  • Which deposit this was
  • Which user initiated it (the mapping is deleted)
  • Which withdrawal it corresponds to (amounts don’t match, pool aggregates everything)

Point 5: Once again, you are factually wrong. There is no amount match. Full stop. I don’t know on which factual basis you are continuing to assert this. Just look some posts above this exchange where I exhibited the receipts, even for a one-shot example, which empirically falsify your claim.

  • The actual transaction graph → no direct link
  • The actual amounts → they don’t match
  • The actual canister state → proved destroyed

Subset-sum reconstruction over a shared pool with randomized chunking is computationally infeasible. The data is public. Anyone can verify it.

Bottom line: you’re denying evidence and choose to speculate.

Which brings me to your concluding paragraph. Saying “practical privacy is near zero” is a strong claim requiring formal justification. You’ve provided none. Zilch. Nada. If you still believe amount correlation survives randomized chunking into a shared pool, demonstrate the attack: adversary observes X, computes Y, links Alice to Bob with probability P. Otherwise you keep throwing assertions without any substance.

78

When will the code be open-sourced/audited and officially launched? Is there a specific timeline? Is there any contact with the foundation? I sincerely hope the foundation can get involved and promote it vigorously! This project could definitely get a share of the privacy market and drive ICP and even CK series into the liquidity market!

79

image
image828×381 55.7 KB

Well? @Leadership

80

Good that you ask.

  1. The platform is live, so anyone can use it. Risk and other disclaimers are clearly stated.

  2. Concerning Open Source: I’m weighting the options and it all depends on where this goes. If the Foundation gets directly involved and decides to support the development moving forward, then going Open Source would not be a problem. I doubt that will happen though. Lacking that, there are two options I would consider which depend on future funding: BSL (e.g., as did Uniswap) or AbA (Audit by Arrangement) where security auditors get access under NDA and audit reports are routinely published. VCs would also get access under NDA for due diligence (which is the model I used with the Foundation for the Nebula project).

  3. The protocol is documented in the paper, which, as you know, has been made public. The code is implementational tooling, hence it saves a third party time rather than limiting capability.

  4. OTOH I’ve done this with no support whatsoever from the Foundation, Angels, VCs, you name it. It’s been my time, guts and money put behind it. So I’m not keen to subsidize low-effort forks.

  5. Finally, I do believe in the value of transparency (hence why I’ve made the paper public) and people are free to decide whether to use the implementation which is now live, or not. If anyone has doubts, they are free to try implementing it.

  6. In summary: It will all depend on how this moves forward.

Hope this makes it clear and transparent.

81

I agree. I don’t know if you’ve seen any of ICP Apprentice’s YouTube videos. I think he’s the best (as in most accessible and visually attractive) current marketer of the tech. DFINITY should take a look.