00:36:55 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 00:36:56 ) validation on any consensus layer, and no recourse against compromised/malicious committee members who stall the process or steal funds. 🤷 00:36:56 > to verify zero-knowledge circuits on Bitcoin. 00:36:57 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. 00:41:26 the Bitcoin L2 literature review of the paper gives me the impression of an affinity scam 00:48:42 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? 00:58:43 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" 01:04:22 using Bitcoin OP_RETURNs as a data availability layer suddenly sounds very cool and smart when you store ZK proofs in them. 04:21:38 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? 04:23:14 it'll be 2 years on v16 this august 06:02:13 reminds me of zec's ceremony (trusted setup). 23:37:00 Update we are over 60 hours into the BP++ review 23:37:16 Lots more to do however