19:00:15 <wumpus> #startmeeting
19:00:15 <lightningbot> Meeting started Thu Mar 21 19:00:15 2019 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:15 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:00:18 <provoostenator> hi
19:00:19 <jonasschnelli> hi
19:00:22 <jnewbery> hi
19:00:47 <MarcoFalke> yo
19:00:48 <kanzure> hi
19:00:59 <achow101> hi
19:01:22 <MarcoFalke> When rc3?
19:01:32 <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
19:01:35 <instagibbs> hi
19:01:41 <sipa> hi
19:01:44 <promag> hi
19:01:45 <luke-jr> hi
19:01:47 <gleb> hi
19:01:49 <meshcollider> hi
19:02:01 <wumpus> MarcoFalke: dunno, rc2 was only very short ago, might want to wait a bit for test results
19:02:23 <MarcoFalke> Early next week?
19:02:26 <jamesob> hi
19:02:34 <moneyball> hi
19:02:41 <wumpus> MarcoFalke: sgtm
19:02:41 <luke-jr> hi
19:02:48 <jonasschnelli> This #15310 needs probably a fix until rc3
19:02:49 <gribble> https://github.com/bitcoin/bitcoin/issues/15310 | gui: crash if encrypt / change passphrase window is open and wallet is unloaded · Issue #15310 · bitcoin/bitcoin · GitHub
19:03:27 <jonasschnelli> Where two proposal to fix it are available: #15313 and #15614 (though not enough review)
19:03:29 <gribble> https://github.com/bitcoin/bitcoin/issues/15313 | Qt: avoid AskPassphraseDialog synchronous QDialog.exec() calls by jonasschnelli · Pull Request #15313 · bitcoin/bitcoin · GitHub
19:03:30 <promag> jonasschnelli: maybe #15614
19:03:31 <gribble> https://github.com/bitcoin/bitcoin/issues/15614 | 0.18: gui: Defer removeAndDeleteWallet when no modal widget is active by promag · Pull Request #15614 · bitcoin/bitcoin · GitHub
19:03:33 <gribble> https://github.com/bitcoin/bitcoin/issues/15614 | 0.18: gui: Defer removeAndDeleteWallet when no modal widget is active by promag · Pull Request #15614 · bitcoin/bitcoin · GitHub
19:04:42 <provoostenator> I'll take a look at both
19:04:46 <wumpus> what is the different between the approaches?
19:04:47 <jonasschnelli> gmaxwell wanted to revert the PR that causes the issue (GUI load/unload)... though I think #15313 is fine
19:04:48 <gribble> https://github.com/bitcoin/bitcoin/issues/15313 | Qt: avoid AskPassphraseDialog synchronous QDialog.exec() calls by jonasschnelli · Pull Request #15313 · bitcoin/bitcoin · GitHub
19:05:17 <jonasschnelli> The #15614 fix delays the unload until all modal windows haven been closed
19:05:20 <gribble> https://github.com/bitcoin/bitcoin/issues/15614 | 0.18: gui: Defer removeAndDeleteWallet when no modal widget is active by promag · Pull Request #15614 · bitcoin/bitcoin · GitHub
19:05:32 <jonasschnelli> where #15313 does close them directly
19:05:33 <gribble> https://github.com/bitcoin/bitcoin/issues/15313 | Qt: avoid AskPassphraseDialog synchronous QDialog.exec() calls by jonasschnelli · Pull Request #15313 · bitcoin/bitcoin · GitHub
19:05:59 <wumpus> so is any one decidedly simpler for a last minute rc fix?
19:06:03 <jonasschnelli> IMO its an edge case (GUI unload wallet via RPC when -server is active)
19:06:11 <promag> right ^
19:06:24 <jonasschnelli> For a last minut fix, promag's 15313 is probably more sane
19:06:31 <promag> for 0.18 the shorter is 15614
19:06:32 <jonasschnelli> It just can make unloadwallet time out
19:06:32 <luke-jr> does RPC unload actually go through GUI walletmodel code like that?
19:06:35 <wumpus> still, someone apparently stumbled on it in the short testing duration
19:06:59 <wumpus> luke-jr: it should trigger the same notifications
19:07:00 <jonasschnelli> luke-jr: it does unload the wallet and there are synchonous dialog calls (the root cause) which leads to a crash
19:07:21 * jonasschnelli stabs synchronous modal dialog calls
19:07:30 <luke-jr> jonasschnelli: I get that, I just don't understand how #15614 works
19:07:31 <wumpus> ok I'll contingently tag 15313 for 0.18.0 then
19:07:33 <gribble> https://github.com/bitcoin/bitcoin/issues/15614 | 0.18: gui: Defer removeAndDeleteWallet when no modal widget is active by promag · Pull Request #15614 · bitcoin/bitcoin · GitHub
19:07:46 <promag> luke-jr: the issue comes from QDialog::exec, which spins another event loop
19:08:03 <jonasschnelli> 15313 will just wait until user closes it, which can lead to a timeout in RPC unloadwallet (probably okay)
19:08:11 <wumpus> oh, was already tagged
19:08:24 <jonasschnelli> Sry,... wrong. I meant 15614 is the one that waits
19:08:39 <jonasschnelli> 15313 does close it explicit and then unload the wallet
19:08:51 <jonasschnelli> but not all dialogs can be closed with the current code (needs major refactoring)
19:09:11 <jonasschnelli> lets just go with 15614...
19:09:18 <promag> yap, I've started it but its too much for 0.18
19:09:50 <jonasschnelli> yes
19:09:53 <luke-jr> ok, I think I see how it works basically
19:09:57 <bitcoin-git> [13bitcoin] 15jonasschnelli closed pull request #15313: Qt: avoid AskPassphraseDialog synchronous QDialog.exec() calls (06master...062019/01/qt_exec) 02https://github.com/bitcoin/bitcoin/pull/15313
19:09:57 <wumpus> that's not really an option for 0.18.0, no, then I'd prefer the revert approach
19:10:08 <promag> luke-jr: 15614 delays the wallet model destruction after all dialogs are closed
19:10:10 <luke-jr> but does a focus change necessarily mean the GUI is done with it?
19:10:35 <luke-jr> specifically, isn't coin control non-modal?
19:10:38 <jonasschnelli> 15614 is a good fix for a case where someone unloads a wallet via RPC when using the GUI (probably rar use-cases)
19:11:03 <promag> luke-jr: afaik there is no signal to know the active window changed
19:11:12 <wumpus> jonasschnelli: ok good to know
19:11:13 <jonasschnelli> luke-jr: it just checks again... when the focus changes (since this is what happens if you close a Dialog)
19:11:51 <jonasschnelli> The long term fix is avoiding synchronous calls
19:12:15 <promag> jonasschnelli: luke-jr: actually now I remember there is QWindow::activeChanged since qt5
19:12:29 <promag> I'll recheck
19:12:48 <jonasschnelli> however, please review #15614 to merge it into 0.18 asap
19:12:49 <gribble> https://github.com/bitcoin/bitcoin/issues/15614 | 0.18: gui: Defer removeAndDeleteWallet when no modal widget is active by promag · Pull Request #15614 · bitcoin/bitcoin · GitHub
19:13:13 <jonasschnelli> we probably won't ship with known and fixable crashes
19:13:27 <MarcoFalke> #action review #15614
19:13:29 <gribble> https://github.com/bitcoin/bitcoin/issues/15614 | 0.18: gui: Defer removeAndDeleteWallet when no modal widget is active by promag · Pull Request #15614 · bitcoin/bitcoin · GitHub
19:13:38 <MarcoFalke> Should also do a forward-port to master?
19:13:57 <MarcoFalke> Or maybe open the pull against master?
19:14:33 <promag> MarcoFalke: I'll rather not, unless you prefer, cause the right fix is to remove qdialog::exec calls
19:14:57 <jonasschnelli> promag: regardless of the long term solution, we probably want this also in master
19:14:58 <promag> no strong opinion really
19:15:03 <luke-jr> things are supposed to go into master before backports (although I can think of cases where that's not viable, so maybe it should be a hard rule)
19:15:12 <jonasschnelli> what luke-jr says
19:15:13 <promag> MarcoFalke: I'll push it then
19:15:21 <luke-jr> shouldn't*
19:15:34 <wumpus> jonasschnelli: our usual strategy is to have everything in master first, so that no fixes get lost
19:15:45 <MarcoFalke> jup, agree with luke-jr
19:15:48 <promag> ok np
19:15:53 <jonasschnelli> wumpus: yes.
19:15:53 <wumpus> if something *only* applies to a branch there's of course an exception
19:16:05 <wumpus> butthat's not the case here
19:16:12 <promag> just note that it will be reverted
19:16:20 <wumpus> not reverted, replaced
19:16:27 <promag> right :)
19:16:29 <luke-jr> *shrug* reverts are fine when appropriate
19:16:45 <wumpus> reverts are fine if some change turns out to be bad
19:16:50 <wumpus> we could to that too …
19:16:57 <wumpus> that was gmaxwell's proposal right
19:17:19 <wumpus> though if other changes built on top since, it might be non-trivial now
19:17:21 <promag> reverting that brings other issues
19:17:44 <luke-jr> wumpus: we're talking about a revert of the bandaid fix
19:17:49 <luke-jr> eg, as part of a real fix
19:17:51 <wumpus> I think we shouldn't have merged those things so late, in retrspect
19:18:00 <promag> again, this is really very unlikely, you have to run bitcoin-qt -server
19:18:09 <wumpus> anyhow let's do the fix for rc3
19:18:12 <wumpus> any other topics?
19:18:15 <cfields> topic suggestion: win codesigning cert.
19:18:26 <luke-jr> would be nice to get getbalance fixed, but I need to run.. <.<
19:18:42 <wumpus> #topic win codesigning cert (cfields)
19:18:49 <cfields> I'm still trying to understand what's going on, but it seems as though the win cert has expired
19:19:03 <wumpus> oh?!?
19:19:04 <jonasschnelli> oh..
19:19:07 <cfields> But afacs it's not causing any problems.
19:19:17 <cfields> So I'm confused.
19:19:23 <jonasschnelli> cfields: should we register a new one via the Bitcoin Core Code Signing Association?
19:19:36 <cfields> I always do a test-install on Win7, and the cert should've been expired for rc2, but nothing complained.
19:19:47 <jonasschnelli> cfields: tolerance period? :-)
19:19:50 <cfields> jonasschnelli: I think yes, asap if possible.
19:20:26 <jonasschnelli> cfields: I have never done this. Glad if someone with Win experience wants to do it. I'm ready to support on the legal/address/payment side.
19:20:32 <cfields> jonasschnelli: If you're up for that, I'm happy to help.
19:20:49 <jonasschnelli> Okay. Lets do that together cfields.
19:20:53 <cfields> I haven't either, but I think I have a few records from the last cert.
19:20:58 <cfields> jonasschnelli: Thanks!
19:21:06 <wumpus> awesome, thanks jonasschnelli and cfields
19:21:16 <cfields> sorry if this causes problems..
19:21:19 <wumpus> without you we'd probably have to drop windows support :)
19:21:32 <jonasschnelli> Would also be good to get a sponsor for the Bitcoin Core Code Signing Association at some point (raise your hand if your willing)
19:21:32 <cfields> wumpus: maybe we should discuss an async win release?
19:21:49 <cfields> wumpus: Hah, in that case I'll leave!
19:21:57 <wumpus> cfields: how do you mean?
19:22:01 <cfields> async win release just in case, that is.
19:22:22 <gwillen> jonasschnelli: sponsor in what sense?
19:22:27 <cfields> If there's a cert problem that would delay the win release, it'd be a shame to hold up everything.
19:22:46 <jonasschnelli> gwillen: There are litte costs (domain, macOS developer programm and now the win code signing cert)
19:22:48 <cfields> heh, I realize this is like the 10th time now that I've suggested that :)
19:23:01 <wumpus> you mean doing a release without windows binaries?
19:23:09 <wumpus> I… don't think I want to do that
19:23:17 <wumpus> will get too many complaints
19:23:41 <cfields> wumpus: ok, no worries, just thinking of contingencies.
19:23:41 <luke-jr> jonasschnelli: I would prefer to see someone sponsor a neutral codesigning org
19:23:48 <gwillen> jonasschnelli: I am happy to pay little costs, I would assume there are plenty of people here willing but lmk
19:23:50 <jonasschnelli> Indeed. Also, watch out, this is a discussion rabbit hole (windows yes/no)
19:24:07 <wumpus> cfields: for an RC it's okay, I think
19:24:11 <wumpus> cfields: but not for final
19:24:20 <cfields> I would be curious to know if rc2 is busted on win10, though.
19:24:29 <cfields> If it is and nobody noticed, that'd be noteworthy.
19:24:31 <wumpus> I don't think it is
19:24:40 <wumpus> someone would have told me
19:24:42 <jonasschnelli> I'll do some VM testing asap
19:25:28 <cfields> thanks all. </topic>
19:25:35 <jonasschnelli> gwillen: great to hear.. just need to find a good way how to do this
19:25:55 <wumpus> any other topics ?
19:26:27 <jnewbery> We didn't talk about high priority for review, but I guess high priority isn't high priority when we have an upcoming release
19:26:45 <sipa> yeah
19:27:04 <jnewbery> My only suggestion would be to add #14121 to the list, which has a few ACKs and seems close to being mergeable
19:27:08 <wumpus> oh sorry, yes
19:27:14 <gribble> https://github.com/bitcoin/bitcoin/issues/14121 | Index for BIP 157 block filters by jimpo · Pull Request #14121 · bitcoin/bitcoin · GitHub
19:27:16 <wumpus> #topic High priority for review
19:27:35 <luke-jr> jonasschnelli, gwillen: (neutral as opposed to Core-only)
19:27:43 <jonasschnelli> luke-jr: makes little sense IMO
19:28:35 <wumpus> 14121 added to https://github.com/bitcoin/bitcoin/projects/8
19:28:43 <MarcoFalke> May I suggest #15596 for high prio?
19:28:45 <gribble> https://github.com/bitcoin/bitcoin/issues/15596 | rpc: Ignore sendmany::minconf as dummy value by MarcoFalke · Pull Request #15596 · bitcoin/bitcoin · GitHub
19:29:16 <wumpus> MarcoFalke: ok, added
19:30:19 <jnewbery> It was great to see #10973 merged yesterday. Thanks to ryanofsky for putting so much work into it!
19:30:24 <gribble> https://github.com/bitcoin/bitcoin/issues/10973 | Refactor: separate wallet from node by ryanofsky · Pull Request #10973 · bitcoin/bitcoin · GitHub
19:30:34 <jonasschnelli> indeed
19:30:41 <wumpus> jnewbery: and right, we skipped high priority review just before the branch / rc1 release, but now that that is done, I suppose enough people are focusing on things to get into 0.19.0 already
19:30:45 <gwillen> luke-jr: I'm happy to pay minor costs either way but who outside core would use it?
19:31:03 <cfields> woohoo!
19:31:22 <promag> MarcoFalke: didn't know you could change base!
19:31:53 <jonasschnelli> me neither
19:32:02 <sipa> change base?
19:32:14 <jonasschnelli> switch a PR from 0.18 to master (as exampe)
19:32:28 <wumpus> and yes, congrats on #10973!
19:32:33 * MarcoFalke all you base belong to me
19:32:33 <gribble> https://github.com/bitcoin/bitcoin/issues/10973 | Refactor: separate wallet from node by ryanofsky · Pull Request #10973 · bitcoin/bitcoin · GitHub
19:32:40 <wumpus> sipa: change the target branch for a PR
19:32:46 <sipa> oh!
19:32:47 <ryanofsky> thanks all
19:34:10 <wumpus> any other topics?
19:35:11 <kanzure> mailing list update: migration still pending. linuxfoundation is in charge of this, and i don't get updates from them.
19:35:32 <kanzure> warren might have more info
19:35:49 <jonasschnelli> kanzure: thanks for the update
19:35:59 <kanzure> sorry it's not more helpful :)
19:36:04 <jonasschnelli> Maybe also write back that that email asking why it was so short notice
19:36:05 <wumpus> yes, he mentioned it, it's been delayed a bit
19:36:41 <warren> I'm writing a longer story of what led up to this for the list, and we have another delay due to one guy taking sick leave.
19:36:43 <kanzure> i suppose the reason for short notice is that we didn't inform everyone a year ago when linuxfoundation announced their intentions
19:37:06 <kanzure> although i do vaguely recall talking about it
19:37:11 <jonasschnelli> Yes. But the list doesn't know that
19:37:21 <jonasschnelli> Or I missed it
19:38:42 <warren> Late 2017 they notified us that mailman2 was unmaintainable and they had to eventually migrate all their lists onto a new platform. mailman2 had  a dead upstream for years and mailman3 they tried but determined was unusable. <then a long story of evaluating options follows>
19:38:57 <warren> <then how predictably people will try to step up to claim they can self-host it>
19:39:19 <warren> This is a long story and the list deserves to hear everything that happened and was considered.
19:39:22 <wumpus> yes, I remember that
19:40:19 <wumpus> it's increasingly difficult to do mailing lists, no one really cares anymore
19:41:19 <jonasschnelli> which is sad
19:41:20 <wumpus> (maybe except for the linux mailing list and freedesktop/mesa, everyone hates using them, let alone maintaining them)
19:41:22 <warren> <I did try to ping many of you over the past year for opinions, got very little, then one of you blamed me for not just forcing a decision, I did one more round of asking many of you for opinions, most of you replied you don't care, we considered self-hosting options evaluated by aj, settled on the least effort solution with self-hosted archives>  will explain all this on list.
19:41:50 <kanzure> alright alright, no need to assign blame
19:42:13 <wumpus> it's no one's responsibility so also no one's blame
19:42:24 <warren> The guy who blamed me was right. It was unrealstic of me to expect "the group" could make a decision when most people don't care, they just want it to work.
19:43:17 <wumpus> in principle it's even off topic in the bitcoin core meeting, the bitcoin-dev mailing list is outside it's scope, not that I mind
19:43:53 <jonasschnelli> Yes. It's not managed by the Core team
19:43:55 <wumpus> anyhow, I think we had this, any other topics?
19:44:01 <wumpus> right
19:44:05 <warren> right
19:44:21 <wumpus> don't ask who it should be managed by, but it's not core's thing
19:45:18 <wumpus> anyone who does care about the list should be happy that warren is doing this work at all, if not, it would just disappear
19:46:15 <jnewbery> ^ agree. Thanks warren!
19:46:17 <warren> It's worth noting despite trying to deprecate the old mailman2 server they've tried to keep it online for us and a few other dev communities who had a hard time moving, and most of their downtime trouble was due to DoS attacks targeting only bitcoin-dev.
19:46:49 <jonasschnelli> *sigh*
19:46:51 <warren> The new infrastructure they recommend they are not concerned about DoS attacks, it's expected and better maintained so it won't fall over so easily.
19:48:40 <wumpus> thanks to the Linux Foundation too, then! it wouldn't be crazy for them to drop bitcoin-dev if it's such a hot potato
19:48:56 <wumpus> going to end this meeting, I don't think there's any more topics
19:48:58 <wumpus> #endmeeting