<s​yntheticbird:monero.social> nice picture

<k​ayabanerve:matrix.org> eprint.iacr.org/2024/1647

<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

<k​ayabanerve:matrix.org> bytes (potentially 20%).

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

<k​ayabanerve:matrix.org> m == MAX_INPUTS

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

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

<k​ayabanerve:matrix.org> No. It'd save (1-1)*... bytes.

<k​ayabanerve:matrix.org> This only saves for the multi-input case.