Show Idle (>14 d.) Chans
← 2022-11-14 | 2022-11-16 → ↓
busybot[asciilifeform]: Current BTC price in USD: $16820.63
billymg[busybot]: still a longgg way to go but at least moving in the right direction: btc balance on exchanges
awt[busybot]: It appears that nearly all btc traded on ftx was paper.
billymg[asciilifeform]: yeah, seems that way, meaning any btc anyone sent them was promptly dumped somewhere
billymg[busybot]: 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
jonsykkel[busybot]: spek readed, its good
jonsykkel[asciilifeform]: pg.22 "any Message where Speaker is not equal to its own" << so if change handle, one resets chain to 0?
jonsykkel[busybot|asciilifeform]: 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
jonsykkel[busybot]: 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
jonsykkel[asciilifeform]: 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
jonsykkel[busybot|asciilifeform]: pan that involves him changing this handle or diff person claiming same handle and
jonsykkel[busybot|asciilifeform]: 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
jonsykkel[busybot|asciilifeform]: 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)
asciilifeform: meanwhile, in x11 lulz, 1337w4rez of 2017(!) b00k on subj. epicly horrid writing, nfi wat author was smoking. but possib. useful
jonsykkel[busybot|asciilifeform]: didnt mean to bury ur x11 lulz
asciilifeform: jonsykkel: noprob
asciilifeform[busybot] will answ. 1 at a time
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
bitbot[asciilifeform|busybot]: 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
asciilifeform: you dun need to know whether 'he -- fast' or 'you -- slow'
jonsykkel[busybot]: indeed, which could be up to 30min!
asciilifeform: all that's demanded is that timestamps monotonically increase as netchain steps
asciilifeform: in practice unlikely, if you let yerself drift eventually will start seeing 0 traffic (and no one sees yours)
asciilifeform: pest requires 'medieval tower clock' level of clock sync.
asciilifeform: i.e. one practical using sundial if necessary.
signpost[busybot]: unless the russians or chinese zap gps you've got a passive clock source all around.
signpost[busybot]: no need for NTP.
asciilifeform: signpost: is precisely same deal as ntp tho -- centralized service
asciilifeform: notion is, no such thing needed for pest
signpost[asciilifeform]: it is, but without interdiction specific to you
jonsykkel[asciilifeform|busybot]: 30min unlikely yes, but for realtime conversation to not molassized will require better than tower clock
signpost[busybot]: slightly less bad
signpost[busybot]: but yep not needed
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)
jonsykkel[busybot|asciilifeform]: or well, maybe tower clock good enuf but how to achieve
bitbot[busybot|asciilifeform]: 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
jonsykkel[busybot]: i dont remember them being 0termed, but could be wrong
jonsykkel[asciilifeform|busybot]: in that case i implemented wrongly
asciilifeform: admittedly not 100% unambig.
jonsykkel[busybot]: unused set to zero yes, but what if all used
asciilifeform: jonsykkel: how do you determined 'all used' in yours if not by looking for a null ?
jonsykkel[busybot]: asciilifeform: well u know the max len
asciilifeform[busybot]: why wouldja read past 1st 0 ?
signpost[asciilifeform]: zero even needed if all used?
asciilifeform: signpost: nope. but 'pad with 0' implies 'look for a 0 from 1st element on' neh
jonsykkel[busybot]: "324 UString[324] Come to tea. (padded with null bytes.)" << if string is 324bytes, 0term would be 325
asciilifeform: an oldspec-compliant pestron oughta notice the 0
asciilifeform: jonsykkel: again nope. if not finds a 0, then 324.
asciilifeform: but if 0 at e.g. position 3, then it's a 2-char string. etc
jonsykkel[busybot]: asciilifeform: yes, thats what i mean
jonsykkel[asciilifeform|busybot]: so u can create a message with 324 usable chars, that all must be interpreted
jonsykkel[asciilifeform|busybot]: and this message will not have a 0terminator on the wire
signpost[busybot]: probs benefits from explicit "if encountered zero -or- end-of-field" statement to remove ambiguity, especially since field termination is such a dangerous thing
asciilifeform: nao wat's missing is a mandatory 0 in 'chunk' in 4.2.2.
asciilifeform: that yes.
asciilifeform will add
asciilifeform: ty jonsykkel
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'
bitbot[asciilifeform|busybot]: 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
asciilifeform: that way also not require an in-memory buffer for incomings. send info straight to disk.
asciilifeform: if anuther copy comes in, you update.
asciilifeform: (if <= minbounce of prev.)
asciilifeform must bbl, will answer the remaining observations
jonsykkel[busybot]: 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
signpost[asciilifeform]: do you necessarily want to delete history when you delete a peer?
signpost[asciilifeform]: I can think of people I'd have unpeered in the past but still wanted to retain history of interaction.
signpost[asciilifeform]: damnatio memoriae is a distinct choice from unpeering imho
jonsykkel[asciilifeform|busybot]: probably not, but u will have references to peers that dont exist anymore. how to handle this on the disk has annoying problems imo
jonsykkel[asciilifeform|busybot]: its nice for example to be able to store each msg in log as constant size thing
signpost[asciilifeform]: beneficial for multiple reasons to not consider a hearsay the same message as a canonical message from that peer.
signpost[asciilifeform]: if you store them all distinctly you have from what to calc stats on message propagation on your network
jonsykkel[asciilifeform|busybot]: true, the info is useful
jonsykkel[asciilifeform|busybot]: 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
jonsykkel[busybot|asciilifeform]: maybe right way to do it anyway
asciilifeform: jonsykkel: how to index is a job for db (and imho not in scope of spec)
asciilifeform: point is that one gotta store'em
asciilifeform: ( and in such a way that adding/removing peers is o(1) rather than some kinda nightmare )
asciilifeform: ... and ideally so to leave all history intact. machine knows what ye peers were at time t.
asciilifeform: http://logs.bitdash.io/pest/2022-11-15#1016261 << you relay unless it's for you, naturally
bitbot[busybot|asciilifeform]: 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
asciilifeform: (if it aint for you, you dun know for whom it is)
asciilifeform: and it's a broadcast, so unless bounce maxed out, you relay.
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)
bitbot[busybot]: 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)
asciilifeform oughta clarify in spec, thought was obv
asciilifeform: on top of this, not need perfectly aligned hammers to work
asciilifeform: if not 100% aligned, will simply take longer
jonsykkel[busybot]: yep, was specifically re the "only deciphered when etc etc..", check seal but no decipher unless this peer is cold
asciilifeform: if he aint cold, then he won't send you addrcast, neh
asciilifeform: (if he does, he has broken pestron and tough cookies for him)
jonsykkel[busybot]: well, u have the delta + the propagation delay from flood routing
jonsykkel[busybot]: but likely to be small enuf
asciilifeform: likely to be ~= for both addrcasts aha
jonsykkel[asciilifeform|busybot]: though the actual hammering occurs not through the same indirect route
asciilifeform: correct
asciilifeform: coupla sec. shouldn't make much diff
jonsykkel[asciilifeform|busybot]: but might as well have been, "start hammering immediately when recv", no? hammerwait doesnt do anything useful unless im missing something
asciilifeform: maybe no point in the delay. needs thought
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
bitbot[asciilifeform]: 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.
asciilifeform: jonsykkel: lemme know if answrd errything or missed any
jonsykkel[asciilifeform|busybot]: asciilifeform: no im satisfied for now, tanks!
asciilifeform: jonsykkel: np
asciilifeform: meanwhile, in other noose.
bitbot[busybot|asciilifeform]: (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.
bitbot[asciilifeform]: (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/
asciilifeform: http://logs.bitdash.io/pest/2022-11-15#1016254 << correct. (can discuss whether Right Thing)
bitbot[busybot]: 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?
asciilifeform: notion is, selfchain oughta represent history of a given handle, from pov of erryone tuned in
asciilifeform: meanwhile, in misc. finds: a trimmed-down ada compiler. ( asciilifeform not tried )
asciilifeform: 'The available Ada language subset supported by HAC is so far, roughly, the "Pascal subset", plus tasking, plus packages, less pointers.'
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.'
asciilifeform: per asciilifeform's reading, oughta (theoretically) build e.g. ffa.
asciilifeform: signpost ^ may find interesting from 'foundational linux' pov.
asciilifeform: seems like a possible equiv. of 'tcc' for ada.
signpost[asciilifeform]: nice, will pop it in pentacle and see if it builds. oughta
signpost[asciilifeform]: http://paste.deedbot.org/?id=cavi << yup, worked out of the box by popping "gnatmake -P hac" in a pbuild
asciilifeform: signpost: does it build self ?
asciilifeform: ( also, seems like is bytecode rather than native compiler ? )
asciilifeform: a la turbopascal
signpost[asciilifeform]: looks like a self-build happened at the beginning of gallery.adb, but will have to look more closely later
asciilifeform admits, amazed that it built. so far encountered ~0 public ada proggies which built w/out any coughing
asciilifeform: ... well, maybe the serpent lib. errything larger than that -- coughed
signpost[asciilifeform] 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.
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,..'
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
asciilifeform: classy.
signpost[asciilifeform]: the timing of this and zelensky suddenly wanting to negotiate is another entertaining "coincidence"
signpost[asciilifeform]: and xi and biden deciding they're special buddies again.
awt[busybot]: and the "election"
signpost[asciilifeform]: entirely possible CZ just executed successful hybrid warfare on behalf of chicoms.
asciilifeform: signpost: wat's the point of elaborately lifting goxcoinz tho
asciilifeform: they're worth ~0
asciilifeform: (after the actual btc, however little or much was in the piggy, walked off)
asciilifeform: would've been simpler to rm -rf / the 'who's owed wat' db, neh
signpost[asciilifeform]: 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.
asciilifeform: seems dirty enuff as is (being entirely undisguised pyramid, complete with 'seven percent!111' or wat was it) but nfi
asciilifeform: meanwhile potentially interesting util linked from the 'hac' thing.
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
bitbot[asciilifeform|busybot]: Logged on 2022-11-15 10:59:43 signpost: but yep not needed
asciilifeform: ... if his clock is wildly out of sync with incoming timestamps from peers.)
asciilifeform: (this is wai multipart. tired of this nonsense)
asciilifeform: (and over9000 tired of having to see www logger errything , 'did it get chopped')
awt[asciilifeform]: asciilifeform: blatta breaks up long messages now
asciilifeform not tried very latest patch just yet
asciilifeform: the prev. one barfed on dupe at entries (somehow?) in db iirc
asciilifeform: and ate ~100% cpu
awt[busybot]: It's in logs but you gotta explicitly enable address cast, also you can run using a faster serpant implementation.
awt[busybot]: *serpent
asciilifeform: awt: hm wai would faster serpent help ?
asciilifeform: hmac, would think, would be the limiting reactant there
asciilifeform: ( if hmac not match seal, there's no deserpenting happening )
asciilifeform: ( ... at least not for the red cast payload )
whaack[asciilifeform]: blog articles are so rare nowadays, scoopbot never gets tested
whaack[busybot]: 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
signpost[asciilifeform]: best solution will be blogging into pest via chained messages
signpost[asciilifeform]: hi whaack, hope all's well
whaack[asciilifeform]: heya signpost, it's never too bad on the beach :)
asciilifeform: wb whaack
asciilifeform: phf: asciilifeform found himself reading 'x11proto' and discovered that it aint so big ( 'only' weighs 3-4x moar than current draft pest spec... )
asciilifeform was thinking, 'wai fuck with xcb etc, wainot 'clx for ada'
asciilifeform is gonna need x11 proto for fpga lispmisms, come to think of it, the super-ice40 board dun have a display connector...
asciilifeform: tho possibly for above could use clx eventually, rather than 'reinvent wheel'
asciilifeform: moar re subj if anyone curious.
asciilifeform: ( and iirc wireshark nao supports it, similarly )
bitbot[busybot]: 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.
bitbot[busybot]: 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 → ↑
Random(pest) | Download hourly DB snapshot | Get Source Code