19:00:23 #startmeeting 19:00:23 Meeting started Thu Apr 26 19:00:23 2018 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:00:23 Useful Commands: #action #agreed #help #info #idea #link #topic. 19:00:25 meeting? 19:00:26 hi 19:00:28 :wave: 19:00:30 meeting 19:00:30 #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101 meshcollider jnewbery maaku fanquake promag provoostenator 19:00:33 hi 19:00:38 hi 19:00:40 hi 19:00:42 hi 19:00:43 hi 19:00:45 hi 19:00:45 proposed topics? 19:01:33 #topic high priority for review 19:01:42 hi. 19:01:54 Would suggest #10757 but I'm seeing unicorns.. 19:01:58 #12979 #12560 #10757 19:01:59 https://github.com/bitcoin/bitcoin/issues/10757 | RPC: Introduce getblockstats to plot things by jtimon · Pull Request #10757 · bitcoin/bitcoin · GitHub 19:02:00 https://github.com/bitcoin/bitcoin/issues/12979 | Split validationinterface into paralell validation/mempool interfaces by TheBlueMatt · Pull Request #12979 · bitcoin/bitcoin · GitHub 19:02:03 https://github.com/bitcoin/bitcoin/issues/12560 | [wallet] Upgrade path for non-HD wallets to HD by achow101 · Pull Request #12560 · bitcoin/bitcoin · GitHub 19:02:06 are currently open and on there 19:02:09 https://github.com/bitcoin/bitcoin/issues/10757 | RPC: Introduce getblockstats to plot things by jtimon · Pull Request #10757 · bitcoin/bitcoin · GitHub 19:02:12 proposed topic: the necessity of "totalFee" as an argument for bumpfee 19:02:34 I mean we havent really been getting any review on the "high priority" list 19:02:39 so not sure the use of bringing it up every week 19:02:55 BlueMatt: if we don't bring it up it's even more pointless I guess 19:03:05 yeah we either nag or we give up -- i vote for the former 19:03:20 * sdaftuar nags self 19:03:21 I've nagged the last two weeks (sorry wasnt prepared today) but...no dice 19:03:22 BlueMatt: 10757's had review, and txindex made it in. yours is hard :( 19:03:23 but if it doens't help we can give up on it too, fine with me 19:03:36 Agree. Though "High Priority" is probably the wrong name for that list 19:04:13 jonasschnelli: any idea for a better name? 19:04:20 i wonder if the "everyone can get one of their PRs on the list" policy is very good 19:04:41 sipa: any idea for a better policy? 19:04:44 I have no better name 19:04:47 BlueMatt: and yours needs rebase again. :( worth tracking which non-high-pri PRs conflict with high-pri issues and avoid merging them? 19:04:58 hi 19:05:04 the subsection is "blockers" 19:05:08 ie "this is blocking my work" 19:05:09 I think the policy seems pretty fair regarding the lack of a steering commitee 19:05:12 which is correct for a few of those 19:05:16 BlueMatt: ah yes, that makes sense 19:05:23 aj: sounds like a lot of work 19:05:43 yes "blockers" might be a better name 19:05:49 jamesob: i have a script that approximates it; haven't been running it regularly, but there's no reason i couldn't 19:05:49 that's why they're high priority 19:05:52 aj: you can still review things with trivial conflicts.... 19:05:57 i started reviewing #12979 but had difficulty following 19:05:59 or supposed to be, anyhow 19:05:59 https://github.com/bitcoin/bitcoin/issues/12979 | Split validationinterface into paralell validation/mempool interfaces by TheBlueMatt · Pull Request #12979 · bitcoin/bitcoin · GitHub 19:06:15 aj: oh interesting 19:06:24 sipa: well it got split off of 11775, so its a pure refactor 19:06:32 all it is is moving things around, so on its face it looks useless and dumb 19:07:06 also, BlueMatt, do you think #11639 may not be closer to merge (as it seems like it may conflict with 12979?) 19:07:10 https://github.com/bitcoin/bitcoin/issues/11639 | Rewrite the interface between validation and net_processing wrt DoS by TheBlueMatt · Pull Request #11639 · bitcoin/bitcoin · GitHub 19:08:26 sipa: it is almost certainly closer to merge, but it is *not* blocking me so is not my "high-priority blocker" 19:08:35 whereas 12979 is blocking about 10 other things 19:08:40 ah, i see 19:08:57 however, our high-priority policy has historically been that you can nominate someone else' pr if its blocking you 19:09:06 so if thats blocking someone, they can nominate it 19:09:25 sure, you can nominate someone else's pr 19:11:24 also I don't think we have enough other meeting topics every week that not discussing the high priority for review would help 19:11:38 but I'm fine with dropping the topic if there's agreement to do that 19:11:57 i'd like to keep it - but if there's not much to say, not much needs to be said about it 19:11:57 well we keep coming back to needing *something* to make progress move when you get blocked on something 19:12:09 if not the high-priority list, what? 19:12:12 yes, if there's nothing to be said we can just move on 19:12:17 and the high-priority list seems to be pretty reliably not working 19:12:29 well one thing got merged from it... 19:12:32 BlueMatt, for your PRs or for all? 19:12:51 yes, but it only got review from like 2 people for several weeks where people were active and it sat on the list 19:12:59 instagibbs: all 19:13:00 so is that because it is on the list? 19:13:22 for all IMO; I'm at least partly to blame though - usually I just pick random PRs without checking the high prio list 19:13:23 no, I'm saying about 2 people bothered to review it for many weeks 19:13:28 which clearly indicates its not working 19:13:43 being on the list doesn't compel people to review 19:13:50 it's clear that things are on the list that have a hard time getting review 19:13:52 certainly I'm not great either, but we need something to get people to care about some blockers list 19:13:54 take it off, see if it gets less review #science 19:13:58 I think having the list is better than not - just a matter of remembering to use it 19:15:10 anyhow, if this topic is only about how ineffective the list is every week, I'm going to drop it 19:15:34 anyway, I'll shut up, instagibbs had a topic 19:15:57 #topic the necessity of "totalFee" as an argument for bumpfee (instagibbs) 19:17:29 * LukeJr pokes instagibbs 19:17:59 * sipa concludes: no necessity of "totalFee" as an argument for bumpfee ? 19:18:34 ohhi 19:18:35 sorry 19:18:43 yes, is it needed 19:18:46 what is this argument used for? 19:18:49 it's optional, no? 19:19:09 sdaftuar, I was hoping to upgrade rbf/cpfp in not too distant future, but it complicates logic to support 19:19:34 I could just not support any better RBF that uses it, but was wondering if it makes sense regardless 19:19:50 wumpus, you pay X BTC more in fees, total, rather than bump by feerate 19:20:01 not X more, X total, right? 19:20:07 yes 19:20:52 instagibbs: I suppose that is useful when all of the fee computation happens on the client side? 19:21:00 i dunno, i don't feel strongly about it, i think these user interface questions are hard to answer in the abstract 19:21:08 so if you have a proposal for some other interface, we should talk about that 19:21:12 instagibbs: error out if totalFee > old-fee + old-change? 19:21:20 (as the topic is necessity it's good to have some use cases?) 19:21:33 aj: or do it as CPFP possibly 19:21:35 aj, hm? 19:21:46 ah, interesting 19:21:49 I'm not sure total fee really makes sense when changing the size though 19:22:12 yeah i agree that seems like a confusing case at the least 19:22:17 agree 19:22:35 I redid everything to just use CreateTransaction, fwiw 19:22:52 so it will select more coins, which changes size 19:22:58 (if needed) 19:23:30 one issue we ran into with bumpfee was nailing down all the rquirements up-front. might be worth laying out what constraints we are trying to satisfy as part of the discussion, so we can ensure we're still meeting them all 19:23:49 instagibbs: considering total fee is optional, we need to work without it regardless; so how does keeping it simplify anything? 19:23:52 BIP125 constraints are the PITA I think 19:24:04 LukeJr, I want to get rid of it 19:24:08 or think about doing so 19:24:10 oh 19:24:44 ok, just wanted to hear any good use cases if they thought of them 19:24:55 i think if you're changing tx size that's a pretty good argument for dropping it 19:24:57 I suppose totalFee could be a kind of "if you calculated a higher fee, fail rather than bump; if lower, increase fee to match" 19:25:25 yeah, what lukejr said 19:25:29 or even just the former might be the useful part 19:25:30 If want total fee, I suppose I could just forbid any new coin selection, and fail out otherwise 19:25:49 backwards compatible without additional cruft 19:25:59 ok, end 19:26:31 oh I have a topic 19:26:32 #topic Remove safemode 19:26:44 #13090 #10563 19:26:45 https://github.com/bitcoin/bitcoin/issues/13090 | Remove Safe mode (achow101) by laanwj · Pull Request #13090 · bitcoin/bitcoin · GitHub 19:26:46 https://github.com/bitcoin/bitcoin/issues/10563 | Remove safe mode by achow101 · Pull Request #10563 · bitcoin/bitcoin · GitHub 19:27:11 this has been open for a long time, safemode was disabled since 0.16, should we complately remove it for 0.17? 19:27:15 sdaftuar, https://github.com/bitcoin/bitcoin/issues/12271 please contribute if this issue helps (ok now done) 19:27:52 I think safemode is a useful concept, but without anyone working to make it useful in practice (ie, detecting actual problem conditions), might as well drop it 19:28:13 it's disabled by default in 0.16 and I've heard no one complaining about it 19:28:22 most people don't know it exists 19:28:26 to be honest I don't think anyone cares 19:28:32 frankly ive never heard of anyone using it, and I still don't know what it does, if anything 19:28:36 and we should drop it to simplify the code 19:28:41 agree... 19:28:44 sorry, late, yeah 10757 got review, thanks 19:28:48 instagibbs: it disables a few RPCs related to the wallet 19:28:57 If one cares about, it could be re-written as external RPC layer/proxy 19:29:15 wumpus: yep seems reasonable to me as well 19:29:19 I mean the alerts that trigger it aren't reliable in the first place 19:29:29 and then it haphazardly disables some wallet RPCs 19:29:49 can always add it back if someone does the work 19:29:49 tbf, if it were useful, and disabled by default, the reaction of someone to not having it would probably be to just enable it, not complain 19:29:49 (but I don't see how it's useful as-is) 19:30:08 if someone would make the alerts useful and reliable, that'd be a first step :) 19:30:13 has safemode ever been triggered before due to a chain fork? 19:30:16 there's -alertnotify! 19:30:51 achow101: not that I know of... 19:31:02 it might make sense to have a "setsafemode" RPC instead of automatic stuff? 19:31:10 meh 19:31:35 * LukeJr shrugs 19:31:53 I don't think the current selection of RPCs to disable is useful, maybe something to disable all wallet calls then? I don't know - I don't think there is demand for this inpractice 19:31:56 BlueMatt: you make something that seems useless and dumb and isn't supposed to change behaviour and don't ping me for review? I'm disappointed :p 19:32:17 What exactly is the purpose of safemode though? If we keep it/change it, what is it's goal? 19:32:20 so anyhow, that was what I wanted t osay 19:32:30 I think everyone is 'meh' about it just like me 19:32:39 other topics? 19:32:44 i think it can just be removed 19:33:18 yes, I'd prefer that 19:33:38 wumpus: walletunload :D 19:33:39 achow101: ideally, it would detect odd network conditions and disable confirming transactions 19:33:39 achow101: eg, if there was an invalid chain longer than the best valid one 19:33:39 (or actually, even more ideal would be to compare the chains, and only confirm transactions common to both..) 19:33:58 #topic walletunload (Lukejr) 19:33:58 disabling RPCs is not how the bitcoin ecosystem will deal with an emergency anyway - a lot of infrastructure wouldn't even notice 19:34:34 I already have unload working without UI reacting 19:34:37 wumpus: I wasn't suggesting it as a topic 19:34:46 LukeJr: oh... 19:34:58 #unload walletunload 19:35:04 maybe topic: cfields any updates on app signing/certs etc? meant to follow up with you from ny 19:35:05 #untopic 19:35:05 wumpus: just saying it would have the same result as disabling wallet RPCs 19:35:32 fanquake: need to poke gmaxwell. He might've forgotten about it 19:35:47 promag: what happens if you try to use the GUI after unloading its wallet? 19:35:50 LukeJr: ok yes, I understand now :) 19:36:01 has anyone seen gmaxwell recently? is he still alive? 19:36:13 he's still alive 19:36:13 LukeJr: don't know, only tested with bitcoind 19:36:13 yes 19:37:03 LukeJr: after #13097 I'll submit unload in the UI 19:37:05 https://github.com/bitcoin/bitcoin/issues/13097 | Support wallets loaded dynamically by promag · Pull Request #13097 · bitcoin/bitcoin · GitHub 19:38:05 I think we've run out of topics 19:38:21 #endmeeting