coinspin

> Since I'm already loading all possible words in the JS,

How many words is that?

6 years at 600k is a stretch. 400k is very doable though. I think you're looking at closer to 10+ years to hit the higher end of 600k (at big tech)

This sounds like one of those tools that was built internally that could spin out to be it's own project/startup. It's such a clever and easy way to solve their problems.

Yeah. I would log it. It doesn't auto sweep the wallet or anything.

There's a blog post on the same site that talks about using https://github.com/in3rsha/bitcoin-utxo-dump. I'm running a pruned node, I use that lib to dump the address and balance to a csv and then I pull out the top 100 or so.

Something is off with the output of parsing the utxos. I'll have to dig deeper into it later!

That's such a big number. I still fail at grasping really large numbers like that.

I just haven't updated it lately. Thanks for the reminder. I'll run the scripts now.

That's a neat idea! It's currently all client side but I could add a simple endpoint to store/read the counts.

OP Here. I submitted this 6 months ago as a Show HN and thought I would try my luck again after adding a blog post last night about doing the same thing on AWS.

Things have started stabilizing. React is a clear winner in the framework wars (but there are some promising new upstarts). I'd build a small app in React and go from there. Next.js is extremely easy to get started with out of the box.

Webpack is still a nightmare but things like snowpack et al try to remove some of that complexity.

It's unclear where the original data source is. It was my understanding that (clean) data was very pricey and hard to come by. Is this changing? Following the links, all I could find was references to Rapid API and not the source

It's doing a batch request to blockchain.info to check the balance. So I generate 100 addresses, fetch them, then show them 1 by one in the UI. Then fetch 100 more in the background. This is mostly to prevent rate-limiting.

I wondered this too. I'm sure you could narrow the universe to some degree. Most wallets use the BIP 39 word list as a seed to derive the private key. So 12 words (in order) out of 2048 possible words is probably less than the total number of possible bitcoin addresses. This is just one example.

OP here. I made this mostly out of fun/curiosity. The premise of cryptocurrencies is that it's practically impossible to guess the private key for a given address. This just keeps guessing on the off chance that you hit a 1 in a 1461501637330902918203684832716283019655932542976 chance.

People are naturally bad at large numbers (myself included).

It would take longer than that to try all combinations. The app logs a message but doesn't attempt to sweep the wallet or anything.

If you're building a REST API you might as well follow the semantics of GET/PUT/POST/PATCH/DELETE. Overloading post requests may seem convenient and tidy but there is a spec for a reason.

If you prefer more of a one query or request to rule them all then GraphQL may align better to your preferences.