Difference between revisions of "Odocrypt"

From DigiByte Wiki
Jump to navigation Jump to search
m (Fix formatting coz I'm a monkey)
Line 1: Line 1:
Odocrypt is a unique GPU / FPGA-friendly hashing algorithm made specifically for DigiByte that changes itself every 10 days as an anti-ASIC method.
+
 
 +
[https://odocrypt.digibyteservers.io/ Odocrypt] is a unique GPU / FPGA-friendly hashing algorithm made specifically for DigiByte that changes itself every 10 days as an anti-ASIC method.
  
 
As of March 2019, DigiByte is testing the algorithm and no code has been merged in to the DigiByte Core code-base.
 
As of March 2019, DigiByte is testing the algorithm and no code has been merged in to the DigiByte Core code-base.
  
* [[Choosing FPGA hardware]]
+
*[[Choosing_FPGA_hardware|Choosing FPGA hardware]]  
* [[FPGA mining]]
+
*[[FPGA_mining|FPGA mining]]  
  
 
=== How does Odocrypt work? ===
 
=== How does Odocrypt work? ===
 +
 
Odocrypt uses the Keccak algorithm (SHA3) for its hashing function, as it is a relatively streamlined and low-memory requirements (Perfect for all common FPGAs). It changes the hashing details every epoch (10 day time-period) based on the new seed. This change occurs at midnight UTC. When the epoch changes, the miners must compile a new .sof file (analog of a binary executable for the FPGA CPU) and program it on to the hardware. During this time, there is a 2-hour period prior to the midnight of the epoch in which the blockchain will accept the new epoch settings and / or the old epoch settings. This gives all miners a chance to re-optimize their settings and reprogram their FPGA's, without causing immediate issues in the overall hashrate for the algorithm, despite automated re-programmings taking only a matter of seconds in most instances. Once reprogrammed the FPGA uses the new seed as it's base, which is required in order to maintain the 'optimized' settings. Without this, the FPGA will be churning out invalid hashes and have an effective efficiency of zero.
 
Odocrypt uses the Keccak algorithm (SHA3) for its hashing function, as it is a relatively streamlined and low-memory requirements (Perfect for all common FPGAs). It changes the hashing details every epoch (10 day time-period) based on the new seed. This change occurs at midnight UTC. When the epoch changes, the miners must compile a new .sof file (analog of a binary executable for the FPGA CPU) and program it on to the hardware. During this time, there is a 2-hour period prior to the midnight of the epoch in which the blockchain will accept the new epoch settings and / or the old epoch settings. This gives all miners a chance to re-optimize their settings and reprogram their FPGA's, without causing immediate issues in the overall hashrate for the algorithm, despite automated re-programmings taking only a matter of seconds in most instances. Once reprogrammed the FPGA uses the new seed as it's base, which is required in order to maintain the 'optimized' settings. Without this, the FPGA will be churning out invalid hashes and have an effective efficiency of zero.

Revision as of 15:30, 12 May 2019

Odocrypt is a unique GPU / FPGA-friendly hashing algorithm made specifically for DigiByte that changes itself every 10 days as an anti-ASIC method.

As of March 2019, DigiByte is testing the algorithm and no code has been merged in to the DigiByte Core code-base.

How does Odocrypt work?

Odocrypt uses the Keccak algorithm (SHA3) for its hashing function, as it is a relatively streamlined and low-memory requirements (Perfect for all common FPGAs). It changes the hashing details every epoch (10 day time-period) based on the new seed. This change occurs at midnight UTC. When the epoch changes, the miners must compile a new .sof file (analog of a binary executable for the FPGA CPU) and program it on to the hardware. During this time, there is a 2-hour period prior to the midnight of the epoch in which the blockchain will accept the new epoch settings and / or the old epoch settings. This gives all miners a chance to re-optimize their settings and reprogram their FPGA's, without causing immediate issues in the overall hashrate for the algorithm, despite automated re-programmings taking only a matter of seconds in most instances. Once reprogrammed the FPGA uses the new seed as it's base, which is required in order to maintain the 'optimized' settings. Without this, the FPGA will be churning out invalid hashes and have an effective efficiency of zero.