Thread by @kayabaNerve

I don't like posts that go

"Here's 10 reasons why MYBAGS is going to revolutionize cryptocurrency and also solve world hunger"

Even when there's something interesting happen, I don't like the exaggerated language.

I'm also wondering if we're in a Monero Renaissance.

I posted the written up proposal Full Chain Membership Proofs over RingCT on March 30th. Just over a month ago. It'd be notably slower than a Seraphis version and not forward secret. That means a Quantum Computer could break sender privacy, something considered inherent to RingCT

A week later, on April 5th, I noticed it allowed malleating output keys. Malleation isn't inherently bad!

Key image malleation? Bad. Enables double spends.

Output malleation?

???

So I looked into it.

Turns out, it's fine, and it changed output keys from xG to xG + aT (any xG key simply has a=0). I started wondering the impact of that.

It trivially gives you outgoing view keys. You now need the private keys x, a, to spend, yet only x is needed to calculate the key images.

This means cold wallets don't have to be brought online to calculate key images, multisig is a lot simpler, and you non-interactively audit the balance of public wallets. Really nice UX improvements, with a lot less technical complexity.

Then I noticed this same malleation offers forward secrecy, if we make one of the proofs forward secret (it wasn't already). This made my FCMPs proposal at feature-parity with Seraphis, despite not requiring a migration. It was still slower though.

On April 28th, I asked why not include old CN outputs, made prior to RingCT? They'd be compatible with this scheme, unify all the privacy pools, and make it so there's only one active set of protocol rules

(Right now, we still have logic for migrating TXs active which is a pain)

I posted the initial paper on April 23rd. It got largely final and in a feedback stage on the 27th. I was funded for my work on the 25th, and a earmarked fund for review and audits was funded on the 29th.

Tevador posted JAMTIS for this scheme on the 28th.

For context, JAMTIS was a new address protocol adding privacy and functionality. It was originally intended for RingCT, yet moved to being for Seraphis. Now, a version exists for FCMPs over RingCT. Kinda full circle there 😅

The new JAMTIS works with existing addresses and:

1) Gives them forward secrecy for all future outputs
2) Solves the Janus attack, except when trying to link a main address with subaddresses

If you only give out subaddresses right now, as Feather defaults to, you'll automatically gain the new privacy features *without creating and distributing new addresses*, once JAMTIS is live.

On April 28th, I also realized the proof will only incur *minor* overhead compared to Seraphis. Most of the performance overhead had been eliminated.

May 1st, moving to Ristretto was proposed (much harder to muck up, faster than what's currently done).

I actually proposed/campaigned for Ristretto years ago, so I find it quite funny to see here. That hasn't been accepted into the proposal yet and may end up in a future hard fork/never. I'd like to see it someday though :)

Then May 2nd, I proposed... redefining key images 😱

Theoretically, that'd make a new privacy pool requiring a migration and allow double spends! Right???

Nope. New key images can be calculated from the old ones. We'd be able to keep one global pool, with no migrations.

The reason for the redefinition is it'd remove ~25% of operations when adding new outputs to the database, and with a slight allowance regarding amount commitments as well, it'd remove something called "permissibility" which is a minor DoS vector (emphasis on minor).

That still needs to be discussed with the community at larger. I'm unsure it'll make the cut.

But with all the flurry of development and how much better it keeps getting, I'm incredibly excited ^_^

Just waiting for something to come back and bite me...

As for timeline, initially, it'll just be FCMPs. No forward secrecy, no outgoing view keys, no JAMTIS.

The goal is to keep it and lean and mean so it can be deployed as soon as reasonable.

Development is going well. The proving system we want to use, Generalized Bulletproofs (Generalized Generalized Bulletproofs if you're in the know) was recently proven by the wonderful Aaron Feickert @ @cypher_stack.

I'm reaching out to ZK auditors regarding components already.

The goal isn't to rush and force it through. It's to aggressively parallelize the work, including full review and audits, to minimize bottlenecks. With the proving system proven, we can audit its impl. While that's done, we can audit the circuit. Then, their joining. Etc.

All in all, I'm incredibly excited ^_^

Still wondering if I can consider it a Monero renaissance 🤔 At least a RingCT renaissance.

Here's hoping it continues well :D