Vanity Pool - vanity address generator pool

[WhyFhy]

Hi, I found a solution for Searched pattern: 1RoseCross
The payment is not going through to me. Writes: Solution does not match the pattern
Everything is correct, I checked everything again. I wrote about it to ThePiachu. The search took 19 days on the same equipment.


1SatoshiNak      In line for search
1AustriaFTW     Search
1HASHCRACK1   In line for search
1RoseCross       The solution was found
1iJuniorTV         The solution was found

You found a solution. Not the solution. Try again.
Your keypairs  aren't merging to a known prefix .
You have about a 1 in 6 chance of getting it right the first time.
There is a slight chance something may be going wrong on the backend. But I doubt it. (This is why I'm pretty certain your keypairs are mismatched) Correct solution. Incorrect merged prefix.

I'm not saying Piachu will rug pull but BTC did just hit 100k I'm pretty sure a lot of people are going to exit soon. Just hope your endeavors don't get pulled.

Why does my solution not always match after combining two keys it gives a completely different address? I have found the correct address.
https://gobittest.appspot.com/VanityAll
I checked other options found and they also did not all match; the first symbols of the address were completely different after combining the two keys.

1SatoshiNak      In line for search
1AustriaFTW     In line for search
1HASHCRACK1   In line for search
1RoseCross       Search
1iJuniorTV        The solution was found

ThePiachu Continues to work on fixing payments from the pool site.

Can you explain this? As far as I know, vanity split key matches should be correct and not have a "1 in 6" chance.

Here's a pretty good writeup explaining it all. TLDR user  generated a child key.

I found goryniche or whatever like 4 times but someone beat me to it.

When I operated 1Splitkey I created (forked) tool and scripted it to check work.

I only learned about child keys through some old programming Bitcoin with CS writeup I found encountering the same issue.

Based on what I've read and researched a master key actually controls or is linked to 5 other wallets by default, even with split keys. Sound familiar?(Multi sig) So no surprise there. I just didn't understand it back then and how it related to legacy address.

Hope this helps clear things up for y'all.

[Cricktor]

Why does my solution not always match after combining two keys it gives a completely different address? I have found the correct address.
https://gobittest.appspot.com/VanityAll
I checked other options found and they also did not all match; the first symbols of the address were completely different after combining the two keys.
ThePiachu Continues to work on fixing payments from the pool site.

If you combine the public key from the requestor with the public key derived from your found private key, the combined public key (added or multiplied, don't remember what vanitypool used) should hash to the requested public address prefix. There's not much room for ambiguity.

I'm not sure if I understand what you're trying to tell. Of course the vanitypool website could still have some bugs, but if it doesn't accept your "solution" than I'd rather think something is wrong with your "solution" or your toolset than otherwise.

If you have a correct split-key solution, it will always give the proper public address prefix when combined properly (i.e. not messing up with compressed/uncompressed keys or adding split-keys when multiplying is required or vice-versa).

ThePiachu Continues to work on fixing payments from the pool site.

Out of curiosity: did you receive the payment for your solution of 1iJuniorTV?

Here's a pretty good writeup explaining it all. TLDR user  generated a child key.

Your cited article doesn't have anything to do with vanitypool. I mean, I could be blind and not see a connection, so beat me to it, please.

Why do you bring up the topic of HD wallet address derivation and try to mingle that with split-key combining for a safe vanity public address that someone else has computed for you?

Vanitypool doesn't use an extended master private key or similar BIP32 stuff.

[ddf2020]

Why does my solution not always match after combining two keys it gives a completely different address? I have found the correct address.
https://gobittest.appspot.com/VanityAll
I checked other options found and they also did not all match; the first symbols of the address were completely different after combining the two keys.
ThePiachu Continues to work on fixing payments from the pool site.

If you combine the public key from the requestor with the public key derived from your found private key, the combined public key (added or multiplied, don't remember what vanitypool used) should hash to the requested public address prefix. There's not much room for ambiguity.

I'm not sure if I understand what you're trying to tell. Of course the vanitypool website could still have some bugs, but if it doesn't accept your "solution" than I'd rather think something is wrong with your "solution" or your toolset than otherwise.

If you have a correct split-key solution, it will always give the proper public address prefix when combined properly (i.e. not messing up with compressed/uncompressed keys or adding split-keys when multiplying is required or vice-versa).

ThePiachu Continues to work on fixing payments from the pool site.

Out of curiosity: did you receive the payment for your solution of 1iJuniorTV?

Here's a pretty good writeup explaining it all. TLDR user  generated a child key.

Your cited article doesn't have anything to do with vanitypool. I mean, I could be blind and not see a connection, so beat me to it, please.

Why do you bring up the topic of HD wallet address derivation and try to mingle that with split-key combining for a safe vanity public address that someone else has computed for you?

Vanitypool doesn't use an extended master private key or similar BIP32 stuff.

For fun, I checked other key variants for 1iJuniorTV and out of 15 variants, only about 5 matched the prefixes.
1RoseCross found 6 variants and none of them matched the prefixes at all.
So the hardware is fine, or there is a problem with converting two keys or when combining two keys, another variant with a different prefix is ​​possible.
Yes, I also thought that when adding or multiplying two keys there should be a 100% match for the found prefix of the address of the searched, apparently not. According to my data, the probability of a match is about 30%. If you remove the public key search option, Vanity finds 100% correct prefixes.
The same video card found a variant for 1iJuniorTV as for 1RoseCross.
ThePiachu paid me 0.01 BTC from his own funds for the solution for 1iJuniorTV.

[LoyceV]

For fun, I checked other key variants for 1iJuniorTV and out of 15 variants, only about 5 matched the prefixes.

Again:

Can you explain this? As far as I know, vanity split key matches should be correct and not have a "1 in 6" chance.

When I did my split key vanity giveaway, every match I found produced the desired address.

[Cricktor]

~~~

Which software do you use to find a work item solution (I might've missed it in case you already wrote about it)?

Did you modify the software in any way?


I can't remember having issues to submit the first hit of a work item solution many many years ago when vanitypool was rather new and there were plenty of not terribly hard work items available (GPUs back then weren't as powerful as today's and I only had a barely middle-class one).

It would be against all odds that I was purely lucky that my first found solution to a work item was just one that worked out fine, if there were detected "solutions" that won't spit out the correct public address prefix after combining the keys.

Why would there be something like "1 in 6" chance? That's nonsense in my opinion as I don't see any mathematical proof for such ambiguity. This sounds much like some strange bug in the software.

And I also can't remember any discussion about such an issue in this thread earlier (not that I've followed the many pages of it to the word).

[WhyFhy]

For fun, I checked other key variants for 1iJuniorTV and out of 15 variants, only about 5 matched the prefixes.

Again:

Can you explain this? As far as I know, vanity split key matches should be correct and not have a "1 in 6" chance.

When I did my split key vanity giveaway, every match I found produced the desired address.

if you used VS you got lucky. The other one discards child keys automatically, JeanLuc should have implemented this into vs.

I broke it down pretty well in the post above. https://bitcointalk.org/index.php?topic=84569.msg64820642

[ddf2020]

~~~

Which software do you use to find a work item solution (I might've missed it in case you already wrote about it)?

Did you modify the software in any way?


I can't remember having issues to submit the first hit of a work item solution many many years ago when vanitypool was rather new and there were plenty of not terribly hard work items available (GPUs back then weren't as powerful as today's and I only had a barely middle-class one).

It would be against all odds that I was purely lucky that my first found solution to a work item was just one that worked out fine, if there were detected "solutions" that won't spit out the correct public address prefix after combining the keys.

Why would there be something like "1 in 6" chance? That's nonsense in my opinion as I don't see any mathematical proof for such ambiguity. This sounds much like some strange bug in the software.

And I also can't remember any discussion about such an issue in this thread earlier (not that I've followed the many pages of it to the word).

I use VanitySearch for searching, with a special search scheme, for speeding up. This problem arose only when searching for a prefix with a public key, when searching for a prefix without it, 100% match of results. I also thought that when using a public key, the match should also be 100%, but it turns out that no, for what reason I can not answer exactly, maybe because elliptic curves are used for calculations or this is a bug in the program or memory without error correction, it is not clear yet why this happens, too little data and it takes months to accumulate it. Maybe there were no problems before because the prefixes were not complicated and it was possible to quickly find another option.

[WhyFhy]

~~~

Which software do you use to find a work item solution (I might've missed it in case you already wrote about it)?

Did you modify the software in any way?


I can't remember having issues to submit the first hit of a work item solution many many years ago when vanitypool was rather new and there were plenty of not terribly hard work items available (GPUs back then weren't as powerful as today's and I only had a barely middle-class one).

It would be against all odds that I was purely lucky that my first found solution to a work item was just one that worked out fine, if there were detected "solutions" that won't spit out the correct public address prefix after combining the keys.

Why would there be something like "1 in 6" chance? That's nonsense in my opinion as I don't see any mathematical proof for such ambiguity. This sounds much like some strange bug in the software.

And I also can't remember any discussion about such an issue in this thread earlier (not that I've followed the many pages of it to the word).

I use VanitySearch for searching, with a special search scheme, for speeding up. This problem arose only when searching for a prefix with a public key, when searching for a prefix without it, 100% match of results. I also thought that when using a public key, the match should also be 100%, but it turns out that no, for what reason I can not answer exactly, maybe because elliptic curves are used for calculations or this is a bug in the program or memory without error correction, it is not clear yet why this happens, too little data and it takes months to accumulate it. Maybe there were no problems before because the prefixes were not complicated and it was possible to quickly find another option.

  I've gone through every inch of the SC of VS , his functions are incomplete when using a pub key with prefix.  Theres no discarding splitkeys in vs. if a function checks out .if it just so happens to find a child wallet it tells you that's fine. The other program doesn't. But it's nowhere near as complex as VS

The only question I really have is why does this happen with LEGACY wallets!  Why do legacy wallets have child keys?

There are more people who would probably know what's going on here  if they see the post. I didn't get into VS until 2019 or so.

[ddf2020]

~~~

Which software do you use to find a work item solution (I might've missed it in case you already wrote about it)?

Did you modify the software in any way?


I can't remember having issues to submit the first hit of a work item solution many many years ago when vanitypool was rather new and there were plenty of not terribly hard work items available (GPUs back then weren't as powerful as today's and I only had a barely middle-class one).

It would be against all odds that I was purely lucky that my first found solution to a work item was just one that worked out fine, if there were detected "solutions" that won't spit out the correct public address prefix after combining the keys.

Why would there be something like "1 in 6" chance? That's nonsense in my opinion as I don't see any mathematical proof for such ambiguity. This sounds much like some strange bug in the software.

And I also can't remember any discussion about such an issue in this thread earlier (not that I've followed the many pages of it to the word).

I use VanitySearch for searching, with a special search scheme, for speeding up. This problem arose only when searching for a prefix with a public key, when searching for a prefix without it, 100% match of results. I also thought that when using a public key, the match should also be 100%, but it turns out that no, for what reason I can not answer exactly, maybe because elliptic curves are used for calculations or this is a bug in the program or memory without error correction, it is not clear yet why this happens, too little data and it takes months to accumulate it. Maybe there were no problems before because the prefixes were not complicated and it was possible to quickly find another option.

 I've gone through every inch of the SC of VS , his functions are incomplete when using a pub key with prefix.  Theres no discarding splitkeys in vs. if a function checks out .if it just so happens to find a child wallet it tells you that's fine. The other program doesn't. But it's nowhere near as complex as VS

The only question I really have is why does this happen with LEGACY wallets!  Why do legacy wallets have child keys?

There are more people who would probably know what's going on here  if they see the post. I didn't get into VS until 2019 or so.

You were right vanitygen gives 100% match when searching for a prefix with a public key, but it works almost 10 times slower because it does not support Nvidia cards!

[kTimesG]

Did I get this right? There are two main ways to have a split-key Vanity service:

a) Client publishes k_c*G = P; solver finds some P + (k_s*G) and submits k_s
 hence real key = k_c + k_s
b) Client publishes k_c*G = P; solver finds some k_s*P and submits k_s
 hence real key = k_c * k_s

Does one of these approaches have some advantage over the other or does it depend on personal taste? Both options seem to be able to be implemented with identical efficiency (simply swap G with P for case b).

And is VanityPool still reliable? I computed that the cost to find 1SatoshiNak is around $24k so it's a losing bet today, but this may change if BTC prize goes up.

[stwenhao]

Does one of these approaches have some advantage over the other or does it depend on personal taste?

If you add public keys, instead of multiplying some public key with some known number, then you can potentially implement it on top of Taproot. Because if you have two Schnorr signatures, then they can be combined, and then, public keys are added, to make an aggregated signature. So, I would recommend picking addition, because it is implemented in that way in other places.

And is VanityPool still reliable?

I don't know, but I think it should be technically possible to do something like that in a completely trustless way, just by locking some coins on some addresses, and then, the miner could simply take the coins, while also publishing the solution in the input Script. Now, it is possible to check the size of some DER signature, and require grinding small s-value, to grab some coins. Maybe by picking the right public key, it would be possible to translate the solution from "pay to Proof of Work address" into "pay to vanity address" instead.

Currently, when we have Pay to Proof of Work scripts, we have:

Code:

s=(z+rd)/k
r=(G/2).x=const
k=1/2
s=(z+const*d)*2

By picking a different private key, than just "d=1", we have "s=(z+template)*2" instead. Which means, that we can pick any difference between s-value and z-value, and the only way to claim such output, would require grinding it (you can see some examples with d=1, by checking addresses like tb1qzsjnew5qcn75e4cqdsc6r9v8fjy5ensancqmv2l2n82p0q5f5tls758l9d).

And also, there is Taproot, where we have aggregated signatures: https://en.bitcoin.it/wiki/Schnorr

Code:

s=k+ed
e=hash(R||P||m)
s1=k1+e*d1
s2=k2+e*d2
s1*G=R1+e*Q1
s2*G=R2+e*Q2
s1+s2=(k1+k2)+e*(d1+d2)
(s1+s2)*G=(R1+R2)+e*(Q1+Q2)

Which means, that not only signatures can be combined, but they can be also splitted. And I wonder, if there is a way, to prepare some Taproot and TapScript, and claim it by grinding a given public key, to match a given pattern. Because also, each TapScript is committed to the Taproot address, by using just some SHA-256 hash of a given TapScript, and it is mixed with the internal public key.

Edit: I have more untested ideas. I think it is possible to pay to vanity address, which would form a valid DER signature.

Code:

 Input: <realSignature> <recoveredKey> <pubkey>
Output: OP_DUP OP_HASH160 OP_SWAP OP_TOALTSTACK OP_SWAP OP_CHECKSIGVERIFY OP_FROMALTSTACK OP_CHECKSIG

Execution:

<realSignature> <recoveredKey> <pubkey>
<realSignature> <recoveredKey> <pubkey> <pubkey>
<realSignature> <recoveredKey> <pubkey> <vanitySignature>
<realSignature> <recoveredKey> <vanitySignature> <pubkey>
<realSignature> <recoveredKey> <vanitySignature>
<realSignature> <vanitySignature> <recoveredKey>
<realSignature>
<realSignature> <pubkey>
OP_TRUE

Then, a given public key will be first hashed with OP_HASH160, and then used as a DER signature, with some randomly recovered public key, matching for a given transaction. And then, the same public key can be checked again, but this time with user-given signature, which would prove private key ownership.

Which means, that this Script above is spendable by anyone, who can give a public key, which would form a valid, 20-byte DER signature, when hashed. Because of DER format, it would be something like that:

Code:

30110207         //DER encoding
3b78ce5630207d   //r-value
0206             //DER encoding
52b332d15b18     //s-value
83               //sighash

Different sighashes can be tried, as well as different sizes for r-value and s-value. But overall, I estimate something around six or seven bytes should be grinded, which means checking something around 2^56 hashes for both SHA-256 and RIPEMD-160.

Edit: When it comes to available signatures, we have something like that:

Code:

+------------------------------------------+-------------------------+-------------------------+
| HASH160 of a given public key            | Vanity address (legacy) | Vanity address (Segwit) |
+------------------------------------------+-------------------------+-------------------------+
| 30110201..020c........................01 | 15P9ow9...              | bc1qxqgsyq...           |
| 30110201..020c........................02 | 15P9ow9...              | bc1qxqgsyq...           |
| 30110201..020c........................03 | 15P9ow9...              | bc1qxqgsyq...           |
| 30110201..020c........................81 | 15P9ow9...              | bc1qxqgsyq...           |
| 30110201..020c........................82 | 15P9ow9...              | bc1qxqgsyq...           |
| 30110201..020c........................83 | 15P9ow9...              | bc1qxqgsyq...           |
+------------------------------------------+-------------------------+-------------------------+
| 30110202....020b......................01 | 15P9ow5...              | bc1qxqgsyq...           |
| 30110202....020b......................02 | 15P9ow5...              | bc1qxqgsyq...           |
| 30110202....020b......................03 | 15P9ow5...              | bc1qxqgsyq...           |
| 30110202....020b......................81 | 15P9ow5...              | bc1qxqgsyq...           |
| 30110202....020b......................82 | 15P9ow5...              | bc1qxqgsyq...           |
| 30110202....020b......................83 | 15P9ow5...              | bc1qxqgsyq...           |
+------------------------------------------+-------------------------+-------------------------+
| 30110203......020a....................01 | 15P9owC...              | bc1qxqgsyq...           |
| 30110203......020a....................02 | 15P9owC...              | bc1qxqgsyq...           |
| 30110203......020a....................03 | 15P9owC...              | bc1qxqgsyq...           |
| 30110203......020a....................81 | 15P9owC...              | bc1qxqgsyq...           |
| 30110203......020a....................82 | 15P9owC...              | bc1qxqgsyq...           |
| 30110203......020a....................83 | 15P9owC...              | bc1qxqgsyq...           |
+------------------------------------------+-------------------------+-------------------------+
| 30110204........0209..................01 | 15P9owG...              | bc1qxqgsyp...           |
| 30110204........0209..................02 | 15P9owG...              | bc1qxqgsyp...           |
| 30110204........0209..................03 | 15P9owG...              | bc1qxqgsyp...           |
| 30110204........0209..................81 | 15P9owG...              | bc1qxqgsyp...           |
| 30110204........0209..................82 | 15P9owG...              | bc1qxqgsyp...           |
| 30110204........0209..................83 | 15P9owG...              | bc1qxqgsyp...           |
+------------------------------------------+-------------------------+-------------------------+
| 30110205..........0208................01 | 15P9owL...              | bc1qxqgsyp...           |
| 30110205..........0208................02 | 15P9owL...              | bc1qxqgsyp...           |
| 30110205..........0208................03 | 15P9owL...              | bc1qxqgsyp...           |
| 30110205..........0208................81 | 15P9owL...              | bc1qxqgsyp...           |
| 30110205..........0208................82 | 15P9owL...              | bc1qxqgsyp...           |
| 30110205..........0208................83 | 15P9owL...              | bc1qxqgsyp...           |
+------------------------------------------+-------------------------+-------------------------+
| 30110206............0207..............01 | 15P9owP...              | bc1qxqgsyp...           |
| 30110206............0207..............02 | 15P9owP...              | bc1qxqgsyp...           |
| 30110206............0207..............03 | 15P9owP...              | bc1qxqgsyp...           |
| 30110206............0207..............81 | 15P9owP...              | bc1qxqgsyp...           |
| 30110206............0207..............82 | 15P9owP...              | bc1qxqgsyp...           |
| 30110206............0207..............83 | 15P9owP...              | bc1qxqgsyp...           |
+------------------------------------------+-------------------------+-------------------------+
| 30110207..............0206............01 | 15P9owT...              | bc1qxqgsyp...           |
| 30110207..............0206............02 | 15P9owT...              | bc1qxqgsyp...           |
| 30110207..............0206............03 | 15P9owT...              | bc1qxqgsyp...           |
| 30110207..............0206............81 | 15P9owT...              | bc1qxqgsyp...           |
| 30110207..............0206............82 | 15P9owT...              | bc1qxqgsyp...           |
| 30110207..............0206............83 | 15P9owT...              | bc1qxqgsyp...           |
+------------------------------------------+-------------------------+-------------------------+
| 30110208................0205..........01 | 15P9owW...              | bc1qxqgsyz...           |
| 30110208................0205..........02 | 15P9owW...              | bc1qxqgsyz...           |
| 30110208................0205..........03 | 15P9owW...              | bc1qxqgsyz...           |
| 30110208................0205..........81 | 15P9owW...              | bc1qxqgsyz...           |
| 30110208................0205..........82 | 15P9owW...              | bc1qxqgsyz...           |
| 30110208................0205..........83 | 15P9owW...              | bc1qxqgsyz...           |
+------------------------------------------+-------------------------+-------------------------+
| 30110209..................0204........01 | 15P9owa...              | bc1qxqgsyz...           |
| 30110209..................0204........02 | 15P9owa...              | bc1qxqgsyz...           |
| 30110209..................0204........03 | 15P9owa...              | bc1qxqgsyz...           |
| 30110209..................0204........81 | 15P9owa...              | bc1qxqgsyz...           |
| 30110209..................0204........82 | 15P9owa...              | bc1qxqgsyz...           |
| 30110209..................0204........83 | 15P9owa...              | bc1qxqgsyz...           |
+------------------------------------------+-------------------------+-------------------------+
| 3011020a....................0203......01 | 15P9owd...              | bc1qxqgsyz...           |
| 3011020a....................0203......02 | 15P9owd...              | bc1qxqgsyz...           |
| 3011020a....................0203......03 | 15P9owd...              | bc1qxqgsyz...           |
| 3011020a....................0203......81 | 15P9owd...              | bc1qxqgsyz...           |
| 3011020a....................0203......82 | 15P9owd...              | bc1qxqgsyz...           |
| 3011020a....................0203......83 | 15P9owd...              | bc1qxqgsyz...           |
+------------------------------------------+-------------------------+-------------------------+
| 3011020b......................0202....01 | 15P9owh...              | bc1qxqgsyz...           |
| 3011020b......................0202....02 | 15P9owh...              | bc1qxqgsyz...           |
| 3011020b......................0202....03 | 15P9owh...              | bc1qxqgsyz...           |
| 3011020b......................0202....81 | 15P9owh...              | bc1qxqgsyz...           |
| 3011020b......................0202....82 | 15P9owh...              | bc1qxqgsyz...           |
| 3011020b......................0202....83 | 15P9owh...              | bc1qxqgsyz...           |
+------------------------------------------+-------------------------+-------------------------+
| 3011020c........................0201..01 | 15P9owk...              | bc1qxqgsyr...           |
| 3011020c........................0201..02 | 15P9owk...              | bc1qxqgsyr...           |
| 3011020c........................0201..03 | 15P9owk...              | bc1qxqgsyr...           |
| 3011020c........................0201..81 | 15P9owk...              | bc1qxqgsyr...           |
| 3011020c........................0201..82 | 15P9owk...              | bc1qxqgsyr...           |
| 3011020c........................0201..83 | 15P9owk...              | bc1qxqgsyr...           |
+------------------------------------------+-------------------------+-------------------------+

Which means, that such vanity addresses would always start with 15P9ow... (legacy) and bc1qxqgsy... (Segwit). I wonder, if some Script tricks can be used to get different patterns out of that.

[ertil]

I think I came up with something, which could allow generating vanity addresses in fully trustless way. First, we put our target public key as a signature, by setting R-value to the x-value of our secp256k1 point, and then for s-value, we use exactly the same thing. Then, through public key recovery, anyone can grind any public key, with any pattern, just by tweaking transaction hash, according to predefined sighashes.

When the given pattern is reached, we can use OP_CODESEPARATOR, to force using a different z-value than previously, and just spend the coins wherever we want, by constraining the transaction, potentially with different sighashes, than used previously.

Code:

 Input: <signature2> <pubkey>
Output: <signature> OP_SWAP OP_DUP OP_TOALTSTACK OP_CHECKSIGVERIFY OP_CODESEPARATOR OP_FROMALTSTACK OP_CHECKSIG

Execution:

<signature2> <pubkey>
<signature2> <pubkey> <signature>
<signature2> <signature> <pubkey>
<signature2> <signature> <pubkey> <pubkey>
<signature2> <signature> <pubkey>
<signature2>
<signature2> <pubkey>
OP_TRUE

What do you think about it? I can see some potential in this approach, but I have to test it, because I didn't that yet.