11800+ entries in 0.026s
mod6: i feel like this thing is a moving target.
mod6: no hard feelings. i said i could do this pretty easily.
mod6: but if you hvae ~no~ seals, then you can press it sure. the 'flow' will represent these as WILD.
mod6: in either of those two cases, it pukes and stops.
mod6: or if I have bad signatures, then it'll complain as well.
mod6: if i have a bunch of seals in my .seals dir from a guy named 'alf' that isn't in my wot, then V will complain.
mod6: it looks for valid/in-valid signatures to vpatches.
mod6: it iterates over all the vpatches and the like-named seals in the .seals dir.
mod6: it's called 'validate_seals'
mod6: i have a subroutine
mod6: should have been done long ago.
mod6: but i encourage you all to experiment with this.
mod6: anyway, i cna't talk atm
mod6: but it'll still press happily enough.
mod6: if you get rid of one of the seals for one of the vpatches, it'll say "WILD"
mod6: and you only have seals from me for vpatches in your patches directory.
mod6: so... say that im the only guy in your wot.
mod6: no seriously, i should have never been adacious enough to think that I could make that thing work.
mod6: which basically means to me, either no one understands "vtronics" or no one who did ever audited the thing. and i'm clearly not qualified and shouldn't have written the fucking thing int he first place.
☟︎ mod6: you know, i'd like to. but my thing has been around for waaay to long for no one to have noticed a huge flaw.
mod6: I think alf should take his V much further, and mine can fall into dust bin.
☟︎ mod6: I'm pretty sure i am a bozo.
mod6: so like when your key expired, shit puked.
mod6: it doesn't care at signature time if one is WILD or not, only if the vpatch does not ~verify~ and there is a corresponding seal.
mod6: mine ~does~ the check.
mod6: you can't turn off the sig check, at least in mine.
mod6: my v checks the hashes for files pressed, and pukes if not a match from the hashes in the processed vpatch.
mod6: how does WILD have anything to to do with patch?
mod6: i don't have time right now. i'll come back later for this.
mod6: im still not groking what is being said here.
mod6: <+trinque> thing sounds like it needs to be cleaved into vpatch and v which calls vpatch << i'm not sure i follow here...
mod6: I think a flag takes care of this, exactly how alf's original v worked.
mod6: I don't think it is reasonable to sign every thing I want to test.
mod6: So yeah, need to add a flag for this.
mod6: But it never occured to me that the average guy might just drop on of these into patches and never consider what he is doing.
mod6: I press them very often, infact.
mod6: a vpatch without any signature placed into .seals.
mod6: Currently, if a WILD vpatch is in the flow, it will just press it as long as it is based correctly.
mod6: <+asciilifeform> even the current thread in #mod6 , is possibly an example << asciilifeform found an oversight in my latest version of V. it doesn't have a flag allow or disallow the pressing of WILD vpatches.
☟︎☟︎ mod6: !%a trb I "Investigate blackhole" "Investigate what might be occuring with the so-called black-hole, described here: btcbase.org/log/2016-12-20#1586635"
mod6: oh that's not it then asciilifeform? this is helpful, please continue to describe.
mod6: ben_vulpes: aha, gotcha.
mod6: im not sure that is helpful... are you discussing how the client just seems to have no peers after some period of time?
mod6: what is meant by 'blackhole mode' ?
mod6: i think i found it.
mod6: <+mircea_popescu> btw mod6 ben_vulpes trinque re the whole db/fs etc discussion, anyone recall the symlinks method / proposed tests ? << yah, im trying to dig this up now actually.
mod6 is still working on a public/private project-a-tron, making decent progress.
mod6: alright, good enough for the moment.
mod6: !%a trb F "Configure Checkpoints by Configuration File" "Allow for a user to set a given checkpoint within a configuration file. See discussion: btcbase.org/log/2016-12-20#1586436"
mod6: yeah. ok, it merits a ticket in the project.
mod6: lemme see if I can dig that part up too.
mod6: <+mircea_popescu> mod6 that "separate config file" references what i recall as a previous discussion. << aha, now i recall. I think the suggestion was that one could, from a config file, turn checkpoints on or off, or add new ones if they wished.
mod6: also, iirc around the same time there was much ado about the wedge @ 168`001 or whatever it was... but that turned out to be the database locking issue.
mod6: and it kinda continues from there, so worth a bit of a read
mod6: ok here's one part:
mod6: <+mircea_popescu> mod6 got al ink ? << i'll dig it up once im caught up here...
mod6: <+asciilifeform> the one caveat that i can think of is that it may very well turn out to be unusably slow (as in, >10min block verify), on anything but reiser. (if there even.) << would be great to start experimenting with this in '17
mod6: <+mircea_popescu> and so we are back to the original bitcoinfs. << aha
mod6: <+mircea_popescu> ben_vulpes iirc the discussion at the time ended with me pointing out it should be made arbitrary to user's choice. << there was a whole public discussion on this at the time. and at that point, i backed away from it.
mod6: mircea_popescu recalls publishing the correct value somewhere (it's not exactly 21mn "bitcoin", it's a satoshi count.) << iirc was a trilema post
mod6: mircea_popescu: ah. now that's an interesting argument.
mod6: pwalletMain->ScanForWalletTransactions(pindexStart, true);
mod6: my vpatch essentially utilizes this function, which exists in the vpatch that was already sent to the ML:
mod6: i don't love this feature as it introduces complexity and an edge-case that mig-pilot needs to be aware of in the first place. but i'll consider it based on the idea that the complexity can be contained.
mod6: however, this requires further code changes than are actually necessary.
mod6: and, we certainly could scan backwards.
mod6: we've discussed this.
mod6: But certainly a step in the right direction. Will update again as they are available. Salud!
mod6: There are some cosmetic changes I may still make to the handling of the parameters of this function, and further testing, auditing, and validation are still required by third-parties.
mod6: Lemme see if I can dig it up, stand by.
mod6: An update on progress towards the privkey tools feature added [ import private key with scanning from a specified beginHeight ]: I have proven out the edge case previously mentioned, twice, as expected. It can be resolved by doing a -rescan at any time. So far at least.
mod6: i look forward to ben_vulpes's investgation on this.
mod6: And yah, that union is scary.
mod6: (still trying to catch up, as you can see haha)
mod6: and if it is required to be attached to at least one other node, then that may be a problem. We could still test on a lan, but you'd have to have two trb nodes on that lan to get past that line of code.
mod6: lemme dig something up.