I love Grin, but it has some unsolved problems. Recently I brainstormed with llm on how to fix them and put together a whitepaper for what I’m calling the Nenza protocol.
It tries to address few things:
No verifiable coin supply
Required transaction interactivity
Linkable transaction graph
No non-interactive payments
No new cryptography, no trusted setup - just wiring existing primitives together inside Mimblewimble.
Battery drain is questionable, iOS will close an app at background, using wakelock to prevent sleep for Android will drain battery like 50% for one night
I only gave it a quick read.
My initial thoughts are that I would question if the increase in chain size would be worth it, in particular the commitments to make supply auditable. I do not see the advantage over just verifying that the sum of all inputs and outputs match supply/emission. Making horizen snapshot proofs to allow faster syncing is however interesting, also for grin.
If I understand it correctly the part about non interactivity is that intermediate transaction steps are published on chain as a multisig with only the sender able to finalize the transaction? That is neat, but again I do wonder if the benefits outweight the costs in terms of complexity and chain growth.
Using single rangeproofs for multiple outputs is a great idea, I think also used by MWixnet. If Grin would use MWixnet it would solve the linkability issues for Grin while staying minimal in design.
Again, I gave it just a superficial read and I am no cryptographer so there might be real benefits that I overlook, will read it again when I have time.
The whitepaper numbers assume active CPU time only during block verification (~1-10 seconds per minute), not 24/7 foreground operation. The idea isn’t to keep the app awake constantly — it’s more like catching up on blocks when the app is opened, or in short periodic bursts. You’re right that a persistent wakelock would kill the battery — that’s not the intended design. The point is that the per-block verification work is light enough that a phone can do it in short bursts, not that it should run nonstop.
On chain size — yeah, the dual commitments do add overhead (~428 bytes/tx). The thing is, checking that inputs and outputs balance per-transaction only proves each transaction is valid individually. It doesn’t tell you the cumulative supply is correct without replaying every kernel from genesis. If something goes wrong in one block, you’d only catch it by re-verifying the whole chain. The IVC proof gives you a 32-byte constant in the header that lets any node verify total supply in milliseconds without replaying anything. And with Bulletproof aggregation the full tx size should actually come in below standard Grin’s — so the overhead isn’t permanent.
On non-interactivity — the silent payments part is actually simpler than multisig on-chain. Alice just builds the whole transaction by herself using Bob’s public key via ECDH, and broadcasts a normal-looking MW transaction. Bob scans the chain to find his outputs. Nothing extra on-chain, no intermediate steps published. The interactive adaptor Slatepack (§5) is a separate path — still 3 rounds like Grin but with sender broadcast control.
On MWixnet — fair point, it’s a solid approach for Grin. Nenza bakes unlinkability into the base protocol instead of relying on a separate mixing layer. Different tradeoffs, both have merit.
No; MWixnet doesn’t aggregate rangeproofs. Instead it uses a single kernel for the aggregation of all 1-input 1-output txs it mixes.
Aggregating rangeproofs is problematic because when some outputs get spent you want to forget about them and their rangeproofs while keeping the rangeproofs of all still unspent outputs.
You’re right about MWixnet and about the cross-transaction aggregation problem, if outputs have independent lifetimes you’d end up needing to keep half a proof around. In Nenza the aggregation is scoped to a single transaction, so both outputs always live and die together. The lifetime problem doesn’t apply.
@arct Just throwing this out there… Maybe you’d be interested in exploring this idea that the creator of Reticulum had. He describes combining ideas from Grin and Scrit.
specifically this part:
The reason I mention this is because if your ideas are only slightly different from Grin, it’ll be a hard sell. But something like this would be different enough that it might not even compete, if you know what I mean.
The “run Slatepack over Reticulum” bit sounds doable in principle, the no-blockchain / Scrit + Grin mashup is a bigger, separate idea and I haven’t dug in enough to say something. Either way I’m not the one to chase it, I’m slammed just trying to wrap my ideas after years of thinking as fast as possible.
Not selling anything or competing with Grin. I’ve been here since day one and posted because I respect this community. Happy if someone else wants to explore the Reticulum angle — I just don’t have the time or headspace right now. Thanks for sharing that.
I’m confused. In a standard tx, Alice and Bob each have 1 output. The 2 outputs get created at the same time, but get spent at different times, so their rangeproofs should be separate.
Oh you’re right, this is actually wrong. Alice and Bob spend their outputs at different times, nothing ties their lifetimes together. Aggregating their proofs would mean you can’t prune one without losing the other, so proofs have to stay per UTXO. The size claim in 9.1 is wrong and I’ll fix it. Thanks for looking deeply.