[XMR]

Hi XMR,

That is incorrect and not how split-key works.

With split key we never have access to your private key.

The process you described is called SSL, and we use that also by default.

Best,
Nick

If you instantly generated an encrypted key, you wouldn't know if it matched the user's desired pattern because it would produce an entirely different address. This means you would not know which one of the millions upon millions of keys you generate to send to the user. Split key is more secure than regular generation, but only if one can guarantee the other party is using an unmodified version of the software. The service itself certainly cannot guarantee this if it isn't the case that nobody at all can.

In order to know which key matches the user's pattern, you must have an unencrypted version of the key to check its derived address. This is the point of failure. You have the address' unencrypted private key. You then encrypt it with the public key supplied by the user and then send it to them. It prevents an MITM attack, but nothing stops you from saving the unencrypted key before sending it off.

What I described is not even related to SSL/TLS. TLS has nothing to do with cryptocurrency address generation and is not used to encrypt data that the service isn't supposed to see. TLS is meant to encrypt data so it can't be modified or read by third parties. The service is not a third party. The goal of split-key generation is to ensure that only the end user can see the private key. This is not (yet) possible as there are no known methods to do this. The service can see everything before it's encrypted, including private keys for bitcoin addresses (despite the claim of secure split-key) and the web pages before they're transmitted.

[Orca]

If you instantly generated an encrypted key, you wouldn't know if it matched the user's desired pattern because it would produce an entirely different address. This means you would not know which one of the millions upon millions of keys you generate to send to the user. Split key is more secure than regular generation, but only if one can guarantee the other party is using an unmodified version of the software. The service itself certainly cannot guarantee this if it isn't the case that nobody at all can.

In order to know which key matches the user's pattern, you must have an unencrypted version of the key to check its derived address. This is the point of failure. You have the address' unencrypted private key. You then encrypt it with the public key supplied by the user and then send it to them. It prevents an MITM attack, but nothing stops you from saving the unencrypted key before sending it off.

What I described is not even related to SSL/TLS. TLS has nothing to do with cryptocurrency address generation and is not used to encrypt data that the service isn't supposed to see. TLS is meant to encrypt data so it can't be modified or read by third parties. The service is not a third party. The goal of split-key generation is to ensure that only the end user can see the private key. This is not (yet) possible as there are no known methods to do this. The service can see everything before it's encrypted, including private keys for bitcoin addresses (despite the claim of secure split-key) and the web pages before they're transmitted.

Hi XMR,

It still appears that you fundamentally do not understand split-key.

And yes what you described is SSL/TLS - the concept of encrypting communication between website and visitor. Split-Key is not this.

Split-Key guarantees, by math, that the only person who will have access to the key is the user.

Best,
Nick

[XMR]

Hi XMR,

It still appears that you fundamentally do not understand split-key.

And yes what you described is SSL/TLS - the concept of encrypting communication between website and visitor. Split-Key is not this.

Split-Key guarantees, by math, that the only person who will have access to the key is the user.

Best,
Nick

You make baseless claims and keep repeating the same thing over and over with the gist being "split key ensures only the end user will have access." You cannot guarantee this. There is no (known) mathematical system that does this and there's a good chance that such a guarantee is impossible.

And yes what you described is SSL/TLS - the concept of encrypting communication between website and visitor. Split-Key is not this.

That isn't what I said at all.

The goal of split-key generation is to ensure that only the end user can see the private key.

Split key is basic public key cryptography. You need an unencrypted copy to encrypt with the end user's public key. You need an unencrypted copy to check if the address matches the end user's desired pattern. Without an unencrypted copy, you can't check this because it would produce an entirely different address.

Public key cryptography requires plaintext data and a public key for the service to encrypt with. If you already have an encrypted key then split key isn't necessary.

Split-Key guarantees, by math, that the only person who will have access to the key is the user.

Then you should have no problem posting mathematical proof of split key being infalliable. Here, infalliable is defined as only the end user having access to the key. I'll wait.

[Orca]

You make baseless claims and keep repeating the same thing over and over with the gist being "split key ensures only the end user will have access." You cannot guarantee this. There is no (known) mathematical system that does this and there's a good chance that such a guarantee is impossible.


That isn't what I said at all.


Split key is basic public key cryptography. You need an unencrypted copy to encrypt with the end user's public key. You need an unencrypted copy to check if the address matches the end user's desired pattern. Without an unencrypted copy, you can't check this because it would produce an entirely different address.

Public key cryptography requires plaintext data and a public key for the service to encrypt with. If you already have an encrypted key then split key isn't necessary.


Then you should have no problem posting mathematical proof of split key being infalliable. Here, infalliable is defined as only the end user having access to the key. I'll wait.

Hi XMR,

Again you seem to be stuck grasping the concept of split-key. Split-key is not encrypted messaging.

I have attached a few resources that may be able to help you get an understanding as you don't seem to want to listen to the facts when I provide them.

https://bitcoin.stackexchange.com/questi...g-ones-coi

There are in depth mathematical breakdowns that might clear things up, but I doubt it as you are having a conceptual problem rather than mathematical one.

Best,
Nick

[RUMRUN]

I highly discourage using this.

[Orca]

I highly discourage using this.

Hi Exec_SH,

Why is that? If there is anything you are concerned about, we can address that to better suit your needs.

Best,
Nick

[RUMRUN]

High risk with having these tools online, in a browser.
It shouldn't be there.
There's a vanity CLI for this purpose.

Nothing against your site, just a bad idea in general.

[335i]

I’m curious how you’re monetizing this? What’s the incentive for you in providing this service? I don’t see any ads or anything like that.

Other than that it’s pretty cool, looks like OP knows his shit despite everybody dogging him for this.

[Orca]

High risk with having these tools online, in a browser.
It shouldn't be there.
There's a vanity CLI for this purpose.

Nothing against your site, just a bad idea in general.

I appreciate your concern, but did you see our split-key feature?

---

I’m curious how you’re monetizing this? What’s the incentive for you in providing this service? I don’t see any ads or anything like that.

Other than that it’s pretty cool, looks like OP knows his Clay Davis despite everybody dogging him for this.

Thank you for the feedback! I appreciate the objectivity.

We charge for addresses that require heavy computational power, in addition to charging for our API access.

[SIM-2015410]

I do not endorse this website nor trust it at all. When I typed something into the public key box to test the split key method, it ignored it and just generated a normal keypair.

You make baseless claims and keep repeating the same thing over and over with the gist being "split key ensures only the end user will have access." You cannot guarantee this. There is no (known) mathematical system that does this and there's a good chance that such a guarantee is impossible.

Split key is basic public key cryptography. You need an unencrypted copy to encrypt with the end user's public key. You need an unencrypted copy to check if the address matches the end user's desired pattern. Without an unencrypted copy, you can't check this because it would produce an entirely different address.

Public key cryptography requires plaintext data and a public key for the service to encrypt with. If you already have an encrypted key then split key isn't necessary.


Then you should have no problem posting mathematical proof of split key being infalliable. Here, infalliable is defined as only the end user having access to the key. I'll wait.

You are incorrect. The OP is actually correct in saying that split key generation is possible. Keypairs on elliptic curves are linear so (private+private)*G = (public+public). The site only needs to know the public key to test the address. I do not trust the site or its implementation of this idea but I am simply saying it is possible and you misunderstand how it works.

[XMR]

I do not endorse this website nor trust it at all. When I typed something into the public key box to test the split key method, it ignored it and just generated a normal keypair.


You are incorrect. The OP is actually correct in saying that split key generation is possible. Keypairs on elliptic curves are linear so (private+private)*G = (public+public). The site only needs to know the public key to test the address. I do not trust the site or its implementation of this idea but I am simply saying it is possible and you misunderstand how it works.

Okay, so I've been proven wrong and split key is possible. However, it seems as though it would only work if the site properly implements it without some type of foul play. But how do we know the site has properly implemented it (according to your post, they haven't) or don't have some type of trick? As far as I know, that can't be guaranteed. You've shown that they can test the address for a match without its private key, but can we guarantee that they're not saving the real private key before they encrypt it?

[Kill Joy]

Okay, so I've been proven wrong and split key is possible. However, it seems as though it would only work if the site properly implements it without some type of foul play. But how do we know the site has properly implemented it (according to your post, they haven't) or don't have some type of trick? As far as I know, that can't be guaranteed. You've shown that they can test the address for a match without its private key, but can we guarantee that they're not saving the real private key before they encrypt it?

They never have access to the private key if this is implemented correctly, which on this website is done incorrectly.

1. You generate a random 256-integer that is less than the SECP256k1 generator (G) and keep this. No one else but you should see this integer as this is essentially a private key.

G = a point on the elliptical curve. SECP256k1 using the ECDSA algorithm has a finite field with (X,Y) coordinates which indicate corresponding public and private keys.

G compressed looks like:

02 79BE667E F9DCBBAC 55A06295 CE870B07 029BFCDB 2DCE28D9 59F2815B 16F81798


which has one coordinate, X, on the curve and you are supposed to solve for Y.

G uncompressed looks:

04 79BE667E F9DCBBAC 55A06295 CE870B07 029BFCDB 2DCE28D9 59F2815B 16F81798 483ADA77 26A3C465 5DA4FBFC 0E1108A8 FD17B448 A6855419 9C47D08F FB10D4B8

2. Now obviously every private key has a corresponding public key. You find this public key along the SECP256k1 curve and give it to the person generating your vanity address.

3. The person generating the vanity address now will also generate a random 256-integer less than (G) and add it to your "public key" and then hash it to see if it corresponds to the vanity address you are seeking. They keep reproducing random 256-integers until they reach the desired address.

4. Once they find the correct random integer, which is currently a public key, they will find the corresponding private key and give it to you.

5. You add the corresponding private key they gave to you to your private key and then reduce it with
G.

6. Congrats. You now have the private key to your desired vanity address.

We achieve 6 because of the rule which Mesh gave,

Code

(private+private)*G = (public+public)

Does this make sense?

Edit: There is also a way to create any public address you would like. I created an example just for shits and giggles.

1KiLLJoyisSatoshiNakamotoxxxX5vsZ

[Orca]

Hi Everyone,

Thank you for clarifying things for some of the newer users, it is much appreciated!

Also regarding our split-key implementation, please try it again and let me know if it is working fine for you now.

Best,
Nick

[XMR]

They never have access to the private key if this is implemented correctly, which on this website is done incorrectly.

1. You generate a random 256-integer that is less than the SECP256k1 generator (G) and keep this. No one else but you should see this integer as this is essentially a private key.

G = a point on the elliptical curve. SECP256k1 using the ECDSA algorithm has a finite field with (X,Y) coordinates which indicate corresponding public and private keys.

G compressed looks like:

02 79BE667E F9DCBBAC 55A06295 CE870B07 029BFCDB 2DCE28D9 59F2815B 16F81798


which has one coordinate, X, on the curve and you are supposed to solve for Y.

G uncompressed looks:

04 79BE667E F9DCBBAC 55A06295 CE870B07 029BFCDB 2DCE28D9 59F2815B 16F81798 483ADA77 26A3C465 5DA4FBFC 0E1108A8 FD17B448 A6855419 9C47D08F FB10D4B8

2. Now obviously every private key has a corresponding public key. You find this public key along the SECP256k1 curve and give it to the person generating your vanity address.

3. The person generating the vanity address now will also generate a random 256-integer less than (G) and add it to your "public key" and then hash it to see if it corresponds to the vanity address you are seeking. They keep reproducing random 256-integers until they reach the desired address.

4. Once they find the correct random integer, which is currently a public key, they will find the corresponding private key and give it to you.

5. You add the corresponding private key they gave to you to your private key and then reduce it with
G.

6. Congrats. You now have the private key to your desired vanity address.

We achieve 6 because of the rule which Mesh gave,

Code

(private+private)*G = (public+public)

Does this make sense?

Edit: There is also a way to create any public address you would like. I created an example just for shits and giggles.

1KiLLJoyisSatoshiNakamotoxxxX5vsZ

It makes perfect sense. Many thanks for the detailed explanation.

So now as I understand it, if it's implemented properly, the address is guaranteed private, but otherwise, the address won't match because the end user's public key is crucial to the process? It seems like it has a sort of built in protection against trickery (eg. do it right or you get a mismatched address).

Again, thanks for the in-depth explanation. It appears as though I was indeed wrong. The more you know lol 🤝

[Orca]

Yes, that's correct the privacy and security of the address is guaranteed!

Glad you can enjoy the service now =)