diana_coman: BingoBoingo: it seems to have at least ~stabilised basically so I'd say publish it already so you can move on to the practical implementation of each point; basically once it's there, look at it each day and aim your work to hit at least one of the stated aims.
diana_coman: BingoBoingo: as an aside, for the crawler etc, the whole thing is cleanly split into a few distinct parts to start with namely: collecting as many urls as can be reached/found from a starting url (and this normally would be iterated in turn on all new urls found until ~nothing new is added, that's pretty much how you can tell you explored at least whatever is connected in the least); separate from this quite entirely is filtering ...
diana_coman: ... (and here you can define whatever filters you want at any time but they do NOT mess up the previous list, they simply FILTER it and spit out those urls passing the filters as output) - for instance you can have a filter to check for a comment form or a filter to check for activity in 2019 or more recent or a filter to check that the word "bitcoin" appears at all, whatever + you can always combine them but *once you make them*; ...
diana_coman: ... then a separate part can be the one inserting a comment even possibly out of a list you make ; etc.
diana_coman: the above is the sort of "split the problem" that helps, literally isolating bits that can be done separately and then basically piped together as desired, at any time.
diana_coman: BingoBoingo: also, do me a favour and include in your weekly review a brief summary of qntra activity set next to the matching one from past week (a simple thing, should not take more than 15 minutes to make - and if it does take more than automate the making of this report to start with), eg something like a table listing perhaps authors vs topics & comments, with number of articles/comments in each cell - this is just a quick idea, ...
diana_coman: ... you find what makes most sense.
diana_coman: dorion: argh, do you need some laurel soup or what?
jfw: My soup status update: 1) the wallet Scheme code is all cleaned up and right where it needs to be (though wasn't by my Wednesday deadline); 2) the python isn't quite where I'd like it but good enough for now; 3) shell+gpg integration with install instructions is drafted but needs further testing & ironing out; 4) the Scheme interpreter is fine but needs installation instructions; 5) all the above
jfw: needs genesis; 6) the TRB patches still need regrind; 7) I was mistaken about the date of a training session, it's next weekend; 8) no progress on databases presentation which means it'll be a fire to put out in upcoming days; 9) I didn't get to my review Saturday because... well, I'd have to say because wallet seemed like more fun and had the excuse of also being important (all the more now that
jfw: MP means to try it).
diana_coman: jfw: basically you need some sharper motivation for any reviews and the like, lolz
diana_coman: what's that difference between where you'd like it and good enough for now at 2) ?
jfw: Main thing was a DB schema change to track block metadata in its own table; some more minor additions that came to mind were an extra query command and database initialization (which can be done manually for now)
jfw: oh, also a command to export the address/tag relation since it's the only part of the DB that can't be regenerated from blockchain.
diana_coman: jfw: so what's the plan there, focus now on genesis + docs + trial with MP and then add those in a vpatch on top or what?
jfw: diana_coman: yes, though as these weren't in the original spec I'm seeing them more as wishlist for a v2 along with what else turns up from getting some use in practice.
diana_coman: ah, sounds fine then.
dorion: http://logs.ossasepia.com/log/ossasepia/2020-03-08#1020307 - I don't know why I let the review slip yesterday. I ended up spinning, but starting over today and here is what I have so far for the first article in the history you didn't know series.
ossabot: Logged on 2020-03-08 05:22:43 diana_coman: dorion: argh, do you need some laurel soup or what?
dorion: http://logs.ossasepia.com/log/ossasepia/2020-03-08#1020308 - thanks for the update, sounds good. so 1, 3-6 in v1 by thursday, then 2 in v2 at data to be set later ?
ossabot: Logged on 2020-03-08 16:16:44 jfw: My soup status update: 1) the wallet Scheme code is all cleaned up and right where it needs to be (though wasn't by my Wednesday deadline); 2) the python isn't quite where I'd like it but good enough for now; 3) shell+gpg integration with install instructions is drafted but needs further testing & ironing out; 4) the Scheme interpreter is fine but needs installation instructions; 5) all the above
diana_coman: dorion: the first paragraph is both running out of breath (you're packing in one sentence 10+ years of your life there, aren't you) and not absolutely needed as it is; as it stands for now, you could probably start directly with the 3rd paragraph and nobody will notice much.
dorion: jfw well, more likely you'll want to be done with those by tuesday because db presentation on wednesday and time with mp is thursday morning.
diana_coman: ^^^
diana_coman: but then he won't play with the red fire truck :P
diana_coman: dorion: what do you mean by "to cure the points together"?
jfw: mhm. as far as 6, seems I need to clarify with MP what bitcoind he has available, if he wants to test that part. That'd be one of the larger potential quagmires
jfw: Though one can push a raw tx through block explorer, or I could do it once my node is patched.
dorion: diana_coman I should've said I'm planning to link the previous articles that touch those topics in the first paragraph to provide context, but okay.
diana_coman: dorion: that would certainly help but it's still not quite enough; if you want to keep those in it's fine but you need to revise them so they read more clearly; maybe look at them and attempt to extract what point you are trying to make with each, in as few words as possible; then rewrite the paragraph starting from/with that.
dorion: diana_coman re cure I mean ease, since there's a lot to cover from different angles, but weave is probably better.
diana_coman: even to "bring the points together" would work, sure.
lobbes: diana_coman: just to update: I have nothing for our standing meeting today. I'm still working through these bugs atm.
diana_coman: dorion: either at re-read if not at writing - you need to be aware of when/what things you are "importing" and either explain them in text or in a footnote e.g. that "boiling frog complacency" in para 2 - do you expect it's a common ref ?
diana_coman: lobbes: well, tbh it sounds more like you have no time to have anything really, because the week first still went to saltmines anyway and then the supposedly quick & easy bot review turns out to be neither quick nor easy or something so dunno, doesn't sound all that great overall.
lobbes: diana_coman: I agree, not going to well. Until I can free myself from these saltmines I'm not sure what else I can do though
dorion: ok re importing; I do expect boiling frog is a common ref, but I could see being mistaken there and doesn't hurt to explain it.
diana_coman: hm, coming like that out of the blue I would be surprised if most get it; but I suppose it's perfect for an empirical exercise, lol
diana_coman: dorion: anyway, if it's first draft, then finish it at least and can do a review on the whole, not like there's much to gain from polishing the intro now.
dorion: ok.
diana_coman: lobbes: the trouble with this "until X" approach is that there's always a Y to take the place of X.
diana_coman: dorion: perhaps worth noting that reviews of written text can be briefly described as "kill your darlings" ; to build up the proper expectations perhaps.
jfw: ugh, I just realized a possible wallet-draining attack from the online node, no thanks to satoshi's not-even-double-entry bookkeeping where the fee is implicit as outputs-inputs. If node understates the value of previous transaction outputs, signer will over-spend on the fee, up to the actual value of the output - and it has no way to detect this since it doesn't have the full transaction set.
lobbes: diana_coman: do you mean that even without the saltmines sucking up my time I'd have something else that'd replace that as a time-sink?
diana_coman: jfw: hm, do you mean that as in a compromised online node?
jfw: diana_coman: correct
jfw: at least it's not a direct theft, unless you're the miner who can grab the fee
dorion: diana_coman noted on killing darlings.
diana_coman: lobbes: for as long as you take that passive approach ie "x is sucking up time" rather than the active "this is my time and I spend it on x ", how could it even happen differently, really?
diana_coman: jfw: yes, but do you see somehow the offline wallet meant to protect someone against compromised/malefic online nodes in general?
diana_coman: (on practical grounds, probably malicious is enough and more likely than outright malefic node, I suppose)
lobbes: diana_coman: I see your point; I'm not taking the proper ownership of my situation. Thank you, I think I've been slipping as of late back into these old excuse-driven modes
jfw: diana_coman: well not the general network but your own online node. Previously I thought the worst it could do if compromised was prevent you from transacting, or leak your address set.
jfw looks up 'malefic'
diana_coman: jfw: ah, certainly worth noting the "worst it can do" if at all possible to set it anywhere below "lose all your money" - because by default for anything online, that'd be the straightforward assumption I'd say; but I see what you mean.
jfw: (Giving you the wrong address to send to is the more obvious attack I'd expect; I just didn't list it above as it's not strictly speaking a function of the bitcoin node.)
diana_coman: jfw: that's the thing - the offline wallet can't protect operator against incorrect inputs basically; that's just not possible, since offline means precisely "can't check what it's fed"
jfw: diana_coman: what do you mean would be the straightforward assumption?
diana_coman: jfw: the "worst it can do is to lose all your money", lol; what else.
jfw: right. Only the operator can check what is being fed; perhaps using multiple nodes
diana_coman: jfw: that's what I'd expect, indeed.
jfw: this vector would be avoided though if there were a rule that "transaction is not valid unless it explicitly states the fee and total input value equals total output value plus fee". Not to mention you could then *tell* what the fee is just from decoding the raw tx.
jfw: </venting>
diana_coman: sure.
feedbot: http://younghands.club/2020/03/09/ar-review-march-2nd-march-8th-2020/ << Young Hands Club -- AR Review March 2nd - March 8th 2020
feedbot: http://younghands.club/2020/03/09/ar-plan-march-9th-march-15th-2020/ << Young Hands Club -- AR Plan March 9th - March 15th 2020
BingoBoingo: diana_coman: A bit of framing added and links installed, but finally published http://bingology.net/2020/qntra-a-plan-for-action/
feedbot: http://younghands.club/2020/03/09/ejb-review-of-mar-2-mar-8-plan-for-mar-9-mar-15/ << Young Hands Club -- ejb review of Mar 2-Mar 8 ; plan for Mar 9-Mar 15