whaack

I've embarked on a mission to create a bitcoin block explorer. My motivation is the network is sorely missing a public block explorer that has a public vpatch'd source. Afaik the only public block explorer made by someone in the web of trust was ben_vulpes's mimisbrunnr, which has been dead for years.

Current heathen block explorers¹ have the wrong ethos. They do not publish their source prominently, they have no guarantee that they won't break their api, they support all sorts of various scam coins, they support non-standard bitcoin transactions, they likely run off prb, etc. etc. They are operated by amorphous identities, rather than by an individual in the web of trust.

So a better block explorer is a low-hanging fruit. But it's worth questioning whether making a block explorer that serves data over http is worth creating in the first place. Bitcoin operators should treat their locally verified blockchain as the source of truth instead of the output of some site.² The thing is... trb operators cannot view what's inside their blockchain because the design for its storage is atrocious.³ If trb stored its data in a sane manner to begin with, a public block explorer wouldn't be necessary. Trb operators would just query their local blockchain.

Since we are stuck with the trb abomination, what's needed is a second program that monitors the growing tumor blockchain and packages the information into a second, sane database. This program, which provides a reasonable way to actually understand wtf's inside all those blk****.dat files, is likely desired by ~all trb node operators.⁴ So while I do plan to provide an http service, the goal is first and foremost to make a block explorer that one can run locally on top of trb.

Much of the hard work for this job has already been completed by jfw. He released gbw-node, a piece of software for the online portion of his wallet that provides a way to track the balances of provided addresses. His program scans the trb blockchain, inserts relevant information in a sanely structured sqlite3 database, and then provides a way to query that db.

A few tweaks and additions are needed to make his gbw-node provide a way to access all the information that a block explorer is generally expected to provide. For example, the db needs a new table for blocks. Also, instead of tracking specific addresses, the gbw-node needs to track all addresses.⁵

The next task on my plate is figuring out the full list of necessary changes and creating an estimation of how much storage space trb + the mirror'd db will require. Meanwhile I need find a home to host my block explorer and begin syncing a trb node in that home asap.

1. Here are some:

   https://www.blockchain.com/explorer
   https://blockchair.com/
   https://tokenview.com/en
   https://explorer.bitcoin.com/btc
   https://insight.bitpay.com/
   https://tradeblock.com/bitcoin/explorer
   https://bitcoinchain.com/block_explorer
   https://btc.com/
   https://live.blockcypher.com/
   https://blockchain.coinmarketcap.com/ [↩]

2. Perhaps a proper http block explorer signs its responses to queries when requested. [↩]
3. And trb is something that the world is stuck with. Fork the source and eventually you'll fork the chain. And who has the authority to say that their new chain, one that is not the accepted longest chain in og trb, is to be called "Bitcoin" proper? Bitcoin defends itself economically, you know. [↩]
4. So long as that node operator is using trb to manage their own bitcoins, rather than just to place a node in the world to increase the robustness of the network / number of copies of the blockchain. [↩]
5. Arguably this is a feature a wallet user with extra storage space / cpu cycles to spare would want anyways. [↩]

This entry was posted on Thursday, July 9th, 2020 at 4:21 p.m. and is filed under Bitcoin, tmsr. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.