1 2017-07-06T00:12:46  *** owowo has quit IRC
   2 2017-07-06T00:14:06  *** coredump_ has joined #bitcoin-core-dev
   3 2017-07-06T00:15:54  *** Chris_Stewart_5 has joined #bitcoin-core-dev
   4 2017-07-06T00:16:46  *** tmddzk has quit IRC
   5 2017-07-06T00:17:43  *** owowo has joined #bitcoin-core-dev
   6 2017-07-06T00:18:45  *** AaronvanW_ has quit IRC
   7 2017-07-06T00:31:21  *** PaulCapestany has joined #bitcoin-core-dev
   8 2017-07-06T00:35:17  *** PaulCapestany has quit IRC
   9 2017-07-06T00:44:46  *** CubicEarth has quit IRC
  10 2017-07-06T00:44:49  <kanzure> i am unsure of the interactions between MIN_FINAL_CHANGE and the targeted fee rate and whether that should be the assumed fee rate for eventually spending the change output.
  11 2017-07-06T00:48:24  <kanzure> oh, "achow101's implementation uses a 1008 block feerate estimate" for the change output amount check before decide burn to miner fee?
  12 2017-07-06T00:49:36  <achow101> kanzure: the 1008 block feerate estimate is for the cost of change. It's the maximum of the feerate and the min relay fee
  13 2017-07-06T00:50:23  <kanzure> "and now you're also throwing away the change output itself,so you are potentially overpaying the newly needed fee by double the cost of creating the change" <--- why not redo the final size estimate and calculate new fee, then redo coin selection for potentially fewer inputs? keep list of n best options, break after grinding for i dunno 10k rounds.
  14 2017-07-06T00:51:02  <gmaxwell> because complex hairball.
  15 2017-07-06T00:51:17  <gmaxwell> Achow's stuff doesn't have that issue, the branch and bound thing assumes always that there will be no change.
  16 2017-07-06T00:51:18  <kanzure> is there a writeup of a wishlist for simulators in this area, or is that also hairball land?
  17 2017-07-06T00:52:32  <kanzure> there was already some area in core that attempts to redo coin selection by increasing the amount and trying again; some of this could probably be consolidated.
  18 2017-07-06T00:56:15  <kanzure> i have this weird case where i have to use two "change" outputs, one of them i can burn to miner fee if it's too small, the other one i need to go back and pick other inputs until i can piggyback.  anyway, lots of questions around utxo results after actual usage, i will have to write a simulator at some point.
  19 2017-07-06T00:58:09  *** handlex has quit IRC
  20 2017-07-06T00:59:49  *** dabura667 has joined #bitcoin-core-dev
  21 2017-07-06T01:00:23  <kanzure> (can't help but think of this like iterative rocket equation calculation until elon musk is sure that his rocket will land at zero velocity with zero fuel left, except for coins we're not targeting total fee exhaustion of course.)
  22 2017-07-06T01:05:59  *** Ylbam has quit IRC
  23 2017-07-06T01:06:33  *** talmai has quit IRC
  24 2017-07-06T01:09:04  *** chjj has quit IRC
  25 2017-07-06T01:10:22  *** Murch has quit IRC
  26 2017-07-06T01:21:09  *** chjj has joined #bitcoin-core-dev
  27 2017-07-06T01:34:47  *** fanquake has joined #bitcoin-core-dev
  28 2017-07-06T01:37:19  <fanquake> Would anyone object to #8550 going into 0.15 ?
  29 2017-07-06T01:37:21  <gribble> https://github.com/bitcoin/bitcoin/issues/8550 | [Qt] Add interactive mempool graph by jonasschnelli · Pull Request #8550 · bitcoin/bitcoin · GitHub
  30 2017-07-06T01:43:45  *** Dyaheon has quit IRC
  31 2017-07-06T01:44:54  *** Dyaheon has joined #bitcoin-core-dev
  32 2017-07-06T01:45:15  *** Chris_Stewart_5 has quit IRC
  33 2017-07-06T01:47:22  <gmaxwell> :(
  34 2017-07-06T01:47:33  <gmaxwell> Thats the graph that doesn't break things up by feerate?
  35 2017-07-06T01:47:43  <gmaxwell> those sorts of graphs have had really bad effects in social media.
  36 2017-07-06T01:48:05  <gmaxwell> People flood with minrelay fee txn to push the numbers up. and then spam with OMG MEMPOOL FULL SELL BITCOINS NOW
  37 2017-07-06T01:48:35  <gmaxwell> Since rate breaking up graphs became more common those minrelay floods seem to have stopped.
  38 2017-07-06T02:08:39  <fanquake> Well we can adjust the graph to break the txs up and display however we'd like, but I think having that info available to node operators would be a plus.
  39 2017-07-06T02:19:23  <morcos> fanquake: that PR is based on #8501 which seems like hasn't gotten work in quite some time
  40 2017-07-06T02:19:24  <gribble> https://github.com/bitcoin/bitcoin/issues/8501 | Add mempool statistics collector by jonasschnelli · Pull Request #8501 · bitcoin/bitcoin · GitHub
  41 2017-07-06T02:19:43  <morcos> in any case I don't think it's making it for 0.15 at this point
  42 2017-07-06T02:20:59  *** chjj has quit IRC
  43 2017-07-06T02:27:02  *** talmai has joined #bitcoin-core-dev
  44 2017-07-06T02:31:07  <fanquake> morcos Fair enough. Will concentrate on other PRs. Need to put aside some time to look through all your fee work.
  45 2017-07-06T02:52:20  *** talmai has quit IRC
  46 2017-07-06T02:57:04  *** arowser has quit IRC
  47 2017-07-06T03:03:10  *** fanquake has quit IRC
  48 2017-07-06T03:04:44  *** arowser has joined #bitcoin-core-dev
  49 2017-07-06T03:04:52  *** stalictite has joined #bitcoin-core-dev
  50 2017-07-06T03:20:41  *** RubenSomsen has joined #bitcoin-core-dev
  51 2017-07-06T03:46:09  *** Alina-malina has quit IRC
  52 2017-07-06T03:56:50  *** Alina-malina has joined #bitcoin-core-dev
  53 2017-07-06T04:09:23  *** mol has quit IRC
  54 2017-07-06T04:11:08  *** molz has joined #bitcoin-core-dev
  55 2017-07-06T04:15:28  *** stalictite has quit IRC
  56 2017-07-06T05:08:45  *** RubenSomsen has quit IRC
  57 2017-07-06T05:09:57  *** fanquake has joined #bitcoin-core-dev
  58 2017-07-06T05:11:49  *** pindarhk__ has joined #bitcoin-core-dev
  59 2017-07-06T05:17:51  *** michagogo_ has joined #bitcoin-core-dev
  60 2017-07-06T05:19:09  *** kinlo_ has joined #bitcoin-core-dev
  61 2017-07-06T05:22:24  *** pindarhk_ has quit IRC
  62 2017-07-06T05:22:24  *** michagogo has quit IRC
  63 2017-07-06T05:22:25  *** kinlo has quit IRC
  64 2017-07-06T05:22:28  *** pindarhk__ is now known as pindarhk_
  65 2017-07-06T05:22:30  *** kinlo_ is now known as kinlo
  66 2017-07-06T05:22:37  *** michagogo_ is now known as michagogo
  67 2017-07-06T05:25:43  *** Lilly2 has quit IRC
  68 2017-07-06T05:26:18  *** lifeofguenter has quit IRC
  69 2017-07-06T05:27:20  *** lifeofguenter has joined #bitcoin-core-dev
  70 2017-07-06T05:27:34  *** Felipe2 has joined #bitcoin-core-dev
  71 2017-07-06T05:31:33  *** cryptapus_afk has quit IRC
  72 2017-07-06T05:32:50  *** cryptapus_afk has joined #bitcoin-core-dev
  73 2017-07-06T05:32:50  *** cryptapus_afk has joined #bitcoin-core-dev
  74 2017-07-06T05:38:57  *** afk11 has quit IRC
  75 2017-07-06T05:41:05  *** arubi has quit IRC
  76 2017-07-06T05:45:12  *** afk11 has joined #bitcoin-core-dev
  77 2017-07-06T05:45:17  *** arubi has joined #bitcoin-core-dev
  78 2017-07-06T05:47:39  *** chjj has joined #bitcoin-core-dev
  79 2017-07-06T05:48:44  *** jtimon has joined #bitcoin-core-dev
  80 2017-07-06T05:50:43  <jtimon> sipa: something seems wrong with  how can I access the CTxOut of an input with AccessByTxid(/Coin in.prevout.hash but without needing in.prevout.n?
  81 2017-07-06T05:51:17  <jtimon> I bet I'm missing something, but not sure what
  82 2017-07-06T05:53:38  <jtimon> oh, there's no in.prevout.n anymore, nevermind
  83 2017-07-06T05:55:33  <jtimon> wait...I'll think more about this, I know how to fing the PR that's relevant
  84 2017-07-06T05:57:19  *** atroxes has quit IRC
  85 2017-07-06T06:02:55  *** atroxes has joined #bitcoin-core-dev
  86 2017-07-06T06:18:12  *** city22 has joined #bitcoin-core-dev
  87 2017-07-06T06:19:36  *** waxwing has quit IRC
  88 2017-07-06T06:20:04  *** MarcoFalke has quit IRC
  89 2017-07-06T06:20:12  *** MarcoFalke has joined #bitcoin-core-dev
  90 2017-07-06T06:20:14  *** waxwing has joined #bitcoin-core-dev
  91 2017-07-06T06:21:00  *** petertodd has quit IRC
  92 2017-07-06T06:21:28  *** jnewbery has quit IRC
  93 2017-07-06T06:21:43  *** jnewbery has joined #bitcoin-core-dev
  94 2017-07-06T06:22:32  *** petertodd has joined #bitcoin-core-dev
  95 2017-07-06T06:33:38  <gmaxwell> jtimon: you cannot. The database doesn't efficiently support that access anymore, it shouldn't generally be needed.
  96 2017-07-06T06:38:48  <jtimon> gmaxwell: my point is...how can it even guarantee the input looked for is the one that is gotten without passing n? it seems like all instances of  AccessByTxid should be replaced wiht inputs.AccessCoin(tx.vin[n].prevout) or a similar wrapper
  97 2017-07-06T06:39:30  <jtimon> summary: AccessByTxid seems completely uinsafe to me at this point unless I'm missing something
  98 2017-07-06T06:39:52  <jtimon> which is not uncommon
  99 2017-07-06T06:41:44  *** waxwing has quit IRC
 100 2017-07-06T06:41:45  *** waxwing has joined #bitcoin-core-dev
 101 2017-07-06T06:41:59  *** Ylbam has joined #bitcoin-core-dev
 102 2017-07-06T06:45:43  *** pigma64 has joined #bitcoin-core-dev
 103 2017-07-06T06:45:44  *** pigma64 has quit IRC
 104 2017-07-06T06:50:51  <sipa> jtimon: AccessByTxid is only for finding height/coinbase
 105 2017-07-06T06:50:59  <sipa> obviously you can't use it to find an actual output
 106 2017-07-06T06:52:06  <jtimon> oh, I see, that's what I was missing
 107 2017-07-06T06:52:27  <sipa> it's also extremely slow
 108 2017-07-06T06:52:44  <jtimon> it still seems weird that you have access to some arvitrary txout from it though
 109 2017-07-06T06:52:58  <sipa> i guess
 110 2017-07-06T06:53:26  <wumpus> please don't do anything on transifex, especially with the "0.15.x" resource, I was running the script to copy over the translation strings from 0.14 and something weird happened, not sure why but it looked like someone overwrote the translation strings (even though it's locked)
 111 2017-07-06T06:54:51  <jtimon> it shouldn't retun a full coin class, or something, anyway, thank you for the missing piece
 112 2017-07-06T06:55:35  *** pigma64 has joined #bitcoin-core-dev
 113 2017-07-06T06:56:13  <sipa> seems very reasonable to document that
 114 2017-07-06T06:58:45  <sipa> gmaxwell: finding CTxOuts is totally doable though... you just need AccessCoin not AccessByTxid
 115 2017-07-06T06:59:41  <sipa> (Coin contains a CTxOut and fCoinbase and nHeight)
 116 2017-07-06T07:10:58  *** timothy has joined #bitcoin-core-dev
 117 2017-07-06T07:12:57  *** LeMiner2 has joined #bitcoin-core-dev
 118 2017-07-06T07:15:36  *** LeMiner has quit IRC
 119 2017-07-06T07:15:37  *** LeMiner2 is now known as LeMiner
 120 2017-07-06T07:21:20  *** fanquake has quit IRC
 121 2017-07-06T07:22:58  *** chjj has quit IRC
 122 2017-07-06T07:31:14  *** jtimon has quit IRC
 123 2017-07-06T07:39:39  *** tiagotrs has joined #bitcoin-core-dev
 124 2017-07-06T07:46:58  <bitcoin-git> [bitcoin] laanwj pushed 1 new commit to master: https://github.com/bitcoin/bitcoin/commit/191d12b07377393c9eb67770ff5cb8e9a1c5cd7c
 125 2017-07-06T07:46:58  <bitcoin-git> bitcoin/master 191d12b Wladimir J. van der Laan: qt: First translations update for 0.15
 126 2017-07-06T07:48:16  <wumpus> transifex copy was successful this time - copied translations (+metadata) from 0.14 to 0.15, and updated 0.15 resource with new messages, set to auto-update from master (don't forget to change when 0.15 branches off), unlocked - should be good to go
 127 2017-07-06T07:48:47  *** Evel-Knievel has joined #bitcoin-core-dev
 128 2017-07-06T07:49:12  *** coredump_ has quit IRC
 129 2017-07-06T07:51:03  *** laurentmt has joined #bitcoin-core-dev
 130 2017-07-06T07:52:08  *** laurentmt has quit IRC
 131 2017-07-06T08:01:02  *** RubenSomsen has joined #bitcoin-core-dev
 132 2017-07-06T08:08:33  <wumpus> https://lists.linuxfoundation.org/pipermail/bitcoin-core-dev/2017-July/000042.html
 133 2017-07-06T08:16:57  <luke-jr> I guess 0.15 will probably miss multiwallet :/
 134 2017-07-06T08:17:14  <luke-jr> (at least in terms of it being actually usable in the GUI)
 135 2017-07-06T08:18:36  *** instagibbs has quit IRC
 136 2017-07-06T08:19:23  *** instagibbs has joined #bitcoin-core-dev
 137 2017-07-06T08:25:03  *** elkalamar_ has quit IRC
 138 2017-07-06T08:46:10  *** NotME_ has joined #bitcoin-core-dev
 139 2017-07-06T09:02:10  *** riemann has joined #bitcoin-core-dev
 140 2017-07-06T09:17:39  *** JackH has joined #bitcoin-core-dev
 141 2017-07-06T09:18:09  *** goatpig has joined #bitcoin-core-dev
 142 2017-07-06T09:29:16  <wumpus> we should aim for basic RPC multiwallet
 143 2017-07-06T09:29:28  <wumpus> full GUI multiwallet is not realistic for 0.15
 144 2017-07-06T09:30:38  <wumpus> darn, forgot to add a tree-sha512 to the last commit on master
 145 2017-07-06T09:32:07  *** coredump_ has joined #bitcoin-core-dev
 146 2017-07-06T09:35:42  <wumpus> why don't we have a "skip these commits for treesha512 check" and only "treesha512 root commit"?
 147 2017-07-06T09:36:46  *** bordeaux_facile is now known as toinetoine
 148 2017-07-06T09:38:37  *** toinetoine is now known as bordeaux_facile
 149 2017-07-06T09:39:08  <wumpus> argh updating the root commit didn't work, it also checks the root
 150 2017-07-06T09:43:35  *** RubenSomsen has quit IRC
 151 2017-07-06T09:44:18  <wumpus> BlueMatt: how to fix this?
 152 2017-07-06T09:46:35  *** jannes has quit IRC
 153 2017-07-06T09:46:37  <wumpus> ... I guess merging a PR with a treehash, then updating the root commit to that would work
 154 2017-07-06T09:46:52  *** jannes has joined #bitcoin-core-dev
 155 2017-07-06T09:49:11  <wumpus> another option would be to force-push the last commit with a treehash, but it's been in master too long
 156 2017-07-06T09:49:18  <wumpus> neither is really nice
 157 2017-07-06T09:51:26  <luke-jr> take the last one with a treehash, and merge the current master into it?
 158 2017-07-06T09:52:01  <luke-jr> could force-push the last commit and open a PR with the real master, if that makes it easier
 159 2017-07-06T09:55:17  <wumpus> that's a smart idea, your first idea is fully fast-forwardable, right?
 160 2017-07-06T10:03:09  <wumpus> seems to work locally, thanks
 161 2017-07-06T10:03:36  *** RubenSomsen has joined #bitcoin-core-dev
 162 2017-07-06T10:04:02  <wumpus> here goes nothing...
 163 2017-07-06T10:04:11  <bitcoin-git> [bitcoin] laanwj pushed 1 new commit to master: https://github.com/bitcoin/bitcoin/commit/a5cd829a0b51b69a2e7d5e93f55196f7d67a7462
 164 2017-07-06T10:04:11  <bitcoin-git> bitcoin/master a5cd829 Wladimir J. van der Laan: Merge branch qt-translations into master...
 165 2017-07-06T10:13:51  *** city22 has quit IRC
 166 2017-07-06T10:16:48  *** coredump_ has quit IRC
 167 2017-07-06T10:17:37  *** AaronvanW has joined #bitcoin-core-dev
 168 2017-07-06T10:19:08  *** Aaronvan_ has joined #bitcoin-core-dev
 169 2017-07-06T10:23:13  *** AaronvanW has quit IRC
 170 2017-07-06T10:24:33  *** marcoagner has quit IRC
 171 2017-07-06T10:24:48  <wumpus> yay Fixed: bitcoin/bitcoin#19612 (master - a5cd829)
 172 2017-07-06T10:24:49  <gribble> https://github.com/bitcoin/bitcoin/issues/19612 | HTTP Error 404: Not Found
 173 2017-07-06T10:36:04  *** marcoagner has joined #bitcoin-core-dev
 174 2017-07-06T11:01:20  *** timothy has quit IRC
 175 2017-07-06T11:03:34  *** Guyver2 has joined #bitcoin-core-dev
 176 2017-07-06T11:44:15  *** Alina-malina has quit IRC
 177 2017-07-06T11:44:15  *** Alina-malina has joined #bitcoin-core-dev
 178 2017-07-06T11:48:06  *** F2ee has joined #bitcoin-core-dev
 179 2017-07-06T11:57:23  *** dabura667 has quit IRC
 180 2017-07-06T11:58:23  *** F2ee has quit IRC
 181 2017-07-06T12:02:15  *** justan0theruser has joined #bitcoin-core-dev
 182 2017-07-06T12:04:49  *** justanotheruser has quit IRC
 183 2017-07-06T12:47:44  *** timothy has joined #bitcoin-core-dev
 184 2017-07-06T12:53:56  *** tiagotrs has quit IRC
 185 2017-07-06T12:54:09  *** afk11 has quit IRC
 186 2017-07-06T12:54:41  *** afk11 has joined #bitcoin-core-dev
 187 2017-07-06T12:57:37  *** RubenSomsen has quit IRC
 188 2017-07-06T13:10:50  *** unholymachine has quit IRC
 189 2017-07-06T13:13:20  *** unholymachine has joined #bitcoin-core-dev
 190 2017-07-06T13:13:41  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 191 2017-07-06T13:19:24  <bitcoin-git> [bitcoin] laanwj opened pull request #10753: test: Check RPC argument mapping (master...2017_07_rpc_argument_check) https://github.com/bitcoin/bitcoin/pull/10753
 192 2017-07-06T13:29:56  *** dseg has joined #bitcoin-core-dev
 193 2017-07-06T13:50:29  *** dseg has quit IRC
 194 2017-07-06T13:51:10  *** stalictite has joined #bitcoin-core-dev
 195 2017-07-06T13:54:07  *** RoyceX has joined #bitcoin-core-dev
 196 2017-07-06T13:54:20  *** Cheeseo has quit IRC
 197 2017-07-06T13:55:44  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/a5cd829a0b51...be824984626f
 198 2017-07-06T13:55:44  <bitcoin-git> bitcoin/master bd00fa5 John Newbery: [test] don't run dbcrash.py on Travis
 199 2017-07-06T13:55:46  <bitcoin-git> bitcoin/master be82498 Wladimir J. van der Laan: Merge #10743: [test] don't run dbcrash.py on Travis...
 200 2017-07-06T13:56:15  <bitcoin-git> [bitcoin] laanwj closed pull request #10743: [test] don't run dbcrash.py on Travis (master...dontrundbcrash) https://github.com/bitcoin/bitcoin/pull/10743
 201 2017-07-06T14:20:26  *** tiagotrs has joined #bitcoin-core-dev
 202 2017-07-06T14:20:53  *** AaronvanW has joined #bitcoin-core-dev
 203 2017-07-06T14:22:58  *** Aaronvan_ has quit IRC
 204 2017-07-06T14:57:23  *** riemann has quit IRC
 205 2017-07-06T15:05:21  *** Guyver2_ has joined #bitcoin-core-dev
 206 2017-07-06T15:07:53  *** Guyver2 has quit IRC
 207 2017-07-06T15:07:54  *** Guyver2_ is now known as Guyver2
 208 2017-07-06T15:07:57  *** Murch has joined #bitcoin-core-dev
 209 2017-07-06T15:22:48  *** tiagotrs has quit IRC
 210 2017-07-06T15:24:31  *** tiagotrs has joined #bitcoin-core-dev
 211 2017-07-06T15:31:53  <BlueMatt> wumpus: ugh, please add the pre-push-hook locally
 212 2017-07-06T15:32:01  * BlueMatt goes to check whats up
 213 2017-07-06T15:45:19  <BlueMatt> wumpus: oh, yes, thanks luke-jr, clever solution
 214 2017-07-06T15:45:52  <morcos> achow101: instagibbs: Murch:  I have a couple questions about branch&bound, effective value and change
 215 2017-07-06T15:46:05  <Murch> okay
 216 2017-07-06T15:46:36  <morcos> So I see how we are accounting for output size via output_fee and input_size via nInputBytes
 217 2017-07-06T15:46:47  <morcos> But how are we accounting for fees paid on the fixed part of a tx
 218 2017-07-06T15:47:01  <morcos> Won't we necessarily fail if we get too close to an exact match?
 219 2017-07-06T15:47:36  <morcos> Second question: Why are we using the longest possible estimate for the creation of change?
 220 2017-07-06T15:47:41  <Murch> We first get an estimate for the fee rate. Since we know which outputs we want to create for recipients, we can calculate the amount of fee for the outputs.
 221 2017-07-06T15:48:05  <Murch> We add that and the cost of the transaction overhead to the target
 222 2017-07-06T15:48:23  <Murch> So, when we select inputs, we can deduct the cost of the inputs from each that we select and thus we have accumulated all fees necessary.
 223 2017-07-06T15:48:51  <morcos> The transaction overhead piece is the part I was missing
 224 2017-07-06T15:48:54  <morcos> maybe i just missed it
 225 2017-07-06T15:49:41  <Murch> Do you mean specifically in the code? I think that achow101 was missing something there, and we discovered the bug in review recently. I'm not sure if he already fixed it.
 226 2017-07-06T15:50:33  <morcos> ok. yeah thats what i meant
 227 2017-07-06T15:50:43  <morcos> i'm mostly asking questions about his code
 228 2017-07-06T15:50:54  <Murch> Re 2nd Q: BnB only creates transactions without change outputs. Since we can account for the fees of the overhead and outputs in advance, and the fees for the inputs on the fly, we're good. So I don't get what you mean with "creation of change".
 229 2017-07-06T15:51:18  <morcos> I mean the cost of change_
 230 2017-07-06T15:51:30  <morcos> we're calculating it using a smart fee estimate for 1008 blocks
 231 2017-07-06T15:51:44  <morcos> when in reality it'll cost us whatever fee we're using for this transaction creation
 232 2017-07-06T15:51:54  <Murch> Well, actually, this is the part that I'm not comfortable with yet.
 233 2017-07-06T15:52:12  <Murch> Obviously, the only amount that we're clearly saving is the cost of creating a change output.
 234 2017-07-06T15:53:09  <Murch> However, in my simulation, I got a cost reduction by allowing the larger window of "cost of input+output". I was assuming _fixed feerates_ though.
 235 2017-07-06T15:53:18  <morcos> ah i see, i'd missed that
 236 2017-07-06T15:53:30  <morcos> well what i'm saying is something different again
 237 2017-07-06T15:53:45  <Murch> I think that it would need some experimentation to determine whether it is actually a net-benefit to have the larger window and thus save the change more often or not.
 238 2017-07-06T15:53:54  <morcos> actually waht we might want is something similar to what i did in #10712
 239 2017-07-06T15:53:55  <gribble> https://github.com/bitcoin/bitcoin/issues/10712 | Add change output if necessary to reduce excess fee by morcos · Pull Request #10712 · bitcoin/bitcoin · GitHub
 240 2017-07-06T15:54:12  <morcos> but my point was the change_feerate we are using is possibly too low
 241 2017-07-06T15:54:19  <Murch> One of the Trezor people implemented BnB for BitcoinJS this week, and came to the conclusion that "cost of change = change * current feerate" has greater savings.
 242 2017-07-06T15:54:23  <morcos> maybe that is a good feerate to use for assumption of spending the change output in the future
 243 2017-07-06T15:54:27  <Murch> So I would suggest that we go with that first.
 244 2017-07-06T15:55:01  <morcos> might it make sense to cache the best result found so far and keep searching
 245 2017-07-06T15:55:30  <morcos> and have two thresholds, one which is good enough to stop searching further, and one which is good enough if its the best thing we came to at the end of the exhaustive search (or hitting max tries)
 246 2017-07-06T15:56:54  <morcos> In any case we're possibly willing to just throw away the amount of fees determined by change_feerate right?  i'd be very hesitant to just use 1008 for that
 247 2017-07-06T15:57:15  * instagibbs reading backlog
 248 2017-07-06T15:57:24  <morcos> I've seen that number as high as 100 sat/byte, not sure poeple would want to throw away that much, at least not without looking for a better exact match
 249 2017-07-06T15:57:45  <Murch> My gut feeling is that this would increase the size of the selected input sets. That would both increase the variance of the input set size, and perhaps reduce the utxo pool more quickly, perhaps reducing overall effectiveness of BnB.
 250 2017-07-06T15:58:05  <morcos> sorry, what would?
 251 2017-07-06T15:58:06  <Murch> More experiments would inform us, I guess.
 252 2017-07-06T15:58:17  <Murch> finding the "best solution".
 253 2017-07-06T15:58:28  <Murch> Also would probably increase the search times a lot
 254 2017-07-06T15:58:43  <Murch> mh
 255 2017-07-06T15:58:53  <Murch> sorry, I'm too slow
 256 2017-07-06T15:58:55  <morcos> yeah i was a bit concerned about that
 257 2017-07-06T15:59:44  <Murch> So 1) for the window of determining the exact match, I would use the same fee rate as for the transaction * size of a change output.
 258 2017-07-06T16:00:10  <morcos> Yes even plus the dust threshold of the output itself
 259 2017-07-06T16:00:13  <morcos> as done in 10712
 260 2017-07-06T16:00:32  <instagibbs> Murch, im sorry you mean don't consider a future spend of it?
 261 2017-07-06T16:00:40  <Murch> 2) I would go with the first solution instead of the best solution, because it reduces variance in input set size, reduces computation time, and will probably be more conducive to finding many exact matches.
 262 2017-07-06T16:00:57  <instagibbs> oh sorry, you mean use same feerate for both output size and future input
 263 2017-07-06T16:00:59  <morcos> I'll defer to your judgement on that
 264 2017-07-06T16:01:15  <morcos> no instagibbs i think he means don't consider future input
 265 2017-07-06T16:01:30  <instagibbs> due to the bitcoinjs experiments?
 266 2017-07-06T16:01:32  <morcos> but i'm suggesting we should consider future input via GetDustThreshold
 267 2017-07-06T16:01:38  <Murch> instagibbs: I'm concerned that we're overestimating the saved cost
 268 2017-07-06T16:01:47  <morcos> In addition to current fee rate times size of creating output
 269 2017-07-06T16:01:50  *** Guyver2_ has joined #bitcoin-core-dev
 270 2017-07-06T16:01:58  <instagibbs> Murch, explain?
 271 2017-07-06T16:02:11  <Murch> @instagibbs: Yeah.
 272 2017-07-06T16:02:21  *** jtimon has joined #bitcoin-core-dev
 273 2017-07-06T16:03:06  <morcos> I think it's exactly this calculation we should use: https://github.com/bitcoin/bitcoin/pull/10712/files#diff-b2bb174788c7409b671c46ccc86034bdR2762
 274 2017-07-06T16:03:09  <Murch> So, my experiments for my thesis assumed a fixed fee rate for the whole cycle. This allows me to be sure of the saved cost of "input + output"
 275 2017-07-06T16:03:53  *** Guyver2 has quit IRC
 276 2017-07-06T16:04:01  <Murch> Fixed fee rate is not a valid assumption IRL, so it's hard to estimate the saved cost for the input.
 277 2017-07-06T16:04:02  *** Guyver2_ is now known as Guyver2
 278 2017-07-06T16:04:20  <Murch> We see frequent changes in fees in a range of factor 50.
 279 2017-07-06T16:04:43  <instagibbs> Yes, but if fees really do move up on longer-term I don't see why we'd ignore it
 280 2017-07-06T16:05:05  <Murch> Now, currently there are four implementations of BnB that I'm aware of: My science project, Core, BitcoinJS, and what I'm working on for BitGo right now.
 281 2017-07-06T16:05:09  <instagibbs> more aggressive non-change making has privacy advantages on top that I don't think we should ignore
 282 2017-07-06T16:05:48  <morcos> I think we have to distinguish between giving up and generating the change (in which case htere is a cost) and saying ok well this solution isn't close enough that we're willing to just discard the difference
 283 2017-07-06T16:05:48  <Murch> Karel implementing the BitcoinJS one, has done some more experiments and informed me that just using the "output as cost of change" resulted in lower total fees.
 284 2017-07-06T16:06:25  <Murch> instagibbs: Smaller window might cause larger input sets, so it might actually work towards that end. It's hard to tell. ;)
 285 2017-07-06T16:06:26  <instagibbs> Murch, what about how many change outputs are made vs
 286 2017-07-06T16:06:29  <morcos> and potentially trying again
 287 2017-07-06T16:06:32  <instagibbs> and how much are you saving
 288 2017-07-06T16:07:46  <instagibbs> not asking for an answer right here, just think it's important to consider
 289 2017-07-06T16:07:55  <Murch> instagibbs: I don't know. Maybe I was overestimating that effect myself, as I asked Karel whether the rate dropped significantly by making the window smaller.
 290 2017-07-06T16:08:05  *** owowo has quit IRC
 291 2017-07-06T16:08:15  <Murch> instagibbs AFAIU, it didn't though.
 292 2017-07-06T16:08:19  <morcos> This all depends on assumptions about the distributions of the utxos in the pool.   It's going to be different for different people.  In some cases making window larger will just cause you to waste money
 293 2017-07-06T16:08:48  <Murch> instagibbs: Yes definitely need to consider that. Also the average input size and whether it exhausts our smaller inputs too quickly to do later exact matches.
 294 2017-07-06T16:08:48  <morcos> B/c you would have found a smaller exact match.  In other cases a larger window will allow you to find an exact match when you otherwise wouldn't have
 295 2017-07-06T16:09:00  <morcos> Do we have any good data sets for a large number of users to evaluate this on at all
 296 2017-07-06T16:09:09  <Murch> morcos "…wasting money…" exactly.
 297 2017-07-06T16:09:13  <instagibbs> not public ones
 298 2017-07-06T16:09:13  <instagibbs> :P
 299 2017-07-06T16:09:30  <Murch> instagibbs: yep.
 300 2017-07-06T16:10:31  <Murch> I'm gonna do a little more experiments in the coming week to evaluate the algorithm for our internal use. I also have another project though, so I can't give you a timeline. I might have more information on some point though.
 301 2017-07-06T16:10:38  <Murch> Can't share the data of course. ;)
 302 2017-07-06T16:10:45  *** owowo has joined #bitcoin-core-dev
 303 2017-07-06T16:13:45  <morcos> Does the KnapsackSolver still try to find an exact match if BnB fails?
 304 2017-07-06T16:13:50  <morcos> Is that worth doing still?
 305 2017-07-06T16:14:08  <instagibbs> likely not worth it
 306 2017-07-06T16:14:08  <morcos> I'm just trying to figure out whether we cna assume we'll probably have change if BnB fails
 307 2017-07-06T16:14:21  <instagibbs> I think we should toss all of that and assume we get change
 308 2017-07-06T16:14:51  <instagibbs> we can definitely get data for that once we have BnB being used...
 309 2017-07-06T16:14:54  <morcos> If so, then we definitely at least want to use the current fee rate times the size of the change out put, plus dustthreshold of output size
 310 2017-07-06T16:15:18  <morcos> Whether we want to do that on a first pass or maybe do two passes or something, I don't know...
 311 2017-07-06T16:15:53  <instagibbs> "use" in what sense, sorry
 312 2017-07-06T16:16:09  <morcos> for the cost_of_change
 313 2017-07-06T16:16:18  <instagibbs> k
 314 2017-07-06T16:16:48  <instagibbs> remind me what the second term is accomplishing?
 315 2017-07-06T16:17:05  <morcos> Also I think we need a lot more reasoning about how we intermingle the (BNB, knapsack) ordering with the (MinConf=6, MinConf=1, MinConf=0 (various chain lengths) ..) ordering
 316 2017-07-06T16:17:13  <instagibbs> just a small window on top?
 317 2017-07-06T16:17:32  <morcos> You can't create a change output smaller than DustThreshold anyway
 318 2017-07-06T16:18:03  <instagibbs> I just need to read the branch again, ignore my q
 319 2017-07-06T16:18:17  <morcos> so if you found a match where once you paid for the fees required to create the change output (at the feerate this tx is using) you only have < dust left for the change, then you'd just eliminate the change later anyway.  So why not look for an exact match
 320 2017-07-06T16:18:34  <instagibbs> yep
 321 2017-07-06T16:18:50  *** timothy has quit IRC
 322 2017-07-06T16:18:59  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/be824984626f...30bc0f672626
 323 2017-07-06T16:18:59  <bitcoin-git> bitcoin/master b8bb425 Michael Rotarius: REST/RPC example update
 324 2017-07-06T16:19:00  <bitcoin-git> bitcoin/master 30bc0f6 Wladimir J. van der Laan: Merge #10710: REST/RPC example update...
 325 2017-07-06T16:19:05  *** timothy has joined #bitcoin-core-dev
 326 2017-07-06T16:19:32  <bitcoin-git> [bitcoin] laanwj closed pull request #10710: REST/RPC example update (master...docupt) https://github.com/bitcoin/bitcoin/pull/10710
 327 2017-07-06T16:19:33  <morcos> Right now it looks to me at a cursory glance like we first try using BNB on all of the minConf orderings...   So potentially we are going to create a long chain of unconfirmed txs just b/c they don't generate change (luckily that's anti-self-reinfocing)
 328 2017-07-06T16:20:15  <morcos> That doesn't seem to me necessarily what the user wants?  But I don't know what the right order is.
 329 2017-07-06T16:20:40  <morcos> It would be good if there was a lot more documentation about the logic in that PR.   The old code was already way under documented, lets not repeat that mistake
 330 2017-07-06T16:21:01  <instagibbs> that block of SCMC could have a comment header explaining the steps
 331 2017-07-06T16:22:05  *** Aaronvan_ has joined #bitcoin-core-dev
 332 2017-07-06T16:22:41  *** Aaronva__ has joined #bitcoin-core-dev
 333 2017-07-06T16:24:18  *** AaronvanW has quit IRC
 334 2017-07-06T16:25:36  *** laurentmt has joined #bitcoin-core-dev
 335 2017-07-06T16:26:01  *** laurentmt has quit IRC
 336 2017-07-06T16:26:09  *** Aaronvan_ has quit IRC
 337 2017-07-06T16:29:37  <Murch> sorry, something came up. I agree that the KnapsackSolver should not try to find an exact match anymore. It's also not good at it anyway.
 338 2017-07-06T16:32:53  <Murch> In most cases when it would find an exact match, it would throw it out because it can't pay the fees in subsequence.
 339 2017-07-06T16:55:00  *** Felipe2 has quit IRC
 340 2017-07-06T16:57:33  <bitcoin-git> [bitcoin] laanwj pushed 37 new commits to 0.14: https://github.com/bitcoin/bitcoin/compare/fc61c8322bd7...91be5e3c1e45
 341 2017-07-06T16:57:34  <bitcoin-git> bitcoin/0.14 d28d583 Suhas Daftuar: Bugfix: PrioritiseTransaction updates the mempool tx counter...
 342 2017-07-06T16:57:34  <bitcoin-git> bitcoin/0.14 71463a7 Suhas Daftuar: [qa] Test prioritise_transaction / getblocktemplate interaction...
 343 2017-07-06T16:57:35  <bitcoin-git> bitcoin/0.14 ef810c4 practicalswift: [trivial] Fix a typo (introduced two days ago) in the default fee warning...
 344 2017-07-06T17:02:38  *** spudowiar has joined #bitcoin-core-dev
 345 2017-07-06T17:02:49  <spudowiar> To confirm, UniValues can only be appended to, not modified, right?
 346 2017-07-06T17:03:59  *** justanotheruser has joined #bitcoin-core-dev
 347 2017-07-06T17:05:48  *** justanotheruser has quit IRC
 348 2017-07-06T17:06:11  *** justanotheruser has joined #bitcoin-core-dev
 349 2017-07-06T17:06:52  *** justan0theruser has quit IRC
 350 2017-07-06T17:08:44  *** Chris_Stewart_5 has quit IRC
 351 2017-07-06T17:09:27  *** tiagotrs has quit IRC
 352 2017-07-06T17:14:14  *** timothy has quit IRC
 353 2017-07-06T17:17:28  <instagibbs> seems that way
 354 2017-07-06T17:18:53  <spudowiar> Copying the object to modify it seems wrong
 355 2017-07-06T17:19:41  <spudowiar> I might copy the function from core_write to CWallet and modify it for my usecase
 356 2017-07-06T17:20:12  <spudowiar> There are quite a few neat changes I could make then
 357 2017-07-06T17:22:24  *** stalictite has quit IRC
 358 2017-07-06T17:26:07  *** stalictite has joined #bitcoin-core-dev
 359 2017-07-06T17:26:28  *** Aaronva__ has quit IRC
 360 2017-07-06T17:26:38  *** AaronvanW has joined #bitcoin-core-dev
 361 2017-07-06T17:31:34  <wumpus> correct - you shouldn't need to edit univalue object, either consume them or generate them
 362 2017-07-06T17:32:05  <wumpus> they're meant for being used on the interface, not meant as a lasting data representation format
 363 2017-07-06T17:32:22  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 364 2017-07-06T17:37:23  *** chjj has joined #bitcoin-core-dev
 365 2017-07-06T17:38:15  <instagibbs> morcos, interesting to note that a successful BnB on a long chain ends that chain for the user. Once we're using effective value everywhere you can do two quick SelectCoins calls, but then you still have that judgment call of which is better.
 366 2017-07-06T17:40:25  <morcos> instagibbs: yeah its not obvious to me what the right outcome is, but i think we explicitly need to think about it.  I think we'd do better creating change from confirmed outputs before extending a chain, at least until we do something smart with whole chain fee control.
 367 2017-07-06T17:40:57  <morcos> but for instance we might prefer to create no-change from 1-confirm inputs before creating change from 6-confirm inputs
 368 2017-07-06T17:41:06  <instagibbs> Indeed that would be better, but I'd still like to revisit BnB if we cant do knapsack w/ confirmed
 369 2017-07-06T17:41:43  *** donaloconnor has joined #bitcoin-core-dev
 370 2017-07-06T17:42:27  <instagibbs> Throw-away idea: Let the transaction construction loop happen once, never accept the first result, then you can compare the two,
 371 2017-07-06T17:43:01  <instagibbs> the first will always fail anyways
 372 2017-07-06T17:44:17  <morcos> sipa: style ruling please, this time i think i checked developer notes first.  If I have a static class member like CWallet::fallbackFee should that be g_fallback_fee or m_fallback_fee?
 373 2017-07-06T17:45:13  <sipa> not a constant?
 374 2017-07-06T17:45:54  <morcos> well its a command line argument
 375 2017-07-06T17:46:19  <sipa> i guess technically that would be a member field, but personally i very much think we should avoid non-const static members, and make them globals instead
 376 2017-07-06T17:46:52  <wumpus> it's an interesting case
 377 2017-07-06T17:47:14  <morcos> ok, i'm happy to do that.  just global but declared in wallet.h ?
 378 2017-07-06T17:47:25  <sipa> sounds good to me
 379 2017-07-06T17:47:30  <wumpus> not convinced a global is better
 380 2017-07-06T17:47:38  <sipa> static class members effectively are globals
 381 2017-07-06T17:47:47  <sipa> they're just abusing the class as a namespace
 382 2017-07-06T17:47:49  <wumpus> at least the class provides some kind of scoping
 383 2017-07-06T17:47:57  <morcos> thats why my guess was CWallet::g_discard_rate
 384 2017-07-06T17:47:59  <wumpus> well it's better than throwing everything into the global namespace
 385 2017-07-06T17:48:19  <sipa> i guess the right approach is to actually have good namespacing
 386 2017-07-06T17:48:29  <wumpus> sure
 387 2017-07-06T17:48:52  *** chjj has quit IRC
 388 2017-07-06T17:48:57  <wumpus> but now it could collide with something e.g. outside of wallet, it's not clear it's for the wallet
 389 2017-07-06T17:49:06  <wumpus> m_fallback_fee could be anything, also a mempool thing
 390 2017-07-06T17:49:21  <gmaxwell> Keep in mind that we avoid spending third party unconfirmed inputs for security reasons; and our own for privacy (otherwise the change is immediately distinguishable)
 391 2017-07-06T17:50:07  <morcos> so what am i doing then?
 392 2017-07-06T17:50:42  <morcos> the existing similar variables are static class members for now
 393 2017-07-06T17:50:48  <sipa> if it's a static member variable, call it CWallet::m_fallback_fee
 394 2017-07-06T17:51:08  <wumpus> better to keep it consistent and make this one too, morcos, I'd say
 395 2017-07-06T17:51:11  *** RubenSomsen has joined #bitcoin-core-dev
 396 2017-07-06T17:51:12  <wumpus> and yes call it m_fallback_fee
 397 2017-07-06T17:51:13  <morcos> ok, i'll do that for now..  if we want to , we can clean up all of them later
 398 2017-07-06T17:51:17  <sipa> ack
 399 2017-07-06T17:51:41  <morcos> btw, i think it would be nice to have helper functions for all these command line arguments
 400 2017-07-06T17:51:51  <sipa> yes...
 401 2017-07-06T17:52:11  <morcos> so we could sort of declare the argument, its help string, its min and max value, etc.. all in one place
 402 2017-07-06T17:52:27  <wumpus> we have a PR that improves argument handling IIRC
 403 2017-07-06T17:52:39  <wumpus> would be nice post-0.15
 404 2017-07-06T17:57:41  <wumpus> would be nice to finally be able to close #1044
 405 2017-07-06T17:57:42  <gribble> https://github.com/bitcoin/bitcoin/issues/1044 | Problems with command-line options silently ignored · Issue #1044 · bitcoin/bitcoin · GitHub
 406 2017-07-06T17:57:57  <sipa> yes...
 407 2017-07-06T17:58:01  <wumpus> which should be easy if all command line arguments are registered
 408 2017-07-06T17:58:16  <spudowiar> Yea or nay: Adding a const CWallet& parameter to TxToUniv which adds hdKeypath to your own inputs and the change outputs?
 409 2017-07-06T17:58:30  <spudowiar> Or should I create a new version of TxToUniv?
 410 2017-07-06T18:00:42  <instagibbs> I don't think that function has any knowledge of wallet
 411 2017-07-06T18:01:57  <wumpus> yes it is not a wallet function, core_io etc has no wallet dependency
 412 2017-07-06T18:02:18  <wumpus> if you need one for the wallet, define your own
 413 2017-07-06T18:02:30  <spudowiar> instagibbs: Hence adding the const CWallet& parameter :)
 414 2017-07-06T18:02:48  <sipa> spudowiar: that would make the function dependent on the wallet, which we want to avoid
 415 2017-07-06T18:02:50  <instagibbs> I more mean it's a layer violation
 416 2017-07-06T18:02:58  <spudowiar> sipa: Only if you provide the wallet parameter
 417 2017-07-06T18:03:07  <wumpus> one that takes a CWalletTx, defined in the wallet library
 418 2017-07-06T18:03:16  <sipa> spudowiar: you don't understanf
 419 2017-07-06T18:03:16  <morcos> gmaxwell: This is the discard_rate idea: https://github.com/morcos/bitcoin/commit/fd8104a9f074ca588d44defe015b0ace77dbc7fc
 420 2017-07-06T18:03:20  <wumpus> spudowiar: no, he means a compile-time dependency
 421 2017-07-06T18:03:27  <spudowiar> Oh, gotcha, sorry :)
 422 2017-07-06T18:03:29  <spudowiar> I just realised :)
 423 2017-07-06T18:03:32  <wumpus> spudowiar: core_io etc do not include wallet.h at all ,they don't link against the wallet stuff
 424 2017-07-06T18:03:39  <spudowiar> I didn't realise it was in bitcoin-common
 425 2017-07-06T18:03:42  <sipa> spudowiar: if the function takes a wallet argument, it becomes code that cannot exist without the wallet code being present too
 426 2017-07-06T18:03:57  <morcos> gmaxwell: very simple, but i fear there are too many outstanding other wallet fee PR's to bother with that for now (i built it on top of them since it interacts)
 427 2017-07-06T18:04:09  <sipa> spudowiar: in general, the wallet is intended to be separated off at some point, and even if it isn't, it's good practices to reduce dependencies between modules
 428 2017-07-06T18:04:48  <wumpus> anyhow, functionality that should be present when buildilng without the wallet relies on TxToUniv
 429 2017-07-06T18:04:56  <gmaxwell> morcos: I like.
 430 2017-07-06T18:05:16  <morcos> instagibbs: Murch: achow101: It's this discard rate idea that I'd use to set your window in BnB as well.  In addition to the cost of creating the change at the current fee level.
 431 2017-07-06T18:06:10  <achow101> discard rate?
 432 2017-07-06T18:06:19  <achow101> (sorry, I've missed most of the conversation here)
 433 2017-07-06T18:06:21  <wumpus> cfields: could you take a look at #10508 - it is a tests PR, but involves some small build system changes, would be nice if you could take a look
 434 2017-07-06T18:06:22  <morcos> See link 10 lines up
 435 2017-07-06T18:06:22  <gribble> https://github.com/bitcoin/bitcoin/issues/10508 | Run Qt wallet tests on travis by ryanofsky · Pull Request #10508 · bitcoin/bitcoin · GitHub
 436 2017-07-06T18:06:50  <achow101> ah, ok
 437 2017-07-06T18:07:22  <cfields> wumpus: grr, i was thinking I was missing a reponse to a build PR, but I couldn't track it down. Sorry. Looking now.
 438 2017-07-06T18:09:36  <instagibbs> morcos, TLDR: max(min(1008 smart unconservative smart fee, static_discard_rate)), dustRelayFee)
 439 2017-07-06T18:09:38  *** chjj has joined #bitcoin-core-dev
 440 2017-07-06T18:10:14  <morcos> instagibbs: yes. GetDustThreshold(^ that)
 441 2017-07-06T18:12:17  <instagibbs> seems reasonable, user can always protect super-dustRelayFee change if they decide to
 442 2017-07-06T18:17:44  *** chjj has quit IRC
 443 2017-07-06T18:17:51  <Murch> morcos: That would be a good price estimate for the input cost of the saved change output.
 444 2017-07-06T18:19:48  <morcos> Murch: yes that's what i'm saying...  and after #10712 its the calculation that is used to say oh wow we're paying way too much fee, lets add change
 445 2017-07-06T18:19:49  <gribble> https://github.com/bitcoin/bitcoin/issues/10712 | Add change output if necessary to reduce excess fee by morcos · Pull Request #10712 · bitcoin/bitcoin · GitHub
 446 2017-07-06T18:21:18  <morcos> I'm actually not 100% convinced 10712 is a good idea.. It will lead to a bit more utxo bloat. The true fix is to be smarter about never creating small change which requires effective fee rates.
 447 2017-07-06T18:25:29  <kanzure> is the sentiment that the 1008 block estimatesmartfee for change output size minimum threshold is a bad thing due to utxo bloat ?
 448 2017-07-06T18:25:57  <instagibbs> kanzure, right now the wallet is just really bad at targeting good change size outputs or exact matches
 449 2017-07-06T18:26:01  <instagibbs> so it kind of lands in the middle
 450 2017-07-06T18:27:08  <kanzure> in another 'wallet' (not core) (it's not a wallet) i was going to ask for two fee rates, one for the non-change outputs and another for an estimation of the minimum size of any possible change output below which to burn to miner fee.
 451 2017-07-06T18:27:38  <instagibbs> right, that's the above idea
 452 2017-07-06T18:27:47  <instagibbs> discardRate, where it's ok to drop it
 453 2017-07-06T18:28:37  <kanzure> if all outputs were required to be multisig p2sh then we could insist that everyone just transfers their change in the same output, and they can worry about spending it later. </joking, not practical>
 454 2017-07-06T18:30:07  <Murch> morcos: I don't think I have a good overview of what's going on yet, but generally I'd suggest that we aim for clearcut scenarios:
 455 2017-07-06T18:30:20  <Murch> 1) Try to create no change output (use BnB)
 456 2017-07-06T18:30:46  <Murch> 2) If fail: Try to create change output greater than min_change
 457 2017-07-06T18:31:25  <Murch> 3) small number of cases that don't fit in any other bucket: If change output is too small to keep discard.
 458 2017-07-06T18:31:46  <Murch> […], discard.
 459 2017-07-06T18:32:02  <morcos> Murch: 100% agree, but the real issue is once we have effective_value we can do both those things.  even part 2 requires a good effective value.
 460 2017-07-06T18:32:25  <Murch> what do you mean with "effective_value"?
 461 2017-07-06T18:32:34  <kanzure> instagibbs: unfortunately we edge up to this fundamental tradeoff between discardRate, utxo bloat minimization, and folks losing money because small outputs are essentially unspendable (some always, some intermittently).  essentially, certain payment amounts-- from certain inputs--  are simply not workable.  if 10 more seconds of coin selection computation could solve this for a user, i thi...
 462 2017-07-06T18:32:40  <kanzure> ...nk that's worth the face value of the output.
 463 2017-07-06T18:32:58  <morcos> An additionaly issue however is I don't think its the best idea in the world to add tons of inputs that have barely positive effective value when we are payin a high fee rate, but thats possibly a later improvement
 464 2017-07-06T18:33:29  <Murch> morcos: I think you're worrying too much about utxo bloat. In my simulation, BnB + RandomSelection as fallback had a much lower average UTXO Pool size than Core selection.
 465 2017-07-06T18:33:56  <Murch> BnB + Core as a fallback should be even smaller.
 466 2017-07-06T18:34:28  <gmaxwell> I don't think there is any bloat concern on BNB. Thats part of why we're doing it first.
 467 2017-07-06T18:34:42  <morcos> The big question is how often does BnB find an answer
 468 2017-07-06T18:34:48  <morcos> I have no insight into that
 469 2017-07-06T18:34:55  <instagibbs> Murch, could you just do dumb fallback
 470 2017-07-06T18:35:01  <instagibbs> I think you did right?
 471 2017-07-06T18:35:37  <Murch> morcos: In my simulation with 12k outgoing payments, I found ~39% exact matches with BnB and ~0.6% with Core.
 472 2017-07-06T18:35:42  <morcos> If murch's simulation is on a larger than typical spendable utxo set then it may overestimate the benfit we gain from BnB
 473 2017-07-06T18:35:55  <Murch> morcos: Saying we have no idea, seems a bit of a stretch.
 474 2017-07-06T18:35:57  <morcos> 12k outgoing payments from what utxo set per payment?
 475 2017-07-06T18:36:12  <morcos> is each one from the actual utxo set that that payment was made from?
 476 2017-07-06T18:36:28  <morcos> is that one big utxo set
 477 2017-07-06T18:36:52  <morcos> sure, i think BnB will make a huge difference for commercial applications with large utxo sets
 478 2017-07-06T18:36:54  <Murch> morcos: It's a sequence of 36k payments in total, 12k outgoing, 24k incoming.
 479 2017-07-06T18:37:04  <morcos> but all to the same utxo set?
 480 2017-07-06T18:37:05  <gmaxwell> morcos: he has a feed of input and output payment amounts simulate the wallet (e.g. how it's utxos evolve over time)
 481 2017-07-06T18:37:09  <Murch> yes
 482 2017-07-06T18:37:13  <gmaxwell> its*
 483 2017-07-06T18:37:17  <morcos> so thats far from typical
 484 2017-07-06T18:37:36  <sipa> morcos: but perhaps very significant on the overall utxo set
 485 2017-07-06T18:37:38  <achow101> isn't that dataset from moneypot's payments?
 486 2017-07-06T18:37:50  <gmaxwell> morcos: well it's actual for at least one user, we don't know how it represents everyone but users like this are a non-trivial amount of the total network behavior.
 487 2017-07-06T18:37:54  <sipa> morcos: as in, perhaps a large portion of the actual network comes from large player's wallets
 488 2017-07-06T18:37:56  <morcos> sipa: unknown.  what % of utxos belong to a big wallet vs small
 489 2017-07-06T18:38:04  <sipa> morcos: yes, i don't know either
 490 2017-07-06T18:38:05  <Murch> I've also consolidated the incoming payments 4 to 1, to make a scenario with 6k incoming payments and 12k outgoing payments. It still did great on UTXO set reduction
 491 2017-07-06T18:38:24  <Murch> achow101: Yes, the same
 492 2017-07-06T18:38:27  <morcos> gmaxwell: don't get me wrong.  i'm very in favor of doing BnB. its certainly not hurting small wallets
 493 2017-07-06T18:38:42  <gmaxwell> Im not sure of the thrust of the discussion here, but I do not see how the BnB could be anything worse than a small improvement.
 494 2017-07-06T18:38:43  <bitcoin-git> [bitcoin] laanwj pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/30bc0f672626...5af657253498
 495 2017-07-06T18:38:44  <bitcoin-git> bitcoin/master 928c681 Matt Corallo: Use "replaceable" instead of "optintorbf" in createrawtransaction....
 496 2017-07-06T18:38:44  <bitcoin-git> bitcoin/master fb915d5 Matt Corallo: Use "replaceable" instead of "optIntoRbf" in fundrawtransaction....
 497 2017-07-06T18:38:45  <bitcoin-git> bitcoin/master 73c942e Matt Corallo: Use "replaceable" instead of "rbfoptin" in bitcoin-tx....
 498 2017-07-06T18:38:49  <gmaxwell> morcos: okay good!
 499 2017-07-06T18:38:57  <morcos> all i'm arguing is we can't look at this increase to 39% exact matches and assume its going to have a huge effect on the overall utxo set which is made up of many smaller sets
 500 2017-07-06T18:39:11  <sipa> morcos: agree - we don't know the impact
 501 2017-07-06T18:39:11  <bitcoin-git> [bitcoin] laanwj closed pull request #10698: Be consistent in calling transactions "replaceable" for Opt-In RBF (master...2017-06-replaceable-rpc-args) https://github.com/bitcoin/bitcoin/pull/10698
 502 2017-07-06T18:39:17  <Murch> morcos: Coin selection in a wallet that has significantly more outgoing payments than incoming (i.e. most end-user cases) is trivial.
 503 2017-07-06T18:39:19  <morcos> so we still have to be worried about utxo bloat in the event BnB fails
 504 2017-07-06T18:39:22  <gmaxwell> oh sure, I think it's fair to say that we don't know how much of an improvement it will be in aggregate.
 505 2017-07-06T18:39:25  <morcos> This is what i'm talking about
 506 2017-07-06T18:39:26  <instagibbs> eh, economic node activity likely follows a power law
 507 2017-07-06T18:39:37  <gmaxwell> Just that it will do no harm and at least in some cases help a lot.
 508 2017-07-06T18:39:39  <Murch> morcos: Coin selection in a wallet that has more incoming payments than outgoing should do very well with BnB.
 509 2017-07-06T18:39:39  <instagibbs> maybe wont matter for small wallets you're right
 510 2017-07-06T18:39:59  <morcos> balancing users wasting their small utxos when they are getting very little to negative effective value from it vs at some point needing to aggregate those to avoid bloat
 511 2017-07-06T18:40:06  <morcos> Murch thought i was over worrying about bloat
 512 2017-07-06T18:40:45  <Murch> morcos: Well, but UTXO set being generally split over more different wallets is not something we can influence on the coinselection level in the first place. That's on the adoption level.
 513 2017-07-06T18:40:48  <gmaxwell> morcos: well in achow101's implementation he is using (and would switch to exactly) something just like the dustfee metric you just linked to, I don't think we have to worry about waste if using that.
 514 2017-07-06T18:41:46  <morcos> gmaxwell: the case i'm talking about is if we don't succeed in BnB, then what change do we aim for.  We certainly would like to get higher than something governed by the discard rate.
 515 2017-07-06T18:42:25  <gmaxwell> morcos: okay so BnB is basically unrelated.
 516 2017-07-06T18:42:27  <instagibbs> I think we're agreeing here. For fallback we should pick something significantly higher if possible
 517 2017-07-06T18:42:30  <morcos> gmaxwell: yes
 518 2017-07-06T18:43:05  <Murch> Yeayeah
 519 2017-07-06T18:43:35  <morcos> while we're on the subject
 520 2017-07-06T18:44:08  <morcos> gmaxwell and everyone did you see my above question about how (bnb, knapsack) should be intermingled with (selectcoinsminconf (different params))
 521 2017-07-06T18:44:31  <morcos> at what point do you prefer no change but less confirmations or longer unconfirmed chain
 522 2017-07-06T18:45:00  <gmaxwell> morcos: yes, I have some agreement though there are privacy implications.  We don't spend 6 conf or less from third parties for security reasons.  And we try to avoid spending our own at less than 6 conf to avoid blowing up any privacy change has.
 523 2017-07-06T18:45:06  *** chjj has joined #bitcoin-core-dev
 524 2017-07-06T18:45:23  <gmaxwell> But I think we should BNB longish chains for example.
 525 2017-07-06T18:45:36  <gmaxwell> because that ends them.
 526 2017-07-06T18:45:53  <gmaxwell> but obviously not overlong (24+) ones.
 527 2017-07-06T18:45:55  <morcos> but not before creating a tx which doesn't spend unconfirmed ?
 528 2017-07-06T18:46:28  <gmaxwell> OH on this subject. We need to consider the feerate of unconfirmed parents as part of their effective rate.
 529 2017-07-06T18:46:31  <gmaxwell> And CPFP them.
 530 2017-07-06T18:46:32  <morcos> actually, maybe it wouldn't be that hard to be kind of smart about it.
 531 2017-07-06T18:47:00  <morcos> yes , well before that step, you could only consider extending chains which pay a feerate at least as high as the one you are paying
 532 2017-07-06T18:47:02  <gmaxwell> For example if you managed to make a very low fee payment A, then make payment B with better fee settings. If B spends from A it needs to CPFP A up to B's target feerate.
 533 2017-07-06T18:47:12  <gmaxwell> Indeed.
 534 2017-07-06T18:47:45  <gmaxwell> I've seen some users screwed with this FWIW.
 535 2017-07-06T18:47:46  <morcos> i don't think you'd necessarily want to automatically CPFP a chain if you had other options
 536 2017-07-06T18:48:05  <gmaxwell> They made a payment with a very low rate shortly after startup, then the next day they made another payment that paid a reasonable rate, but was a child.
 537 2017-07-06T18:48:19  <instagibbs> you'd need to avoid bumping twice, by detecting if they are cousins in a chain
 538 2017-07-06T18:48:33  <gmaxwell> I think you might want to automatically CPFP any input that you set the same confirmed target or lower on.
 539 2017-07-06T18:49:10  <gmaxwell> instagibbs: well they won't be unless we're making multiple change outputs or paying ourselves.... but yes...
 540 2017-07-06T18:49:39  <gmaxwell> this suggests that perhaps we should be tracking what the fee settings were for those transactions.
 541 2017-07-06T18:49:44  <morcos> goodness, this is going to get complicated.
 542 2017-07-06T18:49:49  <gmaxwell> Hurray!
 543 2017-07-06T18:50:01  <gmaxwell> (this means we're starting to understand all that we don't know about the problem space)
 544 2017-07-06T18:50:10  <instagibbs> next we need to throw a general purpose optimizer at it
 545 2017-07-06T18:50:27  <rhavar> pretty sure that's the only sane solution if you want to automatically do CPFP and stuff
 546 2017-07-06T18:50:34  <gmaxwell> nah.
 547 2017-07-06T18:50:57  <gmaxwell> Other than having a bunch of conditionals I think this stuff isn't *that* gnarly.
 548 2017-07-06T18:51:02  <instagibbs>  didn't close my statement with /s
 549 2017-07-06T18:51:49  <gmaxwell> The hurestic would be that you first consider unconfirmeds that either are at the target or higher feerate  or at the current target or lower... ... but always CPFP things up to the current destination rate.
 550 2017-07-06T18:51:59  <gmaxwell> and use the CPFP impact in the EV calculations.
 551 2017-07-06T18:52:29  <rhavar> I'm not sure it's a horrible idea to just write the whole thing up as a general purpose constrain solving problem
 552 2017-07-06T18:52:39  <rhavar> and just not include a constrain solver :P
 553 2017-07-06T18:52:42  <rhavar> have it as a plugin or something
 554 2017-07-06T18:53:05  <gmaxwell> rhavar: I've done this previously, but the actual solving isn't really that big a deal.
 555 2017-07-06T18:53:10  *** RubenSomsen has quit IRC
 556 2017-07-06T18:53:11  <rhavar> For casual wallet users, they're only going to have a couple of inputs and outputs -- you can pretty much brute force the space
 557 2017-07-06T18:53:36  <rhavar> And for commercial users, they can actually install some shared object plugin that calls out to a proper library
 558 2017-07-06T18:54:02  <gmaxwell> it's not magic in any case.
 559 2017-07-06T18:54:35  <rhavar> That's what I'm doing right at this moment, I pretty much brute force solutions with a cost metric
 560 2017-07-06T18:54:42  <gmaxwell> I think there is a AMSL statement of a toy coinselection problem that I wrote floating around out there somewhere.
 561 2017-07-06T18:54:44  <rhavar> and it does a *decent* job
 562 2017-07-06T18:55:20  <rhavar> I'll have a robust minizinc implementation pretty soon, if anyones interested
 563 2017-07-06T18:55:21  <gmaxwell> rhavar: sure and thats what it does internally, it's just using a different cost design than you.  (A dumb one that is optimizing under assumptions like addresses are never reused) :)
 564 2017-07-06T18:56:24  <gmaxwell> unfortunately, last I checked there are no sutable solvers that we can distribute... but I wouldn't have any issue with having an interface to call out to something.
 565 2017-07-06T18:56:33  <rhavar> I guess what I mean, is if you actually support loading a .so  plugin or something -- you can pretty much not worry about it
 566 2017-07-06T18:57:08  <gmaxwell> rhavar: except like, you know, we need to worry about that 99% of users (including commercial ones) that aren't going to solve this for themselves, and not better than we will. :)
 567 2017-07-06T18:57:25  <morcos> also the magic is in the metric isn't it
 568 2017-07-06T18:57:25  <gmaxwell> but no issue supporting loadable things for people who want them.
 569 2017-07-06T18:57:55  <rhavar> This is the cost function I use: https://gist.github.com/RHavar/0710144c713033d42f8f443a99fefbb7
 570 2017-07-06T18:58:03  <rhavar> I think it makes perfect sense for casual users too
 571 2017-07-06T18:58:17  <rhavar> Just instead of using a proper constrain solver, they can use a brute forcer
 572 2017-07-06T18:58:25  <rhavar> which is pretty trivial to write
 573 2017-07-06T18:58:29  <jtimon> meeting?
 574 2017-07-06T18:58:41  <sipa> soon!
 575 2017-07-06T18:59:18  <gmaxwell> rhavar: you perhaps overestimate how far you can go with bruteforce... :P once you have more than two dozen inputs it starts becoming intractable.
 576 2017-07-06T18:59:31  <gmaxwell> (and my wallets have a lot more than two dozen inputs, and I'm just some guy)
 577 2017-07-06T19:00:04  <rhavar> I'm using a brute force search with ~2k inputs right now, and it does a *decent* job
 578 2017-07-06T19:00:17  <rhavar> not perfect though, that's why I'm paying for the minizinc impl
 579 2017-07-06T19:00:37  <rhavar> (I obviously don't search the entire space, I time out after 10 minutes)
 580 2017-07-06T19:00:44  <wumpus> #startmeeting
 581 2017-07-06T19:00:44  <lightningbot> Meeting started Thu Jul  6 19:00:44 2017 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
 582 2017-07-06T19:00:44  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
 583 2017-07-06T19:00:51  <gmaxwell> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier
 584 2017-07-06T19:00:56  <jonasschnelli> proposed topic: multiwallet endpoint vs json item
 585 2017-07-06T19:00:56  <sipa> LO
 586 2017-07-06T19:00:56  <wumpus> topics?
 587 2017-07-06T19:01:01  <achow101> hi
 588 2017-07-06T19:01:04  <cfields> hi
 589 2017-07-06T19:01:10  <kanzure> hi.
 590 2017-07-06T19:01:15  <wumpus> jonasschnelli: yeah, apparently we have to discuss that again, with all the competing PRs
 591 2017-07-06T19:01:22  <jonasschnelli> heh. Yes
 592 2017-07-06T19:01:29  <wumpus> jonasschnelli: though in principle we settled on endpoint a few weeks ago
 593 2017-07-06T19:01:31  <morcos> begging for review... lots of fee/wallet/estimate stuff that needs to make 0.15
 594 2017-07-06T19:01:41  <morcos> i already have 3 on high priority... sheepish grin
 595 2017-07-06T19:01:53  <wumpus> yes, high priority for review will as usual be first topic
 596 2017-07-06T19:01:54  <gmaxwell> morcos: We should do the things.
 597 2017-07-06T19:01:55  <jonasschnelli> We set endpoints, but some where also in favor of the JSON item solution
 598 2017-07-06T19:02:01  <wumpus> #topic high priority for review
 599 2017-07-06T19:02:04  <BlueMatt> PSA: if you're running master, be very careful not to swap -txindex on your db: the check to prevent you from doing so is broken and you could corrupt your chainstate
 600 2017-07-06T19:02:17  <wumpus> https://github.com/bitcoin/bitcoin/projects/8
 601 2017-07-06T19:02:29  <gmaxwell> by swap txindex he means turn it on/off on an already running node.
 602 2017-07-06T19:02:40  *** chjj has quit IRC
 603 2017-07-06T19:02:44  <jonasschnelli> I'll remove my #10240 from the list for now
 604 2017-07-06T19:02:46  <instagibbs> good to know...
 605 2017-07-06T19:02:47  <wumpus> without a reindex-chainstate I guess
 606 2017-07-06T19:02:49  <sipa> gmaxwell: you mean already created db?
 607 2017-07-06T19:02:50  <gribble> https://github.com/bitcoin/bitcoin/issues/10240 | Add HD wallet auto-restore functionality by jonasschnelli · Pull Request #10240 · bitcoin/bitcoin · GitHub
 608 2017-07-06T19:03:01  <wumpus> jonasschnelli: ok
 609 2017-07-06T19:03:22  <jonasschnelli> It's to big and will re-focus during early 0.16
 610 2017-07-06T19:03:27  <jtimon> maybe put #8498 in project 8 ?
 611 2017-07-06T19:03:30  <gribble> https://github.com/bitcoin/bitcoin/issues/8498 | Near-Bugfix: Optimization: Minimize the number of times it is checked that no money... by jtimon · Pull Request #8498 · bitcoin/bitcoin · GitHub
 612 2017-07-06T19:03:33  <luke-jr> wumpus: the arguments for endpoint seem strong IMO
 613 2017-07-06T19:03:38  <instagibbs> morcos, doesn;t help that they're an unconfirmed chain of PRs :)
 614 2017-07-06T19:04:06  <morcos> instagibbs: i know! :)  high priority review ones arent though
 615 2017-07-06T19:04:07  <sipa> we need a chain length limit on PRs
 616 2017-07-06T19:04:08  <luke-jr> guess we're not on that topic yet
 617 2017-07-06T19:04:11  <wumpus> jtimon: is that high priority to get into 0.15?
 618 2017-07-06T19:04:17  <wumpus> luke-jr: next topic
 619 2017-07-06T19:04:25  <BlueMatt> wumpus: I think 10179 is ready(ish) for a merge, which makes my high-prio of 10652 cleaner
 620 2017-07-06T19:04:49  <jtimon> wumpus: I haven't benchmarked, but it's an optimization and now also a "near bugfix"
 621 2017-07-06T19:04:56  <morcos> BlueMatt: i was just rereviewing that, but don't wait on me, i'm out of sync these days and doing all posthumous review
 622 2017-07-06T19:05:51  <wumpus> BlueMatt: agree
 623 2017-07-06T19:06:16  <sipa> #10179
 624 2017-07-06T19:06:19  <gribble> https://github.com/bitcoin/bitcoin/issues/10179 | Give CValidationInterface Support for calling notifications on the CScheduler Thread by TheBlueMatt · Pull Request #10179 · bitcoin/bitcoin · GitHub
 625 2017-07-06T19:07:13  <BlueMatt> yes, second PSA: never shy away from postumous review! the feeling that its not contributing to moving things forward is wrong, if you think something got merged without enough acks, just review it!
 626 2017-07-06T19:07:27  <morcos> or if you want to be sure to understand the new code!
 627 2017-07-06T19:07:32  <BlueMatt> well, that too
 628 2017-07-06T19:07:44  <Murch> Or if you want to understand the code in the first place! :)
 629 2017-07-06T19:08:21  <wumpus> :)
 630 2017-07-06T19:08:51  <wumpus> ok, so anything that needs to be added to project 8?
 631 2017-07-06T19:09:15  <morcos> i have other things needed for 0.15, but they are dependent on the ones i already have in 8
 632 2017-07-06T19:09:28  <morcos> also i already have 3
 633 2017-07-06T19:09:28  <wumpus> ok, just tag them for 0.15 then, don't need to be in that project
 634 2017-07-06T19:09:36  <wumpus> #topic RPC interface for multiwallet (again)
 635 2017-07-06T19:09:36  <jtimon> wumpus: doesn't that qualify for priority?
 636 2017-07-06T19:09:55  <instagibbs> can someone give an overview of what people are thinking on interface for multiwallet... i missed this
 637 2017-07-06T19:09:56  <wumpus> jtimon: if the gain is unclear, I don't think so
 638 2017-07-06T19:09:57  <jonasschnelli> Again we should decide wether we use Endpoints of JSON objects for multiwallet switch... helps to continue on PRs
 639 2017-07-06T19:10:05  <wumpus> instagibbs: please read the current PRs:
 640 2017-07-06T19:10:08  <sipa> wumpus: can we have #10571 #10579 in 0.15?
 641 2017-07-06T19:10:09  <gribble> https://github.com/bitcoin/bitcoin/issues/10571 | [RPC]Move transaction combining from signrawtransaction to new RPC by achow101 · Pull Request #10571 · bitcoin/bitcoin · GitHub
 642 2017-07-06T19:10:10  <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
 643 2017-07-06T19:10:10  <jonasschnelli> The JSON object is simpler... less impect
 644 2017-07-06T19:10:10  <jtimon> wumpus: I think it's clearly a gain
 645 2017-07-06T19:10:36  <jonasschnelli> the endpoint approach may allow more in future...
 646 2017-07-06T19:11:02  <jtimon> I don't understand the criterion then
 647 2017-07-06T19:11:16  <wumpus> #10650 #10653
 648 2017-07-06T19:11:17  <jonasschnelli> In the JSON object approach (where you choose the wallet bases on a JSON array item), I don't like that the actual switch in in the JSON layer.
 649 2017-07-06T19:11:17  <gribble> https://github.com/bitcoin/bitcoin/issues/10650 | Multiwallet: add RPC endpoint support by jonasschnelli · Pull Request #10650 · bitcoin/bitcoin · GitHub
 650 2017-07-06T19:11:18  *** str4d has joined #bitcoin-core-dev
 651 2017-07-06T19:11:18  <gribble> https://github.com/bitcoin/bitcoin/issues/10653 | Simple, backwards compatible RPC multiwallet support by ryanofsky · Pull Request #10653 · bitcoin/bitcoin · GitHub
 652 2017-07-06T19:11:26  <luke-jr> I like the JSON interface, but I worry that when we split out the wallet it will break
 653 2017-07-06T19:11:29  <instagibbs> wumpus, add those to multiwallet project?
 654 2017-07-06T19:11:35  <wumpus> #10650
 655 2017-07-06T19:11:36  <jonasschnelli> It also only works with the new named based argumenst
 656 2017-07-06T19:11:36  <gribble> https://github.com/bitcoin/bitcoin/issues/10650 | Multiwallet: add RPC endpoint support by jonasschnelli · Pull Request #10650 · bitcoin/bitcoin · GitHub
 657 2017-07-06T19:11:40  <wumpus> eh what's the third one?
 658 2017-07-06T19:12:00  <luke-jr> endpoints seemed okay, until the API bump got tacked on..
 659 2017-07-06T19:12:02  <jonasschnelli> I guess the third one (based on Auth) has already been "rejected"? right?
 660 2017-07-06T19:12:08  <wumpus> I don't like the JSON based interface, having to add an optional wallet argument on every wallet call is easy to forget
 661 2017-07-06T19:12:14  <ryanofsky> #10661 works with positional arguments, not just named arguments
 662 2017-07-06T19:12:15  <gribble> https://github.com/bitcoin/bitcoin/issues/10661 | Add optional wallet=filename arguments to wallet RPCs by ryanofsky · Pull Request #10661 · bitcoin/bitcoin · GitHub
 663 2017-07-06T19:12:21  <wumpus> and if you forget it it defaults to the 'default wallet'
 664 2017-07-06T19:12:26  <wumpus> that's just too easy to mess up
 665 2017-07-06T19:12:38  <jonasschnelli> ryanofsky: thanks for clearing this up... wasn't aware, sry
 666 2017-07-06T19:12:40  <wumpus> the endpoint makes sure you can be connected to only one wallet with one RPC connection
 667 2017-07-06T19:12:49  <wumpus> jonasschnelli: right!
 668 2017-07-06T19:12:54  <ryanofsky> i think we should just get rid of the concept of default wallet
 669 2017-07-06T19:13:04  <wumpus> ryanofsky: on the long run, yes, but that's no option for 0.15
 670 2017-07-06T19:13:05  <luke-jr> ryanofsky: definitely not in 0.15
 671 2017-07-06T19:13:13  <kanzure> what about, if more than one wallet, then default wallet must be explicitly specified
 672 2017-07-06T19:13:17  <ryanofsky> if there's more than one wallet, it should just be an error not to specify a wallet
 673 2017-07-06T19:13:20  <wumpus> let's focus on what we want to do now
 674 2017-07-06T19:13:30  <luke-jr> then you break all existing sw
 675 2017-07-06T19:13:31  <wumpus> I think for 0.15 we should simply do the endpoint-based interface
 676 2017-07-06T19:13:34  <ryanofsky> we can do that right now
 677 2017-07-06T19:13:36  <gmaxwell> wumpus: what do you think about the concern that the endpoint stuff establishes a new API that we'll be stuck supporting but haven't given much thought to?
 678 2017-07-06T19:13:37  <ryanofsky> no need to wait
 679 2017-07-06T19:13:52  <sipa> i think as an end goal, endpoint-based selection is awesome, because it prepares for process separation
 680 2017-07-06T19:13:53  <wumpus> gmaxwell: the same is true for any RPC change
 681 2017-07-06T19:13:56  <jonasschnelli> gmaxwell: we can mark it unstable?
 682 2017-07-06T19:14:00  <jonasschnelli> v1 == unstable?
 683 2017-07-06T19:14:09  <jonasschnelli> use / (v0) if you want stability
 684 2017-07-06T19:14:15  <sipa> but if endpoints can't for example remove the non-wallet RPCs, that's sort of not really achieving that goal anyway
 685 2017-07-06T19:14:18  <wumpus> gmaxwell: adding an argument to every wallet RPC call is also such a massive change
 686 2017-07-06T19:14:29  <sipa> wumpus: with named args it's trivial, no?
 687 2017-07-06T19:14:41  <jonasschnelli> I can work on splitting the RPC calls in wallet / nonwallet
 688 2017-07-06T19:14:47  <gmaxwell> (I don't have strong opinions, just raising it)
 689 2017-07-06T19:14:48  <jonasschnelli> if we agree on endpoints
 690 2017-07-06T19:14:50  *** chjj has joined #bitcoin-core-dev
 691 2017-07-06T19:14:51  <ryanofsky> wumpus, are you saying 10661 is a massive change?
 692 2017-07-06T19:14:51  <sipa> and it shouldn't be adding it to every RPC; just catch it in the rpc handler
 693 2017-07-06T19:14:55  <wumpus> but the point is that it'd be something that has to be supported virtually forever
 694 2017-07-06T19:14:58  <luke-jr> (only supporting the default wallet, per rpcauth user, seems the best for backward/forward compatibility still)
 695 2017-07-06T19:14:59  <wumpus> and imo it's poorly thought out
 696 2017-07-06T19:15:16  <wumpus> but I don't care deeply
 697 2017-07-06T19:15:21  <wumpus> at this point we should simply make a choice
 698 2017-07-06T19:15:25  <wumpus> if we don't make a choice today and stick with it
 699 2017-07-06T19:15:26  <gmaxwell> I don't really think named arguments is a great thing. It would make support easier in some software in the short term.
 700 2017-07-06T19:15:30  <wumpus> we can forget multiwallet for 0.15
 701 2017-07-06T19:15:36  <jonasschnelli> ack!
 702 2017-07-06T19:15:36  <gmaxwell> I think every criticism wumpus has on that one is spot on.
 703 2017-07-06T19:15:44  *** str4d has quit IRC
 704 2017-07-06T19:15:56  * luke-jr suggests rpcauth-based default wallet, and we can figure out endpoints for 0.16
 705 2017-07-06T19:16:18  <wumpus> gmaxwell: indeed - most RPC client libraries don't even support named arguments yet
 706 2017-07-06T19:16:22  <luke-jr> that gives more time to think out API change
 707 2017-07-06T19:16:25  <wumpus> gmaxwell: while changing the endpoint is easy, just change the URI
 708 2017-07-06T19:16:48  <wumpus> luke-jr: please don't bring back a third option
 709 2017-07-06T19:16:52  * BlueMatt always kinda assumed named args would allow us to add things like multiwallet/different number precision/etc in the future, as a simple add-on to every RPC without any massive code change everywhere
 710 2017-07-06T19:16:53  <wumpus> luke-jr: that's not going to make it easier
 711 2017-07-06T19:16:54  <BlueMatt> but, ok
 712 2017-07-06T19:16:59  <kanzure> luke-jr: are wallets assigned per rpcauth user already?
 713 2017-07-06T19:17:07  <jonasschnelli> no
 714 2017-07-06T19:17:10  <wumpus> no
 715 2017-07-06T19:17:12  <kanzure> uh..
 716 2017-07-06T19:17:26  <BlueMatt> guess I had a different impression than everyone else, then
 717 2017-07-06T19:17:26  <luke-jr> kanzure: there is no way to use multiwallet right now
 718 2017-07-06T19:17:47  <wumpus> BlueMatt: it's possible, and not hard to implement, but just not the right choice for this IMO
 719 2017-07-06T19:17:56  <jonasschnelli> What about using v1/wallet/y<filename> and mark it unstable (experimental?) for 0.15?
 720 2017-07-06T19:17:59  <ryanofsky> BlueMatt, that was my impression too, it's the basis for 10661 & 10653
 721 2017-07-06T19:18:00  <jonasschnelli> -y
 722 2017-07-06T19:18:05  <sipa> i officially no longer have an opibion on approach
 723 2017-07-06T19:18:07  <wumpus> jonasschnelli: sounds good to me
 724 2017-07-06T19:18:10  <BlueMatt> ok, I mean I dont have a very strong impression, i just always thought that seemed natural
 725 2017-07-06T19:18:18  <luke-jr> wumpus: we should have a per-user default wallet *regardless* of the other options; merging it first is a clean way to defer choosing between the others
 726 2017-07-06T19:18:20  <BlueMatt> but, really, can we flip a coin?
 727 2017-07-06T19:18:32  <sipa> 
 728 2017-07-06T19:18:38  <wumpus> let's just go with endpoints for now
 729 2017-07-06T19:18:55  <jonasschnelli> Somone disagree?
 730 2017-07-06T19:18:57  <midnightmagic> how the heck did you send a blank line
 731 2017-07-06T19:18:59  <jonasschnelli> Anyone
 732 2017-07-06T19:19:01  <gmaxwell> I think we could say that the endpoint version totally unstable and will change to answer the concern that we're setting an api there premately.
 733 2017-07-06T19:19:04  <wumpus> if no one cares deeply, let's just stick with the decision of a few weeks ago
 734 2017-07-06T19:19:25  <instagibbs> gmaxwell, ack
 735 2017-07-06T19:19:29  <jonasschnelli> gmaxwell: we could mark the whole multiwallet (incl. endpoint) as experimental in 0.15
 736 2017-07-06T19:19:33  <jonasschnelli> And stable in 0.16
 737 2017-07-06T19:19:34  <wumpus> midnightmagic: that wasn't a blank line, it as \x7f characters
 738 2017-07-06T19:19:42  <wumpus> gmaxwell: yes, multiwallet is unstable in 0.15, +1
 739 2017-07-06T19:19:51  <wumpus> gmaxwell: there's probably quite some things that need to change, still
 740 2017-07-06T19:19:58  <morcos> no opinon on the issue, but ACK on making a decision.
 741 2017-07-06T19:20:17  <jonasschnelli> ryanofsky: could you live with the endpoint solution?
 742 2017-07-06T19:20:43  <gmaxwell> I think in general we should get into a practice of new API's being explicitly unstable in their first release. We've mulliganed quite a few times.
 743 2017-07-06T19:20:53  <wumpus> gmaxwell: yes
 744 2017-07-06T19:20:53  <ryanofsky> of course, yeah
 745 2017-07-06T19:21:13  <jonasschnelli> okay. Let me finish the endpoint PR and hope it will make it into 0.15
 746 2017-07-06T19:21:18  <wumpus> jonasschnelli: great!
 747 2017-07-06T19:21:33  <jonasschnelli>   /topic
 748 2017-07-06T19:21:40  <wumpus> ryanofsky: thanks
 749 2017-07-06T19:21:59  <luke-jr> jonasschnelli: can you do it on top of 7b73f24311639fdc79c22608c21e4bfcbc6d4243 ?
 750 2017-07-06T19:22:06  <jonasschnelli> pr #?
 751 2017-07-06T19:22:08  <wumpus> any other topics?
 752 2017-07-06T19:22:48  *** annanay25 has quit IRC
 753 2017-07-06T19:22:53  <wumpus> remember morcos was saying something about fee PRs, but not sure it was aimed as a topic
 754 2017-07-06T19:22:56  *** annanay25 has joined #bitcoin-core-dev
 755 2017-07-06T19:22:56  <sipa> wifi just fied in the BS office
 756 2017-07-06T19:22:58  <luke-jr> jonasschnelli: it's part of #10615
 757 2017-07-06T19:22:59  <gmaxwell> I just want to say that master continues to be mostly awesome and performing great. I'm really excited about this next release. (esp if we get our act togeather on multiwallet) :)
 758 2017-07-06T19:23:00  <gribble> https://github.com/bitcoin/bitcoin/issues/10615 | RPC: Allow rpcauth configs to specify a 4th parameter naming a specific wallet (multiwallet RPC support) by luke-jr · Pull Request #10615 · bitcoin/bitcoin · GitHub
 759 2017-07-06T19:23:11  <luke-jr> https://github.com/bitcoin/bitcoin/pull/10615/commits/7b73f24311639fdc79c22608c21e4bfcbc6d4243
 760 2017-07-06T19:23:13  <wumpus> gmaxwell: yeah!
 761 2017-07-06T19:23:15  <jonasschnelli> luke-jr: 7b73f24311639fdc79c22608c21e4bfcbc6d4243 pollutes server.h with CWallet... :/
 762 2017-07-06T19:23:18  <jonasschnelli> (later)
 763 2017-07-06T19:23:29  <BlueMatt> there are a bunch of fee PRs which I think are very useful, and we should try desperately to make progress on them for 15
 764 2017-07-06T19:23:34  <gmaxwell> So yes, there are a number of fee/change handling PRs which are urgent for 0.15.
 765 2017-07-06T19:23:38  <morcos> yeah i don't really have a topic, but i need some review
 766 2017-07-06T19:23:42  <morcos> some are bug fixes
 767 2017-07-06T19:23:47  <gmaxwell> But I don't know what to say beyond that since they're already on the high prio list.
 768 2017-07-06T19:23:48  <wumpus> #topic fee PRs
 769 2017-07-06T19:23:53  <morcos> some are RPC api finalization which would be good to get right
 770 2017-07-06T19:24:03  <jonasschnelli> another topic proposal could be: txoutsbyaddress (it's marked with the 0.15 milestone)
 771 2017-07-06T19:24:38  <morcos> I'm not sure if I broke it up in the easiest way possible for review, but am hesitant to try to reorganize this late in the game...
 772 2017-07-06T19:24:42  <wumpus> jonasschnelli: bleh, server.h should definitely not get a CWallet reference, it's meant to be not specific to bitcoin, let alone wallet
 773 2017-07-06T19:25:02  <jonasschnelli> wumpus: yes. I think the same
 774 2017-07-06T19:25:16  <luke-jr> wumpus: jonasschnelli: I don't see a better alternative.
 775 2017-07-06T19:25:43  <morcos> sounds like jonasschnelli also has his hands full with multiwallet and i think it would have been nice to get access to longer fee estimates in the GUI
 776 2017-07-06T19:25:44  <luke-jr> (keep in mind not all calls will come from the RPC server)
 777 2017-07-06T19:25:48  <morcos> but seems like that is not going to happen
 778 2017-07-06T19:25:52  <jonasschnelli> luke-jr: https://github.com/bitcoin/bitcoin/pull/10650/files#diff-df7d84ff2f53fcb2a0dc15a3a51e55ceR36
 779 2017-07-06T19:26:00  <wumpus> luke-jr: there are certainly alternatives, more general ways to attach custom data to a structure, but let's leave this for another time
 780 2017-07-06T19:26:06  <gmaxwell> morcos: oh the gui doesn't have access to the new estimates?  thats unfortunate.
 781 2017-07-06T19:26:14  <gmaxwell> I guess I need to do some gui testing, haven't used it in a while.
 782 2017-07-06T19:26:16  <morcos> gmaxwell: no
 783 2017-07-06T19:26:16  <bitcoin-git> [bitcoin] ryanofsky closed pull request #10661: Add optional wallet=filename arguments to wallet RPCs (master...pr/multiopt) https://github.com/bitcoin/bitcoin/pull/10661
 784 2017-07-06T19:26:23  <jonasschnelli> gmaxwell: just not the conf target > 26+
 785 2017-07-06T19:26:27  <luke-jr> jonasschnelli: that doesn't work for GUI or tests
 786 2017-07-06T19:26:35  <morcos> no way to ask for non-conservative.  but at least after one of my PR's it'll default to that if tx is replaceable
 787 2017-07-06T19:26:39  <luke-jr> anyhow, later..
 788 2017-07-06T19:26:57  <jonasschnelli> non-conservative would be simple (a checkbox?)
 789 2017-07-06T19:27:15  <jonasschnelli> a slider with fix positions make little sense... sliders are ment to be linear
 790 2017-07-06T19:27:22  <jonasschnelli> A dropdown could make more sense
 791 2017-07-06T19:27:26  * luke-jr likes dropdown
 792 2017-07-06T19:27:30  <morcos> jonasschnelli: yes sort of.  the way it is implemented elsewhere is it defaults to the opposite of opt in rbf, but you coudl force it either way
 793 2017-07-06T19:27:43  <luke-jr> "ASAP", "today", "this week", "eventually"
 794 2017-07-06T19:28:05  <jonasschnelli> luke-jr: names tend to bikeshed... but at least "conf-target in block  |  time"
 795 2017-07-06T19:28:13  * luke-jr shrugs
 796 2017-07-06T19:28:31  <jonasschnelli> Or maybe "time | blocks | feerate"
 797 2017-07-06T19:28:52  <jonasschnelli> Ideally we would run coinselection when opening the dropdown to tell the (possible) absolute fee
 798 2017-07-06T19:29:03  <morcos> jonasschnelli: please no
 799 2017-07-06T19:29:08  <morcos> feerate selection first
 800 2017-07-06T19:29:12  <morcos> then coin selection
 801 2017-07-06T19:29:14  <jonasschnelli> heh.. I though somebody will complain. :)
 802 2017-07-06T19:29:18  <achow101> coin selection needs fee rate..
 803 2017-07-06T19:29:20  <gmaxwell> we can't realistically do that. We need the feerate to perform selection.
 804 2017-07-06T19:29:32  <morcos> in the future coin selection may be different depending on feerate anyway
 805 2017-07-06T19:29:38  <gmaxwell> (and will need it more in the future)
 806 2017-07-06T19:29:39  <jonasschnelli> gmaxwell: do it for all options ... *duck*
 807 2017-07-06T19:29:48  <luke-jr> >_<
 808 2017-07-06T19:29:59  <luke-jr> coin selection can be slow, unless that's been optimised
 809 2017-07-06T19:30:00  <jonasschnelli> Thoughs about the dropbox?
 810 2017-07-06T19:30:10  <sipa> "The next Bitcoin-Qt version requires a 4k screen for coin selection"
 811 2017-07-06T19:30:14  <morcos> in any case, i think _something_ simple would be ideal so users have access to longer than 25 confirms
 812 2017-07-06T19:30:15  <BlueMatt> lol
 813 2017-07-06T19:30:17  <gmaxwell> jonasschnelli: well we'd like to be able to do good selections which won't be instant. thats something that could be expiremented with later.
 814 2017-07-06T19:30:18  <jonasschnelli> I'm happy to do it if it's general accaptable (the dropbown)
 815 2017-07-06T19:30:21  <BlueMatt> sipa: ooo, I have those, sounds gogod!
 816 2017-07-06T19:30:23  <BlueMatt> good
 817 2017-07-06T19:31:08  <gmaxwell> well we do want multiple near term options because of market effects.  e.g. 2,3,4,5,6,72,today,two days, three days, five days, 1 week... or something.
 818 2017-07-06T19:31:17  <jtimon> what about a box with number of blocks instead of a dropbox ?
 819 2017-07-06T19:31:26  <morcos> jonasschnelli: sure. something, anything.  but recommend you build off my other PR #10706
 820 2017-07-06T19:31:27  <gribble> https://github.com/bitcoin/bitcoin/issues/10706 | Improve wallet fee logic and fix GUI bugs by morcos · Pull Request #10706 · bitcoin/bitcoin · GitHub
 821 2017-07-06T19:31:29  <jonasschnelli> I'll try the dropdown and see how it feels.. should not be that hard
 822 2017-07-06T19:31:31  <jtimon> er dropdown
 823 2017-07-06T19:31:34  <jonasschnelli> morcos: will do
 824 2017-07-06T19:31:35  <sipa> do we have to do GUI design in this meeting?
 825 2017-07-06T19:31:43  <luke-jr> XD
 826 2017-07-06T19:31:50  <Murch> gmawell, it could estimate with a blocktarget of ~6 and do that before the window opens? ;)
 827 2017-07-06T19:31:52  <morcos> no i was just hoping for someone else to volunteer since seems jonas has a lot to do
 828 2017-07-06T19:32:11  <Murch> or whatever the default is nowaays
 829 2017-07-06T19:32:14  <morcos> and 0.15 is fast approaching
 830 2017-07-06T19:32:16  <gmaxwell> sipa: that wasn't GUI design, quite the opposite, there are economic reasons that gui clumping people wouldn't be great.
 831 2017-07-06T19:32:19  <luke-jr> I could give it a shot, I guess.
 832 2017-07-06T19:32:44  <jonasschnelli> luke-jr: I just started... :)
 833 2017-07-06T19:32:50  <luke-jr> heh
 834 2017-07-06T19:32:57  <morcos> either or, i'll let you guys work it out, but i'm bad at gUI, but i did make several changes already in the prior PR.   thanks!!
 835 2017-07-06T19:33:50  <wumpus> #topic txoutsbyaddress (it's marked with the 0.15 milestone)
 836 2017-07-06T19:33:55  <wumpus> I think we should remove that milestone
 837 2017-07-06T19:34:06  <gmaxwell> Sadly. Has anyone been working on it?
 838 2017-07-06T19:34:12  <wumpus> #9806  has been quite inactive
 839 2017-07-06T19:34:14  <gribble> https://github.com/bitcoin/bitcoin/issues/9806 | txoutsbyaddress index (take 3) by droark · Pull Request #9806 · bitcoin/bitcoin · GitHub
 840 2017-07-06T19:34:15  <jonasschnelli> I'm more interested about should we or or not add an index for that
 841 2017-07-06T19:34:24  <wumpus> not publicly at least
 842 2017-07-06T19:34:37  <jonasschnelli> The best index implementations is currently the one from Bitpay,.. not?
 843 2017-07-06T19:34:43  <gmaxwell> jonasschnelli: I think we should; unlike many other things it's actually sustainable.
 844 2017-07-06T19:34:59  <jonasschnelli> I tend to also think we should
 845 2017-07-06T19:35:01  *** chjj has quit IRC
 846 2017-07-06T19:35:06  <jonasschnelli> (after installed a BWS index)
 847 2017-07-06T19:35:08  <gmaxwell> the bitpay index stuff is utterly unmaintable and borderline abandonware; fwiw.
 848 2017-07-06T19:35:21  <jtimon> why not by scriptpubkey ? that seems more generic
 849 2017-07-06T19:35:25  <sipa> there is some indexd project
 850 2017-07-06T19:35:30  <jonasschnelli> The most stables index I could find so far is that one: https://github.com/bitcoin/bitcoin/pull/10370
 851 2017-07-06T19:35:36  <gmaxwell> jtimon: yes, I think that was suggested on the PR.
 852 2017-07-06T19:35:42  <instagibbs> dcousens has an external index project which I think sipa is referring to
 853 2017-07-06T19:35:50  <jonasschnelli> (it's the one BWS [Bitpay wallet service] is unsing in the fileld since a couple of years)
 854 2017-07-06T19:36:27  <gmaxwell> jonasschnelli: the UTXO indexes are special because they actually have viable scalablity...
 855 2017-07-06T19:36:43  <sipa> https://github.com/bitcoinjs/indexd
 856 2017-07-06T19:36:48  <gmaxwell> I think anyone depending on complete blockchain indexes will eventually be forced onto centeralized servers, unfortunately.
 857 2017-07-06T19:37:02  <gmaxwell> so I have much less interest in internal support (hooks for external things sound fine though)
 858 2017-07-06T19:37:44  <jonasschnelli> Agree. Maybe internal txoutsbyaddress and for the rest, use something like indexd that sipa mentioned
 859 2017-07-06T19:38:08  <instagibbs> https://github.com/bitcoinjs/indexd
 860 2017-07-06T19:38:09  <wumpus> UTXO indexes would be nice, I'd love to have more query functionality for the UTXO set, we have to track that anyway with a full node
 861 2017-07-06T19:38:14  <jcorgan> i've taken to using zmq to notify of new txes/blocks and the REST API to retrieve parsed info about them, for indexing externally
 862 2017-07-06T19:38:25  <morcos> I've got to run, but someone please tag #10557 #10589 #10707 #10712 for 0.15
 863 2017-07-06T19:38:26  <gribble> https://github.com/bitcoin/bitcoin/issues/10557 | Make check to distinguish between orphan txs and old txs more efficient. by morcos · Pull Request #10557 · bitcoin/bitcoin · GitHub
 864 2017-07-06T19:38:27  <jonasschnelli> I guess one reason why some of the centralized services (like the BWS) still is based on 0.12.1 is because the indexes where never added to Core master branch
 865 2017-07-06T19:38:28  <gribble> https://github.com/bitcoin/bitcoin/issues/10589 | More economical fee estimates for RBF and RPC options to control by morcos · Pull Request #10589 · bitcoin/bitcoin · GitHub
 866 2017-07-06T19:38:29  <gribble> https://github.com/bitcoin/bitcoin/issues/10707 | Better API for estimatesmartfee RPC by morcos · Pull Request #10707 · bitcoin/bitcoin · GitHub
 867 2017-07-06T19:38:30  <gribble> https://github.com/bitcoin/bitcoin/issues/10712 | Add change output if necessary to reduce excess fee by morcos · Pull Request #10712 · bitcoin/bitcoin · GitHub
 868 2017-07-06T19:39:06  <wumpus> huh what is gribble doing
 869 2017-07-06T19:39:12  <gmaxwell> wumpus: right. also if ever we support having pruned wallets (wallets that don't know their full history, but do have their full coins), the txout index is something we need for it... but not other indexes.
 870 2017-07-06T19:39:12  <wumpus> oh sure morcos
 871 2017-07-06T19:39:12  <morcos> (sorry)
 872 2017-07-06T19:39:21  <wumpus> gmaxwell: yes!
 873 2017-07-06T19:39:30  <jonasschnelli> tagged
 874 2017-07-06T19:39:56  <jonasschnelli> gmaxwell: yes. For HD restores in pruned env. the utxo index is handy
 875 2017-07-06T19:39:57  <wumpus> gmaxwell: would be very niec to instantly query the balance, if history isn't important
 876 2017-07-06T19:40:33  <gmaxwell> rescan has become so slow for me at least that I'm kinda desperate for something like that.
 877 2017-07-06T19:40:41  <gmaxwell> I've lost days of time waiting on rescans.
 878 2017-07-06T19:41:42  <wumpus> next topic?
 879 2017-07-06T19:42:09  <sipa> nope.
 880 2017-07-06T19:42:25  <gmaxwell> wumpus: can you remind me of the 0.15 schedule?
 881 2017-07-06T19:42:30  <luke-jr> eh, UTXO isn't a substitute for rescanning.. you'd miss historical txs
 882 2017-07-06T19:42:48  <BlueMatt> #9961
 883 2017-07-06T19:42:48  <gribble> https://github.com/bitcoin/bitcoin/issues/9961 | Release schedule for 0.15.0 · Issue #9961 · bitcoin/bitcoin · GitHub
 884 2017-07-06T19:42:58  <gmaxwell> luke-jr: thus pruned wallet, ... it's fine to not have historical txs if you know you don't.
 885 2017-07-06T19:43:13  <gmaxwell> BlueMatt: thanks!
 886 2017-07-06T19:43:15  <wumpus> luke-jr: what if you don't care about history, and just want balance + possibly spending?
 887 2017-07-06T19:43:21  <BlueMatt> T-10 days to branch
 888 2017-07-06T19:43:22  <luke-jr> gmaxwell: but you'd end up with *some* historical tx in this case, with no deterministic reason why some are missing
 889 2017-07-06T19:43:27  <gmaxwell> luke-jr: you can also say that txes found on the blockchain aren't a replacement for having their metadata... :)
 890 2017-07-06T19:43:35  <luke-jr> I suppose we could import them as all change-only or something? :/
 891 2017-07-06T19:43:38  <jonasschnelli> luke-jr: you can scan in the background for the history in a very slow manner once you have done it via the UTXO set index
 892 2017-07-06T19:43:40  <wumpus> BlueMatt: no, not to branch, to feature freeze
 893 2017-07-06T19:43:50  <sipa> wumpus: it'd be incompatible with hardware wallets, before segwit
 894 2017-07-06T19:43:51  <luke-jr> jonasschnelli: hmm, good idea
 895 2017-07-06T19:43:58  <sipa> as you need the full crediting txn
 896 2017-07-06T19:44:00  <gmaxwell> luke-jr: no you wouldn't: my suggestion is that a pruned wallet basically have a line shown in the UI where nothing is there before it except a move like ledger entry that shows the earlier balance.
 897 2017-07-06T19:44:13  <BlueMatt> oh, sorry, yes, freeze
 898 2017-07-06T19:44:16  <wumpus> BlueMatt: branch is 2017-08-06, so a month away
 899 2017-07-06T19:44:20  <gmaxwell> luke-jr: I made an issue describing some ideas for that a while back.
 900 2017-07-06T19:44:21  <luke-jr> gmaxwell: I see, makes sense
 901 2017-07-06T19:45:05  <achow101> wumpus: can #10571 and #10579 be tagged for 0.15?
 902 2017-07-06T19:45:07  <gribble> https://github.com/bitcoin/bitcoin/issues/10571 | [RPC]Move transaction combining from signrawtransaction to new RPC by achow101 · Pull Request #10571 · bitcoin/bitcoin · GitHub
 903 2017-07-06T19:45:08  <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
 904 2017-07-06T19:45:21  <gmaxwell> There are other reasons why building such things are attractive... (e.g. UTXO based sync can't provide the data to give history...)
 905 2017-07-06T19:45:32  <wumpus> achow101: sure
 906 2017-07-06T19:45:44  <achow101> thanks
 907 2017-07-06T19:45:48  <gmaxwell> ack
 908 2017-07-06T19:48:55  <sipa> early lunch?
 909 2017-07-06T19:49:52  <wumpus> ye fine with me
 910 2017-07-06T19:49:54  <wumpus> #endmeeting
 911 2017-07-06T19:49:54  <lightningbot> Meeting ended Thu Jul  6 19:49:54 2017 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
 912 2017-07-06T19:49:54  <lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-07-06-19.00.html
 913 2017-07-06T19:49:54  <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-07-06-19.00.txt
 914 2017-07-06T19:49:54  <lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-07-06-19.00.log.html
 915 2017-07-06T19:50:32  <spudowiar> Hardware wallet support rebased and now supports change addresses properly
 916 2017-07-06T19:50:39  <jtimon> so why is #8498 not to be tagged for 0.15 nor project 8 ? I want to understand the criterion
 917 2017-07-06T19:50:40  <gribble> https://github.com/bitcoin/bitcoin/issues/8498 | Near-Bugfix: Optimization: Minimize the number of times it is checked that no money... by jtimon · Pull Request #8498 · bitcoin/bitcoin · GitHub
 918 2017-07-06T19:50:49  <jtimon> criteria
 919 2017-07-06T19:52:29  <wumpus> jtimon: well if others think it should be tagged 0.15 or be high priority for review it's fine with me
 920 2017-07-06T19:52:37  <spudowiar> There are a few things I need to tackle now
 921 2017-07-06T19:52:49  <spudowiar> a) How the plugin can tell whether it is Testnet or Mainnet
 922 2017-07-06T19:52:56  <wumpus> jtimon: I don't personally see it as urgent enough for that, it's an optimization without mentioning timings
 923 2017-07-06T19:53:24  <wumpus> jtimon: but that's just my opinion
 924 2017-07-06T19:53:29  <jtimon> I see, thanks
 925 2017-07-06T19:53:35  <spudowiar> b) How the plugin can show a UI? (e.g. TREZOR Pin Matrix)
 926 2017-07-06T19:53:57  <spudowiar> Maybe the plugin can just create a window itself
 927 2017-07-06T19:54:12  <wumpus> spudowiar: la) aunch it with a flag/option that specifies which block chain
 928 2017-07-06T19:54:18  <wumpus> spudowiar: b) yes, have it draw it itself
 929 2017-07-06T19:54:52  <jtimon> well, the timinigs changed over time. now acceptToMemoryPool is not as redundant in fee calculation as it sued to be, and the number of places where checkinouts have been called from has been varying as well
 930 2017-07-06T19:55:08  *** talmai has joined #bitcoin-core-dev
 931 2017-07-06T19:55:09  <spudowiar> c) Multiple devices (I'm going to add a device identifier parameter and a listhwwdevices method to the plugin)
 932 2017-07-06T19:55:11  <wumpus> spudowiar: or have a command askPin() from the plugin that shows a simple Qt message box with a prompt
 933 2017-07-06T19:55:19  <spudowiar> wumpus: It has a special GUI though
 934 2017-07-06T19:55:31  <spudowiar> Hence why I chose that example
 935 2017-07-06T19:55:38  <wumpus> spudowiar: if it has a special gui it should definitely draw it itself, bitcoin qt can't get into the UI delegation/embedding business
 936 2017-07-06T19:55:50  <jtimon> but there's more checkinputs calls now than when I first coded the thing
 937 2017-07-06T19:56:19  <spudowiar> d) Simplify usage (e.g. without command line parameters)
 938 2017-07-06T19:56:34  <spudowiar> This would require to store the plugin name and the device identifier somewhere (probably bitcoin.conf to begin with)
 939 2017-07-06T19:56:54  <spudowiar> e) Need to test multisig
 940 2017-07-06T19:56:57  <wumpus> yes
 941 2017-07-06T19:57:26  <spudowiar> yes to what?
 942 2017-07-06T19:57:59  <wumpus> "This would require to store the plugin name and the device identifier somewhere (probably bitcoin.conf to begin with)"
 943 2017-07-06T19:58:10  <spudowiar> ok
 944 2017-07-06T19:58:32  <jtimon> #10195 and #10192 likely changed how much of an improvement #8498 is as well
 945 2017-07-06T19:58:36  <gribble> https://github.com/bitcoin/bitcoin/issues/10195 | Switch chainstate db and cache to per-txout model by sipa · Pull Request #10195 · bitcoin/bitcoin · GitHub
 946 2017-07-06T19:58:38  <gribble> https://github.com/bitcoin/bitcoin/issues/10192 | Cache full script execution results in addition to signatures by TheBlueMatt · Pull Request #10192 · bitcoin/bitcoin · GitHub
 947 2017-07-06T19:58:40  <gribble> https://github.com/bitcoin/bitcoin/issues/8498 | Near-Bugfix: Optimization: Minimize the number of times it is checked that no money... by jtimon · Pull Request #8498 · bitcoin/bitcoin · GitHub
 948 2017-07-06T19:58:48  <spudowiar> Not going to bother with listhwwdevices for now (that would be useful for a GUI to select the hardware device)
 949 2017-07-06T19:59:23  <wumpus> jtimon: some kind of measurement would be nice, e.g. startup time with a large wallet
 950 2017-07-06T20:00:00  <wumpus> spudowiar: agreed, auto-detecting devices would be something for later
 951 2017-07-06T20:00:06  <jtimon> why a wallet? the improvements are in connectBlock and AcceptToMemoryPool
 952 2017-07-06T20:00:35  <jtimon> wumpus: specially on the latter
 953 2017-07-06T20:00:55  <wumpus> jtimon: I'm confused then - yes wallet would not be appropriate then
 954 2017-07-06T20:01:32  <spudowiar> Oh, and I need to get rid of boost::process dependency
 955 2017-07-06T20:01:44  <instagibbs> spudowiar, please do :P
 956 2017-07-06T20:01:54  <wumpus> I would first focus on functionality
 957 2017-07-06T20:02:00  <jonasschnelli> spudowiar: I think URI schema is the best option for the GUI
 958 2017-07-06T20:02:01  <spudowiar> instagibbs: Find me an alternative :) I don't know C++
 959 2017-07-06T20:02:05  <wumpus> then only when it works, on removing dependencies
 960 2017-07-06T20:02:13  <jonasschnelli> call sign://
 961 2017-07-06T20:02:19  <wumpus> too easy to get stuck in yak shaving dependencies
 962 2017-07-06T20:02:19  <jonasschnelli> or bitcoinsign://
 963 2017-07-06T20:02:26  <spudowiar> jonasschnelli: That overcomplicates things in my opinion
 964 2017-07-06T20:02:49  <instagibbs> wumpus, it's a super new module, only reason I care
 965 2017-07-06T20:02:51  <jonasschnelli> It's a clean separation... could work as a standard
 966 2017-07-06T20:02:59  <jonasschnelli> Otherwise other non-core application could not tab in
 967 2017-07-06T20:03:00  <spudowiar> jonasschnelli: How do you get the data back, anyway?
 968 2017-07-06T20:03:10  <instagibbs> I don't feel like installing it to test his work, so I've rolled my own solution until then
 969 2017-07-06T20:03:31  <spudowiar> jonasschnelli: Why can't non-Core applications use these plugins?
 970 2017-07-06T20:03:32  <jonasschnelli> Core sends: bitcoinsign://signtx?data=blabla&callback=bitcoincore
 971 2017-07-06T20:03:43  <jonasschnelli> spudowiar: you plugin would call back bitcoincore://
 972 2017-07-06T20:03:44  <sipa> why a URI...?
 973 2017-07-06T20:03:45  <spudowiar> So, Core needs to register its own protocol now?
 974 2017-07-06T20:03:53  <spudowiar> URIs are really unnecessary here
 975 2017-07-06T20:03:57  <jonasschnelli> sipa: URI is the only think that works in sandboxed env
 976 2017-07-06T20:04:04  <sipa> jonasschnelli: i don't understand
 977 2017-07-06T20:04:07  <jonasschnelli> (Android, iOS, OSX [soonish])
 978 2017-07-06T20:04:20  <sipa> ?
 979 2017-07-06T20:04:42  <jonasschnelli> In sandboxed enviroments, interprocess communication is impossible, expect over URIs
 980 2017-07-06T20:04:45  <spudowiar> jonasschnelli: JSON-RPC is transport agnostic
 981 2017-07-06T20:04:55  <spudowiar> jonasschnelli: So you can do JSON-RPC over URI if you want, on those platforms
 982 2017-07-06T20:05:03  <spudowiar> I'd prefer not to register arbitrary protocols on my desktop though
 983 2017-07-06T20:05:17  <sipa> ok, so use some wrapper URI on those platforms
 984 2017-07-06T20:05:19  <spudowiar> Not when a perfectly suitable solution exists
 985 2017-07-06T20:05:27  <gmaxwell> what sipa said
 986 2017-07-06T20:05:30  <sipa> not as part of the IPC mechanism in general
 987 2017-07-06T20:05:41  <jonasschnelli> that makes sense....
 988 2017-07-06T20:06:01  <jonasschnelli> in my example: bitcoinsign://signtx?data=blabla&callback=bitcoincore the blabla elements could be the JSON/RPC layer
 989 2017-07-06T20:06:18  <spudowiar> Yep
 990 2017-07-06T20:06:43  <spudowiar> At the moment though, I require the JSON-RPC to be in roughly getrawtransaction format
 991 2017-07-06T20:07:01  <spudowiar> I want to strip parts of that out, then write documentation for the protocol
 992 2017-07-06T20:07:55  <jonasschnelli> I have a branch somewhere where the GUI can select watchonly unspents and create a hex-tx instead when signing... I once thought you may should be able to forware that unsigned hex tx (including utxos) to another app via URI-schema
 993 2017-07-06T20:08:00  <spudowiar> https://github.com/saleemrashid/bitcoin/blob/hardware-wallet/src/wallet/wallet.cpp#L1500
 994 2017-07-06T20:08:44  *** spudowiar has quit IRC
 995 2017-07-06T20:14:05  *** clarkmoody has joined #bitcoin-core-dev
 996 2017-07-06T20:15:18  *** talmai has quit IRC
 997 2017-07-06T20:26:41  <bitcoin-git> [bitcoin] theuni opened pull request #10756: net processing: swap out signals for an interface class (master...no-net-signals2) https://github.com/bitcoin/bitcoin/pull/10756
 998 2017-07-06T20:27:45  <cfields> BlueMatt: I was holding off on ^^ because I thought it might stomp on some of your other PRs, but after taking a look, I think it might actually make your life a little easier
 999 2017-07-06T20:28:00  *** Aaronvan_ has joined #bitcoin-core-dev
1000 2017-07-06T20:29:49  *** talmai has joined #bitcoin-core-dev
1001 2017-07-06T20:30:26  <gmaxwell> <3
1002 2017-07-06T20:31:08  *** AaronvanW has quit IRC
1003 2017-07-06T20:31:41  <gmaxwell> though it shows how much y'all have worn me down about C++ features that I'm cheering for inheretence. :)
1004 2017-07-06T20:32:11  <cfields> heh
1005 2017-07-06T20:32:25  <gmaxwell> my backtraces thank you, however.
1006 2017-07-06T20:32:54  <gmaxwell> I believe this may be measurably faster too... when I ripped out signals and replaced it with direct function calls it was.
1007 2017-07-06T20:33:06  <gmaxwell> the signals stuff has thread synchronization inside it.
1008 2017-07-06T20:33:12  <cfields> yea. I should add that to the PR description.. that might actually be the nicest part of the change
1009 2017-07-06T20:33:27  <cfields> gmaxwell: yea, i've owed you this PR for months now. Sorry for the delay.
1010 2017-07-06T20:33:48  <gmaxwell> Don't worry, I didn't remember.
1011 2017-07-06T20:34:21  <cfields> heh ok
1012 2017-07-06T20:41:26  *** talmai has quit IRC
1013 2017-07-06T20:43:55  *** talmai has joined #bitcoin-core-dev
1014 2017-07-06T20:49:01  *** talmai has quit IRC
1015 2017-07-06T20:54:38  *** Aaronvan_ is now known as AaronvanW
1016 2017-07-06T20:55:30  *** Guyver2_ has joined #bitcoin-core-dev
1017 2017-07-06T20:56:43  *** Guyver2 has quit IRC
1018 2017-07-06T20:56:43  *** Guyver2_ is now known as Guyver2
1019 2017-07-06T21:12:30  *** jamesob has joined #bitcoin-core-dev
1020 2017-07-06T21:13:15  <jamesob> any thoughts on adding a Dockerfile to the repo? might make setting up a dev environment marginally easier
1021 2017-07-06T21:20:25  *** jamesob has quit IRC
1022 2017-07-06T21:22:09  *** jtimon has quit IRC
1023 2017-07-06T21:42:53  *** Chris_Stewart_5 has quit IRC
1024 2017-07-06T21:46:48  *** paracyst is now known as pex
1025 2017-07-06T21:46:58  *** pex is now known as paracyst
1026 2017-07-06T22:17:13  *** vicenteH has quit IRC
1027 2017-07-06T22:17:26  *** chjj has joined #bitcoin-core-dev
1028 2017-07-06T22:19:24  *** stalictite has quit IRC
1029 2017-07-06T22:20:50  *** jtimon has joined #bitcoin-core-dev
1030 2017-07-06T22:23:21  *** stalictite has joined #bitcoin-core-dev
1031 2017-07-06T22:25:49  <stalictite> what's the armory dev irc?
1032 2017-07-06T22:26:03  <stalictite> nvm got it
1033 2017-07-06T22:27:04  *** sanada` has joined #bitcoin-core-dev
1034 2017-07-06T22:28:52  *** sanada has quit IRC
1035 2017-07-06T22:32:21  *** Guyver2 has quit IRC
1036 2017-07-06T22:51:28  *** chjj has quit IRC
1037 2017-07-06T23:05:06  *** chjj has joined #bitcoin-core-dev
1038 2017-07-06T23:20:43  *** Dyaheon has quit IRC
1039 2017-07-06T23:21:20  *** Dyaheon has joined #bitcoin-core-dev
1040 2017-07-06T23:21:35  <bitcoin-git> [bitcoin] jtimon opened pull request #10757: RPC: Introduce getperblockstats to plot things (master...b15-rpc-plotter) https://github.com/bitcoin/bitcoin/pull/10757
1041 2017-07-06T23:27:38  <jtimon> I "had" to delete ~/.bitcoin yesterday until I learned how to cleanup things in docker (damm, should have just copied it to another disk), otherwise I could have seen the historic min fee and feerate per block that I've always wanted to see...
1042 2017-07-06T23:34:14  <jtimon> I hope it's well tested, I rarely introduce new features and didn't run the coverage thing, but I think I cover all the new code
1043 2017-07-06T23:35:31  *** chjj has quit IRC
1044 2017-07-06T23:40:20  <jtimon> not sure what the proper C++11 replacement for boost::split(plot_values, str_plot_values, boost::is_any_of(",")); would be
1045 2017-07-06T23:41:03  <sipa> i don't believe c++11 has a replacement for that
1046 2017-07-06T23:41:11  <jtimon> :(
1047 2017-07-06T23:41:18  <jtimon> c++14 ?
1048 2017-07-06T23:41:38  <sipa> https://stackoverflow.com/a/5167799
1049 2017-07-06T23:44:00  <jtimon> yeah, I think the best I found was that or close to that, but it's still very ugly imo, you can still see the loop!
1050 2017-07-06T23:45:32  <jtimon> I would like a std::vector<std::string> std::string::split(std::string), like python
1051 2017-07-06T23:46:18  <sipa> you can write such a function :)
1052 2017-07-06T23:46:20  <jtimon> anyway, my build is failing to compile in some platforms, it seems univalue is not as multiplatform as I thought
1053 2017-07-06T23:47:23  <jtimon> yeah, I could write such a function and replace it everywhere I guess, instead of only using it in the new rpc function
1054 2017-07-06T23:48:02  <jtimon> oh, you mean for C++ ?
1055 2017-07-06T23:48:09  *** chjj has joined #bitcoin-core-dev
1056 2017-07-06T23:50:16  <jtimon> we don't use it all that much in bitcoin https://0bin.net/paste/p8nz4NJTOuyw622R#A-qZ020Wy3jsQcl6Py3H1KDYJkxjrO7QnCqmauzad7L but I guess that's another idea for a scripted-diff PR
1057 2017-07-06T23:57:14  <sipa> jtimon: in #10757 you're pushing a size_t into UniValue
1058 2017-07-06T23:57:15  <gribble> https://github.com/bitcoin/bitcoin/issues/10757 | RPC: Introduce getperblockstats to plot things by jtimon · Pull Request #10757 · bitcoin/bitcoin · GitHub
1059 2017-07-06T23:57:21  <sipa> size_t is platform dependent
1060 2017-07-06T23:57:30  <sipa> cast it to int64_t first
1061 2017-07-06T23:57:48  <jtimon> yeah, I thought I had to use to constructor for all ints, it'sjust a simple cast
1062 2017-07-06T23:57:52  <jtimon> thanks