asciilifeform: suggests that the typical shitcoin-of-the-day nowadays is a bch-style phork, rather than 2013-style 'prb with genesis swapped'

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: 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: conceivably, these could be forkcoin noades behind a nat

asciilifeform: ^ also not a public noad of any description

asciilifeform: can think of it as simply a very long untappable wire.

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: 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: this does cost you a certain amount of bandwidth, but imho is necessary.

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 )

asciilifeform: ( they're , what, a few bux ea. )

asciilifeform: but even with ordinary one, it aint much of a problem, just be sure to get the fillers started ~before~ current pad runs dry.

asciilifeform: and for point-to-point link, e.g., shell, can last for a good while ( i dun think i've put 1 whole GB through a shell in the past yr... )

asciilifeform: this kinda thing is 1 obvious application for a quality rng ( dun even have to be blazing fast rng, an ordinary FG handily fills a 1G card in ~week or so )

asciilifeform: they're a standard item, common in laboratory/industrial automation etc

asciilifeform: 1 of the things i like about otp box is that it is trivial to verify that it functions as specified ( can plug in a pad with known contents, throw in known plaintext, and observe -- with a comp of your choice -- what comes out )

asciilifeform: Mocky: it's an old idea of asciilifeform's -- otptron gets 2 sd slots. fill switch triggers fill-up of both with identical otp. then you fly to bananistan with ~one~ and trade with the other fella for his. then you both have identical xor of pad-a and pad-b, in the respective slots.

asciilifeform: ( nao i'm curious, what, by d00d's lights, is 'full node', and where might one get such a thing ) ☟︎

asciilifeform: meanwhile, in heathen lulz, https://archive.is/B9hHc#selection-9797.129-9817.37 << ye olde lukejr, 'http://therealbitcoin.org (which is NOT a full node, mind you)' ☟︎

asciilifeform: 'and here is where you strap a live snake, to bite-while-you-smite!'(tm)(r)

asciilifeform: i suspect that there is a sane space b/w the classical design and http://btcbase.org/log/2016-09-12#1540775 extremity, simply gotta find what it is. ☝︎

asciilifeform: ( tho quite possibly a FG2 that doubles as an iron otptron, could be a marketable win in itself )

asciilifeform: another pheature i've considered, is to give the thing a sd card slot, so it could fill it straight for otp use. but this is perhaps a bridge too far.

asciilifeform: 1 possible way around this, would be to send the hashes on a separate serial line.

asciilifeform: 1 of the wins from it would be that user could immediately verify that baud rate etc are set correctly, instead of relying on the convenient happenstance that a FG misconfigged serial line will produce low-entropy rubbish (with stuck bits)

asciilifeform: cuz right nao, theoretically, a supplier of e.g. usb-ttl dongles, or even bugged cable, could substitute prng for the FG bits, undetected

asciilifeform: diana_coman: the 1 crackpottery i've considered adding to FG-2, is an 'authenticated' mode, where userland proggy gets ability to verify that rng bits actually came from a particular FG. the way to do it would be to have a keccak salt, printed on the board, and have the thing send , instead of naked bytes, packets, of b0,b1,...bN bytes, followed by keccak(salt, b0,b1,...bn) . could be enabled by jumper setting, conceivably.

asciilifeform: in other noose, 178.238.224.213 ( by all indications, does not contain a public node of any kind ) has been spamming randomly generated blox, incl. to zoolag, at the rate of 5-10 erry sec ☟︎

asciilifeform: in related lulz, '...following his brief sabbatical in which he pledged to shed his abusive tendencies, it's hoped a kinder and gentler Linus is ready to resume his duties. Perhaps not coincidentally, with the return of Torvalds will come a "harassment-free" code of conduct that is now part of the kernel source tree.'

asciilifeform: fabricate it in 1uM or similar 1980s process. package with optical quartz lid , a la old EPROMs, for audit-with-childrens-microscope. ☟︎

asciilifeform: i'ma describe , for the l0gz : ideal cpu for crypto would be something quite like the schoolbook mips.v -- no cache, no branch prediction, no pipeline, no dram controller (run off sram strictly), a set of large regs for multiply-shift , and dedicated pipe to FG (i.e. have single-instruction that fills a register with entropy ) ☟︎

asciilifeform: ( if yer baking asics, incidentally, may as well bake a http://btcbase.org/log/2015-01-22#987731 and get sane cpu ) ☝︎

asciilifeform: what i'd really like is to bake an entire comp, a la rockchip, with FG on board. but this too is in same budgetary ballpark as asic .

asciilifeform: if this were a bake-by-the-thousands product, we could bake asic. but currently this is not realistic imho ☟︎

asciilifeform: right nao, 2 FG ~just barely~ fit in a 1u serv, and it takes adhesive fasteners

asciilifeform: i wouldn't even be opposed to putting usb logic on FG -- but to this very day have not found a sane (i.e. not reflashable via usb) interface ic , aside from the chinese dongles ( which i outboarded, because if a piece can be outboarded -- it oughta, per specificity-of-diddling )

asciilifeform: if x86 pc were a product of sane folx, it'd have rng sockets on mobo...

asciilifeform: mircea_popescu: classical FG also fits very reluctantly in servers, but currently i dun have a good idea re what specifically to do about this ( the 'obvious' pill is to have a pci variant, but ice40 is too small for the necessary logic, which in itself is quite gnarly )

asciilifeform: diana_coman: i actually have 0 objections to 'octet', tho i confess i never suffered from 'bit'-'byte' conflation ( never worked on a box with 7 or 9 bit bytes, e.g. the CDC described in 1st ed k&r -- tho i did work on boxes with odd word lengths, e.g. pic16, where 14bit nonbreakable word... )

asciilifeform: mod6: dun hurry with that one, it's a somewhat exotic knob that isnt of great immediate consequence

asciilifeform: http://btcbase.org/log/2018-10-23#1865261 << incidentally i dun see how these are mechanically distinguishable from a node's pov ☝︎☟︎

asciilifeform: but if anyone observed a longer one ( whether naturally occurring, that i slept through somehow, or artificial on testbed ) i'd like to know.

asciilifeform has been reading noad spew daily since early 2015, finds it difficult to picture having missed such a bomb

asciilifeform: i definitely watched a 60 blox reorg, but this was in pre- trb era

asciilifeform: mircea_popescu: observed on a trb node concretely ?

asciilifeform: afaik this is not a test that has actually happened in trb history ( longest naturally-occurring reorg since trb first saw use in the battlefield was, iirc, 8 blox or so ? )

asciilifeform: thinking about it, i can actually conceive of 1 possible constructive use for programmable cements -- testing the reorg mechanism ( i.e. deliberately steer a node into a dead end chain, then restart uncemented and see whether it finds its way back properly ) ☟︎

asciilifeform: the 1 thing it'd do for current, is to give easy means to determine that errybody actually has same blox. but the read-only knob already gives this ( and arguably 'dumpblock' already gave a much slower version of same )

asciilifeform: mircea_popescu: can you personally picture a scenario where you'd want to use this ?

asciilifeform: takes the form of 'makecement' (formerly 'makesnap') command, and corresponding '-setcement' flag that takes a tape on bootup.

asciilifeform: really it's a quite dangerous grenade, if used ineptly. ( i personally would only dare to feed it a tape that came out of own node )

asciilifeform: mircea_popescu: unrelated to anyffing: i have a tentative thing that eats a http://btcbase.org/log/2018-10-20#1864354 and gives trb option of replacing 'checkpoints' with it ( i.e. on boot, tests all already-stored blox against it, and if any blox in the tape are not yet present, then it requests & accepts them and only them, 1 at a time ). do we want this for field use ? (if so i can put on conveyor for cleanup) ☝︎☟︎

asciilifeform: ( tho they had a kitschy 'tienda engleza' thing that sold errything from animal fodder to welder

asciilifeform: there's a lolmart in bananistan?!