38600+ entries in 0.015s
mircea_popescu: phf, not really drunk as such. it's either the plum thing, or else the sour cherry thing, basically. not really herbing.
mircea_popescu: ckang, ppl do actually, many older folk own a quarter acre of plumtrees or so, make their own 45-52% "tuica".
mircea_popescu: anyway. i come from a country where 1l 196 proof is ~4 dollars, sold in convenience stores.
mircea_popescu: i suppose you could get a custom made resistor + multi-spot thermometers and push a point.
mircea_popescu: copper stills are great for taking mash (0.x - 7% or so alcohol) to spirit (30-40% or so). they're terrible for trying the 30-50% to 95% part.
mircea_popescu: ckang, yes, but that's too calorically bulky to work for the proposed use here.
mircea_popescu: also it's not properly production, merely fractional distillation of last pass. you're just taking the BBAV/BAC/whatever shitstilleries out of your cup.
mircea_popescu: it won't make commercial amounts, but even the smallest still can outpour your gullet.
mircea_popescu:
http://btcbase.org/log/2018-04-17#1801142 << pretty great story. not to mention the obvious moral : "are you ruining your child's chances to a future by failing to provide a safe learning environment for him through your limp wristed inability to create a clear and present threat to violent bodily harm ?"
☝︎ mircea_popescu: in short, i don't think esltards even vaguely remember YOU CAN DO THINGS.
mircea_popescu: put it in oj or w/e. but this apparently was divine intervention, half hour's labour worth of parts and half hour's worth of work assembling them together.
mircea_popescu: what fucking divine intervention, a still is $15 in household equipment, get one of those rice cookers or w/e pot warmers, wirth digital temperature adjustment. set it for 79C, stick an erlenmeyer glass in there with a cork and a bent tube coming out, put an ice pack over the tube and voila! whatever southern confort goes in, 195 or so proof alcohol comes out.
mircea_popescu: no further than earlier over coffee, girl proposed that during her stay in $us.shithole she "tried getting into beer" because well... gotta have an activity and there was no good alcohool available, except for this beer that didn't utterly suck. so i said, "why not make a still", and she said "baring divine intervention...."
mircea_popescu: yes. but hey, this is precisely why god gave us blogs in the first place.
mircea_popescu: if client has at least one server X key it can bootstrap, sending more.
mircea_popescu: re "registered with deedbot" part : i expect in-game trade should be the driver of both rating and registration.
mircea_popescu: im thinking it's actually best to have a single helo, with r-pubkey. if it is known to the server then it sends X keys ; if it is not known then... it sends X keys.
mircea_popescu: i know this isn't how it works now and hasn't been for a long time, but i'm ready to move on!!1
mircea_popescu: but no, seems the correct approach is to replace 3.1.5 with "rsa pubkey". and ACTUALLY use that as the account id.
mircea_popescu: diana_coman, one consideration was that if it includes pubkey it will have to be multipacket and i wanted it to be singlepacket for some now incomprehensible reason.
☟︎ mircea_popescu: (it does away with the "is user logged in". you can pm everyone all the time, they're always logged in anyway).
mircea_popescu: (for the oursiders : it is the agreement in minigame boardroom that rsa helo packets from existing clients will be lowest priority, after 1. serpent packets and 2. rsa helo packets from unknown clients. the idea is you keep your serpent keys, and continue your "session" whenever, it's kind of a stateless session)\
mircea_popescu: yes, but here's the principle : if server knows something will be needed as a certainty, server should act rather than wait to be called to act. which is why it's a server rather than a client.
mircea_popescu: i don't have this modelled well enough to say it with certainty ; but it seems to me 3 is a reasonable choice.
mircea_popescu: diana_coman, kinda 90% of all server code aims to avoid "accidental client ddos".
mircea_popescu: seems to me the threshold will practically be set at 1 as a matter of absolute necessity. once that is the case, setting it at 3 is in no substantial way different : just as many keys will be used as before, but the setting at 3 forces key creation at a time prior to when keys are needed, which seems to help with resource load spread.
mircea_popescu: but if you want less than 3, it'll keep sending you extras until you give up trying to argue with my server.
mircea_popescu: you can send as many as you want, the server will keep them for you.
mircea_popescu: because it's stuck keeping a list of keys anyway. so it knows how many they are anyway. so might as well send when needed rather than wait to be asked.
mircea_popescu: but basically the idea for X keys is to work like that, if you don't have any server makes, if you make them then server uses .
mircea_popescu: X keys only ; R key is one. and server is concerned because if it has no client X keys, it can't send, and if the client has no server X keys, the server can't receive.
mircea_popescu: diana_coman, in any case strictly speaking, the helo as we spec it does not include R pubkey ; whereas in practice it actually must. but read the whole blob, this is better compiled htan parsed.
mircea_popescu: that's what i mean, this is kinda too fluid and i suspect it's because somewhere in my head i conflate two things.
mircea_popescu: diana_coman, well, two kinds of helo, yes ? when initiating a connection ; and when initaitng an account.
mircea_popescu: now obviously, this approach wouldn't be nearly as useful for dynamically linked clients ; but i deem the fact that it puts the security incentive on dumping dynamic linking a very good thing.
mircea_popescu: (one could object, "it's pointless to attempt this, hacked client can just replace magic string", which is true, but nevertheless client can still binary audit his item and see / login with a special, known-good string-test-only client and see what he should be. ie, client can bootstrap himself out of the fakebox produced by a hacked binary.
mircea_popescu: the reason for this is that games are eminently a domain where people share binaries, a matter of fact established both from general and minigame's own experience. obviously in the sane world of source sharing, v is the correct solution. but if people are going to share binaries, this seems like the only available approach.
mircea_popescu: now here's a question on which i'd very much like to hear a lordship oppinion. so, the model currently contemplated for eulora includes a bit whereby the server has to be told by the client a magic string, and will report this back to the client on demand, "here's what you told me you are". the idea is that the client can then sha his binary, and see if the strings match.
mircea_popescu: also important, third question : should the client be permitted to generate X keys for the server ?
mircea_popescu: now subsidiary for all this : server should generate a batch of X keys and send them to the client every time its store of either S or C X keys drops under a certain value. it's therefore the client responsibility to make sure there's enough keys in store if it doesn't want to pay for key generation. now, what should this threshold be ? 3 ?
mircea_popescu: like this, server must not lose its R privkey and clients must not lose their R privkey , but pubkeys of all these can be safely lost, and X keys don't matter at all. seems altogether safer and less friable.
mircea_popescu: if instead we made it rely on R, there'd be great benefits. consider this alternate model : C : R(hi, this is C.R.key) S : R(here's some X keys for me and for you) C:(actually i'd rather you use these X keys for me).
mircea_popescu: which then runs into the obvious problem that i had been chasing all this time : client's R key has to come earlier in the flux. how about the rule that all hello items sent to the server are either a) encrypted to a pre-existing X key or else b) contain a R key ? ie, our helo is not correct as specced.
mircea_popescu: actually, let's make this clearer, it's ambiguous as it stands. C : hello ; S : new account, here are some X keys you can use to decrypt and some X keys you're required to use to encrypt ; C : here's my R key [and here are some X keys i'd prefer to use].
mircea_popescu: this is then the eulora future login handshake : C : hello ; S : new account, here are your keys ; C : here's some keys of mine. they can now continue indefinitely, just as long as nobody loses all the keys.
mircea_popescu: so implementations MUST keep at least a local and a server X key at all times ; doing otherwise is === deleting the account.
mircea_popescu: now, if B wants to update his X.keys with the server, he sends them X'd with one of the existing S keys. meaning, again, that if B manages to lose all S's X keys, it lost the account.
mircea_popescu: if A fails to respond, S will close the connection, practically meaning that A can't claim to be A unless he keeps some X keys about. which is something A-implementers must be aware of.
mircea_popescu: at this juncture, server knows "someone" claiming to be A initiated a connection. it should therefore send X(answer) back, where X uses a key that S knows A should have, on the basis of previous comms.
☟︎ mircea_popescu: diana_coman, this is too fluid to fix in a comment, and i'd rather have it here than in #eulora. so : let's call eucrypt.serpent X and eucrypt.RSA-OAEP R. now, 1. client wants to log in, R(hello) -> S[erver].
mircea_popescu: what, your no-op example is not trivial, but my no-os example is ?
mircea_popescu: ye olde sld-7001 (check me out, meanwhile i found it!)'s os is GP, notwithstanding it won't run your "intelligent" lawnmower.
mircea_popescu: the confounding factor here is pantsuitist outlook, whereby some retard (the user) regards self as meausre of all things and imagines all vectors start from him, and therefore in his boneheaded approach to the world, "general purpose os" means something about him. it fucking doesn't, a general purpose os isn't one joe schcmucktoe can put on a stick and carry around and "it'll work on all computers he encounters".
mircea_popescu: because in the former case, the VARIOUS gposen would still be in fact different from each other.
mircea_popescu: it all comes down to WHAT is the special purpose. mind that the direction the bitcoin node os is taking is towards ~special purpose hardware~. this is very fucking different, whether you have special purpose hardware run by general purpose osen, or whether you have ibm at clone consumershit emulated into republican sanity by usg's flaour of special purpose os.
mircea_popescu: whereas the one user one box tmsr approach sticks with the general purpose os philosophy, and expects spurious color-of-bits considerations to be implemented in the realm in which they belong -- if you want to own the bits own the box, there shall be no legislating here.
mircea_popescu: and perhaps worthy of noting here, that the "trend" "emerging" from usg's own "computer security" roadside act cum flea circus, is towards special-purpose os. because that's what they mean by "security".