RanchiMall/node-stratum-pool
3
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Update algo_dev.txt

Browse Source
This commit is contained in:
Matthew Little 2014-03-28 19:35:17 -06:00
parent b80575038c
commit 67d35fa320
1 changed files with 12 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
algo_dev.txt
View File

@ -1,3 +1,9 @@
In order to implement a new algo in a pool you need three things
1) the C code to do the actual hashing - which I convert into a native node addon
2) the max difficulty (diff1) of the coin used to check if shares/blocks are valid
3) the share multiplier (2^16 for example) to determine the hashrate of a miner/entire pool
Most coins have diff1 in format like (~uint256(0) >> 20)
I believe you can determine the hashrate multiplier by subtracting the 20 used in bitshift from the number 32
so it would be 2^12 for this one. or for (~uint256(0) >> 16) it would be 2^(32 - 16)
@ -20,6 +26,12 @@ I believe these are the true diff1 values that should be used on pools for each
bcrypt: 0x00f8ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
So remember how that list to add a new algo had 3 items, well the maxcoin devs very unforutentely did something
that added a fourth step:
Step 4) Determine which parts of how work-generation / share-processing / creating-blocks work were arbitrarily
changed and implement them....
Maxcoin devs, it seems, did not simply implement keccek in the way that litecoin devs implemented scrypt.
Or how the darkcoin devs implements x11, or how the quarkcoin devs implemented quark. The maxcoin devs
decided to change several parts of how the the currency works - so that instead of simply changing the block