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. |