<k​ayabanerve:matrix.org> jberman: I believe that's the wrong approach. The proof time should *almost* be linear to the amount of inputs. Creating 128-input TXs across 16 proofs shouldn't be so faster than 1 proof.

<k​ayabanerve:matrix.org> There's an identical amount of divisors consumed. Then the proof itself has a linear growth in circuit size. The only question is if at some point, a super-linear operation occurs with regards to the circuit OR if the existing code has some optimization fault.

<k​ayabanerve:matrix.org> When requesting size estimates for large proofs, it does end up taking a very notable amount of time. That isn't running a ZK proof at all however. That implies my code for creating layouts alone fails at size. That means the layout engine should be improved, not the protocol changed.

<k​ayabanerve:matrix.org> Within the proof, IIRC, the prover has to perform some single-variate polynomial multiplications. Those, yes, would be super-linear but an FFT should transform them back to linear *if that performance is necessary*.

<k​ayabanerve:matrix.org> Again, immediately, my concern is the layout engine, not the proof itself.

<k​ayabanerve:matrix.org> jberman @jberman:monero.social: As that monero.social link notes, there's constructions for payment networks premised on cryptography, not consensus. I don't believe they'd be viable to use IRL but they're possible.

<k​ayabanerve:matrix.org> One proposal for Monero would not work. It premised on transaction chaining and time-delayed signatures for chained transactions. The follow up work premised time-delayed private keys however, which should be simpler (no messing with time-delaying a CLSAG vs a bog-standard scalar, although a CLSAG is likely reducible to a bog-standard scalar) and would apply.

<k​ayabanerve:matrix.org> I created a MRL issue advocating how if we were to discuss this, we should establish minimum viable payment channel designs and from there discuss protocol upgrades.

<k​ayabanerve:matrix.org> My immediate comment now, as an individual, is instead of time-locked cryptography, I'd honestly recommend trusting the Intel SGX or similar (or at least making the backend modular with users able to configure which they're willing to rely on). For users with Intel SGX hardware, it'll be a much better user experience, and a SGX exploit is unlikely to be taken advantage of for smal<clipped messa

<k​ayabanerve:matrix.org> l payment channels

<k​ayabanerve:matrix.org> (Or even a layered solution of time-locked crypto + SGX... I should open an issue with the Grease people providing my thoughts)