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.
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.
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).
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.
How many words is that?