19:01:36 #startmeeting 19:01:36 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 Useful Commands: #action #agreed #help #info #idea #link #topic. 19:01:45 hello! 19:01:48 hello! 19:02:04 hi 19:02:09 #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 hi 19:02:17 hi 19:02:21 wumpus: agree 19:02:24 hi\ 19:02:26 we should probably tag rc 19:02:29 rc3 19:02:29 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 moneyball: thanks! 19:02:41 oi 19:03:45 any other last-minute topic proposals? 19:03:53 hi 19:04:32 #topic high priority for review 19:04:33 https://github.com/bitcoin/bitcoin/projects/8 19:05:26 Fine with rc3 to test the win-sig 19:05:39 Thogh, there needs to be an rc4 for the wallet-mempool bug 19:05:43 six things on there right now, anything to add/remove? 19:05:57 MarcoFalke: is there a PR for that? 19:06:07 yeah the one from promag 19:06:17 It should be in high-priority already ... 19:06:24 ehm, why isn't it labaled 0.18.0 anymore 19:06:42 Somebody said earlier that it was labeled 0.17.2 19:06:52 that's not good 19:06:58 #15652 19:07:01 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 The bug is labeled 0.18.0 19:07:18 But it needs to be fixed in 17 as well 19:07:26 please keep things labeled 0.18.0 for the release now, otherwise it's confusing 19:07:34 Ok 19:07:42 I don't think 17.2 is planned any time soon 19:08:09 but fine let's hold up the RC for that 19:09:09 wumpus: It will take another day or so to get reviewed 19:09:15 Maybe until monday 19:09:23 that's ok 19:09:32 The windows sigs need testing, though 19:09:39 if it's urgent enough to hold upthe relesaer, it should hold up the release 19:10:08 I could create and sign a helloworld.exe for testing if everyone is ok with that. 19:10:21 cfields: sounds good to me 19:10:22 to test the windows sig, just resign rc2? 19:10:37 I think doing a distributed rc build is overkill just to test a signature 19:10:51 at least *if* the rc is a dead end otherwise 19:11:04 achow101: You mean without a gitian build? 19:11:20 achow101: I'd rather not have different versions of an rc floating around. 19:11:24 if it would be a possible -final apart rom the signature test it'd have made sense 19:11:24 gitian build with sig wouldn't work for rc2, if I understand correctly 19:12:02 MarcoFalke: yeah, it'd have to be stitched together manually. 19:12:13 I had forgotten about #15652 because it was moved off the milestone 19:12:16 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 oh right, gitian build wouldn't work 19:12:52 helloworld.exe is trivial. I'll just do that. 19:12:58 thank you 19:13:06 ok, sounds good to me 19:13:09 ack 19:13:25 So we have two pulls to merge for rc3 19:13:32 And one issue to discuss: #15665 19:13:34 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 Some while(true) loop again? 19:14:20 that sounds related to some of the changes we made 19:14:20 the peer selection was just reworked a bunch, no? 19:14:21 two pulls? 19:14:23 sigh 19:14:36 i'll have a look at that 19:14:41 wumpus: https://github.com/bitcoin/bitcoin/milestone/35 19:14:43 #topic CPU spike in thread 19:14:59 > htop is telling me bitcoin-opencon is responsible. Peers are neither added or dropped coinciding with the CPU spike 19:15:04 sorry, haven't been paying much attention, my personal life is hell right no 19:15:12 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 sipa: out of curiosity, why not push the selection algorithm into addrman? That'd make it much easier to test, no? 19:15:22 wumpus: Sorry to hear that 19:15:53 sipa: are you thinking of the addrman tried collision bugfix PR? 19:16:03 sdaftuar: possibly 19:16:04 wumpus: Please let us know if there's anything we can do to help. 19:16:05 i can take a look as well 19:17:14 cfields: thanks! 19:18:43 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 if not, it's still good to fix it but no need to block rcs 19:19:50 #topic bech32 as default address type in 0.19 or 0.20 (gmaxwell) 19:20:09 Hi 19:20:25 There is now an issue that encapsulates a lot of the discussion. 19:20:36 what about making the address type part of the wallet and not a startup option? 19:20:56 #15560 19:20:57 https://github.com/bitcoin/bitcoin/issues/15560 | When to make bech32 the default -addresstype? · Issue #15560 · bitcoin/bitcoin · GitHub 19:20:59 which issue? 19:21:02 okay 19:21:18 Optech is doing a number of things to help here, as outlined in that PR 19:21:21 achow101: we should be really cautious about incorrectly giving the impression that you have to decide wallet wide, (like electrum does)... 19:22:32 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 In any case, I think we obviously want to make bc1x addresses the default at some point. 19:22:54 I think it would be helpful to the industry to announce in advance when we're doing to do that. 19:23:15 in related news, gemini is now defaulting to handing now bc1x addresses as new addresses. 19:23:27 and BitGo announced yesterday too 19:23:46 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 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 How many known stragglers are there? 19:25:03 gmaxwell: why would it not be wallet wide? (maybe I'm misunderstanding you) 19:25:13 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 https://en.bitcoin.it/wiki/Bech32_adoption 19:25:36 well we mostly care about ability to send to bech32 19:25:39 (I'm sure thats not completely current) 19:25:56 Things like ledger's wallet cannot. 19:26:11 data also here https://whensegwit.com 19:26:50 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 (I can privately discuss some parties that have told me this outright) 19:27:25 sipa: yes, thats the only thing to actually care about. 19:27:41 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 achow101: in electrum when you make a segwit wallet it is essentially bc1x only. 19:28:06 achow101: we wouldn't want to create an impression that we work that way too. 19:28:35 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 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 but it needs to be documented well at least... 19:30:03 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 in any case, planning this for 0.20 (potentially moved backward to 0.19) sounds fine to me 19:30:25 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 yes 19:30:33 agreed 19:30:44 the left column which is mostly green on https://en.bitcoin.it/wiki/Bech32_adoption is pretty encouraging 19:30:47 wumpus: sounds good to me. So right now we'll do it in .20 and potentially .19. 19:30:56 gmaxwell: exactly 19:31:45 any way we could signal "deprecation" in the software for .19? 19:31:51 i can't think of any, just wondering aloud 19:32:00 instagibbs: that's a good idea 19:32:01 with descriptor wallets I'm not sure how we would support choosing different address types 19:32:08 instagibbs: really the default change is the deprecation. 19:32:09 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 gmaxwell, yeah true :) 19:32:22 since a descriptor is what we use as "the keypool" and descriptor specify the type 19:32:23 eh yes what gmaxwell says 19:32:28 deprecation is for *removing* features 19:32:33 this is a default change 19:32:37 it just needs to be announced well 19:32:43 achow101: you'd have a descriptor record per address type 19:32:58 it's an imperfect analogy, announce during 0.18 release, switch for 0.19 fine by me 19:33:11 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 instagibbs: we can announce now ish that we'll default to it in .20 and potentially also .19. 19:34:07 announcing now will allow Optech to amplify that announcement too 19:34:09 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 achow101: "sethdseed" has no meaning in a descriptor wallet 19:35:00 achow101: that's a discussion for another topic i think 19:35:07 ok 19:35:07 but i don't think there is much of a problem 19:35:19 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 (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 wumpus: to be clear, that is not Optech's plan! our best practices guidance is to continue supporting legacy addresses 19:36:19 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 moneyball: good to know 19:36:44 this is a summary of our guidance https://github.com/bitcoin/bitcoin/issues/15560#issuecomment-471690972 19:37:16 (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 right, that would be like what electrum has already done 19:37:44 right. 19:38:30 any other prposed topics? 19:39:21 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 aside, I'm not seeing this cpu spike. 19:40:41 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 gmaxwell: haven't noticed it either, maybe it's something that happens if there's no results like a previous time 19:41:03 wumpus: or if your addrman is mostly empty. 19:41:08 right 19:41:18 gwillen: definitely a lot of yahoo 19:41:43 #topic mailing list issues 19:42:03 i've give my update 19:42:09 i'd like warren to start cc'ing me on communication with linuxfoundation 19:42:14 thanks! 19:42:14 I unsubbed recently of my own volition, not an example of some kind of automated screwup. 19:42:18 or if not me then someone else 19:42:28 single threading things through one person is not a good idea for sure. 19:43:21 s/give/given 19:43:27 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 (or BCCing) 19:43:44 yes, that makes sense 19:44:14 +1 on mailing list stuff being CC/BCC to kanzure, perhaps wumpus too if just to collect info. 19:44:23 [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 good, any other topics? 19:45:49 thanks everyone 19:45:51 #endmeeting