Bitcoin Forum
April 27, 2024, 02:28:12 PM *
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 »
641  Bitcoin / Project Development / Re: Keyhunt - development requests - bug reports on: May 05, 2023, 04:58:55 PM
@Op, you were going to buy a laptop with a GPU

I am going to buy a desktop computer wiht some GPU (not a fancy one) but a decent GPU.

When? I hope this month,  I haven't had much time lately as I've been pretty busy.

What happened?

Oh, you know, life just happened. I've got some other things to do and going on besides this crypto community, so I had to prioritize those for a bit.

Anyways, how come you have no GPU but have CPU?

The only good computer I have isn't actually mine. I borrowed it from someone else, but unfortunately, it doesn't have a  decent GPU.

AFAIK, there are no CPU only systems for years, maybe I'm wrong though.

well the laptop that i borrowed, comes with some Intel basic GPU if that is what you mean...

But common guys, i understand you and  got your point, every one want to hit a puzzle with their powerful GPUs that is OK, that is why i going to develop it for GPU and also i want to create the poolclient and server for my program...

I am not rich to buy all those fancy hardware, regardless there is some asshole user out there who think that I somehow magically received some coins from him.

I fully support that. I think developers should work on slow computers (at least slower than average user's computer), it would force them to improve their code without relying on the latest/fastest hardware.

Agree, that is my point.
642  Bitcoin / Project Development / Re: Keyhunt - development requests - bug reports on: May 04, 2023, 07:01:29 PM
Will there be any speed improvement using AVX2 and hugepages for CPUs? As well as L3 cache usage of ryzen cpus which in some cases may replace ram reads increasing the speed by times.

I will check that... thanks to rememberme this instrucctions  i need to verify what i can do with them.

What does KV abbreviation mean? Can you point me to his github repository ?

kanhavishva

https://github.com/secp8x32


@albert0bsd
if I read between the lines correctly, there seems to be something bothering you about the versions of KeyHunt-Cuda available on github (I'm thinking of the versions of Qalander and/or Manyu). I'm guessing that you may be upset because they may have stolen code from you or otherwise misused it without giving you credit. But that's just my guess. At least I read out that you have no interest in a cooperation with them. Nevertheless, thank you very much for your work so far and for sharing your programs with the community. Hats off and keep it up!

WHO? i never heard about them and actually i don't care much...

Out of pure curiosity and personal interest in a working KeyHunt-Cuda version, I'd like to ask you: for what reasons haven't you designed a CUDA-enabled version yet? Working with CPU is completely behind for the purposes after all, GPUs simply have the highest power and performance. Or did you design a KeyHunt-Cuda version in the meantime and I missed it and didn't notice? Am curious and look forward to your answer.

My project start like a proof of concept program for myself, i was learning all the things about the elliptic curve at the same time that i develop it.

it start with some small code with Libgmp and then I start to add some extra functions, here and there.

The main reason that i haven't designed it for CUDA... or GPU is because I HAVEN'T ONE

So, I moved from using libgmp to the same libsecp256k1 code that JLP uses in his BSGS implementation. I only used a part of his code and made some small tweaks to make it work with my initial approach. Right now, I think my BSGS implementation is the fastest one you can get for CPU, and I'm hoping to double its speed again soon.

My C code style is somekind old, maybe some other developers also notice it, but is what actually know by self learning it.

I just want to say that if everyone only focuses on developing for GPUs just because they're faster, they might miss out on some cool speed hacks and math shortcuts that can be really helpful for people like me who don't have top-of-the-line hardware yet.
643  Bitcoin / Bitcoin Discussion / Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it on: May 04, 2023, 05:00:41 AM
======================================

Matching Characters: 10
13zb1hQbWVsc2S7ZTZnP2G4undNNpdh5so
^^^^^^^^                 ^^
13zb1hQbe4NbYTWQqNSZ5PkXbdNhJVeH4K  24C4A7D65296C748E
^^^^^^^^                 ^^

Even one bit different in the RMD hash is enough to invalidate the key ..
644  Bitcoin / Project Development / Re: Keyhunt - development requests - bug reports on: May 02, 2023, 11:01:43 PM
Alberto, what is your plan, any timeline? Do you need help with that? Let me know, maybe we could work together on your software.

Hi PawGo, nice to read you.

Actually i haven't a timeline for it, but the plan is that list in that order, at least i hope that. Let me finish with this increment BSGS speed thing and the Legacy version and then i will let you know to work for it

Thanks
645  Bitcoin / Project Development / Re: Keyhunt - development requests - bug reports on: May 01, 2023, 11:46:21 PM
1 Ekeys/s (1021708069969158067 keys/s)

1.021.708.069.969.158.067 keys/s

128gb + 16 AMD Ryzen 7 5800X

 Smiley Nice config, I really wish you good luck, you will need it



BTW Guys i already update some features in the main branch of my keyhunt repository, here some of the highlighs:

  • Added mode vanity at rmd speed because always is cool to have an own custom address
  • Merge of Address and rmd160, now they both works at the same speed and also accept file with legacy address or rmd hashed
  • Bloom filter and table Saved in file for address, rmd160, xpoint, minikeys, to enable this run always with option -S
  • Endomorphism option -e to enable better speed for address, rmd160, xpoint and vanity this allow to search 6 keys at the same time, it not work for puzzles because 5 of each 6 keys will be outside the range.
  • Improved Makefile options to optimize it to your current architecture, some users report some increment (%20 to %40) of speed for address, rmd160 and xpoint

Things pending TO-DO in keyhunt  (in order)
  • Finish the Double BSGS speed. (I'm having some troubles here but i'm at halfway)
  • Legacy version (to run everywhere Linux, Mac, termux)
  • Windows Version
  • GPU Version
  • Pool client Version

best regards
646  Bitcoin / Project Development / Re: Keyhunt - development requests - bug reports on: April 28, 2023, 04:59:52 PM
Are you saying if your address list contains close to 2^32 addresses, a bug may exist, as you described above?

Yes the bug exists, but the behaivor of it is unexpected

if you see this PoC:
https://github.com/jvirkki/libbloom/issues/20

Code:
Items 4194304 bloom filter bytes 7537997
Items 8388608 bloom filter bytes 15075994
Items 16777216 bloom filter bytes 30151987
Items 33554432 bloom filter bytes 60303973
Items 67108864 bloom filter bytes 120607946
Items 134217728 bloom filter bytes 241215893
Items 268435456 bloom filter bytes 482431785
Items 536870912 bloom filter bytes 427992657
Items 1073741824 bloom filter bytes 319114402
Items 2147483648 bloom filter bytes 101357891

Why more items in the bloom lead to a lower number of bytes? Look carefully:

Items 268435456 bloom filter bytes 482431785
Items 536870912 bloom filter bytes 427992657
Items 1073741824 bloom filter bytes 319114402
Items 2147483648 bloom filter bytes 101357891


That’s a large number of addresses!

Yes it is, I've seeing people making such amount of list with keysubtract or similar custom tools

I’ve ran it with 2^28 addresses and found the key I had put in there as a POW address.

The bug is only present above a 2^30 list and the hebaivor is unexpected it may hit or not but it need to be tested.
647  Bitcoin / Bitcoin Discussion / Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it on: April 28, 2023, 01:34:13 PM
just for fun, to shock satoshi for few seconds though Cheesy anyway, all of these keys have been derived from a single seed. I believe Satoshi must have generated all the addresses using this method. There also appears to be a significant similarity in all the private keys, i run this in loop every time it seems close enough to known keys.

Well he can do that method or another one, maybe some custom method, but there is no way know that right?

Good luck and stop that kind of SPAM becuase you don't specity anything of that in your post you only post:

Code:
address = privatekey

Without context that may be considered SPAM

Regards!
648  Bitcoin / Project Development / Re: Keyhunt - development requests - bug reports on: April 28, 2023, 01:30:15 PM
as keyhunt-cuda find successful the key for puzzle #65, shouldn't we expect that it works fine for #66, too ?

Yes, for small list of address or a single address the bug that I'm describing don't exist, so it will work fine, but i don't know if there are other errors there.
649  Bitcoin / Project Development / Re: Keyhunt - development requests - bug reports on: April 28, 2023, 01:23:30 PM
Maybe albert0bsd refer to bug of using -m address (single, NOT -m addresses ) which will miss the key.

Not is not that, the bloom filter that he is using have some bugs i report those bugs to the developer of the bloomfilter

https://github.com/jvirkki/libbloom/issues/20

But the developer update it some year before that, i solve by my own implementation.

I notify to KV but he didn't solve as far i can remember

So for small list of address it work fime, but for bigger lists it can fail.

I updated my bloom filter implementation to use xxhash (64 bits) instead of murmurhash (32bits), because with murmurhash if the number of addresses in the list, is near to 32 bits then the bloom may be some saturated because almost any data tha that you pass to the bloom filter will do a collision.

Look the original code in https://github.com/jvirkki/libbloom/blob/master/bloom.c#L57

With a 64 bit hash the problem will be solved, but the original bloom may never change it because compatibility reasons.

the KV version may have some other bugs but since it was some kind of copy of my keyhunt, i prefer to improve my own version than fix another versions.
650  Bitcoin / Project Development / Re: Keyhunt - development requests - bug reports on: April 27, 2023, 12:44:03 PM
Dear albert0bsd,

Which GPU do you recommend on Keyhunt-Cuda?

Do you have information about benchmarking result on latest 3090, 4090 or Tesla 32gb cards?

I don't develop keyhunt-cuda, also I don't recommend it, it have some bugs that may missing some keys.

651  Bitcoin / Project Development / Re: Keyhunt - development requests - bug reports on: April 27, 2023, 05:03:06 AM
Can use it for get ecdsa K value to recover Private key ?

Why you quoted all my post? Anyway your question is not specific, what are you trying to do? I know what are you talking about but do you know what are you trying to achieve? It is some special case?
652  Bitcoin / Development & Technical Discussion / Re: Some doubts about rmd160 and address for vanity search on: April 23, 2023, 10:53:53 AM
I know VanitySearch is just check first few bits of the address but that could be useful trade off for example checking 70% of the address to increase the speed of keyhunt and if there are a hit then do 100% checking.

I will check it thanks.

Regards
653  Bitcoin / Development & Technical Discussion / Re: Some doubts about rmd160 and address for vanity search on: April 22, 2023, 08:34:38 PM
This could be out of topic but I have suggestion for BSGS.
Instead of create list from 1bit -> Xbit, create it from target -> Xbit (or reverse) so you can just directly check the hash table without doing any subtract to the private key.

Well yes it is some offtopic but i going to reply to you here

Okay, I didn't get your idea at first glance, but after rereading it for the second time, I now understand what you're trying to do.

There are many substractions in BSGS not only ONE example:

Current Implementation:
Code:
Key 99
known range 75-100
Baby step 5  = { 0,1,2,3,4}
Giant step 5 = {0,5,10,15,20}

First subtraction to move key to the BSGS range
99(key) - 75(Base range) = 24

New Target Key 24

Giant step 0
24 - 0 = 24 is on Baby Table? NO

Giant step 1
24 - 5 = 19 is on Baby Table? NO

Giant step 2
24 - 10 = 14 is on Baby Table? NO

Giant step 3
24 - 15 = 9 is on Baby Table? NO

Giant step 4
24 - 20 = 4 is on Baby Table? YES (HIT)

Calcualted KEY is Giant Step 4 plus Baby step 4 PLUS [b]Base range[/b], this is 20 + 4 + 75 = 99

Your proposed Implementation:
Code:
Key 99
known range 75-100
Baby step 5  = {75,76,77,78,79}
Giant step 5 = {0,5,10,15,20}
Target Key 99

Giant step 0
99 - 0 = 99 is on Baby Table? NO

Giant step 1
99 - 5 = 94 is on Baby Table? NO

Giant step 2
99 - 10 = 89 is on Baby Table? NO

Giant step 3
99 - 15 = 84 is on Baby Table? NO

Giant step 4
99 - 20 = 79 is on Baby Table? YES (HIT)

Calcualted KEY is the HIT key
I don't know if that is your idea or not, please correctme if im wrong But in this example We only avoid one substraction, all the Giant Step subtractions remain... There will be some more varians of this (only make stride
 with the Giant step, etc...) but almost all keep the Giant Step subtractions.

BTW another important thing to Generate a list from 1 to X is that we can use that SAME list for ANOTHER targets BUt if you do the list from Target to ( Target + X), then that list only is going to be useful againts that specific target.

Mora about BSGS: https://andrea.corbellini.name/2015/06/08/elliptic-curve-cryptography-breaking-security-and-a-comparison-with-rsa/
654  Bitcoin / Development & Technical Discussion / Re: Some doubts about rmd160 and address for vanity search on: April 21, 2023, 12:18:17 PM
Yes actually is what my program do it search those base 58 strings that decodes into 25 bytes. Theninuse those values as limits
655  Bitcoin / Bitcoin Discussion / Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it on: April 21, 2023, 01:55:57 AM
The amount of space that 2^67 lines of text would take up in a .txt file depends on the length of each line.
line: 20000000000000000(17 char) 1LgpDjsqkxF9cTkz3UYSbdTJuvbZ45PKvx (34 char) 17+34 = 51
total number of characters as follows:

That is the worst way to store that informacion, to store it you need to store the data in its RAW data fot the address you only need the RMD hash in raw data it is only 20 bytes.

For the privatekey there is two options, don't store the private key because you will not sort the Addresses or Store the private key because you want to Sort the addresses

If you decide to store the private key you only need 9 bytes for it... in that case you only need 29 bytes.

If you decide NOT store the private key you only need 20 bytes for the hash rmd.

656  Bitcoin / Development & Technical Discussion / Re: Some doubts about rmd160 and address for vanity search on: April 20, 2023, 06:59:56 PM
I don't have your C module, but shouldn't you check for the lowest and highest valid address? Replacing the remaining base58 characters with ones and z's doesn't make the address valid, because of the checksum.

Guys this is an example, the Checkcum or validity doesn't is important for the lowest and highes addresses

I only use those values as limits, when i compare if the current hash I omit the prefix 00 byte and the postfix checksum bytes.

Example:

Code:
Target base58: 1Bitcoin
Lower limit base 58:  1Bitcoin11111111111111111111111111
Higher limit base 58: 1Bitcoinzzzzzzzzzzzzzzzzzzzzzzzzzz

Lower limit rmd160:  00759d667708d463667bab9e23c1b83761d6c71dcd3c000000
Higher limit rmd160: 00759d66770a11348c6dc1fda8d293dbc1dec867d5dfffffff

Current Address: 1Bitcoin873Ns4mSAVnUn1eD43RBq89vqo
current hashrmd: 00759d667708fb31996328d15f3056d190278a1bb57dc660b2

Code:
(Lower Limit) <= (Current HASH) <= (Higher Limit) 

For this case will be:

Code:
759d667708d463667bab9e23c1b83761d6c71dcd<= 759d667708fb31996328d15f3056d190278a1bb5 <= 759d66770a11348c6dc1fda8d293dbc1dec867d5 

memcmp stop at the first byte with some difference so the comparation will be only like:

759d667708d4<= 759d667708fb <= 759d66770a11

So if the Current hash value is between the given limits that means the function base58_encode_checksum(00 byte +current hash) will have the Same expected Prefix for this case will be "1Bitcoin"

Have you considered how permutations work on rmd160 hashes?
...

How exactly skipping a simple base58 encoding could double the speed? Is base58 encoding heavier than hashing? If that's the case then it could change a lot of other things, I just need to think what those things could be.

About the speed that its what in practice i get when i run keyhunt for addresses and keyhunt for hashes rmd160. rmd160 search get almost the double of the speed of address search

Aboute the permutations i will check it.

I already tested and for each prefix that we search for vanity ["1Fortune", "1Prosper", "1Winner", etc...] and almost always there are two RMD ranges that generate the same Base58 prefix, so  I think that i will add all those ranges to the search, it will be enough.



The next example compare one address againts some prefixes. but it can also be the other way around Many address to one or more vanity prefixes

Output:
Code:
Address 1Bitcoin873Ns4mSAVnUn1eD43RBq89vqo encode to 759d667708fb31996328d15f3056d190278a1bb5
Raw size: 25, Encoded size: 33 : expected string 1Fortune, base string 1Fortune1111111111111111111111111 => hex 0002ccf0c09d38ef18ac118453594f3bf77af9d90366000000
Raw size: 25, Encoded size: 34 : expected string 1Fortune, base string 1Fortune11111111111111111111111111 => hex 00a26e8ba39ee62b96fbf7fae23bf39611dc9b2ac51c000000
Raw size: 25, Encoded size: 33 : expected string 1Fortune, base string 1Fortunezzzzzzzzzzzzzzzzzzzzzzzzz => hex 0002ccf0c09d3e6576041abaf0203889d5d363cd0c5fffffff
Raw size: 25, Encoded size: 34 : expected string 1Fortune, base string 1Fortunezzzzzzzzzzzzzzzzzzzzzzzzzz => hex 00a26e8ba3a022fcbcee0e5a674ccf3a71e49c74cdbfffffff
The target Address 759d667708fb31996328d15f3056d190278a1bb5 NOT match bewteen the start and end range (02ccf0c09d38ef18ac118453594f3bf77af9d903 and 02ccf0c09d3e6576041abaf0203889d5d363cd0c)
The target Address 759d667708fb31996328d15f3056d190278a1bb5 NOT match bewteen the start and end range (a26e8ba39ee62b96fbf7fae23bf39611dc9b2ac5 and a26e8ba3a022fcbcee0e5a674ccf3a71e49c74cd)
Raw size: 25, Encoded size: 33 : expected string 1Prosper, base string 1Prosper1111111111111111111111111 => hex 000452ba9d1f9147e608975a8067caddeb99dbb63f06000000
Raw size: 25, Encoded size: 34 : expected string 1Prosper, base string 1Prosper11111111111111111111111111 => hex 00fabe479926ea4a1df24a811783f64760dbc74a475c000000
Raw size: 25, Encoded size: 33 : expected string 1Prosper, base string 1Prosperzzzzzzzzzzzzzzzzzzzzzzzzz => hex 000452ba9d1f96be4360a0911d2eb42bc9f245aa47ffffffff
Raw size: 25, Encoded size: 34 : expected string 1Prosper, base string 1Prosperzzzzzzzzzzzzzzzzzzzzzzzzzz => hex 00fabe479928271b43e460e09c94d1ebc0e3c8944fffffffff
The target Address 759d667708fb31996328d15f3056d190278a1bb5 NOT match bewteen the start and end range (0452ba9d1f9147e608975a8067caddeb99dbb63f and 0452ba9d1f96be4360a0911d2eb42bc9f245aa47)
The target Address 759d667708fb31996328d15f3056d190278a1bb5 NOT match bewteen the start and end range (fabe479926ea4a1df24a811783f64760dbc74a47 and fabe479928271b43e460e09c94d1ebc0e3c8944f)
Raw size: 25, Encoded size: 33 : expected string 1Winner, base string 1Winner11111111111111111111111111 => hex 00059ef26b901a66d6bda68342507cdb76d44268a9dc000000
Raw size: 25, Encoded size: 33 : expected string 1Winner, base string 1Winnerzzzzzzzzzzzzzzzzzzzzzzzzzz => hex 00059ef26b915737fcafbce2c761587fd6dc43b2b27fffffff
The target Address 759d667708fb31996328d15f3056d190278a1bb5 NOT match bewteen the start and end range (059ef26b901a66d6bda68342507cdb76d44268a9 and 059ef26b915737fcafbce2c761587fd6dc43b2b2)
Raw size: 25, Encoded size: 33 : expected string 1Bitcoin, base string 1Bitcoin1111111111111111111111111 => hex 00020720a9c6c5de6748c0c08507c0f820955bb57ab6000000
Raw size: 25, Encoded size: 34 : expected string 1Bitcoin, base string 1Bitcoin11111111111111111111111111 => hex 00759d667708d463667bab9e23c1b83761d6c71dcd3c000000
Raw size: 25, Encoded size: 33 : expected string 1Bitcoin, base string 1Bitcoinzzzzzzzzzzzzzzzzzzzzzzzzz => hex 00020720a9c6cb54c4a0c9f721ceaa45feedc5a983afffffff
Raw size: 25, Encoded size: 34 : expected string 1Bitcoin, base string 1Bitcoinzzzzzzzzzzzzzzzzzzzzzzzzzz => hex 00759d66770a11348c6dc1fda8d293dbc1dec867d5dfffffff
The target Address 759d667708fb31996328d15f3056d190278a1bb5 NOT match bewteen the start and end range (020720a9c6c5de6748c0c08507c0f820955bb57a and 020720a9c6cb54c4a0c9f721ceaa45feedc5a983)
The target Address 759d667708fb31996328d15f3056d190278a1bb5 match bewteen the start and end range (759d667708d463667bab9e23c1b83761d6c71dcd and 759d66770a11348c6dc1fda8d293dbc1dec867d5)
Raw size: 25, Encoded size: 33 : expected string 1Satoshi, base string 1Satoshi1111111111111111111111111 => hex 0004d6b1134630fc8c8a8caf92ab9153c6e5569b77fa000000
Raw size: 25, Encoded size: 33 : expected string 1Satoshi, base string 1Satoshizzzzzzzzzzzzzzzzzzzzzzzzz => hex 0004d6b113463672e9e295e62f727aa1a53dc08f80f3ffffff
The target Address 759d667708fb31996328d15f3056d190278a1bb5 NOT match bewteen the start and end range (04d6b1134630fc8c8a8caf92ab9153c6e5569b77 and 04d6b113463672e9e295e62f727aa1a53dc08f80)
Raw size: 25, Encoded size: 33 : expected string 1P, base string 1P1111111111111111111111111111111 => hex 00042926b2614c8a210db0867df56b3274219a39c700000000
Raw size: 25, Encoded size: 34 : expected string 1P, base string 1P11111111111111111111111111111111 => hex 00f152c46a0b574b7d19fe78899a496e4f9cf1171600000000
Raw size: 25, Encoded size: 33 : expected string 1P, base string 1Pzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz => hex 000459912eda15d639d42146c98092fa90aec425217fffffff
Raw size: 25, Encoded size: 34 : expected string 1P, base string 1Pzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz => hex 00fc4ae49d68f2891a0f8a09a7214cc4c798706996ffffffff
The target Address 759d667708fb31996328d15f3056d190278a1bb5 NOT match bewteen the start and end range (042926b2614c8a210db0867df56b3274219a39c7 and 0459912eda15d639d42146c98092fa90aec42521)
The target Address 759d667708fb31996328d15f3056d190278a1bb5 NOT match bewteen the start and end range (f152c46a0b574b7d19fe78899a496e4f9cf11716 and fc4ae49d68f2891a0f8a09a7214cc4c798706996)
Raw size: 25, Encoded size: 33 : expected string 1Q, base string 1Q1111111111111111111111111111111 => hex 000459912eda15d639d42146c98092fa90aec4252180000000
Raw size: 25, Encoded size: 34 : expected string 1Q, base string 1Q11111111111111111111111111111111 => hex 00fc4ae49d68f2891a0f8a09a7214cc4c79870699700000000
Raw size: 25, Encoded size: 33 : expected string 1Q, base string 1Qzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz => hex 000489fbab52df22529a9207150bbac2ad3bee107bffffffff
Something is wrong please check this case "1Q"


Code:

Code:
/*
Developed by Alberto
email: albertobsd@gmail.com

Compile in the keyhunt directory
gcc -o examplermdvanity examplermdvanity.c base58.o util.o
*/


#include <stdio.h>
#include <stdlib.h>
#include <stdint.h>
#include <stdbool.h>
#include <gmp.h>
#include <string.h>
#include <unistd.h>
#include <math.h>
#include <time.h>
#include "util.h"

#include "base58/libbase58.h"

#define LIST_SIZE 8

int main() {
char *targetaddress = "1Bitcoin873Ns4mSAVnUn1eD43RBq89vqo";
unsigned char raw_value_target[50];
char *hexaddress;
char *hextemp,*hextempA,*hextempB;
char *list_targets[LIST_SIZE] = {"1Fortune", "1Prosper", "1Winner", "1Bitcoin","1Satoshi","1P","1Q","1R"};
char target[50];
int i,j,cmpA,cmpB;
int raw_values_A_size,raw_values_B_size;
unsigned char **raw_values_A,**raw_values_B;

    unsigned char raw_value_A[50],raw_value_B[50];
size_t stringsize,raw_value_length;
stringsize = strlen(targetaddress);
raw_value_length = 50;
b58tobin(raw_value_target,&raw_value_length,targetaddress,stringsize);
b58tobin(raw_value_target,&raw_value_length,targetaddress,stringsize);
hexaddress =  tohex(raw_value_target+1,20);
printf("Address %s encode to %s\n",targetaddress,hexaddress);
raw_values_A = NULL;
raw_values_B = NULL;
    for(i = 0; i < LIST_SIZE; i++) {
raw_value_length = 50;
stringsize = strlen(list_targets[i]);
memset(raw_value_A,0,50);
memset(raw_value_B,0,50);
memset(target,0,50);
strncpy(target,list_targets[i],stringsize);

j = 0;
do {
raw_value_length = 50;
b58tobin(raw_value_A,&raw_value_length,target,stringsize);
if(raw_value_length < 25) {
target[stringsize] = '1';
stringsize++;
}
if(raw_value_length == 25){
b58tobin(raw_value_A,&raw_value_length,target,stringsize);
raw_values_A = realloc(raw_values_A,(j+1) * sizeof(unsigned char *));
raw_values_A[j] = calloc(25,1);
memcpy(raw_values_A[j],raw_value_A,25);

hextemp = tohex(raw_values_A[j],raw_value_length);
printf("Raw size: %li, Encoded size: %li : expected string %s, base string %s => hex %s\n", raw_value_length,stringsize,list_targets[i],target,hextemp);
free(hextemp);

j++;
raw_values_A_size = j;

target[stringsize] = '1';
stringsize++;

}
}while(raw_value_length <= 25);

stringsize = strlen(list_targets[i]);
memset(raw_value_B,0,50);
memset(target,0,50);
strncpy(target,list_targets[i],stringsize);
j = 0;
do {
raw_value_length = 50;
b58tobin(raw_value_B,&raw_value_length,target,stringsize);
if(raw_value_length < 25) {
target[stringsize] = 'z';
stringsize++;
}

if(raw_value_length == 25) {
b58tobin(raw_value_B,&raw_value_length,target,stringsize);
raw_values_B = realloc(raw_values_B,(j+1) * sizeof(unsigned char *));
raw_values_B[j] = calloc(25,1);
memcpy(raw_values_B[j],raw_value_B,25);

hextemp = tohex(raw_values_B[j],raw_value_length);
printf("Raw size: %li, Encoded size: %li : expected string %s, base string %s => hex %s\n", raw_value_length,stringsize,list_targets[i],target,hextemp);
free(hextemp);

j++;
raw_values_B_size = j;

target[stringsize] = 'z';
stringsize++;
}
}while(raw_value_length <= 25);

if(raw_values_A_size != raw_values_B_size) {
printf("Something is wrong please check this case \"%s\"\n",list_targets[i]);
exit(0);
}

for(j = 0; j < raw_values_A_size; j++) {
hextempA = tohex(raw_values_A[j]+1,20);
hextempB = tohex(raw_values_B[j]+1,20);
cmpA = memcmp(raw_values_A[j]+1,raw_value_target+1,20);
cmpB = memcmp(raw_values_B[j]+1,raw_value_target+1,20);
if(cmpA <= 0 && cmpB >= 0) {
printf("The target Address %s match bewteen the start and end range (%s and %s)\n",hexaddress,hextempA,hextempB);
}
else {
printf("The target Address %s NOT match bewteen the start and end range (%s and %s)\n",hexaddress,hextempA,hextempB);
}
free(hextempA);
free(hextempB);
}
if(raw_values_A_size > 0){
for(j = 0; j < raw_values_A_size; j++) {
free(raw_values_A[j]);
free(raw_values_B[j]);
}
free(raw_values_A);
free(raw_values_B);
raw_values_A =NULL;
raw_values_B =NULL;
}

    }
}
657  Bitcoin / Development & Technical Discussion / Some doubts about rmd160 and address for vanity search on: April 20, 2023, 03:11:55 PM
Edit.

TL;TR

Almost all the address before the prefix "1Q" have two valid RMD ranges.


I want to improve some feature of the tool that i develop keyhunt

Actually keyhunt can do some vanity search but it is slow because it do the search by string comparation something like:

Code:
strncmp(current_addrres,vanity_target,len_vanity_target);

example:

Code:
strncmp("1Bitcoin873Ns4mSAVnUn1eD43RBq89vqo","1Bitcoin",8);

To improve the speed of the vanity search, So my idea was to do some vanity search but only comparing the hash rmd160 (i mean the binary or raw data not the hexadecimal string representation of it).
This avoid the Base58 encode, to do this we need to calcualte the lower and higher limit of the target hash and check if the current hash is bewteen them


Code:
if(memcmp(rmd_lower_limit,rmd_current,20) >= 0  &&  memcmp(rmd_current,rmd_higher_limit,20) <= 0 ){
//match
}

example

Code:
/*
Target base58: 1Bitcoin
Lower limit base 58:  1Bitcoin11111111111111111111111111
Higher limit base 58: 1Bitcoinzzzzzzzzzzzzzzzzzzzzzzzzzz

Lower limit rmd160:  00759d667708d463667bab9e23c1b83761d6c71dcd3c000000
Higher limit rmd160: 00759d66770a11348c6dc1fda8d293dbc1dec867d5dfffffff

Current Address: 1Bitcoin873Ns4mSAVnUn1eD43RBq89vqo
current hashrmd: 00759d667708fb31996328d15f3056d190278a1bb57dc660b2


So for this case the code evalute the next values:
*/

if(memcmp(759d667708d463667bab9e23c1b83761d6c71dcd,759d667708fb31996328d15f3056d190278a1bb5,20) >= 0  &&  memcmp(759d667708fb31996328d15f3056d190278a1bb5,759d66770a11348c6dc1fda8d293dbc1dec867d5,20) <= 0 ){
//match
}

Although this approach works well, I discovered that there are other valid lower and higher limit values for the hash rmd160 that may generate the same base58 prefix, as shown below:

Code:
/*
Target base58: 1Bitcoin
Lower limit base 58:  1Bitcoin1111111111111111111111111
Higher limit base 58: 1Bitcoinzzzzzzzzzzzzzzzzzzzzzzzzz

Lower limit rmd160:  00020720a9c6c5de6748c0c08507c0f820955bb57ab6000000
Higher limit rmd160: 00020720a9c6cb54c4a0c9f721ceaa45feedc5a983afffffff
*/

In this case, my previous address would not match if compared based on its rmd value.
I wanted to use rmd because it avoids the base58 encoding process and makes the program almost twice as fast.
However, I now realize that there may be multiple valid rmd ranges that can generate the same base58 prefix.
I have not yet checked how other applications handle this comparison against vanity targets but i want to know your thoughts.

What is the most efficient method to search for vanity collisions without performing Base58 encoding, while ensuring that no hits are missed?
658  Bitcoin / Bitcoin Discussion / Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it on: April 20, 2023, 04:30:22 AM
Just ignore the user....
659  Bitcoin / Bitcoin Discussion / Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it on: April 20, 2023, 04:05:54 AM
You mean hexadecimal?  Huh Roll Eyes At this point I don't know if you are just trolling or really you are the perfect example of the dunning kruger effect
660  Bitcoin / Bitcoin Discussion / Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it on: April 20, 2023, 03:47:21 AM
real strong community you guys got made here though only if you guys worked together and not against each other......

Nobody it is against you, everybody is trying to teaching you how it works... please read:

https://www.oreilly.com/library/view/mastering-bitcoin/9781491902639/ch04.html

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!