Bitcoin Forum

I'm a bit confused since you don't split what you write using dot or commas. But basically you need bitcoin address generator which use GPU (CUDA/OpenCL) with input defined by you? Anyway, if you don't plan to generate billion of address, it's more practical to use Bitcoin library which support generate address with custom private key you defined.

if you make such program for free if not we can discuss this if you want you can contact me on telegram its same as my username since i am not that active.

To generate a private key take SHA256(string + n), where n is an ASCII-coded number that starts from 1 and increments as additional keys are needed.

I want the above functionality with a simple twist since gpu will generate addresses in millions compressed and uncompressed form similar to vanity address generators save only the addresses

You should be a little bit more clear if you want someone's services. I've understood half of what you wrote.

I think you have trouble understanding a clear example Type 1 deterministic wallet
A type 1 deterministic wallet is a simple method of generating addresses from a known starting string, as such it does not allow advanced features such as a Master Public Key. To generate a private key take SHA256(string + n), where n is an ASCII-coded number that starts from 1 and increments as additional keys are needed.

And string a random hexadecimally represented number? If you just want to generate brute forcefully addresses starting from a random number, just increase it by 1 for each loop.

Why would i want to use hexadecimal number as string since any number plus alphabet can be represented as string for example i will use my name

Would you mind telling us what's your purpose? It seems like you want to... generate vanity addresses?

Yes i want to generate vanity address using this Type 1 deterministic wallet
A type 1 deterministic wallet is a simple method of generating addresses from a known starting string, as such it does not allow advanced features such as a Master Public Key. To generate a private key take SHA256(string + n), where n is an ASCII-coded number that starts from 1 and increments as additional keys are needed.

Why would i want to use hexadecimal number as string since any number plus alphabet can be represented as string for example i will use my name

[quote author=BlackHatCoiner link=topic=5347515.msg57383096#msg57383096 date=1625401428]...[/quote]
Write here...

To generate a private key take SHA256(string + n), where n is an ASCII-coded number that starts from 1 and increments as additional keys are needed.

Why would i want to use hexadecimal number as string since any number plus alphabet can be represented as string for example i will use my name

Yes i want to generate vanity address using this Type 1 deterministic wallet
A type 1 deterministic wallet is a simple method of generating addresses from a known starting string, as such it does not allow advanced features such as a Master Public Key. To generate a private key take SHA256(string + n), where n is an ASCII-coded number that starts from 1 and increments as additional keys are needed.

If you quote a post, write beneath it, not inside the quote tags.

I know how a simple deterministic wallet implemetation would be like and I understood your example. I'm just recommending you to be clearer in the future, especially when you want to buy services from an unknown person in the internet.

Again, it depends on what you want to achieve. If these addresses will be used in the future for funding, then knowing your name can increase my odds to find their private keys. On the other hand, if you used a very large random number, I couldn't stand a chance.

Great. Don't use the brain wallet way. Instead I'd suggest you to do the following; generate a random number between 1 and 2²⁵⁶ - 2³² - 977 (secp256k1 range). Instead of having an n variable, just increase that number by 1 each time. Simple as that.

this is understandable I will use 132 bits of entropy as a string plus the increments for extra security and uniqueness plus it would be deterministic for me if whenever I forget I can recover it however the big number is just hard to recover if lost so the point stands that I will use string, not my name as I gave that just as an example I will use a string with 132 bits of entropy as that is strong and used by electrum as well plus by using GPU I don't want to save all those billions of addresses so i will only save the addresses that match the pattern but with my method of string+n increments and for this increments are necessary if you use same string billions of times it will generate the same address but if you add the needed numbers/increments it will fulfil the task of pattern and uniqueness since using 132 of entropy for single address is not very economical I would say.

this is understandable I will use 132 bits of entropy as a string plus the increments for extra security and uniqueness

it will fulfil the task of pattern and uniqueness since using 132 of entropy for single address is not very economical I would say.

Breath!

---

---

Wait, do you mean that you'll hash that entropy or that you'll use it directly for the addresses? There's no need to hash anything neither to take any extra security measures; if you randomly generate 256 bits, they're fine to perform ECDSA, SHA256, RIPEMD-160, SHA256 and then the final base58 encoding.

You may have misunderstood the procedure. Every address is an encoded RIPEMD-160 hash along with a version byte in the front and with a checksum in the back. [Useful link (https://en.bitcoin.it/wiki/Technical_background_of_version_1_Bitcoin_addresses)]

There are no 132 bits of entropy. You may have confused it with the BIP39 in which you use 128 bits of entropy along with 4 bits of hash for the seed generation. Then, after some PBKDF2 and HMAC-SHA256/512 rounds, you end up with the derived addresses. But, that's just a proposal for generating deterministic keys. If you want to go with the standard way, you'll need 256 bits.

the string does not have to bip39 to be secure is just needs to be long enough

i think you are misunderstanding or trying to twist my words or maybe trying to change the topic

you think i dont know about those procedures you talk about

you are clearly not very claver regarding this

I never said that.

You caught me!

Buddy, we were just having a discussion and I was trying to help. Good luck on your way to find a programmer that will do you a work you can't even describe..

im not claver...  :'(

Type 1 deterministic wallet
A type 1 deterministic wallet is a simple method of generating addresses from a known starting string, as such it does not allow advanced features such as a Master Public Key. To generate a private key take SHA256(string + n), where n is an ASCII-coded number that starts from 1 and increments as additional keys are needed.

This type of wallet can be created by Casascius Bitcoin Address Utility.

I want the above functionality with a simple twist since gpu will generate addresses in millions compressed and uncompressed form similar to vanity address generators save only the addresses
that have the matching pattern along with the private key that generated that address and do that indefinately gpu either cuda or opencl i will appreciate if you make such program for free if not we can discuss this if you want you can contact me on telegram its same as my username since i am not that active.

can't even describe lol tell me what is so hard to understand? my first post on this topic gives the clear concept of what I want you don't know English now?

this is understandable I will use 132 bits of entropy as a string plus the increments for extra security and uniqueness plus it would be deterministic for me if whenever I forget I can recover it however the big number is just hard to recover if lost so the point stands that I will use string, not my name as I gave that just as an example I will use a string with 132 bits of entropy as that is strong and used by electrum as well plus by using GPU I don't want to save all those billions of addresses so i will only save the addresses that match the pattern but with my method of string+n increments and for this increments are necessary if you use same string billions of times it will generate the same address but if you add the needed numbers/increments it will fulfil the task of pattern and uniqueness since using 132 of entropy for single address is not very economical I would say.

As a native English speaker, I find it difficult to understand what you have written because your grammar and punctuation (which are important components of the language) are poor.

If I understand you correctly, you would like someone to create a vanity address generator that returns a number, N, such that a private key derived from SHA256(M|N) has an address that matches a pattern, where M and the pattern are both chosen by the user.

That is certainly doable. Is there a limit on the value of the number?

Keep in mind that as others have mentioned, any brain wallet is insecure. That includes your derivation of a brain wallet. While "now is the time for all good men to come to the aid of their country 67854897" is more secure than "now is the time for all good men to come to the aid of their country", it may not be not secure enough to be used as a private key.

A random string with 132-bit entropy is much better than what I initially thought you were doing (just make sure you add the string at the end of n and not the other way around (https://en.wikipedia.org/wiki/Length_extension_attack)), but in my opinion, if you really want to generate private keys this way then I suggest ditching hashing functions altogether and use Scrypt (https://en.wikipedia.org/wiki/Scrypt) for your algorithm instead, which can be tweaked to make brute-forcing infeasible.

I think the problem is that what you want (a vanity bitcoin address) and the method you want to use (SHA256(string+n)) don't make sense together and that is what people are trying to tell you. Mainly it doesn't make any sense to start from a starting seed to generate the vanity address, if you want such an address then simply start from a random key.

I think you are talking nonsense how do you explain key generation? Do you think the random key is generated out of nowhere? Random key generation also needs input without input there is no output also to say that random key generation is the only secure way to generate is a real security risk since all random numbers cant be trusted havent you heard of the weak random seed generated by android clients?

You said something about forgetting and being able to recover it from that seed which again doesn't make sense if you are generating a vanity address because depending on how many fixed starting characters the address has the process can take a very long time and recovering it this way is not practical. Not to mention that using a starting string that you can remember suggests weakness in the randomness.

It makes perfect sense see the above reply.

Here is a suggestion, why not generate a random entropy then start your vanity address search from there until you find the key that corresponds to your desired address. Then take the private key to that address (256-bit) and encode that using an algorithm like BIP39 to a set of words that you can easily store or remember (although it is not recommended to only rely on your memory for backup).

I think you are talking nonsense how do you explain key generation? Do you think the random key is generated out of nowhere? Random key generation also needs input without input there is no output also to say that random key generation is the only secure way to generate is a real security risk since all random numbers cant be trusted havent you heard of the weak random seed generated by android clients?

Just because some poorly written applications in the past by incompetent developers used a weak RNG doesn't mean random number generators are weak in general! You just have to know how to use them correctly. Giving them up altogether and relying on a weak method sounds like replacing one mistake with another.

SHA256 is secure you are declaring that sha256 is insecure? besides that length-extension attack wouldn't work on anything which is considered secure such as 132 bits of entropy...

If by secure you mean "cannot be reverse-engineered" then that is correct. However, it is suspectable to brute-force. On a 1080 Ti card a hacker can try SHA256 combos at around 4400 megahash/s. For comparison, the same card can only try scrypt at around 0.9 megahash/s and PBKDF2 with HMAC-SHA256 iterations at 1.6 megahash/s.

I guess the fact that you are using 132 bits of entropy in your string nullifies the cracking speed increase, but you must make sure your entropy source is not dirty or else you could actually be using less entropy unknowingly. A good example of this is using /dev/urandom.

correct /dev/urandom would be a good source of entropy no known weaknesses plus there are good amount of tools available out there that allows you to choose how many bits of entropy you want before hand many even use 256 bit of entropy which is what I consider way over the top.

No you misunderstood what I was saying, do not use /dev/urandom for cryptographic random number generation because when it runs out of hardware entropy it will use a PNRG to give you the rest of the bits. I recommend using /dev/random instead which will stall when hardware entropy runs out until more is made available.