Show Idle (>14 d.) Chans


← 2022-11-14 | 2022-11-16 →
05:52 crtdaydreams $ticker btc usd
05:52 busybot Current BTC price in USD: $16820.63
05:52 crtdaydreams doin just peachy
~ 2 hours 46 minutes ~
08:39 billymg still a longgg way to go but at least moving in the right direction: btc balance on exchanges
08:51 awt It appears that nearly all btc traded on ftx was paper.
08:53 billymg yeah, seems that way, meaning any btc anyone sent them was promptly dumped somewhere
08:54 billymg awt: the chart posted above, afaik, would not include those ftx "coins" in the total though, as the way it is calculated is by summing the balances of known exchange addresses on chain
~ 2 hours ~
10:54 jonsykkel spek readed, its good
10:54 jonsykkel pg.22 "any Message where Speaker is not equal to its own" << so if change handle, one resets chain to 0?
10:54 asciilifeform meanwhile, in x11 lulz, 1337w4rez of 2017(!) b00k on subj. epicly horrid writing, nfi wat author was smoking. but possib. useful
10:54 jonsykkel pg.22 "Note that the NetChain of a Message may not refer to one with a Timestamp greater than its own" << this efectively requires cloks to be synced within seconds, doesnt it. how to know if someone else is fast or you is slow
10:54 jonsykkel pg.23 if pestron 0xFB or earlier encounters such message with all 284bytes used it will interpret the N and potentially the Of+TextHash as part of the utf8 string
10:54 jonsykkel pg.29 re "store list of peers from whom recved a min bounce copy" wats the purpose of storing this info forever? im thinking it will be somewat computationally annoying to handle if for example unpeer. shoudl this info be retained in log if this happens (former peer cant be uniquely identified simply by handle over a times
10:54 jonsykkel pan that involves him changing this handle or diff person claiming same handle and
10:54 jonsykkel so on)
10:54 jonsykkel pg.41 "Incoming Address Casts are only deciphered when the receiver has at least one cold peer, and strictly on a best-effort basis (i.e. when the CPU would otherwise be idle.)" << presumably u still check the seal, to determine whether its for u or not, so know whether to relay
10:54 jonsykkel pg.42 "precisely HammerWait milliseconds after the Timestamp" << also requires either perfectly synced clocks, or pestron to keep track of the delta for that peer (but how can it know this has not changed if peer is cold for days etc)
10:55 jonsykkel didnt mean to bury ur x11 lulz
10:55 asciilifeform jonsykkel: noprob
10:56 * asciilifeform will answ. 1 at a time
10:56 asciilifeform http://logs.bitdash.io/pest/2022-11-15#1016256 << nope. simply requires station to wait to transmit until its time is >= last msg's on net
10:56 bitbot Logged on 2022-11-15 10:54:31 jonsykkel: pg.22 "Note that the NetChain of a Message may not refer to one with a Timestamp greater than its own" << this efectively requires cloks to be synced within seconds, doesnt it. how to know if someone else is fast or you is slow
10:57 asciilifeform you dun need to know whether 'he -- fast' or 'you -- slow'
10:57 jonsykkel indeed, which could be up to 30min!
10:57 asciilifeform all that's demanded is that timestamps monotonically increase as netchain steps
10:57 asciilifeform could
10:58 asciilifeform in practice unlikely, if you let yerself drift eventually will start seeing 0 traffic (and no one sees yours)
10:58 asciilifeform pest requires 'medieval tower clock' level of clock sync.
10:58 asciilifeform i.e. one practical using sundial if necessary.
10:59 signpost unless the russians or chinese zap gps you've got a passive clock source all around.
10:59 signpost no need for NTP.
10:59 asciilifeform signpost: is precisely same deal as ntp tho -- centralized service
10:59 signpost it is, but without interdiction specific to you
10:59 asciilifeform notion is, no such thing needed for pest
10:59 jonsykkel 30min unlikely yes, but for realtime conversation to not molassized will require better than tower clock
10:59 signpost slightly less bad
10:59 signpost but yep not needed
11:01 asciilifeform http://logs.bitdash.io/pest/2022-11-15#1016257 << nope, cuz strings nulltermed in old spec (tho asciilifeform not 100% read the prototypes, possibly 1 or even both would misinterpret. but if implemented old spec correctly, won't)
11:01 bitbot Logged on 2022-11-15 10:54:34 jonsykkel: pg.23 if pestron 0xFB or earlier encounters such message with all 284bytes used it will interpret the N and potentially the Of+TextHash as part of the utf8 string
11:01 jonsykkel or well, maybe tower clock good enuf but how to achieve
11:01 jonsykkel i dont remember them being 0termed, but could be wrong
11:02 jonsykkel in that case i implemented wrongly
11:02 asciilifeform jonsykkel: see here.
11:02 asciilifeform admittedly not 100% unambig.
11:02 jonsykkel unused set to zero yes, but what if all used
11:02 asciilifeform jonsykkel: how do you determined 'all used' in yours if not by looking for a null ?
11:02 jonsykkel asciilifeform: well u know the max len
11:03 asciilifeform why wouldja read past 1st 0 ?
11:03 signpost zero even needed if all used?
11:03 asciilifeform signpost: nope. but 'pad with 0' implies 'look for a 0 from 1st element on' neh
11:04 jonsykkel "324 UString[324] Come to tea. (padded with null bytes.)" << if string is 324bytes, 0term would be 325
11:04 asciilifeform an oldspec-compliant pestron oughta notice the 0
11:04 asciilifeform jonsykkel: again nope. if not finds a 0, then 324.
11:04 jonsykkel asciilifeform: yes, thats what i mean
11:04 asciilifeform but if 0 at e.g. position 3, then it's a 2-char string. etc
11:05 jonsykkel so u can create a message with 324 usable chars, that all must be interpreted
11:05 jonsykkel and this message will not have a 0terminator on the wire
11:05 signpost probs benefits from explicit "if encountered zero -or- end-of-field" statement to remove ambiguity, especially since field termination is such a dangerous thing
11:06 asciilifeform nao wat's missing is a mandatory 0 in 'chunk' in 4.2.2.
11:06 asciilifeform that yes.
11:06 * asciilifeform will add
11:07 asciilifeform ty jonsykkel
11:07 asciilifeform http://logs.bitdash.io/pest/2022-11-15#1016258 << if it's a hearsay, oughta store from whom got it. and nfi wai 'expensive'
11:07 bitbot Logged on 2022-11-15 10:54:37 jonsykkel: pg.29 re "store list of peers from whom recved a min bounce copy" wats the purpose of storing this info forever? im thinking it will be somewat computationally annoying to handle if for example unpeer. shoudl this info be retained in log if this happens (former peer cant be uniquely identified simply by handle over a times
11:07 asciilifeform that way also not require an in-memory buffer for incomings. send info straight to disk.
11:07 asciilifeform if anuther copy comes in, you update.
11:08 asciilifeform (if <= minbounce of prev.)
11:10 * asciilifeform must bbl, will answer the remaining observations
11:11 jonsykkel its not expensive if u do it in the obvious way, storing bit array directly in log, but then u get problem of wat to do if delete peer, go through entire log from start and update all? but then the info is gone
11:11 jonsykkel aight
11:14 signpost do you necessarily want to delete history when you delete a peer?
11:14 signpost I can think of people I'd have unpeered in the past but still wanted to retain history of interaction.
11:15 signpost damnatio memoriae is a distinct choice from unpeering imho
11:17 jonsykkel probably not, but u will have references to peers that dont exist anymore. how to handle this on the disk has annoying problems imo
11:18 jonsykkel its nice for example to be able to store each msg in log as constant size thing
11:19 signpost beneficial for multiple reasons to not consider a hearsay the same message as a canonical message from that peer.
11:20 signpost if you store them all distinctly you have from what to calc stats on message propagation on your network
11:20 * signpost back shortly
11:21 jonsykkel true, the info is useful
11:27 jonsykkel supose can solve by having internal peer id that is big enuf so never gets reused. and then messages not constant size on disk. and then delete peer = mark as deleted rather than removing anythning
11:28 jonsykkel maybe right way to do it anyway
11:33 asciilifeform jonsykkel: how to index is a job for db (and imho not in scope of spec)
11:33 asciilifeform point is that one gotta store'em
11:33 jonsykkel sure
11:34 asciilifeform ( and in such a way that adding/removing peers is o(1) rather than some kinda nightmare )
11:35 asciilifeform ... and ideally so to leave all history intact. machine knows what ye peers were at time t.
11:36 asciilifeform http://logs.bitdash.io/pest/2022-11-15#1016261 << you relay unless it's for you, naturally
11:36 bitbot Logged on 2022-11-15 10:54:45 jonsykkel: pg.41 "Incoming Address Casts are only deciphered when the receiver has at least one cold peer, and strictly on a best-effort basis (i.e. when the CPU would otherwise be idle.)" << presumably u still check the seal, to determine whether its for u or not, so know whether to relay
11:36 asciilifeform (if it aint for you, you dun know for whom it is)
11:36 asciilifeform and it's a broadcast, so unless bounce maxed out, you relay.
11:37 asciilifeform http://logs.bitdash.io/pest/2022-11-15#1016262 << nope. you always have the delta, because nobody will go straight to hammer, 1st need to try prod (addrcast type 1)
11:37 bitbot Logged on 2022-11-15 10:54:50 jonsykkel: pg.42 "precisely HammerWait milliseconds after the Timestamp" << also requires either perfectly synced clocks, or pestron to keep track of the delta for that peer (but how can it know this has not changed if peer is cold for days etc)
11:37 * asciilifeform oughta clarify in spec, thought was obv
11:38 asciilifeform on top of this, not need perfectly aligned hammers to work
11:38 asciilifeform if not 100% aligned, will simply take longer
11:38 jonsykkel yep, was specifically re the "only deciphered when etc etc..", check seal but no decipher unless this peer is cold
11:38 jonsykkel ah yes
11:38 asciilifeform if he aint cold, then he won't send you addrcast, neh
11:39 asciilifeform (if he does, he has broken pestron and tough cookies for him)
11:39 jonsykkel well, u have the delta + the propagation delay from flood routing
11:39 jonsykkel but likely to be small enuf
11:39 jonsykkel indeed
11:39 asciilifeform likely to be ~= for both addrcasts aha
11:39 jonsykkel yep
11:41 jonsykkel though the actual hammering occurs not through the same indirect route
11:41 asciilifeform correct
11:41 asciilifeform coupla sec. shouldn't make much diff
11:41 jonsykkel sure
11:43 jonsykkel but might as well have been, "start hammering immediately when recv", no? hammerwait doesnt do anything useful unless im missing something
11:44 asciilifeform maybe no point in the delay. needs thought
11:46 asciilifeform http://logs.bitdash.io/pest/2022-11-15#1016321 << is absolutely essential to 1) distinguish'em 2) show who / how many peers relayed 3) able to update if immediate (or simply lower-bounce) copy arrives
11:46 bitbot Logged on 2022-11-15 11:19:31 signpost: beneficial for multiple reasons to not consider a hearsay the same message as a canonical message from that peer.
11:57 asciilifeform jonsykkel: lemme know if answrd errything or missed any
11:57 jonsykkel asciilifeform: no im satisfied for now, tanks!
11:58 asciilifeform jonsykkel: np
11:58 asciilifeform meanwhile, in other noose.
11:58 bitbot (asciilifeform) 2022-11-15 lobbes: happy to see you are still fighting the Good Fight. I apologize for letting my logs die; I plan to get those back up after I digest the Pest documentation and get my own station up and running.
11:58 bitbot (asciilifeform) 2022-11-15 lobbes: Along the lines of letting my tools rust, I let krankendenken.com expire and some chinese squatter has gobbled it up. My blog still lives, however, at my old domain name (this one I renewed until 2027): http://www.lobbesblog.com/
12:04 asciilifeform http://logs.bitdash.io/pest/2022-11-15#1016254 << correct. (can discuss whether Right Thing)
12:04 bitbot Logged on 2022-11-15 10:54:27 jonsykkel: pg.22 "any Message where Speaker is not equal to its own" << so if change handle, one resets chain to 0?
12:04 asciilifeform notion is, selfchain oughta represent history of a given handle, from pov of erryone tuned in
12:05 jonsykkel makes sense
~ 15 minutes ~
12:21 asciilifeform meanwhile, in misc. finds: a trimmed-down ada compiler. ( asciilifeform not tried )
12:21 asciilifeform detailed summery from author.
12:22 asciilifeform 'The available Ada language subset supported by HAC is so far, roughly, the "Pascal subset", plus tasking, plus packages, less pointers.'
12:22 asciilifeform 'From a different perspective, HAC supports Ada 83, less pointers, less generics, less unconstrained types, plus a few items from later Ada versions: 95, 2005, 2012 and 2022.'
12:23 asciilifeform per asciilifeform's reading, oughta (theoretically) build e.g. ffa.
12:23 asciilifeform signpost ^ may find interesting from 'foundational linux' pov.
12:23 asciilifeform seems like a possible equiv. of 'tcc' for ada.
~ 1 hours 4 minutes ~
13:28 signpost nice, will pop it in pentacle and see if it builds. oughta
13:38 signpost http://paste.deedbot.org/?id=cavi << yup, worked out of the box by popping "gnatmake -P hac" in a pbuild
13:43 asciilifeform neato!
13:43 asciilifeform signpost: does it build self ?
13:44 asciilifeform ( also, seems like is bytecode rather than native compiler ? )
13:44 asciilifeform a la turbopascal
13:50 signpost looks like a self-build happened at the beginning of gallery.adb, but will have to look more closely later
13:53 * asciilifeform admits, amazed that it built. so far encountered ~0 public ada proggies which built w/out any coughing
13:54 asciilifeform ... well, maybe the serpent lib. errything larger than that -- coughed
13:57 signpost nb at all
13:58 asciilifeform meanwhile in gox lulz.
13:58 * signpost also needs to get a site up for pentacle, because it was trivial to drop the thing in and build. no reason I shouldn't have posted a vpatch of hac in the same sitting.
14:00 asciilifeform '...the report that FTX pushed a malicious OTA update to users mobile devices around midnight on a Friday; this update appears to have exfiltrated users’ private keys, meaning that the funds were stolen off of the users’ devices. Rather than just turning off the lights and freezing the accounts without explanation,..'
14:00 asciilifeform '...FTX appears to have literally stolen customers money in something that is more analagous to a breaking-and-entering. Some people have reported that FTX attempted to drain their bank accounts via Circle, which may or may not be true but will likely be underdiscussed' etc
14:00 asciilifeform classy.
14:01 signpost the timing of this and zelensky suddenly wanting to negotiate is another entertaining "coincidence"
14:01 signpost and xi and biden deciding they're special buddies again.
14:01 awt and the "election"
14:01 signpost entirely possible CZ just executed successful hybrid warfare on behalf of chicoms.
14:03 asciilifeform signpost: wat's the point of elaborately lifting goxcoinz tho
14:03 asciilifeform they're worth ~0
14:03 asciilifeform (after the actual btc, however little or much was in the piggy, walked off)
14:04 asciilifeform would've been simpler to rm -rf / the 'who's owed wat' db, neh
14:06 signpost if you're just trying to kill FTX sure, but if you're trying to maximally dirty your adversary in the eyes of future BRICS++ members, whore house needs to do some volume before you break it open.
14:07 asciilifeform seems dirty enuff as is (being entirely undisguised pyramid, complete with 'seven percent!111' or wat was it) but nfi
14:14 asciilifeform meanwhile potentially interesting util linked from the 'hac' thing.
14:20 asciilifeform http://logs.bitdash.io/pest/2022-11-15#1016282 << to clarify further -- pestron user ~can~ sync own clock from whatever reich service if he wants; but thing designed to operate without this assumption. (incidentally: possible useful feature would be to alert operator if his clock is wildly out of sync with incoming timesta
14:20 bitbot Logged on 2022-11-15 10:59:43 signpost: but yep not needed
14:21 asciilifeform ... if his clock is wildly out of sync with incoming timestamps from peers.)
14:21 asciilifeform grr
14:21 asciilifeform (this is wai multipart. tired of this nonsense)
14:22 asciilifeform (and over9000 tired of having to see www logger errything , 'did it get chopped')
~ 56 minutes ~
15:18 awt asciilifeform: blatta breaks up long messages now
15:19 asciilifeform oh hm
15:19 * asciilifeform not tried very latest patch just yet
15:19 asciilifeform the prev. one barfed on dupe at entries (somehow?) in db iirc
15:20 asciilifeform and ate ~100% cpu
15:21 awt It's in logs but you gotta explicitly enable address cast, also you can run using a faster serpant implementation.
15:21 awt *serpent
~ 20 minutes ~
15:42 asciilifeform awt: hm wai would faster serpent help ?
15:42 asciilifeform hmac, would think, would be the limiting reactant there
15:52 asciilifeform ( if hmac not match seal, there's no deserpenting happening )
15:52 asciilifeform ( ... at least not for the red cast payload )
~ 3 hours 51 minutes ~
19:44 whaack manual scoopbot: http://ztkfg.com/2022/11/apnea-and-the-love-of-freediving/
19:45 whaack blog articles are so rare nowadays, scoopbot never gets tested
19:46 whaack if any1 posts a comment plz let me know here... sadly i am inundated with spam and haven't figured out how to tweak my php form to make it so that naive bots are filtered
19:47 signpost best solution will be blogging into pest via chained messages
19:47 signpost hi whaack, hope all's well
19:53 whaack heya signpost, it's never too bad on the beach :)
~ 1 hours 41 minutes ~
21:35 asciilifeform wb whaack
~ 1 hours 7 minutes ~
22:42 asciilifeform phf: asciilifeform found himself reading 'x11proto' and discovered that it aint so big ( 'only' weighs 3-4x moar than current draft pest spec... )
22:43 * asciilifeform was thinking, 'wai fuck with xcb etc, wainot 'clx for ada'
22:44 * asciilifeform is gonna need x11 proto for fpga lispmisms, come to think of it, the super-ice40 board dun have a display connector...
22:45 asciilifeform tho possibly for above could use clx eventually, rather than 'reinvent wheel'
22:47 asciilifeform moar re subj if anyone curious.
22:47 asciilifeform ( and iirc wireshark nao supports it, similarly )
23:02 * asciilifeform updated pre-draft pest spec with jonsykkel's correction & coupla others.
23:02 bitbot Logged on 2022-11-10 11:51:20 asciilifeform[6]: meanwhile: signpost , awt , jonsykkel , phf, billymg , et al : preview of 0xfa. a number of sections not done, and prolly over9000 typos but fwiw.
23:02 bitbot Logged on 2022-11-15 11:06:35 asciilifeform[6]: nao wat's missing is a mandatory 0 in 'chunk' in 4.2.2.
← 2022-11-14 | 2022-11-16 →