< wumpus>
provoostenator: i don't know, but we can't postpone rc4 indefinitely on it
< wumpus>
we could have some release out and have something for people to test for weeks now, but the discussion on those takes indefinitely
< sipa>
let's just get rc4 out
< aj>
wumpus: if it's not going in, nack it as not being important enough a fix to justify a change? (if it is important enough to justify a change, merging it seems obvious?)
< aj>
wumpus: (i think it's important enough; but obviously lots of people are dubious, and if someone has to make a call, might as well be a maintainer?)
< wumpus>
aj: I have already given my opinion on it
< wumpus>
I don't necesaarily want to push that
< wumpus>
but yes I think the change is unnecessary
< wumpus>
and in that case it's probably better to err on the side of not doing it, that said, if this blocks the release forever it'd be kind of sad
< wumpus>
I really think it's time to do the rc
< wumpus>
looking at #18947, 0.21 has slipped exactly a month now
< wumpus>
i'm not sure this should delay the 0.22.0 release schedule as well
< aj>
wumpus: hmm, i appreciate the "I don't necessarily want to push that" but I also feel like "I think the change is unnecessary" should be more of a nack (concept nack? -0.5? im-not-merging-but-someone-else-might?) than a "~0" and a "review ACK"? it seems like everyone's waiting for someone else to nack it so they don't have to?
< wumpus>
"review ACK" means i think the code is correct in doing what it is stated to do
< michaelfolkson>
You're not making it easy to get quick Concept ACKs jonatack with descriptions like "following up on #19858 (comment)." and not making it clear what is covered by the PR and what is covered by the series of PRs
< jonatack>
idk if the pull descriptions are the issue. i stand by the work and am sad to close, but better to work on things reviewers are enthusiastic about...you do the work because you believe in it; after that you turn it over to reviewers and it's up to them.
< jonatack>
there's a book about it, "review is a harsh mistress" (heinlein, 1966 :))
< michaelfolkson>
Well I'm telling you at least from my perspective a good PR description makes a Concept ACK very quick and easy :)
< michaelfolkson>
The more digging required, the more friction and the unlikelier it is to get quick Concept ACKs. That's my hypothesis anyway
< jonatack>
michaelfolkson: hm, with the title "p2p: improve logging in EvictExtraOutboundPeers" and the diff being only 9 lines, i reckoned more description wasn't required on that one
< jonatack>
maybe could have added more though, idk
< jonatack>
onward and upward
< michaelfolkson>
It is the problem it is solving rather than the solution only being 9 lines
< andytoshi>
is there a way to call `getblock` and not receive witness data? would a PR to add this be accepted?
< luke-jr>
the RPC? there probably shouldn't be
< sipa>
you can run with -rpcserialversion=0 if you really need to
< andytoshi>
oh that's a neat trick sipa, i might do that
< andytoshi>
ok luke-jr if there's gonna be opposition i won't bother
< andytoshi>
but it kinda annoying to haul all that witness data around if i'm not even gonna use it
< luke-jr>
andytoshi: why haul it? just strip at your first hop?
< luke-jr>
or rather, why get the raw block at all if you don't want that? :P
< andytoshi>
luke-jr: i am the first hop, i'm pulling this data over localhost into an indexer, which is just scanning for TXOs that it cares about
< andytoshi>
and inputs
< andytoshi>
i guess if i were to drop the witness data at parse-time in the indexer, the perf hit from that would probabyl not be measurable
< luke-jr>
right, I would expect that's the case
< luke-jr>
libblkmaker has some cheap code to drop it IIRC
< andytoshi>
thanks, i'll check it out
< phantomcircuit>
andytoshi, add an rpc to use the block filters on a set of elements?
< luke-jr>
someone has a PR for that already
< luke-jr>
seems like it'd be less efficient tho
< andytoshi>
luke-jr: i think it would be more efficient than what i'm doing -- i'm asking Core to serialize whole blocks, send it to a nother process, and then i'm filtering there ... if i could ask Core to just do the filtering that should be way faster