Day changed to 2022-02-04
[00:08] jfw: http://fixpoint.welshcomputing.com/2022/the-simplest-way-yet-to-fetch-bitcoin-code/
Day changed to 2022-02-16
[03:03] jfw: whaack: re http://ztkfg.com/2022/02/trbexplorer-genesis-release/ , since you seem to indeed take the stance that your thing is changed entirely, with no attempt at maintaining compatibility etc - which I reckon is for the best since we're not really collaborating on it - I can't for the life of me figure out why you'd then
[03:03] sourcerer: 2022-01-27 20:32:15 (#jwrd) whaack: i probably am going to regenesis, as the function has changed entirely
[03:03] jfw: squat on the 'gbw' name in all the spaces, even to the extent of cooking up a new GBW_HOME environment variable as if it had something to do with me.
[03:19] jfw: also I'm not going to comment on your blog if it requires doing CAPTCHAs. not saying you gotta change it or anything, after all it's your blog to filter as you see fit; but thought I'd give the feedback as to what that filter is selecting for/against.
[03:35] whaack: jfw: Thanks for the feedback. It was a failed/lazy refactoring job mostly, rather than an intent to keep the gbw name included in the source. I think that the GBW_HOME environ variable i made years ago, before I had named the program trbexplorer. I'll remove the gbw phrasing in the next vpatch.
[03:38] whaack: Re the CAPTCHA, that you would not comment because of it is enough for me to remove it, I do not want to over filter. I'll take a look at some other options, I added it because I was inundated with about 1000 spam comments during my blogging hiatus.
[04:10] jfw: whaack: cool. re spam, a practice of checking daily, even if your writing is wedged, as you would for any other inbox you cared about, helps keep it manageable; still, I started getting 10-20 a day which bugged me enough to have a look at the code and tweak the magic field names sufficiently to throw off the current generation of scripts. 99% effective.
[04:13] jfw: I'm not spelling it out because why make it easy for them, but it can probably be spotted easily enough from my comment box html.
[04:19] jfw: basically the same principle as your factorial-algebra: trivial to defeat by script, but requires someone with brain to actually look at it and update the script; a high barrier in nearly any demographic these days but certainly among spammers.
[06:55] anotheruserback: Hello again gentlemen
[14:32] jfw: anotheruserback: all your base are belong to us ??
[14:57] anotheruserback: jfw: I don't understand what you are asking
Day changed to 2022-02-17
[08:16] caai17: jfw: Hey, how are you? Question: I assume that I will need to register a different nick for each computer that I use, right?
[15:26] whaack: caai17: normally you would use the same nick on each machine you use.
[16:05] jfw: not to mention sticking around long enough to receive answers!
[16:06] jfw: I believe he's getting set up on another machine today though.
Day changed to 2022-02-19
[19:29] caai17: jfw: hahaha
[19:31] caai17: I will stay connected on this machine until I have the thinkpad set up.
[19:35] caai17: I have been working on getting the thinkpad set up over the last 2 days.
[20:09] caai17: jfw: It looks like all of the orders were delivered yesterday, except the Cache Internal Hard Drives (ST2000LM003). It says that the new expected delivery date in Thursday, February 24. To my understanding, you already have the tracking number, and therefore, are aware of this.
[21:11] jfw: caai17: any particular difficulties with the thinkpad?
[21:14] jfw: caai17: thanks for the update; I heard that at least one of the items had arrived. Both the Fedex and Amazon tracking sites failed to produce any results for me, and on two different machines (while UPS at least recently was working OK), so as far as I'm concerned those are antiquated couriers that don't have tracking service.
[21:14] jfw: so much for the web, nice while it lasted.
[21:18] jfw: caai17: as it happens I'm currently working on assigning handles (usernames) for everyone we've worked or done business with, for whatever present or future purposes; would you like to go with 'caai17' for that?
[21:18] jfw: does the 17 mean something btw?
[21:24] jfw: re http://fixpoint.welshcomputing.com/2022/jwrd-logs-for-Feb-2022/#3185 , it was a 2000's internet "culture" reference, the memory of which you inadvertently triggered; https://knowyourmeme.com/memes/all-your-base-are-belong-to-us
[21:24] sourcerer: 2022-02-16 14:57:11 (#jwrd) anotheruserback: jfw: I don't understand what you are asking
[21:27] jfw: as a multilinguist you'll probably find it amusing enough.
Day changed to 2022-02-20
[17:10] caai: For now, I will use the nick caai, thus dropping the 17
[17:12] caai: In regards to the thinkpad, I will delineate all of the steps that I have taken in order to help you identify where I have gone astray or not gone far enough:
[17:13] caai: Operating as user, under the src directory, I created a child directory named yrc
[17:18] caai: Under said yrc directory, I downloaded yrc_subdir_genesis.vpatch & yrc_linear_scroll_etc.vpatch, along with their accompanying signatures (4 files in total) from fixpoint.welshcomputing.com/2020/yrc-re-genesis-and-patch-for-smooth-scrolling-and-other-fixes/
[17:20] caai: I created the patch directory and moved the patches to said directory
[17:21] caai: I created the .seals directory and moved the signatures to said directory
[17:24] caai: I created a symbolic link to a .wot directory located under the trb directory on my computer
[17:26] caai: In the newly created ~/src/yrc directory, I ran v.pl wot - keys recognized - check
[17:27] caai: I ran v.pl flow - patches properly organized (2 in total) - check
[17:28] caai: I ran v.pl leafs - patch propery shown (1 in total) - check
[17:32] caai: I ran v.pl p yrc_linear_scroll_etc patches/yrc_linear_scroll_etc.vpatch - check
[17:33] caai: I ran find yrc_linear_scroll_etc/ | sort - recursive listing of tree seems satisfactory - check
[17:35] caai: In the home directory ~, I ran mkdir -p ~/.yrc/nets/freenode
[17:37] caai: I ran echo chat.freenode.net > ~/.yrc/nets/freenode/addrs
[17:38] caai: I ran whoami > ~/.yrc/nick
[17:40] caai: In the directory ~/.yrc, I ran yrc and received the following message: ksh: yrc: not found
[17:55] caai: re http://fixpoint.welshcomputing.com/2022/jwrd-logs-for-Feb-2022/#3201, hahaha, gotcha. I am happy that I have helped keep this classic meme alive
[17:55] sourcerer: 2022-02-19 21:27:48 (#jwrd) jfw: as a multilinguist you'll probably find it amusing enough.
[22:12] jfw: caai: thanks for that listing of steps - very clear & tidy.
[22:17] jfw: what you appear to be missing is the installation step so that it can be run from anywhere on the system rather than just the 'press' directory; this is found in the INSTALLATION section at the top of README.txt in the source tree, namely: 'python setup.py install' (which must be run from that same directory)
[22:19] jfw: then you'll perhaps want to review the email I sent about switching from freenode to JWRD's server (and please keep the given IP address in the shadows for now)
[23:36] jfw: indeed as the README notes but I missed here, that install command needs to run as root. however, there's a further hitch when installing on a Gales system (currently stagnating as a FIXME in the py-setuptools gport), that scripts get installed to /gales/pkg/python/bin which isn't on the shell search path.
[23:38] jfw: as a workaround, you can do as root after the install: 'mv /gales/pkg/python/bin/yrc* /local/bin/'
Day changed to 2022-02-21
[04:06] caai: excellent. I have followed the installation step as root in the directory which has said file in it: python2 setup.pty install
[04:08] caai: After that, as root, I moved the file: mv/gales/pkg/python/bin/yrc* /local/bin
[04:10] caai: Apparently, this were the missing steps that needed to be completed because I am sending these messages from the thinkpad
[04:11] caai: these were*
[17:09] jfw: caai: nice, congrats. see you around and soon we can get to the 'bitcoind' troubles that instigated this.
Day changed to 2022-02-22
[14:42] caai: jwrd: Thanks. Sounds good. I am ready to get to the 'bitcoind' troubles whenever you are.
[16:56] jfw: for future reference, I discovered why the log articles aren't showing up in my 'Archives' sidebar section (for better or worse but certainly not by intent): awklogbot isn't setting the post_date_gmt field, while at least the queries that populate that aggregate view require it
[16:56] jfw: existing and nonzero. There's also a post_modified_gmt field and I don't as yet know what for.
[17:03] jfw: a sane schema IMO would have used gmt dates only and MAYBE an optional offset field if the time according to the author's local courthouse at time of publish/edit is really of interest to anyone.
[17:07] jfw: in practice, all date fields on my blog are gmt because my server doesn't concern itself with time zone data.
[17:12] jfw: in other words, my earlier guess was correct.
[17:12] sourcerer: 2021-07-06 20:43:58 (#jwrd) jfw: I have a guess on why the log articles aren't showing up in the archive counts: for some infernal reason wordpress has two different fields for each type of date, one labeled 'gmt', the other who knows what, certainly doesn't show any zone info in the data itself
[17:18] jfw: the finding came from curiosity about a SQL error I spotted in the html from hanbot's blog, originating from the same dubious queries
[17:19] jfw: "[Expression #1 of ORDER BY clause is not in GROUP BY clause and contains nonaggregated column 'hanbot.wp_posts.post_date' which is not functionally dependent on columns in GROUP BY clause; this is incompatible with sql_mode=only_full_group_by]"
[17:26] jfw: this in turn was because I've now implemented the long awaited auto-archiving of links in chan and was sanity-checking the data.
[17:26] sourcerer: 2020-11-18 06:19:12 (#jwrd) jfw: but it's working nicely now and just about where I want it ; the main things I'd like to add before going live are scraping of external links for auto-archiving, and forward/backward threading links for the log articles. Then I'll need a script to back-fill my existing logs through the usual processing. Although, I suppose I could post-date them so that going live isn't dependent on finishing
[17:29] jfw: no frontend for it yet, but all links are now saved - except a couple where the regex didn't "Do What I Meant" with trailing punctuation, and a couple broken ("upgraded" I imagine) servers throwing SSL handshake errors
[17:36] jfw: the full list of such trailing punctuation observed: close-paren, comma, double-quote, and... control-A, from that pesky CTCP ACTION.
[17:50] jfw: from a grep of my firefox history of 196k unique URLs, close-paren and dot are pretty common as final characters e.g. in wikipedia articles, while there's exactly one comma which looks like a mis-paste anyway, one single-quote and no double-quote.
[18:06] jfw: there's a bit more fine print to the above "all links are now saved", I suppose I should have a look at all the failures and document it.
[18:45] jfw: dorion: I've linked to the event files via http://dorion-mode.com/2021/12/event-identity-money-and-banking-in-the-internet-age/#comment-2684 but perhaps you'd like to incorporate direct links into the Presentations section of the page. It'd be the logical place for the would-be yewtube comments to be directed, anyway.
[18:46] jfw: caai: I'll be up for a rundown on the bitcoind issue at 20 UTC / 3pm local
[20:12] jfw: I'll dig out the highlights of prior conversations for the log. It started when caai dusted off his node and tried to get it synced a few weeks ago; at some point the thinkpad crashed, showing a kernel OOPS on null instruction pointer. This of course brought back jfw's recent memories of similar woes on an apu1 which were ultimately circumvented by switching to a thinkpad; so far though it appears
[20:12] jfw: to be a transient event.
[20:14] jfw: Upon reboot, the node restarted seemingly OK and even got blocks for a while, if I'm recalling correctly.
[20:15] jfw: Somewhere in there my latest patches including the crashproofing and cleanup of crash-recovery code.
[20:15] jfw: * were applied.
[20:16] jfw: But some time later it got stuck, not accepting further blocks and showing in 'getinfo' the somewhat familiar error, 'received invalid chain with greater proof-of-work ... displayed transactions may be incorrect'.
[20:20] jfw: At my request, caai restarted it with a -checkblocks=0 flag, to check integrity of all blocks on the current chain since genesis, and let the check run; it completed successfully then resumed its 'wedged' state, casting strong doubt on the hypothesis that some data had got corrupted due to buggy code or flaky RAM or some such.
[20:24] jfw: My next thought was to try a manual-feed of a known-good next block, to rule out problems in the networking code or hostile or misbehaving peers.
[20:25] jfw: caai: what's your current "blocks" count as shown by "getinfo", so that I can extract a series of nearby blocks for this testing?
[22:54] caai: jfw: sorry about the delayed response. I just now saw your message.
[22:55] caai: My current blocks count is 720920
[23:36] jfw: caai: no problem, it wasn't much delay given that we didn't have an appointment set, I was just giving it a try.
[23:44] jfw: caai: I've put the range of blocks 720919-720922 up at http://fixpoint.welshcomputing.com/wp-content/uploads/2022/02/blk720919 and so forth. try downloading them (with wget or links) and feeding them to the node as follows:
[23:46] jfw: "bitcoind eatblock $PWD/blk720919" - the $PWD makes it expand to an absolute path, because otherwise it can get confusing because the path is interpreted relative to where bitcoind was started rather than to the shell you're running eatblock from.
[23:48] jfw: the expected behavior for the blocks you already have is to print 'false' on the terminal and 'ProcessBlock() : already have block ... from peer LOCAL' in the ~/.bitcoin/debug.log
[23:50] jfw: then we'll see what happens on the newer blocks. to reduce the log noise you might need to get something like this running first: tail -f debug.log | egrep 'Block|Chain'
[23:54] jfw: actually the most useful would be the full log output when eating a "bad" block; to capture that you can do 'tail -c 100k ~/.bitcoin/debug.log > snip.log' just afterward. that should produce a light enough result to load up in vim and trim down further or just paste as-is.
[23:57] jfw: for pasting you can use http://paste.deedbot.org/ ; let me know if you need help getting the data to there from the CLI environment.
Day changed to 2022-02-23
[00:04] jfw looks at his own script for the task, has trouble seeing why http requests and url-encoding should be necessary just to dump some bytes in a bin and get back an identifier
[07:28] jfw tests some tweaks to the archiver link recognizer, which is unfortunately somewhat different from the clickable-link formatter: "http://jwrd.net" 'http://jwrd.net' <http://jwrd.net> http://jwrd.net, http://jwrd.net
[07:35] jfw: nice, so although those (except the last one) are discouraged and fail in various ways in the web view, they're now all recognized as the same link by the background archiver.
[07:39] jfw: which I'd say makes for a correct incentive structure actually.
[17:56] jfw: caai: from the server's perspective, your client was present in the channel until 13:32 today (8:32am local). there's even some degree of certainty here, because the server and client regularly 'ping' each other and take action if the response times out. but at that time, the server logged a 'Read error on connection 12 (socket 12): Connection reset by peer!' this error indicates a somewhat
[17:56] jfw: 'unclean' shutdown of the TCP connection; it's hard to say why as yet, but assuming the client machine itself wasn't rebooted, one possibility is a stateful firewall somewhere along the path being rebooted, or otherwise running out of memory and dropping connection states. and unless the ISP is misbehaving pretty badly, that means one of the routers at your place; does that seem possible?
[17:56] jfw: certainly the timing is interesting since it appeared to be fine until you tried using it.
[17:59] jfw: one point of possible confusion is the term 'registered'; on irc that may simply refer to your current network connection (TCP) being associated with your nickname, such that others can't use the same nick while you're connected; this is the sense meant by the errors you were seeing. a more advanced network however will also keep a permanent sort of registration to prevent others from grabbing
[17:59] jfw: your nick while you're away, requiring some kind of authentication be it shared secret (password) or public/private key.
[18:04] jfw: otherwise I gather you'd like to work on these things around 8:30 to 9am; I will plan accordingly. (my schedule's been slipping later again lately so I hesitate to commit right away to morning availability.)
Day changed to 2022-02-24
[14:39] caai: jwrd: Guten morgen
[14:53] caai: Upon writing my second message, I was given an error message. Therefore, I checked if I was able to login via the gentoo machine. It seems to have a more stable connection.
[14:54] caai: I then logged off the gentoo machine, rebooted the thinkpad and now here I am writing these messages. Vamos a ver que sucede
[15:10] caai: From the asus: upon sending the next message via the thinkpad, I received the following error: ERROR: connection to freenode not registered
[15:11] caai: As stated above, I am not writing from the gentoo/asus
[15:13] caai: 1st Step: I decided to list the directory contents of ~/src/bitcoin/patches to verify that I have received the new patchs: 'bitcoin_fsync_all_blocks.vpatch' & 'bitcoin_checkblocks_cleanup.vpatch' - neither are listed
[15:15] caai: As stated above, I am NOW writing from the gentoo/asus
[15:19] caai: Step 2: In regards to downloading the blocks, could you please indicate which directory I should download them to? I assume: '~/src/bitcoin/bitcoin_dumpblock_no_losers/bitcoin/src' ..?
[15:44] jfw: caai: that thinkpad network connection is looking pretty dismal, huh.
[15:46] jfw: caai: good that you noticed those patches were missing; we were proceeding from incorrect assumptions.
[15:48] jfw: the directory for the block files doesn't matter as far as the software is concerned; I wouldn't put them in 'src' because they're not source code. and you can delete them once we're done. so I'd say right in ~ would be fine
[15:54] jfw: caai: I'd like to get the 'checkblocks' part straightened out first though. can you download those new patches & sigs to the necessary location then tell me what's shown by "v.pl leafs" ?
[15:56] jfw: or rather, ensure "bitcoin_checkblocks_cleanup.vpatch" is included in that output then do a press to that one. or if you'd like to be a bit more adventurous you could try out my new script
[16:04] jfw: caai: another thought arises: before going through the fetch/rebuild dance, let's confirm what version is actually in use, e.g. in case it was built from some location different from where you're now looking. do a "bitcoind -help" and see if you see a line for "-checkblocks", toward the bottom.
[16:05] jfw: (if you do, it's the latest already.)
[16:13] jfw: looking again at the "checkblocks" change though, it shouldn't actually make a difference here, i.e. the meaning of '-checkblocks=0' was unchanged. so, please do check the version for clarity's sake but then proceed with the eatblock test.
[16:13] sourcerer: 2022-02-22 23:44:46 (#jwrd) jfw: caai: I've put the range of blocks 720919-720922 up at http://fixpoint.welshcomputing.com/wp-content/uploads/2022/02/blk720919 and so forth. try downloading them (with wget or links) and feeding them to the node as follows:
[17:50] caai: jfw: Shortly after my last message, the day's tasks began to overwhelm me. I will connect again soon to follow your directions.
[18:39] jfw: caai: good luck digging out from those tasks then!
[20:31] jfw: worth rescuing from the usual hatchet brigades of contemporary sound-bite journalism: https://archive.is/oxtBy ( https://www.bloomberg.com/news/articles/2022-02-24/full-transcript-vladimir-putin-s-televised-address-to-russia-on-ukraine-feb-24 )
[22:12] jfw: Just received a batch of "DTECH" USB to TTL serial converters; they're working so far with the pl2303 driver in the Gales kernel but I was alarmed to find they've reversed the color code for send vs. receive from all previous such adapters I'd seen.
[22:29] jfw: makes a good reminder that "approximately the same item" is a risky concept. giving it a burn-in test now, feeding /dev/urandom from TRNG and will check back for usb flaking as was reported with some other models.
[22:30] jfw: "Internal EEPROM with users writable area" ugh why the fuck.
Day changed to 2022-02-25
[14:35] caai: Clocking in. Let the day begin.
[14:53] jfw: good morning caai, are you clear on the next steps?
[14:55] jfw: caai: was that the network dropping out again but from the asus this time?
[14:56] caai: I downloaded 'bitcoin_fsync_all_blocks.vpatch' & 'bitcoin_checkblocks_cleanup.vpatch' and their signatures to ~/src/bitcoin/patches & ~/src/bitcoind/.seals
[14:56] caai: Yes, the networked dropped again but from the asus this time
[14:57] caai: I listed directory content and the patches are present under ~/src/bitcoin/patches
[14:58] jfw: alright, then it seems the thinkpad is off the hook for now. sounds fine re patches, listening...
[14:58] caai: I ran v.pl flow and I do not see the new patches in 'the flow'
[14:59] jfw: a basic question perhaps but are you running it from the proper directory (~/src/bitcoin) ?
[15:00] jfw: I imagine so if there's a "flow" at all.
[15:00] caai: I ran v.pl leafs from ~/src/bitcoin: Leaf: bitcoin_dumpblock_no_losers.vpatch (jfw)
[15:01] caai: Yes, I am running commands from ~/src/bitcoin
[15:02] jfw: odd; I do see a divergence in your message above between src/bitcoin and src/bitcoind but assumed it was just a typo, is that so?
[15:05] jfw: v.pl unfortunately tends to be of very little help in diagnosing problems - part of why we're moving away from it - but we can at least try to cover the basics.
[15:06] caai: Yes, the '~/src/bitcoind/.seals' is really '~/src/bitcoin/.seals'
[15:06] caai: It was a typo
[15:07] jfw: note also this point: http://fixpoint.welshcomputing.com/2022/jwrd-logs-for-Feb-2022/#3288
[15:07] sourcerer: 2022-02-24 16:04:04 (#jwrd) jfw: caai: another thought arises: before going through the fetch/rebuild dance, let's confirm what version is actually in use, e.g. in case it was built from some location different from where you're now looking. do a "bitcoind -help" and see if you see a line for "-checkblocks", toward the bottom.
[15:08] caai: I ran bitcoind -help. There is an option listed near the bottom: -checkblocks=<n>
[15:09] jfw: ah ok then. so dorion was correct in telling me he'd got it rebuilt with the latest patches - but it's probably in some other directory, perhaps ~/trb or something.
[15:10] jfw: in this case we can leave the v.pl flow/leafs problem and continue with the eatblocks test.
[15:11] jfw: o.O quite some network problem
[15:14] caai: I just listed the directory contents of ~/src/trb/patches and the are there
[15:14] caai: and they* are there
[15:14] jfw: aha.
[15:14] caai: Shall I proceed forward with the eatblock test?
[15:14] jfw: please do
[15:19] caai: I keep getting kick out
[15:20] jfw: I see. I'm probably going to have to just come over and trace the cables
[15:21] jfw: a luxury, but one we have at the moment.
[15:21] caai: I ran links fixpoint.welshcomputing/wp-content/uploads/2022/02/blk/720919 | Message received: You don't have permission to access /wp-content/uploads/2022/02/blk/720919 on this server.
[15:22] jfw: whoops, try again now.
[15:22] caai: Yes, a luxury we can't depend on in the future
[15:25] caai: The screen has said making connection for the last 120 seconds
[15:26] jfw: for one thing, the link shown above is missing .com; for another it's "blk720919" without a slash in the middle; for a third that I didn't mention, for "links" you'll want to use the parent directory (i.e. leave out the "blk...") and use "d" to download the files.
[15:28] jfw: hopefully you're using the shell history and not re-typing the whole link each time here.
[15:33] jfw: caai: this network (or lack thereof) is pretty much a blocker now. will you have some time today for me to look?
[15:35] caai: Sorry, I must always follow the path of the turtle in this environment, perhaps all, and make sure I type everything correctly. With that said, I typed everything correctly on the thinkpad. It eventually displayed a lot of code. I quit the page. Now, in order to keep it simple, I will simply run wget with the same argument.
[15:36] jfw: the "making sure" is well and good, perhaps in time it can be separated from the "typing everything".
[15:37] caai: Yes, can you come over, or I go over, before going to Robinson's bday party?
[15:37] jfw: yes, the "pile of ???? instead of downloading" is what prompted the "parent directory and download" point above.
[15:43] jfw: (the final question there was answered out-of-band as the connection failed again.)
Day changed to 2022-02-26
[19:33] jfw: to follow up here, that network problem is resolved. I mapped the topology, inspected connectors, checked one router's uptime and memory load, and was trying to track down credentials for the cable-company-provided modem-router-wap monstrosity when the symptoms presented themselves for direct poking... it was an IP address collision on the statically numbered LAN.
[19:34] jfw: (which explains why the irc connection dropped only when caai was trying to do things)
[19:41] jfw: irc reconnection was also complicated by the fact that my instructions to update the config to point to us instead of dead-freenode were implemented as an append rather than replace so it had to cycle through the list racking up timeouts.
[19:42] jfw: and http://ossasepia.com/2020/06/01/ossasepia-logs-for-jun-2020/#1027337 came up again.
[20:36] jfw: http://fixpoint.welshcomputing.com/2022/jwrd-logs-for-Feb-2022/#3296 << so far so good at 46 hours. I got a suggestion to use nail polish to correct the wire colors... which might even be the practical solution for just this once, since getting something else to the isthmus could take another 2 weeks
[20:36] sourcerer: 2022-02-24 22:29:10 (#jwrd) jfw: makes a good reminder that "approximately the same item" is a risky concept. giving it a burn-in test now, feeding /dev/urandom from TRNG and will check back for usb flaking as was reported with some other models.
[20:37] jfw: I do NOT want to introduce 'autoconfism' into my wiring docs.
[21:12] jfw: another minus for the Dtech: the connector case is harder to pry open to see the board inside. this done, it's indeed a different board from the previous item - for which the distinguishing characteristic known so far is "the unmarked black one".
[21:14] jfw: we might not have a choice about 'autoconfing' it in the end what with all of it having no more identity than 'nondescript sandwich of plastic and solder from china' and the constant shortages & shifting sands at the suppliers
[21:15] jfw: but the plan is to try to find a good one then stock up when I'm back in the states.
Day changed to 2022-02-27
[02:22] caai: http://fixpoint.welshcomputing.com/2022/jwrd-logs-for-Feb-2022/#3340 Yes, which is much appreciated. And, we determined that both computers should run though the secure eth1 port. Of course, I still have much to learn in order to ensure they are indeed run securely.
[02:22] sourcerer: 2022-02-26 19:33:21 (#jwrd) jfw: to follow up here, that network problem is resolved. I mapped the topology, inspected connectors, checked one router's uptime and memory load, and was trying to track down credentials for the cable-company-provided modem-router-wap monstrosity when the symptoms presented themselves for direct poking... it was an IP address collision on the statically numbered LAN.
[02:28] caai: Next task: http://fixpoint.welshcomputing.com/2022/jwrd-logs-for-Feb-2022/#3259 Shall we set up another meeting to ensure this task is completed properly before you head back to the states?
[02:28] sourcerer: 2022-02-22 23:44:46 (#jwrd) jfw: caai: I've put the range of blocks 720919-720922 up at http://fixpoint.welshcomputing.com/wp-content/uploads/2022/02/blk720919 and so forth. try downloading them (with wget or links) and feeding them to the node as follows:
[06:17] jfw: caai: let's try for starters an irc-meeting; would you be free at 3pm / 20 UTC tomorrow?
[15:30] caai: jfw: an irc-meeting at (3 pm) 20 UTC on Feb 28 works for me. See you then.
[15:50] jfw: caai: ah, I meant tomorrow as in the 27th though indeed technically that would have been 'today'.
[15:54] caai: Alright. Today at 20 UTC works. See you then.
[15:54] jfw: cool.
[20:00] caai: Clocking in. Should I use yrc on the thinkpad?
[20:05] jfw: I'm not sure which will be best as yet so I'd say stick with wherever you are now.
[20:05] caai: From the ~ directory, I have run wget on http://fixpoint.welshcomputing.com/wp-content/uploads/2022/02/blk720919 | It appears to have downloaded successfully.
[20:06] caai: Shall I proceed forward with this step? http://fixpoint.welshcomputing.com/2022/jwrd-logs-for-Feb-2022/#3260
[20:06] sourcerer: 2022-02-22 23:46:46 (#jwrd) jfw: "bitcoind eatblock $PWD/blk720919" - the $PWD makes it expand to an absolute path, because otherwise it can get confusing because the path is interpreted relative to where bitcoind was started rather than to the shell you're running eatblock from.
[20:07] jfw: There was a range of blocks to download there, not just one
[20:08] jfw: http://fixpoint.welshcomputing.com/2022/jwrd-logs-for-Feb-2022/#3259
[20:08] sourcerer: 2022-02-22 23:44:46 (#jwrd) jfw: caai: I've put the range of blocks 720919-720922 up at http://fixpoint.welshcomputing.com/wp-content/uploads/2022/02/blk720919 and so forth. try downloading them (with wget or links) and feeding them to the node as follows:
[20:10] jfw: once you have them all then yes, please proceed with eatblock, one at a time
[20:10] caai: Alright. Trying to download the range of blocks now
[20:13] caai: I have downloaded blocks 720919-720922. Starting to run bitcoind eatblock on each one individually now
[20:22] jfw: it should show a 'true' or 'false' for each one; let's hear those results then look closer at the debug log.
[20:25] caai: I have tried a few things and I seem to be missing a step or two. Do I need to be in the .bitcoin directory? Does bitcoind need to be running beforehand?
[20:26] jfw: the node certainly does need to be running.
[20:26] caai: Alright. It is running now
[20:27] jfw: as for directory, it needs to be where the files were downloaded (unless you fully type out the absolute path)
[20:32] caai: From ~ directory, where blks are located, upon running: 'bitcoind eatblock $PWD/blk720919' the following message was received: 'error: {"code":-2,"message":"Safe mode: WARNING: Received invalid chain with greater proof-of-work. Displayed transactions may not be correct! Your database or other nodes may be corrupted."}
[20:33] jfw: lol, of course, "for your own good". we'll need to override that...
[20:34] jfw: kill the node then start it with a -disablesafemode flag
[20:35] jfw: (seems clear to me that 'eatblock' should be on the whitelist for safe mode anyway)
[20:36] caai: bitcoind -disablesafemode running....
[20:39] caai: From ~ directory, upon running: 'bitcoind eatblock $PWD/blk720919' the following message was received: 'error: {"code":-1,"message":"CAutoFile::operator>> : file handle is NULL"}
[20:42] jfw: ugh. that means it failed for some reason to open the file, and won't tell us why because asciilifeforms can't be bothered with pesky details like error checking.
[20:42] jfw: try this basic sanity test: ls -l $PWD/blk720919
[20:43] jfw: you don't need to paste the whole output, just tell me if it shows an existing, readable file as expected or an error.
[20:43] caai: Yes, it show an existing, readable file
[20:45] jfw: thinking...
[20:48] jfw: I can't see any way this makes sense, so grasping at straws. try this one: tail -c 5m ~/.bitcoin/debug.log | less
[20:49] jfw: this loads the last 5 megs of the log which I'm guessing is enough; then search ('slash' key) for eatblock; once found, check the following line
[20:50] jfw: it should say "Attempting to create block #<something> from file <somefile>" ; <somefile> should be /home/<user>/blk720919. check if this is so
[20:51] caai: There are 8 logs, all of which read the same: 'ThreadRPCServer method=eatblock'
[20:53] jfw: possibly you need to continue to the last one where we'd disabled safe mode
[20:54] jfw: the line I'm looking for should follow either immediately or soon after the one you quoted.
[20:55] caai: Running same command now.....
[20:58] caai: Upon searching /eatblock, there is a message that says "Attempthing to create block#720921 from file blk720919"
[20:58] caai: which is the lastest one
[21:00] caai: It looks like the last 3 messages, following the line with eatblock, all read the same: "Attempting to create block#720921 from file blk720919"
[21:01] jfw: interesting. are you *sure* you included the $PWD/ part when you ran eatblock ?
[21:05] caai: Just ran it correctly, with PWD, which I was doing when it was in safe mode, but not upon disabling safe mode
[21:05] caai: It give a simple message: false
[21:06] caai: It gives*
[21:06] jfw: aha.
[21:07] jfw: false means it already has the block, as expected; so now continue with the next ones.
[21:08] caai: all 4 have been done, all giving the same message: 'false'
[21:11] jfw: looking closer at the code I'm not at all sure I trust the comments about the meaning of 'false' anymore. let's do the log paste now so I can see it in full.
[21:12] jfw: do for starters: tail -c 5m ~/.bitcoin/debug.log > debug-snip.log
[21:14] caai: done
[21:14] jfw: this gives us something unchanging to work with. then: sed -n '/blk720920/,$p' debug-snip.log > debug-snip-tail.log
[21:14] jfw: (make sure to get the special characters correct)
[21:16] jfw: then it's http://fixpoint.welshcomputing.com/2022/jwrd-logs-for-Feb-2022/#3264 but I expect you'll need more specific instructions.
[21:16] sourcerer: 2022-02-22 23:57:16 (#jwrd) jfw: for pasting you can use http://paste.deedbot.org/ ; let me know if you need help getting the data to there from the CLI environment.
[21:23] jfw: caai: how's it going?
[21:25] caai: Almost there
[21:30] caai: when I run links paste.deedbot.org/ it says: Host not found
[21:32] jfw: can you tell me why?
[21:34] caai: Perhaps the firewall is blocking it
[21:36] jfw: no, it's because the thinkpad does not use DNS, therefore it doesn't know any hostnames that it hasn't been told about (by you).
[21:37] jfw: so you'll need to get a root shell and edit /etc/hosts
[21:37] jfw: and add the line: 96.43.130.234 paste.deedbot.org
[21:38] jfw: however, "links" still isn't going to be adequate for the task, because AFAIK it doesn't have a way to import the contents of a file to its input fields.
[21:39] jfw: I have a script for this instead: http://fixpoint.welshcomputing.com/code/misc/deedbot-paste.py
[21:40] caai: paste.deedbot.org It has been added
[21:41] caai: I will open the script
[21:41] jfw: good. see if you can download the linked script, sanity-check the code (it's short), install to /local/bin and run. It will paste whatever it reads from standard input.
[21:42] jfw: thus the usage will be (as the regular user again): deedbot-paste.py < debug-snip-tail.log
[21:43] jfw: if it works, it'll display a short URL, which you then post here. I have to go shortly but that should give you enough to chew on for now.
[21:44] caai: alright
Day changed to 2022-02-28
[15:06] caai: Deedbot script has been successfully downloaded
[15:11] dorion: good morning caai, did you give it a spin ? post the link here when you've done so.
[15:15] caai: Good morning jfw, I assume that I must chmod the script? chmod +x /local/bin/deedbot-paste.py
[15:21] caai: debug-snip-tail.log = http://paste.deedbot.org/?id=YSjo
[15:35] jfw: caai: well done (and no need to assume: to run a file as a command it must indeed be executable.)
[15:43] jfw: my read of the log is that indeed it already has all the blocks being tested, recognizing them by hash; which would seem to mean it's accepted them in some provisional way; yet it refuses to fully accept any past 720920 and activate them as the best chain.
[15:44] jfw: I'm most likely going to have to dig into the code; but this at least gives me some specific questions to guide the search.
[15:57] jfw: caai: the clock offset may also be relevant, though I'm not sure how given that these are old blocks. I recall you tried to reset the date & time recently, but looks like it didn't take; perhaps the system was uncleanly shutdown. You can force an update of the battery-backed ("hardware") clock from the "live" clock by running "hwclock -w" (as root, after setting the time).
[16:00] jfw: caai: meanwhile I'd suggest stopping the node because it's just going to be endlessly downloading the same old blocks that it can't use.
[16:03] jfw: caai: you can also clean up by removing the debug-snip*.log now.
[16:04] jfw: let's leave the block files for future testing though.
[16:09] jfw: "Good morning jfw" - heh, I must point out that was dorion you were replying to initially
[00:08] jfw: http://fixpoint.welshcomputing.com/2022/the-simplest-way-yet-to-fetch-bitcoin-code/
Day changed to 2022-02-16
[03:03] jfw: whaack: re http://ztkfg.com/2022/02/trbexplorer-genesis-release/ , since you seem to indeed take the stance that your thing is changed entirely, with no attempt at maintaining compatibility etc - which I reckon is for the best since we're not really collaborating on it - I can't for the life of me figure out why you'd then
[03:03] sourcerer: 2022-01-27 20:32:15 (#jwrd) whaack: i probably am going to regenesis, as the function has changed entirely
[03:03] jfw: squat on the 'gbw' name in all the spaces, even to the extent of cooking up a new GBW_HOME environment variable as if it had something to do with me.
[03:19] jfw: also I'm not going to comment on your blog if it requires doing CAPTCHAs. not saying you gotta change it or anything, after all it's your blog to filter as you see fit; but thought I'd give the feedback as to what that filter is selecting for/against.
[03:35] whaack: jfw: Thanks for the feedback. It was a failed/lazy refactoring job mostly, rather than an intent to keep the gbw name included in the source. I think that the GBW_HOME environ variable i made years ago, before I had named the program trbexplorer. I'll remove the gbw phrasing in the next vpatch.
[03:38] whaack: Re the CAPTCHA, that you would not comment because of it is enough for me to remove it, I do not want to over filter. I'll take a look at some other options, I added it because I was inundated with about 1000 spam comments during my blogging hiatus.
[04:10] jfw: whaack: cool. re spam, a practice of checking daily, even if your writing is wedged, as you would for any other inbox you cared about, helps keep it manageable; still, I started getting 10-20 a day which bugged me enough to have a look at the code and tweak the magic field names sufficiently to throw off the current generation of scripts. 99% effective.
[04:13] jfw: I'm not spelling it out because why make it easy for them, but it can probably be spotted easily enough from my comment box html.
[04:19] jfw: basically the same principle as your factorial-algebra: trivial to defeat by script, but requires someone with brain to actually look at it and update the script; a high barrier in nearly any demographic these days but certainly among spammers.
[06:55] anotheruserback: Hello again gentlemen
[14:32] jfw: anotheruserback: all your base are belong to us ??
[14:57] anotheruserback: jfw: I don't understand what you are asking
Day changed to 2022-02-17
[08:16] caai17: jfw: Hey, how are you? Question: I assume that I will need to register a different nick for each computer that I use, right?
[15:26] whaack: caai17: normally you would use the same nick on each machine you use.
[16:05] jfw: not to mention sticking around long enough to receive answers!
[16:06] jfw: I believe he's getting set up on another machine today though.
Day changed to 2022-02-19
[19:29] caai17: jfw: hahaha
[19:31] caai17: I will stay connected on this machine until I have the thinkpad set up.
[19:35] caai17: I have been working on getting the thinkpad set up over the last 2 days.
[20:09] caai17: jfw: It looks like all of the orders were delivered yesterday, except the Cache Internal Hard Drives (ST2000LM003). It says that the new expected delivery date in Thursday, February 24. To my understanding, you already have the tracking number, and therefore, are aware of this.
[21:11] jfw: caai17: any particular difficulties with the thinkpad?
[21:14] jfw: caai17: thanks for the update; I heard that at least one of the items had arrived. Both the Fedex and Amazon tracking sites failed to produce any results for me, and on two different machines (while UPS at least recently was working OK), so as far as I'm concerned those are antiquated couriers that don't have tracking service.
[21:14] jfw: so much for the web, nice while it lasted.
[21:18] jfw: caai17: as it happens I'm currently working on assigning handles (usernames) for everyone we've worked or done business with, for whatever present or future purposes; would you like to go with 'caai17' for that?
[21:18] jfw: does the 17 mean something btw?
[21:24] jfw: re http://fixpoint.welshcomputing.com/2022/jwrd-logs-for-Feb-2022/#3185 , it was a 2000's internet "culture" reference, the memory of which you inadvertently triggered; https://knowyourmeme.com/memes/all-your-base-are-belong-to-us
[21:24] sourcerer: 2022-02-16 14:57:11 (#jwrd) anotheruserback: jfw: I don't understand what you are asking
[21:27] jfw: as a multilinguist you'll probably find it amusing enough.
Day changed to 2022-02-20
[17:10] caai: For now, I will use the nick caai, thus dropping the 17
[17:12] caai: In regards to the thinkpad, I will delineate all of the steps that I have taken in order to help you identify where I have gone astray or not gone far enough:
[17:13] caai: Operating as user, under the src directory, I created a child directory named yrc
[17:18] caai: Under said yrc directory, I downloaded yrc_subdir_genesis.vpatch & yrc_linear_scroll_etc.vpatch, along with their accompanying signatures (4 files in total) from fixpoint.welshcomputing.com/2020/yrc-re-genesis-and-patch-for-smooth-scrolling-and-other-fixes/
[17:20] caai: I created the patch directory and moved the patches to said directory
[17:21] caai: I created the .seals directory and moved the signatures to said directory
[17:24] caai: I created a symbolic link to a .wot directory located under the trb directory on my computer
[17:26] caai: In the newly created ~/src/yrc directory, I ran v.pl wot - keys recognized - check
[17:27] caai: I ran v.pl flow - patches properly organized (2 in total) - check
[17:28] caai: I ran v.pl leafs - patch propery shown (1 in total) - check
[17:32] caai: I ran v.pl p yrc_linear_scroll_etc patches/yrc_linear_scroll_etc.vpatch - check
[17:33] caai: I ran find yrc_linear_scroll_etc/ | sort - recursive listing of tree seems satisfactory - check
[17:35] caai: In the home directory ~, I ran mkdir -p ~/.yrc/nets/freenode
[17:37] caai: I ran echo chat.freenode.net > ~/.yrc/nets/freenode/addrs
[17:38] caai: I ran whoami > ~/.yrc/nick
[17:40] caai: In the directory ~/.yrc, I ran yrc and received the following message: ksh: yrc: not found
[17:55] caai: re http://fixpoint.welshcomputing.com/2022/jwrd-logs-for-Feb-2022/#3201, hahaha, gotcha. I am happy that I have helped keep this classic meme alive
[17:55] sourcerer: 2022-02-19 21:27:48 (#jwrd) jfw: as a multilinguist you'll probably find it amusing enough.
[22:12] jfw: caai: thanks for that listing of steps - very clear & tidy.
[22:17] jfw: what you appear to be missing is the installation step so that it can be run from anywhere on the system rather than just the 'press' directory; this is found in the INSTALLATION section at the top of README.txt in the source tree, namely: 'python setup.py install' (which must be run from that same directory)
[22:19] jfw: then you'll perhaps want to review the email I sent about switching from freenode to JWRD's server (and please keep the given IP address in the shadows for now)
[23:36] jfw: indeed as the README notes but I missed here, that install command needs to run as root. however, there's a further hitch when installing on a Gales system (currently stagnating as a FIXME in the py-setuptools gport), that scripts get installed to /gales/pkg/python/bin which isn't on the shell search path.
[23:38] jfw: as a workaround, you can do as root after the install: 'mv /gales/pkg/python/bin/yrc* /local/bin/'
Day changed to 2022-02-21
[04:06] caai: excellent. I have followed the installation step as root in the directory which has said file in it: python2 setup.pty install
[04:08] caai: After that, as root, I moved the file: mv/gales/pkg/python/bin/yrc* /local/bin
[04:10] caai: Apparently, this were the missing steps that needed to be completed because I am sending these messages from the thinkpad
[04:11] caai: these were*
[17:09] jfw: caai: nice, congrats. see you around and soon we can get to the 'bitcoind' troubles that instigated this.
Day changed to 2022-02-22
[14:42] caai: jwrd: Thanks. Sounds good. I am ready to get to the 'bitcoind' troubles whenever you are.
[16:56] jfw: for future reference, I discovered why the log articles aren't showing up in my 'Archives' sidebar section (for better or worse but certainly not by intent): awklogbot isn't setting the post_date_gmt field, while at least the queries that populate that aggregate view require it
[16:56] jfw: existing and nonzero. There's also a post_modified_gmt field and I don't as yet know what for.
[17:03] jfw: a sane schema IMO would have used gmt dates only and MAYBE an optional offset field if the time according to the author's local courthouse at time of publish/edit is really of interest to anyone.
[17:07] jfw: in practice, all date fields on my blog are gmt because my server doesn't concern itself with time zone data.
[17:12] jfw: in other words, my earlier guess was correct.
[17:12] sourcerer: 2021-07-06 20:43:58 (#jwrd) jfw: I have a guess on why the log articles aren't showing up in the archive counts: for some infernal reason wordpress has two different fields for each type of date, one labeled 'gmt', the other who knows what, certainly doesn't show any zone info in the data itself
[17:18] jfw: the finding came from curiosity about a SQL error I spotted in the html from hanbot's blog, originating from the same dubious queries
[17:19] jfw: "[Expression #1 of ORDER BY clause is not in GROUP BY clause and contains nonaggregated column 'hanbot.wp_posts.post_date' which is not functionally dependent on columns in GROUP BY clause; this is incompatible with sql_mode=only_full_group_by]"
[17:26] jfw: this in turn was because I've now implemented the long awaited auto-archiving of links in chan and was sanity-checking the data.
[17:26] sourcerer: 2020-11-18 06:19:12 (#jwrd) jfw: but it's working nicely now and just about where I want it ; the main things I'd like to add before going live are scraping of external links for auto-archiving, and forward/backward threading links for the log articles. Then I'll need a script to back-fill my existing logs through the usual processing. Although, I suppose I could post-date them so that going live isn't dependent on finishing
[17:29] jfw: no frontend for it yet, but all links are now saved - except a couple where the regex didn't "Do What I Meant" with trailing punctuation, and a couple broken ("upgraded" I imagine) servers throwing SSL handshake errors
[17:36] jfw: the full list of such trailing punctuation observed: close-paren, comma, double-quote, and... control-A, from that pesky CTCP ACTION.
[17:50] jfw: from a grep of my firefox history of 196k unique URLs, close-paren and dot are pretty common as final characters e.g. in wikipedia articles, while there's exactly one comma which looks like a mis-paste anyway, one single-quote and no double-quote.
[18:06] jfw: there's a bit more fine print to the above "all links are now saved", I suppose I should have a look at all the failures and document it.
[18:45] jfw: dorion: I've linked to the event files via http://dorion-mode.com/2021/12/event-identity-money-and-banking-in-the-internet-age/#comment-2684 but perhaps you'd like to incorporate direct links into the Presentations section of the page. It'd be the logical place for the would-be yewtube comments to be directed, anyway.
[18:46] jfw: caai: I'll be up for a rundown on the bitcoind issue at 20 UTC / 3pm local
[20:12] jfw: I'll dig out the highlights of prior conversations for the log. It started when caai dusted off his node and tried to get it synced a few weeks ago; at some point the thinkpad crashed, showing a kernel OOPS on null instruction pointer. This of course brought back jfw's recent memories of similar woes on an apu1 which were ultimately circumvented by switching to a thinkpad; so far though it appears
[20:12] jfw: to be a transient event.
[20:14] jfw: Upon reboot, the node restarted seemingly OK and even got blocks for a while, if I'm recalling correctly.
[20:15] jfw: Somewhere in there my latest patches including the crashproofing and cleanup of crash-recovery code.
[20:15] jfw: * were applied.
[20:16] jfw: But some time later it got stuck, not accepting further blocks and showing in 'getinfo' the somewhat familiar error, 'received invalid chain with greater proof-of-work ... displayed transactions may be incorrect'.
[20:20] jfw: At my request, caai restarted it with a -checkblocks=0 flag, to check integrity of all blocks on the current chain since genesis, and let the check run; it completed successfully then resumed its 'wedged' state, casting strong doubt on the hypothesis that some data had got corrupted due to buggy code or flaky RAM or some such.
[20:24] jfw: My next thought was to try a manual-feed of a known-good next block, to rule out problems in the networking code or hostile or misbehaving peers.
[20:25] jfw: caai: what's your current "blocks" count as shown by "getinfo", so that I can extract a series of nearby blocks for this testing?
[22:54] caai: jfw: sorry about the delayed response. I just now saw your message.
[22:55] caai: My current blocks count is 720920
[23:36] jfw: caai: no problem, it wasn't much delay given that we didn't have an appointment set, I was just giving it a try.
[23:44] jfw: caai: I've put the range of blocks 720919-720922 up at http://fixpoint.welshcomputing.com/wp-content/uploads/2022/02/blk720919 and so forth. try downloading them (with wget or links) and feeding them to the node as follows:
[23:46] jfw: "bitcoind eatblock $PWD/blk720919" - the $PWD makes it expand to an absolute path, because otherwise it can get confusing because the path is interpreted relative to where bitcoind was started rather than to the shell you're running eatblock from.
[23:48] jfw: the expected behavior for the blocks you already have is to print 'false' on the terminal and 'ProcessBlock() : already have block ... from peer LOCAL' in the ~/.bitcoin/debug.log
[23:50] jfw: then we'll see what happens on the newer blocks. to reduce the log noise you might need to get something like this running first: tail -f debug.log | egrep 'Block|Chain'
[23:54] jfw: actually the most useful would be the full log output when eating a "bad" block; to capture that you can do 'tail -c 100k ~/.bitcoin/debug.log > snip.log' just afterward. that should produce a light enough result to load up in vim and trim down further or just paste as-is.
[23:57] jfw: for pasting you can use http://paste.deedbot.org/ ; let me know if you need help getting the data to there from the CLI environment.
Day changed to 2022-02-23
[00:04] jfw looks at his own script for the task, has trouble seeing why http requests and url-encoding should be necessary just to dump some bytes in a bin and get back an identifier
[07:28] jfw tests some tweaks to the archiver link recognizer, which is unfortunately somewhat different from the clickable-link formatter: "http://jwrd.net" 'http://jwrd.net' <http://jwrd.net> http://jwrd.net, http://jwrd.net
[07:35] jfw: nice, so although those (except the last one) are discouraged and fail in various ways in the web view, they're now all recognized as the same link by the background archiver.
[07:39] jfw: which I'd say makes for a correct incentive structure actually.
[17:56] jfw: caai: from the server's perspective, your client was present in the channel until 13:32 today (8:32am local). there's even some degree of certainty here, because the server and client regularly 'ping' each other and take action if the response times out. but at that time, the server logged a 'Read error on connection 12 (socket 12): Connection reset by peer!' this error indicates a somewhat
[17:56] jfw: 'unclean' shutdown of the TCP connection; it's hard to say why as yet, but assuming the client machine itself wasn't rebooted, one possibility is a stateful firewall somewhere along the path being rebooted, or otherwise running out of memory and dropping connection states. and unless the ISP is misbehaving pretty badly, that means one of the routers at your place; does that seem possible?
[17:56] jfw: certainly the timing is interesting since it appeared to be fine until you tried using it.
[17:59] jfw: one point of possible confusion is the term 'registered'; on irc that may simply refer to your current network connection (TCP) being associated with your nickname, such that others can't use the same nick while you're connected; this is the sense meant by the errors you were seeing. a more advanced network however will also keep a permanent sort of registration to prevent others from grabbing
[17:59] jfw: your nick while you're away, requiring some kind of authentication be it shared secret (password) or public/private key.
[18:04] jfw: otherwise I gather you'd like to work on these things around 8:30 to 9am; I will plan accordingly. (my schedule's been slipping later again lately so I hesitate to commit right away to morning availability.)
Day changed to 2022-02-24
[14:39] caai: jwrd: Guten morgen
[14:53] caai: Upon writing my second message, I was given an error message. Therefore, I checked if I was able to login via the gentoo machine. It seems to have a more stable connection.
[14:54] caai: I then logged off the gentoo machine, rebooted the thinkpad and now here I am writing these messages. Vamos a ver que sucede
[15:10] caai: From the asus: upon sending the next message via the thinkpad, I received the following error: ERROR: connection to freenode not registered
[15:11] caai: As stated above, I am not writing from the gentoo/asus
[15:13] caai: 1st Step: I decided to list the directory contents of ~/src/bitcoin/patches to verify that I have received the new patchs: 'bitcoin_fsync_all_blocks.vpatch' & 'bitcoin_checkblocks_cleanup.vpatch' - neither are listed
[15:15] caai: As stated above, I am NOW writing from the gentoo/asus
[15:19] caai: Step 2: In regards to downloading the blocks, could you please indicate which directory I should download them to? I assume: '~/src/bitcoin/bitcoin_dumpblock_no_losers/bitcoin/src' ..?
[15:44] jfw: caai: that thinkpad network connection is looking pretty dismal, huh.
[15:46] jfw: caai: good that you noticed those patches were missing; we were proceeding from incorrect assumptions.
[15:48] jfw: the directory for the block files doesn't matter as far as the software is concerned; I wouldn't put them in 'src' because they're not source code. and you can delete them once we're done. so I'd say right in ~ would be fine
[15:54] jfw: caai: I'd like to get the 'checkblocks' part straightened out first though. can you download those new patches & sigs to the necessary location then tell me what's shown by "v.pl leafs" ?
[15:56] jfw: or rather, ensure "bitcoin_checkblocks_cleanup.vpatch" is included in that output then do a press to that one. or if you'd like to be a bit more adventurous you could try out my new script
[16:04] jfw: caai: another thought arises: before going through the fetch/rebuild dance, let's confirm what version is actually in use, e.g. in case it was built from some location different from where you're now looking. do a "bitcoind -help" and see if you see a line for "-checkblocks", toward the bottom.
[16:05] jfw: (if you do, it's the latest already.)
[16:13] jfw: looking again at the "checkblocks" change though, it shouldn't actually make a difference here, i.e. the meaning of '-checkblocks=0' was unchanged. so, please do check the version for clarity's sake but then proceed with the eatblock test.
[16:13] sourcerer: 2022-02-22 23:44:46 (#jwrd) jfw: caai: I've put the range of blocks 720919-720922 up at http://fixpoint.welshcomputing.com/wp-content/uploads/2022/02/blk720919 and so forth. try downloading them (with wget or links) and feeding them to the node as follows:
[17:50] caai: jfw: Shortly after my last message, the day's tasks began to overwhelm me. I will connect again soon to follow your directions.
[18:39] jfw: caai: good luck digging out from those tasks then!
[20:31] jfw: worth rescuing from the usual hatchet brigades of contemporary sound-bite journalism: https://archive.is/oxtBy ( https://www.bloomberg.com/news/articles/2022-02-24/full-transcript-vladimir-putin-s-televised-address-to-russia-on-ukraine-feb-24 )
[22:12] jfw: Just received a batch of "DTECH" USB to TTL serial converters; they're working so far with the pl2303 driver in the Gales kernel but I was alarmed to find they've reversed the color code for send vs. receive from all previous such adapters I'd seen.
[22:29] jfw: makes a good reminder that "approximately the same item" is a risky concept. giving it a burn-in test now, feeding /dev/urandom from TRNG and will check back for usb flaking as was reported with some other models.
[22:30] jfw: "Internal EEPROM with users writable area" ugh why the fuck.
Day changed to 2022-02-25
[14:35] caai: Clocking in. Let the day begin.
[14:53] jfw: good morning caai, are you clear on the next steps?
[14:55] jfw: caai: was that the network dropping out again but from the asus this time?
[14:56] caai: I downloaded 'bitcoin_fsync_all_blocks.vpatch' & 'bitcoin_checkblocks_cleanup.vpatch' and their signatures to ~/src/bitcoin/patches & ~/src/bitcoind/.seals
[14:56] caai: Yes, the networked dropped again but from the asus this time
[14:57] caai: I listed directory content and the patches are present under ~/src/bitcoin/patches
[14:58] jfw: alright, then it seems the thinkpad is off the hook for now. sounds fine re patches, listening...
[14:58] caai: I ran v.pl flow and I do not see the new patches in 'the flow'
[14:59] jfw: a basic question perhaps but are you running it from the proper directory (~/src/bitcoin) ?
[15:00] jfw: I imagine so if there's a "flow" at all.
[15:00] caai: I ran v.pl leafs from ~/src/bitcoin: Leaf: bitcoin_dumpblock_no_losers.vpatch (jfw)
[15:01] caai: Yes, I am running commands from ~/src/bitcoin
[15:02] jfw: odd; I do see a divergence in your message above between src/bitcoin and src/bitcoind but assumed it was just a typo, is that so?
[15:05] jfw: v.pl unfortunately tends to be of very little help in diagnosing problems - part of why we're moving away from it - but we can at least try to cover the basics.
[15:06] caai: Yes, the '~/src/bitcoind/.seals' is really '~/src/bitcoin/.seals'
[15:06] caai: It was a typo
[15:07] jfw: note also this point: http://fixpoint.welshcomputing.com/2022/jwrd-logs-for-Feb-2022/#3288
[15:07] sourcerer: 2022-02-24 16:04:04 (#jwrd) jfw: caai: another thought arises: before going through the fetch/rebuild dance, let's confirm what version is actually in use, e.g. in case it was built from some location different from where you're now looking. do a "bitcoind -help" and see if you see a line for "-checkblocks", toward the bottom.
[15:08] caai: I ran bitcoind -help. There is an option listed near the bottom: -checkblocks=<n>
[15:09] jfw: ah ok then. so dorion was correct in telling me he'd got it rebuilt with the latest patches - but it's probably in some other directory, perhaps ~/trb or something.
[15:10] jfw: in this case we can leave the v.pl flow/leafs problem and continue with the eatblocks test.
[15:11] jfw: o.O quite some network problem
[15:14] caai: I just listed the directory contents of ~/src/trb/patches and the are there
[15:14] caai: and they* are there
[15:14] jfw: aha.
[15:14] caai: Shall I proceed forward with the eatblock test?
[15:14] jfw: please do
[15:19] caai: I keep getting kick out
[15:20] jfw: I see. I'm probably going to have to just come over and trace the cables
[15:21] jfw: a luxury, but one we have at the moment.
[15:21] caai: I ran links fixpoint.welshcomputing/wp-content/uploads/2022/02/blk/720919 | Message received: You don't have permission to access /wp-content/uploads/2022/02/blk/720919 on this server.
[15:22] jfw: whoops, try again now.
[15:22] caai: Yes, a luxury we can't depend on in the future
[15:25] caai: The screen has said making connection for the last 120 seconds
[15:26] jfw: for one thing, the link shown above is missing .com; for another it's "blk720919" without a slash in the middle; for a third that I didn't mention, for "links" you'll want to use the parent directory (i.e. leave out the "blk...") and use "d" to download the files.
[15:28] jfw: hopefully you're using the shell history and not re-typing the whole link each time here.
[15:33] jfw: caai: this network (or lack thereof) is pretty much a blocker now. will you have some time today for me to look?
[15:35] caai: Sorry, I must always follow the path of the turtle in this environment, perhaps all, and make sure I type everything correctly. With that said, I typed everything correctly on the thinkpad. It eventually displayed a lot of code. I quit the page. Now, in order to keep it simple, I will simply run wget with the same argument.
[15:36] jfw: the "making sure" is well and good, perhaps in time it can be separated from the "typing everything".
[15:37] caai: Yes, can you come over, or I go over, before going to Robinson's bday party?
[15:37] jfw: yes, the "pile of ???? instead of downloading" is what prompted the "parent directory and download" point above.
[15:43] jfw: (the final question there was answered out-of-band as the connection failed again.)
Day changed to 2022-02-26
[19:33] jfw: to follow up here, that network problem is resolved. I mapped the topology, inspected connectors, checked one router's uptime and memory load, and was trying to track down credentials for the cable-company-provided modem-router-wap monstrosity when the symptoms presented themselves for direct poking... it was an IP address collision on the statically numbered LAN.
[19:34] jfw: (which explains why the irc connection dropped only when caai was trying to do things)
[19:41] jfw: irc reconnection was also complicated by the fact that my instructions to update the config to point to us instead of dead-freenode were implemented as an append rather than replace so it had to cycle through the list racking up timeouts.
[19:42] jfw: and http://ossasepia.com/2020/06/01/ossasepia-logs-for-jun-2020/#1027337 came up again.
[20:36] jfw: http://fixpoint.welshcomputing.com/2022/jwrd-logs-for-Feb-2022/#3296 << so far so good at 46 hours. I got a suggestion to use nail polish to correct the wire colors... which might even be the practical solution for just this once, since getting something else to the isthmus could take another 2 weeks
[20:36] sourcerer: 2022-02-24 22:29:10 (#jwrd) jfw: makes a good reminder that "approximately the same item" is a risky concept. giving it a burn-in test now, feeding /dev/urandom from TRNG and will check back for usb flaking as was reported with some other models.
[20:37] jfw: I do NOT want to introduce 'autoconfism' into my wiring docs.
[21:12] jfw: another minus for the Dtech: the connector case is harder to pry open to see the board inside. this done, it's indeed a different board from the previous item - for which the distinguishing characteristic known so far is "the unmarked black one".
[21:14] jfw: we might not have a choice about 'autoconfing' it in the end what with all of it having no more identity than 'nondescript sandwich of plastic and solder from china' and the constant shortages & shifting sands at the suppliers
[21:15] jfw: but the plan is to try to find a good one then stock up when I'm back in the states.
Day changed to 2022-02-27
[02:22] caai: http://fixpoint.welshcomputing.com/2022/jwrd-logs-for-Feb-2022/#3340 Yes, which is much appreciated. And, we determined that both computers should run though the secure eth1 port. Of course, I still have much to learn in order to ensure they are indeed run securely.
[02:22] sourcerer: 2022-02-26 19:33:21 (#jwrd) jfw: to follow up here, that network problem is resolved. I mapped the topology, inspected connectors, checked one router's uptime and memory load, and was trying to track down credentials for the cable-company-provided modem-router-wap monstrosity when the symptoms presented themselves for direct poking... it was an IP address collision on the statically numbered LAN.
[02:28] caai: Next task: http://fixpoint.welshcomputing.com/2022/jwrd-logs-for-Feb-2022/#3259 Shall we set up another meeting to ensure this task is completed properly before you head back to the states?
[02:28] sourcerer: 2022-02-22 23:44:46 (#jwrd) jfw: caai: I've put the range of blocks 720919-720922 up at http://fixpoint.welshcomputing.com/wp-content/uploads/2022/02/blk720919 and so forth. try downloading them (with wget or links) and feeding them to the node as follows:
[06:17] jfw: caai: let's try for starters an irc-meeting; would you be free at 3pm / 20 UTC tomorrow?
[15:30] caai: jfw: an irc-meeting at (3 pm) 20 UTC on Feb 28 works for me. See you then.
[15:50] jfw: caai: ah, I meant tomorrow as in the 27th though indeed technically that would have been 'today'.
[15:54] caai: Alright. Today at 20 UTC works. See you then.
[15:54] jfw: cool.
[20:00] caai: Clocking in. Should I use yrc on the thinkpad?
[20:05] jfw: I'm not sure which will be best as yet so I'd say stick with wherever you are now.
[20:05] caai: From the ~ directory, I have run wget on http://fixpoint.welshcomputing.com/wp-content/uploads/2022/02/blk720919 | It appears to have downloaded successfully.
[20:06] caai: Shall I proceed forward with this step? http://fixpoint.welshcomputing.com/2022/jwrd-logs-for-Feb-2022/#3260
[20:06] sourcerer: 2022-02-22 23:46:46 (#jwrd) jfw: "bitcoind eatblock $PWD/blk720919" - the $PWD makes it expand to an absolute path, because otherwise it can get confusing because the path is interpreted relative to where bitcoind was started rather than to the shell you're running eatblock from.
[20:07] jfw: There was a range of blocks to download there, not just one
[20:08] jfw: http://fixpoint.welshcomputing.com/2022/jwrd-logs-for-Feb-2022/#3259
[20:08] sourcerer: 2022-02-22 23:44:46 (#jwrd) jfw: caai: I've put the range of blocks 720919-720922 up at http://fixpoint.welshcomputing.com/wp-content/uploads/2022/02/blk720919 and so forth. try downloading them (with wget or links) and feeding them to the node as follows:
[20:10] jfw: once you have them all then yes, please proceed with eatblock, one at a time
[20:10] caai: Alright. Trying to download the range of blocks now
[20:13] caai: I have downloaded blocks 720919-720922. Starting to run bitcoind eatblock on each one individually now
[20:22] jfw: it should show a 'true' or 'false' for each one; let's hear those results then look closer at the debug log.
[20:25] caai: I have tried a few things and I seem to be missing a step or two. Do I need to be in the .bitcoin directory? Does bitcoind need to be running beforehand?
[20:26] jfw: the node certainly does need to be running.
[20:26] caai: Alright. It is running now
[20:27] jfw: as for directory, it needs to be where the files were downloaded (unless you fully type out the absolute path)
[20:32] caai: From ~ directory, where blks are located, upon running: 'bitcoind eatblock $PWD/blk720919' the following message was received: 'error: {"code":-2,"message":"Safe mode: WARNING: Received invalid chain with greater proof-of-work. Displayed transactions may not be correct! Your database or other nodes may be corrupted."}
[20:33] jfw: lol, of course, "for your own good". we'll need to override that...
[20:34] jfw: kill the node then start it with a -disablesafemode flag
[20:35] jfw: (seems clear to me that 'eatblock' should be on the whitelist for safe mode anyway)
[20:36] caai: bitcoind -disablesafemode running....
[20:39] caai: From ~ directory, upon running: 'bitcoind eatblock $PWD/blk720919' the following message was received: 'error: {"code":-1,"message":"CAutoFile::operator>> : file handle is NULL"}
[20:42] jfw: ugh. that means it failed for some reason to open the file, and won't tell us why because asciilifeforms can't be bothered with pesky details like error checking.
[20:42] jfw: try this basic sanity test: ls -l $PWD/blk720919
[20:43] jfw: you don't need to paste the whole output, just tell me if it shows an existing, readable file as expected or an error.
[20:43] caai: Yes, it show an existing, readable file
[20:45] jfw: thinking...
[20:48] jfw: I can't see any way this makes sense, so grasping at straws. try this one: tail -c 5m ~/.bitcoin/debug.log | less
[20:49] jfw: this loads the last 5 megs of the log which I'm guessing is enough; then search ('slash' key) for eatblock; once found, check the following line
[20:50] jfw: it should say "Attempting to create block #<something> from file <somefile>" ; <somefile> should be /home/<user>/blk720919. check if this is so
[20:51] caai: There are 8 logs, all of which read the same: 'ThreadRPCServer method=eatblock'
[20:53] jfw: possibly you need to continue to the last one where we'd disabled safe mode
[20:54] jfw: the line I'm looking for should follow either immediately or soon after the one you quoted.
[20:55] caai: Running same command now.....
[20:58] caai: Upon searching /eatblock, there is a message that says "Attempthing to create block#720921 from file blk720919"
[20:58] caai: which is the lastest one
[21:00] caai: It looks like the last 3 messages, following the line with eatblock, all read the same: "Attempting to create block#720921 from file blk720919"
[21:01] jfw: interesting. are you *sure* you included the $PWD/ part when you ran eatblock ?
[21:05] caai: Just ran it correctly, with PWD, which I was doing when it was in safe mode, but not upon disabling safe mode
[21:05] caai: It give a simple message: false
[21:06] caai: It gives*
[21:06] jfw: aha.
[21:07] jfw: false means it already has the block, as expected; so now continue with the next ones.
[21:08] caai: all 4 have been done, all giving the same message: 'false'
[21:11] jfw: looking closer at the code I'm not at all sure I trust the comments about the meaning of 'false' anymore. let's do the log paste now so I can see it in full.
[21:12] jfw: do for starters: tail -c 5m ~/.bitcoin/debug.log > debug-snip.log
[21:14] caai: done
[21:14] jfw: this gives us something unchanging to work with. then: sed -n '/blk720920/,$p' debug-snip.log > debug-snip-tail.log
[21:14] jfw: (make sure to get the special characters correct)
[21:16] jfw: then it's http://fixpoint.welshcomputing.com/2022/jwrd-logs-for-Feb-2022/#3264 but I expect you'll need more specific instructions.
[21:16] sourcerer: 2022-02-22 23:57:16 (#jwrd) jfw: for pasting you can use http://paste.deedbot.org/ ; let me know if you need help getting the data to there from the CLI environment.
[21:23] jfw: caai: how's it going?
[21:25] caai: Almost there
[21:30] caai: when I run links paste.deedbot.org/ it says: Host not found
[21:32] jfw: can you tell me why?
[21:34] caai: Perhaps the firewall is blocking it
[21:36] jfw: no, it's because the thinkpad does not use DNS, therefore it doesn't know any hostnames that it hasn't been told about (by you).
[21:37] jfw: so you'll need to get a root shell and edit /etc/hosts
[21:37] jfw: and add the line: 96.43.130.234 paste.deedbot.org
[21:38] jfw: however, "links" still isn't going to be adequate for the task, because AFAIK it doesn't have a way to import the contents of a file to its input fields.
[21:39] jfw: I have a script for this instead: http://fixpoint.welshcomputing.com/code/misc/deedbot-paste.py
[21:40] caai: paste.deedbot.org It has been added
[21:41] caai: I will open the script
[21:41] jfw: good. see if you can download the linked script, sanity-check the code (it's short), install to /local/bin and run. It will paste whatever it reads from standard input.
[21:42] jfw: thus the usage will be (as the regular user again): deedbot-paste.py < debug-snip-tail.log
[21:43] jfw: if it works, it'll display a short URL, which you then post here. I have to go shortly but that should give you enough to chew on for now.
[21:44] caai: alright
Day changed to 2022-02-28
[15:06] caai: Deedbot script has been successfully downloaded
[15:11] dorion: good morning caai, did you give it a spin ? post the link here when you've done so.
[15:15] caai: Good morning jfw, I assume that I must chmod the script? chmod +x /local/bin/deedbot-paste.py
[15:21] caai: debug-snip-tail.log = http://paste.deedbot.org/?id=YSjo
[15:35] jfw: caai: well done (and no need to assume: to run a file as a command it must indeed be executable.)
[15:43] jfw: my read of the log is that indeed it already has all the blocks being tested, recognizing them by hash; which would seem to mean it's accepted them in some provisional way; yet it refuses to fully accept any past 720920 and activate them as the best chain.
[15:44] jfw: I'm most likely going to have to dig into the code; but this at least gives me some specific questions to guide the search.
[15:57] jfw: caai: the clock offset may also be relevant, though I'm not sure how given that these are old blocks. I recall you tried to reset the date & time recently, but looks like it didn't take; perhaps the system was uncleanly shutdown. You can force an update of the battery-backed ("hardware") clock from the "live" clock by running "hwclock -w" (as root, after setting the time).
[16:00] jfw: caai: meanwhile I'd suggest stopping the node because it's just going to be endlessly downloading the same old blocks that it can't use.
[16:03] jfw: caai: you can also clean up by removing the debug-snip*.log now.
[16:04] jfw: let's leave the block files for future testing though.
[16:09] jfw: "Good morning jfw" - heh, I must point out that was dorion you were replying to initially