asciilifeform: indeed

asciilifeform: or if yer doing voice, 100*10**9 / ((9600 / 8) * 60 * 60 * 24) / 365.0 ~= 2.6 ~years~ of 9600 baud voice, with 100G card.

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: Mocky: e.g. https://www.startech.com/Networking-IO/Serial-over-IP/1-port-RS232-serial-over-ip-adapter~NETRS2321P

asciilifeform: the method where you exchange cards, has 2 wins: it is not enuff for enemy to get copy of simply 1 card, must get one of each ; and rng failure on 1 side doesn't sink you, you get combined reliability of the 2 rng's ( perhaps yours is of 1 type, and other fella's -- another )

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: the ciphertext side can be an off-the-shelf ethernet-to-rs232 box.

asciilifeform: or voice encoder, etc

asciilifeform: Mocky: theoretically dun have to use with an actual comp, can have dumb glass terminal on the plaintext side of each box

asciilifeform: Mocky: idea is that you dun need to transport the unit itself

asciilifeform: ( he did same thing, on his end )

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: didjaknow.

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: ( see, e.g., http://btcbase.org/log/2016-06-10#1480388 thread ) ☝︎

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: ( if it isn't obvious to the reader -- the salt would have to be unique per-board, naturally )

asciilifeform: ( at the cost of occupying 2, rather than 1, serial ports )

asciilifeform: then the primary one could function exactly as the classical FG line did.

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

asciilifeform: would have to actually process the stream before use.

asciilifeform: the obvious down-side, aside from the substantially moar complicated logic, would be that you could no longer dd if=/dev/fg | dieharder etc

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: i'ma let mircea_popescu ponder whether this kind of thing is worth doing ☟︎

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: if receiving end were prb ( which last i knew, still had the 'orphanage' thing ) -- would balloon to fill ram

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: would also have some antifuse rom on-board, with option to run entirely from same.

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 wishes were horses'(tm)

asciilifeform: if could afford asic with ~100k transistors -- could have 256x256 multiplier, have 4096bit constant-spacetime rsa in coupla millisecond...

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: ( plus i ~like~ that it gets made from off-the-shelf components, from strategic pov it is imho superior )

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

asciilifeform: aand there's the usb-ttl thing, which is gnarly

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

asciilifeform: diana_coman: the redesign

asciilifeform: diana_coman: given as you're the leading industrial FG user, perhaps share your pov on the above ?

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: or at the very least , >1 serial port ( the current pizarro boxen, do have rs232 header on mobo, but only one, and at the traditional +/- 12v signal levels, rather than ttl, and i eschew the converters, because they all work by oscillating capacitor pump, hence noisy )

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: http://btcbase.org/log/2018-10-23#1865309 << neato ! ☝︎

asciilifeform: the primary headache of old FG is imho the very modest output rate, which makes the thing take ridiculous length of time to test on my bench

asciilifeform: http://btcbase.org/log/2018-10-23#1865312 << ideally we oughta bake the new one, with ice40 & scintillator, imho ☝︎☟︎

asciilifeform: !Q later tell nicoleci http://btcbase.org/log/2018-10-23#1865327 >> s/Their/There ☝︎

asciilifeform: nao possibly i never suffer from this because i very rarely refer to bits explicitly

asciilifeform: in own proggies, i like using explicitly-bitted types, e.g. Unsigned_8 in http://btcbase.org/patches/udp_genesis#L441

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: happy beaching, mircea_popescu

asciilifeform: rare, but otoh 'nobody cancelled' .

asciilifeform: indeed. sorta why they're of interest, imho, as 'corner case'.

asciilifeform: mod6: afaik errybody already runs with the flag. and switching it off dun do anyffing useful, quite the contrary

asciilifeform: but thats all i had on ml in recent times

asciilifeform: mod6: there was earlier one that prints who gave blox

asciilifeform: simply dumps block hashes, without racking up ssd wear as dumpblock/hash/erase to do same job would

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

asciilifeform: mod6: congrats

asciilifeform: i have not observed this on trb to date, but it is precisely the q i was posing, whether can happen ( i.e. reorg logic fails ) in some possible alignment of planets.

asciilifeform: i.e. perma-wedge ?

asciilifeform: 'locked' implies that reorg logic failed ?

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: afaik to date trb demonstrably did Right Thing on reorg of arity 6 ( july '15 incident )

asciilifeform: they happen erry coupla wks on zoolag, but are almost always of arity 1

asciilifeform: mircea_popescu: was asking specifically re events that trigger reorg logic ( as seen in http://btcbase.org/patches/asciilifeform_aggressive_pushgetblocks/tree/bitcoin/src/main.cpp#L1028 ), with arity defined as the length of the eventually discarded forklet chain

asciilifeform brb

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

asciilifeform: mircea_popescu: if you still have the 100blox log spew on tape somewhere, would like to see..

asciilifeform: http://btcbase.org/log/2015-07-04#1187403 << detail. ☝︎

asciilifeform: hm, loox like was only 6 .

asciilifeform: there was the 2015 lulzfest, http://btcbase.org/log/2015-07-04#1186479 , but iirc that summed to sad chain ~dozen blox long ☝︎

asciilifeform: iirc it came from one of those idjit gavin cataclysms

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

asciilifeform: cuz i can't say that i have, on my watch

asciilifeform: mircea_popescu: observed on a trb node concretely ?

asciilifeform bbl,meat

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: of course, removing the checkpoints thing entirely would give this also. ( i dun recall if anyone ever gave convincing case for whether they oughta stay or go, and if stay, wai not selectable )

asciilifeform: ( currently, this is ~impossible )

asciilifeform: seems that he wanted to test whether trb's miner component actually worked.

asciilifeform: aaah found it : http://btcbase.org/log/2017-01-03#1595868 ☝︎

asciilifeform: mircea_popescu: iirc ben_vulpes had an experiment that demanded custom 'checkpoints' but i do not nao recall what it was ( and can't seem to turn up in l0gz )

asciilifeform: ( wonder why it even needs py3.. )

asciilifeform: !Q later tell trinque http://p.bvulpes.com/pastes/dI29G/?raw=true << very peculiar barfology from existing ( same tarball i successfully used for s.mg box ) cuntoo. sat for 4 hrs, built both gcc's, etc., then ended with this.

asciilifeform: ah lol yes

asciilifeform: which

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: $item pertains strictly to current-day trb