Sequential repeatable address generator (as opposed to random)

[ISAWHIM]

I need to create addresses, given a creation range, that are essentially sequential.

I realize that the addresses themselves will not be sequential... It is the keys. Where they are valid.

The purpose is so that I can re-create a series of addresses, without having to worry about losing the wallet due to corruption, theft, or any other act of nature. I do understand the implications that if I can recreate them, that anyone-else can, if they know the sequence.

I have used the "bitcoinjs-min" v0.2.0 for a test-run, but I can not get it to create anything sequential. (Even when I give it a specific value, it just dies and doesn't create anything at all.)

I don't need or want any fancy salt or super-finder or other interfering code, since that will be added later. I just need it pure KISS.

Code:

rawPrivKey = MakePrivateKey(X); // Raw key "X" being the specific value to use, or find the first valid key from there.
myPrivKey = MakePrivateKey(rawPrivKey); // WIF Uncompressed
myPubKeyU = GetPublicKeyU(rawPrivKey); // Address Uncompressed
myPubKeyC = GetPublicKeyC(rawPrivKey); // Address Compressed

Simplified:
ValidValues = new GetValidSet(X); // Returns the first valid value and the actual set data, from X-???
MySet = ValidValues.Set(); // "WIF-Private-Key, Address-Uncompressed, Address-Compressed"
LastValue = ValidValues.Last(); // This would be X+whatever, if it was 2000 values before a valid one was found, X+2000

(For wallet compatibility I need both compressed and uncompressed output for addresses. This is because not all wallets check both unless you explicitly add the other one also, on import.)

That will be used in a loop, so I can generate the sequence of addresses. X = 1-100, 594-694, 23953223193478-23953223193578 etc...

The code I use now is this...

Code:

rawPrivKey = new Bitcoin.ECKey(); // Generates a random private key *** Need this specific range
myPrivKey = rawPrivKey.toWif(); // Converts raw private key to WIF format
myPubKeyU = rawPrivKey.getPub().getAddress(); // Gets uncompressed public address from raw private key
myPubKeyC = rawPrivKey.getPub('compressed').getAddress(); // Gets compressed public address from raw private key

*** The use for Bitcoin.ECKey();, shows that I should be able to use a value in the brackets, but there is no functioning documented code I could find, indicating what it allows for a valid value. Tried raw numbers, HexToBytes, BytesToHex, 'strings'... anything I place in the brackets just cause it to crash and the code never executes beyond that point. The actual code does not help. There is so much bloat in there to handle every browser and every possible font/iso-format/unicode/variable/object/error... yet it just dies. xD So much for effective bloat.

Anyone think they can help?

Major bonus points if you can do this in VB6, or make this a simple 32-bit DLL file. xD

[spin]

Looks like a simplified version of HD walllets.  Why not just use an HD wallet?
https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki

Also HD wallets is a standard that is/will be incorporated in many wallet clients.

With an HD wallet you need minimal info to recreate all the addresses in the wallet.  Armory and some of the other wallets have similar tech.

[ISAWHIM]

Wow, that looks like a pile of 100% easy money to steal if anyone uses that. xD

No, but thank-you for the post. That is not what I am looking for... but, it is similar to what I want to do. Just not with all that huge security risk.

I believe the javascrypt I am using, actually uses that HD crap, which is why it is overly complex, and why I am struggling trying to follow all the cryptic bloat it has. The code is the same that the online wallet generator uses, and that states it uses HD crap. Just not sure if it uses it for all the code, or just for the special bulk-wallet generator things.

I like reading the part about, "Don't share your public or private keys, as there is a risk..." Um, wait... sharing the public key is a risk, then you are screwed, because you public key is in the block-chain, your public key is the address that you give to people, so they can add funds to the address.

This, I realize is just some poor wording, but the risk is real. Those are talking about the internal "generation keys", which the system uses, not the "wallet key pairs", which it did not elaborate on. However... the intention was to use multiple wallets across multiple systems, that can be recreated as one giant wallet, by those keys and extensions.

Let me elaborate my thinking on what I just said above... You have one giant wallet with millions of potential addresses. However, gaining access to one key, or the other, opens you to risk of another person being able to recreate all the addresses of all the wallets. (These, you have to share, to the systems, so they can create the addresses they need from the wallets. Thus, you have to share what you should not share, across multiple systems, with multiple potential leaking exposure.)

What I wanted to do was record something like this...

"Freddy goes to mars"

Then that creates all my addresses and keys, from that data. That text actually tells my program to create 100,000 addresses, starting from logical sequential position 8349994, but skipping 45, then 28, then 840, then 98532. Using the pass-phrase "seagull" then "soda", then "glue", then "snickers"... All just from the text, "Freddy goes to mars". To anyone without the program, those words are useless. To me, with the program locked away, I can recreate all the data I need.

Thus, no out of box program will suffice my needs there. However, I do need it to NOT be randomly generated, which all these stupid things do, and do horribly with pseudo-random predictability. That is the part I need stripped away, so I can insert my sequential data. However, they use some crazy ass javascrypt to do this, and seem to only allow some specific size and range of 58-bit data. But they do not tell you what it is, or how long it has to be, or what format. (I found one key that was valid to use, it was a 58-bit conversion of some long number, but 0 would not work, or any other number that was equally as long, so I am at a loss as to what they were looking for.)

That is not a good sign if it has a limited number of input for anything. That translates into a lot less variations then they portray. That is like saying, well there are a trillion times a trillion possibilities if you use A-Z ^45 ^200... But then say, but the letters have to all form words, and the words have to all be only latin, and the latin words have to all start with S and the s words have to all be under 5 letters. Well, then that leaves you with like 10,000 possible solutions, not a trillion by a trillion. That is essentially what they are doing there.

Just like sha256(sha256()), it does not create more variation, the output is still the same finite results, but now there is more potential collisions, not less. Exponentially more collisions than one can even imagine. (More, since there are invalid possibilities between the outputs that never get created, thus, not part of the output of finite results that they calculate.) But I digress, that is the reason Satoshi/everyone abandoned it, and warned everyone heavily that they have to split all stored coins into multiple addresses, for security, so they don't all get stolen when someone finds one of these many-more collisions, randomly. Thus, causing the network to grow exponentially full of dust in the future, to unmanageable size. (This too, a topic of one of my whitepapers, is what I am working on having fixed.)

[ISAWHIM]

Also HD wallets is a standard that is/will be incorporated in many wallet clients.

With an HD wallet you need minimal info to recreate all the addresses in the wallet.  Armory and some of the other wallets have similar tech.

That statement scares me! xD...

"HD wallets"... "incorporated in many wallet clients"... "minimal info(easy) to recreate(hack)"...

xD What scares me is that there are generators that make valid-invalid addresses... They generate a valid address, thus you can spend to it, but it can't be spent, because the public and private keys do not output a valid hash. Money in, then you are stuck there forever... Unless you find/hack a key-collision that creates a valid output to spend it. I feel bad for those who got stuck depositing into those addresses, and they don't even know it yet, because they never tried to spend the balance. (Guess it pays not to skip that "test spend" phase in the generation sequence.)

[spin]

Well, the HD wallets are really just a fancy way to say with private key x and public key y how do I get to the next set.  You just propose using a password string as they way to do this (previously you were proposing x+1).  It then depends on how strong your password is (read gmaxwell's comments on brainwallets on this forum), and of course the implementation.

Otherwise it is very difficult to respond to this in a reasonably amount of time because you are touching on too many different topics.
- the hd wallets (or similar) are in use in many places by many people.  Read up on Armory for example.
- then you rant about various technical aspect of some java code you are looking at?
- you rant about some "generators"?

Revealing public keys reduces by removing the difficulty of finding the public key for a given address hash.  You still need to figure out the private key.  This is why it is recommended not to reuse addresses because once you make a transaction the public key is available in the bockchain as you state.