Topic: Bitcoin puzzle transaction ~32 BTC prize to who solves it - page 34. (Read 230599 times)
it was NOT J.L.-P. who solved those puzzles
Damn!!! whoever the solver of 130 bit is. is genius..!!!
Of course, that is JLP himself, but apparently not with the GitHub version of Kangaroo 2.2.
This is version 8.0 at least.
How do you know it is JLP ?
Because when it comes to solving 130-bit, even the Kangaroo needs a turbo boost... and JLP's got the keys to the garage!
Then why hast he shared the private key yet ? i mean he is a great contributor if he solved it im pretty sure he would have shared the found private key right ?
Damn!!! whoever the solver of 130 bit is. is genius..!!!
Of course, that is JLP himself, but apparently not with the GitHub version of Kangaroo 2.2.
This is version 8.0 at least.
How do you know it is JLP ?
Because when it comes to solving 130-bit, even the Kangaroo needs a turbo boost... and JLP's got the keys to the garage!
Damn!!! whoever the solver of 130 bit is. is genius..!!!
Of course, that is JLP himself, but apparently not with the GitHub version of Kangaroo 2.2.
This is version 8.0 at least.
How do you know it is JLP ?
Damn!!! whoever the solver of 130 bit is. is genius..!!!
Of course, that is JLP himself, but apparently not with the GitHub version of Kangaroo 2.2.
This is version 8.0 at least.
@Tepan
Can you explain a little bit more your formula ?
Can you explain a little bit more your formula ?
First thing first it's funny someone really spend their time to this like Mr.AKITO.
I want to explain but I'm afraid of appearing smarter than my friends who are great at spending their time creating and ensuring programs like search using the hash of public key 160 and even compressed public keys, will feel offensive to them, this is just my thoughts for 2 years paying more attention to this forum and puzzle.
but okay if you want to.
old_key = 4563 -- was from "95823/21" 21 is divided by count the 95823 into 2097151, have 2 option 22 or 21, 21 is precisely with target.
old_range = (65536, 131071)
new_range = (1048576, 2097151)
result :
[1245699, 1660932, 2076165, 1400841, 1816074, 1140750, 1555983, 1971216, 1295892, 1711125, 1451034, 1866267, 1190943, 1606176, 2021409, 1346085, 1761318, 1085994, 1501227, 1916460, 1241136, 1656369, 2071602, 1396278, 1811511, 1136187, 1551420, 1966653, 1291329, 1706562, 1446471, 1861704, 1186380, 1601613, 2016846, 1341522, 1756755, 1081431, 1496664, 1911897, 1236573, 1651806, 2067039, 1391715, 1806948, 1131624, 1546857, 1962090, 1286766, 1701999, 1441908, 1857141, 1181817, 1597050, 2012283, 1336959, 1752192, 1076868, 1492101, 1907334, 1232010, 1647243, 2062476, 1387152, 1802385, 1127061, 1542294, 1957527, 1282203, 1697436, 1437345, 1852578, 1177254, 1592487, 2007720, 1332396, 1747629, 1072305, 1487538, 1902771, 1227447, 1642680, 2057913, 1382589, 1797822, 1122498, 1537731, 1952964, 1277640, 1692873, 1432782, 1848015, 1172691, 1587924, 2003157, 1327833, 1743066, 1067742, 1482975, 1898208, 1222884, 1638117, 2053350, 1378026, 1793259, 1117935, 1533168, 1948401, 1273077, 1688310, 1428219, 1843452, 1168128, 1583361, 1998594, 1323270, 1738503, 1063179, 1478412, 1893645, 1218321, 1633554, 2048787, 1373463, 1788696, 1113372, 1528605, 1943838, 1268514, 1683747, 1423656, 1838889, 1163565, 1578798, 1994031, 1318707, 1733940, 1058616, 1473849, 1889082, 1213758, 1628991, 2044224, 1368900, 1784133, 1108809, 1524042, 1939275, 1263951, 1679184, 2094417, 1419093, 1834326, 1159002, 1574235, 1989468, 1314144, 1729377, 1054053, 1469286, 1884519, 1209195, 1624428, 2039661, 1364337, 1779570, 1104246, 1519479, 1934712, 1259388, 1674621, 2089854, 1414530, 1829763, 1154439, 1569672, 1984905, 1309581, 1724814, 1049490, 1464723, 1879956, 1204632, 1619865, 2035098, 1359774, 1775007, 1099683, 1514916, 1930149, 1254825, 1670058, 2085291, 1409967, 1825200, 1149876, 1565109, 1980342, 1305018, 1720251, 1460160, 1875393, 1200069, 1615302, 2030535, 1355211, 1770444, 1095120, 1510353, 1925586, 1250262, 1665495, 2080728, 1405404, 1820637, 1145313, 1560546, 1975779, 1300455, 1715688, 1455597, 1870830, 1195506, 1610739, 2025972, 1350648, 1765881, 2097151, 1090557, 1505790, 1921023]
i mark that with red color, just because as you can see, it's nearly with real decimal value to search, i test it with 10-20 puzzle, there is always a very close result, but need to search and wait for time.
for someone if ask how you can determine the first search is 1811764
in real condition with my codes is marked into hex, and groupped for search ranges, so it's from small value to larger value, and sequence ranges but random search on ranges.
searching puzzle #21 key 1BA534 > 1811764.
[...snip...]
@Tepan I still dont understand the sequence of values. Are just random values? Or are they following a pattern using the number old_key = 4563 ?
Also you select the red number based on the private key of the puzzle 21 so... what if you dont know it ?
I'm just trying to make sense to your message and trying to replicate to other puzzles
Damn!!! whoever the solver of 130 bit is. is genius..!!! damn i was on it for 3 years i thought i was almost there.. i know i would get a lot of hate for what im about top tell but.. i was working so hard on this so i could give my dad a better care for my father coz he's terminally ill. now the difficulty just got harder 
and got to redo the math from scratch.. good luck for the solver. just sad i couldn't make it.
and got to redo the math from scratch.. good luck for the solver. just sad i couldn't make it. Shouldn't we be looking at FPGAs by now?
We should. But it should be one that can compete with the 20.000+ number of cores in a high-end GPU.
If it only has a few number of parallel units they should be so freaking fast that they do more total jumps/s than what the equivalent GPU (with [tens of] thousands of cores) do. Otherwise it would overall be slower.
To get a rough idea if it's worth it I would first start with the field multiplication. I'm not sure if Bernstein's 256-bit multiplier using logic gates is the best one yet (or even if it's public) but you can take it as a reference. Then we have on average six 256-bit multiplications per jump per kangaroo. Depending on FPGA specs you can compare the raw performance against what a GPU can perform (for example a RTX 4090 can do around 90 billion 256-bit field mul/s at the very low level, before we can talk about point addition and so on)
You can find very recent (2022) HW designs of fast XGCD (for mod inv) which is the bottleneck when running Kangaroo on a GPU (around 50% of the running time is spent just by field inversion, even when doing just a single inversion for a batch of thousands of kangaroos / jump).
If the inversion is in HW than a FPGA might get overall faster than a GPU, or it might not, dependng on the other factors.
Shouldn't we be looking at FPGAs by now?
Or consider leveraging a RISC-V CPU for this.
Someone has to sit down and write a completely new kangaroo.
Shouldn't we be looking at FPGAs by now?
I'm actually working on a little project to get me started with Verilog.
It is a simple xpoint-only bruteforcer for now. The design works fine, but I couldn't fit it on the target chip yet.
The main goal is to get to the level where I can create a HDL Kangaroo implementation as there are none out there.
I agree with you. I think the future is the FPGA, it is the clear evolution path.
No attacks here, just lonely elliptic curves in a world that never understood them. 😢
chatGPT bab, then talk about brute or secp246k1, not answer about attack....
unless it's bragging about how 'brute' it is! 😜 But don't worry, no attacks here
I am sure many of us have read the exact same ChatGPT answer
Yes, hahaha! I even have version 3.0 of the puzzle exponential prediction script created by ChatGPT. That silicon brain even suggested I try a magic circle with colors in Python. I think 90% of the ideas here came from ChatGPT.
chatGPT bab, then talk about brute or secp246k1, not answer about attack....
I am sure many of us have read the exact same ChatGPT answer
Yes, hahaha! I even have version 3.0 of the puzzle exponential prediction script created by ChatGPT. That silicon brain even suggested I try a magic circle with colors in Python. I think 90% of the ideas here came from ChatGPT.
Someone has to sit down and write a completely new kangaroo.
Shouldn't we be looking at FPGAs by now?
I'm actually working on a little project to get me started with Verilog.
It is a simple xpoint-only bruteforcer for now. The design works fine, but I couldn't fit it on the target chip yet.
The main goal is to get to the level where I can create a HDL Kangaroo implementation as there are none out there.
You can check with monitoring tools on your system OS.
Yes exactly. It's not worth it.. Someone has to sit down and write a completely new kangaroo.
Just to be quick so it's not too late.
Interesting find! It seems the private keys for these addresses are likely generated using a deterministic formula based on a sequence number. The increasing decimal values you've observed (3, 7, 8, 21...) suggest a simple mathematical progression.
Here's what I can analyze:
The pattern seems to be an increasing sequence, possibly exponential.
The provided examples show a clear relationship between the address number and the private key value.
Unfortunately, without knowing the exact formula or a starting point, it's difficult to predict the private keys for addresses 15 and beyond.
Here's what I can analyze:
The pattern seems to be an increasing sequence, possibly exponential.
The provided examples show a clear relationship between the address number and the private key value.
Unfortunately, without knowing the exact formula or a starting point, it's difficult to predict the private keys for addresses 15 and beyond.
If you think there's a simple mathematical pattern, you should team up with the guy who's trying to solve it with Photoshop charts and have digiran oversee you both. I am sure many of us have read the exact same ChatGPT answer, typed verbatim:
Quote
The pattern seems to be an increasing sequence, possibly exponential.
The provided examples show a clear relationship between the address number and the private key value.
Unfortunately, without knowing the exact formula or a starting point, it's difficult to predict the private keys for addresses 15 and beyond.
The provided examples show a clear relationship between the address number and the private key value.
Unfortunately, without knowing the exact formula or a starting point, it's difficult to predict the private keys for addresses 15 and beyond.
lmao you didn't analyze squat.
Interesting find! It seems the private keys for these addresses are likely generated using a deterministic formula based on a sequence number. The increasing decimal values you've observed (3, 7, 8, 21...) suggest a simple mathematical progression.
Here's what I can analyze:
The pattern seems to be an increasing sequence, possibly exponential.
The provided examples show a clear relationship between the address number and the private key value.
Unfortunately, without knowing the exact formula or a starting point, it's difficult to predict the private keys for addresses 15 and beyond.
Here's what I can analyze:
The pattern seems to be an increasing sequence, possibly exponential.
The provided examples show a clear relationship between the address number and the private key value.
Unfortunately, without knowing the exact formula or a starting point, it's difficult to predict the private keys for addresses 15 and beyond.
yeah, I already looked at all the diffs (git diff with git-delta) so you see it like shown on your screenshots. Very neat tool to get the data displayed in linux CLI. However the program does not work as intended, GPU is not utilized at all, only CPU works. The performance counter (rate) shows unreliable and unrealistic high values (trillions and billions of MKeys/sec) depending on the grid size you choose. But most important part is that the GPU is not utilized at all. You can check with monitoring tools on your system OS.
sad we cannot see the diff to JLP's original kangaroo tool. Anyone dived into mikorists' code and can share some thoughts about the changes and implementation routines ?
I didn't have time to go through all the files, but I did go through the SECPK1 folder. Everything has been changed to work for 256bit if the CPU is used. Looking at the counter this version is about 15-20% faster than the original in CPU mode. I didn't look at how the GPU is used. This is a mixed code between ZenulAbidin & AlbertTajuelo. There is nothing new here.
Jump to: