Day changed to 2021-05-01
[19:53] jfw: cruciform: did your bitcoind build finish OK?
[19:54] jfw: and did you figure out where to put it & how to invoke at least as far as the --help?
Day changed to 2021-05-02
[19:37] cruciform: jfw, I'll be doing it tomorrow - along with getting to grips with how btc and segwit actually work (thanks for prompting the investigation, above!)
[19:47] jfw: Wouldn't want to have spoiled the surprise of finding out what it even is that you need to do tomorrow by checking earlier on whether the job left running last week even succeeded or failed, huh. Alright then!
[19:50] jfw: "how btc actually works" is kind of a large topic; certainly worth the look though if you're going to use it I'd say.
[19:58] jfw: segwit aka Jim Crow is pretty simple once you get btc: the signature ("witness") is removed ("segregated") from transaction inputs and put in a second-class data structure to make it look like it doesn't count toward the 1mb block size limit. Which it doesn't, because it's not actually in the block.
Day changed to 2021-05-03
[17:08] whaack: howdy
[17:08] whaack: how goes jwrd?
[17:15] jfw: whaack: welcome back to irc, heh.
[17:16] jfw: going alright here, advancing one day at a time as usual
[17:16] jfw: got some new people going through training - "some" meanwhile reduced to one but that's just how it goes
[17:19] jfw: got an upcoming delivery for an all-around IT plant, hardware for now, software to be expanded gradually; currently beating coreboot into shape for a more reliable & scalable x86 based product. Some of it's in the public logs and we're aiming to put more there by default.
[17:20] jfw: what are you up to these days?
[17:22] jfw: oh and dorion's been scouting out the euloran frontiers as you can see.
[17:23] whaack: I've been spending time with my girlfriend, been traveling abit around Costa Rica (went to the Carribean cost recently), playing/practicing the guitar, and surfing quite a bit
[17:24] whaack: what do you mean by you have an upcoming delivery for an all-around IT plant?
[17:25] jfw: sounds like fun, if rather too comfortable.
[17:28] jfw: it means we have a small to medium business customer that wants to increase its independence by hosting its own stuff, so they hired us to plan it out & build it.
[17:30] jfw: by all-around I mean perhaps "full stack" in the true sense - hardware, OS, applications, network. Walls and roof are provided but it turned out even the rack to put the stuff in had to be planned.
[17:31] jfw: what's the girl do, does she work?
[17:31] whaack: Sure, it's been a good time. I'm missing being productive though, so I'm going to try to return to building out my block explorer.
[17:32] whaack: Yeah she is a web designer https://sararovira.com/our-work/
[17:33] jfw: another victim of the ssl-seo pandemic, seems that's almost implicit in 'does web stuff' these days
[17:37] jfw: I know it's been said before but... not like there's anyone or anything outside stopping you from returning to productivity; what "try to return", just do it
[17:38] whaack: yes, unfortunately so, and always using the newest "latest and greatest" version of wordpress. But if you're in the world of what SV expects, imho she does a good job
[17:38] whaack: ^ word.
[17:41] jfw: yes I can see that re the design, all the impressive centering of divs within divs.
[17:41] sourcerer: 2021-02-25 18:42:11 (#jwrd) PeteLondon: not impressed sorry unless you can center a div within a div
[17:41] whaack: So the IT plant is tangential to the jwrd business?
[17:43] whaack: hehe
[17:43] jfw: It's quite relevant to the business because we needed to firm up our hardware options, software stack and hosting setup anyway
[17:45] jfw: and it's a bit more of an entry level opening - meet your existing business needs, using better stuff on the server side without having to completely transform your customers' traditional environment & re-learn what a computer even is.
[17:48] whaack: So you are going to use the IT plant both to host this customer's software stack, as well as your own? And will it be used in the future for other customers' needs? Also not sure exactly what you mean by an entry leveling opening.
[17:50] jfw: well this specific instance is for the customer but we'll reuse the parts & processes thereby developed.
[17:51] jfw: level, not leveling; I mean a less demanding, easier to sell, way to work with us. A cheapening perhaps, sure.
[17:51] dorion: heya whaack, welcome back.
[17:53] whaack: dorion: heyo
[17:53] dorion: whaack, they're keeping their windows/apple clients, at least in short-mid term, but everything/anything that's done on the server is gales linux.
[17:54] jfw: in usa, people with money ~= old people disinclined to learning anything new.
[17:55] dorion: s/money/fiats/
[17:55] whaack: Well there should be lots of young people in the SV world with freshly printed benjies
[17:57] jfw: whatever's left after the SV rents perhaps
[17:57] whaack: Takes a few years I guess to save up past 1 million, but as I understand with only a few years experience the tech companies are paying 250-350 grand a year
[17:58] whaack: idk if it'll stick but i know a few people here in Nosara saving on rent and pulling the same salary they'd make in office given the covid excuse
[17:58] whaack: I've been told they're being dragged back to prison by September though
[17:59] jfw: mm. prisons must be getting bad if they have to pay that much too
[18:00] whaack: brb
[18:01] dorion: whaack, you suppose any are prospects for jwrd training ?
[18:03] jfw: ^^ we do pay for client referrals; got our hands pretty full right now but things could be opening up for new trainees and possibly managed hosting or self-hosting clients in a couple months.
[18:08] jfw: Also interested in potential subordinates though that's probably not a fit for the salaried SV club types. It would be an unpaid internship / volunteering type arrangement, get to know each other, learn to be useful, get your name out by contributing to open source projects; and if you survive that you're in the pool for potential hiring
[18:37] whaack: I met two guys who live together that both have a strong will to learn and a desire to manage their finances. I think they'd be interested if I could sell them on bitcoin in general
[18:44] whaack: I'm also living in the wealthiest part of the Pacific coast atm, so there is certainly a lot more potential clients here. I'll be on the look out for them.
[19:16] jfw: cool. and to revise my above, we do have current availability for one new trainee or group.
[19:21] whaack: Alright, I may be interested myself. I don't want to waste anyone's time so I'll see if I can get into a rhythm with working on my block explorer first.
[19:37] dorion: whaack, you could start with hardware if you want. way less chance of wasting time there. re the block explorer, you starting with irc as primary interface ?
[19:44] whaack: dorion: Can you elaborate on what it would mean to "start with hardware"?
[20:29] whaack: dorion: My first goal re block explorer is to have a local terminal interface, then eventually yes I will make an irc interface
[21:33] dorion: whaack, I mean you can buy our hardware package. laptops, data diode, trng, router. laptops come pre-installed with gales, router with openbsd.
[21:34] dorion: whaack, makes sense re cli as first goal. cool. how far did you get to date on it ?
[21:54] whaack: dorion: I'd be interested in making that purchase. Do you have a system for international shipping?
[21:58] dorion: whaack, we shipped to cruciform in the UK using UPS. how are you receiving packages from the US now ?
[21:58] dorion: whaack, comment in mod queue.
[21:59] whaack: dorion: Right now I myself need to revise my notes to see where I left off. What I recall is that I extended gbw-node so that it can track-all-addresses. Scanning atm, however, is prohibitively slow.
[22:02] whaack: dorion: I've been using a mail forwarding address in Florida
[22:02] whaack: I need to message them with the product and they will give me a quote
[22:03] whaack: Do you have a picture of the product with some fiat denominated price you can send me that I can send them?
[22:05] whaack: Actually hold off on that, I've messaged the company asking what they will need and how they will calculate the price.
[22:11] dorion: whaack, okay. here is a picture and fiat prices. however, in my own morbid laziness/stupidity, I've not published an update to reflect that we changed quoting to btc and cut out usd. I'll get you an invoice tonight and make a proper pricing update this week.
Day changed to 2021-05-04
[01:43] dorion: whaack, here you go http://dorion-mode.com/jwrd-invoice-0010.txt -- doesn't include shipping.
[05:38] jfw: whaack: possibly sqlite is the bottleneck - it has a number of tunables for increasing transaction throughput for whatever tradeoffs, not sure if I yet squeezed every drop there.
[05:41] jfw: whaack: do you still have your FG? we do still have them to sell but guessing you don't need it.
[05:43] jfw: dorion: we also need to add that 'bus blaster' (or comparable jtagtron, but it seemed fine to me) to the hardware requirements for the advanced training module
[05:47] jfw: I've been gradually working on "The Boundary-Scan Handbook" by K. Parker so as to gain more of a clue about that stuff, but we already have it working to read out & program the cpld bitstream.
[05:49] jfw: (very dry reading, but thorough.)
[14:19] whaack: jfw: I still have the FG, but I'd also like to buy another one.
[15:07] cruciform: jfw, build finished; I've added it to my PATH. Runs fine - currently tinkering with the configuration file. http://fixpoint.welshcomputing.com/2021/jwrd-logs-for-may-2021/#1915
[15:07] sourcerer: 2021-05-01 19:53:19 (#jwrd) jfw: cruciform: did your bitcoind build finish OK?
[15:14] whaack: jfw and dorion: I'm happy to send payment as soon as I get a quote and the thumbs up from my mail forwarding company.
[15:21] dorion: hey cruciform, good news !
[15:25] dorion: whaack, ok. cool. do you also want the jtagtron ? it's used for installing fg code if you want to compile it yourself.
[15:26] dorion: whaack, I'll get you a contract today that'll have everything but the final number.
[15:28] whaack: dorion: Yes I'd like to include it.
[15:33] dorion: OK, I'll update the invoice too.
[16:12] dorion: whaack, been meaning to ask, where in mp-wp src do you add the greenlock span ?
[20:18] whaack: dorion: header.php inside my theme's directory
[22:03] dorion: ty whaack.
Day changed to 2021-05-05
[23:55] whaack: I'm writing a verify-hashes-in-block function that does a sanity-check on the data on the auxillary gbw-node db, it makes sure that I can reconstruct the raw hex for each txn from the columns in the db, and then verify the raw hex can hash to the txn id. the function also checks that I can reconstruct the merkle root, as well as hash the fields in the header to get the block hash
[23:56] whaack: I can now reconstruct and verify the merkle root and the block hash / but I'm pulling my hair out being stuck on getting the raw tx hex to hash to the tx id.
[23:58] whaack: My understanding is that I need to take the raw hex and hash it twice, then reverse the results byte order. However if I take any example txn, say https://api.blockcypher.com/v1/btc/main/txs/5fe6030e8a649b3b3fb257303e89a06d6556226e24118b494f9ccbba06e96254?limit=50&includeHex=true , and take the "hex" and run i tthrough an online sha256 tool twice, I don't get the desired hash (in reverse byte
[23:58] whaack: order or not)
Day changed to 2021-05-06
[00:00] whaack: So while I think that I am stuck from some being-tired type problem, maybe there's a chance that I'm missing something about the protocol.
[00:05] whaack: I'm heading out in a couple of minutes and probably logging off for the day but if anyone has any tips fo rhwere I may be going wrong they would be appreciated
[03:09] whaack: I was able to solve my own problem. My issue was I was passing the hex string to the sha256d function as a string, I needed to pass the raw hex through the function a2b_hex first
[03:44] jfw: whaack: yes, and the same confusion would also come up in the "online sha256 tool twice" approach since its output is presumably hex whereas the output of the first sha256 and input of the second is raw bits.
[03:46] jfw: (bits that get grouped into bytes for real-world implementation, sure, but certainly not expanded to ascii-hex.)
[03:46] jfw: otherwise, sounds kinda complicated what you're doing but I'd have to look closer to figure it out.
[04:33] jfw: more specifically I was unclear why bother building merkle trees and such, doesn't bitcoind verify things well enough? but I could see it making sense as test code
[12:31] whaack: jfw: Yes, the way I figured out my problem was from digging into why the "online-converter-method" was not working
[12:34] whaack: And yes, the primary reason for checking the hashes is for testing
[17:54] jfw: today we learn that "Dangerous Prototypes" joins No Such lAbs in the graveyard of failed former JWRD suppliers, indeed died before they could even update the "Manufacturing: Shipping" status on their web site.
[17:57] jfw: The poo-pooed konsoomer toy "Raspberry Pi" however lives on, though caution is needed to not get herded into the new-improved-with-more-evil versions.
[18:03] jfw: whaack: this relates to the JTAG adapter for FG bitstream verification & programming. We didn't have any extra stocked, will see if we can dig up any last reserves from more obscure retailers, but might need to research other options.
[18:05] jfw: in theory it's scarcely more complex a device than a usb-serial converter, but less standard and the software side is likely to be picky.
[18:17] whaack: noted, thanks, sorry to hear that : /
[18:19] whaack: in other obvious news, life is much easier with fiber optic internet, can't believe I was working with DSL for a ~year
[18:36] jfw: true, unless it's from verizon and their idea of installation involves delicate patch fibers left exposed on the ground outside begging to get chopped by the string trimming brigades as happened to me.
[18:38] whaack: that's a theme here as well, very fast fiber optic but with frequent outtages
[18:39] whaack: the best internet i've seen so far is from this company that installs a tower in your property for $1,000 that communicates with their homebase, speedtest showed 20mbps in each direction iirc, and it ~never drops
[18:40] jfw: ugh. reliability is very nearly the *only* thing that matters for home net connection these days in my view. ain't nobody got time for hd video streaming anyway
[18:41] jfw: ah so point-to-point wireless or how do you call it.
[18:42] jfw: possibly line-of-sight
[18:43] whaack: yes it might require unobstructed line of sight
[18:45] jfw: in case youth these days doesn't remember... ye olde Bell Telephone System *did not go down*. as in, ever, even when power was out to half of town. only if a tree fell on your particular line or something.
Day changed to 2021-05-08
[22:15] whaack: I finished writing up the code that verifies the txn hashes, merkle root, and block hashes by reconstructing the blocks via the gbw-node-turned-block-explorer auxillary db. The next TODO items are to create a way to view transactions in the mempool, and to speed up the scanning. I think I'm going to work on speeding up the scanning first.
[22:17] dorion: hey whaack, sounds good, congrats.
[22:18] whaack: ty
Day changed to 2021-05-09
[00:21] dorion had a pleasant round of golf with whitehorn today. he shot a steady 78 (par 70) on his first time out. in 2nd year golfer ups and downs, I was 6 over par over 10 holes with one birdie (!) and was 21 (!) over par across 8 holes for a 97.
[00:22] dorion: whitehorn will be digging into and playing with his new jwrd-ized hardware later this month/early next month.
[00:26] dorion is satisfied enough w/ bogey golf as long as it's w/ people like whitehorn. pretty much a 4 hours walk and talk with stops to check yardages, wind, slope and attempts at making clean, swinging strikes with sticks.
[00:27] dorion: another client, who doesn't yet have an irc nick, joined us on the front 9, so it was a nice little outing.
[02:03] whaack: sounds like a good time indeed
[02:07] whaack: so my internet flickered, and bitcoind kept running, but i guess whatever flickered got it to stoplocking up the "blockpipe", because all of the sudden the scan function went turbospeed
[02:12] whaack: and as per my profiler the function that is taking up all the time is posix.read via the get_block call
[02:20] whaack: so I guess to get the scan function to run in a timely manner for a fully syncd bitcoind, i need to disconnect my bitcoind from the internet or something similar
[05:21] jfw: I have yet to grasp the meaning or significance of most of those golf numbers and suppose I won't unless I try playing some.
[05:22] jfw: (I mean, over/under par is clear enough, it's more how they fit together.)
[05:24] jfw: whaack: have you got concrete measurements for your fast vs. slow scan observations? I haven't found external network connection to make any difference and don't see why it would unless the node itself is syncing from many blocks behind.
[05:26] jfw: and if indeed the holdup is on waiting for bitcoind to reply to the rpc, you'd think this would be independent of partial vs full address indexing because it has to get the same blocks either way.
[05:30] jfw: that said the networking code in bitcoind is a convoluted mixture of different approaches, inheriting the worst of all of them, so it's believable that a peer being unresponsive in some particular way could cause this.
[05:37] jfw: whaack: what does "my profiler" mean, is it something you made or a standard python thing? iirc I've used cProfile
[16:42] whaack: jfw: yes, upon further inspection it seems that disconnecting bitcoind from being able to download blocks only helps the gbw-node scan function go faster if the bitcoin instance is syncing from many blocks behind, as you say
[16:43] whaack: jfw: Yes I'm using both cProfile and calculating how long it takes to scan in 50 blocks
[16:45] whaack: http://paste.deedbot.org/?id=Hnxe
[17:27] jfw: 3 blocks per second / 2 days to completion from zero doesn't look bad even, compared to the overall sync; and that's about the rate I normally get though likely on a slower cpu.
[17:35] jfw: more specifically re the bitcoind networking code, the methodology seemed to be "threads are nifty, I'll use those... oh shit, threads are dangerous and scary, better put in locks everywhere, and recursive locks on top of the locks for good measure" such that for practical purposes it might as well be single-threaded; in which light, validating a block is a lengthy unit of work and probably with
[17:35] jfw: no preemption points for letting other threads run. and thus rpc responses have to wait whenever a new block's being chewed on.
[20:39] whaack: jfw: I figured as much. And yes 2 days isn't bad, although I may have some inefficiencies in my code that are going to show up more prominently when I get to higher block numbers
[20:43] whaack: I'm
[20:45] whaack: *I'm already seeing time spent on sqlite3 excecute/commit functions ~= time spent waiting for rpc requests by block ~180k
[23:48] whaack: I have a backup hdd that I'm trying to mount, which I _appear_ to have done, however I am getting different sizes for my 1 partition depending on whether I run "df -h" or "lsblk" , any idea why this may be the case? Here is the output of my queries http://paste.deedbot.org/?id=ei3z
Day changed to 2021-05-10
[01:26] jfw: whaack: ah yes, 180-195k is where the actual transaction volume started.
[01:27] jfw: not sure why the 195k number sticks in my head actually, possibly it's the height of the trb-included checkpoint.
[01:28] jfw: re partition size, if it were a small difference I'd suspect different unit or rounding style and say to check the full byte or sector wise numbers, but since it's a large difference I'm guessing you expanded the partition without then expanding the filesystem.
[01:48] whaack: jfw: I expanded it using resize2fs to 100 GB successfully, then tried to go to 950 GB (for my 1TB harddrive) and it barfed and now the partition seems corrupted
[01:49] jfw: lol
[01:49] jfw: (I'd normally run it without any options to fill all space but ok)
[01:50] jfw: what symptoms more specifically?
[01:52] whaack: jfw: http://paste.deedbot.org/?id=fLlr
[01:53] jfw: what *did* you do to your poor partition table prior to asking here anyway?
[01:55] whaack: jfw: Last time I was fiddling with it was many months ago, I need to see if I can find some notes
[01:56] jfw: paste me an "fdisk -l /dev/sdb" if you please, that should be a starting point.
[01:57] whaack: jfw: That command returns nothing.
[01:57] whaack: (It does return something for /dev/sda
[01:57] whaack: )
[01:57] jfw: "# resize2fs /dev/sdb1 950000M" - this is definitely a usage I'd avoid - using approximate units near the actual size such that it might overflow and we don't know for certain if/how the software handles that.
[01:58] jfw: nothing at all, not even an error?
[01:59] whaack: jfw: correct, not even an error, just a new bash prompt
[02:00] whaack: jfw: Right re the 950GB. "I'm not sure what's going on here so I'm going to leave some wiggle room"
[02:00] jfw: holy shit you're right, with the centos fdisk I can reproduce this with fdisk -l /dev/nonexistant. none of my "daily" fdisks "work" like that though, not even the barebones busybox.
[02:01] jfw: is there any actual data on this partition? guessing it was pretty fresh by the earlier df.
[02:02] whaack: jfw: No there is not, apart form a test file test.txt with a couple of chars in it
[02:02] whaack: apart from*
[02:02] jfw: cool, just establishing the level of crisis.
[02:02] whaack: thanks, 0 crisis
[02:03] jfw: does sdb still show the same as before in lsblk? is there anything in the tail end of the kernel log suggesting hardware issues?
[02:03] whaack: yes lsblk result remains the same
[02:04] jfw: how about I dunno, "dd if=/dev/sdb bs=512 count=1 | hexdump -C" ?
[02:05] whaack: yes looks like dmesg shows a bunch of possible hardware issues
[02:05] whaack: http://paste.deedbot.org/?id=ccTx
[02:06] whaack: the results of running your suggested command > http://paste.deedbot.org/?id=6IXR
[02:07] jfw: a yeah, kernel log has it "Buffer I/O error on device sdb", similarly "Input/output error" from a userspace program that actually reports the error it gets rather than silently dying.
[02:08] jfw: the good news is you didn't mess up the filesystem or partition table through software means, the bad news is there's an as yet undetermined hardware problem.
[02:08] jfw: how is the drive attached?
[02:09] whaack: jfw: Through a sata cable. IIRC I had problems with this gbefore and was switching through the different ports
[02:09] whaack: And it was a struggle to get to the point where I could write anything to the device
[02:11] jfw: ah ok, internal backup drive. bad cable perhaps?
[02:12] whaack: jfw: Possibly, I don't have another cable handy and probably won't for the next couple of weeks
[02:13] jfw: given you've already tried replugging & with different ports, not much to suggest but to keep replacing stuff until fixed unfortunately.
[02:14] whaack: jfw: Alright, thanks for the help
[02:14] jfw: at least in my own toolkit; possibly there are diagnostics that can be done on the cable or drive or whatnot, hm.
[02:15] jfw: if you can get the drive back online at all there is possibly the SMART data; I've never yet dug into that but there is a 'smartmontools' for linux
[02:16] jfw: hdparm or sdparm might have some kind of tests too.
[02:17] jfw: and you're welcome.
[02:21] whaack: jfw: Alright, I think I'm going to find an alternative backup system in the meantime, anyways I'm likely offline for the night, hopefully in the next week or two i'll have a beta ircbot that will pop in that will let you explore the first 300k blocks or so
[02:22] jfw: one point to expand for the innocent: "kilo" to computer people means 2^10 = 1024 while to everyone else it means 10^3 = 1000, and the remaining prefixes in the same manner; that's why I think of the 'M' as approximate, it could be "imperial or metric megabytes" and you'd have to know the specific tool to be sure.
[02:24] jfw: whaack: heh, then I guess I've been given fair warning to start considering bot policies
Day changed to 2021-05-11
[13:33] dorion: whaack, re the shipping costs. is your provider a mail forwarder that gives you a Miami PO box ? this is what mine is in Panama. when I order something the merchant charges me for the delivery to Miami and my shipping company their fee when I pick it up or they deliver it to me in Panama.
[13:34] dorion: if this is the case for you, I think we should only include the shipping fee to Miami in our quote and you settle up with the CR company for their fee and customs when to receive the delivery in CR. does that make sense to you ?
[15:46] whaack: dorion: Yes, my forwarding address works the same. So yes, your suggested method makes sense to me and is what what I was expecting.
[21:10] whitehorn: hey @dorion, thank you for setting up the golf Saturday, hope to do it again soon
Day changed to 2021-05-12
[02:20] dorion: whitehorn, let's do it. not the coming weekend, but perhaps the following. and let us know how the gales usage goes !
[21:19] whaack: jfw: I'm consistently getting an error, "Connect reset by peer" (see http://paste.deedbot.org/?id=oE-W) which is causing me to manually restart my scan function. Did you notice this error when scanning for your gbw-node wallet code? Any idea as to what it may be? (I have not investigated yet myself)
[21:45] jfw: normally that means the TCP client received an RST response ie abnormal termination / rejection due to mismatched state (the server crashing, some firewall forgetting the state etc.) any clues in the bitcoind debug.log?
[21:46] jfw: and what happens to manual rpc commands ("bitcoind getinfo" etc)?
[21:49] whaack: jfw: I see this error usually a couple hours after it has occured, and I'm not sure what to search for in debug.log, I believe the client keeps running and listening to rpc commands
[21:49] jfw: I don't recall seeing this particular situation; but there is the pitfall that the blockpipe can deadlock if the client is killed during a block transfer, which can be unwedged by 'cat .gbw/blockpipe >/dev/null' prior to retrying client
[21:50] jfw: so then search the debug.log for the last rpc command
[21:53] whaack: jfw: Ah durr, it is likely because I have my node on auto-restart every 8 hours, I'm going to turn that off and see if I get the same problem.
[21:53] jfw: lolz.
[21:59] jfw: just kicked my node which ofc failed to recover after a network outage, possibly the whole 'trb' fleet will start getting blocks more reliably now; I suspect I'm one of a very few bridges between it and the miners, based on the peers that thirstily request a block as soon as I get one.
Day changed to 2021-05-13
[14:42] dorion: whaack, got an order started on the bus blaster v3 jtag debugger. it's a slovakian company that 1) only ships to the yurope and 2) only takes bank wires. I've got a mail forwarder in germany I've set up to cover 1 and waiting on them to send me the wire instructions for 2, but now have enough info to get the invoice filled out and contract ready to sign so will be getting those to you today.
[15:15] dorion just got notice from .sk they're "cheese shop" after all when it comes to the v3 bus blaster, but can do the v4.
[15:21] dorion: whaack, we've not used the v4, but on paper it has the needed jtag debugging capacity.
[16:04] whaack: dorion: We'll give it a shot!
[16:48] dorion: whaack, cool.
Day changed to 2021-05-14
[14:43] dorion: http://fixpoint.welshcomputing.com/2021/jwrd-logs-for-May-2021/#2112 -- yeah, I read that monkey hammer approach. I've been running a loosened malleus for months now without a hitch. jfw too and he's got an article in the pipeline to publish that change.
[14:43] sourcerer: 2021-05-12 21:53:36 (#jwrd) whaack: jfw: Ah durr, it is likely because I have my node on auto-restart every 8 hours, I'm going to turn that off and see if I get the same problem.
[16:12] whaack: dorion: what does a loosened malleus mean?
[16:17] dorion: not as restrictive.
[16:18] dorion: on the malleus_mikehearnificarum
[16:19] whaack: Got it, that's what I figured you meant but wasn't sure.
[22:10] jfw: check it out cruciform, noobs *are* still using 1-addresses! http://trilema.com/2016/lxs-ninxs/#comment-163623
Day changed to 2021-05-15
[05:51] jfw: http://fixpoint.welshcomputing.com/2021/jwrd-logs-for-May-2021/#2114 - turned out there was more to the state of my node than first met the eye, i.e. the conditioned assumption that "it's not getting blocks, must be the usual suckiness" didn't hold up. So there might be a report on that for now in place of the one dorion was eagerly anticipating.
[05:51] sourcerer: 2021-05-12 21:59:11 (#jwrd) jfw: just kicked my node which ofc failed to recover after a network outage, possibly the whole 'trb' fleet will start getting blocks more reliably now; I suspect I'm one of a very few bridges between it and the miners, based on the peers that thirstily request a block as soon as I get one.
[18:18] whaack: I'm starting to hear gears grind as the scan command gets closer to the end of the chain. At block 389035 i'm processing about .2 blocks per second, so at this rate it'll be another 15 days or so until completition, but likely the blocks per second will slow down as the sql statements start to take longer from a larger database
[18:19] whaack: whitehorn: howdy!
[18:25] jfw: whaack: if we had a block explorer perhaps we could even adjust for the block height vs. cumulative size curve!
[18:26] whaack: hehe
[18:27] jfw: is this on an hdd or was that a metaphorical gears grinding?
[18:27] whaack: metaphorical
[18:28] jfw: ah ok then; good luck.
[18:29] whaack: I still have my profiler running, so I'm going to turn that off to hopefully get a decent speedup.
[18:29] whaack: s/my profiler/cProfile
[18:32] jfw: ah, might help, yes. btw I wasn't specifically objecting to the "my" before, just didn't know what it signified.
[18:49] whaack: in any case, removing cProfile did ~nothing to help
[23:31] whitehorn: whack: hi there :)
[23:32] whitehorn: *whaack
[23:35] dorion: whitehorn, whaack lives in costa rica and we met up in panama.
Day changed to 2021-05-16
[01:12] whitehorn: found it @ http://ztkfg.com/2020/01/panama-bien-vestido/
Day changed to 2021-05-17
[00:01] dorion: hey whitehorn, get this : so my grandparents remember your parents as their high school students and then the first time my father saw a computer was when he was taking a class at fair haven high school with your father and they took a field trip to castleton college campus... and here we are now ! lolz.
[18:20] whitehorn: hey dorion, chatted with my Dad and he said June taught latin and french but had my dad's older sister Esther in high school but he took french from her at castleton state college
[18:21] whitehorn: pretty cool, he doesn't remember bringing your dad to csc to see the computer so i'll ask him about that later for sure, thanks for the connections
Day changed to 2021-05-18
[21:42] dorion: http://dorion-mode.com/2021/05/bitcoin-and-beverages-at-baxters-part-ii/
[22:17] dorion: whitehorn, ah there you go, thanks for setting the record straight.
[22:18] dorion: whitehorn, if you want to register your rsa key with deedbot, I'll rate you.
[22:21] dorion: working from the "own all your things" approach, we'll have our own WoT implementation at some point, but for now trinque still shows some sign of life and deedbot is good enough.
Day changed to 2021-05-20
[18:12] whaack: jfw: I'm working on getting desktop notifications working for yrc. I don't think any modification is required to yrc source; I'm just going to ssh into my VM with a command that simultaneously runs tail on the logs, greps each line for "whaack", and uses notify-send should it find a match
[18:14] whaack: I figured I may as well ask here if you already have found a solution to this problem (or have determined it a non-problem)
[18:58] jfw: whaack: some sort of notification for mentions would be nice to have; I've been doing without, so in effect either I'm reading a channel in full or I'm not reachable there.
[18:59] jfw: notify-send sounds like some dbus horror but if it's there for you then I guess that works, for a workaround
[20:11] jfw: whaack: a simpler notification option might be "printf '\a'", sends the terminal bell code, which gets picked up into a visual cue by the fancier terminal emulators.
[20:14] whaack: jwf: hmm and what do I need to get the visual cue? I operate my comp sans sound so the audio does not help
[20:14] whaack: jfw: *
[20:55] dorion: whaack, reads to me like he's saying you need to run one of the terminal emulators, e.g. tmux.
[22:44] billymg: dorion, jfw: i've got my logger up and running now and i've mirrored all the chans that asciilifeform is hosting. i'd like to add this chan as well but figured i'd ask first. if you have a dump of past logs i can import those as well
Day changed to 2021-05-21
[20:40] jfw: whaack, dorion: unless whaack's using something like a vt100 then he's using a terminal *emulator* already, i.e. software program on some host OS that emulates a hardware terminal, be it the linux virtual console, xterm, screen, tmux etc.
[20:41] jfw: but yes "the fancier ones" would be tmux, screen, kde's Konsole can do it, not sure about the gtk ones.
[20:42] jfw: tmux and screen are special cases in that they're both terminal emulators and clients of a downstream "more physical" terminal; proxies if you will.
[20:45] jfw: billymg, dorion: I'm gathering there was some talk of billymg trying an mpwp-integrated logger, but then it looks more like he already went with the flask one; what's the plan there?
[20:46] jfw: mine is indeed based on 'sonofawitch' but with extensive changes to build it up from prototype to more-or-less production system, including an explicit schema for the raw log table, so would be a better starting point, except that I haven't got around to publishing yet.
[20:50] jfw: billymg: for starters I don't mind what you do with your own logs of this channel, we're not aiming to live by the copyright sword or anything. If there's more to the question than that though it may take some thought
[20:51] jfw: I suppose at least publishing the raw table so who wants can mirror cleanly rather than by spidering is clearly sensible.
Day changed to 2021-05-22
[03:18] dorion: http://fixpoint.welshcomputing.com/2021/jwrd-logs-for-May-2021/#2163 -- he said he's doing both : http://logs.bitdash.io/billymg/2021-05-20#1000084
[03:18] sourcerer: 2021-05-21 20:45:07 (#jwrd) jfw: billymg, dorion: I'm gathering there was some talk of billymg trying an mpwp-integrated logger, but then it looks more like he already went with the flask one; what's the plan there?
[03:50] jfw: "taking a look" is not quite the same as "doing" though, hence the question.
[14:44] billymg: http://fixpoint.welshcomputing.com/2021/jwrd-logs-for-May-2021/#2165 << yeah, i just mean i would have my bot idle in this channel so that i can get the logs on my www. i do read/keep up with this channel so i have an interest in having a copy over there (which is where i'll be doing most of my log reading from now on)
[14:44] sourcerer: 2021-05-21 20:50:08 (#jwrd) jfw: billymg: for starters I don't mind what you do with your own logs of this channel, we're not aiming to live by the copyright sword or anything. If there's more to the question than that though it may take some thought
[14:45] billymg: when referencing #jwrd loglines in this chan i would continue to use your logger, no reason to have your logs filled up with links that, for all you know, might lead to a dead site someday
[14:46] billymg: and as dorion mentioned, yes, i do intend to take a look at the bash/mp-wp based logger, but the first thing i want to do is get the results of my btc network crawler published before i return to looking at mp-wp stuff
[18:35] whaack: jfw: Good to know, I was unaware that bash terminals emulated a piece of hardware
[18:44] whaack: And btw, I eventually hacked up a long command that tail'd my local log files, awk'd and grep'd them to get messages that either matched my nick or were direct messages to me, and put out a notification via notify-send. It seemed to work but after about 1-2 mins the connection would somehow drop, and the program would keep running but no new notifications were sent
[18:47] whaack: (in case anyone's curious, this was the command http://paste.deedbot.org/?id=AZ0J, the awk line puts the filenames into the line, which I wanted because I was checking to see if the filename had a "#" to determine whether the message came from a channel or a dm.)
[18:52] whaack: It looks like ssh may be silently dropping the connection when it doesn't receive anything new for > 1 min.
[23:02] dorion: billymg, all good by me to log it.
[23:05] billymg: dorion: awesome, i'll go ahead and add it to the list of chans
[23:14] jfw: billymg: cool, sounds good. the other issue with links to third-party logs, in the event you took yours down (as would be perfectly within your right to do, without the political ties that bind and whatnot), is the divergence of message IDs. bvt had a smart approach to that based on message+context hashes but nobody's made it happen.
[23:21] jfw: whaack: hah, cruciform's next homework can be to explain that command!
[23:23] jfw: I actually didn't know you could call awk functions without parens, yuck.
[23:23] jfw: ("length" in this case)
[23:24] jfw: the buffering stuff makes me want to throw things at unix but I know why you did it
[23:26] jfw: slashes aren't special in grep (either basic or extended RE flavor) so don't need the escaping there; basically they're nothing to do with regex syntax itself but rather a delimiter used by various things to denote an RE. In grep, no such denoting is needed since that's all it does.
[23:30] jfw: not sure on the 'silent drop', I'd think if the ssh terminated then the rest would too. could check ps & netstat to see at least what is or isn't there when it happens
[23:35] jfw: oh yeah, don't confuse bash with the terminal. bash is just a program running on the host, a sort of 100k line expansion of that 'while read' loop; it talks to the terminal via the tty driver (be that a hardware terminal over a serial line or an emulator through a PTY - pseudoterminal device)
[23:42] billymg: http://fixpoint.welshcomputing.com/2021/jwrd-logs-for-May-2021/#2180 << that's a cool idea
[23:42] sourcerer: 2021-05-22 23:14:26 (#jwrd) jfw: billymg: cool, sounds good. the other issue with links to third-party logs, in the event you took yours down (as would be perfectly within your right to do, without the political ties that bind and whatnot), is the divergence of message IDs. bvt had a smart approach to that based on message+context hashes but nobody's made it happen.
Day changed to 2021-05-23
[14:36] dorion: hello cai2920
[18:37] dorion: cai, what brings you here ?
[18:37] dorion: and how goes in panama ?
[18:38] dorion: cai, what can you tell me about counterpoint ?
[22:12] ghosthell: Buying Trans-Universal Transportation Equipment. Please PM ME If you can Supply. 92
[22:55] whaack: ah dang, I'd PM, but I only have 91 of them :(
[22:56] whaack: jfw: adding "-o ServerAliveInterval=25" to ssh seems to have helped keep the connection alive
Day changed to 2021-05-24
[15:50] ghosthell: whaack I'll take what you have
[15:51] whaack: ghosthell: heh, and who may you be?
[16:06] ghosthell: Im Bob. whaack looking to buy either an xk memo replica or backwards compatable dwg
[16:16] whaack: ghosthell: Not sure if that's a question for me or a statement, in any case I don't know what either of those two are
[16:17] ghosthell: oh sorry you caanot help me then
[16:27] whaack: jfw: Do you have a suggestion as to which data format my block explorer should use to return results to queries? I was thinking it should return either as an sexpr or a json. Or perhaps it should just return in a human readable format.
[16:40] dorion: ghosthell, what brings you here and what makes you think you'll find what you're looking for ?
[16:44] ghosthell: I find for every 30 random rooms I go into atleast 1-2 people are aware of this equipment
[16:47] dorion: I see. enlighten us w/ a link, s'il vous plait ?
[16:48] dorion: (cursory web search didn't point to anything obvious)
[21:41] jfw: lolz.
[21:42] jfw: whaack: keepalive helping suggests retarded ISP. it can also make it worse eg if there's packet loss exceeding the timeout interval.
[21:43] jfw: similar to the whole keeping an irc bot online thing.
[21:44] jfw: whaack: depends on the data, if it's just a table of strings with controlled range of characters it may be simplest to just pick a delimiter character.
[21:50] jfw: otherwise I don't have a strong pref between sexpr and json; on the sexpr side there are dialect issues depending how fancy you get, while with json there's unicodeism
[21:53] dorion: I'd say both sexpr and json are human readable. yeah, they're structured so a machine can read them too, but if you claim to be human and can't read those, what you have is a weak claim.
[21:54] jfw: haha true, at least if well wrapped & indented.
[21:55] jfw: still if it's just a table, might as well keep it awk-friendly.
[22:02] dorion defers to jfw.
Day changed to 2021-05-25
[02:20] dorion: hey ghosthell, whether you're going to talk or not, quit with the join/part spam, aite ?
[14:37] jfw: ghosthell: respond to what you were asked.
[14:38] jfw: cruciform: you out there somewhere? how's it going?
[17:55] dorion: welcome back cruciform.
[18:35] whaack: jfw: looks like my blockexplorer has sped up its sync speed since hitting block ~500,000. My guess/thoery is that the introduction of segshit has somehow reduced the amount of work my blockexplorer needs to do to load all the transactions into my db.
[21:16] jfw: for quicker future reference, to ban in yrc: /mode #YourChannel +b Nick!User@Host
[21:18] jfw: probably no point in not going straight to * for the nick and user parts.
[21:21] jfw: whaack: think you'll do anything to substantiate that guess? fwiw it doesn't seem terribly interesting to me; whereas a proper look at performance numbers when tuning the database parameters would be both controllable as an experiment and actionable
[22:53] whaack: jfw: No, I don't have any plans to substantiate the guess. I may fiddle with the db parameters, however.
Day changed to 2021-05-26
[14:05] cai: hello
[14:09] cai: Is there anybody out there?
[14:38] whaack: cai: good morning
[14:53] cai: whaak: is this whaak who lives in Costa Rica?
[15:39] dorion: heh, bienvenidos cai, but where'd you run off to ?
[15:40] dorion: cai, for when you come back : http://fixpoint.welshcomputing.com/2021/jwrd-logs-for-May-2021/#2193
[15:40] sourcerer: 2021-05-23 18:38:51 (#jwrd) dorion: cai, what can you tell me about counterpoint ?
[15:42] dorion: cruciform, holla at be when you're back around.
[15:42] dorion: me*
[18:03] whaack: cai: yup, guessing by dorion's question about counterpoint I know who you are! welcome to irc
[18:05] whaack: cai: Are you still in Panama?
Day changed to 2021-05-27
[13:21] user: Guten morgen
[14:01] user: It appears as though this is not the best time to engage on this channel. I will try at a different time. On the other hand, I will chose a permanent nick soon. I am not sure if I will use cai henceforth or not. Nos vemos!
[16:01] dorion: user/cai, typically afternoons are more active, but am habits could be developed.
[17:11] jfw: doesn't seem like he's figured out the "stay connected or check the log" thing yet.
[17:57] whaack: cruciform: heyyo
[17:57] cruciform: 'ello
[17:58] whaack: ah it is office hour time!
[17:58] cruciform: how's the block explorer going?
[17:59] whaack: pretty well, I made an interesting discovery for myself yesterday
[17:59] cruciform: don't be coy!
[18:01] whaack: On July 4th 2015 bitcoin had a softph0rk, where miners implemented a new rule regarding signatures that reduced the set of allowed signatures. This fork didn't work out as planned, and disrupted the network for an hour or so. From reading the logs though, I had gathered that prb had succeeded a couple of days later, forcing bitcoin users to adhere to the new rule regarding transactions
[18:03] whaack: however I discovered that there fork did not succeeded until months later, until block 388166 with hash 000000000000000005de239ca0d781cc9e78add7c48e94e2264223aa31fc6256, 'high s' signatures can be found
[18:04] cruciform: interesting - have you written an article on your findings?
[18:05] whaack: (old thread re fork http://logs.nosuchlabs.com/log/trilema/2015-07-03#1186436)
[18:07] cruciform: thanks for the link
[18:07] whaack: cruciform: not yet, I've gone down the rabbit hole of learning the required math for understanding signatures maybe with elliptic curves
[18:07] whaack: made* with elliptic curves
[18:08] cruciform: cool! I've a bunch of rabbit-holing to do wrt how bitcoin works under the hood
[18:08] whaack: it seems to be a ~lifelong journey
[18:08] whaack: (not that it has to be that way)
[18:09] cruciform: heh - believe me, I know all about staying home!
[18:09] whaack: cruciform: what are you working on atm?
[18:11] cruciform: moving boxes into new house; otherwise, JWRD-stuff and gonna get Eulora setup
[18:12] cruciform will be back tomorrow
[18:13] whaack: cool, congrats on the new house
[18:13] whaack: hasta manana
[18:25] jfw: whaack, not that I looked that closely but I thought the high-s thing was a tx acceptance / relay rule rather than block validation rule ie not a softfork
[18:28] whaack: jfw: It's not so clear to me either way
[18:30] whaack: Miners are not including high s sigs in their blocks, whether they would reject a block with a high s signature, idk
[18:34] whaack: Also, there may be high S sigs somewhere between block 400,000 -- present height, I've only seen for myself that there are no high s sigs between 388,167 and 400,000
[18:39] jfw: so your interesting discovery seems to be mostly of your own confusion really :P
[18:40] jfw: would still make an interesting writeup to capture what you learn though.
[18:43] whaack: well that's why i clarified it was interesting for myself! That the softphork never happened, or at least not until December 2015, is certainly well known in many circles
[18:45] jfw: oh I see, I'd parsed as "made a discovery for myself that was interesting"
[18:49] whaack: In any case, yes I will do a writeup on my findings soon
[18:54] jfw: ah, looks like it was a relay-rule thing at first but then indeed included with a couple other things in the bip66 fork attempt.
Day changed to 2021-05-28
[20:50] anotheruser: Guten abend
[20:51] anotheruser: Is there anybody out there?
[20:52] whaack: anotheruser: i'm here now
[20:53] anotheruser: whaak: Is this whaack who lives in Costa Rica?
[20:53] whaack: yessir
[20:54] whaack: anotheruser: I actually responded to your question before, idk if you saw but there are logs here http://fixpoint.welshcomputing.com/2021/jwrd-logs-for-May-2021/#2225
[20:54] sourcerer: 2021-05-26 14:05:26 (#jwrd) cai: hello
[20:54] anotheruser: whaak: Are you still disconfiguring people's mouse settings?
[20:55] whaack: disconfiguring people's mouse settings?? Am I forgetting something we talked about?
[20:55] anotheruser: whaak: I didn't see your response. This is my first experience using irc/yrc so I am still learning.
[20:55] whaack: cool, happy to help :)
[20:55] anotheruser: whaak: This is Chad. We met here in Panama, right?
[20:56] whaack: yup I remember, I was there for your presentation on music theory
[20:56] anotheruser: Yes!
[20:56] whaack: how's composing going?
[20:57] anotheruser: To my uunderstading, upi said that one of your first adventures in high school was disconfiguring mouse settings to confuse users.
[20:57] anotheruser: you said*
[20:57] anotheruser: composing is going well. I am making progress, step by step
[20:58] anotheruser: How about you? What are you working on these days?
[20:59] whaack: I'm working on a bitcoin block explorer, and through that I've been trying to get a grasp on the mathematics behind various functions used in the bitcoin protocol
[21:01] whaack: anotheruser: i have a demo bot in my channel #whaacked http://logs.bitdash.io/whaacked/2021-05-27#1000042
[21:01] bitdashbot: (whaacked) 2021-05-27 whaack: !e view-block 199384
[21:01] whaack: anotheruser: hm no only mischief I can remember that is close to messing with mouse settings was a failed attempt to make an aimbot for halo 1
[21:02] anotheruser: Interesting. I will check it out the demo. Since there are other block explorers out there, what do you hope to achieve by creating a new one?
[21:04] whaack: anotheruser: I have a short article that answers your question pretty directly http://ztkfg.com/2020/07/a-bitcoin-block-explorer-the-why-the-how/
[21:05] anotheruser: Alright!
[21:07] whaack: anotheruser: Do you have anything you've composed that you can share? And are you composing for a specific instrument or for an ensemble / orchestra?
[21:08] whaack: I've been studying the classical guitar regularly, although I've taken a break the past two weeks because I've developed some strain in my wrists.
[21:09] whaack: anotheruser: Also are you using yrc or another client atm? It may be a good time to figure out some questions you have with yrc
[21:12] anotheruser: I am having difficulty viewing the demo. What format is the demo in?
[21:13] whaack: anotheruser: First you have to join the channel #whaacked
[21:13] whaack: with /join #whaacked
[21:13] anotheruser: gotcha
[21:13] whaack: (the interface is through irc, if that wasn't clear)
[21:14] anotheruser: I love learning new information and asking kindergardern questions
[21:14] anotheruser: kindergardener
[21:14] anotheruser: Alright. Gotcha
[21:15] anotheruser: I am glad to hear that have continued studying classical guitar. I hope to hear you in the new future.
[21:15] anotheruser: And taking breaks can be good thing sometimes.
[21:16] anotheruser: On my side, yes, I have alternated my focus between learning a DAW and Music Theory.
[21:16] whaack: what's a DAW?
[21:16] anotheruser: Digital Audio Workstation
[21:18] anotheruser: Due to my specific situation, I have decided to learn a DAW and write electronic music, too.
[21:19] anotheruser: I have some finished songs but I prefer to share one with you that I finished a few days ago.
[21:19] whaack: awesome
[21:20] anotheruser: However, I need to master before sharing it. I will share it with you in a week or two. I have noticed that it is better to wait a few weeks before sharing music because I always end of hearing some small thing in the song that I want to change.
[21:21] anotheruser: always end up*
[21:22] whaack: alright I'll be here heh
[21:22] anotheruser: cool
[21:23] anotheruser: I need to get back to work! Talk to you soon. I am connected here now. I will also join your channel
[21:24] whaack: anotheruser: sounds good, enjoy
[21:24] anotheruser: You too
Day changed to 2021-05-29
[16:42] anotheruser: Guten abend
[16:56] anotheruser: dorion: I see that you responded via the logs. In regards to your question about counterpoint, I can tell you that if one moves from a perfect consonance to another perfect consonance one must proceed in contrary or oblique motion. However, you already know this.
[16:59] anotheruser: dorion: I am running across a new problem while using FL Studio, which is that it is very difficult to view notated music, indeed, it is not possible; it only displays midi notes, and thus has me considering changing to a different DAW called Cubase.
[17:00] anotheruser: dorion: What is new with you? What new problems are you solving up there?
[18:37] whaack: jfw: I'm attempting to write a basic ecdsa signing tool in order to "fully grasp" how the ECDSA works. I've tried to be honest with myself, making sure that I'm not cutting too many corners and at least have a decent understanding of all the proofs and lemmas that back ecdsa. But I've hit what appears to be a bring wall, something above my pay grade. The problem is that from what I understand so
[18:37] whaack: far, to be convinced the generator point G for a curve generates all the points on the curve, I need to be assured that there are a prime number of points on the curve over its finite field (+ the additive identity point at infinity). The problem is that it looks like I'm going to have to grok this proof https://en.wikipedia.org/wiki/Schoof%27s_algorithm#The_algorithm (plz excuse the derpapedia
[18:37] whaack: link) in order to convince myself that there are a prime number of points on the curve for secp256k1
[18:38] whaack: brick* wall
[18:43] whaack: jfw: When you wrote your signing algo for gbw-node, did you work through the various proofs re ecdsa, and did you come accross this one? (The link is an algo, but the 'proof' would be running the algorithm and being convinced that secp256k1 has a prime number of points) Do you have a suggestion as to where I should begin? Should I work through some math texts? Do you think I should give up / put
[18:43] whaack: aside for later the task of grokking ecdsa?
[19:32] jfw: whaack: either you're going deeper on the math than I did, or you're falling into the depths for not having enough grasp of the surface, I can't quite tell.
[19:33] whaack: Maybe simultaneously going deeper in some areas and having less of a grasp on the surface.
[19:33] jfw: Mainly what I worked through was satisfying myself that my code implemented the specs, not that the specs are correct / secure / whatever
[19:34] jfw: far as I understand there is no security proof of the sort one would like, though certain properties can at least be observed, clarifying the assumptions it rests on and that sort of thing.
[19:35] jfw: why does there need to be a prime number of points? if I'm recalling my basics now, the generator generates all points on the curve by definition
[19:37] jfw: ah, it would be possible to choose a generator that doesn't cover all points that pass the "on the curve" test, indeed.
[19:37] jfw: (if it's not prime.)
[19:37] whaack: right, so how can one be convinced that the generator for a curve is generating all the points, without enumerating all the points
[19:40] jfw: and if it didn't generate all the points, there'd be fewer bits in the key space than advertised, I suppose.
[19:40] whaack: correct
[19:41] whaack: (I also haven't grasped why a prime number of points on the curve means that every point is a generator)
[19:42] whaack: I'm playing around with the curve y^2 = x^3 + 7 mod 17 , which has 18 points, and most points are not generators and (15,13) is the only generator I know of
[19:42] jfw: there's a couple magic-looking numbers in the secp256k1 parameters, though the generator looks the most magical indeed
[19:47] jfw: a simpler kind of group to play with might be modular multiplication
[19:48] jfw: with a prime modulus, you should find that the powers of any element will generate the whole group, whereas not so if composite (possibly only its coprimes will)
[19:49] whaack: jfw: I don't think that's exactly correct...one sec
[19:49] jfw: myeah, certainly powers of 1 aren't generating anything
[19:50] whaack: jfw: that, but I was referring to also perfect squares
[19:50] whaack: take the powers of "4" mod 7 for example
[19:51] jfw: right, hmm.
[19:51] whaack: 4, 9, 16, all of those will give you problems. But there are also other numbers that don't appear to be perfect squares but are when you are referring to GF(p)
[19:54] jfw: what can I say, three years ago I think I could have given the correct example but that part of the brain has perhaps rusted.
[19:59] whaack: (for the logs, an example of a not-so-obvoius perfect square mod P is 5 mod 11, 5 is (7 ** 2) % 11, and therefore you cannot generate all the values in GF(11) simply by taking powers of 5
[20:03] jfw: to the higher question though, I can't really say what's best for you but if you find this interesting then it makes sense to me to get to the bottom of it, especially if you do the same for RSA and compare what you find.
[20:05] jfw: just don't get caught in the "go away with your silly demands that the rent be paid, can't you see I'm doing Important Maffs?" trap with it.
[20:10] whaack: ah forget it then, avoiding my irl concerns by replacing them with math problems was half the point!
[20:14] whaack: jfw: joking aside, that advice is important, thank you. Maybe I'll try to dedicate a copule of hours each week to a text on group/ring/field theory, and work my way up from there.
[20:15] jfw: heh, sounds good. 'modern algebra' is possibly the umbrella term there, with a side of 'number theory'
Day changed to 2021-05-30
[14:58] whaack: jfww: http://fixpoint.welshcomputing.com/2021/jwrd-logs-for-May-2021/#2355 << I think I figured out the example you were looking to give. It's the successive multiples (not powers) of a that generate all the elements in mod P if a is relatively prime with P, i.e. 1a, 2a, 3a...(P)(a)
[14:58] sourcerer: 2021-05-29 19:54:06 (#jwrd) jfw: what can I say, three years ago I think I could have given the correct example but that part of the brain has perhaps rusted.
[16:23] jfw: whaack: nice, that's the one - so if P is prime then any 'a' works except for the additive identity. Think I got tripped up trying to use literal exponentiation where all that was needed was group scalar multiplication, which repeated addition mod P fits just fine.
[16:29] jfw: The EC 'exponentiation' is such a thing, just repetition of its 'point addition' the specified (scalar) number of times. It's purely a group, no multiplication operation is defined - except that finite field ops are used as an 'ingredient' to define the arithmetic on the point coordinates for the group operation & membership test.
[16:31] jfw: Implementation is fancier than just repetition because it needs to run in polynomial time - can leverage the associative property to reuse sub-computations, x+x+x+x = (x+x) + (x+x) and so on.
[16:37] jfw: I went a step further in mine (because it was so godawful slow), noting that the 'x' is always the same: the public generator, so all its successive doublings can be precomputed. thus to exponentiate you just go through the bits of the exponent, adding in the respective entry from the table of G^0, G^1, G^2, G^4, G^8... gated on the bit. so the 3 additions in the above trivial example reduce to 1.
[16:40] jfw: er, zero actually since x^4 would be in the table directly - actual # of additions, if you do it timing-invariant, would be = to the number of bits in the key (exponent) I expect.
[17:08] jfw: Big update re JWRD apu1 firmware: after a long slog through the coreboot & seabios config menus, capture of the sgabios code, in-system flashing and some minor iterations to work out the kinks, this is all validated & working.
[17:08] sourcerer: 2021-04-30 17:39:46 (#jwrd) jfw: that is, I'm anticipating that I can use a stack of mainline coreboot (same one captured in '16 for thinkpads), mainline SeaBIOS (idem), and - here's the previously unknown - a mainline sgabios to accomplish the serial console redirection (which I'll note appears to have already existed, as a nice standalone thing, long before they went and did their own
[17:11] jfw: The stock SeaBIOS "Press ESC for boot menu" prompt as well as the LILO boot menu prompt are working unmodified i.e. through the sgabios serial console redirection; boot from SD card appears to work too (at least it's shown as an option when I plug in a card, though I don't have any actually bootable for x86 atm) which wasn't supported in the OEM firmware; and of course Linux boots up.
[19:53] jfw: cruciform: did your bitcoind build finish OK?
[19:54] jfw: and did you figure out where to put it & how to invoke at least as far as the --help?
Day changed to 2021-05-02
[19:37] cruciform: jfw, I'll be doing it tomorrow - along with getting to grips with how btc and segwit actually work (thanks for prompting the investigation, above!)
[19:47] jfw: Wouldn't want to have spoiled the surprise of finding out what it even is that you need to do tomorrow by checking earlier on whether the job left running last week even succeeded or failed, huh. Alright then!
[19:50] jfw: "how btc actually works" is kind of a large topic; certainly worth the look though if you're going to use it I'd say.
[19:58] jfw: segwit aka Jim Crow is pretty simple once you get btc: the signature ("witness") is removed ("segregated") from transaction inputs and put in a second-class data structure to make it look like it doesn't count toward the 1mb block size limit. Which it doesn't, because it's not actually in the block.
Day changed to 2021-05-03
[17:08] whaack: howdy
[17:08] whaack: how goes jwrd?
[17:15] jfw: whaack: welcome back to irc, heh.
[17:16] jfw: going alright here, advancing one day at a time as usual
[17:16] jfw: got some new people going through training - "some" meanwhile reduced to one but that's just how it goes
[17:19] jfw: got an upcoming delivery for an all-around IT plant, hardware for now, software to be expanded gradually; currently beating coreboot into shape for a more reliable & scalable x86 based product. Some of it's in the public logs and we're aiming to put more there by default.
[17:20] jfw: what are you up to these days?
[17:22] jfw: oh and dorion's been scouting out the euloran frontiers as you can see.
[17:23] whaack: I've been spending time with my girlfriend, been traveling abit around Costa Rica (went to the Carribean cost recently), playing/practicing the guitar, and surfing quite a bit
[17:24] whaack: what do you mean by you have an upcoming delivery for an all-around IT plant?
[17:25] jfw: sounds like fun, if rather too comfortable.
[17:28] jfw: it means we have a small to medium business customer that wants to increase its independence by hosting its own stuff, so they hired us to plan it out & build it.
[17:30] jfw: by all-around I mean perhaps "full stack" in the true sense - hardware, OS, applications, network. Walls and roof are provided but it turned out even the rack to put the stuff in had to be planned.
[17:31] jfw: what's the girl do, does she work?
[17:31] whaack: Sure, it's been a good time. I'm missing being productive though, so I'm going to try to return to building out my block explorer.
[17:32] whaack: Yeah she is a web designer https://sararovira.com/our-work/
[17:33] jfw: another victim of the ssl-seo pandemic, seems that's almost implicit in 'does web stuff' these days
[17:37] jfw: I know it's been said before but... not like there's anyone or anything outside stopping you from returning to productivity; what "try to return", just do it
[17:38] whaack: yes, unfortunately so, and always using the newest "latest and greatest" version of wordpress. But if you're in the world of what SV expects, imho she does a good job
[17:38] whaack: ^ word.
[17:41] jfw: yes I can see that re the design, all the impressive centering of divs within divs.
[17:41] sourcerer: 2021-02-25 18:42:11 (#jwrd) PeteLondon: not impressed sorry unless you can center a div within a div
[17:41] whaack: So the IT plant is tangential to the jwrd business?
[17:43] whaack: hehe
[17:43] jfw: It's quite relevant to the business because we needed to firm up our hardware options, software stack and hosting setup anyway
[17:45] jfw: and it's a bit more of an entry level opening - meet your existing business needs, using better stuff on the server side without having to completely transform your customers' traditional environment & re-learn what a computer even is.
[17:48] whaack: So you are going to use the IT plant both to host this customer's software stack, as well as your own? And will it be used in the future for other customers' needs? Also not sure exactly what you mean by an entry leveling opening.
[17:50] jfw: well this specific instance is for the customer but we'll reuse the parts & processes thereby developed.
[17:51] jfw: level, not leveling; I mean a less demanding, easier to sell, way to work with us. A cheapening perhaps, sure.
[17:51] dorion: heya whaack, welcome back.
[17:53] whaack: dorion: heyo
[17:53] dorion: whaack, they're keeping their windows/apple clients, at least in short-mid term, but everything/anything that's done on the server is gales linux.
[17:54] jfw: in usa, people with money ~= old people disinclined to learning anything new.
[17:55] dorion: s/money/fiats/
[17:55] whaack: Well there should be lots of young people in the SV world with freshly printed benjies
[17:57] jfw: whatever's left after the SV rents perhaps
[17:57] whaack: Takes a few years I guess to save up past 1 million, but as I understand with only a few years experience the tech companies are paying 250-350 grand a year
[17:58] whaack: idk if it'll stick but i know a few people here in Nosara saving on rent and pulling the same salary they'd make in office given the covid excuse
[17:58] whaack: I've been told they're being dragged back to prison by September though
[17:59] jfw: mm. prisons must be getting bad if they have to pay that much too
[18:00] whaack: brb
[18:01] dorion: whaack, you suppose any are prospects for jwrd training ?
[18:03] jfw: ^^ we do pay for client referrals; got our hands pretty full right now but things could be opening up for new trainees and possibly managed hosting or self-hosting clients in a couple months.
[18:08] jfw: Also interested in potential subordinates though that's probably not a fit for the salaried SV club types. It would be an unpaid internship / volunteering type arrangement, get to know each other, learn to be useful, get your name out by contributing to open source projects; and if you survive that you're in the pool for potential hiring
[18:37] whaack: I met two guys who live together that both have a strong will to learn and a desire to manage their finances. I think they'd be interested if I could sell them on bitcoin in general
[18:44] whaack: I'm also living in the wealthiest part of the Pacific coast atm, so there is certainly a lot more potential clients here. I'll be on the look out for them.
[19:16] jfw: cool. and to revise my above, we do have current availability for one new trainee or group.
[19:21] whaack: Alright, I may be interested myself. I don't want to waste anyone's time so I'll see if I can get into a rhythm with working on my block explorer first.
[19:37] dorion: whaack, you could start with hardware if you want. way less chance of wasting time there. re the block explorer, you starting with irc as primary interface ?
[19:44] whaack: dorion: Can you elaborate on what it would mean to "start with hardware"?
[20:29] whaack: dorion: My first goal re block explorer is to have a local terminal interface, then eventually yes I will make an irc interface
[21:33] dorion: whaack, I mean you can buy our hardware package. laptops, data diode, trng, router. laptops come pre-installed with gales, router with openbsd.
[21:34] dorion: whaack, makes sense re cli as first goal. cool. how far did you get to date on it ?
[21:54] whaack: dorion: I'd be interested in making that purchase. Do you have a system for international shipping?
[21:58] dorion: whaack, we shipped to cruciform in the UK using UPS. how are you receiving packages from the US now ?
[21:58] dorion: whaack, comment in mod queue.
[21:59] whaack: dorion: Right now I myself need to revise my notes to see where I left off. What I recall is that I extended gbw-node so that it can track-all-addresses. Scanning atm, however, is prohibitively slow.
[22:02] whaack: dorion: I've been using a mail forwarding address in Florida
[22:02] whaack: I need to message them with the product and they will give me a quote
[22:03] whaack: Do you have a picture of the product with some fiat denominated price you can send me that I can send them?
[22:05] whaack: Actually hold off on that, I've messaged the company asking what they will need and how they will calculate the price.
[22:11] dorion: whaack, okay. here is a picture and fiat prices. however, in my own morbid laziness/stupidity, I've not published an update to reflect that we changed quoting to btc and cut out usd. I'll get you an invoice tonight and make a proper pricing update this week.
Day changed to 2021-05-04
[01:43] dorion: whaack, here you go http://dorion-mode.com/jwrd-invoice-0010.txt -- doesn't include shipping.
[05:38] jfw: whaack: possibly sqlite is the bottleneck - it has a number of tunables for increasing transaction throughput for whatever tradeoffs, not sure if I yet squeezed every drop there.
[05:41] jfw: whaack: do you still have your FG? we do still have them to sell but guessing you don't need it.
[05:43] jfw: dorion: we also need to add that 'bus blaster' (or comparable jtagtron, but it seemed fine to me) to the hardware requirements for the advanced training module
[05:47] jfw: I've been gradually working on "The Boundary-Scan Handbook" by K. Parker so as to gain more of a clue about that stuff, but we already have it working to read out & program the cpld bitstream.
[05:49] jfw: (very dry reading, but thorough.)
[14:19] whaack: jfw: I still have the FG, but I'd also like to buy another one.
[15:07] cruciform: jfw, build finished; I've added it to my PATH. Runs fine - currently tinkering with the configuration file. http://fixpoint.welshcomputing.com/2021/jwrd-logs-for-may-2021/#1915
[15:07] sourcerer: 2021-05-01 19:53:19 (#jwrd) jfw: cruciform: did your bitcoind build finish OK?
[15:14] whaack: jfw and dorion: I'm happy to send payment as soon as I get a quote and the thumbs up from my mail forwarding company.
[15:21] dorion: hey cruciform, good news !
[15:25] dorion: whaack, ok. cool. do you also want the jtagtron ? it's used for installing fg code if you want to compile it yourself.
[15:26] dorion: whaack, I'll get you a contract today that'll have everything but the final number.
[15:28] whaack: dorion: Yes I'd like to include it.
[15:33] dorion: OK, I'll update the invoice too.
[16:12] dorion: whaack, been meaning to ask, where in mp-wp src do you add the greenlock span ?
[20:18] whaack: dorion: header.php inside my theme's directory
[22:03] dorion: ty whaack.
Day changed to 2021-05-05
[23:55] whaack: I'm writing a verify-hashes-in-block function that does a sanity-check on the data on the auxillary gbw-node db, it makes sure that I can reconstruct the raw hex for each txn from the columns in the db, and then verify the raw hex can hash to the txn id. the function also checks that I can reconstruct the merkle root, as well as hash the fields in the header to get the block hash
[23:56] whaack: I can now reconstruct and verify the merkle root and the block hash / but I'm pulling my hair out being stuck on getting the raw tx hex to hash to the tx id.
[23:58] whaack: My understanding is that I need to take the raw hex and hash it twice, then reverse the results byte order. However if I take any example txn, say https://api.blockcypher.com/v1/btc/main/txs/5fe6030e8a649b3b3fb257303e89a06d6556226e24118b494f9ccbba06e96254?limit=50&includeHex=true , and take the "hex" and run i tthrough an online sha256 tool twice, I don't get the desired hash (in reverse byte
[23:58] whaack: order or not)
Day changed to 2021-05-06
[00:00] whaack: So while I think that I am stuck from some being-tired type problem, maybe there's a chance that I'm missing something about the protocol.
[00:05] whaack: I'm heading out in a couple of minutes and probably logging off for the day but if anyone has any tips fo rhwere I may be going wrong they would be appreciated
[03:09] whaack: I was able to solve my own problem. My issue was I was passing the hex string to the sha256d function as a string, I needed to pass the raw hex through the function a2b_hex first
[03:44] jfw: whaack: yes, and the same confusion would also come up in the "online sha256 tool twice" approach since its output is presumably hex whereas the output of the first sha256 and input of the second is raw bits.
[03:46] jfw: (bits that get grouped into bytes for real-world implementation, sure, but certainly not expanded to ascii-hex.)
[03:46] jfw: otherwise, sounds kinda complicated what you're doing but I'd have to look closer to figure it out.
[04:33] jfw: more specifically I was unclear why bother building merkle trees and such, doesn't bitcoind verify things well enough? but I could see it making sense as test code
[12:31] whaack: jfw: Yes, the way I figured out my problem was from digging into why the "online-converter-method" was not working
[12:34] whaack: And yes, the primary reason for checking the hashes is for testing
[17:54] jfw: today we learn that "Dangerous Prototypes" joins No Such lAbs in the graveyard of failed former JWRD suppliers, indeed died before they could even update the "Manufacturing: Shipping" status on their web site.
[17:57] jfw: The poo-pooed konsoomer toy "Raspberry Pi" however lives on, though caution is needed to not get herded into the new-improved-with-more-evil versions.
[18:03] jfw: whaack: this relates to the JTAG adapter for FG bitstream verification & programming. We didn't have any extra stocked, will see if we can dig up any last reserves from more obscure retailers, but might need to research other options.
[18:05] jfw: in theory it's scarcely more complex a device than a usb-serial converter, but less standard and the software side is likely to be picky.
[18:17] whaack: noted, thanks, sorry to hear that : /
[18:19] whaack: in other obvious news, life is much easier with fiber optic internet, can't believe I was working with DSL for a ~year
[18:36] jfw: true, unless it's from verizon and their idea of installation involves delicate patch fibers left exposed on the ground outside begging to get chopped by the string trimming brigades as happened to me.
[18:38] whaack: that's a theme here as well, very fast fiber optic but with frequent outtages
[18:39] whaack: the best internet i've seen so far is from this company that installs a tower in your property for $1,000 that communicates with their homebase, speedtest showed 20mbps in each direction iirc, and it ~never drops
[18:40] jfw: ugh. reliability is very nearly the *only* thing that matters for home net connection these days in my view. ain't nobody got time for hd video streaming anyway
[18:41] jfw: ah so point-to-point wireless or how do you call it.
[18:42] jfw: possibly line-of-sight
[18:43] whaack: yes it might require unobstructed line of sight
[18:45] jfw: in case youth these days doesn't remember... ye olde Bell Telephone System *did not go down*. as in, ever, even when power was out to half of town. only if a tree fell on your particular line or something.
Day changed to 2021-05-08
[22:15] whaack: I finished writing up the code that verifies the txn hashes, merkle root, and block hashes by reconstructing the blocks via the gbw-node-turned-block-explorer auxillary db. The next TODO items are to create a way to view transactions in the mempool, and to speed up the scanning. I think I'm going to work on speeding up the scanning first.
[22:17] dorion: hey whaack, sounds good, congrats.
[22:18] whaack: ty
Day changed to 2021-05-09
[00:21] dorion had a pleasant round of golf with whitehorn today. he shot a steady 78 (par 70) on his first time out. in 2nd year golfer ups and downs, I was 6 over par over 10 holes with one birdie (!) and was 21 (!) over par across 8 holes for a 97.
[00:22] dorion: whitehorn will be digging into and playing with his new jwrd-ized hardware later this month/early next month.
[00:26] dorion is satisfied enough w/ bogey golf as long as it's w/ people like whitehorn. pretty much a 4 hours walk and talk with stops to check yardages, wind, slope and attempts at making clean, swinging strikes with sticks.
[00:27] dorion: another client, who doesn't yet have an irc nick, joined us on the front 9, so it was a nice little outing.
[02:03] whaack: sounds like a good time indeed
[02:07] whaack: so my internet flickered, and bitcoind kept running, but i guess whatever flickered got it to stoplocking up the "blockpipe", because all of the sudden the scan function went turbospeed
[02:12] whaack: and as per my profiler the function that is taking up all the time is posix.read via the get_block call
[02:20] whaack: so I guess to get the scan function to run in a timely manner for a fully syncd bitcoind, i need to disconnect my bitcoind from the internet or something similar
[05:21] jfw: I have yet to grasp the meaning or significance of most of those golf numbers and suppose I won't unless I try playing some.
[05:22] jfw: (I mean, over/under par is clear enough, it's more how they fit together.)
[05:24] jfw: whaack: have you got concrete measurements for your fast vs. slow scan observations? I haven't found external network connection to make any difference and don't see why it would unless the node itself is syncing from many blocks behind.
[05:26] jfw: and if indeed the holdup is on waiting for bitcoind to reply to the rpc, you'd think this would be independent of partial vs full address indexing because it has to get the same blocks either way.
[05:30] jfw: that said the networking code in bitcoind is a convoluted mixture of different approaches, inheriting the worst of all of them, so it's believable that a peer being unresponsive in some particular way could cause this.
[05:37] jfw: whaack: what does "my profiler" mean, is it something you made or a standard python thing? iirc I've used cProfile
[16:42] whaack: jfw: yes, upon further inspection it seems that disconnecting bitcoind from being able to download blocks only helps the gbw-node scan function go faster if the bitcoin instance is syncing from many blocks behind, as you say
[16:43] whaack: jfw: Yes I'm using both cProfile and calculating how long it takes to scan in 50 blocks
[16:45] whaack: http://paste.deedbot.org/?id=Hnxe
[17:27] jfw: 3 blocks per second / 2 days to completion from zero doesn't look bad even, compared to the overall sync; and that's about the rate I normally get though likely on a slower cpu.
[17:35] jfw: more specifically re the bitcoind networking code, the methodology seemed to be "threads are nifty, I'll use those... oh shit, threads are dangerous and scary, better put in locks everywhere, and recursive locks on top of the locks for good measure" such that for practical purposes it might as well be single-threaded; in which light, validating a block is a lengthy unit of work and probably with
[17:35] jfw: no preemption points for letting other threads run. and thus rpc responses have to wait whenever a new block's being chewed on.
[20:39] whaack: jfw: I figured as much. And yes 2 days isn't bad, although I may have some inefficiencies in my code that are going to show up more prominently when I get to higher block numbers
[20:43] whaack: I'm
[20:45] whaack: *I'm already seeing time spent on sqlite3 excecute/commit functions ~= time spent waiting for rpc requests by block ~180k
[23:48] whaack: I have a backup hdd that I'm trying to mount, which I _appear_ to have done, however I am getting different sizes for my 1 partition depending on whether I run "df -h" or "lsblk" , any idea why this may be the case? Here is the output of my queries http://paste.deedbot.org/?id=ei3z
Day changed to 2021-05-10
[01:26] jfw: whaack: ah yes, 180-195k is where the actual transaction volume started.
[01:27] jfw: not sure why the 195k number sticks in my head actually, possibly it's the height of the trb-included checkpoint.
[01:28] jfw: re partition size, if it were a small difference I'd suspect different unit or rounding style and say to check the full byte or sector wise numbers, but since it's a large difference I'm guessing you expanded the partition without then expanding the filesystem.
[01:48] whaack: jfw: I expanded it using resize2fs to 100 GB successfully, then tried to go to 950 GB (for my 1TB harddrive) and it barfed and now the partition seems corrupted
[01:49] jfw: lol
[01:49] jfw: (I'd normally run it without any options to fill all space but ok)
[01:50] jfw: what symptoms more specifically?
[01:52] whaack: jfw: http://paste.deedbot.org/?id=fLlr
[01:53] jfw: what *did* you do to your poor partition table prior to asking here anyway?
[01:55] whaack: jfw: Last time I was fiddling with it was many months ago, I need to see if I can find some notes
[01:56] jfw: paste me an "fdisk -l /dev/sdb" if you please, that should be a starting point.
[01:57] whaack: jfw: That command returns nothing.
[01:57] whaack: (It does return something for /dev/sda
[01:57] whaack: )
[01:57] jfw: "# resize2fs /dev/sdb1 950000M" - this is definitely a usage I'd avoid - using approximate units near the actual size such that it might overflow and we don't know for certain if/how the software handles that.
[01:58] jfw: nothing at all, not even an error?
[01:59] whaack: jfw: correct, not even an error, just a new bash prompt
[02:00] whaack: jfw: Right re the 950GB. "I'm not sure what's going on here so I'm going to leave some wiggle room"
[02:00] jfw: holy shit you're right, with the centos fdisk I can reproduce this with fdisk -l /dev/nonexistant. none of my "daily" fdisks "work" like that though, not even the barebones busybox.
[02:01] jfw: is there any actual data on this partition? guessing it was pretty fresh by the earlier df.
[02:02] whaack: jfw: No there is not, apart form a test file test.txt with a couple of chars in it
[02:02] whaack: apart from*
[02:02] jfw: cool, just establishing the level of crisis.
[02:02] whaack: thanks, 0 crisis
[02:03] jfw: does sdb still show the same as before in lsblk? is there anything in the tail end of the kernel log suggesting hardware issues?
[02:03] whaack: yes lsblk result remains the same
[02:04] jfw: how about I dunno, "dd if=/dev/sdb bs=512 count=1 | hexdump -C" ?
[02:05] whaack: yes looks like dmesg shows a bunch of possible hardware issues
[02:05] whaack: http://paste.deedbot.org/?id=ccTx
[02:06] whaack: the results of running your suggested command > http://paste.deedbot.org/?id=6IXR
[02:07] jfw: a yeah, kernel log has it "Buffer I/O error on device sdb", similarly "Input/output error" from a userspace program that actually reports the error it gets rather than silently dying.
[02:08] jfw: the good news is you didn't mess up the filesystem or partition table through software means, the bad news is there's an as yet undetermined hardware problem.
[02:08] jfw: how is the drive attached?
[02:09] whaack: jfw: Through a sata cable. IIRC I had problems with this gbefore and was switching through the different ports
[02:09] whaack: And it was a struggle to get to the point where I could write anything to the device
[02:11] jfw: ah ok, internal backup drive. bad cable perhaps?
[02:12] whaack: jfw: Possibly, I don't have another cable handy and probably won't for the next couple of weeks
[02:13] jfw: given you've already tried replugging & with different ports, not much to suggest but to keep replacing stuff until fixed unfortunately.
[02:14] whaack: jfw: Alright, thanks for the help
[02:14] jfw: at least in my own toolkit; possibly there are diagnostics that can be done on the cable or drive or whatnot, hm.
[02:15] jfw: if you can get the drive back online at all there is possibly the SMART data; I've never yet dug into that but there is a 'smartmontools' for linux
[02:16] jfw: hdparm or sdparm might have some kind of tests too.
[02:17] jfw: and you're welcome.
[02:21] whaack: jfw: Alright, I think I'm going to find an alternative backup system in the meantime, anyways I'm likely offline for the night, hopefully in the next week or two i'll have a beta ircbot that will pop in that will let you explore the first 300k blocks or so
[02:22] jfw: one point to expand for the innocent: "kilo" to computer people means 2^10 = 1024 while to everyone else it means 10^3 = 1000, and the remaining prefixes in the same manner; that's why I think of the 'M' as approximate, it could be "imperial or metric megabytes" and you'd have to know the specific tool to be sure.
[02:24] jfw: whaack: heh, then I guess I've been given fair warning to start considering bot policies
Day changed to 2021-05-11
[13:33] dorion: whaack, re the shipping costs. is your provider a mail forwarder that gives you a Miami PO box ? this is what mine is in Panama. when I order something the merchant charges me for the delivery to Miami and my shipping company their fee when I pick it up or they deliver it to me in Panama.
[13:34] dorion: if this is the case for you, I think we should only include the shipping fee to Miami in our quote and you settle up with the CR company for their fee and customs when to receive the delivery in CR. does that make sense to you ?
[15:46] whaack: dorion: Yes, my forwarding address works the same. So yes, your suggested method makes sense to me and is what what I was expecting.
[21:10] whitehorn: hey @dorion, thank you for setting up the golf Saturday, hope to do it again soon
Day changed to 2021-05-12
[02:20] dorion: whitehorn, let's do it. not the coming weekend, but perhaps the following. and let us know how the gales usage goes !
[21:19] whaack: jfw: I'm consistently getting an error, "Connect reset by peer" (see http://paste.deedbot.org/?id=oE-W) which is causing me to manually restart my scan function. Did you notice this error when scanning for your gbw-node wallet code? Any idea as to what it may be? (I have not investigated yet myself)
[21:45] jfw: normally that means the TCP client received an RST response ie abnormal termination / rejection due to mismatched state (the server crashing, some firewall forgetting the state etc.) any clues in the bitcoind debug.log?
[21:46] jfw: and what happens to manual rpc commands ("bitcoind getinfo" etc)?
[21:49] whaack: jfw: I see this error usually a couple hours after it has occured, and I'm not sure what to search for in debug.log, I believe the client keeps running and listening to rpc commands
[21:49] jfw: I don't recall seeing this particular situation; but there is the pitfall that the blockpipe can deadlock if the client is killed during a block transfer, which can be unwedged by 'cat .gbw/blockpipe >/dev/null' prior to retrying client
[21:50] jfw: so then search the debug.log for the last rpc command
[21:53] whaack: jfw: Ah durr, it is likely because I have my node on auto-restart every 8 hours, I'm going to turn that off and see if I get the same problem.
[21:53] jfw: lolz.
[21:59] jfw: just kicked my node which ofc failed to recover after a network outage, possibly the whole 'trb' fleet will start getting blocks more reliably now; I suspect I'm one of a very few bridges between it and the miners, based on the peers that thirstily request a block as soon as I get one.
Day changed to 2021-05-13
[14:42] dorion: whaack, got an order started on the bus blaster v3 jtag debugger. it's a slovakian company that 1) only ships to the yurope and 2) only takes bank wires. I've got a mail forwarder in germany I've set up to cover 1 and waiting on them to send me the wire instructions for 2, but now have enough info to get the invoice filled out and contract ready to sign so will be getting those to you today.
[15:15] dorion just got notice from .sk they're "cheese shop" after all when it comes to the v3 bus blaster, but can do the v4.
[15:21] dorion: whaack, we've not used the v4, but on paper it has the needed jtag debugging capacity.
[16:04] whaack: dorion: We'll give it a shot!
[16:48] dorion: whaack, cool.
Day changed to 2021-05-14
[14:43] dorion: http://fixpoint.welshcomputing.com/2021/jwrd-logs-for-May-2021/#2112 -- yeah, I read that monkey hammer approach. I've been running a loosened malleus for months now without a hitch. jfw too and he's got an article in the pipeline to publish that change.
[14:43] sourcerer: 2021-05-12 21:53:36 (#jwrd) whaack: jfw: Ah durr, it is likely because I have my node on auto-restart every 8 hours, I'm going to turn that off and see if I get the same problem.
[16:12] whaack: dorion: what does a loosened malleus mean?
[16:17] dorion: not as restrictive.
[16:18] dorion: on the malleus_mikehearnificarum
[16:19] whaack: Got it, that's what I figured you meant but wasn't sure.
[22:10] jfw: check it out cruciform, noobs *are* still using 1-addresses! http://trilema.com/2016/lxs-ninxs/#comment-163623
Day changed to 2021-05-15
[05:51] jfw: http://fixpoint.welshcomputing.com/2021/jwrd-logs-for-May-2021/#2114 - turned out there was more to the state of my node than first met the eye, i.e. the conditioned assumption that "it's not getting blocks, must be the usual suckiness" didn't hold up. So there might be a report on that for now in place of the one dorion was eagerly anticipating.
[05:51] sourcerer: 2021-05-12 21:59:11 (#jwrd) jfw: just kicked my node which ofc failed to recover after a network outage, possibly the whole 'trb' fleet will start getting blocks more reliably now; I suspect I'm one of a very few bridges between it and the miners, based on the peers that thirstily request a block as soon as I get one.
[18:18] whaack: I'm starting to hear gears grind as the scan command gets closer to the end of the chain. At block 389035 i'm processing about .2 blocks per second, so at this rate it'll be another 15 days or so until completition, but likely the blocks per second will slow down as the sql statements start to take longer from a larger database
[18:19] whaack: whitehorn: howdy!
[18:25] jfw: whaack: if we had a block explorer perhaps we could even adjust for the block height vs. cumulative size curve!
[18:26] whaack: hehe
[18:27] jfw: is this on an hdd or was that a metaphorical gears grinding?
[18:27] whaack: metaphorical
[18:28] jfw: ah ok then; good luck.
[18:29] whaack: I still have my profiler running, so I'm going to turn that off to hopefully get a decent speedup.
[18:29] whaack: s/my profiler/cProfile
[18:32] jfw: ah, might help, yes. btw I wasn't specifically objecting to the "my" before, just didn't know what it signified.
[18:49] whaack: in any case, removing cProfile did ~nothing to help
[23:31] whitehorn: whack: hi there :)
[23:32] whitehorn: *whaack
[23:35] dorion: whitehorn, whaack lives in costa rica and we met up in panama.
Day changed to 2021-05-16
[01:12] whitehorn: found it @ http://ztkfg.com/2020/01/panama-bien-vestido/
Day changed to 2021-05-17
[00:01] dorion: hey whitehorn, get this : so my grandparents remember your parents as their high school students and then the first time my father saw a computer was when he was taking a class at fair haven high school with your father and they took a field trip to castleton college campus... and here we are now ! lolz.
[18:20] whitehorn: hey dorion, chatted with my Dad and he said June taught latin and french but had my dad's older sister Esther in high school but he took french from her at castleton state college
[18:21] whitehorn: pretty cool, he doesn't remember bringing your dad to csc to see the computer so i'll ask him about that later for sure, thanks for the connections
Day changed to 2021-05-18
[21:42] dorion: http://dorion-mode.com/2021/05/bitcoin-and-beverages-at-baxters-part-ii/
[22:17] dorion: whitehorn, ah there you go, thanks for setting the record straight.
[22:18] dorion: whitehorn, if you want to register your rsa key with deedbot, I'll rate you.
[22:21] dorion: working from the "own all your things" approach, we'll have our own WoT implementation at some point, but for now trinque still shows some sign of life and deedbot is good enough.
Day changed to 2021-05-20
[18:12] whaack: jfw: I'm working on getting desktop notifications working for yrc. I don't think any modification is required to yrc source; I'm just going to ssh into my VM with a command that simultaneously runs tail on the logs, greps each line for "whaack", and uses notify-send should it find a match
[18:14] whaack: I figured I may as well ask here if you already have found a solution to this problem (or have determined it a non-problem)
[18:58] jfw: whaack: some sort of notification for mentions would be nice to have; I've been doing without, so in effect either I'm reading a channel in full or I'm not reachable there.
[18:59] jfw: notify-send sounds like some dbus horror but if it's there for you then I guess that works, for a workaround
[20:11] jfw: whaack: a simpler notification option might be "printf '\a'", sends the terminal bell code, which gets picked up into a visual cue by the fancier terminal emulators.
[20:14] whaack: jwf: hmm and what do I need to get the visual cue? I operate my comp sans sound so the audio does not help
[20:14] whaack: jfw: *
[20:55] dorion: whaack, reads to me like he's saying you need to run one of the terminal emulators, e.g. tmux.
[22:44] billymg: dorion, jfw: i've got my logger up and running now and i've mirrored all the chans that asciilifeform is hosting. i'd like to add this chan as well but figured i'd ask first. if you have a dump of past logs i can import those as well
Day changed to 2021-05-21
[20:40] jfw: whaack, dorion: unless whaack's using something like a vt100 then he's using a terminal *emulator* already, i.e. software program on some host OS that emulates a hardware terminal, be it the linux virtual console, xterm, screen, tmux etc.
[20:41] jfw: but yes "the fancier ones" would be tmux, screen, kde's Konsole can do it, not sure about the gtk ones.
[20:42] jfw: tmux and screen are special cases in that they're both terminal emulators and clients of a downstream "more physical" terminal; proxies if you will.
[20:45] jfw: billymg, dorion: I'm gathering there was some talk of billymg trying an mpwp-integrated logger, but then it looks more like he already went with the flask one; what's the plan there?
[20:46] jfw: mine is indeed based on 'sonofawitch' but with extensive changes to build it up from prototype to more-or-less production system, including an explicit schema for the raw log table, so would be a better starting point, except that I haven't got around to publishing yet.
[20:50] jfw: billymg: for starters I don't mind what you do with your own logs of this channel, we're not aiming to live by the copyright sword or anything. If there's more to the question than that though it may take some thought
[20:51] jfw: I suppose at least publishing the raw table so who wants can mirror cleanly rather than by spidering is clearly sensible.
Day changed to 2021-05-22
[03:18] dorion: http://fixpoint.welshcomputing.com/2021/jwrd-logs-for-May-2021/#2163 -- he said he's doing both : http://logs.bitdash.io/billymg/2021-05-20#1000084
[03:18] sourcerer: 2021-05-21 20:45:07 (#jwrd) jfw: billymg, dorion: I'm gathering there was some talk of billymg trying an mpwp-integrated logger, but then it looks more like he already went with the flask one; what's the plan there?
[03:50] jfw: "taking a look" is not quite the same as "doing" though, hence the question.
[14:44] billymg: http://fixpoint.welshcomputing.com/2021/jwrd-logs-for-May-2021/#2165 << yeah, i just mean i would have my bot idle in this channel so that i can get the logs on my www. i do read/keep up with this channel so i have an interest in having a copy over there (which is where i'll be doing most of my log reading from now on)
[14:44] sourcerer: 2021-05-21 20:50:08 (#jwrd) jfw: billymg: for starters I don't mind what you do with your own logs of this channel, we're not aiming to live by the copyright sword or anything. If there's more to the question than that though it may take some thought
[14:45] billymg: when referencing #jwrd loglines in this chan i would continue to use your logger, no reason to have your logs filled up with links that, for all you know, might lead to a dead site someday
[14:46] billymg: and as dorion mentioned, yes, i do intend to take a look at the bash/mp-wp based logger, but the first thing i want to do is get the results of my btc network crawler published before i return to looking at mp-wp stuff
[18:35] whaack: jfw: Good to know, I was unaware that bash terminals emulated a piece of hardware
[18:44] whaack: And btw, I eventually hacked up a long command that tail'd my local log files, awk'd and grep'd them to get messages that either matched my nick or were direct messages to me, and put out a notification via notify-send. It seemed to work but after about 1-2 mins the connection would somehow drop, and the program would keep running but no new notifications were sent
[18:47] whaack: (in case anyone's curious, this was the command http://paste.deedbot.org/?id=AZ0J, the awk line puts the filenames into the line, which I wanted because I was checking to see if the filename had a "#" to determine whether the message came from a channel or a dm.)
[18:52] whaack: It looks like ssh may be silently dropping the connection when it doesn't receive anything new for > 1 min.
[23:02] dorion: billymg, all good by me to log it.
[23:05] billymg: dorion: awesome, i'll go ahead and add it to the list of chans
[23:14] jfw: billymg: cool, sounds good. the other issue with links to third-party logs, in the event you took yours down (as would be perfectly within your right to do, without the political ties that bind and whatnot), is the divergence of message IDs. bvt had a smart approach to that based on message+context hashes but nobody's made it happen.
[23:21] jfw: whaack: hah, cruciform's next homework can be to explain that command!
[23:23] jfw: I actually didn't know you could call awk functions without parens, yuck.
[23:23] jfw: ("length" in this case)
[23:24] jfw: the buffering stuff makes me want to throw things at unix but I know why you did it
[23:26] jfw: slashes aren't special in grep (either basic or extended RE flavor) so don't need the escaping there; basically they're nothing to do with regex syntax itself but rather a delimiter used by various things to denote an RE. In grep, no such denoting is needed since that's all it does.
[23:30] jfw: not sure on the 'silent drop', I'd think if the ssh terminated then the rest would too. could check ps & netstat to see at least what is or isn't there when it happens
[23:35] jfw: oh yeah, don't confuse bash with the terminal. bash is just a program running on the host, a sort of 100k line expansion of that 'while read' loop; it talks to the terminal via the tty driver (be that a hardware terminal over a serial line or an emulator through a PTY - pseudoterminal device)
[23:42] billymg: http://fixpoint.welshcomputing.com/2021/jwrd-logs-for-May-2021/#2180 << that's a cool idea
[23:42] sourcerer: 2021-05-22 23:14:26 (#jwrd) jfw: billymg: cool, sounds good. the other issue with links to third-party logs, in the event you took yours down (as would be perfectly within your right to do, without the political ties that bind and whatnot), is the divergence of message IDs. bvt had a smart approach to that based on message+context hashes but nobody's made it happen.
Day changed to 2021-05-23
[14:36] dorion: hello cai2920
[18:37] dorion: cai, what brings you here ?
[18:37] dorion: and how goes in panama ?
[18:38] dorion: cai, what can you tell me about counterpoint ?
[22:12] ghosthell: Buying Trans-Universal Transportation Equipment. Please PM ME If you can Supply. 92
[22:55] whaack: ah dang, I'd PM, but I only have 91 of them :(
[22:56] whaack: jfw: adding "-o ServerAliveInterval=25" to ssh seems to have helped keep the connection alive
Day changed to 2021-05-24
[15:50] ghosthell: whaack I'll take what you have
[15:51] whaack: ghosthell: heh, and who may you be?
[16:06] ghosthell: Im Bob. whaack looking to buy either an xk memo replica or backwards compatable dwg
[16:16] whaack: ghosthell: Not sure if that's a question for me or a statement, in any case I don't know what either of those two are
[16:17] ghosthell: oh sorry you caanot help me then
[16:27] whaack: jfw: Do you have a suggestion as to which data format my block explorer should use to return results to queries? I was thinking it should return either as an sexpr or a json. Or perhaps it should just return in a human readable format.
[16:40] dorion: ghosthell, what brings you here and what makes you think you'll find what you're looking for ?
[16:44] ghosthell: I find for every 30 random rooms I go into atleast 1-2 people are aware of this equipment
[16:47] dorion: I see. enlighten us w/ a link, s'il vous plait ?
[16:48] dorion: (cursory web search didn't point to anything obvious)
[21:41] jfw: lolz.
[21:42] jfw: whaack: keepalive helping suggests retarded ISP. it can also make it worse eg if there's packet loss exceeding the timeout interval.
[21:43] jfw: similar to the whole keeping an irc bot online thing.
[21:44] jfw: whaack: depends on the data, if it's just a table of strings with controlled range of characters it may be simplest to just pick a delimiter character.
[21:50] jfw: otherwise I don't have a strong pref between sexpr and json; on the sexpr side there are dialect issues depending how fancy you get, while with json there's unicodeism
[21:53] dorion: I'd say both sexpr and json are human readable. yeah, they're structured so a machine can read them too, but if you claim to be human and can't read those, what you have is a weak claim.
[21:54] jfw: haha true, at least if well wrapped & indented.
[21:55] jfw: still if it's just a table, might as well keep it awk-friendly.
[22:02] dorion defers to jfw.
Day changed to 2021-05-25
[02:20] dorion: hey ghosthell, whether you're going to talk or not, quit with the join/part spam, aite ?
[14:37] jfw: ghosthell: respond to what you were asked.
[14:38] jfw: cruciform: you out there somewhere? how's it going?
[17:55] dorion: welcome back cruciform.
[18:35] whaack: jfw: looks like my blockexplorer has sped up its sync speed since hitting block ~500,000. My guess/thoery is that the introduction of segshit has somehow reduced the amount of work my blockexplorer needs to do to load all the transactions into my db.
[21:16] jfw: for quicker future reference, to ban in yrc: /mode #YourChannel +b Nick!User@Host
[21:18] jfw: probably no point in not going straight to * for the nick and user parts.
[21:21] jfw: whaack: think you'll do anything to substantiate that guess? fwiw it doesn't seem terribly interesting to me; whereas a proper look at performance numbers when tuning the database parameters would be both controllable as an experiment and actionable
[22:53] whaack: jfw: No, I don't have any plans to substantiate the guess. I may fiddle with the db parameters, however.
Day changed to 2021-05-26
[14:05] cai: hello
[14:09] cai: Is there anybody out there?
[14:38] whaack: cai: good morning
[14:53] cai: whaak: is this whaak who lives in Costa Rica?
[15:39] dorion: heh, bienvenidos cai, but where'd you run off to ?
[15:40] dorion: cai, for when you come back : http://fixpoint.welshcomputing.com/2021/jwrd-logs-for-May-2021/#2193
[15:40] sourcerer: 2021-05-23 18:38:51 (#jwrd) dorion: cai, what can you tell me about counterpoint ?
[15:42] dorion: cruciform, holla at be when you're back around.
[15:42] dorion: me*
[18:03] whaack: cai: yup, guessing by dorion's question about counterpoint I know who you are! welcome to irc
[18:05] whaack: cai: Are you still in Panama?
Day changed to 2021-05-27
[13:21] user: Guten morgen
[14:01] user: It appears as though this is not the best time to engage on this channel. I will try at a different time. On the other hand, I will chose a permanent nick soon. I am not sure if I will use cai henceforth or not. Nos vemos!
[16:01] dorion: user/cai, typically afternoons are more active, but am habits could be developed.
[17:11] jfw: doesn't seem like he's figured out the "stay connected or check the log" thing yet.
[17:57] whaack: cruciform: heyyo
[17:57] cruciform: 'ello
[17:58] whaack: ah it is office hour time!
[17:58] cruciform: how's the block explorer going?
[17:59] whaack: pretty well, I made an interesting discovery for myself yesterday
[17:59] cruciform: don't be coy!
[18:01] whaack: On July 4th 2015 bitcoin had a softph0rk, where miners implemented a new rule regarding signatures that reduced the set of allowed signatures. This fork didn't work out as planned, and disrupted the network for an hour or so. From reading the logs though, I had gathered that prb had succeeded a couple of days later, forcing bitcoin users to adhere to the new rule regarding transactions
[18:03] whaack: however I discovered that there fork did not succeeded until months later, until block 388166 with hash 000000000000000005de239ca0d781cc9e78add7c48e94e2264223aa31fc6256, 'high s' signatures can be found
[18:04] cruciform: interesting - have you written an article on your findings?
[18:05] whaack: (old thread re fork http://logs.nosuchlabs.com/log/trilema/2015-07-03#1186436)
[18:07] cruciform: thanks for the link
[18:07] whaack: cruciform: not yet, I've gone down the rabbit hole of learning the required math for understanding signatures maybe with elliptic curves
[18:07] whaack: made* with elliptic curves
[18:08] cruciform: cool! I've a bunch of rabbit-holing to do wrt how bitcoin works under the hood
[18:08] whaack: it seems to be a ~lifelong journey
[18:08] whaack: (not that it has to be that way)
[18:09] cruciform: heh - believe me, I know all about staying home!
[18:09] whaack: cruciform: what are you working on atm?
[18:11] cruciform: moving boxes into new house; otherwise, JWRD-stuff and gonna get Eulora setup
[18:12] cruciform will be back tomorrow
[18:13] whaack: cool, congrats on the new house
[18:13] whaack: hasta manana
[18:25] jfw: whaack, not that I looked that closely but I thought the high-s thing was a tx acceptance / relay rule rather than block validation rule ie not a softfork
[18:28] whaack: jfw: It's not so clear to me either way
[18:30] whaack: Miners are not including high s sigs in their blocks, whether they would reject a block with a high s signature, idk
[18:34] whaack: Also, there may be high S sigs somewhere between block 400,000 -- present height, I've only seen for myself that there are no high s sigs between 388,167 and 400,000
[18:39] jfw: so your interesting discovery seems to be mostly of your own confusion really :P
[18:40] jfw: would still make an interesting writeup to capture what you learn though.
[18:43] whaack: well that's why i clarified it was interesting for myself! That the softphork never happened, or at least not until December 2015, is certainly well known in many circles
[18:45] jfw: oh I see, I'd parsed as "made a discovery for myself that was interesting"
[18:49] whaack: In any case, yes I will do a writeup on my findings soon
[18:54] jfw: ah, looks like it was a relay-rule thing at first but then indeed included with a couple other things in the bip66 fork attempt.
Day changed to 2021-05-28
[20:50] anotheruser: Guten abend
[20:51] anotheruser: Is there anybody out there?
[20:52] whaack: anotheruser: i'm here now
[20:53] anotheruser: whaak: Is this whaack who lives in Costa Rica?
[20:53] whaack: yessir
[20:54] whaack: anotheruser: I actually responded to your question before, idk if you saw but there are logs here http://fixpoint.welshcomputing.com/2021/jwrd-logs-for-May-2021/#2225
[20:54] sourcerer: 2021-05-26 14:05:26 (#jwrd) cai: hello
[20:54] anotheruser: whaak: Are you still disconfiguring people's mouse settings?
[20:55] whaack: disconfiguring people's mouse settings?? Am I forgetting something we talked about?
[20:55] anotheruser: whaak: I didn't see your response. This is my first experience using irc/yrc so I am still learning.
[20:55] whaack: cool, happy to help :)
[20:55] anotheruser: whaak: This is Chad. We met here in Panama, right?
[20:56] whaack: yup I remember, I was there for your presentation on music theory
[20:56] anotheruser: Yes!
[20:56] whaack: how's composing going?
[20:57] anotheruser: To my uunderstading, upi said that one of your first adventures in high school was disconfiguring mouse settings to confuse users.
[20:57] anotheruser: you said*
[20:57] anotheruser: composing is going well. I am making progress, step by step
[20:58] anotheruser: How about you? What are you working on these days?
[20:59] whaack: I'm working on a bitcoin block explorer, and through that I've been trying to get a grasp on the mathematics behind various functions used in the bitcoin protocol
[21:01] whaack: anotheruser: i have a demo bot in my channel #whaacked http://logs.bitdash.io/whaacked/2021-05-27#1000042
[21:01] bitdashbot: (whaacked) 2021-05-27 whaack: !e view-block 199384
[21:01] whaack: anotheruser: hm no only mischief I can remember that is close to messing with mouse settings was a failed attempt to make an aimbot for halo 1
[21:02] anotheruser: Interesting. I will check it out the demo. Since there are other block explorers out there, what do you hope to achieve by creating a new one?
[21:04] whaack: anotheruser: I have a short article that answers your question pretty directly http://ztkfg.com/2020/07/a-bitcoin-block-explorer-the-why-the-how/
[21:05] anotheruser: Alright!
[21:07] whaack: anotheruser: Do you have anything you've composed that you can share? And are you composing for a specific instrument or for an ensemble / orchestra?
[21:08] whaack: I've been studying the classical guitar regularly, although I've taken a break the past two weeks because I've developed some strain in my wrists.
[21:09] whaack: anotheruser: Also are you using yrc or another client atm? It may be a good time to figure out some questions you have with yrc
[21:12] anotheruser: I am having difficulty viewing the demo. What format is the demo in?
[21:13] whaack: anotheruser: First you have to join the channel #whaacked
[21:13] whaack: with /join #whaacked
[21:13] anotheruser: gotcha
[21:13] whaack: (the interface is through irc, if that wasn't clear)
[21:14] anotheruser: I love learning new information and asking kindergardern questions
[21:14] anotheruser: kindergardener
[21:14] anotheruser: Alright. Gotcha
[21:15] anotheruser: I am glad to hear that have continued studying classical guitar. I hope to hear you in the new future.
[21:15] anotheruser: And taking breaks can be good thing sometimes.
[21:16] anotheruser: On my side, yes, I have alternated my focus between learning a DAW and Music Theory.
[21:16] whaack: what's a DAW?
[21:16] anotheruser: Digital Audio Workstation
[21:18] anotheruser: Due to my specific situation, I have decided to learn a DAW and write electronic music, too.
[21:19] anotheruser: I have some finished songs but I prefer to share one with you that I finished a few days ago.
[21:19] whaack: awesome
[21:20] anotheruser: However, I need to master before sharing it. I will share it with you in a week or two. I have noticed that it is better to wait a few weeks before sharing music because I always end of hearing some small thing in the song that I want to change.
[21:21] anotheruser: always end up*
[21:22] whaack: alright I'll be here heh
[21:22] anotheruser: cool
[21:23] anotheruser: I need to get back to work! Talk to you soon. I am connected here now. I will also join your channel
[21:24] whaack: anotheruser: sounds good, enjoy
[21:24] anotheruser: You too
Day changed to 2021-05-29
[16:42] anotheruser: Guten abend
[16:56] anotheruser: dorion: I see that you responded via the logs. In regards to your question about counterpoint, I can tell you that if one moves from a perfect consonance to another perfect consonance one must proceed in contrary or oblique motion. However, you already know this.
[16:59] anotheruser: dorion: I am running across a new problem while using FL Studio, which is that it is very difficult to view notated music, indeed, it is not possible; it only displays midi notes, and thus has me considering changing to a different DAW called Cubase.
[17:00] anotheruser: dorion: What is new with you? What new problems are you solving up there?
[18:37] whaack: jfw: I'm attempting to write a basic ecdsa signing tool in order to "fully grasp" how the ECDSA works. I've tried to be honest with myself, making sure that I'm not cutting too many corners and at least have a decent understanding of all the proofs and lemmas that back ecdsa. But I've hit what appears to be a bring wall, something above my pay grade. The problem is that from what I understand so
[18:37] whaack: far, to be convinced the generator point G for a curve generates all the points on the curve, I need to be assured that there are a prime number of points on the curve over its finite field (+ the additive identity point at infinity). The problem is that it looks like I'm going to have to grok this proof https://en.wikipedia.org/wiki/Schoof%27s_algorithm#The_algorithm (plz excuse the derpapedia
[18:37] whaack: link) in order to convince myself that there are a prime number of points on the curve for secp256k1
[18:38] whaack: brick* wall
[18:43] whaack: jfw: When you wrote your signing algo for gbw-node, did you work through the various proofs re ecdsa, and did you come accross this one? (The link is an algo, but the 'proof' would be running the algorithm and being convinced that secp256k1 has a prime number of points) Do you have a suggestion as to where I should begin? Should I work through some math texts? Do you think I should give up / put
[18:43] whaack: aside for later the task of grokking ecdsa?
[19:32] jfw: whaack: either you're going deeper on the math than I did, or you're falling into the depths for not having enough grasp of the surface, I can't quite tell.
[19:33] whaack: Maybe simultaneously going deeper in some areas and having less of a grasp on the surface.
[19:33] jfw: Mainly what I worked through was satisfying myself that my code implemented the specs, not that the specs are correct / secure / whatever
[19:34] jfw: far as I understand there is no security proof of the sort one would like, though certain properties can at least be observed, clarifying the assumptions it rests on and that sort of thing.
[19:35] jfw: why does there need to be a prime number of points? if I'm recalling my basics now, the generator generates all points on the curve by definition
[19:37] jfw: ah, it would be possible to choose a generator that doesn't cover all points that pass the "on the curve" test, indeed.
[19:37] jfw: (if it's not prime.)
[19:37] whaack: right, so how can one be convinced that the generator for a curve is generating all the points, without enumerating all the points
[19:40] jfw: and if it didn't generate all the points, there'd be fewer bits in the key space than advertised, I suppose.
[19:40] whaack: correct
[19:41] whaack: (I also haven't grasped why a prime number of points on the curve means that every point is a generator)
[19:42] whaack: I'm playing around with the curve y^2 = x^3 + 7 mod 17 , which has 18 points, and most points are not generators and (15,13) is the only generator I know of
[19:42] jfw: there's a couple magic-looking numbers in the secp256k1 parameters, though the generator looks the most magical indeed
[19:47] jfw: a simpler kind of group to play with might be modular multiplication
[19:48] jfw: with a prime modulus, you should find that the powers of any element will generate the whole group, whereas not so if composite (possibly only its coprimes will)
[19:49] whaack: jfw: I don't think that's exactly correct...one sec
[19:49] jfw: myeah, certainly powers of 1 aren't generating anything
[19:50] whaack: jfw: that, but I was referring to also perfect squares
[19:50] whaack: take the powers of "4" mod 7 for example
[19:51] jfw: right, hmm.
[19:51] whaack: 4, 9, 16, all of those will give you problems. But there are also other numbers that don't appear to be perfect squares but are when you are referring to GF(p)
[19:54] jfw: what can I say, three years ago I think I could have given the correct example but that part of the brain has perhaps rusted.
[19:59] whaack: (for the logs, an example of a not-so-obvoius perfect square mod P is 5 mod 11, 5 is (7 ** 2) % 11, and therefore you cannot generate all the values in GF(11) simply by taking powers of 5
[20:03] jfw: to the higher question though, I can't really say what's best for you but if you find this interesting then it makes sense to me to get to the bottom of it, especially if you do the same for RSA and compare what you find.
[20:05] jfw: just don't get caught in the "go away with your silly demands that the rent be paid, can't you see I'm doing Important Maffs?" trap with it.
[20:10] whaack: ah forget it then, avoiding my irl concerns by replacing them with math problems was half the point!
[20:14] whaack: jfw: joking aside, that advice is important, thank you. Maybe I'll try to dedicate a copule of hours each week to a text on group/ring/field theory, and work my way up from there.
[20:15] jfw: heh, sounds good. 'modern algebra' is possibly the umbrella term there, with a side of 'number theory'
Day changed to 2021-05-30
[14:58] whaack: jfww: http://fixpoint.welshcomputing.com/2021/jwrd-logs-for-May-2021/#2355 << I think I figured out the example you were looking to give. It's the successive multiples (not powers) of a that generate all the elements in mod P if a is relatively prime with P, i.e. 1a, 2a, 3a...(P)(a)
[14:58] sourcerer: 2021-05-29 19:54:06 (#jwrd) jfw: what can I say, three years ago I think I could have given the correct example but that part of the brain has perhaps rusted.
[16:23] jfw: whaack: nice, that's the one - so if P is prime then any 'a' works except for the additive identity. Think I got tripped up trying to use literal exponentiation where all that was needed was group scalar multiplication, which repeated addition mod P fits just fine.
[16:29] jfw: The EC 'exponentiation' is such a thing, just repetition of its 'point addition' the specified (scalar) number of times. It's purely a group, no multiplication operation is defined - except that finite field ops are used as an 'ingredient' to define the arithmetic on the point coordinates for the group operation & membership test.
[16:31] jfw: Implementation is fancier than just repetition because it needs to run in polynomial time - can leverage the associative property to reuse sub-computations, x+x+x+x = (x+x) + (x+x) and so on.
[16:37] jfw: I went a step further in mine (because it was so godawful slow), noting that the 'x' is always the same: the public generator, so all its successive doublings can be precomputed. thus to exponentiate you just go through the bits of the exponent, adding in the respective entry from the table of G^0, G^1, G^2, G^4, G^8... gated on the bit. so the 3 additions in the above trivial example reduce to 1.
[16:40] jfw: er, zero actually since x^4 would be in the table directly - actual # of additions, if you do it timing-invariant, would be = to the number of bits in the key (exponent) I expect.
[17:08] jfw: Big update re JWRD apu1 firmware: after a long slog through the coreboot & seabios config menus, capture of the sgabios code, in-system flashing and some minor iterations to work out the kinks, this is all validated & working.
[17:08] sourcerer: 2021-04-30 17:39:46 (#jwrd) jfw: that is, I'm anticipating that I can use a stack of mainline coreboot (same one captured in '16 for thinkpads), mainline SeaBIOS (idem), and - here's the previously unknown - a mainline sgabios to accomplish the serial console redirection (which I'll note appears to have already existed, as a nice standalone thing, long before they went and did their own
[17:11] jfw: The stock SeaBIOS "Press ESC for boot menu" prompt as well as the LILO boot menu prompt are working unmodified i.e. through the sgabios serial console redirection; boot from SD card appears to work too (at least it's shown as an option when I plug in a card, though I don't have any actually bootable for x86 atm) which wasn't supported in the OEM firmware; and of course Linux boots up.