11600+ entries in 0.031s
mod6: --- a/bitcoin/src/net.cpp false
mod6: if i take this output hash from genesis for say, net.cpp:
mod6: (i played with this for a long time lastnight after that quick conversation)
mod6: asciilifeform: hey, say I wanted to test my toposort...
mod6: yeeep, lot of testing.
mod6: at least, somewhat.
mod6: then once we agree that mine does what is deemed 'correct' others can use the tests to prove their own out.
mod6: this next round of refactoring for this might be some work, but in the end, i aught to write a bunch of these tests into automated ones.
mod6: agreed. we're getting there one bit at a time.
mod6: yeah, if im in the wot too, and I have a valid sig to that one, then it's ok.
mod6: also, as a note, i'll leave the anti-fuzz change in this new version -- it seems ~more~ correct than previous impl.
mod6: not 100% positive, but I seem to recall trying this once. i think my thing broke with a 'cyclic graph!' or something
mod6: fwiw, i believe i've even tested this once by creating a special patch that pointed to an earlier patch in the flow.
mod6: i'll work on something for this. will update at that point. thanks for talking me through it. :]
mod6: correct. now you get an 'a->b->c->d'
mod6: so back to the model: a->b->c->d if I remove 'c', all that should show up in the flow is 'a->b' and all that is pressable is 'a->b', should never attempt to even press 'a->b->d'
mod6: the same flow computation happens in both places.
mod6: it would probably be better form to never have to die, but to never hit that case where we must die.
mod6: i think it should die. when its trying to press and it enounters something that doesn't match: death.
mod6: my v seems to do the correct thing by dying, but maybe showing the entire flow post breakage might be incorrect as well.
mod6: and furthermore, i guess it doesn't make any sense to continue on at all if something is missing in the flow, because even if you could side-step where the breakage is, the vpatch down stream would actually fail to press anyway because its input hash wouldn't match the expected.
mod6: not ~everything~ else.
mod6: but those would be the only two that should drop.
mod6: because there are other routes everywhere else that can follow.
☟︎ mod6: if it were correct, in my mind, i suppose, the flow would be dropping zap_hardcoded_seeds and zap_showmyip_crud.
mod6: if we look at my graph, that really wouldn't be true.
mod6: but this is where it gets hairy.
mod6: or to go back to mr. p.'s example: a->b->c->d all signed by x, if i remove 'c', then the flow should read: a->b
mod6: are you saying, in my flow, in these traces, when i remove a middle vpatch or sig, that it shouldn't show anything in the flow after the breakage even if there are vpatches with valid sigs that correspond to wot entities present?
☟︎ mod6: asciilifeform: im having a hard time following you. let's try to keep this to something i can grok.
mod6: phf's might correct, but his doesn't show all of the edges that mine does.
mod6: anyway, i think my graph is correct.
mod6: that guy has been orphand, he has no parent.
mod6: that's the same as saying : mod6@gentoo ~/sandbox-v $ ./v.pl a asciilifeform_zap_hardcoded_seeds.vpatch
mod6: which says to me, that it was orphand off from dnsseed
mod6: <+asciilifeform> mod6: look here: asciilifeform_zap_hardcoded_seeds.vpatch should have been orphaned in your flow << i think it actually is, quite: when I have the sig for dnsseed moved to duck-fuck-soup, and i check the ante and desc for zap_hardcoded:
http://dpaste.com/2QCN3Y4.txt mod6: mine has another arrow going to dns_thermonyukyoolar_kleansing
mod6: yes, flow is wrong because 'asciilifeform_dnsseed_snipsnip.vpatch' is missing.
mod6: i dunno, lemme try putting in the anti-fuzz thing
mod6: because, mind you, it is ~still~ trying to press asciilifeform_zap_hardcoded_seeds.vpatch, and whatever it shits out from this, if it does not match the expected output hash, will then die yes.
mod6: so you think that if i just use '-F 0' then this problem is hypothetically resolved?
mod6: no worries, fixing this requires some other changes. will go back to drawing board.
mod6: disable fuzz via patch flag?
mod6: and yours doesn't check the output hash.
mod6: well, i suspect that this is a different problem really.
mod6: aha, ok. will do. if i'd venture a guess, we'll see the exact same result.
mod6: yah, so, in this: a->b->c->d ; I basically just got rid of 'c', and then tried to press a->b->d (all signed by x) and it does fail. was this what we were trying to achieve? If not, i'll do another test np.
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'.
mod6: i still have scammer ptsd
mod6: yeah tardstalk was awful. the only redeeming quality there was MPOE-PR.
mod6: some of that OTC stuff was totally insaneo. i remember this one particular day with pirate...
mod6: i totally didn't log anything.
mod6: yeah, im an idiot for not logging everything.
mod6: yeah, i feel like you came in, talked for a few weeks, checked it out... then vanished again for a while. then you were here.
mod6: <+asciilifeform> but how the hell did i wander into #b-a, i still cannot remember. << you were invited to checkout MPEx right?
mod6: for sure. it was unreal. i did like a quadruple take.
mod6: <+mircea_popescu> mod6 remember that time someone put a mega sdice order in and flooded the book ? << Oh yeah, Sir. I'm still doing a O_O from that.
mod6: oh man, this stuff is gold
mod6: wow, the fortunes won, and lost (looking at this old stuff...)
mod6: haha, i think it was ya.
mod6: POP QUIZ: How much was the first MPEx fee after the beta period?
mod6: high-drama in those days.
mod6: <+mircea_popescu> i have jun 2011 - apr 2012 otc logs also, but by now really scraping the bottom. << these would be cool tho
mod6: mircea_popescu: this is a solid point for testing, let me give this a test and see how it goes. will report.
mod6: oh, fwiw, --gen-key --allow-freeform-uid
mod6: "Real name: mod6" "Name must be at least 5 characters long"
mod6: sure, but i'll remain unsigned until testing.
mod6: So I have made a couple small changes to my V99995, and have put together an output trace of what we were seeing with V99995 and what we now see with the changes made in a possible V99994 version. Review of this would be nice to validate that the behavior is correct:
http://www.mod6.net/v-99994-trace.txt mod6: i mean, we could do it that way... where the printable flow tells you which do not have sigs, but then impl-wise, they must be two different lists as to not inadvertantly press out a WILD vpatch. that, or re-check the flow at press time.
mod6: ben_vulpes: i actually love that feature.
mod6: it *can*, but shouldn't be.