Ninjastic
Search content
Sort by
Showing 15 of 15 results by sdfasdf
Post was edited
 1 month ago (view)
Post
Topic
Board Development & Technical Discussion
Re: 🧠 Looking for Real Signature Dataset with < 4-bit Biased Nonces (Educational Pu
by
sdfasdf
on 24/06/2025, 04:35:12 UTC
Quote from: sdfasdf on Today at 02:51:06 AM
🧠 Looking for Real Signature Dataset with < 4-bit Biased Nonces (Educational Purposes)

Hello Bitcointalk community! 🙋‍♂️

I'm currently learning how nonce bias can leak ECDSA private keys. I'm especially interested in real-world datasets where the nonces used in Bitcoin or similar systems were biased by less than 4 bits — for example, 1-bit, 2-bit, or 3-bit biases.

I'm looking for:

Real signatures where the nonce k is biased

Known private key (d) for testing recovery

Bias type clearly labeled (MSB OR LSB)

Dataset in a simple JSON format (see below)

If anyone has experimented with or generated such datasets, especially where 1-bit bias led to successful private key recovery, I would love to learn from them. I’m not asking for any private or wallet keys, just clean test vectors for education.

https://github.com/bitlogik/lattice-attack

How low-bit biases (e.g., 1–3 bits) can leak d

How many signatures are really needed per bias level

What attack methods (HNP, lattice, ML) are used in practice

How to reproduce or validate the bias-to-d-leak pipeline

Thanks in advance to anyone willing to share or discuss!
I'm purely doing this for research and learning, and I'm happy to share my findings and scripts if there's interest.

Also, if you've worked on private key recovery from biased nonces, I’d love to know:

✅ How many biased signatures did you need to recover d for:

1-bit bias?

2-bit bias?

3-bit bias?

🧠 What attack method did you use?

Hidden Number Problem (HNP)?

Lattice (LLL, BKZ)?

Custom optimization?

⚙️ What hardware was used?

CPU (how many cores / threads)?

GPU (which model)?

RAM needed?

⏱️ How long did full recovery take?

From dataset input → full private key output

Any optimization tricks that helped?


Sample (Example Answer I'm Hoping to See):

Edit:
Bit bias: 2-bit (msb or lsb)
Signatures used: 80
Method: Lattice + BKZ-25 reduction
Hardware: Ryzen 7950X + 64GB RAM
Time: ~6 minutes (including preprocessing)
Success: Full d recovered



If anyone has written GPU code or CPU thread-enabled code,

BKZ reduction : block size = ?  # your recommend size


i need 1-bit, data.json if successful recover d some one provide dm 
Post was deleted
 1 month ago (view)
Post
Topic
Board Development & Technical Discussion
Topic OP
How Does Nonce Bias Really Leak in ECDSA? If You Found It — Please Share Code or
by
sdfasdf
on 24/06/2025, 03:41:30 UTC
How Does Nonce Bias Really Leak in ECDSA? If You Found It — Please Share Code or Insights!

Hi everyone,

I'm currently learning about ECDSA nonce bias attacks, and I’d love help understanding how even small weaknesses (1–4 bit biases) in the nonce k can leak private key information. I've seen claims of private key recovery using as little as 1-bit bias — but never seen full working code or data.

🔍 What I’m Trying to Understand:
How does a biased bit in k show up in the signature values (r, s, z)?

Can you detect this leakage just by looking at bit-level patterns in multiple signatures?

How many biased bits + how many signatures = enough to break d?

🧪 My Analysis Method (With Code Below)
Here’s how I currently try to analyze for bias:

Collect multiple valid ECDSA signatures → extract r, s, z per sig.

Convert each value to 256-bit binary.

Count how often each bit is 1 across all samples.
 ✅Code  reference?
✅ Can you share Code & data or results?
Report any bit position with strong deviation from randomness (ideal = 0.5 probability of 1).

Code:
import hashlib
from ecdsa import SigningKey, SECP256k1
from statistics import mean
from math import sqrt

curve = SECP256k1
n = curve.order

# -- ECDSA Sign with fixed nonce (for research/testing only!) --
def sign(privkey_int, nonce_int, message_bytes):
    G = curve.generator
    d = privkey_int
    k = nonce_int

    # Hash the message
    h = hashlib.sha256(message_bytes).digest()
    z = int.from_bytes(h, byteorder='big') % n  # ensure z < n

    # Calculate R = k*G
    R = k * G
    r = R.x() % n
    if r == 0:
        raise ValueError("Invalid r = 0")

    # s = k⁻¹ (z + r*d) mod n
    k_inv = pow(k, -1, n)
    s = (k_inv * (z + r * d)) % n
    if s == 0:
        raise ValueError("Invalid s = 0")

    return r, s, z

# -- Bit-level bias analysis on z --
def analyze_z_bias(z_list, bit_length=256):
    print("[+] Bit-Level Bias in Z (MSB first):")
    for bit in reversed(range(bit_length)):
        ones = sum((z >> bit) & 1 for z in z_list)
        ratio = ones / len(z_list)
        line = f"Bit {bit:3d}: 1s = {ratio:.3f}"
        if ratio in (0.0, 1.0) or abs(ratio - 0.5) > 0.05:
            line += " <-- biased"
        print(line)

# -- Correlation calculation --
def pearson_corr(x_vals, y_vals):
    xm = mean(x_vals)
    ym = mean(y_vals)
    num = sum((x - xm) * (y - ym) for x, y in zip(x_vals, y_vals))
    den = sqrt(sum((x - xm)**2 for x in x_vals) * sum((y - ym)**2 for y in y_vals))
    return num / den if den else 0.0

# -- Demo: Generate signatures and analyze bias --
def run_demo():
    privkey = 0xdeadbeef123456789abcdef0feedfacecafebabe123456789abcdef0123456789
    r_list = []
    s_list = []
    z_list = []

    for i in range(1000):
        msg = f"message {i}".encode()
        nonce = i + 1  # use incrementing nonces (DANGEROUS in real use!)
        try:
            r, s, z = sign(privkey, nonce, msg)
            r_list.append(r)
            s_list.append(s)
            z_list.append(z)
        except Exception as e:
            print(f"Skipping failed signature at i={i}: {e}")

    analyze_z_bias(z_list)

    print("\n[+] Correlation Analysis:")
    print(f"Corr(R,Z): {pearson_corr(r_list, z_list):.4f}")
    print(f"Corr(S,Z): {pearson_corr(s_list, z_list):.4f}")

# Run everything
if __name__ == "__main__":
    run_demo()
#output
python bias.py
  • Bit-Level Bias in Z (MSB first):
Bit 255: 1s = 0.519
Bit 254: 1s = 0.514
Bit 253: 1s = 0.519
Bit 252: 1s = 0.488
Bit 251: 1s = 0.510
Bit 250: 1s = 0.506
Bit 249: 1s = 0.485
Bit 248: 1s = 0.515
Bit 247: 1s = 0.487
Bit 246: 1s = 0.490
Bit 245: 1s = 0.494
Bit 244: 1s = 0.512
Bit 243: 1s = 0.505
Bit 242: 1s = 0.479
Bit 241: 1s = 0.515
Bit 240: 1s = 0.512
Bit 239: 1s = 0.521
Bit 238: 1s = 0.518
Bit 237: 1s = 0.499
Bit 236: 1s = 0.513
Bit 235: 1s = 0.520
Bit 234: 1s = 0.511
Bit 233: 1s = 0.504
Bit 232: 1s = 0.495
Bit 231: 1s = 0.476
Bit 230: 1s = 0.544
Bit 229: 1s = 0.499
Bit 228: 1s = 0.503
Bit 227: 1s = 0.491
Bit 226: 1s = 0.510
Bit 225: 1s = 0.524
Bit 224: 1s = 0.479
Bit 223: 1s = 0.502
Bit 222: 1s = 0.509
Bit 221: 1s = 0.523
Bit 220: 1s = 0.510
Bit 219: 1s = 0.526
Bit 218: 1s = 0.508
Bit 217: 1s = 0.490
Bit 216: 1s = 0.514
Bit 215: 1s = 0.514
Bit 214: 1s = 0.491
Bit 213: 1s = 0.501
Bit 212: 1s = 0.490
Bit 211: 1s = 0.502
Bit 210: 1s = 0.501
Bit 209: 1s = 0.509
Bit 208: 1s = 0.509
Bit 207: 1s = 0.500
Bit 206: 1s = 0.495
Bit 205: 1s = 0.510
Bit 204: 1s = 0.495
Bit 203: 1s = 0.498
Bit 202: 1s = 0.490
Bit 201: 1s = 0.501
Bit 200: 1s = 0.510
Bit 199: 1s = 0.484
Bit 198: 1s = 0.498
Bit 197: 1s = 0.533
Bit 196: 1s = 0.494
Bit 195: 1s = 0.518
Bit 194: 1s = 0.508
Bit 193: 1s = 0.528
Bit 192: 1s = 0.494
Bit 191: 1s = 0.492
Bit 190: 1s = 0.468
Bit 189: 1s = 0.478
Bit 188: 1s = 0.517
Bit 187: 1s = 0.519
Bit 186: 1s = 0.519
Bit 185: 1s = 0.475
Bit 184: 1s = 0.522
Bit 183: 1s = 0.500
Bit 182: 1s = 0.531
Bit 181: 1s = 0.522
Bit 180: 1s = 0.470
Bit 179: 1s = 0.506
Bit 178: 1s = 0.500
Bit 177: 1s = 0.511
Bit 176: 1s = 0.512
Bit 175: 1s = 0.491
Bit 174: 1s = 0.497
Bit 173: 1s = 0.477
Bit 172: 1s = 0.486
Bit 171: 1s = 0.516
Bit 170: 1s = 0.492
Bit 169: 1s = 0.474
Bit 168: 1s = 0.501
Bit 167: 1s = 0.475
Bit 166: 1s = 0.513
Bit 165: 1s = 0.469
Bit 164: 1s = 0.522
Bit 163: 1s = 0.515
Bit 162: 1s = 0.486
Bit 161: 1s = 0.486
Bit 160: 1s = 0.518
Bit 159: 1s = 0.479
Bit 158: 1s = 0.522
Bit 157: 1s = 0.476
Bit 156: 1s = 0.511
Bit 155: 1s = 0.505
Bit 154: 1s = 0.500
Bit 153: 1s = 0.512
Bit 152: 1s = 0.502
Bit 151: 1s = 0.497
Bit 150: 1s = 0.495
Bit 149: 1s = 0.503
Bit 148: 1s = 0.476
Bit 147: 1s = 0.481
Bit 146: 1s = 0.495
Bit 145: 1s = 0.501
Bit 144: 1s = 0.526
Bit 143: 1s = 0.474
Bit 142: 1s = 0.476
Bit 141: 1s = 0.507
Bit 140: 1s = 0.486
Bit 139: 1s = 0.529
Bit 138: 1s = 0.512
Bit 137: 1s = 0.495
Bit 136: 1s = 0.472
Bit 135: 1s = 0.508
Bit 134: 1s = 0.506
Bit 133: 1s = 0.473
Bit 132: 1s = 0.467
Bit 131: 1s = 0.498
Bit 130: 1s = 0.508
Bit 129: 1s = 0.482
Bit 128: 1s = 0.471
Bit 127: 1s = 0.511
Bit 126: 1s = 0.508
Bit 125: 1s = 0.497
Bit 124: 1s = 0.532
Bit 123: 1s = 0.488
Bit 122: 1s = 0.509
Bit 121: 1s = 0.516
Bit 120: 1s = 0.497
Bit 119: 1s = 0.481
Bit 118: 1s = 0.502
Bit 117: 1s = 0.480
Bit 116: 1s = 0.520
Bit 115: 1s = 0.494
Bit 114: 1s = 0.510
Bit 113: 1s = 0.503
Bit 112: 1s = 0.503
Bit 111: 1s = 0.518
Bit 110: 1s = 0.511
Bit 109: 1s = 0.523
Bit 108: 1s = 0.497
Bit 107: 1s = 0.498
Bit 106: 1s = 0.506
Bit 105: 1s = 0.504
Bit 104: 1s = 0.478
Bit 103: 1s = 0.502
Bit 102: 1s = 0.505
Bit 101: 1s = 0.504
Bit 100: 1s = 0.469
Bit  99: 1s = 0.496
Bit  98: 1s = 0.513
Bit  97: 1s = 0.497
Bit  96: 1s = 0.510
Bit  95: 1s = 0.472
Bit  94: 1s = 0.498
Bit  93: 1s = 0.509
Bit  92: 1s = 0.478
Bit  91: 1s = 0.467
Bit  90: 1s = 0.514
Bit  89: 1s = 0.480
Bit  88: 1s = 0.497
Bit  87: 1s = 0.520
Bit  86: 1s = 0.497
Bit  85: 1s = 0.516
Bit  84: 1s = 0.484
Bit  83: 1s = 0.502
Bit  82: 1s = 0.467
Bit  81: 1s = 0.513
Bit  80: 1s = 0.494
Bit  79: 1s = 0.511
Bit  78: 1s = 0.512
Bit  77: 1s = 0.478
Bit  76: 1s = 0.485
Bit  75: 1s = 0.513
Bit  74: 1s = 0.500
Bit  73: 1s = 0.513
Bit  72: 1s = 0.496
Bit  71: 1s = 0.505
Bit  70: 1s = 0.496
Bit  69: 1s = 0.523
Bit  68: 1s = 0.512
Bit  67: 1s = 0.494
Bit  66: 1s = 0.489
Bit  65: 1s = 0.493
Bit  64: 1s = 0.510
Bit  63: 1s = 0.516
Bit  62: 1s = 0.513
Bit  61: 1s = 0.507
Bit  60: 1s = 0.495
Bit  59: 1s = 0.511
Bit  58: 1s = 0.500
Bit  57: 1s = 0.509
Bit  56: 1s = 0.488
Bit  55: 1s = 0.512
Bit  54: 1s = 0.500
Bit  53: 1s = 0.522
Bit  52: 1s = 0.512
Bit  51: 1s = 0.466
Bit  50: 1s = 0.489
Bit  49: 1s = 0.503
Bit  48: 1s = 0.497
Bit  47: 1s = 0.521
Bit  46: 1s = 0.513
Bit  45: 1s = 0.476
Bit  44: 1s = 0.519
Bit  43: 1s = 0.488
Bit  42: 1s = 0.492
Bit  41: 1s = 0.506
Bit  40: 1s = 0.538
Bit  39: 1s = 0.530
Bit  38: 1s = 0.501
Bit  37: 1s = 0.506
Bit  36: 1s = 0.528
Bit  35: 1s = 0.498
Bit  34: 1s = 0.503
Bit  33: 1s = 0.503
Bit  32: 1s = 0.500
Bit  31: 1s = 0.509
Bit  30: 1s = 0.501
Bit  29: 1s = 0.497
Bit  28: 1s = 0.486
Bit  27: 1s = 0.464
Bit  26: 1s = 0.525
Bit  25: 1s = 0.498
Bit  24: 1s = 0.511
Bit  23: 1s = 0.507
Bit  22: 1s = 0.493
Bit  21: 1s = 0.498
Bit  20: 1s = 0.470
Bit  19: 1s = 0.495
Bit  18: 1s = 0.502
Bit  17: 1s = 0.494
Bit  16: 1s = 0.510
Bit  15: 1s = 0.492
Bit  14: 1s = 0.490
Bit  13: 1s = 0.493
Bit  12: 1s = 0.500
Bit  11: 1s = 0.518
Bit  10: 1s = 0.490
Bit   9: 1s = 0.475
Bit   8: 1s = 0.505
Bit   7: 1s = 0.518
Bit   6: 1s = 0.511
Bit   5: 1s = 0.492
Bit   4: 1s = 0.498
Bit   3: 1s = 0.484
Bit   2: 1s = 0.531
Bit   1: 1s = 0.473
Bit   0: 1s = 0.495

  • Correlation Analysis:
Corr(R,Z): 0.0000
Corr(S,Z): -0.0000
Post
Topic
Board Development & Technical Discussion
Re: Possible LLL Attack Opportunity? Bias Detected in 5 ECDSA Signatures
by
sdfasdf
on 24/06/2025, 03:10:17 UTC
Quote from: peakyclin77 on May 13, 2025, 10:19:20 PM
Hello everyone,

I'm still working on solving a puzzle posted at https://bitcointalk.org/index.php?topic=5535021.0

Today, I'm focusing on a specific key that might help trivialize solving half of the puzzle.
This key's corresponding address is currently empty, and I've managed to collect a total of 5 valid ECDSA signatures related to it.

Here's the analysis — I'm particularly looking into whether the signatures reveal enough bias to attempt a lattice (LLL) attack using only 5 samples.

=== Fine-Grained Analysis of S Distribution ===

S in [1, n/4]: 4/5 → 80.00%
S in [1, n/8]: 3/5 → 60.00%
S in [1, n/16]: 1/5 → 20.00%
S in [1, n/32]: 1/5 → 20.00%
S in [1, n/64]: 0/5 → 0.00%
S in [1, n/128]: 0/5 → 0.00%

Result:
MAX BIAS: 4/5 signatures (80.00%) in [1, n/4]
→ Strong bias detected, likely due to a biased nonce k.
=== Exhaustive Bit Analysis of S ===

Total signatures: 5
Number of fixed bits (always 0 or 1): 16

Fixed bits:

    Bit 4: always 0

    Bit 8: always 1

    Bit 49: always 0

    Bit 50: always 0

    Bit 55: always 1

    Bit 69: always 0

    Bit 77: always 1

    Bit 93: always 0

    Bit 102: always 1

    Bit 103: always 1

    Bit 116: always 0

    Bit 146: always 0

    Bit 180: always 0

    Bit 183: always 0

    Bit 202: always 0

    Bit 255: always 0

Max block of consecutive fixed bits: 2 bits (starting at bit 49)
Low 8 bits of S: ['0x6e', '0x2a', '0x29', '0xe4', '0xcc']

Result:
MAX BIAS: 16 fixed bits; max block = 2 bits
→ Strong bias detected, possibly due to structural patterns in k

Can such a bias with only 5 signatures be sufficient to attempt an LLL attack?

Any thoughts or experiences would be greatly appreciated.
Thanks in advance!

Can you share your code because I went to test how your bias code was working?
Post
Topic
Board Bitcoin Technical Support
Re: Bias Weakness in Transactions – Lattice Attack Possible?
by
sdfasdf
on 24/06/2025, 03:03:12 UTC
Quote from: Parabellum118 on June 23, 2025, 06:25:47 AM
Hello everyone, I think I have a problem!

I read an article saying that with enough transactions and a nonce bias of just 1, it's already possible to recover a private Bitcoin key 😯
ECDSA Cracking Methods (April 2025)
A survey paper by Edinburgh Napier University (William Buchanan et al.) summarizes that nonce biases, weak nonce selection, or even a single broken bit can be enough to recover a key using lattice algorithms like LLL.

So I thought, let me take my transactions, and with the help of ChatGPT I created a script based on that study. Before that, I extracted the RSZ data from the transactions using the tools from iceland2k14/rsz and double-checked them with 2coins.org/RSZ-Signature-From-Tx, and the data is correct.

I then converted the RSZ data to binary format, and during the first check, I already had a bit bias of 8 across 12 transactions 🤨 — in the upper area (MSG). I dug deeper and had ChatGPT generate a script that runs the analysis based on the study. As a result, I found that my transactions actually show a very strong bias, and R correlates with S and Z — theoretically, someone could recover my private key.

Then I tried it with a custom tool created by ChatGPT. Luckily, I wasn't able to recover the private key — I did get a lot of addresses, but mine wasn't among them. Still, I'm feeling uncertain.

There are a lot of RSZ recovery tools on GitHub, but most of them require a fully known nonce. Besides the fact that I've already moved my BTC to a new wallet — which tools are actually capable of recovering a private key with a bit bias of 4 to 8?

No quantum computer needed — it seems to work surprisingly fast. The study doesn't offer tools, it's just a paper.
Since I know the private key for my address, I’d like to try it myself.

Anyone here have experience with this?
Can you share the article paper link?

Quote from: Parabellum118 on June 23, 2025, 06:25:47 AM
I then converted the RSZ data to binary format, and during the first check, I already had a bit bias of 8 across 12 transactions 🤨 — in the upper area (MSG). I dug deeper and had ChatGPT generate a script that runs the analysis based on the study. As a result, I found that my transactions actually show a very strong bias, and R correlates with S and Z — theoretically, someone could recover my private key.
I am all ready to try converting the RSZ data to a binary format. No bias leak. Can you share your code because I went to test how your bias code was working?
Post was edited
 1 month ago (view)
Post
Topic
Board Development & Technical Discussion
Topic OP
🧠 Looking for Real Signature Dataset with < 4-bit Biased Nonces (Educational Pu
by
sdfasdf
on 24/06/2025, 02:51:06 UTC
🧠 Looking for Real Signature Dataset with < 4-bit Biased Nonces (Educational Purposes)

Hello Bitcointalk community! 🙋‍♂️

I'm currently learning how nonce bias can leak ECDSA private keys. I'm especially interested in real-world datasets where the nonces used in Bitcoin or similar systems were biased by less than 4 bits — for example, 1-bit, 2-bit, or 3-bit biases.

I'm looking for:

Real signatures where the nonce k is biased

Known private key (d) for testing recovery

Bias type clearly labeled (MSB OR LSB)

Dataset in a simple JSON format (see below)

If anyone has experimented with or generated such datasets, especially where 1-bit bias led to successful private key recovery, I would love to learn from them. I’m not asking for any private or wallet keys, just clean test vectors for education.

https://github.com/bitlogik/lattice-attack

How low-bit biases (e.g., 1–3 bits) can leak d

How many signatures are really needed per bias level

What attack methods (HNP, lattice, ML) are used in practice

How to reproduce or validate the bias-to-d-leak pipeline

Thanks in advance to anyone willing to share or discuss!
I'm purely doing this for research and learning, and I'm happy to share my findings and scripts if there's interest.

Also, if you've worked on private key recovery from biased nonces, I’d love to know:

✅ How many biased signatures did you need to recover d for:

1-bit bias?

2-bit bias?

3-bit bias?

🧠 What attack method did you use?

Hidden Number Problem (HNP)?

Lattice (LLL, BKZ)?

Custom optimization?

⚙️ What hardware was used?

CPU (how many cores / threads)?

GPU (which model)?

RAM needed?

⏱️ How long did full recovery take?

From dataset input → full private key output

Any optimization tricks that helped?


Sample (Example Answer I'm Hoping to See):

Edit:
Bit bias: 2-bit (msb or lsb)
Signatures used: 80
Method: Lattice + BKZ-25 reduction
Hardware: Ryzen 7950X + 64GB RAM
Time: ~6 minutes (including preprocessing)
Success: Full d recovered







Post
Topic
Board Development & Technical Discussion
Re: I found a method to reverse public keys to private keys
by
sdfasdf
on 01/05/2025, 16:36:51 UTC
Quote from: dexizer7799 on Today at 03:30:19 PM
Quote from: nikolayspb on April 30, 2025, 03:58:35 PM
Quote from: dexizer7799 on March 05, 2025, 08:40:34 AM
Test this script, it created by me, this can recover up to 249 bits for up to 256 private key.

https://github.com/dexizer7799/lattice-attack-secp256k1


Hello. Looks like topic deleted. Nothing to try. Can you provide script for testing?


Hi yes I can provide that script write to me personal message.

Hi ,

I hope this message finds you well. I came across your project that involves recovering up to 249 bits for a 256-bit private key. Unfortunately, I found that the GitHub link you provided is not working.

Would you be able to share the script with me directly? I would really appreciate it, as I’m very interested in your work.

Thank you for your time!

Best regards,

fix this >>>User 'dexizer7799' has not chosen to allow messages from newbies. You should post in their relevant thread to remind them to enable this setting. 
Post was edited
 3 months ago (view)
Post
Topic
Board Development & Technical Discussion
Merits 2 from 1 user
Topic OP
Testnet 51% possible ? today ?
by
sdfasdf
on 15/04/2025, 03:50:31 UTC
⭐ Merited by nutildah (2)
With Innopolis Tech having 51.76% of the Bitcoin testnet's hash rate (118.88 TH/s), is it possible for them to execute a 51% attack? What does this mean for the security of the testnet?

https://www.talkimg.com/images/2025/04/15/xy7nP.jpeg
Post
Topic
Board Development & Technical Discussion
Topic OP
Signet Testnet3 Testnet4 ( getblocktemplate submitblock )
by
sdfasdf
on 30/03/2025, 15:00:38 UTC
Hello everyone,

I am currently working with the Signet testnets (testnet3 and testnet4) and I have a couple of questions regarding the use of the getblocktemplate and submitblock RPC methods.

Free RPC Nodes: Can anyone recommend any free RPC nodes or API services that support the Signet testnet? I’m looking for reliable options to test my implementation.
Usage of RPC Methods: I would appreciate any guidance or examples on how to properly use the getblocktemplate and submitblock methods in the context of the Signet testnet. Are there any specific parameters or configurations I should be aware of?
I am currently developing mining software and am focusing on the Signet testnets (testnet3 and testnet4). I have a few questions that I hope the community can help me with:
Thank you for your help!

Best regards,
Post
Topic
Board Development & Technical Discussion
Re: Re : Paires d'adresses P2PKH avec Nonce k réutilisé
by
sdfasdf
on 28/03/2025, 02:42:30 UTC
Quote from: peakyclin77 on March 27, 2025, 09:33:10 PM
Unfortunately, I won’t be sharing the transaction IDs or addresses publicly, for fear that someone might sweep the 4 BTC quickly. The address that reused the R value with the same key is publicly known. Do you have a solution to the mentioned issue?

I understand your concerns about sharing transaction IDs or addresses. However, having the specific transaction ID would greatly help in analyzing the issue and providing a more accurate solution. If you feel comfortable sharing it privately, I assure you that it will be treated with the utmost confidentiality.

send me DM  transaction IDs or addresses
Post
Topic
Board Development & Technical Discussion
Re: P2PKH Address Pairs with Reused Nonce k
by
sdfasdf
on 25/03/2025, 05:39:06 UTC
Quote from: peakyclin77 on March 24, 2025, 10:55:14 PM
I would like to retrieve all the Pk in order to determine if an LLL attack could be effective for the concerned keys. In this specific case, how can I retrieve the Pk, please? I always manage to obtain Pk2, but not Pk1.

Trx 1
Private key 1
R= 1ecab5908a6a6e5715426b9a3a24f48fab3ace6ee410e297a792ecefd98e5b20

Trx 2 :
Private key 2
R= 1ecab5908a6a6e5715426b9a3a24f48fab3ace6ee410e297a792ecefd98e5b20

Trx 3 :
Private key 2
R= 1ecab5908a6a6e5715426b9a3a24f48fab3ace6ee410e297a792ecefd98e5b20


Please reply to me. I am asking for the original transactions: Trx 1, Trx 2, and Trx 3. Why are you not sharing this?
Post
Topic
Board Development & Technical Discussion
Re: P2PKH Address Pairs with Reused Nonce k
by
sdfasdf
on 24/03/2025, 01:06:47 UTC

@peakyclin77
Can you share the transaction ID and P2PKH address pairs with the reused nonce k?

However, I have a few questions and points for clarification:

Nonce Recovery: Could you elaborate on the method for recovering the private keys from the signatures that reused nonces? Are there specific algorithms or techniques you recommend for this?
Lattice Attack Viability: You mentioned uncertainty about the order of the fixed bits and the viability of a lattice attack. Do you have any insights or resources that could help clarify this aspect?
Post
Topic
Board Development & Technical Discussion
Re: P2PKH Address Pairs with Reused Nonce k
by
sdfasdf
on 23/03/2025, 06:56:54 UTC
Quote from: amaclin1 on Today at 06:38:49 AM
Quote from: peakyclin77 on Today at 04:05:04 AM
So, I have converted all the r values into binary and compared each one. Here are the results. These are the r values from the signatures of the address containing just over 2 BTC. Is the number of bits sufficient?
In my example above the 'Comparison between rx and ry' is 256/256
(of course, I can make any ratio below 256/256)
It is not possible to recover priv and k.

You need to mention the address and transaction ID. send me DM
do you think the number of bits is sufficient?
Post
Topic
Board Development & Technical Discussion
Re: P2PKH Address Pairs with Reused Nonce k
by
sdfasdf
on 23/03/2025, 06:34:14 UTC
Quote from: peakyclin77 on Today at 04:05:04 AM
So, I have converted all the r values into binary and compared each one. Here are the results. These are the r values from the signatures of the address containing just over 2 BTC. Is the number of bits sufficient?


Comparison between r1 and r2:
Number of fixed (common) bits: 132 / 256
Ratio of fixed bits: 0.5156
--------------------------------------------------
Comparison between r1 and r3:
Number of fixed (common) bits: 125 / 256
Ratio of fixed bits: 0.4883
--------------------------------------------------
Comparison between r1 and r4:
Number of fixed (common) bits: 131 / 256
Ratio of fixed bits: 0.5117
--------------------------------------------------
Comparison between r1 and r5:
Number of fixed (common) bits: 132 / 256
Ratio of fixed bits: 0.5156
--------------------------------------------------
Comparison between r1 and r6:
Number of fixed (common) bits: 121 / 256
Ratio of fixed bits: 0.4727
--------------------------------------------------
Comparison between r1 and r7:
Number of fixed (common) bits: 136 / 256
Ratio of fixed bits: 0.5312
--------------------------------------------------
Comparison between r2 and r3:
Number of fixed (common) bits: 115 / 256
Ratio of fixed bits: 0.4492
--------------------------------------------------
Comparison between r2 and r4:
Number of fixed (common) bits: 125 / 256
Ratio of fixed bits: 0.4883
--------------------------------------------------
Comparison between r2 and r5:
Number of fixed (common) bits: 140 / 256
Ratio of fixed bits: 0.5469
--------------------------------------------------
Comparison between r2 and r6:
Number of fixed (common) bits: 125 / 256
Ratio of fixed bits: 0.4883
--------------------------------------------------
Comparison between r2 and r7:
Number of fixed (common) bits: 120 / 256
Ratio of fixed bits: 0.4688
--------------------------------------------------
Comparison between r3 and r4:
Number of fixed (common) bits: 134 / 256
Ratio of fixed bits: 0.5234
--------------------------------------------------
Comparison between r3 and r5:
Number of fixed (common) bits: 131 / 256
Ratio of fixed bits: 0.5117
--------------------------------------------------
Comparison between r3 and r6:
Number of fixed (common) bits: 122 / 256
Ratio of fixed bits: 0.4766
--------------------------------------------------
Comparison between r3 and r7:
Number of fixed (common) bits: 129 / 256
Ratio of fixed bits: 0.5039
--------------------------------------------------
Comparison between r4 and r5:
Number of fixed (common) bits: 133 / 256
Ratio of fixed bits: 0.5195
--------------------------------------------------
Comparison between r4 and r6:
Number of fixed (common) bits: 134 / 256
Ratio of fixed bits: 0.5234
--------------------------------------------------
Comparison between r4 and r7:
Number of fixed (common) bits: 137 / 256
Ratio of fixed bits: 0.5352
--------------------------------------------------
Comparison between r5 and r6:
Number of fixed (common) bits: 129 / 256
Ratio of fixed bits: 0.5039
--------------------------------------------------
Comparison between r5 and r7:
Number of fixed (common) bits: 132 / 256
Ratio of fixed bits: 0.5156
--------------------------------------------------
Comparison between r6 and r7:
Number of fixed (common) bits: 131 / 256
Ratio of fixed bits: 0.5117
--------------------------------------------------


You need to mention the address and transaction ID. I can help you with that.

Post
Topic
Board Development & Technical Discussion
Re: Bitcoin
by
sdfasdf
on 12/03/2025, 08:09:58 UTC

https://bitcointalk.org/index.php?topic=5534342.msg65136373#msg65136373


bitcoin Miner
│
├── Network Layer (JSON-RPC/Stratum)
│   ├─ Get block templates # i don't know
│   └─ Submit found blocks # i don't know
│
├── Mining Core                # i know
│   ├─ Header construction# i know
│   ├─ Nonce iteration         # i know
│   └─ Hash validation         # i know
│
└── Transaction Management     # i know
    ├─ Coinbase TX generation   # i don't know
    └─ Merkle root calculation   # i know

Hi, can you help me with generating a Coinbase transaction using Python code? Please provide a real example.
Post
Topic
Board Development & Technical Discussion
Re: Looking for a reference to specific examples of BTC mining calculation
by
sdfasdf
on 06/03/2025, 04:35:40 UTC
Quote from: gt.townsend on Today at 01:49:53 AM
Well, I'm not out of the woods yet. Having taken data from https://learnmeabitcoin.com/ I now realize that I can't tell how it relates to my captured mining data. For example, when I see the table of TX hashes in the table on the website example, does the endian-ness match how they look in the JSON strings from the miner/pool? There are still too many pieces and unknown details, and too many possible things to reverse or not to reverse, so without more details I STILL can't resolve this. I've decided to just post the pool/miner exchange that led to a accepted packet and hope that SOMEONE who sees this feels like seeing if they can put it all together in a way that gives a block header that hashes to a reasonable hash. I've removed all traffic except that relevant to the successfully mined share. However, the exchanges are probably not in order. Here's what I got:

The miner subscribes:
{"id": 3, "method": "mining.subscribe", "params": ["Antminer S19j Pro+/Fri Apr 14 21:39:16 CST 2023"]}



The pool responds:
{"id":3,"result":[[["mining.notify","00"],["mining.set_difficulty","00"]],"00",7],"error":null}
ExtraNonce1: '00',ExtraNonce2_size: 7,


The miner asks to authorize:
{"id": 5, "method": "mining.authorize", "params": ["1AGf9BSutC5ZAnMXi8rvE6nxoaVv4rYfNa.018", "x"]}

The pool responds:
{"id":5,"result":true,"error":null}

Pool offers job to miner:
{"id":null,"method":"mining.notify","params":["3782626","f29143edc62458e69f1a5661f85d2cdff4aeff9000008ac30000000000000000","01000000010000000000000000000000000000000000000000000000000000000000000000fffff fff5a032f840d1d506f7765726564206279204c75786f72205465636868005f002a971a59fabe6d 6d648fad0e94f875d4783a1d2b146e0fa869052d181b79a88ebc54783aeda6018e1000000000000 00000010666","ffffffff05220200000000000017a914bf73ad4cf3a107812bad3deb310611bee49a3c79871a14c 1120000000017a914056adde53ebc396a1b3b678bb0d3a5c116ff430c870000000000000000266a 24aa21a9ed23ed3159409e966bff9642d36a658a385d5b655b0ba0bbba8d8b9317ce9a841500000 000000000002f6a2d434f524501a21cbd3caa4fe89bccd1d716c92ce4533e4d4733f459cc4ca322 d298304ff163b2a360d756c5db8400000000000000002b6a2952534b424c4f434b3a5033e57db45 8230515b003ad6b37755e76755337c12a9d8efd024916006f4f1500000000",["298563959d824c769c90df6880153ffe37ce692f40c86030f8da46072883ca98","713f3880adf3ec99241e10773c5994e0173631b23013be3a406423744523b5cb","d2cedcb2598099f5155c70f3964c8b9983d6bacdeae094a0c125eee2826332af","cd0308e9611464d808fc0cc7cd7a5220e7db837d27f8753ddf7ba1cf0e1004c7","43d98cfae83c979cb52376012ac6087c566b48e5b13c1e1fffbad82ab1ef429a","86c27c93418feac302f2fa49165314470c1c98fb989b7dd0712cba3c7ae515c9","fa5d9bd36f07cd05d7c38b37e5dcb18a4ff5a1c5f137c6c03f97acce091b4770","05b0ee676903b07295f97c2833348101368d5f0f0039fde81e35f3067df03278","4fe266926aab2d9e481aa79ab081b2953fb043c873f8111ec171673aafeb3981","96511215a92f1011bdfae46a4e2b86359571a72f1beaa5f795abb7493fbe4206"],"20000000","17028bb1","67c28154",false]}

Miner submits a share:
{"params": ["1AGf9BSutC5ZAnMXi8rvE6nxoaVv4rYfNa.018", "3782626", "ec100000000000", "67c28154", "16384721", "09b66000"], "id": 19, "method": "mining.submit"}

The pool responds:
{"id":19,"result":true,"error":null}
==========================================
{
  "params": [
    "1AGf9BSutC5ZAnMXi8rvE6nxoaVv4rYfNa.018",  // Username (Bitcoin address + worker name)
    "3782626",                                // Job ID
    "ec100000000000",                         // Extranonce2
    "67c28154",                               // Time
    "16384721",                               // Nonce
    "09b66000"                                // Extra nonce (optional, rarely used)
  ],
  "id": 19,                                   // Request ID
  "method": "mining.submit"                   // Method name
}


pool offers job to miner
{
  "id": null,                          // Identifier for the request (null means no specific ID)
  "method": "mining.notify",           // Method being called (notifies miners of a new block)
  "params": [                          // Parameters for the mining job
    "3782626",                         // Job ID (unique identifier for this mining job)
    "f29143edc62458e69f1a5661f85d2cdff4aeff9000008ac30000000000000000", // Previous block hash
    "01000000010000000000000000000000000000000000000000000000000000000000000000fffff fff5a032f840d1d506f7765726564206279204c75786f72205465636868005f002a971a59fabe6d 6d648fad0e94f875d4783a1d2b146e0fa869052d181b79a88ebc54783aeda6018e1000000000000 00000010666", // Coinbase transaction (block reward + fees)
    "ffffffff05220200000000000017a914bf73ad4cf3a107812bad3deb310611bee49a3c79871a14c 1120000000017a914056adde53ebc396a1b3b678bb0d3a5c116ff430c870000000000000000266a 24aa21a9ed23ed3159409e966bff9642d36a658a385d5b655b0ba0bbba8d8b9317ce9a841500000 000000000002f6a2d434f524501a21cbd3caa4fe89bccd1d716c92ce4533e4d4733f459cc4ca322 d298304ff163b2a360d756c5db8400000000000000002b6a2952534b424c4f434b3a5033e57db45 8230515b003ad6b37755e76755337c12a9d8efd024916006f4f1500000000", // Merkle root (hash of all transactions)
    [
      "298563959d824c769c90df6880153ffe37ce692f40c86030f8da46072883ca98", // Transaction hash 1
      "713f3880adf3ec99241e10773c5994e0173631b23013be3a406423744523b5cb", // Transaction hash 2
      "d2cedcb2598099f5155c70f3964c8b9983d6bacdeae094a0c125eee2826332af", // Transaction hash 3
      "cd0308e9611464d808fc0cc7cd7a5220e7db837d27f8753ddf7ba1cf0e1004c7", // Transaction hash 4
      "43d98cfae83c979cb52376012ac6087c566b48e5b13c1e1fffbad82ab1ef429a", // Transaction hash 5
      "86c27c93418feac302f2fa49165314470c1c98fb989b7dd0712cba3c7ae515c9", // Transaction hash 6
      "fa5d9bd36f07cd05d7c38b37e5dcb18a4ff5a1c5f137c6c03f97acce091b4770", // Transaction hash 7
      "05b0ee676903b07295f97c2833348101368d5f0f0039fde81e35f3067df03278", // Transaction hash 8
      "4fe266926aab2d9e481aa79ab081b2953fb043c873f8111ec171673aafeb3981", // Transaction hash 9
      "96511215a92f1011bdfae46a4e2b86359571a72f1beaa5f795abb7493fbe4206"  // Transaction hash 10
    ],
    "20000000",                        // Block version (format of the block)
    "17028bb1",                        // Network difficulty target (how hard it is to mine)
    "67c28154",                        // Current time (Unix timestamp)
    false                              // Clean flag (false means the block may include unconfirmed transactions)
  ]
}



20000000  # Version
f29143edc62458e69f1a5661f85d2cdff4aeff9000008ac300000000000000000  # Previous Block Hash
[Merkle Root (computed from coinbase & merkle branches)]  # Placeholder
67c28154  # Timestamp
17028bb1  # Bits (Difficulty Target)
16384721  # Nonce




Name                   Usage in Block Construction
Extranonce1             Used in coinbase transaction.
Extranonce2             Used in coinbase transaction.
Username                Embedded in the coinbase transaction.
Job ID                  Included in the share submission.
Previous Block Hash     Used in block header.
Coinbase1               Combined with extranonce1 and extranonce2.
Coinbase2               Combined with extranonce1 and extranonce2.
Merkle Branches   List    Used in block header.
Timestamp (time)   Used in block header.
Bits                    Defines the maximum valid hash for the block.
Nonce                   Used in block header.
Extra Nonce             Not always used in hashing, but included in submission.




"I am also a beginner in writing Bitcoin mining code in Python. I know Python is slow, but I need to write a full Bitcoin mining program in Python. Can you share your code? I need to learn."

"How do I get the correct block template to start mining, and if I successfully find a block, how do I send and receive my reward?"