Bitcoin Forum
June 22, 2024, 04:06:24 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: [1]
1  Bitcoin / Development & Technical Discussion / Re: Pollard's kangaroo ECDLP solver on: January 21, 2024, 09:05:09 AM
Yes, I described the brute force approach on the entire range like I mentioned from the start just to give an idea of the magnitude of the scanning process.

I didn't know how Kangaroo works. (I admit, I didn't used it, just compiled once last year to see how it works, but quit using it, as I was involved only in puzzle 66).

Now after I read something on JLP Kangaroo's readme on github and how it works , you are right, but still requires enough power to do 2^66.05 operations per second, that's ~ 750 GK/s, so you still need 100 x RTX 4090 to maximize your chances to find it faster than anyone else, but that's a serious env which costs goes over the benefits if you do not find it in 2 Months or less.



but I had tweaked the way DPs were found.

Can we have your code?

+1 on this, can we see at least the logic you used, if you do not want to share your work you used to change that, perhaps a code snippet?

And did you reached that speed without anyother change? Going from 2500Mk/s to almost 7750Mk/s is something.

Also I do not see in any class from the JLP Kangarroo the use of GPUGroup.h, is that generated separately or it was migrated from VanitySearch and keept in the project?

Why the use of only 128 in GPU_GRP_SIZE as in KeyHuntCuda was 2048?

What's the relation between this constants?

Code:
// Number of random jumps
// Max 512 for the GPU
#define NB_JUMP 32

// GPU group size
#define GPU_GRP_SIZE 128

// GPU number of run per kernel call
#define NB_RUN 64
2  Bitcoin / Development & Technical Discussion / Re: Pollard's kangaroo ECDLP solver on: January 20, 2024, 09:35:22 PM
I do not want to be offtopic, but guys did you calculated what computing speed is required to scan the entire range of 130 puzzle?

For the range: 200000000000000000000000000000000:3ffffffffffffffffffffffffffffffff, which have: 680564733841876926926749214863536422912 total keys to scan, on a speed of 100 YottaK/s it would take almost 215657 years to finish  Grin

Not to mention that the highest reported speed on a single 4090 was only 7-8Gk/s .

So is there something that I miss, why you still bother to scan beyond 125?

I mean even if you change the bit range to scan to 160 bit range, is still impossible with the current gpu's, maybe with photonic gpu's we might have a chance.
3  Bitcoin / Bitcoin Discussion / Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it on: December 30, 2023, 12:25:31 PM
...
Yes, I understood your idea. But there is 1 fact. When adding a point with even private keys and then adding them, the Y coordinate can be either even or odd. If you filter in getGPUStartingKeys(), I think that after 1 addition the result can be anything.

Yeah you're right, damn it. I guess that's it, we reached a limit.
Thank you again for the responses.
4  Bitcoin / Bitcoin Discussion / Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it on: December 30, 2023, 10:12:44 AM
Any ideas?
How do you know if Point X prefix = 02?
you can do this:
Code:
if (isOdd == 0) { //  02
    _GetHash160Comp(px, isOdd, (uint8_t *)h);
    CHECK_POINT(h, incr, 0, true);
}

In addition, you will have to calculate the Y coordinate when adding points. Look at my mod 12. I removed everything unnecessary there in GPU.
And I changed the conditions in GPUEngine.cu - the ComputeKeys() code is executed. But ComputeKeysComp() is not executed - for the reason that the Y coordinate is needed.
It was measured that it is more profitable to add the Y coordinate than to calculate Ripemd160 2 times.
Everything has already been checked, you can only add a condition. Or loop using Spin. So I gained 6.3% in speed. #define NB_SPIN 32
You also need to change the increment index multiplied by the number of Spin rotations and  add Load256(sx, px); Load256(sy, py);
Post the code and I'll check it Smiley


Thank you for your input, but I think you miss the point where I asked about processing only the expected public keys from the start. Your proposed solution is equal to my second attempt on _GetHash160Comp function.

Let me give you a scenario so you would understand what I mean.

Let's assume the priv key 66 bit range:  3fa62700000000000:3fa627fffffffffff , so you will have to scan ~ 17592186044416 private keys, generate a public key for each key, right? Now let's assume for the sake of the argument that priv key is at 75% of the end of the keyspace and the public key which generates the hashing to obtain the btc adresss starts with "02b7" (the compressed key is: 02b79ba3ab8ca1fd1399e27ce5bf337819ba34320653c7528084a6b52118c17b86).

Now, let's assume that there's an equal parity after you compute all the public keys from the priv key range with pubkeys that start with 02 or 03 and based on that filter from the start 50% of the keys your are not storing anymore and store/load only what you want? Theoretically you will compute less key, therefore the speed should be double.

getGPUStartingKeys code:

Code:
        int prefix02Count = 0;  // Counter for keys starting with '02' //for debug only
        int prefix03Count = 0;  // Counter for keys starting with '03' //for debug only        

for (int i = 0; i < nbThread; i++) {

tRangeEnd2.Set(&tRangeStart2);
tRangeEnd2.Add(&tRangeDiff);

if (rKey <= 0)
keys[i].Set(&tRangeStart2);
else
keys[i].Rand(&tRangeEnd2);

tRangeStart2.Add(&tRangeDiff);

Int k(keys + i);
k.Add((uint64_t)(groupSize / 2)); // Starting key is at the middle of the group
//p[i] = secp->ComputePublicKey(&k); //here we compute the public keys from the priv keys and store them in the p array
                
Point pubKey = secp->ComputePublicKey(&k);  // Compute the public key

// Extract compressed public key bytes
unsigned char publicKeyBytes[33];
secp->GetPubKeyBytes(true, pubKey, publicKeyBytes);

                // Check the prefix of the public key
                if (publicKeyBytes[0] == 0x02) {
                      prefix02Count++;
                      p[i] = pubKey; // here we store in the array only the keys we want
                      //std::string pubKeyAddr = secp->GetPublicKeyHex(true, p[i]);
                      //printf("Public key %d: %s\n", i, pubKeyAddr.c_str()); //for debuging
                } else if (publicKeyBytes[0] == 0x03) {
                      prefix03Count++;
                }

}
        // Calculate percentages
        //double totalKeys = nbThread; //for debug only
        //double percentage02 = (prefix02Count / totalKeys) * 100.0;
        //double percentage03 = (prefix03Count / totalKeys) * 100.0;

//printf("Total number of keys generated: %d\n", nbThread);
        //printf("Percentage of keys starting with '02': %.2f%%\n", percentage02);
        //printf("Percentage of keys starting with '03': %.2f%%\n", percentage03);


FinKeyGPU code:
Code:
...
getGPUStartingKeys(tRangeStart, tRangeEnd, g->GetGroupSize(), nbThread, keys, p);
ok = g->SetKeys(p); //will set only the keys we stored in p
....



How do you know if PubKey prefix = 02?

I think it's a waste of time to guess whether it's 02 or 03 prefix. Whatever the script is, it must pass all the private keys. It is impossible to accelerate this way. It can be filtered, but filtering is not acceleration. Grin

Sorry mate but you don't seem to understand what I asked, read again my post.
I started studying this program in 2020. Now I will try to explain to you what you are doing wrong.
1. In the getGPUStartingKeys function, it forms an array of points with X and Y coordinates. In this function, you do not need to check them for compliance with the prefixes 02 and 03. Because later in the GPU code, when adding any point to the coordinates generated in this function, the new points will be with the prefixes 03 (not even Y). You won't even know it. You need to filter specifically in the GPU code. For this reason, you won't be able to add new cmd argument.
2. There is no need to reduce nbThread > filtredKeys by 50%, the remaining threads are filled with zeros. The entire Points p array must be transferred to the GPU.
I suggested that you check in the GPU code for the parity of the Y coordinate. uint8_t isOdd = (uint8_t)(py[0] & 1); It's simple Smiley
It is not entirely clear what you want to increase further. This is the limit Smiley

I know that piece of code: uint8_t isOdd = (uint8_t)(py[0] & 1), depending on the parity of Y coordinate if 0 is then the parity will be even and if 1 then it will be odd and it will serve on this line when permutation is done: publicKeyBytes[0] = __byte_perm(x32[7], 0x2 + isOdd, 0x4321);

What I want to increase further, speed of computation Smiley even with 16 x RTX 4090, I get only 76.8Gk/s, is useless to scan at this speed the 66 puzzle.
5  Bitcoin / Bitcoin Discussion / Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it on: December 30, 2023, 09:05:52 AM
How do you know if PubKey prefix = 02?

I think it's a waste of time to guess whether it's 02 or 03 prefix. Whatever the script is, it must pass all the private keys. It is impossible to accelerate this way. It can be filtered, but filtering is not acceleration. Grin

Sorry mate but you don't seem to understand what I asked, read again my post.
6  Bitcoin / Bitcoin Discussion / Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it on: December 29, 2023, 06:08:02 PM
Hello guys, I've been working lately on the @WanderingPhilosopher KeyHuntCudaClient version, stripped everything to keep only the single address search mode for the sake of searching puzzle 66 only.

Now the problem, as usual, no mater what ideas I try, there's no possibility to adapt it to what I want to increase the speed.

Without this set of controlling the public keys too to reduce the search complexity is not possible with the current resources, even if we know the priv key ranges.

For e.g. now I tried to modify the getGPUStartingKeys function, on the part where the keys are computed, to compute only the pub keys with the expected prefix, let's say 02 and save them to the p array instead of computing everything and store there.
Normaly this a good thing because you reduce almost 50% of keys, but as nbThread > filtredKeys, the rest of the threads are filled with zeros and I end up processing that garbage too when setKeys is called, so not a solution, even if I force the nbThread = filtredKeys.

Maybe the _GetHash160Comp I said, to filter there the keys just before the SHA256Initialize(s); an if condition to check if (publicKeyBytes[0] & 0xFF) != 0x02, to return early, otherwise to process.

The reason of considering this is as you know hash160 transformation is an expensive process, like the _ModInvGrouped from ComputeKeysSEARCH_MODE_SA and it that way I wanted to save processing.

Oh and the final goal was to have a new cmd argument defined as --pubKeyStartsWith to control the key, only the expected prefix and maybe the second byte, let' say --pubKeyStartsWith "02b7", I think that search will be more refined.

Any ideas?
7  Economy / Marketplace / Re: Don't buy "wallet.dat" files with lost passwords. EXCHANGE THEM! on: April 14, 2023, 09:46:26 AM
The wallet that circulates on internet with 362BTC and file size ~ 700 - 770KB it's fake:

Code:
Balance = 362.00495819 BTC. (Main Bitcoin Address: 1Jkn9wg1WbJdASNBPtQqdmm7wtrcSiATbf). (With recent outgoing transaction. UNDER WATCH.)

, the wallet is forged.

Tried to unlock the wallet with the cracked hash password and obviously received the error:
Code:
"some keys decrypt but not all. Your wallet may be corrupt"

Ok, tried to get it through pywallet and after the dump of privkey, discovered the sec of the address:
Code:
1Jkn9wg1WbJdASNBPtQqdmm7wtrcSiATbf
which of course after was imported in a electrum wallet, nothing, empty.

So the moral of the story is this, it was a fun experience, but the thing is that whenever you receive/find by accident or buy a wallet.dat file and the size is less < 500KB, not always the case and not to mentions recent transactions sent to a "supposedly" lost wallet [...] anyway, an old wallet with many transactions must have at least 1MB of data size, if it's otherwise then probably you got scammed or fooled.
8  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN] Lytix - PoS Maxnode Data API Crypto Platform on: September 04, 2019, 04:17:03 PM

The more you survive in this crypto world, the more you start considering it a "big charade"... The thriving projects are those who have nothing to offer and they are 100% rolling on pure "hype", no real development, no real product or use case (not even a plan to put up one)...

Those coins with crazy volumes are most probably some wash trading bots and/or the project owner injecting money, buying his own coin to make some volume and gain visibility.


Exactly, obviously you can do washed trading if you had money from scammy ICO or sold masternodes with 20k-30k in advance, you have money to pay services and make it look the biggest and promissing project Grin , but like I said, people don't learn from past, are lured by this ingenious scammers and when they realise is too late, well ... we all know the outcomes, the consequnces, sometimes tragic ones.

Rarely, you see a person ask in chat groups about the whitepaper and project purpose or technical goals that team what to achieve and currently working, good sense questions after all ..... only what price it's, if it's minable, on what exchanges is selling listed.

Seriously, that's all what blockchain is, gambling and speculations about cryptocurrency value?
9  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN] Lytix - PoS Maxnode Data API Crypto Platform on: September 01, 2019, 08:07:57 AM
Funny thing how it works in this weird cryptoworld, I just saw a new copy paste project(a pivx fork) on crex24 with the highest volume traded, with 6 commits only (almost all non-related to code), their wallet still have some pivx icons not even changed  Cheesy

Also the site is how it is and people buy like crazies,with no questions related to development and product.

The thing is the following, I have nothing against the developer who uses this fork ... but I have with people who didn't learned from past mistakes, how on earth you buy a coin which clearly shows that is not even polished, still with elements from the original pivx wallet not even changed and you don't ask yourself about it, if it's a genuine project or a scam?

Lytix is also a pivx fork but with serious development, 721 commits and a serious product in development, but with almost no support for paying services, exchanges listing .. no matter what we proposed and achieved, it's fucking insane in comparison with what others provide and they trade their coins at 10000-20000 sats and we barely situate above 35 sats?

I don't know what else to say, I'm perplexed.
10  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN] Lytix - PoS Maxnode Data API Crypto Platform on: August 25, 2019, 07:05:58 AM
It's hard to believe this days which are the trusted source, everyone is accused of trading manipulation .... Binance, Bittrex starts loosing credibility, not to mention that there are hundreds of exchanges which battle for volume to attract new buyers, honestly I would love to see more DEX integrated into wallets with FIAT pay possibility, so they are ruled out of this bad practices and companies who created the cryptocurrencies to start winning instead of them, this middle-mans are like banks, crypto should never be like this, otherwise what's the difference between the old system and the new one.
11  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN] Lytix - PoS Maxnode Data API Crypto Platform on: August 22, 2019, 03:32:23 PM
There's no wonder this days, they say that they support little projects to grow up, but they disqualify exactly this kind of projects.

Ofcourse, they have a team to decide, nothing wrong with that, but we selected this exchange exactly for their name as a trustable name, to show that Lytix is a little project, but with a legit team who wants to be listed on a trusted exchange.

We didn't selected the exchange for the volume or for another things, right now Bittrex adjusted volume is only 24,242,199$ and place 72, even YoBit is on 70 ,which is kinda sad if you ask me.
12  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN] Lytix - PoS Maxnode Data API Crypto Platform on: April 30, 2019, 04:17:00 PM
Lytix is a little project but with great community and community driven, which reminds me of bitcoin old days.
There's no ICO money, masternode pre-sales or super-duper partnerships ... and is not aiming to provide impossible achievements only on whitepapers.
Yes, it's a PIVX fork but why reinventing the wheel if the base code is available?
Many projects derived from the original bitcoin code and they are doing quite well actualy.
The development of this project is going forward and soon the coin purpose will became reality, with maxnodes.

Maxnodes are like super nodes and are used only for managing the transactions on the 2nd layer network and will hold the open APIs that entities will be able to use to store data, decisions, or any other configurable items into the blockchain.

Maxnodes infrastructure will open the door for Enterprises to use the blockchain as an immutable storage layer for decisions, data, or whatever they desire to save costs and control the security of the stored data with the private key they hold.

A possible purpose:
a solution for banks to store GDPR data which can be stored off-chain.

Storage is more secure and having cheap storage transactions, instead of paying alot more for similar solutions (cloud data storage) is a big selling point for this project.

Hope to see more progress next month from faetos, the main developer of the project, when we can see some tangible results and maxnode test network up, so we can bend up the maxnodes for other possible solutions.

13  Alternate cryptocurrencies / Tokens (Altcoins) / Re: 🇨🇭🚀[ANN] [ICO] LAPO - DECENTRALIZED FINANCE REINVENTED. Whitelist Bonus! on: January 02, 2019, 09:56:14 AM
As you know starting from December 2018 LAPO has 2 mining pools, therefore here they are:

Official LAPO GPU Mining Pool

http://pool.lapo.io

Details: no mining fee, only NVIDIA GPU mining

--------------

CustomSpeedPool

http://pool.customspeed.nl


Details:


- mining fee 2.5%
- NVIDIA GPU mining
- Linux optimized cpuminer available for cpu mining (built by the pool dev)
- Windows optimized CPU miner (built by the pool dev)
- soon Linux AMD GPU miner for RX and VEGA (built by the pool dev)


Pages: [1]
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!