Topic: == Bitcoin challenge transaction: ~1000 BTC total bounty to solvers! ==UPDATED== - page 5. (Read 57113 times)

he

https://bitcointalksearch.org/topic/m.51803085

and he in cooperation

https://bitcointalksearch.org/user/jeanluc-2550169

together take 120,125,130

Who is he? Or what does it mean?

This is Zellar wallet.

---

go away scammer !!!!

As we can see this is a fact. 120,125,130 were withdrawn to the same wallet - 3Emiwzxme7Mrj4d89uqohXNncnRM15YESs

No did not move anything. I think it was solved by the same guy as 120,125...

I think the owner of this Puzzle just moved 13 btc from puzzle #130 to his wallet, the one ending with YESs

Wow you just found the puzzle pattern now we can solve it easily thank you very much...


Jokes aside it is the hexadecimal representation, each puzzle was placed in one bit range (2**bit)

Yeah... It's an unpleasant situation for me, and I think for many.
A lot of time and effort has been spent.
But in any case, let's be happy for the winner!
I hope he will provide a private key so that we can make sure that we have applied our efforts and skills in the right direction.
Or we should continue to learn and come up with new search methods.

it`s realy done 

Hello there 

Wow, Gratz to the solver of puzzle 130   

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.

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).
>>>>

This is pretty good for a start.
The speed is not great, of course, but it will do for general education.
Well, everyone knows that a tree grows from a small seed.
Good luck with your development.

Hi guys, I made a little key miner that works for keys 66, 67 and 68, using a tiny super mini esp32-c2, it only generates about 24 keys per second but it's a very low power microcontroller, it has an audible alarm to hear when I win the prize, what do you think?

https://imgur.com/a/bitcoin-puzzle-Ay0xXiY

congratulations to the winner!
so, now 6.7 at fire.

If you had read what I wrote carefully, I would have been happy.

"I guess"

Don't say you have this kind of disease.

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...