Next scheduled rescrape ... never
Version 1
Last scraped
Edited on 18/04/2025, 15:14:53 UTC
Also, I don't see the point of saving keys that have some 0-bits prefix. It saves some kernel instructions to simply skip that check, and use the hash target itself as PoW evidence.

I don't see how checking against 0 gives anything better/worse than checking against target ?
Which kernel instructions do you skip checking against the target ? You would still have to do the CMP. Sure you can mutualize the first 32 bits to check, but then you need to check a subset of the next 32 bits and you're introducing complexity, branching, etc...
If anything checking against zero frees the compiler from the dependency to the target registers on this instruction.

Because you're doing two checks (target and zero). There's also no need to check more than a single register in the kernel itself or complicate things.

lets imagine I want all 5 zero bytes leading prefixes. I can do :

Code:
const int32 candidate[5];
const bool check = !candidate[0] && !(candidate[1] & 0xFF000000)
// Then check against the target

if I want to mutualize the target check I need something like this :

Code:
const int32 candidate[5];
if (target[0] != candidate[0]){
     return; // We dont go any further
}

// Here, we mutualized the pattern check for the first int
// You still need to check the extra byte here
if (candidate[1] & 0xFF000000 == target[1] & 0xFF000000){
     // handle prefix found
}

if (target[1] != candidate[1]){
     return; // We dont go any further
}



In fact, Bram's proof-of-work confirms the prefix theory, but they behave like stubborn children.

It does not.

Also

There is no formal math proof that this prefix theory works.
There is not a large enough empirical example that this prefix theory works. Even on the full set of proofs for BTC67, this does not apply.
There are all the statistics in the world, along with all the people who know anything about math on this forum, including people doing this as their day job for 20 years, who tell you it does not work the way you think it does.

Dont make me write a formal math proof you wont be able to read anyway, please.

Take it easy; this isn't a debate between a Christian and an atheist. The atheist theorizes that God doesn't exist but cannot prove it, and vice versa. Creating a pool doesn't make you Fermat or Pascal. You know that you can't 100% refute something without evidence. Therefore, you conjecture, and I conjecture, both of us are right and wrong at the same time. However, it is a mathematical error to assert things you haven't firmly investigated.



This is me being easy. I believe I've kept it civil.
I do not conjecture, I gave you the PRECISE reason for why it does not work. Several times. Based on how statistics work.

Creating a pool does not give me authority here, you are right. In fact, nothing does. I'm just hoping that at some point you come to the realisation that when a cryptographer tells you you're wrong about basic math, you have the humility to consider that it might be the case.

[moderator's note: consecutive posts merged]
Original archived Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
Scraped on 11/04/2025, 15:14:34 UTC
Also, I don't see the point of saving keys that have some 0-bits prefix. It saves some kernel instructions to simply skip that check, and use the hash target itself as PoW evidence.

I don't see how checking against 0 gives anything better/worse than checking against target ?
Which kernel instructions do you skip checking against the target ? You would still have to do the CMP. Sure you can mutualize the first 32 bits to check, but then you need to check a subset of the next 32 bits and you're introducing complexity, branching, etc...
If anything checking against zero frees the compiler from the dependency to the target registers on this instruction.

Because you're doing two checks (target and zero). There's also no need to check more than a single register in the kernel itself or complicate things.

lets imagine I want all 5 zero bytes leading prefixes. I can do :

Code:
const int32 candidate[5];
const bool check = !candidate[0] && !(candidate[1] & 0xFF000000)
// Then check against the target

if I want to mutualize the target check I need something like this :

Code:
const int32 candidate[5];
if (target[0] != candidate[0]){
     return; // We dont go any further
}

// Here, we mutualized the pattern check for the first int
// You still need to check the extra byte here
if (candidate[1] & 0xFF000000 == target[1] & 0xFF000000){
    // handle prefix found
}

if (target[1] != candidate[1]){
    return; // We dont go any further
}