Forum logs for 23 Oct 2018
| mircea_popescu: | money kinda cancelled, but yeah | [00:31] |
| mircea_popescu: | http://trilema.com/forum-logs-for-22-oct-2018#2489002 << they aren't but bad peer set can produce it also, and often enough does. | [00:32] |
| 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 | [00:32] |
| mircea_popescu: | http://btcbase.org/log/2018-10-23#1865276 << don't waste your time with that, let it emerge naturally. | [00:35] |
| 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. | [00:35] |
| mircea_popescu: | every time we notice same answer is given to repeated question, we note it down. before, what's the use ? | [00:35] |
| mircea_popescu: | sit there try to come up with imaginatioins of future people seems a waste of your time. | [00:35] |
| mircea_popescu: | http://btcbase.org/log/2018-10-22#1865206 << yes. | [00:39] |
| 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 | [00:39] |
| mircea_popescu: | entirely nonfeature. | [00:39] |
| 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. | [02:05] |
| mircea_popescu: | neat! | [02:07] |
| bvt: | thx | [02:18] |
| mircea_popescu: | "While the FG shop has been closed for quite some time already," asciilifeform think we should bake a new set ? | [02:19] |
| mircea_popescu: | diana_coman re http://ossasepia.com/2018/10/18/smg-comms-chapter-3-packing-serpent/#selection-85.346-85.466 wouldn't it be better to have a single style for this ? | [02:30] |
| 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!) | [02:31] |
| 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 ? | [02:31] |
| diana_coman: | mircea_popescu, what would the style be there? | [04:13] |
| 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 | [04:14] |
| mircea_popescu: | i dunno, make everything a byte ? or an octet | [04:32] |
| mircea_popescu: | ie, have some tmsr-wide meta-types. | [04:32] |
| 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!" | [05:46] |
| 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 | [05:47] |
| 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) | [05:54] |
| diana_coman: | than->that | [05:54] |
| 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 | [07:02] |
| a111: | Logged on 2018-10-19 21:27 asciilifeform: whatever happend to http://summaries.logs.esthlos.com btw | [07:02] |
| mircea_popescu: | hm. | [09:18] |
| deedbot: | http://bimbo.club/?p=64 << Bimbo.Club - TMSR Log Summary - 10/19/2018 | [09:19] |
| 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. | [09:19] |
| 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 | [09:27] |
| mircea_popescu: | yeah. i guess a history of c cultural sadness is showing in my preoccupatons huh. | [09:29] |
| mircea_popescu: | a well, what can you do | [09:29] |
| mircea_popescu: | aaactually, ill tell you what i can do : im going to teh beach. back thurs or some shit! | [09:30] |
| diana_coman: | ahaha, that's the spirit: when C strikes, go to the beachz! | [09:31] |
| diana_coman: | have fun | [09:31] |
| asciilifeform: | happy beaching, mircea_popescu | [09:31] |
| 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... ) | [09:32] |
| asciilifeform: | in own proggies, i like using explicitly-bitted types, e.g. Unsigned_8 in http://btcbase.org/patches/udp_genesis#L441 | [09:33] |
| diana_coman: | asciilifeform, it's like a 1ms internal, perceptible interpreting-slowdown every time I meet bit/byte | [09:34] |
| diana_coman: | not exactly confusion, just ...stumble I guess | [09:34] |
| diana_coman: | and yes, octet is defined in smg.comms as unsigned_8 ofc | [09:34] |
| asciilifeform: | nao possibly i never suffer from this because i very rarely refer to bits explicitly | [09:34] |
| diana_coman: | (I just don't want to carry about Interfaces.Unsigned_8 everywhere) | [09:35] |
| diana_coman: | not to mention that I think it is actually saner to have local names for types used | [09:35] |
| BingoBoingo: | Enjoy the beach | [09:37] |
| asciilifeform: | !Q later tell nicoleci http://btcbase.org/log/2018-10-23#1865327 >> s/Their/There | [09:40] |
| a111: | Logged on 2018-10-23 13:19 deedbot: http://bimbo.club/?p=64 << Bimbo.Club - TMSR Log Summary - 10/19/2018 | [09:40] |
| lobbesbot: | asciilifeform: The operation succeeded. | [09:40] |
| asciilifeform: | http://btcbase.org/log/2018-10-23#1865312 << ideally we oughta bake the new one, with ice40 & scintillator, imho | [09:44] |
| 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 ? | [09:44] |
| 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 | [09:45] |
| asciilifeform: | http://btcbase.org/log/2018-10-23#1865309 << neato ! | [09:47] |
| 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. | [09:47] |
| 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 ) | [09:49] |
| asciilifeform: | if x86 pc were a product of sane folx, it'd have rng sockets on mobo... | [09:58] |
| 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 ) | [10:00] |
| 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 ) | [10:02] |
| asciilifeform: | diana_coman: given as you're the leading industrial FG user, perhaps share your pov on the above ? | [10:03] |
| diana_coman: | asciilifeform, so far it's been mainly use-in-testing, what can I say what is it you'd need feedback on? | [10:05] |
| asciilifeform: | diana_coman: the redesign | [10:05] |
| asciilifeform: | right nao, 2 FG ~just barely~ fit in a 1u serv, and it takes adhesive fasteners | [10:06] |
| diana_coman: | I can't say that I see a clear suggestion on how to solve that though | [10:08] |
| asciilifeform: | aand there's the usb-ttl thing, which is gnarly | [10:08] |
| diana_coman: | myeah, that's about the main current pain from my pov | [10:08] |
| asciilifeform: | if this were a bake-by-the-thousands product, we could bake asic. but currently this is not realistic imho | [10:09] |
| asciilifeform: | ( plus i ~like~ that it gets made from off-the-shelf components, from strategic pov it is imho superior ) | [10:09] |
| diana_coman: | so far the FGs are one of the relatively few things that I positively like having to deal with! | [10:11] |
| 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 . | [10:12] |
| diana_coman: | I rather think we'll get there one day not yet though | [10:15] |
| asciilifeform: | ( if yer baking asics, incidentally, may as well bake a http://btcbase.org/log/2015-01-22#987731 and get sane cpu ) | [10:15] |
| a111: | Logged on 2015-01-22 06:26 asciilifeform: whateverthefuck fpga cpu << http://www.cs.utah.edu/~elb/cadbook/Chapters/Chapter13/mips.v << mips. | [10:15] |
| asciilifeform: | if could afford asic with ~100k transistors -- could have 256x256 multiplier, have 4096bit constant-spacetime rsa in coupla millisecond... | [10:17] |
| asciilifeform: | 'if wishes were horses'(tm) | [10:17] |
| 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 ) | [10:19] |
| asciilifeform: | would also have some antifuse rom on-board, with option to run entirely from same. | [10:20] |
| asciilifeform: | fabricate it in 1uM or similar 1980s process. package with optical quartz lid , a la old EPROMs, for audit-with-childrens-microscope. | [10:21] |
| BingoBoingo: | billymg: The CoC situation is lulzier than my reading of it yesterday lead me to believe | [10:56] |
| deedbot: | http://qntra.net/2018/10/manufactured-trannycocist-outrage-over-sqlites-longstanding-benedictine-code-of-conduct-as-coc-incompatibilities-set-up-to-replace-license-incompatibilities-as-top-open-source-drama-fountain/ << Qntra - Manufactured TrannyCoCist Outrage Over SQLite's Longstanding Benedictine Code Of Conduct As CoC Incompatibilities Set Up To Replace License Incompatibilities As Top Open Source Drama Fountain | [11:14] |
| 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.' | [11:22] |
| 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" | [11:27] |
| 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 | [11:40] |
| asciilifeform: | if receiving end were prb ( which last i knew, still had the 'orphanage' thing ) -- would balloon to fill ram | [11:47] |
| 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. | [11:56] |
| 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 | [11:57] |
| asciilifeform: | i'ma let mircea_popescu ponder whether this kind of thing is worth doing | [11:57] |
| 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) | [11:59] |
| 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 | [12:01] |
| asciilifeform: | would have to actually process the stream before use. | [12:01] |
| asciilifeform: | 1 possible way around this, would be to send the hashes on a separate serial line. | [12:03] |
| asciilifeform: | then the primary one could function exactly as the classical FG line did. | [12:03] |
| asciilifeform: | ( at the cost of occupying 2, rather than 1, serial ports ) | [12:03] |
| asciilifeform: | ( if it isn't obvious to the reader -- the salt would have to be unique per-board, naturally ) | [12:07] |
| 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. | [12:11] |
| asciilifeform: | ( tho quite possibly a FG2 that doubles as an iron otptron, could be a marketable win in itself ) | [12:12] |
| asciilifeform: | ( see, e.g., http://btcbase.org/log/2016-06-10#1480388 thread ) | [12:16] |
| a111: | Logged on 2016-06-10 18:07 asciilifeform: calc 10**12 / ((9600 / 8) * 60 * 60 * 24) | [12:16] |
| 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. | [12:18] |
| a111: | Logged on 2016-09-12 22:47 mircea_popescu: comes alive at night and fucks your wife. | [12:18] |
| asciilifeform: | 'and here is where you strap a live snake, to bite-while-you-smite!'(tm)(r) | [12:18] |
| 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)' | [13:07] |
| asciilifeform: | didjaknow. | [13:08] |
| asciilifeform: | ( nao i'm curious, what, by d00d's lights, is 'full node', and where might one get such a thing ) | [13:11] |
| 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 | [13:14] |
| 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. | [13:15] |
| Mocky: | yup, or fill two over lunch together and each walk away with identical copy | [13:16] |
| asciilifeform: | ( he did same thing, on his end ) | [13:16] |
| asciilifeform: | Mocky: idea is that you dun need to transport the unit itself | [13:16] |
| asciilifeform: | Mocky: theoretically dun have to use with an actual comp, can have dumb glass terminal on the plaintext side of each box | [13:17] |
| asciilifeform: | or voice encoder, etc | [13:17] |
| asciilifeform: | the ciphertext side can be an off-the-shelf ethernet-to-rs232 box. | [13:18] |
| 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 ) | [13:19] |
| Mocky: | i'm not familiar with off-the-shelf ethernet-to-rs232 box, but it sounds self explanatory | [13:21] |
| 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 ) | [13:21] |
| asciilifeform: | Mocky: e.g. https://www.startech.com/Networking-IO/Serial-over-IP/1-port-RS232-serial-over-ip-adapter~NETRS2321P | [13:21] |
| asciilifeform: | they're a standard item, common in laboratory/industrial automation etc | [13:21] |
| Mocky: | ah yes, i see the 2 cards angle now | [13:21] |
| 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 ) | [13:23] |
| 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... ) | [13:24] |
| 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. | [13:26] |
| Mocky: | yeah but that card took 2 months for FG x10 to fill, no? | [13:27] |
| asciilifeform: | indeed | [13:27] |
| asciilifeform: | with scintillator FG , at MB/s, faster. | [13:28] |
| 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. | [13:28] |
| Mocky: | yup | [13:28] |
| asciilifeform: | current FG moar than fast enuff, to do 1/year pad flights b/w 2 hypothetical points. | [13:29] |
| asciilifeform: | the 1 missing ingredient, is somebody who actually wants this. | [13:29] |
| asciilifeform: | it is, really, 1970s tech, with the exception of the ssd. | [13:30] |
| asciilifeform: | but even in '90s, with GB disk, could have been easily built. | [13:30] |
| asciilifeform: | the scheme of course lives and dies by the rng but this is common to any form of crypto whatsoever. | [13:31] |
| Mocky: | but also by ensuring material is not ever reused | [13:34] |
| asciilifeform: | Mocky: well yes, you nuke each block on the card prior to xoring plaintext and sending | [13:34] |
| asciilifeform: | and for good measure, use the cards 1ce, cremate'em when empty | [13:34] |
| asciilifeform: | ( they're , what, a few bux ea. ) | [13:34] |
| 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 ) | [13:36] |
| asciilifeform: | that way you can reject rubbish, if somehow enemy is able to send you any | [13:37] |
| asciilifeform: | you only decrypt and wind forward the pad if the auth hash matches the expected one for the block salt. | [13:37] |
| asciilifeform: | this does cost you a certain amount of bandwidth, but imho is necessary. | [13:38] |
| Mocky: | and is block number sent or assumed next available? | [13:41] |
| asciilifeform: | Mocky: you'd want the link to be fully synchronous | [13:42] |
| asciilifeform: | i.e. nothing is sent until prev block ack'd | [13:42] |
| asciilifeform: | that way you dun have to send block #s, or to risk the endpoints getting out of sync. | [13:42] |
| Mocky: | still have to handle unexpected disconnects tho right? | [13:43] |
| asciilifeform: | what's a disconnect in this context ? | [13:43] |
| asciilifeform: | either you get the ack, or you don't | [13:44] |
| Mocky: | ack is sent but never received | [13:44] |
| asciilifeform: | so counterparty retransmits his last ciphered block until he gets it | [13:44] |
| Mocky: | is the last ciphered block stored on disk? | [13:45] |
| asciilifeform: | sram | [13:45] |
| Mocky: | ok, i don't see a hole in it | [13:47] |
| 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. | [13:47] |
| asciilifeform: | imho it's pretty simple. | [13:49] |
| 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. | [13:50] |
| Mocky: | so have to store block you most recently ack'd as well, to detect resend | [13:51] |
| asciilifeform: | correct, you need a sram big enuff to hold 2 blox. | [13:51] |
| asciilifeform: | three whole pennies' worth.. | [13:52] |
| Mocky: | hows the ack look like, a hash? | [13:53] |
| asciilifeform: | as described above | [13:53] |
| asciilifeform: | in 'simple scheme, for example..' | [13:53] |
| Mocky: | oh right | [13:53] |
| asciilifeform: | the idea being, that nobody lacking a copy of the pad can cause you to wind yours forward. | [13:54] |
| Mocky: | yeah | [13:55] |
| asciilifeform: | each side obtains proof that the other actually received and correctly decrypted a block, prior to sending another. | [13:58] |
| 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. | [13:59] |
| 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. | [14:01] |
| asciilifeform: | imho the synchronous variant is preferable, when the underlying physical link permits it . | [14:04] |
| Mocky: | the simplicity of otp is appealing, and knowing that no one is sitting on a back door | [14:05] |
| asciilifeform: | can think of it as simply a very long untappable wire. | [14:06] |
| 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 | [14:06] |
| asciilifeform: | Mocky: it dun replace rsa, you can't sign with it, or speak to >1 counterparty . but imho has its uses | [14:06] |
| asciilifeform: | and modern tech makes it possible to avoid the traditional fatal boojums connected with otpism. | [14:07] |
| 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 ) ) | [14:08] |
| asciilifeform: | BingoBoingo: 'It validates completely validates blocks and transactions' ? | [14:08] |
| BingoBoingo: | It's twitter. The only way to win is Trumpisms | [14:09] |
| BingoBoingo: | And the input box is a turd | [14:09] |
| asciilifeform: | lol | [14:09] |
| BingoBoingo: | laggy as fuck | [14:09] |
| * asciilifeform | never used twatter, does not know | [14:10] |
| BingoBoingo: | It's not a vice I can recommend | [14:12] |
| deedbot: | http://qntra.net/2018/10/derps-now-doing-dns-over-https/ << Qntra - Derps Now Doing DNS Over HTTPS | [15:14] |
| 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, | [15:51] |
| jurov: | but at least gmail needs to be told this is not spam. | [15:51] |
| asciilifeform: | jurov: neato ! ty | [15:51] |
| mod6: | jurov: thanks! messages were in my spambox, but did receive. :] | [16:10] |
| 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.' | [16:13] |
| 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)' | [16:13] |
| asciilifeform: | in other lulz: yet another http://btcbase.org/log/2018-10-23#1865380 found, 165.227.138.176 | [16:52] |
| 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 | [16:52] |
| asciilifeform: | same algo, thing shits out 9000 shitblox and dumps at line speed | [16:52] |
| asciilifeform: | ^ also not a public noad of any description | [16:53] |
| asciilifeform: | http://p.bvulpes.com/pastes/4GZTO/?raw=true << raw barfola. observe that NONE of the 'prev' hashes match any known bitcoin block . | [16:56] |
| asciilifeform: | 501 of'em, interestingly | [16:57] |
| asciilifeform: | conceivably, these could be forkcoin noades behind a nat | [16:58] |
| asciilifeform: | ( tho traditionally these have some means of sticking with their own kind, possibly this has changed ) | [16:58] |
| 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 ) | [16:59] |
| mod6: | asciilifeform: i appreciate you passing around the offending ips | [17:03] |
| 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 | [17:05] |
| asciilifeform: | possibly we learn moar later | [17:05] |
| asciilifeform: | or hey, wai not tcpdump -w fuckwads.pcap -i eth0 "net 165.227.0.0/16" or "net 178.238.0.0/16" . | [17:07] |
| mod6: | *thumbsup* | [17:08] |
| asciilifeform: | if anybody notices moar of these, plox to share, so i can add'em to the glue trap | [17:08] |
| mod6: | im grepping my incoming logs for similar, will report if i see sludge | [17:10] |
| asciilifeform: | i admit that i'm pretty curious re just what it is that they're offering up as blox. | [17:10] |
| asciilifeform: | will post the pcap once it fattens up. | [17:12] |
| bvt: | a better write-up on the vpatch temporary file creation: http://bvt-trace.net/2018/10/vpatch-replacing-mktemp3 | [17:41] |
| asciilifeform: | update : so far only buncha addr's, getdata's, inv's, from *176, in the glue trap. | [18:28] |
| 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 | [18:30] |
| 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 | [18:32] |
| 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 | [18:32] |
| asciilifeform: | wtf this idjit is doing connecting to trb noadez, is anybody's guess. | [18:33] |
| asciilifeform: | such... 'creative' | [18:33] |
| BingoBoingo: | lolollolololololocaust | [18:34] |
| asciilifeform: | i gotta wonder nao, if prb's tx checker is porous enuff that it actually relays these ! | [18:35] |
| BingoBoingo: | It could very well be | [18:39] |
| asciilifeform: | suggests that the typical shitcoin-of-the-day nowadays is a bch-style phork, rather than 2013-style 'prb with genesis swapped' | [18:40] |
| asciilifeform: | and they live, live, cuz not in fact worth the bullet | [18:41] |
| 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 ) | [18:41] |
| asciilifeform: | offers approx same ev as hunting rats in sewer for their skins | [18:43] |
| 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 | [18:46] |
| BingoBoingo: | [emoji: watermelon running from Baltimore native] | [20:22] |
| BingoBoingo: | In other barometers: https://www.elobservador.com.uy/nota/estudiantes-de-magisterio-denuncian-comentarios-homofobicos-y-racistas-de-profesora-20181023185258 | [22:31] |
| billymg: | http://btcbase.org/log/2018-10-23#1865377 << BingoBoingo: nice. imo it's a great way to respond. "oh a CoC? why yes, great idea! in fact let's take it one step further" -- a sort of embrace, extend, extinguish strategy | [23:49] |
| a111: | Logged on 2018-10-23 15:14 deedbot: http://qntra.net/2018/10/manufactured-trannycocist-outrage-over-sqlites-longstanding-benedictine-code-of-conduct-as-coc-incompatibilities-set-up-to-replace-license-incompatibilities-as-top-open-source-drama-fountain/ << Qntra - Manufactured TrannyCoCist Outrage Over SQLite's Longstanding Benedictine Code Of Conduct As CoC Incompatibilities Set Up To Replace License Incompatibilities As Top Open Source Drama Fountain | [23:49] |
Category: Logs
