3400+ entries in 0.037s
a111: Logged on 2018-10-19 09:38
diana_coman: failing that, I guess 20 somethings partying at least have a local father, for whatever good that might be
a111: Logged on 2018-10-19 09:37
diana_coman: the point being to my mind to perhaps meet *there* some people worth meeting, not as much joining the track per se
deedbot: ave1 rated
diana_coman 4 << solid programmer, eulora, gives helpful comments
ave1: !!rate
diana_coman 4 solid programmer, eulora, gives helpful comments
deedbot:
diana_coman rated bvt 1 << introduced himself with well formed question on my blog
deedbot:
diana_coman updated rating of trinque from 3 to 4 << writes at trinque.org; deedbot and cuntoo; he makes me want again to visit Texas.
deedbot:
diana_coman updated rating of BingoBoingo from 3 to 4 << writes at bingology.net and qntra.net; moved to Uruguay and started Pizarro ISP.
deedbot:
diana_coman unrated andreicon.
deedbot:
diana_coman unrated wyrdmantis.
deedbot:
diana_coman updated rating of mircea_popescu from 5 to 7 << writes at trilema.com; at the centre of it all, like it or not; met irl.
deedbot:
diana_coman unrated EDLionX.
a111: Logged on 2018-10-16 13:56 asciilifeform:
diana_coman: you won't need to do any of the streams horror that i did there, because those of your subfields that are arrays, have strictly bounded sizes
deedbot:
diana_coman rated slycordinator 1 << new blood, living in South Korea
a111: Logged on 2018-10-10 21:09 bvt: Hello, I am BT from the recent
diana_coman's comments section
ave1:
diana_coman, updated!
ave1:
diana_coman, Ach yes, I did copy-paste everything I did not touch
a111: Logged on 2018-10-15 06:49
diana_coman:
http://btcbase.org/log/2018-10-15#1862722 -> hm, multi for the sake of it would anyway be taken care of via who signs and who doesn't sign the various patches or trees; but anyway - do you mean you think there should be explicit multi-tree dependencies? this is what I was talking about there: tree A effectively links to patch B.3 in tree B so if B's maintainer regrinds then A's maintainer has to go on a shouting spree (as per "talk to peop
a111: Logged on 2018-10-14 16:13
diana_coman: yes, the way I currently see it now is pretty much that: trunk (main line) goes along the production versions of all stuff (crc32 or keccak or whatever else) and otherwise at the respective points there can be additional branches /leaves with the reference implementations
a111: Logged on 2018-10-14 16:25
diana_coman: once you bring it into your tree, you don't care about the original tree so ...how stuck?
a111: Logged on 2018-10-14 16:25
diana_coman: and then you are stuck maintaining those multiple trees - what's the benefit in that?
a111: Logged on 2018-10-14 16:21
diana_coman: asciilifeform, trouble is - what do you do then when/if that tree gets reground?
a111: Logged on 2018-10-14 16:16 asciilifeform:
diana_coman: iirc mircea_popescu in particular specifically hates libs-as-separate-trees, insists that proggy oughta include errything it eats. ( i dun recall whether he answered why it should not also then include the os and compiler also in same genesis, but i'ma leave thread alone for nao)
a111: Logged on 2018-10-14 16:13
diana_coman: I honestly don't quite see the point of taking crc32 out for instance
a111: Logged on 2018-10-14 16:11
diana_coman: ah, you mean that the only way to do this is to take crc32 out of eucrypt tree?
a111: Logged on 2018-10-14 15:55
diana_coman: as it is, it will be a .vpatch after the lookup implementation - so linear sequence rather than alternative; you might want to branch the tree instead from *before* the lookup implementation so that your div version is effectively alternative branch
a111: Logged on 2018-10-14 11:56
diana_coman: bvt, get yourself a pizarro shared account and start your blog there precisely with those pastes, what's keeping you?
a111: Logged on 2018-10-14 07:53
diana_coman: in fact the 3rd option that is the one actually to use is having different sizes on the two processes (i.e. different constant simply)
a111: Logged on 2018-10-14 07:49
diana_coman:
http://btcbase.org/log/2018-10-14#1862213 -> it's more than just one if statement (although unnecessary branches in themselves are not great anyway); basically it's the udp code itself that has to be messed up to accommodate this particular thing - either using generic or otherwise using the largest of the two and then filtering one level higher
phf:
diana_coman: i've updated eucrypt to keccak, i also added ave1's patch there. also brought udp up to date.
a111: Logged on 2018-10-12 18:14
diana_coman: and it fits perfectly the original idea of alternative, proper
a111: Logged on 2018-10-14 15:55
diana_coman: as it is, it will be a .vpatch after the lookup implementation - so linear sequence rather than alternative; you might want to branch the tree instead from *before* the lookup implementation so that your div version is effectively alternative branch
ave1:
diana_coman, asciilifeform, well I uploaded both with the same scp line, but did not check. So now again new version (thanks for the typo fixes
diana_coman!), I just downloaded both again and verified.
a111: Logged on 2018-10-14 07:53
diana_coman: in fact the 3rd option that is the one actually to use is having different sizes on the two processes (i.e. different constant simply)
ave1:
diana_coman, please try again...
ave1:
diana_coman, place was right, my publish pipeline failed (somehow the final copy operations did not work)
ave1:
diana_coman, I've updated the crc32 code! (still at the place)
a111: Logged on 2018-10-14 01:10 mircea_popescu:
diana_coman 14721 or 14702 BITS long, not octets yes ?
a111: Logged on 2018-10-13 20:48
diana_coman: asciilifeform, hmm, there is certainly a case for same size precisely because way simpler code
a111: Logged on 2018-10-13 20:48
diana_coman: asciilifeform, hmm, there is certainly a case for same size precisely because way simpler code
a111: Logged on 2018-10-13 20:45 asciilifeform:
diana_coman, mircea_popescu : didja ever say wai not made'em all 1472 ?
a111: Logged on 2018-10-02 16:25 mircea_popescu: ok, so this back of a digital envelope seems to suggest we want : 1. fixed size 1470 byte rsa packets, made to work with 3920-bit rsa (of which i presume the useful message size to be 1872 bit,
diana_coman plox to confirm maffs ?). such a packet has then 1696 bits spare for e and bullshit.
mircea_popescu:
diana_coman ahahaha could be, could be, possibly, possibly...
trinque:
diana_coman: indeed, will do
trinque: probably the
diana_coman / Mocky case indicates drop
mircea_popescu:
diana_coman you know, unmolested calves grow into bulls ; ox is product of human industry.
BingoBoingo:
diana_coman: Right, there's a small herd of boys
a111: Logged on 2018-10-13 15:00
diana_coman: possibly, no idea really; but what, they just send random udp stuff on all ports?
mircea_popescu:
diana_coman is he the ultimate in suave p2p ? cuz i'm starting to suspect!
ave1:
diana_coman, I now have a good version of the crc32 bitwise constant time algo, but I ran out of time for today, so eta probably tomorrow.
mircea_popescu:
diana_coman a single line ~in the press~. but a tree ~in existence~.
a111: Logged on 2018-10-12 09:41
diana_coman: there is also the bit-keccak in eucrypt and that is the same really - reference code rather than production code
ave1:
diana_coman, updated!
ave1:
diana_coman, I'll add my test and fix the typo and regrind