Results 1 ... 250 for 'luby'...

Results 1 ... 250 found in all logged channels for 'luby' | →

(pest) bitbot[asciilifeform]: Logged on 2022-12-29 12:30:22 asciilifeform[jonsykkel|awt|deedbot]: 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) bitbot[asciilifeform]: Logged on 2023-07-31 18:19:29 gregorynyssa[deedbot|signpost|PeterL]: signpost: Does your implementation of Luby codes support streams of indefinite duration, or only files of known size?

(pest) gregorynyssa[asciilifeform]: signpost: asciilifeform: If I am not mistaken, the benefit of Luby codes is that we no longer need a TCP-like flow-control mechanism.

(pest) gregorynyssa[asciilifeform]: signpost: Does your implementation of Luby codes support streams of indefinite duration, or only files of known size?

(pest) gregorynyssa[asciilifeform]: signpost: awt: I would be glad to talk about Luby coding sometime.

(pest) bitbot[asciilifeform]: Logged on 2023-05-15 09:53:01 asciilifeform[5]: http://logs.bitdash.io/pest/2023-05-15#1026119 << for 'file', the notion was to luby. for lolcats, iirc no one yet suggested precisely how to mark'em ( would strongly prefer not to roll in the 'mime' traditional idiocy or anyffin like it. prolly best to have a single flag som

(pest) asciilifeform spent far too many cycles chasing 'perpetuum mobile' of trying to devise a lubyesque decoder that could somehow identify bogus chunks

(pest) asciilifeform: ... to the flash stick, write ciphered keys not as file but as luby into N unused-by-fs blocks.

(pest) bitbot[asciilifeform]: Logged on 2023-05-15 09:54:20 asciilifeform[6]: http://logs.bitdash.io/pest/2023-05-15#1026122 << luby 'works', the q afaik is 'whether the game is worth the candles' (vs regular old 'multipartism')

(pest) phf: http://logs.bitdash.io/pest/2023-05-15#1026134 << i don't think it can be considered "works" until there's at least there's a workbench implementation of a complete roundtrip. send out a metadata packet, get counter party to recieve it, request hash against some kind of luby protocol, get file

(pest) bitbot[asciilifeform]: Logged on 2023-05-15 09:19:16 phf[signpost]: 􏿽to pest spec. bit since we don't know if luby will even work, and what will need to go into metadata, there's not been an attempt to add one yet

(pest) asciilifeform: http://logs.bitdash.io/pest/2023-05-15#1026122 << luby 'works', the q afaik is 'whether the game is worth the candles' (vs regular old 'multipartism')

(pest) asciilifeform: http://logs.bitdash.io/pest/2023-05-15#1026119 << for 'file', the notion was to luby. for lolcats, iirc no one yet suggested precisely how to mark'em ( would strongly prefer not to roll in the 'mime' traditional idiocy or anyffin like it. prolly best to have a single flag somewhere )

(pest) phf: 􏿽to pest spec. bit since we don't know if luby will even work, and what will need to go into metadata, there's not been an attempt to add one yet

(pest) phf: 􏿽http://logs.bitdash.io/pest/2023-05-15#1026119 << nobody knows on account of fundamental machinery not being figured out yet. the thinking is that something like signpost's luby implementation will be used for file transfer, at which point some kind "metadata" packet will be added

(pest) PeterL[asciilifeform]: Is "lubyism" a term used by other people across the industry or is that just something we use here for this type of thing?

(pest) dulapbot: Logged on 2023-03-22 12:30:29 asciilifeform: looked at a # of 'lubyisms', found that the moar theoretically-optimal sorts tend to be 1) painfully complicated to implement 2) very high constant cost, such that they aint likely to win in re pest, where most common use case is likely to be simply one station sending to anuther, wanting to eliminate effects of pa

(pest) bitbot[asciilifeform]: Logged on 2023-03-23 09:57:54 unpx[jonsykkel|deedbot|signpost]: http://logs.nosuchlabs.com/log/pest/2023-03-22#1025449 <<< I'm curious about the meaning of ``lubyisms'' and any resource that was ``painfully complicated to implement''

(pest) asciilifeform: http://logs.bitdash.io/pest/2023-03-23#1025086 << 1st such code asciilifeform looked at (and invited other folx to do so) was the luby transform

(pest) unpx[asciilifeform]: http://logs.nosuchlabs.com/log/pest/2023-03-22#1025449 <<< I'm curious about the meaning of ``lubyisms'' and any resource that was ``painfully complicated to implement''

(pest) asciilifeform looked at a # of 'lubyisms', found that the moar theoretically-optimal sorts tend to be 1) painfully complicated to implement 2) very high constant cost, such that they aint likely to win in re pest, where most common use case is likely to be simply one station sending to anuther, wanting to eliminate effects of pa

(pest) asciilifeform: fwiw asciilifeform not convinced that this, rather than phf's earlier proposed algo ('find fast way to detect replayed luby that not relies on timestamp') is the correct pill

(pest) phf: i think i'm going back to considering luby packets as a totally special thing, that will be explored once it's out

(pest) phf: right now the most we know about it, is that it's probably going to be luby and there's going to be a special inline message type to announce it

(pest) phf: perhaps once we have running luby

(pest) phf: and not just luby, but foundational stuff

(pest) bitbot[asciilifeform]: Logged on 2023-02-09 13:19:54 asciilifeform[4]: http://logs.bitdash.io/pest/2023-02-09#1022816 << important to recall, tho, that you can't directmsg (or, when we've the luby thing -- warez) to anyone with whom direct peering is broken

(pest) asciilifeform: http://logs.bitdash.io/pest/2023-02-09#1022816 << important to recall, tho, that you can't directmsg (or, when we've the luby thing -- warez) to anyone with whom direct peering is broken

(pest) phf: right, i was over engineering things in my head. simply "guarding" luby with a handshake is good enough

(pest) asciilifeform: no need to recognize, as such, change in AT; simply insist that the addr to which luby piss is to go is able to receive, as well as send, under the requester's key

(pest) asciilifeform: concretely, instead of a single binary direct msg 'gimme lubystream of hash H' being answered immed. by stream, the station will answer 'sure, but 1st send me back these rng bytes, stream will go to ip they get send back from and it has to be the same 1 from which you had asked just nao'

(pest) asciilifeform: phf: the 'send me back these rng bytes' thing would be part of the trigger for the luby (so 'outside', yes). imho would be enuff to avoid 'cannon' w/out adding much gnarl

(pest) phf: should that be some kind of outside of luby mechanism?

(pest) asciilifeform: the luby gets sent strictly to the addr which sent'em back, no AT renewal permitted between the 2 msgs

(pest) asciilifeform: http://logs.bitdash.io/pest/2023-02-03#1022328 << to elaborate: all you need is, before sending e.g. MB of luby, sent to the proposed addr 'here's 256 random bytes, plox to send'em back, then i'll start'

(pest) asciilifeform: nao, the ~clever~ way to cut this knot would be if you could somehow nail down, via hash tree, the expected hashes of individual luby chunks

(pest) asciilifeform: whereas if yer expecting to converge on a 1MB chunk of known hash, and sumbody's already send you over9000x the nominally-req'd luby chunks, and still not converges -- you'll know that 1 or more of the suppliers is fucking you

(pest) bitbot[asciilifeform]: Logged on 2023-02-03 14:15:04 asciilifeform[5]: the other obv pill would be to require a handshake before firing off luby sequence

(pest) phf: you're trying to bolt a tradition chunk synchronization mechanism on top of a very different model, and there are ways to achieve what you're tyring to do, but in a more luby way

(pest) asciilifeform: ( afaik none of the currently-known lubyistic encodings are at all resistant to rubbish )

(pest) phf: but the idea of "gimme a specific chunk but with luby" ought to be tested against the inherent properties of luby

(pest) phf: i think some kind of hard limit on luby stream makes sense, so like getme lolcat 10, will send you a 1mb of lolcat blocks at 10b/s or whatever. if that was not enough you can ask again and again etc.

(pest) cgra: say, 'luby getdata' = '1MB more plz'

(pest) cgra: what's wrong with 1MB of check blocks per 'luby getdata'?

(pest) phf: why then luby at all?

(pest) phf: asciilifeform, yeah but you ask n peers for maxrate/n luby streams

(pest) phf: n stations sending same luby stream is part of the same probability space

(pest) phf: but isn't that the mechanical beauty of luby. you get 20 streams, you get the result 20x faster :>

(pest) asciilifeform: how to not turn 'hey l1, gimme luby of lolcat.jpg' into a guaranteed own-goal is genuinely open q (suppose yer l1 is 20 stations and they all have it, say) atm

(pest) phf: if you're catching up with log, it's sensible then to have some kind of heuristic for automatic luby payload request, "give me all png/jpg/gif/pdf files that are less than 20mb" or whatever

(pest) asciilifeform: lubyism in asciilifeform's conception is entirely separate protocol, with transport via pest directmsgs

(pest) phf: http://logs.bitdash.io/pest/2023-02-03#1022247 << your initial sync is a bandwidth heavy cornucopia. long stream of getdata requests, and depending on how you implement, a getdata for a message with luby payload results in "oh yeah and by the way also give me stream for this luby"

(pest) asciilifeform: the other obv pill would be to require a handshake before firing off luby sequence

(pest) asciilifeform: fwiw this needs not only peer key, but also to know of a valid file hash to make luby req for

(pest) asciilifeform: if you've the key, can indeed trigger lubyism to arbitrary ip, if can route forged packet to receiver

(pest) phf: or better yet "turn on luby for all the files that i know you have"

(pest) phf: *naive luby that is

(pest) phf: also you can definitely do ddos with luby. as of right no handshake in protocol, so you can e.g. forge a valid "ignore" packet, but with bogus origin ip, so that will update AT, and then you follow it up by "turn on luby please for lolcat.jpg"

(pest) phf: yeah, but that's to your point of "one for one", luby explicitly fails the one for one

(pest) asciilifeform: ( e.g. a hypothetical lolcat.jpg that loox unremarkable and may end up distributed on pest nets but somehow takes 1tb of lubyistic chunks to actually move )

(pest) bitbot[asciilifeform]: Logged on 2023-02-03 12:23:22 asciilifeform[4]: so, for instance, does 'prng fails linear complexity test' imply that one can construct a luby payload that will never properly send (i.e. some blox systematically avoided) ? or 1 that takes 10x the expected # of chunks to send..?

(pest) phf: http://logs.bitdash.io/pest/2023-02-03#1022196 << from reading luby ideal selection is not random, but follows some kind of fancy distribution. i imagine oc is similar

(pest) asciilifeform: so, for instance, does 'prng fails linear complexity test' imply that one can construct a luby payload that will never properly send (i.e. some blox systematically avoided) ? or 1 that takes 10x the expected # of chunks to send..?

(pest) asciilifeform: phf: as asciilifeform understands, from pov of lubyism (rather than cryptographic context) all statistical failures of prng 'are same thing'

(pest) asciilifeform: http://logs.bitdash.io/pest/2023-02-03#1022167 << afaik non-ideal prng, in context of lubyism, simply gives less-than-ideal 'mileage' (excluding the case of a catastrophically-broken prng, e.g. with laughably short period; there, could fail entirely to send $block)

(pest) asciilifeform: aint the ~whole point of lubyism to make order (as well as loss of some arbitrary %) not matter ?

(pest) asciilifeform: even if can make good guess somehow that packet p is part of a luby stream -- has nfi what part

(pest) signpost[cgra]: but I'd think the lubystreams would look different from the outside. constant packet spray, variable time between packets

(pest) signpost[cgra]: yeah, I guess you'd have to know some luby-farts are going on at all, before deciding to drop the easiest to generate

(pest) bitbot[cgra|asciilifeform]: Logged on 2023-02-02 10:13:12 asciilifeform[4]: will note tho that he did not have notion of stuffing lubyism decoder per se into fpga; rather, to use the latter as a pass-through packet filter, with regular comp receiving valid packets strictly

(pest) asciilifeform will note tho that he did not have notion of stuffing lubyism decoder per se into fpga; rather, to use the latter as a pass-through packet filter, with regular comp receiving valid packets strictly

(pest) asciilifeform ftr not has atm even faintest clue re what kinda prng would work best for lubyism. ( aside from obv., e.g. 'need reasonably long period' and 'not ruinously cpu-costly' )

(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) 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) 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: (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) 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?

(asciilifeform) asciilifeform: gregorynyssa: see also .

(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: !#s luby

(trilema) a111: 57 results for "luby", http://btcbase.org/log-search?q=luby

(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: luby has one.

(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) a111: 29 results for "luby", http://btcbase.org/log-search?q=luby

(trilema) trinque: !#s luby

(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) a111: 22 results for "luby", http://btcbase.org/log-search?q=luby

(trilema) trinque: !#s luby

(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.

| →