Bitcoin puzzle transaction ~32 BTC prize to who solves it

[GoVanza108@23]

Do you guys think one day the computational power of a single machine will be able to brute force a 256bits?

Yes

[syedsohailahmed]

This puzzle is very strange. If it's for measuring the world's brute forcing capacity, 161-256 are just a waste (RIPEMD160 entropy is filled by 160, and by all of P2PKH Bitcoin). The puzzle creator could improve the puzzle's utility without bringing in any extra funds from outside - just spend 161-256 across to the unsolved portion 51-160, and roughly treble the puzzle's content density.

If on the other hand there's a pattern to find... well... that's awfully open-ended... can we have a hint or two?

I am the creator.

You are quite right, 161-256 are silly.  I honestly just did not think of this.  What is especially embarrassing, is this did not occur to me once, in two years.  By way of excuse, I was not really thinking much about the puzzle at all.

I will make up for two years of stupidity.  I will spend from 161-256 to the unsolved parts, as you suggest.  In addition, I intend to add further funds.  My aim is to boost the density by a factor of 10, from 0.001*length(key) to 0.01*length(key).  Probably in the next few weeks.  At any rate, when I next have an extended period of quiet and calm, to construct the new transaction carefully.

A few words about the puzzle.  There is no pattern.  It is just consecutive keys from a deterministic wallet (masked with leading 000...0001 to set difficulty).  It is simply a crude measuring instrument, of the cracking strength of the community.

Finally, I wish to express appreciation of the efforts of all developers of new cracking tools and technology.  The "large bitcoin collider" is especially innovative and interesting!

Found Hidden Patterns in Private Keys:
https://github.com/syedsohailahmedsam/BTC_32_PUZZLE.git

This puzzle is very strange. If it's for measuring the world's brute forcing capacity, 161-256 are just a waste (RIPEMD160 entropy is filled by 160, and by all of P2PKH Bitcoin). The puzzle creator could improve the puzzle's utility without bringing in any extra funds from outside - just spend 161-256 across to the unsolved portion 51-160, and roughly treble the puzzle's content density.

If on the other hand there's a pattern to find... well... that's awfully open-ended... can we have a hint or two?

I am the creator.

You are quite right, 161-256 are silly.  I honestly just did not think of this.  What is especially embarrassing, is this did not occur to me once, in two years.  By way of excuse, I was not really thinking much about the puzzle at all.

I will make up for two years of stupidity.  I will spend from 161-256 to the unsolved parts, as you suggest.  In addition, I intend to add further funds.  My aim is to boost the density by a factor of 10, from 0.001*length(key) to 0.01*length(key).  Probably in the next few weeks.  At any rate, when I next have an extended period of quiet and calm, to construct the new transaction carefully.

A few words about the puzzle.  There is no pattern.  It is just consecutive keys from a deterministic wallet (masked with leading 000...0001 to set difficulty).  It is simply a crude measuring instrument, of the cracking strength of the community.

Finally, I wish to express appreciation of the efforts of all developers of new cracking tools and technology.  The "large bitcoin collider" is especially innovative and interesting!

Found Hidden Patterns in Private Keys:
https://github.com/syedsohailahmedsam/BTC_32_PUZZLE.git

This is not a blind brute-force tool.
It is an intelligently constrained search engine for keys that might satisfy the structure of Puzzles.
While still computationally difficult, filtering improves performance and feasibility.

🔧 Want to adjust the rules? Just modify the is_valid_hex_key() logic in either script.

Custom Filtering Rules were derived from previously found private keys of puzzles 1-70. You can see found private keys in "numbers.txt".

In our analysis of all known solved Bitcoin cryptographic puzzles (Puzzles 1–70), we discovered that certain patterns have never appeared in any of the revealed private keys.

❌ "No private keys have..."
We exclude any hex private key that contains:

❌ Triple Characters
No valid puzzle solution has ever had three identical hex characters in a row.
Example: "aaa", "666", "fff", "000" → all are invalid

❌ Repeated Double Pairs
While a key might have a pair like "aa" or "ff", no key ever repeats the same pair.
Example: "112211" → "11" appears twice → invalid

❌ Double Characters from a Restricted Set (6, 9, a, d)
Based on prior solutions, no valid key has ever had a double of these characters.
Disallowed patterns: "66", "99", "aa", "dd"

🧠 Why This Matters
These exclusions are not random — they are based on actual solved keys from the Bitcoin Puzzle series.

Zero to negligible instances of these patterns have appeared in the first 70 puzzles.

This drastically reduces the keyspace, making brute-force search more intelligent and focused.

📌 Summary Line
“No private keys have triples, repeated double pairs, or double 6/9/a/d — filtered to match historical puzzle patterns.”

Paths of first 70 private keys:
All paths from root for each Private Key:
Private Key: 1
Path: [1]
Depth: 0

Private Key: 3
Path: [1, 3]
Depth: 1

Private Key: 7
Path: [1, 3, 7]
Depth: 2

Private Key: 8
Path: [1, 2, 4, 8]
Depth: 3

Private Key: 21
Path: [1, 2, 5, 10, 21]
Depth: 4

Private Key: 49
Path: [1, 3, 6, 12, 24, 49]
Depth: 5

Private Key: 76
Path: [1, 2, 4, 9, 19, 38, 76]
Depth: 6

Private Key: 224
Path: [1, 3, 7, 14, 28, 56, 112, 224]
Depth: 7

Private Key: 467
Path: [1, 3, 7, 14, 29, 58, 116, 233, 467]
Depth: 8

Private Key: 514
Path: [1, 2, 4, 8, 16, 32, 64, 128, 257, 514]
Depth: 9

Private Key: 1155
Path: [1, 2, 4, 9, 18, 36, 72, 144, 288, 577, 1155]
Depth: 10

Private Key: 2683
Path: [1, 2, 5, 10, 20, 41, 83, 167, 335, 670, 1341, 2683]
Depth: 11

Private Key: 5216
Path: [1, 2, 5, 10, 20, 40, 81, 163, 326, 652, 1304, 2608, 5216]
Depth: 12

Private Key: 10544
Path: [1, 2, 5, 10, 20, 41, 82, 164, 329, 659, 1318, 2636, 5272, 10544]
Depth: 13

Private Key: 26867
Path: [1, 3, 6, 13, 26, 52, 104, 209, 419, 839, 1679, 3358, 6716, 13433, 26867]
Depth: 14

Private Key: 51510
Path: [1, 3, 6, 12, 25, 50, 100, 201, 402, 804, 1609, 3219, 6438, 12877, 25755, 51510]
Depth: 15

Private Key: 95823
Path: [1, 2, 5, 11, 23, 46, 93, 187, 374, 748, 1497, 2994, 5988, 11977, 23955, 47911, 95823]
Depth: 16

Private Key: 198669
Path: [1, 3, 6, 12, 24, 48, 97, 194, 388, 776, 1552, 3104, 6208, 12416, 24833, 49667, 99334, 198669]
Depth: 17

Private Key: 357535
Path: [1, 2, 5, 10, 21, 43, 87, 174, 349, 698, 1396, 2793, 5586, 11172, 22345, 44691, 89383, 178767, 357535]
Depth: 18

Private Key: 863317
Path: [1, 3, 6, 13, 26, 52, 105, 210, 421, 843, 1686, 3372, 6744, 13489, 26978, 53957, 107914, 215829, 431658, 863317]
Depth: 19

Private Key: 1811764
Path: [1, 3, 6, 13, 27, 55, 110, 221, 442, 884, 1769, 3538, 7077, 14154, 28308, 56617, 113235, 226470, 452941, 905882, 1811764]
Depth: 20

Private Key: 3007503
Path: [1, 2, 5, 11, 22, 45, 91, 183, 367, 734, 1468, 2937, 5874, 11748, 23496, 46992, 93984, 187968, 375937, 751875, 1503751, 3007503]
Depth: 21

Private Key: 5598802
Path: [1, 2, 5, 10, 21, 42, 85, 170, 341, 683, 1366, 2733, 5467, 10935, 21870, 43740, 87481, 174962, 349925, 699850, 1399700, 2799401, 5598802]
Depth: 22

Private Key: 14428676
Path: [1, 3, 6, 13, 27, 55, 110, 220, 440, 880, 1761, 3522, 7045, 14090, 28181, 56362, 112724, 225448, 450896, 901792, 1803584, 3607169, 7214338, 14428676]
Depth: 23

Private Key: 33185509
Path: [1, 3, 7, 15, 31, 63, 126, 253, 506, 1012, 2025, 4050, 8101, 16203, 32407, 64815, 129630, 259261, 518523, 1037047, 2074094, 4148188, 8296377, 16592754, 33185509]
Depth: 24

Private Key: 54538862
Path: [1, 3, 6, 13, 26, 52, 104, 208, 416, 832, 1664, 3328, 6657, 13315, 26630, 53260, 106521, 213042, 426084, 852169, 1704339, 3408678, 6817357, 13634715, 27269431, 54538862]
Depth: 25

Private Key: 111949941
Path: [1, 3, 6, 13, 26, 53, 106, 213, 427, 854, 1708, 3416, 6832, 13665, 27331, 54663, 109326, 218652, 437304, 874608, 1749217, 3498435, 6996871, 13993742, 27987485, 55974970, 111949941]
Depth: 26

Private Key: 227634408
Path: [1, 3, 6, 13, 27, 54, 108, 217, 434, 868, 1736, 3473, 6946, 13893, 27787, 55574, 111149, 222299, 444598, 889196, 1778393, 3556787, 7113575, 14227150, 28454301, 56908602, 113817204, 227634408]
Depth: 27

Private Key: 400708894
Path: [1, 2, 5, 11, 23, 47, 95, 191, 382, 764, 1528, 3057, 6114, 12228, 24457, 48914, 97829, 195658, 391317, 782634, 1565269, 3130538, 6261076, 12522152, 25044305, 50088611, 100177223, 200354447, 400708894]
Depth: 28

Private Key: 1033162084
Path: [1, 3, 7, 15, 30, 61, 123, 246, 492, 985, 1970, 3941, 7882, 15764, 31529, 63059, 126118, 252236, 504473, 1008947, 2017894, 4035789, 8071578, 16143157, 32286315, 64572630, 129145260, 258290521, 516581042, 1033162084]
Depth: 29

Private Key: 2102388551
Path: [1, 3, 7, 15, 31, 62, 125, 250, 501, 1002, 2004, 4009, 8019, 16039, 32079, 64159, 128319, 256639, 513278, 1026556, 2053113, 4106227, 8212455, 16424910, 32849821, 65699642, 131399284, 262798568, 525597137, 1051194275, 2102388551]
Depth: 30

Private Key: 3093472814
Path: [1, 2, 5, 11, 23, 46, 92, 184, 368, 737, 1475, 2950, 5900, 11800, 23601, 47202, 94405, 188810, 377621, 755242, 1510484, 3020969, 6041939, 12083878, 24167756, 48335512, 96671025, 193342050, 386684101, 773368203, 1546736407, 3093472814]
Depth: 31

Private Key: 7137437912
Path: [1, 3, 6, 13, 26, 53, 106, 212, 425, 850, 1701, 3403, 6806, 13613, 27227, 54454, 108908, 217817, 435634, 871269, 1742538, 3485077, 6970154, 13940308, 27880616, 55761233, 111522467, 223044934, 446089869, 892179739, 1784359478, 3568718956, 7137437912]
Depth: 32

Private Key: 14133072157
Path: [1, 3, 6, 13, 26, 52, 105, 210, 421, 842, 1684, 3369, 6739, 13478, 26956, 53913, 107826, 215653, 431307, 862614, 1725228, 3450457, 6900914, 13801828, 27603656, 55207313, 110414626, 220829252, 441658504, 883317009, 1766634019, 3533268039, 7066536078, 14133072157]
Depth: 33

Private Key: 20112871792
Path: [1, 2, 4, 9, 18, 37, 74, 149, 299, 599, 1198, 2397, 4795, 9590, 19181, 38362, 76724, 153449, 306898, 613796, 1227592, 2455184, 4910369, 9820738, 19641476, 39282952, 78565905, 157131810, 314263621, 628527243, 1257054487, 2514108974, 5028217948, 10056435896, 20112871792]
Depth: 34

Private Key: 42387769980
Path: [1, 2, 4, 9, 19, 39, 78, 157, 315, 631, 1263, 2526, 5053, 10106, 20212, 40424, 80848, 161696, 323393, 646786, 1293572, 2587144, 5174288, 10348576, 20697153, 41394306, 82788613, 165577226, 331154452, 662308905, 1324617811, 2649235623, 5298471247, 10596942495, 21193884990, 42387769980]
Depth: 35

Private Key: 100251560595
Path: [1, 2, 5, 11, 23, 46, 93, 186, 373, 746, 1493, 2987, 5975, 11950, 23901, 47803, 95607, 191214, 382429, 764858, 1529717, 3059434, 6118869, 12237739, 24475478, 48950957, 97901914, 195803829, 391607658, 783215317, 1566430634, 3132861268, 6265722537, 12531445074, 25062890148, 50125780297, 100251560595]
Depth: 36

Private Key: 146971536592
Path: [1, 2, 4, 8, 17, 34, 68, 136, 273, 547, 1095, 2190, 4380, 8760, 17520, 35040, 70081, 140162, 280325, 560651, 1121303, 2242607, 4485215, 8970430, 17940861, 35881722, 71763445, 143526891, 287053782, 574107564, 1148215129, 2296430259, 4592860518, 9185721037, 18371442074, 36742884148, 73485768296, 146971536592]
Depth: 37

Private Key: 323724968937
Path: [1, 2, 4, 9, 18, 37, 75, 150, 301, 602, 1205, 2411, 4823, 9647, 19295, 38591, 77182, 154364, 308728, 617456, 1234912, 2469825, 4939651, 9879302, 19758604, 39517208, 79034416, 158068832, 316137664, 632275329, 1264550659, 2529101319, 5058202639, 10116405279, 20232810558, 40465621117, 80931242234, 161862484468, 323724968937]
Depth: 38

Private Key: 1003651412950
Path: [1, 3, 7, 14, 29, 58, 116, 233, 467, 934, 1869, 3738, 7477, 14955, 29911, 59822, 119644, 239289, 478578, 957156, 1914313, 3828626, 7657252, 15314505, 30629010, 61258020, 122516041, 245032083, 490064166, 980128332, 1960256665, 3920513331, 7841026663, 15682053327, 31364106654, 62728213309, 125456426618, 250912853237, 501825706475, 1003651412950]
Depth: 39

Private Key: 1458252205147
Path: [1, 2, 5, 10, 21, 42, 84, 169, 339, 679, 1358, 2716, 5432, 10864, 21729, 43459, 86918, 173837, 347674, 695348, 1390697, 2781395, 5562790, 11125581, 22251162, 44502325, 89004651, 178009302, 356018604, 712037209, 1424074419, 2848148838, 5696297676, 11392595352, 22785190705, 45570381410, 91140762821, 182281525643, 364563051286, 729126102573, 1458252205147]
Depth: 40

Private Key: 2895374552463
Path: [1, 2, 5, 10, 21, 42, 84, 168, 337, 674, 1348, 2696, 5393, 10786, 21572, 43144, 86288, 172577, 345155, 690311, 1380622, 2761244, 5522488, 11044977, 22089954, 44179909, 88359819, 176719638, 353439276, 706878552, 1413757105, 2827514211, 5655028422, 11310056845, 22620113691, 45240227382, 90480454764, 180960909528, 361921819057, 723843638115, 1447687276231, 2895374552463]
Depth: 41

Private Key: 7409811047825
Path: [1, 3, 6, 13, 26, 53, 107, 215, 431, 862, 1725, 3450, 6900, 13801, 27603, 55207, 110414, 220829, 441659, 883318, 1766636, 3533273, 7066546, 14133092, 28266185, 56532371, 113064743, 226129487, 452258975, 904517950, 1809035900, 3618071800, 7236143601, 14472287202, 28944574405, 57889148811, 115778297622, 231556595244, 463113190489, 926226380978, 1852452761956, 3704905523912, 7409811047825]
Depth: 42

Private Key: 15404761757071
Path: [1, 3, 7, 14, 28, 56, 112, 224, 448, 896, 1793, 3586, 7173, 14346, 28693, 57387, 114774, 229548, 459097, 918195, 1836390, 3672781, 7345562, 14691125, 29382251, 58764502, 117529005, 235058010, 470116020, 940232040, 1880464081, 3760928163, 7521856326, 15043712653, 30087425306, 60174850613, 120349701227, 240699402454, 481398804908, 962797609816, 1925595219633, 3851190439267, 7702380878535, 15404761757071]
Depth: 43

Private Key: 19996463086597
Path: [1, 2, 4, 9, 18, 36, 72, 145, 290, 581, 1163, 2327, 4655, 9311, 18623, 37246, 74492, 148985, 297970, 595941, 1191882, 2383764, 4767528, 9535056, 19070113, 38140226, 76280453, 152560906, 305121812, 610243624, 1220487248, 2440974497, 4881948995, 9763897991, 19527795983, 39055591966, 78111183932, 156222367864, 312444735728, 624889471456, 1249778942912, 2499557885824, 4999115771649, 9998231543298, 19996463086597]
Depth: 44

Private Key: 51408670348612
Path: [1, 2, 5, 11, 23, 46, 93, 187, 374, 748, 1496, 2992, 5984, 11969, 23939, 47878, 95756, 191512, 383024, 766048, 1532097, 3064195, 6128391, 12256782, 24513564, 49027128, 98054257, 196108514, 392217028, 784434056, 1568868113, 3137736227, 6275472454, 12550944909, 25101889818, 50203779637, 100407559274, 200815118549, 401630237098, 803260474197, 1606520948394, 3213041896788, 6426083793576, 12852167587153, 25704335174306, 51408670348612]
Depth: 45

Private Key: 119666659114170
Path: [1, 3, 6, 13, 27, 54, 108, 217, 435, 870, 1741, 3482, 6965, 13931, 27862, 55724, 111448, 222896, 445793, 891586, 1783172, 3566344, 7132688, 14265377, 28530754, 57061509, 114123019, 228246038, 456492077, 912984154, 1825968309, 3651936618, 7303873236, 14607746473, 29215492947, 58430985895, 116861971791, 233723943582, 467447887164, 934895774329, 1869791548658, 3739583097317, 7479166194635, 14958332389271, 29916664778542, 59833329557085, 119666659114170]
Depth: 46

Private Key: 191206974700443
Path: [1, 2, 5, 10, 21, 43, 86, 173, 347, 695, 1391, 2782, 5564, 11129, 22259, 44518, 89037, 178075, 356150, 712301, 1424602, 2849205, 5698411, 11396823, 22793647, 45587295, 91174590, 182349180, 364698361, 729396723, 1458793447, 2917586894, 5835173788, 11670347576, 23340695153, 46681390307, 93362780615, 186725561230, 373451122461, 746902244923, 1493804489847, 2987608979694, 5975217959388, 11950435918777, 23900871837555, 47801743675110, 95603487350221, 191206974700443]
Depth: 47

Private Key: 409118905032525
Path: [1, 2, 5, 11, 23, 46, 93, 186, 372, 744, 1488, 2976, 5953, 11906, 23813, 47627, 95255, 190510, 381021, 762043, 1524086, 3048173, 6096346, 12192693, 24385387, 48770774, 97541548, 195083096, 390166192, 780332384, 1560664768, 3121329536, 6242659073, 12485318146, 24970636293, 49941272586, 99882545173, 199765090347, 399530180695, 799060361391, 1598120722783, 3196241445566, 6392482891133, 12784965782266, 25569931564532, 51139863129065, 102279726258131, 204559452516262, 409118905032525]
Depth: 48

Private Key: 611140496167764
Path: [1, 2, 4, 8, 17, 34, 69, 138, 277, 555, 1111, 2223, 4446, 8893, 17786, 35573, 71146, 142292, 284584, 569168, 1138337, 2276675, 4553351, 9106703, 18213406, 36426812, 72853624, 145707248, 291414497, 582828994, 1165657989, 2331315979, 4662631959, 9325263918, 18650527837, 37301055674, 74602111348, 149204222697, 298408445394, 596816890788, 1193633781577, 2387267563155, 4774535126310, 9549070252621, 19098140505242, 38196281010485, 76392562020970, 152785124041941, 305570248083882, 611140496167764]
Depth: 49

Private Key: 2058769515153876
Path: [1, 3, 7, 14, 29, 58, 117, 234, 468, 936, 1872, 3744, 7489, 14979, 29959, 59918, 119836, 239672, 479344, 958689, 1917378, 3834757, 7669514, 15339028, 30678056, 61356112, 122712225, 245424451, 490848902, 981697805, 1963395610, 3926791220, 7853582440, 15707164880, 31414329760, 62828659520, 125657319040, 251314638080, 502629276160, 1005258552321, 2010517104642, 4021034209284, 8042068418569, 16084136837139, 32168273674279, 64336547348558, 128673094697117, 257346189394234, 514692378788469, 1029384757576938, 2058769515153876]
Depth: 50

Private Key: 4216495639600700
Path: [1, 3, 7, 14, 29, 59, 119, 239, 479, 958, 1917, 3834, 7669, 15339, 30679, 61358, 122716, 245432, 490864, 981729, 1963458, 3926917, 7853835, 15707670, 31415340, 62830681, 125661362, 251322724, 502645449, 1005290899, 2010581798, 4021163596, 8042327193, 16084654386, 32169308773, 64338617547, 128677235095, 257354470190, 514708940380, 1029417880761, 2058835761523, 4117671523047, 8235343046095, 16470686092190, 32941372184380, 65882744368760, 131765488737521, 263530977475043, 527061954950087, 1054123909900175, 2108247819800350, 4216495639600700]
Depth: 51

Private Key: 6763683971478124
Path: [1, 3, 6, 12, 24, 48, 96, 192, 384, 768, 1537, 3075, 6151, 12303, 24606, 49212, 98424, 196849, 393698, 787396, 1574792, 3149585, 6299171, 12598343, 25196686, 50393372, 100786745, 201573490, 403146980, 806293960, 1612587921, 3225175843, 6450351687, 12900703375, 25801406751, 51602813503, 103205627006, 206411254012, 412822508024, 825645016049, 1651290032099, 3302580064198, 6605160128396, 13210320256793, 26420640513586, 52841281027172, 105682562054345, 211365124108691, 422730248217382, 845460496434765, 1690920992869531, 3381841985739062, 6763683971478124]
Depth: 52

Private Key: 9974455244496707
Path: [1, 2, 4, 8, 17, 35, 70, 141, 283, 566, 1133, 2267, 4535, 9071, 18143, 36286, 72573, 145147, 290294, 580589, 1161179, 2322358, 4644717, 9289435, 18578870, 37157741, 74315482, 148630965, 297261930, 594523861, 1189047723, 2378095446, 4756190893, 9512381786, 19024763573, 38049527147, 76099054294, 152198108589, 304396217178, 608792434356, 1217584868712, 2435169737425, 4870339474851, 9740678949703, 19481357899407, 38962715798815, 77925431597630, 155850863195261, 311701726390522, 623403452781044, 1246806905562088, 2493613811124176, 4987227622248353, 9974455244496707]
Depth: 53

Private Key: 30045390491869460
Path: [1, 3, 6, 13, 26, 53, 106, 213, 426, 853, 1707, 3415, 6831, 13663, 27326, 54652, 109304, 218608, 437217, 874435, 1748871, 3497743, 6995487, 13990975, 27981950, 55963900, 111927801, 223855603, 447711206, 895422413, 1790844827, 3581689654, 7163379309, 14326758619, 28653517238, 57307034476, 114614068953, 229228137907, 458456275815, 916912551631, 1833825103263, 3667650206527, 7335300413054, 14670600826108, 29341201652216, 58682403304432, 117364806608865, 234729613217730, 469459226435460, 938918452870920, 1877836905741841, 3755673811483682, 7511347622967365, 15022695245934730, 30045390491869460]
Depth: 54

Private Key: 44218742292676575
Path: [1, 2, 4, 9, 19, 39, 78, 157, 314, 628, 1256, 2513, 5027, 10054, 20108, 40216, 80433, 160866, 321733, 643467, 1286934, 2573869, 5147739, 10295478, 20590956, 41181912, 82363825, 164727651, 329455303, 658910606, 1317821213, 2635642426, 5271284853, 10542569707, 21085139414, 42170278828, 84340557656, 168681115313, 337362230626, 674724461252, 1349448922505, 2698897845011, 5397795690023, 10795591380047, 21591182760095, 43182365520191, 86364731040383, 172729462080767, 345458924161535, 690917848323071, 1381835696646142, 2763671393292285, 5527342786584571, 11054685573169143, 22109371146338287, 44218742292676575]
Depth: 55

Private Key: 138245758910846492
Path: [1, 3, 7, 15, 30, 61, 122, 245, 491, 982, 1964, 3929, 7858, 15716, 31433, 62866, 125733, 251467, 502935, 1005870, 2011740, 4023481, 8046962, 16093924, 32187849, 64375698, 128751396, 257502792, 515005584, 1030011168, 2060022337, 4120044675, 8240089351, 16480178703, 32960357406, 65920714812, 131841429625, 263682859250, 527365718501, 1054731437002, 2109462874005, 4218925748011, 8437851496023, 16875702992046, 33751405984093, 67502811968186, 135005623936373, 270011247872747, 540022495745494, 1080044991490988, 2160089982981976, 4320179965963952, 8640359931927905, 17280719863855811, 34561439727711623, 69122879455423246, 138245758910846492]
Depth: 56

Private Key: 199976667976342049
Path: [1, 2, 5, 11, 22, 44, 88, 177, 355, 710, 1420, 2841, 5683, 11367, 22734, 45469, 90938, 181877, 363755, 727510, 1455021, 2910043, 5820087, 11640174, 23280348, 46560696, 93121392, 186242785, 372485570,

[nochkin]

This drastically reduces the keyspace, making brute-force search more intelligent and focused.

Drastically? Did you try to calculate how "drastically" it is? I think the better word is "negligible", not to mention this approach has no solid grounds for this.

“No private keys have triples, repeated double pairs, or double 6/9/a/d — filtered to match historical puzzle patterns.”

It does not mean anything at all regarding the unsolved private keys.
For example, none of the puzzles before 69 had "101" as the prefix, so following your logic the puzzle 69 could not have "101" as prefix, but it did.

[syedsohailahmed]

This drastically reduces the keyspace, making brute-force search more intelligent and focused.

Drastically? Did you try to calculate how "drastically" it is? I think the better word is "negligible", not to mention this approach has no solid grounds for this.

“No private keys have triples, repeated double pairs, or double 6/9/a/d — filtered to match historical puzzle patterns.”

It does not mean anything at all regarding the unsolved private keys.
For example, none of the puzzles before 69 had "101" as the prefix, so following your logic the puzzle 69 could not have "101" as prefix, but it did.

You’re right!
Let it be Fact (my findings be just a statistical piece)

[Virtuose]

Note:
These findings might not be significant for others, but for me it is hard work and research of finding Bitcoins since 5 years.

Congrats! With this kind of intelligent filtering, you’ll keep searching for the next century.
At least you’ll never run out of empty keyspace to explore. But hey, persistence is its own reward, right? Good luck seriously, you’ll need it! 

[syedsohailahmed]

Note:
These findings might not be significant for others, but for me it is hard work and research of finding Bitcoins since 5 years.

Congrats! With this kind of intelligent filtering, you’ll keep searching for the next century.
At least you’ll never run out of empty keyspace to explore. But hey, persistence is its own reward, right? Good luck seriously, you’ll need it! 

 

How about modifying BitCrack Kernel to filter private keys (using my findings or custom filters like no consecutive 5 zeroes in private keys) before address generation!!
Does it improve efficiency??

[Virtuose]

Note:
These findings might not be significant for others, but for me it is hard work and research of finding Bitcoins since 5 years.

Congrats! With this kind of intelligent filtering, you’ll keep searching for the next century.
At least you’ll never run out of empty keyspace to explore. But hey, persistence is its own reward, right? Good luck seriously, you’ll need it! 

 

How about modifying BitCrack Kernel to filter private keys (using my findings or custom filters like no consecutive 5 zeroes in private keys) before address generation!!
Does it improve efficiency??

Filtering is only useful after you’ve scanned or generated the candidate keys, so you’re still forced to generate and process just as many keys, but you throw most of them away after the work is done.
So, you’re not reducing the actual computational cost, just skipping some post-processing. It’s like searching every page in a phone book and then filtering out the wrong names after you’ve already read them all.
So, no, you don’t gain real efficiency , unless your filter can skip key generation itself, which isn’t the case here.

[syedsohailahmed]

Note:
These findings might not be significant for others, but for me it is hard work and research of finding Bitcoins since 5 years.

Congrats! With this kind of intelligent filtering, you’ll keep searching for the next century.
At least you’ll never run out of empty keyspace to explore. But hey, persistence is its own reward, right? Good luck seriously, you’ll need it! 

 

How about modifying BitCrack Kernel to filter private keys (using my findings or custom filters like no consecutive 5 zeroes in private keys) before address generation!!
Does it improve efficiency??

Filtering is only useful after you’ve scanned or generated the candidate keys, so you’re still forced to generate and process just as many keys, but you throw most of them away after the work is done.
So, you’re not reducing the actual computational cost, just skipping some post-processing. It’s like searching every page in a phone book and then filtering out the wrong names after you’ve already read them all.
So, no, you don’t gain real efficiency , unless your filter can skip key generation itself, which isn’t the case here.

Example of How a Filter Works:
We want to exclude private keys that contain triple repeating characters (e.g., “aaa”, “111”, etc.), because no valid Bitcoin private key from Puzzles 1-70 has had this pattern.

Without Filter:
• Generate Private Key
• Convert Private Key to Public Key (elliptic curve multiplication).
• Check Public Key: Convert to Bitcoin address, compare with target.
• If Invalid: Discard the result.

With Filter (Efficiency Gain):
• Generate Private Key
• Filter Check: Check if the private key contains any triple repeating characters.
• If the key fails the filter (e.g., contains “aaa” or “111”), skip the public key calculation.
• If the key passes the filter, proceed to the next step.
• Convert Private Key to Public Key (elliptic curve multiplication).
• Check Public Key: Convert to Bitcoin address, compare with target.
• If Invalid: Discard the result.

We need to update filter with every new private keys…

[AlphaBheta]

Ah, where have we seen this before?

[Virtuose]

Example of How a Filter Works:
We want to exclude private keys that contain triple repeating characters (e.g., “aaa”, “111”, etc.), because no valid Bitcoin private key from Puzzles 1-70 has had this pattern.

Without Filter:
• Generate Private Key
• Convert Private Key to Public Key (elliptic curve multiplication).
• Check Public Key: Convert to Bitcoin address, compare with target.
• If Invalid: Discard the result.

With Filter (Efficiency Gain):
• Generate Private Key
• Filter Check: Check if the private key contains any triple repeating characters.
• If the key fails the filter (e.g., contains “aaa” or “111”), skip the public key calculation.
• If the key passes the filter, proceed to the next step.
• Convert Private Key to Public Key (elliptic curve multiplication).
• Check Public Key: Convert to Bitcoin address, compare with target.
• If Invalid: Discard the result.

We need to update filter with every new private keys…

You only save the cost of EC multiplication and address conversion for filtered keys, but you still have to generate and scan every private key.
The global search space and thus the brute-force difficulty remains the same. Filtering helps a bit, but doesn’t make miracle.

[syedsohailahmed]

Example of How a Filter Works:
We want to exclude private keys that contain triple repeating characters (e.g., “aaa”, “111”, etc.), because no valid Bitcoin private key from Puzzles 1-70 has had this pattern.

Without Filter:
• Generate Private Key
• Convert Private Key to Public Key (elliptic curve multiplication).
• Check Public Key: Convert to Bitcoin address, compare with target.
• If Invalid: Discard the result.

With Filter (Efficiency Gain):
• Generate Private Key
• Filter Check: Check if the private key contains any triple repeating characters.
• If the key fails the filter (e.g., contains “aaa” or “111”), skip the public key calculation.
• If the key passes the filter, proceed to the next step.
• Convert Private Key to Public Key (elliptic curve multiplication).
• Check Public Key: Convert to Bitcoin address, compare with target.
• If Invalid: Discard the result.

We need to update filter with every new private keys…

You only save the cost of EC multiplication and address conversion for filtered keys, but you still have to generate and scan every private key.
The global search space and thus the brute-force difficulty remains the same. Filtering helps a bit, but doesn’t make miracle.

If the filter (no consecutive three same hex digits like aaa) holds true for 71 puzzle:
Why not exclude key generation for entire sub range:
The range we're talking about, 444000000000000000 to 44500000000000000, the first three digits are always "444" (e.g., 444000000000000000, 444100000000000000, ..., 445000000000000000).
Every key in this range starts with the triplet "444", which holds true the filter we're using, as any key containing triple consecutive digits (e.g., "aaa", "111", "444", etc.) is invalid.

It will save computing for quadrillions of keys!

[Virtuose]

Example of How a Filter Works:
We want to exclude private keys that contain triple repeating characters (e.g., “aaa”, “111”, etc.), because no valid Bitcoin private key from Puzzles 1-70 has had this pattern.

Without Filter:
• Generate Private Key
• Convert Private Key to Public Key (elliptic curve multiplication).
• Check Public Key: Convert to Bitcoin address, compare with target.
• If Invalid: Discard the result.

With Filter (Efficiency Gain):
• Generate Private Key
• Filter Check: Check if the private key contains any triple repeating characters.
• If the key fails the filter (e.g., contains “aaa” or “111”), skip the public key calculation.
• If the key passes the filter, proceed to the next step.
• Convert Private Key to Public Key (elliptic curve multiplication).
• Check Public Key: Convert to Bitcoin address, compare with target.
• If Invalid: Discard the result.

We need to update filter with every new private keys…

You only save the cost of EC multiplication and address conversion for filtered keys, but you still have to generate and scan every private key.
The global search space and thus the brute-force difficulty remains the same. Filtering helps a bit, but doesn’t make miracle.

If the filter (no consecutive three same hex digits like aaa) holds true for 71 puzzle:
Why not exclude key generation for entire sub range:
The range we're talking about, 444000000000000000 to 44500000000000000, the first three digits are always "444" (e.g., 444000000000000000, 444100000000000000, ..., 445000000000000000).
Every key in this range starts with the triplet "444", which holds true the filter we're using, as any key containing triple consecutive digits (e.g., "aaa", "111", "444", etc.) is invalid.

It will save computing for quadrillions of keys!

Sure, you’re right if your filter is absolutely reliable, you can skip entire ranges like 444... that violate the rule, which does save a lot of computation.
But remember, this only works if you’re certain the filter will always hold true for any future puzzle. Otherwise, you risk missing possible solutions.

[mahmood1356]

Example of How a Filter Works:
We want to exclude private keys that contain triple repeating characters (e.g., “aaa”, “111”, etc.), because no valid Bitcoin private key from Puzzles 1-70 has had this pattern.

Without Filter:
• Generate Private Key
• Convert Private Key to Public Key (elliptic curve multiplication).
• Check Public Key: Convert to Bitcoin address, compare with target.
• If Invalid: Discard the result.

With Filter (Efficiency Gain):
• Generate Private Key
• Filter Check: Check if the private key contains any triple repeating characters.
• If the key fails the filter (e.g., contains “aaa” or “111”), skip the public key calculation.
• If the key passes the filter, proceed to the next step.
• Convert Private Key to Public Key (elliptic curve multiplication).
• Check Public Key: Convert to Bitcoin address, compare with target.
• If Invalid: Discard the result.

We need to update filter with every new private keys…

You only save the cost of EC multiplication and address conversion for filtered keys, but you still have to generate and scan every private key.
The global search space and thus the brute-force difficulty remains the same. Filtering helps a bit, but doesn’t make miracle.

If the filter (no consecutive three same hex digits like aaa) holds true for 71 puzzle:
Why not exclude key generation for entire sub range:
The range we're talking about, 444000000000000000 to 44500000000000000, the first three digits are always "444" (e.g., 444000000000000000, 444100000000000000, ..., 445000000000000000).
Every key in this range starts with the triplet "444", which holds true the filter we're using, as any key containing triple consecutive digits (e.g., "aaa", "111", "444", etc.) is invalid.

It will save computing for quadrillions of keys!

Sure, you’re right if your filter is absolutely reliable, you can skip entire ranges like 444... that violate the rule, which does save a lot of computation.
But remember, this only works if you’re certain the filter will always hold true for any future puzzle. Otherwise, you risk missing possible solutions.

I also stated the same theory in previous posts, but it was useless and not accepted by users.

[Virtuose]

Sure, you’re right if your filter is absolutely reliable, you can skip entire ranges like 444... that violate the rule, which does save a lot of computation.
But remember, this only works if you’re certain the filter will always hold true for any future puzzle. Otherwise, you risk missing possible solutions.

I also stated the same theory in previous posts, but it was useless and not accepted by users.

It's not a theory, it's just basic logic, if a whole range violates a strict filter, it can be skipped, no need to generate or check those keys at all.
People who reject this are just ignoring the fundamentals. Filtering entire subranges is standard practice, not some controversial idea.

[mahmood1356]

This is nothing new, and I've asked this question several times, and no satisfactory answer has been given in the forum. And it doesn't require coding, all calculations can be done with a calculator.
5HpHagT65TZzG1PH3CSu63k8DbpvM6sdcMk3rQ8hVnTJAphn1wQ
5Km2kuu7vtFDPpxywn4u3NLpbr5jTnTiwHZAqh7Go9SJu8y7XMR
1FAiLLQsUoJwVYeYPUuoceyAyNVENv3b5w

L5oLkpV3aqBjhki6LmvChTCV6odtRDex6c4zRv2gigEhzkSSVKEP
KwDiBf89QgGbjEhKnhXJuH7LrciWTivUb4Z1b36yk3d4nHheQ1AU
1PijtU6wcyyZYiPcjvTaRBbC6xMMkd5Cj

Why did you post these? You have WIFS/Private Keys that aren't in the curve. Maybe I am missing something.

It may not be in the curve, but if you enter them in the wallets, it will work. And what I'm saying is, what happens if we sign a transaction with these symmetric keys, which you say are outside the curve? Test it.

Sure, you’re right if your filter is absolutely reliable, you can skip entire ranges like 444... that violate the rule, which does save a lot of computation.
But remember, this only works if you’re certain the filter will always hold true for any future puzzle. Otherwise, you risk missing possible solutions.

I also stated the same theory in previous posts, but it was useless and not accepted by users.

It's not a theory, it's just basic logic, if a whole range violates a strict filter, it can be skipped, no need to generate or check those keys at all.
People who reject this are just ignoring the fundamentals. Filtering entire subranges is standard practice, not some controversial idea.

So why does everyone take sides on this rule and consider it useless at the very beginning of the discussion in the forum, causing the discussion to be fruitless and not continue its process?

[Virtuose]

Sure, you’re right if your filter is absolutely reliable, you can skip entire ranges like 444... that violate the rule, which does save a lot of computation.
But remember, this only works if you’re certain the filter will always hold true for any future puzzle. Otherwise, you risk missing possible solutions.

I also stated the same theory in previous posts, but it was useless and not accepted by users.

It's not a theory, it's just basic logic, if a whole range violates a strict filter, it can be skipped, no need to generate or check those keys at all.
People who reject this are just ignoring the fundamentals. Filtering entire subranges is standard practice, not some controversial idea.

So why does everyone take sides on this rule and consider it useless at the very beginning of the discussion in the forum, causing the discussion to be fruitless and not continue its process?

Because most people in the forums don’t actually test the math or the practical consequences, they just repeat assumptions, often without understanding the implications.
Many dismiss any filter rule as "useless" without even considering its impact on the actual keyspace or the logic behind it. That kills meaningful discussion before it even begins.

If more people reasoned with facts and data, not just opinions, debates would be more productive 

[fixedpaul]

It's not a theory, it's just basic logic, if a whole range violates a strict filter, it can be skipped, no need to generate or check those keys at all.
People who reject this are just ignoring the fundamentals. Filtering entire subranges is standard practice, not some controversial idea.

So why does everyone take sides on this rule and consider it useless at the very beginning of the discussion in the forum, causing the discussion to be fruitless and not continue its process?

That's just how it is; it doesn't make sense. You're free to skip any keys you want, but there aren't any keys that are more reasonable to skip than others

[kTimesG]

So why does everyone take sides on this rule and consider it useless at the very beginning of the discussion in the forum, causing the discussion to be fruitless and not continue its process?

Because filtering actually slows down the search, no matter how you look at it, with zero benefits (because the filter itself has zero impact on the likelihood of success).

If I were to filter, the first thing I'd do is search the key in the regions where the filter matches, to make sure it's not there. And after that, simply remove the filter itself, since it's irrelevant to have it anyway and simply slows down the process. This way, you get a win-win: peace of heart that you haven't missed the key, and zero efficiency loss.

Most "filters" around here are so naive that they don't even consider the fact that they cover 0.0000001% or less of the total space, so this is why they are better off with the above strategy.

[Cricktor]

The assumption that certain bit patterns haven't yet been observed in known private keys of puzzles and thus won't exist in yet unknown private keys of unsolved puzzles is flawed by itself. As far as I understand "randomness" of derived private keys of a HD wallet, you can't really make assumptions on basically any bit pattern.

The hashing used in BIP32 derivation of private keys make them virtually random and independent from each other. Why some try to ignore this and think they can reliably skip regions without fear to actually miss a valid solution, is beyond my understanding. I don't want to claim to understand all, hell no!

Sure, long sequences of identical bits are less probable to be actually seen but nothing prevents them from occuring.

[oddstake]

I am also running 135 puzzles, and using bsgs to run some old lost mining addresses. I have been running for more than half a year in total, but I haven't earned a penny. Haha, I wish you good luck.

Are you using BSGS random to break a 256-bit Bitcoin address where the length of a private key is 64 characters long?   That's wasted energy and resources. Even puzzle 135 is almost impossible to crack by using BSGS random where the prv key is having only 34 chars in length.  
Good luck though, I'm currently scanning puzzle 135,  bsgs random with 260 exakeys/s and almost giving up.

Code:

[+] Random mode
[+] Stats output every 1 seconds
[+] Mode BSGS random
[+] Opening file 135.txt
[+] Added 1 points from file
[+] Range
[+] -- from : 0x4000000000000000000000000000000000
[+] -- to   : 0x4fffffffffffffffffffffffffffffffff
[+] N = 0x1000000000000
[+] Bloom filter for 274877906944 elements : 942249.56 MB
[+] Bloom filter for 8589934592 elements : 29445.30 MB
[+] Bloom filter for 268435456 elements : 920.17 MB
[+] Allocating 4096.00 MB for 268435456 bP Points
[+] Reading bloom filter from file keyhunt_bsgs_4_274877906944.blm .... Done!
[+] Reading bloom filter from file keyhunt_bsgs_6_8589934592.blm .... Done!
[+] Reading bP Table from file keyhunt_bsgs_2_268435456.tbl .... Done!
[+] Reading bloom filter from file keyhunt_bsgs_7_268435456.blm .... Done!
[+] Thread 0x4d0c36d8ff9468cc14ad1e038410891c47  conds: ~260 Ekeys/s (260967284607849559562 keys/s)