19:01:05 <wumpus> #startmeeting
19:01:05 <lightningbot> Meeting started Thu Aug  6 19:01:05 2020 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:01:05 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:01:16 <wumpus> I don't think so!
19:01:22 <kanzure> hi
19:01:24 <hebasto> hi
19:01:25 <sipsorcery> hi
19:01:26 <pinheadmz> hi
19:01:30 <meshcollider> hi
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 moneyball kvaciral ariard digi_james
19:01:33 <dongcarl> :)
19:01:34 <wumpus> amiti fjahr jeremyrubin lightlike emilengler jonatack hebasto jb55 elichai2
19:01:35 <achow101> hi
19:01:43 <jb55> hi
19:01:57 <sipa> dongcarl: the meeting timestamp increases by around 604800 seconds per meeting
19:02:04 <wumpus> two pre-proposed meeting topics for today
19:02:08 <ariard> hi
19:02:09 <jeremyrubin> hi
19:02:09 <wumpus> (marcofalke) add #19629 to high prio, discuss whether to remove the pulls that need rebase from high prio. (MarcoFalke, but won't be around)
19:02:11 <gribble> https://github.com/bitcoin/bitcoin/issues/19629 | Pass mempool pointer to chainstate constructor by MarcoFalke · Pull Request #19629 · bitcoin/bitcoin · GitHub
19:02:25 <wumpus> (achow101) what to do about zapwallettxes
19:02:35 <dongcarl> sipa: rings true!
19:02:52 <wumpus> the first is mergeable with the normal high prio for review topic
19:03:01 <ariard> dongcarl: don't trust NTP
19:03:54 <wumpus> any other topics?
19:04:00 <wumpus> sipa: yup, exactly
19:04:39 <wumpus> meetings are scheulded 0.6048 megaseconds apart
19:04:53 <wumpus> #topic High priority for review
19:05:31 <wumpus> MarcoFalke's PR was already added
19:05:36 <jnewbery> hi
19:05:45 <wumpus> 10 blockers 1 bugfix 3 chasing concept ACK
19:05:56 <wumpus> https://github.com/bitcoin/bitcoin/projects/8
19:06:26 <wumpus> anything to add / remove, or that is ready for merge?
19:06:56 <wumpus> Marco suggested removing PRs that have needed rebase for a while
19:07:05 <sdaftuar> oh, hi
19:07:41 <wumpus> I think this is mostly #18242
19:07:43 <jnewbery> I count three that need rebase: #18242 #19055 #11082
19:07:47 <gribble> https://github.com/bitcoin/bitcoin/issues/18242 | Add BIP324 encrypted p2p transport de-/serializer (only used in tests) by jonasschnelli · Pull Request #18242 · bitcoin/bitcoin · GitHub
19:07:47 <gribble> https://github.com/bitcoin/bitcoin/issues/18242 | Add BIP324 encrypted p2p transport de-/serializer (only used in tests) by jonasschnelli · Pull Request #18242 · bitcoin/bitcoin · GitHub
19:07:50 <gribble> https://github.com/bitcoin/bitcoin/issues/19055 | Add MuHash3072 implementation by fjahr · Pull Request #19055 · bitcoin/bitcoin · GitHub
19:07:51 <wumpus> jnewbery: oh!
19:07:52 <gribble> https://github.com/bitcoin/bitcoin/issues/11082 | Add new bitcoin_rw.conf file that is used for settings modified by this software itself by luke-jr · Pull Request #11082 · bitcoin/bitcoin · GitHub
19:08:21 <jnewbery> (just going by the tags)
19:08:36 <sdaftuar> #19620 is not high priority, but i would like it to be (though really it's ready for merge, i think)
19:08:38 <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:08:46 <sdaftuar> because once it's merged i'll be backporting
19:08:56 <wumpus> sdaftuar: will add
19:09:01 <sdaftuar> thank you!
19:09:35 <jnewbery> wumpus: just merge it. It has 5 ACKs :)
19:09:55 <wumpus> jnewbery: ok, after the meeting :)
19:10:27 <hebasto> is #11082 compatible with merged #15935 ?
19:10:28 <wumpus> jonasschnelli fjahr luke-jr anyone of you here?
19:10:30 <gribble> https://github.com/bitcoin/bitcoin/issues/11082 | Add new bitcoin_rw.conf file that is used for settings modified by this software itself by luke-jr · Pull Request #11082 · bitcoin/bitcoin · GitHub
19:10:33 <gribble> https://github.com/bitcoin/bitcoin/issues/15935 | Add /settings.json persistent settings storage by ryanofsky · Pull Request #15935 · bitcoin/bitcoin · GitHub
19:10:49 <achow101> hebasto: yes, they are compatible
19:11:14 <sipa> is there still a point?
19:11:17 <wumpus> please rebase your PR this week
19:12:04 <sipa> ah, i guess bitcoin_rw is for changing config options through UI etc, while settings.json is for other things like bans?
19:12:24 <wumpus> I'm not exactly sure what is the difference either
19:12:43 <wumpus> I guess one is for persisting the other is for changing it through RPC?
19:12:53 <hebasto> I thought they were two alternatives
19:12:53 <jnewbery> I think settings.json can be used for changing config options through GUI or RPC. The idea is to keep dynamic config in sync between bitcoind and bitcoin-qt
19:12:58 <achow101> my understanding was that bitcoin_rw was to let users also change the options
19:13:07 <achow101> and settings.json is only for bitcoind/bitcoin-qt
19:13:35 <achow101> I always viewed it as bitcoin_rw.conf was to supersede bitcoin.conf
19:13:36 <sipa> ah yes _rw would be accessible by bitcoin-cli etc as well
19:13:44 <fjahr> wumpus: will do, just wanted to answer your question as well at the same time
19:13:48 <wumpus> this doesn't add two separate settings mechanisms I hope?
19:13:49 <jnewbery> achow101: I don't think it makes sense to have yet another config source. How many do we have now?
19:14:00 <wumpus> jnewbery: hehe right
19:14:08 <achow101> jnewbery: 3. bitcoin.conf, settings.json, and QSettings
19:14:11 <wumpus> bitcoin-qt is a maze of different config sources already
19:14:24 <achow101> settings.json and QSettings are supposed to be combined I think
19:14:27 <achow101> but not yet
19:14:28 <wumpus> it's really subtle in which order they need to be interpreted to not break any existing things
19:14:29 <sipa> and command line
19:14:41 <jnewbery> and command line, and overrides in the source
19:15:02 <wumpus> right
19:15:13 <sipa> well i think we need ryanofsky and luke-jr to discuss this properly
19:15:22 <jnewbery> After settings.json, QSettings should only be used for QT GUI configuration (eg window size/location)
19:15:28 * jeremyrubin maybe a setting to let you pick which settings you are using
19:15:29 <wumpus> I understand the long-term goal is to drop qsettings for everything but the datadir path
19:15:40 <wumpus> oh and that
19:16:00 <wumpus> but that doesn't overlap with bitcoin.conf so isn't an issue :)
19:16:06 <achow101> wumpus: I think datadir path would want to be in settings.json
19:16:17 <wumpus> achow101: that creates a chicken egg problem !
19:16:22 <sipa> we should go back to storing settings in wallet.dat
19:16:33 * sipa hides
19:16:41 <sdaftuar> sipa: i was going to add an environment variable for enabling such behavior
19:16:55 <wumpus> e.g. on windows, QSettings is in the registry, on linux it's in the standard ~/.config path, it's the only root-of-settings really
19:16:57 <achow101> wumpus: i suppose it does, but it unifies qt and bitcoind datadir paths
19:17:26 <wumpus> I won't pretent to understand it anymore, sorry
19:17:28 <achow101> well conf always overrides qt anyways
19:17:32 <achow101> I think
19:17:54 <sdaftuar> perhaps a good first contributor project would be to document this somewhere, eg on our wiki
19:18:03 <wumpus> heh, yes
19:18:13 <achow101> i'm not sure a first contributor would be able to figure out this mess
19:18:25 <sdaftuar> achow101: fair point!
19:18:25 <wumpus> I'm terrified by that code in bitcoin-qt
19:18:34 <wumpus> took me a lot of work to get it exactly right so be careful
19:18:52 <wumpus> we don't have any tests for it because that's hard for GUI stuff
19:19:56 <wumpus> and yes, conf overrides qt except the initial datadir
19:20:02 <sipa> another reason to aim to move things out of qsettings
19:20:14 <sipa> as it unifies testing across bitcoind and bitcoin-qtr
19:20:19 <wumpus> yes
19:21:19 <wumpus> but on inital use of the GUI, it asks you to select a data directory, it needs to store this somewhere that is not in the data drectory
19:21:32 <sipa> indeed
19:21:43 <wumpus> I'm okay with this being somewhere else than QSettings but I'm not sure where :)
19:22:34 <wumpus> #topic what to do about zapwallettxes (achow101)
19:22:41 <sipa> zap it
19:22:52 <jeremyrubin> PR #?
19:22:53 <wumpus> #19671
19:22:55 <gribble> https://github.com/bitcoin/bitcoin/issues/19671 | wallet: Remove -zapwallettxes by achow101 · Pull Request #19671 · bitcoin/bitcoin · GitHub
19:22:57 <achow101> I think it's obvious that the -zapwallettxes startup option needs to go
19:23:08 <wumpus> sipa: +1
19:23:09 <achow101> but there's a question of where to put it
19:23:18 <achow101> options are wallet tool, rpc, or ditch it entirely
19:23:19 <sipa> wallet tool
19:23:20 <sipa> ?
19:23:23 <wumpus> also #19653
19:23:25 <gribble> https://github.com/bitcoin/bitcoin/issues/19653 | wallet: Replace -zapwallettxes with zapwallettxes RPC by achow101 · Pull Request #19653 · bitcoin/bitcoin · GitHub
19:23:38 <achow101> Since we have abandontransaction, I think ditching it is the way to go
19:23:56 <wumpus> I think abandontransaction is superior *if* it can replace all uses
19:24:00 <achow101> unless people used it for anything other than trying to RBF transactions
19:24:01 <wumpus> as it's more granular
19:24:13 <wumpus> if you don't need a sledgehammer you shouldn't use one
19:24:40 <wumpus> with abandontransaction you can remove any conflicted or non-confirmed transaction?
19:24:57 <wumpus> I don't think it's useful for transactions that are already in a block
19:25:02 <achow101> wumpus: so long as they are not confirmed and not in the mempool, I believe so
19:25:11 <wumpus> ok, right, makes sense
19:25:11 <sipa> abandontransaction only works for things that aren't in the mempool
19:25:14 <achow101> well they remain in history
19:25:14 <jeremyrubin> Shouldn't we deprecate and then remove something like this?
19:25:23 <wumpus> yes, well with zapwalettx you need to nuke the mempool too
19:25:25 <jeremyrubin> Is there any reason to remove all at once?
19:25:29 <achow101> but we also have removeprunedfunds which actually removes them from the wallet I think
19:25:48 <wumpus> jeremyrubin: it's not a RPC
19:26:06 <wumpus> yet
19:26:44 <achow101> to go the full abandontransaction route, we might need to add an rpc to clear the mempool, or at least evict a particular transaction from it
19:26:47 <wumpus> it's not an option someone would normally use except for recoery so there's no need to go through a deprecation cycle
19:26:48 <achow101> but that might not be desirable
19:27:05 <sipa> all of these things are recovery sledgehammers
19:27:11 <sipa> some just smaller than others
19:27:12 <sdaftuar> it strikes me as dangerous to encourage people to manually remove a tx from the mempool so that abandontransaction could be called on it
19:27:22 <achow101> sdaftuar: me too
19:27:25 <sipa> but anything that requires evicting things from the mempool shouldn't be needed on a regular basis
19:27:28 <sipa> sdaftuar: exactly
19:27:35 <wumpus> well if it's less dangerous to remove *all* transactions from the wallet?
19:27:40 <jeremyrubin> wumpus: i just don't want to give anyone reason to not upgrade, but it's probably fine in this case
19:27:43 <wumpus> that's what zapwallettx does
19:28:12 <achow101> also, RBF is on by default anyways, so none of these things should matter today
19:28:34 <wumpus> in any case my initial proposal was to move it to the wallet tool
19:28:47 <wumpus> which is intended for maintenance and recovery like this
19:28:50 <sdaftuar> wumpus: that sounds very reasonable
19:28:56 <sipa> yeah, it may be that the only use for zapwallettx is for completely corrupted scenarios, where you should be using savagewallet instead...
19:29:05 <wumpus> only if *no one* needs it, ever, we can just remove it
19:29:10 <sdaftuar> l
19:29:16 <achow101> wumpus: the main concern I have about that is zapwallettxes requires a rescan afterwards
19:29:16 <sipa> sdaftuar: i know ;)
19:29:28 <achow101> and the wallettol isn't going to do that
19:29:38 <wumpus> do it on next start ?
19:29:47 <wumpus> set the current block of the wallet to 0
19:29:47 <sdaftuar> jeremyrubin: salvagewallet
19:30:01 <jeremyrubin> fair.
19:30:14 <jnewbery> achow101: can't the wallet tool reset the wallet's best block to force a rescan?
19:30:26 <wumpus> right
19:30:28 <achow101> sure
19:30:29 <wumpus> it should
19:30:40 <sipa> it doesn't already?
19:30:40 <wumpus> as that information is unknown from there on
19:30:45 <achow101> startup rescan is always unfun though
19:30:55 <wumpus> zapwallettx rescan is not unfun?
19:30:57 <sipa> yes, just making the rescan automatic doesn't mean it goes away
19:31:00 <wumpus> it's the same IIRC
19:31:42 <achow101> I seem to remember that -rescan on qt stuck you at the splashscreen until it finished
19:31:42 <wumpus> I mean the current zapwallettx already forces a rescan at startup rght?
19:31:56 <wumpus> so this would not make it worse
19:32:01 <wumpus> it's for rare recovery operations
19:32:03 <wumpus> not for fun
19:32:17 <achow101> right
19:32:52 <jeremyrubin> wumpus: maybe it should have had a less fun name
19:32:53 <sipa> right
19:32:55 <wumpus> it sounds too much fun
19:32:59 <wumpus> jeremyrubin: exactly!
19:33:07 <sipa> jeremyrubin: fun draw transaction?
19:33:21 <sdaftuar> sipa: that confused me for so long
19:33:23 * jeremyrubin pew pew tx go bye
19:33:46 <sipa> also gcc -fun roll loops
19:33:48 <achow101> i'm still not convinved that zapwallettxes is actually useful though
19:34:01 <wumpus> abandontransaction is more fun in that regard, you could make an UI that allows zapping transactions one by one in a space invaders game :')
19:34:23 <achow101> We have CWallet::ZapSelectTx :)
19:34:29 <achow101> for removeprunedfunds
19:34:30 <wumpus> achow101: me netiher, but how to we find out
19:35:22 <jeremyrubin> Are there other topics?
19:35:38 <wumpus> like the biggest risk for these kind of things is that it's documented on a wiki somewhere and people try it as a random sledgehammer to fix wallet issues
19:35:41 <wumpus> no, I don't think so
19:35:53 <jnewbery> I was going to propose a time for the p2p meeting
19:36:02 <achow101> wumpus: either way whatever is documented won't work when we remove the startup option anyways
19:36:10 <wumpus> #topic P2P meeting (jnewbery)
19:36:18 <jnewbery> Thanks wumpus
19:36:18 <wumpus> achow101: right!
19:36:44 <jnewbery> I suggest 17:00 UTC on alternate Tuesdays, starting next week (Aug 11)
19:37:12 <wumpus> sgtm
19:37:30 <moneyball> yay p2p meeting
19:37:36 <wumpus> so it's two hours earlier than this meeting
19:37:52 <jnewbery> that's 2 hours before now (10am west coast, 1pm east coast, 6pm UK, 7pm most of europe)
19:38:15 <hebasto> Good for Eastern Europe
19:38:22 <sipa> 3 am for aj?
19:38:29 <sdaftuar> :(
19:38:31 <jnewbery> sorry aj :(
19:38:42 <wumpus> this reminds me we need to document all the meetings on https://bitcoincore.org/en/meetings/ probably
19:39:05 <harding> wumpus: I'll work on updating that page.
19:39:12 <wumpus> harding: thank you!
19:39:18 <jnewbery> that +- an hour or two is the only time that spans west coast US to eastern europe
19:39:32 <sdaftuar> i would try to make that time, but if there's a better time that would get aj too i think it's worth trying to make it work for him
19:39:50 <sipa> i'm ok with up to 2 hours earlier than what is suggested
19:39:52 <aj> 5am that's not a saturday is vaguely plausible, 3am isn't
19:39:57 <sdaftuar> aj!
19:40:15 <sipa> aj: oh wow, a morning person
19:40:18 <achow101> aj: 3am is just a late night
19:40:33 <wumpus> I'm also fine with earlier (but that;s obvious for Europe)
19:40:34 <jnewbery> 5am would be 19:00 UTC (same time as this meeting)
19:41:10 <aj> achow101: it's sleeping all day the next day which gets old
19:41:16 <jnewbery> that'd be 9pm central europe I think, and 10pm for eastern
19:41:42 <sipa> hebasto: up to what time is acceptable to you?
19:41:54 <hebasto> Any
19:41:57 <sipa> as you seem to be on the other end of the spectrum
19:42:17 <aj> 1am/1500UTC might be doable, not sure
19:42:27 <hebasto> 19:00 utc is ok
19:42:41 <jnewbery> aj: is 5am really ok for you?
19:43:17 <aj> jnewbery: as long as it's not on saturday (like the wallet meeting)
19:43:17 <jnewbery> 1500 UTC is 8am for west coast, which might not suit some people (sipa?)
19:43:51 <sipa> i can do 8 am
19:44:19 <jnewbery> great. Thanks everyone for being flexible
19:44:47 <jnewbery> so it sounds like there are two options: 1500 UTC or 1900 UTC
19:45:11 <jnewbery> vote now
19:45:22 <sipa> and they voted so hard that the country exploded
19:45:22 <wumpus> both fine with me
19:45:27 <sdaftuar> i'm indifferent
19:45:39 <sipa> prefer 1900 UTC, but both are ok
19:45:51 <dongcarl> *jeopardy thinking noises*
19:46:02 <hebasto> If 1500 utc suits for aj then prefer it
19:46:03 <jonatack> 1500 UTC :)
19:46:13 <jonatack> got out of bed just to vote
19:46:26 <wumpus> :D
19:46:38 <sipa> it may be advantageous to pick a time that's intentionally different from this meeting
19:46:52 <wumpus> sipa: yes
19:47:12 <jnewbery> aj: ?
19:47:29 <aj> 1500 utc tuesday ? fine by me
19:48:03 <jnewbery> ok, let's set it for 1500 utc on Tuesday Aug 11
19:48:11 <instagibbs> is this every other week or?
19:48:26 <wumpus> yes
19:48:35 <jnewbery> if anyone isn't at this meeting and wants to complain, message me and we can reconsider
19:48:38 <sipa> jnewbery: every week or every 2 week?
19:48:49 <jnewbery> but for now, it's 1500 UTC every 2 weeks
19:48:51 <jeremyrubin> sipa: maybe just complain one time
19:48:52 <jnewbery> starting Aug 11
19:48:58 <aj> 1h, rigt?
19:49:08 <jnewbery> aj: maximum 1 hour
19:49:56 <jnewbery> but less if there's nothing to talk about
19:50:08 <instagibbs> aj is going to get his money's worth
19:50:27 <jnewbery> thanks everyone!
19:50:30 <aj> \o/
19:50:32 <sipa> can we start the meeting at 1600 UTC and run it backwards?
19:50:48 <wumpus> hehe
19:50:50 <hebasto> how to get know topics in advance?
19:51:04 <cfields> sipa: isn't that how it works below the equator?
19:51:07 <sipa> ooh, google calendar supports UTC now
19:51:10 <cfields> everything's backwards down there.
19:51:12 <sipa> well, GMT
19:51:20 <wumpus> sipa: no more Reykjavik?
19:51:42 <sipa> oh no, it's just showing "Greenwich Mean Time (Iceland)"
19:51:47 <sipa> well, it works
19:52:03 <wumpus> yes, that works
19:52:53 <wumpus> #endmeeting