BingoBoingo: The national rolling pigeon club is a few blocks away. Could see if those would work
mod6: can we get a squad of these seals to blockade runners for us:?
asciilifeform: and i'ma never recommend to anyone the use of heathen 'rsa chips'. not even because they all, without exception, work with only 'toy' key lengths, but because srsly wtf.
BingoBoingo: Mocky: I have the local news playing in the background. But they are talking about these guys. https://archive.is/RRHQ Mind the publication date and remember this country was Lego free until that awful movie came out.
asciilifeform: Mocky: in the past i attempted a fpga rsa also. sadly the 'ice40' would need to be about 250x bigger, for it to be bakeable
asciilifeform: Mocky: the constant in that O(1) unfortunately matters.
asciilifeform: Mocky: in theory you already have rsa with Ch. 4 . but nowhere near line speed.
BingoBoingo: In other news Japanese robot seals (the ones for keeping the elderly company) have made it to Uruguay
asciilifeform: ( on sw , the sun ddoses you 24/7/365, as well as washington )
asciilifeform: BingoBoingo: very diff set of problems, there
asciilifeform: BingoBoingo: whole reason ddos even exists as a concept is the short-sighted idjicy of arpa designers. i'd like to avoid repeating it.
asciilifeform: BingoBoingo: they're still pestilential
BingoBoingo: <Mocky> old log threads appear to have mircea_popescu with hatred of UDP, which has meanwhile dissipated ? << There was a period when reddit hadn't yet given up on marginalizing the Republic and DDoS's were pestilential.
asciilifeform: fragola makes this impossible in principle, you gotta stow N frags to get any sense of whether the full packet is friend or foe
asciilifeform: the only final solution to ddos is O(1) crapolade packet rejection. ( preferably in iron )
asciilifeform: Mocky: incidentally, it is possible to do what i suggested to him then, which is to change the protocol # in the ip header and be generic ip, rather than udp . but only once we have own ip stack.
asciilifeform: the ip stack's frag/reasm is one of those things that 'worx until it doesnt'
asciilifeform: imho if you want large messages, oughta have own fragger/reasmer, not the ??? in linux/ciscolade
asciilifeform: Mocky: me neither, esp. given as it wins nuffin bandwidth-wise
Mocky: I don't see the benefit of building in a reliance on an external UDP fragment reassembly mechanism when the algo is 'all or nothing'.
asciilifeform: i for one would rather have no frag reassembly at all if writing ip stack. not only b/c complexity but also this.
asciilifeform: which not only complicates ip stack ( for when we write one ) but opens up to ddosability ( frags are take-it-or-leave-it, they dun even carry the port # )
asciilifeform: even if seems that 100% of 2/3-frag packets make it through in 'laboratory' conditions, still gotta remember that the frag reassembly buffer is the ~exact~ equivalent of the pre-trb 'block orphanage'
asciilifeform: re : udpism : at the risk of rehashing some of the ancient gossipd thread, i'ma put a few notes re fragging :
mod6: mmm, i wanna throw some ribs in the smoker.
mats: BingoBoingo: 2019 is year of the pig
diana_coman: asciilifeform, what's the shortest delay you tried?
BingoBoingo: In other news, the morning news program "Buen Dia Uruguay" has a fat wrinkly bag on right now reading Tarot cards and making predictions for 2019
a111: Logged on 2018-09-28 06:24 diana_coman: asciilifeform's published test data seems to match what I got on my initial tests with 1 second delay; my current plan is to collect first at least 1 week worth of data and then to repeat the experiment with a. smaller delays b. several senders perhaps
a111: Logged on 2018-09-28 00:54 mircea_popescu: just makew sure you put something in there to distinguish "my interface is shitdrops on the floor"
a111: Logged on 2018-09-28 00:58 mircea_popescu: but yes -- the test can (and likely will) be tightened. for starters we just wanted to get a sort of "absolute path limits". and THESE do indeed turn out to be further out than originally thought -- 2kb packets make it np unfragged and in order 100% of the time, and even 20-60kb packets made it.
asciilifeform: http://btcbase.org/log/2018-09-28#1855188 << nitpick: >1500byte always fragged, cuz ethernet. but! apparently get sewn back together in time. at least at the currently tried rates, and with mix of sizes ( remains to be seen what receiver will do with a summed MB/s of frags from different people )
diana_coman: asciilifeform's published test data seems to match what I got on my initial tests with 1 second delay; my current plan is to collect first at least 1 week worth of data and then to repeat the experiment with a. smaller delays b. several senders perhaps
diana_coman: also, note that eulora does not enforce "all players within sight get position update" because server does not push basically; it's up to clients to request what they want, when and if they want it
mircea_popescu: there's also no intention to reproduce the usual http://trilema.com/2016/the-eastern-rpg/ bs. there's not going to be a "central town" everyone HAS to go to because of the linear&automated questline.
mircea_popescu: however, the position is not 20 byte. idea is for eulora to make do with ~6.
mircea_popescu: there is that.
Mocky: there are clever ways to reduce, somewhat. but no silver bullet
Mocky: http://btcbase.org/log/2018-09-28#1855218 >> players in sight of each other, all getting position updates for all others is *THE* central scaling 'n squared problem' for mmo. 20 byte position sent 4 times per second to 100 players is 8k/s per player. and 4 updates per second is really not enough for good playability when you factor in the round trip lag. 15/s is less draconian (many games send 30-60). 100 players gathered with 15 updates
a111: Logged on 2018-09-27 19:17 BingoBoingo: asciilifeform: I have returned from the envirorast office, about to fire off a message to DHL informing them to try again as I am a provisionally acredited importer of packaged goods for commercial use
mircea_popescu: http://btcbase.org/log/2018-09-27#1855070 << this guy. getting him out of the flophouse was the best move ever.
asciilifeform: mircea_popescu: it not only made for very picturesque output in old buggy vtrons, but pretty terrible for blood pressure, as turned out that the supposed 'disable fuzzy' flags dun actually do anyffin in gnupatch
a111: Logged on 2018-09-27 17:54 asciilifeform: phf: imho your approach , i.e. dispensing with gnupatch, is The Right Thing, historically there was quite a bit of grief from gnupatch's habit of eagerly attempting to apply an invalid (by vtronic lights) but 'partially ok' by barbarian lights patch
a111: Logged on 2018-09-27 17:27 phf: trinque: vtools has not been design or intended to compete with any particular v implementation. it's a set of tools that you can use in a v workflow (hence the name). at least initially it was two matching tools vdiff and vpatch that know how to produce and consume a canonical vpatch. the conflation came up, because i also published vtools in a form that broke existing canonical v, v.pl, and was tasked with fixing the situation.
mircea_popescu: we don't do shit for any other reason than because "alternatives were reviewed, this came out".
mircea_popescu: well... the republic is organically grown.
a111: Logged on 2018-09-27 16:08 asciilifeform: imho the situation where 'errybody made own hack' but no one posted 'because obvious' is a barbarism, really ought to have a civilized 'here is the whole thing' sitting on www somewhere.
mircea_popescu: http://btcbase.org/log/2018-09-27#1855041 << this is so, "here's a complete model" is a periodic necessity. just you know, can't complain that "not there jit when i wanted it". but yes in general, ur examples must be had, fully functional model trains must exist, etc. otherwise how to even run academia.
mircea_popescu: dunno how many people keep that around though. i don't think it'd be a crime or anything to make a command-line keccak branch off of it, so people can just press to that if they want.
mircea_popescu: re stand-alone hasher : useful in general (for reason alf describes) even if not strictly needed for v work ; the only way to get one i know of atm is via eucrypt.
a111: Logged on 2018-09-27 16:02 phf: you can basically do (cat foo.vpatch bar.vpatch qux.vpatch) | vpatch and expect the resulting press to be fully valid, hashes and all
a111: Logged on 2018-09-27 09:34 diana_coman: http://barksinthewind.com/2018/vtools-keccak-regrind/ -> gotta ask here, phf, am I missing something or what Wednesday was that there in the first line meant to be?
mircea_popescu: http://btcbase.org/log/2018-09-27#1855025 << actually this is exactly >> http://btcbase.org/log/2018-09-27#1854931 ; i saw it there then, i checked it off in my head and did not return, that or any other wednesday, to check. turns out, it got dropped. don't do that!
asciilifeform: any an' all of the 'soft' hacks
asciilifeform: THEN stopped when 'winmodem' soundcards.
mircea_popescu: http://btcbase.org/log/2018-09-27#1855023 << moreover, i can't imagine who the fuck would make this call ~for others~. you don't like having it, by all means, http://btcbase.org/log/2018-09-26#1854751 ; but i am not going to say "do not use v.pl".
mircea_popescu: good thing linux has code of shithead.
asciilifeform: i dun know the specific answer. but suspect it has to do with the sad audio mixer on most os. they wanna hear the game sounds + the chat.
mircea_popescu: asciilifeform through whatever they like. it's their fucking friends, neh ? sometimes gaming i'll speak acrossd table / yell across room w/e. my fucking harem, my fucking business.
mircea_popescu: kinda weird for a restaurant to also attempt to provide phone service for the patrons. what, they can't carry phones inside ?
mircea_popescu: i don't see why they can't do this -- independently.
asciilifeform never saw the appeal
asciilifeform: i meant those mud folx who have microphones in the game
mircea_popescu: even if you do voices, client should acquire the asset and cache it.
mircea_popescu: not including here asset transfers ; merely the "bread and butter" so to speak.
asciilifeform: mircea_popescu: then yer golden, loox like. at least if errybody has a path no worse than mine
mircea_popescu: moreover, 1kb/s is one thing, 100kb/s ANOTHER thing.
mod6: thats still 2 orders faster than the last test tho.
mircea_popescu: truth be told, on the internet-as-we-thought-it-was, video on demand'd have been a miracle.
mircea_popescu: apparently some parts of the internet DID get better over time.
asciilifeform: about to post the 10ms variant ( 3 shots )..
mircea_popescu: ie, the 508 value largely mythical at this point.
mircea_popescu: (and when didn't made it -- local interface dropping was the likely culprit)
mircea_popescu: but yes -- the test can (and likely will) be tightened. for starters we just wanted to get a sort of "absolute path limits". and THESE do indeed turn out to be further out than originally thought -- 2kb packets make it np unfragged and in order 100% of the time, and even 20-60kb packets made it.
asciilifeform: thus far they all show up on my exit router, fwiw
mircea_popescu: in the worst case, capture the flow upstream and see if the box actually puts out the packets ?
mircea_popescu: early proto-test indicated most of the lossage happens before 2nd hop
mircea_popescu: just makew sure you put something in there to distinguish "my interface is shitdrops on the floor"
mircea_popescu: and diana_coman or hanbot or who will you pick have little problem in turning over next-day keccak patches on trees, as recently put on display. i don't think they're either smarter or blesseder than you, they just have the toolset ready.
asciilifeform: ( afaik 1sec is way moar than long enuff for a packet to either make it, or vanish )
asciilifeform: upstack, re the udp experiment -- 1/sec is sorta 'cheating', no possibility of reorders
mircea_popescu: so then. phf did a new ~vdiff~. and a very good one at that, from all i can see.
asciilifeform: mircea_popescu: so far only tried the -->
mircea_popescu: restaurant served me complete pie, but body shop did only paint the preexisting car i supplied them with.
mircea_popescu: yes there's nothing wrong with people publishing toolsets ; but this can't become a fucking expectations wth. craftsman -- has toolset.
mircea_popescu: that alf manages to do this naturally and with i suspect no malice aforethought (or anything else aforethought at all) is in a sense supportive of the hopes of humanity -- apparently ignorance breeds the nonsense on its own, no "dark lizard" behind it all needed.
mircea_popescu: but yes, the obnoxious part about the ignorant approach is that it purports to "identify as problems" the speciffic parts that are both well designed and functioning as designed, ie specifically the hash transition.
a111: Logged on 2018-09-19 15:56 asciilifeform: mod6: i dun like to discourage folx, esp. mircea_popescu's pupil, who is evidently pouring sweat into the job. but i expected the items would get better with time, and imho so far they haven't
mircea_popescu: sadly there's no simple/just-add-water way out of "i've been ignoring this whole thing for x interval, wut nao". nao -- pick up from where you left off, what.
a111: Logged on 2018-09-27 19:52 mircea_popescu: http://btcbase.org/log/2018-09-27#1854952 << what you apparently did was completely ignore the matter for five months, then discover like children that you actually need tools at the time you started on the task (late at night etc) and so forth.
asciilifeform: 'Note that the sender will send each size of package *only once* and it will simply finish once it sent one package of each size' << aaah
a111: Logged on 2018-09-27 15:36 phf: asciilifeform: but if you want a full "v replacement and i don't want to think about none of that" then just use esthlos's item. i believe he has a working keccak already
mircea_popescu: http://btcbase.org/log/2018-09-27#1854994 << just about, yes. and yeah, the summary's correct.
asciilifeform: diana_coman's test jig ( i did not modify it except for the dest ip ) currently fires 1 / sec.
asciilifeform: going by the current empirical test, however, a packet that frags into 2 or even 3, typically goes. tho it remains to be seen whether they start falling down once you saturate.
asciilifeform: tho as i understand it, they did not account for the 8 byte udp header size, and thereby still fragged.
asciilifeform: admittedly this was in the paleolithic '90s
asciilifeform discussed subj with asciilifeform's brother, who answered 'whaddayamean, what size packet, at $defunctgamesco we only ever used 1480, for decade, ideal'
asciilifeform: will leave it overnight , then post log..
BingoBoingo: For the longs: Peso Argentino went from 0.85/1.45 to 0.55/1.25 in one month.
a111: Logged on 2018-09-27 21:02 mircea_popescu: http://btcbase.org/log/2018-09-27#1855089 << i have no fucking idea how. i read the logs daily atm, mostly impelled by... outright fear. the best heuristic i know of, but otherwise this promises to be a first caliber bane as time goes by.
a111: Logged on 2018-09-27 20:58 mircea_popescu: more's the point : HOW do we establush "100is much, 10k is enough, etc"
asciilifeform: http://btcbase.org/log/2018-09-27#1855107 << the proggy author's duty, and nobody can save him from it. fwiw i go roughly by size/complexity of orig draft.
asciilifeform: ( pretty thinly disguised attempt to get the dumber miners to 'upgrade' )
asciilifeform: http://btcbase.org/log/2018-09-27#1855104 >> bahahaha, and the disinfo machine already spinning at full speed, e.g. 'Everything older than 0.16.3 (and the corresponding 0.14 and 0.15 fix releases) is vulnerable to one exploit or another' etc
a111: Logged on 2018-09-27 20:21 asciilifeform: http://btcbase.org/log/2018-09-27#1855078 << trickier item. recall 'the song of the sirens, some have escaped, but their silence -- no one' . how to deal with 'but ~was~ it in the l0gz'.
mircea_popescu: http://btcbase.org/log/2018-09-27#1855089 << i have no fucking idea how. i read the logs daily atm, mostly impelled by... outright fear. the best heuristic i know of, but otherwise this promises to be a first caliber bane as time goes by.
mircea_popescu: more's the point : HOW do we establush "100is much, 10k is enough, etc"
mircea_popescu: asciilifeform no, i understand the principle, just... nothing, not even mozilla went through 10k versions to date.
diana_coman: it's the move to generic + relaxation of some constraints (because of generic and because of using Calendar for local time to log)
diana_coman: but otherwise the udp_tester.vpatch makes some changes to udp lib that are really just for testing (i.e. I think they should not be part of production use of udp lib)
diana_coman: the rest then are for the tester only - let me know if you give it a spin and how it behaves
diana_coman: asciilifeform, ^ there is also a small .vpatch for that issue with null chars at ip
asciilifeform: elsewhere, else, http://trilema.com/2018/fetlife-the-next-derperation/#comment-126772
asciilifeform: ( asciilifeform plowed through the phf-vtronics thread when came back from voyage, and then second time when diana_coman requested keccak regrind, and both times failed to converge to correct answ re 'is there complete keccak vtron' )
asciilifeform: http://btcbase.org/log/2018-09-27#1855078 << trickier item. recall 'the song of the sirens, some have escaped, but their silence -- no one' . how to deal with 'but ~was~ it in the l0gz'.
a111: Logged on 2018-09-27 19:52 mircea_popescu: in any case shit in the logs ain't gonna to "just go away", this isn't linuslands. ignoring it is like ignoring hot coals.
a111: Logged on 2018-09-27 19:17 BingoBoingo: asciilifeform: I have returned from the envirorast office, about to fire off a message to DHL informing them to try again as I am a provisionally acredited importer of packaged goods for commercial use
a111: Logged on 2018-09-27 19:52 mircea_popescu: http://btcbase.org/log/2018-09-27#1854952 << what you apparently did was completely ignore the matter for five months, then discover like children that you actually need tools at the time you started on the task (late at night etc) and so forth.
a111: Logged on 2018-09-18 18:22 asciilifeform: this is the other thing, 'changes are expensive' promote imho a sane view of software, where you actually try to perma-stabilize yer proggy, rather than to keep up the classic 'open sores' eternal cauldron of bubbling liquishit
a111: Logged on 2018-09-27 20:00 mircea_popescu: http://btcbase.org/log/2018-09-27#1854988 << we came up with this clever thing sometime in 2015 or so iirc. not sure what is gained by doing 99995 --> 99994 etc in light of experience, but i clearly recall how cool it looked at the time.
asciilifeform: http://btcbase.org/log/2018-09-27#1855080 << i stole the notion , in slightly modified form, from knuth. the logic is, decrementing versions, with finite initial N, support a http://btcbase.org/log/2018-09-18#1851362 flow , where 'if you fucked it N+1 times , nao forced to call proggy something else' -- specifically in opposition to the heathen plague of runaway ver nums (e.g. linux kernel, emacs, firefox, etc)
a111: Logged on 2018-09-27 15:12 asciilifeform: ( fughot that they decrement ! )
mircea_popescu: http://btcbase.org/log/2018-09-27#1854988 << we came up with this clever thing sometime in 2015 or so iirc. not sure what is gained by doing 99995 --> 99994 etc in light of experience, but i clearly recall how cool it looked at the time.
deedbot: http://trilema.com/2018/fetlife-the-next-derperation/ << Trilema - Fetlife -- The Next Derperation
mircea_popescu: in any case shit in the logs ain't gonna to "just go away", this isn't linuslands. ignoring it is like ignoring hot coals.
a111: Logged on 2018-09-27 13:35 asciilifeform: call me an idjit, but i thought there were a new vtron...
mircea_popescu: http://btcbase.org/log/2018-09-27#1854952 << what you apparently did was completely ignore the matter for five months, then discover like children that you actually need tools at the time you started on the task (late at night etc) and so forth.
a111: Logged on 2018-09-27 12:47 diana_coman: since I need to get the work done on this, I reground the UDP lib and I'll proceed from there; asciilifeform, phf and anyone else interested, keccak-patches are on my Code Shelf as usual: http://ossasepia.com/reference-code-shelf/#selection-477.0-477.19
BingoBoingo: Now for everything else on the docket
BingoBoingo: asciilifeform: I have returned from the envirorast office, about to fire off a message to DHL informing them to try again as I am a provisionally acredited importer of packaged goods for commercial use
phf: right vpatch applies 'diff -ruN' style patches exactly. it also keeps track of both the hash of the patched file and the hash of the result state as it's reading/patching (there's no double read happening), and errors out if either fails to match the hashes in the header
trinque: the "hunk succeeded at offset $hurrr" thing is abominable
asciilifeform: phf: imho your approach , i.e. dispensing with gnupatch, is The Right Thing, historically there was quite a bit of grief from gnupatch's habit of eagerly attempting to apply an invalid (by vtronic lights) but 'partially ok' by barbarian lights patch
trinque: phf: in principle I'm entirely in favor of the "unix philosophy" approach of simple, single-purpose tools
mod6: yeah, this is the right approach imho. it's what i'd do with my ada-vtron, if it ever does breathe.
phf: re esthlos's work i think it's a shame that he chose to reimplement own keccak, but is still calling out to gnu patch. he could just focus on graph resolution/signature/wot checking, and offload the validation on vpatch: construct the press list, feed the patches in-order to vpatch, if vpatch succeeds then you know _for certain_ that the sequence of patches is valid, hashes and all
asciilifeform: phf: i finally sat down and properly read the thing, and i think i finally grasp.
phf: trinque: vtools has not been design or intended to compete with any particular v implementation. it's a set of tools that you can use in a v workflow (hence the name). at least initially it was two matching tools vdiff and vpatch that know how to produce and consume a canonical vpatch. the conflation came up, because i also published vtools in a form that broke existing canonical v, v.pl, and was tasked with fixing the situation.
phf: trinque: it hasn't been, and i'm doing omission by not mentioning that vtools had a later mandate for graph resolution. meanwhile esthlos v was supposed to supposed to fix the issue, i suspect that different v's will eventually catch up.
asciilifeform: ( right now there's a linux-like situation where errybody has own flags etc )
asciilifeform: prolly will also makes sense to standardize the calling for it eventually ( and i'ma rework mine to fit, etc )
trinque: trinquebrain clearly not handling the swaps between v.pl and v.py in thread just yet
trinque: phf: did the problem which caused folks to have to delete one branch of your vpatch tree to press the other get fixed in v.pl?
asciilifeform: imho the situation where 'errybody made own hack' but no one posted 'because obvious' is a barbarism, really ought to have a civilized 'here is the whole thing' sitting on www somewhere.
a111: Logged on 2018-09-27 15:33 phf: asciilifeform: this has been extensively discussed in the logs. there was never a need for "new style v". v works just fine. one of the design goals of vtools was to nail down (and improve upon) the patch format. vtools are explicitly designed to be used with an existing v (for example i use it with v.py). vdiff produces wellformed vpatches and vpatch presses them ensuring that the format is valid and that the hashes stand. there's no
asciilifeform satisfied with the explanation
asciilifeform: ( i.e. i'd like to dispense with sha512sum util entirely , aside from existing ancient items which have sha512 hashes in the l0gz from years ago )
phf: you can basically do (cat foo.vpatch bar.vpatch qux.vpatch) | vpatch and expect the resulting press to be fully valid, hashes and all
asciilifeform: then not direly needed. though i'd still like to be able to post keccak hash in the log next time we're doing a thread with fw images or the like.
phf: re standalone keccak hasher: i'm not sure that it's needed, i think the relevant phase can just be dispensed with altogether. `vpatch' verifies the hashes as it goes along
phf: asciilifeform: well, you're one of the v maintainers, i'd think you would want to do it to your own tool.
asciilifeform: mod6: for nao i'll be entirely satisfied with the variant phf describes.
mod6: The string handling, discussed previously in the logs, is basically a solved problem - would just need something similar to what alf or others have done before - character by character.
asciilifeform: phf: makes sense. my frustration is from walking the logs for past 2 days and looking for who has the complete shaft+head hammer, and not finding
mod6: I had started on a ada vtron last year, but I got hung up with some of the string handling, and the fact that I had to use shell-outs for pgp. I'd like to get back to it at some point. I would love to dispense with the shell outs - and can probably do so, but not until 'peh' is finished.
phf: when i started working on vtools there was already a handful of battle tested V implementations, that relied on vdiff.sh/gnu patch combination. vtools is a "drop in" replacement for the later. you get valid vpatch on the input, valid press on the output. the purpose is to nail down the format, and gradually replace out its parts (e.g. transparent sha->keccak transition)
phf: asciilifeform: you already have the shaft, it's v.py
asciilifeform: now i'ma need the shaft.
asciilifeform: this thread is not meant to insult phf et al , but i open box where i thought was hammer, but there is only a hammer head
asciilifeform: dun seem like we disagree then ?
asciilifeform: where is the 'fud' ??
asciilifeform: phf: there is not currently a complete replacement for mod6 v.pl ! fact !
asciilifeform: once it ~does~ exist, and fully displaces the duct tape, then yes i'ma start regrinding other things , and i expect then mod6 -- trb, etc
asciilifeform: phf: this is not a criticism of the format. but turns out asciilifeform has been looking for a 'i missed it in logz?' piece that doesn't exist quite yet ( hopefully will in 3 days... )
a111: Logged on 2018-09-27 13:50 diana_coman: asciilifeform, np; re vtron yes, currently it is only vdiff and vpatch functionality; I use old v to see the flow (since it checks the seals but doesn't care about the hashes until press time) and then the vpatch to actually press; looking forward to esthlos' vtron
asciilifeform: ( recall, i introduced the patches thing considerably prior to ~vtronic~ patches )
asciilifeform: and yes it is the picture i got from log. the gap in my head is where diana_coman switched to the new format; i then assumed there is a 100%-complete new vtron, and that 'hmm simply missed this, is in log somewhere' , turns out nope, notyet
asciilifeform: phf: try an' see from my pov : i get a 'goddamn stop using old v' , go an' uncrate the replacement, and turns out it ain't a plug-in replacement but a set of pieces and a roll of duct tape
phf: asciilifeform: but if you want a full "v replacement and i don't want to think about none of that" then just use esthlos's item. i believe he has a working keccak already
lobbesbot: phf: Sent 14 hours and 6 minutes ago: <asciilifeform> nm, distinguished by hand... but my vtron doesn't verify the sigs (not immediately sure why) and mod6's -- sees only Leaf: vtools_vpatch_newline.vpatch (phf)
lobbesbot: phf: Sent 14 hours and 10 minutes ago: <asciilifeform> are http://barksinthewind.com/2018/vtools-keccak-regrind/ old-style or new-style vpatches ?? my vtron won't press'em, and there is no way to distinguish , nor anything in the post to indicate, unless i'm thick
phf: asciilifeform: this has been extensively discussed in the logs. there was never a need for "new style v". v works just fine. one of the design goals of vtools was to nail down (and improve upon) the patch format. vtools are explicitly designed to be used with an existing v (for example i use it with v.py). vdiff produces wellformed vpatches and vpatch presses them ensuring that the format is valid and that the hashes stand. there's no
asciilifeform: ( fughot that they decrement ! )
asciilifeform: mod6: that there's '99993 K' . but what was '99994 K' ??
mod6: http://btcbase.org/log/2018-09-27#1854940 << The changes and reasons for, are discribed here: http://therealbitcoin.org/ml/btc-dev/2018-February/000290.html
a111: Logged on 2018-09-26 22:01 asciilifeform: unlike some folx (as late as '16 some confessed to git ) asciilifeform does not use heathen versiontrons internally, strictly 100% v from aug '15
a111: Logged on 2018-09-26 22:00 asciilifeform: mircea_popescu: prolly like most folx who actually work on proggies, asciilifeform has '9000' vtrees on various disk, on various boxen, that are in classical format, and many not even intended for publication, the ones that see daylight naturally will become newtype
asciilifeform: ( given http://btcbase.org/log/2018-09-26#1854819 + http://btcbase.org/log/2018-09-26#1854820 , i'd really like to have a 100% working item prior to entirely retiring the old )
asciilifeform: if phf's item came with a standalone keccak hasher , would then be quite simple to retool e.g. mod6's vtron, to follow the new format. but as it is loox like i'ma have to wait for esthlos , to get full working replacement for old vtrons
a111: Logged on 2018-09-27 02:27 esthlos: http://btcbase.org/log/2018-09-27#1854912 << I plan to integrate Keccak into the thing this weekend. At that point it should be fully operational.
diana_coman: I kept waiting on phf and esthlos since they were working on it as far as I could tell; and http://btcbase.org/log/2018-09-27#1854921
asciilifeform: this is what i thought, and why i did not hurry to start the regrindings earlier
a111: Logged on 2018-09-27 13:50 diana_coman: asciilifeform, np; re vtron yes, currently it is only vdiff and vpatch functionality; I use old v to see the flow (since it checks the seals but doesn't care about the hashes until press time) and then the vpatch to actually press; looking forward to esthlos' vtron
asciilifeform: diana_coman: is there a version of mod6's vtron that uses the new vdiff / vpatch ? or what do you use in erryday work ?
diana_coman: fwiw I *did* specifically state in the manifest that it's using Keccak hashes
asciilifeform: danke schon, diana_coman . feel free to rename the filez.
diana_coman: asciilifeform, ok, I'll mirror your sigs too and link to the page anyway; a bit later today
diana_coman: I added the manifest + comments in it; otherwise *all* code is precisely what I got from pressing your patches
diana_coman: asciilifeform, np; re vtron yes, currently it is only vdiff and vpatch functionality; I use old v to see the flow (since it checks the seals but doesn't care about the hashes until press time) and then the vpatch to actually press; looking forward to esthlos' vtron
asciilifeform: aaand it loox like diana_coman already did my chore for me... i'ma do the elementary test on it nao, and sign/mirror.
asciilifeform: call me an idjit, but i thought there were a new vtron...
a111: Logged on 2018-09-27 09:41 mircea_popescu: did you follow diana_coman 's http://barksinthewind.com/2018/vtools-keccak-regrind/#comment-27 ?
a111: Logged on 2018-09-27 09:31 diana_coman: http://btcbase.org/log/2018-09-27#1854882 -> got your .tar.gz but I could not find in it the .wot and .seals? at any rate, if I copied over the .wot and .seals dirs, it pressed perfectly fine with v here (9999 K version); ftr I ran also precisely the v.pl you have in there and it also worked!
asciilifeform: http://btcbase.org/log/2018-09-27#1854926 << ~this~ is pretty strange; diana_coman wouldja mind sharing your working set there ?
a111: Logged on 2018-09-27 09:31 diana_coman: http://btcbase.org/log/2018-09-27#1854882 -> got your .tar.gz but I could not find in it the .wot and .seals? at any rate, if I copied over the .wot and .seals dirs, it pressed perfectly fine with v here (9999 K version); ftr I ran also precisely the v.pl you have in there and it also worked!
a111: Logged on 2018-09-27 01:33 mod6: http://thebitcoin.foundation/v/V-20180222.tar.gz << >> http://thebitcoin.foundation/v/V-20180222.tar.gz.mod6.sig
diana_coman: since I need to get the work done on this, I reground the UDP lib and I'll proceed from there; asciilifeform, phf and anyone else interested, keccak-patches are on my Code Shelf as usual: http://ossasepia.com/reference-code-shelf/#selection-477.0-477.19
diana_coman: adding to the above: old v can still be used to check the sigs, to avoid manual check; so use old v to check the sigs and once satisfied, just feed patches to vpatch
mircea_popescu: did you follow diana_coman 's http://barksinthewind.com/2018/vtools-keccak-regrind/#comment-27 ?
mircea_popescu: asciilifeform phf's thing presses fine, since at least june ( http://thewhet.net/2018/06/mp-wp-genesis-regrind/ )
a111: Logged on 2018-09-27 02:28 trinque: obviously I want such a vtron for the cuntoo final cut, or what's the use of the build process producing a vpatch
diana_coman: http://barksinthewind.com/2018/vtools-keccak-regrind/ -> gotta ask here, phf, am I missing something or what Wednesday was that there in the first line meant to be?
a111: Logged on 2018-09-27 02:27 esthlos: http://btcbase.org/log/2018-09-27#1854912 << I plan to integrate Keccak into the thing this weekend. At that point it should be fully operational.
diana_coman: re using vtools, I currently first check sig (so by hand, separate 1-line) and if ok, then feed patch to vtools
a111: Logged on 2018-09-27 01:34 asciilifeform: http://nosuchlabs.com/pub/v_noworky.tar.gz << the complete tarball with both variants, patches, seals, .wot, my attempt thus far.
diana_coman: http://btcbase.org/log/2018-09-27#1854882 -> got your .tar.gz but I could not find in it the .wot and .seals? at any rate, if I copied over the .wot and .seals dirs, it pressed perfectly fine with v here (9999 K version); ftr I ran also precisely the v.pl you have in there and it also worked!
BingoBoingo: <trinque> does it now properly verify hashes? << I am still at the point where I hand read input, patch, and output
trinque: obviously I want such a vtron for the cuntoo final cut, or what's the use of the build process producing a vpatch
esthlos: http://btcbase.org/log/2018-09-27#1854912 << I plan to integrate Keccak into the thing this weekend. At that point it should be fully operational.
mod6: lol, I don't know how to make it do stuff either, but I guess that's a different problem :]
mod6: Alright, I guess the makefile doesn't build the vpatch binary by default, so I built it manually:
mod6: I took your tarball, dumped in the latest version of my vtron, dropped in the .wot (phf) and seals from what I had in my sandbox previously.
BingoBoingo: asciilifeform: I used the esthlos thing.
asciilifeform: loox like the matter may have to wait until the folx with working keccaktrons wake up and tell me what i'm missing.
mod6: aha, ok. in the past, i've alwasys built the sha256 stuff for my own purposes. let's see if i can get the keccak stuff build.
a111: Logged on 2018-09-26 18:46 diana_coman: asciilifeform, udp tester seems to be nicely running uk->uy and uy->uk so my next step on this will be to publish all the relevant code; since this is effectively on top of udplib, I'd patch it on your tree; mind moving it though to keccak?
BingoBoingo: mod6: iirc, buried in open tabs and notes on the import matter
asciilifeform: mod6: i sat down and resolved to give diana_coman the promised item, but presently loox like won't happen tonight
mod6: asciilifeform: yeah, i dunno, it's been a while. i don't have time to tinker with it at the moment, gearing up for month end here.
mod6: im not positive, although, I think another troublesome one was hanbot's wp-mp, which BingoBoingo used esthlos' to press. i think.
mod6: one has to, again, if i remember correctly, remove some of the vpatches from the "right" side. or something to that effect, to press successfull.y
asciilifeform: http://nosuchlabs.com/pub/v_noworky.tar.gz << the complete tarball with both variants, patches, seals, .wot, my attempt thus far.
mod6: anyway, it's been a while, so I don't know for sure, but if memory serves, I believe his vtree is incompatible with my vtron, on the whole.
mod6: http://thebitcoin.foundation/v/V-20180222.tar.gz << >> http://thebitcoin.foundation/v/V-20180222.tar.gz.mod6.sig
asciilifeform: mod6: thing says '99994 K' in there.
asciilifeform: and yes i separated out the sha patches.
lobbesbot: asciilifeform: The operation succeeded.
asciilifeform: !Q later tell phf nm, distinguished by hand... but my vtron doesn't verify the sigs (not immediately sure why) and mod6's -- sees only Leaf: vtools_vpatch_newline.vpatch (phf)
lobbesbot: asciilifeform: The operation succeeded.
asciilifeform: !Q later tell phf are http://barksinthewind.com/2018/vtools-keccak-regrind/ old-style or new-style vpatches ?? my vtron won't press'em, and there is no way to distinguish , nor anything in the post to indicate, unless i'm thick
deedbot: http://trilema.com/2018/occasional-discourse-on-the-negro-question-1849/ << Trilema - Occasional Discourse On The Negro Question, 1849
mircea_popescu: after all the grauduation stuff, DIDSCOURSE!
deedbot: http://trilema.com/2018/occasional-didscourse-on-the-negro-question-1849/ << Trilema - Occasional Didscourse On The Negro Question, 1849
mircea_popescu: asciilifeform after the girls saw http://trilema.com/2015/laile-ou-la-cuisse/ they identified sysco as the tricatel item, it's a constant butt of jokes.