Because, just like individual or pool puzzle mining, they would lose money, not earn a profit.

This is what happens when the expected costs are higher than the expected returns.

I addressed this issue some long time ago. In a nutshell, there is no need to probabilistically minimize bad coding, it is enough to validate the results of some range, using a second ground-truth validation run, which is guaranteed 100% to be valid. For example, testing some random range both on the GPU, and on the CPU (using a stable implementation, like libsecp256k1), and comparing some hash of all the results.

If the hash matches, and all GPU models are tested properly, then everything went OK and the GPU code is thus reliable.

I would never, ever, ever, EVER have blind trust on some anonymous code which lacks basic testing scenarios, especially more so if that code is supposed to be run billions of times in a row. The only result is what happened here, which can be painful.

Yeah, but you're not doing N = 1, it's more like N = 24 for every 36 additions. The ratio doesn't slowly go from 1 to 1.16, it's pretty rapid.

Anyway, I'm not a mathematician so I'll let the big guys decide what's what, if they ever get to do a proper analysis. FWIW, the analysis of the similar BSGS block inversion does what I did: ignores the inversion costs, reduces cost of every 2 group ops into something slightly above 1, and arriving at a sub-unitary "k" because of all that. You might say that N can't go big, but that only depends on the implementation. But it's OK...

Please brag about these everyday accomplishments on your next tech interview (make sure you have your AI/ML techy girlfriend online during that). In the real world, my gut feeling is telling me that you wouldn't be able to write a backtracking algorithm using non-recursive calls even if I give you a month to do it. It's clear that you don't have the smallest idea about the intricacies of the things you are talking about.

You are right. If the inversion cost is not zero, then k should be multiplied straight up by 1.5 instead of 1.16, because k would not have any practical meaning anymore, as there's nothing relative to compare it against. I was offering the asymptotic minimum value to correct the O(), for a free inversion.

Or are you applying double standards, and in the case that INV takes an infinite amount of time, it doesn't matter whether you do one group op, two ops, or 9999999 ops?

if you built those things in 1 week, and also had time to read how to do them, then I'm Jesus from Nazareth. Let me save your soul: a person who can do that does not exist, and if they would exist, they would pretty much earn many times the entire combined BTC value of all the puzzles.

I understand that. My point was that the entire complexity order is expressed in group operations, hence that "k", whatever value it has, needs to be multiplied by ~ 1.16 to bring it into the correct complexity order class, otherwise we're comparing apples to oranges.

I'm sorry but the author of that "paper" must have been on crack. My IQ dropped to -170 after reading through all of that BS. He should maybe stick to management science instead of trying to break crypto.

Let's look closer to the point addition formula:

m = (y1 - y2) / (x1 - x2)
x3 = m**2 - x1 - x2
y3 = m*(x2 - x3) - y2

One inversion, two MUL, 1 SQR, a bunch of ADD.

Batch addition trick reduces N point additions to:

1 INV + (N-1)*(3 MUL) + N*(2 MUL + 1 SQR)

Let's call this the cost for N group operations. Now, one of the tricks in RCKang is preferring point addition results with an X3 of a desired parity. "This helps and I know it works". To do this, the batched addition is mixed with a fast check to see if the "normal" X3 is odd, and if so, computes the addition of a second point (x2, -y2) by re-using the same inverse.

So, in case X3 is not preferred, then the other X3 is computed, before a final Y3:

y2' = -y2
m' = (y1 - y2') / (x1 - x2) (1 MUL with the same inverse)
x3' = m'**2 - x1 - x2
y3 = ... (using y2')

On average, in 50% of the cases, the bit is even. So, on average, for one in two additions the above happens, which means, on average, 0.5 MUL + 0.5 SQR are added into the average cost of a group operation.

The final cost of an operation, for a large N, would then be:

1 INV / N + 5.5 M + 1.5 S

As N increases, the inverse cost goes to zero, however we remain with an unaccounted ratio for "group operations":

(5.5 M + 1.5 S) / (5 M + 1S)

If we put a cost of 1 S = 0.8 M the ratio becomes around 16%.

Which means that the counted group ops, hence the final constant factor, need to be multiplied by 1.16

Keep grinding the natural fluctuations in random variance, eventually you'll get there.

Having fixed bits in the key in whatever positions only reduces the search space, nothing more, and nothing special. For P71, 186 bits are already fixed. zahdi just scans with 218 bits fixed, and he wanted the other 32 to be in the back, not that it matters where they are. The fixed bits can be in any desired positions, and not even consecutive.

I'm not using an Intel or AMD motherboard, neither is it a phone or tablet. Maybe expand your view, have you heard of Apple Silicon? It beats all high-end Intel CPUs for some years now. No BIOS, no Intel shell codes on the SoC.

Anyway, back to the topic. Why is it so hard to understand that a non-vulnerable H160 pool is close to impossible to implement? Even if you secure the client process to private memory and download some signed GPU code from a server every 5 seconds, in the most secure way possible, I can guarantee you the public key needs to be available on the client side one way or another, hence it is subject to be exploited without the server ever knowing it was found. In effect, making the pool un-trustable, even if you throw off 100 security layers on top.

Someone who messed around with logic gates on motherboards would surely grasp this, right?

First of all, I'm not running a BIOS, but thank you for your contribution to the hardware industry!

Secondly, before you spend 20 minutes writing nonsense about SSL, here's a spicy line of code out of the client code:


Now please explain why someone can not simply print the public key to the screen if it hashes down to Puzzle 71, and TRAP the kernel, giving zero fucks about whether the program continues or not.

I don't think you understand the essential problem, frankly.

What w0rd? Advising people to join a broken vulnerable unsafe pool where any other participant can keep the private key for himself by simply using kangaroo after hitting the public key match, while telling the pool that nothing was found and to continue scanning other ranges? Cool.


Those are not crazy new levels, they are very slow speeds even for an underpowered GPU. Which translates to wasting more resources and electricity than required.

I keep all my keys in a JSON file. Every key is encrypted with an AES-256 master key that's decrypted based on a 8 million rounds PBKDF2 derivation step, similar to how wallet.dat does it.

The JSON is steganographically embedded in cat videos based on chroma subsampling averages of encoded 16x16 blocks, so its agnostic to video transcoding. Everything's up on YouTube for secure backup. Ever seen weird videos like "12 hour cat relaxation calm music healing anti stress"? Well, thats me striking users in their face with hidden crypto assets!

The reverse steganography scripts, with secondary backups are saved over in a VeraCrypt hidden volume that appears to contain expired voucher codes; the volume only mounts using a picture of Nyan cat as the keyfile. This allows plausible deniability in case the file gets busted and I'm forced to mount it.

The volume file backups (aptly named "SystemVolumeInformation") is sync'd on a cloud storage I shall not name, using rsync's file encryption feature, thus encrypting all contents and chunking all data into randomly named blobs.

Am I doing it wrong?

That's great for making sure no one can sniff the traffic, but it doesn't help at all with anything, since the client is in full control of the code, hence of whatever is being transferred in and out. Unless you provide a way to find the solution without ever exposing the public key on the client side, all of the security layers are pretty much protecting a system that was already vulnerable since the very first second of being public. If you ever find a "fix" (I doubt one exists), you would have to restart the entire pool from scratch, since nothing your server got so far can actually be trusted, and it's trivial for anyone that joins to simply not send real or complete results back to your server, hence I don't see a reason for anyone to actually join, given these priblems.

Cool. Very powerful security. I haven't seen how you fix this small issue though:

The super-protected client solves the key (let's assume he doesn't even know what was the private key associated with the starting public key; not sure if your code even ensures clients don't know that anyway).

Since the address match requires hashing a public key, and the client knows what hash he wants to find, this means direct access to the public key that yielded the match.

He then simply breaks the private key out of the public key, sending nothing at all to your pool. What's your server protection against this?

Since all valid points on the curve are defined as

y**2 = x**3 + b (b = 7)

this solves as three x roots for every possible y**2.

Since y**2 has two solutions, we have 3*2 = six points sharing the same y**2.

Simplifying and getting rid of the squaring, this means all curve points can be split in sets of 6, every set having the same min(y, -y).

Now, let's assume you have some (x, y) of a point, without even knowing its scalar. You can directly compute all other 5 points, and their scalar multiples, without any expensive operations!

In the scalar domain, solve for lambda**3 = 1 as the post above uses. This allows playing around with the scalars and verifying that the below math checks out OK!

In the curve field (x, y) first solve for beta**3 = 1 like this:

Because of Fermat we have a**(p-1) = 1 mod p for eny integer a and prime p.

So beta**3 == 1 == a**(p-1) hence beta = a**((p-1)/3) (there are only ever two solutions for this no matter what value for a you pick).

Due to another theorem, because we have beta**3 = 1 we then have beta**0 + beta**1 + beta**2 = 0 which gives all roots for beta, which are:

beta**0 = 1
beta**1 = a**((p-1)/3)
beta**2 = -beta**0 - beta**1 = -1 - beta

So, fastest way to get all other 5 points from (x, y):

(x, -y)
(x * beta, y)
(x * beta, -y)
(x * beta**2, y) = (- (x + x*beta), y)
(x * beta**2, -y) = (- (x + x*beta), -y)

So, just one multiplication and a field additions / negations at most.

Note that my point is that the multiplication with a precomputed beta**2 can be simplified with a simple addition and negation.

With enough precomputed data, even a freaking Raspberry Pi can break any 80 bits (or less) private key in a few seconds. Yes, I have this fully working.

Talking about spinning up entire GPU instances only makes sense for high bit puzzles (100+). Anything less can be broken with a mere GPU, or a couple of them. And even so, it takes just a few seconds to have them rented automatically and all of them working together for solving some specific problem. No need for any manual connection, passwords, and admin things like that.

Thinking that the ones who "stole" 66 and 69 used cloud rentals must be joking, or have no clue about some things.

Do you seriously think a sane person would try to actually calculate that?

I'd say the answer lies in the order of millions or more, since you have all the possible front matches, multiplied by the number of all possible combination pairs of the other criteria (e.g. 2 base58 digits out of whatever many remain after the front digits). Then you scale down to some interval size and apply the approximations of a uniform distribution.

Also, this has zero relevance since I can assure you that whatever two numbers you ever provide, in whatever base you choose them to be, there is always some other common representation that will make them look like they're siamese sisters. That's pretty much the case with all the "prefixes" of H160.

Well, since you found the match, the probability is 100% to have exactly 1 of those prefixes, in an interval of size one, starting at the key you've found.