<p>Thanks to Elliptic Curve cryptography, a third party doesn't need to know the private key to generate a vanity address, as JoelKatz describes here:</p>

<ul>
<li><a href="http://bitcointalk.org/index.php?topic=81865.msg901491#msg901491">http://bitcointalk.org/index.php?topic=81865.msg901491#msg901491</a></li>
</ul>

CC BY-SA 3.0
2012-05-28T01:38:44.877Z
Hmm, very interesting and a bit mind boggling...
ThePiachu
CC BY-SA 3.0
2012-05-30T11:24:36.443Z
I think there are some errors in Joel's post, for example "reduce it modulo the SECP256k1 generator".  You never use the generator in that way, instead you should reduce it modulo the order of the underlying field, p.  Also, there's no need to chose numbers smaller than the generator.  Finally, it may not be clear that when adding points on the curve (x1,y1) and (x2,y2), their sum isn't (x1+x2,y1+y2), but rather uses a special addition function, described on page 12 of http://cs.ucsb.edu/~koc/ccs130h/notes/ecdsa-cert.pdf
Chris Moore
CC BY-SA 3.0
2012-05-31T23:46:57.703Z
@ChrisMoore Actually, I think it might be N - the order of the generator. I've been playing with those concepts a bit recently and N appeared to be giving me the proper results...
ThePiachu
CC BY-SA 3.0
2012-06-01T04:49:27.270Z
@ThePiachu that makes sense.  I've also been playing with these concepts, and using the order of the underlying field has been giving me the wrong results ;)
Chris Moore
CC BY-SA 3.0
2012-05-28T01:14:25.390Z
2012-05-28T01:14:25.390Z
Stephen Gornick
<p>I'll be talking about the details.</p>
<p>An ECC public key is of the form <code>dG</code>, where <code>G</code> is the generator point (a curve parameter) and <code>d</code> is your private key (must be between <code>1</code> and <code>prime order-1</code> inclusive)</p>
<p><code>d</code> can't be found without brute-forcing points, if you know the public key (<code>dg</code>).</p>
<p>The goal is to make someone find an appropriate <code>dG</code> that <code>Hash(dG)</code> is in the expected range.</p>
<p>So, you'll need to be keeping a part of <code>d</code> to yourself, and then combine it. How?</p>
<p>For all methods, the beginning is the same:</p>
<p>You calculate some <code>d_1</code> and  keep it to yourself, while sharing <code>(d_1)G</code></p>
<p>To start with, let's review the properties of EC points.</p>
<blockquote>
<p>Linearity:</p>
<p><code>(d_1)G + (d_2)G = (d_1 + d_2)G</code></p>
<p><code>(d_1)(kG) = (k * d_1)G</code></p>
</blockquote>
<hr />
<h2>Method 1) Additive</h2>
<p><em>This is the method used by Vanitygen, and it's way more popular than the others.</em></p>
<p>A bounty hunter tries many random <code>d_2</code> values that make <code>Hash((d_2)G + (d_1)G)</code> in the expected pattern range. If the hunter succeeds, he sends <code>d_2</code> to the bounty giver (either public or private). Now the vanity &quot;assigner&quot; can combine <code>d_1</code> and <code>d_2</code> to create the final private &amp; public keys.</p>
<p>Note that <code>(d_1 + d_2)G</code> can also be calculated by third parties, which means other people will be able to track his/her payments. (because <code>d_2</code> can be shared by the bounty hunter, <code>G</code> is already known, and <code>(d_1)G</code> was published by the assigner, so <code>(d_2)G + ((d_1)G)</code>) This also applies to all known methods.</p>
<h2>Method 2) Multiplicative</h2>
<p><em>This is used rarely.</em></p>
<p>Now that the bounty hunter wanted <code>Hash((d_1 + d_2)G)</code> in the expected pattern range, he wanted something different, and used a different way to do trustless vanity generation.</p>
<p>The innovative bounty hunter calculates a <code>d_2</code> value, by brute-forcing <code>Hash(d_2((d_1)G))</code>: He computes multiples of <code>(d_1)G</code> and checks them.</p>
<p>Now, do you understand that <code>d_2</code> must be between <code>1</code> and <code>prime order-1</code>, also in this method? (Hint: What's the meaning of the prime order?)</p>
<p>It uses the fact that <code>d_2((d_1)G) = (d_2 * d_1)G</code> (with appropriate modulo operations)</p>
<h2>Method 3: Combined</h2>
<p><em>I've never seen this mentioned anywhere. It's not very useful.</em></p>
<p>Simple: The bounty hunter finds <code>d_2</code> and <code>d_3</code> values such that <code>Hash((d_1 * d_2)G + (d_3)G)</code> is in the expected pattern range. This is more complex, because it has two variables. No research has been made on this. At first glance, it looks slower, but there's nothing that stops the vanity miner from fixing <code>d_2</code> or <code>d_3</code>.</p>

CC BY-SA 4.0
2018-05-24T15:55:52.207Z
2019-11-01T11:21:29.977Z
2020-06-16T11:10:03.350Z
MCCCS
<p>From what it appears, yes, it is possible, and quite simple really to outsource vanity address creation to a third party without risking anything.</p>

<p>Bitcoin addresses are created from ECDSA keypairs. Their property is that if you take two private keys and add them together (with appropriate modulo operations), the sum will map to a public key that is the same one as one would obtain by adding the two public keys corresponding to the private keys.</p>

<p>This means that in order to outsource vanity key generation, one can create an ECDSA keypair, store the private key safely, and give out the public key to other people. They would then proceed to generate ECDSA keypairs, summing the generated public keys to the one provided by you, and checking whether they map to the appropriate vanity address. If it does, they need only to give you the appropriate private key, which you then need to add to your secret private key in order to obtain the private key that maps itself to the vanity address.</p>

<p><a href="http://bitcointalk.org/index.php?topic=81865.msg901491#msg901491">JoelKatz explained it in his post</a>, and I went ahead and implemented a <a href="https://bitcointalk.org/index.php?topic=84569.0">"vanity pool"</a> that enables such outsourcing. Moreover, I also created a simple testing suite for playing with <a href="http://gobittest.appspot.com/Vanity">combining the ECDSA keypairs</a>. Currently there are no "split key vanity miners" available, nor any offline solutions for this problem, but they can follow shortly.</p>

CC BY-SA 3.0
2012-06-01T03:04:16.757Z
2012-06-01T03:04:16.757Z
ThePiachu
<p>One can easily generate <a href="https://bitcointalk.org/index.php?topic=25804.0">vanity addresses</a> for Bitcoin, but they can take quite awhile to generate. Outsourcing that process to someone with a strong mining rig is an option, but then one runs into the risk of the person generating the address using it without our knowledge to steal our coins. Is it possible to generate vanity addresses in such a manner so as to make it impossible for anyone to steal your private keys?</p>

<security><theft><vanity-address>
Can one safely buy vanity addresses from a third party without risking one's coins from being stolen?
ThePiachu
# Can one safely buy vanity addresses from a third party without risking one's coins from being stolen?

(Asked by: username_0 on 2012-05-27)

One can easily generate [vanity addresses](https://bitcointalk.org/index.php?topic=25804.0) for Bitcoin, but they can take quite awhile to generate. Outsourcing that process to someone with a strong mining rig is an option, but then one runs into the risk of the person generating the address using it without our knowledge to steal our coins. Is it possible to generate vanity addresses in such a manner so as to make it impossible for anyone to steal your private keys?

**Tags:** security, theft, vanity-address


---

## 3 answers

### Answer by username_0 on 2012-06-01. Score: 20 | Accepted answer

From what it appears, yes, it is possible, and quite simple really to outsource vanity address creation to a third party without risking anything.

Bitcoin addresses are created from ECDSA keypairs. Their property is that if you take two private keys and add them together (with appropriate modulo operations), the sum will map to a public key that is the same one as one would obtain by adding the two public keys corresponding to the private keys.

This means that in order to outsource vanity key generation, one can create an ECDSA keypair, store the private key safely, and give out the public key to other people. They would then proceed to generate ECDSA keypairs, summing the generated public keys to the one provided by you, and checking whether they map to the appropriate vanity address. If it does, they need only to give you the appropriate private key, which you then need to add to your secret private key in order to obtain the private key that maps itself to the vanity address.

[JoelKatz explained it in his post](http://bitcointalk.org/index.php?topic=81865.msg901491#msg901491), and I went ahead and implemented a ["vanity pool"](https://bitcointalk.org/index.php?topic=84569.0) that enables such outsourcing. Moreover, I also created a simple testing suite for playing with [combining the ECDSA keypairs](http://gobittest.appspot.com/Vanity). Currently there are no "split key vanity miners" available, nor any offline solutions for this problem, but they can follow shortly.


---

### Answer by username_1 on 2012-05-28. Score: 9

Thanks to Elliptic Curve cryptography, a third party doesn't need to know the private key to generate a vanity address, as JoelKatz describes here:

* <http://bitcointalk.org/index.php?topic=81865.msg901491#msg901491>

> **Comments:**
> **username_0**: Hmm, very interesting and a bit mind boggling...  
> **username_2**: I think there are some errors in Joel's post, for example "reduce it modulo the SECP256k1 generator".  You never use the generator in that way, instead you should reduce it modulo the order of the underlying field, p.  Also, there's no need to chose numbers smaller than the generator.  Finally, it may not be clear that when adding points on the curve (x1,y1) and (x2,y2), their sum isn't (x1+x2,y1+y2), but rather uses a special addition function, described on page 12 of http://cs.ucsb.edu/~koc/ccs130h/notes/ecdsa-cert.pdf  
> **username_0**: @username_2 Actually, I think it might be N - the order of the generator. I've been playing with those concepts a bit recently and N appeared to be giving me the proper results...  
> **username_2**: @username_0 that makes sense.  I've also been playing with these concepts, and using the order of the underlying field has been giving me the wrong results ;)  

---

### Answer by username_3 on 2018-05-24. Score: 1

I'll be talking about the details.

An ECC public key is of the form `dG`, where `G` is the generator point (a curve parameter) and `d` is your private key (must be between `1` and `prime order-1` inclusive)

`d` can't be found without brute-forcing points, if you know the public key (`dg`).

The goal is to make someone find an appropriate `dG` that `Hash(dG)` is in the expected range.

So, you'll need to be keeping a part of `d` to yourself, and then combine it. How?

For all methods, the beginning is the same:

You calculate some `d_1` and keep it to yourself, while sharing `(d_1)G`

To start with, let's review the properties of EC points.

> Linearity:
>
> `(d_1)G + (d_2)G = (d_1 + d_2)G`
>
> `(d_1)(kG) = (k * d_1)G`

---

## Method 1) Additive

*This is the method used by Vanitygen, and it's way more popular than the others.*

A bounty hunter tries many random `d_2` values that make `Hash((d_2)G + (d_1)G)` in the expected pattern range. If the hunter succeeds, he sends `d_2` to the bounty giver (either public or private). Now the vanity "assigner" can combine `d_1` and `d_2` to create the final private & public keys.

Note that `(d_1 + d_2)G` can also be calculated by third parties, which means other people will be able to track his/her payments. (because `d_2` can be shared by the bounty hunter, `G` is already known, and `(d_1)G` was published by the assigner, so `(d_2)G + ((d_1)G)`) This also applies to all known methods.

## Method 2) Multiplicative

*This is used rarely.*

Now that the bounty hunter wanted `Hash((d_1 + d_2)G)` in the expected pattern range, he wanted something different, and used a different way to do trustless vanity generation.

The innovative bounty hunter calculates a `d_2` value, by brute-forcing `Hash(d_2((d_1)G))`: He computes multiples of `(d_1)G` and checks them.

Now, do you understand that `d_2` must be between `1` and `prime order-1`, also in this method? (Hint: What's the meaning of the prime order?)

It uses the fact that `d_2((d_1)G) = (d_2 * d_1)G` (with appropriate modulo operations)

## Method 3: Combined

*I've never seen this mentioned anywhere. It's not very useful.*

Simple: The bounty hunter finds `d_2` and `d_3` values such that `Hash((d_1 * d_2)G + (d_3)G)` is in the expected pattern range. This is more complex, because it has two variables. No research has been made on this. At first glance, it looks slower, but there's nothing that stops the vanity miner from fixing `d_2` or `d_3`.


---

