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