< bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/8db23349fe9b...149eca433d80
< bitcoin-git> bitcoin/master 2c6a02e Troy Giorshev: Clean message_count and last_message
< bitcoin-git> bitcoin/master 149eca4 MarcoFalke: Merge #19599: test: clean message_count and last_message
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #19599: test: clean message_count and last_message (master...2020-07-clean-message_count) https://github.com/bitcoin/bitcoin/pull/19599
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/149eca433d80...2a784723f0c0
< bitcoin-git> bitcoin/master 82dee87 Sebastian Falbesoner: test: test decodepsbt fee calculation (count input value only once per UTX...
< bitcoin-git> bitcoin/master 2a78472 MarcoFalke: Merge #19597: test: test decodepsbt fee calculation (count input value onl...
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #19597: test: test decodepsbt fee calculation (count input value only once per UTXO) (master...20200726-test-check-deceodepsbt-fee-calculation) https://github.com/bitcoin/bitcoin/pull/19597
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #19624: Interpret and validate rw_settings (master...2007-settings) https://github.com/bitcoin/bitcoin/pull/19624
< bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/2a784723f0c0...4ebe2f6e752c
< bitcoin-git> bitcoin/master 78c312c Martin Ankerl: Replace current benchmarking framework with nanobench
< bitcoin-git> bitcoin/master 4ebe2f6 Wladimir J. van der Laan: Merge #18011: Replace current benchmarking framework with nanobench
< bitcoin-git> [bitcoin] laanwj merged pull request #18011: Replace current benchmarking framework with nanobench (master...2019-10-nanobench) https://github.com/bitcoin/bitcoin/pull/18011
< fanquake> #proposedmeetingtopic 0.20.1rc1 testing. Has anyone had/seen any issues during testing so far? Has anything come up that would require an rc2?
< fanquake> I have moved #19033 to the 0.20.2 milestone.
< gribble> https://github.com/bitcoin/bitcoin/issues/19033 | http: Release work queue after event base finish by promag · Pull Request #19033 · bitcoin/bitcoin · GitHub
< wumpus> I was about to propose the same topic
< wumpus> :)
< wumpus> would be good to get 0.20.1 out of the door asap if no critical issues came up in testing
< bitcoin-git> [bitcoin] laanwj pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/4ebe2f6e752c...17de75b02814
< bitcoin-git> bitcoin/master 4254cd9 Jon Atack: p2p: add CInv transaction message helper methods
< bitcoin-git> bitcoin/master c251d71 Jon Atack: p2p, refactoring: use CInv helpers in net_processing.cpp
< bitcoin-git> bitcoin/master 17de75b Wladimir J. van der Laan: Merge #19590: p2p, refactor: add `CInv` transaction message helpers; use i...
< bitcoin-git> [bitcoin] laanwj merged pull request #19590: p2p, refactor: add `CInv` transaction message helpers; use in net processing (master...CInv-transaction-message-helpers) https://github.com/bitcoin/bitcoin/pull/19590
< bitcoin-git> [bitcoin] theStack opened pull request #19626: refactor: replace sizeof(a)/sizeof(a[0]) by ARRAYLEN(a) (master...20200726-refactor-replace-sizeof-by-arraylen) https://github.com/bitcoin/bitcoin/pull/19626
< luke-jr> I wonder if nodes ought to prefer blocks with expected version over equal-work blocks with unexpected version
< instagibbs> prefer as is preciousblock?
< instagibbs> as in
< instagibbs> oh sorry, yes, i had to read the entire sentence
< luke-jr> similar
< luke-jr> it could make sense, because if features are activated the node doesn't support, it ceases to be a full node
< luke-jr> (and for new nodes, it gives a small bias toward activation of new features they do support?)
< instagibbs> first seen in general gives good convergence properties. Some new asicboost like thing could result in more profitable selfish mining attacks or similar
< fanquake> wumpus: sounds good
< bitcoin-git> [bitcoin] hebasto opened pull request #19627: build: Drop per-host faketime wrappers in gitian-linux build (master...200729-fake) https://github.com/bitcoin/bitcoin/pull/19627
< bitcoin-git> [bitcoin] MarcoFalke pushed 4 commits to master: https://github.com/bitcoin/bitcoin/compare/17de75b02814...37b765b96238
< bitcoin-git> bitcoin/master 0103d64 Andrew Chow: Introduce DummyDatabase and use it in the tests
< bitcoin-git> bitcoin/master da039d2 Andrew Chow: Remove BDB dummy databases
< bitcoin-git> bitcoin/master 0fcff54 Andrew Chow: walletdb: Ensure that having no database handle is a failure
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #19102: wallet: Introduce and use DummyDatabase instead of dummy BerkeleyDatabase (master...true-dummydb) https://github.com/bitcoin/bitcoin/pull/19102
< bitcoin-git> [bitcoin] MarcoFalke pushed 4 commits to master: https://github.com/bitcoin/bitcoin/compare/37b765b96238...62d137ac3b70
< bitcoin-git> bitcoin/master a316e9c Ivan Metlushko: refactor: add unused ArgsManager to replace gArgs
< bitcoin-git> bitcoin/master 9b20f66 Ivan Metlushko: scripted-diff: Replace gArgs with local argsman
< bitcoin-git> bitcoin/master 8ed9002 Ivan Metlushko: refactor: use local argsmanager in CRegTestParams
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #19561: refactor: Pass ArgsManager into functions that register args (master...args_manager) https://github.com/bitcoin/bitcoin/pull/19561
< promag_> #19033 fixes a shutdown race. not too hard to review tbh
< gribble> https://github.com/bitcoin/bitcoin/issues/19033 | http: Release work queue after event base finish by promag · Pull Request #19033 · bitcoin/bitcoin · GitHub
< promag> it doesn't mess with libevent
< bitcoin-git> [bitcoin] MarcoFalke pushed 4 commits to master: https://github.com/bitcoin/bitcoin/compare/62d137ac3b70...ad2952d17a2a
< bitcoin-git> bitcoin/master faec851 MarcoFalke: test: Simplify cs_main locks
< bitcoin-git> bitcoin/master fac674d MarcoFalke: Pass mempool pointer to UnloadBlockIndex
< bitcoin-git> bitcoin/master fae8c28 MarcoFalke: Pass mempool pointer to GetCoinsCacheSizeState
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #19604: Pass mempool pointer to UnloadBlockIndex/GetCoinsCacheSizeState (master...2007-memPointer) https://github.com/bitcoin/bitcoin/pull/19604
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/ad2952d17a2a...edec7f7c2542
< bitcoin-git> bitcoin/master 284a969 Amir Ghorbanian: Linter to check commit message formatting
< bitcoin-git> bitcoin/master edec7f7 MarcoFalke: Merge #19439: script: Linter to check commit message formatting
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #19439: script: Linter to check commit message formatting (master...linter-addition) https://github.com/bitcoin/bitcoin/pull/19439
< bitcoin-git> [bitcoin] vasild opened pull request #19628: net: change CNetAddr::ip to have flexible size (master...make_CNetAddr_ip_flexible) https://github.com/bitcoin/bitcoin/pull/19628
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #19629: Pass mempool reference to chainstate constructor (master...2007-nomem) https://github.com/bitcoin/bitcoin/pull/19629
< sipa> hi
< jnewbery> hi
< wumpus> #startmeeting
< lightningbot> Meeting started Thu Jul 30 19:00:19 2020 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
< lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
< luke-jr> hi
< sipsorcery> hi
< meshcollider> hi
< troygiorshev> hi
< fjahr> hi
< wumpus> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101 meshcollider jnewbery maaku fanquake promag provoostenator aj Chris_Stewart_5 dongcarl gwillen jamesob ken281221 ryanofsky gleb moneyball kvaciral ariard digi_james
< wumpus> amiti fjahr jeremyrubin lightlike emilengler jonatack hebasto jb55 elichai2
< hebasto> hi
< achow101> hi
< pinheadmz> hi
< lightlike> hi
< jamesob> hi
< wumpus> one proposed meeting topic: 0.20.1rc1 testing (fanquake)
< wumpus> any last minute topic ideas?
< jeremyrubin> hi
< jeremyrubin> Maybe backports of wtxid v.s. the thing suhas proposed?
< wumpus> ok
< wumpus> #topic High priority for review
< achow101> #19077 pls
< gribble> https://github.com/bitcoin/bitcoin/issues/19077 | wallet: Add sqlite as an alternative wallet database and use it for new descriptor wallets by achow101 · Pull Request #19077 · bitcoin/bitcoin · GitHub
< wumpus> 10 blockers, 1 bugfix, 3 chasing concept ACK in https://github.com/bitcoin/bitcoin/projects/8
< jamesob> achow101: looking forward to reading that one
< wumpus> achow101: added
< wumpus> I'm happy we got through all the preparation PRs and got to the main one now :)
< meshcollider> Yes \o/
< jeremyrubin> not a devel topic, but gentle nudge for anyone who could use more funding to get themselves added to https://bitcoindevlist.com/, the community has been very generous lately & it's easy to setup via github sponsors (who are matching up to $5k in your first year)
< wumpus> thanks
< wumpus> anything else to add/remove or that is ready for merge?
< wumpus> #topic 0.20.1rc1 testing
< luke-jr> is what ready for merge? O.o
< wumpus> Has anyone had/seen any issues during testing so far?
< wumpus> luke-jr: anything on high priority for review
< luke-jr> ah
< MarcoFalke> Might be ready to ship
< MarcoFalke> Only change since rc has been a doc commit and a travis commit
< hebasto> ^ agree
< wumpus> I think so too
< luke-jr> by my count, I only see 13 nodes using 0.20.1; but I haven't paid much attention to this in the past
< luke-jr> and it's expected that there will be some delay in my stats picking things up
< wumpus> no new problems have been reported with .1 afaik
< wumpus> luke-jr: happy to hear 13 people are testing it :)
< wumpus> (at least)
< wumpus> I'm planning to tag -final soon then, it's good to get this release out of the door
< wumpus> #topic backport of wtxid versus alternative (jeremyrubin)
< jeremyrubin> Hmmm well it seems we lost suhas a moment ago
< wumpus> the backport is #19606
< gribble> https://github.com/bitcoin/bitcoin/issues/19606 | Backport wtxid relay to v0.20 by jnewbery · Pull Request #19606 · bitcoin/bitcoin · GitHub
< sipa> and the alternative is #19620
< gribble> https://github.com/bitcoin/bitcoin/issues/19620 | Add txids with non-standard inputs to reject filter by sdaftuar · Pull Request #19620 · bitcoin/bitcoin · GitHub
< wumpus> right ^^
< sipa> it isn't really an alternative - they're both independent improvements that should both go in master
< MarcoFalke> Does it make sense to ship wtxid in 0.20 before it is shipped in 0.21?
< luke-jr> wb sdaftuar
< wumpus> so I think the question is which one (or both) to backport to 0.20
< MarcoFalke> It's not exactly a bugfix and it might come with risks
< sipa> but i think that one is sufficient to remove concerns about deploying new segwit softforks
< jeremyrubin> is it correct to say they're backport alternatives?
< jnewbery> #19606 is actually quite a straightforward backport. Most of the conflicts are trivial.
< gribble> https://github.com/bitcoin/bitcoin/issues/19606 | Backport wtxid relay to v0.20 by jnewbery · Pull Request #19606 · bitcoin/bitcoin · GitHub
< luke-jr> I thought we figured out we didn't strictly need either?
< wumpus> MarcoFalke: I think that's a good point, might make sense to include wtxid relay only in the 20.x release after 21.0
< jnewbery> The biggest difference is removing the unbroadcast stuff, which was only merged after v0.20 forked, but even that's pretty limited in where it interacts with the rest of the code
< jeremyrubin> Out of curiosity, can we backport either easily to a 19.x? Would that matter?
< luke-jr> (so long as the policy changes were left for 0.21+)
< sdaftuar> sorry my connection is super laggy right now. but i assume we could easily backport #19620 to any recent release
< gribble> https://github.com/bitcoin/bitcoin/issues/19620 | Add txids with non-standard inputs to reject filter by sdaftuar · Pull Request #19620 · bitcoin/bitcoin · GitHub
< jeremyrubin> luke-jr: it would be nice to have less dependency though on when policy changes are advisable
< wumpus> hm 0.19 backport would be much more work (code differs more) and gets much less testing
< jeremyrubin> sdaftuar's patch seems to be really simple compared to wtxid relay
< jnewbery> my opinion is that there's no strong reason not to backport wtxid relay to 0.20. It should be a trivial review for anyone who reviewed it on master, and we want wtxid relay to be widely deployed independent of taproot
< jnewbery> I think 19620 is independently good and should also be backported
< jeremyrubin> maybe backport both to 0.20, sdaftuar patch to 0.19?
< sdaftuar> anyway i definitely wanted wtxid relay to be part of 0.20, so i think jnewbery is right to say the backport isn't terrible, but backporting p2p features isn't something we usually do
< luke-jr> sdaftuar: considering we don't need it for Taproot(consensus), is there another reason you want wtxid relay in 0.20?
< jeremyrubin> I guess the question which I'm uncertain enough is how big of a deal is it going to be for 0.19.x nodes if taproot rolls out and they have no protections
< wumpus> we can make an exception to normallly not backporting p2p features as it's requirement for taproot
< wumpus> which will also be backported
< instagibbs> we normally backport activations, hence this yeah
< sdaftuar> luke-jr: i'm not sure i do want it in 0.20 now, i just meant when i wrote it back in january, i had been hoping it would make the 0.20.0 release :)
< luke-jr> ah
< jnewbery> 19620 should be a trivial backport to 0.19 (it's only 10-20 lines of code changed). I don't think we should backport wtxid relay to 0.19
< jeremyrubin> luke-jr: sipa seemed to be exceptionally frustrated when i suggested that last week, so while possible maybe better to not plan to do that
< sipa> luke-jr: what do you mean by that? it would require some rule that taproot-capable nodes don't relay such transactions to older peers
< sipa> which is a possibility, but i think just backporting #19620 is a lot simpler
< gribble> https://github.com/bitcoin/bitcoin/issues/19620 | Add txids with non-standard inputs to reject filter by sdaftuar · Pull Request #19620 · bitcoin/bitcoin · GitHub
< luke-jr> sipa: I mean we can deploy Taproot(consensus) independently from / in parallel to Taproot(policy)
< luke-jr> the former is going to take at least a year anyway, so 0.21 will be mature by the time it activates
< sipa> luke-jr: sure... but that won't protect old nodes
< jeremyrubin> jnewbery: that sounds good to me as an actionalble plan forward. Is it enough that 0.19.x nodes with the patch won't get bad dos?
< sipa> (by the time things actually start being relayed, from whatever codebase)
< luke-jr> sipa: that's true no matter what release we put it into?
< sipa> luke-jr: yes, fair - but at least there could easily be a 0.20 and 0.19 perhaps with 19620 in it, so people who don't want to immediately upgrade to a new major version would have an option
< sdaftuar> honestly i'm not super concerned about bandwidth waste to old nodes. it's better to not waste bandwidth, of course, but i think if people have a couple alternatives to avoid it (upgrade to latest minor release or major release) it's not a big deal
< jnewbery> sdaftuar: I agree
< wumpus> I agree too
< luke-jr> sipa: I'm not opposed
< sipa> ok
< jnewbery> 0.18 is EOL in Feb next year, Taproot won't activate before then, probably
< jnewbery> so if we backport 19620 to 0.19, anyone on a supported version has a minor release they can upgrade to
< wumpus> yes
< jeremyrubin> I also agree with this to an extent, but I think there are probably some older node users who would be noisy, and I wouldn't want that to translate into opposition to other development work on later versions
< jeremyrubin> jnewbery: I don't think anyone can complain about that plan
< sdaftuar> they can just put an upgraded node in between their old node and the network
< sipa> yeah, seems reasonable to me
< luke-jr> jeremyrubin: if someone insists on using a pre-0.19 version, they can fund longer-term maintenance thereof..
< luke-jr> or what sdaftuar suggested
< sipa> of course, i don't think we have obligations to maintain EOL versions
< jeremyrubin> When is EOL for 0.19?
< wumpus> so the plan is to backport #19606 to 0.20 and #19620 to 0.19 and 0.20?
< gribble> https://github.com/bitcoin/bitcoin/issues/19606 | Backport wtxid relay to v0.20 by jnewbery · Pull Request #19606 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/19620 | Add txids with non-standard inputs to reject filter by sdaftuar · Pull Request #19620 · bitcoin/bitcoin · GitHub
< instagibbs> should be a little while I think?
< jnewbery> wumpus: sounds good to me
< wumpus> okay!
< instagibbs> 0.17 is 2020-08-01 eol
< instagibbs> soon(TM)
< sdaftuar> sounds good
< sipa> sounds reasonable if wtxid relay (and followups) are easy to do in 0.20
< luke-jr> isn't 0.19 unsupported when 0.21 is released?
< sdaftuar> sipa: good point about followups
< jeremyrubin> I think we could change that to be the policy going forward, but https://bitcoincore.org/en/lifecycle/ says otherwise
< sipa> random thought: should the bitcoincore twitter account announce when major releases go unsupported/EOL ?
< sdaftuar> i think your pr about orphan fetching just got conflicted due to a refactor that was merged
< instagibbs> "maintenance end" I think luke-jr
< sipa> sdaftuar: will fix soon, seems trivial
< instagibbs> im reading the website
< sdaftuar> so perhaps we should highlight the followup prs that would be backported as well?
< luke-jr> instagibbs: yeah, me too - it's not clear when EOL is
< sdaftuar> (if more than one)
< achow101> 0.19 eol is after 0.22
< instagibbs> eolAfter EOL, users must upgrade to a later version to receive security updates, even though the community may provide fixes for critical issues on a best effort basis.
< instagibbs> i think maintenance is more what we're considering
< sipa> so wtxid relay is #18044 #19590 #19569... anything else?
< gribble> https://github.com/bitcoin/bitcoin/issues/18044 | Use wtxid for transaction relay by sdaftuar · Pull Request #18044 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/19590 | p2p, refactor: add `CInv` transaction message helpers; use in net processing by jonatack · Pull Request #19590 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/19569 | Enable fetching of orphan parents from wtxid peers by sipa · Pull Request #19569 · bitcoin/bitcoin · GitHub
< wumpus> sipa: seems fine to me, though in general I don't like urging people to upgrade unless there's a security problem
< jnewbery> sipa: yes, it'd be good if the twitter account announced EOLs
< luke-jr> instagibbs: true, this isn't a critical issue
< jnewbery> I don't think 19590 needs to be backported
< jnewbery> we can just take the existing 19569 branch before you rebase it on that
< sdaftuar> jnewbery: it'll make 19569 easier to backport due to the conflicts i think?
< sipa> jnewbery: it doesn't, but it would make the master and backported version of 19569 somewhat different
< instagibbs> it's really tiny...
< sipa> okay
< sipa> i don't think there are any major disagreements here
< jeremyrubin> if you backport #19748 it will take care of the memory overhead from the new wtxid index, but far from required
< gribble> https://github.com/bitcoin/bitcoin/issues/19748 | HTTP Error 404: Not Found
< jeremyrubin> #19478
< gribble> https://github.com/bitcoin/bitcoin/issues/19478 | Remove CTxMempool::mapLinks data structure member by JeremyRubin · Pull Request #19478 · bitcoin/bitcoin · GitHub
< wumpus> any other topics?
< jnewbery> if we're agreed that #19606 should go in, then can I encourage anyone who reviewed #18044 to look at it soon, while the original PR is still fresh for them
< gribble> https://github.com/bitcoin/bitcoin/issues/19606 | Backport wtxid relay to v0.20 by jnewbery · Pull Request #19606 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/18044 | Use wtxid for transaction relay by sdaftuar · Pull Request #18044 · bitcoin/bitcoin · GitHub
< jnewbery> it'll make review easier
< jnewbery> no point in hanging around if we want to get it in
< bitcoin-git> [bitcoin] darosior opened pull request #19630: Refactor fee estimation code (master...20/07/refactor_feeest_code) https://github.com/bitcoin/bitcoin/pull/19630
< jeremyrubin> wait is it going into the upcoming minor?
< jeremyrubin> I thought it's the next 0.20 minor?
< MarcoFalke> And should it be released before 0.21? That would imply that 0.20.x users are testing the 0.21.0 release
< MarcoFalke> jeremyrubin: Not in the one that is rc right now
< jnewbery> jeremyrubin: no. 20.1 already has an rc
< jeremyrubin> that's what I thought, was confused by the 'get it in'
< jeremyrubin> will review
< sdaftuar> MarcoFalke: are you suggesting that the 0.20.x that has wtxid-relay should be held until 0.21 is released?
< wumpus> yes, that's what he suggests
< MarcoFalke> sdaftuar: I am asking if we should
< wumpus> I think it makes sense
< jeremyrubin> I think it should release whenever it's appropriate maybe? Because isn't there a benefit to having deeper backport penetration before 0.21 launches?
< sdaftuar> that seems reasonabel to me as well, i hadn't consideredt hat
< sdaftuar> i think we should get the other mitigation in sooner though
< MarcoFalke> Not saying we must, but something to consider
< wumpus> sdaftuar: definitely, it's different for the other one as it's not a feature
< jeremyrubin> what about plugging in sdaftuar's minor mitigation into the one into current rc? Or is that bad to disrupt that flow?
< wumpus> no
< sdaftuar> jeremyrubin: it has 0 acks i think!
< sipa> i think that would a serious violation of process
< sipa> there is no bug to be fixed here
< sipa> and no regression in the release
< sipa> and it's not even in master!
< luke-jr> one could argue wasting bandwidth is a bug
< wumpus> 0.20.1 is done, we've just decided that in last topic, it's reasonably urgent to get it released and ther ehave been no cricital problems, and anyhow, what sipa says
< sdaftuar> no bandwidth is being wasetd now though
< sdaftuar> well
< instagibbs> it's not a regression except for the fact other nodes will be doing different behavior someday
< sdaftuar> you know hwat i mean
< instagibbs> maybe
< sipa> it can go in 0.20.2
< wumpus> yes
< instagibbs> yeah i dont think there's a rush there
< sipa> agree
< MarcoFalke> agree with sipa
< wumpus> again, please do not try to rush things
< sdaftuar> agree with marco
< jeremyrubin> I'm just trying to understand sdaftuar's comment that the mitigation goes in sooner
< sdaftuar> into 0.20 branch
< jeremyrubin> ah I thought you were meaning a 0.20.3 and 0.20.4 which seemed excessive
< jnewbery> I don't think it matters that much which order they get merged into the 0.20 branch. 19620 is so tiny that conflicts aren't an issue whichever order things happen
< wumpus> jnewbery: that's good to know
< sdaftuar> jnewbery: i interpreted the delay of 0.20.x with wtxid-relay as a suggestion to hold off on the merge
< sdaftuar> in case we needed another 0.20 minor release
< jnewbery> My comment earlier about reviewing now was more about people reviewing when wtxid hasn't been paged out of their memory. Nothing about changing or rushing process
< sdaftuar> and i was thinking that in that event, we might as well get the other mitigation out there since it's pretty easy
< jnewbery> but if it interferes with the normal 0.20.x release process, then there's no problem waiting
< sipa> jnewbery: that makes sense
< MarcoFalke> Jup, good to have the backport open already, so that it can get review, but no rush in merging it
< sipa> i can't remember if we ever made that consideration before - that a feature would appear in a backport release before a new major release
< sipa> new features in backports are arguably rare in any case
< jeremyrubin> I mean is wtxid relay really a feature or a architectural mitigation? You could argue it belonged in 0.13...
< sdaftuar> feature
< jnewbery> I don't think such semantic distinctions are very interesting. It's a large code change
< sdaftuar> anyway i think we have a plan forward?
< sipa> i think so
< wumpus> yes
< sdaftuar> i'll make some backports
< instagibbs> great
< jnewbery> sdaftuar: you mean 19620->v0.20 and 19620->v0.19?
< sdaftuar> yeah
< sdaftuar> thx for biting the bullet on wtxid-relay :)
< jnewbery> sdaftuar: of course. It wasn't actually that bad
< jeremyrubin> +1 fast work!
< wumpus> any other topics?
< instagibbs> reviewing it was also not painful at all fwiw
< sdaftuar> is there a p2p focused irc meeting happening?
< instagibbs> hint hint
< sdaftuar> (you can make that a topic if you want, if not a one word answer)
< sipa> jnewbery inquired if there was interest in one last week or the week before, iirc
< sipa> haven't heard anything since
< jnewbery> sdaftuar: yes. I said I'd figure out a way to schedule it but haven't done so yet
< jnewbery> my preference would be for roughly the same time as this but on a different day, but that's perhaps unfair to some people who might want to attend
< sdaftuar> ok, cool. +1 if we can get the timing to work out
< sdaftuar> i have some p2p stuff i would love to discuss with others
< MarcoFalke> Do it on Friday opposite bi-weekly of the wallet meeting ;)
< instagibbs> we have us west, east, eastern europe, at least among contributors
< instagibbs> for p2p
< luke-jr> MarcoFalke: IIRC there's people who want to attend, whom this time does not work for
< ajonas> Might want to check with AJ to see if he's interested
< jnewbery> unfortunately it turns out the flatearthers were wrong and there isn't a time that's convenient for everyone
< luke-jr> jnewbery: hmm, putting it that way.. can we modify the Earth to be flat? :P
< sdaftuar> might be a consensus change
< sipa> if the model doesn't fit the data, change the data
< troygiorshev> likely people who this time won't work for aren't here right now to say it :)
< luke-jr> troygiorshev: heh, true
< sipa> troygiorshev: yes, that was my concern too with asking it here ;)
< sipa> "Can everyone who is absent raise their hands?"
< luke-jr> maybe ask at the opposite time review club meeting?
< jeremyrubin> luke-jr: you should know that it's not a modification if you're changing it to how it already is
< luke-jr> jeremyrubin: wut
< * jeremyrubin> is a flat earther
< luke-jr> …
< sipa> i think this concludes the meeting?
< wumpus> #endmeeting
< lightningbot> Meeting ended Thu Jul 30 19:55:20 2020 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
< jnewbery> action is still with me to figure out a time (/method for deciding a time). If anyone has suggestions or wants to help, feel free to message me
< instagibbs> troygiorshev, im mentally going through a checklist of p2p constributors instead of asking here :P
< jeremyrubin> just pick a time and move it forward by 30 minutes every time someone complains?
< sipa> jnewbery: easy, whenever a block with a height that's a multiple of 2016 is mined
< luke-jr> sipa: what is the drift on that?
< instagibbs> yes we need more incentive to skew block times :|
< aj> MarcoFalke: p2p meetings at 5am on saturday? thanks, i'll pass...
< fanquake> heh
< bitcoin-git> [bitcoin] Empact opened pull request #19631: test: Wait for 'cmpctblock' in p2p_compactblocks when it is expected (master...2020-07-receive_block_announcment) https://github.com/bitcoin/bitcoin/pull/19631