02:09:00 Hi everybody 02:09:22 Is there chance, or discussion, about ever moving Monero away from decoys to a zero-knowledge approach? 02:10:05 or is there a reason why decoys are favored to zero knowledge? 02:15:49 nakedpony: Efficiency/no trusted setup is my understanding, but I could be wrong. 02:16:31 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? 02:16:38 theres zk-starks now 02:16:47 It does sound like existing signatures will still be fully valid. Just double checking. 02:17:04 vtnerd: Define now :P Starklabs has existed for years. I don't think they've ever been viable though 02:17:13 but the techniques researched by the MRL attempt to within the bounds of existing assumptions 02:17:49 zk-starks claims to not require a trusted setup 02:17:54 I did note efficiency as a reason 02:18:14 Yes, but there's a reason ZCash (or any single cryptocurrency out there) doesn't use Starks. They're horrendously slow 02:18:19 but it has new novel "assumptions" that are not proven, that a different than the assumptions monero assumes (ECDLP hardness and hash construction) 02:18:44 well its beyond that really 02:18:54 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) 02:19:12 Im not sure of the perf they achieve now though 02:19:16 But the proof sizes and horrendous, so even if any algorithm is secure as defined... 02:19:30 The most recent ZK protocol I remember hearing about was SONIC, which was still snarks 02:19:55 https://eprint.iacr.org/2019/099.pdf 02:19:58 Whoa this is some enlightening discourse 02:20:42 Page 3 has a lot of comparisons made 02:20:52 if your google zk-starks ethereum comes up first 02:21:04 which means they've found a new thing to pump and do nothing with 02:22:34 Page 14 has timing information. It becomes decent with aggregation, yet the aggregation scale is... interesting 02:23:29 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. 02:23:35 For some reason, neither went anywhere... 02:23:58 https://www.starkdex.io/ 02:24:14 seems to be the big achievement thus far ? 02:24:40 no idea if it actually works or is usable though, thats always the catch 02:27:53 Seems to be like ZK Rollups 02:28:08 It's not actually used for any privacy. It's to provide succinct proofs of a large amount of data 02:28:33 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 02:29:10 It's an important distinction to note here 02:29:23 yeah was looking at the description, its weird 02:30:36 possibly a ruse to get ZK+DEX+blockchain buzzwords into one project 02:31:08 or its a proof of funds I suppose ? 02:32:34 their services still has knowledge of all the trades 02:53:12 It's a trustless scalability technique which I actually really respect. That said, it's as private as Lightning. 02:53:45 Only the aggregate is published on the underlying network, but the actions aren't private when conducted. 02:53:59 So it's not private. 02:58:03 hmm so the funds still remain in user control then 03:00:01 regret crapping on this, actually kind of interesting 03:03:18 this isn't marketed as a privacy scheme at least, for the reasons you stated 03:12:09 ZK Rollups are the more abstracted version IIRC and it's great 03:33:13 Specified anonymity sets ("decoys") and zero-knowledge proving systems are not necessarily distinct things 03:33:34 It all comes down to the transaction protocol you build with different cryptographic constructions 04:17:31 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. 04:18:08 I didn't roll my own MLSAG library, of course. I did directly wrap the internal RingCT lib though... 04:33:32 *I do understand CLSAG construction/verification is different. Asking on a protocol level. 04:40:57 Never mind. Read through the PR, found the banning of all types other than CLSAG. 04:53:32 Only CLSAG will be accepted 04:53:48 Otherwise it's less efficient and a vector for fingerprinting 07:31:15 -xmr-pr- moneroexamples opened issue #6774: Setting MONERO_WALLET_CRYPTO_LIBRARY to `cn`? 07:31:15 -xmr-pr- > https://github.com/monero-project/monero/issues/6774 10:47:29 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. 10:54:01 I always thought that was the plan (v13 and then v14 after 720 blocks) 11:05:21 When did people want the fork ? October ish IIRC ? 11:05:37 I saw a md-Oct date somewhere 11:05:39 mid 11:06:29 and yes, I would expect a v13 & v14 for txn format changes 11:10:01 October 17th is the fork date 11:10:16 which was publicly announced 11:12:25 Publicly announced... before any code is PRed for it... Amazing. 11:13:03 I'll add two forks for this then. 11:14:35 When do people want a testnet with those ? 11:20:33 plan was to release binaries 1 month before HF, so maybe set the testnet to 1 month before it too 11:20:55 In 6739 now. Testnet can be added shortly before it gets merged. 11:22:13 https://web.getmonero.org/2020/08/18/network-upgrade-october-2020.html 11:25:37 ty 11:27:38 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. 11:27:48 Oooh, that's where the ground changing chat came from :D 11:27:58 yeah :P 16:01:15 -xmr-pr- wojtasss opened issue #6775: --txpool-notify propsal 16:01:15 -xmr-pr- > https://github.com/monero-project/monero/issues/6775