Not sure why. But I can see it on my end:
We should figure out a way to link those channels as they are buried in sub teams… One suggestion was to have some kind of shortcut on the main channel to link all of those.
We should figure out a way to link those channels as they are buried in sub teams… One suggestion was to have some kind of shortcut on the main channel to link all of those.
1 Like
Confirmed that it’s a private channel. The same goes for the other ones (wallet_dev is the only I am aware of)
This channel is definitely open to everyone. On your end you have to request access? I did not receive any notification.
I had to find a direct link to the channel in another chat in order to be able to open the window to request membership. The request was approved very quickly so I am not sure if somehow automated or not.
Why should I trust the Keybase client? I don’t see any way to compile it from source on their Github repository, which makes the project somewhat suspect to me, though I am using their identity-management service:
I’ve asked Claude about this topic, some suggestions below but need other experts to verify
Concrete directions:
- Aggregation-before-broadcast as a first-class service. An opt-in “mixing mempool” / aggregator: wallets submit transactions to it, it non-interactively aggregates everything it receives in a time window, and only the merged blob ever hits the P2P network. A sniffer at the edge now sees a merged transaction, not atomic ones. The catch: the aggregator itself sees the pre-merge inputs — so you want many independent aggregators, or one fronted by a mixnet so it can’t correlate submitter IPs (this is exactly where the goblin Nym model becomes genuinely useful — not for the graph, but for anonymizing submission to the aggregator). That synthesis — Nym transport + non-interactive aggregation — is the strongest MW-native design I’d point a dev at.
- Dandelion++ stem batching. Have stem relays deliberately hold and aggregate transactions over a short window instead of relaying immediately. Trades latency for mixing, and lets you buy some cut-through even at low volume. Tradeoff to model: a Sybil that is the stem relay still sees the atomic form — so this helps against passive observers, not against the aggressive-peering attacker specifically. Needs honest analysis, not hand-waving.
- Normalize payjoin in the wallet. Grin transactions are already interactive, so it’s cheap to have the receiver also contribute an input. That doesn’t hide the graph edges, but it destroys the interpretation — the “these inputs are the sender’s, these outputs the receiver’s” heuristic that makes a reconstructed graph useful stops being reliable. Low-effort, high-leverage, and it degrades the attacker’s benefit rather than trying to raise their cost.
- Wallet-level self-spend churn — periodic self-aggregation to add noise. Weak (costs fees, filterable by a good analyst), but a cheap complement.
How I’d summarize it for a Grin dev
- Attack the attacker’s benefit, not just their cost. Payjoin-by-default is the best bang-for-buck — it makes a reconstructed graph ambiguous even if you can’t stop it being built.
- The real structural fix is non-interactive aggregation upstream of the P2P edge, ideally with a mixnet-fronted, many-provider design so no single aggregator becomes the new sniffer. This is the one place MW can do something Bitcoin structurally can’t.
- Be honest in messaging. Even fully deployed, this is plausible deniability and raised cost, not Monero/Zcash-grade unlinkability. Selling it as more than that is how you get the next “Breaking Mimblewimble” headline.
1 Like
Payjoin (receiver adds an output of its own) is already in the contract branch, indeed the best “bang for the buck” since there are no costs and it removes directionality from the transaction graph.
MWixnet is also ready to be tested. MWixnet would give a great privacy boost when more outputs are being aggregated, but for now focus should be on getting everything in the contract branch ready and tested IMO.
4 Likes