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

I don't have kids yet, i want to have at least one son or a daughter, you don't know but you are actually very blessed

I see you have chosen the path of cowards, there are so many things in life other than this puzzle.
Find something else, believe in God, because he always provides.

Also there is no such a thing as an off switch for us, we never go off, whatever happens we keep existing.

A wife and kids, you are already blessed, you just don't know it.

It has been partly fun but most exhausting running a server in my garage in hope to find one of the puzzles to save me from debt, poverty and help out with illness in my family with unpayable medical bills. Sunday wife and kids are out of town and I will turn off the server and myself. Good luck rest of you!

It's easier to solve a key if you know the public key, when someone spends from his address, public key associated with that address is revealed, this is what Satoshi did with puzzles every 5 key apart, methods such as kangaroo and BSGS can be used to speed up the search thousands of times faster than brute forcing for unexposed puzzles.

That's why you should never keep your coins on addresses with known public keys.😉 ( not that any time soon they can crack 256 bit keys, so every one is safe for a few decades )

I see puzzles 65, 70, 75, 80 ... 125 are solved. How come?

Can anyone here write a fast python  script to do the following?

We'd provide it with target public key and then it divides it by 2 but then adds n/2 to the result and divides the result by 2, however we would want to keep all the generated keys keys, nothing should be discarded.

Example of what we want the script do :

Target : p1
0291b418fd1778356ce947a5cbb46539fd29842aea168486fae91fc5317177a575

Divide by 2 = p2
02239883d26ec1fc3a513e5cc1a93975d1e4ea9850271e88a36520cd3e4eaed7d0

Adding n/2 to p2 = p3
02a714beab8015a2cdffddd772360115ddec59aa4ddf0f8fe968afd1723b576744

Dividing p3 by 2 = p4
02df418550bcb5fe3124b38da7d6ea9fe90db627c04bc048a0bba5486917b31f7e

Adding n/2 to p4 = p5
03013a363007c73a9c2fccabb7a193c35d3daaf7b40026110861488e2b2efbbc56

Now what we want is actually dividing all the keys by 2 as many times as we specify but at the same time we would want to add n/2 to each newly generated key and then divide + n/2 them as well.

Easy peasy, right? Just that if we want to drop 40 characters/bits from our target, we'd need to generate and keep 2^40 public keys. This is for educational purposes only, ( yeah right! 😉 ).

Really crazy what they did with AI and those top end video cards! Still not much changed in the last 15 years - ATI5970, 3200 cores at 800 Mhz,
today top card, only 5-6 times that, with double the frequency, and 20x times the cost. Ok, it has crazy amount of RAM and bandwidth, i am sure
it is important for harvesting people private data, too bad is not much use for us. I honestly believed some 20 years ago when trying to bruteforce
a TEA key(only 8 bytes), that in the future we will be able to flip 64 bits in a second with ease.

The biggest cluster i have personally run was only 20 video cards(10 machines), a friend run like 1500 cards, and that was a nightmare to maintain.

As for scaling up, the only option is to have some kind of server/arbiter/job manager, written in higher language that splits the keyspace into very
small chunks that serve to nodes for crunching, and then verify, barely trust the results. Because hw tricks are simply not enough if you'll be drawing MW from the power grid and pay people to maintain your racks.

it still sounds complicated, you can use the example of 130 puzzles to write commands on how to break it into parts, and what command to look for in each part.

Your welcome =D I hope it can help get more people to test the integrity of the blockchain & bring a bit of awareness to how it functions.

I think there are a number of huge optimizations that could be made to increase the mk/s for the H100's but it would require some changes to the .cu files & headers & whatnot which is over my head haha. I'm definitely gonna play around anyways. All of that bandwidth & memory is not being leveraged properly most dolphinately.

So many questions come to my mind when you brought up failures when running clusters. Would you be able to use the save work function to recover? I wonder what types of redundancies could be put in place, like you mentioned underclocking/volting. From what I was just reading when they trained Bloom 176b LLM they had some failure issues too. I was just reading their paper on the model so i'll copy paste what they were saying:

 "During training, we faced issues with hardware failures: on average, 1–2 GPU failures
occurred each week. As backup nodes were available and automatically used, and checkpoints were saved every three hours, this did not affect training throughput significantly."

They were using 384 NVIDIA A100 80GB GPUs (48 nodes) with 32 spare GPUs for about 3 & a half months! Trained on nuclear energy which is awesome too.

Hey,

Thanks for the video, really informative!


Is that card really that slow ? For 35k USD i expected much more.


Also one other thing not mentioned often, but when you run large clusters, you need to make sure no mistakes can happen, so you either underclock/undervolt the chips/gpus/fpgas/whatever or repeat chunks around, etc. Imagine running whole floor of machines for few months and one machine craps out on the chunk with the winning key ;(

Howdy y'all I just wanted to thank you all who checked out the youtube video I made last year on using vast.ai
I saw that I had like over 1k views and was surprised there was so much interest. Thank you bitcointalk! I caved after almost decade and finally made an account to share what i've been up to.

Anyways, I was really disgusted with the quality of that video so I went and made a better version that is quite fool proof. Here is the link https://youtu.be/bBOLZnFbEOc

In the video I use an Nvidia H100 and it floats around 3500 mk/s

In order to use the H100 I forked the Jean Luc Pons Kangaroo with a new Makefile that works with newer compiler versions. I am running it on cudcuda:12.0.1-devel-ubuntu20.04. g++4.8 no more. My github is https://github.com/momofukku/Kangaroo2

Yo I saw back early April they 10x'd the prizes! Super cool! Now lets try'n find entropy patterns.

Since its my first post but i've been on this site for ever I must end by shouting out gmaxwell omg dude is a legend! Talk about standing on the shoulder of giants!

~one love

Edit: sorry ripemdhash I forgot to try to answer your question. Pretty sure 63 to 64 was solved last September. I saw it guesstimated you have about a 2^10 higher probability of using pollard rho theory opposed to brute forcing. Idk if thats accurate but i'm convinced brute forcing isn't the way.
The best GPU's going right now are probably the H100 and the RTX6000 ADA. Without the proper mathematics all the computer power in the world is just wasted energy so if your gonna shell out the money to run clusters make sure your math is on point =D Thank you for sharing my video!

https://github.com/BTC-HUB-GROUP/PubHunt

Is anyone sure this even works?

When its running it reports bits, every bit the amount of computations double for the next required bit increase. Does this mean when its at 50bit its only scanning in the 50 bit range?

Code seems simple and maybe dare I say fun.

[10:06:53] [GPU: 1538.03 MH/s] [T: 56,831,443,468,288 (46 bit)] [F: 0] 
[23:34:41] [GPU: 1520.21 MH/s] [T: 131,355,736,276,992 (47 bit)] [F: 0] 
[25:18:46] [GPU: 1528.59 MH/s] [T: 140,840,802,451,456 (48 bit)] [F: 0] 
[35:49:31] [GPU: 1540.13 MH/s] [T: 199,668,382,302,208 (48 bit)] [F: 0] 
[57:20:31] [GPU: 1528.60 MH/s] [T: 320,320,640,647,168 (49 bit)] [F: 0] 
[70:41:51] [GPU: 1561.09 MH/s] [T: 394,940,412,592,128 (49 bit)] [F: 0] 
[82:02:23] [GPU: 1568.43 MH/s] [T: 458,789,262,196,736 (49 bit)] [F: 0] 
[96:37:41] [GPU: 1425.79 MH/s] [T: 539,854,018,445,312 (49 bit)] [F: 0] 
[105:48:12] [GPU: 1512.86 MH/s] [T: 591,400,085,225,472 (50 bit)] [F: 0] 
[118:24:29] [GPU: 1517.04 MH/s] [T: 661,610,855,137,280 (50 bit)] [F: 0] 
[144:26:15] [GPU: 1534.88 MH/s] [T: 806,676,613,562,368 (50 bit)] [F: 0] 
[168:04:28] [GPU: 1520.20 MH/s] [T: 939,011,786,932,224 (50 bit)] [F: 0] 
[168:38:10] [GPU: 1510.77 MH/s] [T: 942,101,864,906,752 (50 bit)] [F: 0] 
[191:30:27] [GPU: 1529.64 MH/s] [T: 1,070,122,592,632,832 (50 bit)] [F: 0] 
[191:33:19] [GPU: 1516.01 MH/s] [T: 1,070,385,508,384,768 (50 bit)] [F: 0] 

I don't know what I haven't tried because there are so many attempts. I don't remember everything. Years have passed in this.
I started dreaming at night about WIFs ending so....

This  script calculates the common prefixes of the first 42 characters among Bitcoin private keys in a specified range.
It then lists the private keys and prints the top 10 most similar common prefixes in reverse order (longest to shortest).
start = 67079069358943824031
end =  69594534459904217431
Start and end sets the range of private keys (start and end values) and the number of parts to divide the range into (num_parts = 9).
You can adjust these values as you see fit.

Common Prefix: KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qa5
Part 1 67079069358943824031 KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qa5Dno9kZYi4bZLVzbZF
Part 2 67358565481272756631 KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qa5YXcS8wxDr233cNfFe
Part 3 67638061603601689231 KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qa5sGRiXLMjdSWjJrHgT
Part 4 67917557725930621831 KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qa6C1EzuimFQrzXCYipU
Part 5 68197053848259554431 KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qa6Wk4HJ7AmCHUHd6pi7
Part 6 68476549970588487031 KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qa6qUsZgVaGyhx259cDB
Part 7 68756046092917419631 KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qa7ADgr4synm8RiEbUHW
Part 8 69035542215246352231 KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qa7UxW8TGPJYYuQ9jo4j
Part 9 69315038337575284831 KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qa7ohKQqenpKyP9CM47x

Top 10 Most Similar Prefixes (in reverse order):
KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qa
KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qa
KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qa7
KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qa7
KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qa6
KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qa6
KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qa5
KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qa5
KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qa7ohKQqen

They are all in range:



KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3q + a5, a6, a7  and  a8.


It only takes about 6143,074 years to solve  this range.  

please share it to me lapeci2017@ g mail . com.
thanks

As the list unfolds, it weaves a tapestry of interwoven imagination, leaving the observer intrigued by the enigmatic beauty that emerges from the simple elegance of logarithmic transformations.

Like the cryptic genius behind an encrypted message, the origins and intentions of this sequence remain shrouded in mystery, inviting wonder and sparking curiosity within those who seek to comprehend its enigmatic essence.

hmm, who knew that random generator would be governed by the laws of normal distribution.

https://en.wikipedia.org/wiki/Random_variable

Limited resources......

logarithmic difference (base 10) between WIFs 1-65:

log(3) - log(1) ≈ 0.47712125471966244
log(7) - log(3) ≈ 0.36797678529459443
log(8 ) - log(7) ≈ 0.05799194697768673
log(21) - log(8 ) ≈ 0.41912930774197565
log(49) - log(21) ≈ 0.36797678529459443
log(76) - log(49) ≈ 0.19061751225227766
log(224) - log(76) ≈ 0.46943442605337143
log(467) - log(224) ≈ 0.3190688622319493
log(514) - log(467) ≈ 0.04164623842916361
log(1155) - log(514) ≈ 0.3516188652328874
log(2683) - log(1155) ≈ 0.3660386884437759
log(5216) - log(2683) ≈ 0.2887169100519248
log(10544) - log(5216) ≈ 0.3056678145260709
log(26867) - log(10544) ≈ 0.40621377807107406
log(51510) - log(26867) ≈ 0.28267237455957017
log(95823) - log(51510) ≈ 0.26957821362600115
log(198669) - log(95823) ≈ 0.31666034225815626
log(357535) - log(198669) ≈ 0.25518845663206713
log(863317) - log(357535) ≈ 0.3828517305049723
log(1811764) - log(863317) ≈ 0.3219313330147192
log(3007503) - log(1811764) ≈ 0.22010444330662446
log(5598802) - log(3007503) ≈ 0.26988903984573276
log(14428676) - log(5598802) ≈ 0.41113137224813495
log(33185509) - log(14428676) ≈ 0.3617220019295993
log(54538862) - log(33185509) ≈ 0.21575758852777027
log(111949941) - log(54538862) ≈ 0.3123177972583235
log(227634408) - log(111949941) ≈ 0.3082140392839779
log(400708894) - log(227634408) ≈ 0.24559107367744676
log(1033162084) - log(400708894) ≈ 0.4113394776328735
log(2102388551) - log(1033162084) ≈ 0.30854452321700526
log(3093472814) - log(2102388551) ≈ 0.167733320870153
log(7137437912) - log(3093472814) ≈ 0.36309603966333015
log(14133072157) - log(7137437912) ≈ 0.2966942328950074
log(20112871792) - log(14133072157) ≈ 0.15323750896247362
log(42387769980) - log(20112871792) ≈ 0.3237664837075102
log(100251560595) - log(42387769980) ≈ 0.3738505729734196
log(146971536592) - log(100251560595) ≈ 0.16614209284620785
log(323724968937) - log(146971536592) ≈ 0.3429429631062055
log(1003651412950) - log(323724968937) ≈ 0.4914067024711515
log(1458252205147) - log(1003651412950) ≈ 0.16224974149667518
log(2895374552463) - log(1458252205147) ≈ 0.29787211121731233
log(7409811047825) - log(2895374552463) ≈ 0.40810238044098246
log(15404761757071) - log(7409811047825) ≈ 0.3178478526126524
log(19996463086597) - log(15404761757071) ≈ 0.11329819966627307
log(51408670348612) - log(19996463086597) ≈ 0.41008318549831724
log(119666659114170) - log(51408670348612) ≈ 0.366936795177466
log(191206974700443) - log(119666659114170) ≈ 0.20353056363880792
log(409118905032525) - log(191206974700443) ≈ 0.33034581824839665
log(611140496167764) - log(409118905032525) ≈ 0.17429151410955282
log(2058769515153876) - log(611140496167764) ≈ 0.5274666664452157
log(4216495639600700) - log(2058769515153876) ≈ 0.3113439266558567
log(6763683971478124) - log(4216495639600700) ≈ 0.20523165173925442
log(9974455244496707) - log(6763683971478124) ≈ 0.16870587869969977
log(30045390491869460) - log(9974455244496707) ≈ 0.47888866680875336
log(44218742292676575) - log(30045390491869460) ≈ 0.16782853304825565
log(138245758910846492) - log(44218742292676575) ≈ 0.49504543109679533
log(199976667976342049) - log(138245758910846492) ≈ 0.16032751092312678
log(525070384258266191) - log(199976667976342049) ≈ 0.41923819544053276
log(1135041350219496382) - log(525070384258266191) ≈ 0.3347941601156713
log(1425787542618654982) - log(1135041350219496382) ≈ 0.09904313245967539
log(3908372542507822062) - log(1425787542618654982) ≈ 0.4379411376951916
log(8993229949524469768) - log(3908372542507822062) ≈ 0.36191974453574244
log(17799667357578236628) - log(8993229949524469768) ≈ 0.2964961881251935
log(30568377312064202855) - log(17799667357578236628) ≈ 0.23486049906891004

When we look at the differences, we can observe that they are roughly consistent, hovering around 0.4 to 0.6.  

The differences appear to fluctuate without any apparent pattern.

May I ask why you guys are doing this? What do you think is the advantage?

I'm doing almost the same but using cuda