Difference between revisions of "Preventing Preimage Attacks"

From BiblePay Wiki
Jump to: navigation, search
Line 23: Line 23:
 
'''What is the difference between merged mining and randomx dual hash mining:'''
 
'''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).  Although, merged mining works fine in an algorithm like scrypt, because preimages are not financially beneficial.   However classic merged mining with RandomX would introduce pre-image risk if the larger block header were exploited (by keeping a table of solved blocks to try to brute force the solution in the smaller coin).  However with a block solution equation, the pre-image risk is mitigated.
The reason this is extremely important is some may confuse a classic merge mining scenario (such as a pool that allows the miner to earn DOGE+LTC).  The merged mining works fine in an algorithm like scrypt, because preimages are not financially beneficial therefore impossible with scrypt. However with BiblePay, a merged mining scenario would contain preimage risk (specifically because we would blindly accept the Monero header, which could have been preimaged, as a solution to our difficulty).  Therefore the reason we chose the equation option.
 
  
  

Revision as of 15:11, 13 March 2020


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). Although, merged mining works fine in an algorithm like scrypt, because preimages are not financially beneficial. However classic merged mining with RandomX would introduce pre-image risk if the larger block header were exploited (by keeping a table of solved blocks to try to brute force the solution in the smaller coin). However with a block solution equation, the pre-image risk is mitigated.


Summary:


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.