180000+ entries in 0.11s
mircea_popescu: i don't want
to grind myself by
the measure of some 9.60 an hour mexicans in a kitchen somewhere.
mircea_popescu: see, because if she is
too slow, i don't just SAY she's
too slow. she fixes it. and if she dun fix it fast enough i got whips
to help along. what's
the gps do ? it doesn't afford you any agency
towards
the pizzeria. yet you're wartching. so what do you do ? you
turn inward, educate ~yourself~.
mircea_popescu: slavegirl
to run kitchen >>> gps
to watch kitchen being run in
mircea_popescu: computer pseudoscience may be
the only engineering discipline in which
the ancient solutions actually are better.
sina: the pizza doesn't even exist, you just say "yo, make pizza" and flour assembles itself into dough,
tomatos become paste, basil grinds itself
mircea_popescu: but, and here's
the beauty, for
the same money
today had salmon.
sina: mircea_popescu: my perspective is
that I am just
trying
to implement what appears
to be an interesting spec. for
the reason of being interested in implementing
that spec. so when I ask for
tmsrthing clarification, it is just in
terms of spec, not in
terms of "making a
thing" ...if
that makes sense
mircea_popescu: sina do you see how
this is an extra cost, not an added benefit ?
sina: the future is not all bad. I order pizza and can see its current progress in
the store and GPS
tells me its location en route
mircea_popescu: sina
the problem with
the non-tmsr
things is
that
they are undependable. in
the complete sense of
that
term :
temporally, functionally, you name it.
sina: does he in an explosion of shit as he sits on
the
toilet?
sina: I mean I *can* go off and do my own
thing, but
then I am making a sinathing not a
tmsrthing
mircea_popescu: it can work, depending, but it doesn't work by itself, it has
to be a very strictly examioned
thing.
mircea_popescu: this is
the root of
the divergence so far, so not a bad reference. encountering a problem, sina
tends
to seek
the "correct" dependency
to bake in.
mircea_popescu: notice how it's not even POSSIBLE for
the "same" message
to be delivered via gossipd. for purely quantic reasons.
sina: ordering/conflict resolution is left up
to
the operator
sina: yeah, per
the spec, peers are only storing messages with local
timestamp
they received
them
sina: oh yeah. I'm actually on holidays from work
this week,
that is why I'm around hassling y'all at all hours
sina: the weather is shit so I am just going
to order a pizza and sit in
the dark
a111: Logged on 2017-06-28 02:04 sina: you can't replay
timestamps outside of a certain window +/- 0.5s or something?
mircea_popescu: the problem with it, once ammended for
the sign issue, was not exactly
technical, more in
terms of how expensiuve it is
Framedragger: sina: point was
to prove continued identity of A, continued ownership of A's private key, so
to speak.
Framedragger: asciilifeform: ah, damn. is
the point
to prove
to B
that A holds A's key at
time
t? i feel dumb
sina: anyway, I guess
this is a seperate question for smarter people, I will just stick
to
trying
to update my
thingo
to match mircea_popescu description above
Framedragger: if incoming message is *not signed*,
then i understand - it sets a fixed horizon in
terms of how much you can spam.
Framedragger: and if
the main work is in checking signature, how does a "could not have practically come into existence before you broadcast S" help with regards
to DoS?
sina: <+asciilifeform> Framedragger: because not signing but decrypting << I am not sure I understand
this. Why is it decrypting? Considering everyone has
the plaintext from broadcasts
Framedragger: asciilifeform: but
the main work by
the receiving peer is in checking
the signature of
the other peer anyway (besides decrypting
the message itself), no?
sina: you can prevent replay by signing a
timestamp and accepting only "current"
timestamp within a window of +/- 0.X seconds?
sina: and send
them at will?
sina: asciilifeform: if
the challenges are being broadcast by
the lighthouse in
the clear, and all
the peers are storing N of
them, can't evilguy X just encrypt all of
them?
sina: oh yeah, while we have you alf, can you answer above? why is lighthouse necessary if A can just sign current
timestamp and B only accept
timestamps within a small variance window?
Framedragger: i'm in fact curious why in your model lighthouse has
to be unpredictable, asciilifeform. maybe it's something very obvious
sina: time for some food and stuffs, I will spend
time later
trying
to implement
this
Framedragger: asciilifeform: i never got
to comandeer one from irc channel, am sad
mircea_popescu: there's a difference between my client showing alf as "online" and my client being built on
the concept of sessions.
mircea_popescu: the idea was
to report
to
the operator, "We have link with x". but conceptually, sessions as a fundamental building block of comms, are not used.
sina: this clarification is much appreciated, I do
think I can rework what I've got
to fit
the above model
sina:
http://trilema.com/2016/gossipd-design-document/ III. Gossipd will receive inbound connectionsvii from identified clientsviii and on
the basis of
that identification produce an encrypted challenge string, which constitutes its response. If
the other party responds with
the proper challenge string,
the connection is established ; otherwise it is dropped.
sina: because
the blogpost has a challenge/response
thingo
mircea_popescu: Framedragger
that is what "forever" means
to machines.
sina: mircea_popescu: ok
that makes sense, you should consider updating
the blogpost :P
Framedragger: mircea_popescu: well you did say "whenever operator feels like it, keys get nuked." (i guess
that's not
the same,
tho)
Framedragger: asciilifeform: ah,
then i confused
things by way of saying
that "challenge-response needs
to be ditched in gossipd model". hmm. i did
think
that
the
two items are not conceptually separable anymore
sina: mircea_popescu: I assume A generated
that reference, and it is storing it until B has responded?
mircea_popescu: sina i imagine it's a keyid of some kind.
that makes a session ?
sina: "a reference allowing it
to respond." << is
that not a session concept?
mircea_popescu: asciilifeform exactly. nmot
that i'm against further exploring
the lighthouse
thing, but gotta be separate item for nao.
mircea_popescu: if
the operator of B opts
to relay, at
t5 various nodes will receive a P.?j
mircea_popescu: if
the operator of B opts
to respond, at
t4 A will receive a P'.Ai
mircea_popescu: at
t3, providing B has opted
to decrypt P.B1, it is in possession of P. if P is a standard message, it contains a reference allowing it
to respond.
mircea_popescu: at
t2, B is free
to decrypt or not decrypt P.B1. it is supposed
to make
this decision on
the basis of B1 and whatever other data it uses
to make such a decision.
sina: mircea_popescu: while I appreciate
the validty of issues about sessions, challenge/response dictates
there must be something akin
to a session, even if
that isn't
the most precisely fitting
term
Framedragger: "Re 119 : You'll have
to properly spec
this if you want it." (you said it!)
Framedragger: mircea_popescu: yeah lighthouse discussion does complicate matters,
the fact of
the matter is, it's
the only current (written) alternative
to DoS-prone
traditional challenge-response (A asks B
to plz send challenge, A
then response
to B with
that challenge), within gossipd universe
mircea_popescu: there's no peer discovery as a gossipd function ; at all
times it knows already all
the peers it will ever know. in lawyer speak
this is called "never ask a question you don't know
the answer
to."
☟︎ mircea_popescu: the only way for A and B
to be introduced, outside of
the grandfatherly, A fucks B and
they exchange bits of paper, is C
tells A about B and B about A.
☟︎ Framedragger: (in fact maybe
that's an important point as well: lighthouse shits at a fixed rate;
there is a discrete amount of auth strings which can be used. i guess
this is obvious, i'm slow)