yes that's right that's why I said it's strange .....I try to understand how this can happen but

ok albert0bsd but my remark came from the fact that the explorer shows $2.07 sent as well as the difference between the total received and the final balance...so why 

It's strange did you notice that on #66 there is an output awaiting validation  2.07$  
https://www.blockchain.com/fr/explorer/addresses/btc/13zb1hQbWVsc2S7ZTZnP2G4undNNpdh5so
It is not validated so the pubkey is not broadcast but the scale takes it into account without any validation   Total Received 6.60036526 BTC   Final Bitcoin Balance 6.60028826
It doesn't exist on the other # yet. How can this happen?

it remains only theoretical and probabilistic the distribution is obviously not linear if not on range #64 by adding an additional character to 16jY7qLJnx ex H ==> 16jY7qLJnxH it should come out <1 but in this case there are 2 whereas for 16jY7qLJnx N or P only one address but it stands

No, I do not think so because it covers the whole range #64 with this prefix 16jY7qLJnx
So 18 obtained on a purely theoretical and probabilistic distribution of 21 on this range with this prefix 16jY7qLJnx

EDF9CD60356DCC19        17147962869286816793            16jY7qLJnx2ixrxCnTLSraerkgyB3YYAiT
AF6F7A0015695AA4        12641456819830086308            16jY7qLJnx4enVJC2Ao3wRv3tRusseu5Yb
EBE2EB35503B43E4        16997406557861528548            16jY7qLJnx4f4yqNvmp7LtnaatiUuwgUwW
CF32BE01449CE45D        14930204627341993053            16jY7qLJnxABQQMzyUZ8qsJ3sHaPDZVxJ7
C9DDAD024A7C3688       14545972596827764360            16jY7qLJnxBo3HMqG3wP2MRh9CQXcgSVcf
EEB9AB334DF2770D         17201968488557737741            16jY7qLJnxHBp3dqwV2kzYq1LucfZzgxsH
CE1EB402A0085C60         14852506544482311264            16jY7qLJnxHHepGawzcc4xcNVZZdpFD8xu
C33AE60173B94230         14067809279956042288            16jY7qLJnxN3ec4QBdgpT8pYg77c8Wt6A9
D461BAACE35DB135        15303718260493365557            16jY7qLJnxPwmtRgVS3HBg2RtAoHe1koZF
F7051F27B09112D4          17799667357578236628            16jY7qLJnxb7CHZyqBP8qca9d51gAjyXQN
B0D6BBB249F4D96F          12742578570110753135            16jY7qLJnxcZQ1ff7Y6ascX2FwkVfMEqcn
C42B8F0185753E8C          14135549092129226380            16jY7qLJnxgQD6f6rp4js9MiqCMkB3gAY5
E5CC7336D5283C4A          16558736609276083274            16jY7qLJnxhMwuUoPD7J3GTmDqLH7MaU6h
9357254130F9270A          10616995608473970442            16jY7qLJnxht5HL2NBywuoC8jK34rz8NJv
C8841802AA8BE839          14448699904241690681            16jY7qLJnxiepip11xyDZitPPsHssCRKT2
C4230300DFE089AF          14133143357909666223            16jY7qLJnxoBx9Zhsa1tN62rfZXX1bgKNp
AF3F2501F141A44C          12627852570442966092            16jY7qLJnxpsj9dmx9WAuRgxkk9pPvuFXw
8EC5EDB376AEB55A          10287890278843856218            16jY7qLJnxtt8FSYMze4DRVMWQF47auU8M

How to get all addresses + privateKey starting with 16jY7qLJn from #64?
More interesting all those on this same range of 64 starting with 16jY7qLJnx?

I had fun going through these ranges on the basis of the principle to reduce the search time that the last character before the 5 could perhaps be:  a c e n h G . According to the script I purposely excluded all other ABCDEF....123456789

Kw111111111a5bCRZhiS5sEGMpmcRZdpAhmWLRfMmutGmPHtjVob
Kwzzzzzzzzza5bCRZhiS5sEGMpmcRZdpAhmWLRfMmutGmPHtjVob
Kw111111111c5bCRZhiS5sEGMpmcRZdpAhmWLRfMmutGmPHtjVob
Kwzzzzzzzzzc5bCRZhiS5sEGMPmcRZdpAhmWLRfMmutGmPHtjVob
Kw111111111e5bCRZhiS5sEGMpmcRZdpAhmWLRfMmutGmPHtjVob
Kwzzzzzzzzzze5bCRZhiS5sEGMpmcRZdpAhmWLRfMmutGmPHtjVob
Kw111111111n5bCRZhiS5sEGMpmcRZdpAhmWLRfMmutGmPHtjVob
Kwzzzzzzzzzn5bCRZhiS5sEGMpmcRZdpAhmWLRfMmutGmPHtjVob
Kw111111111h5bCRZhiS5sEGMpmcRZdpAhmWLRfMmutGmPHtjVob
Kwzzzzzzzzzh5bCRZhiS5sEGMpmcRZdpAhmWLRfMmutGmPHtjVob
Kw111111111G5bCRZhiS5sEGMpmcRZdpAhmWLRfMmutGmPHtjVob
KwzzzzzzzzzG5bCRZhiS5sEGMPmcRZdpAhmWLRfMmutGmPHtjVob
The same tracks were made with the prefixes L1 L2 L3 L4 L5 and Kx Ky Kz for compressed

In Uncompressed
5J11111111a5bCRZhiS5sEGMpmcRZdpAhmWLRfMmutGmPHtjVob
5Jzzzzzzzza5bCRZhiS5sEGMPmcRZdpAhmWLRfMmutGmPHtjVob
5J11111111c5bCRZhiS5sEGMpmcRZdpAhmWLRfMmutGmPHtjVob
5Jzzzzzzzzc5bCRZhiS5sEGMpmcRZdpAhmWLRfMmutGmPHtjVob
5J11111111e5bCRZhiS5sEGMpmcRZdpAhmWLRfMmutGmPHtjVob
5Jzzzzzzzze5bCRZhiS5sEGMpmcRZdpAhmWLRfMmutGmPHtjVob
5J11111111n5bCRZhiS5sEGMpmcRZdpAhmWLRfMmutGmPHtjVob
5Jzzzzzzzzn5bCRZhiS5sEGMpmcRZdpAhmWLRfMmutGmPHtjVob
5J11111111h5bCRZhiS5sEGMpmcRZdpAhmWLRfMmutGmPHtjVob
5Jzzzzzzzzh5bCRZhiS5sEGMpmcRZdpAhmWLRfMmutGmPHtjVob
5J11111111G5bCRZhiS5sEGMpmcRZdpAhmWLRfMmutGmPHtjVob
5JzzzzzzzzG5bCRZhiS5sEGMpmcRZdpAhmWLRfMmutGmPHtjVob

To cover more it would be necessary to continue with 5K and 5H but hey I think like PawGo that it's one more fake and a waste of time, I just wanted to make sure :-)
Surely someone else had to do it before but I haven't seen anything these are my results after there is still a small chance with 5K and 5H or with another character than a c e n h G before 5 but I very much doubt it although it remains a possibility
The only serious addresses that deserve attention are those of Puzzle 1000 BTC, the rest for 99% is only fake or scam

in 3 months maximum it will be discovered

this from MrMaxwell might suit you very simple to use
https://github.com/MrMaxweII/Secp256k1-Calculator
On the other hand if you want to divide a pubkey which corresponds to an odd pk you will have its half etc etc... deleting the float is another much more complicated story. In short, dividing a pubkey in half will not help you much unless you know the starting pk

Hi Zielar
Waouhh impressive this speed! If you could choose the beginning and end of the search range, you could find pubkey #66 between 2 and 4 months. On the other hand the search is carried out randomly it makes random hashes on the PK of #64 #66 #67 #68 #69 #71 and #72 it can be faster as well as much longer depending on luck. Too bad this program could be largely optimized like choosing the hash range #66 as well as the random or sequential mode with your speed you could come across #66 in 1 month or 2 depending on luck.

Edit
Looking more closely at the operation of this utility and your speed, the proba are these
in 10 days on all the beaches by inserting the 6 pubkeys (I calculated for the first 6 # not 29)  you have a one in 148 chance of having one of the keys
in 20 days 1/74  1.35%
in 40 days 1/37  2.75%
in 80 days 1/18  5.5%
in 160 days 1/9  11%
in 320 days 1/4  25%
it remains arbitrary because luck can enormously speed up the process

Yes your results are correct. But this is possible because you know the initial private key otherwise you would have a problem your result would be wrong and your PubKey not found on the curve.
Try to perform the same operations with this pubkey 03770538afe9b82a6a4d6511ee28427f68ce2d4c4a2598fd5453232e304bedb9e0
and your result will be false very quickly where you will need +/-1 so 2^n for each operation then just for -10 bit 2^10 1024 operations X2 because +/- so 2048  (2048 pubkey of which only one will be on the curve with -10bit) 11 bit 4096 operations

It would take a minimum speed of 5 TerraKeys/s to start being in the correct time frame for #66. Multiply by 2 the delay or speed for each key above without pubkey

it all depends on your hardware but let's say that with average hardware Bitcrack vanbitcracken keyhunt can do it without any problem or even much more but even if you could multiply by 2 or 3 their speed it will help you very very very little

unfortunately no magic for puzzles without pubkey for the moment there is only brute force but even for 66 it's bigger than ocean! For those with pubkey on the other hand, a whole bunch of arithmetic ideas can be found, it remains to find the right one to restrict the range which is enormous and then use kangaroo or bsgs

approximately 0.000000000012%  /  you are about 100 times more likely to win the lottery
but without playing it is not certain not to win 

X   33709eb11e0d4439a729f21c2c443dedb727528229713f0065721ba8fa46f00e
Y   2a1c304a39a77775d3579d077b6ee5e4d26fd3ec36f52ad674a9b47fdd999c48


no but the pubkeys are accessible as they all had an exit

For the moment this proves one thing, regardless of the premium behind an address and the computing power used when the pubkey is disclosed, having a private key greater than 125 bit is secure  and without pubkey even a 66 bit is solid. Conclusion bitcoin is strong and bruteforcing is not the right approach with current technology to resolve all #  .... I have a hunch the bounties may even be doubled even further as this won't resolve either #125 or #68. For #66 and 67 maybe

Not quite exact as calculation with 100000 RTX 2070 GPUs it would take 4 days for #66 and 8 days for #67 but I agree it would take around 100000 RTX 2070 or 50000 RTX 3060 GPUs  
For #66 67 68 69 with a lot of luck / good material / and a community it can be found it is not impossible with time. But for #71 and following without pubkey you need another approach than bruteforcing

Everyone thinks he will be the lucky one and prefers to avoid having to share the X10 is made to encourage people to pool their power to demonstrate that even with a collective effort the 66 67 68 and 69 will be difficult to obtain otherwise it won't find away
Also give a good boost to this puzzle which is now 8 years old

even if he does not intervene with his nickname it seems that he has read and listened to you digaran making it even more attractive

#66 and #67 should not last long because it becomes very interesting (profitable) to rent a strong computing power to reach them

I'm curious to see now if the X10 financial bounty can accelerate or not as saatoshi_rising said "of the cracking strength of the community." if the resistance is due to the bounty or the network strength .... anyway I highly doubt that beyond 135 bit nothing will be solved no matter the bounty it will take something other than brute force