nomachine
Member
Offline
Activity: 321
Merit: 17
|
|
May 12, 2024, 05:43:18 PM Last edit: May 12, 2024, 05:56:59 PM by nomachine |
|
It's more likely to find a $1 million lotto ticket using Dowsing than to solve this Puzzle.
|
|
|
|
kTimesG
Member
Offline
Activity: 87
Merit: 21
|
|
May 12, 2024, 06:03:02 PM |
|
If I would be the creator I would laugh so hard about some of the things discussed here.
Guys, a logarithm is an abstract concept, not some math function.
You get a thing called a "base change". In this case we're dealing with a change of base of an element from some position in a finite field (private keys) to an element in the same position in a finite group (EC public keys) and the problem is to solve for the position without a way to go back from the latter to the first (which is assumed to be hard, but not yet proven). And this in the best case that we even have such an element, and not some fingerprint of it (an address), which makes the problem levels of more absurdly difficult. WTF is with the real numbers field log2 discussion, it makes no sense, we already know the ranges double in size at each step, of course any polynomial regression or whatever is a straight line. Dividing 1 by (2**64) is four levels of magnitude below a double-precision IEEE floating point, so what errors do you expect, they will always be after the 64-th zero decimal digit in reality. Nevermind the fact that there's an infinity of real numbers between any two real numbers, so an infinity of computations. Take 7 as a private key and try to solve back from [1/4, 1/8) interval, mission impossible.
This is not an analytical problem, it's a group theory problem.
log2 - It's just a way of representing numbers in a different way. I'll ask you again, do you know what you're talking about? I hope you are joking. That is NOT what a logarithm is. Number: 7 Representing 7 in different ways: Base 10: 7 Base 2: 0111 Base 7: 10 Base 16: 0x07 Base 1: <potato> <potato> <potato> <potato> <potato> <potato> <potato> Shall I go on? Logarithm of 7 in the infinite field of real numbers: Base 2: 2.8073549221... (infinite number of decimals) - it counts how many bits you need to represent value 7 Base e: 1.9459101490553132... (infinite number of decimals) - it counts how many natural numbers you need that, raised to this power, yields 7 Logarithm of 7 in some modular finite field with N = 3: log(7) = mod 3 (oh no, this doesn't work, hmm... is it 0? 1? 2? damn, something is missing, maybe we didn't even define the neutral element yet? or not even an binary addition operator?) So, do YOU know what you are talking about?
|
|
|
|
maylabel
Newbie
Offline
Activity: 24
Merit: 0
|
|
May 12, 2024, 10:39:07 PM |
|
|
|
|
|
eggsylacer
Newbie
Offline
Activity: 7
Merit: 0
|
|
May 14, 2024, 09:17:46 AM |
|
Geniuses who found the key for address #66, can you tell me if the key is between 37396512239913013824 and 51680708854858323072?
|
|
|
|
Tepan
Jr. Member
Offline
Activity: 47
Merit: 1
|
|
May 14, 2024, 05:11:22 PM |
|
Geniuses who found the key for address #66, can you tell me if the key is between 37396512239913013824 and 51680708854858323072?
The hexadecimal approximately probably 16.12% to found within the 66 bit range. 2B85F409A58861B43 into 3ffffffffffffffff 169,549,060,031,553,553,727. guess that big number.
|
|
|
|
Tepan
Jr. Member
Offline
Activity: 47
Merit: 1
|
|
May 17, 2024, 12:34:06 AM Last edit: May 17, 2024, 01:06:12 AM by Tepan |
|
for your information guys, this puzzle has same pattern like this address doing the transaction. 1VayNert3x1KzbpzMGt2qdqrAThiRovi8proof of https://www.blockchain.com/explorer/transactions/btc/9969603dca74d14d29d1d5f56b94c7872551607f8c2d6837ab9715c60721b50ehttps://www.blockchain.com/explorer/transactions/btc/8c8baf2e0529c0193ad3a583306a16fcc3e9cd271ba625e12bfd74261a46ad7cTotal Received 25467612.38364991 BTC $1,666,432,468,144 Total Sent 25467612.13780228 BTC $1,666,432,452,057 all those transactions seem to have the same ways generate password/OP codes, too, so he would need to spend all of them at the same time. and back to 04/16/2023, that address was sending some amount to this address bc1quksn4yxlxp80tn929gqnh8xpnngqj0fqr99q4z ( not directly), with some scrambled transaction involves many address.
|
|
|
|
maylabel
Newbie
Offline
Activity: 24
Merit: 0
|
|
May 17, 2024, 01:21:44 AM |
|
for your information guys, this puzzle has same pattern like this address doing the transaction.
1VayNert3x1KzbpzMGt2qdqrAThiRovi8
Total Received 25467612.38364991 BTC $1,666,432,468,144
Total Sent 25467612.13780228 BTC $1,666,432,452,057
all those transactions seem to have the same password, too, so he would need to spend all of them at the same time.
and back to 04/16/2023, that address was sending some amount to this address bc1quksn4yxlxp80tn929gqnh8xpnngqj0fqr99q4z (not directly), with some scrambled transaction involves many address.
guess who’s said no pattern ?
Quick update from my side I have been work with statistics, and beside some hints, I manage to find some odd to say at least I was frustrated to the amount of convoluted in the scripts I needed to do to calculate P and Q and the sheer amount of bad explanations of the calculation of bitcoin without step by step (reminds me Butkov), so I worked backwards. I did a script to run the statistics of each letter of the address and the probability of some letters to appear inspired in Kryptos. (My personal theory is: if you add cryptography in top of cryptography several times, you eventually will arrive in a shortcut bypassing all the cryptography before)So theoretically we have base58 what means we can have 58 letter and number to choose, means the probability of each letter is 1/58, so 1.7241379% Even if I manage to find this, something quite stood out as a sore thumb: Some letters has more statistics appearance than others, in some cases up to 8% comparing to the average, and 13% compare with the other extreme of the tail. It was significant more than I was looking for tbh The really caveat is: The top characters are always the same, like no randomization at all. Its always the same group of letters. And if you take a look deeper you will see in vastly majority of addresses are not 34 characters, but way lessa) you take the first number because is not relevant b) you have a considerably amount of repetition inside of the same address. Like the vast majority has minimum of 1 pair of duplicates c) the puzzle 66 have in reality only 20 characters if you take off the repetition. d) this effect happening with most of the addresses You will may say: Is just run more and the averages will pull to 1.72%, right? Quite not, even increasing the size of the batches from 10k addresses to 100k the difference was negligible. Of course I can go up, but my point is why this is so prominent? Sorry but is color code for you see the relationship ( https://imgur.com/a/9hpLpdi) https://imgur.com/a/9hpLpdiI tried to run different rules, like hexadecimals with a lot of number 3 or 4, and looks odd for some batches... kind of a fingerprint,maybe Some letters looks significant more relevant than others... Could be a dead end, i know, but someone looked this before? Someone with more experience in riped160 can tell me why this effect happened? Why we don't have literally any other letter above 1.72% beside as follow I have more other specific analyzes for some areas but I rather save to myself tho I need go back to work, this already took 3 days non stop calculations.
|
|
|
|
nomachine
Member
Offline
Activity: 321
Merit: 17
|
|
May 17, 2024, 06:10:55 AM |
|
all those transactions seem to have the same ways generate password/OP codes, too, so he would need to spend all of them at the same time.
If this is not a BS and is true.... He used used a custom method like: "Type 1 Deterministic Wallet" from here: https://bitcointalk.org/index.php?topic=19137.0Masked with leading 000...0001 to set difficulty. Bad news - if is Greg Maxwell creator of this puzzle password is 30 characters long and so complex that it will take you a couple of million years to crack.
|
|
|
|
kTimesG
Member
Offline
Activity: 87
Merit: 21
|
|
May 17, 2024, 10:24:39 PM Last edit: May 17, 2024, 10:41:57 PM by kTimesG |
|
So theoretically we have base58 what means we can have 58 letter and number to choose, means the probability of each letter is 1/58, so 1.7241379%
Not really, you started off from a wrong premise. RIPEMD: 160 bits. 2**160 choices. 2**160 does not divide by 58 so your probability doesn't take into account the bias for the last remainder (only 52 choices out of 58, hence fewer z w x... was this your secret information to keep for yourself lol?), and neither the implicit "1" characters found at the beginning, when the address is shorter than the maximum length (explaining fewer "1"s). Those leading zeros are actually the character "1" in base58. The leading "1" in the address is discardable since it's just a hint that the first byte of the number is 0, which is always true. Maybe run the stats on the base2 160 bits instead? base58 strings don't map 1:1 with any bitstring, since there is no power of 2 to divide 58, so their space lengths don't fill each other exactly, e.g. I can give you base58 "addresses" with a length identical to a correct one, but that will require more than 160 bits. [LE] It's actually worse than this. Because there's 4 bytes of checksum added to the RIPEMD, and THEN it goes into the base58 encoder, we have 2**192 % 58 = 38 as a remainder. So this might explain your findings better. Last symbol is heavily biased, it only covers 2/3 of the possible choices. It is a known theorem that if two numbers do not divide each other, then bias occurs when using one of them to produce ranges in the other one. Take for example the hidden issues when (naively) doing something like this: A histogram on r will reveal pretty fast that (assuming random() is uniform) you will have a big bias between the range [0, n) and the range [n, 7}, where n = MAX_RAND % 7. Because there's more possibilities to choose from one range than the other one, due to the remainder.
|
|
|
|
nomachine
Member
Offline
Activity: 321
Merit: 17
|
|
May 18, 2024, 08:02:07 AM |
|
We need to develop a multi-threaded algorithm with the following structure: Thread 1: This thread generates starting keys and stores them in a global array. Thread 2: This thread retrieves keys from the global array, computes the corresponding points and RIPEMD-160 hashes, and then stores the resulting HASH160 values into another global array. Threads 3 and 4: These comparator threads read several hundred addresses from a file and compare them with the HASH160 values stored in the global array. Each thread operates independently without relying on the others, potentially improving overall performance. They will work separately. Maybe it will be faster this way? I don't know.
|
|
|
|
maylabel
Newbie
Offline
Activity: 24
Merit: 0
|
|
May 18, 2024, 09:40:04 AM |
|
So theoretically we have base58 what means we can have 58 letter and number to choose, means the probability of each letter is 1/58, so 1.7241379%
Not really, you started off from a wrong premise. RIPEMD: 160 bits. 2**160 choices. 2**160 does not divide by 58 so your probability doesn't take into account the bias for the last remainder (only 52 choices out of 58, hence fewer z w x... was this your secret information to keep for yourself lol?), and neither the implicit "1" characters found at the beginning, when the address is shorter than the maximum length (explaining fewer "1"s). Those leading zeros are actually the character "1" in base58. The leading "1" in the address is discardable since it's just a hint that the first byte of the number is 0, which is always true. Not really, I discarded the first number one because is a testnet, so basically I didnt screw my statistics. But basically you are wrong because you can run by yourself and see the average of all probabilitiess and nail at 1.7241379% in all decimals, means IT IS 1/58 regardless. Furthermore, I didn't found any explanation why has this preferential for some letter if is a "random math base equation" even if you use other hexadecimals. Is this not defeat the entire propose of been random? I mean, run the same statistics for range for 100k between 89f183007d3ce24269a66fb7fe4bc132a0ec877a0b145f6dbb5058f36921cfe3 to 89f1830088a1ec1b926f4b894b4e7b2c6b66dea05bd76434ab5058f36921cfe3 give the same 20 letters above the average of 0000000000000000000000000000000000000000000000020000000000000000 to 000000000000000000000000000000000000000000000003ffffffffffffffff... is very odd to say at least. IDK but I believe is worth it to try, with more time and effort, and a better computer... Anaconda is literally make my laptop give me 3 degree burn ngl because of the simulations i need to use a ice pack... that's how F up is my set up was this your secret information to keep for yourself lol?
Lol.... if is secret is a secret...just a hint, is not that... Has way more mathematical ways to explore this problem. But I need to pay my rent first, otherwise I will sleep on the streets lol Maybe run the stats on the base2 160 bits instead?
Not bad idea... I ran per letter/hexadecimal and the results were very, very, very wild base58 strings don't map 1:1 with any bitstring, since there is no power of 2 to divide 58, so their space lengths don't fill each other exactly, e.g. I can give you base58 "addresses" with a length identical to a correct one, but that will require more than 160 bits.
[LE] It's actually worse than this. Because there's 4 bytes of checksum added to the RIPEMD, and THEN it goes into the base58 encoder, we have 2**192 % 58 = 38 as a remainder. So this might explain your findings better. Last symbol is heavily biased, it only covers 2/3 of the possible choices.
That's a possibility, but when you have a bias, you have a weakness It is a known theorem that if two numbers do not divide each other, then bias occurs when using one of them to produce ranges in the other one. Take for example the hidden issues when (naively) doing something like this: A histogram on r will reveal pretty fast that (assuming random() is uniform) you will have a big bias between the range [0, n) and the range [n, 7}, where n = MAX_RAND % 7. Because there's more possibilities to choose from one range than the other one, due to the remainder. That's something I commented way before: using the idea we are using pseudo-random number + a bias operation, this can, theoretically, reversible... at least for a range But I need to check montecarlo first.... when I have time If you have more ideas, I will love to listen
|
|
|
|
maylabel
Newbie
Offline
Activity: 24
Merit: 0
|
|
May 18, 2024, 10:11:48 AM |
|
We need to develop a multi-threaded algorithm with the following structure: Thread 1: This thread generates starting keys and stores them in a global array. Thread 2: This thread retrieves keys from the global array, computes the corresponding points and RIPEMD-160 hashes, and then stores the resulting HASH160 values into another global array. Threads 3 and 4: These comparator threads read several hundred addresses from a file and compare them with the HASH160 values stored in the global array. Each thread operates independently without relying on the others, potentially improving overall performance. They will work separately. Maybe it will be faster this way? I don't know. this is a pool, right? a pool of checking addresses. that's sometime I said wayyyyyy before... The fact we are probably checking the same addresses is not that low if you are doing by sequence, but also if you do random and you need to shut down your computer, you just lost all your already checked addresses But i believe an better strategy: 3 threads - one produce addresses, the other just check the first 4 digits, and other comparing the pool generated by the second one. Why? Because you save time by just run the first 4 letters. I was watching a yt about a billion data points challenge and they run the analyzes in less than 3 sec with java! If someone can do this in rust/c/java, I will give a hug, please, i need it! Because python....no,no,no... unless you want you house burn down
|
|
|
|
nomachine
Member
Offline
Activity: 321
Merit: 17
|
|
May 18, 2024, 11:06:42 AM Last edit: May 18, 2024, 11:56:24 AM by nomachine |
|
We need to develop a multi-threaded algorithm with the following structure: Thread 1: This thread generates starting keys and stores them in a global array. Thread 2: This thread retrieves keys from the global array, computes the corresponding points and RIPEMD-160 hashes, and then stores the resulting HASH160 values into another global array. Threads 3 and 4: These comparator threads read several hundred addresses from a file and compare them with the HASH160 values stored in the global array. Each thread operates independently without relying on the others, potentially improving overall performance. They will work separately. Maybe it will be faster this way? I don't know. this is a pool, right? a pool of checking addresses. https://tosc.iacr.org/index.php/ToSC/article/view/11282/10814You can find the Git code for the 43-step differential comparator here: https://github.com/Peace9911/ripemd160_attackThis is far better than gazing into a crystal ball or magic circle.
|
|
|
|
maylabel
Newbie
Offline
Activity: 24
Merit: 0
|
|
May 18, 2024, 12:08:09 PM |
|
We need to develop a multi-threaded algorithm with the following structure: Thread 1: This thread generates starting keys and stores them in a global array. Thread 2: This thread retrieves keys from the global array, computes the corresponding points and RIPEMD-160 hashes, and then stores the resulting HASH160 values into another global array. Threads 3 and 4: These comparator threads read several hundred addresses from a file and compare them with the HASH160 values stored in the global array. Each thread operates independently without relying on the others, potentially improving overall performance. They will work separately. Maybe it will be faster this way? I don't know. this is a pool, right? a pool of checking addresses. https://tosc.iacr.org/index.php/ToSC/article/view/11282/10814You can find the Git code for the 43-step differential comparator here: https://github.com/Peace9911/ripemd160_attackThis is far better than gazing into a crystal ball or magic circle. ohhhhh, i looooooooove papers, thanks. I will consume Did you know also ECDSA has a great attack way not patched? I didnt have time if is possible for btc but is worth it to read too https://minerva.crocs.fi.muni.cz/Anyways, i believe if we combine our minds we can arrive somewhere tho
|
|
|
|
kTimesG
Member
Offline
Activity: 87
Merit: 21
|
|
May 18, 2024, 02:28:03 PM |
|
Not really, I discarded the first number one because is a testnet, so basically I didnt screw my statistics.
Did you account for the implicit "1"s I mentioned about? E.g. in decimal if I give you the number "42" but you also know it's a 64-bit value, there are implicit "0"s in front of 42, if your goal is to make some stats on base10 digits of 64-bit values. Because it would not be fair to only count 0s in numbers such as "402", "420", "81505" and so on. Same principle for a BTC address. For base58 the implicit symbol is "1" (the first symbol of base58). This has nothing to do with the "1" which you actually see at the start of an address. And even more, if you have multiple "1"s at the start, all of them are just a convention that says "so many bytes at the start are 0x00", NOT "this so many digits at the front of the base58 representation are 1". So some work is involved here if you truly want to make a histogram on base58 usage (which I don't really understand why you would, it's much more direct and error-free if you just use the binary representation). Furthermore, I didn't found any explanation why has this preferential for some letter if is a "random math base equation" even if you use other hexadecimals. Is this not defeat the entire propose of been random?
Modulus bias. It is not about the random function, it's about the domain size vs. the modulus (base in this case) which is used. base58 is just done like in any other case: divide a big integer, use remainder, repeat with quotient. Maybe run the stats on the base2 160 bits instead?
That's a possibility, but when you have a bias, you have a weakness The only bias here is about the bias of base58 representation, not on RIPEMD. We need to develop a multi-threaded algorithm with the following structure: Thread 1: This thread generates starting keys and stores them in a global array. Thread 2: This thread retrieves keys from the global array, computes the corresponding points and RIPEMD-160 hashes, and then stores the resulting HASH160 values into another global array. Threads 3 and 4: These comparator threads read several hundred addresses from a file and compare them with the HASH160 values stored in the global array. Each thread operates independently without relying on the others, potentially improving overall performance. They will work separately. Maybe it will be faster this way? I don't know. But i believe an better strategy: 3 threads - one produce addresses, the other just check the first 4 digits, and other comparing the pool generated by the second one. Why? Because you save time by just run the first 4 letters. I was watching a yt about a billion data points challenge and they run the analyzes in less than 3 sec with java! If someone can do this in rust/c/java, I will give a hug, please, i need it! Because python....no,no,no... unless you want you house burn down I did it in C. PrivKey (sequential) to PubKey to RIPEMD and then memcmp with the static constant target RIPEMD (which ofcourse returns false as soon as the first byte is different, come on...). You CAN't do it faster than this, and it can only scale linearly with thread count. But it's quickly obvious that it's unfeasible, I mean it's the only real way to do it without knowing the public key, but it's both a O(n) complexity AND it involves SHA256 + RIPEMD at every step. That's why I strongly believe #130 will be found next, not #66. Much more room for breakthroughs and exploration there, and while the complexity seems similar it runs WAY, way faster (no hashing nonsense). btw we need a ton of signatures to break ECDSA, we only have one here. And the nonces are deterministic (checked), so we're screwed.
|
|
|
|
jacky19790729
Jr. Member
Offline
Activity: 71
Merit: 8
|
|
May 18, 2024, 03:11:38 PM Last edit: June 10, 2024, 01:18:32 PM by jacky19790729 |
|
btw we need a ton of signatures to break ECDSA, we only have one here. And the nonces are deterministic (checked), so we're screwed.
#130 only 1 rsz r = 0x9fca00d29192007648f7e4b525f15a00a5180833617a604ec6701833eb26e580 s = 0x1f5ff38219a72080f77534b735badbcf57f503a33e91935ee7a859387abf5483 z = 0x8d9ac8a5bc9b7ab8954e985fb9ebfc82e11c009fcccafcfb90934fb01a8c57ce k = 2^256 priv = 2^129 ~ 2^130 Even with a large number of signatures, it still takes a lot of time... I run https://github.com/iceland2k14/rsz LLL_nonce_leakage.py , spend time log CPU: Intel i9-11900K ( 2024/06/10 Update ) K bit_length spend time --------------------------------------------------------------- 200 bits 20 seconds ( success to find private key ) 8 rsz ... 224 bits 207 seconds ( success to find private key ) 12 rsz ... 236 bits 1813 seconds ( success to find private key ) 19 rsz ... 240 bits 5021 seconds ( success to find private key ) 23 rsz ... 244 bits 12747 seconds ( success to find private key ) 31 rsz 245 bits 18146 seconds ( success to find private key ) 33 rsz 246 bits 36348 seconds ( success to find private key ) 37 rsz 247 bits 248 bits 142189 seconds ( success to find private key ) 45 rsz 249 bits 251375 seconds ( failed ) 52 rsz , need more rsz 250 bits 572073 seconds ( failed ) 64 rsz , need more rsz 251 bits 252 bits 253 bits Never , No matter hundreds to thousands or more rsz 254 bits Never , No matter hundreds to thousands or more rsz 255 bits Never , No matter hundreds to thousands or more rsz 256 bits Never , No matter hundreds to thousands or more rsz
|
|
|
|
Cryptoman2009
Newbie
Offline
Activity: 12
Merit: 1
|
|
May 18, 2024, 10:11:00 PM |
|
Stop looking for logic, all the addresses of the puzzle are random. And using python is 100% a waste of energy. Don't dream idly. Search in a small space (for 66 or 130) and hope for luck.
99.99999999999999999% JUST FOR FUN
|
|
|
|
maylabel
Newbie
Offline
Activity: 24
Merit: 0
|
|
May 19, 2024, 04:09:05 AM |
|
Not really, I discarded the first number one because is a testnet, so basically I didnt screw my statistics.
Did you account for the implicit "1"s I mentioned about? E.g. in decimal if I give you the number "42" but you also know it's a 64-bit value, there are implicit "0"s in front of 42, if your goal is to make some stats on base10 digits of 64-bit values. Because it would not be fair to only count 0s in numbers such as "402", "420", "81505" and so on. As I said,I didn't have time to take a look in running in decimals yet. It's in my to-do list, and I'm surely will take a look to see if any patterns emerged Same principle for a BTC address. For base58 the implicit symbol is "1" (the first symbol of base58). This has nothing to do with the "1" which you actually see at the start of an address. And even more, if you have multiple "1"s at the start, all of them are just a convention that says "so many bytes at the start are 0x00", NOT "this so many digits at the front of the base58 representation are 1". So some work is involved here if you truly want to make a histogram on base58 usage (which I don't really understand why you would, it's much more direct and error-free if you just use the binary representation).
I believe you didnt get what I was pointing out: Cryptography, as any most mathematical techniques, consist in change a one space to another space... we do this all the time, transform x,y,z in polar coordinates, exp and so on... What I may didn't said is: Any exchange of spaces has strength and drawbacks, they are the sides of the same coin. Some pattern can and will emerge when you change spaces. Initially, i imagined change for an log space, but now I see can have other functions fitting better with what I'm seeing. But something similar happened when I worked as statistician in developing games for casinos: We need to work hard to looks "most random as possible". It's way more complicated than you think. The greatest problem is human perception of randomness is not the same as computer randomness, that's why most lottery game are made by functions like that and I proved decade ago this (I was just a broke uni student, and I didn't had credit to put money where my mouth it is, unfortunately )That's why this puzzle really tickles me: I know I can do it, time and money is all I need tho Stop looking for logic, all the addresses of the puzzle are random. And using python is 100% a waste of energy. Don't dream idly. Search in a small space (for 66 or 130) and hope for luck.
99.99999999999999999% JUST FOR FUN
Of course, money is a great incentive (i never needed so much in my life like now) but is a great way to take the rust of my mathematical skills. If you think is a waste of time, is your opinion and good luck for you.... is just not mine Furthermore, I didn't found any explanation why has this preferential for some letter if is a "random math base equation" even if you use other hexadecimals. Is this not defeat the entire propose of been random?
Modulus bias. It is not about the random function, it's about the domain size vs. the modulus (base in this case) which is used. base58 is just done like in any other case: divide a big integer, use remainder, repeat with quotient. That's a high possibility, but again, when pattern emerges, even if is not a bijective function per say, the areas of search reduce considerabily Maybe run the stats on the base2 160 bits instead?
That's a possibility, but when you have a bias, you have a weakness The only bias here is about the bias of base58 representation, not on RIPEMD. We need to develop a multi-threaded algorithm with the following structure: Thread 1: This thread generates starting keys and stores them in a global array. Thread 2: This thread retrieves keys from the global array, computes the corresponding points and RIPEMD-160 hashes, and then stores the resulting HASH160 values into another global array. Threads 3 and 4: These comparator threads read several hundred addresses from a file and compare them with the HASH160 values stored in the global array. Each thread operates independently without relying on the others, potentially improving overall performance. They will work separately. Maybe it will be faster this way? I don't know. But i believe an better strategy: 3 threads - one produce addresses, the other just check the first 4 digits, and other comparing the pool generated by the second one. Why? Because you save time by just run the first 4 letters. I was watching a yt about a billion data points challenge and they run the analyzes in less than 3 sec with java! If someone can do this in rust/c/java, I will give a hug, please, i need it! Because python....no,no,no... unless you want you house burn down I did it in C. PrivKey (sequential) to PubKey to RIPEMD and then memcmp with the static constant target RIPEMD (which ofcourse returns false as soon as the first byte is different, come on...). You CAN't do it faster than this, and it can only scale linearly with thread count. But it's quickly obvious that it's unfeasible, I mean it's the only real way to do it without knowing the public key, but it's both a O(n) complexity AND it involves SHA256 + RIPEMD at every step. I was searching yesterday about Bend and the Multi parallel processing for python, together with some other ideas: - Instead to search for letters use the decimal code cuz been an integer is faster than base 58, around 30% of the speed - KAN machine learning (maybe ) still very new so IDK tbh, but is a possibility nevertheless. - dedicated 2 mini pcs and only the list been for another computer (mine is worse than a potato) - use old phones to do some part of the search.... is not fast but is something That's why I strongly believe #130 will be found next, not #66. Much more room for breakthroughs and exploration there, and while the complexity seems similar it runs WAY, way faster (no hashing nonsense).
btw we need a ton of signatures to break ECDSA, we only have one here. And the nonces are deterministic (checked), so we're screwed.
can you explain more about? I didn't get it, sorry Now I need go back to work... see you later
|
|
|
|
nomachine
Member
Offline
Activity: 321
Merit: 17
|
|
May 19, 2024, 07:13:53 AM |
|
That's why I strongly believe #130 will be found next, not #66. Much more room for breakthroughs and exploration there, and while the complexity seems similar it runs WAY, way faster (no hashing nonsense).
btw we need a ton of signatures to break ECDSA, we only have one here. And the nonces are deterministic (checked), so we're screwed.
can you explain more about? I didn't get it, sorry Now I need go back to work... see you later That's not my quote. But regardless, I can say that none of the puzzles will be solved soon. It takes a thousand GPUs to make something serious. Everything else is just kidding or when discussion derails into "who has bigger dick" babble
|
|
|
|
holy_ship
Jr. Member
Offline
Activity: 113
Merit: 1
|
|
May 20, 2024, 07:17:15 PM Last edit: May 24, 2024, 12:43:43 PM by holy_ship |
|
It takes a thousand GPUs to make something serious. Everything else is just kidding
Why GPU? BSGS works on CPU. btw, what's more important RAM or CPU? I've tried AMD Ryzen 9 7950X - 4.5GHZ, 16c/32th + 128GB - 4ek on start, reaches 6ek after week Intel Core i7-11700K 3.6GHZ, 8c/16th + 128GB - only 2ek, no growth Intel Core i7-11700K 3.6GHZ, 8c/16th + 64GB - around 1ek, no growth E5-2670v3 2.3 GHz 12c/24th + 256GB - 7ek on start 2×E5-2680v4 2.4 GHz 28c/56th + 256GB - 9.5ek on start
|
|
|
|
|