<c​haserene:matrix.org> it is (put the proofs into tx_extra), but I don't see why anyone would use this scheme even on Bitcoin. this is strictly a glorified multisig where a predetermined set of committee members promise to evaluate ZK proofs that people put into OP_RETURN outputs, and "vote" whether the proof is valid and whether the money can be released from the multisig. there is no state (transition<clipped message>

<c​haserene:matrix.org> ) validation on any consensus layer, and no recourse against compromised/malicious committee members who stall the process or steal funds. 🤷

<c​haserene:matrix.org> > to verify zero-knowledge circuits on Bitcoin.

<c​haserene:matrix.org> they're NOT verified on Bitcoin. they're verified on other people's computers that you can't control and who have no liability toward you.

<c​haserene:matrix.org> the Bitcoin L2 literature review of the paper gives me the impression of an affinity scam

<s​ilverpill:poa.st> These people would need to collude in order to steal funds, so it is still better than trusting a single person to perform computation, right?

<c​haserene:matrix.org> yes. but the committee members verifying the proof has no provable relation with the transactions carried out by the multisig address. they could all just say "whatever, I ain't verifying this big ass proof, I'll just vote yay". or "that's a nice deposit, it's time to hit up the other committee members to plot an exit scam"

<c​haserene:matrix.org> using Bitcoin OP_RETURNs as a data availability layer suddenly sounds very cool and smart when you store ZK proofs in them.

random idea. depends on how close we are to Mega Rings or FCMPs.... but should we perhaps start considering the whole automatic ring size increases with CLSAG?

it'll be 2 years on v16 this august

<k​4r4b3y:karapara.net> reminds me of zec's ceremony (trusted setup).

<d​iego:cypherstack.com> Update we are over 60 hours into the BP++ review

<d​iego:cypherstack.com> Lots more to do however