1 2017-11-21 01:36:56	0|Murch|morcos: I was just looking at fee rate estimation. I'm surprised that the Bitcoin Core estimate is still on 170 for second block target when the network has been clearing the mempool of <40 for four days.
  2 2017-11-21 01:37:37	0|Murch|morcos: A few minutes ago, the block would have cleared down to below 5 satoshis per byte, but now there is one MB waiting at 160+
  3 2017-11-21 01:37:52	0|Murch|morcos: Maybe the estimation is a bit of o self-fulfilling prophecy?
  4 2017-11-21 01:38:26	0|sipa|Murch: fee estimation does not look at what fees would be required to confirm given the current mempool
  5 2017-11-21 01:38:32	0|sipa|but at what fees *are* confirming
  6 2017-11-21 01:38:34	0|Murch|I know
  7 2017-11-21 01:38:53	0|sipa|so yes, i guess it's by definition a self-fullfilling prophecy
  8 2017-11-21 01:39:07	0|sipa|if people keep overpaying, fee estimation will keep telling them to overpay
  9 2017-11-21 01:39:19	0|Murch|however, the fee estimation may be sustaining a higher fee level by jumping in at a too high level and generating enough send queue at that level
 10 2017-11-21 01:40:09	0|Murch|I was considering that Morcos' algorithm may not be decreasing fees aggressively enough after such a great fee spike as we had.
 11 2017-11-21 01:40:19	0|sipa|right
 12 2017-11-21 01:40:50	0|morcos|Murch: I'm not sure what you mean about clearing the mempool of <40 for 4 days
 13 2017-11-21 01:41:23	0|morcos|sipa: thats HOPEFU?LLy not true.  the design is such that if at least some poeple aren't overpaying, and are also being confirmed, then fee esitmation will let you know that
 14 2017-11-21 01:41:28	0|morcos|even if most poeple are still overpaying
 15 2017-11-21 01:41:35	0|sipa|morcos: right
 16 2017-11-21 01:41:56	0|sipa|morcos: but to an extent, there is a self-sustaining property in it
 17 2017-11-21 01:42:10	0|morcos|the short term estimate has a half-life of only 18 blocks... so anything that happened more than say 12 hours ago is pretty meaningless
 18 2017-11-21 01:43:07	0|morcos|yeah, there used to be more though.  now some people do place lower fees b/c they are willing to wait and so they use a longer target, so that helps the estimates for the shorter targets come down
 19 2017-11-21 01:43:28	0|morcos|that's a big part of why i wanted to increase the range to 1008.  incentivise people to try for those lower numbers
 20 2017-11-21 01:43:59	0|morcos|but yea, i think there is definitely room to improve fee estimation, i just thinkthere is not much low hanging fruit.  it's going to be pretty complicated to make it significantly better
 21 2017-11-21 01:44:35	0|Murch|well, the estimate does fit, as the fee level is now at ~170, but only 1.5MB over 30, and 1MB over 160 seems a bit unnatural
 22 2017-11-21 01:44:58	0|morcos|Murch, looking at the last couple hours, there are several blocks that haven't cleared down below 100
 23 2017-11-21 01:45:08	0|Murch|yeah, the next one won't either
 24 2017-11-21 01:45:24	0|morcos|so then if you want to get confirmed in 2 blocks, you shouldn't pay something that low
 25 2017-11-21 01:45:34	0|morcos|ask it for 12 and you'll get a much lower answer
 26 2017-11-21 01:46:16	0|Murch|yeah, was just curious if anyone else was watching this and had thoughts on it
 27 2017-11-21 01:48:09	0|morcos|Fee estimates for target of 6 have gone up recently actually
 28 2017-11-21 01:48:29	0|morcos|but yeah its a good idea to keep an eye on it, especially since its' relatively new
 29 2017-11-21 01:49:28	0|Murch|morcos: I was wondering, why is the fee estimate jumping at 45?
 30 2017-11-21 01:49:36	0|Murch|Are you switching the confidence curve?
 31 2017-11-21 01:50:01	0|Murch|sorry, 42
 32 2017-11-21 01:50:32	0|Murch|Or, if you don't know what I'm talking about, that may be custom to our estimate.
 33 2017-11-21 01:50:34	0|morcos|the time horizons break at 12 and 48, so there are often jumps around 6 , 12, 24, 48
 34 2017-11-21 01:50:45	0|morcos|i don't know why that would happen at 42
 35 2017-11-21 01:51:09	0|Murch|"23": 22152,
 36 2017-11-21 01:51:09	0|Murch|"25": 20083,
 37 2017-11-21 01:51:10	0|Murch|"42": 135327,
 38 2017-11-21 01:51:10	0|Murch|"49": 128408,
 39 2017-11-21 01:51:37	0|morcos|huh???
 40 2017-11-21 01:51:40	0|morcos|that's broken
 41 2017-11-21 01:51:44	0|morcos|it should never increase
 42 2017-11-21 01:51:46	0|Murch|Maybe it's just a modification in our algorithm, maybe we're not using Vanilla-Core after all
 43 2017-11-21 01:51:54	0|Murch|yeah, exactly
 44 2017-11-21 01:52:13	0|morcos|i see 19201 for 42
 45 2017-11-21 01:52:18	0|Murch|thanks
 46 2017-11-21 01:52:33	0|morcos|maybe you stopped asking for ECONOMICAL estimates?
 47 2017-11-21 01:52:56	0|Murch|We don't have RBF, so we don't do economical estimates
 48 2017-11-21 01:53:34	0|morcos|i think you are for 23/25
 49 2017-11-21 01:53:54	0|Murch|ah, that might be it
 50 2017-11-21 01:53:56	0|morcos|my conservative estimates for those are higher
 51 2017-11-21 01:54:32	0|Murch|Alright, well, I guess I was mistaken in my thinking that our fee estimation is vanilla Core :)
 52 2017-11-21 01:54:51	0|morcos|oh.. forgot where you work, yeah i don't think it is
 53 2017-11-21 01:55:32	0|Murch|alright, thanks for your insights
 54 2017-11-21 07:01:36	0|JeffSlentz|Hey, as a recent grad with not much experience with the Bitcoin Core project, are there any suggestions for contributing?
 55 2017-11-21 07:12:49	0|Randolf|JeffSlentz:  Probably one of the best things you can do is to become familiar with the source code.
 56 2017-11-21 07:13:05	0|Randolf|JeffSlentz:  From there, you may find an area that can be improved and then raise discussions about it.
 57 2017-11-21 07:13:26	0|Randolf|JeffSlentz:  ...and suggestions on how to improve it, including source code if you feel inclined to write some.
 58 2017-11-21 07:25:25	0|JeffSlentz|Randolf: Thanks! Is there a best practices way to learn the source code? I'm overwhelmed with the sheer amount
 59 2017-11-21 07:26:18	0|Randolf|JeffSlentz:  Are you familiar with the programming language(s) that said source code is written in?
 60 2017-11-21 07:27:12	0|Randolf|JeffSlentz:  If not, then there may be other options for you, but you'll probably need to ask about those possibilities in the #bitcoin channel.
 61 2017-11-21 07:29:10	0|fanquake|JeffSlentz Checkout the "good first issue" label on repo. https://github.com/bitcoin/bitcoin/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22
 62 2017-11-21 07:29:19	0|fanquake|JeffSlentz Trying to jump in and more generally "learn the source code" wont be the best place to start. Instead, pick an issue, familiarise yourself with the code concerned, submit a PR to fix it. Rinse & repeat.
 63 2017-11-21 07:29:40	0|JeffSlentz|Randolf: I've written some C++ but it's not my preferred language, I suppose.
 64 2017-11-21 07:30:35	0|JeffSlentz|fanquake: Thanks, I think that's a good approach
 65 2017-11-21 07:34:04	0|fanquake|JeffSlentz Also read through https://github.com/bitcoin/bitcoin/blob/master/CONTRIBUTING.md & https://github.com/bitcoin/bitcoin/blob/master/doc/developer-notes.md . They explain how the development process works, and preferred code styles etc.
 66 2017-11-21 07:52:07	0|bitcoin-git|13bitcoin/06master 14d9340ce 15Matt Corallo: Fix sendrawtransaction hang when sending a tx already in mempool
 67 2017-11-21 07:52:07	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/901ba3e38194...d4267a3ab271
 68 2017-11-21 07:52:08	0|bitcoin-git|13bitcoin/06master 14d4267a3 15Wladimir J. van der Laan: Merge #11738: Fix sendrawtransaction hang when sending a tx already in mempool...
 69 2017-11-21 07:52:44	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #11738: Fix sendrawtransaction hang when sending a tx already in mempool (06master...062017-11-fix-sendraw-block) 02https://github.com/bitcoin/bitcoin/pull/11738
 70 2017-11-21 08:18:44	0|fanquake|wumpus exposed :p
 71 2017-11-21 08:18:59	0|wumpus|fanquake: yep :p
 72 2017-11-21 08:25:13	0|geezas|anyone know if network-adjusted time as described in the wiki on block timestamps is used as described there
 73 2017-11-21 08:25:15	0|geezas|?
 74 2017-11-21 08:25:26	0|geezas|"A timestamp is accepted as valid if it is greater than the median timestamp of previous 11 blocks, and less than the network-adjusted time + 2 hours. "Network-adjusted time" is the median of the timestamps returned by all nodes connected to you."
 75 2017-11-21 09:42:25	0|wumpus|see GetMedianTimePast
 76 2017-11-21 09:50:52	0|Sentineo|wumpus: the timespamt from node is just the timestamp in the blocks my node receives, right? Checking getMedianTimePast(), it referencis the blockchain. I have a feeling geezas tends to think it is a message that is exchanged between nodes. Can you shed some light, which view is correct?
 77 2017-11-21 09:51:49	0|wumpus|the text he quotes talks about the median timestamp of the previous 11 blocks, that's implemented in GetMedianTimePast
 78 2017-11-21 09:52:31	0|wumpus|there is also a median filter get relative node times at connection, in src/timedata.h, but that is a wholly separate thing
 79 2017-11-21 09:52:39	0|sipa|it also talks about network-adjusted time, which is indeed there is a message exchanged between nodes
 80 2017-11-21 09:52:52	0|Sentineo|ah ok, that is what I wanted to know
 81 2017-11-21 09:53:05	0|Sentineo|tried doing an experiment, but can not force my system to change its time
 82 2017-11-21 09:53:41	0|Sentineo|so if I set my time to 2015 would I invalidate blocks? It sounds like bitcoin-core would take the blockchain (and other nodes) as the source of time
 83 2017-11-21 09:53:48	0|wumpus|there's an option to override that logic IIRC
 84 2017-11-21 09:53:52	0|Sentineo|need to look into timedata.h, that might answer it
 85 2017-11-21 09:53:57	0|sipa|it also never adjusts more than 1 hour iirc
 86 2017-11-21 09:54:00	0|wumpus|(for the node time, not for the consensus logic obviously)
 87 2017-11-21 09:54:37	0|wumpus|-maxtimeadjustment=0
 88 2017-11-21 09:54:46	0|Sentineo|yeah turned off ntp on my laptop, but will see. I will perhaps use regtest and disconnect from the internet for that time :)
 89 2017-11-21 09:55:12	0|wumpus|also if you just want to test w/ bitcoin and times there's setmocktime
 90 2017-11-21 09:56:11	0|Sentineo|ah ok, it must be in the unit tests than ... will look it up
 91 2017-11-21 09:56:12	0|Sentineo|ty!
 92 2017-11-21 09:57:00	0|wumpus|there's also the 'faketime' command that allows time machine experiments without changing time on your computer globally
 93 2017-11-21 09:57:36	0|Sentineo|ah wow
 94 2017-11-21 09:57:40	0|Sentineo|did not know that one
 95 2017-11-21 09:57:48	0|wumpus|"faketime - manipulate the system time for a given command" we use or at least used that for the gitian build to force a deterministic time
 96 2017-11-21 09:58:09	0|Sentineo|ah this is cool
 97 2017-11-21 09:59:20	0|wumpus|from my experience it doesn't work with very far future dates due to 32-bit timestamps, but YMMV
 98 2017-11-21 10:07:06	0|Sentineo|hm not getting peers when in future :)
 99 2017-11-21 12:26:24	0|Varunram|Hey guys, have a small question - Can anyone suggest an easy way to view the nSequence bit for rbf signalling? Thanks!
100 2017-11-21 12:34:10	0|Varunram|well, nvm, I just parsed the json from getrawtransaction :)
101 2017-11-21 13:52:47	0|bitcoin-git|[13bitcoin] 15MarcoFalke opened pull request #11743: qa: Add multiwallet prefix test (06master...06Mf1711-qaMultiwallet) 02https://github.com/bitcoin/bitcoin/pull/11743
102 2017-11-21 15:56:08	0|promag|wumpus: should #10996 be discussed next meeting?
103 2017-11-21 15:56:10	0|gribble|https://github.com/bitcoin/bitcoin/issues/10996 | Add per-network config file network.conf by ajtowns · Pull Request #10996 · bitcoin/bitcoin · GitHub
104 2017-11-21 15:57:29	0|wumpus|promag: sure
105 2017-11-21 15:57:42	0|promag|I'll give it a try
106 2017-11-21 15:57:52	0|wumpus|promag: I think it'd help a lot in changes that we're making that effectively set configuration for a single network
107 2017-11-21 15:58:16	0|promag|+
108 2017-11-21 15:58:18	0|promag|+1
109 2017-11-21 15:58:54	0|promag|I don't think we should allow overwriting logs different networks
110 2017-11-21 15:59:04	0|promag|*of different networks
111 2017-11-21 15:59:47	0|wumpus|we could allow some settings to only appear in per-network configuration or command line
112 2017-11-21 16:03:20	0|wumpus|we have no way of handling multiple daemons writing to the same log file so we really want to avoid that
113 2017-11-21 16:03:44	0|promag|right
114 2017-11-21 16:04:50	0|promag|maybe GetArg and friends could automatically handle options like `-(<network>-)?<arg>`?
115 2017-11-21 16:05:13	0|wumpus|also it'd make no sense, we'd have to distinguish which daemon is logging for each line - if you really want to dump all your bitcoin logging to one place, you can already use -printtoconsole w/ some log aggregation like systemd
116 2017-11-21 16:05:38	0|promag|right, proper logging
117 2017-11-21 16:05:40	0|wumpus|yea that'd be another option
118 2017-11-21 16:06:27	0|wumpus|to make it possible to prefix options with -regtest- and -testnet- or -mainnet-, that would (afaik) work just as well as per-network configuration files...
119 2017-11-21 16:07:16	0|promag|wumpus: the only difference is that you must launch with the network argument
120 2017-11-21 16:07:28	0|promag|so that it can read from the correct config file
121 2017-11-21 16:08:46	0|promag|with a single file, GetArg could 1st check -(<network>-)?<arg> and then -<arg>
122 2017-11-21 16:08:53	0|aj|hmm, does "-testnet-logfile=BLAH" make more sense than "-logfile=blah-$NETWORK-log" ?
123 2017-11-21 16:09:44	0|promag|aj: IMO it does, with $NETWORK you are stick to that replacement
124 2017-11-21 16:10:27	0|promag|anyway, something to discuss thrusday
125 2017-11-21 16:12:16	0|aj|promag: you could still use different conf files (-conffile or network specific) to have different names, but yeah, i think i agree
126 2017-11-21 16:13:04	0|aj|promag: i think setting -logfile=blah should be treated as -mainnet-logfile=blah, so if you run -regtest or -testnet you get an error, though...
127 2017-11-21 16:13:13	0|hkjn0|hey, I noticed that getrawtransaction says "Use gettransaction for wallet transactions" when it doesn't have a transaction.. but the gettransaction RPC doesn't seem to exist on my node, presumably because I compiled it with --disable-wallet?
128 2017-11-21 16:13:37	0|aj|promag: (or it uses the default location, rather than erroring probably)
129 2017-11-21 16:13:54	0|hkjn0|if that's what's going on, might it make sense to still have all the wallet RPCs stubbed out with a helpful message, even when wallet support is not compiled in?
130 2017-11-21 16:15:37	0|wumpus|hkjn0: would be better to change the getrawtransaction message to not mention the wallet if wallet support is not built in
131 2017-11-21 16:15:51	0|achow101|hkjn0: gettransaction is a wallet rpc, so if you did --disable-wallet, it won't exist
132 2017-11-21 16:16:23	0|hkjn0|ok wumpus, that also would make sense to me, but we agree current messages are somewhat confusing?
133 2017-11-21 16:17:17	0|wumpus|stubbing out the methods would add some code, and would make the wallet method names exist in yet another place, I prefer for nothing wallet-related to be in the client at all if built without
134 2017-11-21 16:17:56	0|wumpus|--disable-build is very much an advanced option, we don't ship binaries with that, and assume people that use it know what they're doing
135 2017-11-21 16:18:00	0|wumpus|disable-wallet lol
136 2017-11-21 16:18:21	0|hkjn0|clearly a risky assumption, in my case! :)
137 2017-11-21 16:18:53	0|hkjn0|ok, if the change is to just modify the getrawtransaction message if wallet isn't enabled, what's the best way to do that? should I file an issue?
138 2017-11-21 16:19:08	0|wumpus|make a patch and file a PR
139 2017-11-21 16:19:53	0|wumpus|if you create an issue for something non-critical without providing code, it's unlikely it's ever picked up
140 2017-11-21 16:21:36	0|hkjn0|I'm just asking for advice for best processes here, change might be simple enough that I can give it a whirl.. but the change is so small an issue is unnecessary here?
141 2017-11-21 16:22:15	0|hkjn0|or is it preferred to have issue + patch, even for small changes?
142 2017-11-21 16:25:24	0|wumpus|we always handle code changes through github PRs, even small ones
143 2017-11-21 16:25:28	0|wumpus|they still need review
144 2017-11-21 16:29:22	0|aj|jnewbery: btw, are you going to revive #11047 ?
145 2017-11-21 16:29:23	0|gribble|https://github.com/bitcoin/bitcoin/issues/11047 | [tests] rename functional tests by jnewbery · Pull Request #11047 · bitcoin/bitcoin · GitHub
146 2017-11-21 16:33:22	0|hkjn0|wumpus: sorry if I was unclear, I realize all changes go through PRs, but my question was whether it was encouraged to have PR + GH issue even for small changes, or if PR alone would suffice
147 2017-11-21 16:33:54	0|wumpus|PR alone is fine
148 2017-11-21 16:34:22	0|hkjn0|cool
149 2017-11-21 16:34:30	0|wumpus|sorry, was also confused by terminology, as github regards a PR also as a kind of issue
150 2017-11-21 16:34:35	0|instagibbs|hkjn0: please at least describe if it fixes something though
151 2017-11-21 16:36:12	0|hkjn0|instagibbs: could you elaborate? are you saying "use good descriptions in commits / PRs", or something else?
152 2017-11-21 16:37:43	0|instagibbs|hkjn0: right, as appropriate. At a minimum in the PR, so I can git blame and backtrace
153 2017-11-21 16:38:25	0|instagibbs|certain contributors aren't that great at it :P
154 2017-11-21 16:39:26	0|hkjn0|kk, for sure.. I'm pretty used to commit messages many times longer than actual code diff :)
155 2017-11-21 16:39:48	0|bitcoin-git|[13bitcoin] 15practicalswift opened pull request #11744: net: Add missing locks in net.{cpp,h} (06master...06missing-net-locks) 02https://github.com/bitcoin/bitcoin/pull/11744
156 2017-11-21 16:46:04	0|instagibbs|hkjn0: perfect :)
157 2017-11-21 17:05:14	0|jnewbery|aj: it's not near the top of my list. If you want it, it's yours!
158 2017-11-21 17:20:35	0|aj|jnewbery: does it need anything other than regular rebases and nit fixes?
159 2017-11-21 18:15:53	0|bitcoin-git|[13bitcoin] 15practicalswift opened pull request #11746: trivial: Fix unsuccessful typo (06master...06unsuccesful) 02https://github.com/bitcoin/bitcoin/pull/11746
160 2017-11-21 18:43:06	0|jonasschnelli|sipa: do you still have that "block request amount" graph? (what depth will be received how frequently)?
161 2017-11-21 19:05:44	0|sipa|jonasschnelli: i'm still gathering the data
162 2017-11-21 19:06:28	0|jonasschnelli|sipa: okay.. you have a live graph? or you will produce one once you have collected enought points?
163 2017-11-21 19:41:45	0|bitcoin-git|[13bitcoin] 15Elbandi opened pull request #11747: Fix: Open files read only if requested (06master...06fix11745) 02https://github.com/bitcoin/bitcoin/pull/11747
164 2017-11-21 19:44:35	0|ChuckSupport|Good day! I've been saving up since 2015 to buy my own antminer and finally mine on core and not GPU mine. I'm a QA first developer second and would like to contribute but I'm still new to github practices. Can someone suggest how I could go about this? Start with github practices, then how can I pull test code and test ,etc. Thanks for everything you've done and sacrificed for this!
165 2017-11-21 20:06:10	0|andytoshi|Chris_Stewart_5: #bitcoin-mining will probably be more helpful, or #bitcoin. this channel is specifically about software development of Bitcoin Core
166 2017-11-21 20:06:24	0|andytoshi|sorry Chris_Stewart_5 i meant to highlight that guy who left
167 2017-11-21 22:29:16	0|meshcollider|aj: are you here atm?
168 2017-11-21 22:29:26	0|aj|meshcollider: hey
169 2017-11-21 22:29:42	0|meshcollider|aj: re #10996, I'm just a little confused now
170 2017-11-21 22:29:44	0|gribble|https://github.com/bitcoin/bitcoin/issues/10996 | Add per-network config file network.conf by ajtowns · Pull Request #10996 · bitcoin/bitcoin · GitHub
171 2017-11-21 22:30:20	0|meshcollider|-netconf is just -conf but relative to net-specific datadir?
172 2017-11-21 22:31:23	0|aj|meshcollider: yeah: patch makes bitcoind load two config files, .bitcoin/bitcoin.conf and .bitcoin/testnet3/network.conf; -conf lets you choose a different name for the first one, -netconf a different name for the second one
173 2017-11-21 22:32:59	0|meshcollider|I like the default reading of the network specific config file but I'm worried the parameter interaction between conf and netconf will confuse users
174 2017-11-21 22:34:04	0|aj|meshcollider: i worry about that too. current behaviour is that bitcoin.conf is loaded first and network.conf second (so bitcoin.conf can specify the network), and any setting in bitcoin.conf overrides any setting in network.conf
175 2017-11-21 22:35:31	0|aj|meshcollider: (ie, GetArg returns the first value seen, GetArgs returns all of them from both files)
176 2017-11-21 22:36:10	0|meshcollider|aj: Perhaps instead of -netconf parameter, just rely on -conf for specifying a config file if they want (because they can specify one in a net-specific directory explicitly if they want) and then only load the network.conf if -conf is not specified?
177 2017-11-21 22:38:03	0|aj|meshcollider: hmm.. the choice i'm seeing is between having a param to let you choose a different name for the file, or no param at all and just always checking for datadir/network.conf
178 2017-11-21 22:38:42	0|meshcollider|I think if people are explicitly specifying a different config with -conf parameter, we can assume they want to use it on the network they've specified right?
179 2017-11-21 22:39:37	0|meshcollider|So if they use -conf, we only load that, but if they don't then we load the network specific file by default too?
180 2017-11-21 22:40:12	0|meshcollider|aj: But perhaps I haven't fully understood the use case so it's your call
181 2017-11-21 22:43:01	0|jnewbery|aj: sorry for long delay. Yes, just rebase and nits. Rebase should be easy - it's just a case of re-running the script
182 2017-11-21 22:47:32	0|aj|jnewbery: no worries about the delay, that's why the i in irc doesn't stand for instant :) sounds good, i guess i'll check with MarcoFalke that there's not more reason to close it than inactivity
183 2017-11-21 22:51:01	0|aj|meshcollider: i'm not sure if there's a use case... atm, you could have standard settings in bitcoin.conf and special settings in network.conf (mainnet addnode's say), and switch either independently via command line options. that just seems a bit more flexible and maybe natural to me?
184 2017-11-21 22:53:54	0|meshcollider|aj: Or, what if both the net specific file and the root datadir one had the same name, and -conf specified them both?
185 2017-11-21 22:54:16	0|meshcollider|Or would having them both called bitcoin.conf be confusing
186 2017-11-21 22:54:18	0|aj|meshcollider: mainnet bitcoin.conf and network.conf live in the same directory :(
187 2017-11-21 22:54:30	0|meshcollider|Ah true lol
188 2017-11-21 22:56:16	0|meshcollider|aj: Hmm perhaps someone else will give feedback on the approach too, I think I'd still prefer not having the netconf command and just using conf if it's specified but yeah no massive leaning either way
189 2017-11-21 22:59:58	0|aj|meshcollider: i might see if i can code up your way and match the tests, see what it looks liek
190 2017-11-21 23:00:26	0|meshcollider|aj: sounds good, thank you! :)
191 2017-11-21 23:00:39	0|aj|meshcollider: i don't expect to like it, but i've been wrong before :)
192 2017-11-21 23:00:39	0|meshcollider|Sorry for being difficult :)
193 2017-11-21 23:06:52	0|aj|meshcollider: hmm, question is, if i respond in less than two weeks, will the difficulty increase...
194 2017-11-21 23:37:51	0|bitcoin-git|[13bitcoin] 15fanquake closed pull request #11735: [refactor] Remove magic numbers from HMAC SHA256 (06master...06eliminate_magic_numbers) 02https://github.com/bitcoin/bitcoin/pull/11735