Hi everybody

Is there chance, or discussion, about ever moving Monero away from decoys to a zero-knowledge approach?

or is there a reason why decoys are favored to zero knowledge?

nakedpony: Efficiency/no trusted setup is my understanding, but I could be wrong.

With the new CLSAG signatures going around, will wallets using the existing signature format stop producing valid transactions? Or is it an optionally faster signature method that everyone should use but is not required to?

theres zk-starks now

It does sound like existing signatures will still be fully valid. Just double checking.

vtnerd: Define now :P Starklabs has existed for years. I don't think they've ever been viable though

but the techniques researched by the MRL attempt to within the bounds of existing assumptions

zk-starks claims to not require a trusted setup

I did note efficiency as a reason

Yes, but there's a reason ZCash (or any single cryptocurrency out there) doesn't use Starks. They're horrendously slow

but it has new novel "assumptions" that are not proven, that a different than the assumptions monero assumes (ECDLP hardness and hash construction)

well its beyond that really

The theory has existed for years, and I'm pretty sure there have also been construction/verification procedures for years (with the same standard of review as zerocoin/zerocash)

Im not sure of the perf they achieve now though

But the proof sizes and horrendous, so even if any algorithm is secure as defined...

The most recent ZK protocol I remember hearing about was SONIC, which was still snarks

Whoa this is some enlightening discourse

Page 3 has a lot of comparisons made

if your google zk-starks ethereum comes up first

which means they've found a new thing to pump and do nothing with

Page 14 has timing information. It becomes decent with aggregation, yet the aggregation scale is... interesting

Starkware has existed for years and had a theoretically working STARK model at the start. Their work has been on viability and a crypto implementing said viable algorithm.

For some reason, neither went anywhere...

seems to be the big achievement thus far ?

no idea if it actually works or is usable though, thats always the catch

Seems to be like ZK Rollups

It's not actually used for any privacy. It's to provide succinct proofs of a large amount of data

So you can conduct a ton of sends/trades on a second layer/side chain, and then publish a few KB to Ethereum with the result, which the Smart Contract can verify

It's an important distinction to note here

yeah was looking at the description, its weird

possibly a ruse to get ZK+DEX+blockchain buzzwords into one project

or its a proof of funds I suppose ?

their services still has knowledge of all the trades

It's a trustless scalability technique which I actually really respect. That said, it's as private as Lightning.

Only the aggregate is published on the underlying network, but the actions aren't private when conducted.

So it's not private.

hmm so the funds still remain in user control then

regret crapping on this, actually kind of interesting

this isn't marketed as a privacy scheme at least, for the reasons you stated

ZK Rollups are the more abstracted version IIRC and it's great

Specified anonymity sets ("decoys") and zero-knowledge proving systems are not necessarily distinct things

It all comes down to the transaction protocol you build with different cryptographic constructions

Bit of a repost, but because it wasn't answered, I'd like to ask again. The new CLSAG signatures in the hard fork. If I have a program creating transactions using the existing signature scheme, will those remain compatible? It sounds like it will, but I'd love to confirm.

I didn't roll my own MLSAG library, of course. I did directly wrap the internal RingCT lib though...

*I do understand CLSAG construction/verification is different. Asking on a protocol level.

Never mind. Read through the PR, found the banning of all types other than CLSAG.

Only CLSAG will be accepted

Otherwise it's less efficient and a vector for fingerprinting

Looks like MLSAG will get rejected on v14. Do we want a quick v14 ? There's just a v13 defined in the fork table atm.

I always thought that was the plan (v13 and then v14 after 720 blocks)

When did people want the fork ? October ish IIRC ?

I saw a md-Oct date somewhere

mid

and yes, I would expect a v13 & v14 for txn format changes

October 17th is the fork date

which was publicly announced

Publicly announced... before any code is PRed for it... Amazing.

I'll add two forks for this then.

When do people want a testnet with those ?

plan was to release binaries 1 month before HF, so maybe set the testnet to 1 month before it too

In 6739 now. Testnet can be added shortly before it gets merged.

ty

moneromooo: I thought an announcement was necessary since we decided the date one month agod and weare 1 month and a half away from the hard fork.

Oooh, that's where the ground changing chat came from :D

yeah :P