Bitcoin Forum
April 28, 2024, 09:39:41 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 [37] 38 39 40 41 42 43 »
721  Bitcoin / Development & Technical Discussion / Re: secp256k1 library in pure assembly on: December 01, 2022, 12:33:33 PM
The main problem in secp256k1 is modulo p

Actually we only need a good framework to do operations with big numbers, this also using all the capabilities of modern CPU.

Regards.
722  Bitcoin / Development & Technical Discussion / Re: secp256k1 library in pure assembly on: December 01, 2022, 12:56:23 AM
I'm looking for library written in pure nasm/masm - assembly for x8086-64 (not arm) Intel version.

Write code in ASM is really hard, i have a long time without write anythin in ASM by my self the last code that check in ASM and edit just some lines was the libaesni for some of my old projects.

If there are any other developers interesting in write this code please let me know.
723  Bitcoin / Development & Technical Discussion / Re: How to split hex ranges in smaller parts on: November 25, 2022, 01:02:23 PM
It seems that alberto's slicer tool sometimes creates one more additional range than user input was. Only the first range pair matches always between both programs.

The parameters need to have the prefix 0x for hexadecimal numbers.

the ranges need to be divisible by the given number, if not it will create an extra range with some values outside of the given range.

And yes I spotted some bug in the ranges, I will solve it
724  Bitcoin / Project Development / Re: Keyhunt - development requests - bug reports on: November 25, 2022, 12:52:46 PM
In a small range, it seems the my program is faster than yours, on higher range the viceversa.

Yes I notice the same, this is really interesting I should check your code to see if i can learn something to boost the current speeds.

Good job!
725  Bitcoin / Project Development / Re: Keyhunt - development requests - bug reports on: November 25, 2022, 03:43:20 AM
How do you compute the speed?

If you search a 2^40 interval in 1 s you compute 1 Terakeys/s ?

How long it takes to scan a 2^64 interval (with 1 thread)?

According to your premise 2^40 interval (1,099,511,627,776 keys) in 1 Second yes is more of less @ 1 Terakey/s (1,000,000,000,000 )

To compute 2^64 we only need 2^24 times the time of (2^40) this is like 16,777,216 seconds or 4660 hours.

But why limit the speed to 1 Terakey per second?

The next is keyhunt with 8GB of RAM with a single thread:

Code:
albertobsd:~/keyhunt$ ./keyhunt -m bsgs -f tests/120.txt -b 120 -q -s 1 -R -S -k 512 -t 1
[+] Version 0.2.211117 SSE Trick or treat ¡Beta!, developed by AlbertoBSD
[+] Quiet thread output
[+] Stats output every 1 seconds
[+] Random mode
[+] K factor 512
[+] Thread : 1
[+] Mode BSGS random
[+] Opening file tests/120.txt
[+] Added 1 points from file
[+] Bit Range 120
[+] -- from : 0x800000000000000000000000000000
[+] -- to   : 0x1000000000000000000000000000000
[+] N = 0x100000000000
[+] Bloom filter for 2147483648 elements : 7361.33 MB
[+] Bloom filter for 67108864 elements : 230.04 MB
[+] Bloom filter for 2097152 elements : 7.19 MB
[+] Allocating 32.00 MB for 2097152 bP Points
[+] Reading bloom filter from file keyhunt_bsgs_4_2147483648.blm .... Done!
[+] Reading bloom filter from file keyhunt_bsgs_6_67108864.blm .... Done!
[+] Reading bP Table from file keyhunt_bsgs_2_2097152.tbl .... Done!
[+] Reading bloom filter from file keyhunt_bsgs_7_2097152.blm .... Done!
[+] Total 337875525169053696 keys in 75 seconds: ~4 Pkeys/s (4505007002254049 keys/s)

That is 4.5 Petakeys per second this will solve 64 bits in 4,094 Seconds

2^64 = 18,446,744,073,709,551,616 keys
bewteen 4505007002254049 keys/ s = 4064 Seconds, near 68 minutes

In my laptop i use to get 20 Petakeys/s with 8 threads and 8 GB of RAM, yes i know it is not lineal but some CPU intructions are shared per Physical core

BY THE WAY:

I write some post about your speed time ago:

https://bitcoin.albertobsd.dev/2021/12/puzzle-70-one-sigle-thread.html

In that post I show a test solving the puzzle 70 with a single thread and near 32GB of RAM it took me 9 hrs to solve it

Please check it. Thanks!

And with some math and probabilistic tricks i manage to solve 75 bits in 8 hrs:

https://twitter.com/albertobsd/status/1465540963128987651

But actually the time should be less because in that screenshot half of the time was used to generate the Bloom filter and creat the auxiliar files.

726  Bitcoin / Bitcoin Technical Support / Re: How do i make sure my Bitcoin Private Key is Random and secure? on: November 24, 2022, 02:38:04 AM
Use the next Linux command

Code:
</dev/urandom tr -dc 'A-F0-9' | head -c 64  ; echo

Please read the next article if you have concerns about urandom

https://www.2uo.de/myths-about-urandom/
727  Bitcoin / Development & Technical Discussion / Re: overview of key cracking tools for 32BTC puzzle on: November 22, 2022, 02:26:31 AM
Well the options are very clear if you have GPU then use it a program for GPU. If you only have CPU then use keyhunt.

The BSGS in keyhunt use a custom Bloomfilter it use less RAM than the bsgs in the JeanLucPons version (More RAM available means more speed)

The BSGS of JeanLucPons use a HashTable

About the programs for GPU i only have to mention that if you have the publickey available then use Kangaroo it is faster than BSGS.

If you don't have the publickey then use bitcrack.
728  Bitcoin / Project Development / Re: Keyhunt - development requests - bug reports on: November 21, 2022, 03:17:53 PM
I just search for BSGS cuda and some repository appears it is written in PureBasic.
About the performance you need to test it, I don't have GPU to test those programs.

But yes, the performance will be 100 times superior to bsgs on CPU.

What's the difference between n and k values?

N is the size of the giant step

K is a multiplier of N

So the real Giant Step is N*K

To understand BSGS please read:

https://andrea.corbellini.name/2015/06/08/elliptic-curve-cryptography-breaking-security-and-a-comparison-with-rsa/
729  Bitcoin / Project Development / Re: keysubtracter - test - development requests - bug reports on: November 19, 2022, 11:09:36 AM
What version of Ubuntu do you have?

Code:
uname -a

What version of gcc do you have?

Code:
gcc -v
730  Bitcoin / Project Development / Re: Keyhunt - development requests - bug reports on: November 16, 2022, 10:25:22 AM
Great! thanks for your reply.

Say I have hardware1 and run with -k 1024 and -S

Can I copy the created files from -S and move them to hardware2 and run there again with -k 1024 and -S ? Will that work?

Yes you can! those files don't change between system.
731  Bitcoin / Project Development / Re: Keyhunt - development requests - bug reports on: November 16, 2022, 02:52:57 AM
Hello Alberto. I cannot find bPfile, where is this located? I have searched all the subfolders but nothing found. How can we create the .bin files ?
And can you explain please how the switch -S works in detail and when we can/should use it or not?

Thank you in advance.

That Pfile is now obsolete, the new way to speed up the booting process for the mode BSGS is with the option "-S" only available in the las version in github.

This -S parameter Store and Read the Bloom Filter File and the Array Table. Those files will be always the same unless you change the parameters in  -n and -k

Regards!
732  Bitcoin / Bitcoin Discussion / Re: == Bitcoin challenge transaction: ~100 BTC total bounty to solvers! ==UPDATED== on: November 14, 2022, 02:52:51 AM
Using BSGS you can get speed up to Ekeys/s but this speed is nothing compare to the length of 120bit.
You will have more chance with Mkeys/s in 66bit then having Ekeys/s in 120bit

Exactly, even with yottakeys per second in bags is not enough for puzzle 120.
733  Bitcoin / Project Development / Re: ECDSA signature R,S,Z values on: November 08, 2022, 09:54:08 PM
Indeed if you figure any relationship betweetn two different signatures from the same publickey you may solve the equation.
734  Bitcoin / Bitcoin Discussion / Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it on: October 23, 2022, 10:51:59 PM
Good luck
735  Bitcoin / Bitcoin Discussion / Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it on: October 23, 2022, 09:42:53 PM
..it depends on the CPU used... I have 3GHz/core... be happy, the faster the better!
but the forum is not for saying "who can run faster"

it's about innovation, ideas to shorten the search... new ways in the programming..

My CPU is core i5 @ 2.6 GHz.

Anyway if it is about innovation your code doesn't have any of them.

Your way is not the shorten way, and also is not a new way of programing.

You did not reply my question

Your way:
WIF->Private Key->Publickey->Sha256->rmd160->Address.

Why not only?
Publickey->Sha256->rmd160

Skipping the WIF to privatekey and the rmd160 to address you can save a lot of process and speed up your search up to 200% or more... Trust me I already pass for that process.

What I'm trying to write, is that you can do it better, what stop you from that slow speed? You can get a better performance from your current hardware
736  Bitcoin / Bitcoin Discussion / Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it on: October 23, 2022, 07:26:48 PM

Speed test with 4 cores:   [ Speed : 301444.62 Keys/s ]
the calculation takes place one after the other, not at the same time, which would take time...

I can get the same speed with only one core using my code
737  Bitcoin / Bitcoin Discussion / Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it on: October 23, 2022, 01:12:36 PM
WIF-Key based scanner for the 66 bit range..
 ...happy Hunting!! Wink

your code is the most inefficient way to search the puzzle.

Your way:
WIF->Private Key->Publickey->Sha256->rmd160->Address.


Why not only?

Publickey->Sha256->rmd160

In this way you avoid some steps that need a lot of calculation.

Regards!

738  Bitcoin / Bitcoin Discussion / Re: == Bitcoin challenge transaction: ~100 BTC total bounty to solvers! ==UPDATED== on: October 23, 2022, 12:51:42 AM
Hi friend,

There is a tip for 64 wallets,

The beginning starts with the letter B. The next most likely is the number 2.

The highly probable start starts with B2, possibly with B25 or B26.

Great TIP Roll Eyes Roll Eyes

I want to ask you this?
These wallets are created by a Random computer, it is the creator who says so.

No, Those wallets weren't random they were created from a deterministic seed and masked every privatekey to fit in its own bit space a

Why 4 wallets for every hex?
The reason is because it forms at certain intervals.

No that really, the true reason for that is that every hexadecimal character can fit in 4 bits:

0000 - 0
0001 - 1
0010 - 2
...
1110 - E
1111 - F

From each hexadecimal character we have

Bit 1 from range 1000... to 1FFF...
Bit 2 from range 2000... to 3FFF...
Bit 3 from range 4000... to 7FFF...
Bit 4 from range 8000... to FFFF...

It was masked from their privatekeys to fit in that way example:

Code:
Original KEY
93fad720399802f8ad26961031d5166670a76e48af27d57c8a83d00fbd07f939
Masked KEY
0000000000000000000000000000000000000000000000008a83d00fbd07f939

I want to show it as a small picture. Because it's very brain tiring.


Wow that image was also totally useful



But yes i know what you try to said about probabilities, some times those numbers are some biased depending of the way to generate those numbers, but this is not the case.

Anyway i don't find any trouble...

The only clue that someone can find will be the seed and method used by the puzzle creator... That will solve all the puzzles.

Best regards!
739  Bitcoin / Bitcoin Discussion / Re: == Bitcoin challenge transaction: ~100 BTC total bounty to solvers! ==UPDATED== on: October 11, 2022, 04:43:15 AM
I think I found a clue.

I think that you don have idea how sha256 and rmd160 works.
740  Bitcoin / Project Development / Re: Keyhunt - development requests - bug reports on: September 16, 2022, 03:25:19 AM
Is it possible to make keyhunt compatible with GPU or do you think It's not worth it?

My keyhunt right now is NOT compatible for GPU.

There are some projects with BSGS for GPU you can found those on github. Also you can use Kangaroo it, don't depend of Memory in GPU.

Regards!
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 [37] 38 39 40 41 42 43 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!