First, the hash is in hexadecimal, so only A through F would be present. So including G and subsequent letters is useless.
Second. There is an inherent error in the logic where the drawing algorithm can select "00" but it is not allowed in the number where 1-60 would be valid numbers.
First, our software doesn't transform "g" and subsequent letters, so, in fact, it's an amendment to make to the document.
Second, it is not a logic error, but a need for clarification as we state:
When it should also state that 00 pairs would be split just as numbers higher than 60 would.
Thank you very much for your observation!
Good, looking forward to updated whitepaper.
When it should also state that 00 pairs would be split just as numbers higher than 60 would.
This would reduce the chance of 00, but does not eliminate it.
Here is the drawing numbers algorithm:
Set the CurrentDigitPair to end of string -2
clear variable PickNumber[6]
Do for 6 numbers
CurrentNumber = take the right most 2 hexadecimal digit pair from CurrentDigitPair
check for presence of A-F and substitute 0-5
if number is greater than 60
then
PickNumber = Prepend 0 + LSD of CurrentNumber
set CurrentDigitPair to CurrentDigitPair -1
else
PickNumber = CurrentNumber
set CurrentDigitPair to CurrentDigitPair -2
enddo
Here is an example of a transaction hash:
https://blockchain.info/block/000000000000000000450016a722bb867cad73aeb1edaa2187ab989b5863f052
For a discussion of 00, if a byte of hash is 0x00.
Per the whitepaper's description of selecting a number, the algorithm is detailed above and will be followed.
1) take the LS digit pair, 00, as per your description, it will be spit into 2 digits. 0, 0.
2) prepend 0 0 LSD of current number, resulting in a new 00.
So the 00 does not go away with >60 split mechanism.
Are you taking into account the fact that the process is made from right to left?
In your example the drawing outcome would be:
52 - 50 - 3 - 6 - 58 - 1
I listed that as an example of what a transaction hash would look like which is quite different from the example in the whitepaper.
Now for a "discussion" take a byte of "00" which is certainly possible. So if we take hash byte of 00, the above logic would take place. So, the logic in the whitepaper is still incorrect.