whaack: nah, haven't done bodysurfing/surfing nude
whaack: and i went to the shorebreak and just let the barrels break over me, so i got a lot of great views, but not barreled + escaped
vex: who's going to complain?
vex: I've swum in huge
vex: chest just barely glancing actoss the rocks
whaack: vex: do you surf much?
whaack: not so many people know about the hand plane unless they're into the psort, afaik
vex: nah Imma kook.
vex: i like a quiet spot
vex: check the dolphin
scoopbot: New article on A Syndication of Verisimilitudes: Art of Latin Noun Declensions
vex: dfaq
verisimilitude: http://logs.nosuchlabs.com/log/asciilifeform/2022-02-11#1078919 I've not posted on 4chan's /g/ in over half a decade, and I'd rather maintain my streak.
dulapbot: Logged on 2022-02-11 23:13:05 shinohai: http://logs.nosuchlabs.com/log/asciilifeform/2022-02-11#1078907 <<< Just post it to /g/ kek
verisimilitude: Besides, it was a hellhole back then, and even worse now.
vex: what's g?
verisimilitude: http://logs.nosuchlabs.com/log/asciilifeform/2022-02-12#1078983 I'm referring to my language speaking and thinking skills.
dulapbot: Logged on 2022-02-12 08:25:51 adlai: http://logs.nosuchlabs.com/log/asciilifeform/2022-02-11#1078848 << are you referring to Elision, and related ideas?
vex: 8chan had afailover aftter mp bought adpace
verisimilitude: I've ``cold emailed'' others, crtdaydreams, but it rarely amounts to anything.
vex: hotwheels told me I was the weirdest thing he's ver seen
vex: you're a head in a wheelchair
verisimilitude: Yes.
vex: anyway 8 can beacame something elks
verisimilitude: It's dead.
vex: lister sisterchans wnet squirelling for winter
vex: 2chan is the original?
vex: so nippon
verisimilitude: Sure.
vex: im the reason moot hates aussies
verisimilitude: Stop asking stupid questions, vex.
vex: how old are you verisimilitude?
verisimilitude: That's private.
vex: you're lucky. my older pets will hold u down
vex: I don't expext ny complaints
verisimilitude: Okay.
vex: not happening.
vex: they say it is
vex: you're gonna be outta sight for a little while. hold the fuck on
verisimilitude: I suppose vex is like a father figure to me, owing to the nightly inebriation.
vex: nah. just a bullshit artist
verisimilitude: Oh, I'd misread ``im the reason moot hates aussies'' as a question.
verisimilitude: Comment on my latest art, vex.
vex: I did look. can't rememeber
verisimilitude: Look again; there's no cost.
vex scrolls up
vex: i learded some latin in channel th other day
verisimilitude: Tell me more.
vex: ammend mistakes
verisimilitude: Yes, I was there.
vex: New to me
vex: I only use english
verisimilitude: Yes, how nice it is to learn.
vex: I appreciate the insights
vex: seen BingoBoingo ?
whaack: morning all
whaack: !e view-height
trbexplorer: block_height: 723282
trbexplorer: mins_since_last_block: 10
asciilifeform: $ticker btc usd
busybot: Current BTC price in USD: $42603.28
asciilifeform: !w poll
watchglass: Polling 14 nodes...
watchglass: 205.134.172.4:8333 : (172-4.core.ai.net) Alive: (0.021s) V=70001 (/therealbitcoin.org:0.7.0.1/) Jumpers=0x1 (TRB-Compat.) Blocks=723287
watchglass: 205.134.172.6:8333 : (172-6.core.ai.net) Alive: (0.091s) V=99999 (/therealbitcoin.org:0.9.99.99/) Jumpers=0x1 (TRB-Compat.) Return Addr=0.0.0.0:8333 Blocks=723287
watchglass: 205.134.172.27:8333 : Alive: (0.094s) V=99999 (/therealbitcoin.org:0.9.99.99/) Jumpers=0x1 (TRB-Compat.) Blocks=723287 (Operator: asciilifeform)
watchglass: 54.39.156.171:8333 : (ns562940.ip-54-39-156.net) Alive: (0.172s) V=99999 (/therealbitcoin.org:0.9.99.99/) Jumpers=0x1 (TRB-Compat.) Blocks=723287
watchglass: 71.191.220.241:8333 : (pool-71-191-220-241.washdc.fios.verizon.net) Alive: (0.154s) V=99999 (/therealbitcoin.org:0.9.99.99/) Jumpers=0x1 (TRB-Compat.) Blocks=723287 (Operator: asciilifeform)
watchglass: 205.134.172.28:8333 : Alive: (0.144s) V=99999 (/therealbitcoin.org:0.9.99.99/) Jumpers=0x1 (TRB-Compat.) Return Addr=0.0.0.0:8333 Blocks=723287 (Operator: whaack)
watchglass: 208.94.240.42:8333 : Alive: (0.203s) V=99999 (/therealbitcoin.org:0.9.99.99/) Jumpers=0x1 (TRB-Compat.) Blocks=723287
watchglass: 54.38.94.63:8333 : (ns3140226.ip-54-38-94.eu) Alive: (0.258s) V=88888 (/therealbitcoin.org:0.8.88.88/) Jumpers=0x1 (TRB-Compat.) Blocks=723287
watchglass: 82.79.58.192:8333 : (static-82-79-58-192.rdsnet.ro) Alive: (0.328s) V=99999 (/therealbitcoin.org:0.9.99.99/) Jumpers=0x1 (TRB-Compat.) Blocks=723287
watchglass: 103.36.92.112:8333 : (terebe.ns01.net) Alive: (0.524s) V=99999 (/therealbitcoin.org:0.9.99.99/) Jumpers=0x1 (TRB-Compat.) Blocks=723287
watchglass: 75.106.222.93:8333 : Alive: (0.408s) V=99999 (/therealbitcoin.org:0.9.99.99/) Jumpers=0x1 (TRB-Compat.) Blocks=723287
watchglass: 94.176.238.102:8333 : Violated BTC Protocol: Bad header length!
watchglass: 205.134.172.26:8333 : Busy? (No answer in 100 sec.)
watchglass: 143.202.160.10:8333 : Busy? (No answer in 100 sec.)
billymg: whaack: sitting down with your explorer now, is sqlite3 version > 3.7 a hard requirement? i have 3.35 installed currently
whaack: billymg: that may work
whaack: billymg: But I recall I ran into some issue with the sql version... digging through logs to see what it was
whaack: and ty for doing this right after I published, I appreciate it
billymg: ok i'll try it out then before upgrading, will let you know if i run into any issues with the 3.35 version
whaack: billymg: okay, and if you at some point decide to run the webserver on a gentoo box this will be handy http://ztkfg.com/2021/07/a-short-guide-for-setting-up-apache-with-flask-on-gentoo/
billymg: oh hey, i must have missed that guide, good to know it's there
billymg: the logotron and crawler both run on flask atop apache so unfortunately i'm already familiar with it
whaack: billymg: i had also forgot that i wrote that guide myself until recently lol
whaack: billymg: http://logs.nosuchlabs.com/log/ossasepia/2020-07-11#1027742 some comments re the sqlite3 version, supported version is 3.7.12. But 3.35 looks like it is a way higher version
dulapbot: (ossasepia) 2020-07-11 jfw: whaack: found the fix in http://archive.is/dDtit which looks to have quietly slipped into 3.7.12. Previously my documented minimum requirement was 3.7.0, which I now see the centos6 rpm doesn't meet. Expect transactional throughput to very much suck due to lack of WAL journal mode (or sacrifice crash consistency).
whaack: the decimal versioning system is quite silly, 3.35 > 3.7
billymg: whaack: ah, lol
billymg: that's right, many softs do this
whaack: yeah it trips me up every time
billymg: whaack: in this step: `sqlite3 ~/.gbw/db </package/gbw-node/library/schema-node.sql`, is '/package/gbw-node/library/schema-node.sql' something i'd have if i had GBW installed already?
whaack: billymg: Ah, that is an error in the readme
whaack: it's in library/schema-node.sql
whaack: that's a legacy line from the original README
billymg: got it
whaack: and i kept the directory name "~/.gbw" mostly because i didn't want to alter my directory names on my machines, but it is a legacy of the code being originally for Gales Bitcoin Wallet
whaack: billymg: Did you get the scanning to begin ?
billymg: whaack: went and made myself some coffee first actually :D, but just tried now and got this error: http://paste.deedbot.org/?id=obxU
billymg: modified those two lines (37,38) to point to the paths i have, got a bit further and then hit this: http://paste.deedbot.org/?id=wEtc
whaack: billymg: You need to set the environ variable GBW_HOME, for ex. in ~/bash_rc add the line "export GBW_HOME='/home/billymg'" and then run `source ~/.bash_rc`
whaack: billymg: ah that is a real bug, one second
billymg: this is my desktop and i threw an extra ssd in after the fact, so i have my trb blockchain in the default home location, on the first ssd, and initialized the explorer db on the second ssd
whaack: kk that shouldn't be a problem
billymg: but it means GBW_HOME prefix would have to be different for those two lines, no?
billymg: that's why i just hardcoded the paths for now
billymg: i could do a symlink thing too i guess
whaack: the second bug you're seeing is a simple edge case error caused because when we scan we check to make sure that prev_hash of the block were scanning matches the hash of the prior block
billymg: personally i'd like to have those as startup flags that you can pass to the proggy
whaack: but i didn't test this from block 0, and we're indexing into block - 1
billymg: ah, classic lol
whaack: billymg: this should fix it http://paste.deedbot.org/?id=Chyw
billymg: whaack: that fixed it!
whaack: the if height == 0, return true are the two lines you need to add. I will post a vpatch , but maybe add those lines yourself and try again
billymg: seems to be scanning now
whaack: awesome!
whaack: you can try running python trbexplorer.py view-block 0
billymg: what do you think about having the datadirs as flags?
billymg: one prefix assumes trb chain and explorer db are in the same parent directory
whaack: billymg: ah i see, yeah and this case of having them in different directories will be pretty common given the sizes of the dbs
billymg: that view-block command worked fine too, neat!
whaack: well i think environment variables are okay, i don't think it makes sense to pass them to the proggy everytime you run it, and you can always set environ variables in the same line that you start the program if you want to
whaack: but i agree there should be separate variables for the location of the .bitcoin directory and for the location of your trbexplorer db
billymg: yeah, no strong opinion on flag vs env variable
whaack: billymg: every 50 blocks or so there should be a print out of the prediction on how long the sync is going to take, how long does yours say?
whaack: (it's going to underestimate by a lot, but curious to see what it reads)
billymg: "Processing blocks for 3.34939098358 seconds at 14.928087 blocks_per_second per the last 50 blocks, there are 707849blocks remaining, estimated time to completion is 0.0 days, 13.0 hours, 10.0 minutes, and 17.2611667442 seconds."
whaack: ah, if only
billymg: ah, yeah, the estimate jumps around (i think i saw you talking about this in the logs)
billymg: saw one go by for 2 days and change, and the next a day and change
billymg: now 5 days...
whaack: well the scanning is much more steady than trb, but it starts to slow down as the index of txs and addresses gets large
asciilifeform: whaack: left comment on your www, seems to be in spam queue
billymg: whaack: pretty fuckin' cool though
whaack: asciilifeform: approved
asciilifeform: whaack: ty
whaack: billymg: Yup, the best part is you can go into the db via the sqlite3 command line tool and start running your own arbitrary queries
billymg: whaack: do you know if the scanning is CPU bound? i noticed you're using python's threading instead of multiprocessing, iirc the latter lets you use multiple OS threads
billymg: my crawler uses threading only because the only bottleneck there was network io (waiting for node responses), so a single python thread is more than enough
whaack: billymg: I do not know, to be honest, and the threading and setup of the sqlite3 db were written by jfw
asciilifeform: pretty simple algo, will restate ftr: add cmdline flag '-cement=path_to_cement_file'. file is a (signed by producer, verified by noad operator) list of blox #s and corresponding hashes
dulapbot: (therealbitcoin) 2020-08-30 asciilifeform: http://logs.nosuchlabs.com/log/therealbitcoin/2020-08-30#1001100 << imho 'cement' would be useful if implemented compactly; then could feed a node <100MB signed list of hashes and it'll download correct blox through N from the net. but indeed 'less mutilation is best' imho when comes to trb; and if thinking about it, ANY trb node that aint synced to ~current height, will in fact refuse to relay most tx (and will be mostly busy
asciilifeform: when requesting next block, if current height < max_cement_height , then request specifically next hash from cement.
whaack: asciilifeform: there are two things going on here, trb's sync from the outer world, and trbexplorer's sync from the local trb
billymg: whaack: ah, perhaps worth taking a look at python's multiprocessing then. i've never used it myself but when i was looking at it seemed to have a very similar API to 'threading'
asciilifeform: whaack: speaking of trb sync per se
whaack: asciilifeform: maybe that's a project i'm willing to take on next
asciilifeform: whaack: imho is a++ project
asciilifeform: asciilifeform's cement maker. note, is buggy, i.e. needs whaack's 'dumpblock' patch to actually produce correct output, as it happens
whaack: billymg: You will also need the dumpblock patch for your trb or you will experience problems scanning
whaack: billymg: if you don't have the dumpblock patch then at some point you're going to request a block from trb and you're going to get back some orphan, and then the scanner is going to get stuck in a loop of adding the orphan and then deleting it back and fourth as it tries to reorg from a detected hash mismatch
asciilifeform: the hygienic way to use 'cement' of course would be, in order of preference, 1) cement from 1 of yer existing noades 2) cement from several of yer l1 folx who agree on 1..n (as they oughta) and all signed
whaack: asciilifeform: I can use my trbexplorer to sign a 2 column file of (block number, hashes) in the near future
asciilifeform: whaack: imho automated signers are a dodgy proposition and at any rate not really needed.
asciilifeform: if folx post up-to-date cement ~yearly, will more than suffice for quick (wks, rather than months) sync
whaack: asciilifeform: I wasn't implying that the signing would be automatic
asciilifeform: certainly would be useful if it could return cement for 0..n, for specified n
asciilifeform: signing/verifying best left to operators' hands tho.
asciilifeform: worth noting that what the prb people do is already equivalent to a (braindamaged implementation of) 'cement', where they request headers 1st, but do so from arbitrary rando automatically, rather than from source specified by operator
asciilifeform: is the only reason prb 'syncs quickly'
whaack: right, but as much as we shit on prb, they actually find solutions to problems (even though they ignore principles)
asciilifeform: this was their 'solution' to 'sync faster!111'
asciilifeform: moar generally, their 'solution' largely consists of 'lusers dun bother to operate noad, keep coin in gox' etc
whaack: i'm not defending them as much as noting that we fail at producing basic stuff, and then constantly have to rely on their tools (like wallets and blockexplorers)
whaack: but looks like if you're right about how much of a speedup the cement code your mentioning will produce, then all the heavy lifting of finding a good solution is done, and the implementation should not be too much of a job
asciilifeform: whaack: can only speak for self, but asciilifeform not relying on prb wallets. as for block exploders, they are useful but imho a luxury, i.e. not actually necessary for handling own tx, but largely for 'voyeurism' of others
asciilifeform very much in favour of trb-powered exploder & whaack's experiment. but must point out the obv. fact that while seeing tx you didn't generate yerself is often interesting , you wouldn't want to rely on a 3rdparty exploder to see whether you've been paid
whaack: asciilifeform: that's the point of open sourcing it, so you can have your own local explorer, to facilitate any resarch you wanna do (via sql queries) and to allow yourself to look up any address without inadvertly doxxing yourself
asciilifeform: aha
asciilifeform: ( see also re logical conclusion )
dulapbot: Logged on 2022-01-30 14:23:19 asciilifeform: http://logs.nosuchlabs.com/log/asciilifeform/2022-01-30#1077257 << imho the correct place for a block exploder is ultimately a pseudoserver within trb noad per se, locally
whaack: the public facing apis are for outreach, or easy access when you wanna know something that is not privacy sensitive while away from terminal
asciilifeform: right
asciilifeform: imho trb oughta use a db that's accessible from other process on same box. would then be trivial to query arbitrary addr balances, dissect blox, etc
whaack: billymg: Btw, regarding multithreading, from my experience in my performance-optimization MIT course I took, multithreading is the last step, it adds massive headaches of complexity, and your maximum gain is capped by the number of cores you have.
asciilifeform: whaack: funnily enuff, trb in fact suffers from all of these headaches, w/out any of the win. but you already knew this.
whaack: heh, i know it from reading the logs, but i'm quite unfamiliar with the trb source itself
asciilifeform: whaack: there's a buncha threads, but also locks haphazardly littered around errywhere, so in effect only 1 is able to run at a given time
billymg: whaack: makes sense. like i said my crawler was network i/o bound when single-threaded, adding threading allowed it to send out pings and process results from 100s of nodes simultaneously (whatever you set the max_sockets knob to in the crawler's config)
billymg: i only suggested it because i noticed your code was already using threading (so it already has some of the multithreading complexity added/handled)
billymg: though admit did not read enough to see how you were using it
billymg: and also do not know how direct the translation is from the 'threading' library to the 'multiprocessing' library, probably not 4free in terms of complexity, but idk
scoopbot: New article on whaack: Podcast Episode 02 - The USDdb and Bitcoin's Speculative Attack
shinohai: >tfw one of the girls announces above podcast to me, and pronounces whaack like it rhymes with "quake". xD
whaack: aha, technically it's pronounced walk, since my last name haack is pronounced like hawk, but i usually read it in my own head as whack
whaack: off for today, i wanted to make a note here that mpwp's comment form should state that a valid email is not required for commenting
verisimilitude: I've improved my latest article a tad.
verisimilitude: http://logs.nosuchlabs.com/log/asciilifeform/2022-02-14#1079368 I don't really pay attention to the mathematical proof of that or whatever but, unsurprisingly, have also read that when the von Neumann architecture be abandoned, such as by using systolic arrays, all of a sudden it's found that ``lol, that no longer applies''.
dulapbot: Logged on 2022-02-14 13:45:16 whaack: billymg: Btw, regarding multithreading, from my experience in my performance-optimization MIT course I took, multithreading is the last step, it adds massive headaches of complexity, and your maximum gain is capped by the number of cores you have.
verisimilitude: One should always be careful to notice just what axioms a mathematical proof is based upon.
verisimilitude: The ``lying with statistics'' is a special case of ``lying with mathematics''.
verisimilitude: I was referring to `Amdahl's law'', in particular.