19:00:19 <wumpus> #startmeeting
19:00:19 <lightningbot> Meeting started Thu Jul 30 19:00:19 2020 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:19 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:00:21 <luke-jr> hi
19:00:23 <sipsorcery> hi
19:00:25 <meshcollider> hi
19:00:26 <troygiorshev> hi
19:00:28 <fjahr> hi
19:00:31 <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
19:00:32 <wumpus> amiti fjahr jeremyrubin lightlike emilengler jonatack hebasto jb55 elichai2
19:00:32 <hebasto> hi
19:00:33 <achow101> hi
19:00:39 <pinheadmz> hi
19:00:42 <lightlike> hi
19:00:50 <jamesob> hi
19:00:52 <wumpus> one proposed meeting topic:  0.20.1rc1 testing (fanquake)
19:00:58 <wumpus> any last minute topic ideas?
19:00:59 <jeremyrubin> hi
19:01:13 <jeremyrubin> Maybe backports of wtxid v.s. the thing suhas proposed?
19:01:20 <wumpus> ok
19:02:08 <wumpus> #topic High priority for review
19:02:25 <achow101> #19077 pls
19:02:27 <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
19:02:31 <wumpus> 10 blockers, 1 bugfix, 3 chasing concept ACK in https://github.com/bitcoin/bitcoin/projects/8
19:02:54 <jamesob> achow101: looking forward to reading that one
19:03:11 <wumpus> achow101: added
19:03:50 <wumpus> I'm happy we got through all the preparation PRs and got to the main one now :)
19:03:59 <meshcollider> Yes \o/
19:04:10 <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)
19:05:25 <wumpus> thanks
19:05:57 <wumpus> anything else to add/remove or that is ready for merge?
19:06:36 <wumpus> #topic 0.20.1rc1 testing
19:06:46 <luke-jr> is what ready for merge? O.o
19:06:48 <wumpus> Has anyone had/seen any issues during testing so far?
19:06:55 <wumpus> luke-jr: anything on high priority for review
19:07:01 <luke-jr> ah
19:07:20 <MarcoFalke> Might be ready to ship
19:07:34 <MarcoFalke> Only change since rc has been a doc commit and a travis commit
19:07:46 <hebasto> ^ agree
19:07:49 <wumpus> I think so too
19:07:58 <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
19:08:08 <luke-jr> and it's expected that there will be some delay in my stats picking things up
19:08:13 <wumpus> no new problems have been reported with .1 afaik
19:08:43 <wumpus> luke-jr: happy to hear 13 people are testing it :)
19:08:55 <wumpus> (at least)
19:10:10 <wumpus> I'm planning to tag -final soon then, it's good to get this release out of the door
19:10:37 <wumpus> #topic backport of wtxid versus alternative (jeremyrubin)
19:11:00 <jeremyrubin> Hmmm well it seems we lost suhas a moment ago
19:11:05 <wumpus> the backport is #19606
19:11:07 <gribble> https://github.com/bitcoin/bitcoin/issues/19606 | Backport wtxid relay to v0.20 by jnewbery · Pull Request #19606 · bitcoin/bitcoin · GitHub
19:11:16 <sipa> and the alternative is #19620
19:11:17 <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
19:11:29 <wumpus> right ^^
19:11:31 <sipa> it isn't really an alternative - they're both independent improvements that should both go in master
19:11:52 <MarcoFalke> Does it make sense to ship wtxid in 0.20 before it is shipped in 0.21?
19:11:53 <luke-jr> wb sdaftuar
19:12:00 <wumpus> so I think the question is which one (or both) to backport to 0.20
19:12:02 <MarcoFalke> It's not exactly a bugfix and it might come with risks
19:12:05 <sipa> but i think that one is sufficient to remove concerns about deploying new segwit softforks
19:12:07 <jeremyrubin> is it correct to say they're backport alternatives?
19:12:14 <jnewbery> #19606 is actually quite a straightforward backport. Most of the conflicts are trivial.
19:12:15 <gribble> https://github.com/bitcoin/bitcoin/issues/19606 | Backport wtxid relay to v0.20 by jnewbery · Pull Request #19606 · bitcoin/bitcoin · GitHub
19:12:21 <luke-jr> I thought we figured out we didn't strictly need either?
19:12:57 <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
19:12:59 <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
19:13:01 <jeremyrubin> Out of curiosity, can we backport either easily to a 19.x? Would that matter?
19:13:02 <luke-jr> (so long as the policy changes were left for 0.21+)
19:14:16 <sdaftuar> sorry my connection is super laggy right now. but i assume we could easily backport #19620 to any recent release
19:14:17 <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
19:14:35 <jeremyrubin> luke-jr: it would be nice to have less dependency though on when policy changes are advisable
19:14:38 <wumpus> hm 0.19 backport would be much more work (code differs more) and gets much less testing
19:15:07 <jeremyrubin> sdaftuar's patch seems to be really simple compared to wtxid relay
19:15:08 <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
19:15:25 <jnewbery> I think 19620 is independently good and should also be backported
19:15:27 <jeremyrubin> maybe backport both to 0.20, sdaftuar patch to 0.19?
19:15:27 <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
19:16:16 <luke-jr> sdaftuar: considering we don't need it for Taproot(consensus), is there another reason you want wtxid relay in 0.20?
19:16:16 <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
19:16:35 <wumpus> we can make an exception to normallly not backporting p2p features as it's requirement for taproot
19:16:44 <wumpus> which will also be backported
19:16:50 <instagibbs> we normally backport activations, hence this yeah
19:16:52 <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 :)
19:16:58 <luke-jr> ah
19:17:03 <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
19:17:04 <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
19:17:07 <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
19:17:35 <sipa> which is a possibility, but i think just backporting #19620 is a lot simpler
19:17:37 <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
19:17:47 <luke-jr> sipa: I mean we can deploy Taproot(consensus) independently from / in parallel to Taproot(policy)
19:18:15 <luke-jr> the former is going to take at least a year anyway, so 0.21 will be mature by the time it activates
19:18:23 <sipa> luke-jr: sure... but that won't protect old nodes
19:18:26 <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?
19:18:39 <sipa> (by the time things actually start being relayed, from whatever codebase)
19:19:19 <luke-jr> sipa: that's true no matter what release we put it into?
19:20:01 <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
19:20:09 <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
19:20:25 <jnewbery> sdaftuar: I agree
19:20:31 <wumpus> I agree too
19:20:37 <luke-jr> sipa: I'm not opposed
19:20:42 <sipa> ok
19:20:48 <jnewbery> 0.18 is EOL in Feb next year, Taproot won't activate before then, probably
19:21:17 <jnewbery> so if we backport 19620 to 0.19, anyone on a supported version has a minor release they can upgrade to
19:21:32 <wumpus> yes
19:21:34 <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
19:22:02 <jeremyrubin> jnewbery: I don't think anyone can complain about that plan
19:22:08 <sdaftuar> they can just put an upgraded node in between their old node and the network
19:22:11 <sipa> yeah, seems reasonable to me
19:22:27 <luke-jr> jeremyrubin: if someone insists on using a pre-0.19 version, they can fund longer-term maintenance thereof..
19:22:44 <luke-jr> or what sdaftuar suggested
19:22:55 <sipa> of course, i don't think we have obligations to maintain EOL versions
19:24:44 <jeremyrubin> When is EOL for 0.19?
19:25:04 <wumpus> so the plan is to backport  #19606 to 0.20 and #19620 to 0.19 and 0.20?
19:25:06 <gribble> https://github.com/bitcoin/bitcoin/issues/19606 | Backport wtxid relay to v0.20 by jnewbery · Pull Request #19606 · bitcoin/bitcoin · GitHub
19:25:07 <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
19:25:07 <instagibbs> should be a little while I think?
19:25:26 <jnewbery> wumpus: sounds good to me
19:25:37 <wumpus> okay!
19:25:47 <instagibbs> 0.17 is 2020-08-01 eol
19:25:51 <instagibbs> soon(TM)
19:25:58 <sdaftuar> sounds good
19:26:07 <sipa> sounds reasonable if wtxid relay (and followups) are easy to do in 0.20
19:26:16 <luke-jr> isn't 0.19 unsupported when 0.21 is released?
19:26:36 <sdaftuar> sipa: good point about followups
19:26:51 <jeremyrubin> I think we could change that to be the policy going forward, but https://bitcoincore.org/en/lifecycle/ says otherwise
19:26:53 <sipa> random thought: should the bitcoincore twitter account announce when major releases go unsupported/EOL ?
19:26:55 <sdaftuar> i think your pr about orphan fetching just got conflicted due to a refactor that was merged
19:27:06 <instagibbs> "maintenance end" I think luke-jr
19:27:07 <sipa> sdaftuar: will fix soon, seems trivial
19:27:09 <instagibbs> im reading the website
19:27:11 <sdaftuar> so perhaps we should highlight the followup prs that would be backported as well?
19:27:21 <luke-jr> instagibbs: yeah, me too - it's not clear when EOL is
19:27:30 <sdaftuar> (if more than one)
19:27:34 <achow101> 0.19 eol is after 0.22
19:27:38 <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.
19:28:06 <instagibbs> i think maintenance is more what we're considering
19:28:07 <sipa> so wtxid relay is #18044 #19590 #19569... anything else?
19:28:11 <gribble> https://github.com/bitcoin/bitcoin/issues/18044 | Use wtxid for transaction relay by sdaftuar · Pull Request #18044 · bitcoin/bitcoin · GitHub
19:28:13 <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
19:28:15 <gribble> https://github.com/bitcoin/bitcoin/issues/19569 | Enable fetching of orphan parents from wtxid peers by sipa · Pull Request #19569 · bitcoin/bitcoin · GitHub
19:28:32 <wumpus> sipa: seems fine to me, though in general I don't like urging people to upgrade unless there's a security problem
19:28:32 <jnewbery> sipa: yes, it'd be good if the twitter account announced EOLs
19:28:37 <luke-jr> instagibbs: true, this isn't a critical issue
19:28:50 <jnewbery> I don't think 19590 needs to be backported
19:29:09 <jnewbery> we can just take the existing 19569 branch before you rebase it on that
19:29:11 <sdaftuar> jnewbery: it'll make 19569 easier to backport due to the conflicts i think?
19:29:15 <sipa> jnewbery: it doesn't, but it would make the master and backported version of 19569 somewhat different
19:29:19 <instagibbs> it's really tiny...
19:29:25 <sipa> okay
19:29:33 <sipa> i don't think there are any major disagreements here
19:30:01 <jeremyrubin> if you backport #19748 it will take care of the memory overhead from the new wtxid index, but far from required
19:30:01 <gribble> https://github.com/bitcoin/bitcoin/issues/19748 | HTTP Error 404: Not Found
19:30:12 <jeremyrubin> #19478
19:30:14 <gribble> https://github.com/bitcoin/bitcoin/issues/19478 | Remove CTxMempool::mapLinks data structure member by JeremyRubin · Pull Request #19478 · bitcoin/bitcoin · GitHub
19:30:14 <wumpus> any other topics?
19:31:44 <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
19:31:45 <gribble> https://github.com/bitcoin/bitcoin/issues/19606 | Backport wtxid relay to v0.20 by jnewbery · Pull Request #19606 · bitcoin/bitcoin · GitHub
19:31:48 <gribble> https://github.com/bitcoin/bitcoin/issues/18044 | Use wtxid for transaction relay by sdaftuar · Pull Request #18044 · bitcoin/bitcoin · GitHub
19:31:50 <jnewbery> it'll make review easier
19:32:14 <jnewbery> no point in hanging around if we want to get it in
19:33:13 <bitcoin-git> [13bitcoin] 15darosior opened pull request #19630: Refactor fee estimation code (06master...0620/07/refactor_feeest_code) 02https://github.com/bitcoin/bitcoin/pull/19630
19:33:52 <jeremyrubin> wait is it going into the upcoming minor?
19:33:59 <jeremyrubin> I thought it's the next 0.20 minor?
19:34:02 <MarcoFalke> And should it be released before 0.21? That would imply that 0.20.x users are testing the 0.21.0 release
19:34:25 <MarcoFalke> jeremyrubin: Not in the one that is rc right now
19:34:42 <jnewbery> jeremyrubin: no. 20.1 already has an rc
19:34:55 <jeremyrubin> that's what I thought, was confused by the 'get it in'
19:35:04 <jeremyrubin> will review
19:35:41 <sdaftuar> MarcoFalke: are you suggesting that the 0.20.x that has wtxid-relay should be held until 0.21 is released?
19:36:13 <wumpus> yes, that's what he suggests
19:36:19 <MarcoFalke> sdaftuar: I am asking if we should
19:36:24 <wumpus> I think it makes sense
19:36:32 <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?
19:36:33 <sdaftuar> that seems reasonabel to me as well, i hadn't consideredt hat
19:36:41 <sdaftuar> i think we should get the other mitigation in sooner though
19:36:45 <MarcoFalke> Not saying we must, but something to consider
19:37:09 <wumpus> sdaftuar: definitely, it's different for the other one as it's not a feature
19:37:35 <jeremyrubin> what about plugging in sdaftuar's minor mitigation into the one into current rc? Or is that bad to disrupt that flow?
19:37:52 <wumpus> no
19:37:56 <sdaftuar> jeremyrubin: it has 0 acks i think!
19:37:57 <sipa> i think that would a serious violation of process
19:38:02 <sipa> there is no bug to be fixed here
19:38:06 <sipa> and no regression in the release
19:38:12 <sipa> and it's not even in master!
19:38:36 <luke-jr> one could argue wasting bandwidth is a bug
19:38:47 <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
19:38:49 <sdaftuar> no bandwidth is being wasetd now though
19:38:52 <sdaftuar> well
19:38:56 <instagibbs> it's not a regression except for the fact other nodes will be doing different behavior someday
19:38:57 <sdaftuar> you know hwat i mean
19:38:57 <instagibbs> maybe
19:39:08 <sipa> it can go in 0.20.2
19:39:13 <wumpus> yes
19:39:16 <instagibbs> yeah i dont think there's a rush there
19:39:20 <sipa> agree
19:39:23 <MarcoFalke> agree with sipa
19:39:25 <wumpus> again, please do not try to rush things
19:39:29 <sdaftuar> agree with marco
19:39:30 <jeremyrubin> I'm just trying to understand sdaftuar's comment that the mitigation goes in sooner
19:39:36 <sdaftuar> into 0.20 branch
19:40:04 <jeremyrubin> ah I thought you were meaning a 0.20.3 and 0.20.4 which seemed excessive
19:40:36 <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
19:40:57 <wumpus> jnewbery: that's good to know
19:41:00 <sdaftuar> jnewbery: i interpreted the delay of 0.20.x with wtxid-relay as a suggestion to hold off on the merge
19:41:10 <sdaftuar> in case we needed another 0.20 minor release
19:41:22 <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
19:42:06 <sdaftuar> and i was thinking that in that event, we might as well get the other mitigation out there since it's pretty easy
19:42:07 <jnewbery> but if it interferes with the normal 0.20.x release process, then there's no problem waiting
19:42:07 <sipa> jnewbery: that makes sense
19:42:13 <MarcoFalke> Jup, good to have the backport open already, so that it can get review, but no rush in merging it
19:42:51 <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
19:43:02 <sipa> new features in backports are arguably rare in any case
19:44:01 <jeremyrubin> I mean is wtxid relay really a feature or a architectural mitigation? You could argue it belonged in 0.13...
19:44:26 <sdaftuar> feature
19:44:58 <jnewbery> I don't think such semantic distinctions are very interesting. It's a large code change
19:44:59 <sdaftuar> anyway i think we have a plan forward?
19:45:29 <sipa> i think so
19:45:31 <wumpus> yes
19:45:32 <sdaftuar> i'll make some backports
19:46:00 <instagibbs> great
19:46:23 <jnewbery> sdaftuar: you mean 19620->v0.20 and 19620->v0.19?
19:46:32 <sdaftuar> yeah
19:46:41 <sdaftuar> thx for biting the bullet on wtxid-relay :)
19:47:14 <jnewbery> sdaftuar: of course. It wasn't actually that bad
19:47:14 <jeremyrubin> +1 fast work!
19:48:09 <wumpus> any other topics?
19:48:35 <instagibbs> reviewing it was also not painful at all fwiw
19:48:35 <sdaftuar> is there a p2p focused irc meeting happening?
19:48:36 <instagibbs> hint hint
19:49:13 <sdaftuar> (you can make that a topic if you want, if not a one word answer)
19:49:37 <sipa> jnewbery inquired if there was interest in one last week or the week before, iirc
19:49:42 <sipa> haven't heard anything since
19:49:42 <jnewbery> sdaftuar: yes. I said I'd figure out a way to schedule it but haven't done so yet
19:50:15 <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
19:50:34 <sdaftuar> ok, cool. +1 if we can get the timing to work out
19:50:46 <sdaftuar> i have some p2p stuff i would love to discuss with others
19:50:47 <MarcoFalke> Do it on Friday opposite bi-weekly of the wallet meeting ;)
19:50:55 <instagibbs> we have us west, east, eastern europe, at least among contributors
19:50:59 <instagibbs> for p2p
19:51:15 <luke-jr> MarcoFalke: IIRC there's people who want to attend, whom this time does not work for
19:51:57 <ajonas> Might want to check with AJ to see if he's interested
19:52:05 <jnewbery> unfortunately it turns out the flatearthers were wrong and there isn't a time that's convenient for everyone
19:52:27 <luke-jr> jnewbery: hmm, putting it that way.. can we modify the Earth to be flat? :P
19:52:38 <sdaftuar> might be a consensus change
19:52:39 <sipa> if the model doesn't fit the data, change the data
19:52:59 <troygiorshev> likely people who this time won't work for aren't here right now to say it :)
19:53:10 <luke-jr> troygiorshev: heh, true
19:53:14 <sipa> troygiorshev: yes, that was my concern too with asking it here ;)
19:53:27 <sipa> "Can everyone who is absent raise their hands?"
19:53:43 <luke-jr> maybe ask at the opposite time review club meeting?
19:53:50 <jeremyrubin> luke-jr: you should know that it's not a modification if you're changing it to how it already is
19:53:59 <luke-jr> jeremyrubin: wut
19:54:18 * jeremyrubin is a flat earther
19:54:27 <luke-jr> …
19:55:08 <sipa> i think this concludes the meeting?
19:55:20 <wumpus> #endmeeting