Offtop, how if your twist attack?

I have been learning about ECDSA ( r s z, public key ,private key ) for about 2 months

# 130 Although only 1  rsz  is  known , but 1000 rsz can be produced using the public key,  the nonce K value will be 240~256 bits

50% - nonce is 256 bit
25% - nonce is 254 bit
25% - nonce is 253~240 bit

However, more than 64 rsz must be leaked at the same time to leak more than 12 bits to use  lattice-attack

# 130  Public Key ( Fix  2024/06/25 )
0x633cbe3ec02b9401c5effa144c5b4d22f87940259634858fc7e59b1c09937852, 0xb078a17cc1558a9a4fa0b406f194c9a2b71d9a61424b533ceefe27408b3191e3

Address:    1Fo65aKq8s8iquMt6weF1rku1moWVEd5Ua

I create some rsz as #130 , these are address  "1Fo65aKq8s8iquMt6weF1rku1moWVEd5Ua"  and the public keys are #130 public key
 

https://bt.irlbtc.com/view/5394249.100

read it ....... garlonicon share his source code
Even if I have 100,000 puzzle #130 r , s, z
I still can't use lattice-attack crack ....Because the generated rsz and k values ​​are unknown....
I used my private key and public key to see nonce  K value ...

From the probability, more than 50% is a 256-bit nonce K value ~~ It must be 252 bit or less bit ......
Unless you can know from these 100,000 rsz which nonce k bits are less than 252 bit , and select 88 group for lattice attack...
This probability is lower than guessing any Bitcoin private key   

N = 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141

if N <= 252 bit , we can use  #130 public key to produce 70 ~ 100  fake rsz ,  and  ECDSA  will broken ~~~ Now, ECDSA is still safe

the same r value , we can recovery private key ........

but we are interested in recovering the private key of #puzzle 130 from a large set of r s z and public key ...

But we need to know the bits of  k ， from every set of r s z .........

if anyone can know the bits of k from every r s z and public key  ,  all bitcoin address that leaks the public key can recovery private key

Of course, currently only 252 bit k can be recovery by the lattice attack.

https://githubhelp.com/bitlogik/lattice-attack/issues/2 
The authors of the lattice-attack mentioned that they were also unable to crack more than k > 252 bits~~~

For the topic "down to 2 bits", note that we never found a private key using our LatticeAttack software below 4 know bits, hence the restriction put in place that prevent the user to run it with lower than 4 bits. But we never performed long running time. Using higher RECOVERY_SEQUENCE "effort" block size, combined with a loop "-l" can be a way to recover key with 3 or even 2 bits. That would just require long running times (several hours), and no guarantee of result.

I had edit my post ~~ fix it  #130
public key 0x633cbe3ec02b9401c5effa144c5b4d22f87940259634858fc7e59b1c09937852, 0xb078a17cc1558a9a4fa0b406f194c9a2b71d9a61424b533ceefe27408b3191e3

and Provide 5 sets of my own generated rsz for #130

# 130   rsz  1
r=0x56a37728d3036203ba57a2399ba282351b55e7b7a2660080a510732f373f18f8
s=0x6bf0c1501792f3184866f56a82b69ad17cb169105ed85350ca30f3e2070e032e
z=0x0042fe8868fbfa3d16b603af849bb81a35d6292651ab36a23af4c427d4265bf9

# 130   rsz  2
r=0x84812aade108ee63f12098f31e0819b36fcd4a4433fdbd29dbc8d94082e1a822
s=0xa7da5a2552d02a4551a23381fe4bcca9f1108d66cb0137712d9325d2a1fe4b4a
z=0x50825e90bcae246a62602d3719d895da1108545b3c09527ed1dbf599034cf0a2

# 130   rsz  3
r=0x1567a88d2dc54158afc135433f5bd7cb673a73ecd978626504fa7a972fc88eb0
s=0x0340b27310b89895c166c839b5a27fd6de1a271a8765de608c07e96539827850
z=0x503f919c88920407436211529abf8f8d2459d8aec963181dbaf822e20f162d0e

# 130   rsz  4
r=0x3facca914bf602c454b2e1332e4bd9db3482cdc648bc9f79328fed36de7babca
s=0xfe9797f9323c74e8b5d91937c4ea704f0a73e3aae536d8f051e7c77214a4a5a9
z=0xdde32a1d171f66168bc88211c5bbd1f0de2bc8aa504b70af8591f7619b6a3632

# 130   rsz  5
r=0x63444d8aa42965428ea68fa74976fe38772ba59e6e1b4f8682e6f6178ee4c1e9
s=0x33f53e75c58b289d094932407c4f1eac3156a0029c9a33f257485a0c3b5b497d
z=0xfe4573a2009e9f7985f8f366949757f001aaccc81da635ea3868c1d70b9a2e04

  1Fo65aKq8s8iquMt6weF1rku1moWVEd5Ua

You try bruteforce 02d7232c0eed9a80a6e53d74b57d80cd892816b46c69157f8e543ee76dc21f8410 ?

output:
HA:  e809a06f968e72e232e96f55e26f809d22d922681acca6904f12c4ba1b53018d
r1 = 0xd7232c0eed9a80a6e53d74b57d80cd892816b46c69157f8e543ee76dc21f8410
s1 = 0xe6665792427b98ebd93cd43f694e03383c84af34b00e5f471c5cec5a24541808
z1 = 0xc3479c8d5591597a4b12018ccacd0215528e584aa18125d63fac5c0c0c92588b
r2= 0xd7232c0eed9a80a6e53d74b57d80cd892816b46c69157f8e543ee76dc21f8410
s2= 0xe6665792427b98ebd93cd43f694e03383c84af34b00e5f471c5cec5a24541808
z2= 0xc3479c8d5591597a4b12018ccacd0215528e584aa18125d63fac5c0c0c92588b

r1 = r2 ,   s1 = s2 ,    z1 = z2 .......Your 2 rsz are from the same rsz  

Recovered Bitcoin public key: 023e42b3151f310f5f417f11b4c32d8360b22109dcc6432339243332b56cd596de
Bitcoin Address： 1ak61eAXk4bxNbovZuqh4f1PxBaf1VUBV
r=0x678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb6
s=0x24c8a42e8fe11d670633fa66ebedb1672c71a517a30cbbaa9e14f2d5a15a3783
z=0xe0f6c07e19eb2dfa2e0c3586a2a9f4b225dba10c353fc354baa2dabcc9d42051

---
Recovered Bitcoin public key: 03c79fa242694e3148c8d50e667010e0c221f6004d108692c5040ff139595ed081
Bitcoin Address： 1GLKrFmj8eUsHS7s91PTMh2L6rPtF1RzNj
r=0x678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb6
s=0x768a0e3b0cfb3c8d9b7899f59f480555176ef25eefa1e96d3ac575ba4ffe85fd
z=0x48ef5d298a862b6f74338ebb5281f5212d8221a2fd8cce827be72779bffd25dd

---
Recovered Bitcoin public key: 03c03657988e2baf31a1a1061a87fa3da20f166dc8a22c02658f6d325dec722d84
Bitcoin Address： 17aj9BWZyDTqr6UnK7LScoCHdsbFRT6LZG
r=0x678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb6
s=0xd17c5ed9fb37692cd152f381c4a3f16a896f96d26100310fe818d6963c402b25
z=0x1e6a32d38fb096d19ad46186c6299f82b7bfd5a92d0d3b17142e8ff18b75e358

I can't understand  special values

Which values? All values are special ;-)
First 3 signatures use Satoshi private key #1 as a nonce, but signed real messages (not random). Nobody noticed?
The fourth signature signs again real message, and with the same key also a private key of Puzzle #130 as input, there is no "why", that's an intention.

And finally the value of s2 shows the weakness of the private key here:

Well, thanks, I was too hasty this time.