Verifying a proof-of-work has to at least be quicker than computing the proof-of-work. Verifying and computing can't be literally the same operation. That's not a proof-of-work.
>Like if 500 people can independently confirm a build produces a binary with result X then they could all share in the reward, whatever that is.
In a cryptocurrency blockchain, every single node verifies every block received from another node in order to check whether it should be included in the node's local copy of the blockchain. If computing and verifying are the same operation, it's not "500 people independently verify a source produces a given binary and the rest of the network rewards them", but "the entire network verifies that a source produces a given binary and they all equally pat each other on the back". Unless you only reward the first to verify a build, but then no node would bother spending time verifying blocks made by other people and building off that chain rather than mining its own blocks if they both take as long as each other.
>The problem is in verifying that someone actually did the work and didn't steal someone else's solution.
Bitcoin uses the hash of the rest of the block (which includes the address for the reward of the miner who is doing the proof-of-work) as an input into the proof-of-work such that the result of the proof-of-work is only valid for that input. It's not apparent to me whether where there could be room to add an input like that into checking whether a source compiles to a binary. (I thought through whether you could make a Lamport-signature-like scheme involving picking specific intermediate values generated during the compilation that correspond to parts from a pre-committed series of hash pairs, but then I realized it wouldn't work because anyone who does the build once would get all of the intermediate values and be able to create as many of these signatures as they wanted for little effort.)
>Maybe encrypting the result you get and sending it off in escrow to a centralized verification location would work, and once a sufficient number of solutions are collected the solutions are unsealed and the results shared so everyone can see what happened and raise any objections.
Sounds like what you're looking for is some kind of web-of-trust reputation system with a trusted authority rather than a cryptocurrency blockchain. (If you have a trusted authority, then nearly all of the design of a bitcoin-like cryptocurrency is ridiculous dead weight. You can shed nearly everything, you don't need a broadcast-everything blockchain, and you could choose to have really cool things like blind signatures for anonymous transactions.) (Though if you have a trusted authority who can afford to be running build processes, it'd be a lot simpler to just have them do all the build-verifying for you, and you could do away with anything discussed in this post and just have them publish a PGP/HTTPS-encrypted webpage with their results.)
>Like if 500 people can independently confirm a build produces a binary with result X then they could all share in the reward, whatever that is.
In a cryptocurrency blockchain, every single node verifies every block received from another node in order to check whether it should be included in the node's local copy of the blockchain. If computing and verifying are the same operation, it's not "500 people independently verify a source produces a given binary and the rest of the network rewards them", but "the entire network verifies that a source produces a given binary and they all equally pat each other on the back". Unless you only reward the first to verify a build, but then no node would bother spending time verifying blocks made by other people and building off that chain rather than mining its own blocks if they both take as long as each other.
>The problem is in verifying that someone actually did the work and didn't steal someone else's solution.
Bitcoin uses the hash of the rest of the block (which includes the address for the reward of the miner who is doing the proof-of-work) as an input into the proof-of-work such that the result of the proof-of-work is only valid for that input. It's not apparent to me whether where there could be room to add an input like that into checking whether a source compiles to a binary. (I thought through whether you could make a Lamport-signature-like scheme involving picking specific intermediate values generated during the compilation that correspond to parts from a pre-committed series of hash pairs, but then I realized it wouldn't work because anyone who does the build once would get all of the intermediate values and be able to create as many of these signatures as they wanted for little effort.)
>Maybe encrypting the result you get and sending it off in escrow to a centralized verification location would work, and once a sufficient number of solutions are collected the solutions are unsealed and the results shared so everyone can see what happened and raise any objections.
Sounds like what you're looking for is some kind of web-of-trust reputation system with a trusted authority rather than a cryptocurrency blockchain. (If you have a trusted authority, then nearly all of the design of a bitcoin-like cryptocurrency is ridiculous dead weight. You can shed nearly everything, you don't need a broadcast-everything blockchain, and you could choose to have really cool things like blind signatures for anonymous transactions.) (Though if you have a trusted authority who can afford to be running build processes, it'd be a lot simpler to just have them do all the build-verifying for you, and you could do away with anything discussed in this post and just have them publish a PGP/HTTPS-encrypted webpage with their results.)