Bitcoin puzzle transaction ~32 BTC prize to who solves it

[nomachine]

python scans 50,000 addresses per second

Just to add... Rust is about 10-15 times faster than python, depending on which Crates are used on which hardware and how it is compiled. So for those who don't have a GPU, they also have a solution together with standard C++ scripts.

[ihsotas91]

120, 125 and 130.
captured by hacker ? because this address is 1DiegoU6ETJXK9hNWVTeuK4Y8fkksPnEnK seem fishy with 3Emiwzxme7Mrj4d89uqohXNncnRM15YESs
and he's announce this "https://www.blockchain.com/explorer/transactions/btc/69888f5e55d414b8de65f3a9307a1f414d7035cf9142239045300ce018984bd4"

the next target to take and spend.

    {
      "address": "1BY8GQbnueYofwSuFAT3USAhGjPrkxDdW9",
      "pkscript": "76a914739437bb3dd6d1983e66629c5f08c70e5276937188ac",
      "value": 1231,
      "spent": false,
      "spender": null
    },

it's 67, anyone who can find even 67, the transactions will be attacked by this person.

ngl, this guy very smart and genius build the transaction and from the number of transactions increasing slowly and rhythmically.

You are right about the attack. However about 3Emi, I do not think so, that transaction you shared does not belong to 3Emi, it belongs to a lamer, a noob, a very beginner who does not know anything.

And for you guys, I shared in older posts a script where you can immediately move BTC from one wallet to another. Use those kind of proper and reliable script to move when you solve any puzzle. Also, move whole balance all in once, because while waiting small amount of transfer to be moved (testing if btc is going), hackers start slowing and solves the private key from the exposed public key in 4-5 minutes for the small numbers like the puzzle #67.

[nomachine]

https://github.com/mikorist/Kangaroo-256-bit

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.

[citb0in]

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.

[tradingtalks]

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.

[saatoshi_falling]

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.

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:

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.

lmao you didn't analyze squat.

[nomachine]

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. 

[CY4NiDE]

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.

[nomachine]

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.

[COBRAS]

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

[nomachine]

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 

[Akito S. M. Hosana]

No attacks here, just lonely elliptic curves in a world that never understood them. 😢

[alexxino]

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.

[nomachine]

Shouldn't we be looking at FPGAs by now?

Or consider leveraging a RISC-V CPU for this.

[kTimesG]

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.

[shelby0930]

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.

[alexxino]

@Tepan

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

[nomachine]

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. 

[shelby0930]

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 ?

[Akito S. M. Hosana]

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!