Topic: Bitcoin puzzle transaction ~32 BTC prize to who solves it - page 127. (Read 230098 times)

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

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.

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.

How do you know if Point X prefix = 02?
you can do this:

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

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.

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?

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

Seriously now : you are a funny guy.

48 hours

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?

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

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!   

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.

could you please share the code ? its intresting

perfect, so you're on the right path 

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

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

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?

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'm interested. I can do.
Do I need to place some low free transaction with RBF off with 100usd on it and say everybody a private key? Yes?
And we'll see if transaction can be modified with RBF flag off? Yes?

Please fund your challenges or don't have a challenge.
Miners decide which transaction to include in blocks and any serious miner will chose those with the highest fees. So I don't see why we need such challenge.