asciilifeform: this in practice is harder than simple sat launch ( the latter is not trying to fly to a specific point in space )

asciilifeform: problem is to get there.

asciilifeform: if you're at musket range, even shot shell would work

asciilifeform: contact detonator ? proximity ?

asciilifeform: mircea_popescu: depends on distance, neh

asciilifeform: also depends, do you want to machinegun 1 sat, or... whole orbit

asciilifeform: ( you don't have blast, recall, must rely on frags )

asciilifeform: well needs a kg or so

asciilifeform: ergo same work.

asciilifeform: small rocket that goes to same orbit.

asciilifeform: well yes

asciilifeform: (elementarily)

asciilifeform: it's ~same work as launching yer own

asciilifeform: depends what means individual

asciilifeform: http://btcbase.org/log/2015-10-15#1299189 << thread ☝︎

asciilifeform: yeah but they ~already own~ the sat

asciilifeform: and claim 'sat is best'

asciilifeform: presumably plan is part of 2-pronged approach where they interfere with ordinary propagation.

asciilifeform: now this i cannot say

asciilifeform: ( much cheaper than mining )

asciilifeform: they've been looking for how to monopolize relay, for years.

asciilifeform: '1 way from owned source' noshit.

asciilifeform: paypalization

asciilifeform: and noshit.jpg you check for nuffin, you eat the mother church's blox as the come, presumably

asciilifeform: 1way much cheaper

asciilifeform: 1way

asciilifeform: meanwhile, usg.prb folx claiming they will soon 'broadcast blocks from satellite', 'use prb without internet!111' -- leveraging the orbit monopoly to diddle 'these blox, mined by us, legal, other, terrorist blox -- orphans nao' ☟︎

asciilifeform: PeterL: sorta why i wrote the most general , unconstrained ffa .

asciilifeform: well i thought of making a 3^n. but there's no reason not to say 'be a whole power of the machine BASE ' !

asciilifeform: the 192b cpu of the dark future will have to smoke sadly...

asciilifeform: and a few other things.

asciilifeform: forcing 2^x = W, x in Z , also simplifies comba

asciilifeform: this means you can have, e.g., 192b, 384b, etc ffa

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: i cannot currently say which i prefer

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

asciilifeform: 4096, i thought, it was

asciilifeform: it is already over the limit

asciilifeform: PeterL: that's a 4150b

asciilifeform: 'non-choice' here means 'obviously Right Thing' or the opposite ?

asciilifeform: mircea_popescu plox to expand on http://btcbase.org/log/2017-08-14#1697729 ☝︎

asciilifeform: PeterL: these ain't hard to calculate

asciilifeform points out that even very modest iron, ffa's quite acceptably over 8192b and higher.

asciilifeform: with his variable-time ops

asciilifeform: moar hamming weight, the merrier for the enemy to suffer crunching'em

asciilifeform: no reason to use any particular pattern, understand, ffa

asciilifeform: mircea_popescu: but not cheaper for us

asciilifeform: but on your current iron you're stuck with cups of a certain size.

asciilifeform: well theoretically fpga

asciilifeform: ALL ffa ops take time that is not dependent on the hamming weight. that's what 'constant time' means.

asciilifeform: 'large' means 'occupies most of W' here.

asciilifeform: ( you no longer win anything by using small ones )

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.

asciilifeform: e.g. 6666-bit keys work fine on ffa!

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. ☝︎

asciilifeform: ( by a max of B-1 bits , where B is your machine word )

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 was going for max generality, at minimal expense

asciilifeform: but then you can only 8,16,....,4096,... etc. W.

asciilifeform: this is also a 10% or so speedup.

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 ☟︎

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: and so instead went with 'mult of 64'

asciilifeform: or at least encourages them

asciilifeform: but i specifically did not like that it gives 'traditional keys'

asciilifeform: it would simplify many routines, in particular karatsuba

asciilifeform: ftr i considered imposing a 'ffa W is power of 2 or fuckyou'

asciilifeform: aaaha here .

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

asciilifeform: and use that.

asciilifeform: so you find nearest multiple that is longer than your payload.

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: think about it

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

asciilifeform: each of which computes exactly same thing, correctly.

asciilifeform: this becomes 3 64-bit words on opteron; 6 32-bit words on pentium; 12 16-bit words on 8086; and 24 8-bit 'words' on 6502.

asciilifeform: say for some peculiar purpose, an ffa run needs 192-bitness.

asciilifeform: let's work an example

asciilifeform: not quite

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

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 ,

asciilifeform: rewrite of what

asciilifeform: a trio that has not prev been achieved at any point.

asciilifeform: mircea_popescu: 'solution to math problem' existed in 1978. ffa goal is simplicity+correctness of implementation + adequateperformance.