Day changed to 2021-07-01
[17:16] dorion: whaack, yeah, I read it and probably did. haven't thought of a way to check for this, but don't see how it affects me now that the patch has been applied.
[17:17] dorion: 'gyu kaku' in midtown -- we went and enjoyed !
[19:12] dorion: jfw, how often do you recommend running fstrim on machine running bitcoind ?
[22:52] dorion is packing up and heading back to vt.
Day changed to 2021-07-02
[00:01] jfw: dorion: lately I've been doing it monthly as part of my full node backup process. if I were to script it, I'd probably make it weekly.
[00:01] jfw: could even do daily, I'm not aware of any downsides. it goes faster when run more frequently.
[00:04] jfw: you'd think the filesystem could just do it incrementally whenever space is freed... guess nobody managed to do the work though, too busy rewriting everything in systemd or something.
[02:50] jfw: dorion: re "don't see how it affects me now that the patch has been applied" - possibly you know this but to be clear: it would affect accuracy of the gbw-node database if any of your watched addresses have transactions confirmed in one or the other but not both branches of an affected block. I don't know a way to check, short of writing new code to do it perhaps as part of a rescan.
[02:55] jfw: it does not affect internal accuracy of the rows in the unspent outputs table as used by gbw-signer, just might miss rows that should be there or include ones that shouldn't and would result in an unconfirmable transaction.
[05:51] dorion: jfw thanks for the fstrim insight.
[05:52] dorion: "if any of your watched addresses have transactions confirmed in one or the other but not both branches of an affected block." -- right.
[06:02] dorion: bubbs drove a tesla dual engine model y back through the rain. had to stop twice to recharge (rental contract said he can't let the charge get less than 20% nor higher than 80%). defintely a fast, shiny car with bells and whistles that I'm not interested in myself but he's likely to end up buying. either that or the cyber truck thingy.
[14:01] dorion: whaack, did you decide on how you prefer the fg delivered ? include in package to cr or have jfw deliver to trusted agent in nyc ?
[15:49] jfw: I could see the point of not discharging below 20% - charging stations being scarcer than fuel pumps, and you can't just have a friend or roadside service deliver a gallon in the event you run it dry. Can't see the 80% though - what, the battery can't handle its own reported capacity? Perhaps they're afraid it wears them out faster, though I thought these sorta things were all using Li-ion just
[15:49] jfw: like laptops which is fine to keep at 100%.
[15:50] jfw: dorion: how long did the charging stops take?
[17:46] dorion: yeah, I've not looked into how the batteries work. the stops took about 10 mins. the navigation system had them marked. this one was a 'performance' model, they also have 'long range' (~50 miles longer or so).
[18:02] jfw: hey, just enough time to enjoy some folic acid and hfcs contaminated donuts from the convenience store.
[18:04] jfw: usg.blue, knowing it can't win on its own merits, moves toward further injury of the competition (archived)
[18:54] dorion: jfw, there is a touch screen on the dash that displays all the meters, e.g. speedometer. it doubles as a tv/video game to use while charging..
[19:16] whaack: dorion: I'd rather you just send the FG, I am not 110% sure I'll be in NYC in August and my brother is also traveling upstate for a lot of the summer.
[19:17] whaack: dorion: and awesome i'm glad you enjoyed Gyu Kaku! It's a huge chain in Japan with only a couple of franchises in the states, afaik
[19:17] whaack: i wasn't able to get a table while in Japan
[19:31] dorion: whaack, ok. will do. I aim to have it in the mail by monday.
[19:36] dorion: whaack, according to their website, they've a couple dozen in usia.
[21:07] jfw: dorion: the donuts still sound healthier & more pleasant but to each his own.
Day changed to 2021-07-04
[03:03] jfw: https://www.vortex86.com/ - possibly interesting alternative to dying AMD-based product lines for low powered computing, off the beaten path; seen for example in https://pc104.org/products/pc104board-dx3/ . I'm only just beginning a broader survey of the space.
[03:08] jfw: dunno if this "industrial computer" class has much in the way of coreboot support but at least they won't be killing BIOS for the UEFI morass. MS-DOS compatibility prominently displayed.
[03:10] jfw: also dunno at what point you're better off running a virtual MIPS or something on FPGA but seems like an interesting question.
[03:16] jfw: sad to see that Lattice (of open fpga toolchain fame, if not by their own doing) is based in usa but not manufactured in the americas
[03:30] jfw: xilinx likewise from what I can sniff so far - but TSMC is possibly coming here
[03:35] jfw: and in news I either missed or forgot, AMD moved to buy Xilinx last year for $35bn (probably still in process)
[03:35] jfw: Intel already had Altera.
[04:54] jfw: in weird news from wanna-republics, https://www.breitbart.com/law-and-order/2021/07/03/11-armed-suspects-arrested-following-9-hour-standoff-on-mass-highway/ (archived)
[21:55] whaack: i met some mildly based bitcoiners in seekrit spot in this jungle
[21:59] whaack: by based i mean they were bitcoin maximalists, they signal'd their detestment of shitcoins, called out various "spooks" like gavin. seemed to be heavy into austrian economics and they were scouting to find a place with freedom in the world
[22:00] whaack: the "mild" part comes from their use / indifference to the problem of segwit, their idea that there is such a thing as bitcoin core
[23:06] jfw: they heard of mp or the wot or the forum or any of it?
[23:09] jfw: I guess there is such thing as bitcoin core, but you'd think in their view it'd be considered spookware.
Day changed to 2021-07-05
[00:19] dorion: whaack, sounds like it wasn't a terribly boring conversation, at least. did you ask them if they run nodes or get a gpg key from them ? where were they (how many ?) from ?
[01:00] dorion: i suppose in the end it comes down to what means bitcoin and what they mean by bitcoin maximalism. I think the whole, bitcoin maximalist vs shitcoiner is a too simple/binary/black and white --the topic is more complexly layers. While I've only run a bitcoin node to date, I personally push back when others describe me as a maximalist --to me it's more realist. on the one hand,
[01:00] dorion: the computation scoreboard since for going on a decade by now is hard to argue with, the woes of altcoin, the feasibilty of block chains for anything and everything in
[01:00] dorion: theory and practice ; on the second hand, there's the question of how many years you got until the [https://www.contravex.com/2015/11/29/the-distant-future-of-bitcoin-miner-defection/][distant
[01:00] dorion: future of bitcoin miner defection] and phase transition of what V --there is not we, there is only V-- mean by bitcoin.
[01:15] dorion: the fog of war remains quite thick for me and I'm sure there's a lot I don't see/hear/read, but with MP's passing, Bitcoin is now a much different thing than it's been the whole time I've been learning about it and using it as with him, the prime structure of authority is gone. sure, his coin and text are still "here", but being the
[01:15] dorion: cause, the man was bigger than both those effects.
[02:33] jfw: I'd missed out on that 'how many years you got' - what a neat little argument.
[02:37] dorion: heh, still a lot more trilema to uncover yet.
[15:39] whaack: at least one of them had read trilema and hailed mp as 'argueably the purest bitcoiner'
[15:40] whaack: but given some of the discussion around 'bitcoin 2.0' i guess he had not internalized a lot of his writings lol
[15:54] jfw: ah, one of the 'I read trilema in five days' types perhaps.
Day changed to 2021-07-06
[20:05] jfw: wb sourcerer! I've backfilled the published log from my local one, so the channel is back to public-readable but still joinable by invite only.
[20:43] 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
[21:36] dorion: http://fixpoint.welshcomputing.com/2021/jwrd-logs-for-Jul-2021/#2663 -- cool.
[21:36] sourcerer: 2021-07-06 20:05:14 (#jwrd) jfw: wb sourcerer! I've backfilled the published log from my local one, so the channel is back to public-readable but still joinable by invite only.
[23:23] jfw: the weird double-date fields.
Day changed to 2021-07-07
[15:29] jfw: The apu1 well has run dry; the run on the bank driven apparently not by people who give shit one about clean chips, but by apu2+ customers displaced by that production line's getting starved out in Taiwan.
[15:32] jfw: Last I heard, pcengines is "still on the fence" about building another batch of apu1, and my guess is it won't happen. JWRD has stocked up enough to leave us some runway, but will surely need to find another (most likely inferior) solution.
[15:38] jfw: US distributor SiliconKit still shows "in stock", but I wouldn't be surprised to find this is fake news (and they are most likely pre-assembled, quite possibly *wrongly* pre-assembled systems, not virgin boards as pictured).
[16:02] dorion: jfw, thanks for the update. are you going to write pcengines about another apu1 run and what quantity they need to justify/rationalize ?
[17:57] jfw: dorion: as you know: I already did; they didn't address or even acknowledge that part of the question in the reply; they haven't as yet replied at all to my last correspondence; and even if they build a new batch there "may be a long lead time". I did speak of circling back at some point once actually sold out, and sure, why not, but let's not expect much from it.
[18:31] dorion: jfw, right, slipped my mind they didn't reply to your message from friday.
Day changed to 2021-07-08
[20:51] whaack: So my irc bot hangs on some requests to my block explorer, for example http://logs.bitdash.io/whaacked/2021-06-14#1000180 - i.e. looking at addresses with lots of transaction data associated
[20:52] whaack: My current thought is to put a default limit on all the queries that have unbounded output lengths, and then allow the user to superpass that limit with some sort of optional parameter
Day changed to 2021-07-09
[00:10] jfw: whaack: sounds reasonable; pretty sure all the competition paginates the prolific responses
Day changed to 2021-07-10
[21:50] whaack: I have the sense that all queries should have a parameter (perhaps mandatory) that clarifies as to which block you want the data from.
[21:52] whaack: "How much balance does address N have?" should be "How much balance does address N have as of block number X?"
Day changed to 2021-07-13
[14:39] whaack: dorion: package arriged in FL. They informed me I will need to wait 15-22 days for it to be transported to CR / pass through customs / arrive here
[14:49] dorion: whaack, thanks for the update. is that 2-3 wk delay typical ? items are available for me in panama 3-4 days after hitting my fl p.o. box.
[17:01] whaack: dorion: nope, ridiculously absurd. They said they needed the extra time because it is a 'used' item
[17:10] jfw: whaack: nuts, full import regimen for a single item you could have simply brought carry-on. it did sound from prior descriptions that CR is rather more invasive than Panama in that regard anyway.
[17:12] jfw: re "balance as of block number", perhaps just include it by way of a running total in the listing of transactions affecting an address? sounds annoying if it's made mandatory, seems to me that "as of now" would be the usual case.
Day changed to 2021-07-18
[17:57] whaack: jfw: ok, I was thinking that I want the results of commands to be determinsitic and nonchanging (minus reorgs)
[17:58] whaack: but that may be a bit of overengineering and it may wind up being annoying for any actual use of the explorer
[17:58] whaack: btw do you know of a way to execute a sql command, restricting the command to only READ?
[17:59] whaack: i would like to have an interface available so that any sql query can be sent to trbexplorer
[18:36] jfw: whaack: "deterministic & unchanging" would mean it has to respond correctly to queries about future blocks too; and that you couldn't have a "current block count" query; so it sounds like both an impossible and an unhelpful constraint. But what advantage were you seeing?
[18:39] jfw: don't think I can help you much with SQL sandboxing; sounds pretty hazardous.
[18:40] jfw: I mean, with a full blown RDBMS you could add a separate user with read only grants. Perhaps a unix user with read-only access to the sqlite files? Not sure if or how well that works.
[18:40] whaack: jfw: Heh the unix user idea was what i was about to suggest
[18:41] whaack: that should work as long as sqlite3 doesn't need to write to the db file in order to run a select statement
[18:42] whaack: jfw: But likely it needs to write something in order to get a lock on the db
[18:43] jfw: I recall it uses kernel/filesystem locking facilities; not sure how that interacts with file permissions.
[18:44] jfw: There'd also be a question of preventing escapes from the target database, e.g. is there some query that can create / write to arbitrary files, to fill up the disk or squirrel away data or whatever other games
[18:45] jfw: most generally you'd want to look at the whole query parser & interpreter since you're making that your attack surface.
[18:47] whaack: yeah...then this sounds like not something i'm going to get myslef involved in
[18:48] whaack: myself*
[18:49] whaack: i can post the sql schema and if someone wants to run a custom query they can either index the db themselves or their query can go through my human filter
[18:49] jfw: though I suppose having someone take a good look at sqlite wouldn't be the worst thing anyway.
[18:53] jfw: for my part I'm still looking through a car manual and the top level of the ircd-ratbox tree - which they might as well have called ratsnest if first impressions carry
Day changed to 2021-07-20
[21:15] whaack: http://ztkfg.com/2021/07/warning-bitcoins-stored-in-segwit-addresses-are-not-safe/
[21:16] whaack: ^ manual feedbot
[21:38] jfw winces again about not having a proper one
[21:39] jfw: I had made some good progress on one, too. back before a month from hell, the end of the world, and other such adventures.
Day changed to 2021-07-21
[12:53] dorion: whaack, I think you need to prepend http:// to the trinque.org
[14:50] whaack: dorion: thx, will do
Day changed to 2021-07-23
[15:44] dorion: hey whaack, would you be interested in making a bitcoind vpatch for decoderawtransaction ?
[15:48] whaack: dorion: yes, i would be interested, but i think there is some prerequisite work required, such as going through some cplusplus book or the like
[15:51] whaack: do you have some sort of spec as to what decoderawtransaction should output?
[15:53] dorion: cool. jfw may have a c++ book recommendation. decoderawtransaction exists in prb, but let me get back to you on the spec.
[15:54] dorion: the prb version includes a bunch of their cruft too, naturally.
[15:55] whaack: also, why do you think this should exist as a vpatch for trb rather than as part of an external program?
[16:33] dorion: whaack, I suppose it could exist as a patch on, e.g. gbw-node or gbw-signer. the use case I'm thinking of is you sign with gbw-signer, which as mp pointed out, it does on faith, and you want to verify what you signed is the transaction you actually wanted.
[16:38] dorion: there's other cases where one might want to decode a raw txn, but I'd say the highest priority is for the ones you yourself sign.
[16:42] whaack: dorion: so the signer signs on faith, in the sense that it doesn't keep a store of utxos, however the offline signer should be able to see the final output of what it signed
[16:45] whaack: so to me it makes sense for the patch to be on gbw-signer
[16:50] dorion: whaack, yeah. jfw, what to you think ? (he might be afk this afternoon).
[18:47] jfw: I recall a "SAMS Teach Yourself C++ in 21 Days" from back in the day, probably good for someone starting from zero. Cline & Lomow's canonical "C++ FAQ" is helpful as a sort of mental lubricant, learning to think like a cpp fanboy.
[18:48] jfw: dorion, are you after decoding arbitrary raw transactions with whatever nonsense, or just standard p2pkh ones?
[18:49] jfw: if the latter, gbw-node already has the code for it.
[18:50] dorion: jfw, p2pkh ones first and foremost.
[18:50] jfw: note that if you're looking for "how much money does this tx spend", decoding alone can't answer that because it depends on the referenced inputs which could come from the full blockchain.
[18:51] jfw: (so gbw-node would be in a better position to implement that as well.)
[19:09] dorion: jfw, ah, ok. so it'd be adding a command to gbw-node that uses its extant code to decode the raw tx and calculate the sums of the outputs. (sorry if this is a bit muddled, thinking it through via conversation)
[19:15] jfw: the output sizes are directly present in the raw transaction; the fee however is implicit based on sum(outputs)-sum(inputs). gbw-node would at least be in a position to fetch arbitrary (confirmed) inputs via bitcoind getrawtransaction.
[19:15] jfw: still kinda guessing at what you're actually looking for based on past conversations.
[19:17] jfw: (and yes, it's dumb that it works this way.)
[19:17] jfw: whaack: comment in moderation.
[20:17] whaack: jfw: published
[20:21] whaack: jfw: re first byte being 0x00 in p2pkh addresses, perhaps i am quite confused
[20:22] whaack: i am likely mixing up terms as I am using term address to denote the data found in the "scriptPubKey" part of outputs
[20:31] jfw: whaack: that'd do it; the standard form scriptPubKey does include the address as a datum pushed to the stack, among other opcodes
[20:34] jfw: the 0x76a914 (which disassembles to [dup] [hash160] [push the following 20 bytes]) doesn't go into the base58 encoding.
[20:36] whaack: jfw: gotcha, ty for the clarification, i'll be careful to get those terms right going forward
[20:37] jfw: np, glad it's sorted.
[20:38] whaack: and ty for the link to the logs where you describe that addresses that start with a "3" that are "multsig" addresses are also trivially spent outputs for traditional bitcoin clients
[20:39] whaack: perhaps you are right in saying that this is by design, i.e. the social engineering operation specifically coined the term anyonecanspend to segwit to make a false contrast between segwit and multsig
[20:40] jfw: who knows; I suppose my angle is more about not importing the enemy's spurious terminology.
[20:41] whaack: it is a good angle
[20:47] whaack previously thought that "multsig" (i.e. nosig) was unsupported by trb however i also thought it was NOT trivially spendable. I held in suspicion that *perhaps* "multisig" was ~== segwit, and jfw has now confirmed that suspicion.
[20:49] jfw: there *is* a kind of multisig present since the early days, just that you have to send coins to a custom script rather than a standard form represented by a base58 address. gavin added p2sh aka 3-addresses supposedly to make it easier to implement in practice.
[20:50] jfw: then apparently luke-jr later thought he had invented this idea of soft fork by anyonecanspend.
[20:51] jfw: did you manage to answer your old question of how much coin is held under such conditions? I imagine you have all the tools now to get real numbers
[20:56] jfw: perhaps just add up all the unspent outputs NOT in standard p2pkh form, then look at further categorizing the pile if interested.
[20:57] whaack: jfw: no, i haven't conjured the sql query yet, although if heathen reports can be trusted there is about 3-6 million coins up for grabs
[20:57] jfw: iirc the early mining & transacting was in an even simpler 'pay to pubkey' form, possibly the "satoshi pile" is still there.
[20:57] whaack: but what the hell, i'll write the query now
[20:58] whaack: jfw: you do recall correctly, block 728 has the first p2pkh txn
[21:01] whaack: jfw: so do i understand this correctly: gavin's p2sh scheme is trivially spendable per trb, but there's also this more-complicated-to-implement actual multsig?
[21:05] jfw: yep, OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY exist in trb, just no UI knobs and it won't accept them as standard for relay, iirc.
[21:12] jfw: https://www.blockchain.com/btc/tx/5e1dbe340f7cf7047fc82298d35edf8677b72074d7c1c371ca8b60c173e3f533 - random recent example txn containing both a p2sh and I suppose segwit output. The scriptpubkey (which they've renamed 'Pkscript') shows the disassembly - the gavinist p2sh form is OP_HASH160 [20 byte hash160 of the actual intended script] OP_EQUAL
[21:14] jfw: trb doesn't unpack and re-execute that hashed script; to satisfy such a condition, you only need the hash input, which the "owner" graciously provides when they try to spend from it.
[21:15] jfw: the OP_0 on the segwit one looks like a red herring; idk why they used that particular form, but essentially that's a script that always evaluates to true, no hash input even necessary.
[21:17] whaack: jfw: got it. so in order to snag the coins in the first output the trb miner needs to wait for the "owner" to broadcast the value x for h(x) = ... , whereas for the second one the coins are available to be snagged right away
[21:18] jfw: looks like.
[21:20] jfw: actually looks like the distinction here is sipa's blegh32 versus traditional p2sh addresses, rather than segwit per se.
[21:21] jfw: (that's bech32 , for teh search keywordz.)
[21:24] jfw: (and that's sipa the death row inmate)
[21:30] jfw pauses to appreciate the "will recieve payment" language as opposed to "I will pay" or something that would conceivably expire on the signer's death
[21:33] whaack: lulz
Day changed to 2021-07-24
[18:07] whaack: There are 2,065,269 bitcoins in UTXOs where the scriptPubKey has a leading "0" byte.
[18:11] whaack: this was as of block ~692400
[18:13] whaack: This seems to confirm the validity of the data presented on https://txstats.com
[18:24] whaack: I should note here that the current prototype of blockexplorer my confused notion that addresses==scriptPubKeys is apparent, as the "address" value for address stores the scriptPubKey and not just the "address"
[19:04] jfw: it lends credence to the pictures painted there at least, as I'm not seeing anything that'd qualify as "data" presented.
[19:05] jfw: you going to look at any more transaction types?
[19:05] jfw: *output types
[19:26] whaack: jfw: yup, i'm going to do similar queries to find out how many more coins are stored in trivially spendable outputs
[19:28] whaack: maybe I should draw up a plan for some sort of 'systematic wandering' instead of tunnel visioning on this one idea
[19:28] whaack: there's likely other interesting pieces of information that exist that i don't know i should be looking for
[19:46] whaack: jfw: I realize I may want to sharpen my SQL chops before going forward, do you have any tutorial recommendation ? (ty for the c++ link, btw)
[22:58] jfw: heh, if there's a way for an approach to be simultaneously systematic and wandering I'm sure I don't know what it is. but maybe something like, setting yourself up to maximize the returns from wandering
[23:01] jfw: it's sorta why I suggested counting first the negative space, all outputs NOT of a known "good" form, then looking closer at what's in that pile.
[23:08] jfw: what seems to be missing in your grasp of SQL (or the underlying concepts)? I don't have any tutorials per se coming to mind. possibly the manuals of the various systems if you're looking for specific things. E.F. Codd 1970 is the seminal paper of the relational databases field. or possibly the more 'LAMP web development' oriented tutorials will be easier to find and will surely touch on it.
[23:11] jfw: there was also an intro databases video course on youtube, from Jennifer Widom of Stanford, that I found decent at filling in the theoretical gaps in my practice-driven knowledge.\
[23:16] jfw: (I hadn't managed to squeeze a proper databases course into my undergrad years.)
Day changed to 2021-07-25
[16:01] whaack: jfw: i was trying to figure out how to optimize my sql queries that contained a couple of joins
Day changed to 2021-07-28
[18:06] jfw: whaack: the 'explain' statement & variants can be helpful for understanding sql query performance
[18:12] jfw: The local rag today reports what looks to me like a major flip-flop: the trendy gene therapy oft mislabeled as 'vaccine' doesn't suppress the flourishing of contagious levels of SARS-CoV population but merely the expression of symptoms, according to usg.
[18:14] jfw: I'm expecting a renewed wave of masks and all the other mandates and lockdowns at least in the usg subdivisions that previously succumbed.
[18:16] jfw: (which at first approximation was 40/50 states.)
[18:24] jfw: I'm also seeing reports - I don't know how credible - that deaths attributable to the experimental therapy (which still lacks FDA approval, having been rushed to emergency authorization under the Trump administration) are estimated to number in the five figures, i.e. comparable to the worst of the seasonal flu epidemics in recorded memory.
Day changed to 2021-07-29
[16:13] whaack: jfw: Does 'FDA approval' for a drug hold weight for you?
[16:14] whaack thinks of https://thelastpsychiatrist.com/2007/07/the_most_important_article_on.html
[18:15] jfw: whaack: not necessarily, but supposedly it does for them.
[19:03] jfw: whaack: I enjoyed the article, but what connection do you make?
[19:08] jfw: "That's the semiotic conundrum, why psychiatry is politics: the truth is demanded only when it supports a preset ideology." - perhaps that's the true weight that FDA approval holds for "them": only when it agrees with existing belief or desire.
[19:09] jfw: I confess, even after looking up semiotics, to still not knowing what the hell he's talking about though.
[19:15] whaack: jfw: He makes a good argument that a drug's *function* changes based on its dosage. Not just the strength. However the FDA labels the function of the drug based on its molecular make up alone.
[19:17] whaack: So instead of "Drug A == antidepresent" there should be "Drug A with dosage 100-150mg is an antidepresent for those weighing 60-80kg, at 200-250mg it is an antidepresant and antihistamine for the same weight"
[19:19] whaack: And that the FDA doesn't do this perhaps is enough to discredit their entire process of drug approval.
[19:19] whaack has not looked into this beyond this article, but has enough distrust of the usg and its beauracratic crap to believe tlp on first pass.
[19:23] jfw: my read wasn't that he was trashing fda labelling altogether but rather naive interpretations of it. maybe we're to infer something stronger from the snark level.
[19:25] jfw: there's no way they'd be able to spell out the exact conditions like that; there's too many unknowns.
[19:26] jfw: that is, effects will be different for different people even controlling for dosage, weight, bmi or whatever.
[19:31] whaack: ;The drug can't be called an antipsychotic unless it is behaving as an antipsychotic, regardless of the product labeling.
[19:31] whaack: ARE YOU SAYING THE FDA ARE A BUNCH OF UNSCIENTIFIC ASS-MONKEYS?
[19:31] whaack: What?;
[19:33] jfw: "'what?' ain't no country I ever heard of. they speak english in 'what'?"
[19:33] whaack: s/;/"
[19:33] whaack: aha
[19:35] jfw: being labeled for use as an antipsychotic means piles of clinical research were submitted & supposedly reviewed demonstrating that it has antipsychotic effects at least in some cases.
[19:36] jfw: reading more into it than that is the reader's mistake.
[19:42] whaack: jfw: that makes sense, especially considering your point about there being too many unknowns
[17:16] dorion: whaack, yeah, I read it and probably did. haven't thought of a way to check for this, but don't see how it affects me now that the patch has been applied.
[17:17] dorion: 'gyu kaku' in midtown -- we went and enjoyed !
[19:12] dorion: jfw, how often do you recommend running fstrim on machine running bitcoind ?
[22:52] dorion is packing up and heading back to vt.
Day changed to 2021-07-02
[00:01] jfw: dorion: lately I've been doing it monthly as part of my full node backup process. if I were to script it, I'd probably make it weekly.
[00:01] jfw: could even do daily, I'm not aware of any downsides. it goes faster when run more frequently.
[00:04] jfw: you'd think the filesystem could just do it incrementally whenever space is freed... guess nobody managed to do the work though, too busy rewriting everything in systemd or something.
[02:50] jfw: dorion: re "don't see how it affects me now that the patch has been applied" - possibly you know this but to be clear: it would affect accuracy of the gbw-node database if any of your watched addresses have transactions confirmed in one or the other but not both branches of an affected block. I don't know a way to check, short of writing new code to do it perhaps as part of a rescan.
[02:55] jfw: it does not affect internal accuracy of the rows in the unspent outputs table as used by gbw-signer, just might miss rows that should be there or include ones that shouldn't and would result in an unconfirmable transaction.
[05:51] dorion: jfw thanks for the fstrim insight.
[05:52] dorion: "if any of your watched addresses have transactions confirmed in one or the other but not both branches of an affected block." -- right.
[06:02] dorion: bubbs drove a tesla dual engine model y back through the rain. had to stop twice to recharge (rental contract said he can't let the charge get less than 20% nor higher than 80%). defintely a fast, shiny car with bells and whistles that I'm not interested in myself but he's likely to end up buying. either that or the cyber truck thingy.
[14:01] dorion: whaack, did you decide on how you prefer the fg delivered ? include in package to cr or have jfw deliver to trusted agent in nyc ?
[15:49] jfw: I could see the point of not discharging below 20% - charging stations being scarcer than fuel pumps, and you can't just have a friend or roadside service deliver a gallon in the event you run it dry. Can't see the 80% though - what, the battery can't handle its own reported capacity? Perhaps they're afraid it wears them out faster, though I thought these sorta things were all using Li-ion just
[15:49] jfw: like laptops which is fine to keep at 100%.
[15:50] jfw: dorion: how long did the charging stops take?
[17:46] dorion: yeah, I've not looked into how the batteries work. the stops took about 10 mins. the navigation system had them marked. this one was a 'performance' model, they also have 'long range' (~50 miles longer or so).
[18:02] jfw: hey, just enough time to enjoy some folic acid and hfcs contaminated donuts from the convenience store.
[18:04] jfw: usg.blue, knowing it can't win on its own merits, moves toward further injury of the competition (archived)
[18:54] dorion: jfw, there is a touch screen on the dash that displays all the meters, e.g. speedometer. it doubles as a tv/video game to use while charging..
[19:16] whaack: dorion: I'd rather you just send the FG, I am not 110% sure I'll be in NYC in August and my brother is also traveling upstate for a lot of the summer.
[19:17] whaack: dorion: and awesome i'm glad you enjoyed Gyu Kaku! It's a huge chain in Japan with only a couple of franchises in the states, afaik
[19:17] whaack: i wasn't able to get a table while in Japan
[19:31] dorion: whaack, ok. will do. I aim to have it in the mail by monday.
[19:36] dorion: whaack, according to their website, they've a couple dozen in usia.
[21:07] jfw: dorion: the donuts still sound healthier & more pleasant but to each his own.
Day changed to 2021-07-04
[03:03] jfw: https://www.vortex86.com/ - possibly interesting alternative to dying AMD-based product lines for low powered computing, off the beaten path; seen for example in https://pc104.org/products/pc104board-dx3/ . I'm only just beginning a broader survey of the space.
[03:08] jfw: dunno if this "industrial computer" class has much in the way of coreboot support but at least they won't be killing BIOS for the UEFI morass. MS-DOS compatibility prominently displayed.
[03:10] jfw: also dunno at what point you're better off running a virtual MIPS or something on FPGA but seems like an interesting question.
[03:16] jfw: sad to see that Lattice (of open fpga toolchain fame, if not by their own doing) is based in usa but not manufactured in the americas
[03:30] jfw: xilinx likewise from what I can sniff so far - but TSMC is possibly coming here
[03:35] jfw: and in news I either missed or forgot, AMD moved to buy Xilinx last year for $35bn (probably still in process)
[03:35] jfw: Intel already had Altera.
[04:54] jfw: in weird news from wanna-republics, https://www.breitbart.com/law-and-order/2021/07/03/11-armed-suspects-arrested-following-9-hour-standoff-on-mass-highway/ (archived)
[21:55] whaack: i met some mildly based bitcoiners in seekrit spot in this jungle
[21:59] whaack: by based i mean they were bitcoin maximalists, they signal'd their detestment of shitcoins, called out various "spooks" like gavin. seemed to be heavy into austrian economics and they were scouting to find a place with freedom in the world
[22:00] whaack: the "mild" part comes from their use / indifference to the problem of segwit, their idea that there is such a thing as bitcoin core
[23:06] jfw: they heard of mp or the wot or the forum or any of it?
[23:09] jfw: I guess there is such thing as bitcoin core, but you'd think in their view it'd be considered spookware.
Day changed to 2021-07-05
[00:19] dorion: whaack, sounds like it wasn't a terribly boring conversation, at least. did you ask them if they run nodes or get a gpg key from them ? where were they (how many ?) from ?
[01:00] dorion: i suppose in the end it comes down to what means bitcoin and what they mean by bitcoin maximalism. I think the whole, bitcoin maximalist vs shitcoiner is a too simple/binary/black and white --the topic is more complexly layers. While I've only run a bitcoin node to date, I personally push back when others describe me as a maximalist --to me it's more realist. on the one hand,
[01:00] dorion: the computation scoreboard since for going on a decade by now is hard to argue with, the woes of altcoin, the feasibilty of block chains for anything and everything in
[01:00] dorion: theory and practice ; on the second hand, there's the question of how many years you got until the [https://www.contravex.com/2015/11/29/the-distant-future-of-bitcoin-miner-defection/][distant
[01:00] dorion: future of bitcoin miner defection] and phase transition of what V --there is not we, there is only V-- mean by bitcoin.
[01:15] dorion: the fog of war remains quite thick for me and I'm sure there's a lot I don't see/hear/read, but with MP's passing, Bitcoin is now a much different thing than it's been the whole time I've been learning about it and using it as with him, the prime structure of authority is gone. sure, his coin and text are still "here", but being the
[01:15] dorion: cause, the man was bigger than both those effects.
[02:33] jfw: I'd missed out on that 'how many years you got' - what a neat little argument.
[02:37] dorion: heh, still a lot more trilema to uncover yet.
[15:39] whaack: at least one of them had read trilema and hailed mp as 'argueably the purest bitcoiner'
[15:40] whaack: but given some of the discussion around 'bitcoin 2.0' i guess he had not internalized a lot of his writings lol
[15:54] jfw: ah, one of the 'I read trilema in five days' types perhaps.
Day changed to 2021-07-06
[20:05] jfw: wb sourcerer! I've backfilled the published log from my local one, so the channel is back to public-readable but still joinable by invite only.
[20:43] 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
[21:36] dorion: http://fixpoint.welshcomputing.com/2021/jwrd-logs-for-Jul-2021/#2663 -- cool.
[21:36] sourcerer: 2021-07-06 20:05:14 (#jwrd) jfw: wb sourcerer! I've backfilled the published log from my local one, so the channel is back to public-readable but still joinable by invite only.
[23:23] jfw: the weird double-date fields.
Day changed to 2021-07-07
[15:29] jfw: The apu1 well has run dry; the run on the bank driven apparently not by people who give shit one about clean chips, but by apu2+ customers displaced by that production line's getting starved out in Taiwan.
[15:32] jfw: Last I heard, pcengines is "still on the fence" about building another batch of apu1, and my guess is it won't happen. JWRD has stocked up enough to leave us some runway, but will surely need to find another (most likely inferior) solution.
[15:38] jfw: US distributor SiliconKit still shows "in stock", but I wouldn't be surprised to find this is fake news (and they are most likely pre-assembled, quite possibly *wrongly* pre-assembled systems, not virgin boards as pictured).
[16:02] dorion: jfw, thanks for the update. are you going to write pcengines about another apu1 run and what quantity they need to justify/rationalize ?
[17:57] jfw: dorion: as you know: I already did; they didn't address or even acknowledge that part of the question in the reply; they haven't as yet replied at all to my last correspondence; and even if they build a new batch there "may be a long lead time". I did speak of circling back at some point once actually sold out, and sure, why not, but let's not expect much from it.
[18:31] dorion: jfw, right, slipped my mind they didn't reply to your message from friday.
Day changed to 2021-07-08
[20:51] whaack: So my irc bot hangs on some requests to my block explorer, for example http://logs.bitdash.io/whaacked/2021-06-14#1000180 - i.e. looking at addresses with lots of transaction data associated
[20:52] whaack: My current thought is to put a default limit on all the queries that have unbounded output lengths, and then allow the user to superpass that limit with some sort of optional parameter
Day changed to 2021-07-09
[00:10] jfw: whaack: sounds reasonable; pretty sure all the competition paginates the prolific responses
Day changed to 2021-07-10
[21:50] whaack: I have the sense that all queries should have a parameter (perhaps mandatory) that clarifies as to which block you want the data from.
[21:52] whaack: "How much balance does address N have?" should be "How much balance does address N have as of block number X?"
Day changed to 2021-07-13
[14:39] whaack: dorion: package arriged in FL. They informed me I will need to wait 15-22 days for it to be transported to CR / pass through customs / arrive here
[14:49] dorion: whaack, thanks for the update. is that 2-3 wk delay typical ? items are available for me in panama 3-4 days after hitting my fl p.o. box.
[17:01] whaack: dorion: nope, ridiculously absurd. They said they needed the extra time because it is a 'used' item
[17:10] jfw: whaack: nuts, full import regimen for a single item you could have simply brought carry-on. it did sound from prior descriptions that CR is rather more invasive than Panama in that regard anyway.
[17:12] jfw: re "balance as of block number", perhaps just include it by way of a running total in the listing of transactions affecting an address? sounds annoying if it's made mandatory, seems to me that "as of now" would be the usual case.
Day changed to 2021-07-18
[17:57] whaack: jfw: ok, I was thinking that I want the results of commands to be determinsitic and nonchanging (minus reorgs)
[17:58] whaack: but that may be a bit of overengineering and it may wind up being annoying for any actual use of the explorer
[17:58] whaack: btw do you know of a way to execute a sql command, restricting the command to only READ?
[17:59] whaack: i would like to have an interface available so that any sql query can be sent to trbexplorer
[18:36] jfw: whaack: "deterministic & unchanging" would mean it has to respond correctly to queries about future blocks too; and that you couldn't have a "current block count" query; so it sounds like both an impossible and an unhelpful constraint. But what advantage were you seeing?
[18:39] jfw: don't think I can help you much with SQL sandboxing; sounds pretty hazardous.
[18:40] jfw: I mean, with a full blown RDBMS you could add a separate user with read only grants. Perhaps a unix user with read-only access to the sqlite files? Not sure if or how well that works.
[18:40] whaack: jfw: Heh the unix user idea was what i was about to suggest
[18:41] whaack: that should work as long as sqlite3 doesn't need to write to the db file in order to run a select statement
[18:42] whaack: jfw: But likely it needs to write something in order to get a lock on the db
[18:43] jfw: I recall it uses kernel/filesystem locking facilities; not sure how that interacts with file permissions.
[18:44] jfw: There'd also be a question of preventing escapes from the target database, e.g. is there some query that can create / write to arbitrary files, to fill up the disk or squirrel away data or whatever other games
[18:45] jfw: most generally you'd want to look at the whole query parser & interpreter since you're making that your attack surface.
[18:47] whaack: yeah...then this sounds like not something i'm going to get myslef involved in
[18:48] whaack: myself*
[18:49] whaack: i can post the sql schema and if someone wants to run a custom query they can either index the db themselves or their query can go through my human filter
[18:49] jfw: though I suppose having someone take a good look at sqlite wouldn't be the worst thing anyway.
[18:53] jfw: for my part I'm still looking through a car manual and the top level of the ircd-ratbox tree - which they might as well have called ratsnest if first impressions carry
Day changed to 2021-07-20
[21:15] whaack: http://ztkfg.com/2021/07/warning-bitcoins-stored-in-segwit-addresses-are-not-safe/
[21:16] whaack: ^ manual feedbot
[21:38] jfw winces again about not having a proper one
[21:39] jfw: I had made some good progress on one, too. back before a month from hell, the end of the world, and other such adventures.
Day changed to 2021-07-21
[12:53] dorion: whaack, I think you need to prepend http:// to the trinque.org
[14:50] whaack: dorion: thx, will do
Day changed to 2021-07-23
[15:44] dorion: hey whaack, would you be interested in making a bitcoind vpatch for decoderawtransaction ?
[15:48] whaack: dorion: yes, i would be interested, but i think there is some prerequisite work required, such as going through some cplusplus book or the like
[15:51] whaack: do you have some sort of spec as to what decoderawtransaction should output?
[15:53] dorion: cool. jfw may have a c++ book recommendation. decoderawtransaction exists in prb, but let me get back to you on the spec.
[15:54] dorion: the prb version includes a bunch of their cruft too, naturally.
[15:55] whaack: also, why do you think this should exist as a vpatch for trb rather than as part of an external program?
[16:33] dorion: whaack, I suppose it could exist as a patch on, e.g. gbw-node or gbw-signer. the use case I'm thinking of is you sign with gbw-signer, which as mp pointed out, it does on faith, and you want to verify what you signed is the transaction you actually wanted.
[16:38] dorion: there's other cases where one might want to decode a raw txn, but I'd say the highest priority is for the ones you yourself sign.
[16:42] whaack: dorion: so the signer signs on faith, in the sense that it doesn't keep a store of utxos, however the offline signer should be able to see the final output of what it signed
[16:45] whaack: so to me it makes sense for the patch to be on gbw-signer
[16:50] dorion: whaack, yeah. jfw, what to you think ? (he might be afk this afternoon).
[18:47] jfw: I recall a "SAMS Teach Yourself C++ in 21 Days" from back in the day, probably good for someone starting from zero. Cline & Lomow's canonical "C++ FAQ" is helpful as a sort of mental lubricant, learning to think like a cpp fanboy.
[18:48] jfw: dorion, are you after decoding arbitrary raw transactions with whatever nonsense, or just standard p2pkh ones?
[18:49] jfw: if the latter, gbw-node already has the code for it.
[18:50] dorion: jfw, p2pkh ones first and foremost.
[18:50] jfw: note that if you're looking for "how much money does this tx spend", decoding alone can't answer that because it depends on the referenced inputs which could come from the full blockchain.
[18:51] jfw: (so gbw-node would be in a better position to implement that as well.)
[19:09] dorion: jfw, ah, ok. so it'd be adding a command to gbw-node that uses its extant code to decode the raw tx and calculate the sums of the outputs. (sorry if this is a bit muddled, thinking it through via conversation)
[19:15] jfw: the output sizes are directly present in the raw transaction; the fee however is implicit based on sum(outputs)-sum(inputs). gbw-node would at least be in a position to fetch arbitrary (confirmed) inputs via bitcoind getrawtransaction.
[19:15] jfw: still kinda guessing at what you're actually looking for based on past conversations.
[19:17] jfw: (and yes, it's dumb that it works this way.)
[19:17] jfw: whaack: comment in moderation.
[20:17] whaack: jfw: published
[20:21] whaack: jfw: re first byte being 0x00 in p2pkh addresses, perhaps i am quite confused
[20:22] whaack: i am likely mixing up terms as I am using term address to denote the data found in the "scriptPubKey" part of outputs
[20:31] jfw: whaack: that'd do it; the standard form scriptPubKey does include the address as a datum pushed to the stack, among other opcodes
[20:34] jfw: the 0x76a914 (which disassembles to [dup] [hash160] [push the following 20 bytes]) doesn't go into the base58 encoding.
[20:36] whaack: jfw: gotcha, ty for the clarification, i'll be careful to get those terms right going forward
[20:37] jfw: np, glad it's sorted.
[20:38] whaack: and ty for the link to the logs where you describe that addresses that start with a "3" that are "multsig" addresses are also trivially spent outputs for traditional bitcoin clients
[20:39] whaack: perhaps you are right in saying that this is by design, i.e. the social engineering operation specifically coined the term anyonecanspend to segwit to make a false contrast between segwit and multsig
[20:40] jfw: who knows; I suppose my angle is more about not importing the enemy's spurious terminology.
[20:41] whaack: it is a good angle
[20:47] whaack previously thought that "multsig" (i.e. nosig) was unsupported by trb however i also thought it was NOT trivially spendable. I held in suspicion that *perhaps* "multisig" was ~== segwit, and jfw has now confirmed that suspicion.
[20:49] jfw: there *is* a kind of multisig present since the early days, just that you have to send coins to a custom script rather than a standard form represented by a base58 address. gavin added p2sh aka 3-addresses supposedly to make it easier to implement in practice.
[20:50] jfw: then apparently luke-jr later thought he had invented this idea of soft fork by anyonecanspend.
[20:51] jfw: did you manage to answer your old question of how much coin is held under such conditions? I imagine you have all the tools now to get real numbers
[20:56] jfw: perhaps just add up all the unspent outputs NOT in standard p2pkh form, then look at further categorizing the pile if interested.
[20:57] whaack: jfw: no, i haven't conjured the sql query yet, although if heathen reports can be trusted there is about 3-6 million coins up for grabs
[20:57] jfw: iirc the early mining & transacting was in an even simpler 'pay to pubkey' form, possibly the "satoshi pile" is still there.
[20:57] whaack: but what the hell, i'll write the query now
[20:58] whaack: jfw: you do recall correctly, block 728 has the first p2pkh txn
[21:01] whaack: jfw: so do i understand this correctly: gavin's p2sh scheme is trivially spendable per trb, but there's also this more-complicated-to-implement actual multsig?
[21:05] jfw: yep, OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY exist in trb, just no UI knobs and it won't accept them as standard for relay, iirc.
[21:12] jfw: https://www.blockchain.com/btc/tx/5e1dbe340f7cf7047fc82298d35edf8677b72074d7c1c371ca8b60c173e3f533 - random recent example txn containing both a p2sh and I suppose segwit output. The scriptpubkey (which they've renamed 'Pkscript') shows the disassembly - the gavinist p2sh form is OP_HASH160 [20 byte hash160 of the actual intended script] OP_EQUAL
[21:14] jfw: trb doesn't unpack and re-execute that hashed script; to satisfy such a condition, you only need the hash input, which the "owner" graciously provides when they try to spend from it.
[21:15] jfw: the OP_0 on the segwit one looks like a red herring; idk why they used that particular form, but essentially that's a script that always evaluates to true, no hash input even necessary.
[21:17] whaack: jfw: got it. so in order to snag the coins in the first output the trb miner needs to wait for the "owner" to broadcast the value x for h(x) = ... , whereas for the second one the coins are available to be snagged right away
[21:18] jfw: looks like.
[21:20] jfw: actually looks like the distinction here is sipa's blegh32 versus traditional p2sh addresses, rather than segwit per se.
[21:21] jfw: (that's bech32 , for teh search keywordz.)
[21:24] jfw: (and that's sipa the death row inmate)
[21:30] jfw pauses to appreciate the "will recieve payment" language as opposed to "I will pay" or something that would conceivably expire on the signer's death
[21:33] whaack: lulz
Day changed to 2021-07-24
[18:07] whaack: There are 2,065,269 bitcoins in UTXOs where the scriptPubKey has a leading "0" byte.
[18:11] whaack: this was as of block ~692400
[18:13] whaack: This seems to confirm the validity of the data presented on https://txstats.com
[18:24] whaack: I should note here that the current prototype of blockexplorer my confused notion that addresses==scriptPubKeys is apparent, as the "address" value for address stores the scriptPubKey and not just the "address"
[19:04] jfw: it lends credence to the pictures painted there at least, as I'm not seeing anything that'd qualify as "data" presented.
[19:05] jfw: you going to look at any more transaction types?
[19:05] jfw: *output types
[19:26] whaack: jfw: yup, i'm going to do similar queries to find out how many more coins are stored in trivially spendable outputs
[19:28] whaack: maybe I should draw up a plan for some sort of 'systematic wandering' instead of tunnel visioning on this one idea
[19:28] whaack: there's likely other interesting pieces of information that exist that i don't know i should be looking for
[19:46] whaack: jfw: I realize I may want to sharpen my SQL chops before going forward, do you have any tutorial recommendation ? (ty for the c++ link, btw)
[22:58] jfw: heh, if there's a way for an approach to be simultaneously systematic and wandering I'm sure I don't know what it is. but maybe something like, setting yourself up to maximize the returns from wandering
[23:01] jfw: it's sorta why I suggested counting first the negative space, all outputs NOT of a known "good" form, then looking closer at what's in that pile.
[23:08] jfw: what seems to be missing in your grasp of SQL (or the underlying concepts)? I don't have any tutorials per se coming to mind. possibly the manuals of the various systems if you're looking for specific things. E.F. Codd 1970 is the seminal paper of the relational databases field. or possibly the more 'LAMP web development' oriented tutorials will be easier to find and will surely touch on it.
[23:11] jfw: there was also an intro databases video course on youtube, from Jennifer Widom of Stanford, that I found decent at filling in the theoretical gaps in my practice-driven knowledge.\
[23:16] jfw: (I hadn't managed to squeeze a proper databases course into my undergrad years.)
Day changed to 2021-07-25
[16:01] whaack: jfw: i was trying to figure out how to optimize my sql queries that contained a couple of joins
Day changed to 2021-07-28
[18:06] jfw: whaack: the 'explain' statement & variants can be helpful for understanding sql query performance
[18:12] jfw: The local rag today reports what looks to me like a major flip-flop: the trendy gene therapy oft mislabeled as 'vaccine' doesn't suppress the flourishing of contagious levels of SARS-CoV population but merely the expression of symptoms, according to usg.
[18:14] jfw: I'm expecting a renewed wave of masks and all the other mandates and lockdowns at least in the usg subdivisions that previously succumbed.
[18:16] jfw: (which at first approximation was 40/50 states.)
[18:24] jfw: I'm also seeing reports - I don't know how credible - that deaths attributable to the experimental therapy (which still lacks FDA approval, having been rushed to emergency authorization under the Trump administration) are estimated to number in the five figures, i.e. comparable to the worst of the seasonal flu epidemics in recorded memory.
Day changed to 2021-07-29
[16:13] whaack: jfw: Does 'FDA approval' for a drug hold weight for you?
[16:14] whaack thinks of https://thelastpsychiatrist.com/2007/07/the_most_important_article_on.html
[18:15] jfw: whaack: not necessarily, but supposedly it does for them.
[19:03] jfw: whaack: I enjoyed the article, but what connection do you make?
[19:08] jfw: "That's the semiotic conundrum, why psychiatry is politics: the truth is demanded only when it supports a preset ideology." - perhaps that's the true weight that FDA approval holds for "them": only when it agrees with existing belief or desire.
[19:09] jfw: I confess, even after looking up semiotics, to still not knowing what the hell he's talking about though.
[19:15] whaack: jfw: He makes a good argument that a drug's *function* changes based on its dosage. Not just the strength. However the FDA labels the function of the drug based on its molecular make up alone.
[19:17] whaack: So instead of "Drug A == antidepresent" there should be "Drug A with dosage 100-150mg is an antidepresent for those weighing 60-80kg, at 200-250mg it is an antidepresant and antihistamine for the same weight"
[19:19] whaack: And that the FDA doesn't do this perhaps is enough to discredit their entire process of drug approval.
[19:19] whaack has not looked into this beyond this article, but has enough distrust of the usg and its beauracratic crap to believe tlp on first pass.
[19:23] jfw: my read wasn't that he was trashing fda labelling altogether but rather naive interpretations of it. maybe we're to infer something stronger from the snark level.
[19:25] jfw: there's no way they'd be able to spell out the exact conditions like that; there's too many unknowns.
[19:26] jfw: that is, effects will be different for different people even controlling for dosage, weight, bmi or whatever.
[19:31] whaack: ;The drug can't be called an antipsychotic unless it is behaving as an antipsychotic, regardless of the product labeling.
[19:31] whaack: ARE YOU SAYING THE FDA ARE A BUNCH OF UNSCIENTIFIC ASS-MONKEYS?
[19:31] whaack: What?;
[19:33] jfw: "'what?' ain't no country I ever heard of. they speak english in 'what'?"
[19:33] whaack: s/;/"
[19:33] whaack: aha
[19:35] jfw: being labeled for use as an antipsychotic means piles of clinical research were submitted & supposedly reviewed demonstrating that it has antipsychotic effects at least in some cases.
[19:36] jfw: reading more into it than that is the reader's mistake.
[19:42] whaack: jfw: that makes sense, especially considering your point about there being too many unknowns