02:09:14 <m-relay> <h​andpickencounter:matrix.org> is FCMP actually zero knowledge? thats the only way it can advertise "forward secrecy" afaik. but it still relies on ECC so a CRQC can theoretically print coin?
02:12:51 <m-relay> <h​andpickencounter:matrix.org> this is the only actual advantage zcash actually has over monero atm, their anon-set is backed by zero knowledge.
04:43:10 <m-relay> <j​effro256:monero.social> Hmmm? Zero-knowledge proving systems don't inherently mean anti-forging security against discrete log solvers. Some are, like ZK-STARKS, but (last time I checked) Zcash uses ZK-SNARKs (with an "N") in their protocol called Halo2 which isn't anti-forging secure against discrete log solvers. FCMP++, which uses a variation of Bulletproofs called "Generalized Bulletproofs", also isn't<clipped message>
04:43:10 <m-relay> <j​effro256:monero.social>  secure against discrete log solvers. But both FCMP++ and Halo2  are still *quantum forward secret*, meaning that the proofs still reveal zero-knowledge about the statements proven, even with access to a discrete log solver (i.e. a working quantum computer)
04:44:10 <m-relay> <j​effro256:monero.social> In short, quantum properties between Zcash's protocol and Monero's protocol are basically the same: not forging resistant, but with forward privacy
04:47:14 <m-relay> <j​effro256:monero.social> To be clear, Zcash also still relies on the discrete log problem over elliptic curves for their cryptographic hardness assumption in Halo2, hence why it doesn't have anti-forging resistant against a quantum computer
06:06:29 <m-relay> <h​andpickencounter:matrix.org> That was my understanding which  south to confirm, STARKs are ideal but the proof size is unacceptable for individual transacitons. However FCMP++ is still not mainline so sadly "quantum properties between Zcash's protocol and Monero's protocol" aren't the same yet.
06:06:39 <m-relay> <h​andpickencounter:matrix.org> That was my understanding which  I sought to confirm, STARKs are ideal but the proof size is unacceptable for individual transacitons. However FCMP++ is still not mainline so sadly "quantum properties between Zcash's protocol and Monero's protocol" aren't the same yet.
12:55:39 <binarybaron2> I'm building a wrapper around wallet2_api.h (rust). I'm trying to test on my local regtest network but refreshing does not work. I believe this is because I need to allow_mismatched_daemon_version. But it seems to me that wallet2_api.h does not allow enabling that? wallet2.h does have support for it though.
12:55:40 <binarybaron2> "wallet/wallet2.cpp:3493:N5tools5error22incorrect_fork_versionE: Unexpected hard fork version v16 at height 1. Make sure the node you are connected to is running the latest version"
12:57:01 <binarybaron2> wallet2.h has void allow_mismatched_daemon_version(bool allow_mismatch) but I cannot find an equivalent for wallet2_api.h
13:03:55 <m-relay> <r​brunner7:monero.social> If no wallet app using the Wallet API saw a need for that call, it's missing.
13:04:24 <m-relay> <r​brunner7:monero.social> SNeedlewoods 's "Wallet API completing PR" will add it: https://github.com/monero-project/monero/pull/9464/
13:06:14 <m-relay> <r​brunner7:monero.social> As far as I know that PR waits for quite a wile already for a second review and/or jeffro256 having some time between his many balls in the air to have a look, so it's unclear when this will get merged to master, and more unclear still when it will find its way into a release
13:09:34 <binarybaron2> Ok thanks
13:09:45 <binarybaron2> Is wallet2_api.h still recommended over wallet2.h?
13:13:16 <m-relay> <r​brunner7:monero.social> The idea still is to phase out `wallet2.h` over time, and make the Wallet API the sole public API. But well, I don't think we reached already all devs with this decision, and maybe when time finally comes to retire `wallet2.h` hordes of offended devs will come out of the woods and shout "Whaaaaat, nobody ever told something!" :)
13:18:02 <m-relay> <r​brunner7:monero.social> Lol, in 2 days it's exactly 1 year since my announcement on Reddit: https://old.reddit.com/r/Monero/comments/1cf8oom/the_monero_core_software_wallet_api_will_probably/
13:18:27 <binarybaron2> Well for what it's worth I like the API a lot better : )
13:20:11 <binarybaron2> I'm assuming #9464 is likely to get merged at some point so I'll start building the wrapper on top of SNeedlewoods branch from the start
13:22:47 <m-relay> <r​brunner7:monero.social> I hope so. Much work, and much care, went into this, and I think it's a reasonable foundation, and a workable compromise, compared with coming up with some brand-new interface designed out on a green field.
13:25:02 <m-relay> <r​brunner7:monero.social> Beside the small problem that such interfaces do not fall from the sky, fully fleshed out ...
13:52:01 <m-relay> <s​yntheticbird:monero.social> https://github.com/monero-project/meta/pull/1195
14:11:03 <m-relay> <j​effro256:monero.social> binarybaron2: if doing regtest, you have to use the flag `--allow-mismatched-daemon-version` on the wallet