19:01:13 <wumpus> #startmeeting 19:01:13 <lightningbot> Meeting started Thu Dec 21 19:01:13 2017 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:01:13 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic. 19:01:18 <provoostenator> gmaxwell: ok, that's "great"; saves me time to reproduce. So far it's only using 1.1 GB of RAM in ~2013... 19:01:19 <wumpus> #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 19:01:28 <jonasschnelli> hi 19:01:38 <Chris_Stewart_5> hello 19:01:40 <provoostenator> hi 19:01:41 * BlueMatt is betting on low attendance 19:01:42 <promag> hi o/ 19:01:55 <kanzure> hi. 19:01:58 <luke-jr> why? 19:02:08 <gmaxwell> people travling for holidays 19:02:14 <luke-jr> oh 19:02:22 <sipa> oh, look, a meeting 19:02:23 <provoostenator> Without taking their laptop? Lame. 19:02:26 <promag> or buying gifts 19:02:34 <wumpus> seems there are enough people to warrant a meeting 19:02:41 <cfields> hi 19:03:12 <wumpus> but yes holidays is a good topic, I won't be there for next week and the week after that meeting 19:03:42 <promag> on my side just want to let know that I've made some progress on the activity feature, hope to submit PR next week 19:04:39 <jonasschnelli> topics? 19:04:43 <jtimon> hi 19:04:50 <wumpus> segwit wallet merge? please? :) 19:04:57 * sipa is in favor 19:04:57 <jonasschnelli> Yes. Please 19:05:00 <gmaxwell> plz 19:05:03 <jonasschnelli> xmas present 19:05:09 <sipa> but also please review first 19:05:10 <wumpus> #topic segwit wallet 19:05:18 <wumpus> what is left to do? 19:05:34 <BlueMatt> I think it needs more review still? I havent checked since my last round but there were a number of papercuts that needed fixing 19:05:34 <sipa> ryanofsky made a nice list of todos in a comment (all for other PRs ino) 19:05:46 <wumpus> yes, I mean for this PR 19:05:52 <sipa> BlueMatt: i've responded, please review 19:06:00 <BlueMatt> yes, will try to get back to it this week 19:06:06 <wumpus> there's plenty of things that can be done after merging it 19:06:12 <sipa> cool 19:06:21 <gmaxwell> sipa: did you look into that multisig still using p2sh thing we discussed? 19:06:32 <sipa> gmaxwell: yes, fixed, and added tests 19:06:42 <BlueMatt> oh, yes, it def needed more tests 19:06:51 <aj> ryanofsky's todo's: https://github.com/bitcoin/bitcoin/pull/11403#pullrequestreview-83563917 19:06:58 <sipa> BlueMatt: also addressed, i think 19:07:02 <BlueMatt> kool 19:07:06 <wumpus> #link ryanofsky's todo's: https://github.com/bitcoin/bitcoin/pull/11403#pullrequestreview-83563917 19:07:55 <sipa> ah yes, there are no address_type parsing tests yet 19:07:59 <sipa> i'll add those 19:08:16 <wumpus> great 19:09:07 <wumpus> any other topics? 19:09:18 <jonasschnelli> gitian build are broken 19:09:18 <jonasschnelli> https://github.com/bitcoin/bitcoin/issues/11935 19:09:23 <jonasschnelli> *builds 19:09:34 <BlueMatt> review 0.16 stuff! 19:09:35 <jonasschnelli> (I think its not a local issue) 19:09:39 <BlueMatt> (not just segwit wallet) 19:09:42 <wumpus> oh no not again 19:09:52 <cfields> mm, will have a look 19:09:54 <jonasschnelli> I think its one for cfields 19:09:58 <cfields> jonasschnelli: thanks for reporting 19:10:18 <cfields> jonasschnelli: oh, i see 19:10:29 <cfields> it's missing -static-libstdc++ for some reason 19:10:30 <Chris_Stewart_5> is there still a memory leak on master? 19:10:37 <wumpus> oh the symbols check fails 19:10:49 <jonasschnelli> Chris_Stewart_5: yes see 11824 19:10:50 <gmaxwell> Chris_Stewart_5: it's not a memory leak, but yes its still there. 19:10:53 <sipa> Chris_Stewart_5: not a leak, but memory is growing unboundedly 19:10:59 <wumpus> yes, it shouldn't dynamically import libstdc++ 19:11:01 <cfields> yea, the stdlib is just linked shared. Will get to the bottom of it. 19:11:21 <wumpus> cfields: thanks 19:11:22 <cfields> nice to see that got caught! 19:12:34 <jonasschnelli> it's broken since dec. 1st if that helps track down the relevant commit 19:13:38 <wumpus> two PRs were merged that day, #11804 and #11337 19:13:39 <gribble> https://github.com/bitcoin/bitcoin/issues/11804 | [docs] Fixed outdated link with archive.is by TimothyShimmin · Pull Request #11804 · bitcoin/bitcoin · GitHub 19:13:41 <gribble> https://github.com/bitcoin/bitcoin/issues/11337 | Fix code constness in CBlockIndex::GetAncestor() overloads by danra · Pull Request #11337 · bitcoin/bitcoin · GitHub 19:14:14 <cfields> thanks 19:14:35 <jonasschnelli> Build 2017-12-01 00:00:10 UTC failed... but build 2017-11-30 00:00:10 UTC succeeded 19:14:49 <wumpus> ok many more things were merged the day before that 19:15:36 <sipa> dec 1st in what tz? 19:15:45 <jonasschnelli> 2017-12-01 00:00:10 UTC 19:16:05 <jonasschnelli> Commit must be between 2017-11-30 00:00:10 UTC and 2017-12-01 00:00:10 UTC 19:16:19 <jonasschnelli> But maybe other topics first? 19:16:55 <jonasschnelli> anything to change at / mention from the HP list https://github.com/bitcoin/bitcoin/projects/8? 19:17:15 <wumpus> there's 10 things on there already, I don't think it will help to add more 19:17:15 <jtimon> BlueMatt: what is "0.16 stuff"? 19:17:31 <BlueMatt> jtimon: https://github.com/bitcoin/bitcoin/milestone/30 19:17:36 <wumpus> only so much that can be 'high priority' at once 19:17:55 <wumpus> and what we really want is segwit wallet anyway 19:18:06 <sipa> prioritize ALL THE THINGS! 19:18:13 <wumpus> hehe 19:18:27 <jtimon> does everything in there need to be merged before forking 0.16 ? 19:18:36 <wumpus> jtimon: no 19:18:46 <wumpus> just segwit wallet + the bugfixes 19:18:56 <wumpus> all features are optional 19:19:14 <wumpus> I think we get this question every week 19:19:32 <jonasschnelli> Maybe a short discussion about fallbackfee / RBF defaults? 19:19:42 <wumpus> #topic fallbackfee / RBF defaults 19:19:44 <jtimon> I guess the 0.16 tag confuses me 19:20:10 <jonasschnelli> There is a PR to split walletrbf between RPC and GUI #11605 (I don't think we should do that) 19:20:12 <gribble> https://github.com/bitcoin/bitcoin/issues/11605 | [Wallet] Enable RBF by default in QT by Sjors · Pull Request #11605 · bitcoin/bitcoin · GitHub 19:20:19 <wumpus> RBF should probably become default, I don't think there's any way around that 19:20:23 <jonasschnelli> Also,.. there are two PRs do disable the fallback fee (one on mainnet, one entierly) 19:20:23 <gmaxwell> RBF should probably be default now, electrum does it, without any great consequence. 19:20:34 <instagibbs> wumpus, ACK 19:20:41 <jonasschnelli> Okay. I agree. So lets enable it by default. 19:20:51 <promag> +1 19:20:52 <gmaxwell> jonasschnelli: if fallback fee is disabled what happens if it would otherwise use it? 19:21:04 <jonasschnelli> provoostenator: can you transform your PR toward that: 11605? 19:21:05 <wumpus> not sure what the rationale is to enable it only by default for qt? 19:21:10 <provoostenator> Well, I'm not so sure if that's a good idea for the RPC, which is used by different applicaitons than e.g. electrum. 19:21:14 <jonasschnelli> gmaxwell: reject 19:21:26 <jonasschnelli> Disabled fallback fee = JSON throw or QT reject 19:21:34 <gmaxwell> jonasschnelli: I mean, does the user get prompted to enter a fee? 19:21:39 <jonasschnelli> No 19:21:45 <wumpus> but let's merge enabling it for the gui first at least that's a step forward 19:21:45 <jonasschnelli> No manual fee entering is provoked 19:21:48 <provoostenator> Electrum is used afaik person to person, not for broadcasting lots of stuff through an automated process. 19:21:48 <gmaxwell> so the software just becomes unusable? 19:21:51 <luke-jr> ^ 19:21:57 <wumpus> jonasschnelli: but it's possible to select a custom fee right? 19:22:03 <wumpus> jonasschnelli: the GUI has a checkbox for that 19:22:05 <jonasschnelli> wumpus: Yes. Always... 19:22:10 <luke-jr> hmm 19:22:12 <wumpus> so no, the software doesn't become unusable 19:22:15 <gmaxwell> What about in the rpc/cli? 19:22:17 <jonasschnelli> wumpus: but if you don't and fee estimations are not ready,.. rject! 19:22:32 <jonasschnelli> gmaxwell: reject if you haven't set fallbackfee or paytxfee and feeest is not ready 19:22:40 <jonasschnelli> fallback fees are the worst! 19:22:43 <jonasschnelli> (UX) 19:23:00 <gmaxwell> Is there are rpc way to see a fallback fee? 19:23:01 <jonasschnelli> Especially if its default enabled and the user don't get informed it was used! 19:23:06 <sipa> feeest! 19:23:16 <jonasschnelli> gmaxwell: I don't think so 19:23:21 <gmaxwell> jonasschnelli: in the gui does the failure message tell you that you can set a fee? 19:23:25 <provoostenator> See this comment and the IRC discussion it points back to: https://github.com/bitcoin/bitcoin/pull/11605#issuecomment-352056518 (also cc bluematt) 19:23:26 <jonasschnelli> If we disable it by default, you wonldn't 19:23:40 <jonasschnelli> gmaxwell: no.. but I guess I should add that 19:23:58 <jonasschnelli> gmaxwell: it says you should wait for the feeest to be ready (a couple of blocks) 19:24:37 <gmaxwell> We should probably do this but we need to make the matching fixes so that the software isn't unusuable for the first day of running it or whatever. e.g. by telling you that you can manually set a fee and providing facilities to do that. 19:24:49 <gmaxwell> probably need to add a trivial rpc to set the fallback fee. 19:24:51 <jtimon> ack on RBF by default. I would also remove -mempoolreplacement and always do replacements but that's likely to be more controversial 19:25:06 <instagibbs> jtimon, luke-jr says miners actually use this option 19:25:10 <jonasschnelli> gmaxwell: I agree. 19:25:10 <wumpus> it's still settable on the command line at least 19:25:30 <gmaxwell> since paytxfee doesn't really do the right thing there. 19:25:32 <sipa> it's probably best to look at the actual UI, which i haven't :) 19:25:33 <jonasschnelli> We could even fetch estimations from bitcoincore.org (*hide* *duck* *runaway") 19:25:33 <wumpus> not sure it'd make sense as a RPC, as there's already paytxfee 19:25:42 <zelest> sorry for asking, but can anyone just grab whatever bug in the repo and fix it.. and submit a pull request? :o 19:25:47 <instagibbs> jonasschnelli, or from one of my two suspended twitter bots :P 19:25:54 <jtimon> instagibbs: yeah, I remember that, just repeating my opinion about it 19:25:55 <jonasschnelli> heh 19:26:02 <gmaxwell> wumpus: IIRC paytxfee overrides the estimator, rather than being overridden by the estimator. 19:26:11 <sipa> indeed 19:26:13 <wumpus> zelest: no, you need triple-signed off documents from the central committee first 19:26:20 <wumpus> zelest: (yes, everyone can just do that :-) 19:26:27 <gmaxwell> wumpus: so if you achieve your fallback by setting paytxfee then you'll end up underpaying even when your estimator knows better. 19:26:29 <zelest> Ah ;-) 19:26:31 <jonasschnelli> The sendto commands have really no clever way to set the txfee 19:26:51 <zelest> Mayhaps this is what I should spend/waste my free time on... 19:26:53 <gmaxwell> in any case, I can write the rpc to set the fallback fee, it would be trivial. 19:27:02 <jtimon> what is the fallback fee? 19:27:07 <meshcollider> hi, sorry I'm late 19:27:13 <gmaxwell> and then the errors when you hit that case should just tell you to set the fee. 19:27:14 <wumpus> gmaxwell: I think it'd be slightly confusing to add yet another fee setting RPC, but okay 19:27:14 <jonasschnelli> jtimon: its the feerate used when no estimations are available 19:27:22 <wumpus> another global used in fee determination 19:27:24 <jtimon> jonasschnelli: thanks 19:27:29 <wumpus> zelest: that'd be awesome 19:27:58 <jonasschnelli> I agree with gmaxwell that we need a good UX for the first "day" when fee estimations are not available 19:28:03 <gmaxwell> wumpus: Agreed, but I don't see around it, telling lots of people to use paytxfee is probably a bad situation. 19:28:10 <promag> so if fee estimation is not available, rpc funding should fail? 19:28:22 <gmaxwell> jonasschnelli: not just first day, every day, because of resource usage lots of people don't leave their nodes running. 19:28:23 <jonasschnelli> promag: Yes 19:28:24 <wumpus> gmaxwell: agree... 19:28:32 <jonasschnelli> gmaxwell: indeed. 19:28:47 <gmaxwell> promag: unless you've set a fallback feerate. 19:28:48 <wumpus> gmaxwell: would almost wish that there'd be something like 'paytxfeepriority' but not that that would be any easier to understand :-) 19:28:52 <promag> jonasschnelli: and in the UI too? or prompt for custom? 19:28:53 <jtimon> gmaxwell: yeah, or people just shut down their computers when they go to sleep 19:28:56 <jonasschnelli> So either the user enters the current feerates into RPC/GUI or we load it from somewhere 19:29:03 <wumpus> gmaxwell: (e.g. whether it'd override the fee estimator or not) 19:29:04 <promag> gmaxwell: but we want to remove that? 19:29:20 <gmaxwell> promag: no we want to eliminate there being a default one. 19:29:48 <gmaxwell> The estimator is always going to take time to start working. And it's not reasonable to force people to not transact until they have estimates. 19:30:03 <gmaxwell> But a static compiled in fallback is dumb. 19:30:05 <wumpus> promag: the problem is that fees are too variable now to hardcode any sensible default in the software 19:30:06 <promag> gmaxwell: ok, but once defined it can be outdated very fast 19:30:22 <luke-jr> ideally we could pre-sign multiple fee rates and send the higher ones once we have an estimate 19:30:43 <promag> luke-jr: only with rbf signaled 19:30:54 <gmaxwell> RBFing has complications, unfortunately. 19:30:54 <promag> ? 19:31:04 <jonasschnelli> luke-jr: long term.... yes. Maybe. But complicated to implement 19:31:05 <luke-jr> well, require RBF when there's no estimates? 19:31:14 <jonasschnelli> luke-jr: I had this in a PR 19:31:17 <gmaxwell> You can't just assume that RBF will work unfortunately. 19:31:25 <gmaxwell> Because of the pinning problem. 19:31:26 <jonasschnelli> But then morocs asked for just disabling fallback.. which makes sense 19:31:31 <wumpus> RBF is orthogonal imo 19:31:33 <luke-jr> even without RBF, it would probably work if the problem is fee rate too low 19:31:43 <instagibbs> gmaxwell, "pinning" meaning someone spending on top? 19:31:47 <instagibbs> I like the name if so 19:31:48 <luke-jr> if nobody has the conflicting tx in their mempool, it's not even considered a replacement 19:31:51 <wumpus> yes, we also want RBF by default, but that doesn't change the fallback fee situation 19:31:52 <gmaxwell> instagibbs: with a large txn, yes. 19:32:10 <wumpus> certainly not for RPC 19:32:32 * luke-jr wonders how pinning affects mempool eviction of low feerate 19:32:38 <jonasschnelli> I think the fallback fee problem is solveble in the GUI,... but not sure about RPC layer,... we would have to add feerate parameters to the send commands 19:32:41 <gmaxwell> in any case, ACK removing fallback fee but we must be mindful that for a lot of users the no-estimate case will be very frequent so the workflow has to be good: which means clear messages and a straight forward way to set a fee. 19:33:03 <gmaxwell> jonasschnelli: RPC I think is fine, setfallbackfee ... and the error returned on send tells you that you have to use that. 19:33:15 <wumpus> yeah... 19:33:22 <jonasschnelli> I think gmaxwell idea with the setfallbackfee RPC makes most sense.. 19:33:26 <jtimon> yeah I think RBF is orthogonal too. let's just make it default independently of the estimation issue 19:33:35 <wumpus> jtimon: agree 19:33:37 <gmaxwell> then for cli users the workflow is basically like the GUI one, and for businesses they might pull the fallback off another node, or an estimation site. 19:33:48 <wumpus> right 19:33:50 <gmaxwell> (automatically) 19:33:59 <jtimon> don't we have an estimator purely based on past blocks with no knowledge of the mempool? 19:34:27 <instagibbs> jtimon, that's the only way we do it 19:34:54 <jtimon> mhm, then why do you need to be up for some time to have estimates? 19:34:55 <gmaxwell> instagibbs: not quite we watch the dwell time of transactions that confirm. 19:34:59 <gmaxwell> it needs both 19:35:01 <promag> how about something to help/speedup fee estimation? 19:35:23 <instagibbs> mistook the question 19:35:25 <wumpus> using only blocks would be easy to manipulate 19:35:26 <promag> like feeding fee estimation with something.. don't know the internals 19:35:31 <gmaxwell> using blocks exclusively is exploitable, unfortunately. Though there are limited ways which it could help. 19:35:56 <gmaxwell> e.g. you could look at the minimum fee confirmed over many blocks, but sadly it would be misleadingly low because of OOB payments and such. 19:36:03 <jtimon> perhaps we could have a non-mempool estimator that is used by default until there's data for the mempool based one 19:36:20 <wumpus> adding a new estimator is not going to go for 0.16 at least 19:36:33 <wumpus> in the future, who knows 19:36:43 <gmaxwell> also it's not likely to be invented by folks who don't know the current one and history. :) 19:36:54 <jtimon> say, something stupid like max (the minimum feerate in each block for the last 144 blocks) 19:37:38 <gmaxwell> jtimon: yes, maybe... under the bet that there is at least one block with no OOB fees. You'd have to exclude blocks that weren't full. 19:37:55 <sipa> or bounding estimates by the feerate at 1 MB vbyte from the top of the mempool 19:38:01 <aj> jtimon: aggregate all the fee rates over a bunch of blocks and choose a fee that's higher than ~10% or 20% of them 19:38:09 <gmaxwell> sipa: without mempool sync that isn't fast. 19:38:16 <jtimon> gmaxwell: right, 100 empty blocks would screw you 19:38:18 <sipa> ah yes 19:38:23 <gmaxwell> but indeed, once we have some kind of mempool sync we could do things like that. 19:38:49 <wumpus> 100 empty blocks would screw everyone 19:39:24 <jtimon> is there a way to persist the mempool while running instead of only when shutting down? 19:39:38 <instagibbs> jtimon, i think there is an rpc for that 19:39:49 <gmaxwell> jtimon: just go back one day of blocks, counting only blocks at least 0.95*MAX_WEIGHT in size, and check the maximum of their minimum feerates. Would be interesting to see what that yields right now. It _might_ be useful. 19:40:05 <wumpus> savemempool RPC 19:40:22 <instagibbs> https://github.com/bitcoin/bitcoin/pull/11099 19:40:44 <jtimon> gmaxwell: yeah, that sounds less stupid than what I proposed, and still isn't hard 19:41:19 <gmaxwell> or instead of their minimum feerate, their Nth percentile feerate. 19:41:26 <jtimon> I mean, still probably not for 0.16, but not hard to code I think 19:41:31 <gmaxwell> right 19:41:48 <wumpus> any other topics? 19:42:07 <gmaxwell> e.g. what feerate is less than 95% of the txn in the block... gives it room to ignore 5% priority txn. 19:42:18 <jtimon> wumpus: instagibbs thank you! and sorry, the question is kind of unrelated anyway 19:42:20 <wumpus> yes that'd make sense 19:42:20 <provoostenator> I'm still reluctant about enabling RBF for RPC. Without having a long disucssion here, is there a list of known large services that use Bitcoin Core RPC to broadcast transactions? I'd like to know their take on this. 19:42:40 <gmaxwell> provoostenator: an RPC using service can at least read the release note and simply turn it off again. 19:42:44 <aj> i did sextile graphs of fee rates aggregated over 24 hours the other day, http://azure.erisian.com.au/~aj/tmp/graphs/fpvb-trends.png and http://azure.erisian.com.au/~aj/tmp/graphs/segwit-comparison.png i think they track pretty well 19:42:50 <wumpus> promag: let's first enable it for the gui, at least that's uncontroversial 19:42:54 <wumpus> provoostenator* 19:44:23 <instagibbs> 15 minutes left 19:44:25 <provoostenator> It's equally trivial for an RPC user to just set walletrbf=1 if they want to use this. The only problem seems to be code complexity. 19:44:30 <wumpus> I think having a too long defaults discussion is not productive, if anyone is opposed to enabling it for RPC with good reason then we shouldn't do that 19:44:51 <gmaxwell> rpc can wait, we can release note a reminder that you can turn it on for cli/rpc use. 19:44:54 <promag> wumpus: ok 19:45:09 <wumpus> people using RPC will usually have a better idea of available options anyhow 19:45:12 <provoostenator> gmaxwell: I already put that in the release note in my PR 19:45:20 <instagibbs> perhaps with a warning that future versions may change this 19:45:21 <provoostenator> (sort of) 19:45:34 <jonasschnelli> I don't think splitting walletrbf between GUI and RPC makes sense in the long run 19:45:40 <wumpus> yes, defaults are subject to change 19:45:44 <gmaxwell> sipa: so what do you think long term trying to use that block percentile as a maximum fee for a fast estimate, and then use a synced mempool to potentially reduce the number. I think that escapes the primary manipulation concerns we have. 19:45:45 <wumpus> jonasschnelli: on the long run it makes no sense 19:45:50 <provoostenator> I think it does make sense to treat GUI and RPC different 19:45:53 <wumpus> jonasschnelli: it'd be a temporary artifact 19:45:56 <provoostenator> Very different use cases. 19:45:59 <gmaxwell> just get rid of the setting for the GUI. 19:46:15 <provoostenator> It's just a code maintenance thing why we shouldn't make them too different. 19:46:28 <sipa> gmaxwell: if you're worried about OOB paymemts, shouldn't you also be concerned about OOB refunds? 19:46:39 <jonasschnelli> What speak again just enabling -walletrbf GUI/RPC by default? 19:46:42 <jonasschnelli> *against 19:46:44 <wumpus> gmaxwell: I think that's a good point too - why would the GUI need a setting for the default? 19:46:47 <jtimon> i think rbf active is the most sensible default for both rpc and gui 19:46:49 <gmaxwell> sipa: OOB refunds don't currently appear to be a real thing. 19:46:49 <wumpus> it has a checkbox if you really want to disable it 19:46:56 <provoostenator> gmaxwell: yes, I can kill the setting for the GUI, especially because I renamed the RPC setting to -rpcwalletrbf 19:47:00 <gmaxwell> wumpus: yep thats just what I was typing, that it has a checkbox. 19:47:00 <jonasschnelli> wumpus: people are lazy to read checkboxes? :) 19:47:25 <gmaxwell> then they'll certantly not read a setting. :) 19:47:26 <wumpus> jonasschnelli: well the default is sensible, lazy people won't want to override it! 19:47:32 <wumpus> gmaxwell: indeed 19:47:43 <sipa> gmaxwell: for now. 19:47:57 <wumpus> +1 on not having the GUI default setting 19:48:01 <jonasschnelli> Set walletrbf=1 by default,.. switch the checkbox in the GUI (to disable RBF instead of enable) 19:49:24 <jtimon> why not leave the checkbox as meaning enabled but simply have it checked by default? 19:49:30 <provoostenator> Rather than renaming -walletrbf to -rpcwalletrbf, I can also make it clear that -walletrbf won't impact the GUI. 19:49:43 <wumpus> provoostenator: yes, I'd prefer that 19:49:47 <gmaxwell> +1 19:49:54 <wumpus> provoostenator: I'd really prefer not to have a rename/deprecate cycle there 19:50:00 <wumpus> provoostenator: (as I've expressed before) 19:50:03 <gmaxwell> better to not break things for people who are already walletrbf=1 if we can avoid it. 19:50:10 <wumpus> yeah... 19:50:10 * jonasschnelli unsure 19:50:26 <wumpus> just document the option instead of renaming it 19:50:27 <jonasschnelli> Wait...yes. This makes sense 19:50:28 <provoostenator> Yeah, the deprecation stuff was a bit overkill. 19:50:48 <gmaxwell> just adjust the description, make the gui not read that setting for the checkbox default. 19:50:49 <wumpus> ok, cool! 19:50:55 <wumpus> seems we agree 19:50:58 <jonasschnelli> ack 19:51:05 <meshcollider> yep sounds good 19:51:07 <gmaxwell> if users complain that they can't set a different default we'll deal with that then, but I don't expect it. 19:51:15 <luke-jr> why not just let -walletrbf continue to work, but have the new defaults only affect when it's unset? 19:51:24 <wumpus> luke-jr: it will continue to work 19:51:30 <wumpus> for the RPC 19:51:34 <luke-jr> wumpus: I mean for both 19:51:37 <wumpus> any other topics? 19:51:48 <wumpus> luke-jr: using the same setting with different default in different places was *ugly* 19:52:01 <provoostenator> ^ 19:52:13 <provoostenator> That was actually what I did in the first version, but it's confusing. 19:52:24 <gmaxwell> the 'implementation defined behavior when not set' should be used very sparingly. 19:52:28 <provoostenator> Making it clear that -walletrbf has no bearing on the GUI (including it's default) seems better. 19:52:31 <luke-jr> IMO the ugliness only comes from having two defaults, not from having a common setting 19:52:42 <wumpus> yes, that used to be the case, but it's no way to handle options imo, and won't be ocmpatible when we introduce an actual options registration/parsing system 19:52:47 <provoostenator> I'll push that after the meeting. 19:52:57 <jonasschnelli> Thanks provoostenator! 19:52:58 <gmaxwell> In general we should probably not have config file setting for GUI checkboxes that stare the user in the face. 19:53:06 <provoostenator> Remind me not to make changes to defaults too often :-) 19:53:09 <gmaxwell> if the GUI wants a persistant default it should be changable from the GUI. 19:53:14 <meshcollider> Which I am trying to work on at the moment :) 19:53:17 <luke-jr> gmaxwell: via rwconf ;) 19:53:18 <jonasschnelli> provoostenator: hah... these are the worst. :) 19:53:20 <gmaxwell> But hopefully we won't need a changable persistant default for this. 19:53:50 <wumpus> right 19:53:53 <jtimon> the rbf checkbox doesn't appear with every tx? 19:54:03 <provoostenator> luke-jr: rwconf? 19:54:17 <wumpus> jtimon: isn't it always there? 19:54:20 <meshcollider> jtimon: what? 19:54:21 <gmaxwell> provoostenator: code to allow the conf file to be rewritten by setting changes at runtime. 19:54:23 <luke-jr> provoostenator: lets the GUI change config file settings 19:54:32 <wumpus> please, no scope creep 19:54:38 <gmaxwell> that was just a tangent. 19:54:44 <gmaxwell> not scope creep. :) 19:54:55 <provoostenator> Ah, so we don't have this "here's a setting, but if you use -blah it's overridden, unless you also have bitcoin.conf, unless you have another one" stuff? 19:55:17 <gmaxwell> I was just expressing the principle that controlling GUI defaults via non-gui accessable settings is just not very good. 19:55:24 <jtimon> sorry, I should look at the gui. my assumption was that for every tx a checkbox would say "allow rbf" and that is unchecked by default and we're moving to checked by default 19:55:31 <wumpus> it would add another bitcoin.conf, bitcoin_rw.conf, which can be written by the software itself 19:55:45 <provoostenator> gmaxwell: indeed, also not very easy to launch QT with flags on OSX. 19:55:53 <gmaxwell> I know, we could save the users settings ON THE BLOCKCHAIN 19:56:03 <meshcollider> jtimon: yep that's basically what this is doing 19:56:08 <wumpus> hehehe, settings delta chain 19:56:10 <sipa> gmaxwell: woah! 19:56:44 <meshcollider> lol 19:56:50 * cfields founds chainsettingsalytics 19:56:51 <wumpus> gmaxwell: I"m surprised that no *coin project commits git diffs to the blockchain yet 19:56:56 <jtimon> meshcollider: then I don't understand the -walletrbf discussion, but it's fine 19:57:02 <gmaxwell> plus the related costs will make them never get changed, and since they're never changed we could remove the implementation of the choices... less UI to maintain! 19:57:12 <provoostenator> Some people use opentimestamps for that 19:57:24 <provoostenator> The git integration thing. 19:57:32 <achow101> wumpus: there's definitely a Core commit diff somewhere on the blockchain 19:57:33 <meshcollider> jtimon: the walletrbf discussion is about whether that parameter should affect the GUI default or only the RPC I believe 19:57:34 <wumpus> or even better, just commit javascript code for the GUI to the block chain 19:57:42 <wumpus> :') 19:57:47 <achow101> I found it once, but don't know where it is 19:58:05 <wumpus> achow101: oh! which one? 19:58:19 <wumpus> it'd certainly create incentive to make patches small 19:58:23 <achow101> wumpus: I don't quite remember 19:58:56 <jtimon> meshcollider: right, we're moving to not affecting it seems, which is what makes most sense to me, just what I described with no relation to -walletrbf. so it's fine. 19:58:57 <meshcollider> wumpus: heh why just the GUI, entire new versions of core could be downloaded directly from the blockchain too! 19:59:08 <wumpus> no one would submit a diff-all-over-the-place PR if it costs >300 sat/byte 19:59:28 <wumpus> meshcollider: yes of course, updates to the consensus algo too :') 19:59:29 <sipa> wumpus: do you get a refund for deleted lines? 19:59:34 <wumpus> sipa: yes! 19:59:35 <provoostenator> Unless they want to show off their wealth as an offering... 19:59:37 <meshcollider> jtimon: yep exactly 19:59:38 <jtimon> meshcollider: that would be great to make sure everyone upgrades before a hf :p 19:59:44 <sipa> wumpus: brb, deleting all the tests 19:59:54 <wumpus> sipa: but only if accepted :-) 19:59:57 <luke-jr> wumpus: you're going to give my children nightmares 19:59:58 <sipa> oh. 20:00:05 <sipa> DONG 20:00:08 <wumpus> #endmeeting