Hi
I’m a little confuse
with this header
040000007003225F30E1015EE14609B222E6036B7572963E18355688A966BB0E00000000E53B8DC142BBF69584F26B5F1D2125B79F238E77D04A37CDFAE64D3CFE9B2E730000000000000000000000000000000000000000000000000000000000000000C85BDA595DB6121C4FFFFFFF05000000000000000000000000000000000000000000000000000000
and after + 00000000 and 01000000 and 02000000 then compute blake2b(50) I received these , that are different with your result
index 0 ====> aad5e0ace4562e371912fd1b2660f6e10e4456093e1f8a6ad8d4bdbe46accc087f636a1abcaab319abb85bfd4cfe987cf077
index 1 ===> bfd3bcba82f35bd49d3551bef1ce1d0cd7bf01a32ee43a36eac11cd627fbc5499cf8d1714fd4b63c96d5519ae3e5c99c3423
index 2 ===> 1fcb2423d9d5717712af4ffd5f5b95b6b5e230a896b8eb706d865dcfa6ac309d5a6ab50dbcd3162a818d5e1710bad0d36d9b
now we have to select 512 of them that make xor of them 0 and also this 2 rules
1-“on each split by two of your indexes the left ones must be ordered”
2-" on each split by two of your indexes resulting XOR of strings must have 20*height zero bits from the left. More on algorithm is in the part II."
Could you please explain a little more about this 2 rules?
and also if it possible for you please solve this and give those 512 indexes that satisfy these rules ,it really helps me to understand more.
rule 1 means that on any branch of index tree - branches are ordered, so the tree is uniquely (deterministicaly) represents the solution, and you can not easily get another solutions by permutation of branches.
rule 2 means that Wagner’s algorithm (or similar) must be used, and tree branches as they grow xored give more and more zeroes, i.e. original_string[solution_idx[0]] ^ original_string[solution_idx[1]] as well as 2^3 will give 20 zero bits from the left, (0^1)^(2^3) will give 40 zeroes etc.
so next step is to make sloution block as you wrote is " solution itself, which is encoded by 21 bits per index, "?
What is this mean ?how we can encoded index in 21 bit?
is it correct?==> 920+1c3ff8+301ef+…==>000000000100100100000+111000011111111111000+000110000000111101111+…
////////////////////////
Actually there is a misunderstanding for me,after making blake2b hashes we have to chose 512 of them that make xor zero for finding this 512 there is an algorithm with name of wagner ! it is no mandatory to use this algorithm yes?or no? actually we can find another way for chose this 512? am i right?
///////////////////////
those two rules steel unclear for me maybe because I have not understood wagner algorithm yet and I could not find any paper for this and most paper is just for optimizing his algorithm ,Is there any guide for wagner pure?
Original paper from that page explains Wagner’s algorithm, slightly academic.
When algorithm is solved and we get those indexes (920, 1c3ff8, …) we pack them into Zcash block. Since each index is between 0 and 2097151, or 21 bits width - we just encode them tightly as you’ve shown, that’s correct.
“Actually there is a misunderstanding for me,after making blake2b hashes we have to chose 512 of them that make xor zero for finding this 512 there is an algorithm with name of wagner ! it is no mandatory to use this algorithm yes?or no? actually we can find another way for chose this 512? am i right?”
we must use wagner algorithm? or we can use any other algorithm for finding 512 indexes? (Actually I want to know the goal is to find 512 indexes that make xor of them zero?)
yep, the goal is to choose 512 strings from 2097152, such as xor of them is zero (with some additional requirements to the order of those strings).
you may invent any algorithm. however, the generally accepted view is that Wagner is the only possible (and only its optimizations matter). you are very welcome to disprove this and break zcash mining market.
some order is required. without an order you will get too many solutions for free by permutations.
each of 512 indexes must be unique.
xor of string[index[0]] with string[index[1]] must begin with N/(K+1)=20 zero bits, string[index[2]]^string[index[3]] the same etc. index[0] must be less then index[1], index[2] < index[3] etc. let’s call it the first step.
string[index[0]][1][2][3] must begin with 40 zero bits, etc. index[0]<index[2], index[4] < index[6], etc. it’s the second step.
repeat for other steps up to the step 8, [[0]]^…[[255]] must begin with 160 zero bits, same for [[256]]^…[[511]], index[0] < index[128], index[256] < index[384]
and at the final step 9, index[0] < index[256] and xor of all chosen strings is zero.
Thanks @mtve On each step next 20 bits should become zero or can we use any other algorithm to bring xor of 512 strings (string[0] ^ string[1] ^ string[2]^ … string[511]) to zero? Because I’m planning to write an algorithm which finds strings as the order your mentioned above and bring xor of them to zero.
yes. consider 512 indexes of strings as leafs of a binary tree with depth 9. on each branch arms are ordered, and total xor of branch has leading zeroes (20*height bits).
unfortunately this is required by Equihash and so Zcash, because it follows from Wagner’s algorithm.
perhaps natural order of indexes without intermediate xors would be more aboveboard, but it’s not our case.
anyway, even if your algorithm will not provide required order, it could be interesting, so please publish it.
@mtve Thanks again. Sure, once I find it working I will share the github URL for public And how the solutions are verified by other nodes? Can you explain or share c/c++ code which does this part?
@mtve hey, I’ve also been implementing the zcash PoW stratum algo, as a way to get a detailed understanding of how everything works. I get the correct solution for corresponding input as given in this thread. However one thing still remains unclear to me: the generation of the nonce in combination with a mining pool.
I have sniffed some communication between the EWBF cuda miner and nanopool. As I understand, part of the nonce should be given in the reply from the ‘mining.subscribe’, however that field is null:
{“id”:1,“method”:“mining.subscribe”,“params”:[“EWBF 0.3.4b”,null,“zec-eu1.nanopool.org”,“6666”]}
{“id”:1,“result”:[null,“6bf601000000000094e3cf4e56bf1c49”],“error”:null}
On one of the mining.submit message from the mining software, I then see for example the nonce2 is being sent as ‘0a450000000000000000000000000000’, which is only 16 byte instead of the required 32 for the complete nonce. I have tried prepending or appending 16 0x00 bytes to this, but don’t succeed in getting the same solutions as the miner with that nonce.
Furthermore, if a mining pool sends a job, is the mining software supposed to continue increasing its nonce and sending solutions until the pool gives a new job?
I should change the the representation of each block of 8 bytes to big-endian - and then perform collision and xor on that converted data? From the protocol, I thought that only the solution was big-endian - not the data during each round of solving equihash.
And how the solutions are verified by other nodes? Can you explain or share c/c++ code which does this part?