• Welcome to TechPowerUp Forums, Guest! Please check out our forum guidelines for info related to our community.
  • The forums have been upgraded with support for dark mode. By default it will follow the setting on your system/browser. You may override it by scrolling to the end of the page and clicking the gears icon.

Idea for ASIC-proof PoW mining algorithm

Nemo84

New Member
Joined
Jun 8, 2021
Messages
2 (0.00/day)
Hello there!

I just wanted to share my basic idea for a crypto mining algorithm based on the proof of work concept. The concept should be ASIC resistant and thus protect the idea of decentralized mining on consumer hardware.
As of the time being, it should run best on nVidia RTX graphics cards, at least until AMD also adds matrix cores to their Radeon chips with hardware raytracing.

Since I am no programmer, computer scientist, crypto expert or mathematician I am afraid I lack the skills to develop a ready-to-implement concept, not to speak of a working implementation.
But I hope someone who has those skills likes my idea and creates such an implementation. My only condition, if you want to do so, is that it must be published under a free, open source license, for everyone to use without having to worry about patents or royalties.

The mining would work like this:
  1. The peer-to-peer network provides a file with a complex, high polygon, shaded and textured 3D scenery with multiple light sources (e.g. in the form of a Blender 3D file). It is downloaded by the miner and verified by help of a secure hash sum (e.g. SHA-3) which is consensually stored in the blockchain. For extra security, double-checking with a different hash algorithm (like Blake 2 for example) could be put in place.
    This file always changes after a defined number of blocks, like the random program in ProgPow, significantly altering the scene or replacing it by a different one entirely.
  2. The network provides a losslessly compressed image (e.g. in PNG-format) of a certain size, also verifyable by at least one hash sum in the blockchain. This image actually is a rectangular snippet of a larger picture. The exact size and aspect ratio of this larger picture is predefined and known to every miner. In addition to the snipped (which I would propose to be about 1/8 to 1/4 of the full image's area) the X and Y coordinates of the snippet's upper left corner are given, in pixels of the full image.
    This image-snippet-pair changes with every block. The full image remains a secret and is not shared to the miners.
    The full image is in fact a rendered frame of the virtual 3D scenery, rendered by an unbiased pathtracing renderer - with global illumination, soft shadows, several bounces of indirect lighting, and at least 10,000 light paths per pixel, so there is no perceivable grain anymore. The virtual camera's position in 3D space, its angle and zoom factor are randomly chosen within reasonable boundaries, which are predefined for the 3D scenery file. The camera parameters remain secret as well.
  3. The miner receives the block data for hashing
  4. Two hash sums are calculated, one by the CPU (using a RandomX-based algorithm) and one by the GPU (using a ProgPow-based algorithm)
  5. By analyzing the snippet image the mining software tries to figure out how the virtual camera must be set up in the 3D scenery file, to render a frame in accordance with the full-image's specifications and with the snippet at the specified X-Y-position.
  6. The miner renders this frame, trying to get its respective portion as close to the provided snippet as possible. Since pathtracing takes a lot of time, it needs to be accelerated. This is achieved by using the hardware-raytracing cores of the GPU for acceleration of the monte-carlo-like pathtracing algorithm, trying to lower the number of paths per pixel with light importance sampling and an AI denoising filter accelerated by the Tensor cores / matrix cores. Basically as demonstrated here: https://developer.nvidia.com/blog/t...active-path-tracing-scenes-from-a-short-film/
  7. When the miner is pleased with its rendering result, it packs the rendered frame (losslessly compressed) with the pair of block hash sums created by the two hashing algorithms. If these have been running in parallel to the 3D image reconstruction, many possible hashes have been created and the results of the highest achieved difficulty (in terms of probability / mining difficulty) of each algorithm will be used.
  8. The data package is digitally signed with the mining adress' private key and sent to the network.
  9. The network node uses an objective metric like SSIM to compare the submitted frame to the secret original full image. The metric score must be above a given limit, which defines the network difficulty for mining.
  10. If the rendered result is good enough, the submitted block hashes are verified by the network.
  11. Every share submitted within the predefined block time, and which has passed the validation, gets rewarded with newly generated coins. For this a formula is used which weighs every share by the difficulty of its hash values and its image metric score. However the formula should be designed in such a way, that a higher number of good quality shares results in a higher mining reward than a few very high difficulty shares. This makes sure, that the miners actually have to use neural networks and such tricks, to speed up the rendering. Otherwise you could use a normal render engine, which takes a lot of time, giving your hash functions more time to find more difficult hashes, and then submit a high difficulty share every long time interval. Submitting more shares per time with similar image qualities should be more profitable, even it the hash sum difficulties in them are lower.
  12. The valid share with the most difficult, meaning smallest (lowest) hash sums is chosen for the new block in the chain.
For providing the 3D scenery files, secret frames, per-block-snippets and their hash sums, a proof-of-stake algorithm can be used to find consent.

I hope I did not just think up nonsense here. I am looking forward to an interesting discussion. :-)
 
My only condition, if you want to do so, is that it must be published under a free, open source license, for everyone to use without having to worry about patents or royalties.
Just FYI without a patent you have no means to enforce this.

I'm by no means looking to steal this idea, just stating the (maybe not so) obvious.
 
Just FYI without a patent you have no means to enforce this.

I'm by no means looking to steal this idea, just stating the (maybe not so) obvious.
You are probably right. But since I published the idea here, I can at least prove that I had it before someone else filed a patent for it, and then I can try my luck and sue. :-P
I just hope that, if someone takes on the effort of realizing this, he, she or them respects my wish. But since most mining algos are freely available, I doubt it would be different here.

And what problem does this solve?
It would not quite provide a solution to unsolved problems, but rather improve upon existing solutions:
  1. Highest degree of ASIC resistance, making sure the mining stays on PCs and everyone with a good graphics card can earn their share.
  2. It would be pretty much impossible to launch a 51%-attack
  3. Very high level of cryptographic security, due to the combination of 2 state-of-the-art hash functions
  4. It should be impossible to take a short cut, as it is possible with the time/memory tradeoff attacks on Cuckoo Cycle for example
  5. Helps advancing AI and image processing applications
  6. It is a new approach, providing an alternative to established methods - just in case the existing methods get hacked or the ASICs catch up too much.
  7. Could be used as a showcase for the Cortex network, with the AI mining software being developed as DApps for the CVM.
 
This isn't going to be ASIC resistant, it's very easy to verify if something will be ASIC resistant or not, if it involves mostly massively parallel data independent computation forget about it. You'll eventually be able to build a chip optimized for this particular set of operations. You need serial, memory bound algorithms for ASIC resilience. However, the problem is that those will be so slow that they'll be undesirable from the get go.
 
It appears that this or similar ideas are all over the internet already so not sure who, if anyone could claim any rights or patents, interesting nevertheless.
 
The huge problem I see is with step 1. Who provides the image? Someone or something has to create them, and that means centralization, which means it's a non-starter.
 
Back
Top