Bitcoin puzzle transaction ~32 BTC prize to who solves it

[citb0in]

No 100 USD man, just the minimum possible account you can send. Let's say 0.0001 BTC. Send 0.0001 BTC to 1C8uD9G4AGQas5sG15869p5B1mrF3RELY3 and choose an appropriate fee that is ok for you, 145 sat/vB ? By this the mentioned address that is controlled by me should be funded soon. As soon as this RBF-challenge address is funded I will generate the outgoing transaction with 1sat/vB, so it will take forever to be executed. This means the potential attacker has huge time available to redirect the transaction to his address of choice and keep the coins.

We're just gonna simulate if and how a bad boy could make such an attack to the real puzzle 66 (67, 68 ...) hit

[3dmlib]

No 100 USD man, just the minimum possible account you can send. Let's say 0.0001 BTC. Send 0.0001 BTC to 1C8uD9G4AGQas5sG15869p5B1mrF3RELY3 and choose an appropriate fee that is ok for you, 145 sat/vB ? By this the mentioned address that is controlled by me should be funded soon. As soon as this RBF-challenge address is funded I will generate the outgoing transaction with 1sat/vB, so it will take forever to be executed. This means the potential attacker has huge time available to redirect the transaction to his address of choice and keep the coins.

We're just gonna simulate if and how a bad boy could make such an attack to the real puzzle 66 (67, 68 ...) hit

I think it will be more interesting to attacker get 100 usd, not 0.0001 btc
Can I do it on my own address and post private key here?

[citb0in]

did you really understand what this RBF-challenge is all about?

[3dmlib]

did you really understand what this RBF-challenge is all about?

Yes. I'll find puzzle 66 in a next few months and I don't want to be my money be stolen on transaction

[citb0in]

perfect, so you're on the right path 

[mabdlmonem]

Good luck....

awesome ! I have some cuda functions for Point add and Point Mult, and a basic script working but I need to fix it, sometimes it works and sometimes not...

Code:

[DEV: NVIDIA GeForce G 1111/4095MB] [00000000000000000000000000000000000000000000000000022004DA800000 (50 bit) 
[DEV: NVIDIA GeForce G 1111/4095MB] [000000000000000000000000000000000000000000000000000222B60D800000 (50 bit) 
[DEV: NVIDIA GeForce G 1111/4095MB] [0000000000000000000000000000000000000000000000000002256266000000 (50 bit) 
[DEV: NVIDIA GeForce G 1111/4095MB] [0000000000000000000000000000000000000000000000000002281873800000 (50 bit) 
[DEV: NVIDIA GeForce G 1111/4095MB] [00000000000000000000000000000000000000000000000000022AC9A6800000 (50 bit)
[TARGET: 1] [SPEED: 1632701.66 MKey/s] [TOTAL: 48,937,041,920] [00:05:18]
[2023-11-23.11:08:30] [Info] Found key for address '1MEzite4ReNuWaL5Ds17ePKt2dCxWEofwk'. Written to 'found.txt'

[2023-11-23.11:08:30] [Info] No targets remaining

found the #50 in 5 minutes...

could you please share the code ? its intresting

[arulbero]

So you are claiming that any Bitcoin transaction could be double-spended and therefore all Bitcoin transactions are insecure. Makes sense ?

What do you think of a challenge? I transfer an amount of x coins, you only know the source address, which I will publish here. Its private key will be in the range of 66bit just like the mentioned puzzle. Then you siphon off the coins and transfer them to another address before I receive them just like you described the looter would. If the coins end up at your freely chosen address, you can keep them. If they end up with me, you have lost and made a fool of yourself. Deal ?


@Legends_Never_Die
So what's about the RBF-challenge, deal or no deal?
I generate an address with a 66bit private key and send a few coins to it. Then I create a transaction to send the entire contents of this wallet address to any other address. I will explicitly set 1 sat/vB as the fee so that the transaction can stay in the blockchain forever. Now you (or someone else if you like) try to cancel this outgoing transaction and thus simulate a mallory sucker that wants to withdraw the coins. As the transaction has the minimum fee you have all the time that you need.

As the fees are currently very high, I am unfortunately unable to send coins to the RBF-challenge address. If anyone is interested in this RBF-challenge and would like to sponsor some minimum amount of satoshis, here is the wallet address:
1C8uD9G4AGQas5sG15869p5B1mrF3RELY3

I own the private key of this address

The sha256 of the privkey is:
6297b7a9a38985d967e9d5603ba5e4f133b0e8a998219f29c4029aa03601110b

Using a 66-bit private key is like make a transaction, and few seconds after make the private private key "public".

Retrieving such private key from a public key is matter of seconds with a GPU.

A suggestion for your challenge:

1) choose an address where you have already a few satoshi

2) make a tx with fee = 1 satoshi from this address

3) public here a range of 2^66 range in which your private keys is

It is the same challenge, but you save a tx.

[Woz2000]

The attacker will not get $100USD. Most of it will go to the miners in fees. Save your money, I know you have more than you need  but no point wasting it, save it for another day or donate it to someone in need. It is the holidays!   

No 100 USD man, just the minimum possible account you can send. Let's say 0.0001 BTC. Send 0.0001 BTC to 1C8uD9G4AGQas5sG15869p5B1mrF3RELY3 and choose an appropriate fee that is ok for you, 145 sat/vB ? By this the mentioned address that is controlled by me should be funded soon. As soon as this RBF-challenge address is funded I will generate the outgoing transaction with 1sat/vB, so it will take forever to be executed. This means the potential attacker has huge time available to redirect the transaction to his address of choice and keep the coins.

We're just gonna simulate if and how a bad boy could make such an attack to the real puzzle 66 (67, 68 ...) hit

I think it will be more interesting to attacker get 100 usd, not 0.0001 btc
Can I do it on my own address and post private key here?

[mcdouglasx]

No 100 USD man, just the minimum possible account you can send. Let's say 0.0001 BTC. Send 0.0001 BTC to 1C8uD9G4AGQas5sG15869p5B1mrF3RELY3 and choose an appropriate fee that is ok for you, 145 sat/vB ? By this the mentioned address that is controlled by me should be funded soon. As soon as this RBF-challenge address is funded I will generate the outgoing transaction with 1sat/vB, so it will take forever to be executed. This means the potential attacker has huge time available to redirect the transaction to his address of choice and keep the coins.

We're just gonna simulate if and how a bad boy could make such an attack to the real puzzle 66 (67, 68 ...) hit

I think it will be more interesting to attacker get 100 usd, not 0.0001 btc
Can I do it on my own address and post private key here?

I don't see the challenge in RBF, donate it to the kangaroo or keyhunt project, this is giving more money to the miners.

[3dmlib]

No 100 USD man, just the minimum possible account you can send. Let's say 0.0001 BTC. Send 0.0001 BTC to 1C8uD9G4AGQas5sG15869p5B1mrF3RELY3 and choose an appropriate fee that is ok for you, 145 sat/vB ? By this the mentioned address that is controlled by me should be funded soon. As soon as this RBF-challenge address is funded I will generate the outgoing transaction with 1sat/vB, so it will take forever to be executed. This means the potential attacker has huge time available to redirect the transaction to his address of choice and keep the coins.

We're just gonna simulate if and how a bad boy could make such an attack to the real puzzle 66 (67, 68 ...) hit

I think it will be more interesting to attacker get 100 usd, not 0.0001 btc
Can I do it on my own address and post private key here?

I don't see the challenge in RBF, donate it to the kangaroo or keyhunt project, this is giving more money to the miners.

But if address balance is low attacker cannot make a transaction, because address balance should be more than current transaction fee...

If I did it right then 1PbL9QGg5fqRHmFXEBNBkey6Atp6SkWnFw address should have stuck transaction now.

After what time it will be usually dropped from mempool if not processed?

[mcdouglasx]

After what time it will be usually dropped from mempool if not processed?

48 hours

[AlanJohnson]

So for the sake of my safety and the safety of my loved ones, I resign from actively trying to break elliptic curve cryptography.

Oh, thank you my lord ! Now elliptic curve cryptography will remain safe.

Seriously now : you are a funny guy.

[CryptoMaster84]

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?

[lordfrs]

^{Message: This address was exclusively generated for the RBF-challenge <https://bitcointalk.org/index.php?topic=1306983.msg63398077#msg63398077> and I have the private key of this address. citb0in, 2023-12-27
Address: 1C8uD9G4AGQas5sG15869p5B1mrF3RELY3
Signature: IAMmKuX5C2Z97eCSjYjfAN49hApXTk2LcMLzHWUp/vYYTxmKsHGaUdc7KQRFilTHUyqiEGt0B3NFqanjcgWl/Fg=}

Pubkey can be calculated with the information you provide and it takes a few seconds to find the private key. Because you said it was in the 66 bit range. I think you should not send coins to this wallet.

[alek76]

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

[nomachine]

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.

[alek76]

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.

That's right, that's the limit. It can speed up by about 6.3%. If spin rotation is used. I don’t know what can be optimized in the GPU anymore. Everything is clear there. This is absolutely a normal increase in speed. Every percent is worth it, especially in GPUs.

[CryptoMaster84]

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.

Sorry mate but you don't seem to understand what I asked, read again my post.

[alek76]

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.

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
It is not entirely clear what you want to increase further. This is the limit

[CryptoMaster84]

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

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.

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
It is not entirely clear what you want to increase further. This is the limit

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 even with 16 x RTX 4090, I get only 76.8Gk/s, is useless to scan at this speed the 66 puzzle.