<l​oop.ster:matrix.org> What is the proof size, proving time, and verification time for FCMP++ proofs? Vs say, BP++?

<g​ingeropolous:monero.social> is there any interest in expanding zmq functionality?

loop.ster: do you mean compared to CLSAGs? The analogue of FCMP++ proofs to current transactions proofs is CLSAG. We don't currently use BP++ in txs, just BP+. We use BP+ proofs to prove range on the output amounts. We would still use BP+ for FCMP++ txs for output amount range proving

<l​oop.ster:matrix.org> Yeah, clsags, sorry.

Here's a table for the membership proof (just the FCMP part) size per transaction: github.com/seraphis-migration/moner…c430927/src/fcmp_pp/proof_len.h#L40. To get the full FCMP++ proof size (with SA/Ls), add 384*M, where M is the number of inputs.

The table is indexed first by number of inputs (row), then number of tree layers (column).

Sine Monero is at >150M outputs, we're at n_tree_layers=6, we will move to 7 when we hit ~300M IIRC

Here's a table of transaction byte sizes and verify times for different in/out counts, assuming n_tree_layers=7: seraphis-migration/monero #44#issuecomment-3150754862

<l​oop.ster:matrix.org> Perfect thanks. So not too dissimilar to CLSAG.

<l​oop.ster:matrix.org> I assume SNARKS were ever considered because ed25519 is not a snark-friendly curve.

<h​into:monero.social> > local node, when RPC connection that must be verified comes in, returns result of TOTP(details | secret | time) + time

<h​into:monero.social> DataHoarder: re: PoWER, how would this work considering ports can't be relied upon for RPC?

<h​into:monero.social> > If given expiration explicitly via generation these can be kept exactly as long as needed then removed away

<h​into:monero.social> This was the misunderstood idea, it's a DoS vector to keep these around

<h​into:monero.social> Another thing about PoW per connection when it comes to un-held RPC connections is that multiple users behind a single IP only need a single PoW, if we are assuming we only mark the IP as valid to relay high input TXs (also, how long does this stay valid before another PoW should be required?)

<h​into:monero.social> it may be simpler to do PoW per connection for P2P/ZMQ then PoW per TX for RPC

> This was the misunderstood idea, it's a DoS vector to keep these around

Only solved ones would be kept

also on details, they still need to provide the PoW

how much time: this is adjustable as a parameter in code

<h​into:monero.social> assuming a RPC client disconnects, they would have to calculate PoW for each TX since their port can't be depended on as an identifier, no?

they need to provide the information from before, which the node can verify without keeping state (besides single global one)

and keeping a list of solved PoW (which don't have DoS unless someone wastes power on solving pow, difficulty can raise as the list grows, and these have a fixed lifetime)

non-solved pow or failed ones don't need to be kept

<h​into:monero.social> I understand, but what binds the solved PoW to an RPC client, just an IP?

<h​into:monero.social> I am assuming the info from before can't be the only identifier as then the PoW can be shared, and also that ports cannot be relied upon

<h​into:monero.social> If the IP is the only identifier then that means we are okay with shared IPs (VPN, Tor exit) only needing 1 PoW for potentially many users

<j​effro256:monero.social> Verification is ~10x slower than a 16-member CLSAG. Sizes are only ~4x bigger than a 16-member CLSAG.

<j​effro256:monero.social> It's a big difference IMO. It's one that I think is worth it, but it will absolutely be noticeable to end users