Search content
Sort by
Showing 20 of 48 results by Kpot87
have anybody found relationship between pvk 1
and new x coordinats
xcubed = 0x4866d6a5ab41ab2c6bcc57ccd3735da5f16f80a548e5e20a44e4e9b8118c26eb
x1 = 0xc994b69768832bcbff5e9ab39ae8d1d3763bbf1e531bed98fe51de5ee84f50fb
x2 = 0xbcace2e99da01887ab0102b696902325872844067f15e98da7bba04400b88fcb
x3 = 0x79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798
?
and new x coordinats
xcubed = 0x4866d6a5ab41ab2c6bcc57ccd3735da5f16f80a548e5e20a44e4e9b8118c26eb
x1 = 0xc994b69768832bcbff5e9ab39ae8d1d3763bbf1e531bed98fe51de5ee84f50fb
x2 = 0xbcace2e99da01887ab0102b696902325872844067f15e98da7bba04400b88fcb
x3 = 0x79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798
?
Quote
Code:
s2 = 0x352b52b52b52b52b52b52b52b52b52b4e7c1db2bf914fdd54560dc7fb517156e
^repeated pattern^ |<---- 130 bits --->|
^repeated pattern^ |<---- 130 bits --->|
thank you!
Quote
It is a proof that someone had private key to puzzle 66 year before it was officialy solved.
No, it is not. If you have any address for some compressed public key, then you can safely convert P2PKH into P2WPKH, and it will be standard. For example:Code:
P2PKH: 1111111111111111111114oLvT2
Script: 76a914000000000000000000000000000000000000000088ac
P2WPKH: bc1qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq9e75rs
Script: 00140000000000000000000000000000000000000000
And if you know, that instead of those zeroes in the middle, you have other hex digits, then you can just copy-paste them, and change address type, as you wish. Of course, P2PKH works for both compressed and uncompressed keys, but P2WPKH are standard only for uncompressed ones.Script: 76a914000000000000000000000000000000000000000088ac
P2WPKH: bc1qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq9e75rs
Script: 00140000000000000000000000000000000000000000
What are you talking about ?!
To make a valid transaction you need a private key. Period.
The transaction we are talking about was made from bech32 address created from the same private key that puzzle 66 address containing funds. And it was created about a year ago from now.
It was income transaction but in other type of address!!! I'm personally not affected by #66 being solved because even though I've been at it for a year or so, I looked through all my theories, all my notes, all my scripts, and not one of them were even close to the solved keyspace/binary/hex/decimal.
Pub Addr: 13zb1hQbWVsGTfNXwP3Wtk7rqq3vA6vvfa
Priv (WIF): p2pkh:KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qZdhJgPUu3yfb2fwVhmH
Priv (HEX): 0x00000000000000000000000000000000000000000000000270733ED8D4660295
What is this, that works with gpu?
This is kangaroo, you can find it in this repo:
https://github.com/JeanLucPons/Kangaroo
As you see, it's works well with gpu.
So you couldn't use It tô get 130°?
How long It will take?
Avg 463.6y with single RTX 3090 GPU (Kangaroo-256-bit).
I need approximately 464 GPUs to solve the problem in 1 year.
Shall I ask something? You said that if we run 1 3090 graphics card with the kangaroo program, it will be found in 463 years. Well, isn't it possible to find this earlier? What if we have a lot of luck? For example, can't we run the kangaroo program and find it within 1 hour?
This works for me
1.Download https://github.com/ChillMagic/MPIR-Binary
2.Download https://github.com/AntonKueltz/fastecdsa
3.rename mpir.h to gmp.h from MPIR-Binary-master\include and rename mpir.lib to gmp.lib from MPIR-Binary-master\lib\MD\x64\Release
4.Copy and paste gmp.lib C:\Program Files (x86)\Microsoft Visual Studio\20XX\BuildTools\VC\Tools\MSVC\XX.XX.XXXX\lib\x64
5.Copy and paste gmp.h C:\Phyton3\include or C:\Users\XXXXXXXX\AppData\Local\Programs\Python\include
6.Open CMD and cd to where you put your fastecdsa E:\Download\fastecdsa-master
7.when your cmd is in the directory type: python setup.py build
8.after installation type again: python setup.py install
1.Download https://github.com/ChillMagic/MPIR-Binary
2.Download https://github.com/AntonKueltz/fastecdsa
3.rename mpir.h to gmp.h from MPIR-Binary-master\include and rename mpir.lib to gmp.lib from MPIR-Binary-master\lib\MD\x64\Release
4.Copy and paste gmp.lib C:\Program Files (x86)\Microsoft Visual Studio\20XX\BuildTools\VC\Tools\MSVC\XX.XX.XXXX\lib\x64
5.Copy and paste gmp.h C:\Phyton3\include or C:\Users\XXXXXXXX\AppData\Local\Programs\Python\include
6.Open CMD and cd to where you put your fastecdsa E:\Download\fastecdsa-master
7.when your cmd is in the directory type: python setup.py build
8.after installation type again: python setup.py install
Re: lightweight database, for brute force using publickeys-32Mk =3.81MB(secp256k1)
Ok but how you image to work with bigger size of range, the nearest 2**130…? How much ram do you need to generate such equation ?
I don't image to work with bigger size of range.
At this level the problem in my opinion is to shrink the size of database. That's all.
To "cover" a 2**130 space, you need 2**65 keys with distance 2**65.
2**65 keys with 128 bits (at least) for each key means 2**73 bit = 2**70 bytes, 1 Billions of TB.
If you use the script of the OP, 2**65 keys = 2**65 bits = 2**62 bytes = 4 Millions of TB.
These are the numbers.
These script are made for fun, not to become rich.
Re: lightweight database, for brute force using publickeys-32Mk =3.81MB(secp256k1)
Code:
start_key = 2**49
num_public_keys = 2**50
bits_to_store = 64
bytes_to_store = bits_to_store//8
rate_of_key_to_generate = 2**20
num_public_keys = 2**50
bits_to_store = 64
bytes_to_store = bits_to_store//8
rate_of_key_to_generate = 2**20
Actually, I already figured it out, the difference is just 2**49)
2**49 / 2**20 = 2**29 keys stored in DB. 2**20 keys generated in search script against 2**29 keys generated in create_database script = 2**49 couples.
I presume that the probability of collision is not low with these numbers.
The script is not optimized, it is only a proof of concept. It needs some work.
Try with bits_to_store = 96, in this way the probability of collision is lower.
Ok but how you image to work with bigger size of range, the nearest 2**130…? How much ram do you need to generate such equation ?
Re: lightweight database, for brute force using publickeys-32Mk =3.81MB(secp256k1)
OP doesn't understand the program/script.
I used your single key check and it didn't even find a match.
Check it yourself:
With 4,000,000 keys in database I ran this for a single key check.
pk = 3093472814 - 62500
No results.
But I think I figured it out.
Whatever pk is landed on, whether random or increment, it has to be a multiple of the collision margin.
because if you run single key check using:
pk= 3093472814 - 3999936
pk= 3093472814 - 640
pk= 3093472814 - 64
you will get a match.
I'm even more lost now lol.
You just miss your key when substract 40000.000 in you DBI used your single key check and it didn't even find a match.
Check it yourself:
With 4,000,000 keys in database I ran this for a single key check.
pk = 3093472814 - 62500
No results.
But I think I figured it out.
Whatever pk is landed on, whether random or increment, it has to be a multiple of the collision margin.
because if you run single key check using:
pk= 3093472814 - 3999936
pk= 3093472814 - 640
pk= 3093472814 - 64
you will get a match.
I'm even more lost now lol.
in this way it is waste the time (your time).
if you want to understand the curve you need understand the algorithm for sign transaction.
example in this way for understanding the real algorithm of sign transaction:
privatekey = 4
nonce = 6
message_hash=2
after signing : we have r,s,z (remember z == message_hash)
so:
now you must : calculate u1,u2
def calc_u(r,s,z):
mod_s= modinv(s,n)%n
u1=mod_s*z%n
u2=mod_s*r%n
print("u1==",u1,"n-u1=",n-u1)
print("u2==",u2,"n-u2=",n-u2)
return u1,u2
result:
now generate :
result:
and: 57446123528476574921383425882760106825160817048876048499830450377360758406696 as u1 -> is real mod n as
thos tricks and little maths -> can break all transactions:)
happy hunting
ps. IF any question ask ( of course for money)
Hi, for what you calculate u1 and u2?in your exampleif you want to understand the curve you need understand the algorithm for sign transaction.
example in this way for understanding the real algorithm of sign transaction:
privatekey = 4
nonce = 6
message_hash=2
after signing : we have r,s,z (remember z == message_hash)
so:
Code:
r= 115780575977492633039504758427830329241728645270042306223540962614150928364886
s= 115784413730767153834193500621449522112098284939719838943229029456606672741370
z= 2
s= 115784413730767153834193500621449522112098284939719838943229029456606672741370
z= 2
now you must : calculate u1,u2
Code:
def calc_u(r,s,z):
mod_s= modinv(s,n)%n
u1=mod_s*z%n
u2=mod_s*r%n
print("u1==",u1,"n-u1=",n-u1)
print("u2==",u2,"n-u2=",n-u2)
return u1,u2
result:
Code:
u1== 57446123528476574921383425882760106825160817048876048499830450377360758406696 n-u1 = 58345965708839620502187559125927801027676747230198855882774712764157403087641
u2== 43534513736538953981439636033653927220128577877318440066344968976418891145496 n-u2 = 72257575500777241442131348975033980632708986401756464316260194165099270348841
u2== 43534513736538953981439636033653927220128577877318440066344968976418891145496 n-u2 = 72257575500777241442131348975033980632708986401756464316260194165099270348841
now generate :
Code:
for i in range(1,10):
k=(r*i+z)*modinv(s,n)%n
print("i=",i,"k==",k)
k=(r*i+z)*modinv(s,n)%n
print("i=",i,"k==",k)
result:
Code:
i= 1 k== 100980637265015528902823061916414034045289394926194488566175419353779649552192
i= 2 k== 28723061764238287460691712941380053412580408524438024249915225188680379203351
i= 3 k== 72257575500777241442131348975033980632708986401756464316260194165099270348847 -> this compare with n-u2
i= 4 k== 6
i= 5 k== 43534513736538953981439636033653927220128577877318440066344968976418891145502 -> this compare with u2
i= 6 k== 87069027473077907962879272067307854440257155754636880132689937952837782290998
i= 7 k== 14811451972300666520747923092273873807548169352880415816429743787738511942157
i= 8 k== 58345965708839620502187559125927801027676747230198855882774712764157403087653 -> this compare with n-u1
i= 9 k== 101880479445378574483627195159581728247805325107517295949119681740576294233149
i= 2 k== 28723061764238287460691712941380053412580408524438024249915225188680379203351
i= 3 k== 72257575500777241442131348975033980632708986401756464316260194165099270348847 -> this compare with n-u2
i= 4 k== 6
i= 5 k== 43534513736538953981439636033653927220128577877318440066344968976418891145502 -> this compare with u2
i= 6 k== 87069027473077907962879272067307854440257155754636880132689937952837782290998
i= 7 k== 14811451972300666520747923092273873807548169352880415816429743787738511942157
i= 8 k== 58345965708839620502187559125927801027676747230198855882774712764157403087653 -> this compare with n-u1
i= 9 k== 101880479445378574483627195159581728247805325107517295949119681740576294233149
and: 57446123528476574921383425882760106825160817048876048499830450377360758406696 as u1 -> is real mod n as
thos tricks and little maths -> can break all transactions:)
happy hunting
ps. IF any question ask ( of course for money)
Re: lightweight database, for brute force using publickeys-32Mk =3.81MB(secp256k1)
Regarding the scan script; if I use any subtract other than one, it always gets a false positive.
I've used subtract values from 16 up to in the thousands and always get a wrong result (false positive).
If you use a large subtraction number, the result shows up way out of the upper limit range.
Can you shed any wisdom as to why?
have you possible to generate DB more than 2**28? I've used subtract values from 16 up to in the thousands and always get a wrong result (false positive).
If you use a large subtraction number, the result shows up way out of the upper limit range.
Can you shed any wisdom as to why?
3 hours nothing changed? no file *.bin created... what can be wrong& @mcdouglasx
Re: lightweight database, for brute force using publickeys-32Mk =3.81MB(secp256k1)
Regarding the scan script; if I use any subtract other than one, it always gets a false positive.
I've used subtract values from 16 up to in the thousands and always get a wrong result (false positive).
If you use a large subtraction number, the result shows up way out of the upper limit range.
Can you shed any wisdom as to why?
have you possible to generate DB more than 2**28? I've used subtract values from 16 up to in the thousands and always get a wrong result (false positive).
If you use a large subtraction number, the result shows up way out of the upper limit range.
Can you shed any wisdom as to why?
Re: lightweight database, for brute force using publickeys-32Mk =3.81MB(secp256k1)
I think you are writing the ones and zeros as bytes, when you should be writing them out as bits.
Here's what you should do to make your program faster. set a counter like i to 0, and then each time you perform a subtraction, do byte_value |= 0 [or 1] << i; i = (i + 1) % 8. Then only do a write after every 8 iterations. Although, you can make the writing process even faster by waiting until you fill thousands of bytes like this, and then just write them all at once in one batch.
Here's what you should do to make your program faster. set a counter like i to 0, and then each time you perform a subtraction, do byte_value |= 0 [or 1] << i; i = (i + 1) % 8. Then only do a write after every 8 iterations. Although, you can make the writing process even faster by waiting until you fill thousands of bytes like this, and then just write them all at once in one batch.
This script speeds up the creation of the database.
Code:
#@mcdouglasx
import secp256k1 as ice
from bitstring import BitArray
print("Making Binary Data-Base")
target_public_key = "030d282cf2ff536d2c42f105d0b8588821a915dc3f9a05bd98bb23af67a2e92a5b"
target = ice.pub2upub(target_public_key)
num = 16000000 # number of times.
sustract= 1 #amount to subtract each time.
sustract_pub= ice.scalar_multiplication(sustract)
res= ice.point_loop_subtraction(num, target, sustract_pub)
binary = ''
for t in range (num):
h= (res[t*65:t*65+65]).hex()
hc= int(h[2:], 16)
if str(hc).endswith(('0','2','4','6','8')):
A="0"
binary+= ''.join(str(A))
if str(hc).endswith(('1','3','5','7','9')):
A="1"
binary+= ''.join(str(A))
my_str = bytes(BitArray(bin=binary))
binary_file = open('data-base.bin', 'wb')
binary_file.write(my_str)
binary_file.close()
import secp256k1 as ice
from bitstring import BitArray
print("Making Binary Data-Base")
target_public_key = "030d282cf2ff536d2c42f105d0b8588821a915dc3f9a05bd98bb23af67a2e92a5b"
target = ice.pub2upub(target_public_key)
num = 16000000 # number of times.
sustract= 1 #amount to subtract each time.
sustract_pub= ice.scalar_multiplication(sustract)
res= ice.point_loop_subtraction(num, target, sustract_pub)
binary = ''
for t in range (num):
h= (res[t*65:t*65+65]).hex()
hc= int(h[2:], 16)
if str(hc).endswith(('0','2','4','6','8')):
A="0"
binary+= ''.join(str(A))
if str(hc).endswith(('1','3','5','7','9')):
A="1"
binary+= ''.join(str(A))
my_str = bytes(BitArray(bin=binary))
binary_file = open('data-base.bin', 'wb')
binary_file.write(my_str)
binary_file.close()
but as @WanderingPhilospher says
This will depend on the amount of RAM you have, of course.
Hi! get this error
Traceback (most recent call last):
File "D:\BTC\lightweight-database\lightweight-database\binary_Db.py", line 20, in <module>
hc= int(h[2:], 16)
^^^^^^^^^^^^^^
ValueError: invalid literal for int() with base 16: ''
⭐ Merited by vjudeu (1)
Quote
I would like to know the relation between p and n, because it seems that G is irrelevant in the curve calculations.
I can even give you some code to get n-value, based on p-value, and the curve equation. Of course, it is the simplest brute-force, and it will stop working if you use it on bigger numbers, but it is simple enough to understand it, and implement in any programming language you want.Code:
#include <iostream>
int get_n_from_p(int p)
{
int n=1; //we start from n=1, and not n=0, because of the point at infinity
for(int y=0;y<p;++y)
{
for(int x=0;x<p;++x)
{
int y_square=(y*y)%p;
int x_cube=(x*x*x)%p;
int x_cube_plus_seven=(x_cube+7)%p;
if(y_square==x_cube_plus_seven)
{
++n;
}
}
}
return n;
}
int main()
{
for(int p=1;p<=1000;++p)
{
std::cout<<"p="<<p<<", n="<<get_n_from_p(p)<<'\n';
}
}
See? No generator is used there. Every single point is checked, and you can just create an image, and put a black pixel, if there is no point on a given curve, or put a white pixel, when you can find a match. This is basically what vjudeu did in his repository. As you can see, in this brute-force algorithm, there is no need to even pick any specific point, because all of them are checked.int get_n_from_p(int p)
{
int n=1; //we start from n=1, and not n=0, because of the point at infinity
for(int y=0;y<p;++y)
{
for(int x=0;x<p;++x)
{
int y_square=(y*y)%p;
int x_cube=(x*x*x)%p;
int x_cube_plus_seven=(x_cube+7)%p;
if(y_square==x_cube_plus_seven)
{
++n;
}
}
}
return n;
}
int main()
{
for(int p=1;p<=1000;++p)
{
std::cout<<"p="<<p<<", n="<<get_n_from_p(p)<<'\n';
}
}
ok? the question is how in 199x years it was possible to do it(brute-force). how this n and p was chosen? thanks