10:24:54 <narodnik> what's the issue with upgrading curves? you just have old and new type keys running alongside each other
10:26:21 <narodnik> you could also just create a merkle witness proof using the current bulletproofs system
10:26:29 <narodnik> by engineering poseidon hash into a circuit
10:27:55 <narodnik> imagine if monero implements this, then the anonymity set is practically infinite, and there will be zero competition for monero
10:29:13 <narodnik> that way you wouldn't need to upgrade the curves (if that's a big issue)
14:52:44 <andytoshi> narodnik: lol supporting two entirely separate crypto stacks, forever, would be an impossible mantinance burden
14:53:04 <andytoshi> you'd also have to add special transaction types to handle conversions between the two curves
14:53:46 <andytoshi> 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
14:54:13 <andytoshi> (maybe. but even answering this is a nontrivial crypto question)
14:55:37 <UkoeHB> I think the main problem would be doing cross-curve balance checks
14:55:51 <UkoeHB> everything else can be isolated
14:55:54 <andytoshi> yeah, if you could use both curves within a single transaction
14:55:59 <andytoshi> 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
14:56:47 <UkoeHB> it's not too different from what seraphis would/will do
14:57:08 <UkoeHB> the address scheme would break anyway
14:58:12 <UkoeHB> not that breaking the address scheme a second time would be appealing at all..
19:04:36 <narodnik> 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
19:05:16 <narodnik> 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
19:05:59 <narodnik> you can eventually phase out the old stack using checkpoints
19:06:47 <narodnik> but ok lets say you don't want to use a new curve
19:06:59 <narodnik> why not then introduce arithmetization using the current bulletproofs?
19:07:12 <narodnik> then code a membership proof using circuits
19:11:21 <narodnik> https://github.com/darkrenaissance/darkfi/blob/master/script/research/halo/halo2.sage
19:12:29 <tevador> what would be the rough size and verification time for such a proof?
19:13:15 <narodnik> i can write a benchmark in rust with zcash halo2 API, where it does 32 poseidon hashes
19:13:43 <narodnik> i think they normally use sinsemilla though for merkle trees
19:15:24 <narodnik> it's mainly dependent on the number of rows, which is a power of 2 always due to 2-adicity of the group
19:21:59 <andytoshi> i'd also be very curious about the benchmark numbers
19:22:22 <andytoshi> 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
19:23:28 <narodnik> my computer is lagging a huge amount so will restart one sec for the benchmark
19:31:12 <andytoshi> cool! tho don't rush on my part, i almost never contribute to this project and don't have time to help anytime soon
20:14:14 <narodnik> proof verify [0.018967216 s]
20:14:19 <narodnik> here's the benchmark
20:14:57 <narodnik> code i hastily threw together just now
20:14:58 <narodnik> https://agorism.dev/uploads/zk.rs
20:15:10 <narodnik> https://agorism.dev/uploads/inclusion_proof.zk
20:15:19 <narodnik> https://agorism.dev/uploads/output.txt
20:16:13 <narodnik> this is using bulletproofs for inner product proof, so there's no trusted setup
20:16:54 <narodnik> it proves that $leaf has a pathway to $root without revealing the exact path
20:17:18 <narodnik> 0.019 secs
20:18:47 <xmrack[m]> narodnik: how does this compare to the current implementation?
20:29:56 <narodnik> idk but this tree has a size of 2^32, while current ring size is 128?
20:36:36 <tevador> 19 ms is not bad at all. What is the proof size?
20:48:49 <narodnik> let me check
20:52:01 <narodnik> 6403 bytes
20:54:45 <tevador> I think the seraphis membership proof is something like 800-ish bytes
21:27:27 <narodnik> so an 8x size increase for 33554432x increase in anonymity set
21:27:34 <narodnik> seems worth it
21:34:50 <tevador> 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
21:56:10 <narodnik> it's pretty much just defining a polynomial relation to prove the merkle tree inclusion, then committing to that using the bulletproofs scheme
21:56:51 <narodnik> given a and b are boolean ints, you can arithmetize them as so:
21:56:55 <narodnik> a AND b = ab
21:57:02 <narodnik> a OR b = a + b - ab
21:57:06 <narodnik> NOT a = 1 - a
21:58:02 <narodnik> then we convert our algo to that format, and we construct polynomials that interpolate those points, then commit and open it using bulletproofs
22:40:28 <UkoeHB> this is what a seraphis-compatible membership proof needs to do:
22:40:30 <UkoeHB> https://github.com/monero-project/research-lab/issues/100#issuecomment-1115448487