what's the issue with upgrading curves? you just have old and new type keys running alongside each other

you could also just create a merkle witness proof using the current bulletproofs system

by engineering poseidon hash into a circuit

imagine if monero implements this, then the anonymity set is practically infinite, and there will be zero competition for monero

that way you wouldn't need to upgrade the curves (if that's a big issue)

narodnik: lol supporting two entirely separate crypto stacks, forever, would be an impossible mantinance burden

you'd also have to add special transaction types to handle conversions between the two curves

and you'd need the ability to do membership proofs over sets containing points on both curves, which may negate the benefits of the new curve

(maybe. but even answering this is a nontrivial crypto question)

I think the main problem would be doing cross-curve balance checks

everything else can be isolated

yeah, if you could use both curves within a single transaction

maaybe in monero land you could get away with a hf that basically said "we're using the new curve, the only thing you're allowed to do with your old/existing coins is convert them" but that would be really invasive

it's not too different from what seraphis would/will do

the address scheme would break anyway

not that breaking the address scheme a second time would be appealing at all..

andytoshi: people can upgrade from old coins to new ones, it's not a big deal but would be a much welcome change that puts monero on firm competitive ground

literally the main critique of monero is anon set size. imagine if that is solved. then monero would solve the biggest issue, and might become finally a large mcap project if it could pull this off

you can eventually phase out the old stack using checkpoints

but ok lets say you don't want to use a new curve

why not then introduce arithmetization using the current bulletproofs?

then code a membership proof using circuits

what would be the rough size and verification time for such a proof?

i can write a benchmark in rust with zcash halo2 API, where it does 32 poseidon hashes

i think they normally use sinsemilla though for merkle trees

it's mainly dependent on the number of rows, which is a power of 2 always due to 2-adicity of the group

i'd also be very curious about the benchmark numbers

i agree with you that if monero could get an "effectively infinite" anon set without a trusted setup or weird crypto assumptions, that'd be a game changer

my computer is lagging a huge amount so will restart one sec for the benchmark

cool! tho don't rush on my part, i almost never contribute to this project and don't have time to help anytime soon

proof verify [0.018967216 s]

here's the benchmark

code i hastily threw together just now

this is using bulletproofs for inner product proof, so there's no trusted setup

it proves that $leaf has a pathway to $root without revealing the exact path

0.019 secs

narodnik: how does this compare to the current implementation?

idk but this tree has a size of 2^32, while current ring size is 128?

19 ms is not bad at all. What is the proof size?

let me check

6403 bytes

I think the seraphis membership proof is something like 800-ish bytes

so an 8x size increase for 33554432x increase in anonymity set

seems worth it

definitely worth looking into, would be nice if the proof was compatible with the seraphis masked key, then it'd be pretty much plug and play

it's pretty much just defining a polynomial relation to prove the merkle tree inclusion, then committing to that using the bulletproofs scheme

given a and b are boolean ints, you can arithmetize them as so:

a AND b = ab

a OR b = a + b - ab

NOT a = 1 - a

then we convert our algo to that format, and we construct polynomials that interpolate those points, then commit and open it using bulletproofs

this is what a seraphis-compatible membership proof needs to do: