whaack: diana_coman: No I don't think that works, because I find the block explorer much more important than anything else I'm doing.
whaack: diana_coman: I read through jfw's series on gbw node yesterday. Some articles I digested more than others. It seems that gbw node is just a few settings and a small interface away from being a block explorer.
diana_coman: whaack - so ask jfw where/what doesn't quite make sense, no?
whaack: diana_coman: yes of course. Mostly I mean that some of the details, such as all the various functions needed to craft bits into the correct encoding, were skimmed.
diana_coman: so install it, give it a spin, write up the whole thing, the works; I wouldn't be all that surprised if there's in there most of what you need for a block explorer, perhaps only even more than absolutely needed for that as such, but not like there's any loss in getting to know that code properly.
whaack: jfw: Does the following sound like a feasible/reasonable way to go about making a block explorer. (1) Get a beefy machine (specifics to be calculated, but 2 TB of SSD, 16GB of Ram, 3.0Ghz processor are some ballpark estimates) (2) Install trb and gbw node. (3) Configure gbw to watch *all* addresses, and give a public interface for the sql db
whaack: I'm setting my goal for today to build trb and gbw node locally. I'm going to read http://thebitcoin.foundation/trb-howto.html and dorion's guide here http://dorion-mode.com/2020/07/gbw-node-gales-bitcoin-wallet-node-verified-acquisition-build-install-and-run-in-21ish-short-simple-steps/ first.
diana_coman: sounds good.
whaack: while setting, up trb locally I hit an error upon running `make ONLINE=1` . I was curious to see if running the command again required redownloading/compiling everything, so I ran it again, and I hit a new error. Then I was intruiged by hitting a 2nd error, so I ran it again, and got a 3rd error. I've decided to stop before running it a 4th time. Here are the errors I've received:
whaack: I'm giving http://fixpoint.welshcomputing.com/2020/build-system-overhaul-for-bitcoind/ a read now, seems like I may have hit some problem from LD_LIBRARY_PATH getting set when setting up eulora
whaack: Looks like the problem may have been that my path variable was wrong, setting my gcc to some gcc 8.x used by GNAT
whaack: Now, using jfw's new build system overhaul patch, I ran make ONLINE=1 again, and I sat and watched the spew of logs. I saw a bunch of python errors somewhere in the middle, so I have a hunch that I have a problem for having python 2.6.6 installed instead of python 2.7.
whaack: ^ This was the problem, I had a successful build by switching my python to 2.7
whaack: jfw: I have bitcoind running, the debug logs say I'm at height 100k or something. I wanted to see if I could watch the address 1Q2TWHE3GMdB6BZKafqwxXtWAWgFt5Jvm3 that allegedly received 10 btc at [block 170] [https://www.blockchain.com/btc/tx/f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16] I did the following steps which I believed would result in being able to see a balance for
whaack: that address http://paste.deedbot.org/?id=byob but instead I saw a balance of 0 after scanning above block 170.
feedbot: http://ztkfg.com/2020/07/spanish-practice-log-10-july-5th-2020/ << whaack -- Spanish Practice Log 10, July 5th 2020
feedbot: http://ztkfg.com/2020/07/spanish-practice-log-12-july-7th-2020/ << whaack -- Spanish Study Log 12, July 7th 2020
feedbot: http://ztkfg.com/2020/07/spanish-practice-log-11-july-6th-2020/ << whaack -- Spanish Practice Log 11, July 6th 2020
jfw: I'm alive, just in a bit of a hole owing to various accumulated sins against time. Light's on the horizon though.
jfw: whaack: much of the code in gbw-node would be directly useful for a block explorer, indeed. I would definitely suggest some schema tweaks though.
jfw: for example adding a table to track blocks and factoring block_hash and block_height out of tx into that, referenced by integer primary key
jfw: (32 byte hash -> 8 byte rowid, multiplied by every transaction in bitcoin would save quite some space I expect.)
jfw: and removing the "input" table (which I believe I mentioned in the schema article)
jfw: whaack: as is it can't be told to track "all" addresses; there's a list and that list won't fit all possible seen & unseen addresses. If you mean changing the code to remove the 'watched address' checks and index all seen addresses, then yes that's the way to go.
jfw: Possibly even the way gbw-node itself ought to be - though the full index will have a hefty size cost.
jfw: incidentally if TRB had used SQL this tradeoff would literally be a one-liner CREATE INDEX.
jfw: 2T/16G wouuld be plenty beefy enough, indeed 1T/4G probably fine
jfw: the extra ram can always be thrown at database cache though so won't hurt.
jfw: re make errors, haven't looked specifically but without my patch, repeating 'make' can indeed produce different errors because it gives 'make' no way to see that an openssl/bdb/boost build failed and it just proceeds.
jfw: python errors in trb build? that's a bit surprising, my guess would be Boost as it has some python binding thing, "shouldn't" be necessary for trb tho
jfw: however 2.7 is a hard requirement for gbw-node as I haven't found a non-glacial alternative to memoryviews given the volume of deserialization it has to do.
jfw: whaack: re block 170, I bet your problem is that the site you got the address from is revising history to imply that "1-addresses" were used back then. They weren't; the standard script was pay-to-pubkey, no hash. I dunno how it was presented in the early UI but at least would have been a longer string.
jfw: if you look at the 'disassembly' of the scriptPubKey on such a site, and compare to a more sample, you'll see the difference.
jfw: *more recent sample
jfw: "more recent" as in past the first couple 10k, iirc.
jfw: whaack: I un-lazied and clicked your link, this is indeed the situation.
jfw: gbw-node indexes only actual "1-addresses", i.e. scripts matching the standard p2pkh form. For a block explorer, a middle ground between that and writing special cases for all sorts of weird species of script would be indexing the script itself as a blob.
jfw: out_script_address is the filtering/extraction function there.
whaack: jfw: Addressing a few things: Yes I meant changing the code to remove watched addresses and index all seen addresses.
whaack: jfw: Indeed, I believe the problem was with building Boost.
jfw: whaack: cool. Off to sleep now but I should be back tomorrow.
whaack: jfw: gn