Show Idle (>14 d.) Chans
← 2018-10-01 | 2018-10-03 → ↓
BingoBoingo: Session keep alive packet not recieved: BingoBoingo to sleep
ben_vulpes: taking mimisbrunnr down for a spell
mircea_popescu: i never heard of obesity miscarriage before.
diana_coman: http://btcbase.org/log/2018-10-02#1857131 -> afaik obesity does increase risk of miscarriage
a111: Logged on 2018-10-02 06:54 mircea_popescu: i never heard of obesity miscarriage before.
diana_coman: http://btcbase.org/log/2018-10-01#1856931 -> today works anytime really, just let me know in the logs
a111: Logged on 2018-10-01 21:14 asciilifeform: diana_coman, mod6 , lobbes , let BingoBoingo & asciilifeform know when is good day to take down yer units and copy contents to new drives.
diana_coman: BingoBoingo, asciilifeform ^
diana_coman: http://btcbase.org/log/2018-10-02#1857110 -> if it's anything like mine, it'll be mostly loud complaints from php because "time zone not set!!!" and similar (apparently php version on the RC is too new for its own good)
a111: Logged on 2018-10-02 01:45 asciilifeform: btw lobbes in case you care, it's almost all apache error log...
diana_coman: http://btcbase.org/log/2018-10-01#1856937 -> yes, please; also yes, can leave the old disk plugged in to see when it dies, why not (iirc there should still be 1 usb2 empty slot on my RC as the other one has an FG)
a111: Logged on 2018-10-01 21:17 asciilifeform: diana_coman, mod6 , lobbes , also give signal re whether you want the newer iptables-enabled kernel to go on your boot sd , when we take the boxen down ( iirc we already did mod6's )
diana_coman: the thing is though that at any rate, it won't get the same type of use as it did as main disk so I don't know whether much can be found out from that really
ben_vulpes: those reluctant to diddle /etc/hosts without seeing signed material first may: curl --header 'Host: cascadianhacker.com' 216.151.13.77/dns_update.txt
diana_coman: I suspect there might be more to find out from dissection of the thing
mircea_popescu: i guess im behind the times in obstetrics.
mircea_popescu: ben_vulpes updatered, thx
asciilifeform: !Q later tell BingoBoingo lobbes's drive ready to plug
lobbesbot: asciilifeform: The operation succeeded.
BingoBoingo: asciilifeform: Ty, headed over
lobbesbot: BingoBoingo: Sent 1 minute ago: <asciilifeform> lobbes's drive ready to plug
asciilifeform: BingoBoingo: btw figure out when you want to do yours
asciilifeform: http://btcbase.org/log/2018-10-02#1857127 << month and a half... whatcha moving it with , mod6? oxcart ?
a111: Logged on 2018-10-02 03:10 mod6: Lords and Ladies of TMSR~: Update on 216.151.13.78 (The Bitcoin Foundation's 2nd node), this TRB machine will be shutdown tomorrow morning, to be packed up and brought to texas (it's new home). We anticipate this box to come back online on-or-around November 15th.
mod6: ben_vulpes: I am shutting down 'lovelace' (the second tbf node) now.
mod6: I have also pulled '216.151.13.78' off of the Advertised Node list.
mod6: asciilifeform: ben_vulpes is bringing this with him to texas. He said he'd be able to have it up and running in a rack down there by mid-November.
asciilifeform: aa rack not built yet. aite
asciilifeform pictures ben_vulpes's texan fort
diana_coman: http://btcbase.org/log/2018-09-27#1855101 -> it turns out Eulora actually needs precisely this since its communication protocol specifies different lengths of messages, hm
a111: Logged on 2018-09-27 20:37 asciilifeform: yea i can't picture for what might need variable masses in production
a111: Logged on 2018-09-18 14:26 asciilifeform: mircea_popescu: i wrote the item originally for gossipd experimentations. udp gives a max practical packet length ( what it is , remains to be determined ) and if given proggy's protocol needs variably-sized ones, you can pad with rng.
asciilifeform: afaik there is no practical reason to actually send variable-length udp.
diana_coman: asciilifeform, clients pay for traffic though so dunno
asciilifeform: diana_coman: i dun think there exists still on planet3 an isp that actually charges per-byte
asciilifeform: ( per TB -- yes. per byte afaik no )
diana_coman: it's not the isp, lol; it's eulora-internal because client can choose how much traffic it generates
diana_coman: but if you force it to pad everything to maxlen it's a bit iffy
diana_coman: every time they simply ask for an object you force them to send over 2048 bytes, ugh
diana_coman: there IS some padding, i.e. it's not entirely arbitrary lengths, no
asciilifeform: diana_coman: a frame is a frame, short packets still occupy one,.
diana_coman: but it's variable lengths..
asciilifeform: i.e. it'll still take 1500.
asciilifeform: even if nominal length is 3.
mircea_popescu: diana_coman working on it.
mircea_popescu: SPEC HAS EVOLVED MEANWHILE!
asciilifeform: ultimately it's diana_coman's proggy, not mine, i can only recommend. imho fixed packets make the coad 9000x simpler, and simplify crapola filtration also. but if diana_coman's application absolutely gotta vary the lengths, then do it..
diana_coman: mircea_popescu, cool; well, it's been 4 months being digested hopefully by everyone around so evolution makes sense!
mircea_popescu: so far, productive activity, but only made it up to 3.
diana_coman: asciilifeform, it certainly makes the code simpler! if only I could always choose by this criteria though...
diana_coman: anyways, will wait to see the updates
asciilifeform: diana_coman: given that you have rsa in there also, how do you intend to make'em shorter ? or is this strictly re the serpent payloads
mircea_popescu: anyway, re "client pays for traffic" -- yes, but message traffic not packet traffic.
diana_coman: asciilifeform, serpent payloads really; rsa is meant for single use when registering with server pretty much
mircea_popescu: padding wouldn't cost in principle, except if crypto produced then entropy costs.
mircea_popescu: but i expect can have client opt to pad with fixnum.
asciilifeform: mircea_popescu: hm if this is so, then i have nfi why you'd want to try an' shorten packets
diana_coman: asciilifeform, the above wasn't clear until now, it's clarified ...now
mircea_popescu: asciilifeform because the largest packet we ~need~ is 16kb
diana_coman: so then hooray
mircea_popescu: and forcing all packets 16kb may lose us on some routes.
asciilifeform: well i did warn, http://btcbase.org/log/2018-09-28#1855322 , what else i can say.
a111: Logged on 2018-09-28 15:12 asciilifeform: even if seems that 100% of 2/3-frag packets make it through in 'laboratory' conditions, still gotta remember that the frag reassembly buffer is the ~exact~ equivalent of the pre-trb 'block orphanage'
mircea_popescu: here's the bojum, explained :
asciilifeform: ( if i were writing this proggy, i'd rather http://btcbase.org/log/2018-09-28#1855329 . )
a111: Logged on 2018-09-28 15:57 asciilifeform: imho if you want large messages, oughta have own fragger/reasmer, not the ??? in linux/ciscolade
mircea_popescu: 1. server must be able to acquire RSA key of client. 2. the rsa key of client will have to go in a rsa message, because they presumably don't have serpent keys agreed upon ; 3. the payload for one chunk of rsa key is 1960 bytes, fixed ; 4. the size of a key is 3.x such 1960 byte chunks, meaning 4 chunks. 5. the size of a 4 payload message is 16kb.
mircea_popescu: 6. if you pertmit this 16kb item be chunked, you basically rebuild the tcp ddos bs long discussed here. if it has to be in 1 piece, you can always use or discard on sight.
mircea_popescu: so -- eulora MUST have a 16kb packet in its format.
asciilifeform: i'd still rather reasm'em in the proggy itself, rather than baking in a perma-reliance on the linux nonsense. but i suppose is easy to say, but moar work to actually bake.
mircea_popescu: now, if it also has 1 single size, that means the size of all packets is 16kb
mircea_popescu: this seems nutty.
mircea_popescu: asciilifeform nevermind that. to re-asm you gotta keep chunks.
mircea_popescu: how many chunks am i keeping and for how long ?
asciilifeform: right but if you reasm in own proggy, the chunks actually carry the port # and origin ip.
asciilifeform: whereas if you rely on the udp fragger, only 1 in 4 chunks does, and the rest are not mechanically filtrable.
mircea_popescu: what's "here's a list of 2mn unknown ips" buy me ?
asciilifeform: that you can throw out obvious crapola
asciilifeform: and that you can then use fyootoor fragless ip stack . is all.
mircea_popescu: doesn't take so much work to ask me to hold 16gb of chunks.
diana_coman: asciilifeform, but what's the problem with that? client sends and waits (for as long as it wants) for a reply; whenever it has enough of waiting...sends again; until it makes it
mircea_popescu: this must-have magical packet of 16kb is extremely rare -- basically only sent when new client making new account.
mircea_popescu: if it has to retry a few times not end of world.
asciilifeform: diana_coman: imho i described the problem with using linux's fragger/defragger in sufficient detail, would rather not clutter the log with a repeat
mircea_popescu: meanwhile if every single 13 byte posupdate takes 16kb... that's insanity.
mod6: ben_vulpes: bitcoind has been stopped, and lovelace has been shutdown with `shutdown -h now`. Feel free to pack it up whenever you're ready. Thanks.
asciilifeform: mircea_popescu: realize that the linux frag reassembler doesn't give you anything near GB buffer
asciilifeform: once you have any substantial traffic density, it'll simply start dropping.
mircea_popescu: nobody here but you is discussing that.
asciilifeform: ( it's a coupla kB typically )
mircea_popescu: my problem is that i can't ~not~ have 2 sizes of udp packets.
mircea_popescu: diana_coman do you see a way out of this ?
asciilifeform: the way i'd do it, is to have e.g. 1400 byte packets , and they're authenticated (e.g. client gets seekrit 512bit turd, and keccak(turd + payload) is a field in those 1400) , and ~then~ there is a flag for whether the packet is part of a e.g. 8 byte sequence that gotta reasm, or not .
asciilifeform: i.e. internal defragger .
asciilifeform: err, not 8 byte, 8 packet
mircea_popescu: asciilifeform and the attacker sends you sequence-1 packets. and you hold them. and as i said, "doesn't take so much work to ask me to hold 16gb of chunks."
asciilifeform: attacker can't send anyffing unless he has a valid key
mircea_popescu: i am not so interested in holding on to chunks of future.
asciilifeform: ( he can send, but it gets tossed in O(1) )
mircea_popescu: looky, we're discontinuing this discussion, because you've not taken the time to familiarize with priors and i don't judge it's worth your time to do so, or mine to make you do so.
asciilifeform: my observation is strictly in re linux defragger gives you no way to filter, whereas hand-sewn -- would. but it is not my intention to prevent folx from pissing on erry possible electric fence, i'ma leave it there.
asciilifeform: and pretty sure i grasp the priors. for instance, the proggy i originally wrote the udp thing for, operated in 64kB chunks.
asciilifeform: rereading http://btcbase.org/log/2018-10-02#1857215 -- if you actually gotta take 'new rsa key' from allcomers, and there is no way to have'em know a seekrit bitstring prior , then yes afaik it is impossible to do better than mircea_popescu's algo. ( it is unclear to me what's to prevent enemy from swamping your system with new acct requests and giving you 9000 TB of rsa keys to store, but possibly i missed a detail )
a111: Logged on 2018-10-02 14:30 mircea_popescu: this must-have magical packet of 16kb is extremely rare -- basically only sent when new client making new account.
mircea_popescu: see ? it's not that i hate you, but we gotta talk of the same things to talk to any sort of productive end.
asciilifeform: no i get it
mircea_popescu: here's the bojum with that : soner or later, you gotta meet new people. the DEFINITION of "new people" is "no way to secret prior". so...
asciilifeform: i'd have a separate box for new acct regs, that eats rsagrams..
mircea_popescu: server as it stands now doesn't talk to any new people, hence the "talk to mp" thing in client.
asciilifeform: ( or at least separate nic )
mircea_popescu: asciilifeform the problem degrades gracefully : even if you do have shared rsa key, client sometimes wants to send serpent keys (which go to rsa) and some other times wants to send plain cruft (goes to serpent). so two sizes again
mircea_popescu: i can't have as many interfaces as packet types for crying out loud.
asciilifeform: as i currently understand, the only non-negotiably 'heavy' one is the new acct packet
asciilifeform: so there are 2 fundamental types
asciilifeform: ( the serpent packets are constrained to simply multiples of 128 )
mircea_popescu: well, rsa packets are 4096 bits multiple ; serpent packets are multiples of 128. rsa key exchange is 16kb fix.
asciilifeform: so this'd easily cut into 1 process that eats always 4096bit, and another that eats 16kb.
asciilifeform: ( serpent can pad into 4096 )
mircea_popescu: yes but i can't possibly turn http://btcbase.org/log/2018-09-28#1855277 into 4096 bit and live.
a111: Logged on 2018-09-28 05:07 Mocky: http://btcbase.org/log/2018-09-28#1855218 >> players in sight of each other, all getting position updates for all others is *THE* central scaling 'n squared problem' for mmo. 20 byte position sent 4 times per second to 100 players is 8k/s per player. and 4 updates per second is really not enough for good playability when you factor in the round trip lag. 15/s is less draconian (many games send 30-60). 100 players gathered with 15 updates
mircea_popescu: heck, im currently proud i took that 20 down to 13.
asciilifeform: 4096bit is 512byte, you're sending 1500 frame always, even if your nominal packet is 3bytes long. simply how ethernet worx.
asciilifeform: i.e. the space saving is illusory.
asciilifeform: this is that 'bit-packing variables' thing all over again.
mircea_popescu: jesus christ you're right aren't you.
asciilifeform: aha! i dun hate mircea_popescu's algo because his name starts with m!111 i simply rtfm'd...
asciilifeform: ( and peeked at what actually moves down my wire.. )
asciilifeform: anyway i'ma bbl, meat.
mircea_popescu: it's funny how "optimization" lures the mind.
Mocky: if you accept 16k new-acct packets seems just as easy to http://btcbase.org/log/2018-10-02#1857229 but further, if you rely on external frag-reassm it's even easier for attacker to prevent you from accepting *any* new account packets
a111: Logged on 2018-10-02 14:35 mircea_popescu: asciilifeform and the attacker sends you sequence-1 packets. and you hold them. and as i said, "doesn't take so much work to ask me to hold 16gb of chunks."
Mocky: frag reassembly in-program can use a buffer of specified size, just as is done externally. so excess chunk memory overhead is known up front
Mocky: http://btcbase.org/log/2018-10-02#1857260 I see anything like this in the logs, do you have a link?
a111: Logged on 2018-10-02 14:53 asciilifeform: this is that 'bit-packing variables' thing all over again.
Mocky: *don't see*
a111: Logged on 2018-09-18 14:27 mircea_popescu: what it is is certainly <1kb say. wasting the occasional portion of a kb is not so unlike wasting the occasional portion of a 64 bit register to represent a boolean value.
a111: Logged on 2017-11-22 23:03 mircea_popescu: it's bullshit all the way down, "the 4096 bit block gets cut into 16 sub blocks to be fit into rotorizers that cut each block into 64 bits and process with their 4 bit s boxes". because we're from the fucking cartoons.
a111: Logged on 2017-11-14 20:35 mircea_popescu: asciilifeform typical pc has the following situation : 64 bit registers, 128 bit memory, 1024 bit disk sectors, 64 mb video buffers, and atop sitting a drunk driver who thinks 8 bits are a byte.
Mocky: ah ok, thx
mircea_popescu: there's more, somewhere i say "meanwhile people figured out the complexity's not worth the saving" and etc. recurrent topic.
diana_coman: Mocky, if I get this right you argue that it's better to do frag internally because can't trust externally to not fuck up the line entirely as attack vector?
Mocky: yes
Mocky: e.g. attacker floods with packet frags prevents legitimate frags from ever being reassembled, instead silently dropped, server is none the wiser
mircea_popescu: there are no frags.
diana_coman: he is talking of the new rsa packets that are biggest
diana_coman: so will get presumably fragged
mircea_popescu: iirc 20kb packets made it over test
Mocky: 16k packet -> 1500 MTU
diana_coman: but honestly I don't see that to be such a huge problem
mircea_popescu: Mocky 16kbits, you realise.
Mocky: nope, missed that
mircea_popescu: 4x rsa chunk. 2048 bytes.
mircea_popescu: and in our tests, we saw unfragged 20-50kB packets.
diana_coman: mircea_popescu, uhm, they made it through - presumably fragged though?
mircea_popescu: ie, mtu is two things : no smaller frame shall issue from interface ; and larger packets MAY (but don't have to) travel as multiple frames.
mircea_popescu: diana_coman well, possibly. iirc we didn't specifically check for that.
diana_coman: precisely; I think that in principle there is a possibility of that "attack" but I fail to see that it's worth much really
asciilifeform: mircea_popescu: there are no frames bigger than 1500 ( aside from exotic lans )
diana_coman: so basically what, for as long as attacker can keep flooding , presumably no new accounts although there might still be some that make it through?
asciilifeform: your heavies got fragged & reasmed by receiver
mircea_popescu: asciilifeform so interface silently and timely reassembled 50kb packet out of 30 fragments ?
mircea_popescu: pretty good.
mircea_popescu: anyway, i have no intention to deal with udp flood at gameserver level.
Mocky: I'd expect frag and auto reassemble to work well in low volume conditions
asciilifeform: try it with saturated receiver tho.
asciilifeform: Mocky: errything worx great with quiet volume.
mircea_popescu: of course... if we used smaller rsa keys we could fit in the mtu...
diana_coman: eulora-sized rsa, hm
mircea_popescu: but i mean... it's for a reason, not just cuz bored.
mircea_popescu: i mean, really, 2048, not 1460 ? written in heavens or what ?
mircea_popescu: suppose i make the rsa packet 1498 bytes. this then means 2996 bit rsa. problem ?
Mocky: well including udp header, like 1470 to 1480 of payload available
asciilifeform: afaik it's not unlike diff b/w a 25 and 50 megatonne nyook
asciilifeform: i.e. large on paper, but ~sams physical effect
diana_coman: from a practical point of view it does mean that Eulora doesn't use directly TMSR RSA keys though
mircea_popescu: im not sure anyone'd want to use his main key for this anyway
mircea_popescu: but yes, as far as anyone knows 2048 bit keys perfectly safe, now and for the foreseable future (this isn't a comment on koch faux-pgp, which unsafe at any length as well documented in logs qntra and so on).
diana_coman: yes; anyway it's basically a knob to turn, not a big issue in itself
asciilifeform: fwiw asciilifeform is still sitting on top of a 2048b main key
mircea_popescu: i'm going to re-write the rewrite of comms protocol with this new paradigm.
asciilifeform: ( will move when finally kerosene poured on gpg )
mircea_popescu: let's calculate this precisely. so what size is my actual payload here, 1468 reliably ?
mircea_popescu: ( and btw diana_coman it's entirely possible this will mean republic might well inherit the format, seeing how the problem we are dealing with isn't of our own make -- others will run into it too.)
asciilifeform: mircea_popescu: 1500(ethernet frame) - 20 byte (ip header) - 8 byte == 1472
asciilifeform: ( 1472 remains for programmable payload )
mircea_popescu: am i absurd in wanting to start from 1499 rather than 1500 ?
asciilifeform: i can't think of why, but it dun do any harm afaik
mircea_popescu: sure it do harm, you lose on some bytes.
asciilifeform: the nic will simply insert a 0 octet
asciilifeform: well yes, in that sense.
mircea_popescu: alright then, ima put 1472 bytes helo packet ; meaning 2944 bit rsa keys.
Mocky: 1472 is what i've used in the past
asciilifeform: Mocky: it's the theoretical max udp-over-ethernet aha
asciilifeform: ( not taking into consideration weirdo lans with 'jumbo' nics etc )
mircea_popescu: diana_coman 2944 bit rsa keys, meaning 1384 bit usable message space in the rsa packet ? with oaep and everything ?
mircea_popescu: !Qcalc 2944 / 1384
lobbesbot: mircea_popescu: 2.12716763006
mircea_popescu: holy shit, what if i can shave it down to 3x ?!
mircea_popescu: !Qcalc 1472/3
lobbesbot: mircea_popescu: 490.666666667
Mocky: http://btcbase.org/log/2018-10-02#1857302 >> still will be filtering incoming UDP by known IPs and preferred serpent keys though anyway, correct?
a111: Logged on 2018-10-02 15:50 mircea_popescu: anyway, i have no intention to deal with udp flood at gameserver level.
mircea_popescu: Mocky nope, by size.
mircea_popescu: rsa-size and serpent-size packets handled, rest discarded (and sources punished)
Mocky: ok but if size matches still have to attempt decryption even if contains garbage?
mircea_popescu: !Qcalc 1472/128
lobbesbot: mircea_popescu: 11.5
asciilifeform: i expect decryptions will be the principal cpu expense of running a rsatronic box. at least until the fyootoor day of fpga etc
mircea_popescu: possibru
asciilifeform: fortunately they parallelize linearly
mircea_popescu: the thing is -- new accounts handled "as resources permit" anyway, so...
asciilifeform: ( farm out to as many cores as you like )
mircea_popescu: ok, so this back of a digital envelope seems to suggest we want : 1. fixed size 1470 byte rsa packets, made to work with 3920-bit rsa (of which i presume the useful message size to be 1872 bit, diana_coman plox to confirm maffs ?). such a packet has then 1696 bits spare for e and bullshit.
mircea_popescu: 2. fixed size 1408 byte serpent packets.
diana_coman: mircea_popescu, 1872 useful bits in 3920-bit rsa, confirmed
mircea_popescu: is serpent 128 bits or 128 bytes ?
mircea_popescu: bits so then
mircea_popescu: 2. fixed size 1472 byte serpent packets.
diana_coman: bits, yes
mircea_popescu: yuppers. 1470 vs 1472, pretty as can be.
diana_coman: ha, quite
mircea_popescu: in other very sads, the new p.bvulpes machine is VERY fucking slow.
mircea_popescu: * About to connect() to p.bvulpes.com port 80 (#0)
mircea_popescu: * Trying 51.15.42.105... Connection timed out
ben_vulpes: that's odd, i'll look
mircea_popescu: ben_vulpes nah, no need, by now i mostly suspect my route was bad.
ben_vulpes: i was going to ask for a traceroute
ben_vulpes: mod6: ack
asciilifeform: lobbes: plox to confirm when satisfied that your rk worx correctly
deedbot: http://bimbo.club/?p=38 << Bimbo.Club - TMSR Log Summary - 9/28/2018
asciilifeform: 'Asciilifeform would never recommend the use of 'rsa chips' as they work with only 'toy' key lengths, work in one direction, and have to be manually transported' << agh what
asciilifeform: ~pigeons~ manually transported, nicoleci
mircea_popescu: !!up nicoleci
deedbot: nicoleci voiced for 30 minutes.
mircea_popescu: meanwhile @birdcage, "<nicoleci> im getting so frusterated with these logs <mircea_popescu> yssat ? <nicoleci> i understand every 45th line"
asciilifeform: lol i wouldn't have guessed that it'd be ~that~ line..
asciilifeform: i thought pigeon were universal.
mircea_popescu: she didn't go to kindergarten.
asciilifeform: ( my local ww1 aviation museum has entire glass case of stuffed 'famous' carrier pigeons. so they defo know about'em in usa... )
mircea_popescu: chick's injun, they got their own schools.
asciilifeform: same place where they have the bed the wrights slept in, the shitter they shat in, etc
nicoleci: im not going to make excuses for not connecting the pigeon talk, but no fucking clue what http://btcbase.org/log/2018-09-28#1855365 means
a111: Logged on 2018-09-28 16:21 asciilifeform: and i'ma never recommend to anyone the use of heathen 'rsa chips'. not even because they all, without exception, work with only 'toy' key lengths, but because srsly wtf.
lobbesbot: nicoleci: Sent 16 hours and 5 minutes ago: <asciilifeform> s/to/too
mircea_popescu: nicoleci rsa keys are useless when the key is short. do you understand how rsa works ?
nicoleci: mircea_popescu: not at all.
mircea_popescu: alright. can you tell me the prime factors of the number 6 ?
nicoleci: ah 1,2,3,6
mircea_popescu: ok. 1 and 6 we ignore, as they're trivial for our exercise.
mircea_popescu: now, can you tell me the non-trivial prime factors of 221 ? (but without looking anywhere online).
nicoleci: lol, no
mircea_popescu: can you tell me what's 13 * 17 ?
mircea_popescu: right. this is then the rsa problem : it is relatively easy to multiply prime numbers ; it is exceedingly difficult to get them back out of the multiplicated soup
mircea_popescu: this is especially true the larger the prime numbers become. rsa uses this disparity to produce an undefeatable encryptio scheme. the two prime factors (13, 17) are the private (ie, secret) key. their product (221) is the public key.
mircea_popescu: some clever bits of math permit one to encrypt a message with the use of that 221 so that only he who knows 13 * 17 =221 can ever get it back out.
nicoleci: ahh i see
BingoBoingo: Ah, slave priviledge in action. Countless ninjashoguns weep as the combination of right behavior and right parts allows the priviledged to learn in hallowed logs.
BingoBoingo: #WoTInAction
nicoleci: yeah thanks, Master. privilege in knowledge, torture in a chromebook
mircea_popescu: http://trilema.com/2018/euloras-communication-protocol-restated/ << republished to significant change ; diana_coman Mocky asciilifeform an' whoever else may be interested. comments welcome!
deedbot: http://qntra.net/2018/10/university-of-brighton-takes-ambiguous-position-on-program-supporting-coed-to-gentlemen-connections/ << Qntra - University Of Brighton Takes Ambiguous Position On Program Supporting Coed To Gentlemen Connections
mircea_popescu: the 1 in 6 far exceeds the 1 in 20 or so females worth the fucking in ~anyone's estimation.
BingoBoingo: And yet 100% of them are only 19 once
BingoBoingo: Meanwhile from other mines: "I’m active in supporting LGBT causes. My boyfriend recently said that “this whole LGBT thing has gone way too far” and that he’s no longer sure what to think about same-sex marriage, even though he had thought he supported it. Worse, he said that maybe the original civil rights movement went too far, and perhaps businesses should be allowed to racially discriminate if they want to. In fairnes
BingoBoingo: s, that was in response to me pointing to that as a precedent for LGBT rights, but I’m not sure that makes it better. I’m just aghast. How can I make him see how wrong he is?"
asciilifeform loox at mircea_popescu's item..
asciilifeform: mircea_popescu: is the 20 may date intentional ?
Mocky: original pub date
asciilifeform: aaaah edited aite
mircea_popescu: BingoBoingo doh. let's check back with the aghast lonely hearts club when we're discussing how business can keep slaves (ie, them) if they feel like it.
asciilifeform: 'n*(4*int64 + int32) (32 bytes each key followed by a 4 byte ID calculated as the keccak hash of the key itself)' << unless i misread, how does one get a 4byte output from keccak ?
mircea_popescu: by setting it to spit out 4 byte output ?
asciilifeform: does diana_coman's keccak do this ? ( aside from the q of what does a 32bit hash output win, it aint exactly hard to collide into a desired 32bit regardless of how you make hash algo.. )
mircea_popescu: but this'd be a collision inside an encrypted packet.
asciilifeform: so moar of a checksum ?
mircea_popescu: im really only using it as an adhoc crc ; possibly should either get rid of it altogether, or implement a proper ec.
asciilifeform: aaah so not asked to be resistant, aite
asciilifeform: i'd use ordinary crc32 for such item, much cheaper cpuwise
mircea_popescu: in ~principle~ eve can't even know what serpent keys either server or client are using.
mircea_popescu: but yes, i am seriousl;y considering this.
asciilifeform reads the other moving parts...
asciilifeform: 'text, consisting of int32 (keccak hash of top level itemxviii)' << i assume ditto
mircea_popescu: anyways, i shall now torture girls @ beach. will read all comments and everything tonite.
asciilifeform: and in 4.8 same
asciilifeform: i dun get how 'int8 (equal to 18364757930599072545' worx
asciilifeform: on my planet, 'int8' means 8 bits
asciilifeform: int16 - 16, int32 -- 32, int64 -- 64
asciilifeform bbl,meat; will come back to this item
diana_coman: asciilifeform, keccak can spit out as many or as few bits as you want it to, not sure what is you q there re keccak
diana_coman: specifically, bit-level version gives bit-level precision so one can ask for as many bits as they want; workhorse byte-level keccak implementation works at byte-level so it will spit out as many *bytes* as you ask for (see http://www.dianacoman.com/2018/02/08/eucrypt-chapter-9-byte-order-and-bit-disorder-in-keccak/#selection-193.1-197.51 )
diana_coman: http://btcbase.org/log/2018-10-02#1857391 -> lol, they are also just... not prime
a111: Logged on 2018-10-02 18:17 mircea_popescu: ok. 1 and 6 we ignore, as they're trivial for our exercise.
asciilifeform: http://btcbase.org/log/2018-10-02#1857438 << ok i wasn't sure whether diana_coman's keccak knew how to output arbitrary bitness. but my other point was that a 32bit hash may as well be crc32, there can be no notion of collision resistance when yer output is 32b.
a111: Logged on 2018-10-02 18:53 diana_coman: asciilifeform, keccak can spit out as many or as few bits as you want it to, not sure what is you q there re keccak
asciilifeform: diana_coman: can you clarify re the 'int8' thing plox ?
diana_coman: asciilifeform, int8 is indeed meant to be on 8 bits so no idea what that thing there is ; fwiw I added it to my comment on the article with ref to your q here in the logs too because I'm puzzled by it too
diana_coman: re collision yes, it's clearly not collision-resistant
diana_coman: the eucrypt keccak implementation uses an out parameter for output and so it will fill whatever the caller provides
ben_vulpes: http://archive.fo/WeQ7Q << ruralia continues to deliver lulz: "booby trapped wheelchair", "hot tub attached to tripwire" "elder abuse"
asciilifeform: ben_vulpes: poor idjit. could've set up proper dynamite, not as if he could sizzle in electric chair twice.
asciilifeform: '.410-guage shotgun pellet' lol.
ben_vulpes: sad fate to be remembered for failing to take out agents of the imperium given ~unlimited time and inclination to prepare.
asciilifeform: Fuck Moar Cousins, i guess..
ben_vulpes: the many sleepless nights of the rural amphet didn't help.
asciilifeform: between rotgut, dope, 6 generations of fucked cousin, mcfood -- not much chance left for brain
deedbot: http://bingology.net/2018/10/02/haiku-r1beta1-thoughts/ << Bingology - BingoBoingo's Blog - Haiku R1/beta1 Thoughts
BingoBoingo: asciilifeform: replied
asciilifeform: BingoBoingo: loox like they lifted various drivers from freebsd, since i last saw
BingoBoingo: Other parts as well.
asciilifeform: so in effect it's freebsd but with an oddball incompatible thing in place of x11
asciilifeform: sorta like an open sores crapple.
BingoBoingo: Well, the microkernel thing is different
asciilifeform: still massive ball o' C
asciilifeform: hence 'like crapple'
BingoBoingo: Sure. Its the sort of thing you'd stick in a lobby to let people check the weather.
BingoBoingo: Or throw on a video playing box
asciilifeform: i'd stick a kernel that dun crash on these..
asciilifeform: and ugggh c++ kernel...
asciilifeform: reminds me of 'reactos' ( another oddball 'man alone' item; believe or not : attempt to open sores re-create... winblowz )
BingoBoingo: The big difference between Haiku and ReactOS is in Haiku spreading works (TM)(R). Reactos hasn't made it that far yet.
asciilifeform: spreading worx pretty easily when you lift all of the iron-specific C hairballs from existing open sores
asciilifeform: the q is, what is gained thereby
BingoBoingo: novelty
asciilifeform: possibly i find novelty 'for sake of novelty' to not be auto-attractive; but imho these folx took the same baccilae that made microshit what it is ( cpp kernel, kernelized gui, 'desktopization' ) and somehow supposed that it'd add up to different result than microshit's..
asciilifeform: ( and on top of this imported the worst gnarl from freebsd... )
asciilifeform: seems like there's even 1990s liquishit from the original 'beos' in there.
BingoBoingo: Well, it isn't novelty for the sake of novelty. Novelty for the sake of highlighting how broken Ubuntu is.
BingoBoingo: This piece of weird with all of its flaws... still works better than Ubuntu
asciilifeform: BingoBoingo: even win10 loox pretty good when laid next to shituntu.
asciilifeform: on just about erry metric..
BingoBoingo: Never tried it myself
asciilifeform: wasn't an invitation to try it, lol. but statement of phakt.
asciilifeform: BingoBoingo: i strongly suspect that a box that smoothly runs the haiku thing will also run freebsd..
trinque: huh, I ran one of the early x86 Be versions for a bit, didn't hate.
asciilifeform: trinque: i dun hate. but gotta point out what it is.
trinque: but yes, can't disagree with asciilifeform
BingoBoingo: It ran openbsd fine, runs a linux fine now, FreeBSD was flakey last time I tried it on this one
asciilifeform: at least terry davis was straightforward about not having iron drivers.
asciilifeform: he refrained from importing world's 2nd gnarliest shitstack.
asciilifeform: i favour folx who are honest, 'i dun have drivers', over gabriel_laddels
BingoBoingo: Well, Uncle Terry is the Saint everyone thought Linus was
trinque: pbuh
BingoBoingo: Terry didn't let his daughter's feelz get in the way of his cause
asciilifeform: BingoBoingo: i suppose that's 1 way to 'saint' -- skipping straight to face to face with odin..
BingoBoingo: TempleOS does exactly as advertised
BingoBoingo: And now terry in in Valhala for it
BingoBoingo curious if gabriel ever got that amputation
asciilifeform: meanwhile, in trb observatory, http://nosuchlabs.com/pub/trb/10_2_moar_ProcessBlock.txt << caught up..
asciilifeform: BingoBoingo: for all i know he got head amputation.
BingoBoingo: Or maybe got adlai'd into a rehab
asciilifeform: BingoBoingo: is 186.50.24.80 , castle BingoBoingostein ?
BingoBoingo: It doesn't appear to be at the moment, but it could have been
asciilifeform: aah dynamic
asciilifeform: ( i have dynamic here also, for some reason local fuckheads want 2x the dough to make static. but it changes 1-2x / year, thus far i live with it )
BingoBoingo: Here dynamic means dynamic
BingoBoingo: It's also possible there's another trb node I haven't put my own eyes on running on a residential connection in this country
asciilifeform: i've been thinking i oughta conjure up moar trb nodez, but erry time i sit down and look to do it, end up thinking 'why give money to heathen derps'. but on other hand it dun do much good to put 9000 nodes all in pizarro. but to which heathen can give moneys without retching..
asciilifeform: trinque's asian noad seems to be well-behaved
asciilifeform: but it for same reason as stated earlier it wouldn't do so much good if i put a noad in same place
asciilifeform: so presently i end up shelving the idea erry time it makes circle round my conveyor
asciilifeform: sooo if anybody ( mircea_popescu ? diana_coman ? ) knows of some place that 1) isn't complete shit 2) doesn't have a trb noad living there yet -- plox to write in.
asciilifeform: ( ideally : on some ~continent~ that dun have one yet, imho )
asciilifeform: diana_coman: do you have one back in 'old blightey' ? or know of a place there where i oughta put one
BingoBoingo: asciilifeform: Have an eta on when to do the diana_coman switch?
asciilifeform: BingoBoingo: how about nao.
BingoBoingo: asciilifeform: Aite, lemme put pants on
BingoBoingo: And finish this balcony coffee
asciilifeform: BingoBoingo: i'ma meatspace for ~20min, should give you enuff time for leg
asciilifeform: BingoBoingo: when you get to the dc, feel free to pull lobbes's drive from dulap ( label it ) and insert 1) first, diana_coman's 2) 30sec later, the new
asciilifeform: BingoBoingo: ping me in #p when ready.
asciilifeform: !Q later tell diana_coman your rk is redisked! and running; you may want to stand up yer www server (iirc it doesn't run on boot)
lobbesbot: asciilifeform: The operation succeeded.
asciilifeform: diana_coman , lobbes : your old drives are currently in dulap, lemme know when you're ready to have'em reformatted ( so your boxen dun try an' boot from'em instead of the primary ) and reissued to you as secondary disks.
asciilifeform: BingoBoingo: i think this is all for today in the bilge
BingoBoingo: Aite, coming up
asciilifeform: ty BingoBoingo !
asciilifeform: a+++ as usual.
lobbes: http://btcbase.org/log/2018-10-02#1857370 << I can confirm rk is working. ty!
a111: Logged on 2018-10-02 17:34 asciilifeform: lobbes: plox to confirm when satisfied that your rk worx correctly
lobbes: http://btcbase.org/log/2018-10-02#1857138 << I can also confirm that this was exaaactly what was in my 40gb error log.. oof (btw ty asciilifeform for teh heads-up)
a111: Logged on 2018-10-02 09:46 diana_coman: http://btcbase.org/log/2018-10-02#1857110 -> if it's anything like mine, it'll be mostly loud complaints from php because "time zone not set!!!" and similar (apparently php version on the RC is too new for its own good)
asciilifeform bbl,meat
asciilifeform: oh btw, lobbes & diana_coman , dun forget to set your rk's clocks.
asciilifeform genuinely bbl
lobbes: http://btcbase.org/log/2018-10-03#1857528 << forgot to respond to this, but you have my a-ok to reformat old drive. and thank you gentlemen for the smooth swap
a111: Logged on 2018-10-03 00:38 asciilifeform: diana_coman , lobbes : your old drives are currently in dulap, lemme know when you're ready to have'em reformatted ( so your boxen dun try an' boot from'em instead of the primary ) and reissued to you as secondary disks.
lobbes: (obligatory pizarro pitch to log readers: where else can you have 100% context on -why- service is being done on your box, as well as watch it unfold real-time? Compare and contrast with, say, this example from heathenlandia (Edis) >> http://archive.is/NVpIR)
mircea_popescu: the incredible transparency they got going is actually a very strong selling point
mircea_popescu: just needs packaging & being market communicated.
trinque: "we slay incas" while cute, communicates nothing except "you're not in the in-group"
trinque: oughta say something about why the fuck someone wants a republican ISP
asciilifeform: trinque: yea the inca thing is placeholder
asciilifeform: trinque: the text to answer 'wai republican isp' exists, unfortunately it's a coupla hundr MB, aka.. the l0gz
asciilifeform: if can think of a way to conpress!
asciilifeform: ( pretty hard, imho, to even begin in language heathens might understand.. )
asciilifeform: *compress
trinque: I'd lean hard on the "we're humans" thing, communicate that
trinque: somebody wants to know what makes an actual human later, great for him
trinque: i.e. there's this fine gentleman BingoBoingo actually in the bowls of the machine, steadfastly giving a shit.
trinque: polymath madman assembling world's only sane ARM hosting, etc
BingoBoingo: Condensing these logs into marketing is a thing being pondered
BingoBoingo returns from doing the necessary work of walking the beach at night and tormenting the Peruana by reporting how incredibly safe and secure it was
← 2018-10-01 | 2018-10-03 → ↑
Random(trilema) | Download hourly DB snapshot | Get Source Code