<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?

<h​andpickencounter:matrix.org> this is the only actual advantage zcash actually has over monero atm, their anon-set is backed by zero knowledge.

<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>

<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)

<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

<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

<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.

<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.

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.

"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"

wallet2.h has void allow_mismatched_daemon_version(bool allow_mismatch) but I cannot find an equivalent for wallet2_api.h

<r​brunner7:monero.social> If no wallet app using the Wallet API saw a need for that call, it's missing.

<r​brunner7:monero.social> SNeedlewoods 's "Wallet API completing PR" will add it: monero-project/monero #9464

<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

Ok thanks

Is wallet2_api.h still recommended over wallet2.h?

<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!" :)

<r​brunner7:monero.social> Lol, in 2 days it's exactly 1 year since my announcement on Reddit: old.reddit.com/r/Monero/comments/1c…e_software_wallet_api_will_probably

Well for what it's worth I like the API a lot better : )

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

<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.

<r​brunner7:monero.social> Beside the small problem that such interfaces do not fall from the sky, fully fleshed out ...

<s​yntheticbird:monero.social> monero-project/meta #1195

<j​effro256:monero.social> binarybaron2: if doing regtest, you have to use the flag `--allow-mismatched-daemon-version` on the wallet