19:00:41 #startmeeting 19:00:41 Meeting started Thu Sep 26 19:00:41 2019 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:00:41 Useful Commands: #action #agreed #help #info #idea #link #topic. 19:00:44 hi 19:00:51 #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 19:00:53 hi 19:00:58 hi 19:00:58 hi 19:01:04 hi 19:01:21 What is the status of 0.17.2 and 0.18.2? 19:01:24 with the 0.19 split-off coming up, I think we should use today's meeting to discuss and triage the still-open issues on the 0.19 milestone (https://github.com/bitcoin/bitcoin/milestone/37) 19:01:54 ack 19:03:01 I'll try to resist shiny object syndrome and review a bunch of 0.19 soon tm. 19:03:03 MarcoFalke: 0.17.2 is done, still have to upload executables, dunno about 0.18.2 19:03:29 provoostenator: welcome to my life 19:03:29 So 0.17.2rc2 is 0.17.2-final 19:03:49 MarcoFalke: eh wait, I mean rc2 19:03:59 heh 19:04:51 What is the status of #14289 ? 19:04:53 https://github.com/bitcoin/bitcoin/issues/14289 | Unbounded growth of scheduler queue · Issue #14289 · bitcoin/bitcoin · GitHub 19:04:54 #topic 0.19 open issues 19:05:17 Something has been addressed and I am not sure what still remains to be fixed 19:05:53 I don't know either 19:06:14 #16849 needs review 19:06:15 https://github.com/bitcoin/bitcoin/issues/16849 | Fix block index inconsistency in InvalidateBlock() by sdaftuar · Pull Request #16849 · bitcoin/bitcoin · GitHub 19:06:20 Then moving it to another milestone won't help. I'd say close it 19:06:44 i'm not aware of any current scheduler queue problems, though i think there are code improvements some have been discussing to ensure no new problems develop? not sure 19:06:50 I dont see whay #14289 is on 0.19 - it seems the issue isn't specific anyway? 19:06:52 https://github.com/bitcoin/bitcoin/issues/14289 | Unbounded growth of scheduler queue · Issue #14289 · bitcoin/bitcoin · GitHub 19:07:13 BlueMatt: MarcoFalke let's just remoe the milestone 19:07:36 re: #16849, i'm curious to get other opinions about what the best fix is 19:07:37 right, long-term I think #16323 "solves" the issue wholesale (and other locking/scheduling/queue concerns) 19:07:38 https://github.com/bitcoin/bitcoin/issues/16849 | Fix block index inconsistency in InvalidateBlock() by sdaftuar · Pull Request #16849 · bitcoin/bitcoin · GitHub 19:07:38 it's a long term improvement aim, not something that needs to be solved before a certain version 19:07:40 https://github.com/bitcoin/bitcoin/issues/16323 | Call ProcessNewBlock() asynchronously by TheBlueMatt · Pull Request #16323 · bitcoin/bitcoin · GitHub 19:07:40 The scheduler queue thing's worst symptom has been fixed a while ago 19:07:42 but its *definitely* not an 0.19 thing 19:07:44 I'd rather not do #16849 for 0.19. Seems to risky for a validation change that has effects only tests 19:07:46 https://github.com/bitcoin/bitcoin/issues/16849 | Fix block index inconsistency in InvalidateBlock() by sdaftuar · Pull Request #16849 · bitcoin/bitcoin · GitHub 19:08:36 MarcoFalke: only invalidateblock is affected, right? i think it's defensively written. however it may be an unnecessary fix altogether imo 19:08:37 I mean its lower-risk than it appears 19:08:53 the bug is essentially non-observable 19:08:56 adding extra crap to setBlockIndexCandidates just makes things slower, not broken 19:09:13 though of course it could have some other classes of bugs 19:09:32 agreed :) 19:09:57 not for 19, either, but invalidateblock is also broken in other ways - see #16856 19:09:58 https://github.com/bitcoin/bitcoin/issues/16856 | Do not allow descendants of BLOCK_FAILED_VALID blocks to be BLOCK_FAILED_VALID by TheBlueMatt · Pull Request #16856 · bitcoin/bitcoin · GitHub 19:09:59 anyway i mostly want people to chime in on whether we should even bother fixing the "bug" 19:10:29 #16713 is easier to review. I am going to merge that after one more ACK 19:10:31 https://github.com/bitcoin/bitcoin/issues/16713 | Ignore old versionbit activations to avoid unknown softforks warning by jnewbery · Pull Request #16713 · bitcoin/bitcoin · GitHub 19:11:20 MarcoFalke: concept ack 19:11:24 does that count? :P 19:11:30 what about #16072? 19:11:31 https://github.com/bitcoin/bitcoin/issues/16072 | sendtoaddress ignores conf_target (spending whole UTxO with subtractfeefromamount=true) · Issue #16072 · bitcoin/bitcoin · GitHub 19:11:51 it looks like we don't have tests for sendtoaddress with a conf_target at all, so can't be sure it works 19:11:53 ooooof 19:13:05 MarcoFalke: we defeinitely need to merge one of the versionbits warning fixes 19:13:42 jup, this is a bug 19:14:17 wumpus, I can dig into that sendtoaddress report later today if you'd like and see what i can find 19:14:37 instagibbs: thanks! 19:14:56 3 hour train ride should find some time... 19:15:36 what about #16418? 19:15:37 https://github.com/bitcoin/bitcoin/issues/16418 | Ensure we have sufficient transaction-relay peers · Issue #16418 · bitcoin/bitcoin · GitHub 19:17:26 it doesn't have an associated PR yet, so it's a bit late 19:17:38 It is mostly brainstorming 19:17:43 Not tied to a release 19:17:50 ok, remove or bump the milestone? 19:17:58 but pointing to an actual (long-term) problem 19:18:03 remove 19:18:05 ? sdaftuar 19:18:18 yes, it's an actual problem 19:18:53 but we're triaging what has to be done for 0.19, not in general 19:19:06 removed the milestone for now, eel free to add a different one 19:19:13 then there's #16485 19:19:15 https://github.com/bitcoin/bitcoin/issues/16485 | bumpfee.TotalFee removed without replacement · Issue #16485 · bitcoin/bitcoin · GitHub 19:19:41 instagibbs has a fix, but it hasn't received any review 19:19:41 oh that does have a PR, #16727 19:19:43 https://github.com/bitcoin/bitcoin/issues/16727 | wallet: Explicit feerate for bumpfee by instagibbs · Pull Request #16727 · bitcoin/bitcoin · GitHub 19:19:56 ^ I'll give that a review 19:20:02 we should try to get that in 19:20:14 thanks, the original contributor ghosted, which is why it was a bit late 19:20:30 Initially I was hoping to get kallewoof's thing in first for an easier syntax, but that can wait 19:20:50 provoostenator, was more controversial than I'd hoped tbh 19:20:59 signet? 19:21:03 #11413 19:21:05 https://github.com/bitcoin/bitcoin/issues/11413 | [wallet] [rpc] sendtoaddress/sendmany: Add explicit feerate option by kallewoof · Pull Request #11413 · bitcoin/bitcoin · GitHub 19:21:17 the string args for sat/kB etc 19:21:23 ^ At this point it's better to punt that to 0.20 19:21:24 that's really a feature 19:21:54 orthogonal too, we can always augment 16727 19:21:58 later 19:22:07 Indeed 19:23:21 then there's #16950 (and fix PR #16952) 19:23:21 https://github.com/bitcoin/bitcoin/issues/16950 | gui: crash trying to access info of a removed transaction · Issue #16950 · bitcoin/bitcoin · GitHub 19:23:23 https://github.com/bitcoin/bitcoin/issues/16952 | gui: make sure to update the UI when deleting a transaction by jonasschnelli · Pull Request #16952 · bitcoin/bitcoin · GitHub 19:23:30 also a bug, not a *new* one but it's gotten a bunch of review already: #16507 19:23:32 https://github.com/bitcoin/bitcoin/issues/16507 | feefilter: Compute the absolute fee rather than stored rate by instagibbs · Pull Request #16507 · bitcoin/bitcoin · GitHub 19:23:47 looks like a simple change, but there's some questions if it solves the whole problem 19:24:19 I'd like to address promags point in 16952 19:24:22 So not ready yet but soon 19:24:23 let's keep discussion to what is already tagged with the milestone for now 19:24:35 apologies 19:24:53 instagibbs: would be nice to get it in, sure 19:25:01 jonasschnelli: ok! 19:26:04 then we have #16939, which is tagged 0.19, but fixes an issue (#15434) that is not tagged 0.19 19:26:05 https://github.com/bitcoin/bitcoin/issues/16939 | p2p: Delay querying DNS seeds if addrman is populated by ajtowns · Pull Request #16939 · bitcoin/bitcoin · GitHub 19:26:06 https://github.com/bitcoin/bitcoin/issues/15434 | Querying DNS seeds too frequently · Issue #15434 · bitcoin/bitcoin · GitHub 19:26:36 not a regression bugfix, right 19:26:44 Seems like a feature 19:26:47 it's mostly a "query DNS seeds to often" annoyance, not really a bug 19:26:52 yeah 19:27:22 removing it from the milestone 19:28:13 #16936 is only a test change and should be ready to go after the linter changes are removed from it 19:28:15 https://github.com/bitcoin/bitcoin/issues/16936 | qa: Fix service flag comparison check in rpc_net test by luke-jr · Pull Request #16936 · bitcoin/bitcoin · GitHub 19:29:09 #16817 is just a simple argument casing change so no worries it can go in 19:29:10 https://github.com/bitcoin/bitcoin/issues/16817 | rpc: Fix casing in getblockchaininfo to be inline with other fields by dangershony · Pull Request #16817 · bitcoin/bitcoin · GitHub 19:29:47 (but it's critical that it gets into 0.19, because otherwise there will be version incompatiblity) 19:30:37 next topic? 19:30:46 #16689 is a help only change, would be nice to have it in but not necessary 19:30:48 https://github.com/bitcoin/bitcoin/issues/16689 | rpc: add missing fields to wallet rpc help output by ariard · Pull Request #16689 · bitcoin/bitcoin · GitHub 19:30:53 I think that covered them all 19:30:59 sure, any other topics? 19:31:28 I don't think we need to do "high priority for review" 19:31:49 oh we had a topic from last time: proposed by instagibbs: what to do with change output creation with bech32-default Core wallets: https://github.com/bitcoin/bitcoin/issues/15560#issuecomment-531796601 19:32:08 #topic what to do with change output creation with bech32-default Core wallets 19:33:01 uhhh nothing new on that front :) 19:33:12 what would be different from setting -addresstype=bech32 today? 19:33:12 maybe there's someone interested in discussing it this week 19:33:20 last week, there weren't many people 19:34:24 achow101, the main change I was curious about was if someone specifies p2sh-wrapped for address, should we try to match bech32 change 19:34:37 that's historical behavior that my PR is changing 19:34:42 via https://github.com/bitcoin/bitcoin/pull/16884/commits/f069b9bf55936d3793406f2ab1af107a6e1a40c4 19:35:21 the mimicking behavior was for privacy so it's slightly less obvious which address is change 19:35:36 privacy + small discount 19:36:22 so the q is should someone asking for p2sh-wrapped be given that "discount and privacy", or should we just respect the choice 19:36:37 since everyone else will be running bech32 19:37:02 but not immediately 19:37:27 I would prefer to keep the match the outgoing address type behavior 19:37:27 and only bitcoin core changes the default here, not every other wallet 19:37:31 well if people are -1 on it I can remove it and fix tests 19:37:47 instagibbs: I think it makes sense to split it off from the default change itself 19:37:59 changing tests twice :P 19:38:13 I can remove it 19:38:41 ok! 19:38:54 unless I run into a reason I'd forgotten, then we can continue in-thread 19:38:56 thanks! 19:39:02 any other topics? 19:39:46 ok, please use the remaining 20 minutes to review PRs for 0.19 then :< 19:39:49 #endmeeting