< bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/e3272ff2907c...19f812c57b42
< bitcoin-git> bitcoin/master fa5288c MarcoFalke: contrib: Fixup valgrind suppressions file
< bitcoin-git> bitcoin/master 19f812c fanquake: Merge #19669: contrib: Fixup valgrind suppressions file
< bitcoin-git> [bitcoin] fanquake merged pull request #19669: contrib: Fixup valgrind suppressions file (master...2008-valSupp) https://github.com/bitcoin/bitcoin/pull/19669
< kallewoof> Should btcdeb be moved into the bitcoin github repo?
< luke-jr> kallewoof: we're trying to move things out, not in.. why? :p
< kallewoof> luke-jr: oh, okay. i thought there was talk about moving btcdeb into the bitcoin org at one point. feels like that might encourage contributors and would make it easier to provide binaries too
< luke-jr> kallewoof: maybe it would make sense to move it to the bitcoin-core org as a new repo, but we're also trying to keep stuff off the bitcoin org now IIRC
< kallewoof> okay
< bitcoin-git> [bitcoin] Crypt-iQ opened pull request #19672: build: make clean removes .gcda and .gcno files from fuzz directory (master...fuzz_cov_cleanup_0806) https://github.com/bitcoin/bitcoin/pull/19672
< jeremyrubin> Question Of The Day: empty scriptpubkeys are valid but not standard, correct? Is an empty p2sh script also valid? Can I satisfy it with OP_1 {}?
< sipa> yes, yes (as far as i remember)
< jeremyrubin> This is also true in segwit v0 and v1?
< sipa> i believe so
< jeremyrubin> TIL
< sipa> did you know that a zero-of-zero checkmultisig is valid?
< jeremyrubin> that I think I did know, and makes more sense?
< jeremyrubin> what about a 0 of 2 multisig?
< bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/19f812c57b42...82127d27c900
< bitcoin-git> bitcoin/master 70452a0 fanquake: build: set minimum required Boost to 1.58
< bitcoin-git> bitcoin/master 82127d2 fanquake: Merge #19667: build: set minimum required Boost to 1.58.0
< bitcoin-git> [bitcoin] fanquake merged pull request #19667: build: set minimum required Boost to 1.58.0 (master...boost_1_58_0) https://github.com/bitcoin/bitcoin/pull/19667
< wumpus> kallewoof: sgtm to move it to bitcoin-core org, but not to bitcoin (that's really only for legacy repos)
< bitcoin-git> [bitcoin] troygiorshev opened pull request #19673: Move cs_vSend into SocketSendData and resolve RecordBytesSent lock inconsistency (master...2020-08-socketsenddata) https://github.com/bitcoin/bitcoin/pull/19673
< sdaftuar> MarcoFalke: around? wondering if you have any advice on the CI failures in #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
< sdaftuar> aside from the CI failures, i think that PR is ready
< sdaftuar> (ie i don't think the ci failures are my fault! :) )
< bitcoin-git> [bitcoin] theStack opened pull request #19674: refactor: test: use throwaway _ variable for unused loop counters (master...20200804-refactor-test-use-underscore-variable) https://github.com/bitcoin/bitcoin/pull/19674
< dongcarl> Did meeting time change?
< wumpus> #startmeeting
< lightningbot> Meeting started Thu Aug 6 19:01:05 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.
< wumpus> I don't think so!
< kanzure> hi
< hebasto> hi
< sipsorcery> hi
< pinheadmz> hi
< meshcollider> 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
< dongcarl> :)
< wumpus> amiti fjahr jeremyrubin lightlike emilengler jonatack hebasto jb55 elichai2
< achow101> hi
< jb55> hi
< sipa> dongcarl: the meeting timestamp increases by around 604800 seconds per meeting
< wumpus> two pre-proposed meeting topics for today
< ariard> hi
< 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)
< jeremyrubin> hi
< gribble> https://github.com/bitcoin/bitcoin/issues/19629 | Pass mempool pointer to chainstate constructor by MarcoFalke · Pull Request #19629 · bitcoin/bitcoin · GitHub
< wumpus> (achow101) what to do about zapwallettxes
< dongcarl> sipa: rings true!
< wumpus> the first is mergeable with the normal high prio for review topic
< ariard> dongcarl: don't trust NTP
< wumpus> any other topics?
< wumpus> sipa: yup, exactly
< wumpus> meetings are scheulded 0.6048 megaseconds apart
< wumpus> #topic High priority for review
< wumpus> MarcoFalke's PR was already added
< jnewbery> hi
< wumpus> 10 blockers 1 bugfix 3 chasing concept ACK
< wumpus> anything to add / remove, or that is ready for merge?
< wumpus> Marco suggested removing PRs that have needed rebase for a while
< sdaftuar> oh, hi
< wumpus> I think this is mostly #18242
< jnewbery> I count three that need rebase: #18242 #19055 #11082
< 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
< 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
< gribble> https://github.com/bitcoin/bitcoin/issues/19055 | Add MuHash3072 implementation by fjahr · Pull Request #19055 · bitcoin/bitcoin · GitHub
< wumpus> jnewbery: oh!
< 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
< jnewbery> (just going by the tags)
< sdaftuar> #19620 is not high priority, but i would like it to be (though really it's ready for merge, i think)
< 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
< sdaftuar> because once it's merged i'll be backporting
< wumpus> sdaftuar: will add
< sdaftuar> thank you!
< jnewbery> wumpus: just merge it. It has 5 ACKs :)
< wumpus> jnewbery: ok, after the meeting :)
< hebasto> is #11082 compatible with merged #15935 ?
< wumpus> jonasschnelli fjahr luke-jr anyone of you here?
< 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
< gribble> https://github.com/bitcoin/bitcoin/issues/15935 | Add /settings.json persistent settings storage by ryanofsky · Pull Request #15935 · bitcoin/bitcoin · GitHub
< achow101> hebasto: yes, they are compatible
< sipa> is there still a point?
< wumpus> please rebase your PR this week
< sipa> ah, i guess bitcoin_rw is for changing config options through UI etc, while settings.json is for other things like bans?
< wumpus> I'm not exactly sure what is the difference either
< wumpus> I guess one is for persisting the other is for changing it through RPC?
< hebasto> I thought they were two alternatives
< 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
< achow101> my understanding was that bitcoin_rw was to let users also change the options
< achow101> and settings.json is only for bitcoind/bitcoin-qt
< achow101> I always viewed it as bitcoin_rw.conf was to supersede bitcoin.conf
< sipa> ah yes _rw would be accessible by bitcoin-cli etc as well
< fjahr> wumpus: will do, just wanted to answer your question as well at the same time
< wumpus> this doesn't add two separate settings mechanisms I hope?
< jnewbery> achow101: I don't think it makes sense to have yet another config source. How many do we have now?
< wumpus> jnewbery: hehe right
< achow101> jnewbery: 3. bitcoin.conf, settings.json, and QSettings
< wumpus> bitcoin-qt is a maze of different config sources already
< achow101> settings.json and QSettings are supposed to be combined I think
< achow101> but not yet
< wumpus> it's really subtle in which order they need to be interpreted to not break any existing things
< sipa> and command line
< jnewbery> and command line, and overrides in the source
< wumpus> right
< sipa> well i think we need ryanofsky and luke-jr to discuss this properly
< jnewbery> After settings.json, QSettings should only be used for QT GUI configuration (eg window size/location)
< * jeremyrubin> maybe a setting to let you pick which settings you are using
< wumpus> I understand the long-term goal is to drop qsettings for everything but the datadir path
< wumpus> oh and that
< wumpus> but that doesn't overlap with bitcoin.conf so isn't an issue :)
< achow101> wumpus: I think datadir path would want to be in settings.json
< wumpus> achow101: that creates a chicken egg problem !
< sipa> we should go back to storing settings in wallet.dat
< * sipa> hides
< sdaftuar> sipa: i was going to add an environment variable for enabling such behavior
< 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
< achow101> wumpus: i suppose it does, but it unifies qt and bitcoind datadir paths
< wumpus> I won't pretent to understand it anymore, sorry
< achow101> well conf always overrides qt anyways
< achow101> I think
< sdaftuar> perhaps a good first contributor project would be to document this somewhere, eg on our wiki
< wumpus> heh, yes
< achow101> i'm not sure a first contributor would be able to figure out this mess
< sdaftuar> achow101: fair point!
< wumpus> I'm terrified by that code in bitcoin-qt
< wumpus> took me a lot of work to get it exactly right so be careful
< wumpus> we don't have any tests for it because that's hard for GUI stuff
< wumpus> and yes, conf overrides qt except the initial datadir
< sipa> another reason to aim to move things out of qsettings
< sipa> as it unifies testing across bitcoind and bitcoin-qtr
< wumpus> yes
< 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
< sipa> indeed
< wumpus> I'm okay with this being somewhere else than QSettings but I'm not sure where :)
< wumpus> #topic what to do about zapwallettxes (achow101)
< sipa> zap it
< jeremyrubin> PR #?
< wumpus> #19671
< gribble> https://github.com/bitcoin/bitcoin/issues/19671 | wallet: Remove -zapwallettxes by achow101 · Pull Request #19671 · bitcoin/bitcoin · GitHub
< achow101> I think it's obvious that the -zapwallettxes startup option needs to go
< wumpus> sipa: +1
< achow101> but there's a question of where to put it
< achow101> options are wallet tool, rpc, or ditch it entirely
< sipa> wallet tool
< sipa> ?
< wumpus> also #19653
< gribble> https://github.com/bitcoin/bitcoin/issues/19653 | wallet: Replace -zapwallettxes with zapwallettxes RPC by achow101 · Pull Request #19653 · bitcoin/bitcoin · GitHub
< achow101> Since we have abandontransaction, I think ditching it is the way to go
< wumpus> I think abandontransaction is superior *if* it can replace all uses
< achow101> unless people used it for anything other than trying to RBF transactions
< wumpus> as it's more granular
< wumpus> if you don't need a sledgehammer you shouldn't use one
< wumpus> with abandontransaction you can remove any conflicted or non-confirmed transaction?
< wumpus> I don't think it's useful for transactions that are already in a block
< achow101> wumpus: so long as they are not confirmed and not in the mempool, I believe so
< wumpus> ok, right, makes sense
< sipa> abandontransaction only works for things that aren't in the mempool
< achow101> well they remain in history
< jeremyrubin> Shouldn't we deprecate and then remove something like this?
< wumpus> yes, well with zapwalettx you need to nuke the mempool too
< jeremyrubin> Is there any reason to remove all at once?
< achow101> but we also have removeprunedfunds which actually removes them from the wallet I think
< wumpus> jeremyrubin: it's not a RPC
< wumpus> yet
< 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
< wumpus> it's not an option someone would normally use except for recoery so there's no need to go through a deprecation cycle
< achow101> but that might not be desirable
< sipa> all of these things are recovery sledgehammers
< sipa> some just smaller than others
< 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
< achow101> sdaftuar: me too
< sipa> but anything that requires evicting things from the mempool shouldn't be needed on a regular basis
< sipa> sdaftuar: exactly
< wumpus> well if it's less dangerous to remove *all* transactions from the wallet?
< jeremyrubin> wumpus: i just don't want to give anyone reason to not upgrade, but it's probably fine in this case
< wumpus> that's what zapwallettx does
< achow101> also, RBF is on by default anyways, so none of these things should matter today
< wumpus> in any case my initial proposal was to move it to the wallet tool
< wumpus> which is intended for maintenance and recovery like this
< sdaftuar> wumpus: that sounds very reasonable
< sipa> yeah, it may be that the only use for zapwallettx is for completely corrupted scenarios, where you should be using savagewallet instead...
< wumpus> only if *no one* needs it, ever, we can just remove it
< sdaftuar> l
< achow101> wumpus: the main concern I have about that is zapwallettxes requires a rescan afterwards
< sipa> sdaftuar: i know ;)
< achow101> and the wallettol isn't going to do that
< wumpus> do it on next start ?
< wumpus> set the current block of the wallet to 0
< sdaftuar> jeremyrubin: salvagewallet
< jeremyrubin> fair.
< jnewbery> achow101: can't the wallet tool reset the wallet's best block to force a rescan?
< wumpus> right
< achow101> sure
< wumpus> it should
< sipa> it doesn't already?
< wumpus> as that information is unknown from there on
< achow101> startup rescan is always unfun though
< wumpus> zapwallettx rescan is not unfun?
< sipa> yes, just making the rescan automatic doesn't mean it goes away
< wumpus> it's the same IIRC
< achow101> I seem to remember that -rescan on qt stuck you at the splashscreen until it finished
< wumpus> I mean the current zapwallettx already forces a rescan at startup rght?
< wumpus> so this would not make it worse
< wumpus> it's for rare recovery operations
< wumpus> not for fun
< achow101> right
< jeremyrubin> wumpus: maybe it should have had a less fun name
< sipa> right
< wumpus> it sounds too much fun
< wumpus> jeremyrubin: exactly!
< sipa> jeremyrubin: fun draw transaction?
< sdaftuar> sipa: that confused me for so long
< * jeremyrubin> pew pew tx go bye
< sipa> also gcc -fun roll loops
< achow101> i'm still not convinved that zapwallettxes is actually useful though
< 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 :')
< achow101> We have CWallet::ZapSelectTx :)
< achow101> for removeprunedfunds
< wumpus> achow101: me netiher, but how to we find out
< jeremyrubin> Are there other topics?
< 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
< wumpus> no, I don't think so
< jnewbery> I was going to propose a time for the p2p meeting
< achow101> wumpus: either way whatever is documented won't work when we remove the startup option anyways
< wumpus> #topic P2P meeting (jnewbery)
< jnewbery> Thanks wumpus
< wumpus> achow101: right!
< jnewbery> I suggest 17:00 UTC on alternate Tuesdays, starting next week (Aug 11)
< wumpus> sgtm
< moneyball> yay p2p meeting
< wumpus> so it's two hours earlier than this meeting
< jnewbery> that's 2 hours before now (10am west coast, 1pm east coast, 6pm UK, 7pm most of europe)
< hebasto> Good for Eastern Europe
< sipa> 3 am for aj?
< sdaftuar> :(
< jnewbery> sorry aj :(
< wumpus> this reminds me we need to document all the meetings on https://bitcoincore.org/en/meetings/ probably
< harding> wumpus: I'll work on updating that page.
< wumpus> harding: thank you!
< jnewbery> that +- an hour or two is the only time that spans west coast US to eastern europe
< 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
< sipa> i'm ok with up to 2 hours earlier than what is suggested
< aj> 5am that's not a saturday is vaguely plausible, 3am isn't
< sdaftuar> aj!
< sipa> aj: oh wow, a morning person
< achow101> aj: 3am is just a late night
< wumpus> I'm also fine with earlier (but that;s obvious for Europe)
< jnewbery> 5am would be 19:00 UTC (same time as this meeting)
< aj> achow101: it's sleeping all day the next day which gets old
< jnewbery> that'd be 9pm central europe I think, and 10pm for eastern
< sipa> hebasto: up to what time is acceptable to you?
< hebasto> Any
< sipa> as you seem to be on the other end of the spectrum
< aj> 1am/1500UTC might be doable, not sure
< hebasto> 19:00 utc is ok
< jnewbery> aj: is 5am really ok for you?
< aj> jnewbery: as long as it's not on saturday (like the wallet meeting)
< jnewbery> 1500 UTC is 8am for west coast, which might not suit some people (sipa?)
< sipa> i can do 8 am
< jnewbery> great. Thanks everyone for being flexible
< jnewbery> so it sounds like there are two options: 1500 UTC or 1900 UTC
< jnewbery> vote now
< sipa> and they voted so hard that the country exploded
< wumpus> both fine with me
< sdaftuar> i'm indifferent
< sipa> prefer 1900 UTC, but both are ok
< dongcarl> *jeopardy thinking noises*
< hebasto> If 1500 utc suits for aj then prefer it
< jonatack> 1500 UTC :)
< jonatack> got out of bed just to vote
< wumpus> :D
< sipa> it may be advantageous to pick a time that's intentionally different from this meeting
< wumpus> sipa: yes
< jnewbery> aj: ?
< aj> 1500 utc tuesday ? fine by me
< jnewbery> ok, let's set it for 1500 utc on Tuesday Aug 11
< instagibbs> is this every other week or?
< wumpus> yes
< jnewbery> if anyone isn't at this meeting and wants to complain, message me and we can reconsider
< sipa> jnewbery: every week or every 2 week?
< jnewbery> but for now, it's 1500 UTC every 2 weeks
< jeremyrubin> sipa: maybe just complain one time
< jnewbery> starting Aug 11
< aj> 1h, rigt?
< jnewbery> aj: maximum 1 hour
< jnewbery> but less if there's nothing to talk about
< instagibbs> aj is going to get his money's worth
< jnewbery> thanks everyone!
< aj> \o/
< sipa> can we start the meeting at 1600 UTC and run it backwards?
< wumpus> hehe
< hebasto> how to get know topics in advance?
< cfields> sipa: isn't that how it works below the equator?
< sipa> ooh, google calendar supports UTC now
< cfields> everything's backwards down there.
< sipa> well, GMT
< wumpus> sipa: no more Reykjavik?
< sipa> oh no, it's just showing "Greenwich Mean Time (Iceland)"
< sipa> well, it works
< wumpus> yes, that works
< wumpus> #endmeeting
< lightningbot> Meeting ended Thu Aug 6 19:52:53 2020 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
< jnewbery> I'll make a gist with meeting time and suggested topics and post a link here
< sdaftuar> jnewbery: would be great to talk about people's sense of how we should prioritize all the PRs that are open right now
< jnewbery> sdaftuar: right. That's the first topic. Everyone gets to share what they're working on and what their prioirities are.
< sdaftuar> my hope is that people with opinions will make a case for particular PRs/areas of the code getting broader focus!
< sdaftuar> not sure i'll have any strong opinions, as i try to wrap my head around all the open PRs, but i'd be most interested in contributing to areas that several other people have agreed would be helpful for all of us to focus on
< sdaftuar> s/all/many/
< jnewbery> I have opinions!
< wumpus> no idea if I'm getting this right but google calender with all meetings (this one, IRC, P2P and PR review): https://calendar.google.com/calendar?cid=MTFwcXZkZ3BkOTlubGliZjliYTg2MXZ1OHNAZ3JvdXAuY2FsZW5kYXIuZ29vZ2xlLmNvbQ
< sdaftuar> wumpus: looks good to me
< jnewbery> wumpus: yes, that's correct
< wumpus> awesome!
< jnewbery> gist here: https://gist.github.com/jnewbery/dfaf34706f93a0608bb24869f13abcbf . Please suggest topics or leave any other feedback. Looking forward to it!
< wumpus> heh, either we need a #proposedmeetingtopi c for the different meetings or people need to specify what meeting it's for when they use it
< achow101> for the wallet meeting, we use #proposedwalletmeetingtopic
< wumpus> hah
< achow101> Oh, now I remember why I think zapwallettxes doesn't work with the wallet tool: the keep metadata option
< achow101> in order for that to work, the rescan needs to happen while we temporarily store the now-removed txs
< wumpus> now that payment requests aren't a thing anymore, is transaction metadata much of a thing?
< achow101> labels?
< wumpus> there's label<->address mapping but that's not per transaction
< wumpus> you could just keep all of them
< achow101> CWalletTx's metadata is kind of opaque and hard to figure out
< achow101> there is a "comment"
< achow101> and some old metadata related to accounts
< achow101> also time related stuff
< bitcoin-git> [bitcoin] Warchant opened pull request #19675: Run clang-tidy -*,performance-* (master...master) https://github.com/bitcoin/bitcoin/pull/19675
< bitcoin-git> [bitcoin] fanquake pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/82127d27c900...6d8543504d8c
< bitcoin-git> bitcoin/master 7989901 Suhas Daftuar: Add txids with non-standard inputs to reject filter
< bitcoin-git> bitcoin/master 9f88ded Gregory Sanders: test addition of unknown segwit spends to txid reject filter
< bitcoin-git> bitcoin/master 6d85435 fanquake: Merge #19620: Add txids with non-standard inputs to reject filter
< bitcoin-git> [bitcoin] fanquake merged pull request #19620: Add txids with non-standard inputs to reject filter (master...2020-07-reject-unknown-wit) https://github.com/bitcoin/bitcoin/pull/19620