15:52:33 <m-relay> <r​brunner7:monero.social> For greater visibility, as posted earlier already in -community: https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/645
15:56:52 <m-relay> <r​brunner7:monero.social> I just left a comment there. As useful and as fascinating this proposal may be, I worry about the feasibility of a FCMP++ rewrite in Python.
16:16:59 <m-relay> <j​babb:cypherstack.com> another implementation to reference would be great if it works :P
19:10:09 <m-relay> <k​ayabanerve:matrix.org> I'm not convinced it's infeasible rbrunner7:
19:11:09 <m-relay> <k​ayabanerve:matrix.org> The exact issue will be transcripting the same circuit. The half-step is simply to export the circuit from the Rust code.
19:13:20 <m-relay> <k​ayabanerve:matrix.org> https://github.com/monero-oxide/monero-oxide/blob/92af05e0d44bd1ec1fed6028a8d2aade615f805a/crypto/generalized-bulletproofs/src/arithmetic_circuit_proof.rs#L231-L288
19:13:22 <m-relay> <k​ayabanerve:matrix.org> These debug assertions within the prover check the prover's witness is consistent with the statement. The statement itself, the list of constraints, is just a list of structures each with a variety of matrices which are just numeric weights.
19:13:45 <m-relay> <k​ayabanerve:matrix.org> One could half-step such that the numeric weights from Rust are exported and avoid having to calculate most of them.
19:14:06 <m-relay> <k​ayabanerve:matrix.org> (some are chosen in response to the transaction itself, so some still have to be calculated)
19:15:21 <m-relay> <k​ayabanerve:matrix.org> As for if one generates the weights, I can defer to the FCMP circuit's additional layer instantion:
19:15:22 <m-relay> <k​ayabanerve:matrix.org> https://github.com/monero-oxide/monero-oxide/blob/92af05e0d44bd1ec1fed6028a8d2aade615f805a/crypto/fcmps/src/circuit.rs#L165-L186
19:16:06 <m-relay> <k​ayabanerve:matrix.org> The design of the code is to define a series of incremental steps, reusable code, such that the final circuit is really straightforward to specify.
19:16:53 <m-relay> <k​ayabanerve:matrix.org> Now, that would imply a reimplementation would have to implement the same patterns I used in order to achieve the same ordering of steps and the same result. That may put into question the value of reimplementation if a lack of freedoms may be taken.
19:18:30 <m-relay> <k​ayabanerve:matrix.org> But I think feasible isn't off the table, and to watch a reimplementation occur would provide context on where the exact hard requirements are, where freedom can be taken, and if there is anything glaring exposed via reimplementation re: a design anti practice we have the opportunity to correct now, before deployment (even if the paperwork would be a nightmare)