Day changed to 2024-11-04
[03:16] jfw: dorion: finalizing the gbw-signer vpatch, testing on v.pl silently fails yet again. it happened for gscm too, but I figured out it was because I'd missed the project subdirectory (gscm never having previously used such, I guess I'd been manually putting it in each time for the prior maintenance patches). thus, patch missing antecedent. so far no clue on this one though.
[03:17] jfw: it applies fine manually, can try it as a fetch-bitcoind update since that also checks sigs & hashes.
[13:22] dorion: jfw, alright. sux about v.pl and sounds good wrt fetch-bitcoind. this adds more weight to moving to vamp, wouldn't you say ?
[14:42] jfw: moving to vamp is a weight that still needs more lifting, while staying without it is a weight that continues dragging, I'd say.
Day changed to 2024-11-06
[15:10] jfw: so, the press reports a projected Trumpreich 2.0, with Trump claiming victory and politburo-appointed runner-up Kamelface Whatshername apparently hiding in a closet declining to comment.
[15:20] jfw: the former Paypal competitor X.com, now housing Elon Musk's allegedly pro-free-speech micro-blogging platform, reports merely "This browser is no longer supported." When asked for clarification, they explained that users of non-whitelisted browsers, such as any who haven't swallowed all of SillyCon Valley's latest booster updates, "may be unable to use X". Left unstated is that this disability is
[15:20] jfw: of their own creation.
[15:20] jfw: * of X's own creation.
[18:00] jfw: btc-usd markets seem to like the news, up around 6% over 24h.
[18:01] dorion: apparently the republicans now control the executive, house, senate and already controlled the supreme court. they grabbed that election by the pussy.
[18:01] dorion: usdbtc down 6%
[21:12] jfw: the house seems uncertain yet.
[21:12] jfw: think the election liked it?
[23:16] dorion: non one asked.
Day changed to 2024-11-07
[09:48] lru: jfw: is the browser check based on the headers sent, or something more complex like javascript code running in the browser? if just headers, send what it expects?
[09:51] lru: I'm sure X will happily take the "blame" for this disability too, because they likely test against the whitelist, instead of against one particular web standard
[17:08] jfw: it's probably both. they're welcome to send someone here to work with me on it, I can donate some testing & feedback; otherwise, I have better things to do than reverse engineering the braindamage du jour.
[20:33] jfw: http://jfxpt.com/2024/in-accidental-social-engineering-yesterday/
Day changed to 2024-11-09
[18:33] jfw: http://jfxpt.com/2024/jwrd-logs-for-Oct-2024/#12504 - this guy's up to 374700.
[18:33] sourcerer: 2024-10-18 03:40:27 (#jwrd) jfw: I've now got its busybox rebuilt for the tar fix, rngnet feeding /dev/urandom, bitcoind built and a sync kicked off.
[18:37] jfw: we had an 11-hour power outage at the "datacenter"; everything seems recovered fine now, though looks like the restoration was "noisy", the server got stuck in a powered off state and needed a kick to come back up. not the most auspicious start, but it's the infrastructure we afford so far and such outage should be unusual.
[18:41] jfw: it sounded like a quite localised event, like a transformer failed right on the street by the building.
Day changed to 2024-11-10
[20:47] jfw: Running behind schedule again on publishing the latest Scheme work; going through the pre-signing review of the last and heaviest of six patches, and already turned up one small thing worth fixing in it.
[20:54] jfw: Still not enjoying this part as much as the new coding... but, if the work is important, then the problem must be in the enjoyer.
Day changed to 2024-11-11
[12:06] lru: how do you know if work is important?
[12:06] lru: is it possible to live on crypto only, without fiat, in north america yet?
[12:07] lru: my two questions for the day
[14:51] dorion: lru, btc -> local cash otc is likely to continue to be the norm, because btc isn't made for retail, nor do I want to be carrying keys everywhere.
[14:52] dorion: lru, where abouts are you ?
[14:54] dorion: http://jfxpt.com/2024/jwrd-logs-for-Nov-2024/#12540 -- the upside is the more intense review caused you to find something worth fixing prior to publishing.
[14:54] sourcerer: 2024-11-10 20:54:57 (#jwrd) jfw: Still not enjoying this part as much as the new coding... but, if the work is important, then the problem must be in the enjoyer.
[14:59] dorion: http://jfxpt.com/2024/jwrd-logs-for-Nov-2024/#12541 -- the best heuristic for 'knowing' is if a client who shares your values is willing to pay for it at an acceptable price. absent that, you're working more on a basis of belief that the work will help you find those clients or , once found, convince them to use the output.
[14:59] sourcerer: 2024-11-11 12:06:06 (#jwrd) lru: how do you know if work is important?
[15:33] jfw: what dorion said and perhaps more generally: because the work solves a problem that exists either now or in the future. where the experience and art of management come in, then, is figuring out what's really a problem and what's likely to be needed in the future, at least with enough odds to justify the cost in the present, weighed against all the other things that might be needed.
[15:38] jfw: and tackling things at the right time, before they become crises.
[15:43] jfw: which would suggest that the better things are going, the more important becomes internal motivation or discipline because you're doing things that only pay off in the future if at all.
[20:59] lru: thank you both for your thoughtful answers
[21:01] lru: dorion: I'm in Canada... and after posting my question, searched for crypto/bitcoiny ways to pay for things... found some... one idea being to use a credit card and then pay it off with bitcoin
[21:02] lru: I don't know who I would go to for an in-person btc->cash transaction
[21:46] dorion: lru, you have a credit card that accepts btc ? i know some canadians that use wences' xapo card. I think there used to be more otc options in canada, a couple contacts here operated in vancouver and montreal, but increased kyc demands caused them to shut down.
[21:47] dorion: is your plan to stay in canada ? there are lots of canucks in panama, actually.
[22:47] lru: yeah, I plan to stay in Canada... I don't have a credit card that accept btc now, but it appeared to be an option, or at least an option to do btc to bank payments, leaving a credit card as one of the things you can pay ff
[22:47] lru: off*
[22:49] dorion: what do you like about Canada ?
[22:50] lru: other than I was born here, and have family, I like how little land is actually in use, leaving a lot of it wild and basically unused
[22:51] dorion: are you an outdoorsman then ?
[22:52] lru: not as much as I would like :-) but the fact the option is there is appealing
[22:52] dorion: i know a canadian here who ran a trapline in northern bc for a year during his 20s. some interesting stories and he tells them well.
[22:52] dorion: ever hunted w/ success ?
[22:53] lru: no, sadly
[22:54] dorion: deer season is upon us. but maybe better wait for next year. hunter safety is important.
[22:54] dorion: and noteably, killing the thing is sometimes the easier part. gutting it and getting it back to civilization can be messier.
[22:56] lru: depending what you shoot, and where, it can be a multi-person job to get it all back
[22:57] dorion: that's what I mean. both deer I shot were carted out on atv. no dragging necessary. lucky me.
[22:58] lru: indeed
[22:59] dorion: lru, did you get ahold of a 1tb drive yet for your btc node ?
[23:01] lru: I don't recall saying I was going to, but no.... I was almost stunned and very happy to know that a 1tb drive would be enough
[23:01] lru: quick price check on disks...
[23:03] lru: $116 for crucial ssd... is that good?
[23:19] dorion: we always use samsung.
[23:19] jfw: looks like http://jfxpt.com/2024/jwrd-logs-for-May-2024/#11120 was the last talk on SSDs. I'm not familiar with Crucial's myself; at least that brand goes back a ways in DRAM
[23:19] sourcerer: 2024-05-08 18:07:19 (#jwrd) jfw: cruciform asked about SSD recommendations; for the Thinkpads we've pretty much been sticking with Samsung EVO, following the TMSR gossip - which AFAIK was indeed just gossip, no data.
[23:20] dorion: lru, i was referring to http://jfxpt.com/2024/blockchain-kindergarten-why-proof-of-work/?b=the%20largest&e=500G#select
[23:30] lru: $129-ish for samsung
[23:31] lru: dorion: yes, and that is still the case :-) used one of them up recently as a system backup while I did an in-place Debian upgrade to Bookworm
[23:32] lru: when I deem the upgrade a success, I can free it up again
[23:33] lru: nice having a small pile of disks all the same size
Day changed to 2024-11-13
[02:08] jfw: yesterday I hit some perplexing curiosities in the depths of the Scheme macro semantics. Unearthed an old test case that still failed, and discovered that another I thought working only appeared so because I'd botched the test code. Both look rather difficult to fix and yet rather obscure and inconsequential. So today I've at least clarified the situation in mind and in comments; it might just
[02:08] jfw: have to be a "bugs declared features" kinda thing. Planning to do a mini-writeup, at least get some juice from it.
[02:12] jfw: the look into test cases was prompted by a dubious spot in the implementation on the readthrough, i.e. it's turned up by a systematic process, not just throwing darts and seeing what hits.
[02:16] jfw: ("penetrate and patch" in other words)
[02:18] jfw: since high assurance is kinda the whole point of having our own interpreter, it gets the fine-toothed-comb treatment.
Day changed to 2024-11-14
[02:23] jfw: http://jfxpt.com/2024/a-perplexing-curiosity-from-the-depths-of-scheme-definitions/ - that's one of the two curiosities out.
Day changed to 2024-11-15
[03:37] jfw: http://jfxpt.com/2024/jwrd-logs-for-Nov-2024/#12535 - up to 388000 blocks. it's doing typically 2-6 blocks per minute, with the occasional long period of nothing as per the known weakness of the sync code.
[03:37] sourcerer: 2024-11-09 18:33:20 (#jwrd) jfw: http://jfxpt.com/2024/jwrd-logs-for-Oct-2024/#12504 - this guy's up to 374700.
[03:42] jfw: courtesy of whaack's explorer I'm seeing that the blocks in that range are mostly toward the full side, though sometimes much smaller. I expect it's likely to slow down a bit more in a logarithmic kinda way just due to the increasing size of the data set, but overall seems a perfectly respectable rate for keeping up once it's synced, and even for the sync itself as long as there's no rush
[03:50] jfw: though another point is that this is with a luxurious 30GB RAM soaked up in page cache.
[03:51] jfw: so if the box is carved up for other uses, the node won't have all that to itself.
[03:52] jfw: what do you make of the data points so far, dorion? we last discussed in the back room, "testing btc node performance on hdd was one thing to do with the new box"
[03:53] jfw: latest from the ISP is I got their invoicing process unclogged (some front office drone typo'd an email address on the handoff) and they've successfully received their first payment from us, so that closes the loop.
[03:54] jfw: cash deposit at the bank worked, no further accounts/dox necessary.
[03:59] jfw: extrapolating 4 bpm gives 84 days to finish the current sync
[04:32] jfw: the limitation we still have on booting is that lilo can't install to a RAID1 over 2 TB. an upgrade option with minimal time and materials cost, then, is to keep the existing 600G RAID1 for a boot volume plus whatever application group might want its own "dedicated spindle"; then buy two max-size HDDs for a second RAID1 data volume.
[04:36] jfw: or, go hybrid and use one or two SSDs for that 'boot' volume and put the node there
[04:41] jfw: or, go with some small/cheap device for the boot volume, ssd perhaps for less power draw, and just the 2 new HDDs for data, which leaves room for a warm spare.
[04:41] jfw: possibly there'd be room for that even with the 2-SSD RAID.
[04:42] jfw: I'm not that attached to the 'warm spare' though.
[04:52] jfw: the beauty of option 1 is we could open for business right now, add the new HDDs at our convenience, and not have to migrate anything. options 2 and 3 will both take my time to set up the new boot volume, and option 2 entails the most outlay on SSDs.
[05:00] jfw: an option 4 is to fuck around with the software to deal with that limitation, which has long term value but seems to be what we have the least bandwidth to handle right now.
Day changed to 2024-11-18
[12:18] lru: so if 3 and bc1 addresses are "anyone can spend", has anyone attempted spending them, and if not, why not?
[14:44] jfw: lru: what have you found so far on the subject?
[15:29] lru: jfw: nothing yet... I imagine I'd have to test it on a testnet setup or something, with a mix of old bitcoin and latest bitcoin nodes
[15:34] jfw: or try reading more, dorion and whaack for starters have written about it in some detail
[15:35] jfw: oh hm, whaack, ztkfg.com returns "Internal server error" ?
[15:37] dorion: lru, do you know the differences between soft and hard forks ?
[15:41] whaack: iru: thanks for pointing that out, will take a look later today.
[15:41] jfw: whaack: wrong 3-letter name but sounds good :P and that was a quick join after mention
[15:47] lru: dorion: yes, based on what I read last night, hard forks relax rules and therefore require everyone to jump to the new version, while soft forks add rules within the existing rules, allowing for piecemeal upgrades and coexistence
[15:48] lru: whaack is watching us closely :-)
[15:51] lru: reading dorion's site is what so far has inspired the question
[15:55] dorion: lru, we can tease it out further. in a hardfork, 2 chains and thus coin histories are created at the time of the fork and miners are forced to choose which to mine. in a softfork, miners censor transactions the dissenting side (the ones who don't include the softfork patch in their node code) sees as valid, but there isn't a fork to the chain.
[15:57] dorion: when would a chain fork happen though ? when a chunk of the miners decide to stop the censorship of those valid transactions and spend the anyone can spend to themselves. the softforked nodes would see these transactions as invalid, but the normal nodes see them as valid, because they've been valid all along according to them.
[15:58] jfw: yes. a hardfork is an honest change that allows the market to form between the two versions; a softfork is basically a 51% attack where miners collude to change rules without approval of holders.
[15:58] dorion: to the softforked nodes, this would essentially be a hardfork, a loosening of the rules. to the normal nodes, it's business as usual.
[16:00] dorion: now, how does the economics play out ? to holders with value in p2pkh addresses (starts with 1), they're likely have value on both chains. to people with anyone can spend addresses (starts with 3 and bc1), they only have value in the softforked chain with weakened key security that is only upheld by miner censorship.
[16:03] dorion: some p2pkh owners will do nothing, sleep through it. others will sell the chain they see as less valuable and buy the chain they see as more valuable. anyone can spend people, including various fiat exchanges and probably fiat products like the etfs, have to pray the censorship continues.
[16:06] dorion: if miners do defect to the normal rules and stop the censorship, the propaganda war will be intense, "bitcoin has been hacked"
[16:08] jfw: i.e. the thief who cries thief, as played out previously
[16:12] dorion: if miners are pricing their actions in btc, unwinding the softfork makes more sense the more the reward pool grows and the more difficulty rises while block reward decreases. what happens to the short term fiat value of the btc is hard to predict, but seems to me the odds would be towards panic selling and a crash in the price, which would likely cause more fiat sensitive miners to try to uphold
[16:12] dorion: the less secure chain.
[16:14] dorion: well, hm. i'm not so sure about the last point.
[16:15] dorion: lru, I'm going to leave it there for now, let us know what questions/comments come to mind.
[17:31] lru: dorion: that was a beautiful explanation, thank you very much! I was missing the part that it's the miners doing the first round of censorship, before the nodes even see it.
[17:42] lru: I'm unclear what the motivation is for a miner to censor, unless the increased tx rate turned into a higher profit than what would have occured normally via higher tx rates with fewer txs
[21:32] jfw: at the moment, breaking with the cartel means a miner won't get paid for its blocks because others won't build on them. how that came to be is less clear to me, but politics, virtue signalling and gullibility for starters; the idea that massive retail transaction volume is necessary for bitcoin to succeed
[21:34] jfw: and the desire to water down bitcoin to make it more acceptable to fiat minds & institutions
Day changed to 2024-11-19
[23:23] dorion: lru, you're welcome, glad to read it helped. I'm not sure if the nodes don't see it, some "nodes" certainly do.
[23:28] dorion: lru, on top of what jfw said, it's not clear to me how many miners or pool operators understand the dynamics at play. in large part, they've been sybil'd into believeing whatever the power rangers do defines bitcoin. if you recall, they pushed segwit through on the "user activated soft fork" bs. they say this was the "economic majority", though there is no way to know how many bitcoin are behind a
[23:28] dorion: given node. i.e. 1k nodes with 1btc each is a greater majority in their model than 1 node with 10k or 100k btc.
[23:31] dorion: if it were so easy to change the bitcoin protocol by node count voting, an attacker could relatively cheaply spin up 100k aws 'nodes' or whatever, without having much, if any, bitcoin behind them. 100k aws nodes wouldn't be very cheap, but cheaper than buying enough btc to be the actual economic majority.
[23:33] dorion: one what to pool the economic majority would be to request signed messages with the keys that hold the coins. it's hard to believe this didn't occur to them, but I suspect they didn't propose it because they sensed their proposed changes would be struck down. so they propose the sybilable "voting" instead.
[23:34] dorion: s/one what to pool/one way* to poll/ ; ffs
[23:58] jfw: oh, they actually did a 'vote by IP address count'? and this convinced anybody of anything? I didn't really follow that 'uasf', didn't there there was any more to it than a socialmedia hashtag.
[23:58] jfw: *didn't think there
[23:59] jfw: but yes, that'd be the gullibility.
Day changed to 2024-11-20
[01:08] dorion: jfw, I'm pretty sure that's what it is.
[01:10] dorion: http://jfxpt.com/2024/jwrd-logs-for-Nov-2024/#12595 -- so we're about a month into it, eh ?
[01:10] sourcerer: 2024-11-15 03:52:10 (#jwrd) jfw: what do you make of the data points so far, dorion? we last discussed in the back room, "testing btc node performance on hdd was one thing to do with the new box"
[01:11] dorion: http://jfxpt.com/2024/jwrd-logs-for-Nov-2024/#12598 -- does this extrapolation include where the tip is estimated to be in 84 days ? or just the height it was last week when you wrote that ?
[01:11] sourcerer: 2024-11-15 03:59:24 (#jwrd) jfw: extrapolating 4 bpm gives 84 days to finish the current sync
[01:12] dorion: http://jfxpt.com/2024/jwrd-logs-for-Nov-2024/#12595 -- I think it's worth it to keep it going for now, at least see what another month does. would be nice to see it go all the way and then have that to compare it to when sync code is improved.
[01:12] sourcerer: 2024-11-15 03:52:10 (#jwrd) jfw: what do you make of the data points so far, dorion? we last discussed in the back room, "testing btc node performance on hdd was one thing to do with the new box"
[01:44] jfw: http://jfxpt.com/2024/jwrd-logs-for-Nov-2024/#12643 - that's right
[01:44] sourcerer: 2024-11-20 01:10:23 (#jwrd) dorion: http://jfxpt.com/2024/jwrd-logs-for-Nov-2024/#12595 -- so we're about a month into it, eh ?
[01:45] jfw: http://jfxpt.com/2024/jwrd-logs-for-Nov-2024/#12645 - no, maybe add 3% for that (84 days out of maybe 10 yrs of heavy blocks)
[01:45] sourcerer: 2024-11-20 01:11:20 (#jwrd) dorion: http://jfxpt.com/2024/jwrd-logs-for-Nov-2024/#12598 -- does this extrapolation include where the tip is estimated to be in 84 days ? or just the height it was last week when you wrote that ?
[01:48] jfw: comparing performance of a sync improvement would be valid if we don't change disks
[01:50] jfw: but their 600G limit makes that iffy
[02:01] jfw: dorion: thoughts on the storage upgrade options I layed out, in that same monologue? #1 would allow the current sync to finish as-is, at the cost of not hosting anything else until either it's done or the new disks are in. the rest would strictly have to wait for the sync before hosting anything else, if we want that data.
[02:13] jfw: to at least give the correct model for the quite approximate extrapolation, it's the grade school algebra "when does train A catch up with train B?" or "Galilean relativity" problem. if the node proceeds at 4 bpm while the network proceeds at 1 block per 10 minutes or .1 bpm, then the node advances on the network at 3.9 bpm.
[02:19] jfw: though it's now at 400549 which puts it closer to 1.7 bpm average over the interval since that last reading, ETA 200 days, lol.
[02:20] jfw: checking just now it was 10 hours stuck, so I restarted and it's moving again.
[14:42] dorion: jfw, at face value, I don't like to prospect of tying that machine up for months. however, taking that path would force us to grow. first we need to verify the cost and process for adding IPs. in place of vpsen, we could offer some apu1s, which might be more attractive to people anyways.
[14:43] dorion: i also have 2 pogos in stock.
Day changed to 2024-11-21
[14:59] whaack: lru et all: blog has been fixed, thanks
[15:14] dorion: howdy whaack.
[15:15] whaack: howdy
[15:16] whaack: how's Panama?
[15:49] dorion: it's pretty normal here.
[16:09] dorion: whaack, you been occupied with your venture w/ billymg ?
[16:10] dorion: any substantial change in the wrists ?
[16:24] whaack: dorion: yup, still grinding out that business.
[16:25] whaack: wrists are about the same, but i have a little stretching routine that has allowed me to push through and not have flareups, i'm back to surfing as well
[16:31] dorion: sounds like you're dealing with it the best you can, managing it and not letting it control you.
[16:43] whaack: yup, life is good. near 100k USD <-> btc ain't bad either eh
[16:52] lru: I suppose now is the time for me to buy...
[16:57] jfw: when lru buys, we'll know the top is in
[16:58] jfw: whaack: want to do a panama visit some time? atm I can offer a guest room and uncrowded kitchen to save you some expenses
[16:59] whaack: ohh that sounds quite nice, i would indeed like to
[17:00] whaack: haha lru: please announce when that is
[17:02] whaack: jfw: any preference on dates? I'm going to visit my mom dec 12 - 28th or so it seemns, probably easiest time for me would be to come before i come back to CR
[17:02] jfw: so around the new year?
[17:02] whaack: yup
[17:03] jfw: might work. I'll be heading north at some point too but timing depends on getting some stuff wrapped up here.
[17:06] jfw: now through early december is clear for me
[17:09] jfw: dorion: indeed the workstation and the apu1s are both fallow resources atm, and looks like either way requires some further parts & labor. previously we were talking about 1 apu to segregate some of our data but now you're thinking more of a fleet?
[17:11] jfw: I think quite a few could fit in the space, with some consideration to racking & cooling perhaps, but might need to renegotiate for it
[17:16] jfw: from anecdotal experience I'm not so hot on the apu1s, after the misadventures in running a bitcoind on the first test unit, though there's still the hypothesis that it was damaged from all the hands-on experimentation. at any rate they don't do ECC.
[17:16] jfw: it could be interesting at least to try more and get a bigger sample.
[17:17] jfw: iirc there were also the 2/7 that failed to boot after coreboot reflashing
[17:20] jfw: cruciform if tuned in: you're also welcome to come chill in panama
[17:21] jfw: the room is good for a single or couple, but there's plenty of hotels too running the gamut of prices
[17:22] jfw: mid december through march or so would be the high tourism season
[17:29] jfw: (meaning, more crowded roads & beaches, harder to get cars rented, minimal rain but still hot weather)
[21:43] whaack: sry for join/spart spam, signing off
Day changed to 2024-11-23
[20:57] jfw: http://jfxpt.com/2024/tradingview-dot-com-as-understood-through-the-platforms-playbook/
Day changed to 2024-11-24
[12:34] lru: what would a non-platform version of TradingView look like? basically a database that all users would need to start paying for access too from the beginning?
[17:47] jfw: if you mean, what would work as a business model, that sort of thing is easy to armchair-strategize but requires someone to put skin in the game to actually prove, and that's unlikely to happen while the neighbors are dumping a free-with-strings-attached version, at least not for the same audience.
[17:47] jfw: but to my mind an "honest" version would mean either dropping the "free" or dropping the "strings attached"
[17:48] jfw: you could perhaps publish the client software and charge something for the data access; not a lot though, it's hard to sell data as such beyond the cost of delivery because it's so easily replicated
Day changed to 2024-11-25
[17:42] jfw: http://jfxpt.com/2024/jwrd-logs-for-Nov-2024/#12657 - update: 415012 = 1.8 bpm since then.
[17:42] sourcerer: 2024-11-20 02:19:03 (#jwrd) jfw: though it's now at 400549 which puts it closer to 1.7 bpm average over the interval since that last reading, ETA 200 days, lol.
[19:31] jfw: http://jfxpt.com/2024/jwrd-logs-for-Nov-2024/#12599 - I'll add an option #5: add a new HDD pair, keeping the current pair but reformatting it with a RAID1 boot partition and RAID0 or linear (aka span/JBOD) data partition. That'll give a healthy 1.2T for the node and possibly some performance boost, keep it seek-independent from other applications, and maximize storage for the current satoshi
[19:31] sourcerer: 2024-11-15 04:32:32 (#jwrd) jfw: the limitation we still have on booting is that lilo can't install to a RAID1 over 2 TB. an upgrade option with minimal time and materials cost, then, is to keep the existing 600G RAID1 for a boot volume plus whatever application group might want its own "dedicated spindle"; then buy two max-size HDDs for a second RAID1 data volume.
[19:31] jfw: outlay.
[19:32] jfw: the node won't have block level redundancy, but it wouldn't in a single-SSD setup either, it can always be recovered, and arguably the HDDs are well proven and less likely to fail in the first place.
[19:35] jfw: I'm liking this one best atm.
[19:41] jfw: especially as it seems SATA SSD prices aren't really coming down at all.
[19:42] jfw: though apparently there's now such thing as a 1TB micro-SD card, and for 100 bones, wut
[21:00] dorion: http://jfxpt.com/2024/jwrd-logs-for-Nov-2024/#12699 -- sounds good, I'm liking that one too.
[21:00] sourcerer: 2024-11-25 19:31:06 (#jwrd) jfw: http://jfxpt.com/2024/jwrd-logs-for-Nov-2024/#12599 - I'll add an option #5: add a new HDD pair, keeping the current pair but reformatting it with a RAID1 boot partition and RAID0 or linear (aka span/JBOD) data partition. That'll give a healthy 1.2T for the node and possibly some performance boost, keep it seek-independent from other applications, and maximize stor
Day changed to 2024-11-26
[06:22] jfw: http://jfxpt.com/2024/jwrd-logs-for-Nov-2024/#12584 <-> http://jfxpt.com/2024/another-perplexing-curiosity-from-the-depths-of-scheme-macros/
[06:22] sourcerer: 2024-11-13 02:08:55 (#jwrd) jfw: yesterday I hit some perplexing curiosities in the depths of the Scheme macro semantics. Unearthed an old test case that still failed, and discovered that another I thought working only appeared so because I'd botched the test code. Both look rather difficult to fix and yet rather obscure and inconsequential. So today I've at least clarified the situation in mind a
[06:22] jfw: fixpoint is on fire this month, and it's not burnt out yet!
[06:23] jfw: there's also a sort of behind-the-scenes, fireside-chat expansion on that latest one, to finish revision.
[21:53] jfw: http://jfxpt.com/2024/that-in-a-word-is-the-corner-that-im-painted-into-even-though-this-seems-an-incredibly-obscure-situation-of-having-a-top-level-macro-which-inserts-a-top-level-definition-which-may-or-may-not-be/ and there it is.
Day changed to 2024-11-27
[21:30] jfw: dorion: yet another option to weigh on the storage is getting a SAS controller, which would let us standardize on SAS drives. to try it out we could even borrow the 3ware 9750-4i card from either of the idle supermicro boxen. supposedly those can be had for $50.
[21:33] jfw: funnily enough the SAS drives don't look any more expensive, eg 10TB SAS for $160 versus 8TB SATA for $150 even with 'black friday deal'
[21:34] jfw: I think around 8T is the sweet spot atm for a build that'll last a while
[21:37] jfw: we could even steal 2x 4TB SAS drives from that last build, but I'd rather not undo that installation work basically.
[21:46] jfw: I could install a controller on Friday, test it out with the existing SATA drives - that direction of mixing is supposed to be possible - and if all is well, order the new drives.
[21:47] jfw: and controller, so as not to leave us without a spare.
Day changed to 2024-11-30
[20:16] jfw: http://jfxpt.com/2024/jwrd-logs-for-Nov-2024/#12717 - worked just dandy, viva la 3ware.
[20:16] sourcerer: 2024-11-27 21:46:17 (#jwrd) jfw: I could install a controller on Friday, test it out with the existing SATA drives - that direction of mixing is supposed to be possible - and if all is well, order the new drives.
[20:18] jfw: technically I used the spare drive so as not to disrupt the existing array, and didn't map it all the way through to test from the OS, but it showed fine in the BIOS config utility, after some uefi config futzing to get that to display at all.
[20:23] jfw: so to recap, current plan is 2x 10TB or so SAS drives for a RAID1 - probably won't order a spare, figuring the N+1 plus active monitoring should buy enough time to replace when needed - one new controller of same model though possibly w/o battery, and redo the current 600G drives as RAID0 for the node.
[20:39] jfw: enabling the controller's write cache w/ battery would be a possible optimization if performance becomes a problem; but atm I don't like it because with the residential grade power grid I can't guarantee there's no outage that outlasts the battery leading to data loss/corruption.
[20:41] jfw: if we can rig up an impending-death signal from the external UPS to trigger shutdown, it would help.
[20:42] jfw: there's a usb cable for it but protocol is unclear.
[21:25] jfw: though now that I figured out the 'shingled' HDDs scam, I'm finding there's a "512e/4Kn" or "advanced format" thing afoot, pushing for large sectors
[22:39] jfw: possible troubles: some drives switched to 4k sectors while presenting themselves in 512-byte emulation mode, resulting in write performance penalties. some drives are 4k only, forcing software support at various levels. Some Seagate drives have a 'fastformat' which ships in 512e (emulation) by default but allows switching to 4k native, using not-sure-what software. the 3ware's interoperability
[22:39] jfw: list hasn't been updated since 2013 and its manuals from '09 say nothing about sector size, being from the simpler age when it was 512, end of story.
[22:41] jfw: util-linux fdisk can report physical + logical sector sizes, busybox fdisk not so.
[22:44] jfw: the supposed argument for large sectors is it slightly reduces header overhead (~10% capacity increase) and allows for more robust ECC - i.e. they're not otherwise able to make the medium reliable enough at current densities.
[23:06] jfw: https://www.seagate.com/blog/advanced-format-4k-sector-hard-drives-master-ti/ - sorta-ok overview (with broken images)
[23:15] jfw: and such "blog" with no comments, trackbacks or even article date... so I guess it's from around 2011 and they haven't shed any light on how the transition went outside the "laptop and desktop market segments".
[23:43] jfw: I reckon I'll go ahead with the new disks but skip ordering a new controller until it's proven with them.
[23:44] jfw: stick to 512-byte logical sectors but align the partitions to 4k (or even 1M as I would for an SSD), and hope the RAID controller doesn't throw off the alignment.
[03:16] jfw: dorion: finalizing the gbw-signer vpatch, testing on v.pl silently fails yet again. it happened for gscm too, but I figured out it was because I'd missed the project subdirectory (gscm never having previously used such, I guess I'd been manually putting it in each time for the prior maintenance patches). thus, patch missing antecedent. so far no clue on this one though.
[03:17] jfw: it applies fine manually, can try it as a fetch-bitcoind update since that also checks sigs & hashes.
[13:22] dorion: jfw, alright. sux about v.pl and sounds good wrt fetch-bitcoind. this adds more weight to moving to vamp, wouldn't you say ?
[14:42] jfw: moving to vamp is a weight that still needs more lifting, while staying without it is a weight that continues dragging, I'd say.
Day changed to 2024-11-06
[15:10] jfw: so, the press reports a projected Trumpreich 2.0, with Trump claiming victory and politburo-appointed runner-up Kamelface Whatshername apparently hiding in a closet declining to comment.
[15:20] jfw: the former Paypal competitor X.com, now housing Elon Musk's allegedly pro-free-speech micro-blogging platform, reports merely "This browser is no longer supported." When asked for clarification, they explained that users of non-whitelisted browsers, such as any who haven't swallowed all of SillyCon Valley's latest booster updates, "may be unable to use X". Left unstated is that this disability is
[15:20] jfw: of their own creation.
[15:20] jfw: * of X's own creation.
[18:00] jfw: btc-usd markets seem to like the news, up around 6% over 24h.
[18:01] dorion: apparently the republicans now control the executive, house, senate and already controlled the supreme court. they grabbed that election by the pussy.
[18:01] dorion: usdbtc down 6%
[21:12] jfw: the house seems uncertain yet.
[21:12] jfw: think the election liked it?
[23:16] dorion: non one asked.
Day changed to 2024-11-07
[09:48] lru: jfw: is the browser check based on the headers sent, or something more complex like javascript code running in the browser? if just headers, send what it expects?
[09:51] lru: I'm sure X will happily take the "blame" for this disability too, because they likely test against the whitelist, instead of against one particular web standard
[17:08] jfw: it's probably both. they're welcome to send someone here to work with me on it, I can donate some testing & feedback; otherwise, I have better things to do than reverse engineering the braindamage du jour.
[20:33] jfw: http://jfxpt.com/2024/in-accidental-social-engineering-yesterday/
Day changed to 2024-11-09
[18:33] jfw: http://jfxpt.com/2024/jwrd-logs-for-Oct-2024/#12504 - this guy's up to 374700.
[18:33] sourcerer: 2024-10-18 03:40:27 (#jwrd) jfw: I've now got its busybox rebuilt for the tar fix, rngnet feeding /dev/urandom, bitcoind built and a sync kicked off.
[18:37] jfw: we had an 11-hour power outage at the "datacenter"; everything seems recovered fine now, though looks like the restoration was "noisy", the server got stuck in a powered off state and needed a kick to come back up. not the most auspicious start, but it's the infrastructure we afford so far and such outage should be unusual.
[18:41] jfw: it sounded like a quite localised event, like a transformer failed right on the street by the building.
Day changed to 2024-11-10
[20:47] jfw: Running behind schedule again on publishing the latest Scheme work; going through the pre-signing review of the last and heaviest of six patches, and already turned up one small thing worth fixing in it.
[20:54] jfw: Still not enjoying this part as much as the new coding... but, if the work is important, then the problem must be in the enjoyer.
Day changed to 2024-11-11
[12:06] lru: how do you know if work is important?
[12:06] lru: is it possible to live on crypto only, without fiat, in north america yet?
[12:07] lru: my two questions for the day
[14:51] dorion: lru, btc -> local cash otc is likely to continue to be the norm, because btc isn't made for retail, nor do I want to be carrying keys everywhere.
[14:52] dorion: lru, where abouts are you ?
[14:54] dorion: http://jfxpt.com/2024/jwrd-logs-for-Nov-2024/#12540 -- the upside is the more intense review caused you to find something worth fixing prior to publishing.
[14:54] sourcerer: 2024-11-10 20:54:57 (#jwrd) jfw: Still not enjoying this part as much as the new coding... but, if the work is important, then the problem must be in the enjoyer.
[14:59] dorion: http://jfxpt.com/2024/jwrd-logs-for-Nov-2024/#12541 -- the best heuristic for 'knowing' is if a client who shares your values is willing to pay for it at an acceptable price. absent that, you're working more on a basis of belief that the work will help you find those clients or , once found, convince them to use the output.
[14:59] sourcerer: 2024-11-11 12:06:06 (#jwrd) lru: how do you know if work is important?
[15:33] jfw: what dorion said and perhaps more generally: because the work solves a problem that exists either now or in the future. where the experience and art of management come in, then, is figuring out what's really a problem and what's likely to be needed in the future, at least with enough odds to justify the cost in the present, weighed against all the other things that might be needed.
[15:38] jfw: and tackling things at the right time, before they become crises.
[15:43] jfw: which would suggest that the better things are going, the more important becomes internal motivation or discipline because you're doing things that only pay off in the future if at all.
[20:59] lru: thank you both for your thoughtful answers
[21:01] lru: dorion: I'm in Canada... and after posting my question, searched for crypto/bitcoiny ways to pay for things... found some... one idea being to use a credit card and then pay it off with bitcoin
[21:02] lru: I don't know who I would go to for an in-person btc->cash transaction
[21:46] dorion: lru, you have a credit card that accepts btc ? i know some canadians that use wences' xapo card. I think there used to be more otc options in canada, a couple contacts here operated in vancouver and montreal, but increased kyc demands caused them to shut down.
[21:47] dorion: is your plan to stay in canada ? there are lots of canucks in panama, actually.
[22:47] lru: yeah, I plan to stay in Canada... I don't have a credit card that accept btc now, but it appeared to be an option, or at least an option to do btc to bank payments, leaving a credit card as one of the things you can pay ff
[22:47] lru: off*
[22:49] dorion: what do you like about Canada ?
[22:50] lru: other than I was born here, and have family, I like how little land is actually in use, leaving a lot of it wild and basically unused
[22:51] dorion: are you an outdoorsman then ?
[22:52] lru: not as much as I would like :-) but the fact the option is there is appealing
[22:52] dorion: i know a canadian here who ran a trapline in northern bc for a year during his 20s. some interesting stories and he tells them well.
[22:52] dorion: ever hunted w/ success ?
[22:53] lru: no, sadly
[22:54] dorion: deer season is upon us. but maybe better wait for next year. hunter safety is important.
[22:54] dorion: and noteably, killing the thing is sometimes the easier part. gutting it and getting it back to civilization can be messier.
[22:56] lru: depending what you shoot, and where, it can be a multi-person job to get it all back
[22:57] dorion: that's what I mean. both deer I shot were carted out on atv. no dragging necessary. lucky me.
[22:58] lru: indeed
[22:59] dorion: lru, did you get ahold of a 1tb drive yet for your btc node ?
[23:01] lru: I don't recall saying I was going to, but no.... I was almost stunned and very happy to know that a 1tb drive would be enough
[23:01] lru: quick price check on disks...
[23:03] lru: $116 for crucial ssd... is that good?
[23:19] dorion: we always use samsung.
[23:19] jfw: looks like http://jfxpt.com/2024/jwrd-logs-for-May-2024/#11120 was the last talk on SSDs. I'm not familiar with Crucial's myself; at least that brand goes back a ways in DRAM
[23:19] sourcerer: 2024-05-08 18:07:19 (#jwrd) jfw: cruciform asked about SSD recommendations; for the Thinkpads we've pretty much been sticking with Samsung EVO, following the TMSR gossip - which AFAIK was indeed just gossip, no data.
[23:20] dorion: lru, i was referring to http://jfxpt.com/2024/blockchain-kindergarten-why-proof-of-work/?b=the%20largest&e=500G#select
[23:30] lru: $129-ish for samsung
[23:31] lru: dorion: yes, and that is still the case :-) used one of them up recently as a system backup while I did an in-place Debian upgrade to Bookworm
[23:32] lru: when I deem the upgrade a success, I can free it up again
[23:33] lru: nice having a small pile of disks all the same size
Day changed to 2024-11-13
[02:08] jfw: yesterday I hit some perplexing curiosities in the depths of the Scheme macro semantics. Unearthed an old test case that still failed, and discovered that another I thought working only appeared so because I'd botched the test code. Both look rather difficult to fix and yet rather obscure and inconsequential. So today I've at least clarified the situation in mind and in comments; it might just
[02:08] jfw: have to be a "bugs declared features" kinda thing. Planning to do a mini-writeup, at least get some juice from it.
[02:12] jfw: the look into test cases was prompted by a dubious spot in the implementation on the readthrough, i.e. it's turned up by a systematic process, not just throwing darts and seeing what hits.
[02:16] jfw: ("penetrate and patch" in other words)
[02:18] jfw: since high assurance is kinda the whole point of having our own interpreter, it gets the fine-toothed-comb treatment.
Day changed to 2024-11-14
[02:23] jfw: http://jfxpt.com/2024/a-perplexing-curiosity-from-the-depths-of-scheme-definitions/ - that's one of the two curiosities out.
Day changed to 2024-11-15
[03:37] jfw: http://jfxpt.com/2024/jwrd-logs-for-Nov-2024/#12535 - up to 388000 blocks. it's doing typically 2-6 blocks per minute, with the occasional long period of nothing as per the known weakness of the sync code.
[03:37] sourcerer: 2024-11-09 18:33:20 (#jwrd) jfw: http://jfxpt.com/2024/jwrd-logs-for-Oct-2024/#12504 - this guy's up to 374700.
[03:42] jfw: courtesy of whaack's explorer I'm seeing that the blocks in that range are mostly toward the full side, though sometimes much smaller. I expect it's likely to slow down a bit more in a logarithmic kinda way just due to the increasing size of the data set, but overall seems a perfectly respectable rate for keeping up once it's synced, and even for the sync itself as long as there's no rush
[03:50] jfw: though another point is that this is with a luxurious 30GB RAM soaked up in page cache.
[03:51] jfw: so if the box is carved up for other uses, the node won't have all that to itself.
[03:52] jfw: what do you make of the data points so far, dorion? we last discussed in the back room, "testing btc node performance on hdd was one thing to do with the new box"
[03:53] jfw: latest from the ISP is I got their invoicing process unclogged (some front office drone typo'd an email address on the handoff) and they've successfully received their first payment from us, so that closes the loop.
[03:54] jfw: cash deposit at the bank worked, no further accounts/dox necessary.
[03:59] jfw: extrapolating 4 bpm gives 84 days to finish the current sync
[04:32] jfw: the limitation we still have on booting is that lilo can't install to a RAID1 over 2 TB. an upgrade option with minimal time and materials cost, then, is to keep the existing 600G RAID1 for a boot volume plus whatever application group might want its own "dedicated spindle"; then buy two max-size HDDs for a second RAID1 data volume.
[04:36] jfw: or, go hybrid and use one or two SSDs for that 'boot' volume and put the node there
[04:41] jfw: or, go with some small/cheap device for the boot volume, ssd perhaps for less power draw, and just the 2 new HDDs for data, which leaves room for a warm spare.
[04:41] jfw: possibly there'd be room for that even with the 2-SSD RAID.
[04:42] jfw: I'm not that attached to the 'warm spare' though.
[04:52] jfw: the beauty of option 1 is we could open for business right now, add the new HDDs at our convenience, and not have to migrate anything. options 2 and 3 will both take my time to set up the new boot volume, and option 2 entails the most outlay on SSDs.
[05:00] jfw: an option 4 is to fuck around with the software to deal with that limitation, which has long term value but seems to be what we have the least bandwidth to handle right now.
Day changed to 2024-11-18
[12:18] lru: so if 3 and bc1 addresses are "anyone can spend", has anyone attempted spending them, and if not, why not?
[14:44] jfw: lru: what have you found so far on the subject?
[15:29] lru: jfw: nothing yet... I imagine I'd have to test it on a testnet setup or something, with a mix of old bitcoin and latest bitcoin nodes
[15:34] jfw: or try reading more, dorion and whaack for starters have written about it in some detail
[15:35] jfw: oh hm, whaack, ztkfg.com returns "Internal server error" ?
[15:37] dorion: lru, do you know the differences between soft and hard forks ?
[15:41] whaack: iru: thanks for pointing that out, will take a look later today.
[15:41] jfw: whaack: wrong 3-letter name but sounds good :P and that was a quick join after mention
[15:47] lru: dorion: yes, based on what I read last night, hard forks relax rules and therefore require everyone to jump to the new version, while soft forks add rules within the existing rules, allowing for piecemeal upgrades and coexistence
[15:48] lru: whaack is watching us closely :-)
[15:51] lru: reading dorion's site is what so far has inspired the question
[15:55] dorion: lru, we can tease it out further. in a hardfork, 2 chains and thus coin histories are created at the time of the fork and miners are forced to choose which to mine. in a softfork, miners censor transactions the dissenting side (the ones who don't include the softfork patch in their node code) sees as valid, but there isn't a fork to the chain.
[15:57] dorion: when would a chain fork happen though ? when a chunk of the miners decide to stop the censorship of those valid transactions and spend the anyone can spend to themselves. the softforked nodes would see these transactions as invalid, but the normal nodes see them as valid, because they've been valid all along according to them.
[15:58] jfw: yes. a hardfork is an honest change that allows the market to form between the two versions; a softfork is basically a 51% attack where miners collude to change rules without approval of holders.
[15:58] dorion: to the softforked nodes, this would essentially be a hardfork, a loosening of the rules. to the normal nodes, it's business as usual.
[16:00] dorion: now, how does the economics play out ? to holders with value in p2pkh addresses (starts with 1), they're likely have value on both chains. to people with anyone can spend addresses (starts with 3 and bc1), they only have value in the softforked chain with weakened key security that is only upheld by miner censorship.
[16:03] dorion: some p2pkh owners will do nothing, sleep through it. others will sell the chain they see as less valuable and buy the chain they see as more valuable. anyone can spend people, including various fiat exchanges and probably fiat products like the etfs, have to pray the censorship continues.
[16:06] dorion: if miners do defect to the normal rules and stop the censorship, the propaganda war will be intense, "bitcoin has been hacked"
[16:08] jfw: i.e. the thief who cries thief, as played out previously
[16:12] dorion: if miners are pricing their actions in btc, unwinding the softfork makes more sense the more the reward pool grows and the more difficulty rises while block reward decreases. what happens to the short term fiat value of the btc is hard to predict, but seems to me the odds would be towards panic selling and a crash in the price, which would likely cause more fiat sensitive miners to try to uphold
[16:12] dorion: the less secure chain.
[16:14] dorion: well, hm. i'm not so sure about the last point.
[16:15] dorion: lru, I'm going to leave it there for now, let us know what questions/comments come to mind.
[17:31] lru: dorion: that was a beautiful explanation, thank you very much! I was missing the part that it's the miners doing the first round of censorship, before the nodes even see it.
[17:42] lru: I'm unclear what the motivation is for a miner to censor, unless the increased tx rate turned into a higher profit than what would have occured normally via higher tx rates with fewer txs
[21:32] jfw: at the moment, breaking with the cartel means a miner won't get paid for its blocks because others won't build on them. how that came to be is less clear to me, but politics, virtue signalling and gullibility for starters; the idea that massive retail transaction volume is necessary for bitcoin to succeed
[21:34] jfw: and the desire to water down bitcoin to make it more acceptable to fiat minds & institutions
Day changed to 2024-11-19
[23:23] dorion: lru, you're welcome, glad to read it helped. I'm not sure if the nodes don't see it, some "nodes" certainly do.
[23:28] dorion: lru, on top of what jfw said, it's not clear to me how many miners or pool operators understand the dynamics at play. in large part, they've been sybil'd into believeing whatever the power rangers do defines bitcoin. if you recall, they pushed segwit through on the "user activated soft fork" bs. they say this was the "economic majority", though there is no way to know how many bitcoin are behind a
[23:28] dorion: given node. i.e. 1k nodes with 1btc each is a greater majority in their model than 1 node with 10k or 100k btc.
[23:31] dorion: if it were so easy to change the bitcoin protocol by node count voting, an attacker could relatively cheaply spin up 100k aws 'nodes' or whatever, without having much, if any, bitcoin behind them. 100k aws nodes wouldn't be very cheap, but cheaper than buying enough btc to be the actual economic majority.
[23:33] dorion: one what to pool the economic majority would be to request signed messages with the keys that hold the coins. it's hard to believe this didn't occur to them, but I suspect they didn't propose it because they sensed their proposed changes would be struck down. so they propose the sybilable "voting" instead.
[23:34] dorion: s/one what to pool/one way* to poll/ ; ffs
[23:58] jfw: oh, they actually did a 'vote by IP address count'? and this convinced anybody of anything? I didn't really follow that 'uasf', didn't there there was any more to it than a socialmedia hashtag.
[23:58] jfw: *didn't think there
[23:59] jfw: but yes, that'd be the gullibility.
Day changed to 2024-11-20
[01:08] dorion: jfw, I'm pretty sure that's what it is.
[01:10] dorion: http://jfxpt.com/2024/jwrd-logs-for-Nov-2024/#12595 -- so we're about a month into it, eh ?
[01:10] sourcerer: 2024-11-15 03:52:10 (#jwrd) jfw: what do you make of the data points so far, dorion? we last discussed in the back room, "testing btc node performance on hdd was one thing to do with the new box"
[01:11] dorion: http://jfxpt.com/2024/jwrd-logs-for-Nov-2024/#12598 -- does this extrapolation include where the tip is estimated to be in 84 days ? or just the height it was last week when you wrote that ?
[01:11] sourcerer: 2024-11-15 03:59:24 (#jwrd) jfw: extrapolating 4 bpm gives 84 days to finish the current sync
[01:12] dorion: http://jfxpt.com/2024/jwrd-logs-for-Nov-2024/#12595 -- I think it's worth it to keep it going for now, at least see what another month does. would be nice to see it go all the way and then have that to compare it to when sync code is improved.
[01:12] sourcerer: 2024-11-15 03:52:10 (#jwrd) jfw: what do you make of the data points so far, dorion? we last discussed in the back room, "testing btc node performance on hdd was one thing to do with the new box"
[01:44] jfw: http://jfxpt.com/2024/jwrd-logs-for-Nov-2024/#12643 - that's right
[01:44] sourcerer: 2024-11-20 01:10:23 (#jwrd) dorion: http://jfxpt.com/2024/jwrd-logs-for-Nov-2024/#12595 -- so we're about a month into it, eh ?
[01:45] jfw: http://jfxpt.com/2024/jwrd-logs-for-Nov-2024/#12645 - no, maybe add 3% for that (84 days out of maybe 10 yrs of heavy blocks)
[01:45] sourcerer: 2024-11-20 01:11:20 (#jwrd) dorion: http://jfxpt.com/2024/jwrd-logs-for-Nov-2024/#12598 -- does this extrapolation include where the tip is estimated to be in 84 days ? or just the height it was last week when you wrote that ?
[01:48] jfw: comparing performance of a sync improvement would be valid if we don't change disks
[01:50] jfw: but their 600G limit makes that iffy
[02:01] jfw: dorion: thoughts on the storage upgrade options I layed out, in that same monologue? #1 would allow the current sync to finish as-is, at the cost of not hosting anything else until either it's done or the new disks are in. the rest would strictly have to wait for the sync before hosting anything else, if we want that data.
[02:13] jfw: to at least give the correct model for the quite approximate extrapolation, it's the grade school algebra "when does train A catch up with train B?" or "Galilean relativity" problem. if the node proceeds at 4 bpm while the network proceeds at 1 block per 10 minutes or .1 bpm, then the node advances on the network at 3.9 bpm.
[02:19] jfw: though it's now at 400549 which puts it closer to 1.7 bpm average over the interval since that last reading, ETA 200 days, lol.
[02:20] jfw: checking just now it was 10 hours stuck, so I restarted and it's moving again.
[14:42] dorion: jfw, at face value, I don't like to prospect of tying that machine up for months. however, taking that path would force us to grow. first we need to verify the cost and process for adding IPs. in place of vpsen, we could offer some apu1s, which might be more attractive to people anyways.
[14:43] dorion: i also have 2 pogos in stock.
Day changed to 2024-11-21
[14:59] whaack: lru et all: blog has been fixed, thanks
[15:14] dorion: howdy whaack.
[15:15] whaack: howdy
[15:16] whaack: how's Panama?
[15:49] dorion: it's pretty normal here.
[16:09] dorion: whaack, you been occupied with your venture w/ billymg ?
[16:10] dorion: any substantial change in the wrists ?
[16:24] whaack: dorion: yup, still grinding out that business.
[16:25] whaack: wrists are about the same, but i have a little stretching routine that has allowed me to push through and not have flareups, i'm back to surfing as well
[16:31] dorion: sounds like you're dealing with it the best you can, managing it and not letting it control you.
[16:43] whaack: yup, life is good. near 100k USD <-> btc ain't bad either eh
[16:52] lru: I suppose now is the time for me to buy...
[16:57] jfw: when lru buys, we'll know the top is in
[16:58] jfw: whaack: want to do a panama visit some time? atm I can offer a guest room and uncrowded kitchen to save you some expenses
[16:59] whaack: ohh that sounds quite nice, i would indeed like to
[17:00] whaack: haha lru: please announce when that is
[17:02] whaack: jfw: any preference on dates? I'm going to visit my mom dec 12 - 28th or so it seemns, probably easiest time for me would be to come before i come back to CR
[17:02] jfw: so around the new year?
[17:02] whaack: yup
[17:03] jfw: might work. I'll be heading north at some point too but timing depends on getting some stuff wrapped up here.
[17:06] jfw: now through early december is clear for me
[17:09] jfw: dorion: indeed the workstation and the apu1s are both fallow resources atm, and looks like either way requires some further parts & labor. previously we were talking about 1 apu to segregate some of our data but now you're thinking more of a fleet?
[17:11] jfw: I think quite a few could fit in the space, with some consideration to racking & cooling perhaps, but might need to renegotiate for it
[17:16] jfw: from anecdotal experience I'm not so hot on the apu1s, after the misadventures in running a bitcoind on the first test unit, though there's still the hypothesis that it was damaged from all the hands-on experimentation. at any rate they don't do ECC.
[17:16] jfw: it could be interesting at least to try more and get a bigger sample.
[17:17] jfw: iirc there were also the 2/7 that failed to boot after coreboot reflashing
[17:20] jfw: cruciform if tuned in: you're also welcome to come chill in panama
[17:21] jfw: the room is good for a single or couple, but there's plenty of hotels too running the gamut of prices
[17:22] jfw: mid december through march or so would be the high tourism season
[17:29] jfw: (meaning, more crowded roads & beaches, harder to get cars rented, minimal rain but still hot weather)
[21:43] whaack: sry for join/spart spam, signing off
Day changed to 2024-11-23
[20:57] jfw: http://jfxpt.com/2024/tradingview-dot-com-as-understood-through-the-platforms-playbook/
Day changed to 2024-11-24
[12:34] lru: what would a non-platform version of TradingView look like? basically a database that all users would need to start paying for access too from the beginning?
[17:47] jfw: if you mean, what would work as a business model, that sort of thing is easy to armchair-strategize but requires someone to put skin in the game to actually prove, and that's unlikely to happen while the neighbors are dumping a free-with-strings-attached version, at least not for the same audience.
[17:47] jfw: but to my mind an "honest" version would mean either dropping the "free" or dropping the "strings attached"
[17:48] jfw: you could perhaps publish the client software and charge something for the data access; not a lot though, it's hard to sell data as such beyond the cost of delivery because it's so easily replicated
Day changed to 2024-11-25
[17:42] jfw: http://jfxpt.com/2024/jwrd-logs-for-Nov-2024/#12657 - update: 415012 = 1.8 bpm since then.
[17:42] sourcerer: 2024-11-20 02:19:03 (#jwrd) jfw: though it's now at 400549 which puts it closer to 1.7 bpm average over the interval since that last reading, ETA 200 days, lol.
[19:31] jfw: http://jfxpt.com/2024/jwrd-logs-for-Nov-2024/#12599 - I'll add an option #5: add a new HDD pair, keeping the current pair but reformatting it with a RAID1 boot partition and RAID0 or linear (aka span/JBOD) data partition. That'll give a healthy 1.2T for the node and possibly some performance boost, keep it seek-independent from other applications, and maximize storage for the current satoshi
[19:31] sourcerer: 2024-11-15 04:32:32 (#jwrd) jfw: the limitation we still have on booting is that lilo can't install to a RAID1 over 2 TB. an upgrade option with minimal time and materials cost, then, is to keep the existing 600G RAID1 for a boot volume plus whatever application group might want its own "dedicated spindle"; then buy two max-size HDDs for a second RAID1 data volume.
[19:31] jfw: outlay.
[19:32] jfw: the node won't have block level redundancy, but it wouldn't in a single-SSD setup either, it can always be recovered, and arguably the HDDs are well proven and less likely to fail in the first place.
[19:35] jfw: I'm liking this one best atm.
[19:41] jfw: especially as it seems SATA SSD prices aren't really coming down at all.
[19:42] jfw: though apparently there's now such thing as a 1TB micro-SD card, and for 100 bones, wut
[21:00] dorion: http://jfxpt.com/2024/jwrd-logs-for-Nov-2024/#12699 -- sounds good, I'm liking that one too.
[21:00] sourcerer: 2024-11-25 19:31:06 (#jwrd) jfw: http://jfxpt.com/2024/jwrd-logs-for-Nov-2024/#12599 - I'll add an option #5: add a new HDD pair, keeping the current pair but reformatting it with a RAID1 boot partition and RAID0 or linear (aka span/JBOD) data partition. That'll give a healthy 1.2T for the node and possibly some performance boost, keep it seek-independent from other applications, and maximize stor
Day changed to 2024-11-26
[06:22] jfw: http://jfxpt.com/2024/jwrd-logs-for-Nov-2024/#12584 <-> http://jfxpt.com/2024/another-perplexing-curiosity-from-the-depths-of-scheme-macros/
[06:22] sourcerer: 2024-11-13 02:08:55 (#jwrd) jfw: yesterday I hit some perplexing curiosities in the depths of the Scheme macro semantics. Unearthed an old test case that still failed, and discovered that another I thought working only appeared so because I'd botched the test code. Both look rather difficult to fix and yet rather obscure and inconsequential. So today I've at least clarified the situation in mind a
[06:22] jfw: fixpoint is on fire this month, and it's not burnt out yet!
[06:23] jfw: there's also a sort of behind-the-scenes, fireside-chat expansion on that latest one, to finish revision.
[21:53] jfw: http://jfxpt.com/2024/that-in-a-word-is-the-corner-that-im-painted-into-even-though-this-seems-an-incredibly-obscure-situation-of-having-a-top-level-macro-which-inserts-a-top-level-definition-which-may-or-may-not-be/ and there it is.
Day changed to 2024-11-27
[21:30] jfw: dorion: yet another option to weigh on the storage is getting a SAS controller, which would let us standardize on SAS drives. to try it out we could even borrow the 3ware 9750-4i card from either of the idle supermicro boxen. supposedly those can be had for $50.
[21:33] jfw: funnily enough the SAS drives don't look any more expensive, eg 10TB SAS for $160 versus 8TB SATA for $150 even with 'black friday deal'
[21:34] jfw: I think around 8T is the sweet spot atm for a build that'll last a while
[21:37] jfw: we could even steal 2x 4TB SAS drives from that last build, but I'd rather not undo that installation work basically.
[21:46] jfw: I could install a controller on Friday, test it out with the existing SATA drives - that direction of mixing is supposed to be possible - and if all is well, order the new drives.
[21:47] jfw: and controller, so as not to leave us without a spare.
Day changed to 2024-11-30
[20:16] jfw: http://jfxpt.com/2024/jwrd-logs-for-Nov-2024/#12717 - worked just dandy, viva la 3ware.
[20:16] sourcerer: 2024-11-27 21:46:17 (#jwrd) jfw: I could install a controller on Friday, test it out with the existing SATA drives - that direction of mixing is supposed to be possible - and if all is well, order the new drives.
[20:18] jfw: technically I used the spare drive so as not to disrupt the existing array, and didn't map it all the way through to test from the OS, but it showed fine in the BIOS config utility, after some uefi config futzing to get that to display at all.
[20:23] jfw: so to recap, current plan is 2x 10TB or so SAS drives for a RAID1 - probably won't order a spare, figuring the N+1 plus active monitoring should buy enough time to replace when needed - one new controller of same model though possibly w/o battery, and redo the current 600G drives as RAID0 for the node.
[20:39] jfw: enabling the controller's write cache w/ battery would be a possible optimization if performance becomes a problem; but atm I don't like it because with the residential grade power grid I can't guarantee there's no outage that outlasts the battery leading to data loss/corruption.
[20:41] jfw: if we can rig up an impending-death signal from the external UPS to trigger shutdown, it would help.
[20:42] jfw: there's a usb cable for it but protocol is unclear.
[21:25] jfw: though now that I figured out the 'shingled' HDDs scam, I'm finding there's a "512e/4Kn" or "advanced format" thing afoot, pushing for large sectors
[22:39] jfw: possible troubles: some drives switched to 4k sectors while presenting themselves in 512-byte emulation mode, resulting in write performance penalties. some drives are 4k only, forcing software support at various levels. Some Seagate drives have a 'fastformat' which ships in 512e (emulation) by default but allows switching to 4k native, using not-sure-what software. the 3ware's interoperability
[22:39] jfw: list hasn't been updated since 2013 and its manuals from '09 say nothing about sector size, being from the simpler age when it was 512, end of story.
[22:41] jfw: util-linux fdisk can report physical + logical sector sizes, busybox fdisk not so.
[22:44] jfw: the supposed argument for large sectors is it slightly reduces header overhead (~10% capacity increase) and allows for more robust ECC - i.e. they're not otherwise able to make the medium reliable enough at current densities.
[23:06] jfw: https://www.seagate.com/blog/advanced-format-4k-sector-hard-drives-master-ti/ - sorta-ok overview (with broken images)
[23:15] jfw: and such "blog" with no comments, trackbacks or even article date... so I guess it's from around 2011 and they haven't shed any light on how the transition went outside the "laptop and desktop market segments".
[23:43] jfw: I reckon I'll go ahead with the new disks but skip ordering a new controller until it's proven with them.
[23:44] jfw: stick to 512-byte logical sectors but align the partitions to 4k (or even 1M as I would for an SSD), and hope the RAID controller doesn't throw off the alignment.