19:01:36 <wumpus> #startmeeting
19:01:36 <lightningbot> Meeting started Thu Mar 28 19:01:36 2019 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:01:36 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:01:45 <jnewbery> hello!
19:01:48 <midnightmagic> hello!
19:02:04 <moneyball> hi
19:02:09 <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:02:14 <cfields> hi
19:02:17 <jonasschnelli> hi
19:02:21 <sipa> wumpus: agree
19:02:24 <achow101> hi\
19:02:26 <wumpus> we should probably tag rc
19:02:29 <wumpus> rc3
19:02:29 <moneyball> we have 1 proposed topic! topic proposed by gmaxwell: Bech32 support shipped first in Bitcoin Core in Feb 2018, more than a year ago. We should consider making an announcement that Bitcoin Core intends to change the default addresstype from p2sh-segwit to bech32 in 0.19 or 0.20.
19:02:36 <wumpus> moneyball: thanks!
19:02:41 <instagibbs> oi
19:03:45 <wumpus> any other last-minute topic proposals?
19:03:53 <phantomcircuit> hi
19:04:32 <wumpus> #topic high priority for review
19:04:33 <wumpus> https://github.com/bitcoin/bitcoin/projects/8
19:05:26 <MarcoFalke> Fine with rc3 to test the win-sig
19:05:39 <MarcoFalke> Thogh, there needs to be an rc4 for the wallet-mempool bug
19:05:43 <wumpus> six things on there right now, anything to add/remove?
19:05:57 <wumpus> MarcoFalke: is there a PR for that?
19:06:07 <MarcoFalke> yeah the one from promag
19:06:17 <MarcoFalke> It should be in high-priority already ...
19:06:24 <wumpus> ehm, why isn't it labaled 0.18.0 anymore
19:06:42 <harding> Somebody said earlier that it was labeled 0.17.2
19:06:52 <wumpus> that's not good
19:06:58 <MarcoFalke> #15652
19:07:01 <gribble> https://github.com/bitcoin/bitcoin/issues/15652 | wallet: Update transactions with current mempool after load by promag · Pull Request #15652 · bitcoin/bitcoin · GitHub
19:07:08 <MarcoFalke> The bug is labeled 0.18.0
19:07:18 <MarcoFalke> But it needs to be fixed in 17 as well
19:07:26 <wumpus> please keep things labeled 0.18.0 for the release now, otherwise it's confusing
19:07:34 <MarcoFalke> Ok
19:07:42 <wumpus> I don't think 17.2 is planned any time soon
19:08:09 <wumpus> but fine let's hold up the RC for that
19:09:09 <MarcoFalke> wumpus: It will take another day or so to get reviewed
19:09:15 <MarcoFalke> Maybe until monday
19:09:23 <wumpus> that's ok
19:09:32 <MarcoFalke> The windows sigs need testing, though
19:09:39 <wumpus> if it's urgent enough to hold upthe relesaer, it should hold up the release
19:10:08 <cfields> I could create and sign a helloworld.exe for testing if everyone is ok with that.
19:10:21 <wumpus> cfields: sounds good to me
19:10:22 <achow101> to test the windows sig, just resign rc2?
19:10:37 <wumpus> I think doing a distributed rc build is overkill just to test a signature
19:10:51 <wumpus> at least *if* the rc is a dead end otherwise
19:11:04 <MarcoFalke> achow101: You mean without a gitian build?
19:11:20 <cfields> achow101: I'd rather not have different versions of an rc floating around.
19:11:24 <wumpus> if it would be a possible -final apart rom the signature test it'd have made sense
19:11:24 <MarcoFalke> gitian build with sig wouldn't work for rc2, if I understand correctly
19:12:02 <cfields> MarcoFalke: yeah, it'd have to be stitched together manually.
19:12:13 <wumpus> I had forgotten about #15652 because it was moved off the milestone
19:12:16 <gribble> https://github.com/bitcoin/bitcoin/issues/15652 | wallet: Update transactions with current mempool after load by promag · Pull Request #15652 · bitcoin/bitcoin · GitHub
19:12:29 <achow101> oh right, gitian build wouldn't work
19:12:52 <cfields> helloworld.exe is trivial. I'll just do that.
19:12:58 <wumpus> thank you
19:13:06 <MarcoFalke> ok, sounds good to me
19:13:09 <achow101> ack
19:13:25 <MarcoFalke> So we have two pulls to merge for rc3
19:13:32 <MarcoFalke> And one issue to discuss: #15665
19:13:34 <gribble> https://github.com/bitcoin/bitcoin/issues/15665 | 0.18.0 rc2 CPU spike in thread bitcoin-opencon · Issue #15665 · bitcoin/bitcoin · GitHub
19:13:49 <MarcoFalke> Some while(true) loop again?
19:14:20 <sipa> that sounds related to some of the changes we made
19:14:20 <cfields> the peer selection was just reworked a bunch, no?
19:14:21 <wumpus> two pulls?
19:14:23 <sipa> sigh
19:14:36 <sipa> i'll have a look at that
19:14:41 <MarcoFalke> wumpus: https://github.com/bitcoin/bitcoin/milestone/35
19:14:43 <wumpus> #topic CPU spike in thread
19:14:59 <MarcoFalke> > htop is telling me bitcoin-opencon is responsible. Peers are neither added or dropped coinciding with the CPU spike
19:15:04 <wumpus> sorry, haven't been paying much attention, my personal life is hell right no
19:15:12 <sipa> don't think there's much to discuss; just a report of a regression that sounds like it may be caused by changes in 0.18
19:15:21 <cfields> sipa: out of curiosity, why not push the selection algorithm into addrman? That'd make it much easier to test, no?
19:15:22 <MarcoFalke> wumpus: Sorry to hear that
19:15:53 <sdaftuar> sipa: are you thinking of the addrman tried collision bugfix PR?
19:16:03 <sipa> sdaftuar: possibly
19:16:04 <cfields> wumpus: Please let us know if there's anything we can do to help.
19:16:05 <sdaftuar> i can take a look as well
19:17:14 <wumpus> cfields: thanks!
19:18:43 <wumpus> if it's a regression for 0.18 then yes, it makes sense to try to fix it before the release of 0.18.0
19:19:19 <wumpus> if not, it's still good to fix it but no need to block rcs
19:19:50 <wumpus> #topic bech32 as default address type in 0.19 or 0.20 (gmaxwell)
19:20:09 <gmaxwell> Hi
19:20:25 <gmaxwell> There is now an issue that encapsulates a lot of the discussion.
19:20:36 <achow101> what about making the address type part of the wallet and not a startup option?
19:20:56 <moneyball> #15560
19:20:57 <gribble> https://github.com/bitcoin/bitcoin/issues/15560 | When to make bech32 the default -addresstype? · Issue #15560 · bitcoin/bitcoin · GitHub
19:20:59 <wumpus> which issue?
19:21:02 <wumpus> okay
19:21:18 <moneyball> Optech is doing a number of things to help here, as outlined in that PR
19:21:21 <gmaxwell> achow101: we should be really cautious about incorrectly giving the impression that you have to decide wallet wide, (like electrum does)...
19:22:32 <moneyball> I agree with the intention of the PR, and if we collect enough data before v0.19 is cut, we could potentially demonstrate that a sufficient portion of the ecosystem supports bech32 sends that it would be pretty uncontroversial to do.
19:22:38 <gmaxwell> In any case, I think we obviously want to make bc1x addresses the default at some point.
19:22:54 <gmaxwell> I think it would be helpful to the industry to announce in advance when we're doing to do that.
19:23:15 <gmaxwell> in related news, gemini is now defaulting to handing now bc1x addresses as new addresses.
19:23:27 <moneyball> and BitGo announced yesterday too
19:23:46 <moneyball> We might have data in say, 2-3 months, which would help the Core project to determine whether to announce it will be default in v0.19 or v0.20. Are folks ok waiting for that?
19:24:03 <gmaxwell> which I believe is the first (or at least one of the first) major services doing that... and makes me feel much more comfortable that 0.19 would be a good target (instead of 0.20)
19:25:02 <cfields> How many known stragglers are there?
19:25:03 <achow101> gmaxwell: why would it not be wallet wide? (maybe I'm misunderstanding you)
19:25:13 <gmaxwell> Data is good but also we wouldn't want to be circular.  The languishing with no schedule to change the default has been contributing to lack of support.
19:25:26 <gmaxwell> https://en.bitcoin.it/wiki/Bech32_adoption
19:25:36 <sipa> well we mostly care about ability to send to bech32
19:25:39 <gmaxwell> (I'm sure thats not completely current)
19:25:56 <gmaxwell> Things like ledger's wallet cannot.
19:26:11 <moneyball> data also here https://whensegwit.com
19:26:50 <gmaxwell> I'm concerned that we're erroring a little too strongly towards total compatiblity, which is causing industry participants to make an economically rational decision to ignore updating their bitcoin support in favor of supporting more altcoins.
19:27:04 <gmaxwell> (I can privately discuss some parties that have told me this outright)
19:27:25 <gmaxwell> sipa: yes, thats the only thing to actually care about.
19:27:41 <sipa> we wouldn't move to bech32-only in any case, so the question isn't nearly as strong as for electrum (which afaik needs either fully bech32 or not at all)
19:27:47 <gmaxwell> achow101: in electrum when you make a segwit wallet it is essentially bc1x only.
19:28:06 <gmaxwell> achow101: we wouldn't want to create an impression that we work that way too.
19:28:35 <gmaxwell> The difference in making a default is that users will splat into invalid address messages sometimes and need to go hit a button to get a compatiblity address.
19:29:00 <wumpus> right, the only risk is that we'd switch to bech32 addresses by default while there's still wallets in common use that can't send to them, that would be kind of bad though as the UI allows for generating different address types, also not uncircumventable
19:29:20 <wumpus> but it needs to be documented well at least...
19:30:03 <gmaxwell> And I think we've reached a point in deployment now where most things that don't support it are going to continue to not support it, (and instead spend efforts adding more altcoins) unless there is a bit more of a push. But more probably is just making their shortcomings more visible by changing defaults.
19:30:12 <wumpus> in any case, planning this for 0.20 (potentially moved backward to 0.19) sounds fine to me
19:30:25 <gmaxwell> Regardless of that: at some point we want to change, for sure, and we should establish in advance when we're going to do it.
19:30:30 <wumpus> yes
19:30:33 <sipa> agreed
19:30:44 <sipa> the left column which is mostly green on https://en.bitcoin.it/wiki/Bech32_adoption is pretty encouraging
19:30:47 <gmaxwell> wumpus: sounds good to me. So right now we'll do it in .20 and potentially .19.
19:30:56 <wumpus> gmaxwell: exactly
19:31:45 <instagibbs> any way we could signal "deprecation" in the software for .19?
19:31:51 <instagibbs> i can't think of any, just wondering aloud
19:32:00 <wumpus> instagibbs: that's a good idea
19:32:01 <achow101> with descriptor wallets I'm not sure how we would support choosing different address types
19:32:08 <gmaxwell> instagibbs: really the default change is the deprecation.
19:32:09 <moneyball> gmaxwell: i do hope optech's 24 weeks of bech32 in our newsletter as well as our personal outreach to many services will have an impact on this in 2019. no guarantees but i think we might move the needle a bit.
19:32:15 <instagibbs> gmaxwell, yeah true :)
19:32:22 <achow101> since a descriptor is what we use as "the keypool" and descriptor specify the type
19:32:23 <wumpus> eh yes  what gmaxwell says
19:32:28 <wumpus> deprecation is for *removing* features
19:32:33 <wumpus> this is a default change
19:32:37 <wumpus> it just needs to be announced well
19:32:43 <sipa> achow101: you'd have a descriptor record per address type
19:32:58 <instagibbs> it's an imperfect analogy, announce during 0.18 release, switch for 0.19 fine by me
19:33:11 <gmaxwell> I was about to say we don't have any intent to remove getting compat addresses, but achow points out that they're actually hard to universally support in a descriptor only wallet... so thats another reason to make the switch sooner rather than later too.
19:33:32 <gmaxwell> instagibbs: we can announce now ish that we'll default to it in .20 and potentially also .19.
19:34:07 <moneyball> announcing now will allow Optech to amplify that announcement too
19:34:09 <achow101> sipa: that's a bit incompatible with things like sethdseed. and I don't think we would want to have 3 records that refer to the same seed
19:34:25 <sipa> achow101: "sethdseed" has no meaning in a descriptor wallet
19:35:00 <sipa> achow101: that's a discussion for another topic i think
19:35:07 <achow101> ok
19:35:07 <sipa> but i don't think there is much of a problem
19:35:19 <wumpus> please, don't announce dropping support for old-style addresses (at whatever point), I expect this to cause major upheaval and it's not relevant to this
19:35:22 <gmaxwell> (and to make it clear, I don't fault parties that have been allocating their time elsewhere, they need to make whatever is the best business decisions for them... but by the same token, we shouldn't wait forever to hit 0% disruption)
19:36:03 <moneyball> wumpus: to be clear, that is not Optech's plan! our best practices guidance is to continue supporting legacy addresses
19:36:19 <gmaxwell> Yeah, to be clear we have no plans to drop support for compatiblity addresses. I was only going to say that we even had no reason to ever consider that, but achow did give a reason why we might someday want to, at least in some contexts.
19:36:20 <wumpus> moneyball: good to know
19:36:44 <moneyball> this is a summary of our guidance https://github.com/bitcoin/bitcoin/issues/15560#issuecomment-471690972
19:37:16 <gmaxwell> (and by drop support, I mean not generating in some new wallet types, no one has ever suggested a reason to drop being able to send to.)
19:37:38 <wumpus> right, that would be like what electrum has already done
19:37:44 <gmaxwell> right.
19:38:30 <wumpus> any other prposed topics?
19:39:21 <kanzure> minor mailing list updates. warren is the sole person handling that at this point. also i noticed that like 1200 users were mass unsubscribed this morning, dunno why.
19:39:42 <gmaxwell> aside, I'm not seeing this cpu spike.
19:40:41 <gwillen> kanzure: any obvious pattern in the mass unsubscription? (All gmail users, all non-gmail users, all people with names starting with A?)
19:40:50 <wumpus> gmaxwell: haven't noticed it either, maybe it's something that happens if there's no results like a previous time
19:41:03 <gmaxwell> wumpus: or if your addrman is mostly empty.
19:41:08 <wumpus> right
19:41:18 <kanzure> gwillen: definitely a lot of yahoo
19:41:43 <wumpus> #topic mailing list issues
19:42:03 <kanzure> i've give my update
19:42:09 <kanzure> i'd like warren to start cc'ing me on communication with linuxfoundation
19:42:14 <wumpus> thanks!
19:42:14 <gmaxwell> I unsubbed recently of my own volition, not an example of some kind of automated screwup.
19:42:18 <kanzure> or if not me then someone else
19:42:28 <gmaxwell> single threading things through one person is not a good idea for sure.
19:43:21 <kanzure> s/give/given
19:43:27 <gmaxwell> I've always made a point of CCing other people (usually wumpus and sipa) anytime I communicated something 'for bitcoin core project', even dumb stuff like lame whining at people for idiotic tweets.  ... just so if I drop off the face of the earth someone has context.
19:43:42 <gmaxwell> (or BCCing)
19:43:44 <wumpus> yes, that makes sense
19:44:14 <gmaxwell> +1 on mailing list stuff being CC/BCC to kanzure, perhaps wumpus too if just to collect info.
19:44:23 <bitcoin-git> [13bitcoin] 15dongcarl opened pull request #15689: netaddress: Update CNetAddr for ORCHIDv2 (06master...062019-03-account-for-orchidv2) 02https://github.com/bitcoin/bitcoin/pull/15689
19:44:47 <wumpus> good, any other topics?
19:45:49 <wumpus> thanks everyone
19:45:51 <wumpus> #endmeeting