log☇︎
1900+ entries in 0.193s
ben_vulpes: http://btcbase.org/log/2016-12-28#1591573 << the diff line is distinct from the --- / +++ lines, does one ever see a patch file where the files compared aren't prefixed with a/ or b/ ? ☝︎☟︎
mircea_popescu: no patch can be elevated to the status of genesis ; if it is a genesis of something it knows this, and the way it knows this is through the antecedent being false
phf: i don't mean that the patch is called "genesis", i mean that the concept is called genesis, so there's no need for new nomenclature like "true root"
mod6: the reason, I'm finding, that my previous patch still listed a->b->d in the flow, is because 'd' got picked up as a root. and the reason it does is because at this point, it has no antecedents.
mircea_popescu: ben_vulpes if you patch it lemme know.
asciilifeform: mircea_popescu: not related, same eggog whenever you're missing a patch
asciilifeform: this is pure martian-level surreality: gnat-gcc-...[crapola].patch doesn't exist. but no package takes ownership of it.
asciilifeform: * ( gnat-gcc-4.9.3-make-default-paths-match-slot.patch )
asciilifeform: * /usr/portage/dev-lang/gnat-gcc/files/gnat-gcc-4.9.3-make-default-paths-match-slot.patch
deedbot: http://cascadianhacker.com/veh-patch-hashes_and_errorsvpatch << CH - veh patch: hashes_and_errors.vpatch
a111: Logged on 2016-12-26 02:38 phf: ben_vulpes: according to master this is the reason http://glyf.org/tmp/ironclad-sha512.patch unsigned for obvious reasons
ben_vulpes: phf linked the patch, he fixed it
ben_vulpes: plan then is to grind this patch for my v out shelling out to sha512sum
phf: ben_vulpes: according to master this is the reason http://glyf.org/tmp/ironclad-sha512.patch unsigned for obvious reasons ☟︎
mircea_popescu: now, there's entirely nothing "promisetronic" about people providing seals named as their patches are named. if they fail to do this - their patch won't work.
mircea_popescu: anyway, the idea is maximum power for the user. a scheme whereby i am forced to check all seals for each patch dispowers me ; a system whereby i can always resolve each patch in at least 1 checks or however many i feel like doing empowers me.
ben_vulpes: the naive o(n^2) calculation is to say "there is a signature for this patch" and not giving a shit about which signature, provided it corresponds to a key in .wot .
ben_vulpes: also that mothers know which baby is theirs and a signature can't tell me which patch it belongs to
mircea_popescu: i dunno how either the current method adds complexity (show this ?) or the alternative isn't rank insanity. why should i have to look at >1 seal to verify a patch ?
ben_vulpes: it costs in complexity, yes. could be argued that it is a very minimal cost, but i would still prefer to "pick any signature from .seals that verifies" instead of the by my read promisetronic "pick any signature whose filename contains the filename of the patch under verification"
ben_vulpes: mircea_popescu: only patch's fuzzy application, nothing more.
ben_vulpes: asciilifeform: i'm happy to implement post-patch hash checks
ben_vulpes: asciilifeform, mod6: subject of "making things 1000x more complex" i embarked on handling various conditions a v might encounter (missing pubkey, unsigned patch, mismatched hashes after a press...) and i daresay the volume of code must increase!
mircea_popescu: huh ? i can just make a new patch off genesis.
mircea_popescu: much like currently mod6's latest, the makefiles patch. takes 'mod6_der_high_low_s' , 'malleus_mikehearnificarum', and 'asciilifeform_maxint_locks_corrected' .
mircea_popescu: maybe we're not talking of the same thing, but isn't the very patch in question, with its 3 references, a converger ?
a111: Logged on 2016-12-23 19:26 mircea_popescu: there's multiple approaches available. a) each patch nails down the whole list of direct antecedents, so it'd be 3 in this case ; b) each patch signer picks an arbitrary antecedent to reference of the list (of here - 3), others are free to "fork" it by picking a different one or w/e.
asciilifeform: mircea_popescu: if your branches cannot converge (and under your algo, they cannot, because path dependence ~everywhere~) your tree gets cancer, every single patch creates a wholly separate universe that can never touch others.
mircea_popescu: there's multiple approaches available. a) each patch nails down the whole list of direct antecedents, so it'd be 3 in this case ; b) each patch signer picks an arbitrary antecedent to reference of the list (of here - 3), others are free to "fork" it by picking a different one or w/e. ☟︎
asciilifeform: if each patch nails down an explicit 'and on top of THIS' press sequence, it drags the entire universe behind it, all of a sudden there is no such thing as 'sibling', i.e. a thing that goes from same ancestor to a different but nonconflicting place.
asciilifeform: (this is a difficult process because we have multiple 'patchons' inside a patch..)
asciilifeform: take mod6's latest, the makefiles patch.
mircea_popescu: adding the hash of the antecedent to the actual file makes that hash part of the diff of the actual file, which makes it part of the hash of the patch (ie, diff of files).
mircea_popescu: dude. adding it in the actual file makes it part of the diff of the patch which makes it part of the hash.
asciilifeform: of the patch..?
mircea_popescu: now, because of a naive "repetition creates cycles" and "index=text content" joint assumption, you automatically imagine that two people signing the same (text+context) pair would create a cycle. not anymore - the situation neatly reduces to "two people sign the same patch", ie, having multiple seals for the same patch.
asciilifeform: mircea_popescu takes the patch, writes it in corpses of usg soldiers in the desert, photographers come, it is printed in every paper in the world; now -- ordered.
mircea_popescu: except woe, you can't make it because someone already made a patch for this block and you aren't going to see another block without a patch.
mircea_popescu: the stoppage may require a patch
mircea_popescu: asciilifeform if you mean that you and i both sign the same patch text in the same tree context, the result here has been the very common, and very benign, MULTIPLE SEALS. which we currently have.
asciilifeform: i.e. identical patch.
asciilifeform: +#Patch for 53fedeea28a5b6608b422f90f8c28e97c4604d6da5c18b8167b10c994166d8f0b47cd07bca8a6e4e53b6a961bef75f494c70e97437b7afd2d69c4110d7c06575
asciilifeform: -#Patch for genesis.
asciilifeform: it does not in point of fact have a unique 'last patch applied', because there is no way to prevent two people who do not know about one another from both writing :
mircea_popescu: well, do we actually want this ? it doesn't seem to make sense ; in the sense that when you write the patch in question, you write it atop a specified code ; which is the result of a press ; which has a "last patch applied" necessarily. so that one should be the "antecedent" properly speaking.
asciilifeform: for starters, a patch can antecedentize 10,001 other patches.
mircea_popescu: it's a fixed word. you could have it #Patch for false
asciilifeform: what does the string 'Patch for genesis' do in mircea_popescu's paste example ?
mircea_popescu: but yes, in the last instance, it's to demand that "same patch" can only mean, "same text" + "applied in same place".
mircea_popescu: well in fact, to demand that hashes cover the patch and its context, not merely the patch.
mircea_popescu: you propose we both write the same code on the same patch ? then yes, they come out the same. this is fine.
mircea_popescu: look : your patch will be sha512(#Patch bfffhlerghhl\nalf's words\n) and my patch will be sha512(#Patch bfffhlerghhl\nmp's words\n)
asciilifeform: we at the same time write '#Patch bfffhlerghhl' for our gensyms.
asciilifeform: say i sit down to write a patch.
mircea_popescu: nono, just previous patch hash. whenever you sit down to write a patch, you sit down to write it atop a press, or at any rate the situation resulting from a press. that has a "last item pressed" by necessity, and THAT will be your header.
asciilifeform: mircea_popescu's solution, if i understand it, is to include a gensym in each patch body.
asciilifeform: you can ban it, as shown above in mircea_popescu's paste, by demanding that no new patch produce the antecedent of an old one.
mircea_popescu: asciilifeform i specifically want a cycle (n >1) where one element traces back to genesis. it seems to me that because one patch can only identify one antecedent, it is not possible to create cycles for the ~same reason organic chemistry doesn't work on hydrogen and oxygen only.
asciilifeform: mircea_popescu: because dr.mengele makes a patch that ~produces~ the genesis, thinking he is oh so clever
asciilifeform: any patch in that loop is pressable without spinning in circle forever.
asciilifeform: it'll need a 1-patch-at-a-time hopper.
asciilifeform: with 1-patch-per-block, there can be no ambiguity as to who is responsible for closing a cycle.
asciilifeform: not if 1 patch per blocktime.
asciilifeform: this also would give mircea_popescu the thing he asked for, which was a litmus that'd let him reject a cycle-creating patch immediately from his light cone, before it can get into his vtron and cause headache. and that is, 'no patch may have a descendant that is also an antecedent of itself or of an earlier-blocktimed patch.'
asciilifeform: so my cyclic(T)==false, cyclic(T+1)==true, culprit is the signator(s) of the patch closing the loop, worx great, when this condition is adhered to
asciilifeform: the signator(s) of that patch is the culprit.
asciilifeform: at T+1 (after one patch) -- there is.
mircea_popescu: if all patches are required to change a comment line in all files they touch, so that it contains the hash of that patch's intended antecessor ; then it is no longer possible to build cycles without deliberately hash-mining for them (because to close the cycle you will have to at one point claim as anterior an ulterior item).
asciilifeform: vpatches are not applied 'onto a patch'
asciilifeform: mircea_popescu: there isn't a 'the patch'
mircea_popescu: suppose we had a rule stating that "all patches must include as a comment the patch upon they are to be applied" ? ☟︎
asciilifeform: http://btcbase.org/log/2016-12-23#1589083 << the shortest cycle possible in v (assuming that all of the patches are valid, that is, actually produce the hashes they indicate as descendants, as outputted by gnudiff, as opposed to a hand-sewn crapolade which does not) is a->b->a. this happens if you have a patch 'c' that has 'b' as antecedent but 'a' as descendant. ☝︎
a111: Logged on 2016-12-23 02:19 mircea_popescu: mod6 i read through http://www.mod6.net/v-99994-trace.txt and indeed it seems right and proper vtronics. one q though : was there any patch not signed by asciilifeform interspersed in the flow ? because that's the only not tested case i think, if you have say a->b->c->d where a, c and d are signed by x. does it stop at a ?
asciilifeform: i will rephrase again for clarity: for so long as you have 1 pubkey, which was used to make 1 seal, and that seal is for one, single patch, your only one, a genesis, you can display a flow. and literally every other file in .seals, .wot, .patches can be a lolcat.
mod6: fwiw, i believe i've even tested this once by creating a special patch that pointed to an earlier patch in the flow.
asciilifeform: it is less hairy if you use my algo, where every single patch, when deciding if it gets into the flow, has to trace descent to a genesis, unbrokenly
asciilifeform: a vtron that displays descendants for a patch that has an antecedent hash that corresponds to no patch, or does the same for any of its apparent children, is incorrect
asciilifeform: mod6: think for a minute: an orhpaned patch has no descendants.
asciilifeform: patch for whom antecedent does not exist, gets ignored
asciilifeform: or patch would not have tried to fuzz at all
asciilifeform: i am still waiting for something like a logical argument for why patch fuzz existed.
asciilifeform: fuzz is this horror where gnu patch tries to hammer square stick into round hole by default
mod6: disable fuzz via patch flag?
asciilifeform: correct, it did not, it instead invoked patch with zero fuzz
asciilifeform: look at how my vtron invoked 'patch'
mod6: <+mircea_popescu> mod6 why's the hash mismatching ? << upon checking the output hash from the pressing of asciilifeform_zap_hardcoded_seeds.vpatch, it failed. because this patch depends on asciilifeform_dnsseed_snipsnip.vpatch which was not in the flow, because it was renamed 'duck-fuck-soup.vpatch'.
mircea_popescu: mod6 i read through http://www.mod6.net/v-99994-trace.txt and indeed it seems right and proper vtronics. one q though : was there any patch not signed by asciilifeform interspersed in the flow ? because that's the only not tested case i think, if you have say a->b->c->d where a, c and d are signed by x. does it stop at a ? ☟︎
ben_vulpes: rebase/regrind to move the patch in the tree and seal to...seal.
mircea_popescu: reseal = the act of signing a patch with your own key.
a111: Logged on 2016-12-22 18:49 mircea_popescu: you ~can~ after all rebase a patch ; not just because of the patch, but also because of the sig.
ben_vulpes: http://btcbase.org/log/2016-12-22#1588519 << 'rebase' in my mind entails changing vpatch to have new hashes, or some other mutation. just transmitting a new sig does not change where a patch might lie in the tree. ☝︎
mircea_popescu: you can literally come up with an idea for a thing while travelling ; go to internet cafe ; spin up gpg to make you a new key while you bash it down ; then sign the patch with that key which you don't even bother taking from there.
mircea_popescu: can release patch today under your text sig ; rebase it later with your main sig.
mircea_popescu: you ~can~ after all rebase a patch ; not just because of the patch, but also because of the sig. ☟︎
asciilifeform: phf: i stabbed at the problem of formalizing a way to specify what it is you actually commit to when signing a patch. it was the 'vectorized' thing, and everybody barfed.
a111: Logged on 2016-02-20 22:45 phf: "i, ordained computron mircea lifeform, in the year of our republic 1932, having devoted three months to the verification of checksums, with my heart pure and my press clean, sit down to transcribe vee patch ascii_limits_hack, signed by the illustrious asciilifeform, mircea_popescu, ben_vulpes and all saints."
ben_vulpes: i expect it to be a royal pain to run down "which patch is missing sigs and breaking the flow from genesis to whatever"
ben_vulpes: provided the implementation fails if any patch in the flow has *no* signatures from keys in .wot, that sounds right.
asciilifeform: a seal, on the other hand, floating about without an active pubkey, for for that matter without a corresponding patch, is inert.
asciilifeform: trinque: a patch, so long as there exists 1 seal for it, and that seal corresponds to a key in your active wot -- is valid.