Preventing Preimage Attacks
Explanation of Preimage Attack and relationship to RandomX:
Preimage attacks are created when the actor finds it financially beneficial to store a table of precomputed hash data, rather than calculate the hash by performing the work. Obviously, with fast hash algorithms such as SHA256, it would be much more efficient to generate new hashes rather than store the key/value pairs. As it consumes less clock cycles to calculate the hash in sha256 than the corresponding cost to store a large table. However, in the RandomX world, where the hash algorithm is approximately 2500 times harder to compute, the preimage attack risk rises. Therefore it is of paramount concern to prevent preimage attack with RandomX.
Why is this important in BiblePay:
Because BiblePay is moving to RandomX. Therefore it is important for us to maintain an environment that makes it impossible to preimage the randomx hashes.
How does BiblePay prevent preimages:
BiblePay has decided to solve for an equation that requires the prior block hash to be present (BlakeHash(Previous_DAC_Hash + RandomX_Hash(RandomX_Coin_Header)) < Current_DAC_Block_Difficulty) in the input of the blake hash. This means that it is impossible to preimage a set of RX hashes to solve a biblepay block.
What is the difference between merged mining and randomx dual hash mining:
In a classic merged mining scenario, (such as a pool that allows the miner to earn DOGE+LTC) the merge mined block header is accepted as part of the solution for the merged coin (which would not introduce pre-image risk with a fast algorithm such as scrypt). Therefore, merged mining works fine for an algorithm like scrypt, because preimages are not financially beneficial. However classic merged mining with RandomX would introduce pre-image risk if the larger (currencies by market-cap) block header were exploited (by keeping a table of stored header source data and hashes - to try to brute force a new solution into the smaller coin (by market cap)). However with a block solution equation (requiring prior blockhash bytes to be present in the input), the pre-image risk is mitigated.
BiblePay is immune to preimage attacks, we have the security afforded by all of the potential Monero and BiblePay miners and dual-hash mining, and we have chain-locks.