Fixpoint

Day changed to 2025-10-02
[16:29] jfw: !e view-height
[16:29] btcexplorer: block_height: 915529
[16:29] btcexplorer: mins_since_last_block: 18007
[16:30] jfw: !E view-height
[19:12] jfw: !e view-height
[19:12] btcexplorer: block_height: 915529
[19:12] btcexplorer: mins_since_last_block: 18170
Day changed to 2025-10-10
[15:12] jfw: http://jfxpt.com/2025/a-thorny-memory-leak-in-bitcoind-and-a-way-forward/
Day changed to 2025-10-11
[01:25] lru: jfw: I'm glad you got to the bottom of it
[01:26] lru: are you in any way concerned with the new version 30 coming out from bitcoin core?
[01:27] lru: from what I understand, that version will allow large graphic images to be embedded in the blockchain
[04:57] jfw: lru: what's the supposed harm to come from that?
[11:04] lru: people are worried that harmful actors will upload child porn somehow into the permanent blockchain, putting all nodes and bitcoin itself at risk of legal attack... so far, the size limits have been too small for that kind of nonsense, but the new OP_RETURN thing allows for image-sized attachments, from what I hear... I've been following the warnings on youtube by Matthew Kratter who has been sounding the alarm
[11:04] lru: and encouraging people to switch to Bitcoin Knots (a fork) instead of Core
[13:39] dorion: lru, is it in the blockchain proper or 'witness data' they keep in a separate db segregated from teh blockchain ?
[13:41] jfw: sounds like recycled worries too, the CP bogeyman is so 2000's, and I recall hearing it's supposedly in the blockchain like 10y ago
[13:44] dorion: lru, ftr, in our reference implementation, OP_RETURN shows up 3 times in the sauce, but it's essentially deactivated. the power rangers made the 80 byte thing in 0.9 or so, iirc.
[13:48] jfw: for sure people should stop listening to the corecoin scum, but switching to a renaming of the same thing by one of the same people is hardly a solution.
[13:59] jfw: from the history books, http://trilema.com/2013/and-gavin-moves-on-to-the-dark-side-the-bitcoin-project-is-officially-hijacked/
[17:54] dorion: http://jfxpt.com/2025/jwrd-logs-for-Oct-2025/#14989 -- http://jfxpt.com/2025/a-thorny-memory-leak-in-bitcoind-and-a-way-forward/#comment-3342
[17:54] sourcerer: 2025-10-10 15:12:52 (#jwrd) jfw: http://jfxpt.com/2025/a-thorny-memory-leak-in-bitcoind-and-a-way-forward/
Day changed to 2025-10-12
[17:03] lru: dorion: as I understand it, it is data on the blockchain itself, up to the maximum size of a standard transaction
[17:04] lru: https://learnmeabitcoin.com/technical/script/return/
[17:05] lru: See Histry, Bitcoin v30.0 (October 2025) - "Limit removed"
Day changed to 2025-10-13
[12:05] dorion: it was introduced in v0.9, how do they cause nodes older than that to store it if it essentially doesn't exist according to the pre-v0.9 nodes ?
[13:06] lru: dorion: that I don't know, but OP_RETURN exists in the code from jfxpt.com, it appears to just ignore whatever is in the area
[13:07] lru: hmmmm, actually it returns false.... let me check what that means
[13:12] lru: appears to mean that any block with an OP_RETURN in it causes VerifySignature() to fail, which I assume is pretty serious... but does your blockchain truly have no OP_RETURNs in it at all? how can that be?
[14:39] lru: oh.... other nodes may accept them into the blockchain, and once in the blockchain, <0.9 nodes would also download them, right?
[15:06] jfw: yeah, 'return' was among the original 'script' opcodes (satoshi was going for the programmable money / smart contracts thing, but disabled most of it early on because it was a giant DoS magnet)
[15:09] jfw: the thing added later on was that if an output script always returns false then the value in it can never be spent, and so can be pruned from the unspent outputs database. which itself was a later addition aimed at allowing "nodes" to throw away all the old block data.
[15:11] jfw: so they started allowing op_return scripts into the mempool for embedding small data, and now apparently larger data too, based on the scam that it "won't cost disk space".
[15:13] lru: does a node running < 0.9 software accept large data in OP_RETURN?
[15:13] lru: I mean, once it's been placed into the blockchain
[15:13] lru: by some other >=30.0 version
[15:14] jfw: yes, the "standard transaction" filters are only for what's accepted to mempool; if someone else mines it then it's all valid in a block, no individual choice there since that would create forks.
[15:15] lru: earlier you mentioned the "CP bogeyman"... is that not a concern in this case? or am I misunderstanding your meaning?
[15:16] lru: I've heard that the max size is now around 100k
[15:26] jfw: "No results found for site:trilema.com child porn" - yeah right, useless search engine is useless, it was definitely talked about at least once...
[15:28] jfw: like "think of the children" generally, it's mostly just a cudgel used to shut down debate / opposition to whatever expansion of power
[15:30] lru: distributed software systems can suffer from lack of participation though, because of such risks... for example, I'd probably run a Tor node if I was sure that it wouldn't be used for nefarious purposes, but since I can't guarantee that, I don't need that kind of risk
[15:30] jfw: but it's particularly preposterous now that ~anyone over age 12 with functioning sex organs probably has probably had nude selfies in a Device and thus the Cloud, nevermind where they sent 'em, at least once. still child porn, to the slammer with ye!
[15:32] lru: off to jail with Jeff Bezos for hosting nefarious stuff in the cloud
[15:32] jfw: and the thing with CP was that "ok we'll take it down if you ask through the proper channels" wasn't even a defense, mere possession was all.
[15:34] jfw: just a pretext for the kangaroo court to do what it's there to do anyway
[15:35] lru: sure, but why introduce features that invite such trouble in the first place? which is why I'm glad there is at least some backlash via Bitcoin Knots
[15:38] jfw: they'll just as easily say they found child porn encoded in the mucus on your covid swab. you gonna argue with the science?? and docusign says you authorized it too!
[15:38] jfw: anyway, I'm not arguing for op_return or anything now
[15:48] jfw: the objection is to the idea that the american pulpit lobby gets any say in the affairs of bitcoin.
[15:51] dorion: lru, i think it's perhaps useful that luke-jr's efforts woke up some folks to the shitshow that is the rotten core, but only inasmuch as they also realize it's luke-jr's subversive progressivism that created a bunch of other problems. the correct approach is to reject both herds of derps.
[15:52] lru: dorion: how do you reject both herds if their crap still makes it into your blockchain?
[16:22] jfw: I'm having trouble seeing how the blockchain is 'yours'. your computer, your software, sure. like you can have your own bible to scribble in as you please, but that doesn't do anything to god. bitcoin is a social system in which the proof of work is infallible; if it's mined, it's definitionally not crap. you can always pick another god i.e. go on a hard fork, which may or may not prosper.
[16:23] jfw: you reject the herds first of all by not using their stuff.
[16:24] jfw: second I suppose by not spending your time looking for the meaning in their mooing.
[17:02] lru: perhaps you live in a country that doesn't use such pretexts to shutdown an external monetary threat, and you can easily afford storing the entire blockchain on your servers and serving up all blocks, whether they include cp or not; or perhaps you are one of those who live in a semi-free western country and managed to never take a covid test and never wore a covid mask (I can claim this too) and you don't care
[17:02] lru: what legal consequences may come to you for running a bitcoin node (I cannot claim this)... so for me, this is a problem that still needs a solution, while for you perhaps it is just another opportunity to strengthen your willpower
[17:34] jfw: hm, if whatever government wanted to & could shut down bitcoin that way, why haven't they done it already ?
[17:34] jfw: you can already store arbitrary data just fine, op_return just makes it "easier" supposedly
[17:36] lru: of what size can this arbitrary data be?
[17:37] jfw: up to the 1mb block size, minus encoding overhead, or even larger if it doesn't absolutely have to be sequential
[17:38] jfw: the address you send coins to is just a hex string
[17:38] jfw: or bytes, whatever
[17:40] lru: well well... the blockchain format is much more liberal than I thought :-) good point then
[17:42] lru: no wonder your statements in the past have heavily weighted the miners as the ones with power instead of the nodes... I had thought there was more to check / reject on the node side.
[17:43] lru: would it have been smarter to make the format stricter? that would have made these recent changes into hard forks instead of soft forks
[17:44] lru: perhaps that is what MP meant by "specify the damn thing"
[17:49] jfw: c'mon, I thought you were a techie... a key is just a number, and you can encode anything into a number
[17:51] lru: but an address specification saying it is 20 characters long, 0-9a-z lower case, would limit shenanigans
[17:52] lru: 0-9a-f*
[17:53] jfw: you stand accused of possessing digital contraband and your defense is that... it's hex encoded?
[17:55] lru: no, it's that bad actors can store less random data, and instead keep the data as relevant to financial transactions as possible...there is no need for an address contain a JPG of the ower's face in a purely financial transaction
[17:59] jfw: you're moving the goalpost.
[17:59] lru: as a person running a node, I may say "yes, I agree to share my resources for financial purposes" but if it is not well specified, I may also be blindly saying "please use my resources as a public ftp site or a private chat network or as a secondary CPU for your cloud"... that's the world of ethereum
[18:01] lru: I feel you're strawmanning my argument into caring too much what the government thinks, and I'm saying every person has the right to decide that for himself
[18:02] jfw: what is your argument exactly, because from here it's getting hard to keep track.
[18:05] jfw: it could certainly be better specified but that wouldn't change the fact that users can encode whatever they want across however many transactions and miners can include whichever transactions they choose.
[18:09] jfw: ethereum doesn't have a practical limit on how much storage & compute the users can impose on the nodes, thus predictably nobody runs nodes anymore. bitcoin has a hard limit, so the comparison doesn't hold, your objection (and luke-jrism more generally) seems to be instead about policing what are the socially acceptable types of bits to be stored
[18:10] lru: I was not aware that users could store arbitrary 100k+ data in the blockchain already (sequential,I mean... I know anyone can use stegonography tactics to use bits here and there)... so with that news, my initial point and original reason for talking about v30.0 is moot
[18:11] jfw: you misunderstand me, it's exactly what you call stego, just another encoding scheme
[18:12] lru: I was under the impression that bitcoin was one of the view cryptocurrencies that was still focused, and strictly limited to, currency
[18:12] lru: one of the few*
[18:16] lru: as for socially acceptable bits, even strictly limited to currency, bitcoin has its hands full of potential nefarious use... just like cash does... it would be nice if that was the only nefarious use it supported, and not yet more uses that could be used to attack its utility in the first case
[18:20] jfw: you're trying to invent a screwdriver that can't be used for nefarious purposes now? and imagining that the fact that it can be used for things some people don't like is somehow a problem for the screwdriver?
[18:21] jfw: I gotta move on for now.
[18:26] lru: more like a screwdriver can already be used for nefarious purposes: unscrewing hinges on doors, used as a poking implement to break a window, used as a weapon... all this is due to its inherent function. What I object to is adding an extra meter-long iron handle to the end of screwdrivers to make them better at being levers and better at impact weaponry... allowing 100k+ arbitrary data in the blockchain does
[18:26] lru: not enhance bitcoin's core function in my opinion, but *could* harm it.
[18:27] lru: understood... thanks for chatting as long as you did :-)
[20:05] jfw: preliminary patch is under testing which doesn't yet tackle the reinvention of the inv queues but should help with the worst of the debug.log bloat, by making the existing -debug flag work sanely as a log level and no more, and improves state visibility through getinfo and a new getpeerinfo.
[23:12] jfw: just now realizing bitcoind has its own whole template-class-based bignum arithmetic implementation for all but multiplication & division, in addition to importing openssl's
Day changed to 2025-10-14
[01:04] jfw: preview patch posted for comments
[01:21] jfw: lru, you seem intent on continuing to miss the point, I could just as well have used a meter-long crowbar as the example, it's still just a tool, and there's nothing inherently bad about unscrewing hinges or breaking windows either, wut.
[01:31] jfw: to summarize my argument, if the fear is that bitcoin and/or you personally are at risk because someone could plant illegal bits in it and blame you just for running a node, you might as well give up because that attack is just as possible no matter what technical restrictions are put in place; yet we don't see it happening in practice. on the other hand if the fear is about the shear weight of
[01:31] jfw: the blockchain pushing for centralization, closing and ultimately subversion of the network, then logically you'd best stand against those who already acted to hasten that, which would include 'knots'. otherwise, it's all just that much more idle chatter.
[01:37] jfw: idle chatter at best, more like FUD slinging.
[01:45] jfw: I recall the "TOR exit nodes are too hot to handle" point being accompanied by real stories of operators getting SWATted or the like by clueless local cops. where are the corpses of the btc node operators? there's been plenty of time to hear from them by now. but the most you ever heard about was the occasional DDoS botnet strike, back in the day.
[01:58] jfw: patch updated because I forgot to note the keypool info removal in the manifest.
[17:03] dorion: jfw, cool. I'm finishing a backup of one of my nodes and I'll test it.
[17:05] jfw: our two public nodes are back online with the patch & catching up, old logs offloaded for now pending the grep fix.
[18:36] dorion: sweet.
Day changed to 2025-10-15
[15:19] jfw: !E view-height
[15:19] jfw: !e view-height
[15:19] btcexplorer: block_height: 915529
[15:19] btcexplorer: mins_since_last_block: 36656
[15:23] jfw: whaack: 205.134.172.28 seems not accepting connections at all?
[19:18] whaack: jfw: i haven't figured out what's amiss, i restarted the node a while back but it didn't seem to fix anything
[20:24] jfw: does it respond to local queries? any connections at all? no clues in debug.log?
Day changed to 2025-10-17
[12:48] dorion: both of my nodes are now running the latest patch and are synced to the tip. I used -connect w/ one of the prb nodes to get to the tip and then switched to -addnode, the patch was useful in figuring which to connect to.
Day changed to 2025-10-20
[00:38] bob: What distro of linux do you guys like the most?
[00:47] jfw: bob: depends on the application. for the closest thing to a fully-owned, stable & maintainable system - our own Gales Linux. for a 'permissive' machine capable of running the latest gui-driven fads without too much fuss, I've been using Xubuntu with the 'snaps' purged and firefox installed from mozilla repo
[00:49] jfw: CentOS 6 gets a mention too but lately the new stuff tends not to run there.
[00:51] bob: Nice, I am on Debian for years as it is very stable and consevative. But I like Ubuntu as well sometimes
[01:03] dorion: bob are you on a systemd free debian ?
[01:04] dorion: bob, welcome back.
[01:35] bob: Yeah pretty much all version of debian since debian 9
[01:36] bob: Server and desktop
Day changed to 2025-10-22
[15:11] jfw: dorion: let's see if https://tinyurl.com/jwrdnet can circumvent the whatsapp link corruption
[15:11] jfw: surprised I didn't think of that before
[20:34] dorion: jfw, the problem is with articles though too. need to keep an tinyurl index of every article now ?
[20:39] jfw: ah. well I guess you could create them as you link them, the process was pretty painless
[20:40] jfw: js required but not account
[20:41] dorion: the mp-wp link redirect is a huge time saver though. i guess I could keep a text file of an index and grep it, but then wut do about the selection ?
[20:47] jfw: hey, it's a first step.
[20:49] jfw: selection parameters can go into the url to be shortened too
[20:52] dorion: i'm somewhat on the fence because it also is an opportunity to show whatsapp braindamage and the mitm attack they're running
[20:57] jfw: depends on how much credit you have with the audience I guess
[20:58] dorion: some raise the error, some don't.
Day changed to 2025-10-23
[06:48] lru: what does whatsapp do with urls?
[13:30] dorion: lru, it mangles http links to https
[16:42] jfw: in other propaganda, openssh now labeling classical key exchange algorithms as "weak", apparently based on the claim that they've made a hybrid scheme that ensures the post-quantum algos don't worsen security over the previous "best" (by which they mean elliptic curves, ofc, anything but RSA)
[16:43] jfw: the proof appears to have been too large to fit in the margin.
[16:44] jfw: or the next step could be to push for disabling the EC part altogether, for the same "efficiency" reasons that got us EC in the first place
[16:59] jfw: http://jfxpt.com/2025/jwrd-logs-for-Oct-2025/#15105 - it also has value as intelligence test: are they sharp enough to perceive their cage, once it's shown to them? but while that may be useful information, it may not be affordable as a filter for all interaction.
[16:59] sourcerer: 2025-10-22 20:52:21 (#jwrd) dorion: i'm somewhat on the fence because it also is an opportunity to show whatsapp braindamage and the mitm attack they're running
[21:11] lru: dorion: thanks
[21:11] lru: I assume they become the "https" server if the end host doesn't support it?
[21:12] lru: jfw: the last FAQ is interesting...they claim to be using combo algorithms... both PQ and non-PQ, just in case one collapses before the other
[21:29] jfw: right. because if that doesn't hold up, there's no more guarantees on the PQ stuff than on RSA; for all we know it's more easily attacked by existing computers, which for the conspiratorial mind could explain why the mega hype campaign to switch.
[21:31] jfw: re whatscrapp, no, it just changes the protocol scheme of its own accord and sends the broken link to the browser app as if that's really what you meant to click on, nevermind that the server doesn't even listen on 443.
[21:32] jfw: so it's "broken link" as seen by luser via browser.
[22:01] jfw: http://jfxpt.com/2025/jwrd-logs-for-Aug-2025/#14739 - Google's AI mode tells me there's been no discussion of the issue and furthermore that an overflow such as the one I pointed out to it is unlikely because the input file would need to exceed 9 quintillion lines! (because that's what would happen if it were a 64-bit integer)
[22:01] sourcerer: 2025-08-11 05:19:38 (#jwrd) jfw: confirmed bug in busybox "grep", a pretty serious one I'd think: it stops printing any output after exceeding ~2bn lines of input, due to overflow of a 32-bit (signed!) integer line counter, used for the -n and -A/B/C features regardless of whether they're invoked.
[22:04] jfw: I'm not even *trying* to fool the chatbot here, this is entirely typical of what happens whenever I give it something remotely interesting to chew on.
[22:08] lru: nice catch
[22:09] lru: I haven't bothered much with AI yet
[22:09] lru: it could be a bubble
[22:11] jfw: it definitely looks like a bubble in financial terms, unfortunately we're going to be stuck with the fallout
[22:12] jfw: it's basically the new web search, since all web search does now anyway is point you to ai output masquerading as people with domain names and everything.