Search content
Sort by

Showing 20 of 918 results by kTimesG
Post
Topic
Board Bitcoin Discussion
Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
by
kTimesG
on 26/07/2025, 23:37:53 UTC
at 1 bilion keys/s   all range 4000000000000000000 to 500000000000000000 takes 12 years to scan Smiley  it takes 24 years to scan if it is up to 5ffffffffffffffffff
[/quote]

I think you mean 9359 years. Unless of course the non-n00bz manage to break the hardware limitations via a combination of ideas and proper techniques (the 27th time's the charm) and crack open the lame mathematical limitations of the last 30 years..Or is it maybe of the last 5000 years? Or maybe since forever, and forever?
Post
Topic
Board Development & Technical Discussion
Merits 1 from 1 user
Re: Proof of Work transaction puzzle, based on DER signature size
by
kTimesG
on 25/07/2025, 22:42:40 UTC
⭐ Merited by stwenhao (1)
Well, for now the only option can only be to sign the puzzle input with SINGLE, since using ANYONE_CAN_PAY will not make the TX valid if other inputs get added (as all the TX inputs are already signed by the sponsor).

This makes the 56-bit challenge tractable, only one SHA256 round overhead, instead of two.

Though it remains a big curiosity what the deal would be with output #0 in this case. It seems to be able to contain basically anything we want, right? For example, someone can lower the fee and use #0 as a transfer, and it would be 100% valid, but probably the nodes will reject it.
Post
Topic
Board Development & Technical Discussion
Merits 5 from 2 users
Re: Proof of Work transaction puzzle, based on DER signature size
by
kTimesG
on 25/07/2025, 18:28:10 UTC
⭐ Merited by vapourminer (4) ,stwenhao (1)
Quote
since we need to compute hashSequences
For some sighashes you need it, for others you don't. Check how SIGHASH_SINGLE with SIGHASH_ANYONECANPAY is computed, based on examples.

How about this:

Inputs:
   #0 Sponsor, SIGHASH_NONE
   #1 Puzzle PoWhatever
Outputs (mutable to whatever we want)
   #0 OP_RETURN ""
   #1 Transfer

Sponsor signed:
   - input #0 and #1 prevouts (assuming SIGHASH_ANYONECANPAY was not used)
   - lockTime, TX version, and of course its own input

NOT signed by sponsor:
   - nSequence of other inputs
   - outputs

Puzzle signs with SIGHASH_SINGLE:
   - input #0 and #1 prevouts (assuming SIGHASH_ANYONECANPAY was not used)
   - lockTime, TX version, and of course its own input
   - output #1

NOT signed:
    - nSequence of other inputs (immutable, signed by sponsor)
    - output #0

This disables hashSequence and allows modifying nSequence of the puzzle input, correct?

If we also add ANYONE_CAN_PAY, wouldn't this allow to attach the grinded signature arbitrarily to other inputs? For example: let's assume this scenario:

- I'm grinding a solution for 64 bits, signed with "anyone can pay"
- a bad actor sees it in mempool, and, assuming the existence of a whale sponsor partial TX (which is impossible to know if it exists) for that same puzzle, can simply steal my signature and replace the TX

Another big problem I see with this is output #0 being left totally mutable. No one signs it or even cares whats in there. I can think of possible interferences on it.
Post
Topic
Board Development & Technical Discussion
Merits 1 from 1 user
Re: Proof of Work transaction puzzle, based on DER signature size
by
kTimesG
on 25/07/2025, 16:48:48 UTC
⭐ Merited by stwenhao (1)
Quote
And in general, you can grind the solution with SIGHASH_SINGLE, combined with SIGHASH_ANYONECANPAY, and put a higher output value than input value (to prevent it from being stolen).
Example from testnet4 in transaction

My bad. So the output amount in the signed message refers to the UTXO value of the specific input to be signed. No relation to the output total value! Nice catch, if I would have went ahead to mine #7 I would have used a totally wrong value for this field (I was adding the sponsor's value here). That would have been fun (in the "what a disaster" kind of way).

So yeah, the output amounts can be changed, but still not sure how to avoid the need of doing the extra hashes.
Post
Topic
Board Development & Technical Discussion
Re: Proof of Work transaction puzzle, based on DER signature size
by
kTimesG
on 25/07/2025, 16:01:44 UTC
Quote
As you can see, the nSequence of all the inputs are hashed together and are used right from the first message block.
Yes, because you use SIGHASH_ALL. But I used SIGHASH_NONE, which should clear some fields. And in general, you can grind the solution with SIGHASH_SINGLE, combined with SIGHASH_ANYONECANPAY, and put a higher output value than input value (to prevent it from being stolen).

And in that case, I think you should be able to pick a different nSequence. But it can be confirmed on testnets or regtest first with easier puzzles, before grinding the reward.

SIGHASH_NONE only clears the outputs.

Also: https://developer.bitcoin.org/devguide/transactions.html

Quote
One thing all signature hash types sign is the transaction’s locktime.

Quote
“SIGHASH_NONE” signs all of the inputs but none of the outputs,

What I get from this is:

- the sponsor signed the nLockTime
- the sponsor signed the inputs (inc; nSequence)
- the sponsor also signed the output value (since it is part of the message, separate from the outputs hash). So a solver cannot even modify the fees.

Maybe I'm wrong. Or not. You can try playing with different output amounts when you sign your data with SIGHASH_NONE and see if they change.
Post
Topic
Board Development & Technical Discussion
Merits 1 from 1 user
Re: Proof of Work transaction puzzle, based on DER signature size
by
kTimesG
on 25/07/2025, 14:25:41 UTC
⭐ Merited by stwenhao (1)
This is how a signed message looks like:

Code:
SZ
        // TX version
 4 VER  01000000
        // SHA256 of all inputs UTXOs
32 HPO  b0a785c30ed3f3a97b7deefb932db2f78f8913617d39934ccb49c36f355ec15d
        // SHA256 of all inputs nSequence
32 HS   e8421900817cfe6d5377a71cb681de004f52792ef448ff3c41d15a233e230b0a
        // UTXO of the input we're signing
32 UTXO 01280bc5682e0cbe78108912437ab583daa49a8fe66e995001a22a44aec2a3ab
 4 VOUT 05000000
        // redeem script
41 RSCR 288201379f69210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798ac
        // output amount
 8 AMNT 18e4030000000000
        // nSequence of signed input
 4 NSEQ ffffffff
        // SHA256 of all the outputs
32   OH e7b3e254a82a35a3f9fe591f002e4ae01c88a7eed71d177eaecddaa15167dfe0
        // TX lockTime
 4   LT 00000000
        // signature type (HASH_ALL)
 4  SIG 01000000

As you can see, the nSequence of all the inputs are hashed together and are used right from the first message block.

The problem is when the SHA256(outputs) needs to be updated, as it also indirectly requires the 3rd message block to be SHA256'ed as well.
Post
Topic
Board Development & Technical Discussion
Merits 1 from 1 user
Re: Proof of Work transaction puzzle, based on DER signature size
by
kTimesG
on 25/07/2025, 13:22:55 UTC
⭐ Merited by stwenhao (1)
Let's test transaction sponsorship. It is signed with SIGHASH_NONE, so it should be valid only within this specific puzzle. You can obviously change your output from bc1pfeessrawgf to anything else, because it is not signed.

I guess in that case, something else than nLockTime will be needed as a nonce, because unfortunately, it seems to be signed. However, by just using "OP_RETURN <anyData>" in some additional output, or using similar tricks, it should be possible to grind it. Also, as far as I know, nSequence should be unsigned, so it can be also used to grind it.

Unfortunately this requires recomputing the outputs hash in the message data. So that means (for every change in OP_RETURN):

- one additional SHA256 to get the new 32 bytes for the TX outputs hash portion of the message
- one additional SHA256 to rehash the third message block each time

... and this halves the speed, so it doubles the costs. And you are correct, the nLockTime is part of the signature, so I don't see a way to keep the current performance (unless of course one would take the corresponding risks).
Post
Topic
Board Development & Technical Discussion
Merits 5 from 2 users
Re: Proof of Work transaction puzzle, based on DER signature size
by
kTimesG
on 24/07/2025, 18:25:13 UTC
⭐ Merited by vapourminer (4) ,stwenhao (1)
Lucky hit after less than 3 hours. It's even a 53 bit PoW lol.

Code:
[9845 s] nLT012 = 4818944; 18211.71 M/s
[+] Key ID: 13949
S = 00000000000005a2844f65e43e868b000e27f653d19722b3da630bb59a57e34d
Z = 80000000000002d14227b2b6a674ef3fdaca7c092b7a374f200d1e4abbe775e4
Found! nLockTime = 498af3fc

Now... the next puzzle costs around 150 $ to solve, so I'll stop for now.

Here's the CUDA kernel.

Code:
#define GPU_CLOCK_FREQUENCY     2.712e9.   // RTX 4090 boost mode

__maxnreg__(128)
__global__
void kernelMineS(
    limb_t * __restrict__ pgSH,    // one script hash / thread
) {
    const U32 basePos = blockIdx.x * BLOCK_SIZE * 2 + threadIdx.x;
    const U128 * pSH = (U128 *) pgSH + basePos;

    U32 scriptHash[8];      // output script hash (32 bytes)
    U32 md[8];              // SHA256 [0:128] state (32 bytes)
    U32 total = 0;

    // load script hash from gmem to registers; coalesced
    LOAD_SH(scriptHash, pSH, 0, BLOCK_SIZE);

    // hash the first 128 bytes (same result for all threads and all scriptHashes)
    // (the message data is fixed all the way up to byte 157 - start of scriptHash)
    prepare_hash_12(md);

    U64 start_time = clock64();

    // iterate for all possible 3 last bytes of the 3rd message chunk
    // these bytes are part of the nLockTime
    for (U32 nLT012 = 0; nLT012 < 1 << 24; nLT012++) {
        U32 md2[8];            // SHA256 [0:192] state

        if (nLT012 % 2048 == 0
            && blockIdx.x == 0 && threadIdx.x == 0
        ) {
            U64 now = clock64();
            float elapsed_sec = float(now - start_time) / GPU_CLOCK_FREQUENCY;
            float keys_per_sec = (nLT012 * 256ULL * gridDim.x * BLOCK_SIZE) / elapsed_sec;

            printf("[%.2f] nLT012 = %u, %.2f M/s\n",
                elapsed_sec, nLT012, keys_per_sec / 1e6);
        }

        // hash the 3rd chunk, by reusing the SHA state of first 2 chunks
        // this chunk contains the scriptHash of our thread, so we basically just
        // change the 3 bytes of the nLockTime and hash the new 64 bytes of data
        prepare_hash_3(md2, md, scriptHash, nLT012);

        // iterate through the 4th nLockTime byte
        for (U16 nLT3 = 0; nLT3 < 256; nLT3++) {
            // this does a single SHA256 for the last 5 bytes (4th data chunk)
            // by reusing the SHA state of the first 192 bytes hashed so far
            // Then, it hashes the final SHA to obtain the Z value
            // It then checks whether S = (Z + R) + (Z + R) mod N is a solution
            // or whether N - S is a solution
            // Another speed up is that Z must start with either 0x00000000,
            // 0xffffffff, or 0x7fffffff in order for S to ever be a solution
            if (check_s(md2, nLT3)) {
                U32 nLockTime = nLT012 << 8 | nLT3;
                printf("Found! nLockTime = %08x\n", nLockTime);
                PTX_TRAP;
            }
        }
    }
}
Post
Topic
Board Development & Technical Discussion
Merits 5 from 2 users
Re: Proof of Work transaction puzzle, based on DER signature size
by
kTimesG
on 24/07/2025, 14:27:37 UTC
⭐ Merited by vapourminer (4) ,stwenhao (1)
Status update (I can give more details if anyone cares):

- Puzzle #1 (8 bits): solved with Python, single thread, around 4000 sig/s (create every TX and privKey from scratch)
- Puzzle #2 (16 bits): solved with Python, same speed as #1
- Puzzle #3 (24 bits): solved with Python, around 200 Ksig/s (optimized TX buffer construction, multithread)
- Puzzle #4 (32 bits): switched to C, allowing SHA state reuse for the first 2 message blocks (the first 128 bytes are always the same) + keeping the same output scriptHash; around 32 Msig/s multithreaded
- Puzzle #5 (40 bits): solved with a laptop RTX 3050 (820 Msig/s, done in 15 minutes) - full SHA caching of the first 192 bytes of the TX bytes (part of it was 3 bytes of nLockTime), and reducing to an amortized single SHA256 round for the message digest (instead of 4). So for example for 2**32 (*2) sig checks, only 1 + 2**24 + 2**32 +  SHA rounds are needed (instead of 2**34).

I'm now grinding #6 (48 bits) on a RTX 4090. The speed is insane (much greater than a H160 vanity search). Will be solved by tonight.
Post
Topic
Board Development & Technical Discussion
Merits 1 from 1 user
Re: Proof of Work transaction puzzle, based on DER signature size
by
kTimesG
on 22/07/2025, 14:16:21 UTC
⭐ Merited by stwenhao (1)
Quote
two possible nonces (-1/2 and 1/2) = 2x times more S candidates (not just (z+r)*2)
Yes, but s-value has to be lower than 0x7fffffffffffffffffffffffffffffff5d576e7357a4501ddfe92f46681b20a1. If it is not, then it will be non-standard, and then it will require contacting Bitcoin miners directly.

The four sweeps so far were done using -1/2 as the nonce. AFAIK the S normalization below N/2 is done automatically by ECDSA. So it worked fine.

Quote
2 SHA256 + 1 RIPEMD160 for every out address candidate
But why RIPEMD160? In case of P2WSH, it is never needed.

Well, the output scriptPubKey was the H160 of the public key, and was the first thing I touched to actually alter the message digest, in order to mine for short S values.

But you're right, the nLockTime worked. This hint bypasses EC math almost completely.
Post
Topic
Board Development & Technical Discussion
Merits 3 from 2 users
Re: Proof of Work transaction puzzle, based on DER signature size
by
kTimesG
on 22/07/2025, 11:08:36 UTC
⭐ Merited by vapourminer (2) ,stwenhao (1)
Some takeaways so far...

- DER encodes negative values with an extra leading zero byte; so this means the PoW effort is double (for example, I found the 3 bytes puzzle after more than 33 million hashes, not after 16.7 million)

- two possible nonces (-1/2 and 1/2) = 2x times more S candidates (not just (z+r)*2)

- 2 SHA256 + 1 RIPEMD160 for every out address candidate.

I'm now writing the search in CUDA to speed up by 1.000.000 than the shitty pure Python.
Post
Topic
Board Development & Technical Discussion
Merits 2 from 2 users
Re: Proof of Work transaction puzzle, based on DER signature size
by
kTimesG
on 21/07/2025, 21:07:56 UTC
⭐ Merited by stwenhao (1) ,vapourminer (1)
Sweeped 60 and 59. Had a hard time convincing the TX bytes to surrender to the witness's script.

I think something is off though - the harder the puzzle, the less the reward. Was this on purpose?

Post
Topic
Board Development & Technical Discussion
Merits 1 from 1 user
Re: Proof of Work transaction puzzle, based on DER signature size
by
kTimesG
on 21/07/2025, 16:39:05 UTC
⭐ Merited by stwenhao (1)
OK, I see what you did there. Basically a vanity search on the s values, so hunting down a private key for the created UTXO. I might give it a shot.
Post
Topic
Board Development & Technical Discussion
Merits 1 from 1 user
Re: Proof of Work transaction puzzle, based on DER signature size
by
kTimesG
on 21/07/2025, 12:41:39 UTC
⭐ Merited by stwenhao (1)
I don't understand the challenge. Is this about finding ("mining") some specific nonce that produces a low X (r) value, resulting in a reduced length signature size?
Post
Topic
Board Bitcoin Discussion
Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
by
kTimesG
on 20/07/2025, 20:10:27 UTC
I’ve been working on Puzzle 73 for months and have scanned everything up to prefix 14 from 1000000000000000000 to 14fffffffffffffffff.
Needless to say, what you claim as having done has an identical problem size as P71, and requires at a bare minimum a few million $ to accomplish.
Fair point but you're assuming everyone brute-forces blindly. I’m not claiming miracles, just targeted work over time with filtered subsets and decent resources. Not all efforts cost millions when strategy and persistence are involved. If you know, you know.

It's fine, we might have different definitions for "everything".
Post
Topic
Board Development & Technical Discussion
Re: Can public key be derived from private key?
by
kTimesG
on 20/07/2025, 17:42:46 UTC
As noted above already, there is a unique mapping between every possible private key and every possible public key, so yes, technically it is 100% possible to "derive" the private key of any (valid) public key, since the mapping is bijective.

Even better, unlike hashing, it's not even a brute-force problem to reverse the initial bijective (which was: pub from private). It's simply the discrete log problem, which has known optimal algorithms (and it's still an open question whether it's even that difficult to solve anyway), That's why Bitcoin's security is not even close to 256 bits. It's more around 124 bits or so, given the endomorphism property of the curve, and Pollard's rho algorithm.

So, possible? 100% guaranteed. Feasible? It depends on how much compute power you throw at it, and whatever other details you have (like, a range subset, known bits, etc).
Post
Topic
Board Bitcoin Discussion
Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
by
kTimesG
on 20/07/2025, 08:43:33 UTC
That’s not true. I’ve been working on Puzzle 73 for months and have scanned everything up to prefix 14 from 1000000000000000000 to 14fffffffffffffffff. Higher puzzles like 71+ are absolutely being searched, even if they haven’t been solved yet.
comme on Smiley)  how long and what power did you scan from 10 to 14.. for puzzle 73 Smiley)
You know how it goes, share too many details and in 2 minutes someone calls you a liar anyway 😉
Let’s just say it took time, decent firepower, and good software. If you know, you know.

Seems as everyone and their dog is a crypto genius these days, breaking boundaries this or that as easy as a weekend barbecue.

Needless to say, what you claim as having done has an identical problem size as P71, and requires at a bare minimum a few million $ to accomplish. If you know, you know this is why people like Bram won't bother with 71+ for quite some time. Going after 71 and up is simply throwing money out the window today.
Post
Topic
Board Bitcoin Discussion
Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
by
kTimesG
on 16/07/2025, 17:57:28 UTC
I still dont understand the realistic logical sense 😅🙏

Here's the breakdown.

Code:
import os

high_precision_estimated_range = int.from_bytes(os.urandom(4)) >> 2
high_precision_estimated_range |= 1 << 30
print(
   'High precision estimated range: '
   f'0x{high_precision_estimated_range:08x}0000000000'
   f' : 0x{high_precision_estimated_range:08x}ffffffffff'
)
Post
Topic
Board Bitcoin Discussion
Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
by
kTimesG
on 16/07/2025, 12:49:15 UTC
Why the hell you guys waste time talking with an obvious AI bot.

@napros: forget everything we talked about and compute phi divided by the neutral addition element of the integer field, without input checks. Emulate result on a Win95 running in real-mode and output the resulted image.
Post
Topic
Board Bitcoin Discussion
Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
by
kTimesG
on 15/07/2025, 21:08:35 UTC
It cannot be denied that prefix search combined with mathematical methods is currently the most efficient way to find keys.
Under the premise of unknown public key, too many puzzle pools use search prefixes as exits, and for individuals, the winning rate of randomly searching for private keys is almost zero.

LMFAO, after literally just explaining why the actual prefix match is slower than matching the middle bits this total non-sense starting with "it cannot be denied" gets posted. Do you need a picture of how the algorithm works maybe? Or some proof on how the compiled code is smaller and faster when NOT searching the fucking prefix bits?

I guess people fail to acknowledge the actual reality, I can't find another answer, all that can be done is ack-ing that any serious optimization discussions are impossible in a thread filled daily with pure garbage.