232300+ entries in 1.591s
ben_vulpes: just because mircea_popescu didn't complain about
the failure at
the
time doesn't make it right.
☟︎ ben_vulpes: no,
that's death() ing on a patch for which
the system had valid seals, yours and mine.
mod6: read
the link!
that's exactly what it does right now,
this very minute.
ben_vulpes: and yes,
this implies an o(n^2) worst case process in (or (map 'boolean (lambda (sig) (verify 'some_patch.vpatch' sig)))
a111: Logged on 2015-12-21 22:15 mircea_popescu: so /me gives new girl
task
to press v, half hour ago. other
than
the url issue above, "hey what sigs should i put in here ?"
ben_vulpes: i'm pretty sure
the design as described above is correct.
the way i imagined
this working in steady state is for patches and .seals
to accumulate all of
the patches and signatures
thereof a user'd seen over all of history, and
then
the contents of .wot used
to filter
the patches and press used
to pick a head.
mod6: (former lumps from having
this impl before, and
then removing it
to its current state)
mod6: i just feel like we've been here before. like i have some pavalonian response from
this.
☟︎ mod6: it's
totally fine if
that's how we want it.
mod6: i gotta dig
through
the logs now.
mod6: where's
the camera crew?
mod6: what I should do, is ignore
that sig, and continue iterating, collecting up all of
the mod6 .sigs and
then creating a v-tree from just
those alone.
mod6: i could almost swear
that we had a whole discussion on
this before where we wanted it
this way??
mod6: so mine, with only 'mod6' in .wot, calls death() when encountering a sig from a person not included in
the wot.
mod6: so let's back up a minute, cause i'm still
trying
to figure out what I need
to do here...
mircea_popescu: that's ok, i'm just waiting for phf
to say something so i unrate him
mod6: im like, mentally retarded. i need
things spelled out in explicit, literal forms. :]
mod6: if it were obvious, we wouldn't be having
this conversation in
the first place.
mod6: we are seriously way beyond 'noshit'
territory.
mircea_popescu: ben_vulpes> so long as
there is at least one signature for a patch, for which signature v can import a corresponding key, on
the basis of
the wot,
that patch should press. << ftfy.
mircea_popescu: i agree with
the notion .wot is supposed
to be a filter over .seals
ben_vulpes: so long as
there is at least one signature for which v can import a corresponding key,
that patch should press.
mod6: ok. see maybe
there was something
there
that I didn't pick up on. :/
mod6: fwiw, and
this may not be
the correct way, but i
think i just
tried
to clone alf's.
mod6: not
that it's correct, just for example of "where are we at?"
mircea_popescu: ben_vulpes i don't even want
to open
that discussion, it's fucking obvious
they're equivalent but whatevers.
mircea_popescu: mod6 in practice you'd just keep .seals_mp .seals_all .seals_alfmod6 etc and move
them around
ben_vulpes: asciilifeform:
to be fair, .wot, .seals and patches apparently constitutes 'hidden state'
today.
mod6: so
today, with my impl, you'd have
to at minimum, get rid of 3999 sigs from .seals. you could also, if you wanted
to, get rid of 68 pub keys in your .wot. iirc,
that part isn't required
tho.
mircea_popescu: mod6
the idea is
that you should be able
to alter
the end product by altering .wot rather
than by altering .wot AND .patch or .seal
a111: Logged on 2016-12-22 00:52 mircea_popescu:
the key being,
that if you allow pressing without signatures,
then git qualifies as a v implementation.
mod6: aside from
the fact
that I might have 69 people in my .wot, and 4000 sigs in my .seals dir.
mod6: and in
the context of
trb, I would end up with, currently, just genesis.vpatch pressed out in 'output_press_dir'
mod6: so what you're saying... is
that i should be able
to say "v press output_press_dir SOME_HEAD mircea_popescu"
trinque: as an aside, an environment where "man makes own necessities" out of still simpler
tools he can combine as he likes, strikes me as ideal.
mircea_popescu: whereas if you allow dieing in arbitrary condition,
then whatever, you get a more restrictive v
than other people.
mircea_popescu: the key being,
that if you allow pressing without signatures,
then git qualifies as a v implementation.
☟︎ mod6: this is fair, and i agree. i do want it
to work
the way it it should work. not
the way it does work if
those are disjointed. no way
to get
there, except
through
these kinds of investigations.
mircea_popescu: that it eschews key checks is one
thing ;
that it dies on which condition is apparently a different
thing.
mircea_popescu: such as in "what classes of objections can or can't be brought
to a v implementation"
mircea_popescu: mod6 no,
the discussion is actually very productive in
that it actually helps specify exactly what v is.
mircea_popescu: asciilifeform yes ; methodological objections are really of
those
three pillars. like "use ascii" or "the signatures are given
TO BE USED" etc.
mod6: i want it
to work
the way
that it is supposed
to work.
mod6: and not
that it shoudn't anyway,
there are some
things about my implementation
that i do not appreciate looking back on it.
mod6: i gather,
to implement what is sort of discussed here, will
take quite an overhaul
mod6: i suspect
that it isn't written
that way.
mircea_popescu: well he can run his v any way he pleases ; but yes it should prolly just drop
the bad patch and move on
mod6: but if you get rid of everyone else's sigs from .seals,
then it's fine and you can happily do 'mod6'
tree.
mod6: ok so yah. if you only have 'mod6' in your wot, and you leave ~all~ of
the sigs (from alf, mp,
trinque, bc) in your .seals dir,
then we
throw an error and die.
mircea_popescu: it should probably stop if it finds valid patch
that can't be applied (mismatched hashes) - because by
then your state is broken.
mod6: <+asciilifeform> mod6: you ought
to be able
to press variant-wots (say, mod6-only) without having
to also remove patches mod6 did not sign from patches dir << now
this.
mircea_popescu: mod6 if it simply skips over
the patches it can't find acceptable sigs for, it delivers asciilifeform 's
thing above where you don't have
to keep fucking around with
the patch set.
mod6: we don't not allow
the oppertunity
to continue without a signature on a vpatch.
mod6: i
think it's fine. you make a
testkey, you sign your
test vpatches, you press &
test, etc.
then we're using encryption everywhere. and we fail fast.
mod6: <+mircea_popescu>
there shouldn't be any flag - nor should it press unsigned
things. && <+mircea_popescu> with
the
test key ? why not ? fucks with your workflow ?
mod6: <+mircea_popescu> im not sure it has
to die when it encounters malformed patch (be it not signed or whatever), but anyway. << i was
thinking
this was simple because of
this:
a111: Logged on 2016-12-22 00:03 mod6: Essentially, during
the verify_signatures subroutine, if a vpatch is found
to NOT have a corresponding signature, death().
mod6: <+asciilifeform>
http://btcbase.org/log/2016-12-22#1587685 <<
the simplest way
to implement
this is
to iterate over
the ~seals~, finding corresponding patches << <+mircea_popescu> not particularily correct ; should iterate over patches, check sealness ; act accordingly. << 'validate_seals' does
this; iterates over patches, finds seals for patch, verifies or fails if bad ;; now dies if
there are none.
☝︎ mircea_popescu: well when we finally have better-pg, we may do different
things, but really...
mircea_popescu: the disadvantage of being clever is
that one will be surprised.
mircea_popescu: for every patch, check if patch sig by approved names is present.
this isn't any sort of N^2 ; it's O(N*M) where N is
the count of patches and M
the count of approved signers.
mircea_popescu: no
they won't ; partly because we won't be doing anything idiotic like "giving random names
to seals".
a111: Logged on 2016-01-18 15:35 ascii_butugychag: jurov:
theoretically you can avoid using
the name prior
to .sig, but
then you have
to check ALL seals agains ALL patches ALWAYS and
this is O(N^2)
mircea_popescu: im not sure it has
to die when it encounters malformed patch (be it not signed or whatever), but anyway.
a111: Logged on 2016-12-22 00:03 mod6: Essentially, during
the verify_signatures subroutine, if a vpatch is found
to NOT have a corresponding signature, death().
BingoBoingo so far happy with end of
the year lulz acceleration following slow early december
mircea_popescu: asciilifeform his reasoning is fucking broken ; same
time means nothing, if he found difference it might've meant something
a111: Logged on 2016-12-22 00:01 mircea_popescu:
http://btcbase.org/log/2016-12-21#1587625 << you gotta appreciate scrutiny is very inelastic. many people used
their own implementations ; discussion of others' versions only meaningfully starts after some localized familiarity etc. in any case "being qualified
to even use v" is an iffy
thing - seeing how it's a novel design, and
the novelty is fundamental and conceptual, nobody is
technically qualified
to use one. you wouldn