Developer: Write code to generate all possible private keys

[cookiebro]

I'm looking for a developer to write a script to generate all possible private keys and write them to an SQL database. Payment available

[enzogla]

There are already websites that do that.

https://keys.lol

Good luck though, the chances of finding an active one are ridiculously low.

[cookiebro]

I know. It's not for anything nefarious. I need the data locally.

[PawGo]

What do you mean by "all possible private keys"?
All possible addresses from a given private key (so for one key to generate addresses bc1... 3... 1..., compressed/uncompressed) or you want to iterate each possible private key, one by one and generate address for that - then technically it is easy and doable, the problem I see is that you will need eons to have work finished, you will need a lot of energy and enormous amount of disk space.
But if you want, I may do it for you...

[pooya87]

I'm looking for a developer to write a script to generate all possible private keys and write them to an SQL database. Payment available

Code:

using AlienTechnologies.TimeTravel;
using Encoders;

public void Main()
{
  var storage = TimeTravelToFuture();
  var sql = new SqlDatabase(storage);
  for (BigInteger i = 1; i < 115792089237316195423570985008687907852837564279074904382605163141518161494337; i++)
  {
    sql.Write(Base58Encoder.GetWif(i));
  }
}

private Storage TimeTravelToFuture()
{
  TimeMachine.Engine.TurnOn();
  TimeMachine.Time.Set("2120-01-01-12-45-00");
  TimeMachine.Travel();
  return TimeMachine.RetreiveStorageDisk();
}

You're welcome.

[BlackHatCoiner]

I'm looking for a developer to write a script to generate all possible private keys and write them to an SQL database. Payment available

In Bitcoin? What to do the bitcoins if you know my private key? 

[...]

This will be insanely slow. Consider using Foxpup.TimeTravel; instead.

[o_e_l_e_o]

2²⁵⁶ private keys * 32 bytes each = 3.7*10⁵⁴ yottabytes.

The combined storage capacity of every device on the planet is not yet at 1 yottabyte. Good luck!

I'm also wondering where you are keeping the several million Dyson spheres you'll need to generate enough electricity to perform this?

Yes yes, I know it's not really 2²⁵⁶. I'm just making a point.

-snip-

I initially glossed over this because I assumed you had written the actual code knowing full well it would just fill his available storage space. Glad I went back and read it properly though.

Edit: @o_e_l_e_o beat me almost by a minute.

As BHC has said above, Foxpup.TimeTravel is the superior function.

[mamuu]

I'm looking for a developer to write a script to generate all possible private keys and write them to an SQL database. Payment available

Code:

using AlienTechnologies.TimeTravel;
using Encoders;

public void Main()
{
  var storage = TimeTravelToFuture();
  var sql = new SqlDatabase(storage);
  for (BigInteger i = 1; i < 115792089237316195423570985008687907852837564279074904382605163141518161494337; i++)
  {
    sql.Write(Base58Encoder.GetWif(i));
  }
}

private Storage TimeTravelToFuture()
{
  TimeMachine.Engine.TurnOn();
  TimeMachine.Time.Set("2120-01-01-12-45-00");
  TimeMachine.Travel();
  return TimeMachine.RetreiveStorageDisk();
}

You're welcome.

I'll be damned! to this answer 

[mynonce]

I'm looking for a developer to write a script to generate all possible private keys and write them to an SQL database. Payment available

You're too late. Someone else did it already.

https://allprivatekeys.com

'All private keys list
Whole range of Bitcoin and Bitcoin Cash Private Keys, compressed/ uncompressed, SegWit and HD wallet. Whole wallets including YOURS.
Don't believe?

Just open to see.'

[larry_vw_1955]

You're welcome.

you shouldn't be doing that pooya. that's a job for someone they could put food on the table but not now!

[NotATether]

It should be assumed that the first 2^40 private keys have already been broken and are inside some local database (330*64GB or about 21TB large uncompressed) so they must not be used for whatever reason.
Same for last 2^40 private keys, first 2^40 even PKs, first couple prime number PKs and so on.

[larry_vw_1955]

It should be assumed that the first 2^40 private keys have already been broken and are inside some local database (330*64GB or about 21TB large uncompressed) so they must not be used for whatever reason.
Same for last 2^40 private keys, first 2^40 even PKs, first couple prime number PKs and so on.

but how would someone know if their private key was in that range? especially with hd wallets and such they aren't checking things like that. hopefully their funds dont get stolen. oh also the middle 2^40 private keys whatever those are would probably be sitting inside some kid in their basement on their hard drive.

[PrimeNumber7]

It should be assumed that the first 2^40 private keys have already been broken and are inside some local database (330*64GB or about 21TB large uncompressed) so they must not be used for whatever reason.
Same for last 2^40 private keys, first 2^40 even PKs, first couple prime number PKs and so on.

but how would someone know if their private key was in that range? especially with hd wallets and such they aren't checking things like that. hopefully their funds dont get stolen. oh also the middle 2^40 private keys whatever those are would probably be sitting inside some kid in their basement on their hard drive.

The chances of a private key being in any 2^40 range is approximately 1 in 10^67, or approximately zero.

Wallets could potentially black list those private keys, but if that was a mainstream thing, crackers could simply monitor the next 2^40 set of keys (and this process would continue).

I seriously doubt that the key 2^35 is being actively monitored, and I doubt that someone that naturally generates this key is going to have their coin stolen.

Sure, if you say to send coin to an address associated with a key in that range in the next month, there would be a guarantee that monitoring those addresses would present an opportunity to see coin stolen. But monitoring all those addresses for years, or even decades would be much more expensive, with no assurance that the attacker would be able to receive any coin as a result of monitoring all those addresses.

[NotATether]

It should be assumed that the first 2^40 private keys have already been broken and are inside some local database (330*64GB or about 21TB large uncompressed) so they must not be used for whatever reason.
Same for last 2^40 private keys, first 2^40 even PKs, first couple prime number PKs and so on.

but how would someone know if their private key was in that range? especially with hd wallets and such they aren't checking things like that. hopefully their funds dont get stolen. oh also the middle 2^40 private keys whatever those are would probably be sitting inside some kid in their basement on their hard drive.

I meant if the private key was generated directly, or you're using a wallet that allows you to see the private key of your address.

[dextronomous]

was thinking 
how much is it gonna be in data TB , if range 64 would be safed uncompressed,
raw txt file, and only this range is it doable?

[pooya87]

was thinking 
how much is it gonna be in data TB , if range 64 would be safed uncompressed,
raw txt file, and only this range is it doable?

It would be silly to store things in string form, for example in this case it would be 51-52 bytes versus 32. So to compute the total size needed you just multiply the number of items by the raw-byte size which is 32.

Code:

32 * 2^64 = 2^69 = 5.9E+20 bytes = 590,000,000 terabytes

[larry_vw_1955]

Code:

32 * 2^64 = 2^69 = 5.9E+20 bytes = 590,000,000 terabytes

when will that be feasible? probably not in the next 10 years right?

[pooya87]

when will that be feasible? probably not in the next 10 years right?

I don't really follow hardware development to be able to give an informed response but considering that over past 10 years we've gone from about 60 TB to the maximum 100 TB SSDs which is roughly a 2x rise, I don't see how a revolution could occur in the next 10 years that could increase this maximum capacity 5.9 million times!

[PrimeNumber7]

Code:

32 * 2^64 = 2^69 = 5.9E+20 bytes = 590,000,000 terabytes

when will that be feasible? probably not in the next 10 years right?

Storing all private keys is pretty pointless, IMO. Simply storing a list of private keys without the ability to a) quickly access the corresponding public key and address, and b) quickly check if the associated address in "a" has received any transactions, will not provide much value to anyone.

As an example, I currently have all possible private keys stored in my head. This includes all of your private keys (although I have no way of filtering out all private keys that do not belong to you). However, my brain cannot quickly calculate an associated address from a private key, so the process of obtaining an address from any private key in my head is very slow. The process for me to look up if an address has received a transaction is even slower.

The above concept can be applied to a computer that is able to store all private keys on a hard drive. Even if a computer could quickly check many private keys to see if a private key's associated address has received a transaction, in order to check n private keys, the computer would need to perform n calculations. The number of private keys is too large for any computer to ever perform any calculation on all possible private keys, given theoretical computational limits.

was thinking 
how much is it gonna be in data TB , if range 64 would be safed uncompressed,
raw txt file, and only this range is it doable?

It would be silly to store things in string form, for example in this case it would be 51-52 bytes versus 32. So to compute the total size needed you just multiply the number of items by the raw-byte size which is 32.

Code:

32 * 2^64 = 2^69 = 5.9E+20 bytes = 590,000,000 terabytes

If I am not mistaken, you are describing the amount of space required to store all private keys as 32 bit integers. Most private keys are numbers that are greater than 32 bits.

[BlackHatCoiner]

The question is why would one save 2⁶⁴ private keys in their hard drive? I mean what's the point? Do you also want to store the addresses after each key, just to make searching easier for the first 2⁶⁴ uncompressed addresses? There's no reason to store only the keys.

If I am not mistaken, you are describing the amount of space required to store all private keys as 32 bit integers. Most private keys are numbers that are greater than 32 bits.

He's talking about the [1, 2⁶⁴] range. Storing all the private keys would cost much much more space.

[pooya87]

If I am not mistaken, you are describing the amount of space required to store all private keys as 32 bit integers. Most private keys are numbers that are greater than 32 bits.

Bitcoin private keys are 256 bits or 32 bytes.
The total number of keys in "range 64" (which I assume dextronomous meant between 1 and 2⁶⁴ like the puzzle people love these days!) is 2⁶⁴ (-1 which we ignore) and each of them are 32 bytes so we multiply total with 32 to get the total size in bytes.

[o_e_l_e_o]

when will that be feasible? probably not in the next 10 years right?

That's 390 zettabytes. Various estimates (linked below) put global storage at around 175-200 zettabytes by 2025. So globally we will be storing 390 zettabytes by around 2030, I would imagine. How long will it take to turn the storage for 8 billion people in to a medium which can be bought, owned, and operated by a single person? I would say well over 100 years.

https://cybersecurityventures.com/the-world-will-store-200-zettabytes-of-data-by-2025/
https://www.prnewswire.com/news-releases/the-world-will-store-200-zettabytes-of-data-by-2025-301072627.html
https://www.networkworld.com/article/3325397/idc-expect-175-zettabytes-of-data-worldwide-by-2025.html

in order to check n private keys, the computer would need to perform n calculations.

It's far more than a single calculation per private key to arrive at an address which can be checked for balance. And if you don't want to perform those calculations every single time you want to check for balance and would rather just have a list of addresses to look up, then you are going to need to multiply your storage capacity several times if you want to cover every address type.

[j2002ba2]

Storing 2⁶⁴ (or 2⁶⁹) bits is possible with todays technology. To get 2⁶⁹ bits in a cubic meter, we need 100x100x100 nm cell size. IIRC a SRAM cell fits 100nm. Making a new Si layer is used today - CVD grows layers 10-20 nm per minute.

There are some concerns though. The power consumption might be too big, even for SRAM. And the biggest concern is bit rot. Such amount of memory will start degrading instantly (cosmic rays, etc.), so one needs to use lots of power for repairing it. Orders of magnitude more than just storing.

Since the stored information is easy to regenerate, it could be better to checksum, and regenerate it on access in case of error.

Some search gave me failure rate of around 10^-13 = 2^-43. So even storing it all would need workarounds in order to be error-free.

It is quite pointless to do all this. Moreover, it might be more cost efficient to do a brute force search every time a new address appears.

[DaveF]

Storing 2⁶⁴ (or 2⁶⁹) bits is possible with todays technology. To get 2⁶⁹ bits in a cubic meter, we need 100x100x100 nm cell size. IIRC a SRAM cell fits 100nm. Making a new Si layer is used today - CVD grows layers 10-20 nm per minute.

There are some concerns though. The power consumption might be too big, even for SRAM. And the biggest concern is bit rot. Such amount of memory will start degrading instantly (cosmic rays, etc.), so one needs to use lots of power for repairing it. Orders of magnitude more than just storing.

Since the stored information is easy to regenerate, it could be better to checksum, and regenerate it on access in case of error.

Some search gave me failure rate of around 10^-13 = 2^-43. So even storing it all would need workarounds in order to be error-free.

It is quite pointless to do all this. Moreover, it might be more cost efficient to do a brute force search every time a new address appears.

You also left out cooling and controller chips, even very efficient low power memory will get hot at that density. And although you did mention power, its also the power regulation circuity needed.
Interesting thought experiment but beyond that, not really a real word option. Unless you have Bezos / Musk money to throw around.

-Dave

[NeuroticFish]

Will OP have enough energy for generating all those private keys?
I remember a picture telling otherwise:

[larry_vw_1955]

when will that be feasible? probably not in the next 10 years right?

That's 390 zettabytes. Various estimates (linked below) put global storage at around 175-200 zettabytes by 2025. So globally we will be storing 390 zettabytes by around 2030, I would imagine. How long will it take to turn the storage for 8 billion people in to a medium which can be bought, owned, and operated by a single person? I would say well over 100 years.

 dna could store that in about 3 kilograms apparently. dna data storage has its issues though. so it won't make the cut to users desktops.

[o_e_l_e_o]

Don't forget high cost to perform read/write operation.

Under the DNA fountain scheme, Erlich and Zielinski (2017) spent USD 7000 to encode 2.14 MB data. Hence, DNA fountain costs about ~ USD 3500 per MB of data writing and another USD 1000 to read it (Service 2017).

Nice! So when bitcoin hits $65 trillion per coin, then if we sell all 21 million bitcoin we can encode every private key in to DNA. Unfortunately, we'll have no money left over to read or perform any operations on the data.

When moon?

[larry_vw_1955]

Don't forget high cost to perform read/write operation.

Under the DNA fountain scheme, Erlich and Zielinski (2017) spent USD 7000 to encode 2.14 MB data. Hence, DNA fountain costs about ~ USD 3500 per MB of data writing and another USD 1000 to read it (Service 2017).

I'm sure when hard drives were first developed they had a high research cost to write to them also. but obviously it goes without saying price has to come down to reach consumers desktop. it always does.

[PrimeNumber7]

when will that be feasible? probably not in the next 10 years right?

That's 390 zettabytes. Various estimates (linked below) put global storage at around 175-200 zettabytes by 2025. So globally we will be storing 390 zettabytes by around 2030, I would imagine. How long will it take to turn the storage for 8 billion people in to a medium which can be bought, owned, and operated by a single person? I would say well over 100 years.

 dna could store that in about 3 kilograms apparently. dna data storage has its issues though. so it won't make the cut to users desktops.

I'm sure when hard drives were first developed they had a high research cost to write to them also. but obviously it goes without saying price has to come down to reach consumers desktop. it always does.

The price to read/write to "DNA" will come down, but the cost to process that much data will exceed the available amount of resources required to process that much data. See the above picture posted by NeuroticFish above.

in order to check n private keys, the computer would need to perform n calculations.

It's far more than a single calculation per private key to arrive at an address which can be checked for balance. And if you don't want to perform those calculations every single time you want to check for balance and would rather just have a list of addresses to look up, then you are going to need to multiply your storage capacity several times if you want to cover every address type.

You are right. I was thinking in terms of Big O Notation for the time complexity of calculating an address, based on a private key. So if you want to calculate j addresses from their private keys, you will perform p * j calculations, and if you want to calculate (j +1) addresses from their private keys, you will need to perform p * (j + 1) calculations. Or, to put it another way, for every additional address you want to calculate from a private key, you will need to perform a consistent additional number of calculations, with the consistent being a positive integer. 

[larry_vw_1955]

The price to read/write to "DNA" will come down, but the cost to process that much data will exceed the available amount of resources required to process that much data. See the above picture posted by NeuroticFish above.

that picture is referring to 2^256, not 2^64. big difference. but if you're referring to 2^64 and the 3kg of dna then i guess it depends on your definition of "process". i guess you already decided that 3kg of dna can't be processed efficiently. ok.

[n0nce]

I'm looking for a developer to write a script to generate all possible private keys and write them to an SQL database. Payment available

You're too late. Someone else did it already.

https://allprivatekeys.com

'All private keys list
Whole range of Bitcoin and Bitcoin Cash Private Keys, compressed/ uncompressed, SegWit and HD wallet. Whole wallets including YOURS.
Don't believe?

Just open to see.'

This is not an offline database though (which OP was looking for) and instead generates the keys on the fly. As was shown already in this thread, the whole world's storage wouldn't be able to store all the private keys.
Just calculating a public key from a private key is a pretty trivial thing.

Nearly every 256-bit number is a valid ECDSA private key. Specifically, any 256-bit number from 0x1 to 0xFFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFE BAAE DCE6 AF48 A03B BFD2 5E8C D036 4140 is a valid private key.

[larry_vw_1955]

While i agree the price most likely will decline over time, but i disagree with part it'll reach/popular among desktop user. For example, Tape Drive have high capacity, high speed (compared with HDD) and very long lifespan (usually up to 20-30 years). But almost no desktop user use it, although it's still popular option for archival and enterprise user. Besides, storage isn't the only concern in this case.

Tape drives don't really have a capacity. the tape has the capacity but lto-9 is 18TB. hard drives of that size sell for maybe $300 if you get a sale. the lto-9 tape maybe sells for half that at best. not much of an advantage in the size and price category to justify spending $3000 on a tape drive. plus the hard drive is way faster. anything goes wrong with your tape drive and it's another $3000 to spend.

[larry_vw_1955]

While i know tape drive capacity isn't much different from HDD, is tape drive really that expensive? Looking at website such as Newegg and tapeandmedia, some tape drive price isn't that different from HDD.

As I think I mentioned, you can get an 18TB hard drive for about twice the price you can get the same size tape. Check the prices yourself.

Not true, for comparison WD Gold 8TB speed is 255MB/s while IBM TS1160 and IBM LTO 9 speed are 400MB/s (without compression). Check their product specification,

I still say the hard drive is way faster. Faster in access time. Tape is 50 seconds average. Hard drive is milliseconds.

anything goes wrong with your tape drive and it's another $3000 to spend.

Also applies to HDD.

I'd rather have 30 things that costed $100 than one thing that costed $3000. Big point of failure there but I guess to each their own. Plus hard drives are commodity item. Tape drives aren't. You cant just pick one up at best buy.