You won't be able to find my entire
public key in any other
ScriptPubKey other than the one where Braiins stole my block reward, so what's your point?
Go for it blabbermouth if you can find all my public key's bytes of
939a1d46a66ecddf96497a7ec10a79103e317bd5 in any other block reward's ScriptPubKey here on
https://mempool.space/ I'm wrong, otherwise STFU.
ALL BYTES in my public key are accounted for in OP_RETURN's ScriptPubKey therefore not random:
https://mempool.space/tx/12b3d6e1404f6d9714426cbf78f3f5e0392a74f8f6142f9de28f4635c1973c3e A.I. did not go through the bytes in the result.
I DID, byte by byte. I already said that in the last comment. Learn to read.
Well you've ignored this issue:
You are matching half byte boundaries with the half bytes next to them. NOT byte by byte as you claim.
That's not matching that's faking results.
4f does not exist in 1474f0, the only bytes there are 14 74 and f0
Using half byte boundaries to claim that 4f exists in there is bullshit.
Then you are also reversing each byte to almost double the possible values again.
Yes you wont easily find your 20 bytes in other sigs, coz no matching will do the fake looking at half byte boundaries and reverse bytes you are doing, that greatly increases the chances. However, I wouldn't actually be surprised to find your 20 bytes in other sigs, coz the sig is a max of 100 bytes.
However, when you add in the incorrect half byte boundaries you get 199 random bytes - yepo that's got a good chance
Then reverse each of them you end up with
398 different bytes - woo more than
256 there - sound like a lot
It took a braindead AI to do the matches, coz valid byte searches wouldn't find it as easily, vs half byte offset searches, and reverse byte searches.
How about I take that sig and do your fake forward+backward+half byte and see how many unique bytes I get ...
Using my own blockchain explorer I wrote ... getting the coinbase sig from txn 12b3d6e1404f6d9714426cbf78f3f5e0392a74f8f6142f9de28f4635c1973c3e
I get: 03db010e0f2f736c7573682fcb010300b782655bfabe6d6dbbd6cc6f21cd1acf9bc7f872b789f05
6e9b27f68eadf22bdb8441f5c1663b0411000000000000000000028215100de7601000000
(...../slush/......e[..mm...o!......r...V...h.."..D.\.c.A..........(!Q..v....)
Now sorting each byte, normally, and removing duplicates, I find (only) 54 different bytes in there - that's 21.1% of all possible values.
With the above + reversing each byte, and removing duplicates, gives you 91 different values - woo that's already 35.5% of all possible values.
Now also adding in the half byte offsets, and again removing duplicates, you end up with 136 different values - wow that's 53% of all possible values!
Good chance of matching anything only 20 bytes long
But to go one step further, you are also claiming that bytes randomly distributed in a sig, not in any order related to your 20 bytes, is also apparently a match. lol. Reality check please.
P.S. how to get the number "136" different values:
(echo -n '03db010e0f2f736c7573682fcb010300b782655bfabe6d6dbbd6cc6f21cd1acf9bc7f872b789f056e9b27f68eadf22bdb8441f5c1663b0411000000000000000000028215100de7601000000' | rev ; echo -n '03db010e0f2f736c7573682fcb010300b782655bfabe6d6dbbd6cc6f21cd1acf9bc7f872b789f056e9b27f68eadf22bdb8441f5c1663b0411000000000000000000028215100de7601000000' ; echo -n '3db010e0f2f736c7573682fcb010300b782655bfabe6d6dbbd6cc6f21cd1acf9bc7f872b789f056e9b27f68eadf22bdb8441f5c1663b0411000000000000000000028215100de760100000' | rev ; echo -n '3db010e0f2f736c7573682fcb010300b782655bfabe6d6dbbd6cc6f21cd1acf9bc7f872b789f056e9b27f68eadf22bdb8441f5c1663b0411000000000000000000028215100de760100000') | sed -e "s/\(..\)/\1\n/g" | sort -u | wc
