1 2017-07-17T00:10:41  *** fanquake has joined #bitcoin-core-dev
   2 2017-07-17T00:10:44  *** rhavar has joined #bitcoin-core-dev
   3 2017-07-17T00:10:54  *** fanquake has quit IRC
   4 2017-07-17T00:12:56  *** jamesob has joined #bitcoin-core-dev
   5 2017-07-17T00:13:32  *** arowser has joined #bitcoin-core-dev
   6 2017-07-17T00:15:49  <sipa> gmaxwell: we likely want that to be dynamic, based on the chosen implementation
   7 2017-07-17T00:16:47  <gmaxwell> I don't think always buffering two would hurt, other than a slight latency hit.
   8 2017-07-17T00:17:00  <gmaxwell> 8 would be kinda nuts
   9 2017-07-17T00:17:05  *** jamesob has quit IRC
  10 2017-07-17T00:17:08  <sipa> well, we can benchmark
  11 2017-07-17T00:19:44  <gmaxwell> I could be wrong about it mattering at all too. Though I don't think so.
  12 2017-07-17T00:23:52  *** belcher has quit IRC
  13 2017-07-17T00:25:28  *** belcher has joined #bitcoin-core-dev
  14 2017-07-17T00:32:43  *** Chris_Stewart_5 has quit IRC
  15 2017-07-17T00:35:38  *** arowser has quit IRC
  16 2017-07-17T00:38:45  *** Murch has joined #bitcoin-core-dev
  17 2017-07-17T00:40:26  *** Murch has quit IRC
  18 2017-07-17T00:42:17  *** arowser has joined #bitcoin-core-dev
  19 2017-07-17T00:56:09  *** arowser has quit IRC
  20 2017-07-17T00:58:41  *** goatpig has quit IRC
  21 2017-07-17T01:00:13  <sipa> hmm, i wonder why i think that sse 4.2 is needed for that asm code
  22 2017-07-17T01:00:20  <sipa> it seems to only use sse 4.1 instructions
  23 2017-07-17T01:00:28  <sipa> crc32 needs sse 4.2
  24 2017-07-17T01:07:00  *** promag has quit IRC
  25 2017-07-17T01:18:47  *** arowser has joined #bitcoin-core-dev
  26 2017-07-17T01:21:51  *** Murch has joined #bitcoin-core-dev
  27 2017-07-17T01:25:09  *** discreteunit has joined #bitcoin-core-dev
  28 2017-07-17T01:28:01  *** chjj has quit IRC
  29 2017-07-17T01:31:54  *** chjj has joined #bitcoin-core-dev
  30 2017-07-17T01:34:45  *** discreteunit has quit IRC
  31 2017-07-17T01:42:06  *** arowser has quit IRC
  32 2017-07-17T01:49:48  *** Ylbam has quit IRC
  33 2017-07-17T01:51:28  *** arowser has joined #bitcoin-core-dev
  34 2017-07-17T02:05:25  *** arowser has quit IRC
  35 2017-07-17T02:11:50  *** arowser has joined #bitcoin-core-dev
  36 2017-07-17T02:14:11  *** jamesob has joined #bitcoin-core-dev
  37 2017-07-17T02:18:43  *** jamesob has quit IRC
  38 2017-07-17T02:26:39  <bitcoin-git> [bitcoin] MarcoFalke pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/3895e25a7736...bf0a08be281d
  39 2017-07-17T02:26:40  <bitcoin-git> bitcoin/master ff7365e John Newbery: [tests] fix flake8 warnings in zapwallettxes.py
  40 2017-07-17T02:26:40  <bitcoin-git> bitcoin/master e7a2181 John Newbery: [wallet] fix zapwallettxes interaction with persistent mempool...
  41 2017-07-17T02:26:41  <bitcoin-git> bitcoin/master 4c3b538 John Newbery: [logs] fix zapwallettxes startup logs
  42 2017-07-17T02:26:55  *** Chris_Stewart_5 has joined #bitcoin-core-dev
  43 2017-07-17T02:26:56  <bitcoin-git> [bitcoin] MarcoFalke closed pull request #10330: [wallet] fix zapwallettxes interaction with persistent mempool (master...zapwallettxes) https://github.com/bitcoin/bitcoin/pull/10330
  44 2017-07-17T02:27:50  *** rhavar has quit IRC
  45 2017-07-17T02:34:38  *** Chris_Stewart_5 has quit IRC
  46 2017-07-17T02:40:02  *** handlex has joined #bitcoin-core-dev
  47 2017-07-17T02:40:05  *** twistedline has quit IRC
  48 2017-07-17T02:40:06  *** twistedline_ has joined #bitcoin-core-dev
  49 2017-07-17T02:44:05  *** twistedline_ has quit IRC
  50 2017-07-17T02:44:12  *** twistedline has joined #bitcoin-core-dev
  51 2017-07-17T02:48:01  *** Chris_Stewart_5 has joined #bitcoin-core-dev
  52 2017-07-17T02:48:22  *** twistedline has quit IRC
  53 2017-07-17T02:52:34  *** twistedline has joined #bitcoin-core-dev
  54 2017-07-17T03:08:23  *** jamesob has joined #bitcoin-core-dev
  55 2017-07-17T03:08:39  *** handlex has quit IRC
  56 2017-07-17T03:11:21  *** handlex has joined #bitcoin-core-dev
  57 2017-07-17T03:17:48  *** Giszmo has quit IRC
  58 2017-07-17T03:32:48  *** Giszmo has joined #bitcoin-core-dev
  59 2017-07-17T03:40:32  *** Chris_Stewart_5 has quit IRC
  60 2017-07-17T03:55:21  *** handlex has quit IRC
  61 2017-07-17T04:18:07  <bitcoin-git> [bitcoin] jnewbery closed pull request #10802: [tests] skip zapwallettxes.py (master...skip_zapwallettxes) https://github.com/bitcoin/bitcoin/pull/10802
  62 2017-07-17T04:25:39  <gmaxwell> sipa: you broke the sse4 thing by renaming incompletely. fixy fixy.
  63 2017-07-17T04:37:14  <sipa> gmaxwell: fixed
  64 2017-07-17T04:42:28  <cfields> jeez, qt 5.9 made a mess of _everything_
  65 2017-07-17T04:44:05  <gmaxwell> What did they do
  66 2017-07-17T04:46:54  <cfields> they're working on modularizing their source/build. but the result (so far) is just a new tangled mess of dependencies. And no working configs without patches
  67 2017-07-17T04:46:57  *** JackH has quit IRC
  68 2017-07-17T04:47:38  <cfields> want cocoa for osx? you'll need a printer of course. And obviously printers require opengl...
  69 2017-07-17T04:47:49  <luke-jr> O.o
  70 2017-07-17T04:47:50  <sipa> any reason why we'd really want 5.9?
  71 2017-07-17T04:48:02  <sipa> cfields: they're 3D printers perhaps? :D
  72 2017-07-17T04:48:44  <cfields> sipa: lol
  73 2017-07-17T04:49:13  <cfields> sipa: ironically i was looking forward to 5.9 and its slimmer build
  74 2017-07-17T04:49:15  <gmaxwell> they probably need opengl for 'lpad()'...
  75 2017-07-17T04:50:00  <sipa> or for is_integer
  76 2017-07-17T04:50:38  <cfields> but after messing with it all day, it's not offering many advantages so far
  77 2017-07-17T04:51:00  *** Giszmo has quit IRC
  78 2017-07-17T04:51:00  <cfields> (other than providing me a stack of patches to upstream)
  79 2017-07-17T04:52:20  <cfields> so no, i don't think it makes sense to bump
  80 2017-07-17T04:52:40  <cfields> as-is, we don't build with 5.9. But I haven't seen a bug report yet, so I'm assuming distros aren't shipping it
  81 2017-07-17T04:52:57  <cfields> (and it'll be a pain to support once they do :( )
  82 2017-07-17T04:53:44  <luke-jr> Qt used to care about backward compat :/
  83 2017-07-17T04:54:02  <luke-jr> I noticed some stuff I have won't build with 5.7 because it requires C++11 >_<
  84 2017-07-17T04:54:02  <cfields> luke-jr: i suspect all is fine if you use qmake
  85 2017-07-17T04:54:12  <luke-jr> ah
  86 2017-07-17T04:54:22  <cfields> yea, c++11 became a hard dep for 5.7 i believe
  87 2017-07-17T04:54:25  <luke-jr> well, FWIW, Gentoo doesn't have 5.8 as even an option yet
  88 2017-07-17T04:54:46  <cfields> but stl is still optional i think :p
  89 2017-07-17T04:54:50  <luke-jr> hard dep makes sense; but 5.7 won't allow Qt programs to use non-C++11 :p
  90 2017-07-17T04:55:26  <sipa> gcc 6 by default already compiles with c++14
  91 2017-07-17T04:55:26  <luke-jr> anyhow, so I changed my USE flags to build that app for Qt4 <.<
  92 2017-07-17T04:55:36  <cfields> mm, that's annoying. but kinda makes sense from a support standpoint
  93 2017-07-17T05:05:39  *** Giszmo has joined #bitcoin-core-dev
  94 2017-07-17T05:05:43  *** QBcrusher_ has joined #bitcoin-core-dev
  95 2017-07-17T05:07:09  *** Murch has quit IRC
  96 2017-07-17T05:08:17  *** QBcrusher has quit IRC
  97 2017-07-17T05:23:58  *** CubicEarth has joined #bitcoin-core-dev
  98 2017-07-17T05:28:19  *** paveljanik has quit IRC
  99 2017-07-17T05:58:45  <wumpus> any reason to not just stick with our current qt for 0.15? that sounds like a nightmare, better let them sort out their problems upstream and not be a guinea pig
 100 2017-07-17T05:59:46  <wumpus> from a user PoV there seems to be no difference between different qt version for a long time now, as we basically only use the 4.x API
 101 2017-07-17T06:06:17  <luke-jr> they don't even have a Qt5.9 dance, so..
 102 2017-07-17T06:06:46  <wumpus> hehe
 103 2017-07-17T06:12:23  <wumpus> disabling -getinfo on the day of the feature freeze, really?
 104 2017-07-17T06:13:27  <luke-jr> meh, why not. there's an option to get it back
 105 2017-07-17T06:13:33  <wumpus> I don't get it, what is the sudden rush?
 106 2017-07-17T06:14:00  <wumpus> sure, but we could have done that 100 times during 0.15's release cycle
 107 2017-07-17T06:14:07  <wumpus> but somehow it has to be added in the last day
 108 2017-07-17T06:14:11  <gmaxwell> leeroy jenkins!
 109 2017-07-17T06:14:18  <luke-jr> I suppose it adds a new string
 110 2017-07-17T06:14:27  <luke-jr> (for the -help)
 111 2017-07-17T06:15:19  <gmaxwell> I think it should be done at the beginning of a cycle. It's bound to cause severe irritation for people who use it at the CLI and we will predictably get PRs to improve other things to compensate.
 112 2017-07-17T06:15:42  <wumpus> gmaxwell: heh indeed, in this way we don't even get used to it ourself
 113 2017-07-17T06:15:51  <wumpus> before exposing it to end users
 114 2017-07-17T06:15:53  *** CubicEarth has quit IRC
 115 2017-07-17T06:16:14  <wumpus> can't we just add a comment to the getinfo output instead?
 116 2017-07-17T06:16:22  <wumpus> Warning: this will be deprecated!
 117 2017-07-17T06:16:26  <gmaxwell> (or perhaps I'm alone in continuing to use getinfo myself? :) )
 118 2017-07-17T06:16:42  <wumpus> instead of the add a command line argument dance
 119 2017-07-17T06:16:54  <gmaxwell> "nag": "This RPC will be deprecated."
 120 2017-07-17T06:17:21  <wumpus> gmaxwell: I officially stopped using it at least, replaced it with a client-side script that shows more useful information
 121 2017-07-17T06:17:51  <luke-jr> wumpus: +1, maybe even put it in the warnings software already should look at?
 122 2017-07-17T06:18:06  <wumpus> getinfo's output is pretty meh, do you ever lok at anything besides the number of connections or the wallet balance?
 123 2017-07-17T06:18:34  <wumpus> luke-jr: not sure that's a good idea
 124 2017-07-17T06:18:44  <wumpus> luke-jr: it's not part of the node-wide warnings
 125 2017-07-17T06:19:29  <luke-jr> not sure why that'd be a reason not to do it
 126 2017-07-17T06:19:44  <wumpus> because it's a false alarm
 127 2017-07-17T06:19:51  <wumpus> it's not actually an alarm
 128 2017-07-17T06:20:07  <luke-jr> "your software is about to break" isn't? ;)
 129 2017-07-17T06:20:23  <gmaxwell> Connections, block count, balance, warings. And unfortunately, to use seperate rpcs to get this info is three rpcs (four?) and most of them each give a full screen full of information each. :)
 130 2017-07-17T06:20:55  <luke-jr> getblockcount and getbalance are scalars
 131 2017-07-17T06:21:27  <sipa> is there any rpc besides getinfo that actually lists the warning?
 132 2017-07-17T06:21:29  <wumpus> what the hell
 133 2017-07-17T06:21:40  <wumpus> BlueMatt concerned about atomicity in #8843?!
 134 2017-07-17T06:21:41  <gmaxwell> true, though I was using getblockchaininfo and getwalletinfo as replacements.
 135 2017-07-17T06:21:41  <gribble> https://github.com/bitcoin/bitcoin/issues/8843 | rpc: Handle `getinfo` client-side in bitcoin-cli w/ `-getinfo` by laanwj · Pull Request #8843 · bitcoin/bitcoin · GitHub
 136 2017-07-17T06:22:07  <wumpus> I don't...
 137 2017-07-17T06:22:18  <luke-jr> gmaxwell: "don't do that"? :p
 138 2017-07-17T06:22:23  <bitcoin-git> [bitcoin] laanwj closed pull request #8843: rpc: Handle `getinfo` client-side in bitcoin-cli w/ `-getinfo` (master...2016_09_getinfo_clientside) https://github.com/bitcoin/bitcoin/pull/8843
 139 2017-07-17T06:22:35  <wumpus> never mind, going to put this discussion on the backburner, there's more important things to worry about
 140 2017-07-17T06:22:40  <wumpus> what needs to get in today?
 141 2017-07-17T06:23:47  <luke-jr> BIP148, but I assume if the hold-outs on that had changed their mind, they'd say so :/ so probably nothing to do / discuss there
 142 2017-07-17T06:24:13  <wumpus> no no no no no
 143 2017-07-17T06:24:22  <sipa> #10831 would be nice, together with #10830 (which i hope can go in s a bugfix later)
 144 2017-07-17T06:24:23  <gribble> https://github.com/bitcoin/bitcoin/issues/10831 | Batch flushing operations to the walletdb during top up and increase keypool size. by gmaxwell · Pull Request #10831 · bitcoin/bitcoin · GitHub
 145 2017-07-17T06:24:24  <gribble> https://github.com/bitcoin/bitcoin/issues/10830 | [WIP] [wallet] keypool restore by jnewbery · Pull Request #10830 · bitcoin/bitcoin · GitHub
 146 2017-07-17T06:26:30  <wumpus> I'll just maintain my own client-side info scripts, I'm not going to try to introduce convenient info functionality in bitcoin-cli anymore
 147 2017-07-17T06:26:38  <wumpus> this is just too bizarry
 148 2017-07-17T06:26:40  <achow101> re getinfo: can we add something to the errors field warning about it being removed soon
 149 2017-07-17T06:26:49  <luke-jr> wumpus: put it in contrib/?
 150 2017-07-17T06:26:57  <wumpus> luke-jr: no, people can write their own
 151 2017-07-17T06:27:21  <wumpus> luke-jr: would probably get 100 comments again from people that want something slightly differetn
 152 2017-07-17T06:27:30  <wumpus> luke-jr: just tired of it
 153 2017-07-17T06:27:31  <luke-jr> sigh
 154 2017-07-17T06:27:54  <gmaxwell> please don't add things to the errors field.
 155 2017-07-17T06:28:00  <wumpus> that's what I said
 156 2017-07-17T06:28:05  <wumpus> just add an extra 'nag' field or so
 157 2017-07-17T06:28:11  <gmaxwell> yes, that would be okay.
 158 2017-07-17T06:28:37  <wumpus> errors would be a horrible place to add it, because it's not a block chain error
 159 2017-07-17T06:28:43  <sipa> agree
 160 2017-07-17T06:29:08  <sipa> there are more urgent things
 161 2017-07-17T06:29:24  <sipa> #10706 should get review
 162 2017-07-17T06:29:25  <gribble> https://github.com/bitcoin/bitcoin/issues/10706 | Improve wallet fee logic and fix GUI bugs by morcos · Pull Request #10706 · bitcoin/bitcoin · GitHub
 163 2017-07-17T06:30:00  <sipa> and #10829 or #10650
 164 2017-07-17T06:30:02  <gribble> https://github.com/bitcoin/bitcoin/issues/10829 | Simple, backwards compatible RPC multiwallet support. by ryanofsky · Pull Request #10829 · bitcoin/bitcoin · GitHub
 165 2017-07-17T06:30:05  <gribble> https://github.com/bitcoin/bitcoin/issues/10650 | Multiwallet: add RPC endpoint support by jonasschnelli · Pull Request #10650 · bitcoin/bitcoin · GitHub
 166 2017-07-17T06:31:22  <gmaxwell> sipa: I was just finishing testing/reviewing 10706.
 167 2017-07-17T06:31:56  <bitcoin-git> [bitcoin] luke-jr closed pull request #10074: Block size/weight fraud proofs (master...sizefp) https://github.com/bitcoin/bitcoin/pull/10074
 168 2017-07-17T06:47:27  *** Ylbam has joined #bitcoin-core-dev
 169 2017-07-17T06:58:03  *** mmgen has joined #bitcoin-core-dev
 170 2017-07-17T07:10:24  <luke-jr> anyone have anything urgent / must be done before August I can help with for the next hour?
 171 2017-07-17T07:11:44  *** paveljanik has joined #bitcoin-core-dev
 172 2017-07-17T07:26:05  <bitcoin-git> [bitcoin] laanwj pushed 7 new commits to master: https://github.com/bitcoin/bitcoin/compare/bf0a08be281d...6859ad2936bf
 173 2017-07-17T07:26:06  <bitcoin-git> bitcoin/master ecd81df Alex Morcos: Make CoinControl a required argument to CreateTransaction
 174 2017-07-17T07:26:06  <bitcoin-git> bitcoin/master 03ee701 Alex Morcos: Refactor to use CoinControl in GetMinimumFee and FeeBumper...
 175 2017-07-17T07:26:07  <bitcoin-git> bitcoin/master 1983ca6 Alex Morcos: Use CoinControl to pass custom fee setting from QT....
 176 2017-07-17T07:26:28  <bitcoin-git> [bitcoin] laanwj closed pull request #10706: Improve wallet fee logic and fix GUI bugs (master...improveWalletFeeLogic) https://github.com/bitcoin/bitcoin/pull/10706
 177 2017-07-17T07:26:53  *** coredump_ has quit IRC
 178 2017-07-17T07:30:08  <wumpus> anyone opposed to adding #10829 as a last-ditch try to still have RPC multiwallet support in 0.15?
 179 2017-07-17T07:30:10  <gribble> https://github.com/bitcoin/bitcoin/issues/10829 | Simple, backwards compatible RPC multiwallet support. by ryanofsky · Pull Request #10829 · bitcoin/bitcoin · GitHub
 180 2017-07-17T07:30:46  <wumpus> it is simple to review at least
 181 2017-07-17T07:34:12  <gmaxwell> I support it.
 182 2017-07-17T07:39:16  *** Evel-Knievel has quit IRC
 183 2017-07-17T07:41:22  *** promag has joined #bitcoin-core-dev
 184 2017-07-17T07:41:52  *** promag1 has joined #bitcoin-core-dev
 185 2017-07-17T07:43:08  *** Walter2 has joined #bitcoin-core-dev
 186 2017-07-17T07:49:58  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/6859ad2936bf...91edda8f3c81
 187 2017-07-17T07:49:58  <bitcoin-git> bitcoin/master 1cc251f Patrick Strateman: Explicitly search for bdb5.3....
 188 2017-07-17T07:49:59  <bitcoin-git> bitcoin/master 91edda8 Wladimir J. van der Laan: Merge #10803: Explicitly search for bdb5.3....
 189 2017-07-17T07:50:20  *** Evel-Knievel has joined #bitcoin-core-dev
 190 2017-07-17T07:50:25  <bitcoin-git> [bitcoin] laanwj closed pull request #10803: Explicitly search for bdb5.3. (master...2017-07-02-bdb5.3) https://github.com/bitcoin/bitcoin/pull/10803
 191 2017-07-17T07:52:10  *** BashCo has quit IRC
 192 2017-07-17T07:54:20  <gmaxwell> so on #10831  I'm ambivlent to the performance improvement; I created the PR because I understood that performance issue to be a blocker for increasing the default keypool size, which I think is really important to get out due to bad interactions with hd wallet and rescan.
 193 2017-07-17T07:54:21  <gribble> https://github.com/bitcoin/bitcoin/issues/10831 | Batch flushing operations to the walletdb during top up and increase keypool size. by gmaxwell · Pull Request #10831 · bitcoin/bitcoin · GitHub
 194 2017-07-17T07:55:21  <luke-jr> we should probably just do keypool in the background..?
 195 2017-07-17T07:55:49  <bitcoin-git> [bitcoin] practicalswift closed pull request #10847: Enable devirtualization opportunities by using the final specifier (C++11) (master...devirtualization) https://github.com/bitcoin/bitcoin/pull/10847
 196 2017-07-17T07:56:12  <wumpus> well, performance improvement or not, doing the keypool top-up in a single db transaction makes sense
 197 2017-07-17T07:56:54  <luke-jr> doing it in a single dbtx would necessitate blocking on it, though, no?
 198 2017-07-17T07:57:07  <sipa> ?
 199 2017-07-17T07:57:08  <luke-jr> at least before any of the keys can be used
 200 2017-07-17T07:57:08  <wumpus> especially on VMs with slow sync (most of them), it's super slow as it is right now
 201 2017-07-17T07:57:19  <wumpus> blocking on *what*? key generation is so fast
 202 2017-07-17T07:57:57  <sipa> if it weren't for db syncing, we can generate 10000 per second or so
 203 2017-07-17T07:58:04  <wumpus> the only reason it takes noticable time right now is because of the sync per key
 204 2017-07-17T07:58:08  <gmaxwell> luke-jr: the topup is already a single operation that holds the relevant locks the whole time.
 205 2017-07-17T07:58:09  <luke-jr> i c
 206 2017-07-17T07:58:31  <luke-jr> gmaxwell: yes, I was thinking we shouldn't do that, but otoh, if this is so much of a gain, maybe it doesn't matter
 207 2017-07-17T07:58:48  <wumpus> it's only done once anyhow!
 208 2017-07-17T07:58:49  <gmaxwell> sipa: well not quite that fast, the code paths it goes through per key are very twisty and inefficient, and we aren't multithreaded for it, and we do validate after create. :)
 209 2017-07-17T07:59:01  <wumpus> (at least, so much at once)
 210 2017-07-17T07:59:03  <gmaxwell> but thousands per second sure.
 211 2017-07-17T08:00:00  <wumpus> keypool generation happens a lot during testing though, so #10831 is going to speed up testing
 212 2017-07-17T08:00:01  <gribble> https://github.com/bitcoin/bitcoin/issues/10831 | Batch flushing operations to the walletdb during top up and increase keypool size. by gmaxwell · Pull Request #10831 · bitcoin/bitcoin · GitHub
 213 2017-07-17T08:00:44  <wumpus> (euh.. it would at least if if the number of keys generated stayed the same)
 214 2017-07-17T08:00:48  <gmaxwell> luke-jr: if someone really cared, they could make topup run in batches of no more than X to reduce worst case blocking, it would be a couple lines improvement probably.
 215 2017-07-17T08:01:02  <gmaxwell> wumpus: it'll be faster even with the 1000 size increase, esp on things with slow IO.
 216 2017-07-17T08:01:13  <wumpus> ah yes it's 1000, yes srue
 217 2017-07-17T08:01:27  <wumpus> does it still log a line for every key?
 218 2017-07-17T08:01:32  <wumpus> probably want to get rid of that too
 219 2017-07-17T08:01:33  <luke-jr> well, if it's so fast, it doesn't matter
 220 2017-07-17T08:01:39  <gmaxwell> yes.
 221 2017-07-17T08:01:46  <luke-jr> "added N keys to keypool" ☺
 222 2017-07-17T08:02:05  *** promag1 has quit IRC
 223 2017-07-17T08:03:55  <gmaxwell> instagibbs reported for 1000 keys (new default) on his presumably SSD equipmt system it went from 20 second to 1.6. so I expect it's still a 20% speedup. We could in the future make many of the tests turn their keypool sizes down to speed them up further.
 224 2017-07-17T08:05:17  <gmaxwell> it would be a trivial (2 loc-ish) change to make it log only one line in the topup.
 225 2017-07-17T08:06:08  <wumpus> should certainly do that, I've always found the per-key message annoying during first run, and it's 10 times as annoying now :)
 226 2017-07-17T08:06:13  <gmaxwell> as in, remove the current line, re-add it two below using the missingInternal missingExternal variables as the count.
 227 2017-07-17T08:06:24  <gmaxwell> okay, should I just add another commit that does that to my PR?
 228 2017-07-17T08:06:29  <sipa> ack
 229 2017-07-17T08:06:56  <wumpus> remove the current line, or move it to debug category if someone theoretically could be interested while troubleshooting
 230 2017-07-17T08:07:25  <gmaxwell> I can't see the reason, it conveys no useful information that the summary wouldn't have.
 231 2017-07-17T08:07:40  <wumpus> agree
 232 2017-07-17T08:08:43  <gmaxwell> and yes, the old one annoyed me too. though leveldb logging with debug on has made me blind to log annoyances... (funny, I did that nice bitfield thing and I don't use it to deactivate leveldb)
 233 2017-07-17T08:09:35  <wumpus> heh yes that's kind of what it was meant for
 234 2017-07-17T08:10:30  <wumpus> though now that it's possible to enable/disable debug bits at runtime, I don't enable any by default anymore
 235 2017-07-17T08:11:01  <wumpus> well, bench. That one is nice.
 236 2017-07-17T08:11:02  *** Walter2 has quit IRC
 237 2017-07-17T08:17:29  <gmaxwell> pushed, not yet tested because it'll take me a half hour to compile it.
 238 2017-07-17T08:19:41  *** BashCo has joined #bitcoin-core-dev
 239 2017-07-17T08:23:48  <wumpus> I can test np
 240 2017-07-17T08:24:56  <gmaxwell> I will test, just... when the build finishes.
 241 2017-07-17T08:25:29  <wumpus> half an hour for a single-line change, did you change to rpi for builds? :-)
 242 2017-07-17T08:26:47  <gmaxwell> wumpus: my laptop is slow, and I've switched trees, so its recompiling all the things.
 243 2017-07-17T08:34:47  *** timothy has joined #bitcoin-core-dev
 244 2017-07-17T08:41:36  <wumpus> ccache can help with that a lot
 245 2017-07-17T08:43:22  <gmaxwell> 2017-07-17 08:42:25 keypool added 2000 keys (1000 internal), size=2000 (1000 internal)
 246 2017-07-17T08:43:25  <wumpus> though, you need to set the cache size high to survive tree switches
 247 2017-07-17T08:43:41  <gmaxwell> yes, and with a full blockchain on a 256GB disk, I can't do that. :(
 248 2017-07-17T08:44:13  <gmaxwell> okay, only took me 25 minutes.
 249 2017-07-17T08:44:22  * wumpus wonders how well lzo compression fs will work for ccache objects
 250 2017-07-17T08:44:47  *** harrymm has quit IRC
 251 2017-07-17T08:45:18  <wumpus> 2017-07-17 08:45:03 Performing wallet upgrade to 60000
 252 2017-07-17T08:45:18  <wumpus> 2017-07-17 08:45:05 keypool added 2000 keys (1000 internal), size=2000 (1000 internal)
 253 2017-07-17T08:45:21  <wumpus> two seconds woohoo
 254 2017-07-17T08:45:56  <gmaxwell> yea, thats still pretty slow considering how fast the underlying crypto is... but fast enough.
 255 2017-07-17T08:52:14  <wumpus> well it's short enough not to be noticable in the overall process, could always be optimzied further if anyone cares
 256 2017-07-17T08:52:46  <gmaxwell> if we later change it to 10k it might be worth it.
 257 2017-07-17T08:53:20  <wumpus> 184s for 10k keys here, yea that's definitely too slow
 258 2017-07-17T08:53:33  <wumpus> sorry - 100k keys
 259 2017-07-17T08:54:06  <wumpus> but 18.4 seconds would also be too slow
 260 2017-07-17T08:54:46  <gmaxwell> it could also be broken up and run in the background, I didn't push for 10k for a different reason: bloats up the wallet currently.
 261 2017-07-17T08:55:01  <gmaxwell> esp if you use encryption and immediately mark all the keys you just generated as used.
 262 2017-07-17T08:55:01  <wumpus> then again you had a good point about the encryption
 263 2017-07-17T08:55:04  <wumpus> yes
 264 2017-07-17T08:55:42  <gmaxwell> but we can fix this later by not even creating the wallet until you do something like hit getnewaddress or do encryption.
 265 2017-07-17T08:55:51  <wumpus> there could be some kind of shortcut - if you *never* dealt out a key before encrypting
 266 2017-07-17T08:56:05  <wumpus> then it could just start over with an encrypted wallet
 267 2017-07-17T08:56:24  <gmaxwell> or that.. and also, by using smaller records for keypool entries.
 268 2017-07-17T08:56:38  <wumpus> for multiwallet it'd also be nice to be able to create wallets in encrypted mode
 269 2017-07-17T08:57:26  <wumpus> yes
 270 2017-07-17T08:57:58  *** promag has joined #bitcoin-core-dev
 271 2017-07-17T08:59:56  *** harrymm has joined #bitcoin-core-dev
 272 2017-07-17T09:05:55  <gmaxwell> I think we should generally consider defered init of the wallet because it would allow us to better integrate mandatory backup/recovery.
 273 2017-07-17T09:07:07  <gmaxwell> e.g. in the GUI at least you don't do a wallet unless you complete a series of slightly paternalistic steps that make it likely you actually got some kind of backup.
 274 2017-07-17T09:07:53  <gmaxwell> so: starting with no wallet, and any effort to get an address prompts you to make one, along with a backup of some form.
 275 2017-07-17T09:28:58  *** ivan has quit IRC
 276 2017-07-17T09:53:02  *** Dyaheon has quit IRC
 277 2017-07-17T09:54:15  *** Dyaheon has joined #bitcoin-core-dev
 278 2017-07-17T10:08:17  <morcos> wumpus thanks for merging 10706.  The last thing I want to nag about is #10707.  It hasn't gotten much review b/c it was dependent on 10706, but its not big.  I think its important in terms of finalizing estimatesmartfee API now that it is no longer marked unstable.  Not sure if you feel the cutoff for it is today.
 279 2017-07-17T10:08:19  <gribble> https://github.com/bitcoin/bitcoin/issues/10707 | Better API for estimatesmartfee RPC by morcos · Pull Request #10707 · bitcoin/bitcoin · GitHub
 280 2017-07-17T10:09:17  <morcos> #10817 would be nice (and isn't yet tagged 0.15) but isn't critical, and so far I haven't heard anyone other than gmaxwell and I's opinion on it.
 281 2017-07-17T10:09:18  <gribble> https://github.com/bitcoin/bitcoin/issues/10817 | Add a discard_rate to avoid small change by morcos · Pull Request #10817 · bitcoin/bitcoin · GitHub
 282 2017-07-17T10:14:48  <bitcoin-git> [bitcoin] jonasschnelli opened pull request #10849: Multiwallet: simplest endpoint support (master...2017/07/mw_endpoint_simple) https://github.com/bitcoin/bitcoin/pull/10849
 283 2017-07-17T10:18:14  <gmaxwell> morcos:  I would not for 10817 that the definition used there is a bit different then the one were thinking of using for the exact matching hurestic, because the dust threshold has a *3 in it.
 284 2017-07-17T10:19:12  <gmaxwell> I think thats okay, but its slightly less of a no-brainer than the factor of one hurestic (where the output is worthless at the long term feerate).
 285 2017-07-17T10:24:36  <morcos> gmaxwell: Yeah I argued a release ago we should remove the *3 from the definition of dust and correspondingly change the dust rate to 3 sat/B .  It would make more sense to talk about everything like that.
 286 2017-07-17T10:25:33  <gmaxwell> morcos: I would agree with that change, makes a lot of sense.
 287 2017-07-17T10:25:59  <gmaxwell> if you make a commit that does that, fix the comment in IsDust which just seems to be inexplicable.
 288 2017-07-17T10:26:29  <gmaxwell> (there is no integer you can multiply 148 by to get 546)
 289 2017-07-17T10:26:34  <morcos> still want to try to do that for 0.15?  or forget it for now
 290 2017-07-17T10:26:58  <morcos> heh!
 291 2017-07-17T10:27:12  <gmaxwell> Well I think you should put it in 10817, other than the 10817 behavior it's a no-op
 292 2017-07-17T10:27:13  <morcos> not forget, but postpone
 293 2017-07-17T10:27:25  <morcos> ok
 294 2017-07-17T10:27:52  <gmaxwell> I'd like to get it in 0.15, but wladimir's call. I think the PR would be better with it, esp as it makes it even a more benign change.
 295 2017-07-17T10:28:34  <gmaxwell> (also, I don't really think we have any other utxo bloat reducers in this release; gotta meet quota)
 296 2017-07-17T10:28:48  <morcos> But then you would make the discard rate still 5 sat/B or you'd make it higher
 297 2017-07-17T10:28:57  <gmaxwell> morcos: the 3x in there was due to the original somewhat stupid formulation that tied it to minimum relay fee.
 298 2017-07-17T10:29:05  <morcos> in the PR I gave the long term fee estimation rate can only serve to LOWER the discard rate
 299 2017-07-17T10:29:08  <morcos> it is not a max
 300 2017-07-17T10:29:34  <morcos> I think it is dangerous to use the existing long term fee estimation rate as a discard rate
 301 2017-07-17T10:29:41  <morcos> it got as high as 100 sat/B a couple months ago
 302 2017-07-17T10:30:16  <gmaxwell> Could be argued that leaving it at 5 is just more conservative and better than not having the feature.
 303 2017-07-17T10:31:13  <gmaxwell> 5 means the threshold is about at 1.5 cents at the current prices.
 304 2017-07-17T10:31:44  <morcos> it seems not worth the complication to increase the discard rate from the preexisting 3 sat/B b/c of dust to 5
 305 2017-07-17T10:31:49  <morcos> from 3 to 15 then yes
 306 2017-07-17T10:32:37  <morcos> and i think the fact that it gets MIN'ed with long term fee estimation makes me not worry too much that the 15 will end up biting people in the ass later.  (also it's configurable)
 307 2017-07-17T10:33:05  <gmaxwell> Yes, that also sounds fine to me.
 308 2017-07-17T10:33:38  <morcos> only other question is it's a bit dicey to change the definition of a command line argument like dustrelayfee, but in this case it's a hidden argument that i doubt anyone specified, so its probably ok.
 309 2017-07-17T10:33:51  <morcos> but thats more reason to do it now while it's only been out for one release
 310 2017-07-17T10:34:48  <gmaxwell> it's also good to get this in because the exact matcher code should signficantly increase the number of cases where this happens, so if people are gonna squak about the wallet throwing away a few more cents to avoid change it'll be good to hear about it.
 311 2017-07-17T10:35:18  <morcos> gmaxwell: 546 = 3 * (148 + 34)
 312 2017-07-17T10:35:22  *** Guyver2 has joined #bitcoin-core-dev
 313 2017-07-17T10:36:17  <gmaxwell> ah thats where it comes from; it's including the txout itself.
 314 2017-07-17T10:40:26  *** AaronvanW has joined #bitcoin-core-dev
 315 2017-07-17T10:43:27  *** promag has quit IRC
 316 2017-07-17T10:43:39  *** goatpig has joined #bitcoin-core-dev
 317 2017-07-17T10:47:05  *** rockhouse has quit IRC
 318 2017-07-17T10:52:48  *** promag has joined #bitcoin-core-dev
 319 2017-07-17T11:06:29  *** Lorena has joined #bitcoin-core-dev
 320 2017-07-17T11:12:13  *** BashCo has quit IRC
 321 2017-07-17T11:12:49  *** BashCo has joined #bitcoin-core-dev
 322 2017-07-17T11:15:53  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/91edda8f3c81...8bc6d1f179a0
 323 2017-07-17T11:15:53  <bitcoin-git> bitcoin/master a8ae0b2 Dag Robole: Fix resource leak
 324 2017-07-17T11:15:54  <bitcoin-git> bitcoin/master 8bc6d1f Wladimir J. van der Laan: Merge #10837: Fix resource leak on error in GetDevURandom...
 325 2017-07-17T11:16:33  <bitcoin-git> [bitcoin] laanwj closed pull request #10837: Fix resource leak on error in GetDevURandom (master...20170715-fix-leak-1) https://github.com/bitcoin/bitcoin/pull/10837
 326 2017-07-17T11:20:39  <morcos> gmaxwell: ok updated 10817 and reduced the discard rate from 15 to 10
 327 2017-07-17T11:39:05  *** harrymm has quit IRC
 328 2017-07-17T11:49:51  <luke-jr> wumpus: hmm, what about ;wallet=abc (path segment parameter)?
 329 2017-07-17T11:49:58  <wumpus> :-(
 330 2017-07-17T11:50:22  * luke-jr wonders if anything actually uses that part of the spec
 331 2017-07-17T11:50:22  <wumpus> let's pile up even more alternatives
 332 2017-07-17T11:50:33  <wumpus> heh I wonder too
 333 2017-07-17T11:50:38  <luke-jr> wumpus: well, it doesn't have the issue you were concerned with
 334 2017-07-17T11:50:58  <wumpus> maybe we should do something really obscure so that at least no one is happy with it either :p
 335 2017-07-17T11:51:23  <luke-jr> custom HTTP header?
 336 2017-07-17T11:51:34  <wumpus> :-)
 337 2017-07-17T11:51:49  <luke-jr> although that's not so obscure :/
 338 2017-07-17T11:51:56  <wumpus> or a custom field in the JSON-RPC outer structure
 339 2017-07-17T11:52:03  <luke-jr> let's encode it in the Accept header!
 340 2017-07-17T11:52:17  <wumpus> or in the user agent
 341 2017-07-17T11:52:24  <luke-jr> lol
 342 2017-07-17T11:52:25  <jonasschnelli> :/
 343 2017-07-17T11:52:42  <jonasschnelli> lets use sessions and states ... *duck*
 344 2017-07-17T11:52:52  <luke-jr> oooh perfect
 345 2017-07-17T11:53:08  <luke-jr> that would actually be useful for other stuff too
 346 2017-07-17T11:53:36  <luke-jr> historically anyway, maybe not post-named params
 347 2017-07-17T11:53:41  <jonasschnelli> Yes. Would be useful to lose all your coins.. :)
 348 2017-07-17T11:53:42  <jonasschnelli> *loose
 349 2017-07-17T11:53:47  <luke-jr> (I'm thinking settxfee)
 350 2017-07-17T11:53:59  <wumpus> how would that lose coins - store private keys in a session identifier?
 351 2017-07-17T11:54:19  <luke-jr> sounds like bc.i
 352 2017-07-17T11:54:36  <wumpus> "sorry, your session expired" but isntead of losing that long mail, you lose all your coins
 353 2017-07-17T11:54:38  <jonasschnelli> You may loose them because your session with "the other" wallet is still active...
 354 2017-07-17T11:54:48  <jonasschnelli> Though loosing may not directly be possible..
 355 2017-07-17T11:54:52  <jonasschnelli> But sessions is the worst for APIS
 356 2017-07-17T11:55:30  <wumpus> I'm sure someone somewhere thinks it's a good idea
 357 2017-07-17T11:55:55  <jonasschnelli> hehe
 358 2017-07-17T11:55:57  <jonasschnelli> Me too
 359 2017-07-17T11:56:06  <luke-jr> Coinbase
 360 2017-07-17T11:56:23  <jonasschnelli> Does their API work keep state in sessions?
 361 2017-07-17T11:56:25  <luke-jr> OAuth2 is kinda inherently session-based tho.
 362 2017-07-17T11:56:39  <luke-jr> not state, I think
 363 2017-07-17T11:56:43  <jonasschnelli> For Auth, header fields are better IMO.
 364 2017-07-17T11:56:58  *** harrymm has joined #bitcoin-core-dev
 365 2017-07-17T11:57:02  <jonasschnelli> Bitpays stuff is pretty nice (ECDSA auth via signature of post in header)
 366 2017-07-17T11:57:06  <luke-jr> couldn't do session-less for OAuth2's use case
 367 2017-07-17T11:57:22  <jonasschnelli> Just sign each request
 368 2017-07-17T11:57:28  <luke-jr> because the user is authenticating, and the app is just accessing that session
 369 2017-07-17T11:57:41  <jonasschnelli> And add an upcounting nonce
 370 2017-07-17T11:57:59  <luke-jr> jonasschnelli: the authenticator is not the API-accessor
 371 2017-07-17T11:58:13  <jonasschnelli> OAuth, yeah
 372 2017-07-17T12:01:12  <gmaxwell> the bitpay auth scheme is insecure. IIRC, has not anti-replay nonce
 373 2017-07-17T12:02:08  <gmaxwell> s/not/no/
 374 2017-07-17T12:03:58  <morcos> settxfee needs to go away
 375 2017-07-17T12:04:17  <morcos> we're getting close to being able to just do it on a per rpc call
 376 2017-07-17T12:04:25  <jonasschnelli> gmaxwell: Indeed
 377 2017-07-17T12:04:34  <luke-jr> morcos: probably replacing it with sessions isn't the way though :p
 378 2017-07-17T12:06:34  *** Ch4rlesM4ck4y has joined #bitcoin-core-dev
 379 2017-07-17T12:08:06  *** Ch4rlesM4ck4y has left #bitcoin-core-dev
 380 2017-07-17T12:34:28  *** blznblzn2 has joined #bitcoin-core-dev
 381 2017-07-17T12:46:33  *** RoyceX has joined #bitcoin-core-dev
 382 2017-07-17T12:50:01  *** cheese_ has quit IRC
 383 2017-07-17T12:51:54  *** blznblzn2 has quit IRC
 384 2017-07-17T13:06:06  <wumpus> <morcos> settxfee needs to go away <- yes please
 385 2017-07-17T13:06:28  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/8bc6d1f179a0...2b0179d8a9b7
 386 2017-07-17T13:06:29  <bitcoin-git> bitcoin/master e061d8d practicalswift: Remove declaration of unused function: void UpdatedTransaction(const uint256 &)
 387 2017-07-17T13:06:29  <bitcoin-git> bitcoin/master 2b0179d MarcoFalke: Merge #10834: Remove declaration of unused method: void UpdatedTransaction(const uint256 &)...
 388 2017-07-17T13:06:58  <bitcoin-git> [bitcoin] MarcoFalke closed pull request #10834: Remove declaration of unused method: void UpdatedTransaction(const uint256 &) (master...remove-UpdatedTransaction) https://github.com/bitcoin/bitcoin/pull/10834
 389 2017-07-17T13:07:35  <wumpus> happy that we're moving to an API where all the important things can be set per transaction, so that different callers don't have to worry about messing up each other's global state
 390 2017-07-17T13:11:21  <promag> wumpus: remove https://github.com/bitcoin/bitcoin/pull/10650 from project 8?
 391 2017-07-17T13:12:31  <wumpus> only 3 things in project 8 anyhow - maybe we should clean it out for now, and use the 0.15 milestone list instead
 392 2017-07-17T13:12:42  <wumpus> (it's what I'm doing at least)
 393 2017-07-17T13:13:02  <wumpus> (one thing now)
 394 2017-07-17T13:13:39  *** CubicEarth has joined #bitcoin-core-dev
 395 2017-07-17T13:28:31  *** Dyaheon has quit IRC
 396 2017-07-17T13:31:30  <jonasschnelli> CodeShark: have you started to work on client side filtering after roasbeef's specs?
 397 2017-07-17T13:31:33  *** Dyaheon has joined #bitcoin-core-dev
 398 2017-07-17T13:39:19  *** CubicEarth has quit IRC
 399 2017-07-17T13:42:12  <jnewbery> Chris_Stewart_5: to get all blocks and transactions to propagate, try BitcoinTestFramework.sync_all()
 400 2017-07-17T13:42:30  <jnewbery> wumpus gmaxwell: for getinfo, "nag": "This RPC will be deprecated." will be silently dropped by any clients that are picking individual fields from getinfo.
 401 2017-07-17T13:42:33  <jnewbery> Hiding getinfo behind a flag for one version *forces* users to acknowledge that the RPC is being deprecated (and gives them one release grace period to fix their scripts/whatever that is using getinfo)
 402 2017-07-17T13:42:56  <jnewbery> wumpus: > keypool generation happens a lot during testing though
 403 2017-07-17T13:42:57  <jnewbery> unit testing or functional testing? Default keypool size in the functional tests is 1 (https://github.com/bitcoin/bitcoin/blob/master/test/functional/test_framework/test_framework.py#L212)
 404 2017-07-17T13:44:42  <wumpus> jnewbery: didn't know that the keypool size was overridden for testing, so in that case this doesn't help testing become faster, well too bad :)
 405 2017-07-17T13:45:02  <wumpus> jnewbery: yes, we can do the other thing for 0.16, just too late to make such a change for 0.15
 406 2017-07-17T13:45:14  <wumpus> jnewbery: I honestly don't understand why this comes up on the last day before feature freeze
 407 2017-07-17T13:50:35  <jnewbery> I agree, it's late. But hiding getinfo behind a flag in v0.16 => removing in 0.17. getinfo is one of the bitcoin_server -> bitcoin_wallet dependencies. I was hoping we'd be able to remove all of those for 0.16
 408 2017-07-17T13:53:10  <wumpus> sure, but couldn't you have brought it up a few weeks earlier?
 409 2017-07-17T13:53:58  <gmaxwell> I'd still complain that we haven't dogfooded it enough.
 410 2017-07-17T13:55:16  <wumpus> we could just remove the wallet balance from there
 411 2017-07-17T13:55:29  <gmaxwell> I wouldn't complain about that.
 412 2017-07-17T13:55:33  <wumpus> it makes no sense with multiwallet anyway
 413 2017-07-17T13:56:19  <wumpus> then again, that doesn't need to be done last-minute for 0.15, the circular dependency won't be solved before then anyhow
 414 2017-07-17T13:56:42  <wumpus> but let's say it's the last thing holding back solving the build dependency, we could do that
 415 2017-07-17T13:57:19  <wumpus> I still think adding the nag: makes sense, most people using getinfo will likely use it from the command line
 416 2017-07-17T13:57:38  <gmaxwell> even if they don't use it always that way, it's more visible than even release notes.
 417 2017-07-17T13:57:49  <wumpus> yes it would be in addition to release notes, not instead
 418 2017-07-17T13:57:50  <gmaxwell> and we've mentioned it in release notes before (I think, I hope)
 419 2017-07-17T13:57:55  <wumpus> yes, we did
 420 2017-07-17T13:58:12  <wumpus> even with the new places where everything could be found
 421 2017-07-17T13:58:36  <wumpus> https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-0.14.0.md#getinfo-deprecated
 422 2017-07-17T13:59:55  <wumpus> I don't know why we waited for 0.14 before doing that
 423 2017-07-17T14:04:28  <BlueMatt> yeesh y'all been busy this morning
 424 2017-07-17T14:04:37  <wumpus> anyhow as it was deprecated in 0.14 (the deprecation message in the help was even backported to 0.13.1), removing it completely in 0.16 should be fine
 425 2017-07-17T14:04:55  <BlueMatt> wumpus: I mean its not a strong concern, really, I pointed it out cause it would be a problem for automated users (which I hope are mostly not calling -cli)
 426 2017-07-17T14:05:51  <wumpus> BlueMatt: yes, the -cli change would mostly be for command line users, but now agree we shouldn't do that, external stats/info scripts should be external
 427 2017-07-17T14:06:27  <BlueMatt> well i was more curious to find out what the demand for it was (re: the "IRC discussion" referenced in that pr)
 428 2017-07-17T14:06:29  <wumpus> and -cli should be a minimal, dumb client utiltiy
 429 2017-07-17T14:06:37  <gmaxwell> I think we'll have to do ~something~ but the best way to find that and get it done is just to live with it for a while.
 430 2017-07-17T14:08:25  <wumpus> maybe some example of a stats script? I don't know - generally, those things have gone unmaintained fast, as they're personal, everyone is interested in different info
 431 2017-07-17T14:08:48  *** CubicEarth has joined #bitcoin-core-dev
 432 2017-07-17T14:09:32  <wumpus> there is also such a low threshold to writing them
 433 2017-07-17T14:10:13  <gmaxwell> connection count + height + errors is pretty universal; and is a bit obnoxious from the cli in our post getinfo world.
 434 2017-07-17T14:11:08  <jnewbery> > couldn't you have brought it up a few weeks earlier?
 435 2017-07-17T14:11:22  <wumpus> well for example personally I'm not interested in totai connection count - my script shows in/out versus ipv4/ipv6/tor
 436 2017-07-17T14:11:48  <jnewbery> I brought it up in response to #10841. I thought it would be friendlier to hide the RPC behind a flag before removing it one release later
 437 2017-07-17T14:11:50  <gribble> https://github.com/bitcoin/bitcoin/issues/10841 | [rpc] Give users one final warning before removing getinfo by jnewbery · Pull Request #10841 · bitcoin/bitcoin · GitHub
 438 2017-07-17T14:12:07  <wumpus> this is much more useful to troubleshoot any connectivity issues than the total number
 439 2017-07-17T14:12:18  <jnewbery> sorry, in response to #10838
 440 2017-07-17T14:12:19  <gribble> https://github.com/bitcoin/bitcoin/issues/10838 | (finally) remove the longest-ever-deprecated RPC call getinfo by TheBlueMatt · Pull Request #10838 · bitcoin/bitcoin · GitHub
 441 2017-07-17T14:12:36  <gmaxwell> wumpus: the normal thing I'm interested in is 0/8/many. seperate in/out counts would be interesting. From a cli perspective there are a number of other interesting things to show; e.g. best block hash, without getting into those huge info dumps like getblockchaininfo.
 442 2017-07-17T14:12:37  * BlueMatt has 7 4k monitors full of stats monitoring scripts...anyone need some?
 443 2017-07-17T14:12:55  <wumpus> jnewbery: sure! BlueMatt was the original wtf 'why do you bring this up now', you tried to do a friendlier version, which is why I tagged that one
 444 2017-07-17T14:12:57  <jnewbery> If we're going to remove getinfo in v0.16, I suggest I close #10841
 445 2017-07-17T14:12:58  <gribble> https://github.com/bitcoin/bitcoin/issues/10841 | [rpc] Give users one final warning before removing getinfo by jnewbery · Pull Request #10841 · bitcoin/bitcoin · GitHub
 446 2017-07-17T14:13:18  <wumpus> jnewbery: but I stil think it is too much for such a late change
 447 2017-07-17T14:13:48  <wumpus> gmaxwell: exactly, none of which getinfo currently does, it's been frozen for years (on purpose)
 448 2017-07-17T14:14:00  * BlueMatt had assumed it had been longer-deprecated, so figured it could just be removed, when it was pointed out that it was only deprecated in 14 (damn it) i withdrew, but making the deprecation more explicit is nice
 449 2017-07-17T14:14:10  <BlueMatt> i guess it doesnt matter much, though
 450 2017-07-17T14:14:25  <jnewbery> Yeah, doesn't matter too much. I'll close 10841.
 451 2017-07-17T14:14:30  <wumpus> we should have mentioned it in the release notes much earlier
 452 2017-07-17T14:14:48  <wumpus> jnewbery: I still think it makes sense to add a 'nag': to the result with your message, but anyhow
 453 2017-07-17T14:14:48  <gmaxwell> wumpus: I would have log ago proposed a 'status' rpc, but feared that the response would be "omg not another getinfo!"
 454 2017-07-17T14:15:10  <wumpus> gmaxwell: yes we're definitely not going to have any new server side call like that, that spans subsystems
 455 2017-07-17T14:15:22  <jnewbery> yeah, adding a "nag" field does no harm
 456 2017-07-17T14:15:37  <wumpus> client-side would have been ok with me, but runs into too much opposition, so we';re not going to do that either
 457 2017-07-17T14:15:45  <bitcoin-git> [bitcoin] jnewbery closed pull request #10841: [rpc] Give users one final warning before removing getinfo (master...deprecate_getinfo) https://github.com/bitcoin/bitcoin/pull/10841
 458 2017-07-17T14:16:47  <gmaxwell> wumpus: if it didn't span into the wallet, but was just blockchain stats and p2p stats?
 459 2017-07-17T14:17:33  <wumpus> gmaxwell: I don't think that's a good idea, no
 460 2017-07-17T14:17:41  <gmaxwell> I figured.
 461 2017-07-17T14:17:56  <wumpus> could potentially create another dependency in the future that will be so hard to get rid of
 462 2017-07-17T14:18:15  <wumpus> if getting rid of getinfo would have been easier, I would have thought differently about it, but this keeps haunting us forever
 463 2017-07-17T14:18:34  <gmaxwell> well, we have to do something. I don't pretend to know what. But having to run multiple commands just to get the most basic of health information, is a real burden for support.
 464 2017-07-17T14:18:58  <BlueMatt> can we call #10526 a fix for a performance regression (really, disk space usage regression) and tag it 15 and merge it later this week?
 465 2017-07-17T14:18:59  <gribble> https://github.com/bitcoin/bitcoin/issues/10526 | Force on-the-fly compaction during pertxout upgrade by sipa · Pull Request #10526 · bitcoin/bitcoin · GitHub
 466 2017-07-17T14:19:04  <wumpus> then do something: write a useful script taht collects that information, submit it as PR
 467 2017-07-17T14:19:06  <wumpus> I TRIED
 468 2017-07-17T14:19:19  <gmaxwell> I think we haven't gotten rid of it because we haven't replaced it for anything but programmatic users who care little about how many calls they make or how many pages of uninteresting data they toss.
 469 2017-07-17T14:19:31  <wumpus> I just mistakingly made it part of -cli
 470 2017-07-17T14:19:49  <gmaxwell> wumpus: I know. Though I admit I have mixed feelings about cli being anything but a dumb client too. I am not yelling at you.
 471 2017-07-17T14:19:57  <gmaxwell> you did great.
 472 2017-07-17T14:20:22  <gmaxwell> BlueMatt: I believe we were waiting on feedback from wumpus to determine if there actually was a need there.
 473 2017-07-17T14:20:38  <wumpus> things that don't have to be done server side don't need to be done server side, this is the same reason I argue against #10804
 474 2017-07-17T14:20:40  <gribble> https://github.com/bitcoin/bitcoin/issues/10804 | Add histunspent RPC by promag · Pull Request #10804 · bitcoin/bitcoin · GitHub
 475 2017-07-17T14:20:53  <wumpus> client side has the information, so can roll the statistics and display them in any way
 476 2017-07-17T14:21:01  <gmaxwell> yes, I also saw 10804 and thought that.
 477 2017-07-17T14:21:02  <wumpus> the RPC interface doesn't have to acoomodate end users specifics
 478 2017-07-17T14:21:27  <gmaxwell> then our issue is that we just don't have a cli interface, except we have a highly used cli interface.
 479 2017-07-17T14:21:30  <gmaxwell> :)
 480 2017-07-17T14:21:56  <gmaxwell> BlueMatt: there was some question about the state of the node in question where he saw the not good results.
 481 2017-07-17T14:21:59  <wumpus> the same problem we had in 2012, and have had extensive discussions about since then, and no one is making that tool it seems
 482 2017-07-17T14:22:14  <wumpus> which I understand, I'm certainly not going to do it, too many opinions about it, I only write simple utility scripts for myself :)
 483 2017-07-17T14:22:18  <BlueMatt> wumpus: hmm, ok, now I understand the desire, thanks, yea thanks for making that pr. would be nice to just make it a bash script, but sadly fucking json :(
 484 2017-07-17T14:23:10  <wumpus> BlueMatt: it's trivial in python though
 485 2017-07-17T14:23:20  <gmaxwell> rename bitcoin-cli bitcoin-rpc and we create a real bitcoin-cli ? :P
 486 2017-07-17T14:23:21  <BlueMatt> true
 487 2017-07-17T14:23:24  <BlueMatt> lol
 488 2017-07-17T14:23:39  <mmgen> Just adding my two bits here: how about creating an addition cli command that aggregates info from various RPC calls and presents it in a readable way?
 489 2017-07-17T14:23:41  <wumpus> I have that script, could post it, but don't really feel like submitting such trivial things to the repo
 490 2017-07-17T14:23:51  <wumpus> mmgen: I DID THAT
 491 2017-07-17T14:24:02  <mmgen> wumpus: what's it called?
 492 2017-07-17T14:24:02  <wumpus> mmgen: no one liked it!
 493 2017-07-17T14:24:07  <BlueMatt> lol
 494 2017-07-17T14:24:14  <mmgen> I think that's the best solution
 495 2017-07-17T14:24:21  <mmgen> It could even be coded in Python
 496 2017-07-17T14:24:34  <wumpus> mmgen: I have a python and c++ implementation!
 497 2017-07-17T14:25:17  <gmaxwell> wumpus: I liked it except for one concern, the parity between the CLI and RPC is a major learing curve improvement. If we went down the path of a highly cooked bitcoin-cli then knoweldge wouldn't automatically transfer between them, improvements wouldn't automatically transfer, etc.
 498 2017-07-17T14:25:20  <wumpus> #8843 was the c++ one
 499 2017-07-17T14:25:21  <gribble> https://github.com/bitcoin/bitcoin/issues/8843 | rpc: Handle `getinfo` client-side in bitcoin-cli w/ `-getinfo` by laanwj · Pull Request #8843 · bitcoin/bitcoin · GitHub
 500 2017-07-17T14:25:32  <mmgen> wumpus: need to convince the others I think
 501 2017-07-17T14:25:41  <wumpus> I don't have the python one online, but could post it if anyone cares
 502 2017-07-17T14:25:41  * BlueMatt was not aware of the python version
 503 2017-07-17T14:25:51  <BlueMatt> yea, I'd be interested in putting the python one in contrib
 504 2017-07-17T14:26:13  *** CubicEarth has quit IRC
 505 2017-07-17T14:26:17  <gmaxwell> for a getinfo replacement that cooked vs not cooked argument doesn't really hold, since it would just be one command.
 506 2017-07-17T14:26:24  <wumpus> gmaxwell: sure, that's just a matter of documentation though
 507 2017-07-17T14:26:43  <gmaxwell> which could be documented ('here are the underlying rpcs')
 508 2017-07-17T14:26:44  <wumpus> gmaxwell: it could show where it collects the various fields from for getinfo
 509 2017-07-17T14:26:47  <wumpus> yeah...
 510 2017-07-17T14:26:53  <mmgen> My wallet basically does just that, so I have a bit of experience in this area
 511 2017-07-17T14:27:00  <wumpus> a python script is self documentingi nthat regard
 512 2017-07-17T14:27:09  <wumpus> and easier to edit if you want something else
 513 2017-07-17T14:27:22  <wumpus> so ok, I'll add that to contrib, not in 0.15 though
 514 2017-07-17T14:27:26  <gmaxwell> wumpus: if it went as far as .e.g the ncurses interface, then that isn't the case. :)
 515 2017-07-17T14:27:38  <gmaxwell> wumpus: we could use more python rpc examples, IMO, in any case.
 516 2017-07-17T14:28:05  <wumpus> gmaxwell: yes I mean a simple getinfo replacement
 517 2017-07-17T14:28:37  <wumpus> ncurses isn't trivial (though also not rocket science, I've gotten people to start linux coding using it)
 518 2017-07-17T14:29:17  <promag> I'm happy to close #10804.. the problem is that to compute the histogram it takes really long to get and dump the json to the client with large utxo set
 519 2017-07-17T14:29:22  <gribble> https://github.com/bitcoin/bitcoin/issues/10804 | Add histunspent RPC by promag · Pull Request #10804 · bitcoin/bitcoin · GitHub
 520 2017-07-17T14:29:36  <mmgen> wumpus: ncurses is for wimps. real programmers use ANSI escape codes
 521 2017-07-17T14:29:54  <wumpus> mmgen: HAHA ansi escape codes are easier imo
 522 2017-07-17T14:30:04  <mmgen> wumpus: the fact is they are
 523 2017-07-17T14:30:27  <BlueMatt> morcos: wait, i thought min conftarget was 2?
 524 2017-07-17T14:30:31  <wumpus> (depending on what you want to do, if you need windowing and partial refresh etc, and menus, ncurses is definitely the way to go)
 525 2017-07-17T14:31:03  <mmgen> wumpus: true
 526 2017-07-17T14:31:04  <gmaxwell> promag: how long is really long? for how large?  With thousands of txouts it still takes a fraction of a second to listunspent last I checked.
 527 2017-07-17T14:31:18  <wumpus> if you want to go wild with displaying 24-bit color unicode graphs, ansi escape colors are definitely easier
 528 2017-07-17T14:33:23  <wumpus> promag: sure, computing the statistics server-side will be faster, but it's all a compromise...
 529 2017-07-17T14:34:02  <wumpus> promag: in that case maintaining a private patch set might make sense - the use for those statistics is probably specific to you
 530 2017-07-17T14:34:26  <gmaxwell> there are certantly things where I've written a python script to collect some data.. started it.... got tired of waiting, wrote it into the daemon on another host, recompiled, ran it, got the result...
 531 2017-07-17T14:34:36  <promag> gmaxwell: let me get fresh numbers for you
 532 2017-07-17T14:34:58  <gmaxwell> its unfortunate that rpc from python (and perhaps rpc in general) is so slow, though it is much faster than it used to be.
 533 2017-07-17T14:35:26  <BlueMatt> yea, Ive run python rpc clients that literally look days to complete
 534 2017-07-17T14:35:28  <mmgen> gmaxwell: I use it all the time. Haven't noticed that it's slow
 535 2017-07-17T14:36:23  <mmgen> but this is with my own RPC library
 536 2017-07-17T14:36:30  <wumpus> in that case it makes sense to implement it server-side in c++, but less sense for it to be merged upstream
 537 2017-07-17T14:36:41  <gmaxwell> mmgen: try doing something simple like graphing the size of all blocks from it... takes rather long time.  (or better, fee income from each block) at least with the normal python bitcoinrpc stuff
 538 2017-07-17T14:37:23  <wumpus> there's not really any API that can help you in that case, I guess there could be a dynlib plugin interface to load things into bitcoind, but does that ever make things easier than just recompiling?
 539 2017-07-17T14:37:27  <mmgen> gmaxwell: I don't use python-bitcoinrpc.  I just connect to the daemon directly
 540 2017-07-17T14:38:00  <gmaxwell> I believe we've factored up the relevant interfaces now that it shouldn't be hard to maintain external patches for things like this. Presumably we could take other changes that improved it further.
 541 2017-07-17T14:38:49  <gmaxwell> mmgen: may be that it's mostly the python side handling making it slow now. (didn't used to be the case, but the rpc has become a lot faster)
 542 2017-07-17T14:39:12  <mmgen> gmaxwell: Probably is. Python is slow
 543 2017-07-17T14:39:17  <mmgen> in general
 544 2017-07-17T14:39:37  *** whphhg has left #bitcoin-core-dev
 545 2017-07-17T14:39:44  <morcos> BlueMatt: huh?
 546 2017-07-17T14:40:00  <BlueMatt> morcos: new docs for estimatesmartfee says nblocks minimum is 1?
 547 2017-07-17T14:40:10  <wumpus> sometimes speeding up python is easy, a lot of code works as-is with pypy
 548 2017-07-17T14:40:10  <BlueMatt> in #10707
 549 2017-07-17T14:40:12  <gribble> https://github.com/bitcoin/bitcoin/issues/10707 | Better API for estimatesmartfee RPC by morcos · Pull Request #10707 · bitcoin/bitcoin · GitHub
 550 2017-07-17T14:41:19  <mmgen> wumpus: never tried pypy
 551 2017-07-17T14:41:21  <morcos> BlueMatt: you mean conf_target :)
 552 2017-07-17T14:41:38  <morcos> it is the minimum you can request, however asking for 1 will give you an answer for 2
 553 2017-07-17T14:41:41  <mmgen> wumpus: but everything remains single-threaded anyway
 554 2017-07-17T14:41:43  <BlueMatt> morcos: yes, sorry, was reviewing the first commit first :p
 555 2017-07-17T14:41:51  <BlueMatt> morcos: so lets just make the minimum 1?
 556 2017-07-17T14:41:56  <BlueMatt> (or at least mention that in the docs)
 557 2017-07-17T14:42:04  <morcos> it always worked to ask for 1, i didn't want to change that
 558 2017-07-17T14:42:15  <morcos> it seems like a semi-common thing a user might ask for
 559 2017-07-17T14:42:17  <BlueMatt> ok, so mention it in the docs, i guess
 560 2017-07-17T14:42:22  <wumpus> mmgen: it's still quite a big linear speedup for tight loops, better than you'd get with multithreading in most cases
 561 2017-07-17T14:43:01  <wumpus> (and it's no extra work, unlike multithreading)
 562 2017-07-17T14:43:32  <morcos> Also I think it preserves the ability to in the future return something different/smarter for a as fast as possible conf_target of 1
 563 2017-07-17T14:45:00  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 564 2017-07-17T14:45:26  *** Murch has joined #bitcoin-core-dev
 565 2017-07-17T14:47:58  <morcos> BlueMatt: ok, while I'm at it, should I change the return parameter name from "blocks" now that we changed the argument to "conf_target" or leave it?
 566 2017-07-17T14:48:17  <morcos> I guess I vote leave it
 567 2017-07-17T14:49:34  <bitcoin-git> [bitcoin] promag closed pull request #10804: Add histunspent RPC (master...2017-07-rpc-add-histunspent) https://github.com/bitcoin/bitcoin/pull/10804
 568 2017-07-17T14:49:48  <BlueMatt> morcos: leave it, id say
 569 2017-07-17T14:51:35  *** owowo has quit IRC
 570 2017-07-17T15:00:28  <BlueMatt> morcos: "fee estimation is *only* able to return"....
 571 2017-07-17T15:02:19  <morcos> BlueMatt: did you read the whole sentence?
 572 2017-07-17T15:02:38  <morcos> that would make no sense
 573 2017-07-17T15:03:22  <BlueMatt> morcos: oh, its one sentence
 574 2017-07-17T15:03:24  <BlueMatt> ok, whatever
 575 2017-07-17T15:04:36  <morcos> just ACK it already
 576 2017-07-17T15:05:01  <BlueMatt> i did
 577 2017-07-17T15:07:44  *** BashCo has quit IRC
 578 2017-07-17T15:08:18  *** BashCo has joined #bitcoin-core-dev
 579 2017-07-17T15:13:46  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/2b0179d8a9b7...89bb0365b97a
 580 2017-07-17T15:13:46  <bitcoin-git> bitcoin/master dba485d Wladimir J. van der Laan: init: Factor out AppInitLockDataDirectory...
 581 2017-07-17T15:13:47  <bitcoin-git> bitcoin/master 89bb036 Wladimir J. van der Laan: Merge #10832: init: Factor out AppInitLockDataDirectory and fix startup core dump issue...
 582 2017-07-17T15:14:16  <bitcoin-git> [bitcoin] laanwj closed pull request #10832: init: Factor out AppInitLockDataDirectory and fix startup core dump issue (master...2017_07_appinitlockdatadirectory) https://github.com/bitcoin/bitcoin/pull/10832
 583 2017-07-17T15:16:39  <bitcoin-git> [bitcoin] laanwj pushed 5 new commits to master: https://github.com/bitcoin/bitcoin/compare/89bb0365b97a...0b019357ff09
 584 2017-07-17T15:16:40  <bitcoin-git> bitcoin/master 3a53f19 Gregory Maxwell: Pushdown walletdb object through GenerateNewKey/DeriveNewChildKey....
 585 2017-07-17T15:16:40  <bitcoin-git> bitcoin/master 30d8f3a Gregory Maxwell: Pushdown walletdb though CWallet::AddKeyPubKey to avoid flushes....
 586 2017-07-17T15:16:41  <bitcoin-git> bitcoin/master 41dc163 Gregory Maxwell: Increase wallet default keypool size to 1000.
 587 2017-07-17T15:17:12  <bitcoin-git> [bitcoin] laanwj closed pull request #10831: Batch flushing operations to the walletdb during top up and increase keypool size. (master...topup_batch_flush) https://github.com/bitcoin/bitcoin/pull/10831
 588 2017-07-17T15:19:48  <cfields> wumpus: re qt, no, i don't think it's worth messing with for now
 589 2017-07-17T15:22:07  <wumpus> ok
 590 2017-07-17T15:23:51  <BlueMatt> gah, github is missing notification emails :(
 591 2017-07-17T15:26:46  <BlueMatt> wumpus: hmmm....I think (in addition to github actually missing notification emails) github wont send an email for a merge unless you comment merged.
 592 2017-07-17T15:26:48  <BlueMatt> can you do that?
 593 2017-07-17T15:27:06  <wumpus> hm?
 594 2017-07-17T15:27:12  <morcos> BlueMatt: I've never gotten more than about 1 in 3 of my expected github notification emails
 595 2017-07-17T15:27:14  <BlueMatt> eg #10831
 596 2017-07-17T15:27:16  <gribble> https://github.com/bitcoin/bitcoin/issues/10831 | Batch flushing operations to the walletdb during top up and increase keypool size. by gmaxwell · Pull Request #10831 · bitcoin/bitcoin · GitHub
 597 2017-07-17T15:27:20  <BlueMatt> morcos: did you mail support@?
 598 2017-07-17T15:27:23  <wumpus> github should send an automated mail when something gets merged
 599 2017-07-17T15:27:29  <BlueMatt> morcos: i just for the first time missed some emails
 600 2017-07-17T15:27:31  <morcos> i complained to sdaftuar, does that count
 601 2017-07-17T15:27:35  <BlueMatt> ........
 602 2017-07-17T15:27:44  <morcos> it didn't used to happen to him, but now it does too
 603 2017-07-17T15:27:51  <BlueMatt> well whatever, I have all mailserver logs and didnt get any, so I'm gonna bitch to support@
 604 2017-07-17T15:27:51  <wumpus> but I don't know what you mean with 'comment merged'
 605 2017-07-17T15:28:05  <BlueMatt> wumpus: as in usually when sipa merges he comments on the pr merged when he closes it
 606 2017-07-17T15:28:06  <BlueMatt> iirc
 607 2017-07-17T15:28:12  <BlueMatt> saying "Merged"
 608 2017-07-17T15:28:20  <wumpus> huh? no, he doesn't
 609 2017-07-17T15:29:17  <BlueMatt> oh?
 610 2017-07-17T15:29:23  <wumpus> see https://github.com/bitcoin/bitcoin/pull/10735 https://github.com/bitcoin/bitcoin/pull/10844
 611 2017-07-17T15:29:35  <wumpus> https://github.com/bitcoin/bitcoin/pull/10840
 612 2017-07-17T15:30:00  <BlueMatt> hmm, oh, you're right!
 613 2017-07-17T15:30:04  <wumpus> being the last things he merged, he commented on none of them, besides an utACK in some cases, but no "Merged". Github does that.
 614 2017-07-17T15:30:07  <BlueMatt> ugh, yea, so github notifications ar ejust fucked
 615 2017-07-17T15:30:14  <BlueMatt> yea, ok, ill go bitch at them
 616 2017-07-17T15:31:31  <BlueMatt> clearly we should be doing dev on our own hosted infrastructure so that we dont miss notification emails :p
 617 2017-07-17T15:32:00  <wumpus> as if sending mails from your own infrastructure (and having them actually arrive) is a sure thing, or was that the joke? :)
 618 2017-07-17T15:32:08  <BlueMatt> it was a joke
 619 2017-07-17T15:32:09  <gmaxwell> "now you have two problems"
 620 2017-07-17T15:32:09  <BlueMatt> yea
 621 2017-07-17T15:32:19  <BlueMatt> i mean they'd arrive for me, cause i run the receiving mailserver too :p
 622 2017-07-17T15:33:03  <gmaxwell> BlueMatt: but feel free to setup mirrored infra... :)
 623 2017-07-17T15:33:12  <BlueMatt> lol, I'll pass
 624 2017-07-17T15:33:15  <BlueMatt> i already manage too much shit
 625 2017-07-17T15:37:37  *** Murch has quit IRC
 626 2017-07-17T15:38:10  <gmaxwell> What do we think of #10817 ?  I didn't notice until a day ago that it wasn't 15 flagged, I think it's ready to go.  And its a likely useful lead up to work in 0.16-- in that it will increase change discarding somewhat, while planned work for 0.16 (the exact match coin selecter) will increase it a lot more... might be good to have in field feedback (are people going to be irate about it throwing
 627 2017-07-17T15:38:12  <gribble> https://github.com/bitcoin/bitcoin/issues/10817 | Redefine Dust and add a discard_rate by morcos · Pull Request #10817 · bitcoin/bitcoin · GitHub
 628 2017-07-17T15:38:17  <gmaxwell> away an extra 5 cents in bitcoin to avoid change outputs)
 629 2017-07-17T15:39:09  <wumpus> tagged
 630 2017-07-17T15:39:20  <gmaxwell> danke.
 631 2017-07-17T15:39:42  <bitcoin-git> [bitcoin] theuni opened pull request #10851: depends: bump fontconfig to 2.12.4 (master...fontconfig-bump) https://github.com/bitcoin/bitcoin/pull/10851
 632 2017-07-17T15:43:00  *** Murch has joined #bitcoin-core-dev
 633 2017-07-17T15:44:09  *** SopaXorzTaker has joined #bitcoin-core-dev
 634 2017-07-17T15:48:45  <gmaxwell> I think 9728 can be untagged for 15, retagged for 16.
 635 2017-07-17T15:49:36  <instagibbs> freeze is after today yes?
 636 2017-07-17T15:49:49  <wumpus> gmaxwell: ok, agree
 637 2017-07-17T15:49:52  <instagibbs> ack re 9728, we still have work on it
 638 2017-07-17T15:50:02  <instagibbs> but should def be ready for 16
 639 2017-07-17T15:50:03  <wumpus> instagibbs: seems we're slipping with regard to multiwallet
 640 2017-07-17T15:50:24  <instagibbs> yeah I noticed, but I don't have the strongest opinion so kinda ducked out of that
 641 2017-07-17T15:50:28  <wumpus> instagibbs: but yeah, please no new stuff now
 642 2017-07-17T15:51:01  <wumpus> (unless they're bugfixes, ofcourse)
 643 2017-07-17T15:51:16  <gmaxwell> that was the only thing in the 15 tags that seemed to me that obviously wouldn't make it. (I'm sure some other things won't too)
 644 2017-07-17T15:53:09  <morcos> #10830 is missing the 0.15 tag and probably still needs the most work
 645 2017-07-17T15:53:11  <gribble> https://github.com/bitcoin/bitcoin/issues/10830 | [WIP] [wallet] keypool restore by jnewbery · Pull Request #10830 · bitcoin/bitcoin · GitHub
 646 2017-07-17T15:53:14  <BlueMatt> ok, what are we doing about multiwallet for 15?
 647 2017-07-17T15:53:33  * BlueMatt ducks before the impending swats
 648 2017-07-17T15:53:35  <gmaxwell> morcos: Agreed, though I consider 10830 a bugfix. It should still be tagged. (the other PR was tagged)
 649 2017-07-17T15:54:10  <gmaxwell> sipa: Have you looked at the redo of the endpoint change... it's much simpler and drop-in usable than the earlier one.
 650 2017-07-17T15:54:52  *** pandabull has joined #bitcoin-core-dev
 651 2017-07-17T15:55:07  *** pandabull has quit IRC
 652 2017-07-17T15:55:17  <bitcoin-git> [bitcoin] jnewbery opened pull request #10853: [tests] Fix RPC failure testing (again) (master...cleanup_jsonrpc_asserts) https://github.com/bitcoin/bitcoin/pull/10853
 653 2017-07-17T15:55:28  <morcos> As for multiwallet, everyone just vote 0, 1, or 2 votes for either #10829 or #10849 based on how stronly you feel, and lets just pick one. honestly, we'll be fine with either choice, but lets concentrate our effort on one of them
 654 2017-07-17T15:55:29  <gribble> https://github.com/bitcoin/bitcoin/issues/10829 | Simple, backwards compatible RPC multiwallet support. by ryanofsky · Pull Request #10829 · bitcoin/bitcoin · GitHub
 655 2017-07-17T15:55:30  <gribble> https://github.com/bitcoin/bitcoin/issues/10849 | Multiwallet: simplest endpoint support by jonasschnelli · Pull Request #10849 · bitcoin/bitcoin · GitHub
 656 2017-07-17T15:55:50  <gmaxwell> #10821 tag for 0.16
 657 2017-07-17T15:55:52  <gribble> https://github.com/bitcoin/bitcoin/issues/10821 | Add SSE4 optimized SHA256 by sipa · Pull Request #10821 · bitcoin/bitcoin · GitHub
 658 2017-07-17T15:56:06  <morcos> I vote 0 votes
 659 2017-07-17T15:56:14  *** Murch has quit IRC
 660 2017-07-17T15:56:24  <gmaxwell> do not vote for SSE4 optimized multiwallet.
 661 2017-07-17T15:56:37  <BlueMatt> oooo, 2 votes for that (whatever the hell it is)
 662 2017-07-17T15:56:56  <morcos> as my 2 year old would say whenever we tell him no..  "not yet?"
 663 2017-07-17T15:56:58  <instagibbs> 1.6x as secure as regular multiwallet
 664 2017-07-17T15:57:02  *** Murch has joined #bitcoin-core-dev
 665 2017-07-17T15:57:13  *** owowo has joined #bitcoin-core-dev
 666 2017-07-17T16:02:37  <jnewbery> Is #10650 definitely dead? It had 4 ACKs and instagibbs and I had both tested it.
 667 2017-07-17T16:02:40  <gribble> https://github.com/bitcoin/bitcoin/issues/10650 | Multiwallet: add RPC endpoint support by jonasschnelli · Pull Request #10650 · bitcoin/bitcoin · GitHub
 668 2017-07-17T16:03:11  <jnewbery> If it is dead, then my 1 vote is for #10849, since I've reviewed and tested that manually, and I think endpoints is the correct way to go
 669 2017-07-17T16:03:13  <gribble> https://github.com/bitcoin/bitcoin/issues/10849 | Multiwallet: simplest endpoint support by jonasschnelli · Pull Request #10849 · bitcoin/bitcoin · GitHub
 670 2017-07-17T16:03:20  <instagibbs> 1 very vehement NACK, basically
 671 2017-07-17T16:03:26  <instagibbs> (not saying right or wrong)
 672 2017-07-17T16:04:15  <jnewbery> but if other people have reviewed and tested #10829 then I can also live with that. I see the multiwallet interface in v0.15 as unstable/experimental, so as long as something gets in, I'm happy
 673 2017-07-17T16:04:17  <gribble> https://github.com/bitcoin/bitcoin/issues/10829 | Simple, backwards compatible RPC multiwallet support. by ryanofsky · Pull Request #10829 · bitcoin/bitcoin · GitHub
 674 2017-07-17T16:05:07  <instagibbs> I mostly reviewed that things behaved like they should, I can do the same today for either of the other two. I'm happy with whatever works.
 675 2017-07-17T16:06:59  <gmaxwell> -1 on 10650, I think  like 10849 better than 10829, as I think it will be more usable in practice but I will be fully willing to help throw out either interface later, so I don't care overly much.  10849 is a newer pr... both presumably still need a lot of review love.
 676 2017-07-17T16:07:10  *** mmgen has quit IRC
 677 2017-07-17T16:12:18  <gmaxwell> morcos: care to review #10672
 678 2017-07-17T16:12:20  <gribble> https://github.com/bitcoin/bitcoin/issues/10672 | Avoid division by zero in the case of a corrupt estimates file by practicalswift · Pull Request #10672 · bitcoin/bitcoin · GitHub
 679 2017-07-17T16:17:01  <cfields> BlueMatt: are you still wanting #10652 for 0.15 ?
 680 2017-07-17T16:17:03  <gribble> https://github.com/bitcoin/bitcoin/issues/10652 | Small step towards demangling cs_main from CNodeState by TheBlueMatt · Pull Request #10652 · bitcoin/bitcoin · GitHub
 681 2017-07-17T16:17:20  *** Guyver2 has quit IRC
 682 2017-07-17T16:20:06  <gmaxwell> #10335 sounds like something should be done.
 683 2017-07-17T16:20:07  <gribble> https://github.com/bitcoin/bitcoin/issues/10335 | back-compat: add fallback getentropy implementation by theuni · Pull Request #10335 · bitcoin/bitcoin · GitHub
 684 2017-07-17T16:35:05  <cfields> gmaxwell: thanks for the reminder. fixing that up now.
 685 2017-07-17T16:35:06  *** mmgen has joined #bitcoin-core-dev
 686 2017-07-17T16:35:13  *** Dyaheon has quit IRC
 687 2017-07-17T16:36:50  *** Dyaheon has joined #bitcoin-core-dev
 688 2017-07-17T16:40:16  *** fengling has quit IRC
 689 2017-07-17T16:40:17  *** [Author] has quit IRC
 690 2017-07-17T16:40:17  *** Magma has quit IRC
 691 2017-07-17T16:41:29  <BlueMatt> fizzwont: nah, think its gonna slip now
 692 2017-07-17T16:41:33  <BlueMatt> cfields: ...
 693 2017-07-17T16:41:44  <instagibbs> little worried about 10829 since named support is still a bit flakey. I think merging that would mean fixing up named arg support becomes priority.
 694 2017-07-17T16:41:49  <BlueMatt> it would've been nice, but i dont think its critical enough to care, just untag 10672
 695 2017-07-17T16:42:20  <gmaxwell> BlueMatt: whats the 'fizzwont' context for your message?
 696 2017-07-17T16:42:36  <BlueMatt> gmaxwell: bad auto-tab, its a user on here
 697 2017-07-17T16:42:39  <cfields> :(
 698 2017-07-17T16:43:11  <BlueMatt> cfields: meh, its mostly a bugfix for not-really-issues bugs
 699 2017-07-17T16:43:20  <BlueMatt> the cleanup to do the demangle is gonna be a through-16 process
 700 2017-07-17T16:44:17  <fizzwont> i'm honored...but just observing
 701 2017-07-17T16:59:19  *** Murch has quit IRC
 702 2017-07-17T17:01:45  *** Murch has joined #bitcoin-core-dev
 703 2017-07-17T17:03:25  <bitcoin-git> [bitcoin] gmaxwell opened pull request #10854: Avoid using sizes on non-fixed-width types to derive protocol constants. (master...rbf-numlimit-fix) https://github.com/bitcoin/bitcoin/pull/10854
 704 2017-07-17T17:06:59  *** arowser has quit IRC
 705 2017-07-17T17:10:34  *** herzmeister[m] has quit IRC
 706 2017-07-17T17:11:07  *** draadpiraat[m] has quit IRC
 707 2017-07-17T17:12:01  *** kewde[m] has quit IRC
 708 2017-07-17T17:15:57  <bitcoin-git> [bitcoin] theuni closed pull request #10335: back-compat: add fallback getentropy implementation (master...getentropy-back-compat) https://github.com/bitcoin/bitcoin/pull/10335
 709 2017-07-17T17:16:10  *** arowser has joined #bitcoin-core-dev
 710 2017-07-17T17:18:07  <bitcoin-git> [bitcoin] theuni opened pull request #10855: random: only use getentropy on openbsd (master...getentropy-openbsd) https://github.com/bitcoin/bitcoin/pull/10855
 711 2017-07-17T17:19:39  *** herzmeister[m] has joined #bitcoin-core-dev
 712 2017-07-17T17:23:06  *** Murch has quit IRC
 713 2017-07-17T17:24:53  *** Murch has joined #bitcoin-core-dev
 714 2017-07-17T17:26:42  *** kexkey has joined #bitcoin-core-dev
 715 2017-07-17T17:27:06  *** promag has quit IRC
 716 2017-07-17T17:30:52  *** jamesob_ has joined #bitcoin-core-dev
 717 2017-07-17T17:37:29  *** CubicEarth has joined #bitcoin-core-dev
 718 2017-07-17T17:42:28  *** arubi has quit IRC
 719 2017-07-17T17:42:28  *** dermoth has quit IRC
 720 2017-07-17T17:43:24  *** dermoth has joined #bitcoin-core-dev
 721 2017-07-17T17:44:52  *** arubi has joined #bitcoin-core-dev
 722 2017-07-17T17:47:29  *** jtimon has joined #bitcoin-core-dev
 723 2017-07-17T17:50:11  *** nakaluna has joined #bitcoin-core-dev
 724 2017-07-17T17:52:10  <morcos> yeah someone please tag #10758 for 0.15
 725 2017-07-17T17:53:28  <sipa> done
 726 2017-07-17T17:54:21  <morcos> instagibbs: to be clear, there are no rpc calls where you can't use named arguments right?  there just might be some where you need to specifically specify the default value if you want to name a later argument (but this is the same thing you have to do with positional)
 727 2017-07-17T17:54:55  <sipa> wasnt't there a PR to fix that?
 728 2017-07-17T17:55:05  *** kewde[m] has joined #bitcoin-core-dev
 729 2017-07-17T17:55:05  *** draadpiraat[m] has joined #bitcoin-core-dev
 730 2017-07-17T17:55:18  <instagibbs> morcos, oh, true
 731 2017-07-17T17:55:28  <instagibbs> yes you'll have to enter in all values for some
 732 2017-07-17T17:55:37  <gribble> https://github.com/bitcoin/bitcoin/issues/10758 | Fix some chainstate-init-order bugs. by TheBlueMatt · Pull Request #10758 · bitcoin/bitcoin · GitHub
 733 2017-07-17T17:55:44  <instagibbs> so, less urgent :)
 734 2017-07-17T17:55:47  <morcos> sipa: yeah, i was just trying to understand the urgency
 735 2017-07-17T17:56:02  <instagibbs> merely annoying
 736 2017-07-17T17:56:55  *** timothy has quit IRC
 737 2017-07-17T17:57:25  <BlueMatt> lol, somehow i thought 10758 was already tagged 15
 738 2017-07-17T17:57:27  *** CubicEarth has quit IRC
 739 2017-07-17T17:57:28  <morcos> i guess people didn't like my voting idea or don't have an opinon on which multiwallet PR to merge.  can we decide so we can make it happen?  i'm happy to review 10849 if we prefer that one
 740 2017-07-17T17:57:47  <sipa> i'll review the last PR before giving an opinion
 741 2017-07-17T17:57:51  *** PaulCape_ has quit IRC
 742 2017-07-17T18:00:28  *** PaulCapestany has joined #bitcoin-core-dev
 743 2017-07-17T18:03:28  <ryanofsky> i'd give one vote to 10829 (obvs), and one conditional vote to 10849 if it uses a plain query parameter, or has some documentation explaining the path schema
 744 2017-07-17T18:05:41  <sipa> i think a query parameter is inferior to just a named parameter, and doesn't really simplify later moving to a new process
 745 2017-07-17T18:06:09  <sipa> i'm fine with named parameters for now, as a stopgap measure because a full new API isn't complete
 746 2017-07-17T18:06:16  <sipa> documentation can come later
 747 2017-07-17T18:06:26  <sipa> that doesn't need to be ready by the feature freeze
 748 2017-07-17T18:08:03  <sipa> but i do think a new endpoint is eventually the way to go - whether that happens in 0.15 or not
 749 2017-07-17T18:08:05  <ryanofsky> sipa i think moving to new process is basically orthogonal. reason why i think query parameter is better is it leave uri-path space open for future uses and an actual thoughtful design. current design is changing multiple times a day
 750 2017-07-17T18:08:47  <ryanofsky> add v1, subtract v1, forward node calls through wallet, then stop, then start again
 751 2017-07-17T18:09:16  <sipa> ryanofsky: i really disagree with that... the point of an endpoint is that clients can be configured to point to a new process
 752 2017-07-17T18:09:36  <ryanofsky> i'm trying to understand...
 753 2017-07-17T18:09:41  <sipa> you can't do that with query parameters
 754 2017-07-17T18:09:55  <ryanofsky> ? why not?
 755 2017-07-17T18:10:20  <sipa> what if some of them are process-specific, and some or not?
 756 2017-07-17T18:10:31  <sipa> the client software would need to go modify the url to put in extra things
 757 2017-07-17T18:10:59  <sipa> i guess it isn't worse - as long as everything you'd put in the path becomes a query parameter and nothing else
 758 2017-07-17T18:11:05  <sipa> but it also doesn't gain you anything
 759 2017-07-17T18:11:05  <jtimon> ryanofsky: it's about simplyfing concurrency
 760 2017-07-17T18:11:11  <sipa> jtimon: wut?
 761 2017-07-17T18:11:17  <jtimon> is it not?
 762 2017-07-17T18:11:23  <sipa> what does that have to do with anything
 763 2017-07-17T18:11:40  *** AaronvanW has quit IRC
 764 2017-07-17T18:11:58  <ryanofsky> i'm not understanding what you're saying sipa... did you change your mind midway?
 765 2017-07-17T18:12:28  <sipa> ryanofsky: yes, i did; i agree that query parameters can do anything that a URI can... but it also doesn't gain you anything
 766 2017-07-17T18:12:32  <ryanofsky> advantage of query parameter is it leaves more options for the future that don't require us to break compatibility
 767 2017-07-17T18:12:39  <ryanofsky> nothing to do with multiprocess
 768 2017-07-17T18:13:53  <ryanofsky> specific example of what i'm talking about: maybe we want to have web interface listening on /wallet. maybe we want to add versioning in the future
 769 2017-07-17T18:13:59  <sipa> ryanofsky: but the point is creating a namespace
 770 2017-07-17T18:14:12  <jtimon> right, each wallet can get its own lock even with query paramters, then I don't undesrtand what's the point either...can't you serve the rpc more concurrently with different http addresses more concurrently either (ie maybe a server for each or something)?
 771 2017-07-17T18:14:15  <sipa> separating things off, which can later move elsewhere
 772 2017-07-17T18:14:24  <ryanofsky> doing these things cleanly means planning out url design somewhat, which hasn't been done. in these prs url design is constantly in flux
 773 2017-07-17T18:14:33  <sipa> jtimon: that's completely orthogonal; we're talking about interface here
 774 2017-07-17T18:14:59  <jtimon> well, I remembered that about the most convincing argument in favor of this interface
 775 2017-07-17T18:15:13  <jtimon> s/about/as/
 776 2017-07-17T18:15:22  <sipa> jtimon: we already have multithreaded RPC...
 777 2017-07-17T18:15:37  <jtimon> sipa: oh, nice
 778 2017-07-17T18:15:40  <sipa> jtimon: ...
 779 2017-07-17T18:16:25  <ryanofsky> jtimon, fwiw, i don't see connection there either
 780 2017-07-17T18:16:51  <sipa> jtimon: the RPC implementation isn't very concurrent, but that's an implementation detail that can be improved independently
 781 2017-07-17T18:17:00  <jtimon> I didn't know, sorry, then I don't understand why this wallet/<my wallet> is better than wallet=<mywallet> in the rpc either. but I'll read your conversation and see if I get it
 782 2017-07-17T18:17:00  <sipa> (overeager locking in many places)
 783 2017-07-17T18:17:19  <sipa> jtimon: it's so that things can move to a different process
 784 2017-07-17T18:17:41  <sipa> if the wallet weren't handled by bitcoind anymore, it would have its own RPC server, which runs on a different port or something
 785 2017-07-17T18:17:53  <jtimon> sipa: how is moving things to a different process unrelated to concurrency?
 786 2017-07-17T18:18:03  <sipa> jtimon: because it's already multithreaded!
 787 2017-07-17T18:18:27  <jtimon> then what's the point of moving it to a different process?
 788 2017-07-17T18:18:37  <sipa> the reason for moving things to a different process is for security (don't have your private keys connected to a network interface) and modularity (run it on a different machine)
 789 2017-07-17T18:19:04  <jtimon> ok, thanks, I wrongly assumed the reason was concurrency
 790 2017-07-17T18:19:06  <ryanofsky> my the way my conditional vote for 10849 had an OR in it. if query parameter is worse for some reason (aesthetics?) and path interpretation is way to go, please just document/respond what actual plans are for path interpretation. what compatibility is being promised
 791 2017-07-17T18:19:24  <sipa> ryanofsky: of course it needs documenting
 792 2017-07-17T18:20:15  <sipa> ryanofsky: if we aren't clear on how the namespace separation should happen, i agree that just an RPC named parameter for selecting a wallet is better for now
 793 2017-07-17T18:20:38  <sipa> ryanofsky: but if we are, we should do it... and url parameters seem like a very odd thing for a namespace
 794 2017-07-17T18:21:38  <ryanofsky> i don't understand the point about a namespace. is an aesthetic thing, or a practical difference?
 795 2017-07-17T18:22:05  *** DaggerHashimoto has joined #bitcoin-core-dev
 796 2017-07-17T18:22:29  <ryanofsky> i'm asking for documentation not just because documentation is needed, but also because i really think i am missing something about rationales (or that rationales haven't actually been thought through)
 797 2017-07-17T18:22:46  <sipa> ryanofsky: my concern is that uri parameters don't force us to think about separation
 798 2017-07-17T18:22:57  <jtimon> but the parameters don't need to go in the url, do they? they can go with the json data (ie with method, params, jsonrpc and id)
 799 2017-07-17T18:23:18  <sipa> jtimon: yes, that's the discussion... there are 4 approaches suggested
 800 2017-07-17T18:24:11  <jtimon> I think I'm missing one from the last meeting...
 801 2017-07-17T18:24:54  <sipa> jtimon: in the URL (http://localhost:8333/v1/wallet/[walletname]), in a URL parameter (http://localhost:8333/v1?wallet=[walletname]), in a JSON RPC parameter (pass wallet: "[walletname]" as named argument), through RPC auth (every rpc user has his own wallet)
 802 2017-07-17T18:25:24  <jtimon> I see, rpc auth was the one I was mising
 803 2017-07-17T18:25:44  <sipa> ryanofsky: people may be inclined to add things to URI parameters that don't naturally correspond to separation (say, an option for changing the default currency unit)
 804 2017-07-17T18:25:51  <sipa> ryanofsky: or expect those to go there
 805 2017-07-17T18:25:55  <jtimon> no, I thought we agreed some users will have more than one, and I think some users may not want one too
 806 2017-07-17T18:26:31  <sipa> ryanofsky: sure you can say, "well don't do that"
 807 2017-07-17T18:26:45  <ryanofsky> not sure why a query option like that would be bad at all. do you also think a timeout query option would be bad?
 808 2017-07-17T18:26:46  <BlueMatt> it may be unfair, but ryanofsky succcessfully convinced me over lunch....the user experience of upgrading is gonna be the same no matter how we do it, and the args approach is much simpler for users to add
 809 2017-07-17T18:26:53  <BlueMatt> rather than the endpoints approach
 810 2017-07-17T18:27:22  <sipa> ryanofsky: ok, say we have ?wallet=[walletname]&timeout=30
 811 2017-07-17T18:27:31  <sipa> all in one process
 812 2017-07-17T18:27:41  <BlueMatt> the endpoints stuff is kinda nice in that it makes users thing, but realistically its just another hop to upgrade, cause if we move to process isolation now its all a different ip/port connection anyway
 813 2017-07-17T18:27:46  <BlueMatt> so its just a useless upgrade hop
 814 2017-07-17T18:28:13  <sipa> now the wallets move to different processes
 815 2017-07-17T18:28:30  <BlueMatt> and now the split is by connection port, and not endpoint anyway :p
 816 2017-07-17T18:28:40  <sipa> you can't just go reconfigure the client software
 817 2017-07-17T18:29:08  <sipa> it needs to mix something from the configured URI (which likely has the ?wallet= part) and from the application (which likely has the ?timeout= part)
 818 2017-07-17T18:29:09  <BlueMatt> actually args makes it easier at that point than endpoints?
 819 2017-07-17T18:29:16  <BlueMatt> precisely cause it doesnt require client reconfiguration
 820 2017-07-17T18:29:29  <BlueMatt> wait, now maybe I'm confused, why are we re-adding uri parameters now
 821 2017-07-17T18:29:34  <sipa> but client reconfiguration is easy
 822 2017-07-17T18:29:36  <ryanofsky> sipa are you talking about a node process that forwards requests to various wallets?
 823 2017-07-17T18:29:40  <sipa> ryanofsky: no
 824 2017-07-17T18:29:41  <ryanofsky> BlueMatt, i have same confusion
 825 2017-07-17T18:30:02  <ryanofsky> so you are talking about what matt is talking about. wallet process listening on own port
 826 2017-07-17T18:30:08  <BlueMatt> doing wallet split today is very doable - have multiple rpc clients pointed at different listening ports
 827 2017-07-17T18:30:10  <sipa> i want to just tell my client app (instead of http://localhost:8333, you can use http://localhost:8333/v1/wallet/bla)
 828 2017-07-17T18:30:21  <BlueMatt> but you cant with most clients/
 829 2017-07-17T18:30:22  <BlueMatt> ?
 830 2017-07-17T18:30:31  <ryanofsky> wait sipa, that sounds like you are saying one port for node and wallet?
 831 2017-07-17T18:30:38  <sipa> ryanofsky: ???
 832 2017-07-17T18:30:55  <sipa> as long as they're in the same process
 833 2017-07-17T18:31:00  <ryanofsky> port 8333 is wallet process or node process?
 834 2017-07-17T18:31:07  <sipa> it's the process process
 835 2017-07-17T18:31:09  <sipa> there is just one
 836 2017-07-17T18:31:10  <BlueMatt> instead of btc = AuthServiceProxy(); btc.getwalletinfo(); btc.getmininginfo(); its now wallet_btc = AuthServiceProxy(...:8332); node_btc = AuthServiceProxy(...:8331)......
 837 2017-07-17T18:31:22  <sipa> ryanofsky: i'm talking about the case before things move to a idfferent process
 838 2017-07-17T18:31:25  <BlueMatt> sipa: I'm horribly confused
 839 2017-07-17T18:31:28  <ryanofsky> AH ok
 840 2017-07-17T18:31:33  <ryanofsky> so single process just like today
 841 2017-07-17T18:32:13  <BlueMatt> sipa: I think ryanofsky's point (and my point) is that we should focus on making it easier for clients to do the upgrade (which wallet arg is, imo) cause the isolation is gonna come from different listening ports in the future anyway
 842 2017-07-17T18:32:15  <sipa> however, afterwards, when things move to a new process, you don't need to change the application software, just reconfigure it to use a different URI (which is now maybe running on a different port, or a different host)
 843 2017-07-17T18:32:24  <BlueMatt> so trying to force endpoints is just an extra step for users for no reason
 844 2017-07-17T18:32:41  <BlueMatt> sipa: you can already do that?
 845 2017-07-17T18:32:47  <ryanofsky> sipa, how is wallet named arg a problem in that scenario?
 846 2017-07-17T18:32:53  <BlueMatt> just tell your app software that you have two different rpc hosts
 847 2017-07-17T18:32:59  <ryanofsky> i think wallet named arg is a feature even in that scenario
 848 2017-07-17T18:33:15  <sipa> ryanofsky: because wallet named arg requires at the very least the client application to know which wallet it is talking to
 849 2017-07-17T18:33:23  <ryanofsky> because it's easy to imagine starting wallet processes and confusing yourself about port numbers
 850 2017-07-17T18:33:29  <sipa> while it can be encapsulated in the uri
 851 2017-07-17T18:34:51  <BlueMatt> sipa: if you're gonna change the rpc library to support endpoints, you can also change it to support a global wallet argument
 852 2017-07-17T18:35:00  <ryanofsky> i'm confused again. now we are talking about separate wallet process listening it's separate wallet port. what is the harm of wallet param there (used or unused)?
 853 2017-07-17T18:35:12  <BlueMatt> whereas arguments are nice cause you dont have to change the library, if it already supports named args
 854 2017-07-17T18:35:13  <sipa> BlueMatt: but after process separation there may not even be a need for a global wallet argument
 855 2017-07-17T18:35:22  <jtimon> for what is worth, I like v1 in the uri more than "jsonrpc": "1.0" in the json data, but do we need 2 of them?
 856 2017-07-17T18:35:23  <sipa> BlueMatt: endpoint support means there is just one change
 857 2017-07-17T18:35:32  <BlueMatt> sipa: sure, and its, in fact, easier to remove the wallet arg at that point than the endpoints
 858 2017-07-17T18:35:33  <sipa> to the application
 859 2017-07-17T18:35:39  <BlueMatt> cause we can even start ignoring the arg
 860 2017-07-17T18:36:10  <sipa> you really think so? that first requiring everything to add a wallet configuration option, and then later change it again because now it's done in a different URI
 861 2017-07-17T18:36:17  <sipa> is easier than just allowing to configure a URI?
 862 2017-07-17T18:36:43  <ryanofsky> oh sipa, now i finally get it, yes i agree
 863 2017-07-17T18:36:50  <BlueMatt> sipa: think about eg the python library which is never updated
 864 2017-07-17T18:36:58  <BlueMatt> you could use multiwallet even before the library is updated
 865 2017-07-17T18:37:08  <BlueMatt> and if you update the library then its the same
 866 2017-07-17T18:37:18  <ryanofsky> yes that is an argument against named json-rpc params in favor of urls
 867 2017-07-17T18:37:20  <BlueMatt> (either the library silently adds the wallet arg to all calls, or it doesnt)
 868 2017-07-17T18:37:21  <sipa> i'm confused
 869 2017-07-17T18:37:28  <BlueMatt> instead of silently adding the wallet endpoint to all calls, or not
 870 2017-07-17T18:37:40  <ryanofsky> it's not an argument for wallet in uri-path instead of wallet in url query-string
 871 2017-07-17T18:37:43  <sipa> BlueMatt: it shouldn't silently add wallet endpoints!
 872 2017-07-17T18:37:53  <sipa> BlueMatt: you should tell it "MY URL IS ...../v1/wallet"
 873 2017-07-17T18:38:08  <sipa> it shouldn't even know there is such a thing as wallet names
 874 2017-07-17T18:38:08  <BlueMatt> sipa: does the current python client support that?
 875 2017-07-17T18:38:18  <BlueMatt> (I dont know, I'm asking)
 876 2017-07-17T18:38:20  <sipa> BlueMatt: i don't know, but it'd be trivial to add
 877 2017-07-17T18:38:38  <sipa> and certainly easier than updating it to selectively go add wallet parameters everywhere
 878 2017-07-17T18:38:41  <sipa> and then later making that optional
 879 2017-07-17T18:39:28  <jtimon> sipa: how is "encapsulated in the uri" different from "encapsulated on the json data like 'jsonrpc' and 'method'"? if that's better, why not move the method to the uri too?
 880 2017-07-17T18:39:50  <sipa> jtimon: because thr rpc method and parameter are decided by the application
 881 2017-07-17T18:39:55  *** SopaXorzTaker has quit IRC
 882 2017-07-17T18:40:00  <sipa> jtimon: and the URI is decided by the person configuring the software
 883 2017-07-17T18:40:02  <jtimon> sipa: and so it's the uri?
 884 2017-07-17T18:40:08  <sipa> no
 885 2017-07-17T18:40:20  <sipa> you tell your application which host and port the RPC server runs on,
 886 2017-07-17T18:40:26  <sipa> you can also tell it what URI to use
 887 2017-07-17T18:40:45  <sipa> ryanofsky: i agree that technically url query-string can do as much as uri-path... but i do believe that this approach can only work if we clearly think about what can be separated
 888 2017-07-17T18:40:46  *** Dyaheon has quit IRC
 889 2017-07-17T18:40:46  <BlueMatt> sipa: issue is I do not believe most client libraries support that today
 890 2017-07-17T18:40:48  <jtimon> mhmm, well, that's were I'm confused, I don't see how you could have control of the json data bur not of the uri
 891 2017-07-17T18:40:51  <sipa> BlueMatt: sure, so?
 892 2017-07-17T18:40:53  <BlueMatt> (I was informed that the python-bitcoinrpc library does not)
 893 2017-07-17T18:40:54  <sipa> BlueMatt: they can be updated
 894 2017-07-17T18:40:55  <jtimon> s/were/where
 895 2017-07-17T18:41:15  <BlueMatt> sipa: whereas client libraies may already support a wallet argument
 896 2017-07-17T18:41:17  <BlueMatt> silently, easily
 897 2017-07-17T18:41:21  <ryanofsky> sipa, maybe an example of where query-string would not work & uri-path would work?
 898 2017-07-17T18:41:55  <sipa> 18:10:59 < sipa> i guess it isn't worse - as long as everything you'd put in the path becomes a query parameter and nothing else
 899 2017-07-17T18:41:59  <ryanofsky> by the way, one reason i am more inclined to named wallet param is that i think it is actually better for safety
 900 2017-07-17T18:41:59  <sipa> ryanofsky: there isn't
 901 2017-07-17T18:42:24  *** Dyaheon has joined #bitcoin-core-dev
 902 2017-07-17T18:42:30  <jtimon> sipa: oh, ok, then that's where I was confused! what are we discussing then?
 903 2017-07-17T18:42:39  <sipa> jtimon: JSON RPC argument vs URI
 904 2017-07-17T18:42:53  <sipa> jtimon: i'm not talking about URI path vs URI query string
 905 2017-07-17T18:43:08  <ryanofsky> named arguments are safer than positional arguments, because harder to screw up ordering, explicitly specifying wallet is better than not because easy to mess up port numbers
 906 2017-07-17T18:43:42  <ryanofsky> so i tend to think even with multiprocess wallet, param has utility
 907 2017-07-17T18:44:36  <jtimon> sipa: right, so there's no difference between JSON RPC argument vs URI, right?
 908 2017-07-17T18:44:47  <sipa> jtimon: yes there is
 909 2017-07-17T18:45:04  <sipa> jtimon: with URI based approaches, we can avoid the need for applications to know what wallet they're talking to
 910 2017-07-17T18:45:13  <sipa> or even know that there is such a thing as multiwallet
 911 2017-07-17T18:45:23  <jtimon> I thought you just said there isn't an example of what ryanofsky was asking for?
 912 2017-07-17T18:45:30  <jtimon> I'm getting more confused, sorry
 913 2017-07-17T18:45:37  <sipa> jtimon: sigh... that was about URI path vs URI query
 914 2017-07-17T18:45:42  <jtimon> I'll read the full conversation
 915 2017-07-17T18:46:09  <ryanofsky> jtimon, talking about 3 different things. (1) wallet in jsonrpc param (2) wallet in uri query param (3) wallet in uri-path
 916 2017-07-17T18:46:13  <jtimon> I don't think ryanofsky was asking anything about URI query, I know I wasn't
 917 2017-07-17T18:46:18  <BlueMatt> sipa: but thats my point...we cant cause none of the client libraries support it, and they're all like barely maintained last I heard
 918 2017-07-17T18:46:36  <sipa> ryanofsky: every JSON-RPC library supports passing in a URI
 919 2017-07-17T18:46:39  <sipa> eh, BlueMatt ^
 920 2017-07-17T18:46:51  <sipa> BlueMatt: the bitcoin specific shims can be trivially patched to pass that through
 921 2017-07-17T18:47:28  <sipa> adding a named wallet arg everywhere is far harder, and requires logic that imho is totally unneeded at that level
 922 2017-07-17T18:47:28  <jtimon> ryanofsky: and who is defending 2 ?
 923 2017-07-17T18:48:00  <jtimon> ryanofsky: I really thought we were only duscussing 1 vs 3 already, sorry
 924 2017-07-17T18:48:25  *** THoVer has joined #bitcoin-core-dev
 925 2017-07-17T18:48:38  <sipa> jtimon: the main discussion is (1) vs (3)... though ryanofsky has suggested that he'd prefer (2) over (3)
 926 2017-07-17T18:48:40  <ryanofsky> i'm defending 2. i think there are practical tradeoffs between 1 & 2, but that 3 has no practical advantages over either and has disadvange of introducing undocumented half-baked url scheme
 927 2017-07-17T18:48:43  <BlueMatt> sipa: you could add a shim that passes the wallet arg in everywhere, too, which is already supported by some rpc client libraries, and all of this debate is useless if we have a process split anyway, cause then its about port numbers anyway
 928 2017-07-17T18:49:01  <BlueMatt> at least then we wont have new endpoints to maintain, just an extra arg that we can ignore
 929 2017-07-17T18:49:06  <sipa> BlueMatt: port numbers are also part of the URI
 930 2017-07-17T18:49:11  <jtimon> ok, I missed that, as said I will read the beginning of the discussion...
 931 2017-07-17T18:49:21  <BlueMatt> yes, but are treated differently by some rpc client software :p
 932 2017-07-17T18:49:27  <sipa> ?
 933 2017-07-17T18:49:48  <BlueMatt> well apparently at least python-bitcoinrpc does not support endpoints, but does, obviously, already support a different port to connect to
 934 2017-07-17T18:49:53  <BlueMatt> or so I'm told
 935 2017-07-17T18:49:58  <sipa> yes, but that's easy to fix
 936 2017-07-17T18:50:14  <sipa> and doesn't change that's better if client libraries don't need to know what wallet they're connected to
 937 2017-07-17T18:50:35  <jtimon> yeah, don't know python-bitcoinrpc but I can't imagine how it wouldn't be trivial to adapt either way
 938 2017-07-17T18:50:47  <ryanofsky> BlueMatt, python-bitcoinrpc doesn't support multiple endpoints currently, you have to choose one in advance if you want to write a test that uses multiple wallets for example. but jonas pr changes that
 939 2017-07-17T18:51:08  <BlueMatt> ohoh, wait, so it does support endpoints but you just need multiple AuthServiceProxy's for it?
 940 2017-07-17T18:51:10  <jtimon> afk
 941 2017-07-17T18:51:12  <BlueMatt> wait, that might change my view
 942 2017-07-17T18:51:12  <BlueMatt> ugh
 943 2017-07-17T18:51:14  <BlueMatt> i give up
 944 2017-07-17T18:51:18  <ryanofsky> BlueMatt, exactly
 945 2017-07-17T18:51:30  <BlueMatt> oh, well i mean thats kinda more analygous to the port number changes :(
 946 2017-07-17T18:51:33  <BlueMatt> lol, sorry sipa
 947 2017-07-17T18:51:59  <sipa> ryanofsky: i think that you do bring up a good point that there is a risk in creation a half-baked url scheme
 948 2017-07-17T18:52:11  <ryanofsky> sipa, that is why i am fine with 2
 949 2017-07-17T18:52:34  <sipa> ryanofsky: i believe (2) has more risk in going the wrong way than (3)
 950 2017-07-17T18:53:02  <sipa> and i guess part of that argument is aesthetics
 951 2017-07-17T18:53:05  <ryanofsky> i also want to point out that there we are talking about 1 practical tradeoff between 1 & 2/3, there are other practical advantages to 1 like not having to modify bitcoin-cli
 952 2017-07-17T18:53:15  <BlueMatt> can we use the lsb of the next blockhash?
 953 2017-07-17T18:54:03  <ryanofsky> sipa, ok that is what i think i'm not understanding. is there more to the argument than aesthetics...
 954 2017-07-17T18:54:05  <sipa> ryanofsky: i am fine with (1) over (2)/(3) if we believe the separation isn't thought out enough
 955 2017-07-17T18:54:40  <sipa> ryanofsky: it's a slippery slope argument, so you can counter anything i say with "well, we can just decide not to do that"
 956 2017-07-17T18:55:06  <sipa> ryanofsky: but i believe there is a risk that (2) will make it too easy for us to say "oh, let's put the currency unit in the URI"
 957 2017-07-17T18:55:09  <ryanofsky> sipa, not sure i understand an example of something bad....
 958 2017-07-17T18:55:30  <ryanofsky> you were saying some other parameters are bad to put in query strings?
 959 2017-07-17T18:56:53  <sipa> actually, i change my mind - that wouldn't be bad
 960 2017-07-17T18:57:36  <ryanofsky> also just to list other practical advantages i see in (1) over (2/3). Requires no changes to bitcoin-cli. Is properly documented, easy to understand, just a param. Encourages named arguments. Allows checking wallet name for safety even with multiprocess.
 961 2017-07-17T18:58:08  <sipa> so yes, my preference for (3) over (2) is aesthetics (and, _if_ we have a well thought-out separation, i also think (2) does not really have advantages over (3))
 962 2017-07-17T18:58:50  *** promag has joined #bitcoin-core-dev
 963 2017-07-17T18:59:21  <ryanofsky> agree maybe (2) may not have advantages over (3) if you have a well-thought uri-path schema
 964 2017-07-17T18:59:52  <sipa> and things like a currency type or timeout can still be query string options rather than paths
 965 2017-07-17T19:00:21  <ryanofsky> i definitely have opposite aesthetics though, straight key=value named argument vastly preferable to me to inflexible /positional/path/stuff
 966 2017-07-17T19:01:01  *** d_t_ has joined #bitcoin-core-dev
 967 2017-07-17T19:01:28  <sipa> well, (purely aesthetics argument), paths feel like "i am now talking to a different subsystem!"; query options feel like "here is some extra stuff that may or may not affect how you're interpreting my request"
 968 2017-07-17T19:01:59  *** AaronvanW has joined #bitcoin-core-dev
 969 2017-07-17T19:02:55  <ryanofsky> sure, i can see that
 970 2017-07-17T19:03:29  <sipa> and given an intention (if we agree to that) to move the wallet out, i think it makes sense to treat it as a different subsystem
 971 2017-07-17T19:03:41  <morcos> at the risk of derailing this convo on the brink of agreement, sipa: achow: do you still want #10579 for 0.15, it doesn't look as far along as 10571
 972 2017-07-17T19:03:41  <ryanofsky> maybe i don't understand what you see in multiprocess world. i see wallet=filename still being something you can specify for safety
 973 2017-07-17T19:03:42  <gribble> https://github.com/bitcoin/bitcoin/issues/10579 | [RPC] Split signrawtransaction into wallet and non-wallet RPC command by achow101 · Pull Request #10579 · bitcoin/bitcoin · GitHub
 974 2017-07-17T19:04:16  <ryanofsky> but you are seeing us do this elaborate /v1/wallet/ /v1/node thing and then the /v1/wallet stuff goes in the trash because it is no longer a "separate subsystem"?
 975 2017-07-17T19:04:24  <morcos> oops achow101 ^
 976 2017-07-17T19:04:55  <sipa> ryanofsky: no, /v1/wallet would remain - the wallet process just would not expose /v1/node anymore
 977 2017-07-17T19:05:15  <ryanofsky> sipa, ok. that is aesthetically ugly to me :)
 978 2017-07-17T19:05:24  <sipa> ryanofsky: please clarify
 979 2017-07-17T19:05:54  *** paveljanik has joined #bitcoin-core-dev
 980 2017-07-17T19:05:54  *** paveljanik has joined #bitcoin-core-dev
 981 2017-07-17T19:06:38  <sipa> (as in, i'd genuinely interested in hearing why)
 982 2017-07-17T19:06:41  <sipa> *i'm
 983 2017-07-17T19:06:53  <ryanofsky> wallet filename at that point is no longer "specifying a subsystem". it is just redundant at that point. we have to go on treating it as this magical thing different from other parameters forever
 984 2017-07-17T19:07:12  <sipa> ryanofsky: well i expect one process to remain capable of handling multiple wallets
 985 2017-07-17T19:07:49  <sipa> a lightweight node is far cheaper than a full node, but handling an individual wallet compared to that is still orders of magnitude less
 986 2017-07-17T19:08:21  <achow101> morcos: I would like to have it in 0.15 but it hasn't been getting any review
 987 2017-07-17T19:09:19  <sipa> ryanofsky: actually, no
 988 2017-07-17T19:09:42  <sipa> ryanofsky: the whole point of having it in a URI is that it shouldn't be treated as part of the interface
 989 2017-07-17T19:09:54  *** BashCo has quit IRC
 990 2017-07-17T19:10:19  *** helo has quit IRC
 991 2017-07-17T19:10:31  <sipa> someone could create a new lightweight implementation that has the same API (unlikely, i know), which only exposes what we have now under /v1/wallet/[walletname], but just exposes it as '/blah'
 992 2017-07-17T19:10:33  *** BashCo has joined #bitcoin-core-dev
 993 2017-07-17T19:10:34  *** helo has joined #bitcoin-core-dev
 994 2017-07-17T19:12:40  <jnewbery> sorry, I was away from my desk. Seems like I missed out on all the fun.
 995 2017-07-17T19:12:42  <sipa> however, if people feel that we haven't thought through the implication of that, and whether we can do that separation cleanly... we should just do (1)
 996 2017-07-17T19:12:54  <jnewbery> At the risk of going over old ground, I prefer (3) for a couple of reasons:
 997 2017-07-17T19:13:20  <jnewbery> 1. each wallet is conceptually a separate resource, so it makes sense to me to have different URIs
 998 2017-07-17T19:13:39  <jnewbery> That's true whether or not we go for wallet separation in future
 999 2017-07-17T19:14:20  <jnewbery> *wallet process separation
1000 2017-07-17T19:14:22  <ryanofsky> thanks jnewbery, you are finally writing the documentatino i was asking for :)
1001 2017-07-17T19:14:58  <jnewbery> 2. It offers a smoother upgrade path for clients if we do go for wallet process separation and each wallet binds to its own port
1002 2017-07-17T19:15:27  <jnewbery> namely: change the endpoint now to /wallet/<blah>, and then change the endpoint later to <wallet port>
1003 2017-07-17T19:15:53  *** THoVer has quit IRC
1004 2017-07-17T19:16:13  <jnewbery> I'm *much* less worried than ryanofsky about implementing a uri scheme now that we want to get rid of later. This should all be considered unstable/experimental anyway
1005 2017-07-17T19:16:26  *** promag has quit IRC
1006 2017-07-17T19:16:35  <jnewbery> yes, I'll happily write documentation
1007 2017-07-17T19:17:20  <sipa> ryanofsky: if anything - thanks for discussing this; it's made your point clearer to me, and helped me understand my own preferences better
1008 2017-07-17T19:17:49  <ryanofsky> your second reason is reason sipa & gmaxwell like approaches (2)&(3) over approach (1), in that respect there is no distiniction between (2)/(3), and countervailing tradeoffs like having to modify bitcoin-cli and other things i mentioned above
1009 2017-07-17T19:18:38  <ryanofsky> and yes, it is clear that i am wayyy more concerned with backwards compatibility than other people
1010 2017-07-17T19:19:15  <jnewbery> In general, I'm also concerned about backwards compatibility. But in this specific case, I'm not
1011 2017-07-17T19:19:20  <ryanofsky> i'm probably just an outlier in that respect
1012 2017-07-17T19:20:08  <instagibbs> jnewbery, a brief(!) recap in the PR itself on the design choice being made would be nice for review/historicity sake
1013 2017-07-17T19:21:07  <jnewbery> > countervailing tradeoffs like having to modify bitcoin-cli
1014 2017-07-17T19:21:25  <ryanofsky> yes named arguments require no changes to bitcoin-cli
1015 2017-07-17T19:21:38  <sipa> ok, i just looked over #10849, and it is suffuciently simple that i don't think i care about implementation complexity compared to 10829
1016 2017-07-17T19:21:39  <gribble> https://github.com/bitcoin/bitcoin/issues/10849 | Multiwallet: simplest endpoint support by jonasschnelli · Pull Request #10849 · bitcoin/bitcoin · GitHub
1017 2017-07-17T19:22:15  <jnewbery> I think (2) is better in that respect. We need to modify bitcoin-cli, but we have those changes already coded. With (1), every script that calls wallet methods using bitcoin-cli needs to be changed because positional arguments are no longer supported
1018 2017-07-17T19:22:24  <jnewbery> or have I misunderstood?
1019 2017-07-17T19:22:30  *** d_t has joined #bitcoin-core-dev
1020 2017-07-17T19:22:45  *** tiagotrs has joined #bitcoin-core-dev
1021 2017-07-17T19:22:52  <sipa> jnewbery: that is also a good argument
1022 2017-07-17T19:23:21  <ryanofsky> jnewbery, you understood. i see that is an argument the other way because named arguments are safer
1023 2017-07-17T19:24:22  <jnewbery> with (2), the bitcoin-cli caller needs to change to include a `-usewallet` argument. With (1) the entire invocation needs to change
1024 2017-07-17T19:24:37  <ryanofsky> jnewbery, correct
1025 2017-07-17T19:24:59  <jnewbery> so with (2), it's just as safe. There's no default wallet - it has to be explicitly specified
1026 2017-07-17T19:25:18  <ryanofsky> i'm talking about general safety of named parameters vs positional arguments
1027 2017-07-17T19:25:51  <ryanofsky> i don't think discouraging positional arguments is bad, i actually think it is good
1028 2017-07-17T19:25:52  *** d_t_ has quit IRC
1029 2017-07-17T19:25:59  <jnewbery> oh, absolutely agree there - everyone should use named. But that's an orthogonal point
1030 2017-07-17T19:26:02  <sipa> ryanofsky: that seems orthogonal
1031 2017-07-17T19:26:05  <ryanofsky> i think changes to bitcoin-cli are simple but ugly
1032 2017-07-17T19:26:10  <ryanofsky> anyway these are minor points
1033 2017-07-17T19:26:30  <ryanofsky> i think we all understand tradeoffs between 1 / 2&3 at this point?
1034 2017-07-17T19:27:44  <ryanofsky> for those who have clear notions of what "conceptually a separate resource" means & who don't care about backwards compatibility, there is no difference between 2&3
1035 2017-07-17T19:29:12  <sipa> for those who don't have clear notions, you mean?
1036 2017-07-17T19:29:56  <ryanofsky> i'm saying i don't know clearly what "separate resource" means. it just seems like an arbitrary distinction
1037 2017-07-17T19:30:56  <ryanofsky> it just seems weird to me that you'd want to structure a path scheme around wallet filename, but if you're confident that this is the way to go, then great
1038 2017-07-17T19:31:04  <sipa> how about this: all parts of a request that are expected to be identical between all calls made by a single client application should go into a path
1039 2017-07-17T19:31:46  <jnewbery> Yes, I think we all understand the tradeoffs. My preference order is still 3 > 2 > 1, but I'm happy with any of them going in now, and then coming up with a stable design for all of this in time for v0.16.
1040 2017-07-17T19:32:18  *** promag has joined #bitcoin-core-dev
1041 2017-07-17T19:32:29  <ryanofsky> sipa, to me it's ugly you even want to make that distinction. aesthetically i prefer if all parts of request should just be treated as similarly as possible
1042 2017-07-17T19:33:26  <sipa> ryanofsky: actually, that sentence applies to (2) and (3) equally
1043 2017-07-17T19:33:42  <sipa> so replace 'path' with 'uri' in it
1044 2017-07-17T19:33:45  <ryanofsky> there are practical reasons (imo weak ones for wanting to make wallet special enough to go in url rather than json request). but making it root of brand new uri schema seems overboard to me
1045 2017-07-17T19:34:00  <jtimon> sipa: I guess we don't move "jsonrpc": "1.0" to the path because it's part of the rpc scheme specification or something?
1046 2017-07-17T19:34:27  <sipa> jtimon: no, it's part of the JSON-RPC spec
1047 2017-07-17T19:34:38  <sipa> oh, that's what you mean; yes
1048 2017-07-17T19:34:41  <ryanofsky> in (1) wallet is just one of many normal params. in (2) wallet is special enough to be a url param. in (3) wallet is root of a new uri-scheme
1049 2017-07-17T19:34:51  <jtimon> right, that's what I meant, but didn't rename json-rpc name
1050 2017-07-17T19:35:19  <ryanofsky> uri-path scheme i mean
1051 2017-07-17T19:35:22  <jtimon> wouldn't putting the wallet there violate the json-rpc spec ?
1052 2017-07-17T19:35:30  <sipa> no
1053 2017-07-17T19:35:40  <sipa> it's just a different URL you're using
1054 2017-07-17T19:37:55  <jtimon> no, I mean, putting wallet in the json data alongside method, jsonrpc, params and id
1055 2017-07-17T19:38:14  <ryanofsky> jtimon, that isn't (1) (2) or (3).
1056 2017-07-17T19:38:15  <sipa> that's not what's being suggested
1057 2017-07-17T19:38:26  <ryanofsky> (1) is just sticking it into params
1058 2017-07-17T19:38:28  <sipa> (1) suggests making the wallet part of 'params'
1059 2017-07-17T19:38:33  <jtimon> oh, I see
1060 2017-07-17T19:43:17  *** Chris_Stewart_5 has quit IRC
1061 2017-07-17T19:47:43  *** chjj has quit IRC
1062 2017-07-17T19:55:00  *** jamesob__ has joined #bitcoin-core-dev
1063 2017-07-17T19:55:35  *** jamesob has quit IRC
1064 2017-07-17T19:55:57  *** corebob has joined #bitcoin-core-dev
1065 2017-07-17T19:57:25  <promag> BlueMatt: saw some rpc functions, all have spaces in ()
1066 2017-07-17T19:57:46  *** Chris_Stewart_5 has joined #bitcoin-core-dev
1067 2017-07-17T19:58:45  <BlueMatt> promag: hmm, ok
1068 2017-07-17T20:00:17  <morcos> wumpus: not sure where we are with feature freeze, but i think #10707 is going to make it, looks ready for merge
1069 2017-07-17T20:00:19  <gribble> https://github.com/bitcoin/bitcoin/issues/10707 | Better API for estimatesmartfee RPC by morcos · Pull Request #10707 · bitcoin/bitcoin · GitHub
1070 2017-07-17T20:00:28  <morcos> #10672 can also be merged
1071 2017-07-17T20:00:30  <gribble> https://github.com/bitcoin/bitcoin/issues/10672 | Avoid division by zero in the case of a corrupt estimates file by practicalswift · Pull Request #10672 · bitcoin/bitcoin · GitHub
1072 2017-07-17T20:02:14  <BlueMatt> we should probably pull an 0.14 and just say that we're frozen with an exception for things already tagged that make it in the next day or two?
1073 2017-07-17T20:02:41  *** Aaronvan_ has joined #bitcoin-core-dev
1074 2017-07-17T20:03:52  <morcos> someone PLEASE tag #10830
1075 2017-07-17T20:03:54  <gribble> https://github.com/bitcoin/bitcoin/issues/10830 | [WIP] [wallet] keypool restore by jnewbery · Pull Request #10830 · bitcoin/bitcoin · GitHub
1076 2017-07-17T20:03:59  <morcos> I keep forgetting about it b/c its not on the milestone list
1077 2017-07-17T20:04:25  <morcos> sipa: aren't you the one that was threatening to rip the entire wallet out if we didn't get a version of that in
1078 2017-07-17T20:04:37  <sipa> morcos: lol
1079 2017-07-17T20:04:58  <sipa> tagged
1080 2017-07-17T20:05:03  <morcos> thanks!
1081 2017-07-17T20:05:08  <jnewbery> I'm working on a cut-down version of #10830
1082 2017-07-17T20:05:09  <gribble> https://github.com/bitcoin/bitcoin/issues/10830 | [WIP] [wallet] keypool restore by jnewbery · Pull Request #10830 · bitcoin/bitcoin · GitHub
1083 2017-07-17T20:05:19  <jnewbery> probably under a different PR number - sorry!
1084 2017-07-17T20:05:21  *** AaronvanW has quit IRC
1085 2017-07-17T20:05:42  <jnewbery> I think the prevailing view is we don't need the node sync pause stuff for 0.15
1086 2017-07-17T20:06:16  <sipa> jnewbery: you'd need to do something, though
1087 2017-07-17T20:06:20  <sipa> what is your suggestion?
1088 2017-07-17T20:07:10  <jnewbery> I'm trying to understand what's required. You've mentioned before that HD split makes things worse, but I can't understand why that would be true
1089 2017-07-17T20:07:34  <sipa> it doesn't; i was confused
1090 2017-07-17T20:07:46  <jtimon> so, regarding #9806 txoutsbyaddress, txoutsbyscript and all that...what are the plans for 0.15 again (if any), it seems I may have misunderstood things there
1091 2017-07-17T20:07:47  <jnewbery> ok, good
1092 2017-07-17T20:07:48  <gribble> https://github.com/bitcoin/bitcoin/issues/9806 | txoutsbyaddress index (take 3) by droark · Pull Request #9806 · bitcoin/bitcoin · GitHub
1093 2017-07-17T20:08:14  <jnewbery> so, I'll keep the stuff that marks all keys up to a used key as used
1094 2017-07-17T20:08:56  <jnewbery> gmaxwell says "we could couple that with something that prolongs keeping an encrypted wallet unlocked while syncing/rescanning is running". I'm just looking at how locking/unlocking works to understand what's required there
1095 2017-07-17T20:09:45  <sipa> i think you can just shutdown when the keypool goes below some threshold
1096 2017-07-17T20:10:10  <sipa> which can only happen when you're recovering from an old wallet backup anyway
1097 2017-07-17T20:10:51  <jnewbery> hows that? What if your wallet is encrypted and you can't top up?
1098 2017-07-17T20:11:11  <sipa> then you have a problem
1099 2017-07-17T20:11:21  *** Aaronvan_ has quit IRC
1100 2017-07-17T20:11:32  <sipa> because you're going to silently miss transactions
1101 2017-07-17T20:11:57  *** AaronvanW has joined #bitcoin-core-dev
1102 2017-07-17T20:12:54  <jnewbery> right. Sorry - I don't understand how your keypool can only go below a threshold if you're recovering from an old wallet backup
1103 2017-07-17T20:13:31  <sipa> during normal operation, you never see a key used on the network that you didn't create with getnewaddress, which will make you top up
1104 2017-07-17T20:16:02  *** AaronvanW has quit IRC
1105 2017-07-17T20:16:24  <jnewbery> ok, so I get a bunch of adddresses with getnewaddress, I hand them out, my wallet locks, and then I start seeing transactions to those addresses. What next? Isn't my unused keypool running down as I see those transactions?
1106 2017-07-17T20:16:44  <sipa> jnewbery: getnewaddress already marked those keys as used
1107 2017-07-17T20:16:59  <sipa> it can refuse to give you a new one before topping up
1108 2017-07-17T20:17:05  <jnewbery> ah, ok
1109 2017-07-17T20:17:13  <sipa> it does now, but the threshold is 0
1110 2017-07-17T20:17:18  <sipa> that's probably too low, but easy to change
1111 2017-07-17T20:17:50  <sipa> if you're able to avoid hitting a keypool of 0 when its maximum is 100, you're certainly able to avoid hitting 100 when the default is 1000
1112 2017-07-17T20:18:03  <jnewbery> ok, I'll take a look. Thanks
1113 2017-07-17T20:21:41  <promag> https://github.com/bitcoin/bitcoin/pull/9502 it's supposed to keep syncing headers? sipa?
1114 2017-07-17T20:22:22  <sipa> promag: i'm not sure what it's supposed to do, but i believe that is what it does yes
1115 2017-07-17T20:29:21  *** harrymm has quit IRC
1116 2017-07-17T20:30:58  <BlueMatt> sipa: can you update the state of #10526?
1117 2017-07-17T20:30:59  <gribble> https://github.com/bitcoin/bitcoin/issues/10526 | Force on-the-fly compaction during pertxout upgrade by sipa · Pull Request #10526 · bitcoin/bitcoin · GitHub
1118 2017-07-17T20:31:34  <BlueMatt> can we confirm if we need it for 15 or not?
1119 2017-07-17T20:34:57  <sipa> BlueMatt: willdo
1120 2017-07-17T20:35:15  *** chjj has joined #bitcoin-core-dev
1121 2017-07-17T20:38:53  <jnewbery> sipa: if we shutdown when the keypool goes below a threshold, how would I start with an old encrypted wallet that has fewer than the minimum threshold keypool? It'll shutdown before I have a change to unlock the wallet
1122 2017-07-17T20:40:32  <sipa> jnewbery: i don't know
1123 2017-07-17T20:45:41  *** harrymm has joined #bitcoin-core-dev
1124 2017-07-17T20:46:03  *** Dyaheon has quit IRC
1125 2017-07-17T20:46:33  *** Dyaheon has joined #bitcoin-core-dev
1126 2017-07-17T20:54:16  <jtimon> btw, with gettxout I think it should either include confirmed utxos when calling with include_mempool or have include_mempool renamed to mempool_only or something of the sort. At the very very least s/Whether to include the mempool/Only search in the mempool. Default: true/
1127 2017-07-17T20:54:19  <jtimon> thoughts ?
1128 2017-07-17T20:55:13  <sipa> jtimon: include_mempool is the wrong name
1129 2017-07-17T20:55:31  <sipa> it either presents the view of the utxo at the last block
1130 2017-07-17T20:55:43  <sipa> or the one as seen by the mempool
1131 2017-07-17T20:56:50  <jtimon> right, my point is that if we want to maintain the name, we can first consider the mempool, if not, the current utxo; and the caller can check whether "confirmations" == 0 or not
1132 2017-07-17T20:57:12  <jtimon> but I take it as you prefer just renaming, right?
1133 2017-07-17T20:57:23  <sipa> or properly documenting
1134 2017-07-17T20:57:43  <sipa> but the RPC is about viewing the utxo set... not random access to txouts
1135 2017-07-17T20:58:12  <sipa> we have two utxo sets... the one defined by the blockchain, and the one defined by the blockchain+mempool
1136 2017-07-17T20:58:14  *** jamesob has joined #bitcoin-core-dev
1137 2017-07-17T20:58:32  *** promag has quit IRC
1138 2017-07-17T20:59:14  *** nakaluna has quit IRC
1139 2017-07-17T21:00:16  <jnewbery> sipa: I can think of a couple of good solutions to the old encrypted wallet at start: 1. have a bitcoin-wallet util that can topup the keypool offline. 2. have a `loadwallet` RPC that can decrypt on load
1140 2017-07-17T21:00:16  *** jamesob__ has quit IRC
1141 2017-07-17T21:00:46  <jnewbery> obviously neither of those are in v0.15. It seems a shame to merge something that could make an encrypted wallet file unloadable
1142 2017-07-17T21:01:59  <jnewbery> there would be one way to recover a blocked wallet: invalidateblock at the wallet's best block, load and unlock the wallet, topup keypool, then reconsiderblock. But I don't think we should be telling users to do that!
1143 2017-07-17T21:02:37  *** AaronvanW has joined #bitcoin-core-dev
1144 2017-07-17T21:02:42  <jtimon> sipa: mhmm, but a confirmed utxo won't appear if you call with include_mempool
1145 2017-07-17T21:03:25  <sipa> jtimon: of course not
1146 2017-07-17T21:03:37  <sipa> it is not an unspent output, when looking at the mempool
1147 2017-07-17T21:03:48  <sipa> wait
1148 2017-07-17T21:03:54  <sipa> i'm not sure what you're saying
1149 2017-07-17T21:04:54  <sipa> jtimon: my answer is about a transaction that is unspent in the chain, but spent by a mempool tx
1150 2017-07-17T21:05:15  <jtimon> right, that won't appear if you chose include_mempoo=true
1151 2017-07-17T21:05:44  <sipa> yes, intentionally
1152 2017-07-17T21:05:49  <jtimon> ok
1153 2017-07-17T21:06:02  <sipa> because it is not an unspent output when looking at the mempool
1154 2017-07-17T21:06:52  *** laurentmt has joined #bitcoin-core-dev
1155 2017-07-17T21:07:09  <jtimon> oh, I see, but if it's both spent in the chain and the mempool it will appear, I was missing that, thanks
1156 2017-07-17T21:07:39  <sipa> unspent, you mean
1157 2017-07-17T21:07:59  <jtimon> perhaps we should test that too
1158 2017-07-17T21:08:06  <jtimon> yeah, unspent sorry
1159 2017-07-17T21:08:39  <jtimon> ok, so I think I'll write a PR correcting the documentation and testing that case
1160 2017-07-17T21:09:10  <sipa> cool
1161 2017-07-17T21:10:35  <jtimon> but before closing #10822, I would like to know more about what the general thoughts about gettxoutbyaddress, gettxoutbyscript and all that
1162 2017-07-17T21:10:36  <gribble> https://github.com/bitcoin/bitcoin/issues/10822 | RPC: Also serve txo from gettxout (not just utxo and mempool) by jtimon · Pull Request #10822 · bitcoin/bitcoin · GitHub
1163 2017-07-17T21:11:21  <sipa> jtimon: i believe other people have different opinions, but imho that does not belong in core
1164 2017-07-17T21:11:24  *** nakaluna has joined #bitcoin-core-dev
1165 2017-07-17T21:12:07  <sipa> or at least only if we modularize the code enough so that it's a totally separately pluggable thing
1166 2017-07-17T21:14:27  <jtimon> by thought was to have something like -scriptpubkeyindex analogous to txindex or something like that, but I see you don't like having -txindex already
1167 2017-07-17T21:14:46  <sipa> yes
1168 2017-07-17T21:15:11  <sipa> i'm very strongly opposed to any functionality that requires having a fully indexed blockchain
1169 2017-07-17T21:15:16  <jtimon> of course I don't need this to be in core for my purposes, but since people were talking about it I was trying to find synergies
1170 2017-07-17T21:15:34  <sipa> if it's just the utxo set... it's less bad, but i still think it's beyond our scope
1171 2017-07-17T21:16:00  <jtimon> but a -scriptpubkeyindex only for current utxo would be more acceptable?
1172 2017-07-17T21:16:07  <jtimon> ok
1173 2017-07-17T21:18:15  <jtimon> thanks, I will ask on the next meeting about if I haven't closed #10822 by the time if more people give me their opinion
1174 2017-07-17T21:18:17  <gribble> https://github.com/bitcoin/bitcoin/issues/10822 | RPC: Also serve txo from gettxout (not just utxo and mempool) by jtimon · Pull Request #10822 · bitcoin/bitcoin · GitHub
1175 2017-07-17T21:19:11  <sipa> i think we're a bit too busy with 0.15 :)
1176 2017-07-17T21:20:49  *** jamesob has quit IRC
1177 2017-07-17T21:21:22  *** jamesob has joined #bitcoin-core-dev
1178 2017-07-17T21:23:55  *** earlz has quit IRC
1179 2017-07-17T21:25:53  *** jamesob has quit IRC
1180 2017-07-17T21:29:08  *** earlz has joined #bitcoin-core-dev
1181 2017-07-17T21:33:36  *** earlz has quit IRC
1182 2017-07-17T21:33:48  *** earlz has joined #bitcoin-core-dev
1183 2017-07-17T21:35:03  *** Chris_Stewart_5 has quit IRC
1184 2017-07-17T21:38:53  <sipa> jnewbery: yeah, i don't know
1185 2017-07-17T21:39:11  <sipa> a cleaner solution is to actually support stopping a sync, and allowing it to continue with a keypool unlock
1186 2017-07-17T21:39:39  <sipa> but this is an unusual situation, which will only be reached when recovering from a backup anyway
1187 2017-07-17T21:41:20  <jcorgan> just fyi, we (gnuradio project) just got a github PR with a malware PDF attached to a comment, looked automated
1188 2017-07-17T21:41:54  <jcorgan> well, assuming it is malware, virustotal found 0 hits
1189 2017-07-17T21:44:33  <sipa> jcorgan: good to know, thanks
1190 2017-07-17T21:51:47  <jtimon> sipa: yeah, sure, no hurry on my part, I just thought something re gettxoutbyaddress for 0.15, I guess it was just for after 0.15
1191 2017-07-17T21:52:46  *** mmgen has quit IRC
1192 2017-07-17T21:56:32  *** earlz has quit IRC
1193 2017-07-17T21:56:43  *** earlz has joined #bitcoin-core-dev
1194 2017-07-17T21:57:14  *** jtimon has quit IRC
1195 2017-07-17T21:59:22  *** CubicEarth has joined #bitcoin-core-dev
1196 2017-07-17T22:01:02  *** d9b4bef9 has quit IRC
1197 2017-07-17T22:01:57  *** CubicEarth has quit IRC
1198 2017-07-17T22:02:08  *** d9b4bef9 has joined #bitcoin-core-dev
1199 2017-07-17T22:07:51  *** jannes has quit IRC
1200 2017-07-17T22:08:26  *** CubicEarth has joined #bitcoin-core-dev
1201 2017-07-17T22:13:03  <bitcoin-git> [bitcoin] sipa pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/0b019357ff09...fee0d803fb55
1202 2017-07-17T22:13:03  <bitcoin-git> bitcoin/master 8276e70 Chris Stewart: Adding assert to avoid a memory access violation inside of PartialMerkleTree::CalcHash()...
1203 2017-07-17T22:13:04  <bitcoin-git> bitcoin/master fee0d80 Pieter Wuille: Merge #9980: Fix mem access violation merkleblock...
1204 2017-07-17T22:13:17  <bitcoin-git> [bitcoin] sipa closed pull request #9980: Fix mem access violation merkleblock (master...fix_mem_access_violation_merkleblock) https://github.com/bitcoin/bitcoin/pull/9980
1205 2017-07-17T22:16:34  *** laurentmt has quit IRC
1206 2017-07-17T22:18:07  *** jcorgan has quit IRC
1207 2017-07-17T22:20:07  *** chjj has quit IRC
1208 2017-07-17T22:27:29  *** dermoth has quit IRC
1209 2017-07-17T22:27:37  *** spinza has quit IRC
1210 2017-07-17T22:27:55  *** dermoth has joined #bitcoin-core-dev
1211 2017-07-17T22:28:43  *** CubicEarth has quit IRC
1212 2017-07-17T22:30:20  *** CubicEarth has joined #bitcoin-core-dev
1213 2017-07-17T22:31:49  *** CubicEarth has quit IRC
1214 2017-07-17T22:32:39  *** chjj has joined #bitcoin-core-dev
1215 2017-07-17T22:32:41  *** Aaronvan_ has joined #bitcoin-core-dev
1216 2017-07-17T22:33:32  *** spinza has joined #bitcoin-core-dev
1217 2017-07-17T22:35:50  <bitcoin-git> [bitcoin] achow101 opened pull request #10857: [RPC] Add a deprecation warning to getinfo's output (master...deprecate-getinfo) https://github.com/bitcoin/bitcoin/pull/10857
1218 2017-07-17T22:36:04  *** AaronvanW has quit IRC
1219 2017-07-17T22:37:58  *** promag has joined #bitcoin-core-dev
1220 2017-07-17T22:42:03  *** discreteunit has joined #bitcoin-core-dev
1221 2017-07-17T22:43:46  *** tiagotrs has quit IRC
1222 2017-07-17T22:50:18  *** Dyaheon has quit IRC
1223 2017-07-17T22:53:16  *** Dyaheon has joined #bitcoin-core-dev
1224 2017-07-17T22:53:43  *** jcorgan has joined #bitcoin-core-dev
1225 2017-07-17T23:08:14  *** BashCo has quit IRC
1226 2017-07-17T23:09:04  *** BashCo has joined #bitcoin-core-dev
1227 2017-07-17T23:13:02  *** rockhouse has joined #bitcoin-core-dev
1228 2017-07-17T23:14:51  <bitcoin-git> [bitcoin] achow101 opened pull request #10858: [RPC] Add "errors" field to getblockchaininfo and unify "errors" field in get*info RPCs (master...getblockchaininfo-errors) https://github.com/bitcoin/bitcoin/pull/10858
1229 2017-07-17T23:26:10  *** discreteunit has quit IRC
1230 2017-07-17T23:27:49  *** chjj has quit IRC
1231 2017-07-17T23:34:46  *** justan0theruser has joined #bitcoin-core-dev
1232 2017-07-17T23:36:57  *** justanotheruser has quit IRC
1233 2017-07-17T23:37:36  *** coredump_ has joined #bitcoin-core-dev
1234 2017-07-17T23:41:11  *** chjj has joined #bitcoin-core-dev
1235 2017-07-17T23:41:22  *** CubicEarth has joined #bitcoin-core-dev
1236 2017-07-17T23:48:13  *** nakaluna has quit IRC
1237 2017-07-17T23:53:05  *** Aaronvan_ has quit IRC
1238 2017-07-17T23:54:51  <bitcoin-git> [bitcoin] sipa pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/fee0d803fb55...75b5643c47c3
1239 2017-07-17T23:54:51  <bitcoin-git> bitcoin/master 439c4e8 Alex Morcos: Improve api to estimatesmartfee...
1240 2017-07-17T23:54:52  <bitcoin-git> bitcoin/master 06bcdb8 Alex Morcos: Convert named argument from nblocks to conf_target...
1241 2017-07-17T23:54:52  <bitcoin-git> bitcoin/master 75b5643 Pieter Wuille: Merge #10707: Better API for estimatesmartfee RPC...
1242 2017-07-17T23:55:15  <bitcoin-git> [bitcoin] sipa closed pull request #10707: Better API for estimatesmartfee RPC  (master...bettersmartfeeapi) https://github.com/bitcoin/bitcoin/pull/10707