09:03:32 <m-relay> <s​yntheticbird:monero.social> nice picture
16:46:16 <m-relay> <k​ayabanerve:matrix.org> https://eprint.iacr.org/2024/1647
16:46:17 <m-relay> <k​ayabanerve:matrix.org> This gives us a smaller circuit. The smaller circuit doesn't give us faster verification as we'd need a 50% decrease in proof size and the part of the circuit they shrink isn't close to 50% of our circuit. It would, on n-input TXs, save (n-1)*6*32 bytes from the proof in our use case. We'd also have somewhat faster proofs due to not dealing with the commitments we drop from those <clipped message
16:46:19 <m-relay> <k​ayabanerve:matrix.org> bytes (potentially 20%).
16:46:21 <m-relay> <k​ayabanerve:matrix.org> This comes at the cost of needing to build m trees, not 1. The increased scalarmuls for the tree building is less than the scalarmuls saved by proof verification. This would increase the size of archive nodes by m * 5 GB. When we deprecate FCMPs (for a new structure), those trees could be pruned.
16:46:23 <m-relay> <k​ayabanerve:matrix.org> m == MAX_INPUTS
17:20:36 <m-relay> <k​ayabanerve:matrix.org> The biggest issue will be with wallets and wallet trees. They don't care about proof size/verification time but do care about the time to build the tree.
17:22:59 <m-relay> <r​ucknium:monero.social> If the number of inputs is 1, does this technique have no effect on tx size? From `(n-1)*6*32`
23:14:54 <m-relay> <k​ayabanerve:matrix.org> No. It'd save (1-1)*... bytes.
23:15:08 <m-relay> <k​ayabanerve:matrix.org> This only saves for the multi-input case.