02:57:26 All you are 'fighting' for is e-penis of a guy you never met, that doesn't even have common decency to pay you for your time. 02:57:26 Do you think they care about Monero, or privacy or anything other than money? 10:03:30 I think everyone here knows that most Monero exchange withdrawals and desposits are traceable (Breaking Monero - poisoned outputs). How does it feel to go out and lie to people that they are private and then earn less than holding BTC on your bag? 13:11:26 Hey, I've got a quick question regarding Triptych and was hoping anyone on here could help me out with it: 13:11:27 In the protocol for parallel linkable one-of-many commitments (section 6) it uses the challenges $\mu_1, ..., \mu_{d-1}$ obtained from a hash / random oracle (obviously these challenges could alternatively be provided by the verifier instead). 13:11:27 Now my question is: what's the reason for each $\mu_\alpha$ being a separate challenge? Wouldn't it also work, if the verifier / random oracle only provides a single challenge $\mu$ and then using powers of this challenge, so $\mu_\alpha = \mu^\alpha$? 13:52:46 try emailing one of the paper's authors 14:16:49 IIUC I think this is what happens in practice, since a field multiplication should be cheaper than squeezing out another challenge from a hash function 14:17:56 However in theory/paper, it’s more about proving the protocol secure, which you use a random oracle for and concrete efficiency is not that important 14:19:42 Powers of a single verifier challenge should work fine as well 14:25:17 ok great, thanks :) 14:27:13 Note that this is just my intuition at this point; there would need to be a more careful analysis 15:58:29 https://eprint.iacr.org/2018/1210.pdf 15:58:39 did we discuss MProve back in 2018? 15:58:46 this doesn't ring a bell 15:59:01 was published in IEEE https://ieeexplore.ieee.org/document/8802437 17:48:01 “I thought, ‘I’m going to pump it and dump it,’ because I was interested and taking the ideas and implementing them in bitcoin. The bitcoin code base was far more interesting to me than monero, and I thought, ‘I’m not going to work on this codebase, it’s terrible,'” he recalls - fluffypony in an interview about Monero 19:21:32 how does cut through work? 19:25:05 hrm nvm, reading it. not what i expected 19:34:19 could u hash all the algorithmic inputs for triptych and then just do the verification required on those hashes? 20:20:12 though i guess even if that worked you'd still have to hash 64 or 128 or 256 things and then do the main math 20:33:36 hrmmm... i think im blending homomorphic encryption and hash functions maybe 21:31:17 Triptych relies heavily on the algebraic structure of inputs 21:31:27 Both the signing keys and the amount commitments 21:32:04 sarang: are these verification or signing times at the bottom? https://github.com/SarangNoether/skunkworks/blob/sublinear/triptych.md 21:32:32 Verification 21:32:45 I don't think I ever bothered with recording signing times, since they're one-off operations 21:32:54 okay good 21:32:55 * sgp_[m]2 uploaded an image: (27KiB) < https://matrix.org/_matrix/media/r0/download/monero.social/WHGJYOjMZxsKDNYeCniVEjVE/image.png > 21:33:08 are they comparable to these from the clsag paper? 21:33:23 No 21:33:33 CLSAG preprint is only the ring signature 21:33:54 That Triptych note includes range proofs, balance proofs, and signing zkp 21:34:13 oh so triptych is even better than how it appears comparing directly 21:34:37 The newer CLSAG performance tests include the balance proof, IIRC 21:34:46 So you'd just have to add in the corresponding batched range proof verifications 21:34:54 I tried to unify the perf_tests as much as reasonable 21:35:20 but I can pretty safely say triptych 128 is faster to verify than clsag 16? 21:36:17 unless those CLSAG numbers are unbatched 21:36:31 The CLSAG preprint does not batch 21:36:34 because CLSAG does not batch 21:36:58 got it 21:37:19 "but I can pretty safely say triptych 128 is faster to verify than clsag 16?" this is reasonably true then no? 21:37:38 I'd need to check if those numbers were on the same machine or not 21:37:48 If not, the wall times are meaningless 21:37:53 yeah that's a critical assumption 21:51:47 If you build from source, you can make perf_tests for whatever params you like 21:52:00 I've run these numbers before, but I don't recall if I stored the results :/ 21:56:57 sgp_[m]2: do you get PMs from freenode accounts? 21:59:18 I should be able to 21:59:18 sarang you can set yourself to +R to block spammers 21:59:25 oh.. 23:48:39 What ring size is being targeted for the Triptych upgrade? 23:49:29 ~128 23:49:36 But not set in stone AFAIK 23:49:47 This is a placeholder. 23:49:59 I just needed one. 23:50:13 Ok, thanks. 23:50:14 Also, has anyone created a comparison table of all the new ring signature proofs from the last year or so? Triptych, CLSAG, RCT3, Arcterus(?), etc 23:50:38 It would be nice to see the tradeoffs and why Triptych was chosen over the others. 23:50:44 Just to keep up to speed 23:51:19 sarang or sgp_ would be the most likely to have something like that, I think! 23:51:36 sarang did, most are likely findable via https://github.com/SarangNoether/skunkworks 23:54:02 Thanks! I will dig through the branches and see what I find