Fixpoint

Day changed to 2023-03-01
[00:45] dorion: http://fixpoint.welshcomputing.com/2023/jwrd-logs-for-Feb-2023/#6082 -- very good question. there is a level of trust, especially at the start. one's skills/knowledge determine the extent one can verify our claims about it, but a purpose of the training is to build the skills and, as jfw said, reproduce the system independently. One nice thing about the x200 is they are relatively easy to
[00:45] sourcerer: 2023-02-28 20:44:25 (#jwrd) sstacks: Hey guys. While i was reading the article about the hardware kit, it pops into my mind a question, maybe a silly one, but since you have gave me the confidence to ask anything ill just go ahead. -- Do we need to trust you in any way, regarding to the setup of the delivered hardware? Since the objective of this course is, indeed, looking for our personal sovereignty, I think its sound to make this question. Don't be offended in any way. After all, how could
[00:45] dorion: disassemble. As one example, one can verify for himself if the Wifi and Bluetooth cards have actually been extracted.
[00:46] dorion: ha, what are the chances sourcerer times out the same second I submit a message.
[00:48] jfw: that 'quits [Request too long]' looks interesting actually
[00:49] dorion: I'm not seeing your latest line either.
[00:53] jfw: from its log, the last thing it saw from the server was an "ERROR :Request too long", nothing relevant prior, then connection closing. it restarts and rejoins, seemingly successfully.
[00:58] jfw: ahh, its 'request' was in attempting to quote the linked line, which is 460 chars and ends up overflowing the 512 byte overall irc message limit once it adds on its context.
[00:58] jfw: still not sure why it's gone deaf now.
[01:01] jfw: huh, it actually got all the lines (old + new) in the raw log table
[01:02] jfw: perhaps it left the article update halfway-complete, breaking further updates, in getting disconnected. what with mysql not having invented transactions and all XD
[01:05] jfw: oh, lol, we're just not seeing the new lines because it turned over to March!
[01:06] jfw: so - sourcerer simply doesn't care about the irc message limit, its log is complete and we're the ones missing out on the quote it served!!
[01:08] dorion: http://fixpoint.welshcomputing.com/2023/jwrd-logs-for-Mar-2023/#6106 -- roflmao
[01:08] sourcerer: 2023-03-01 01:05:01 (#jwrd) jfw: oh, lol, we're just not seeing the new lines because it turned over to March!
[01:08] jfw: we probably didn't hit this before because yrc self-limits message lengths somewhat aggressively because I didn't work out how to do it 'correctly' if there is such a thing.
[01:33] dorion: http://fixpoint.welshcomputing.com/2023/jwrd-logs-for-Feb-2023/#6083 -- good point, and as diana_coman explained to whaack back in the day, asking questions, whaver they may be, is method of learning if you trust us and to what extent.
[01:33] sourcerer: 2023-02-28 20:44:25 (#jwrd) sstacks: someone ignorant in this matter learn if not through a third person who is willing to teach directly or indirectly . Just curious.
[01:38] dorion: http://fixpoint.welshcomputing.com/2023/jwrd-logs-for-Feb-2023/#6085 -- right. and there's lots of 3rd party code installed in the system, but we aim to lower the costs of checking, both for ourselves and other operators. if/when an error or bug is encountered, one has to decide what's the source of it and what to do about it, both in the moment for how to fix it and longer term, what updates of
[01:38] sourcerer: 2023-02-28 20:47:59 (#jwrd) sstacks: As for example, we know conventional computers arent safe since they are potentially backdoored
[01:38] dorion: one's trust model need to be made. here's an example : http://fixpoint.welshcomputing.com/2021/alert-dumpblock-flaw-in-bitcoind-can-cause-gbw-node-to-incorrectly-report-transactions/
[23:41] samy: thanks for replaying guys, ill check it out
[23:42] dorion: you're welcome. looks like your nick changed, the command /nick sstacks can restore it.
Day changed to 2023-03-02
[01:01] sstacks: whaack: http://fixpoint.welshcomputing.com/2023/jwrd-logs-for-Feb-2023/#6086. Thanks for the site. I see this intend to be a transparent bitcoin explorer. Which implies that other explorers are not being transparent. Ill check the articles you reference on the homepage.
[01:01] sourcerer: 2023-02-28 23:02:43 (#jwrd) whaack: sstacks: http://bitcoindexplorer.com/
[01:06] sstacks: whaack: http://fixpoint.welshcomputing.com/2023/jwrd-logs-for-Feb-2023/#6088. This is a great advise. Building my own hardware. Maybe this could be a good goal in a near future. Just need to get equipped from my guys from #jwrd
[01:06] sourcerer: 2023-02-28 23:10:14 (#jwrd) whaack: sstacks: re your question above, my thought is you're trying to reduce the amount of trust you need. if you had the resources maybe you could build your own machines, proofread the whole bitcoin codebase + all its dependencies, work through every math proof yourself. that's an ideal you want to try to get as close to as you can but even though you can't get 100% that doesn't mean to go to 0% either. this is a long winded way of saying that yes you probably a
[01:16] sstacks: http://fixpoint.welshcomputing.com/2023/jwrd-logs-for-Feb-2023/#6089. Indeed. I havent seen this course anywhere. Maybe it because im not part of the dev "scene" of Bitcoin (nor anything similar in that matter). I am very expectant in this journey with the aim of finding a way to market this course so that more bitcoiners without a technical and programming background are interested in it.
[01:16] sourcerer: 2023-02-28 23:10:14 (#jwrd) whaack: t this point need to put some trust in jwrd , however afaik no one on the market offers a course+hardware system where the trust is more reduced than their service.
[01:18] sstacks: jfw: http://fixpoint.welshcomputing.com/2023/jwrd-logs-for-Feb-2023/#6090. I hope I can reach such a point of understanding.
[01:18] sourcerer: 2023-02-28 23:15:13 (#jwrd) jfw: sstacks: no offense taken, it's a fine question and yes, you are implicitly trusting us regarding the software and even to some degree hardware of the machines, and some such leap of faith is going to be necessary no matter what if you want to get anywhere. the idea with our training is to get you to the point where you don't even need to trust our installation anymore and can reproduce the full
[01:25] sstacks: jfw: http://fixpoint.welshcomputing.com/2023/jwrd-logs-for-Feb-2023/#6092. I havent dont my dutty on making a research on "you" as JWRD. Just had it for granted since i met Robinson, and its not the kind of guy I wouldn't trust. Although to be fair, I haven't shown good judgment in my partnership history in the past. I dont feel at all suspicious. Just thought it would be a fair question to bring to the table.
[01:25] sourcerer: 2023-02-28 23:18:38 (#jwrd) jfw: as far as evaluating us, there's the history of our actions and interactions to look at, of which quite a lot is visible online and deliberately preserved, which is perhaps not immediately obvious and unfortunately rather unusual these days.
[01:44] sstacks: jfw: But what I do recognize that you both have fair amount of exposure online with no apparent bad-practice report
[02:01] sstacks: whaack: http://ztkfg.com/2021/07/warning-bitcoins-stored-in-segwit-addresses-are-not-safe/ loved this. Its very complementary with http://dorion-mode.com/2021/11/the-bitcoin-address-as-a-sign-of-intelligence/ I think this are very different styles of redaction. Btw, as a christian theologian, I do admire the importance and care that Jacob puts on words (regarding to the commentaries section of your article). We are in a society where words have lost the
[02:01] sstacks: importance of their true meaning and have simply adopted light forms of communication where the meaning of words is diluted (at best) and at worst, has been distorted. .
[02:56] sstacks: whaack: The 3rd possible outcome is trb becomes economically irrelevant. Perhaps the segwit users/bitcoin core team manage to pull off a hard fork that wins in the market place, or trb nodes all go offline. Revisionist history wins, and the roots of Bitcoin fade away into the cosmos.
[02:56] sstacks: whaack: this 3rd possible outcome from your article (http://ztkfg.com/2022/01/the-possible-outcomes-of-segwit/).. is quite scary.
[12:44] sstacks: whaack: http://ztkfg.com/2020/01/panama-bien-vestido/ Im glad you had a great time in Panamá. Dorion's "Bien Vestido" reasons are actually legit. Great read.
[14:36] whaack: ty sstacks. will respond later, i can only type w my left hand atm
[14:37] whaack: surgery went well, ill know in about 1 month if it relieves my symptoms
[15:41] sstacks: whaack: im glad everything went well.. isnt that cool that you have to wait for a whole month to find out if it was effective though. Dont worry for response! Get well soon my friend
[15:42] whaack: tyty
[17:34] jfw: sstacks: http://fixpoint.welshcomputing.com/2023/jwrd-logs-for-Mar-2023/#6129 - hey thank you for the kind observation. I'm no theologian but I guess you could say I'm a ...philologian! or at the least, one of those old-culture types (what "old-fashioned"?) that uses words for their meanings rather than the sounds they make, or
[17:34] sourcerer: 2023-03-02 02:01:17 (#jwrd) sstacks: whaack: http://ztkfg.com/2021/07/warning-bitcoins-stored-in-segwit-addresses-are-not-safe/ loved this. Its very complementary with http://dorion-mode.com/2021/11/the-bitcoin-address-as-a-sign-of-intelligence/ I think this are very different styles of redaction. Btw, as a christian theologian, I do admire the importance and care that Jacob puts on words (regarding to the commentaries section of your article). We are in a society where words have lost the
[17:34] jfw: as if they were soup ingredients - it comes up a lot, I guess there are many who live in such a soup.
[17:39] jfw: (funny, now the overlength quote shows in channel with a "[CUT]" and the bot wasn't kicked. this is possibly annoying me enough to get a proper fix soon)
[17:48] jfw: whaack: good that it went well. I'm mildly curious what ligament that was (as an anatomy novice who just recently learned the T-bone is a lateral process of the vertebra through which the tenderloin is connected ventral to the NY strip)
[17:51] jfw: http://fixpoint.welshcomputing.com/2023/jwrd-logs-for-Mar-2023/#6132 - good, then I guess you won't need much further convincing as to why run a node (and I know you tried the 'umbrel' thing already)
[17:51] sourcerer: 2023-03-02 02:56:41 (#jwrd) sstacks: whaack: this 3rd possible outcome from your article (http://ztkfg.com/2022/01/the-possible-outcomes-of-segwit/).. is quite scary.
[17:53] jfw: that's only a start of course, a machine does not in itself make for economic relevance however well oiled it may be.
[18:42] jfw: woah, irssi was originally from Timo Sirainen, of dovecot notoriety
[18:43] whaack: jfw: they cut the transverse carpal ligament
[18:44] whaack: the ligament is supposed to heal, leaving more room in the tunnel when it reconnects to itself
[18:52] whaack: sstacks: the good thing is that we have agency and can possibly prevent situation 3, albeit with a large amount of work. if you read the first recommended reading from the hw you can see a previous attempt to promote trb that failed to establish traction
[21:06] jfw: whaack: I see, I had in mind some kind of narrow fiber running through the tunnel in parallel with the nerves but rather it's a broad thing going across and covering them up.
[21:07] jfw: I guess it's involved in contracting the palm where the thumb & pinky sides bend inwards/together
[21:10] jfw: I found the line splitting length calculation for irssi is in src/irc/core/irc-servers.c, function "split_message", which cites a "splitlong_safe.pl", which is a googlebomb but probably close to splitlong.pl from an irssi scripts collection
[21:13] jfw: the calculation matches what I get from looking at the forwarded message format from the server; the hard part is figuring the length of the nick and userhost ("username@address")
[21:14] jfw: the nick I believe isn't possible to know for sure because it can be changed asynchronously by the server, but if we ignore that detail as they seem to do it's readily available
[21:17] jfw: the client is never actually told its own userhost in any protocol-standard way by the server, though in practice it seems to show in the welcome message (reply 001) - and irssi punts by assuming the maximum based on "63 is the maximum hostname length defined by the protocol. 10 is a common username limit on many networks."
[21:22] jfw: ah, the client also happens to get its userhost reflected when joining a channel
[21:31] jfw: possibly it can also change after registration eg due to cloaking, and can be explicitly queried with a USERHOST message
[21:34] jfw: the [CUT] I'm guessing came from the irc server where the bot's message didn't itself overflow but the server's forwarded version with the added fields would have.
[21:35] jfw: dorion: what do you figure the bot should log in case of quoted message overflow like that - the truncated version as would be seen by people in the channel, or the full version which it has and in principle could record in full in its log
[21:36] jfw: I'd think it should be the truncated version for consistency's sake, eg if you try to reconcile local with bot logs
[21:37] jfw: this in turn determines whether the bot can truncate simply based on the 512-byte limit on its own outbound messages, risking that it still gets [CUT] by the server
[21:47] jfw: that hostname length limit 63 is nowhere to be found in the original irc spec rfc1459, possibly it's in the later extended ones. the 10-byte username limit seems to hold here, actually 9 including a leading ~
[21:50] jfw: so since irssi was certainly widely used, and its line splitting seemed to work fine in practice, I'm inclined to just copy its magic 63/10 limit for simplicity. especially given the context that irc as a whole is on life support here.
[21:57] jfw: only remaining wrinkle perhaps is the iterated-prototype bot doesn't track its own nick as acknowledged by the server. it could just go with its configured/intended one, worst case it'll get the [CUT] treatment but at least not the disconnect for invalid message.
[22:31] whaack: howdy jfw, it would be fairly hard to get anything running in parallel with the nerve out of the way, i imagine
[22:32] whaack: i have a little use of my right hand already, 30 hours out of surgery :)
Day changed to 2023-03-03
[04:57] jfw: whaack: sounds good but do take it easy!
[05:01] jfw: http://fixpoint.welshcomputing.com/2023/jwrd-logs-for-Mar-2023/#6155 << something seems wrong about this, because I'm seeing examples not only of hexchat users but a reported irssi user producing messages upwards of 460 characters, while according to this theory the max should be 510-strlen(":! PRIVMSG :")-strlen(nick)-strlen(target)-64-10 or 423 not even counting nick+target
[05:01] sourcerer: 2023-03-02 21:17:33 (#jwrd) jfw: the client is never actually told its own userhost in any protocol-standard way by the server, though in practice it seems to show in the welcome message (reply 001) - and irssi punts by assuming the maximum based on "63 is the maximum hostname length defined by the protocol. 10 is a common username limit on many networks."
[05:04] jfw: which would be roughly equal to yrc's static 400 byte limit
[05:07] jfw: aha, they changed it even as of the 0.8.20 I was referencing, and indeed in part because of the cloaking complication.
[05:10] jfw: tbh it really sounds like a case of "irc is broken, message sizing can't be done correctly so yrc is smart to do it wrong but cheaply"
[06:02] jfw: xchat (line 4135) and hexchat (fork of xchat) variants. they look off-by-one in several instances, possibly the multiple mistakes cancelling out, lolz. but at core they're using the stored nick + hostname where available and falling back to the
[06:02] jfw: ~64+10 limit otherwise.
[06:05] jfw: (with a terribly named field 'hostname' rather than 'userhost'.)
[17:17] jfw: dorion: on the costs side of the stupid fixed length limit, it still doesn't 100% guarantee full delivery eg if the hostname really does take up 63 bytes and the nick and channel name are long enough too, and there's the situation that [][] links can get split across lines due to spaces in the text part which is all the more likely the smaller the line limit gets. and in general it's bothersome
[17:17] jfw: not to be able to make full use of the available space while the other clients are, with their respective low-probability failure modes.
[17:22] jfw: the way I'd do it in yrc, if I did, would be liberal use of that USERHOST query: on initial registration if the welcome doesn't match expected format; each time an unrecognized message type is received from the server; immediately following outbound messages and perhaps other client commands; and on a regular timer, replacing the current use of PING.
[17:23] jfw: in any case it would only go out if there wasn't already an existing query in-flight.
[17:29] jfw: this would somewhat improve the message-delivery feedback since the 'ping:' in the status bar would start counting each time you sent a message, so if it starts climbing you get an early clue that the message might not be delivered. this can't be done fully reliably because of the sorta-decentralized situation ie getting to one server doesn't ensure a message gets to all clients.
[17:30] jfw: the resulting userhost would be displayed along with nick as the leftmost status bar field ie in nick!user@host format.
[17:32] jfw: on the bot side, this all seems like overkill for sure and it should simply http://fixpoint.welshcomputing.com/2023/jwrd-logs-for-Mar-2023/#6161
[17:32] sourcerer: 2023-03-02 21:37:56 (#jwrd) jfw: this in turn determines whether the bot can truncate simply based on the 512-byte limit on its own outbound messages, risking that it still gets [CUT] by the server
[17:37] jfw: incidentally, even across the atlantic the bot's been staying connected fine so far without sending active pings of its own.
[20:26] dorion: http://fixpoint.welshcomputing.com/2023/jwrd-logs-for-Feb-2023/#6074 -- good to see he found himself a full time documentation role he seems to be satisfied with.
[20:26] sourcerer: 2023-02-28 03:44:46 (#jwrd) jfw: dorion, whaack: well, BingoBoingo's still online - sorta
[20:31] dorion: sent him a linkedin as he said it's his preferred contact point.
[20:33] dorion: http://fixpoint.welshcomputing.com/2023/jwrd-logs-for-Feb-2023/#6088 -- well said.
[20:33] sourcerer: 2023-02-28 23:10:14 (#jwrd) whaack: sstacks: re your question above, my thought is you're trying to reduce the amount of trust you need. if you had the resources maybe you could build your own machines, proofread the whole bitcoin codebase + all its dependencies, work through every math proof yourself. that's an ideal you want to try to get as close to as you can but even though you can't get 100% that doesn't mean to go to 0% either. this is a long winded way of saying that yes you probably a
[20:36] dorion: http://fixpoint.welshcomputing.com/2023/jwrd-logs-for-Feb-2023/#6093 -- while in the shadows, we were in Panama. so one thing that's easier for you to do sstacks is ask around locally. see who has something negative to say about us and what it is. if something bad/questionable does come up, feel free to bring those comments here and we can talk through them in public.
[20:36] sourcerer: 2023-02-28 23:24:37 (#jwrd) jfw: we have less visibility prior to 2019, as we were grinding away in the seeming safety & comfort of the shadows, basically in the habit of overvaluing the costs and undervaluing the benefits of public engagement, which was one of the first things we had to come to grips with in Young Hands Club.
[20:37] dorion: link to http://younghands.club/ if you didn't know it already or at least for the log.
[20:58] dorion: http://fixpoint.welshcomputing.com/2023/jwrd-logs-for-mar-2023/#6118 -- I'm not so sure the other blockexplorers lack transparency in the data per se, but more about their political stance. while whaack's provide links to entry points of the political divide, they don't acknowledge, afaict, there even is a political divide. from this political divide, there is a divergence in the data however. for
[20:58] sourcerer: 2023-03-02 01:01:11 (#jwrd) sstacks: whaack: http://fixpoint.welshcomputing.com/2023/jwrd-logs-for-Feb-2023/#6086. Thanks for the site. I see this intend to be a transparent bitcoin explorer. Which implies that other explorers are not being transparent. Ill check the articles you reference on the homepage.
[20:58] dorion: example, you might find some lamestream explorers report that various bitcoin blocks are greater than 1mb. which is impossible w/o causing a hardfork because satoshi hardcoded the 1mb blocksize limit.
[21:03] dorion: (someone feel free to correct me if I linked to the wrong part of the code, but looksgoodtome.jpg)
[21:03] dorion: hardcoded magic numbers for better and worse, but nevertheless, they haven't changed.
[21:20] dorion: the political divide is, of course, the reference implementation of bitcoind we maintain doesn't recognize any of the softforks injected to subvert bitcoin after satoshi.
[21:27] dorion: as for the data divergence, a recent example that bubbled up is block 774628. reported in the "Roger Ver presents the lamestream noose" and, e.g. 'blockcypher' (if you enable the javascript turds they serve you from their domain, ajax.googleapis.com ~and~
[21:27] dorion: bootstrapcdn.com (can't be one or the other, has to be both, derp)) as being a 3`955`272 byte block.
[21:33] dorion: while whaack's shows that sucker to weigh in at "size_bytes: 12499". same exact blockhash. so wut gives ? sha256 collison ?!? mnope, sorry charlie, not today. blockcypher pretends there's an extra 3`942`773 bytes in the block (3+ full blocks worth) that isn't !
[21:37] dorion: http://fixpoint.welshcomputing.com/2023/jwrd-logs-for-mar-2023/#6193 -- probably at the end you can argue they aren't transparent about how they lie about shit being in the blockchain that isn't.
[21:37] sourcerer: 2023-03-03 20:58:47 (#jwrd) dorion: http://fixpoint.welshcomputing.com/2023/jwrd-logs-for-mar-2023/#6118 -- I'm not so sure the other blockexplorers lack transparency in the data per se, but more about their political stance. while whaack's provide links to entry points of the political divide, they don't acknowledge, afaict, there even is a political divide. from this political divide, there is a divergence in the data however. for
[21:37] dorion: the other part about the "no bullshit" in whaack's is no javascript.
[21:38] dorion: whaack, btw, http://bitcoindexplorer.com/?args= produces "500 Internal Server Error"
[21:39] dorion: http://fixpoint.welshcomputing.com/2023/jwrd-logs-for-mar-2023/#6122 -- we look forward to your marketing advise, for sure.
[21:39] sourcerer: 2023-03-02 01:16:34 (#jwrd) sstacks: http://fixpoint.welshcomputing.com/2023/jwrd-logs-for-Feb-2023/#6089. Indeed. I havent seen this course anywhere. Maybe it because im not part of the dev "scene" of Bitcoin (nor anything similar in that matter). I am very expectant in this journey with the aim of finding a way to market this course so that more bitcoiners without a technical and programming background are interested in it.
[21:40] dorion: http://fixpoint.welshcomputing.com/2023/jwrd-logs-for-mar-2023/#6126 -- thanks, don't hesitate to raise doubts any that bubble up in the future either.
[21:40] sourcerer: 2023-03-02 01:25:39 (#jwrd) sstacks: jfw: http://fixpoint.welshcomputing.com/2023/jwrd-logs-for-Feb-2023/#6092. I havent dont my dutty on making a research on "you" as JWRD. Just had it for granted since i met Robinson, and its not the kind of guy I wouldn't trust. Although to be fair, I haven't shown good judgment in my partnership history in the past. I dont feel at all suspicious. Just thought it would be a fair question to bring to the table.
[21:40] dorion: http://fixpoint.welshcomputing.com/2023/jwrd-logs-for-mar-2023/#6130 -- agreed
[21:40] sourcerer: 2023-03-02 02:01:17 (#jwrd) sstacks: importance of their true meaning and have simply adopted light forms of communication where the meaning of words is diluted (at best) and at worst, has been distorted. .
[21:48] dorion: http://fixpoint.welshcomputing.com/2023/jwrd-logs-for-mar-2023/#6132 -- the thing about this in the meantime/while the battle is being waged though is if there is a hardfork and you have coins in valid bitcoin addresses (P2PKH, start with 1), you'd have coins on both sides of the "hardfork". enforcing the satoshi rules feels like a hardfork to softforkers. hardforks loosen the rules and softforks
[21:48] sourcerer: 2023-03-02 02:56:41 (#jwrd) sstacks: whaack: this 3rd possible outcome from your article (http://ztkfg.com/2022/01/the-possible-outcomes-of-segwit/).. is quite scary.
[21:48] dorion: tighten them. so if the tight rules their using are loosened, it feels like they're being fucked hard. but to the satoshi rules, it's business as it has been since satoshi last published.
[21:49] dorion: or did I mean "feels like they're being forked hard". /me shruggs.
[21:56] dorion: whereas if you have "anyonecanspend" coins (start with 3 or bc1), you only have coins on the softfork chain. so if you have all your coins in 1 addresses, go offline for 3, 4, 5 block halvings --or however long it takes to pop dat booty-- and come back, your best odds of having spendable outputs are if they're in P2PKH addresses. independent of which rule set wins out. unless I'm missing a way
[21:56] dorion: they could invalidate those addresses. for all anyone knows though, all coins mined by satoshi are laying in wait to sink the softfork as soon as the booty is fat enough. he said his peace once, he might fire the gun next time around. or maybe he's dead. in any case, place your bets before ~alea
[21:56] dorion: iacta est~ and all that.
[21:58] dorion: http://fixpoint.welshcomputing.com/2023/jwrd-logs-for-mar-2023/#6133 -- ty. so you know, only ASCII characters show up here (man ascii), i.e. no acccents or tildes.
[21:58] sourcerer: 2023-03-02 12:44:08 (#jwrd) sstacks: whaack: http://ztkfg.com/2020/01/panama-bien-vestido/ Im glad you had a great time in Panam??. Dorion's "Bien Vestido" reasons are actually legit. Great read.
[21:59] dorion: http://fixpoint.welshcomputing.com/2023/jwrd-logs-for-mar-2023/#6135 -- glad to hear you're doing okay post-op. best advice I have is to be patient and rest up.
[21:59] sourcerer: 2023-03-02 14:37:54 (#jwrd) whaack: surgery went well, ill know in about 1 month if it relieves my symptoms
[22:07] dorion: http://fixpoint.welshcomputing.com/2023/jwrd-logs-for-mar-2023/#6160 -- makes sense to me. and the link is right there when people want to navigate for the full context.
[22:07] sourcerer: 2023-03-02 21:36:33 (#jwrd) jfw: I'd think it should be the truncated version for consistency's sake, eg if you try to reconcile local with bot logs
[22:08] dorion: http://fixpoint.welshcomputing.com/2023/jwrd-logs-for-mar-2023/#6163 -- word.
[22:08] sourcerer: 2023-03-02 21:50:34 (#jwrd) jfw: so since irssi was certainly widely used, and its line splitting seemed to work fine in practice, I'm inclined to just copy its magic 63/10 limit for simplicity. especially given the context that irc as a whole is on life support here.
[22:10] dorion: oh, there was more coming.
[22:16] dorion: http://fixpoint.welshcomputing.com/2023/jwrd-logs-for-mar-2023/#6172 -- yeah, I think the more strategic next steps for yrc would be to replace the IRC parts w/ e2 chat.
[22:16] sourcerer: 2023-03-03 05:10:40 (#jwrd) jfw: tbh it really sounds like a case of "irc is broken, message sizing can't be done correctly so yrc is smart to do it wrong but cheaply"
[22:30] dorion: there was a sidebar in one of the swamps going on w/ sstacks while I was working on the above. for interested parties : http://welshcomputing.com/paste/tyjpn6448z
Day changed to 2023-03-04
[01:21] jfw: http://fixpoint.welshcomputing.com/2023/building-r-on-centos-6/
[01:32] jfw: http://fixpoint.welshcomputing.com/2023/jwrd-logs-for-Mar-2023/#6199 - pretty lulzy news link, complete with the ad images ineptly splayed on top of the text, all it's missing is the <blink> tags!
[01:32] sourcerer: 2023-03-03 21:27:19 (#jwrd) dorion: as for the data divergence, a recent example that bubbled up is block 774628. reported in the "Roger Ver presents the lamestream noose" and, e.g. 'blockcypher' (if you enable the javascript turds they serve you from their domain, ajax.googleapis.com ~and~
[01:36] jfw: "In addition to the stir caused by the Wizard-block Ordinal, an unsavory image was inscribed into inscription #668. Although the image was removed from the Ordinals website, it remains immutable and cannot be removed from the Bitcoin blockchain." - sounds like a decidely non-transparent NFT explorer; then, since I gather none of this is in fact in the bitcoin blockchain but only the segregated
[01:36] jfw: cattle pens, someone should tell them about the "pruning nodes" which I imagine are prevalent there. immutable huh?
[01:45] jfw: http://fixpoint.welshcomputing.com/2023/jwrd-logs-for-Mar-2023/#6216 - I guess they do a soft fork whereby "transactions from 1-addresses are no longer valid", there'd have to be some advance warning though; not sure if there'd be a way to split the coins if the fork didn't actually manifest (ie to keep your 1-bitcoins while also keeping them in bc1-anyonecanspend on scam-chain)
[01:45] sourcerer: 2023-03-03 21:56:03 (#jwrd) dorion: whereas if you have "anyonecanspend" coins (start with 3 or bc1), you only have coins on the softfork chain. so if you have all your coins in 1 addresses, go offline for 3, 4, 5 block halvings --or however long it takes to pop dat booty-- and come back, your best odds of having spendable outputs are if they're in P2PKH addresses. independent of which rule set wins out. unless I'm missing a way
[01:46] jfw: *they could do
[01:51] jfw: sounds like a self-defeating softfork though - the total absence of block space supply would promptly create huge fee pressure for transactions from remaining 1-addresses, which miners would be incentivized to capture through defection, which they could do without the risks of unwinding segshit.
[02:04] jfw: http://fixpoint.welshcomputing.com/2023/jwrd-logs-for-Mar-2023/#6227 - heh. there wasn't at the time, but it turned out to be a "blink and you missed it" question.
[02:04] sourcerer: 2023-03-03 22:10:48 (#jwrd) dorion: oh, there was more coming.
[02:12] jfw: sstacks, since you say you want to strenghten your english, I can do my part to point out your errors in chat
[02:20] jfw: "sstacks: I have loads of mirceas' articles tabs on my browser, but i recognize its not easy for me to understand. I usually read it, then translate the page to get full grasp info." - *mircea's articles' tabs ; it's ; to get a full grasp of the info. but primarily I'm quoting this to point out that this is the case for native speakers too, for trilema articles that is; between the footnotes,
[02:20] jfw: internal & external references, uncommon words, and multilingual parts, on top of (or rather, supporting) the complexity of what's being communicated, and the emotional triggers laced throughout, at least for those with the buttons to be pushed.
[02:22] jfw: nothing wrong with a machine translation as a quick aid but best to add a good dictionary at least to the ready reference material. (what's a good dictionary? don't think I found one yet)
[02:30] jfw: "sstacks: So i was also thinking about this common denominator of your space of having a blog. Interested to know about rationale behind it." - I'd say the blog is what you get when you combine 1) talking in public, 2) properly structuring information, building up a structure of meaning over time, and 3) owning your own content as dorion mentioned.
[02:30] jfw: and as to blogging as an activity, it's important for building the muscle of intellectual fitness
[02:33] jfw: it maximizes the leverage of your words (and the effort spent on finding them) as it allows you to conveniently reference them whenever needed as well as deliver them to any number of readers for a modest cost.
[02:34] jfw: nonetheless, the intellectual part of that cost is too much for most and so they end up on the Platforms, where the words accrue instead toward serving the owners of the platform.
[02:36] jfw: http://fixpoint.welshcomputing.com/2023/jwrd-logs-for-Mar-2023/#6242 - *strengthen, lolz.
[02:36] sourcerer: 2023-03-04 02:12:25 (#jwrd) jfw: sstacks, since you say you want to strenghten your english, I can do my part to point out your errors in chat
[17:18] jfw: http://fixpoint.welshcomputing.com/2023/jwrd-logs-for-Mar-2023/#6228 - I expect that's going to take several steps at least, that is, not exactly comparable difficulty to tweaking the existing irc support. it'll also take some thinking and/or time to clarify the goals of such a project
[17:18] sourcerer: 2023-03-03 22:16:45 (#jwrd) dorion: http://fixpoint.welshcomputing.com/2023/jwrd-logs-for-mar-2023/#6172 -- yeah, I think the more strategic next steps for yrc would be to replace the IRC parts w/ e2 chat.
[17:21] jfw: like, is it basically to be a lightweight eulora2 client? to be a near-drop-in replacement for irc? full security or a 2-tier thing where some gateway has the rsa keys and the light clients connect by plain password or similar?
[17:22] jfw: does it need to run on gales? if going for full security, does that force pulling in gnat, or better to rewrite parts of eucore in a less demanding language?
[17:25] jfw: do we implement a server component too so we can offer it independently as a service (as we could in theory with ircd) or is it fully tied to the e2 WoT and services?
[17:28] jfw: or there's the p2p route of course.
[18:12] jfw: testing reference to long line
[18:12] sourcerer: 2023-02-28 23:10:14 (#jwrd) whaack: sstacks: re your question above, my thought is you're trying to reduce the amount of trust you need. if you had the resources maybe you could build your own machines, proofread the whole bitcoin codebase + all its dependencies, work through every math proof yourself. that's an ideal you want to try to get as close to as you can but even though you can't get 100%
[18:13] jfw: and recursively to where the bot was last disconnected for overflow on quoting it, http://fixpoint.welshcomputing.com/2023/jwrd-logs-for-Mar-2023/#6121
[18:13] sourcerer: 2023-03-02 01:06:16 (#jwrd) sourcerer: 2023-02-28 23:10:14 (#jwrd) whaack: sstacks: re your question above, my thought is you're trying to reduce the amount of trust you need. if you had the resources maybe you could build your own machines, proofread the whole bitcoin codebase + all its dependencies, work through every math proof yourself. that's an ideal you want to try to get as close to as you
[18:15] jfw: now the bot owns the bottleneck (going with the same magic 400-byte limit as in yrc) so it's no longer disconnected and its log agrees with what we see in channel.
[18:19] jfw: sstacks: it's best to include a delimiter (i.e. a space) before any further characters at the end of links you paste, because for instance dot and close-parenthesis are valid URL characters so the machines don't know you didn't mean them as part of the link, so it comes out a broken link.
[18:20] jfw: if unsure you can always try and see how it shows on the web log.
[18:21] jfw: for example, see http://fixpoint.welshcomputing.com/2023/jwrd-logs-for-Mar-2023/#6132 in browser and try to click the link.
[18:21] sourcerer: 2023-03-02 02:56:41 (#jwrd) sstacks: whaack: this 3rd possible outcome from your article (http://ztkfg.com/2022/01/the-possible-outcomes-of-segwit/).. is quite scary.
[18:25] jfw: dorion: one approach if we're ok with the 2-tiered setup would be an extended, non-gui version of the eulora client that acts as a simple irc server, allowing existing clients and bots to be bridged in.
[18:25] sourcerer: 2023-03-04 17:21:01 (#jwrd) jfw: like, is it basically to be a lightweight eulora2 client? to be a near-drop-in replacement for irc? full security or a 2-tier thing where some gateway has the rsa keys and the light clients connect by plain password or similar?
[18:25] jfw: there'd be some inherent mismatch in the tcp vs udp view of the world.
[18:30] jfw: (and line length limits of course!)
[18:56] dorion: http://fixpoint.welshcomputing.com/2023/jwrd-logs-for-mar-2023/#6252 -- oh fo sho. by strategic next steps I didn't mean it's a high priority atm, given all the other stuff to do. but in the end I don't see much sense in supporting 2 chat protocols, esp when e2 chat so much superior.
[18:56] sourcerer: 2023-03-04 17:18:04 (#jwrd) jfw: http://fixpoint.welshcomputing.com/2023/jwrd-logs-for-Mar-2023/#6228 - I expect that's going to take several steps at least, that is, not exactly comparable difficulty to tweaking the existing irc support. it'll also take some thinking and/or time to clarify the goals of such a project
[18:58] dorion: http://fixpoint.welshcomputing.com/2023/jwrd-logs-for-mar-2023/#6254 , http://fixpoint.welshcomputing.com/2023/jwrd-logs-for-mar-2023/#6255 , http://fixpoint.welshcomputing.com/2023/jwrd-logs-for-mar-2023/#6256 -- all important questions, that I don't have the answers to now, but good to have them written out.
[18:58] sourcerer: 2023-03-04 17:21:01 (#jwrd) jfw: like, is it basically to be a lightweight eulora2 client? to be a near-drop-in replacement for irc? full security or a 2-tier thing where some gateway has the rsa keys and the light clients connect by plain password or similar?
[18:58] sourcerer: 2023-03-04 17:22:36 (#jwrd) jfw: does it need to run on gales? if going for full security, does that force pulling in gnat, or better to rewrite parts of eucore in a less demanding language?
[18:58] sourcerer: 2023-03-04 17:25:08 (#jwrd) jfw: do we implement a server component too so we can offer it independently as a service (as we could in theory with ircd) or is it fully tied to the e2 WoT and services?
[18:59] dorion: http://fixpoint.welshcomputing.com/2023/jwrd-logs-for-mar-2023/#6262 -- nice.
[18:59] sourcerer: 2023-03-04 18:15:27 (#jwrd) jfw: now the bot owns the bottleneck (going with the same magic 400-byte limit as in yrc) so it's no longer disconnected and its log agrees with what we see in channel.
[19:02] dorion: http://fixpoint.welshcomputing.com/2023/jwrd-logs-for-mar-2023/#6271 -- to expand a bit more, given e2's reference implementation is good enough for now, the higher priorities for us there now are the write ups we promised to Diana already.
[19:02] sourcerer: 2023-03-04 18:56:43 (#jwrd) dorion: http://fixpoint.welshcomputing.com/2023/jwrd-logs-for-mar-2023/#6252 -- oh fo sho. by strategic next steps I didn't mean it's a high priority atm, given all the other stuff to do. but in the end I don't see much sense in supporting 2 chat protocols, esp when e2 chat so much superior.
[19:09] dorion: http://fixpoint.welshcomputing.com/2023/jwrd-logs-for-mar-2023/#6267 -- there's an idea, but as you say, there's lots of difficulties to work out. It looks like scratching the bottleneck itch on the bot was done done rather efficiently, but so you know, I meant the original comment about strategic next steps to downshift yrc work atm, not drop the clutch, lol. I shoulda been more explicit. the
[19:09] sourcerer: 2023-03-04 18:25:17 (#jwrd) jfw: dorion: one approach if we're ok with the 2-tiered setup would be an extended, non-gui version of the eulora client that acts as a simple irc server, allowing existing clients and bots to be bridged in.
[19:09] dorion: questions that came out are good, but pump the brakes on it for now is all.
[19:35] jfw: dorion: I think we're on the same page, I just shared my thoughts on the e2 chat roadmap since you brought it up, meanwhile fixing the bot because it was broken right now.
[19:36] jfw: while not adding the contemplated complications to yrc for more precise message sizing.
[19:43] dorion: cool.
[22:24] jfw: sstacks, whaack: for the extra motivation & accountability or simply help keeping track: http://jwrd.net/group/8/key-management/progress-grp8.html
[22:26] dorion: jfw, I like it.
[22:48] jfw: updated to pull out the session number & add dates.
Day changed to 2023-03-05
[23:43] sstacks: http://fixpoint.welshcomputing.com/2023/jwrd-logs-for-Mar-2023/#6190 -- I could do this. I would just to probe the general feeling towards jwrd. Sincerely Im feeling curious as well, what people think too. Im quite surprised that general feeling towards the fact of trusting miners is acceptable.
[23:43] sourcerer: 2023-03-03 20:36:54 (#jwrd) dorion: http://fixpoint.welshcomputing.com/2023/jwrd-logs-for-Feb-2023/#6093 -- while in the shadows, we were in Panama. so one thing that's easier for you to do sstacks is ask around locally. see who has something negative to say about us and what it is. if something bad/questionable does come up, feel free to bring those comments here and we can talk through them in p
[23:47] sstacks: http://fixpoint.welshcomputing.com/2023/jwrd-logs-for-Mar-2023/#6206 -- Will do my friend.
[23:47] sourcerer: 2023-03-03 21:39:14 (#jwrd) dorion: http://fixpoint.welshcomputing.com/2023/jwrd-logs-for-mar-2023/#6122 -- we look forward to your marketing advise, for sure.
[23:49] dorion: http://fixpoint.welshcomputing.com/2023/jwrd-logs-for-Mar-2023/#6290 -- they likely don't realize they're trusting miners. they've generally not done the due dilligence to reveal such facts. in my experience, sharing such information triggers cognitive dissonance because they've not heard it from the lamestream they've become emotionally attached to. common responses are, "it wouldn't be in the
[23:49] sourcerer: 2023-03-05 23:43:01 (#jwrd) sstacks: http://fixpoint.welshcomputing.com/2023/jwrd-logs-for-Mar-2023/#6190 -- I could do this. I would just to probe the general feeling towards jwrd. Sincerely Im feeling curious as well, what people think too. Im quite surprised that general feeling towards the fact of trusting miners is acceptable.
[23:49] dorion: miners' interests" and "well why haven't they done it yet ?"
[23:54] sstacks: http://fixpoint.welshcomputing.com/2023/jwrd-logs-for-Mar-2023/#6242 -- Thanks my friend. So whenever I dont have an spelling mistake, might be because Im getting help from our friends at Google Translate
[23:54] sourcerer: 2023-03-04 02:12:25 (#jwrd) jfw: sstacks, since you say you want to strenghten your english, I can do my part to point out your errors in chat
[23:55] sstacks: http://fixpoint.welshcomputing.com/2023/jwrd-logs-for-Mar-2023/#6244 -- great tip!
[23:55] sourcerer: 2023-03-04 02:20:40 (#jwrd) jfw: internal & external references, uncommon words, and multilingual parts, on top of (or rather, supporting) the complexity of what's being communicated, and the emotional triggers laced throughout, at least for those with the buttons to be pushed.
[23:56] sstacks: http://fixpoint.welshcomputing.com/2023/jwrd-logs-for-Mar-2023/#6245 -- Check out this one, interested on your take. https://www.amazon.com/American-Dictionary-English-Language-Facsimile/dp/091249803X/ref=sr_1_5?crid=2R3FI3T5S3TF4&keywords=webster+dictionary+1828+edition&qid=1678060562&sprefix=webster+dictionary%2Caps%2C142&sr=8-5&ufe=app_do%3Aamzn1.fos.006c50ae-5d4c-4777-9bc0-4513d670b6bc
[23:56] sourcerer: 2023-03-04 02:22:29 (#jwrd) jfw: nothing wrong with a machine translation as a quick aid but best to add a good dictionary at least to the ready reference material. (what's a good dictionary? don't think I found one yet)
Day changed to 2023-03-06
[04:09] jfw: sstacks: project gutenberg has a mostly-ok OCR of webster's unabridged dictionary of 1913 which might be something of a halfway point; I haven't tried that 1828 one. I wouldn't specifically select for American ones either. Supposedly the most comprehensive ever produced (taking up the whole bookshelf level) was the Oxford English Dictionary.
[04:14] jfw: sstacks: dunno if you deliberately skip the apostrophes (in contractions & possessives), it comes across a bit more sloppy than, say, not caring about capitalization as we largely don't here. that is, the apostrophe is an actual part of the spelling, supporting the word's meaning and improving readability.
[04:23] jfw: http://fixpoint.welshcomputing.com/2023/jwrd-logs-for-Mar-2023/#6297 - easy one here: *a spelling. always 'a' when followed by a consonant sound.
[04:23] sourcerer: 2023-03-05 23:54:18 (#jwrd) sstacks: http://fixpoint.welshcomputing.com/2023/jwrd-logs-for-Mar-2023/#6242 -- Thanks my friend. So whenever I dont have an spelling mistake, might be because Im getting help from our friends at Google Translate
[04:24] jfw: https://www.merriam-webster.com/words-at-play/is-it-a-or-an has the fine print there on 'sound'.
[18:25] whaack: http://fixpoint.welshcomputing.com/2023/jwrd-logs-for-Mar-2023/#6294 <-- 'miner's defecting from segwit is 51% attack FUD' - this is one i've heard a few times. irony being that SegWit itself is a 51% attack (group of minders blocking valid txs from being included in the blockchain for an extended period of time)
[18:25] sourcerer: 2023-03-05 23:49:27 (#jwrd) dorion: http://fixpoint.welshcomputing.com/2023/jwrd-logs-for-Mar-2023/#6290 -- they likely don't realize they're trusting miners. they've generally not done the due dilligence to reveal such facts. in my experience, sharing such information triggers cognitive dissonance because they've not heard it from the lamestream they've become emotionally attached to. common resp
[19:44] dorion: miner's were blocking valid txs for an extended period of time ? when ? the only example I know of is the bitbet transaction. claiming it'd be a 51% simply shows there illiteracy. it's not double spending, it's picking up cash people left in the gutter because they misrepresented "gutter" for "bank gr4de s3k00rity" or somesuch.
[19:53] whaack: dorion: the miners block txs that take coins in the segwit piggy bank
[19:59] jfw: right; basically every softfork is a censorship attack.
[20:01] jfw: and some hardforks too, like when the ethereum developers stole the DAO payout.
[20:02] jfw: ( http://trilema.com/2016/to-the-dao-and-the-ethereum-community-fuck-you/ )
[20:07] dorion: http://fixpoint.welshcomputing.com/2023/jwrd-logs-for-Mar-2023/#6311 -- oooooohh, right you are.
[20:07] sourcerer: 2023-03-06 19:53:35 (#jwrd) whaack: dorion: the miners block txs that take coins in the segwit piggy bank
[22:03] sstacks: Hey guys. Need some help. Im note sure what does the dashes on directories and files means regarding to the permissions. For example, drwx------
[22:06] dorion: in that case, it means "group" and "other" have no permissions on that directory.
[22:07] dorion: drwxr--r-- on the other hand means "user" can do as he pleases, but group and other can only read it.
[22:09] sstacks: So its always a combination of 9 ?
[22:10] sstacks: the dash means "no permission" ?
[22:12] sstacks: The letters are arranged in a certain way. The first is only used to give specific information about the file (see the above table). Then there are three groups of three characters. The first trio correspond to the user's rights, the next three are the group rights, and the last three are for all others. When a letter is present it means that category of user has that particular access to the file. A file that has the protection code "-rwxr-x---" is a plain
[22:12] sstacks: file; the user can read, write/delete and execute it; people in the same group as the user can read and execute it; and everyone else can only see that the file exists (if given access to the containing directory).
[22:12] sstacks: So its a combination of 10
[22:13] sstacks: 1 descriptive letter of the file and the other 9 about permissions
[22:16] dorion: http://fixpoint.welshcomputing.com/2023/jwrd-logs-for-Mar-2023/#6321 -- if the dash is the leading character, it means it's a normal file, if it's a directory, it'll be "d". jfw can fill in for me if there are other potential options for that spot.
[22:16] sourcerer: 2023-03-06 22:10:00 (#jwrd) sstacks: the dash means "no permission" ?
[22:17] dorion: http://fixpoint.welshcomputing.com/2023/jwrd-logs-for-Mar-2023/#6325 -- right.
[22:17] sourcerer: 2023-03-06 22:13:14 (#jwrd) sstacks: 1 descriptive letter of the file and the other 9 about permissions
[22:17] sstacks: Yeah i can see the other options in the table provided inside the lecture
[22:17] sstacks: Thanks bro
[22:19] dorion: you're welcome manito.
[22:19] dorion: http://fixpoint.welshcomputing.com/2023/jwrd-logs-for-Mar-2023/#6232 -- though fittingly, that "taproot" add looks like graffiti.
[22:19] sourcerer: 2023-03-04 01:32:26 (#jwrd) jfw: http://fixpoint.welshcomputing.com/2023/jwrd-logs-for-Mar-2023/#6199 - pretty lulzy news link, complete with the ad images ineptly splayed on top of the text, all it's missing is the <blink> tags!
[22:56] sstacks: I think i took off permissions from myself on my home directory. Is this possible?
[23:00] sstacks: D. Allow group and others to be able to read and execute on the public_html directory --- by following this instruction i issued: chmod 055 .
[23:17] whaack: sstacks lol yes its possible
[23:18] whaack: you should be able to fix this tho
[23:19] whaack: there are certain cases where u can shoot yourself in the foot with these permission type commands, but this mistake u made is reversible
[23:37] sstacks: feels pretty much that way, shot myself in the foot hahaha
Day changed to 2023-03-07
[02:06] sstacks: I tried closing and reopening PuTTy, I cannot login either.
[02:39] dorion: sstacks, the premissions need to be reset by the root user, which jfw has access to, but I don't in this case. When he gets caught up w/ the log, he'll reset it for you.
[03:30] jfw: sstacks: heh, you could've recovered it yourself so long as you didn't log out
[03:31] jfw: should be fixed now
[03:32] jfw: I'll let you do the asking if you need it explained why your command did that.
[03:33] jfw: good thing we're using those rubber bullets, though "less educative" perhaps :D
[16:09] dorion: http://dorion-mode.com/2023/03/prolonged-periods-in-the-postabsorptive-phase/
[16:49] jfw: sstacks, whaack: my schedule is looking iffy for office hours this thursday so I'll plan to move it to the same time this Friday (4pm). let me know if something different works better for you.
[16:51] jfw: I've got a local move underway from the 'temporary landing spot'.
Day changed to 2023-03-08
[01:40] jfw: whaack: here was the recent mention of the inflation bug you were unsure about; it was qntra'd too
[01:40] sourcerer: 2023-02-28 23:54:49 (#jwrd) jfw: you could also contrast the level of "discussion" that goes on in open sores projects with the literate & properly social coding approach, where changes are presented and discussed in detail and in context befitti
[05:11] whaack: l
[18:40] sstacks: jfw: hey jacob, should I try to follow Session 3's command lines on the online machine?
[18:42] sstacks: Im watching the class recording right now.
[18:43] dorion: sstacks, yes.
[18:44] dorion: you'll be writing the configuration file, running bitcoind and checking out the debug.log
[18:45] sstacks: ok, I'll give it a try!
[18:50] dorion: good luck ;-)
[19:12] sstacks: Should I go all over again from the commands from Session 2?
[19:12] sstacks: tried pulling off the bitcoind --help, and i got a "not found" msg
[19:48] jfw: sstacks: you'd proceed from wherever you left off. it sounds like you didn't yet get bitcoind installed; so far it's unclear if you got it built.
[19:51] jfw: sstacks: so revisit "Lab: Fetching, Building..." section 2 from last time
[19:51] jfw: noting the context that you need to be the 'build' user and in the ~/bitcoin directory for that user.
[19:52] sstacks: jfw: hey jacob, thanks. I think i was using the wrong machine. My bad. I will have to tag it properly. I ran the bitcoind --help on the other machine at it printed.
[19:52] jfw: sstacks: ah, good then.
[19:53] jfw: http://fixpoint.welshcomputing.com/2023/jwrd-logs-for-Mar-2023/#6352 << this is peculiar given the immediately preceeding "02:29:02 whaack!~whaack@a341e2c9 quits [Client closed connection]" - his client got a letter 'l' through despite not being connected?!
[19:53] sourcerer: 2023-03-08 05:11:08 (#jwrd) whaack: l
[19:54] sstacks: Its alive!
[19:56] sstacks: jfw: The main eth cable (from my isp) should be plugged into eth0 and then plug the laptop into eth1. And then I can pull an extra eth cable connected to my common computer from eth2?
[20:21] sstacks: For connecting to a node I should issue "addnode 116.202.223.108" ?
[20:31] jfw: http://fixpoint.welshcomputing.com/2023/jwrd-logs-for-Mar-2023/#6369 << correct
[20:31] sourcerer: 2023-03-08 19:56:52 (#jwrd) sstacks: jfw: The main eth cable (from my isp) should be plugged into eth0 and then plug the laptop into eth1. And then I can pull an extra eth cable connected to my common computer from eth2?
[20:33] jfw: http://fixpoint.welshcomputing.com/2023/jwrd-logs-for-Mar-2023/#6370 << that would be ours, yes; you can add multiple nodes (using multiple 'addnode=' lines) and it's a good idea to do so, though in any case it will discover more nodes by asking each one it meets.
[20:33] sourcerer: 2023-03-08 20:21:35 (#jwrd) sstacks: For connecting to a node I should issue "addnode 116.202.223.108" ?
[20:34] jfw: to be precise, the line to put in bitcoin.conf would look like: addnode=116.202.223.108
[20:34] jfw: samy/sstacks, looks like you have two connections open now.
[20:35] jfw: I'll be signing off momentarily, should be back online late tomorrow or Friday.
[20:36] samy: thanks jfw
[20:37] samy: take care
[21:44] sstacks: "For connecting to a node I should issue "addnode 116.202.223.108" ?" -- I wasent able to connect to JWRD node, maybe I'm doing something wrong, just not sure what is.
[21:45] sstacks: I just shut down the Umbrel node. Any recommendation to find a use for this Raspberry pi?
[23:07] dorion: sstacks, you need the = sign in the place of the space between addnode and the IP.
Day changed to 2023-03-09
[00:41] sstacks: dorion: thanks my friend
Day changed to 2023-03-10
[21:00] jfw is in
[21:03] jfw: sstack: do I take it that adding the '=' did the trick?
[21:03] jfw: (not like I didn't already point that out explicitly, lolz)
[21:06] jfw: sstack: I use a raspberry pi for flashing the thinkpad ROMs due to its SPI interface pins, but didn't find much other use for mine yet. then again, I deliberately got the one without network interfaces.
[21:06] jfw: maybe a networked music player, file server, or print server
[21:11] jfw: otherwise, I usually procure machines to fill some need, rather than searching for new "needs" so an idle gadget can feel useful :D
Day changed to 2023-03-11
[23:50] sstacks: jfw: havent tried again, im trying to cover the unix hw for no.
[23:50] sstacks: now*
[23:50] sstacks: jfw: Sorry i must have missed it.
[23:53] sstacks: jfw: ftm, im trying to respond to the practice 1. On practice #1, part 2, asks to issue "./newshell.1" I indeed, get an error since that shell is not present. But im requested to "determine the shell in question from the error msg"
[23:58] sstacks: jfw: Following right there in question #2. Asks to issue "./newshell.2" I dont get an error this time. I understand i must be in a new shell if i dont get an error? I issue echo $0 to check if im in a new shell, but im still in ksh
[23:59] sstacks: jfw: so when im asked to exit the shell, its suposed to be with ctrl+d .. my whole putty closes afterwards.
[23:59] sstacks: jfw: Im sorry if im not clear enough. Im kinda stuck in this.
Day changed to 2023-03-12
[00:02] jfw: hello sstacks
[00:03] sstacks: jfw: hey my friend
[00:04] jfw: sstacks: for newshell.1, what is the error you're seeing?
[00:13] jfw: sstacks: btw, dorion mentioned some trouble with the 'alias' command - the key there is the note that an '=' is required in bourne style shells. (so, much like the bitcoin.conf issue, perhaps!)
[00:18] jfw: http://fixpoint.welshcomputing.com/2023/jwrd-logs-for-Mar-2023/#6392 << it was here
[00:18] sourcerer: 2023-03-11 23:50:45 (#jwrd) sstacks: jfw: Sorry i must have missed it.
[00:18] sourcerer: 2023-03-08 20:34:08 (#jwrd) jfw: to be precise, the line to put in bitcoin.conf would look like: addnode=116.202.223.108
[00:20] jfw: possibly it didn't quite jump out enough for someone not accustomed to how closely the text needs to be scrutinized, where every symbol potentially matters to the machine
[00:41] jfw: http://fixpoint.welshcomputing.com/2023/jwrd-logs-for-Mar-2023/#6394 - that much sounds OK, it would still be "ksh" because that's the "new" shell in question. But, it should end up with a new *instance* of that shell, running as a subprocess, hence the ^D should only exit that inner shell and return to the first, rather than ending the whole session.
[00:41] sourcerer: 2023-03-11 23:58:25 (#jwrd) sstacks: jfw: Following right there in question #2. Asks to issue "./newshell.2" I dont get an error this time. I understand i must be in a new shell if i dont get an error? I issue echo $0 to check if im in a new shell, but im still in ksh
[00:45] jfw: another way to check would be the up-arrow to recall from command history: if it's a new shell then it won't recall the ./newshell.2 line that started it.
[00:46] jfw: a third and most direct way to check would be to 'echo $$' which will print the current shell's PID (process ID) which would differ between the two instances.
[01:02] sstacks: <jfw> possibly it didn't quite jump out enough for someone not accustomed to how closely the text needs to be scrutinized, where every symbol potentially matters to the machine--- I should start checking the logs instead of relying on what i see on my end.
[01:04] sstacks: jfw: so the second question has 3 parts. Ive peeked on the answer sheet and I can see the first part's answer is "C Shell" . I need to know how i get to that answer.
[03:55] jfw: sstacks: "I should start checking the logs instead of relying on what i see on my end." - good idea, and more generally, re-reading because it's your brain and not just your connection that won't always see everything the first time
[04:03] jfw: you missed my previous question which was meant to clarify yours, although you hadn't quite asked it (as in, with a question mark and everything), either then or now
[04:03] sourcerer: 2023-03-12 00:04:52 (#jwrd) jfw: sstacks: for newshell.1, what is the error you're seeing?
[04:04] jfw: actually it kinda looked like you ran away from the keyboard as soon as you saw I was in :P
[04:05] jfw: I'm not that scary am I?
Day changed to 2023-03-13
[18:27] sstacks: hey guys. Question. What does PATH= specifically do?
[18:27] sstacks: So when i issue that command i cannot use the ls nor ps commands
[18:27] sstacks: I have to restart the putty to go back
[18:49] dorion: it's the shell variable that store the command path, i.e. the places the shell will look for commands. generally, all paths on the filesystem tree start at root and branch out down the directory hierarchy.
[18:52] dorion: in the practice 1 exercise, note that it's PATH=. , that '.' is meaningful, it means current working directory, i.e. where you are on the filesystem at that time.
[18:55] dorion: if it's, e.g. your user's home directory, no, you can't use ls or ps straight anymore, because they're installed under /bin/ . you can call their absolute paths though, so /bin/ls should continue working.
[20:13] jfw: http://fixpoint.welshcomputing.com/2023/jwrd-logs-for-Mar-2023/#6416 - to answer the exact question, it updates the shell variable named PATH to contain nothing at all (technically an empty string, as in ""). Since that variable is used to configure what directories the shell searches for commands, the effect is that it won't find any commands just by name and would need explicit paths as dorion
[20:13] sourcerer: 2023-03-13 18:27:05 (#jwrd) sstacks: hey guys. Question. What does PATH= specifically do?
[20:13] jfw: says.
[20:17] jfw: the exercise does show PATH=. so what that would do is update the PATH variable to contain the string ".", which indeed refers to the working directory. for the specific exercise, it doesn't much matter, the intent was to break it and see what happens, which happens in either case.
Day changed to 2023-03-14
[02:13] jfw: whaack: to head off any confusion, note that we're not observing a time change regarding class scheduling, utc is utc after all. let me know if that makes it interfere with local stuff.
[17:15] dorion: http://dorion-mode.com/2023/03/the-inflation-of-bitcoin-the-mechanisms-enforcements-and-verification-costs/
[18:03] jfw: sstacks, whaack: I'm taking email out of the pipeline for return of homework and now just posting them all in a "homework" subdirectory on the class site.
Day changed to 2023-03-15
[13:27] jfw: sstacks: how about doing a zoom call 4pm tomorrow (office hours) to work on implementing that firewall configuration change? for one thing it'll save us the commute, but moreover it'll serve as a review of many of the basics while putting them into practice.
[13:38] jfw: dorion: do you recall how dns is set up for the untrusted net on sstacks's router, ie what nameserver(s) are advertised by dhcpd? was I mistaken in writing that they're initially unconfigured? it looks that way to me, with the default config using google.
[13:40] jfw: sstacks: another idea was that I could do some more writing to expand on or review the basic unix topics, or write more practice problems to drill, but I dunno, do you think that would help?
[13:41] dorion: jfw, just checked, looks like I used 8.8.8.8, 8.8.4.4
[13:41] jfw: dorion: thanks. possibly I was remembering an older practice then.
[13:42] jfw: what do you think about putting a djbdns cache on the edgerouters themselves?
[13:43] jfw: openbsd comes with 'unbound' but I'd rather keep my eggs in one better-understood basket there
[13:45] jfw: it'll pull in daemontools for the router build too, but djb was big on portability and bsd especially so I'd guess that'll be pretty smooth
[13:45] jfw: alternatively we could run our own public dns cache
[13:46] sstacks: Morning guys. Thanks to you both for the great assistance. Tomorrow its difficult for me since Ill be running some errands most of the day. Weekends its hard as well. If you are willing to extend mercy for the same offer for sometime next week, we can schedule. Regarding on the reinforcement for basic unix, id love that as well.
[13:47] jfw: sstacks: that does make me wonder, how much practice time have you been getting in?
[13:48] jfw: sstacks: you're certainly welcome
[13:49] sstacks: jfw: exclusively the practice sessions from the homework. As I do try to apply "man" and "--help" to get some depth
[13:50] sstacks: jfw: besides that time, no practice. I certainly have full hands.
[13:50] jfw: sstacks: was the issue with homework 3 (last week's) just that you ran out of time, or that you got stuck as well?
[13:52] sstacks: jfw: both id say. I don't like skipping to the next problem without having a resolution on the one im actually working on. Ive done it, but i dont love to.
[13:53] jfw: sstacks: alright; and is the thursday office hours time conflicted in general?
[13:54] sstacks: Regarding to education, Im taking personalized trading course, with 3 sessions a week. And theology seminary its demanding as well (its fair to confess this is the obligation i mostly relax among others)
[13:55] sstacks: jfw: not generally. Tomorrow is extracurricular case
[13:55] sstacks: As i need to attend both my parents needs and errands since they have limitations
[13:56] jfw: sstacks: ok. working things through one at a time is fine but there needs to be a time where we can sit down and do that together
[13:56] sstacks: Sometimes theres unforeseen events i have to take care
[13:56] jfw: sure
[13:57] jfw: it's just, the more you fall behind, the more overwhelming it will feel
[13:57] sstacks: Ive determined this not be an obstacle for me. Since I dont have actually a job i have to attend. So ive managed to wakeup very early
[13:58] sstacks: Indeed.
[13:58] jfw: a job can be a big drain indeed, so that's good at least.
[13:59] jfw: the usual sort of 'job' at least.
[14:00] jfw: how about 4pm monday then for the router work?
[14:05] jfw: http://fixpoint.welshcomputing.com/2023/jwrd-logs-for-Mar-2023/#6433 << looks like wishful thinking more likely.
[14:05] sourcerer: 2023-03-15 13:41:53 (#jwrd) jfw: dorion: thanks. possibly I was remembering an older practice then.
[15:50] jfw: looking a bit closer at that 2016-2018 inflation bug, an ugly glimpse at the inner workings of the power rangers & mining cartel: https://archive.is/2l6lg - basically, they deliberately withheld highly relevant information about the effects of the fix from their reporting on it, such as the release notes. That is to say, they
[15:50] jfw: lied by omission, downplaying their inflationary hard-fork as a run-of-the-mill denial-of-service vulnerability.
[15:51] jfw: then their well-trained followers sucked it down so fast that they didn't notice.
[15:52] jfw: it's unclear if they were even going to come clean at all if someone hadn't independently reported it.
[16:01] jfw: then for added lulz, the "ultimate security vulnerability datasource" never got the news, and mislabeled the vendor as 'Bitcoincore', with the result that one of the most significant vulnerabilities doesn't even show up in the list.
[16:06] sstacks: jfw: monday 4pm is perfect.
[16:07] jfw: sstacks: alright
[16:59] dorion: http://fixpoint.welshcomputing.com/2023/jwrd-logs-for-Mar-2023/#6460 -- it appears they also misreported when the original check was merged. they say pull request #443 was merged in 2012, yet the primary source shows it was merged 2011-8-8.
[16:59] sourcerer: 2023-03-15 15:50:11 (#jwrd) jfw: looking a bit closer at that 2016-2018 inflation bug, an ugly glimpse at the inner workings of the power rangers & mining cartel: https://archive.is/2l6lg - basically, they deliberately withheld highly relevant information about the effects of the fix from their reporting on it, such as the [https://github.com/bitcoin/bitcoin/blob/v0.16.3/doc/release-notes.md][rele
[17:01] dorion: for the log, here's the function in the reference implementation.
[17:04] dorion: http://fixpoint.welshcomputing.com/2023/jwrd-logs-for-Mar-2023/#6461 -- they lied by omission wrt what people can do about it too in that they advised, "get our latest booster shot now !" and didn't mention rolling back to pre-0.14 versions.
[17:04] sourcerer: 2023-03-15 15:50:11 (#jwrd) jfw: lied by omission, downplaying their inflationary hard-fork as a run-of-the-mill denial-of-service vulnerability.
[17:07] dorion: http://fixpoint.welshcomputing.com/2023/jwrd-logs-for-Mar-2023/#6464 -- probably worth a short email w/ curious tone pointing it out to that Serkan Ozkan.
[17:07] sourcerer: 2023-03-15 16:01:16 (#jwrd) jfw: then for added lulz, the "ultimate security vulnerability datasource" never got the news, and mislabeled the vendor as 'Bitcoincore', with the result that one of the most significant vulnerabilities doesn't even show up in [https://www.cvedetails.com/vulnerability-list/vendor_id-12094/product_id-59195/Bitcoin-Bitcoin
[17:10] sstacks: Question my friends, for whenever you can answer
[17:10] sstacks: ls > output.2
[17:10] sstacks: whoami > output.2
[17:10] sstacks: ps > output.2
[17:10] sstacks: These are 3 commands right.
[17:11] sstacks: On the first one, output.2 content is replaces with ls contents
[17:12] sstacks: on the second one, output.2 contents is now ls's, but after issuing the second command its replaced with whoami's content
[17:12] sstacks: And following the same logic for the last one. output.2's content is now what was contained on ps
[17:12] sstacks: Is this correct?
[17:13] jfw: sstacks: it is.
[17:13] sstacks: Oh greatt
[17:13] sstacks: Thanks
[17:13] jfw: no problem
[17:24] jfw: http://fixpoint.welshcomputing.com/2023/jwrd-logs-for-Mar-2023/#6467 - yeah, weird, seems like just a lack of basic fact checking there
[17:24] sourcerer: 2023-03-15 16:59:39 (#jwrd) dorion: http://fixpoint.welshcomputing.com/2023/jwrd-logs-for-Mar-2023/#6460 -- it appears they also misreported when the original check was merged. they say pull request #443 was merged in 2012, yet the primary source shows it was merged 2011-8-8.
[17:29] jfw: dorion: https://www.cvedetails.com/how-does-it-work.php - I guess it's basically just a marginally more accessible frontend to the NIST data.
[17:32] jfw: with the inconsistent labeling being a known issue and 'caveat emptor'
[17:38] jfw: seems to make it not all that useful in practice, even with the given that it's an imperial database
[17:51] dorion: jfw, aha.
[17:51] dorion: hey whaack, how's the wrist recovery coming along ? also, any plans to stop over in Panama on your way back ?
[18:58] jfw: dorion: http://fixpoint.welshcomputing.com/2023/jwrd-logs-for-Mar-2023/#6470 - missed this line. I expect you're right, though the hypothetical neutral observer might want to see what you're referring to specifically.
[18:58] sourcerer: 2023-03-15 17:04:49 (#jwrd) dorion: http://fixpoint.welshcomputing.com/2023/jwrd-logs-for-Mar-2023/#6461 -- they lied by omission wrt what people can do about it too in that they advised, "get our latest booster shot now !" and didn't mention rolling back to pre-0.14 versions.
[19:31] dorion: jfw, not exactly sure how it wasn't clear, but from 2011 when the check was put in there until 0.14 when it was taken out (by the same guy, bluematt), those versions of Bitcoin aren't effected by the inflation bug.
[19:52] jfw: dorion, I meant where did they say upgrading was the only option
[19:57] jfw: https://teddit.net/r/Bitcoin/comments/9hkoo6/new_info_escalates_importance_upgrading_to_0163/e6d0r36/ - here's thermos saying ~that and the jester pushing his tricks
[19:58] dorion: "However, it still remains critical that affected users upgrade and apply the latest patches to ensure no possibility of large reorganizations, mining of invalid blocks, or acceptance of invalid transactions occurs."
[20:00] jfw: dorion: ah fair enough. guess I literally couldn't make it through all the verbiage.
[21:50] dorion: http://fixpoint.welshcomputing.com/2023/jwrd-logs-for-Mar-2023/#6460 -- "The first time you run version 0.15.0 or newer, your chainstate database will be converted to a new format, which will take anywhere from a few minutes to half an hour, depending on the speed of your machine...
[21:50] sourcerer: 2023-03-15 15:50:11 (#jwrd) jfw: looking a bit closer at that 2016-2018 inflation bug, an ugly glimpse at the inner workings of the power rangers & mining cartel: https://archive.is/2l6lg - basically, they deliberately withheld highly relevant information about the effects of the fix from their reporting on it, such as the [https://github.com/bitcoin/bitcoin/blob/v0.16.3/doc/release-notes.md][rele
[21:50] dorion: "Note that the block database format also changed in version 0.8.0 and there is no automatic upgrade code from before version 0.8 to version 0.15.0 or higher. Upgrading directly from 0.7.x and earlier without re-downloading the blockchain is not supported."
[21:51] dorion: how many fucking times do they have to fuck with the db for chrissakes ?!?
[22:37] jfw: until morale improves.
Day changed to 2023-03-16
[19:18] dorion: http://dorion-mode.com/2023/03/the-evolution-of-my-osen-operation/
Day changed to 2023-03-17
[03:44] jfw: https://blog.thelifeofkenneth.com/2017/11/creating-autonomous-system-for-fun-and.html - fun read I stumbled into.
[23:40] dorion: http://dorion-mode.com/2023/03/happy-saint-patricks-day/
Day changed to 2023-03-18
[13:34] sstacks: Morning guys
[13:37] sstacks: Do you have any non-technical article about Tor's weaknesses? On one of the readings recommended on the last lesson, MP points out Tor as a "Appallingly coded pieces of crap". Just curious, because every1 takes for granted this ¿Protocol? is safe and sound to use without government intervention. And well, as im not programmer, id like a reading I can actually understand. Have a great day every1
[19:04] jfw: sstacks, I'm not thining of such an article exactly offhand; I suppose if you want to know about the appallingness of the code the best thing would be to have a look at that code. I haven't really found it worth my time in the case of Tor; it's not like there isn't plenty of other appalling code around in more urgent need of hacking through by machete.
[19:04] jfw: for a non-technical view though I'd look first at the non-technical aspects, for instance, where did the initial r&d funding for tor come from?
[19:05] jfw: and there's even the fully played out practical example - do you know what happened to Ross Ulbricht?
[19:29] jfw: sstacks: there's also http://trilema.com/2013/anonimity-not-for-the-poor/ for a more philosophical take & bit of a tease.
[21:01] dorion: http://dorion-mode.com/2023/03/event-the-fundamentals-of-bitcoin-at-towerlab/
[21:58] caai: nice!
Day changed to 2023-03-20
[03:11] whaack: dorion: continuing our convo from heathen channels, friday should work well for a meeting
[03:12] whaack: and congrats to towerbank for having you speak there , heh.
[03:12] whaack: nice to see you flexing those writing muscles as well
[16:24] sstacks: jfw: http://fixpoint.welshcomputing.com/2023/jwrd-logs-for-Mar-2023/#6514 thanks for respose
[16:24] sourcerer: 2023-03-18 19:29:31 (#jwrd) jfw: sstacks: there's also http://trilema.com/2013/anonimity-not-for-the-poor/ for a more philosophical take & bit of a tease.
[16:25] sstacks: dorion: nice bro! Hopefully i can join
[17:26] jfw: sstacks: no problem. I was wondering, how do all those formatting codes come into your homework responses? I'm seeing things like **, ???, and even some markdown-style links to command descriptions.
[17:28] sstacks: jfw: oh yes, sorry for confusion. I use Notion as my notebook
[17:29] sstacks: jfw: Thought i corrected it before i send it
[17:29] jfw: I suppose I'll have to insist on starting with vim as soon as possible
[17:29] sstacks: jfw: give me a sec
[17:32] sstacks: jfw: please check email. Ok I hear you regarding vim
[17:32] jfw: sstacks: so I gather the process is something like, "write in a wysiwyg / msword equivalent, export awkwardly to 'plain text', then attempt to clean up the machine's mess by hand" - sounds quite inefficient to me!
[17:33] sstacks: jfw: indeed it is.
[17:34] jfw: sstacks: I still see the stars and question marks but nevermind for now, I'm almost through it anyway.
[17:36] jfw: sstacks: thanks for explaining, mostly I was curious as to what it was and how we might adapt our instructions.
[17:37] jfw: it does make sense to keep your own saved copy, certainly
[18:06] sstacks: jfw: Ok, thanks. Now im trying to create the shell script. This must be done on the putty?
[18:06] jfw: sstacks, whaack: last week's homework responses are up on the site.
[18:07] jfw: sstacks: which script do you mean?
[18:07] jfw: ah, for the FG initialization
[18:08] jfw: sstacks: you'll want to do that on the thinkpad, for it to do any good. You can send me the contents of the script to check it.
[18:09] sstacks: Im pretty sure theres something im missing. Can i send here?
[18:12] jfw: sstacks: sure, you can use http://welshcomputing.com/paste/ if there's something bigger than one line
[18:13] sstacks: http://welshcomputing.com/paste/ii9t7u3h69
[18:14] sstacks: So I executed first the editor, and inserted the following lines on the "script"
[18:15] jfw: sstacks: you're missing that the command is 'stty' while 'raw' and the rest are the options given to that command, thus on the same line.
[18:16] jfw: you'll also need to specify the path to the USB TTY device. just like the command we used in class, in other words.
[18:18] sstacks: # stty -F /dev/ttyUSB0 115200 raw -echo -echoe -echok
[18:20] jfw: verily.
[18:42] sstacks: http://welshcomputing.com/paste/qx2cbud3rz
[18:43] sstacks: Is this more likely? Im figuring out how to specify the path
[18:43] sstacks: Regarding adding the options to the stty command, is that the correct way_
[18:44] sstacks: ?
[19:08] sstacks: http://welshcomputing.com/paste/ifctidkeb6
[19:09] sstacks: Dont mind the last url
[19:40] jfw: sstacks: http://fixpoint.welshcomputing.com/2023/jwrd-logs-for-Mar-2023/#6548 - what path do you mean?
[19:40] sourcerer: 2023-03-20 18:43:24 (#jwrd) sstacks: Is this more likely? Im figuring out how to specify the path
[19:41] jfw: it's getting closer though for sure
[21:01] jfw: sstacks, ready when you are for the router work.
[21:02] sstacks: jfw: im at the zoom
[21:43] samy: jfw: thanks bro for your assistance. Im all setup with my router now
[21:49] jfw: you're welcome and to refine my last response, rather than "don't worry too much about me", it's more like, let me be the judge of when to be frustrated or annoyed or whatever. we're solving problems & making progress, nothing to be frustrated about that I can see there. yes it's a slow pace but that's to be expected at this stage.
Day changed to 2023-03-21
[01:34] sstacks: jfw: I did take it on that sense! Oh well.. I think im just reflecting, id be frustrated if I was you. Some of us are not as great teacher as you. yes I realize the effort you make to simplify some explanations for my limited understanding, so this i respect and value.
[01:41] jfw: sstacks: I suppose I do have a certain combination of patience and practice at simplifying things. still, I'd say frustration is the situation where you get no returns on effort expended, or inadequate returns
[01:46] jfw: I guess it'd be caused by either underestimation of the attempted task or overestimation of the applied effort
[01:52] jfw: (because if you *know* the applied effort is inadequate to the task, that's not called being frustrated but simply being stupid)
[11:41] sstacks: jfw: "I guess it'd be caused by either underestimation of the attempted task or overestimation of the applied effort." - Great and useful insight.
[15:39] jfw: http://fixpoint.welshcomputing.com/2023/correcting-tedus-sct-utility-to-set-color-temperature/
[23:06] jfw: sstacks, dorion, whaack: btw I posted the recording from monday's router work session to the class site as well, in case it's of interest as a PF appetizer.
Day changed to 2023-03-23
[04:49] jfw: http://fixpoint.welshcomputing.com/2023/gales-scheme-release-0407-fixing-glibc-build/
[21:46] sstacks: hey guys. Regarding to the hw. Should I use the PuTTy, or this is on the Thinkpad_
[22:05] jfw: sstacks: your choice, although pasting the key might be somewhat easier to figure out from PuTTY (there's multiple ways to do it)
[22:06] sstacks: jfw: ok thanks
[22:19] sstacks: jfw: default-key "<Your Key ID>"
[22:19] sstacks: jfw: this Key ID i have to generate it somehow?
[22:19] sstacks: Or could I just make something up?
[23:21] sstacks: ok nvm. Just find out
Day changed to 2023-03-24
[15:15] sstacks: Hey guys, sorry I couldnt make it last night. We had a meeting with a potential client at 7:00 pm
[15:17] sstacks: Continuing the hw. I already generated my GPG key. On default-key "<Your Key ID>" I have to place the pub or sub key I generated?
[16:07] jfw: sstacks: it would be the short ID (or full fingerprint) of the top-level public key (pub).
[16:08] jfw: possibly we should just remove that line from the configuration, as it's only relevant when you have multiple private keys
[19:12] dorion: http://fixpoint.welshcomputing.com/2023/jwrd-logs-for-Mar-2023/#6575 -- ok, I hope it went well for you. the recording has been published : http://dorion-mode.com/2023/03/event-the-fundamentals-of-bitcoin-at-towerlab/?b=the%20video%20recording&e=#select
[19:12] sourcerer: 2023-03-24 15:15:10 (#jwrd) sstacks: Hey guys, sorry I couldnt make it last night. We had a meeting with a potential client at 7:00 pm
[19:48] sstacks: dorion: great bro, thank you. Will sit next week and watch recordings.. Judging by the slides, it was awesome
Day changed to 2023-03-25
[05:25] jfw: hear ye, hear ye, http://fixpoint.welshcomputing.com/bitcoin-reference-implementation/ is now up and with its permanent sidebar link (under Pages).
[05:25] jfw: I suppose it could still use a section with the complete walkthrough on how to install and get started with all the stuff.
[13:03] dorion: jfw, nice ! a walk through sounds good.
[13:11] dorion: want to also add a link to jwrd.net on the first JWRD mention ?
[13:12] dorion: and how about mentioning the use of openssl. afiau, prb moved to libsecp256k1
[13:14] dorion: yeah, as of ~2015 : https://archive.is/rqXpB
[14:26] jfw: "I'm very in favor of this being merged, however I can't say I have reviewed this code or done specific testing." "I cannot give an utACK because I'm not trying to understand everything that is done here.
[14:26] jfw: But I reviewed the parts is easy for me to understand and I would utACK those parts"
[14:28] jfw: such helpful contributions to the consensus!
[14:33] jfw: dorion: I think you have a good point in there but possibly trickier to draw it out exactly. for starters, they're talking about no longer depending on openssl. this has at least the appearance of virtue; for instance it's what I did in gbw-signer. do they actually mean their node doesn't link openssl anymore? I would guess not, unless they removed that hearnian heartbleeding "payments protocol"
[14:34] jfw: I mean, I'd guess it *doesn't* mean they no longer link it, double negative.
[14:36] jfw: but needs verification.
[14:37] jfw: "One thing that is planned before final release is an explanation of the test procedures and formal verification mechanisms used." -sipa; gee, there's a thought. at least from the thread there it looks like they all took his rigorous testing claims at face value
[14:38] jfw: "which turned up a set of (to me) previously unknown behaviour in OpenSSL's parser" -sipa; majorly explanation needed!!
[14:52] jfw: http://fixpoint.welshcomputing.com/2023/jwrd-logs-for-Mar-2023/#6585 - ty, done.
[14:52] sourcerer: 2023-03-25 13:11:37 (#jwrd) dorion: want to also add a link to jwrd.net on the first JWRD mention ?
[14:59] jfw: incidentally, I really wanted to write "resolves *all* known bugs in the old code" but had to pull it back, given that 1) it's known that there are many less-severe weaknesses and potentially buggy spots and 2) I haven't really attempted a thorough cataloging of all bugs that might have been mentioned somewhere
[15:01] jfw: I don't really fancy doing that either, as it seems a better return on time to continue cleaning & studying the code, thereby searching the full space of possible bugs, rather than searching historical NPC chatter.
[15:04] jfw: it's the previously-unknown bugs that matter most, after all
[15:23] jfw: http://fixpoint.welshcomputing.com/2023/jwrd-logs-for-Mar-2023/#6584 - I'm thinking to leave this fruit on the tree for now. There should be canonical documentation for all steps, already reachable through the included links in combination with the self-documentation features of the various code. If someone writes up the full, one-stop recipe for a given system, I'll happily link to that too.
[15:23] sourcerer: 2023-03-25 13:03:32 (#jwrd) dorion: jfw, nice ! a walk through sounds good.
[15:26] jfw: possibly missing links are 1) a list of working initial peer IP addresses, 2) explicit instructions on installing the bitcoind binary to the system path, for the unix novice, 3) explicit pointer to bitcoind --help, idem.
[19:19] sstacks: jfw: http://welshcomputing.com/paste/ke7f9uxrk8
[19:21] sstacks: Is this output the expected one?
[20:03] jfw: sstacks: looks good and imported successfully!
Day changed to 2023-03-27
[12:31] whaack: gpg woes
[12:31] whaack: Real name: Will
[12:31] whaack: Name must be at least 5 characters long
[12:52] whaack: jfw: i am a bit confused by task 2 of the hw 'Search the options set in the example gpg.conf in the gpg manual and write what they do.'
[12:53] whaack: i saw a gpg.conf file already in /.gnupg/gpg.conf, was this what you were referring to? i only ask because i don't see an example config inside the actual man page of gpg, i.e. in the text from 'man gpg'
[12:58] whaack: sstacks and jfw: here is my pub key http://welshcomputing.com/paste/kaijam3vqf
[14:41] dorion: whaack, the example config being referenced in question 2 is quoted in question 1. so the question/task is to research those options.
[20:12] sstacks: Hey guys, im a little bit lost (or very lost) about what to do with whaack's pub key
[20:21] dorion: sstacks, you should be ! jfw, is going to go over it at the beginning of class tomorrow since we didn't finish the full class last week. sorry if that wasn't made clear.
[20:24] sstacks: No need to be sorry.. i actually managed to go through most of the tasks, surprisingly
[20:34] sstacks: I did find a good resource that helped me to go thru.
[21:28] dorion: sstack, haha, even better !
[21:33] jfw: whaack: that 5 char minimum is pretty lulzy indeed.
[21:35] jfw: that initial ~/.gnupg/gpg.conf that it installs by itself is actually a good example of what we're NOT throwing at you and why we wrote our own example.
[21:37] jfw: "sorry if that wasn't made clear." - it was definitely mentioned, but not hammered from multiple angles.
[21:39] jfw: whaack: your key looks fine except you actually exported my key too; your whole keyring perhaps.
[21:40] jfw: whaack: one way to see clearer what's in those walls of base64 is to pipe them into 'gpg --list-packets'
[22:04] sstacks: Is it possible that the router is blocking access to a certain site? Im trying to log in into a site where i upload videos
[22:56] dorion: ftr, sstacks and I discussed in PM and have concluded the router is not the issue wrt accessing the site in question.
[22:56] jfw: ah cool.
Day changed to 2023-03-28
[20:51] dorion: whaack, sstacks, fyi running ~5 mins late.
Day changed to 2023-03-29
[23:00] jfw: whaack, sstacks: http://welshcomputing.com/paste/7hgrnipvig , http://welshcomputing.com/paste/6ehr3hf8g6
[23:07] jfw: whaack, sstacks: http://welshcomputing.com/paste/w8cg6h3ntu
[23:13] jfw: I changed up the "game of telephone" exercise a bit compared to the previous instructions. First, you'll have to try decrypting each of the above messages to find out which one is for you. Only one of them is the "hot" message: whoever receives this needs to relay it to the other, as explained before. Another message contains additional instructions for the other person, about what to do on
[23:13] jfw: receiving the "hot" message.
[23:15] jfw: I'm hoping this makes it a bit more fun/suspenseful. (Plus I didn't want to have to come up with two separate clever secret messages!!)
Day changed to 2023-03-30
[21:07] jfw: I regret to note that this drawback now applies to netgear too: just unboxed a "GS305v3" and unlike my old GS105 it only has one indicator light per port, and they don't even do green vs orange.
[21:07] sourcerer: 2023-02-24 19:01:50 (#jwrd) jfw: sstacks: the netgear gs305 or gs308 look probably fine; I'm currently using a "gs605v5" which has a plastic case (metal is preferable). I'm also using a number of tp-link tl-sg105 which is metal and nominally a bit cheaper; basic docs here. only drawback I've noticed is the indicator LEDs are on/off only, no hi
[21:08] jfw: thus, you need 'ethtool' or the like to verify port speed.
[21:11] jfw: on openbsd, ifconfig itself shows the link speed under media info.
[21:11] jfw: but between two such unmanaged switches...? guess you're SOL
[21:14] jfw: its power adapter is on the fat side, too.