@Sunfishstanford contrasted with the standard authentication example where leaking bits of w allows impersonating Alice
@Sunfishstanford okay, right, so my original assumption that the main value prop is the “SNARK” bit and not the “zk” bit holds up, in that while the verifier doesn’t require knowledge of w, nothing bad happens if the proof leaks bits of w (since w is public already, if you wanted to allocate storage for it)
@Sunfishstanford that seems anti-useful for the most of the computations I would want to run on historical blockchain data (although the broader category of “proofs of knowledge” seems very useful, as it would allow you to return the answer and the proof without the whole historical blockchain coming along for the ride - this is where the other paper I linked sets out a nice framework).
@Sunfishstanford that’s what I gathered as well - in particular I’m assuming it’s a zk-SNARK, or similar “proof of knowledge” protocol. But….the way zero knowledge proofs in particular are formulated, the querier can’t learn anything new from the response - ie you have to already know the answer before you ask for a ZKP as the proof won’t reveal it, only whether the other party knows it too.
@ricci 🧐
@vitaut @dev every time I see a waterfall pic on social media I feel compelled to share this photo I took in a fit of youthful insanity http://sfgp.cemetech.net/imgs/gallery/photos/The_Plunge_0.jpg
@dev hi, could you spare a moment to talk about our lord and savior, Kevlar pants?
@Sunfishstanford but if you’re interested in the slightly more general “non-interactive proof of knowledge” side of things, there’s a fantastic paper here by my M.S. advisor that’s fairly relevant https://scholar.google.com/scholar?hl=en&as_sdt=0%2C46&q=Incrementally+Verifiable+Computation+or+Proofs+of+Knowledge+Imply+Time%2FSpace+Efficiency.&btnG=#d=gs_qabs&t=1675127928370&u=%23p%3D8pfMnQP3Za4J
@Sunfishstanford not sure from the announcement what the value prop for the “zero knowledge” bit is - archival blockchain data is already public so keeping it secret doesn’t seem to add utility. Is this about hiding the function that you personally want to compute over that data?
@steve @Gankra the possibility for ODR nondeterminism with is one of the reasons you’re REALLY not supposed to provide specializations of std:: templates (except apparently specialization of std::hash is allowed as an extension point for your own types, and I think that’s the only allowed deviation)
@Gankra @steve The “can’t have virtual templates because you can’t generate sensible vtables” is a fun one that I had to recently explain to a Rustacean friend who writes C++ for me at work now. He was convinced Rust solved this problem and I was like “I know it hasn’t or someone would have authored a paper fixing it for C++23 with the same technique”, which led to a deep dive into Rust documentation to the definition of object-safe trait
co-Founder // Chief Science Officer at @geopipe (🖖🏻), PhD from Brown CS Dept (w/ @maurice), SMCVT alum (Math/Physics/CS), admin at Cemetech, AFOL & open-theist.
Decentralizing systems (human & digital). Opinions are my own.
📍 Vermont