VanitySearch (Yet another address prefix finder) - page 41.

arulbero

legendary

Activity: 1948

Merit: 2097

Quote from: zielar on December 26, 2019, 09:42:38 AM

Quote from: Jean_Luc on December 26, 2019, 05:09:52 AM

Hi,
The difficulty is the search space size.
A difficulty of 173346595075428800 means that you have a probability of 1/173346595075428800 to find the result after 1 try.
After n tries, you can compute the probability to reach the desired address by using Bernoulli.
P(n) = 1-(1-1/173346595075428800)^n

I am asking because I have scanned the range of keys being the number given by Diff, but I have not found a solution.

1. What is the remainder of the range that I should scan to find the answer?
2. The fact that I did not find the correct key despite this is not the reason for the error in the code?

I already answered to you: difficulty is not the range you should scan to find the solution at 100% : you have in the above example

P(173346595075428800) = 1-(1-1/173346595075428800)^173346595075428800 = 0.63 --> 63% ( = 1-1/e), not 100%!

That means that only 2 times each 3 you will find the solution in a range = difficulty.

zielar

full member

Activity: 282

Merit: 114

Quote from: Jean_Luc on December 26, 2019, 05:09:52 AM

Hi,
The difficulty is the search space size.
A difficulty of 173346595075428800 means that you have a probability of 1/173346595075428800 to find the result after 1 try.
After n tries, you can compute the probability to reach the desired address by using Bernoulli.
P(n) = 1-(1-1/173346595075428800)^n

I am asking because I have scanned the range of keys being the number given by Diff, but I have not found a solution.

1. What is the remainder of the range that I should scan to find the answer?
2. The fact that I did not find the correct key despite this is not the reason for the error in the code?

arulbero

legendary

Activity: 1948

Merit: 2097

@Jean-Luc

Could you implement the possibility to import a different generator point G as parameter?

To run your program on unsafe machine:

https://bitcointalksearch.org/topic/m.53429180

arulbero

legendary

Activity: 1948

Merit: 2097

Quote from: zielar on December 25, 2019, 07:06:04 AM

Hello,
I have a question to dispel doubts about the diff index in VanitySearch.
Suppose I am looking for the prefix "1RoseCross".
VanitySearch reports difficulty 173346595075428800 for the indicated prefix.

1. Is this value simply speaking - a group that creates 100% addresses where one of them will start with a given search (1RoseCross)?

Quote from: Jean_Luc on December 26, 2019, 05:09:52 AM

The difficulty is the search space size.
A difficulty of 173346595075428800 means that you have a probability of 1/173346595075428800 to find the result after 1 try.
After n tries, you can compute the probability to reach the desired address by using Bernoulli.
P(n) = 1-(1-1/173346595075428800)^n

To be more precise:

difficulty = 173346595075428800 means that:
--> there is a correct address each 173346595075428800 addresses
--> you have a probability of 1/173346595075428800 to find the result each 1 try
--> on average it takes 173346595075428800 tries to get 1 match (on average means: if you try many times 173346595075428800 tries), but if you do 173346595075428800 tries only once you will have only a 63% chance to get a match! No 100%!

Any vanitygen-like program computes right the probability to find a match in the particular sequence you are running, it doesn't compute anything "on average".

Search space size is not 173346595075428800, sometimes you have to generate more than 173346595075428800 addresses to get a match.
A group that creates 100% addresses where one of them will start with a given prefix has size 2^160 - 173346595075428800 + 1 (and I'm not considering the fact that there are 2^96 different private keys - means tries - for the same address).

Here more details:
https://bitcointalksearch.org/topic/m.48056010

Jean_Luc

sr. member

Activity: 462

Merit: 701

Hi,
The difficulty is the search space size.
A difficulty of 173346595075428800 means that you have a probability of 1/173346595075428800 to find the result after 1 try.
After n tries, you can compute the probability to reach the desired address by using Bernoulli.
P(n) = 1-(1-1/173346595075428800)^n

zielar

full member

Activity: 282

Merit: 114

Hello,
I have a question to dispel doubts about the diff index in VanitySearch.
Suppose I am looking for the prefix "1RoseCross".
VanitySearch reports difficulty 173346595075428800 for the indicated prefix.

1. Is this value simply speaking - a group that creates 100% addresses where one of them will start with a given search (1RoseCross)?
2. If YES, is "173346595075428800" a decimal value which in hex is "0x0267d9cf4e7e91c0"?
3. If YES, are there any cases or exceptions in which it will be possible not to find the prefix after scanning the range 173346595075428800 despite the fact that VanitySearch has given such difficulty value?

Thank you in advance for your response!

MrFreeDragon

sr. member

Activity: 443

Merit: 350

Quote from: A-Bolt on December 22, 2019, 05:31:00 AM

Quote from: MrFreeDragon on December 21, 2019, 05:03:57 AM

in ETH 256bit public keys are the addresses

Ethereum address is the lower 20 bytes of the keccack256 hash of the public key.

Yeah, right. ETH addresses are 160bit (20x8). I made a mistake. Thank you.

A-Bolt

legendary

Activity: 2317

Merit: 2318

Quote from: MrFreeDragon on December 21, 2019, 05:03:57 AM

in ETH 256bit public keys are the addresses

Ethereum address is the lower 20 bytes of the keccack256 hash of the public key.

MrFreeDragon

sr. member

Activity: 443

Merit: 350

Quote from: imjustagirl on December 20, 2019, 08:29:30 AM

It would be nice if you could search for not just a specific Vanity address, but also a specific pubkey address.
For example if I wanted to search for an address with a public key that begins with 0400000000 or 02123456 or 03333333 etc.
Is it very hard to implement something like this to the VanitySearch?

Interesting idea ) Something like vanity public key Grin

Actually this could be applied to ETH addresses as well (in ETH 256bit public keys are the addresses).

I also suppose that vanity search for BTC public key should be faster (as there is no need to perform RIPEMD 160 and SHA256 hash fuctions)

imjustagirl

member

Activity: 118

Merit: 11

It would be nice if you could search for not just a specific Vanity address, but also a specific pubkey address.
For example if I wanted to search for an address with a public key that begins with 0400000000 or 02123456 or 03333333 etc.
Is it very hard to implement something like this to the VanitySearch?

OgNasty

donator

Activity: 4760

Merit: 4323

Leading Crypto Sports Betting & Casino Platform

Quote from: blockblock1 on December 12, 2019, 01:42:34 PM

Quote from: Dabs on December 12, 2019, 10:08:31 AM

I don't think you can get any ASICs meant for mining to work on VanitySearch.

why?
Are there alternative programs?

None I've ever heard of. More surprisingly, I'm not even aware of any FPGA vanity searching tools.

blockblock1

newbie

Activity: 4

Merit: 0

Quote from: Dabs on December 12, 2019, 10:08:31 AM

I don't think you can get any ASICs meant for mining to work on VanitySearch.

why?
Are there alternative programs?

Dabs

legendary

Activity: 3416

Merit: 1912

The Concierge of Crypto

I don't think you can get any ASICs meant for mining to work on VanitySearch.

blockblock1

newbie

Activity: 4

Merit: 0

How to configure VanitySearch to work with bitfury bf1

https://imgur.com/8bwVYG8
https://imgur.com/iqpi94c
https://imgur.com/226O3t7

GPU: GPU #0 GeForce GTX 770 (8x192 cores) Grid(64x128)
Seed: 1576154843
167.716 MegaKey/sec
ComputeKeys() found 1494 items , CPU check...
GPU/CPU check OK

does not see the device bitfury bf1 ((

I want to set up a mining farm to work with VanitySearch.
USB hub 49 ports.

Jean_Luc

sr. member

Activity: 462

Merit: 701

Quote from: MrFreeDragon on December 09, 2019, 04:25:59 AM

Jean_Luc, thank you for the detailed explanation.

Do you know, are there any other elliptic curve properties exist besides symmetry and endomorphism?

Symmetry and endomorphism were used by you in the code to spead up the process. However may be you know some other properties or features which could be used for additional speedup?

To my knowledge, no other speedup using other ec properties can be added to VanitySearch, but my knowledge is not infinite Wink

In any case the time required for ECC calculation is now low compare to hashing (~80% of CPU usage is taken by SHA256 and RIPEMD160). By using symmetry and endomorphism, we are near of ~1 modular multiplication per point. Even if we double the speed of ECC, it will only result in a ~10% speed increase.
To my point of view, the only significant speedup can be bring by partial reversing of the hashing function in order to reduce hashing time consumption.

MrFreeDragon

sr. member

Activity: 443

Merit: 350

Jean_Luc, thank you for the detailed explanation.

Do you know, are there any other elliptic curve properties exist besides symmetry and endomorphism?

Symmetry and endomorphism were used by you in the code to spead up the process. However may be you know some other properties or features which could be used for additional speedup?

Jean_Luc

sr. member

Activity: 462

Merit: 701

Quote from: MrFreeDragon on December 08, 2019, 09:56:50 AM

Are these properties all known elliptic curve properties, or there are some other known properties but not used in vanitysearch?

Symmetry (x,y) (x,-y) is a common property of all elliptic curve.
Secpk1 admit a primitive cubic root of unity so an endomorphism can be constructed using β and λ (β^3 = 1 mod p and λ^3 = 1 mod n)
If β^3 = 1 and λ^3 = 1 we have also (β^-1)^3 = 1,(λ^-1)^3 = 1 so we can construct a second endomorphism using β^-1 and λ^-1.
Note: β^3 = 1 mod p => β^3.(β^-1) = 1.(β^-1) mod p => β^2 = β^-1 mod p (same for λ^3 mod n)

Code:

β = 7ae96a2b 657c0710 6e64479e ac3434e9 9cf04975 12f58995 c1396c28 719501ee
λ = 5363ad4c c05c30e0 a5261c02 8812645a 122e22ea 20816678 df02967c 1b23bd72

To find primitive roots of unity you need to factorize p-1 and n-1 and find common prime factors. We have always a primitive square root of unity but it is 1 and it does not bring an improvement, speck1 admit only a cubic primitive root of unity which can be exploited.

Code:

Factorization of p-1 and n-1, only 3 can be exploited.

p-1 = FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEFFFFFC2E
2
3
7
3481
1DB8260E5E3B460A46A0088FCCF6A3A5936D75D89A776D4C0DA4F338AAFB

n-1 = FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364140
2^6
3
95
277
17D6CFB8EE30C51
978C6F353C3889A79
10DBFF26EAB8198050172EE03275

Quote from: MrFreeDragon on December 08, 2019, 09:56:50 AM

I also made some tests with vanitysearch and it is interesting for me why it is faster than bitcrack. For example, for 1 compressed address on GTX 1080ti bitcrack has 340-350MKey/sec, but vanitysearch has 950-1000MKey/sec (3 times more). Was it caused by endomorphism used?

Symmetry and endomorphisms bring significant speedup. I'm not sure, but it seems to me that bitcrak use 32 bits arithmetic which is slower...

Edit: Added factorisation of p-1 and n-1

MrFreeDragon

sr. member

Activity: 443

Merit: 350

Quote from: arulbero on December 06, 2019, 02:29:41 PM

Quote from: MrFreeDragon on December 06, 2019, 11:47:53 AM

Any other ECDSA properties are used?

Endomorphism. It is a elliptic curve property, not a ECDSA property.

If kG = (x,y) then (λ*k)G = (β*x, y) and (λ*λ*k)G = (β*β*x, y)
-snip-

Thank you! I have looked at the code and also found just these properties:
1) Endomorphism (for λ and λ*λ) - 2 additional addresses for kG
2) Curve symmetry (if (x,y) = k*G, then (x, -y) is -k*G) - 1 additional address

So, it is clear why 6 addresses are found: (1+2) * 2 = 6

Are these properties all known elliptic curve properties, or there are some other known properties but not used in vanitysearch?

I also made some tests with vanitysearch and it is interesting for me why it is faster than bitcrack. For example, for 1 compressed address on GTX 1080ti bitcrack has 340-350MKey/sec, but vanitysearch has 950-1000MKey/sec (3 times more). Was it caused by endomorphism used?

arulbero

legendary

Activity: 1948

Merit: 2097

Quote from: WhyFhy on December 06, 2019, 04:50:51 PM

this explains why 1 of 6 will be valid if split gen right?

Yes. But this is due only to the way the programs we use to reassemble the pieces for the final private key work.

Let s (Q = sG) be the secret private key (the public key). Only one person knows 's'.

Then he sends only Q to another person, who run a "split gen" program.

Usually "split gen" works like this:

it computes only (s+1)G = Q + G, (s+2)G = Q + 2G, …, (s+k)G = Q + kG = P

until it gets a public key P with a particular address.

The program knows only k (the partial private key).

Then you need to compute k' (k' G = P):

k' = (s + k) mod n.

Now suppose you get P in this way: - (Q + kG) = P

then in order to get from the partial private key k the correct final private key k' = (-s -k) mod n
you need to know how k was obtained (exploiting the symmetry).

If you get P in this way: λ(Q + kG) = P

(exploiting the endomorphism) the correct final private k' will be: λ*(s + k) mod n and so on.

WhyFhy

hero member

Activity: 1443

Merit: 513

Quote from: arulbero on December 06, 2019, 02:29:41 PM

Quote from: MrFreeDragon on December 06, 2019, 11:47:53 AM

Any other ECDSA properties are used?

Endomorphism. It is a elliptic curve property, not a ECDSA property.

If kG = (x,y) then (λ*k)G = (β*x, y) and (λ*λ*k)G = (β*β*x, y)

where

Code:

λ = 5363ad4c c05c30e0 a5261c02 8812645a 122e22ea 20816678 df02967c 1b23bd72
β = 7ae96a2b 657c0710 6e64479e ac3434e9 9cf04975 12f58995 c1396c28 719501ee

λ*k is mod n, β*x is mod p

where

Code:

n = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE BAAEDCE6 AF48A03B BFD25E8C D0364141
p = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE FFFFFC2F

In this way, you get 6 points with only 1 "operation" kG:

(x,y) (β*x, y) (β*β*x, y)
(x,p-y) (β*x, p-y) (β*β*x, p-y)

this explains why 1 of 6 will be valid if split gen right?

Topic: VanitySearch (Yet another address prefix finder) - page 41. (Read 32966 times)