Bitcoin Forum
November 01, 2024, 02:23:29 PM *
News: Latest Bitcoin Core release: 28.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Generating a large number of safe bitcoin vanity addresses  (Read 1155 times)
addrstore.com (OP)
Newbie
*
Offline Offline

Activity: 45
Merit: 0


View Profile WWW
August 29, 2017, 06:36:22 AM
 #1

Hi guys.

There was such idea: if you want absolutely safe to generate the vanity address (outsource) it is necessary to use partial key. This is too expensive, you need to use all the processing power to generate one vanity address. My idea: use third-party services that will generate a private and public key (something like a certification authority center as GeoTrust, Comodo etc.). The public key will be used to generate a large number of vanity addresses, so they can be made much cheaper. In this case, the full private key can only be obtained using the private key of a third-party service.

Can it work?
achow101
Moderator
Legendary
*
expert
Offline Offline

Activity: 3542
Merit: 6884


Just writing some code


View Profile WWW
August 29, 2017, 01:54:04 PM
 #2

How does that make generating vanity addresses cheaper? You still need the same amount of processing power to generate one vanity address.

addrstore.com (OP)
Newbie
*
Offline Offline

Activity: 45
Merit: 0


View Profile WWW
August 30, 2017, 05:52:05 AM
 #3

How does that make generating vanity addresses cheaper? You still need the same amount of processing power to generate one vanity address.

Yes, the more computing power, the better.

However, you can generate many vanity addresses at once. Accordingly, the more simultaneously generated vanity addresses, the greater the chance to find one of them and the less its cost.

It all depends on the chance: the more the chance to find a vanity address, the cheaper it is.
aleksej996
Sr. Member
****
Offline Offline

Activity: 490
Merit: 389


Do not trust the government


View Profile
August 30, 2017, 08:25:16 AM
 #4

I don't understand the goal here. If you want to create many vanity addresses from the same public key, then all of them will have one private key. So this isn't really for many users, it is if one user wants many vanity addresses and that they are transparently connected to each other for anyone to see.
achow101
Moderator
Legendary
*
expert
Offline Offline

Activity: 3542
Merit: 6884


Just writing some code


View Profile WWW
August 30, 2017, 02:14:25 PM
Merited by ABCbits (2)
 #5

However, you can generate many vanity addresses at once. Accordingly, the more simultaneously generated vanity addresses, the greater the chance to find one of them and the less its cost.

It all depends on the chance: the more the chance to find a vanity address, the cheaper it is.
Oh, I see. So any address generated can be a vanity address for a large list of prefixes so it can be more efficient.

The only problem with this setup is the trusted third party. Everyone would have to trust that you don't give them the generated private key and that they don't give you their private key. But everyone is going to know their private key anyways, so there is a lot of security risk there.

Instead of using a trusted third party, what you could do is have each participant generate their own new key pair. When you generate addresses, you add all participants' public keys along with the one you generated in order to find a vanity address. This would be multi-party split key generation. Once an address is found, all participants send their private keys to the person who got their vanity address. Then they generate new key pairs and send the public keys back to you for the next vanity address to be generate. In this way, no one but the receiver of the vanity address can actually know the full private key to it.

I don't understand the goal here. If you want to create many vanity addresses from the same public key, then all of them will have one private key. So this isn't really for many users, it is if one user wants many vanity addresses and that they are transparently connected to each other for anyone to see.
You can't make multiple addresses from one public key, that's not how addresses work. It is only one public-private key pair for each address. What he is doing is that he would be doing split key generation where the public key generated is added to the public key owned by a trusted third party so that a final public key can be generated and its address generated.

aleksej996
Sr. Member
****
Offline Offline

Activity: 490
Merit: 389


Do not trust the government


View Profile
August 30, 2017, 02:58:46 PM
 #6

I don't understand the goal here. If you want to create many vanity addresses from the same public key, then all of them will have one private key. So this isn't really for many users, it is if one user wants many vanity addresses and that they are transparently connected to each other for anyone to see.
You can't make multiple addresses from one public key, that's not how addresses work. It is only one public-private key pair for each address. What he is doing is that he would be doing split key generation where the public key generated is added to the public key owned by a trusted third party so that a final public key can be generated and its address generated.
I know, it is what I meant to say. I just assumed that like in RSA keys, if you start with one public key and change just the exponent of it in order to change the hash, then it's private keys of all of these new keys would have the same factors and be able to calculate the private exponent for all these public keys.
Assuming that during key generation factors are not discarded and just private exponent kept.
I made a lot of assumptions here based on my understanding of RSA keys and how you could generate different hashes for public keys with same module by just changing the public exponent, so that the owner of private keys could generate a private exponent corresponding to the new public exponent. I assumed it is a similar process and that all of these public keys would be (visibly) connected in such a way. Am I correct?
achow101
Moderator
Legendary
*
expert
Offline Offline

Activity: 3542
Merit: 6884


Just writing some code


View Profile WWW
August 30, 2017, 03:05:52 PM
 #7

I know, it is what I meant to say. I just assumed that like in RSA keys, if you start with one public key and change just the exponent of it in order to change the hash, then it's private keys of all of these new keys would have the same factors and be able to calculate the private exponent for all these public keys.
Assuming that during key generation factors are not discarded and just private exponent kept.
I made a lot of assumptions here based on my understanding of RSA keys and how you could generate different hashes for public keys with same module by just changing the public exponent, so that the owner of private keys could generate a private exponent corresponding to the new public exponent. I assumed it is a similar process and that all of these public keys would be (visibly) connected in such a way. Am I correct?
No, ECDSA keys are not like RSA keys. You can't do that to ECDSA keys.

addrstore.com (OP)
Newbie
*
Offline Offline

Activity: 45
Merit: 0


View Profile WWW
September 01, 2017, 06:46:47 AM
 #8


I don't understand the goal here. If you want to create many vanity addresses from the same public key, then all of them will have one private key. So this isn't really for many users, it is if one user wants many vanity addresses and that they are transparently connected to each other for anyone to see.

You can't make multiple addresses from one public key, that's not how addresses work. It is only one public-private key pair for each address. What he is doing is that he would be doing split key generation where the public key generated is added to the public key owned by a trusted third party so that a final public key can be generated and its address generated.

You have understood correctly. So, if I need to generate a lot of vanity addresses, then I would need to use a separate public key for each address and spend all the processing power on finding just one vanity address. But I can generate many vanity addresses at a time, using the public key received from the 3rd party.
addrstore.com (OP)
Newbie
*
Offline Offline

Activity: 45
Merit: 0


View Profile WWW
September 01, 2017, 07:22:07 AM
 #9


The only problem with this setup is the trusted third party. Everyone would have to trust that you don't give them the generated private key and that they don't give you their private key. But everyone is going to know their private key anyways, so there is a lot of security risk there.

Instead of using a trusted third party, what you could do is have each participant generate their own new key pair. When you generate addresses, you add all participants' public keys along with the one you generated in order to find a vanity address. This would be multi-party split key generation. Once an address is found, all participants send their private keys to the person who got their vanity address. Then they generate new key pairs and send the public keys back to you for the next vanity address to be generate. In this way, no one but the receiver of the vanity address can actually know the full private key to it.


This problem can be solved as follows: third parties who will provide public keys for generating a large number of vanity addresses should work according to some rules, for example:
1. function "get public key" - always returns a new public key to generate a large number of vanity addresses;
2. function "get private key" - based on a public key from function 1 the private key is given out. You can request a private key ONLY 1 time, then the public key is considered inactive and can not be used. When you repeatedly request the same private key, the service should give an error and say that the key has already been issued (compromised).


The service for generating vanity addresses will work according to the following algorithm: a request for a public key from a third party, a private key, it will not be requested, because the private key will then be compromised. Next, the service looks for many vanity addresses, if found, then sends the customer a vanity address and a third-party public key. And when the customer wants to get a private key from a third party, he will already know whether the key is compromised or not. And then the algorithm repeats.
aleksej996
Sr. Member
****
Offline Offline

Activity: 490
Merit: 389


Do not trust the government


View Profile
September 01, 2017, 11:25:34 AM
 #10

Well then as I understand you will not be using a split key generation, since third parties will have the customers private key, which is kind of ridiculous. You might as well just make a online wallet with vanity address feature, instead of giving users false hope that only they can use that address. Third party here will have access to all the bitcoins forever and since customers payed money to have that address, there would be no sense in moving those coins to a better address. You might as well make a vanity address proxy service, where you pass along funds sent to those addresses.

Since the third party will have the private key anyway, you might as well make a online wallet without the option of exporting the private key to the customer and just generate all the vanity addresses from the same private key and keep it secret from all the customers. This would have the same security and save a lot of processing power.
addrstore.com (OP)
Newbie
*
Offline Offline

Activity: 45
Merit: 0


View Profile WWW
September 01, 2017, 12:12:55 PM
 #11

Well then as I understand you will not be using a split key generation, since third parties will have the customers private key, which is kind of ridiculous. You might as well just make a online wallet with vanity address feature, instead of giving users false hope that only they can use that address. Third party here will have access to all the bitcoins forever and since customers payed money to have that address, there would be no sense in moving those coins to a better address. You might as well make a vanity address proxy service, where you pass along funds sent to those addresses.

Since the third party will have the private key anyway, you might as well make a online wallet without the option of exporting the private key to the customer and just generate all the vanity addresses from the same private key and keep it secret from all the customers. This would have the same security and save a lot of processing power.

No, you misunderstood!

We will use generation of vanity addresses using split-keys, but the partial public key for generation will be provided not by the customer, but by a third party. The full private key for the vanity address can be obtained using the partial private key of the third party and the partial private key of service, that generated the vanity address. It's clear that these 2 partial private keys will eventually be received only by the customer and no one else.
achow101
Moderator
Legendary
*
expert
Offline Offline

Activity: 3542
Merit: 6884


Just writing some code


View Profile WWW
September 01, 2017, 01:57:40 PM
 #12

This problem can be solved as follows: third parties who will provide public keys for generating a large number of vanity addresses should work according to some rules, for example:
1. function "get public key" - always returns a new public key to generate a large number of vanity addresses;
2. function "get private key" - based on a public key from function 1 the private key is given out. You can request a private key ONLY 1 time, then the public key is considered inactive and can not be used. When you repeatedly request the same private key, the service should give an error and say that the key has already been issued (compromised).


The service for generating vanity addresses will work according to the following algorithm: a request for a public key from a third party, a private key, it will not be requested, because the private key will then be compromised. Next, the service looks for many vanity addresses, if found, then sends the customer a vanity address and a third-party public key. And when the customer wants to get a private key from a third party, he will already know whether the key is compromised or not. And then the algorithm repeats.
That does not remove the trust problem at all. What prevents the service from leaking the private keys (besides that you said so)? There is nothing technically that would prevent them from disclosing the private keys, and disclosing them would be easy to do.

Jerfer
Full Member
***
Offline Offline

Activity: 121
Merit: 100


View Profile
September 01, 2017, 05:46:00 PM
 #13

The only way I event trust a vanity address like this is if I can compile from an open source code that is heavily reviewed and do it offline.

████→→       ● DeepOnion                                                                       ✯✯✯✯✯✯✯✯✯✯✯✯✯✯✯✯✯✯✯✯✯✯✯✯✯✯ 
████→→       ● Tor integrated, 100% anonymous!                                ✯     Get Your FREE Coins NOW!        ✯
████→→       ● Free Airdrop! (No ICO, No Crowdfund)                        ✯✯✯✯✯✯✯✯✯✯✯✯✯✯✯✯✯✯✯✯✯✯✯✯✯✯
DannyHamilton
Legendary
*
Offline Offline

Activity: 3472
Merit: 4801



View Profile
September 01, 2017, 06:09:17 PM
 #14

The full private key for the vanity address can be obtained using the partial private key of the third party and the partial private key of service, that generated the vanity address.

You are using a VERY strange and unusual definition for the word "safe".

As I understand it, you are suggesting...

A complete stranger that I know nothing about and have no reason to trust generates a partial private key for himself and gives me a copy of it.
Another complete stranger that I know nothing about and have no reason to trust uses the partial public key that is associated with that partial private key to generate a vanity address.
This second stranger has the second part of the private key for himself and gives me a copy of it.

So, now two complete strangers that I know nothing about and have no reason to trust each have a different half of my private key, and I'm supposed to feel "safe" about that?

Furthermore, the first stranger will be sharing his half of my private key with lots of other people (so they can all get vanity addresses generated with the same effort by the second stranger).

Now, lots of people all have one half of my private key, and the vanity address generator has the other half.  Furthermore, depending on the method used by the vanity address generator, it may be possible for someone else to use their vanity address partial private key from the same generator to calculate mine?

No thanks.
addrstore.com (OP)
Newbie
*
Offline Offline

Activity: 45
Merit: 0


View Profile WWW
September 02, 2017, 02:07:46 PM
Last edit: September 02, 2017, 02:27:07 PM by addrstore.com
 #15

This problem can be solved as follows: third parties who will provide public keys for generating a large number of vanity addresses should work according to some rules, for example:
1. function "get public key" - always returns a new public key to generate a large number of vanity addresses;
2. function "get private key" - based on a public key from function 1 the private key is given out. You can request a private key ONLY 1 time, then the public key is considered inactive and can not be used. When you repeatedly request the same private key, the service should give an error and say that the key has already been issued (compromised).


The service for generating vanity addresses will work according to the following algorithm: a request for a public key from a third party, a private key, it will not be requested, because the private key will then be compromised. Next, the service looks for many vanity addresses, if found, then sends the customer a vanity address and a third-party public key. And when the customer wants to get a private key from a third party, he will already know whether the key is compromised or not. And then the algorithm repeats.
That does not remove the trust problem at all. What prevents the service from leaking the private keys (besides that you said so)? There is nothing technically that would prevent them from disclosing the private keys, and disclosing them would be easy to do.

In order for these services to be trusted, they must have an appropriate level of security, which should not allow leaks of public and private keys. It is not in their interests to earn long trust, and then lose it because of data leakage.

In addition, issued private keys do not need to be stored and can be destroyed.
addrstore.com (OP)
Newbie
*
Offline Offline

Activity: 45
Merit: 0


View Profile WWW
September 02, 2017, 02:23:56 PM
 #16

The only way I event trust a vanity address like this is if I can compile from an open source code that is heavily reviewed and do it offline.

Let's proceed from the fact that not all users are technical experts who can compile the source code and even more so that it is inspected for backdoors.

But if you are a technical expert and you do all this, then you may not have the necessary computing power to generate a complex vanity address in the foreseeable future.

Therefore, to use some third-party services to generate vanity addresses is a good idea, the main thing is that it is safe enough.
addrstore.com (OP)
Newbie
*
Offline Offline

Activity: 45
Merit: 0


View Profile WWW
September 02, 2017, 02:58:46 PM
 #17

So, now two complete strangers that I know nothing about and have no reason to trust each have a different half of my private key, and I'm supposed to feel "safe" about that?

These two strangers will only have 1 part of the full private key, i.e. no stranger can get a full private vanity address key. In this, the whole point is that parts of the private key are kept by different strangers. In fact, they must collude in order to get a full private key, but then they both lose trust from the side of other users.

Furthermore, the first stranger will be sharing his half of my private key with lots of other people (so they can all get vanity addresses generated with the same effort by the second stranger).

No, after a vanity address was generated for some customer, a new public key obtained from a third-party service is used for the new customer, because a private key from a third-party service can be obtained only 1 time (see post#9).

Now, lots of people all have one half of my private key, and the vanity address generator has the other half.  Furthermore, depending on the method used by the vanity address generator, it may be possible for someone else to use their vanity address partial private key from the same generator to calculate mine?

No, only you can get the full private key of your vanity address. And with an insignificant amount of probability, the full private key of your vanity address can get by "strangers" if they enter into collusion, but they both lose trust from other users.
achow101
Moderator
Legendary
*
expert
Offline Offline

Activity: 3542
Merit: 6884


Just writing some code


View Profile WWW
September 02, 2017, 03:28:28 PM
 #18

In order for these services to be trusted, they must have an appropriate level of security, which should not allow leaks of public and private keys. It is not in their interests to earn long trust, and then lose it because of data leakage.

In addition, issued private keys do not need to be stored and can be destroyed.
The point is that they have to be trusted. But this whole thing can be done in a more trustless manner that does not require a third party at all, just the participants and you. So why do you have to introduce a trusted third party into this? The trusted third party is single point of failure; it does not require them to be malicious, it just requires them to do something stupid, and people tend to do stupid things accidentally.

No, only you can get the full private key of your vanity address. And with an insignificant amount of probability, the full private key of your vanity address can get by "strangers" if they enter into collusion, but they both lose trust from other users.
Then we have to trust that they don't collude. Why should we be trusting them to not collude? We don't know who they are, we have never met them, we don't know what they are doing behind closed doors. What reason should we ever trust these strangers with our partial private keys?



P.S. Don't make consecutive posts replying to people like you just did. Instead make one big post with your replies to the people you want to reply to.

addrstore.com (OP)
Newbie
*
Offline Offline

Activity: 45
Merit: 0


View Profile WWW
September 04, 2017, 05:45:46 AM
 #19


No, only you can get the full private key of your vanity address. And with an insignificant amount of probability, the full private key of your vanity address can get by "strangers" if they enter into collusion, but they both lose trust from other users.
Then we have to trust that they don't collude. Why should we be trusting them to not collude? We don't know who they are, we have never met them, we don't know what they are doing behind closed doors. What reason should we ever trust these strangers with our partial private keys?


I understood you.  But look at the online wallets. They own the full private keys of your addresses. Such an online wallet at any time can steal your coins and he does not have to collude with anyone. You have to completely trust them, but in return you get the convenience to make transactions with the wallet.

For vanity addresses, the situation is similar - you trust the service for generating vanity addresses and the service for providing public keys, and in return you get a vanity address at a significantly low price. Even with vanity addresses, security is much higher, because to steal your coins simultaneously 2 services should be dishonest, they must find each other, agree among themselves who will get the full private key and steal coins and how they will be shared, and most importantly - they both will lose the trust of users and its business.

In addition, if one of the services turns out to be honest, it can warn other users in advance that the other service is dishonest.
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!