asciilifeform: Mocky: come to think of it, the FG algo is applicable: the endpoint who speaks first, gets to be 'left', and the one who ack's first -- 'right'.☟︎
asciilifeform: ( the FG master/slave mechanism is only used in test benching )
asciilifeform: now, for an erryday piece of critical gear like otptron, i'd prefer an algo that ~provably~ terminates with correct (i.e. opposite polarity) pair, rather than 'oh it never ties in practice cuz no 2 crystals are exactly same' thing.
asciilifeform: sorta like the ancient algo where two boys hold a stick and break it
asciilifeform: Mocky: relatedly to 'who's top' algo , you may find the method illustrated in FG to be of interest, http://btcbase.org/patches/fg-genesis/tree/fg.v#L269 ( tldr : it's a straight 'foot race', and, for physical reasons, never ends in a 'tie' in practice )
asciilifeform: mod6: dun burn much time on it, i suspect there is nothing much of interest ( they break some of the protocol format, but not, as far as i can tell, to any interesting end )
asciilifeform: mod6: lemme know if you see sumthing interesting that i missed. but seems to me that my earlier hypothesis holds, they were forkolade noades.
asciilifeform: kilometre of crapola, streamism, variablelengthstringism, etc
asciilifeform: bvt: you'll find that the gnat-specific packages are ~entirely liquishit -- check out what passes for 'gnat.sockets' for instance.
asciilifeform: when we get own sane os, can reimplement on ~that~ . but under unixlike, stuck with .c thing
asciilifeform: bvt: thing is, there's a non-negotiable must-have subset of posix, that ~cannot~ be implemented as pure ada. e.g. the udp structs liquishit. or , as we learned from bvt , open()
asciilifeform: Mocky: i can think of several algos for reliably picking 'left' and 'right' without any manual config ( recall, 'a' and 'b' have the cards slotted in, in opposite orders, call'em pad 'x' and 'y' , 'a' has x-y and b y-x -- both get same final xor, x xor y, is used as pad p )
asciilifeform: the .c absolutely gotta be bug-free tho, or it sinks yer whole proggy☟︎
asciilifeform: imho, segregating as much as possible of unix liquishit in a short .c, is cleaner than buncha Import() and hardcoded flag constants derived by guesswork
asciilifeform: my orig attempt at the udp thing tried to stick with purely pragma Import(...), but the result was definitely not portable, and so i rewrote it like-so
asciilifeform: if it weren't for struct sockaddr_in..., struct in_addr..., i'd've simply imported the calls via pragma Import(C, ... )
asciilifeform: there is afaik no clean way of portably eating the ridiculous c structs without actually including a .c component.
asciilifeform: but currently seems to me that it is impossible to write a portable proggy that uses open() without a .c that #include's the system's flags
asciilifeform: prolly at some point we'll unify these and others
asciilifeform: bvt: i have a variant of this in ffa, and yet another subset in mmap
asciilifeform: my mmap thing was originally c-free (aside from a coupla imported, adatronically, calls) but apparently will have to include a .c simply for open(), to be portable.
asciilifeform: with culprit being the assumption of standard open() flags
asciilifeform: bvt: search turned up plenty of folx on the net wondering why their $proggy (all kinds) dun go on mips
asciilifeform: my mmap thing, which i've mostly finished rework to prepare for genesis, demands open(), mmap cannot eat fopen()
asciilifeform: it is not possible to get away without open() in a nontrivial proggy on unixlike
asciilifeform: bvt : i'ma have to implement something to make calls to open() portable, cuz this is riotously ridiculous
asciilifeform: tldr : the shitcoin people are in fact pretending to compatibility with ordinary btc protocol; even going as far as using unchanged version strings, and backdated block timestamps ( of course trb rejects the liquishit in O(1) , but it is entertaining )
asciilifeform: briefly revisiting http://btcbase.org/log/2018-10-23#1865463 >> nobody noticed the omission, but i oughta've pointed out that 'a' and 'b' gotta proceed from opposite ends of the pad, when sending, otherwise risk collision☝︎☟︎
asciilifeform: i suspected shitfork, when realized that the 501 blox gotta be a few kB most, ea. -- my pipe couldn't disgorge 501 human-sized blox in <2sec☟︎
asciilifeform: offers approx same ev as hunting rats in sewer for their skins
asciilifeform: ( bullet still costs a day's work, or so, to set up shitnode-of-the-day, then find some exchange where it can even be traded , etc )
asciilifeform: and they live, live, cuz not in fact worth the bullet
asciilifeform: suggests that the typical shitcoin-of-the-day nowadays is a bch-style phork, rather than 2013-style 'prb with genesis swapped'
asciilifeform: i gotta wonder nao, if prb's tx checker is porous enuff that it actually relays these !
asciilifeform: wtf this idjit is doing connecting to trb noadez, is anybody's guess.
asciilifeform: 'The installation is a three-by-three-meter replica of steel and wood reproducing the coin minting machine used by Spanish settlers in the gold and silver mines of Potosí, (Bolivia). The mill mints physical coins that are automatically registered in a blockchain...' blah blah
asciilifeform: as for *213 : behold : answer to this bermuda triangle : https://archive.is/9j7vx#selection-5463.0-5525.29 << tardstalk : 'interesting thing! a creativecoin clone ( with strange ico: real coins vs virtual coins ) ... if you want to add me: addnode=178.238.224.213:12358' etc etc
asciilifeform: defo seems to be a misconfigured/maliciously-configged shitfork noad, none of the tx hashes in the inv's line up with anything from human planet☟︎
asciilifeform: update : so far only buncha addr's, getdata's, inv's, from *176, in the glue trap.
asciilifeform: i'ma leave a tcpdump -w fuckwads.pcap -i eth0 "host 165.227.138.176" or "host 178.238.224.213" running on zoolag
asciilifeform: would be interesting to learn wtf is inside those blox. but i dun currently have the box configured to save liquishit ( no conceivable disk would suffice )
asciilifeform: ( tho traditionally these have some means of sticking with their own kind, possibly this has changed )
asciilifeform: conceivably, these could be forkcoin noades behind a nat
asciilifeform: BingoBoingo: 'It validates completely validates blocks and transactions' ?
asciilifeform: ( specifically: need to carry pads often (not any moar, carry 1TB disk etc ) ; reuse of pad ( nomoar, burn each block after use ) ; shit rng (nomoar, we have decent rng ) )
asciilifeform: and modern tech makes it possible to avoid the traditional fatal boojums connected with otpism.
asciilifeform: Mocky: it dun replace rsa, you can't sign with it, or speak to >1 counterparty . but imho has its uses
asciilifeform: can think of it as simply a very long untappable wire.
asciilifeform: imho the synchronous variant is preferable, when the underlying physical link permits it .
asciilifeform: in an asynchronous scheme, you gotta explicitly divide the pad in halves, one for a->b and one for b->a, so as to exclude any possibility of either end making use of a block of pad that may have already been made use of by other side meanwhile.☟︎
asciilifeform: nao if you really must have an asynchronous link ( for e.g. delivery on carrier pigeons, or somesuch ) you can have sequence #s. but still must have authenticator mechanism similar to above, or enemy can force your pad forward by sending crapola.
asciilifeform: each side obtains proof that the other actually received and correctly decrypted a block, prior to sending another.
asciilifeform: the idea being, that nobody lacking a copy of the pad can cause you to wind yours forward.☟︎
asciilifeform: correct, you need a sram big enuff to hold 2 blox.
asciilifeform: the link, being a physical object, can be disrupted by enemy, but there's nuffin anybody without a copy of the pads can productively do to the traveling bits.
asciilifeform: simple scheme, for example: 512 byte pad blocks; 1st 64 bytes are reserved for a-b keccak salt, last 64 bytes -- b->a salt, 384 in the middle for payload pad. say 'a' starts the convo: sends c = 384byte-plaintext xor 384byte pad . followed by h = keccak(a->b salt + c ). then he expects an ack in the form of keccak(b->a salt + c ) before he winds forward to next block.
asciilifeform: what's a disconnect in this context ?
asciilifeform: that way you dun have to send block #s, or to risk the endpoints getting out of sync.
asciilifeform: i.e. nothing is sent until prev block ack'd
asciilifeform: Mocky: you'd want the link to be fully synchronous
asciilifeform: this does cost you a certain amount of bandwidth, but imho is necessary.
asciilifeform: you only decrypt and wind forward the pad if the auth hash matches the expected one for the block salt.
asciilifeform: that way you can reject rubbish, if somehow enemy is able to send you any
asciilifeform: the 1 slightly subtle devil in the details, is that you gotta authenticate incoming data, or enemy can force you to burn your pad by sending rubbish. fortunately there are several easy ways of doing this ( the most obvious, is to use a small piece of each block as a hash salt, and send keccak(salt+ciphertext) after each N bytes of ciphertext )
