Results 1 ... 196 found in all logged channels for 'luby'

(pest) asciilifeform: returning to this point, imho is major reason wai the luby thing aint optional luxury, but key moving part --
(pest) bitbot[asciilifeform]: Logged on 2023-01-01 19:18:56 asciilifeform[jonsykkel]: signpost: any prng can shit out the desired distribution if you transform the output. ( afaik the key attributes of a prng usable for lubyism are -- long period (i.e. not absurdly short), uniformity, and speed , in that order. )
(pest) asciilifeform: signpost: any prng can shit out the desired distribution if you transform the output. ( afaik the key attributes of a prng usable for lubyism are -- long period (i.e. not absurdly short), uniformity, and speed , in that order. )
(pest) phf: http://logs.nosuchlabs.com/log/pest/2023-01-01#1020083 << yeah, i ran into this issue with the luby prototype. cmucl uses XOROSHIRO, sbcl MT19937, python also uses mersenne twister, but whether it corresponds to sbcl's mt remains to be seen
(pest) phf: http://glyf.org/screenshots/luby-success.png successful decode of the second coming by yeats
(pest) bitbot[asciilifeform]: Logged on 2022-12-30 20:14:19 phf[deedbot|awt]: i assume online codes share similar properties to luby, you can generate infinite numbers of blocks to do a constant broadcast
(pest) phf: i assume online codes share similar properties to luby, you can generate infinite numbers of blocks to do a constant broadcast
(pest) signpost[phf]: "This paper is written in terms of a new algorithm called on-line codes [7]. Luby has recently published an algorithm called LTcodes, which is similar to on-line codes, but suffers from O(n lo
(pest) phf: ah shit i'm 2/3 implementing luby
(pest) signpost[asciilifeform]: nah, it's not luby's erasure code. it's the one in the paper I link in this post
(pest) phf: and to further clarify, it's an implementation of `Luby, M. (n.d.). LT codes. The 43rd Annual IEEE Symposium on Foundations of Computer Science, 2002.` without any further extensions?
(pest) asciilifeform: ( why luby to begin with? precisely so can be asynchronous and order-not-matters and occasional-loss-not-matters )
(pest) asciilifeform: 1 of the reasons why the luby transfer absolutely gotta be direct-only (tho can be from >1 peer in parallel, sending diff frags)
(pest) asciilifeform: phf: the notion iirc was that it won't, when comes down to level of 'leaf' (you get n luby packets, of which you need m, or until say 'enuff'. again need concretes to say what n/m oughta be)
(pest) asciilifeform: http://logs.bitdash.io/pest/2022-12-29#1019880 << there was a napkin-level thread which cannot atm find, where 'luby has overhead, so only makes sense for $size, so what response to getbinwithhash oughta be is a tree of hashes until leaves represent frag with $size'
(pest) asciilifeform: there are no bw-guzzling or hdd-filling issues re ~direct~ transfer of a chained (or lubyized for that matter) cat.jpg
(pest) asciilifeform: and then may as well pass files in direct streams of luby
(pest) bitbot[asciilifeform]: Logged on 2022-12-28 12:07:44 asciilifeform[jonsykkel|deedbot|awt]: lolcats really oughta travel e.g. a-lubystream->b-lubystream->c etc. after c->gimmebinwithhash->b-gimmebinwithhash->a
(pest) asciilifeform: phf: imho propagating request for bin-with-$hash to peers, and if 1 of'em has the thing in cache, you get a lubystream -- is the rough solution
(pest) asciilifeform: lolcats really oughta travel e.g. a-lubystream->b-lubystream->c etc. after c->gimmebinwithhash->b-gimmebinwithhash->a
(pest) asciilifeform: imho would be much better to do the clever thing re luby fileshares instead, i.e. where they can propagate somehow
(pest) phf[asciilifeform]: so as far as i understand luby is p2p, and exists essentially on same level as dm. what about something like broadcast inline stuff? like e.g. if you waant to send funny picture of cat, and have it appear inline in logs?
(pest) phf[asciilifeform]: 􏿽i'd probably put theoretical future luby code into a separate conditional branch, have totally special caching etc. strategy for the messages. at which point the problem of black->red as fast as possible becomes most important, and there's plenty of work even there. maybe ffi to so
(pest) asciilifeform: asciilifeform's concern is when 1 or more of the 10 start shooting multi-GB luby pissstreams to 1 anuther
(pest) jonsykkel[asciilifeform]: right, not same for stales, but common case during lubytronic activities is that u are blasted with valid packets
(pest) asciilifeform: re 'how' will prolly have to wait until the lubytron actually specified.
(pest) asciilifeform suspects that replayed lubyism could be rejected faster than a lookup in 16GB+ heap
(pest) asciilifeform: if can guarantee that a replayed luby frag is rejected as fast (or faster) as the filter would've -- then, worx
(pest) asciilifeform: problem is that sumbody can eat yer cpu 100% by replaying luby frags, tho
(pest) dulapbot: (asciilifeform) 2022-07-25 asciilifeform: each luby msg would include hash of the slice it is a frag of. thereby dr.evil piping in chunks of previous transfers would do 0
(pest) asciilifeform: for anuther thing, luby per se (even signpost's variant) doesn't automatically tolerate garbage
(pest) jonsykkel[asciilifeform]: asciilifeform: yes, its in memory, where it will be imposibly big is my point, if its to store every luby frag
(pest) bitbot[asciilifeform]: Logged on 2022-12-25 11:03:13 asciilifeform[jonsykkel]: observe that filter stores hashes of all msgs, not only chained; and emitted as well as received. letting'em all sit for potentially 15 extra min. is mega-bloat, esp. after we have signpost's luby
(pest) jonsykkel[asciilifeform]: http://logs.bitdash.io/pest/2022-12-25#1019276 << luby frags will go in filter? this is imposible imo, if want to send fat warez at >dialup speed
(pest) asciilifeform: observe that filter stores hashes of all msgs, not only chained; and emitted as well as received. letting'em all sit for potentially 15 extra min. is mega-bloat, esp. after we have signpost's luby
(pest) asciilifeform: signpost: this is likely 1 of those cases where the overhead of lubyism wins for GB+ warez, but loses for a 200kB lolcat.gif
(pest) bitbot[asciilifeform]: Logged on 2022-12-05 12:41:21 asciilifeform[5]: phf: lubytron only practical for direct msgs
(pest) asciilifeform: phf: lubytron only practical for direct msgs
(pest) asciilifeform: m-of-n per asciilifeform's picture oughta be for text strictly. (for fat binaries, oughta use signpost's lubytronic encoding)
(pest) asciilifeform: esp. once bolted on signpost's luby thing
(pest) asciilifeform: 'binary' msg type for eventual use w/ signpost's lubytron.
(pest) asciilifeform: (which is where signpost's lubytron comes in)
(pest) asciilifeform: asciilifeform's notion is, can issue 'i want file with $hash' to >1 peer, and get direct lubyisms from >1 if they have it
(pest) asciilifeform suspects the need for this will be felt moar acutely once we've the luby file transfer thing
(pest) asciilifeform: prolly oughta wait until spec is bugfree per current reader's lights; and prolly also until we've the luby algo
(pest) asciilifeform thinking that msgs with > n (for some n) chunks oughta travel in luby transport.
(pest) asciilifeform: ( and, naturally, they oughta ride on signpost's luby scheme )
(pest) asciilifeform: likely you'd want signpost's luby encoder
(pest) PeterL[asciilifeform|asciilifeform|asciilifeform]: signpost: so I had a few moments, was thinking about lubyism/online codes, is http://trinque.org/2022/02/19/online-codes-in-python-wip/ the latest python version of your thing or did you improve upon that?
(pest) asciilifeform: http://logs.bitdash.io/pest/2022-07-27#1010475 << with the caveat that as asciilifeform understands, the result won't be all that similar to traditional bt ( e.g. lubyism instead of deterministic chunks; l1 peers rather than swarm of randos; what's left.. )
(asciilifeform) asciilifeform: ... could in principle have it so lubyism request aint rebroadcast (i.e. goes strictly to l1)
(asciilifeform) dulapbot: (pest) 2022-07-26 asciilifeform: http://logs.nosuchlabs.com/log/pest/2022-07-25#1010638 << imho could make sense to have a lubytron where can ask >1 peer for $frag; but not l2+ (cuz ruinously, 'geometrically' expensive, and the traffic will be pure noise to all but the 1 intended recipient)
(pest) asciilifeform: http://logs.nosuchlabs.com/log/pest/2022-07-25#1010638 << imho could make sense to have a lubytron where can ask >1 peer for $frag; but not l2+ (cuz ruinously, 'geometrically' expensive, and the traffic will be pure noise to all but the 1 intended recipient)
(pest) asciilifeform considers that there aint any point to attempting lubyism b/w l2+; it oughta be strictly b/w peers, otherwise threatens to get ridiculously bw-hungry and complicated
(pest) asciilifeform: phf: given that luby convergence aint deterministic, also would make sense to define a 'stop, we're done'
(asciilifeform) asciilifeform: each luby msg would include hash of the slice it is a frag of. thereby dr.evil piping in chunks of previous transfers would do 0
(asciilifeform) asciilifeform: simply won't be chained ( chaining of any kind makes 0 sense for luby frags )
(asciilifeform) asciilifeform: jonsykkel: in luby-style scheme, btw, there's not really such a thing as a dupe, erry frag is of the form x1^x2^...^xn where x_i are chunks of the payload; erry x_i recv'd gives you some bits of info until you converge on the payload in its entirety
(pest) asciilifeform: phf: signpost is working on a lubytronic file tx/rx
(asciilifeform) dulapbot: Logged on 2021-11-28 19:37:11 asciilifeform: signpost: somewhat apropos, thought of your lubytron in context of possible pheature: pestron takes a local dir and 'hosts'. peers (and optionally broader pestnet members, e.g. l2/l3) can visit e.g. http://localhost:8000/signpost and see his 'www'.
(pest) PeterL[asciilifeform]: http://logs.nosuchlabs.com/log/asciilifeform/2022-06-21#1108032 << would signpost's luby-share thing be able to replace git over pest?
(asciilifeform) asciilifeform: adlai|text: signpost is working on a lubyism commandset for 1337 w4r3z, but dun expect this'll change any existing mechanism
(asciilifeform) asciilifeform: ideally, of course, chains for 'chat' and luby&friends for GB warez...
(asciilifeform) asciilifeform: there's of course stochastic sync ( e.g. luby ) but not ideal for low-traffic link like chat
(asciilifeform) dulapbot: (trilema) 2018-07-22 asciilifeform: basic idea, however buried under mountain of paper rubbish, is deadly simple : instead of periodic wave, you send shaped bursts of 'static' that cover entire $band ( ideally, below noise floor ); on other side, receiver has a correspondingly-shaped filter. pulse position encoding + luby etc. for receive.
(asciilifeform) jonsykkel: i see, ill have look at luby paper
(asciilifeform) asciilifeform: http://logs.nosuchlabs.com/log/asciilifeform/2022-03-29#1090312 << various ways. e.g. box-muller transform converts a uniform to gaussian distribution. or see the 'soliton' equation in luby's paper, similar.
(asciilifeform) asciilifeform: signpost, mangol : thinking about it, you prolly wouldn't want $hash to potentially represent e.g. 1tb file. instead pick a block size, e.g. 1M, and a given lubyism req oughta yield a 1M * redundancy_factor mass of packets. when req'ing a given $hash, if the file is <1M, you get the file, otherwise you get a merkleistic tree of subchunks which can then req.
(asciilifeform) signpost: but yeah, this is an extension of e.g. luby, etc
(asciilifeform) asciilifeform: mangol: see the 'luby', 'turbo code', etc. discussions
(asciilifeform) thimbronion: verisimilitude: not sure what you mean. I envision a built in local http server that loads pages fetched via lubyism
(asciilifeform) dulapbot: Logged on 2021-11-28 19:37:11 asciilifeform: signpost: somewhat apropos, thought of your lubytron in context of possible pheature: pestron takes a local dir and 'hosts'. peers (and optionally broader pestnet members, e.g. l2/l3) can visit e.g. http://localhost:8000/signpost and see his 'www'.
(asciilifeform) asciilifeform: signpost: well several luby quanta at any rate
(asciilifeform) asciilifeform: http://logs.nosuchlabs.com/log/asciilifeform/2022-02-26#1081042 << well if yer using luby, turbo, etc. can set it up so some % of the packets are 'fat', but will still converge if these dun make it to other side, cuz redundancy
(asciilifeform) asciilifeform: verisimilitude: iirc signpost pointed you at various lubyism articles. wainot derive a better algo, say.
(asciilifeform) dulapbot: Logged on 2022-02-19 13:55:37 thimbronion: signpost: plz to repoast recommended luby readings. I am getting to the point where I have time to research this and consider it in the context of pest/blatta.
(asciilifeform) asciilifeform partial to orig. luby, it is by all appearances the simplest, mechanically, and adequate
(asciilifeform) asciilifeform: thimbronion: the piece signpost was working through was not about classical luby tho, but a theoretically moar optimal algo iirc
(asciilifeform) asciilifeform: thimbronion: old piece re luby, iirc linked prior
(asciilifeform) thimbronion: signpost: plz to repoast recommended luby readings. I am getting to the point where I have time to research this and consider it in the context of pest/blatta.
(asciilifeform) dulapbot: Logged on 2021-11-28 19:37:11 asciilifeform: signpost: somewhat apropos, thought of your lubytron in context of possible pheature: pestron takes a local dir and 'hosts'. peers (and optionally broader pestnet members, e.g. l2/l3) can visit e.g. http://localhost:8000/signpost and see his 'www'.
(asciilifeform) dulapbot: Logged on 2021-11-28 19:37:11 asciilifeform: signpost: somewhat apropos, thought of your lubytron in context of possible pheature: pestron takes a local dir and 'hosts'. peers (and optionally broader pestnet members, e.g. l2/l3) can visit e.g. http://localhost:8000/signpost and see his 'www'.
(asciilifeform) dulapbot: Logged on 2021-11-28 19:37:11 asciilifeform: signpost: somewhat apropos, thought of your lubytron in context of possible pheature: pestron takes a local dir and 'hosts'. peers (and optionally broader pestnet members, e.g. l2/l3) can visit e.g. http://localhost:8000/signpost and see his 'www'.
(asciilifeform) signpost: (then atop this, one can build something where he asks his wot for $hash, and whomever has starts blasting lubywads until requester says stop or sender decides enough, at say (1+$lossRate)*$originalMessageLen or w/e)
(asciilifeform) signpost has thought about this as perhaps a message type to request a lubyistic transfer, which opens a side channel and blasts lubywads to peer
(asciilifeform) asciilifeform: really for large payloads lubyism & similar beats the shit outta sequential chunking
(asciilifeform) asciilifeform speaking of luby's but iirc the moar recent encodings require similar mechanism
(asciilifeform) dulapbot: Logged on 2021-11-28 19:37:11 asciilifeform: signpost: somewhat apropos, thought of your lubytron in context of possible pheature: pestron takes a local dir and 'hosts'. peers (and optionally broader pestnet members, e.g. l2/l3) can visit e.g. http://localhost:8000/signpost and see his 'www'.
(asciilifeform) dulapbot: (trilema) 2017-12-18 asciilifeform: ( to complete the picture above : no pow, but a tx ~does~ carry a lubyism, e.g. three lengths of 64bits , each of these the xor of 3 64bit substrings of the world-state, hashtronically selected based ~strictly on the tx payload's hash~ -- nothing to waltz, yer stuck with so-and-so lubyism obligation to fulfill by virtue of yer inputs being such-an-such and yer outputs such-an-such )
(asciilifeform) signpost already encountering broken-headed things in his pylubytron that fall out naturally writing in CL
(asciilifeform) dulapbot: Logged on 2021-11-28 19:37:11 asciilifeform: signpost: somewhat apropos, thought of your lubytron in context of possible pheature: pestron takes a local dir and 'hosts'. peers (and optionally broader pestnet members, e.g. l2/l3) can visit e.g. http://localhost:8000/signpost and see his 'www'.
(asciilifeform) asciilifeform: signpost: somewhat apropos, thought of your lubytron in context of possible pheature: pestron takes a local dir and 'hosts'. peers (and optionally broader pestnet members, e.g. l2/l3) can visit e.g. http://localhost:8000/signpost and see his 'www'.
(asciilifeform) asciilifeform: lubyisms are unbeatable when you know the hash of the warezball you want to get, and perhaps even a subtree of chunk hashes
(asciilifeform) asciilifeform: if signpost knows of a lubyistic algo for the latter, would be interesting to hear it tho
(asciilifeform) asciilifeform: http://logs.nosuchlabs.com/log/asciilifeform/2021-11-20#1066924 << at this pt signpost is prolly better read re lubyisms than asciilifeform , but all the variations on the theme i know of require agreement on the exact item being 'torrented' (if you will) for this kind of cooperation
(asciilifeform) signpost: yeah, I'd recommend that syncs of the entire history happen via a bulk mechanism, e.g. a lubytorrent
(asciilifeform) asciilifeform: cgra: was gonna set aside a msg code for multipartisms (we might want to use e.g. signpost's luby transform, where 'part x of y' has very diff. meaning from the usual, say)
(asciilifeform) asciilifeform: (tho after a certain mass, trinque's lubyisms become worthwhile)
(asciilifeform) asciilifeform: signpost: imho lubyism is a++ for pest-style known-peers net, as the need to separately authenticate the frags falls away (i.e. can generally trust that a direct peer is not sending garbage frag)
(asciilifeform) asciilifeform: iirc signpost wants to send lubygrams, for instance.
(asciilifeform) asciilifeform suspects that lubyism will need dedicated experiments to tune properly (and for various scenarios -- long-haul international; gsmism; etc)
(asciilifeform) asciilifeform: signpost: the satellite tv people already use lubyism in exactly this way (per frame) iirc
(asciilifeform) asciilifeform: http://logs.nosuchlabs.com/log/asciilifeform/2021-03-04#1032809 << i'd actually rec that folx start w/ luby's method, for study -- it is the simplest (and gets across the idea)
(asciilifeform) trinque: this guy's thing looks like a huge improvement to what luby had.
(asciilifeform) asciilifeform: for that matter, trinque , ~all variants of luby algo are similarly usg.prohibited.
(asciilifeform) asciilifeform: verisimilitude: some context for subj.
(asciilifeform) asciilifeform: http://logs.nosuchlabs.com/log/asciilifeform/2020-09-26#1022509 << i wrote, ages ago, a udp lib for this. but as for luby/raptor in particular, all i got is the orig paper + a heathen py demo proggy (iirc linked in '17 ? if not, can post again)
(asciilifeform) trinque: at any rate, I'll happily fix anything wrong with deedbot. atm I'm wrapping my gourd around luby and raptor coding, would like to end up with an item that fires udp or raw IP packets of either directly to friendly peers, in place of IRC.
(asciilifeform) gregorynyssa: asciilifeform: hadn't heard of Luby before this. would it be implemented upon UDP or raw IP?
(ossasepia) jfw: http://logs.ossasepia.com/log/ossasepia/2019-11-30#1011687 - then thanks both for clearing that up. So he was quite serious but I misinterpreted. /me adds to his MP reading luby codex
(ossasepia) jfw: ooh, perhaps I digest the Luby paper on the plane.
(trilema) jfw: Luby / LT codes? Got a paper on that waiting in a nearby pile, heh
(asciilifeform) snsabot: (trilema) 2018-07-22 asciilifeform: basic idea, however buried under mountain of paper rubbish, is deadly simple : instead of periodic wave, you send shaped bursts of 'static' that cover entire $band ( ideally, below noise floor ); on other side, receiver has a correspondingly-shaped filter. pulse position encoding + luby etc. for receive.
(trilema) asciilifeform: prolly would make moar sense to discuss 1nce we have luby/gossipd/etc
(trilema) asciilifeform: ( this in re luby's algo )
(trilema) asciilifeform: mp_en_viaje: there are actually coupla dozen (that asciilifeform knows of) schemes similar in scope to luby's -- i picked his simply cuz a) works b) minimal complexity
(trilema) asciilifeform: mp_en_viaje: btw this is another application where box with FG wins -- generating fast-converging luby frags
(trilema) asciilifeform: for yrs nao, asciilifeform thought, 'why the everliving fuck not serve page as a set of luby packets'
(trilema) asciilifeform: iirc it was a plain reed-solomon tho, not newfangled luby
(trilema) asciilifeform: oh hey remember the luby-style usenet archiver thing
(trilema) asciilifeform: mircea_popescu: re the ciphers : it's the item asciilifeform regularly comes back to, iirc most recently in http://btcbase.org/log/2017-11-22#1742198 , http://btcbase.org/log/2017-02-14#1613906 , but also we did the luby variant of same, and iirc earliest discussion was the http://btcbase.org/log/2016-12-24#1589881 thing ( and mircea_popescu's various extensions of subj )
(trilema) asciilifeform: btw i was going through my ffa notebooks and found a margin note that was actually about this, that prolly oughta go in the l0gz : if yer 'pow' is a walk-through-storage, 1 problem is that initial state of the system gives too little material to walk. so 1 interesting answer might be to include a 'ballast', consisting of, say, the first 9 yrs of classical btc blox, 1...N, that is part of the luby'd set (as raw bytes, rather than as m
(trilema) asciilifeform: recall, with the luby(3 blox) thing
(trilema) a111: Logged on 2017-03-01 19:34 asciilifeform: there is no way to practically compute this value without having a copy of the blockchain. and it also ends up being luby-transformable into any one of the 3 old tx if you have the other 2. a kind of perpetual redundancy in the storage .
(trilema) asciilifeform: my orig application called for 'no frag', given as already luby, so why also have ??? in the mix ruining the impedance match
(trilema) asciilifeform: ( btw the standard reassembly method is quite braindamaged, those folx never apparently heard of e.g. luby )
(trilema) asciilifeform: basic idea, however buried under mountain of paper rubbish, is deadly simple : instead of periodic wave, you send shaped bursts of 'static' that cover entire $band ( ideally, below noise floor ); on other side, receiver has a correspondingly-shaped filter. pulse position encoding + luby etc. for receive.
(trilema) asciilifeform: box, incidentally, doesn't need to know anyffing re particulars of gossip protocol; simply verify(4096b) luby packets, rejecting old nonces, reassemble into block, and then retransmit until a newer block is assembled, then repeat ad infinitum.
(trilema) asciilifeform: http://btcbase.org/log/2018-07-05#1831795 << piling on to this thread ftr : ~fiddybux buys you a device that can eat, 24/7, the entire 30MHz or so usable sw spectrum, and search for whatever. pulsers can then transmit short luby slices of $block pretty much wherever in said spectrum , at various times, even regardless of ionospheric season; a % of these will get eaten by $receiver, and slowly reconstitute a valid parcel.
(trilema) caaddr: luby soliton, what else?
(trilema) asciilifeform: http://btcbase.org/log/2017-12-31#1761781 << i gotta point out ftr, luby is recent but e.g. reed-solomon - quite bearded
(trilema) a111: Logged on 2017-12-19 02:33 asciilifeform: and, i'll add, in light of the luby proof-of-storage item.
(trilema) asciilifeform: ( to complete the picture above : no pow, but a tx ~does~ carry a lubyism, e.g. three lengths of 64bits , each of these the xor of 3 64bit substrings of the world-state, hashtronically selected based ~strictly on the tx payload's hash~ -- nothing to waltz, yer stuck with so-and-so lubyism obligation to fulfill by virtue of yer inputs being such-an-such and yer outputs such-an-such )
(trilema) asciilifeform: prolly i'm doomed to describe a complete algo nao. so consider : no pow. a block is 2^20 bytes . it can hold a certain # of fixed-length tx ( i will not repeat earlier scheme, with the luby etc., imho it was adequate. ) ;
(trilema) asciilifeform: and, i'll add, in light of the luby proof-of-storage item.
(trilema) asciilifeform: ( tldr : 13125 bytes on 2sided business card , after luby )
(trilema) asciilifeform: can deal with it same as with everything else, by lubycode-cum-rsa (i.e. distiller of signal from noise , followed by authenticator )
(trilema) a111: Logged on 2017-10-19 13:18 asciilifeform: http://btcbase.org/log/2017-10-19#1726675 << 'filter out the strange' is the naive usg av 'industry' nonsense. a half decent diddletron neither produces nor consumes any 'strange', and 'magic packet' will consist of , e.g., lubyization of 10,000 ordinary packets' timing
(trilema) asciilifeform: http://btcbase.org/log/2017-10-19#1726675 << 'filter out the strange' is the naive usg av 'industry' nonsense. a half decent diddletron neither produces nor consumes any 'strange', and 'magic packet' will consist of , e.g., lubyization of 10,000 ordinary packets' timing
(trilema) asciilifeform: btw let's do the phone thing, briefly. a 4096b rsa modexp can carry 4096b , i.e. 512byte, of payload sans padding. let's conservatively suppose that padding ( and hash auth, or whatever, and/or lubyzation, etc ) costs half of the payload room. so you get 256 byte per 4096b modexp;
(trilema) a111: Logged on 2017-09-01 23:36 asciilifeform: luby has one.
(trilema) hanbot: http://btcbase.org/log/2016-06-14#1481878 << would a sort of bibliography/encyclopedia be useful in the lordship's opinion? have entries for figures that come up often; luby, naggum, etc. obviously these are googleablelier than the dictionary entries, but might benefit from the trilema, # or no #, treatment...?
(trilema) asciilifeform: in particular, to work out what the minimal ( with engineering margin, a la miller-rabin ) number of lubypackets would be.
(trilema) asciilifeform: also error-tolerant, by virtue of lubyism, you can afford to lose a few packets, how many depends on what you have left over.
(trilema) asciilifeform: to verify, delubyize the lists L0....Ln and verify the rsa sig on each.
(trilema) asciilifeform: mircea_popescu: there's potentially infinitely many ways to lubyate
(trilema) asciilifeform: then verify by unlubying.
(trilema) asciilifeform: grind luby's soliton distribution, and you get a calculably vanishing probability of failure
(trilema) asciilifeform: ( yer sig gets hashed and you get to luby in 3 tx from history... )
(trilema) asciilifeform walked into b00ksh0p being sold off 'by the pound' after death of owner, found there a b00k by luby (of luby code) that had nfi existed at all
(trilema) asciilifeform: mircea_popescu: i was thinking, at some point really gotta write up the luby-pow thing into a proper algo
(trilema) asciilifeform reread the piece and ended up in the old luby thread, lol
(trilema) trinque: why huck just to me either, can turn on the luby hose and let multiple folks drink together, when they have the same question
(trilema) a111: Logged on 2017-06-30 16:05 asciilifeform: there is not ( and probably provably cannot be ) a 'luby for computation'
(trilema) asciilifeform: there is not ( and probably provably cannot be ) a 'luby for computation'
(trilema) asciilifeform: esp. the udp/luby piece (where ONE packet must somehow suffice for friend-or-foe, but it cannot >512byte! )
(trilema) asciilifeform: and it was different from asciilifeform's, and did not include 'lighthouses', luby transform, a few elses
(trilema) trinque: there was for example the lighthouse concept; asciilifeform has also spoken of using the luby fountain algorithm over iirc either udp or raw IP packets.
(trilema) Framedragger: (but that's not even luby codes, right)
(trilema) Framedragger: i guess no way to use luby code or equivalent on tcp huh
(trilema) asciilifeform: you replace a block you know to have been fully lubyized with a 'if you want this, go and find'. BUT what, now you have an empty string there ..
(trilema) asciilifeform: and yes you can compute the odds of a particular block B ending up wholly lubyized by a time T. however if you rely on the luby strings for your mining, you will be fucked timewise.
(trilema) mircea_popescu: anyway, the exact way to apply luby to it prolly can take more thinking. but hte idea certainly has merit.
(trilema) asciilifeform: oooh gotta revisit upstack, briefly, http://btcbase.org/log/2017-03-01#1620677 << ~this~ in particular cannot be done as written. else, the first relayer of a freshly mined block could simply steal the work that went into determining luby(Z) and get massive head start on making his own block, which he then relays instead of the plagiarized.
(trilema) asciilifeform: and we have the luby transform above.
(trilema) asciilifeform: (statistically speaking, any sequence of blocks, will eventually end up luby-coded into future blocks ! )
(trilema) asciilifeform: there is no way to practically compute this value without having a copy of the blockchain. and it also ends up being luby-transformable into any one of the 3 old tx if you have the other 2. a kind of perpetual redundancy in the storage .
(trilema) asciilifeform: now if you're in ~no~ kind of hurry, and know luby algo, you can wifi.
(trilema) asciilifeform: 2) consider a device of the following scheme. receives luby-coded packets via radio; if packet checksums AND has one of N lordly signatures, it is relayed (transmitted to neighbouring nodes.) otherwise, not.
(trilema) asciilifeform: the other fundamental aspect, other than 'nothing-to-allcomers' is that synchronous comms over lossy media (e.g. radio) do not work well. the thing that works well is 'i'll pour a bucket of luby in your direction, and you - in mine.'
(trilema) mircea_popescu: they could have like an itinerant seminar of luby transforms, functional analysis and convexity.
(trilema) asciilifeform: in 'idle' state, when the thing has no payload, it listens for a lubyfied turd signed with $key.
(trilema) asciilifeform: mircea_popescu: speaking of uci, ever consider generalizing luby's algo to ~calculation~ ?
(trilema) asciilifeform: (luby himself opened up a troll shop, it seems)
(trilema) asciilifeform: if anyone wondered why fountain (e.g., luby's) algo is not widely used, answer is... mega-unsurprise... patent trollage
(trilema) phf: asciilifeform: what's your luby transform code written in?
(trilema) asciilifeform: (tcp, that massive barrel of liquishit, was designed before the discovery of luby code - or any of the subsequent 'fountain' algos)
(trilema) asciilifeform: satellite tv outfits use a somewhat more efficient - but ~considerably~ more complex - version of luby
(trilema) asciilifeform: in related nyooz, i have Luby Transform working.
(trilema) asciilifeform: http://log.bitcoin-assets.com/?date=24-12-2015#1351837 << mega-b00k describes a kgb legend: the first man who explained to beria how otp is provably 'perfect'-secure, was allowed to leave lubyanka - but at the door they took his employee pass
(trilema) asciilifeform: but i can't help but agree with the general principle. 'public' is largely vermin. and if mircea_popescu decides to open a meatspace lubyanka and make an old-fashioned entirely nonpublic intelligence-gathering corps, he ought to wake us all up.
(trilema) asciilifeform pictures 'lublianka' as a lubyanka (kgb hq) in liubliana
(trilema) asciilifeform: artifexd: a good compromise, probably, would be the Luby transform.
(trilema) mircea_popescu: <BlueMeanie4> in engineering these problems << the agenda is, "send nuland to dance naked in teh lubyanka. we didn't think the ukraine posturing was funny."
(trilema) mircea_popescu: why is he not @lubyanka then
(trilema) Mats_cd03: is this something you can only experience in the dreaded lubyanka
(trilema) herbijudlestoids: nubbins`: there is this awesome blogger bill luby, he does vixandmore.blogspot.com ...hardcore options geekery explained for the masses.