Show Posts
76
Archived Proposals / BiblePay Future Hash Algorithm for CPUs
« on: January 26, 2020, 10:09:36 AM »
Option 1 - POBH 3.0: This means we would rewrite POBH (which has the 31,000 verses of the bible) in a way that would run slower in a GPU (than on a CPU) and be very unlikely to work on an ASIC in the future. This appears to be possible by using .netcore's polymorphism, branching, and large initial required data streams. In a nutshell it would take more work to move the inital calculated stream to a GPU than to perform the operation on the CPU. The CPU is also the only way to execute the dotnetcore commands.
Option 2 - Math Prize: Embed one of the worlds greatest math problems in the next algorithm, to give BBP a chance of winning the $1 mil prize, for example. One example is the Reimann Zeta hypothesis, when calculating Zeta on the critical strip above 10 to the 30th power, these zeroes become extremely hard to calculate and elusive (the highest found is 10 to the 30th). https://www.claymath.org/millennium-problems/riemann-hypothesis
Option 3 - Useful Work: This option is similar to #1, in that our hash function would be in dotnetcore, but the difference is we would update the code occasionally using auto-upgrades. And the code would perform some type of useful work; similar to what is done in boinc projects. We would find a useful algorithm and use it until it needs upgraded (such as CFD, for instance that Togo recommended).
Option 4 - RandomX and dual revenue streams for the miner: The idea here is that we switch to the randomx hashing algorithm, for core wallet, pool and miner. We add the ability to allow the miner to mine any randomX coin (we do this by querying the block-key which changes every 2048 blocks in all randomX coins, and making our hash algorithm solve for an *equation* rather than the diff level. ) This way, our miner can perform useful work that generates revenue, by mining XMR or another randomx coin, for instance. However the difference is, every hash that is calculated in the randomX virtual machine would have a chance at solving the current BBP block also. This would provide a dual revenue stream for the miner. Theoretically, we would be a more enticing project for every randomx miner, simply because of the dual revenue. This algorithm appears to not only be possible, but 95% efficient, meaning that each hash counts for both the primary randomx target (ONE only), plus BBP. The theoretical algorithm we would use is : X11(PrevBlockHash + CurrentRandomXHash) < DiffLevel(CurBBPBlock). Note this is novel and unique in that our diff and block spacing can be in parallel to RandomX. It also means the miner can mine any randomx pool or coin, and not need the Monero wallet for example (they will need the SPV wallet for the coin they mine).
Option 2 - Math Prize: Embed one of the worlds greatest math problems in the next algorithm, to give BBP a chance of winning the $1 mil prize, for example. One example is the Reimann Zeta hypothesis, when calculating Zeta on the critical strip above 10 to the 30th power, these zeroes become extremely hard to calculate and elusive (the highest found is 10 to the 30th). https://www.claymath.org/millennium-problems/riemann-hypothesis
Option 3 - Useful Work: This option is similar to #1, in that our hash function would be in dotnetcore, but the difference is we would update the code occasionally using auto-upgrades. And the code would perform some type of useful work; similar to what is done in boinc projects. We would find a useful algorithm and use it until it needs upgraded (such as CFD, for instance that Togo recommended).
Option 4 - RandomX and dual revenue streams for the miner: The idea here is that we switch to the randomx hashing algorithm, for core wallet, pool and miner. We add the ability to allow the miner to mine any randomX coin (we do this by querying the block-key which changes every 2048 blocks in all randomX coins, and making our hash algorithm solve for an *equation* rather than the diff level. ) This way, our miner can perform useful work that generates revenue, by mining XMR or another randomx coin, for instance. However the difference is, every hash that is calculated in the randomX virtual machine would have a chance at solving the current BBP block also. This would provide a dual revenue stream for the miner. Theoretically, we would be a more enticing project for every randomx miner, simply because of the dual revenue. This algorithm appears to not only be possible, but 95% efficient, meaning that each hash counts for both the primary randomx target (ONE only), plus BBP. The theoretical algorithm we would use is : X11(PrevBlockHash + CurrentRandomXHash) < DiffLevel(CurBBPBlock). Note this is novel and unique in that our diff and block spacing can be in parallel to RandomX. It also means the miner can mine any randomx pool or coin, and not need the Monero wallet for example (they will need the SPV wallet for the coin they mine).
, but please ask any questions if I missed something.
