 Show Posts
|
|
Pages: [1] 2 3 »
|
Robots?  hahahahah Using Mara and no robot can do nothing  |
|
|
|
Mara is a tool designed to quickly replace or front-run unconfirmed transactions by broadcasting competing ones. For the attacker, it’s effective and “safe” to use. For the victim, it means a real risk of losing funds if their transaction gets replaced before confirmation basically Mara is one of several tools designed to do the same thing: quickly replace or front-run unconfirmed Bitcoin transactions by broadcasting competing transactions with higher fees. What makes Mara notable is it’s often optimized for speed and automation, especially in the context of puzzle key cracking and mempool monitoring. But fundamentally, it uses Bitcoin’s standard Replace-By-Fee (RBF) or mempool replacement rules—just like any other mempool? ? Mara doesn't publish the public key. Without it, no bot will notice any ID txid , public key, or anything else. When the origin address is 0, the all balance it's already in my new wallet then in the mempool my transaction appears saying: Public key not available or not published something like that. in short: bots are useless with Mara https://www.binance.com/en/square/post/22423542983737 |
|
|
|
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. ´´Heklo friend WanderingPhilospher Its possible you tell me wath diference i use or not the parameter in VBCr.exe -r rekey? is better with rekey or dont use that paraneter? Any advantage if i use? thank you so much (my 3060 make 1070 Mkeys/s) |
|
|
|
The GPU part of the code is way too complex to be efficient. Consider simplifying it (a lot!) that is the point, the binary transformations involved create unique values(no repeatence, no collisions) and hit areas of the range that random or sequential may never reach, yes, its not that fast, there is trade-off, but its unique in its own way so threoretically there are multiple targets (horizontally or vertically or inversion or reversed) - hitting which automatically reveals the main private key, and i believe it could be effective and because all transformations are in binary format they are quite accurate, hitting those tiny places, that random or sequential may never reach for a better understanding i made a pc version of the same algorithm on python https://github.com/puzzleman22/Bitcoin-puzzle-transformations-CPUyes of course I realize that the range is still huge I believe that with enough computational power this method can be very effective Hello friend. Thank you for your project. I don't care how it works as long as it works I'm already testing it on 45 bits to see how long it will take, but I believe it has great promise. I'm sorry I'm poor and can't contribute, but who knows, maybe something will happen, and I will definitely remember you. Thank you. ps: can't really work with any interval other than starting with 1 to 1? because full transformations are applied from 0 to F in hex with "1" prefix is simplier to apply them, on prefix "2" or "3" we need to repeat them for both yes you can use it on any range, but it will not be symmetrical for them for now its just for simplicity i recommend start from 21 puzzle, then increase to see how it goes... GPUS are not meant for this kind of approaches, because it creates so much divergence, i made the infinite loop within a gpu, each thread, thousands of threads are looping the transformations until one of them finds the target, so no CPU at all, then it stops and show the private key on the console and returns to CPU to save to a file result.txt i am still working on it speed optimization Okay, I get it, friend. I narrowed it down to puzzle 33, and when I find the target, I'll see how long it took, since we're only talking about 9 characters in the private key. Once I find 33, I'll try it again the 33 and see how long it takes a second time, and I expect very different times if there's no set sequence. And I really hope there isn't thank you |
|
|
|
The GPU part of the code is way too complex to be efficient. Consider simplifying it (a lot!) that is the point, the binary transformations involved create unique values(no repeatence, no collisions) and hit areas of the range that random or sequential may never reach, yes, its not that fast, there is trade-off, but its unique in its own way so threoretically there are multiple targets (horizontally or vertically or inversion or reversed) - hitting which automatically reveals the main private key, and i believe it could be effective and because all transformations are in binary format they are quite accurate, hitting those tiny places, that random or sequential may never reach for a better understanding i made a pc version of the same algorithm on python https://github.com/puzzleman22/Bitcoin-puzzle-transformations-CPUyes of course I realize that the range is still huge I believe that with enough computational power this method can be very effective Hello friend. Thank you for your project. I don't care how it works as long as it works I'm already testing it on 45 bits to see how long it will take, but I believe it has great promise. I'm sorry I'm poor and can't contribute, but who knows, maybe something will happen, and I will definitely remember you. Thank you. ps: can't really work with any interval other than starting with 1 to 1? |
|
|
|
My friend, I didn't mention any binary. I said that he didn't provide the source code and therefore I don't know what he used to compile VBCr.exe in the end. Since I don't want to get his source code at all, I asked if he could recompile the code he has using os.random if that's not the type of random that the executable uses Simple, friend The .exe file is a binary. I answered to the second part of your question already. Please take your time to check. So there you go...yes, the binary for direct execution (.exe) can be compiled using the source code that the author has in his possession. What part of my question that my friend didn't understand? :/ and my original question was to the author WanderingPhilosopher and he should understand what I asked him, and he is the one who must know the correct answer to what I asked him, if he can recompile the VBCR.exe with os.radom from source offcourse If VBCR.exe was compiled with os.random for key generation, then everything is fine and I don't need it to do anything. This was my question from the beginning, but I possibly explained myself badly because I neither speak nor write English. VBCR.exe uses https://en.wikipedia.org/wiki/CryptGenRandom thank you so much my friend. That's exactly what I wanted to know, what kind of random was used in VBCr.exe and in this case is more powerfull and more secure of os.random . best regards the "CryptGenRandom" is only used in the timer seed: std::string Timer::getSeed(int size) {
std::string ret;
char tmp[3];
unsigned char *buff = (unsigned char *)malloc(size);
#ifdef WIN64
HCRYPTPROV hCryptProv = NULL;
LPCSTR UserName = "KeyContainer";
if (!CryptAcquireContext(
&hCryptProv,
UserName,
NULL,
PROV_RSA_FULL,
0))
{
if (GetLastError() == NTE_BAD_KEYSET) {
if (!CryptAcquireContext(
&hCryptProv,
UserName,
NULL,
PROV_RSA_FULL,
CRYPT_NEWKEYSET)) {
printf("CryptAcquireContext(): Could not create a new key container.\n");
exit(1);
}
} else {
printf("CryptAcquireContext(): A cryptographic service handle could not be acquired.\n");
exit(1);
}
}
if (!CryptGenRandom(hCryptProv,size,buff)) {
printf("CryptGenRandom(): Error during random sequence acquisition.\n");
exit(1);
}
CryptReleaseContext(hCryptProv, 0);
#else
FILE *f = fopen("/dev/urandom","rb");
if(f==NULL) {
printf("Failed to open /dev/urandom %s\n", strerror( errno ));
exit(1);
}
if( fread(buff,1,size,f)!=size ) {
printf("Failed to read from /dev/urandom %s\n", strerror( errno ));
exit(1);
}
fclose(f);
#endif
If I recall correctly, if you are using the -bits feature the random is: if (nbit <= 64) {
bits64[0] = (uint64_t)((uint64_t)MASK64 >> (64 - nbit)) & (rndl64() | ((uint64_t)0x1UL << (nbit - 1)));
bits64[1] = 0UL;
bits64[2] = 0UL;
bits64[3] = 0UL;
bits64[4] = 0UL;
}
else if (nbit <= 128 && nbit > 64) {
bits64[0] = rndl64();
bits64[1] = (uint64_t)((uint64_t)MASK64 >> (64 - (nbit - 64))) & (rndl64() | ((uint64_t)0x1UL << (nbit - 64 - 1)));
bits64[2] = 0UL;
bits64[3] = 0UL;
bits64[4] = 0UL;
}
else if (nbit <= 192 && nbit > 128) {
bits64[0] = rndl64();
bits64[1] = rndl64();
bits64[2] = (uint64_t)((uint64_t)MASK64 >> (64 - (nbit - 64))) & (rndl64() | ((uint64_t)0x1UL << (nbit - 64 - 1)));
bits64[3] = 0UL;
bits64[4] = 0UL;
}
else if (nbit <= 256 && nbit > 192) {
bits64[0] = rndl64();
bits64[1] = rndl64();
bits64[2] = rndl64();
bits64[3] = (uint64_t)((uint64_t)MASK64 >> (64 - (nbit - 64))) & (rndl64() | ((uint64_t)0x1UL << (nbit - 64 - 1)));
bits64[4] = 0UL;
}
if not using the -bits flag then random is: uint32_t nb = nbit / 32;
uint32_t leftBit = nbit % 32;
uint32_t mask = 1;
mask = (mask << leftBit) - 1;
uint32_t i = 0;
for (; i < nb; i++) {
if (i + 1 != nb) {
bits[i] = rndl();
}
else {
bits[i] = rndl() | ((uint64_t)1 << nbit);
}
}
bits[i] = rndl() & mask;
I just want to observe the distribution around those key and the other key. Yeah I don't think anyone has found 2 private keys that transform into the same address. If they have, they aren't telling lol. I did build a script whilst being bored a few days ago to find: Hash160 truncated (65 bits): 83f1c3abb24ca603
Key A PK: 0xeedaa8fb
Key A H160: 83F1C3ABB24CA603AA19A06DA310CA91B0F00B88
Key A ADDR: 1D2f9DDCbPLifCoN4FfRF4menkJnAn7o1z
Key B PK: 0x905ad362
Key B H160: 83F1C3ABB24CA603FD94C186DF757AB0EBB4FBDD
Key B ADDR: 1D2f9DDCbPLiqWhSzdR5Ar9dv9H6kWMHGa
and then got even more bored and looked for h160 and X coord bit collisions: Priv A : 0x73376a58
Address A : 1HBciTzQvptaeMprAb2b7Rf7MLmKxgUxHB
HASH160 A : b183fc47e322f0c789fe7577464300dddbaca88d
Priv B : 0x1861323a3
Address B : 1HBciUPdv1v93jQFSkZ7uo4yrZxxZ1x6WA
HASH160 B : b183fc4e661efeeddeff8c2d9a52d1810d6ea606
X‑coord A : 40f9171f3ab73d2cb2439bac4a88f60d0db14b342b22bfe01354580299fd2dcb
X‑coord B : 40f9171939818f237426a1415c983a49a8f30b2df19a379598a794579b8f4d7e
X‑match bits : 29 (need ≥28)
H160‑match bits : 28 (need ≥28)
For my part, I am enlightened and I appreciate the explanations of how VBCr.exe works in the random key generation part. Thank you very much |
|
|
|
My friend, I didn't mention any binary. I said that he didn't provide the source code and therefore I don't know what he used to compile VBCr.exe in the end. Since I don't want to get his source code at all, I asked if he could recompile the code he has using os.random if that's not the type of random that the executable uses Simple, friend The .exe file is a binary. I answered to the second part of your question already. Please take your time to check. So there you go...yes, the binary for direct execution (.exe) can be compiled using the source code that the author has in his possession. What part of my question that my friend didn't understand? :/ and my original question was to the author WanderingPhilosopher and he should understand what I asked him, and he is the one who must know the correct answer to what I asked him, if he can recompile the VBCR.exe with os.radom from source offcourse If VBCR.exe was compiled with os.random for key generation, then everything is fine and I don't need it to do anything. This was my question from the beginning, but I possibly explained myself badly because I neither speak nor write English. VBCR.exe uses https://en.wikipedia.org/wiki/CryptGenRandomthank you so much my friend. That's exactly what I wanted to know, what kind of random was used in VBCr.exe and in this case is more powerfull and more secure of os.random . best regards |
|
|
|
My friend, I didn't mention any binary. I said that he didn't provide the source code and therefore I don't know what he used to compile VBCr.exe in the end. Since I don't want to get his source code at all, I asked if he could recompile the code he has using os.random if that's not the type of random that the executable uses Simple, friend The .exe file is a binary. I answered to the second part of your question already. Please take your time to check. So there you go...yes, the binary for direct execution (.exe) can be compiled using the source code that the author has in his possession. What part of my question that my friend didn't understand? :/ and my original question was to the author WanderingPhilosopher and he should understand what I asked him, and he is the one who must know the correct answer to what I asked him, if he can recompile the VBCR.exe with os.radom from source offcourse If VBCR.exe was compiled with os.random for key generation, then everything is fine and I don't need it to do anything. This was my question from the beginning, but I possibly explained myself badly because I neither speak nor write English. |
|
|
|
I still don't fully understand — if a low-bit privkey public key is exposed, how could someone potentially derive the private key from it? Could someone please explain how that's possible?
Brute-forcing using the public key is much cheaper than brute-forcing using an address only. if he didn't use it, he could go back and compile an .exe with o.random. This is not how development works. You can't just "compile a binary" after sticking "o.random" somewhere and expecting it to work. My friend, I didn't mention any binary. I said that he didn't provide the source code and therefore I don't know what he used to compile VBCr.exe in the end. Since I don't want to get his source code at all, I asked if he could recompile the code he has using os.random if that's not the type of random that the executable uses Simple, friend |
|
|
|
Taking advantage of wallets 71 and 72, I'd like to ask WanderingPhilosopher - author of VBCR.exe - if he could release a compilation of the executable but with os.random, if he hasn't used this type of random. Is that possible, friend?
It does not look like it's using Python. Most likely it's C++ with CUDA. At least, the Linux version uses /dev/urandom, so most likely the Win binary is doing something similar. Since his source code isn't available on GitHub, I don't know what he uses, but it must be C++ and Cuda. But if he uses o.random, then random character generation is fine. That's why I asked if, if he didn't use it, he could go back and compile an .exe with os.random. |
|
|
|
|
Taking advantage of wallets 71 and 72, I'd like to ask WanderingPhilosopher - author of VBCR.exe - if he could release a compilation of the executable but with os.random, if he hasn't used this type of random. Is that possible, friend?
for 18 characters
import os
random_bytes = os.urandom(9)
random_hex = random_bytes.hex().upper()
print(random_hex)
Thank you very much
|
|
|
|
1PWo3JeB9jrGLDTmsp45h1pDXXtb7zisQH
start with 79B
Why does everyone keep trying to solve it? I think this is a game that benefits others, not the solvers!! When more inventory was added to these puzzles, each Bitcoin was worth about $27,000. Have any of you thought about why the finder of puzzle 69 lost inventory? Let me remind you of a few principles: Bitcoin can only consider a transaction as completed after receiving 6 confirmations in the next blocks in the blockchain network chain, and before 6 confirmations, that asset is not in your possession, and the block containing the transaction confirmed by miners may be completely removed from the blockchain chain before reaching 6 confirmations, which are called orphan blocks. lost because he used the mempool instead of Mara. Big mistake when it's already been discussed here on how to avoid losing those funds. Although using a private mining pool instead of a public one can prevent RBF, but who can guarantee that the private mining pool will not embezzle the money? This is not difficult at all technically. Normal transfers with high fees may still have a chance of success, but if they cheat through a private mining pool, you will never get your property back. I think the decentralization of Bitcoin does not allow you to hand over transactions to private mining pools. And I have not seen any evidence that No. 67 and 68 were successfully transferred through Mara. If you have any questions, why dont you try Mara by yourself? Ill make myself clear: im not specialist in bitcoin not even in coding. But I already have tested Mara and it`ll worked out in the end. At no time in this process the private key is revealed, you only need a hex of a signed transaction which contains just numbers, and past it in Mara. I dont see how they could get the private key and trick you leaving you with nothing. I could be talking bullshit since im not an expert about all of this, Im just talking about what I did and tested with 5 dolars. If I'm not thinking incorrectly, the assumption or theory behind not trusting MARA is entirely based on the hex of a signed transaction, the idea that someone there, whether it's the miner or someone else, could access the public key information before anyone else and, thinking "well, this is a Bitcoin puzzle anyway," could take the entire amount for themselves. There only 2 way. Collusion inside 😅. Or setup huge mount of miner at mara pool and hope lucky the public key pass to your miner .. But why .. .. better to find way to solve it 🙃😅 If it fail trough mara , then mara reputation will fall i think. Cause the solver will surely go bonker 🙃 My discussion is not about attacking or removing confirmed blocks for profit; it is about why some puzzles - whose existence is recorded at the time of their creation - become very valuable and popular, but when these puzzles are solved, the rewards are not distributed to the solvers and are stolen? The answer is quite clear: we all know that it is completely ridiculous and illogical to believe that bots can obtain the private key in a very short time, given the public key. The only logical and 100% probable case is that those bots already have that key before you yourself have access to your private key. "Yes, of course the number of these bots is the same as the number of puzzles left. These bots all have the keys to the puzzles and are designed to monitor and investigate unsolved Bitcoin puzzles and monitor Bitcoin transactions across the blockchain. If you have access to a full node on the Bitcoin network, you can examine the transactions associated with orphaned blocks at the time and date of previous puzzle solutions and see how many of these thefts occurred there." Summoning KtimesG and nomachine. Let see their comment 😅🙏 And by the way, everyone knows that our company has a lot of computing power and cannot solve the puzzles in a very short time. So, have you ever wondered why it didn't do this? In the news and reports about our company's monthly income, it is stated that last month the company's net income was 900 bitcoins. In your opinion, why doesn't our company solve these puzzles so that it can earn more income than the previous month? I am Iranian and I translate texts using Google Translate, and if there is a mistake in the writing, I am not to blame. Cause for puzzle 71 it is gamble. Cost of bruting the entire puzzle is more than the prize in current technology. thats my opinion. What if we send the transaction with Wasabi Wallet? Can bots still hack it? Does anyone have experience with it? The secret to all this is that the wallets are low bits, and the important thing is that the public key doesn't become public before you receive the funds in your new wallet. That's all. Don't make the public key public |
|
|
|
1PWo3JeB9jrGLDTmsp45h1pDXXtb7zisQH
start with 79B
Why does everyone keep trying to solve it? I think this is a game that benefits others, not the solvers!! When more inventory was added to these puzzles, each Bitcoin was worth about $27,000. Have any of you thought about why the finder of puzzle 69 lost inventory? Let me remind you of a few principles: Bitcoin can only consider a transaction as completed after receiving 6 confirmations in the next blocks in the blockchain network chain, and before 6 confirmations, that asset is not in your possession, and the block containing the transaction confirmed by miners may be completely removed from the blockchain chain before reaching 6 confirmations, which are called orphan blocks. lost because he used the mempool instead of Mara. Big mistake when it's already been discussed here on how to avoid losing those funds. |
|
|
|
at 1 bilion keys/s all range 4000000000000000000 to 500000000000000000 takes 12 years to scan it takes 24 years to scan if it is up to 5ffffffffffffffffff I think you mean 9359 years. Unless of course the non-n00bz manage to break the hardware limitations via a combination of ideas and proper techniques (the 27th time's the charm) and crack open the lame mathematical limitations of the last 30 years..Or is it maybe of the last 5000 years? Or maybe since forever, and forever? I know that in sequential mode we need almost 100k (maybe 92k enough hahahaah ) GPU 5090 at 10GKeys/s to scan all 400000000000000000:7fffffffffffffffff in 30 days |
|
|
|
Thank you bro i will try DID ANYONE FINISH 400000000000000000 TO 500000000000000000 I UNDERSTAND THIS IS I COMPETITION BUT WE ARE ALL IN 000000000000000000000000000000000000000000000052674A80FE35EEBF15 TO 000000000000000000000000000000000000000000000052674CA3107FFE5E53 =  0000000000000000000000000000000000000000000000639DDDD954B03AF084 TO 0000000000000000000000000000000000000000000000639DDFFB66FA4A8FC2 = I WILL SHARE MORE ONCE THEY FINISH THE SEARCH at 1 bilion keys/s all range 4000000000000000000 to 500000000000000000 takes 12 years to scan it takes 24 years to scan if it is up to 5ffffffffffffffffff |
|
|
|
lol i start searching today,using 4 Nvidia L4 each scanning at 335 m/k x to 312 m/k x sec is all about lucky? But i believe the key is around 7............ why because Puzzle 70 was done in 2019-06-09 and since then nobody have find the key for 71 how many people have being scanning for key 71 since 2019-06-09 so must be around 6....... or 7............ what do you guys think? because nobody has scanned for 71 until 69 was found 70 was found because the pubkey was intentional leaked.. but the latest found was 69 That’s not true. I’ve been working on Puzzle 73 for months and have scanned everything up to prefix 14 from 1000000000000000000 to 14fffffffffffffffff. Higher puzzles like 71+ are absolutely being searched, even if they haven’t been solved yet. comme on ) how long and what power did you scan from 10 to 14.. for puzzle 73 ) You know how it goes, share too many details and in 2 minutes someone calls you a liar anyway 😉 Let’s just say it took time, decent firepower, and good software. If you know, you know. liar or no liar you wrote you been working on puzzle 73 for months and scanned EVERYTHING from 10... to 14... witch i think is bigger than puzzle 71 range so .... no need to continue 10 to 14 ? still missing 15 to 1F |
|
|
|
I use this at 1000mk/s with my 3060 but so far without success |
|
|
|
|
Great speed but dont have range Start and End.
|
|
|
|
Imagine you're trying to find a single specific grain of sand on all the beaches on Earth. There are about 2^62 to 2^63 grains of sand on all beaches combined. Puzzle 71 is like trying to find not just one grain, but a Puzzle 71 (2^70) = 157.4x Earth's sand. Even if you could check a billion grains every second, it would take you thousands of years to go through them all.  What if it is puzzle 135 and we know the public key?  The eternity of 135 is the same as that of 130. Either everything is not explained, or eternity does not apply to the author of the discovery of the key to 130 |
|
|
|
|
