10:10:40 <tevador> It seems that Seraphis offers strictly weaker privacy than RingCT against a quantum adversary. Each SpCompositionProof directly leaks k_s if the adversary knows the discrete logs of X and U. This immediately links the output to a particular wallet.
12:42:43 <UkoeHB> tevador: how does the dlp of X and U leak k_s?
13:08:31 <tevador> The proof gives 6 equations with 6 variables (a_t1, a_t2, a_ki, a, b, c), so it's solvable. K_o = a G + b X + c U.
13:08:43 <tevador> c is the spend key
13:15:51 <tevador> UkoeHB: https://paste.debian.net/plainh/097e9baf
13:23:46 <UkoeHB> tevador: that adversary seems to know more DLPs than just between X and U
13:25:12 <UkoeHB> If you can get any arbitrary DLP, then you only need two to get k_s: between K” and K_t1, and between KI and U.
13:25:21 <tevador> I meant a quantum adversaty in general, able to solve any DLP.
13:26:33 <UkoeHB> I don’t mind updating jamtis for better forward-secrecy against a DLP-breaking adversary (quantum or otherwise). I’ll post an update on the gist today, it’s easy enough.
13:27:24 <tevador> it's not about Jamtis, but the Seraphis ownership proof
13:30:11 <tevador> The proof also gives the output key that was spent (= b X + c U), which breaks the ring signature. But this is the same with RingCT.
13:33:00 <tevador> UkoeHB: by updating Jamtis, you mean to also tweak the U-component?
13:58:19 <UkoeHB> Yes, tweak the U
13:59:51 <UkoeHB> I’m looking back at the modified chaum-pedersen proof used by lelantus-spark, which seems to have better forward-secrecy against a DLP-breaker than composition proofs.
14:48:17 <UkoeHB> nvm, there is a system of equations that can be solved to get all the variables
15:27:59 <tevador> is there no way to make the proof perfectly hiding? even at the cost of computational soundness
15:35:54 <Lazarus> Hi friends,
15:36:12 <Lazarus> https://decrypt.co/84540/privacy-blockchain-putting-100-million-compete-zcash-monero
15:37:12 <Lazarus> Is anyone familiar with what Findora is doing? Any key advantages they have vs. Monero and zcash?
15:37:33 <UkoeHB> tevador: no idea
15:47:27 <UkoeHB> Lazarus: looks like a dead project and possibly a scam
15:56:40 <rbrunner> From the article: "He added that Findora's research team created the "bulletproofs" technology used on Monero."
15:59:28 <Lazarus> Ha, curious.
15:59:28 <rbrunner> So please show a little respect :)
16:00:55 <dangerousfreedom> <tevador> "is there no way to make the..." <- Pedersen commitments scheme are perfectly hiding, right? What do you mean? The equations used are not Pedersen like or you would like to have schemes that do not depend on the DLP like quantum resitant algorithms?
16:01:23 <rbrunner> And the txs on their blockchain are sooooo private right now: https://findorascan.io/transactionshash?hash=6B502F68C3C5C57ADDA6DF196FE595D975174F57929156BB3B09AAC068BEE5C0
16:01:23 <baro77[m]> this  is/was their tech docs page: https://wiki.findora.org/docs/findora_basics/introduction/  the only relevant thing (if true) to my eyes being the state machine replication algo was a fork of tendermint, so a BFT-like a not a longest-chain... by the way.. any way to use a leader election strategy permitting permissionless access with that kind of SMR, as far as you know? 
16:01:59 <baro77[m]> s/findora_basics/findora\_basics/, s/a/and/
16:03:19 <rbrunner> And I guess the 100 millions for that fund will just rain from the sky.
16:03:28 <tevador> dangerousfreedom: I meant to have a proof that says you know a, b, c such that K = a G + b X + c U, but won't leak a, b, c if the DLP is broken.
16:18:59 <dangerousfreedom> <tevador> "dangerousfreedom: I meant to..." <- I see, AFAIK only quantum resistant algos do it. But I guess we never seriously consider implementing something like that as we are far away from this scenario.
16:21:36 <tevador> Forward secrecy is needed *now*, not at some point in the future. It's inevitable that ed25519 will be broken and we want past transctions to stay private.
16:22:30 <dangerousfreedom> Hello guys, a quick update from my side:
16:22:30 <dangerousfreedom> I took some vacation last week and now I'm ready to continue annoying you :)
16:22:30 <dangerousfreedom> I finished what I proposed to do related to the moneroinflation project but I still didnt answer all the questions that I have about it (as there is the bp+ era). I feel ready though to continue working to improve Monero so in the next month I will still continue working on finishing the moneroinflation project (scan the bp/bp+ era using my RUST codes) and improving a bit more the website. Meanwhile, I will be organizing
16:22:30 <dangerousfreedom> my tasks to create a wallet for Seraphis asap. I would be happy to get your thoughts on the required tasks and TODOS so I can better prioritize my work. (I will definitely need the help and inputs from koe, tevador, jberman, rbrunner and others so be aware that I will reach out to you soon :))
16:23:48 <dangerousfreedom> tevador: I agree. I just don't know how to do it without radically changing the crypto schemes. Moreover, I believe that there isn't a standard on how to achieve it either.
16:28:58 <dangerousfreedom> I guess we have much higher risks with bad implementations of the known schemes than with quantum computers now. Really nice spot about these 6 equations/6 unknows. Something like that is much more harmful. Also allowing non-canonical points/scalars could be harmful if not handled correctly.
16:34:03 <moneromooo> Anything could be harmful if not handled correctly.
16:58:59 <rbrunner> dangerousfreedom: Right now I think merely coming up with a solid list of tasks needed to implement a Seraphis wallet will be a difficult task in itself. Tasks all the way down :)
17:18:34 <dangerousfreedom> Haha yeah :)
18:15:26 <tevador> https://gist.github.com/tevador/23a84444df2419dd658cba804bf57f1a
18:15:35 <tevador> reviews/comments are welcome
18:26:22 <dangerousfreedom> <tevador> "https://gist.github.com/tevador/..." <- Wow! Amazing!!!
18:27:19 <dangerousfreedom> I will definitely look into it carefully 
18:36:32 <tevador> I'm leaning towards SPHINCS+-SHA-256-128f-simple as the QR signature scheme. Least likely to be backdoored by NSA. Replacing SHA-256 with Blake2s should give a 2x speed-up for hardware wallets.
23:35:33 <kayabanerve[m]> tevador: I believe NACK. SHA-256 was found to be insecure IIRC.
23:35:57 <kayabanerve[m]> *tens of bits less secure when used in a WOTS derived scheme
23:36:10 <kayabanerve[m]> https://eprint.iacr.org/2022/1061.pdf
23:37:23 <kayabanerve[m]> The exact ciphersuite you named may not be category 5, and accordingly not harmed by this research (as SHA-256 may not be the lower bound). If that's the case, I'll drop my commentary :P But I did remember this paper and wanted to be sure it was represented.
23:37:47 <kayabanerve[m]> Though aren't we able to use schemes which only allow a single message without issue?
23:38:29 <kayabanerve[m]> If SPHINCS+ offers more efficient public keys, great, but I don't believe we have benefits from the multi-messaging function offered. Accordingly, wouldn't pure WOTS+ be possible?
23:42:18 <kayabanerve[m]> *Yes, the proposed one is category one. So ACK on the proposed suite.
23:42:59 <kayabanerve[m]> *assuming we did use SPHINCS+.
23:43:36 <kayabanerve[m]> Though I can't comment on s/f simple/robust at this time.