| 12:29 |
asciilifeform |
$ticker btc usd |
| 12:29 |
busybot |
Current BTC price in USD: $16522.07 |
| |
~ 1 hours 30 minutes ~ |
| 14:00 |
shinohai |
$vwap |
| 14:00 |
busybot |
The 24-Hour VWAP for BTC is $ 16547.90 USD |
| |
~ 1 hours 43 minutes ~ |
| 15:44 |
phf |
did we get too cocky muskbros? |
| 15:45 |
* |
asciilifeform admits that he dunget the ref (aside from possibly the '21 episode where musk&co carried out the latest 'lift exchrate in a plane, then drop it out' ..?) |
| |
~ 20 minutes ~ |
| 16:06 |
phf |
that joke is too dumb for me to explain |
| 16:06 |
asciilifeform |
aite |
| 16:10 |
phf |
i've added multibroadcast, so now my packets are near-realtime. on the other i will probably no longer gain any new insight into udp reliability |
| 16:12 |
phf |
i no longer need to rage over my packets occasionally getting stuck in awt's nursery for 15 minutes |
| 16:12 |
asciilifeform |
a++ |
| |
~ 16 minutes ~ |
| 16:28 |
phf |
http://logs.bitdash.io/pest/2022-10-30#1014626 << is this your latest lisp source/test combo? also is there a third file, where it's an interface poc. ii'll tease it out from tests, but… |
| 16:28 |
bitbot |
Logged on 2022-10-30 03:07:03 signpost: http://paste.deedbot.org/?id=kAql << and tests |
| |
~ 1 hours 39 minutes ~ |
| 18:07 |
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? |
| |
~ 1 hours 35 minutes ~ |
| 19:43 |
signpost |
nah, it's not luby's erasure code. it's the one in the paper I link in this post |
| 19:44 |
signpost |
I've updated the python one quite a bit past where the lisp one currently is. will be posting a subsequent vpatch shortly, which implements file transfer over udp socket, rather than just a toy impl of the encoding/decoding |
| 19:46 |
signpost |
the lisp one's a toy encoder/decoder atop bit-vectors without any send/receive yet, but expresses the algorithm correctly. |
| 19:48 |
signpost |
also would benefit from multiple encode/decode threads. there's zero coordination needed in the encoder to parallelize. in python I'm just calling fork() to do it, since what state is shared is read-only (and decisions on which message blocks to use as inputs to produce a check block are pseudorandom). |
| 19:52 |
signpost |
parallelizing the decoder will be slightly more work, since there's shared mutable state there between workers. |
| 19:52 |
signpost |
can't recall if I had sbcl's atomics in that WIP lisp paste already, but figured these will be useful for that. |
| 19:54 |
signpost |
anyway paper's pretty straightforward, happy to answer any questions about the draft implementations. |
| 19:55 |
phf |
ah shit i'm 2/3 implementing luby |
| 19:56 |
signpost |
iirc that had worse complexity than "online codes". |
| 19:56 |
phf |
complexity in what sense? |
| 19:59 |
signpost |
"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 |
| 19:59 |
signpost |
g n) running time, as compared to linear time for on-line codes |
| 19:59 |
signpost |
" |
| 19:59 |
signpost |
from https://pdos.csail.mit.edu/~petar/papers/maymounkov-bigdown.pdf |
| 19:59 |
signpost |
one of the two linked from blog |
| 19:59 |
phf |
ah ty |
| 20:00 |
signpost |
yw, the "bigdown" paper is what excited me about this algo most. |
| 20:00 |
signpost |
intersting not just for "decentralized torrent" but also "achieve wide distribution of this byte-array under heavy ddos" |
| 20:01 |
signpost |
or jammed radio. oughta work for extremely lossy channels as well as marginally lossy, just with lower (but predictable) bandwidth |
| 20:02 |
signpost |
or asciilifeform's "noise-floor" radio of old threads. |
| 20:03 |
phf |
http://logs.nosuchlabs.com/log/pest/2022-12-30#1020024 << are you packing your blocks in pest-like packets? |
| 20:03 |
signpost |
yup, of ~400byte |
| 20:03 |
signpost |
udp |
| 20:04 |
phf |
with the common prelude? nonce, bounces, version, command, black encoded? |
| 20:06 |
dulapbot |
Logged on 2022-12-30 19:42:59 signpost[asciilifeform]: I've updated the python one quite a bit past where the lisp one currently is. will be posting a subsequent vpatch shortly, which implements file transfer over udp socket, rather than just a toy impl of the encoding/decoding |
| 20:06 |
signpost |
haven't included any of the pest protocol details here. thought is this oc-packet rides inside a kind of direct message. |
| 20:08 |
phf |
right, i guess if you're hacking it into an existing implementation, you just need to provide 428 bytes of message, and e.g. blatta will take care of container |
| 20:09 |
signpost |
yup, that was the thought. next step get it welded into blatta and be able to request hash-identified payload from my peers, have them confirm they have it, then request an oc-stream of particular parameters that I supply (which control the fault-tolerance and difficulty of encode/decode) |
| |
↖ |
| 20:09 |
* |
signpost bbl, tiny hellspawn in gastric distress |
| 20:09 |
signpost |
beloved hellspawn, of course |
| 20:12 |
signpost |
one other thing to mention is that I can learn about the lossiness between myself and my peers by the delta between what I asked for and what I ended up needing from them, in terms of packet count |
| 20:12 |
signpost |
got more than needed, channels less lossy than you thought, can adjust down. got less, more. |
| 20:13 |
phf |
you could just slice it into blatta to send an infinite stream of blocks of some easter egg payload to all your peers at a low frequency, give it a random command id. |
| |
↖ |
| 20:14 |
phf |
i assume online codes share similar properties to luby, you can generate infinite numbers of blocks to do a constant broadcast |
| |
↖ |
| 20:17 |
phf |
an independent reconstruction of easter egg payload will be a poc |
| 20:19 |
phf |
reason is that i'm thinking the bureaucracy around http://logs.bitdash.io/pest/2022-12-30#1019983 3 might put a needless delay on experimentation |
| 20:19 |
bitbot |
Logged on 2022-12-30 20:09:35 signpost: yup, that was the thought. next step get it welded into blatta and be able to request hash-identified payload from my peers, have them confirm they have it, then request an oc-stream of particular parameters that I supply (which control the fault-tolerance and difficulty of encode/decode) |
| 20:25 |
signpost |
http://logs.bitdash.io/pest/2022-12-30#1019989 << yep, that was the justification they gave for the terrible name for the algo, that it's capable of "online" encoding ad infinitum |
| 20:25 |
bitbot |
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 |
| 20:25 |
signpost |
http://logs.bitdash.io/pest/2022-12-30#1019988 << that's fun. yeah, will get this going. |
| 20:25 |
bitbot |
Logged on 2022-12-30 20:13:00 phf[awt]: you could just slice it into blatta to send an infinite stream of blocks of some easter egg payload to all your peers at a low frequency, give it a random command id. |
| |
~ 2 hours 7 minutes ~ |
| 22:33 |
phf |
http://glyf.org/screenshots/luby-success.png successful decode of the second coming by yeats |
| |
~ 1 hours 16 minutes ~ |
| 23:49 |
phf |
signpost, what's the prng you ended up using? |
| |
↖ ↖ |