The last time I considered this: - Most grid/cluster-based video rendering systems assume trust. Shared filesystems, central nodes that allocate work, users su

The last time I considered this: - Most grid/cluster-based video rendering systems assume trust. Shared filesystems, central nodes that allocate work, users submit jobs to the central node. This trust allows for lower overhead, as each unit of work only needs to be processed once. (By comparison, with blockchains, you need to wait for n copies of the work to be done and compare them to verify that a bad actor hasn't submitted garbage; these are "confirmations".) - One key property of cryptocurrencies is resilience in the face of bad actors. In particular, you want each node to independently be able to come to consensus without trusting a central node. (Otherwise, you would just devise a scheme that trusts a central node, such as a Bank.) So if you want to replace Proof of Work or Proof of Stake with a "useful" task, you have to devise a scheme that retains the property of "consensus without trust", while also providing "useful" work (that is, correct video rendering results, in a reasonable response time). I'd look up "51% attack", as well as the documents describing the design of scrypt (https://www.tarsnap.com/scrypt.html https://www.tarsnap.com/scrypt.html) and other password hashing functions to get a sense of the attack modes you have to design for. - Assuming you come up with a good scheme, you then need to convince the rest of the world to adopt it. (Note that some actors have hardware that is optimized for the task defined by Bitcoin. Also, if your user base is too small, then it's trivial to 51% attack by just buying more computers than you.) I don't think it's impossible; I just don't think it's cost-effective (versus just buying and building a grid/cluster with trusted nodes).