Quote from: qwertyui0p on September 22, 2024, 03:52:08 AM

I may be reading this wrong and my theory may be without merit -- but it seems to me, given the replacement transaction was less than 18 seconds behind the original, it implies the creator of the replacement transaction ALREADY had the private key and did not need to the public key to run Pollard's kangaroo against it. Wouldn't it have taken a little longer than 18 seconds to find the key and replace the transaction? And isn't it ironic that the creator of the replacement transaction left exactly .66 BTC behind (for puzzle #66), instead of sweeping the entire thing? Who would have had the private key already and not used it? Who would leave behind exactly .66 BTC? Is it possible it was the creator of the puzzle clawing back the lion share and leaving the original amount? Anyone else have thoughts about this?

>>>>
2024-09-12: puzzle #66 (6.60126013 BTC) was solved by 1Jvv4yWkE9MhbuwGUoqFYzDjRVQHaLWuJd (tx) but the original spending transaction was replaced by bc1qpkp47q5cucrvnyepsdnjcv2kzyav5ze0ta7n67 (tx) spending only 5.93923605 BTC. Another address 15XVN6hFkzGdUTY1XcsYKXxRezjARwyBQx took the rest of the prize: 0.66100387 BTC (tx).
>>>>

Quote from: Cricktor on September 17, 2024, 12:58:20 PM

Quote from: bibilgin on September 15, 2024, 10:18:25 PM

Quote from: TamactiJun on September 13, 2024, 01:57:12 AM

~~~

Hello, I noticed something.

66. Wallet transfer time: 9/13/2024, 01:59:39
Your message: 09/13/2024, 01:57:12
...

You should normalize timestamps to UTC for universal comparability. Block #861068 which contained the first withdrawal tx 57a88f47e4c0...6e9ae7fc2f5f has a block timestamp of 2024-09-12T22:59:39Z (the suffix Z for Zulu means it's UTC). And one of my own nodes saw this block at precisely 2024-09-12T22:59:57Z ("Saw new header" announcement) and UpdateTip a second later.

Common blockchain explorers like mempool.space or bitcoinexplorer.org show block and transaction timestamps in your browser's local timezone per default (for bitcoinexplorer.org you can configure it to display in UTC which is nice), while blockchair.com displays it in UTC per default AFAIR.

If you draw conclusions based on wrong data (unknowingly?), you spread false and flawed assumptions. Sort of a disease in these internet times when too many people spread any BS unquestioned...

I'm no expert but....
To your first question, no. The first transaction was https://www.blockchain.com/explorer/transactions/btc/8c8ec6b3511c62500ea9b3a1c30ca937e15d251b55d30290a2a6da2f1124f3fb which was replaced by https://www.blockchain.com/explorer/transactions/btc/57a88f47e4c047740b782a5562fca143ce85de0373cbff3a7d406e9ae7fc2f5f about 75 seconds later, but treat this number as a ballpark figure since transactions are seen by nodes at slightly different times as they propagate across the network. For a mid to high end PC with a well written script, this is more than enough time to crack the key and broadcast a replacement transaction. Using albert0's Keyhunt on my own desktop PC (Intel i7-14700k, 96GB RAM) assuming I have already saved the pubkey to file 66key.txt:

time ./keyhunt -m bsgs -f tests/66key.txt -l compress -b 66 -s 1 -t 28 -k 2048 -S -6

Version 0.2.230519 Satoshi Quest, developed by AlbertoBSD
Search compress only
Stats output every 1 seconds
Threads : 28
K factor 2048

[W] Skipping checksums on files

Mode BSGS sequential
Opening file tests/66key.txt
Added 1 points from file
Bit Range 66
-- from : 0x20000000000000000
-- to : 0x40000000000000000
N = 0x100000000000
Bloom filter for 8589934592 elements : 29445.30 MB
Bloom filter for 268435456 elements : 920.17 MB
Bloom filter for 8388608 elements : 28.76 MB
Allocating 128.00 MB for 8388608 bP Points
Reading bloom filter from file keyhunt_bsgs_4_8589934592.blm .... Done!
Reading bloom filter from file keyhunt_bsgs_6_268435456.blm .... Done!
Reading bP Table from file keyhunt_bsgs_2_8388608.tbl .... Done!
Reading bloom filter from file keyhunt_bsgs_7_8388608.blm .... Done!
Thread Key found privkey 2832ed74f2b5e35ee 62822912 keys in 8 seconds: ~2 Ekeys/s (2193815968482852864 keys/s)
Publickey 024ee2be2d4e9f92d2f5a4a03058617dc45befe22938feed5b7a6b7282dd74cbdd

All points were found000000000

Thread 0x28339600000000000

real 0m15.194s
user 3m43.041s
sys 0m9.423s

It takes just 15.194 seconds. If anything, I'm surprised the replacement transaction didn't arrive sooner.

As for your other questions (again I'm no expert, just an observer):
1. Maybe key finder was a newb and tried to sweep all funds which failed
2. Maybe the replacement transaction was a bot, choosing to only spend 66's largest input with a much higher fee to increase chances it would be accepted into the mempool and be mined
3. Maybe the key finder was an expert, and in a clever and methodical way, intentionally broadcasted the first sweep transaction as well as the replacement transaction of just the largest input, to increase the chances they would at least get the 5.9BTC, and this (may have??) had the effect of causing the mempool to reject any more replacement transaction attempts until the next block was mined and
4. Maybe there were no bots, or if there was, they either weren't running at the time, were not configured properly/not fast enough to get a replacement transaction broadcast to the mempool or the transactions were simply just rejected because of the then-pending existing replacement transaction
5. Maybe the number of possible scenario's that could have played out is as big as the bitcoin keyspace itself, I doubt we will ever really know who/what/when/where/how it happened.