 Show Posts
|
|
Pages: [1] 2 3 »
|
We made some exclusive addresses with prefixes 23, 234, 777, LUXE, GoLD completely free. Limitations of the offer: 1. no more than 1 order per IP-address per week; 2. no more than 2 free addresses per IP-address per week; 3. IP-addresses should not be "gray" (nodes TOR, proxy, etc.). |
|
|
|
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. |
|
|
|
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. |
|
|
|
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. |
|
|
|
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. |
|
|
|
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. |
|
|
|
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. |
|
|
|
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. |
|
|
|
I wonder why a CUDA version of OCL vanitygen never got made? Surely, it would better on NVIDIA cards.
Strange. I have oclvanitygen.exe and it's working great with my integrated Nvidia GPU on the laptop. Already had some fun with the proggie... The work of "A Performance Comparison of CUDA and OpenCL" says that the performance of the OpenCL core loses CUDA from 13% to 63%. So, if you rewrite the utility Vanitygen on CUDA, you can significantly increase the speed of searching for vanity addresses. |
|
|
|
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. |
|
|
|
|
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?
|
|
|
|
|
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?
|
|
|
|
|
Thanks. A beautiful and detailed answer. Now I agree that for p2sh addresses there really is a need to use a longer hash.
|
|
|
|
In order to get collision with a 40% chance on a set of 2 ^ 80 addresses, you need a memory size of 2.4 * 10 ^ 25 bytes. And even applying algorithms that use a trade-off between memory and calculation time - it will still be a huge size.
That's not correct. Floyd's cycle-finding algorithm can be used to find colliding script hashes with O(1) memory, for just a factor 3 slowdown. If I understand correctly on Wikipedia, this is a pointer algorithm, it uses O(1) memory, but the data structure itself, for which pointers will be created how much will it occupy? |
|
|
|
you need a memory size of 2.4 * 10 ^ 25 bytes. And even applying algorithms that use a trade-off between memory and calculation time - it will still be a huge size.
No it won't. Collisions can be found an an effectively storageless manner with a small constant factor slowdown, I gave google terms upthread. You're suffering from the same ignorance that caused the collision design flaw in "xthin" where they were claiming that collisions of a 64-bit hash were infeasible to compute due to storage requirements. (which I eventually eventually grew tired of correcting and started responding to all the messages with 64-bit sha2 collisions.) You want to say that performing a hash according to the scheme: Hash1 = RIPEMD160(SHA256(Data1)) Hash2 = RIPEMD160(SHA256(Data2)) You can find such Data1 and Data2, in which the first 64 bits in hash1 and hash2 will be the same without using the birthdays attack and bruteforce? And you will not spend much memory? Can I see the algorithm (GitHub) and proof of work? I want to try it myself. How much time will it take to calculate this? |
|
|
|
Thanks for the answers, now I'm calm for bitcoin ...  |
|
|
|
With 160 bit addresses, there is a reasonably good chance that an attacker could do so within 2^80 attempts.
What good chance are you talking about? You can take specific numbers and count. In order to get collision with a 40% chance on a set of 2 ^ 80 addresses, you need a memory size of 2.4 * 10 ^ 25 bytes. And even applying algorithms that use a trade-off between memory and calculation time - it will still be a huge size. All the Internet for the time of its existence is estimated only in 10 ^ 24 bytes ( https://www.livescience.com/54094-how-big-is-the-internet.html), i.e. You will need a memory capacity like 200 modern Internet, I'm not talking about computing power, which will also be needed. Hence, we can conclude that in practice we will not be able to find a collision at the current time and for the next 15-20 years it will be impossible. Quantum computers will appear faster because of which it will be necessary to change all modern cryptography and hashing methods.. |
|
|
|
Accidentally stumbled in the Internet for the project: https://lbc.cryptoguru.org. Found a page with their trophies. I have a question - did they actually find private keys to all the addresses listed or is it a fake? |
|
|
|
|
The author, there is no need to go to the 256-bit address. 160 bits is enough to ensure the security of the address.
The problem is completely contrived.
In order to get a collision with a probability of 1.77636E-15 (and this probability is negligible, there is a higher chance of winning the lottery) there must be a blockchain in which 2 ^ 56 addresses will be used, each address being 20 bytes (160 bit). In total, the blockchain with such an amount of addresses will occupy not less than 2 ^ 56 * 20 = 1441151 TB (this is the lowest estimate), by the way, at the moment, the blockchain is only 126 GB.
|
|
|
|
|
