| 14:22 |
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. |
| 14:24 |
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. |
| 14:36 |
diana_coman |
whaack - so ask jfw where/what doesn't quite make sense, no? |
| 14:39 |
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. |
| 14:41 |
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. |
| 14:41 |
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 |
| |
~ 19 minutes ~ |
| 15:00 |
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. |
| 15:01 |
diana_coman |
sounds good. |
| |
~ 1 hours 30 minutes ~ |
| 16:32 |
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: |
| 16:32 |
whaack |
http://paste.deedbot.org/?id=uZyS |
| 16:36 |
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 |
| 16:50 |
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 |
| |
~ 1 hours 42 minutes ~ |
| 18:32 |
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. |
| |
~ 17 minutes ~ |
| 18:49 |
whaack |
^ This was the problem, I had a successful build by switching my python to 2.7 |
| |
~ 53 minutes ~ |
| 19:43 |
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 |
| 19:43 |
whaack |
that address http://paste.deedbot.org/?id=byob but instead I saw a balance of 0 after scanning above block 170. |
| |
~ 2 hours 31 minutes ~ |
| 22:14 |
feedbot |
http://ztkfg.com/2020/07/spanish-practice-log-10-july-5th-2020/ << whaack -- Spanish Practice Log 10, July 5th 2020 |
| 22:19 |
feedbot |
http://ztkfg.com/2020/07/spanish-practice-log-12-july-7th-2020/ << whaack -- Spanish Study Log 12, July 7th 2020 |
| |
~ 17 minutes ~ |
| 22:36 |
feedbot |
http://ztkfg.com/2020/07/spanish-practice-log-11-july-6th-2020/ << whaack -- Spanish Practice Log 11, July 6th 2020 |
| |
~ 20 minutes ~ |
| 22:57 |
jfw |
I'm alive, just in a bit of a hole owing to various accumulated sins against time. Light's on the horizon though. |
| 23:01 |
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. |
| 23:04 |
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 |
| 23:06 |
jfw |
(32 byte hash -> 8 byte rowid, multiplied by every transaction in bitcoin would save quite some space I expect.) |
| 23:07 |
jfw |
and removing the "input" table (which I believe I mentioned in the schema article) |
| 23:12 |
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. |
| 23:12 |
jfw |
Possibly even the way gbw-node itself ought to be - though the full index will have a hefty size cost. |
| 23:13 |
jfw |
incidentally if TRB had used SQL this tradeoff would literally be a one-liner CREATE INDEX. |
| 23:16 |
jfw |
2T/16G wouuld be plenty beefy enough, indeed 1T/4G probably fine |
| 23:17 |
jfw |
the extra ram can always be thrown at database cache though so won't hurt. |
| 23:20 |
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. |
| 23:22 |
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 |
| 23:24 |
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. |
| 23:27 |
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. |
| 23:29 |
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. |
| 23:29 |
jfw |
*more recent sample |
| 23:30 |
jfw |
"more recent" as in past the first couple 10k, iirc. |
| 23:32 |
jfw |
whaack: I un-lazied and clicked your link, this is indeed the situation. |
| 23:35 |
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. |
| 23:38 |
jfw |
out_script_address is the filtering/extraction function there. |
| 23:39 |
whaack |
jfw: Addressing a few things: Yes I meant changing the code to remove watched addresses and index all seen addresses. |
| 23:40 |
whaack |
jfw: Indeed, I believe the problem was with building Boost. |
| 23:41 |
jfw |
whaack: cool. Off to sleep now but I should be back tomorrow. |
| 23:42 |
whaack |
jfw: gn |