so currently you have:
1) Given a block of data D, calculate H = Hash(D).
2) Find nonce A and nonce B such that BirthdayHash(A +H) == BirthdayHash( B+H)
3) If Hash(H + A + B) < TargetDifficulty then a result has been found, otherwise keep
searching.
Step 2 never needs to be run, BirthdayHash is never executed.
All you do is increment A and run Hash(H + A + A) until a result has been found that is under the TargetDifficulty. As soon as you've found this, then B == A and of course BirthdayHash(A+H) == BirthdayHash(B+H).
To fix this, all you need to do is create a rule such that A and B must be different.
Rather than just assuming it and not hard coding it or building it in to the algo that A != B. Seems quite a critical thing to miss from a white paper.
You'll also note that you didn't check for this in your own validation function
bool momentum_verify( pow_seed_type head, uint32_t a, uint32_t b )
{
uint32_t ia = (a / 8) * 8;
fc::sha512::encoder enca;
enca.write( (char*)&ia, sizeof(ia) );
enca.write( (char*)&head, sizeof(head) );
auto ar = enca.result();
uint32_t ib = (b / 8) * 8;
fc::sha512::encoder encb;
encb.write( (char*)&ib, sizeof(ib) );
encb.write( (char*)&head, sizeof(head) );
auto br = encb.result();
return (ar._hash[a%8]>>14) == (br._hash[b%8]>>14);
}
Very surprised to see it missing given your comment to me that:
Hopefully it is of some value, and you correct the code and add it in to the paper, else of course the whole approach is pointless is A can equal B
1) Given a block of data D, calculate H = Hash(D).
2) Find nonce A and nonce B such that BirthdayHash(A +H) == BirthdayHash( B+H)
3) If Hash(H + A + B) < TargetDifficulty then a result has been found, otherwise keep
searching.
Step 2 never needs to be run, BirthdayHash is never executed.
All you do is increment A and run Hash(H + A + A) until a result has been found that is under the TargetDifficulty. As soon as you've found this, then B == A and of course BirthdayHash(A+H) == BirthdayHash(B+H).
To fix this, all you need to do is create a rule such that A and B must be different.
Rather than just assuming it and not hard coding it or building it in to the algo that A != B. Seems quite a critical thing to miss from a white paper.
You'll also note that you didn't check for this in your own validation function
Code:
bool momentum_verify( pow_seed_type head, uint32_t a, uint32_t b )
{
uint32_t ia = (a / 8) * 8;
fc::sha512::encoder enca;
enca.write( (char*)&ia, sizeof(ia) );
enca.write( (char*)&head, sizeof(head) );
auto ar = enca.result();
uint32_t ib = (b / 8) * 8;
fc::sha512::encoder encb;
encb.write( (char*)&ib, sizeof(ib) );
encb.write( (char*)&head, sizeof(head) );
auto br = encb.result();
return (ar._hash[a%8]>>14) == (br._hash[b%8]>>14);
}
Very surprised to see it missing given your comment to me that:
What you have just stipulated was implied by using variables A and B and simply pointing out that A cannot be equal to B is IMPLIED and also OBVIOUS. It does not change the algorithm or the idea. So obvious in fact that I suspect everyone else reading it also assumed that requirement.
Sorry, you don't get 30 BTC because I am doing NOTHING DIFFERENT and your feedback provided 0 value.
Sorry, you don't get 30 BTC because I am doing NOTHING DIFFERENT and your feedback provided 0 value.
Hopefully it is of some value, and you correct the code and add it in to the paper, else of course the whole approach is pointless is A can equal B