Bitcoin Forum
May 29, 2024, 04:09:19 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 2 [3]
41  Bitcoin / Development & Technical Discussion / Re: Odd or even? on: January 19, 2022, 09:04:31 AM
Good day!

I think  that answer is NO, but maybe..

Is there any ways to understand is private key of known public key odd or even? Maybe any mathematician operations with public keys may helps?

Thank you!

If you manage to guess any piece of information (parity , range ,bias,  divisibility by a number etc...) of a private key with his public key  (or a bunch of public keys), secp256k1 will  be broken and bitcoin too.

We are pretty sure (99.9999% but not 100%) that is impossible and the generated public key (EC point)  of a specific private key seems to be perfectly random an perfectly distributed.

Fanch
42  Bitcoin / Development & Technical Discussion / Re: Recovery process on: January 19, 2022, 08:43:00 AM
Hello.
I have been trying to recover my wallet with about 180BTC almost for one year.
I was ”clever” enough to create a wallet with SHA256 custom string entry, and didn’t bother saving neither SHA256 result of it nor the private key WIF. I had it for years on my computer. But the computer crashed and I am now unable to remember what the string entry was. However, I know what keys I used but cannot remember the pattern.

I generate hashes from various patterns, as described above, and enter the hash results into https://www.bitaddress.org/ under “Wallet Address” and then try to import the private WIF into a new wallet. However it is a very slow process. Is there any tool/website that can create multiple private WIF keys from numerous hash entries?

Please, refrain yourself from sending me private messages in order to "help" me, reply only here in the public thread. Thanks.

Hello,
Have you sucess to recover your sha256 wallet?
In case of not i can propose you the help of my own software.
Ive optimised it to be as fast as possible.

It can try around 50Mega keys (sha256 brainwallet) per seconds on a rtx 3070.

Btcrecover can only kilo k /sec

If you want I can help you to recover your funds.

Fanch
43  Bitcoin / Development & Technical Discussion / Re: Pollard's kangaroo ECDLP solver on: January 11, 2022, 01:57:25 PM
Hi
I can eventually convert this code using  my own secp256k1 library for CUDA (based on Jean Luc Pons Kangaroo ).

It can achieve up to 70M scalar mult /sec on a rtx 3070.

A python implementation with pycuda can be do easily

But sorry for this trivial question :
What the purpose of this script?

Regards

Fanch

using 120 puzzles public key to generate a lot of keys and use that script random the more keys the better the chance to hit one
I just don't know if it can be generated with 1 public key more keys if so, it can be useful

I've redesigned it a bit now, I should , 2x faster for python


Hi

I already think about this method of searching for a collision between a temporary key (for example every intermediate wild kangaroo jump) and a lookup in a  hashtable of precomputed  random key in the range of puzzle 120.

Let-s do some math to show if it is realistic or not...

Imagine that you will precompute an huge hashtable (or a bloom filter) of 256 Gigas entries (or 256Giga  keys picked up at random in the puzzle 120 interval)

Forget the fact that this table will occupe several TerraBytes of RAM and that the lookup time will increases with the size of the hashtable (less true for a bloom filter look up).

The formula which defines the probability of finding a particular piece among N pieces at the end of n draw without replacement, is as follows:

P=1-(1-1/N)^n

we can replace 1/N by (number_entries_in_hashtable/interval_of_puzzle_120) =  256*10^9/(2^120-2^119) = 3.85e-25


We fixed  for example P=0.5 (means a probability of having an hit of 50%)

Let's calculate n for such P=0.5

0.5=(1-1/N)^n

a=b^n => n=ln(a)/ln(b)

n=ln(0.5)/ln(1-3.85e-25) = 1.8e24
if your GPU can do 1 billion  jumps (and lookup at the same time) per second (typically the speed of Jean-Luc pons program with a good GPU)

You will have to wait 1.8e24/1e9 = 1.8e15 seconds or  57 Millions of years before having 50% of having an hit...

Hopeless..., even if you uses a bigger hashtable or a powerfull GPU cloud.


The main problem of this approach is that you don't  profite of the birthday paradox used in the kangaroo solver because you look for in a predefined list.

Regards

Fanch
44  Bitcoin / Development & Technical Discussion / Re: Pollard's kangaroo ECDLP solver on: January 10, 2022, 09:02:09 AM
Hi
I can eventually convert this code using  my own secp256k1 library for CUDA (based on Jean Luc Pons Kangaroo ).

It can achieve up to 70M scalar mult /sec on a rtx 3070.

A python implementation with pycuda can be do easily

But sorry for this trivial question :
What the purpose of this script?

Regards

Fanch
45  Bitcoin / Development & Technical Discussion / Re: Reused R values on: March 23, 2021, 09:22:34 PM
I have seen an address where two transactions share similar r values and similar s values. I have once calculated a private key for a bitcoin address with two similar r values and a different s values. But this one has similar r values and similar s values.

In  this case where R1=R2 and S1=S2 It's impossible to recover the private key. And it probably come from an invalid TX because in the bitcoin protocol signature you might not have two S identical

But there is different case where you can recover private key from bad use of R.

if you find for the same address two TXS with the same R and different S the private key can be easily recover with a simple formula. Before that you have to recover the Z parameter (hash of the previous tx output). If you have the private key you can easily find the nonce  (k) that generate the R (supposed to be random).


After if you find an second address using the same R than above (even in only one TX). you will be able to recover the second privkey.

this case of R reusing is only possible if a issue was made on the creation of the TX
for example:
bad number random generator.
bad implementation of a TX by a developper who coded tx 'by hand'.


But as you know,  knowing a private key doesn't mean than the bitcoin are yours (in a ethical way).

 
46  Bitcoin / Development & Technical Discussion / Re: Pollard's kangaroo ECDLP solver on: March 21, 2021, 08:41:57 PM
So you said you used 4 cores, how many "kangaroos" per core/thread were you running?

one kangaroo per core.

47  Bitcoin / Development & Technical Discussion / Re: Pollard's kangaroo ECDLP solver on: March 21, 2021, 08:23:13 PM

So each tame or wild thread, must jump, check for dp, if dp send to hashtable and then jump again, if no dp, jump again, rinse and repeat.

Yes !

In your test, you merely walked through 1 billion random points, correct?

1 billions points of random walk determined by the formula :
jD=[G,2*G,4*G...2^n-1*G]
 tamePos[j+1] =  tamePos[j] + jD[tamePos[j].x % n]    (like in Jean-Luc Pons algorithm explanation) j
48  Bitcoin / Development & Technical Discussion / Re: Pollard's kangaroo ECDLP solver on: March 21, 2021, 07:56:45 PM
So your speed (30MKey/s) does not include actually searching for/finding and writing/storing distinguished points to RAM/file?

Exactly, but i'don't think it will decreases dramatically the performance.

in the way i'm imagine the system, the clients (lots of ARM CPUs) will be only dedicated to be wild or tame kangaroo and to performs pure increments in the random walk.

If a distinguished point is found (i've to find a way to  be faster as possible) : example (AND mask beetween the first   of the 5 limbs (5*52bits)of X  and the desired DP,
 the client   send the X coordinate through a socket to the centralized server (computer with and hashtable checking continuously if a collision is found between received x coordinate and previously ones ).
I think it will  not slow significantly the computing because a client send a message to the server  only 1 on 2^DP times on average and a the stop of computing during the socket communication can be optimised to be fast.
 
49  Bitcoin / Development & Technical Discussion / Re: Pollard's kangaroo ECDLP solver on: March 21, 2021, 06:42:39 PM


If you manage to push it a little over 30MKeys/s (like by using Neon instruction set) then you can match GPU performance.

In fact this speed is achieved with a modified version of the secp256k1 library of bitcoin core where every verification instructions have been removed for field and group function.
The library field_5*52.h  (instead of 10*26 for x86 cpu) (limbs registers) is automatically include for 64bits architecture and you've right it's maybe 10x faster.

I will study the NEON instructions to improve but it will be difficult because this benchmark doesn't include the DP detection code.
It's only a pure random walk benchmark on 1 Billion points.

 
50  Bitcoin / Development & Technical Discussion / Re: Pollard's kangaroo ECDLP solver on: March 21, 2021, 05:29:32 PM
Hi everybody,
I'm writing a  light beta library in C  to run Pollard kangaroo algorithm on ARM64 CPU.

I am at the very beginning of this project but i am able to do benchmark.

when the library will be functionnal i will posted it on github.

the library (a shared object file) will be callable by python with ctypes module
The herds  of kangaroos will be controlled directly with python (for convenience and ease).
The idea is to have a lot of clients running on ARM64 low cost CPU to compute parallelized secp256k1 points additions  .
The memory (DP  points of a client) will be returned with a client-server socket data transfer (server will have the main hashtable of DP ) as the Kangaroo software from Jean-Luc Pons.

The first benchmark on ARM (Raspberry PI 400 without overclocking ) are better than I expected (around 30MKeys/s with 4 cores).

What do you think about this performance ?
Do you know if there is a very low cost card (mini PC) with ARM CPU (similar to raspberry pi compute module 4 see link below)  to do the work (in a parallelized way) and see if the ratio (computing power)/price might be better compared to the latest GPU CUDA Compatible graphics card.

https://www.raspberrypi.org/products/compute-module-4/?variant=raspberry-pi-cm4001000



51  Bitcoin / Development & Technical Discussion / Re: Pollard's kangaroo ECDLP solver on: March 16, 2021, 03:40:57 PM
AWS has some rentable FPGAs, but it'll be incredibly hard finding an FPGA developer.

Ok thanks i' don't know that, (amazon EC2 F1 on AWS)

I made some search about FPGA performance on secp256k1 operations.

https://github.com/ZcashFoundation/zcash-fpga/blob/master/zcash_fpga_design_doc_v1.4.2.pdf

this paper (from Zcash fondation) presents some benchmarks of a well optimised group operation on secp256k1 implementating on an AWS FPGA (Zcash has the same curve than bitcoin).

Point addition is "only" about (1.9M op/s).
maybe it is possible to optimise it for the kangaroo algorithm but we are far away from the Giga op / s with the latest GPU.

 
52  Bitcoin / Development & Technical Discussion / Re: Pollard's kangaroo ECDLP solver on: March 15, 2021, 09:55:28 PM
Quote
Maybe you can look at it from a different angle then trying to use the same concept that is used for mining and the use of ASIC/FPGA for these tasks.
It does not have to be 256 bit integers, it only has to be 256 bit integers if you are trying to travel to your public point that belongs to your known 256 bit private key.
You will visit a lot of intermediate points, which all correspond to valid bitcoin addresses on your way to bit 256.
It's possible that you visited some point/address at for example bit 122 that had 100 BTC in it, but you will never know it if you don't look for it and just skip it and discard the data.
But make sure that you understand that the nearest public point, if you are not trying to solve a known 256 bit key, is not 256 bits away but just one bit away since it is K+1 or Q+1G.
So that is 1 bit and not 256 bits.
Make sure you understand this so that you can use it to optimize your ideas, when it comes to collisions it can also be modified from SECP256K1 to SECP1K1 so realize that its not always 256 or an average of 128 point calculations there is a difference between talking about a specific point, and talking about any point.
A specific point will need to go through the entire loop of 256 bits, but any point is just any point on which you can throw any number of *G's.
For example if the (first) last bit of your private key is a 1 then this will rule out the entire key space below that number and it's only one step to get into that range, not 256 or 128

Sorry but i'm not sure to fully understand what you said about bits (1 vs 256).
I understand about the kangaroo algorithm that it forces you to perform a group addition at every jumps of every kangaroo of the herd (wild or tame)
in affine coordinate you have to calculate the next jump with this function (whatever the range size)

X(i+1)=X(i)+deterministic_random_walk[G,2G,4G...]

m = (y1 - y2) * inverse_mod(x - xG,P)
xQ = pow(m,2,P) - x1 - xG
yQ = y1 + m * (xQ - x1)
Q = (xQ %P -yQ %P)

knowing that P is about 2^256, you cannot reduce the size of the integers used in this function
below 256bits because the result coordinate of point Q will be (about randomly) between
(x,y) = ([1 -- 2^256],[1 -- 2^256])
and u need all this information to compute the next point (whatever DP bits used)

it is this costly addition function that i want to implement in my hypothetical ASICs of FPGA's chips (parrellised).

Storing the X coordinates (masked with DP) of every jump  (calculate with the dedicated devices) in a hash table could be achieved with a centralized computer with a lot of ram.
53  Bitcoin / Development & Technical Discussion / Re: Pollard's kangaroo ECDLP solver on: March 15, 2021, 01:38:02 PM

Quote
To solve #120 you need about 2^60.5 group operations.
If GPU speed is 4 billion op/s (~2^32), then it will takes 2^28.5 seconds to solve.
2^28.5 seconds is ~4393 days
4393 days / 8 GPUs = ~549 days to solve.

There calculations on Kangaroo Github, that #120 will require ~2 months with 256x V100 (~2 billion op/s each)

Ok thanks for the correction so the average cost will be

549/7 *1000 about 78000 $ (not profitable ;( )

Quote
ASIC == Application Specific Integrated Circuit.

It's baked specifically for one task (SHA256) and can not be easily made to do something else.

Yes I know that but i want to know if it feasible to develop such of "specific circuit" by a man or in team in is garage ( Wink )for a relative low cost  ?

this study gives diagrams for implementing SECP256K1 addition/multiplication/modular inversion on 256bits integers on a FPGA.

https://cse.iitkgp.ac.in/~debdeep/osscrypto/psec/downloads/PSEC-KEM_prime.pdf

But i dont know what sort of performance it can have on FPGA (op/s) ?
If it is fast for relative low cost parrellised FPGA chips can may be an alternative to GPU??
Maybe is it possible to "convert" this diagram to develop an ASIC.?

54  Bitcoin / Development & Technical Discussion / Re: Pollard's kangaroo ECDLP solver on: March 15, 2021, 09:52:24 AM
Hello everybody,

I am newly interested in the resolution of puzzle # 120 (119 bits private key)
pubkey : 02CEB6CBBCDBDF5EF7150682150F4CE2C6F4807B349827DCDBDD1F2EFA885A2630 (hash 160: 17s2b9ksz5y7abUm92PCTzK8jEl5y7abUm92PCTzK8jEl5y7abUm92cHZK8jElc).
a short calculation shows the difficulty of it with the excellent (probably the most optimised) GPU  solver from Jean-Luc Pons.


n=2*sqrt(0x7FFFFFFFFFFFFFFFFFFFFFFFFFFFF-0x40000000000000000000000000000)

best_GPU_card_speed=4*10**9 #(I read that RTX3090 can achieve around 4Giga Keys /s with Kangaroo ECDLP SOLVER)
excepted_days=n/best_GPU_card_power/86400

so ... around 833 excepted days! 

if u consider a rent of gpu cloud at the minimal price (around 1000$ per week for 8x3090) u can expected to resolve it in 100 days (about 15 weeks)
15*1000=15000$ (very rentable in comparison of 60000$/BTC market price) (1.2*60000 72000$ on wallet) 

But u forget that
-that someone else can be faster than u,
-u can be unlucky because the Kangaroo Lambda algorithm is a probabilistic algorithm.
-Bitcoin price can dip while u are in!

Are my calculation are correct?

Have u heard of an implementation of SEC256K1 addition on FPGA or ASIC (ASIC miner have only optimised implementation for sha256)?

Regards

Fanch
Pages: « 1 2 [3]
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!