tmsr - Log 2018-10-23

a111: Logged on 2015-07-04 21:58 mircea_popescu: atm the situation is that block 363730 is forked. one chain, 6 blocks long, proceeds atop a v2 block. the current main chain proceeds from 363730 on v3 blocks.

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

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

mircea_popescu: asciilifeform to be clear, is the idea "node locked on alt chain while main chain goes on a lot of blocks" or "node on a lengthy orphan chain" ? ☟︎

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: they happen erry coupla wks on zoolag, but are almost always of arity 1

asciilifeform: afaik to date trb demonstrably did Right Thing on reorg of arity 6 ( july '15 incident )

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

a111: Logged on 2018-10-23 01:37 mircea_popescu: asciilifeform to be clear, is the idea "node locked on alt chain while main chain goes on a lot of blocks" or "node on a lengthy orphan chain" ?

asciilifeform: 'locked' implies that reorg logic failed ?

asciilifeform: i.e. perma-wedge ?

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: mod6: congrats

mod6: Gotta catch up on l0gz and the rest. In particular, I'm just about nowhere on my task of creating answers to FAQs/Common Questions about the Foundation itself. I'll be working on that this week as a main priority - will post what I have for review/comments/corrections in #trilema by end of weekend. ☟︎☟︎

mod6: asciilifeform: thanks for your recent submissions to the ML. I'll get to reviewing those as soon as I can.

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

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

mod6: Oh, my bad, there was just one. For some reason, I thought that I read there were two.

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

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

mod6: The creation of a keccak trb tree is still on the to-do list; however, one thing kinda proceeds that item for me - a review / testing of keccak implementation. I've never had a chance to do that yet, and I think it's important.

mod6: Meanwhile... my node is happily eating blocks to catch back up. On block 64 of 85. Will be a few days yet, I'm certain.

a111: Logged on 2018-10-22 22:44 asciilifeform: relatedly, mod6 et al, i suggest abolition of '-verifyall' flag, it should really be permanently welded on, bypassing sig tests doesn't win ~anyffin in so far as i can tell

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

a111: Logged on 2018-10-22 23:17 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: indeed. sorta why they're of interest, imho, as 'corner case'.

asciilifeform: rare, but otoh 'nobody cancelled' .

mircea_popescu: http://btcbase.org/log/2018-10-23#1865268 << they aren't ; but bad peer set can produce it also, and often enough does. ☝︎

a111: Logged on 2018-10-23 01:48 asciilifeform: http://btcbase.org/log/2018-10-23#1865261 << incidentally i dun see how these are mechanically distinguishable from a node's pov

a111: Logged on 2018-10-23 01:51 mod6: Gotta catch up on l0gz and the rest. In particular, I'm just about nowhere on my task of creating answers to FAQs/Common Questions about the Foundation itself. I'll be working on that this week as a main priority - will post what I have for review/comments/corrections in #trilema by end of weekend.

mircea_popescu: every time we notice same answer is given to repeated question, we note it down. before, what's the use ? ☟︎

mircea_popescu: sit there try to come up with imaginatioins of future people seems a waste of your time.

bvt: hi, i have mp-wp set up now: http://bvt-trace.net/2018/10/instead-of-hello-world-fg-tests/ . I will publish writeup and updated vpatch for vpatch later today. ☟︎

mircea_popescu: "While the FG shop has been closed for quite some time already," asciilifeform think we should bake a new set ? ☟︎

mircea_popescu: slowly but surely a republican ada style manual is shaping up (and through the exact http://btcbase.org/log/2018-10-23#1865304 process, at that!) ☝︎☟︎☟︎

a111: Logged on 2018-10-23 04:35 mircea_popescu: every time we notice same answer is given to repeated question, we note it down. before, what's the use ?

diana_coman: on one hand libs on their own should logically have their own types; on the other hand, when they are used as part of a bigger project, it makes sense I think to make their types subtypes - where they fit/are the same

diana_coman: hm, theoretically the byte is standard but there is the bit/byte confusion issue and moreover I really find octet easier on brain as it directly points at "it's eight bits!"

diana_coman: that being said, names are one thing, definition of the types another: i.e. every packet and project still needs to define/have defined somewhere the types it uses

diana_coman: ftr I quite like the neat way in which asciilifeform defined those basic types in FFA; however, he went for the classical types so byte, nibble ; and I find octet SO much easier than I'm reluctant to give it up in my code (though all it takes is anyway a "subtype Octet is Byte" at top if Byte definition is to be adopted)

esthlos: http://btcbase.org/log/2018-10-19#1864316 << apologies alf, I'm running behind! trying to gather time to get caught up in the next week or two ☝︎

a111: Logged on 2018-10-19 21:27 asciilifeform: whatever happend to http://summaries.logs.esthlos.com btw

mircea_popescu: diana_coman i can see it ; i like octet also, but yeah, can't start forcing this cultural issue on people. a one line define i guess only reasonable approach at this point.

diana_coman: yes; basically Ada makes it easy enough to not have to force anything; funny how Ada is in fact *very* accommodating - where it makes sense to be

mircea_popescu: yeah. i guess a history of c cultural sadness is showing in my preoccupatons huh.

mircea_popescu: aaactually, ill tell you what i can do : im going to teh beach. back thurs or some shit!

asciilifeform: happy beaching, mircea_popescu

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: in own proggies, i like using explicitly-bitted types, e.g. Unsigned_8 in http://btcbase.org/patches/udp_genesis#L441

diana_coman: asciilifeform, it's like a 1ms internal, perceptible interpreting-slowdown every time I meet bit/byte

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

diana_coman: not to mention that I think it is actually saner to have local names for types used

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

a111: Logged on 2018-10-23 13:19 deedbot: http://bimbo.club/?p=64 << Bimbo.Club - TMSR Log Summary - 10/19/2018

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

a111: Logged on 2018-10-23 06:19 mircea_popescu: "While the FG shop has been closed for quite some time already," asciilifeform think we should bake a new set ?

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#1865309 << neato ! ☝︎

a111: Logged on 2018-10-23 06:05 bvt: hi, i have mp-wp set up now: http://bvt-trace.net/2018/10/instead-of-hello-world-fg-tests/ . I will publish writeup and updated vpatch for vpatch later today.

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: if x86 pc were a product of sane folx, it'd have rng sockets on mobo...

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: 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: diana_coman: given as you're the leading industrial FG user, perhaps share your pov on the above ?

diana_coman: asciilifeform, so far it's been mainly use-in-testing, what can I say; what is it you'd need feedback on?

asciilifeform: diana_coman: the redesign

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

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

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

asciilifeform: ( plus i ~like~ that it gets made from off-the-shelf components, from strategic pov it is imho superior )

diana_coman: so far the FGs are one of the relatively few things that I positively like having to deal with!

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 yer baking asics, incidentally, may as well bake a http://btcbase.org/log/2015-01-22#987731 and get sane cpu ) ☝︎

a111: Logged on 2015-01-22 06:26 asciilifeform: whateverthefuck fpga cpu << http://www.cs.utah.edu/~elb/cadbook/Chapters/Chapter13/mips.v << mips.

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

asciilifeform: 'if wishes were horses'(tm)

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

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

BingoBoingo: billymg: The CoC situation is lulzier than my reading of it yesterday lead me to believe

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

BingoBoingo: Not really news unless someone involved in the zombie Linus thing comes up with a line like: "but that would put me in the position of editing and redacting Benedict of Nursia, as if I were wiser than he"

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

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

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: 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: would have to actually process the stream before use.

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

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

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

asciilifeform: ( if it isn't obvious to the reader -- the salt would have to be unique per-board, naturally )

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: ( tho quite possibly a FG2 that doubles as an iron otptron, could be a marketable win in itself )

asciilifeform: ( see, e.g., http://btcbase.org/log/2016-06-10#1480388 thread ) ☝︎

a111: Logged on 2016-06-10 18:07 asciilifeform: ;;calc 10**12 / ((9600 / 8) * 60 * 60 * 24)

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. ☝︎

a111: Logged on 2016-09-12 22:47 mircea_popescu: comes alive at night and fucks your wife.

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

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

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

Mocky: sd card slot has merit. for iron otptron even two slots is not going overboard imo if it doesn't overcomplicate the design, since generally will need two copies and may prefer not to plug into general purpose comp

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: ( he did same thing, on his end )

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

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

asciilifeform: or voice encoder, etc

asciilifeform: the ciphertext side can be an off-the-shelf ethernet-to-rs232 box.

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 )

Mocky: i'm not familiar with off-the-shelf ethernet-to-rs232 box, but it sounds self explanatory

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

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

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: 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: 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: indeed

asciilifeform: with scintillator FG , at MB/s, faster.

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: current FG moar than fast enuff, to do 1/year pad flights b/w 2 hypothetical points.

asciilifeform: the 1 missing ingredient, is somebody who actually wants this.

asciilifeform: it is, really, 1970s tech, with the exception of the ssd.

asciilifeform: but even in '90s, with GB disk, could have been easily built.

asciilifeform: the scheme of course lives and dies by the rng; but this is common to any form of crypto whatsoever.

asciilifeform: Mocky: well yes, you nuke each block on the card prior to xoring plaintext and sending

asciilifeform: and for good measure, use the cards 1ce, cremate'em when empty

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

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: that way you can reject rubbish, if somehow enemy is able to send you any

asciilifeform: you only decrypt and wind forward the pad if the auth hash matches the expected one for the block salt.

asciilifeform: this does cost you a certain amount of bandwidth, but imho is necessary.

asciilifeform: Mocky: you'd want the link to be fully synchronous

asciilifeform: i.e. nothing is sent until prev block ack'd

asciilifeform: that way you dun have to send block #s, or to risk the endpoints getting out of sync.

asciilifeform: what's a disconnect in this context ?

asciilifeform: either you get the ack, or you don't

asciilifeform: so counterparty retransmits his last ciphered block until he gets it

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: imho it's pretty simple.

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: correct, you need a sram big enuff to hold 2 blox.

asciilifeform: three whole pennies' worth..

asciilifeform: as described above

asciilifeform: in 'simple scheme, for example..'

asciilifeform: the idea being, that nobody lacking a copy of the pad can cause you to wind yours forward. ☟︎

asciilifeform: each side obtains proof that the other actually received and correctly decrypted a block, prior to sending another.

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: 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: imho the synchronous variant is preferable, when the underlying physical link permits it .

Mocky: the simplicity of otp is appealing, and knowing that no one is sitting on a back door

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

BingoBoingo: <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)' << Has been addressed. Turns out I STILL haven't been banned (likely from not using the thing) https://twitter.com/BBoingo/status/1054795688679272450

asciilifeform: Mocky: it dun replace rsa, you can't sign with it, or speak to >1 counterparty . but imho has its uses

asciilifeform: and modern tech makes it possible to avoid the traditional fatal boojums connected with otpism.

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: BingoBoingo: 'It validates completely validates blocks and transactions' ?

asciilifeform never used twatter, does not know

jurov: mod6: BingoBoingo: ben_vulpes: asciilifeform: and everyone - therealbitcoin btc-dev mailing list is now working on the Foundation's server. You should have got an announcement,

asciilifeform: jurov: neato ! ty

mats: http://btcbase.org/log/2018-10-23#1865399 << reply from buterin: 'You guys should train users to take an active role in governance and keep their software up to date by having more hard forks.' ☝︎

a111: Logged on 2018-10-23 17:07 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: in other lulz: yet another http://btcbase.org/log/2018-10-23#1865380 found, 165.227.138.176 ☝︎

a111: Logged on 2018-10-23 15:40 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: same algo, thing shits out 9000 shitblox and dumps at line speed

asciilifeform: ^ also not a public noad of any description

asciilifeform: http://p.bvulpes.com/pastes/4GZTO/?raw=true << raw barfola. observe that NONE of the 'prev' hashes match any known bitcoin block .

asciilifeform: 501 of'em, interestingly

asciilifeform: conceivably, these could be forkcoin noades behind a nat

asciilifeform: ( tho traditionally these have some means of sticking with their own kind, possibly this has changed )

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: 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: possibly we learn moar later

asciilifeform: or hey, wai not tcpdump -w fuckwads.pcap -i eth0 "net 165.227.0.0/16" or "net 178.238.0.0/16" .

asciilifeform: if anybody notices moar of these, plox to share, so i can add'em to the glue trap

asciilifeform: i admit that i'm pretty curious re just what it is that they're offering up as blox.

asciilifeform: will post the pcap once it fattens up. ☟︎

asciilifeform: update : so far only buncha addr's, getdata's, inv's, from *176, in the glue trap.

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: 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: '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: wtf this idjit is doing connecting to trb noadez, is anybody's guess.

asciilifeform: such... 'creative'

asciilifeform: i gotta wonder nao, if prb's tx checker is porous enuff that it actually relays these !

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

asciilifeform: and they live, live, cuz not in fact worth the bullet

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: offers approx same ev as hunting rats in sewer for their skins

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 ☟︎