cgra: right
cgra: heh
cgra cgra no doubt himself such a plebe, can't remember when the last time handled a significant amount of cash
cgra: asciilifeform: a finnish plebe is all for e-payment convenience, keeps me wondering how is cash still around
cgra: http://logs.nosuchlabs.com/log/asciilifeform/2022-01-10#1072275 << what kind of towers are these? or otherwise care to elaborate to a noob how to estimate when the cash will be gone?
cgra: right
cgra: ah you mean the temporary solution needs a full rewrite anyway, when a complete pill is found
cgra: asciilifeform: if modifier-click variant sufficed, would the heavy-weight capable completer still similarly remain an obstacle?
cgra: modifier-click variant wouldn't beat that?
cgra: how do you jump between?
cgra: asciilifeform: are you meanwhile using a modifier-click variant or "nothing"?
cgra: asciilifeform: ah ok. that seals the deal
cgra: so while this looks awfully lot close to what you're looking for, a known roadblock will eventually surface?
cgra: asciilifeform: you believe what scrap lies underneath eclipse, belongs necessarily to this group?
cgra: asciilifeform: right. was thinking that maybe this hints it being doable -- doesn't prove though.
cgra: because not always link?
cgra: asciilifeform: well, the link disappears only after mouse leaves the hotspot
cgra: asciilifeform: move mouse on the interesting bit and it turns into a hyperlink under the mouse. you can now click the link if you like
cgra: (tried it out, verified a thing)
cgra: from settings dialog: ""On demand hyperlinks are shown when moving the mouse in the editor while the specified modifier is pressed. The hyperlinks appear on mouse move when no modifier is specified.""
cgra: asciilifeform: just found out that, while eclipse has by default this 'press ctrl and hovering mouse over interesting code bits turns them into hyperlinks', it also allows for the same work ~without any modifier key~
cgra: asciilifeform: in your flow, how do you backtrack link click trail?
cgra: asciilifeform: clicking a link, to start editing it's text, would that be a right-click in your prog?
cgra: one q that comes to my mind is how may such eclipse contraptions be mixed with rich text and graphics. though did asciilifeform find a bare plaintext item worth existing?
cgra: the eclipse youtube links i dug are some random items i didn't even listen to. prolly just fughetabout the whatever rest in them, except for the visual action on exact linked video position
cgra: asciilifeform: find it perhaps worth a deeper dig?
cgra: http://logs.nosuchlabs.com/log/asciilifeform/2022-01-03#1070901 << though, the handful of times i dipped my toe in the java swing gui poop pond, this sounds like it should induce similar reaction (not 100% sure though, whether a swing creation or smth else)
cgra: problem, given jumping to function and variable declarations is another eclipse standard item
cgra: http://logs.nosuchlabs.com/log/asciilifeform/2020-07-03#1015789 << in recent eclipse versions (the java-land behemoth, likely much like intellij idea and netbeans etc) a "live semantic edit" is a thing (no idea how generic tho), as is the usual code-completion. also would guess link navigation is not a
cgra: billymg: ty, sounds promising!
cgra: billymg: is a font (these days?) something you can include in your website and even configure like you suggested, and expect it to work reasonably well for all visitors? i guess it may come down to a target audience -- then let's say at least somewhat technically literate readers
cgra: fwiw, also not sure why would anyone want to fix the (maximum) blog width. why not let the reader decide with his own viewport? (not that i never saw people browsing the net with a maximized window, on a horizontal 16:9 monitor, unaware or mysteriously unwilling of manual viewport adjustment...)
cgra: http://logs.bitdash.io/pest/2021-12-29#1001504 << billymg, my own noob experience re a blog theme: personally i've had the font one pain point. wanted something that has unambiguous oO0lI1 while not fixed-width, and also numbers with uniform height bases (for example, for a font that styles a '3' a bit like a 'g', 2<sup>32</sup> becomes a visual puzzle). haven't completely solved yet the font issue for myself
cgra: for me, for now does what md doesn't and i figured maybe can convert later to smth else with own code, if need be (speaking of which, not clear to this noob at all how to formulate a proper replacement)
cgra: and no idea if helps anything re diagrams
cgra: it may or may not fit your purpose, but at least it appears to properly permit multiple invocations of same footnotes and lets you define anchors you can organize irrespective of section numbering. i don't know if automatic section numbering works, in case you needed that also.
cgra: http://logs.nosuchlabs.com/log/asciilifeform/2021-12-28#1069958 << from a group of apparent, non-ideal options (incl markdown and 'roll your own'), i ended up choosing "reStructuredText" when deciding how to begin drawing down trb picture while eating the c++ spaghetti
cgra: asciilifeform: had to deal with this lump in the spit strain first, now a step closer to discussing sync
cgra: when i was finguring out a reason for a particular strange in trb sync, the git log pre-dating trb genesis proved helpful
cgra: i pulled my copy in summer 2020, so not very close to trb bd.
cgra: ran across this while checking whether anyone ever notarized the prb git log -- speaking of which, does anyone happen to have such an item lying around, ideally created only little after trb birthday?
cgra: whoever might care, re the missing gnupg-1.4.10.tar.gz, an item of equivalent (or greater) value is also recorded here
cgra: http://logs.nosuchlabs.com/log/asciilifeform/2021-12-11#1069027 << 2) is a comparison to previous blocks' timestamps, node's own clock doesn't affect
cgra: re 1) i mean duplicate input, ie. same output of a particular source tx
cgra: does asciilifeform (or anyone else) have a good reason why isn't the peer being banned for pushing bad blocks in the following cases:
cgra: asciilifeform: i'll just make a blog piece of this too, sometime soon(ish)
cgra: setInventoryKnown]["spam guard"]
cgra: http://logs.nosuchlabs.com/log/asciilifeform/2021-12-05#1068777 << what i was contemplating here, was not out-of-order reception of blocks, but the opposite: fix the last out-of-orderism the old 'getblocks, sometimes mixed with new top block adverts' mechanism has. and prevent getting stuck while catching up, because of some block ending up barred by every peers' [http://cgra.net/2021/12/trb-defect-exhibition-oom-and-other-spam#
cgra: though, there's that getdata buffer limit getting hit if you just immediately "AskFor()" every incoming header
cgra: advertise same items more than once
cgra: asciilifeform: dunno why took this long to figure out (myself), but how about using "getheaders" instead of "getblocks" to sync trb? would remove three obstacles: 1) response to "getblocks" may annoyingly have top block(s) in front or in back, 2) "getblocks" doesn't provide clear hint where the blocks belong in the chain (no prevHashes), 3) the "setInventoryKnown" spam guard wouldn't get in the way, because "getheaders" response can
cgra: right
cgra: asciilifeform: happy bd too. is this already a decimal-round figure?
cgra: thimbronion: handle_udp_data()'s debug print threw error if message text contained non-ascii char (bonus: tab indent at end of Server.start(), uneven indent at end of Client.__command_handler())
cgra: thimbronion: blatta 9986 notes, of simple variety. undefined variables: 1) Station.rebroadcast():packet_info, 2) Client.notice_and_privmsg_handler():formatted_message. Missing import: Channel._write_state:tempfile. Last and the least: inside lib, no need to import 'lib.something', plain 'something' works cuz in same scope (+ as a bonus, my IDE wouldn't nag about them)
cgra: (because the bloated peer state i injected, wasn't cleaned up, but kept for extra 15mins)
cgra: that's why didn't die directly on my arrow, but apparently later, from regular work
cgra: seems like vSend's underlying vector was doubling it's capacity in so large blocks that node could still operate within some bounds. only large allocations failing
cgra: asciilifeform: and apparently mostly worked, lotsa "EXCEPTION: St9bad_alloc" there
cgra: asciilifeform: these are mine "getheaders 1 to 0000000000000000000000000000000000000000000000000000000000000000 limit 1050585"
cgra: asciilifeform: when you get to ig, and if logs indicate, try and check whether node's last breath was about ~57MB getheaders responses or something else
cgra: asciilifeform: recipe upcoming in the oom summary
cgra: asciilifeform: the specific mixture here was receive buffer filled with fabricated getheaders messages
cgra: http://logs.nosuchlabs.com/log/asciilifeform/2021-11-26#1067642 << did throw coupla, yesterday or day before. kept sctratching head why didn't kill it... i doubt my poison was this slow
cgra: i thought unix timestamp had smaller than 1-second units, but i was apparently wrong (maybe too much personal oop/spackle stack history).
cgra: http://logs.nosuchlabs.com/log/asciilifeform/2021-11-24#1067443 << blatta message timestamps are integers, in 1-second units, note thimbronion gregory5
cgra: actually, isn't fixed-pointness or an integer just two different ways to look at the same thing, if you adjust the unit accordingly
cgra: http://logs.nosuchlabs.com/log/asciilifeform/2021-11-24#1067416 << my uneducated assumption was pest timestamp is an integer. i'd specify the fixed-pointness and its bit division too in the footnote
cgra: asciilifeform: in the pest timestamp footnote, i'd explicitly specify 1) the epoch and 2) the time unit.
cgra: anyway, just an ack that still intending to finish a summary
cgra: asciilifeform: right! :)
cgra: repeatedly forced to ask yourself how deep do you really want to dig
cgra: signpost: yea... if you have time estimate, you're already wrong -- no reliable estimates exist! :)
cgra: i mean, similar self-shitting as the 'getdata wedge' does
cgra: asciilifeform: my 'within few days' is stretching like thick spit -- cuz this task also is starting to show 'spittoonesque' symptoms. realized getblocks/getheaders works as a DoS weapon, and then upon further investigation, getheaders is showing similar, mysterious node-shitting-itself characteristics.
cgra: moving on with the rest of the dos list
cgra: asciilifeform: np let's fughedaboudit for now, i'll blog it up if it starts to make sense again to me
cgra: asciilifeform: i mean, i know trb ~offers~ that many blocks at a time, it could send in one go
cgra: asciilifeform: i'm referring specifically to my earlier claim -- there's this 2x sendbuffersize thing too. i know trb sends only that many blocks what its sendbuffersize can hold. and also seen how prb streams in 500 block bursts
cgra: so how does A end up banning B then, if no getdata comes from B?
cgra: asciilifeform: if A is catching up blocks, B isn't going to send getdata to A (and trigger the obey_sendbuffersize check), but the other way around. is why i'm confused atm
cgra: i wonder if my brain was revving backwards, when i came up with this, because now i can't find sense in it. did asciilifeform grasp? :P
cgra: yeah
cgra: asciilifeform: swallowing a block even on an intelist box, seconds/piece
cgra: asciilifeform: is 'line rate' assuming other block processing bottlenecks fixed, or hash optimism?
cgra: right
cgra: http://logs.nosuchlabs.com/log/asciilifeform/2021-11-12#1065424 << to be exact, permit the operator to tell node how much recent work reorgable. this seems to me like it's a thing 'operator must operate' like periodic adding to the cement would be. if your comment still applies, can you elaborate?
cgra: interesting point :)
cgra: asciilifeform: i suppose it's something the operator needs to keep an eye on, perhaps a runtime knob?
cgra: asciilifeform: iirc you intended similar for nqb, the line between forever frozen blocks and possibly-reorging blocks
cgra: how about user knob of 'how much work or height to past at most, considered valid'?
cgra: asciilifeform: yeah, should be easy to implement
cgra: just meant as another fill ram/disk DoS
cgra: ah you mean can't fool into inhabiting an altchain, as in to believe were the main chain
cgra: asciilifeform: why has to be connected to perp only?
cgra wears scoopbot mask and: "New post on cgra's: TRB Defect Exhibition - Two DoS Classics"
cgra: what's more, how many of those bad ideas you may replace (if you somehow found a way to isolate them), and still be speaking of trb? i don't necessarily feel qualified to choose.
cgra: beginning to also lean on the #1 feature needing a fix first...
cgra: then i ran into a bunch of DoS issues (about to publish a (partial?) summary soonish), and thought they need a fix. breaking a tooth in a fix attempt made me better understand what asciilifeform meant by 'c++ trb being a life support item': there is a near-complete chain of bad ideas depending on each other -- try and touch one, gotta also change a handful of others, and then handful of further handfuls, and so on. that's why i may be
cgra: when i began trb study, i thought i'd read and document the thing, for easier digestion and reference. and i'd simply cut off every line that didn't do anything meaningful, and see if it got any clearer. then, once i'd feel confident in what i'm doing, start operating a node, a node that would not need a daily baby-sitting. while no end in sight, the plan worked, more or less.
cgra: i also have a mini-review in response to trb/tbf topic at hand:
cgra: i do appreciate coin rewards, but if i ever end up producing significant value for someone, it's up to him to choose how to compliment -- for now, i don't trust myself skill- and engagement-wise to speak of anything too serious, in advance.
cgra: asciilifeform: ok
cgra: asciilifeform: did your test trb box, by any chance, keep a historical ram usage record? if did, how much was the peak in last 45mins or so?
cgra: billymg: ty for the pest logger, wouldn't wanna miss much pest tech talk before possibly joining the fun myself too.
cgra: how many pages?
cgra: asciilifeform: do you have trb on paper?
cgra: asciilifeform: right, just realized maybe your binders come into play here
cgra: asciilifeform: i don't have an acute personal need, but was wondering what kind of torture do emacs users go through when trying to figure out codebases like trb's, if they don't have a cross-referencer
cgra: does a cross-referencer for c++ code exist in the emacs land? something you can track down with: call hierarchies, variable assignments and reads, class hierarchies
cgra: asciilifeform: i'll write, possibly within few days
cgra: asciilifeform: i could detail the specific items at least, for now, if yields any benefit (not to say they're somehow hard to discover -- more like "how come nobody ever mentioned before, or did i miss something?")
cgra: http://logs.nosuchlabs.com/log/asciilifeform/2021-11-03#1063142 << thought i'd try to fix, then slowly ended up feeling was actually trying to sip from another massive "spittoon" here.. possibly what asciilifeform was talking earlier of. may be so that can't just fix those "couple of issues" without re-designing large parts from ground-up
cgra: http://logs.nosuchlabs.com/log/asciilifeform/2021-11-03#1063111 << simply found an apparently working link from mentioned piece's comment section
cgra: asciilifeform: so can view, say, in 120 cols if thrown such a pile at you?
cgra: unless i counted 2+1=4, your numbers seem to add up to about 160 cols, not 80 cols. but yeah, i begin to understand asciilifeform prefers pretty large font, compared to my usual 10-12pt (on 27" 2560x1440).
cgra: http://logs.nosuchlabs.com/log/asciilifeform/2021-10-27#1061975 << i'm starting to getting a feeling it's because similarly want ~80 cols and deeply nested indentation will could seriously cramp things up. or smth else?
cgra: in the series of noob questions, there's another, possibly related: what would make tab indentation superior (in c/c++ context, if nowhere else) to spaces?
cgra: asciilifeform: so if you had a 27" 16:9 vertical display, smth like 22pt font size? when you're rummaging items like trb source, do you ever zoom out?
cgra: http://logs.nosuchlabs.com/log/asciilifeform/2021-10-26#1061941 << how many columns (in reasonably large letter size) does your typical vertical display have?
cgra: http://logs.nosuchlabs.com/log/asciilifeform/2021-10-26#1061867 << i remember as a teen/kid (forgot year exactly) to prefer learning pascal over c/c++, and kept sticking to pascal and thinking why is c++ so damn weird, like 'std::out << "printed text"'
cgra: thanks asciilifeform, verisimilitude and signpost for 80 col comments. personally had already also developed a general feel of around 100-120 col being "most comfortable". now summarized in my own head that need 80-90 col only mostly if want to unconditionally support code on paper.
cgra: asciilifeform: is multipartism going to have a different message format?
cgra: (for completeness, in-between null-byte strings of a warez file also an issue similarly, cuz may coincide last bytes of a pest message payload)
cgra: asciilifeform: thinking beyond pest irc-like messages, is it too early to consider a spot to explicitly encode a message payload size? the actual text content is currently null-terminated, even if upper boundary is defined. say, i wanted to send a warez file. it's size is usually not going to be an exact multiple of pest message payload. and it could end in a string of null-bytes
cgra: thimbronion: zeroed chain values ought to be '"\x00" * 32' instead of '"0" * 32'. the latter yields a '0000...' string, while ought to be a string of null-bytes
cgra: thimbronion: would you perhaps see value in converting 'message object as dict' into a py object in alcuin? would read 'message.command' instead of 'message["command"]' where 'command' highlighted as string constant (throws me off a bit, personally). also perhaps the attribute 'original' would get an explicit default value (tho not far enough in reading to understand whether default actually needed)
cgra: asciilifeform: re portrait-mode display, how many 80cols simultaneously, side by side?
cgra: asciilifeform: do you use paper for book/binder output specifically only, or also office plastered with full source code, for a head-load process?
cgra: noob question inbound...: why should a software author adhere to 80 columns?
cgra: thimbronion: (fwiw, likely not worth mentioning separately: could've also unpacked 'bytes_address_pair' tuple like this: "data,(ip,port) = bytes_address_pair")
cgra: thimbronion: i'm looking at shinohai's publication of alcuin. Server.handle_udp_data()'s 'unknown peer' debug print wouldn't work, because string format args not as a tuple
cgra: asciilifeform: right!
cgra: asciilifeform: if lossy line is manageable, then i suppose skimping on the station hardware also equally manageable, because you could keep a queue of incoming packets and drop some randomly, if queue ever nearing full (ie. running outta cpu juice)
cgra: asciilifeform: "all my buddies say asciilifeform said so" vs "cgra said nebuchadnezzar said asciilifeform said otherwise", kinda fits the 'hearsay' term
cgra: asciilifeform: which part of spec should i look at again, to grasp how the deliberate handle collision would possibly happen, if otherwise issue mitigated by random handles? or, if you can work a simple example for me
cgra: asciilifeform: this 'handle must not collide' kinda got me thinking every Joe must be separately introduced to me before the name carries a specific enough meaning
cgra: asciilifeform: pardon if i missed something, but: where do you end up, if handles aren't "first names of various people" and hence eventually collide, but specify 'must be properly random string min x characters'? -- and perhaps deal with the nicknaming issue on each console's end instead
cgra: asciilifeform: the last time i spent time following your ffa curriculum, i felt a need to go a full cycle before returning to ch1, for a review, and until then gaining a proper grasp. now figured must've been similar for a writer, too... fits-in-head after all
cgra: asciilifeform: or even, how complete per se?
cgra: asciilifeform: how complete was the FFA picture in your head, before published ch1?
cgra: whaack: got it, thanks!
cgra: ah ok
cgra: asciilifeform: ok, thanks! unless whaack gets to do it first (assuming his explorer made it easy for him)
cgra: asciilifeform: my test node (and only node) is one year behind, so i would need someone else to do it
cgra: if yes, could you arrange me a list? those could help me better figuring out the quirks in trb sync mechanism -- i could replace log-file's hashes with height numbers and get a better idea of the order things happen in
cgra: whaack: would you happen to have a handy way to enumerate block hashes, starting from block height 655609, up to the current height? for example, in per-line format: <height> <hex-hash>
cgra: http://logs.nosuchlabs.com/log/asciilifeform/2021-09-07#1056701 << this would be clear as crystal
cgra: http://logs.nosuchlabs.com/log/asciilifeform/2021-09-07#1056648 << does it matter that the pest spec now allows spaces and commas in the channel name? not that i really think the operators weren't soon to find out their irc clients won't cooperate in such cases...
cgra: channel name is specified somewhat incompatible to the irc spec, where three character codes are verboten. (on a side note, i didn't expect irc spec to be that liberal -- newlines or, say, vertical tabs in a channel name?) is this as you intended?
cgra: did you mean ~web~ of trust?
cgra: asciilifeform: a couple of simplistic nitpick attempts re pest_FE
cgra: signpost: re subrate, interesting thing to consider
cgra: i originally ran to this while trying to peer-seed my test node from a single trb node: all i was getting were prb nodes which were banned immediately, and i ended up with a single peer, the seeder
cgra: i was wondering whether most trb nodes were running without malleus_mikehearnificarum, because i saw a lot of prb peers in their "connected" lists. but it's likely, because the trb ProcessMessages() will refresh an outbound addr age already on receiving "version", ie. before the prb peer gets banned. so prb node addrs keep staying fresh, as long as trb don't have 8 outbound peers.
cgra: what trb does though, for what i can tell, reports addrs at most 3h old (measured in "adjustedTime"). trb only updates active outbound peers' addr ages, not inbound. also, when a peer advertises addrs to trb, it will mostly accept the peer-provided addr ages as is, will just add a 2h extra to their age. i dunno if peers do this, but they could advertise 0-age addrs, and they would stay 1h in trb's report set.
cgra: http://logs.nosuchlabs.com/log/asciilifeform/2021-09-04#1056475 << that asciilifeform's original "reported peers" is prolly good, because you wouldn't know about a particular node anyway, despite what is in trb's/prb's/any published code
cgra: billymg: sorry, i must go afk now. i intend to return tomorrow to finish my q or admit hasty conclusion
cgra: ah, yeah
cgra: i might've overlooked something in trb code, last q now pending
cgra: so "connected nodes" here is more like "peers the node knows of"?
cgra: billymg: bitdash.io seems to somehow figure out what peers a node is connected to: like here, section "connected peers". how do you do it? or does it mean smth else?
cgra: PeterL: by me, you may add it to the scoopbot roll, http://cgra.net/feed
cgra: http://logs.nosuchlabs.com/log/asciilifeform/2021-08-17#1052830 << i currently have other plans, but not 100%, so i will keep this in mind, thanks!
cgra: http://logs.nosuchlabs.com/log/asciilifeform/2021-08-17#1052829 << live approximately within a few days, will announce here
cgra: billymg: yeah, i'm meaning to leverage your linkable line numbers heavily! and the colored diff adds clarity nicely
cgra: and littered with links to patch lines
cgra: billymg: i'm trying to annotate a patch. talking code and prose intermingled. thought inline styling of code items would be useful
cgra: billymg: ever run (or expect to eventually) into hand-crank being so much work that a separate tool for the job becomes interesting?
cgra: billymg: i'm a blog noob and i'm experimenting with your mpwp variant. how do you format an article? just hand-crank html, or use some external tool and dump its output to the blog database/edit textbox?
cgra: if nothing else, a handy way to push prb upgrading :)
cgra: asciilifeform: those both points would then make sense to me, especially the former
cgra: http://logs.nosuchlabs.com/log/asciilifeform/2021-08-12#1052413 << re 2) can't see why stop there, when first hole gets plugged. if really want nodes down and stay down. re 1) maybe some version appeared that routinely pulls too hard
cgra: fwiw, judging by the amount of OOM holes in trb, and absence of other issues similar to the 'wedge', seems to me the wedge was just someone pulling blocks in maximum force, for whatever reason, unaware of the lethal side effects. all these added up, obey_sendbuffersize may have been better off not rating such peers for misbehavior
cgra: a possibly interesting consequence is that it adds an extra issue to consider: the already-deployed obey_sendbuffersize nodes when mapping out the trb swamp of protocol ram usage
cgra: asciilifeform: haven't tested this, but i suspect that an obey_sendbuffersize node (A), when catching up blocks, may end up banning peer (B) with >2x the sendbuffersize, if B advertises blocks with full capacity, in response to A's "getblocks"
cgra: http://logs.nosuchlabs.com/log/asciilifeform/2021-08-09#1051577 << whaack sorry, only now noticed your q. i may propose a fix/a set of fixes if capable of producing one, prolly not going to happen very fast anyway
cgra: asciilifeform: ah yes, true. only for the lower priority part
cgra: asciilifeform: anyone-can-spends apparently also throw off prioritization, assuming fee/byte ordering was used
cgra: currently figuring out mempool and trying to grasp 'how should instead'
cgra: asciilifeform: unless i run outta steam before, might write a detailed summary, can see all my proposed why/why-not's
cgra: i mean, while ~every part needs fixing, this "every" still perhaps countable by own fingers
cgra: asciilifeform: otherwise yeah, but still need time to grasp where can put a peer fence, without blocking convoluted, but vital, moving parts. otoh, also, while ~every part, still appear enumerable...
cgra: for bonus: perhaps even "mapBlockIndex", if second hand old-gen miner reusable as bogus block generator. (operator-defined checkpoints, or the 'cement' ought to fix)
cgra: mempool-, addr-, and inventory-related, send/recv buffers, the agent string.
cgra learned today, fwiw, that trb's almost every peer-accessible rubber variable can be inflated by a random bypasser/coordinated inbound peers, until ~OOM. not unlike previously noted... got tired of demonstrating every individual case
cgra: i said it confusingly, i meant <1000 sats is a no-go, but 1000...9999 is 'a maybe', and >=10000 is 'no questions asked'
cgra: lower is "a maybe" type of deal
cgra: if you cross the latter tier, no questions asked
cgra: whaack: it has two, 1000 sats and 10000 sats
cgra: ok
cgra: can play with the bait money only
cgra: whaack: is it that you don't even need an address you control?
cgra: just that maybe using plenty of 1-sat outputs works
cgra: (maybe too early to ask, i haven't looked carefully enough yet, how to even bake such cakes traditionally)
cgra: whaack: btw, does segwit-bomb tx make it any easier to bake large (byte-wise) transactions? i so far didn't look into your experiments in detail (or whole segwit), so would't know
cgra: whaack: ty!
cgra: measure as in 'just measure, otherwise let the pile keep stinking'
cgra: asciilifeform: the analogy lingering in my mind is 'still could be worth looking for the bottom-most funnel, and finding the only pointy end to plug', but i keep your words in mind. also i currently have difficulty in understanding how to reliably measure -- copper wiring each and every spaghetto?
cgra: (the default red area in sendbuffer odometer)
cgra: asciilifeform: yeah, but 10 blocks prolly under the 10MB mark
cgra: for extra impact and pedantry, could request ~1MB blocks for the rest of the 50000 allowed inv's
cgra: one more trb observation: if there's an easy way to make a tx upwards from 55kB in weight, that trb will accept, the wedging issue is still present, because no odometry for tx data, and the attacker could easily request 49990 times the same tx, in one 'getdata'
cgra: right
cgra: yeah, i'm thinking of an acceptable solution that replaces parts with smaller ones
cgra: http://logs.nosuchlabs.com/log/asciilifeform/2021-08-01#1049664 << and http://logs.nosuchlabs.com/log/asciilifeform/2021-08-01#1049665 << do you mean that likely some kinda odometer is the only 'clean' approach in such swamps as the satoshi's creation?
cgra: and what's more, std::string afaik has same capacity mechanism, which i intend to eventually review as well
cgra: still, separately need fixing the issues of 1) unbounded agent string, and 2) std::vector internal capacity not automatically reducing -- because you wouldn't want 125 simultaneous peers to consume >2GB of RAM
cgra: http://logs.nosuchlabs.com/log/asciilifeform/2021-08-01#1049627 << this is where the stale peers accumulate, and if such a dumpster didn't exist, my previous exploits wouldn't work. re the dumpster, i must get a better grasp of c++ networking to understand the why and the how-to-replace.
cgra: bloated vSend of hundreds of stale, abrutply disconnected peers (all from same address)
cgra: umm no, actually. not a capacity leak in same sense. but a straight stale peer data abuse
cgra: asciilifeform: this time a getdata exploit, but based on the same vector "capacity" leak
cgra: !w probe 205.134.172.27
cgra: asciilifeform: ok, thanks! does it need you to stand up if tripped?
cgra: right
cgra: asciilifeform: i suspect this is not even limited to the agent string, deeper down issue is possibly the std::vector "capacity" concept.
cgra: asciilifeform: "a bunch", my methods weren't easily measurable
cgra: (or busy doing smth else...)
cgra: now down apparently
cgra: asciilifeform: how much ram there?
cgra: asciilifeform: ok
cgra: can you easily watch ram usage?
cgra: asciilifeform: how does it look so far?
cgra: asciilifeform: my bomber is based on just that :)
cgra: ok, sec
cgra: asciilifeform: yeah, no serious damage attempted
cgra: sorry, 9500000-byte
cgra: i used 950000-byte agent strings
cgra: asciilifeform: a modest row of 10 bombs apparently sank in, wasn't sure whether ok to sink the whole ship or not
cgra: the issue was apparently handled in prb in 2014, by prohibiting agent strings beyond 256 bytes. the simplest fix i can imagine off-hand, is just truncating the agent string. i could't find any use of it, so could even truncate to just 32 bytes.
cgra: it worked on my local node, so not yet tested in the wild. anyone willing to lend a node for target practice?
cgra: version parsing doesn't specifically limit the agent string size; GetRefCount() is special and plays a part; all the stale peer details (agent strings included) get kept in RAM for extra 15 minutes, after being disconnected (vNodesDisconnected).
cgra: looks like trb may be susceptible to a trivial DoS -- getting greeted by a pile of bloated agent strings, ~10MB each.
cgra: is this is just because 'there's no 100%'? ie. humans make mistakes and only *mostly* notice
cgra: asciilifeform: now that we're on topic, i've been for a while wanting to ask a q. at the bottom of nosuchlabs.com front page, you say "We recommend at least 24 hours of entropy distillation (solely via XOR-in-place !) if generating mission-critical, long-term cryptographic keys."
cgra: asciilifeform: yeah. i tried to briefly study (from rfc's + some) how do irc servers intercommunicate user messages. then you said this :)
cgra: thimbronion: thanks! will check it out sometime soon(ish)
cgra: asciilifeform: fwiw, finally bothered with a bouncer, too
cgra: http://logs.nosuchlabs.com/log/asciilifeform/2021-02-02#1030749 << trinque, yes please
cgra: http://logs.nosuchlabs.com/log/asciilifeform/2021-02-02#1030723 << yeah, sorry i didn't ack! i read the article and found as previously discussed
cgra: asciilifeform: i went to explore the (originally mostly unknown to me) arm64 land after realizing amd64 opcode encoding is hideously complex... in the hopes of finding a better place to study binary auditability
cgra: trinque: also, got a handful of related notes to perhaps share, or do you already have a significantly different, new item on your table?
cgra: asciilifeform: hi!