02:57:26 <asieamxofn> 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 <asieamxofn> Do you think they care about Monero, or privacy or anything other than money?
10:03:30 <fwsrmenjvhqd> 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 <madhatter369> Hey, I've got a quick question regarding Triptych and was hoping anyone on here could help me out with it:
13:11:27 <madhatter369> 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 <madhatter369> 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 <UkoeHB> try emailing one of the paper's authors
14:16:49 <kenshamir[m]> <madhatter369 "Now my question is: what's the r"> 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 <kenshamir[m]> 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 <sarang> Powers of a single verifier challenge should work fine as well
14:25:17 <madhatter369> ok great, thanks :)
14:27:13 <sarang> Note that this is just my intuition at this point; there would need to be a more careful analysis
15:58:29 <sgp_[m]2> https://eprint.iacr.org/2018/1210.pdf
15:58:39 <sgp_[m]2> did we discuss MProve back in 2018?
15:58:46 <sgp_[m]2> this doesn't ring a bell
15:59:01 <sgp_[m]2> was published in IEEE https://ieeexplore.ieee.org/document/8802437
17:48:01 <idtopelbhh> “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 <gingeropolous> how does cut through work?
19:25:05 <gingeropolous> hrm nvm, reading it. not what i expected
19:34:19 <gingeropolous> could u hash all the algorithmic inputs for triptych and then just do the verification required on those hashes?
20:20:12 <gingeropolous> 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 <gingeropolous> hrmmm... i think im blending homomorphic encryption and hash functions maybe
21:31:17 <sarang> Triptych relies heavily on the algebraic structure of inputs
21:31:27 <sarang> Both the signing keys and the amount commitments
21:32:04 <sgp_[m]2> sarang: are these verification or signing times at the bottom? https://github.com/SarangNoether/skunkworks/blob/sublinear/triptych.md
21:32:32 <sarang> Verification
21:32:45 <sarang> I don't think I ever bothered with recording signing times, since they're one-off operations
21:32:54 <sgp_[m]2> 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 <sgp_[m]2> are they comparable to these from the clsag paper?
21:33:23 <sarang> No
21:33:33 <sarang> CLSAG preprint is only the ring signature
21:33:54 <sarang> That Triptych note includes range proofs, balance proofs, and signing zkp
21:34:13 <sgp_[m]2> oh so triptych is even better than how it appears comparing directly
21:34:37 <sarang> The newer CLSAG performance tests include the balance proof, IIRC
21:34:46 <sarang> So you'd just have to add in the corresponding batched range proof verifications
21:34:54 <sarang> I tried to unify the perf_tests as much as reasonable
21:35:20 <sgp_[m]2> but I can pretty safely say triptych 128 is faster to verify than clsag 16?
21:36:17 <sgp_[m]2> unless those CLSAG numbers are unbatched
21:36:31 <sarang> The CLSAG preprint does not batch
21:36:34 <sarang> because CLSAG does not batch
21:36:58 <sgp_[m]2> got it
21:37:19 <sgp_[m]2> "but I can pretty safely say triptych 128 is faster to verify than clsag 16?" this is reasonably true then no?
21:37:38 <sarang> I'd need to check if those numbers were on the same machine or not
21:37:48 <sarang> If not, the wall times are meaningless
21:37:53 <sgp_[m]2> yeah that's a critical assumption
21:51:47 <sarang> If you build from source, you can make perf_tests for whatever params you like
21:52:00 <sarang> I've run these numbers before, but I don't recall if I stored the results :/
21:56:57 <sarang> sgp_[m]2: do you get PMs from freenode accounts?
21:59:18 <sgp_[m]2> I should be able to
21:59:18 <UkoeHB> sarang you can set yourself to +R to block spammers
21:59:25 <UkoeHB> oh..
23:48:39 <childofthecorn[m> What ring size is being targeted for the Triptych upgrade?
23:49:29 <sethsimmons> ~128
23:49:36 <sethsimmons> But not set in stone AFAIK
23:49:47 <moneromooo> This is a placeholder.
23:49:59 <moneromooo> I just needed one.
23:50:13 <childofthecorn[m> Ok, thanks.
23:50:14 <childofthecorn[m> 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 <childofthecorn[m> It would be nice to see the tradeoffs and why Triptych was chosen over the others.
23:50:44 <childofthecorn[m> Just to keep up to speed
23:51:19 <sethsimmons> sarang or sgp_ would be the most likely to have something like that, I think!
23:51:36 <moneromooo> sarang did, most are likely findable via https://github.com/SarangNoether/skunkworks
23:54:02 <childofthecorn[m> Thanks! I will dig through the branches and see what I find