log☇︎
167300+ entries in 0.099s
asciilifeform: as for the other thing, right now we have a 'classical' karatsuba that permits odd splits
asciilifeform: ( or describe a logic for showing that one is always preferable to the other )
asciilifeform: mircea_popescu: there's something to be said for 111111.....1 (max hamming weight), and there's something else to be said for max-entropy
mircea_popescu: asciilifeform it means there's no space for choosing, as there's an obvious right thing.
asciilifeform: 4096, i thought, it was
PeterL: (I was using 4160 bits as the limit)
asciilifeform: it is already over the limit
PeterL: could be the next prime would put it over the limit, right?
asciilifeform: PeterL: that's a 4150b
PeterL: (I forgot to increment a variable, so the first number is just 2*(a big exponent of 3) )
PeterL: http://wotpaste.cascadianhacker.com/pastes/x9YvV/?raw=true << this is a better one!
asciilifeform: 'non-choice' here means 'obviously Right Thing' or the opposite ?
a111: Logged on 2017-08-14 17:57 mircea_popescu: no, it is not, in that it would simplify routines. that's what makes it an aesthetic non-choice.
asciilifeform: mircea_popescu plox to expand on http://btcbase.org/log/2017-08-14#1697729 ☝︎
PeterL: oh, wait, nevermind, that is wrong
mircea_popescu: PeterL we found a hole in the spec ;/
asciilifeform: PeterL: these ain't hard to calculate
PeterL: I am still digesting logs, did you guys agree on a bit size for the primorial you want?
asciilifeform points out that even very modest iron, ffa's quite acceptably over 8192b and higher.
mircea_popescu: anyway. i am sad, but defeated. the dream has to die, it's what it is. so regretfully... 4096 keys.
asciilifeform: moar hamming weight, the merrier for the enemy to suffer crunching'em
asciilifeform: no reason to use any particular pattern, understand, ffa
mircea_popescu: aha. prolly should have a "dense" prime then.
mircea_popescu: why, no penalty to use checkerpattern instead ?
mircea_popescu: re exponent, it's traditionally 0101 because cheaper calcs.
asciilifeform: well theoretically fpga
mircea_popescu: asciilifeform no dude, consider the catechistic angle. "soo... why is your key 515 byts ?" "i dunno, his lordship mp said so" "why ?" "nobody knoiws, really. he just says things." "so how do you calculate it ?" "first, you set ffa to 520 bytes..." "why did he say 515 then ?" "uh... that's a good question."
asciilifeform: ALL ffa ops take time that is not dependent on the hamming weight. that's what 'constant time' means.
asciilifeform: incidentally, there is no reason why the ~public~ exponent , on ffatronic rsa, should not also be a large prime
asciilifeform: recall also that, since we have karatsuba, cost goes up with W logarithmically, rather than quadratically
asciilifeform: simply take a 6720-bit W.
a111: Logged on 2017-08-14 17:50 mircea_popescu: but this important point has important consequences, because now we can't have my eccentric rsa keys. must be 4096, because the only alternatives ffa permits are 2048 which is too short and 8912 which is too long.
asciilifeform: http://btcbase.org/log/2017-08-14#1697693 << and importantly, current ffa works with ( see factorial demo ) any multiple of 64, that fits in your machine memory. ☝︎
a111: Logged on 2017-08-14 17:56 mircea_popescu is really pissy that "gotta use trad width keys" ended up imposed on him!
asciilifeform: i'ma repeat that http://btcbase.org/log/2017-08-14#1697720 is a mistake -- you can still use any key width you like. just gotta 0extend up to the permitted multiple. ☝︎
asciilifeform: but then you can only 8,16,....,4096,... etc. W.
asciilifeform: because could instead pass the splits directly
asciilifeform: and by extension, with the temp buffers in same ☟︎
asciilifeform: if instead of 'mult of 64' we had 'powers of 2', we could dispense with the odd split in karatsuba ☟︎
mircea_popescu: no, it is not, in that it would simplify routines. that's what makes it an aesthetic non-choice. ☟︎
asciilifeform: can't just say 'sorry , can't do that here'
asciilifeform: however P progs MUST execute to same result on ALL known iron, is the idea
asciilifeform: this is open to debate, it is an aesthetic choice
asciilifeform: or at least encourages them
asciilifeform: but i specifically did not like that it gives 'traditional keys'
mircea_popescu is really pissy that "gotta use trad width keys" ended up imposed on him! ☟︎
a111: Logged on 2016-02-22 23:21 asciilifeform: bit-serial cpu is meaningfully and interestingly unlike anything that came before (or, afaik, after.)
asciilifeform: ( there WAS attempt to make 'comp of no fixed bitness' )
asciilifeform: but i lost the link.
asciilifeform: btw the bitserial cpu thread prolly belongs linked here
mircea_popescu: because 4096 will accomodate all computers up to 4096 bit ones.
asciilifeform: and use that.
asciilifeform: so you find nearest multiple that is longer than your payload.
mircea_popescu: which is how "it's either 4096 bits long or get lost" ends up in there.
mircea_popescu: asciilifeform yes, and then you're going to compute 192 keys on 256 bits, and wonder why the fuck are you not using 256.
asciilifeform: you are already forced to pad to multiple of 8 on every iron in existence today, this is no different. and nobody will reprieve you from it.
asciilifeform: when on 128-bit iron , which exists today, you simply gotta pad out your payload so it sits in a W multiple of 128 ( supposing you insist on squeezing every penny of horse out of the 128ness )
asciilifeform: just like your opteron is happy to add 1 + 1, even though 1 is a '1-bit' rather than 64-bit int
asciilifeform: this is not end of the world
asciilifeform: mircea_popescu: you can use any key bitness you like ! but gotta top it out with 0s to sit it into a ffa word
mircea_popescu: and then when a 128 bit machine comes along ?
asciilifeform: each of which computes exactly same thing, correctly.
mircea_popescu: but this important point has important consequences, because now we can't have my eccentric rsa keys. must be 4096, because the only alternatives ffa permits are 2048 which is too short and 8912 which is too long. ☟︎
asciilifeform: ( perhaps to pdp8... )
asciilifeform: not to the moon, not to mars
asciilifeform: and 'W % 64 == 0' is not any more or less nonsensical than 'W % 8 == 0' which you are not escaping from to anywhere
mircea_popescu: ah, that part is not in dispute.
asciilifeform: it is not possible to have anything that looks like ffa, without suffering this constraint.
asciilifeform: would be very clear that the 'must sit in whole number of machine words' is not any kind of constraint imposed by asciilifeform , but by the machine
asciilifeform: if you read the code, mircea_popescu ,
a111: Logged on 2017-08-14 17:44 mircea_popescu: "N must be 64 because at some point i nthe past a 64 bit machine was released and we care ; N will not have to be 128 in the future because even though an 128 bit machine will probably be released in the future, we don't understand the future and consequently do not care"
mircea_popescu: you'll have to re-read this log tomorro.
asciilifeform: a trio that has not prev been achieved at any point.
mircea_popescu: turns out my mock-rewrite was more on point than originally thought.
asciilifeform: mircea_popescu: 'solution to math problem' existed in 1978. ffa goal is simplicity+correctness of implementation + adequateperformance.
asciilifeform: it can go to hell.
mircea_popescu: goal is definitive solution to math problem.
asciilifeform: the hypothetical future 128ism is not , in that light, needed for anything.
asciilifeform: goal is ADEQUATE performance on iron of TODAY
mircea_popescu: so then we CANT use 64 bit aritm on 128 bit machine.
asciilifeform: just like ffa worx just fine on opteron today dialed down to 32
mircea_popescu: and then why can't we use 32 bit aritm on 64 bit machine ?
mircea_popescu: "N must be 64 because at some point i nthe past a 64 bit machine was released and we care ; N will not have to be 128 in the future because even though an 128 bit machine will probably be released in the future, we don't understand the future and consequently do not care" ☟︎
asciilifeform: 'W is constrained, such that any permissible value of W must be representable in a whole number of machine words on 8, 16, 32, 64-bit ALU.'
asciilifeform: i have nfi where to even begin
mircea_popescu: this has been the worst explanation of a rationale in recorded history. care to do it over ?
mircea_popescu: answer the q then! when a 128 bit computer is sold, ffa word will ahve to increase to 128 bits ?
asciilifeform: understand, it is not possible to use partial machinewords in the simplest possible (i.e. the one in ffa) arithmetic method.
mircea_popescu: and an update when the 128 computer hits the shelves ?
asciilifeform: it has to do SAME THING on all iron
asciilifeform: btw does it makes sense why i put in that req ?
asciilifeform: ( at which point you oughta use THAT as the cap, not it )
mircea_popescu: so the correct work spec here is then, 4160 bits ?
asciilifeform: unless you push it up to next multiple.
mircea_popescu: asciilifeform tmsr key = 515 bytes = 4120 bits.
mircea_popescu is not going to comment re right or wrong for teh obvious reason!
mircea_popescu: hanbot what's that, first 419 primes ?
hanbot: <mircea_popescu> this is actually going to be teh magic number of the republic. so at this juncture i would like to ask everyone to compute "the largest primorial (ie, product of all successive primes) that fits in 515 bits", sign it and put it into deedbot. << is this right (up to 2900)? http://wotpaste.cascadianhacker.com/pastes/9lxGb/?raw=true
asciilifeform: breakable even today
mircea_popescu: the idea is to use DIFFERENT methods to compute it.