Thanks! 
Topic: SCIP POW (Read 973 times)
I apologize if this is obvious, but I didn't find it on a search. What does SCIP stand for?
From the first post of the thread linked in OP:
In SNARKs for C: Verifying Program Executions Succinctly and in Zero Knowledge (referred to as SCIP below), Eli Ben-Sasson et al. describe their work on highly efficient non-interactive proofs with zero-knowledge for the faithful execution of programs written in C. Eli also presented at the Bitcoin conference.
I apologize if this is obvious, but I didn't find it on a search. What does SCIP stand for?
+1. i agree with your point that POW as it is is already useful. also agree on the trivial nature of alternative proof of work schemes. your final point is a run on sentence and i didn't understand what you meant exactly, if you could elaborate a bit that would be great.
Split from the CoinWitness
POW is generally the same up to some constant factors. It all provably expends energy in order to force the miners to choose a unique history to support instead of greedily supporting multiple chain-heads.
Having secondary uses of the work is not obvious adventitious for the system: It may dilute the motivation to participate honestly, if you try to mine on a fork you would at least still conserve the value of this other work, instead of wasting your effort entirely.
As far as using SCIP for this, you're talking about a prover overhead of thousands of times slowdown. This is unlikely to keep your useful work useful. Also, because of the non-determinstic input necessary in any SCIP like system which is either succinct proofs or zero-knoweldge almost certainly means that a single program execution run can be fuzzed into an infinite number of POW hashes, so even using SCIP evaluation of your function can't guarantee non-trivial amounts of your desired work is getting done.
If you wan to wax philosophic about alternative POW, ones that create proofs that the miner isn't just some blind remote computing service and actually knows what they're validating (e.g. memory hard proofs over UTXO queries) are probably more interesting than arbitrary functions.
(And as said we've not talked about SCIP-based
productive proof-of-work yet...)
I don't think this is very interesting, beyond aligning the POW to some other processing which is also useful to Bitcoin. Our proof of work is already productive: It secures Bitcoin. I am currently shaking my fist at your comment promoting the misunderstanding that our work isn't useful.productive proof-of-work yet...)
POW is generally the same up to some constant factors. It all provably expends energy in order to force the miners to choose a unique history to support instead of greedily supporting multiple chain-heads.
Having secondary uses of the work is not obvious adventitious for the system: It may dilute the motivation to participate honestly, if you try to mine on a fork you would at least still conserve the value of this other work, instead of wasting your effort entirely.
As far as using SCIP for this, you're talking about a prover overhead of thousands of times slowdown. This is unlikely to keep your useful work useful. Also, because of the non-determinstic input necessary in any SCIP like system which is either succinct proofs or zero-knoweldge almost certainly means that a single program execution run can be fuzzed into an infinite number of POW hashes, so even using SCIP evaluation of your function can't guarantee non-trivial amounts of your desired work is getting done.
If you wan to wax philosophic about alternative POW, ones that create proofs that the miner isn't just some blind remote computing service and actually knows what they're validating (e.g. memory hard proofs over UTXO queries) are probably more interesting than arbitrary functions.
Jump to: