1 2017-07-06 00:44:50	0|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.
  2 2017-07-06 00:48:25	0|kanzure|oh, "achow101's implementation uses a 1008 block feerate estimate" for the change output amount check before decide burn to miner fee?
  3 2017-07-06 00:49:37	0|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
  4 2017-07-06 00:50:24	0|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.
  5 2017-07-06 00:51:02	0|gmaxwell|because complex hairball.
  6 2017-07-06 00:51:18	0|gmaxwell|Achow's stuff doesn't have that issue, the branch and bound thing assumes always that there will be no change.
  7 2017-07-06 00:51:19	0|kanzure|is there a writeup of a wishlist for simulators in this area, or is that also hairball land?
  8 2017-07-06 00:52:32	0|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.
  9 2017-07-06 00:56:16	0|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.
 10 2017-07-06 01:00:24	0|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.)
 11 2017-07-06 01:37:20	0|fanquake|Would anyone object to #8550 going into 0.15 ?
 12 2017-07-06 01:37:22	0|gribble|https://github.com/bitcoin/bitcoin/issues/8550 | [Qt] Add interactive mempool graph by jonasschnelli · Pull Request #8550 · bitcoin/bitcoin · GitHub
 13 2017-07-06 01:47:23	0|gmaxwell|:(
 14 2017-07-06 01:47:34	0|gmaxwell|Thats the graph that doesn't break things up by feerate?
 15 2017-07-06 01:47:44	0|gmaxwell|those sorts of graphs have had really bad effects in social media.
 16 2017-07-06 01:48:06	0|gmaxwell|People flood with minrelay fee txn to push the numbers up. and then spam with OMG MEMPOOL FULL SELL BITCOINS NOW
 17 2017-07-06 01:48:35	0|gmaxwell|Since rate breaking up graphs became more common those minrelay floods seem to have stopped.
 18 2017-07-06 02:08:40	0|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.
 19 2017-07-06 02:19:24	0|morcos|fanquake: that PR is based on #8501 which seems like hasn't gotten work in quite some time
 20 2017-07-06 02:19:25	0|gribble|https://github.com/bitcoin/bitcoin/issues/8501 | Add mempool statistics collector by jonasschnelli · Pull Request #8501 · bitcoin/bitcoin · GitHub
 21 2017-07-06 02:19:44	0|morcos|in any case I don't think it's making it for 0.15 at this point
 22 2017-07-06 02:31:08	0|fanquake|morcos Fair enough. Will concentrate on other PRs. Need to put aside some time to look through all your fee work.
 23 2017-07-06 05:50:44	0|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?
 24 2017-07-06 05:51:18	0|jtimon|I bet I'm missing something, but not sure what
 25 2017-07-06 05:53:39	0|jtimon|oh, there's no in.prevout.n anymore, nevermind
 26 2017-07-06 05:55:34	0|jtimon|wait...I'll think more about this, I know how to fing the PR that's relevant
 27 2017-07-06 06:33:39	0|gmaxwell|jtimon: you cannot. The database doesn't efficiently support that access anymore, it shouldn't generally be needed.
 28 2017-07-06 06:38:48	0|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
 29 2017-07-06 06:39:30	0|jtimon|summary: AccessByTxid seems completely uinsafe to me at this point unless I'm missing something
 30 2017-07-06 06:39:52	0|jtimon|which is not uncommon
 31 2017-07-06 06:50:52	0|sipa|jtimon: AccessByTxid is only for finding height/coinbase
 32 2017-07-06 06:51:00	0|sipa|obviously you can't use it to find an actual output
 33 2017-07-06 06:52:07	0|jtimon|oh, I see, that's what I was missing
 34 2017-07-06 06:52:28	0|sipa|it's also extremely slow
 35 2017-07-06 06:52:45	0|jtimon|it still seems weird that you have access to some arvitrary txout from it though
 36 2017-07-06 06:52:59	0|sipa|i guess
 37 2017-07-06 06:53:27	0|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)
 38 2017-07-06 06:54:52	0|jtimon|it shouldn't retun a full coin class, or something, anyway, thank you for the missing piece
 39 2017-07-06 06:56:14	0|sipa|seems very reasonable to document that
 40 2017-07-06 06:58:46	0|sipa|gmaxwell: finding CTxOuts is totally doable though... you just need AccessCoin not AccessByTxid
 41 2017-07-06 06:59:42	0|sipa|(Coin contains a CTxOut and fCoinbase and nHeight)
 42 2017-07-06 07:46:59	0|bitcoin-git|13bitcoin/06master 14191d12b 15Wladimir J. van der Laan: qt: First translations update for 0.15
 43 2017-07-06 07:46:59	0|bitcoin-git|[13bitcoin] 15laanwj pushed 1 new commit to 06master: 02https://github.com/bitcoin/bitcoin/commit/191d12b07377393c9eb67770ff5cb8e9a1c5cd7c
 44 2017-07-06 07:48:17	0|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
 45 2017-07-06 08:08:34	0|wumpus|https://lists.linuxfoundation.org/pipermail/bitcoin-core-dev/2017-July/000042.html
 46 2017-07-06 08:16:58	0|luke-jr|I guess 0.15 will probably miss multiwallet :/
 47 2017-07-06 08:17:15	0|luke-jr|(at least in terms of it being actually usable in the GUI)
 48 2017-07-06 09:29:17	0|wumpus|we should aim for basic RPC multiwallet
 49 2017-07-06 09:29:29	0|wumpus|full GUI multiwallet is not realistic for 0.15
 50 2017-07-06 09:30:39	0|wumpus|darn, forgot to add a tree-sha512 to the last commit on master
 51 2017-07-06 09:35:42	0|wumpus|why don't we have a "skip these commits for treesha512 check" and only "treesha512 root commit"?
 52 2017-07-06 09:39:09	0|wumpus|argh updating the root commit didn't work, it also checks the root
 53 2017-07-06 09:44:19	0|wumpus|BlueMatt: how to fix this?
 54 2017-07-06 09:46:38	0|wumpus|... I guess merging a PR with a treehash, then updating the root commit to that would work
 55 2017-07-06 09:49:12	0|wumpus|another option would be to force-push the last commit with a treehash, but it's been in master too long
 56 2017-07-06 09:49:19	0|wumpus|neither is really nice
 57 2017-07-06 09:51:27	0|luke-jr|take the last one with a treehash, and merge the current master into it?
 58 2017-07-06 09:52:02	0|luke-jr|could force-push the last commit and open a PR with the real master, if that makes it easier
 59 2017-07-06 09:55:18	0|wumpus|that's a smart idea, your first idea is fully fast-forwardable, right?
 60 2017-07-06 10:03:10	0|wumpus|seems to work locally, thanks
 61 2017-07-06 10:04:03	0|wumpus|here goes nothing...
 62 2017-07-06 10:04:12	0|bitcoin-git|13bitcoin/06master 14a5cd829 15Wladimir J. van der Laan: Merge branch qt-translations into master...
 63 2017-07-06 10:04:12	0|bitcoin-git|[13bitcoin] 15laanwj pushed 1 new commit to 06master: 02https://github.com/bitcoin/bitcoin/commit/a5cd829a0b51b69a2e7d5e93f55196f7d67a7462
 64 2017-07-06 10:24:49	0|wumpus|yay Fixed: bitcoin/bitcoin#19612 (master - a5cd829)
 65 2017-07-06 10:24:50	0|gribble|https://github.com/bitcoin/bitcoin/issues/19612 | HTTP Error 404: Not Found
 66 2017-07-06 13:19:25	0|bitcoin-git|[13bitcoin] 15laanwj opened pull request #10753: test: Check RPC argument mapping (06master...062017_07_rpc_argument_check) 02https://github.com/bitcoin/bitcoin/pull/10753
 67 2017-07-06 13:55:45	0|bitcoin-git|13bitcoin/06master 14bd00fa5 15John Newbery: [test] don't run dbcrash.py on Travis
 68 2017-07-06 13:55:45	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/a5cd829a0b51...be824984626f
 69 2017-07-06 13:55:46	0|bitcoin-git|13bitcoin/06master 14be82498 15Wladimir J. van der Laan: Merge #10743: [test] don't run dbcrash.py on Travis...
 70 2017-07-06 13:56:16	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #10743: [test] don't run dbcrash.py on Travis (06master...06dontrundbcrash) 02https://github.com/bitcoin/bitcoin/pull/10743
 71 2017-07-06 15:31:54	0|BlueMatt|wumpus: ugh, please add the pre-push-hook locally
 72 2017-07-06 15:45:19	0|BlueMatt|wumpus: oh, yes, thanks luke-jr, clever solution
 73 2017-07-06 15:45:53	0|morcos|achow101: instagibbs: Murch:  I have a couple questions about branch&bound, effective value and change
 74 2017-07-06 15:46:06	0|Murch|okay
 75 2017-07-06 15:46:37	0|morcos|So I see how we are accounting for output size via output_fee and input_size via nInputBytes
 76 2017-07-06 15:46:47	0|morcos|But how are we accounting for fees paid on the fixed part of a tx
 77 2017-07-06 15:47:02	0|morcos|Won't we necessarily fail if we get too close to an exact match?
 78 2017-07-06 15:47:37	0|morcos|Second question: Why are we using the longest possible estimate for the creation of change?
 79 2017-07-06 15:47:41	0|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.
 80 2017-07-06 15:48:06	0|Murch|We add that and the cost of the transaction overhead to the target
 81 2017-07-06 15:48:23	0|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.
 82 2017-07-06 15:48:52	0|morcos|The transaction overhead piece is the part I was missing
 83 2017-07-06 15:48:55	0|morcos|maybe i just missed it
 84 2017-07-06 15:49:41	0|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.
 85 2017-07-06 15:50:34	0|morcos|ok. yeah thats what i meant
 86 2017-07-06 15:50:44	0|morcos|i'm mostly asking questions about his code
 87 2017-07-06 15:50:55	0|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".
 88 2017-07-06 15:51:19	0|morcos|I mean the cost of change_
 89 2017-07-06 15:51:30	0|morcos|we're calculating it using a smart fee estimate for 1008 blocks
 90 2017-07-06 15:51:45	0|morcos|when in reality it'll cost us whatever fee we're using for this transaction creation
 91 2017-07-06 15:51:55	0|Murch|Well, actually, this is the part that I'm not comfortable with yet.
 92 2017-07-06 15:52:13	0|Murch|Obviously, the only amount that we're clearly saving is the cost of creating a change output.
 93 2017-07-06 15:53:10	0|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.
 94 2017-07-06 15:53:18	0|morcos|ah i see, i'd missed that
 95 2017-07-06 15:53:30	0|morcos|well what i'm saying is something different again
 96 2017-07-06 15:53:45	0|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.
 97 2017-07-06 15:53:54	0|morcos|actually waht we might want is something similar to what i did in #10712
 98 2017-07-06 15:53:56	0|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
 99 2017-07-06 15:54:13	0|morcos|but my point was the change_feerate we are using is possibly too low
100 2017-07-06 15:54:20	0|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.
101 2017-07-06 15:54:24	0|morcos|maybe that is a good feerate to use for assumption of spending the change output in the future
102 2017-07-06 15:54:28	0|Murch|So I would suggest that we go with that first.
103 2017-07-06 15:55:01	0|morcos|might it make sense to cache the best result found so far and keep searching
104 2017-07-06 15:55:31	0|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)
105 2017-07-06 15:56:55	0|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
106 2017-07-06 15:57:25	0|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
107 2017-07-06 15:57:46	0|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.
108 2017-07-06 15:58:06	0|morcos|sorry, what would?
109 2017-07-06 15:58:07	0|Murch|More experiments would inform us, I guess.
110 2017-07-06 15:58:18	0|Murch|finding the "best solution".
111 2017-07-06 15:58:28	0|Murch|Also would probably increase the search times a lot
112 2017-07-06 15:58:44	0|Murch|mh
113 2017-07-06 15:58:53	0|Murch|sorry, I'm too slow
114 2017-07-06 15:58:56	0|morcos|yeah i was a bit concerned about that
115 2017-07-06 15:59:45	0|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.
116 2017-07-06 16:00:11	0|morcos|Yes even plus the dust threshold of the output itself
117 2017-07-06 16:00:14	0|morcos|as done in 10712
118 2017-07-06 16:00:33	0|instagibbs|Murch, im sorry you mean don't consider a future spend of it?
119 2017-07-06 16:00:41	0|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.
120 2017-07-06 16:00:58	0|instagibbs|oh sorry, you mean use same feerate for both output size and future input
121 2017-07-06 16:01:00	0|morcos|I'll defer to your judgement on that
122 2017-07-06 16:01:15	0|morcos|no instagibbs i think he means don't consider future input
123 2017-07-06 16:01:30	0|instagibbs|due to the bitcoinjs experiments?
124 2017-07-06 16:01:33	0|morcos|but i'm suggesting we should consider future input via GetDustThreshold
125 2017-07-06 16:01:38	0|Murch|instagibbs: I'm concerned that we're overestimating the saved cost
126 2017-07-06 16:01:48	0|morcos|In addition to current fee rate times size of creating output
127 2017-07-06 16:01:59	0|instagibbs|Murch, explain?
128 2017-07-06 16:02:12	0|Murch|@instagibbs: Yeah.
129 2017-07-06 16:03:07	0|morcos|I think it's exactly this calculation we should use: https://github.com/bitcoin/bitcoin/pull/10712/files#diff-b2bb174788c7409b671c46ccc86034bdR2762
130 2017-07-06 16:03:10	0|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"
131 2017-07-06 16:04:02	0|Murch|Fixed fee rate is not a valid assumption IRL, so it's hard to estimate the saved cost for the input.
132 2017-07-06 16:04:21	0|Murch|We see frequent changes in fees in a range of factor 50.
133 2017-07-06 16:04:44	0|instagibbs|Yes, but if fees really do move up on longer-term I don't see why we'd ignore it
134 2017-07-06 16:05:06	0|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.
135 2017-07-06 16:05:10	0|instagibbs|more aggressive non-change making has privacy advantages on top that I don't think we should ignore
136 2017-07-06 16:05:49	0|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
137 2017-07-06 16:05:49	0|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.
138 2017-07-06 16:06:26	0|Murch|instagibbs: Smaller window might cause larger input sets, so it might actually work towards that end. It's hard to tell. ;)
139 2017-07-06 16:06:27	0|instagibbs|Murch, what about how many change outputs are made vs
140 2017-07-06 16:06:30	0|morcos|and potentially trying again
141 2017-07-06 16:06:33	0|instagibbs|and how much are you saving
142 2017-07-06 16:07:47	0|instagibbs|not asking for an answer right here, just think it's important to consider
143 2017-07-06 16:07:56	0|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.
144 2017-07-06 16:08:15	0|Murch|instagibbs AFAIU, it didn't though.
145 2017-07-06 16:08:20	0|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
146 2017-07-06 16:08:48	0|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.
147 2017-07-06 16:08:49	0|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
148 2017-07-06 16:09:01	0|morcos|Do we have any good data sets for a large number of users to evaluate this on at all
149 2017-07-06 16:09:10	0|Murch|morcos "…wasting money…" exactly.
150 2017-07-06 16:09:13	0|instagibbs|not public ones
151 2017-07-06 16:09:14	0|instagibbs|:P
152 2017-07-06 16:09:31	0|Murch|instagibbs: yep.
153 2017-07-06 16:10:32	0|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.
154 2017-07-06 16:10:39	0|Murch|Can't share the data of course. ;)
155 2017-07-06 16:13:46	0|morcos|Does the KnapsackSolver still try to find an exact match if BnB fails?
156 2017-07-06 16:13:50	0|morcos|Is that worth doing still?
157 2017-07-06 16:14:08	0|instagibbs|likely not worth it
158 2017-07-06 16:14:09	0|morcos|I'm just trying to figure out whether we cna assume we'll probably have change if BnB fails
159 2017-07-06 16:14:22	0|instagibbs|I think we should toss all of that and assume we get change
160 2017-07-06 16:14:52	0|instagibbs|we can definitely get data for that once we have BnB being used...
161 2017-07-06 16:14:54	0|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
162 2017-07-06 16:15:19	0|morcos|Whether we want to do that on a first pass or maybe do two passes or something, I don't know...
163 2017-07-06 16:15:54	0|instagibbs|"use" in what sense, sorry
164 2017-07-06 16:16:10	0|morcos|for the cost_of_change
165 2017-07-06 16:16:19	0|instagibbs|k
166 2017-07-06 16:16:48	0|instagibbs|remind me what the second term is accomplishing?
167 2017-07-06 16:17:06	0|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
168 2017-07-06 16:17:14	0|instagibbs|just a small window on top?
169 2017-07-06 16:17:33	0|morcos|You can't create a change output smaller than DustThreshold anyway
170 2017-07-06 16:18:04	0|instagibbs|I just need to read the branch again, ignore my q
171 2017-07-06 16:18:18	0|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
172 2017-07-06 16:18:35	0|instagibbs|yep
173 2017-07-06 16:19:00	0|bitcoin-git|13bitcoin/06master 14b8bb425 15Michael Rotarius: REST/RPC example update
174 2017-07-06 16:19:00	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/be824984626f...30bc0f672626
175 2017-07-06 16:19:01	0|bitcoin-git|13bitcoin/06master 1430bc0f6 15Wladimir J. van der Laan: Merge #10710: REST/RPC example update...
176 2017-07-06 16:19:33	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #10710: REST/RPC example update (06master...06docupt) 02https://github.com/bitcoin/bitcoin/pull/10710
177 2017-07-06 16:19:34	0|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)
178 2017-07-06 16:20:16	0|morcos|That doesn't seem to me necessarily what the user wants?  But I don't know what the right order is.
179 2017-07-06 16:20:41	0|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
180 2017-07-06 16:21:02	0|instagibbs|that block of SCMC could have a comment header explaining the steps
181 2017-07-06 16:29:38	0|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.
182 2017-07-06 16:32:54	0|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.
183 2017-07-06 16:57:34	0|bitcoin-git|[13bitcoin] 15laanwj pushed 37 new commits to 060.14: 02https://github.com/bitcoin/bitcoin/compare/fc61c8322bd7...91be5e3c1e45
184 2017-07-06 16:57:35	0|bitcoin-git|13bitcoin/060.14 1471463a7 15Suhas Daftuar: [qa] Test prioritise_transaction / getblocktemplate interaction...
185 2017-07-06 16:57:35	0|bitcoin-git|13bitcoin/060.14 14d28d583 15Suhas Daftuar: Bugfix: PrioritiseTransaction updates the mempool tx counter...
186 2017-07-06 16:57:36	0|bitcoin-git|13bitcoin/060.14 14ef810c4 15practicalswift: [trivial] Fix a typo (introduced two days ago) in the default fee warning...
187 2017-07-06 17:02:50	0|spudowiar|To confirm, UniValues can only be appended to, not modified, right?
188 2017-07-06 17:17:29	0|instagibbs|seems that way
189 2017-07-06 17:18:54	0|spudowiar|Copying the object to modify it seems wrong
190 2017-07-06 17:19:42	0|spudowiar|I might copy the function from core_write to CWallet and modify it for my usecase
191 2017-07-06 17:20:13	0|spudowiar|There are quite a few neat changes I could make then
192 2017-07-06 17:31:35	0|wumpus|correct - you shouldn't need to edit univalue object, either consume them or generate them
193 2017-07-06 17:32:06	0|wumpus|they're meant for being used on the interface, not meant as a lasting data representation format
194 2017-07-06 17:38:16	0|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.
195 2017-07-06 17:40:26	0|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.
196 2017-07-06 17:40:58	0|morcos|but for instance we might prefer to create no-change from 1-confirm inputs before creating change from 6-confirm inputs
197 2017-07-06 17:41:06	0|instagibbs|Indeed that would be better, but I'd still like to revisit BnB if we cant do knapsack w/ confirmed
198 2017-07-06 17:42:28	0|instagibbs|Throw-away idea: Let the transaction construction loop happen once, never accept the first result, then you can compare the two,
199 2017-07-06 17:43:02	0|instagibbs|the first will always fail anyways
200 2017-07-06 17:44:17	0|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?
201 2017-07-06 17:45:14	0|sipa|not a constant?
202 2017-07-06 17:45:55	0|morcos|well its a command line argument
203 2017-07-06 17:46:20	0|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
204 2017-07-06 17:46:53	0|wumpus|it's an interesting case
205 2017-07-06 17:47:14	0|morcos|ok, i'm happy to do that.  just global but declared in wallet.h ?
206 2017-07-06 17:47:25	0|sipa|sounds good to me
207 2017-07-06 17:47:31	0|wumpus|not convinced a global is better
208 2017-07-06 17:47:39	0|sipa|static class members effectively are globals
209 2017-07-06 17:47:48	0|sipa|they're just abusing the class as a namespace
210 2017-07-06 17:47:50	0|wumpus|at least the class provides some kind of scoping
211 2017-07-06 17:47:58	0|morcos|thats why my guess was CWallet::g_discard_rate
212 2017-07-06 17:47:59	0|wumpus|well it's better than throwing everything into the global namespace
213 2017-07-06 17:48:20	0|sipa|i guess the right approach is to actually have good namespacing
214 2017-07-06 17:48:30	0|wumpus|sure
215 2017-07-06 17:48:57	0|wumpus|but now it could collide with something e.g. outside of wallet, it's not clear it's for the wallet
216 2017-07-06 17:49:07	0|wumpus|m_fallback_fee could be anything, also a mempool thing
217 2017-07-06 17:49:21	0|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)
218 2017-07-06 17:50:07	0|morcos|so what am i doing then?
219 2017-07-06 17:50:42	0|morcos|the existing similar variables are static class members for now
220 2017-07-06 17:50:49	0|sipa|if it's a static member variable, call it CWallet::m_fallback_fee
221 2017-07-06 17:51:08	0|wumpus|better to keep it consistent and make this one too, morcos, I'd say
222 2017-07-06 17:51:13	0|wumpus|and yes call it m_fallback_fee
223 2017-07-06 17:51:14	0|morcos|ok, i'll do that for now..  if we want to , we can clean up all of them later
224 2017-07-06 17:51:18	0|sipa|ack
225 2017-07-06 17:51:42	0|morcos|btw, i think it would be nice to have helper functions for all these command line arguments
226 2017-07-06 17:51:52	0|sipa|yes...
227 2017-07-06 17:52:12	0|morcos|so we could sort of declare the argument, its help string, its min and max value, etc.. all in one place
228 2017-07-06 17:52:28	0|wumpus|we have a PR that improves argument handling IIRC
229 2017-07-06 17:52:40	0|wumpus|would be nice post-0.15
230 2017-07-06 17:57:42	0|wumpus|would be nice to finally be able to close #1044
231 2017-07-06 17:57:43	0|gribble|https://github.com/bitcoin/bitcoin/issues/1044 | Problems with command-line options silently ignored · Issue #1044 · bitcoin/bitcoin · GitHub
232 2017-07-06 17:57:58	0|sipa|yes...
233 2017-07-06 17:58:02	0|wumpus|which should be easy if all command line arguments are registered
234 2017-07-06 17:58:17	0|spudowiar|Yea or nay: Adding a const CWallet& parameter to TxToUniv which adds hdKeypath to your own inputs and the change outputs?
235 2017-07-06 17:58:31	0|spudowiar|Or should I create a new version of TxToUniv?
236 2017-07-06 18:00:43	0|instagibbs|I don't think that function has any knowledge of wallet
237 2017-07-06 18:01:58	0|wumpus|yes it is not a wallet function, core_io etc has no wallet dependency
238 2017-07-06 18:02:19	0|wumpus|if you need one for the wallet, define your own
239 2017-07-06 18:02:31	0|spudowiar|instagibbs: Hence adding the const CWallet& parameter :)
240 2017-07-06 18:02:49	0|sipa|spudowiar: that would make the function dependent on the wallet, which we want to avoid
241 2017-07-06 18:02:51	0|instagibbs|I more mean it's a layer violation
242 2017-07-06 18:02:59	0|spudowiar|sipa: Only if you provide the wallet parameter
243 2017-07-06 18:03:08	0|wumpus|one that takes a CWalletTx, defined in the wallet library
244 2017-07-06 18:03:17	0|morcos|gmaxwell: This is the discard_rate idea: https://github.com/morcos/bitcoin/commit/fd8104a9f074ca588d44defe015b0ace77dbc7fc
245 2017-07-06 18:03:17	0|sipa|spudowiar: you don't understanf
246 2017-07-06 18:03:21	0|wumpus|spudowiar: no, he means a compile-time dependency
247 2017-07-06 18:03:28	0|spudowiar|Oh, gotcha, sorry :)
248 2017-07-06 18:03:30	0|spudowiar|I just realised :)
249 2017-07-06 18:03:33	0|wumpus|spudowiar: core_io etc do not include wallet.h at all ,they don't link against the wallet stuff
250 2017-07-06 18:03:40	0|spudowiar|I didn't realise it was in bitcoin-common
251 2017-07-06 18:03:42	0|sipa|spudowiar: if the function takes a wallet argument, it becomes code that cannot exist without the wallet code being present too
252 2017-07-06 18:03:58	0|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)
253 2017-07-06 18:04:09	0|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
254 2017-07-06 18:04:48	0|wumpus|anyhow, functionality that should be present when buildilng without the wallet relies on TxToUniv
255 2017-07-06 18:04:57	0|gmaxwell|morcos: I like.
256 2017-07-06 18:05:17	0|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.
257 2017-07-06 18:06:11	0|achow101|discard rate?
258 2017-07-06 18:06:19	0|achow101|(sorry, I've missed most of the conversation here)
259 2017-07-06 18:06:21	0|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
260 2017-07-06 18:06:22	0|morcos|See link 10 lines up
261 2017-07-06 18:06:23	0|gribble|https://github.com/bitcoin/bitcoin/issues/10508 | Run Qt wallet tests on travis by ryanofsky · Pull Request #10508 · bitcoin/bitcoin · GitHub
262 2017-07-06 18:06:51	0|achow101|ah, ok
263 2017-07-06 18:07:23	0|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.
264 2017-07-06 18:09:36	0|instagibbs|morcos, TLDR: max(min(1008 smart unconservative smart fee, static_discard_rate)), dustRelayFee)
265 2017-07-06 18:10:15	0|morcos|instagibbs: yes. GetDustThreshold(^ that)
266 2017-07-06 18:12:18	0|instagibbs|seems reasonable, user can always protect super-dustRelayFee change if they decide to
267 2017-07-06 18:17:52	0|Murch|morcos: That would be a good price estimate for the input cost of the saved change output.
268 2017-07-06 18:19:49	0|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
269 2017-07-06 18:19:50	0|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
270 2017-07-06 18:21:19	0|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.
271 2017-07-06 18:25:30	0|kanzure|is the sentiment that the 1008 block estimatesmartfee for change output size minimum threshold is a bad thing due to utxo bloat ?
272 2017-07-06 18:25:58	0|instagibbs|kanzure, right now the wallet is just really bad at targeting good change size outputs or exact matches
273 2017-07-06 18:26:02	0|instagibbs|so it kind of lands in the middle
274 2017-07-06 18:27:09	0|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.
275 2017-07-06 18:27:39	0|instagibbs|right, that's the above idea
276 2017-07-06 18:27:48	0|instagibbs|discardRate, where it's ok to drop it
277 2017-07-06 18:28:38	0|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>
278 2017-07-06 18:30:08	0|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:
279 2017-07-06 18:30:21	0|Murch|1) Try to create no change output (use BnB)
280 2017-07-06 18:30:47	0|Murch|2) If fail: Try to create change output greater than min_change
281 2017-07-06 18:31:26	0|Murch|3) small number of cases that don't fit in any other bucket: If change output is too small to keep discard.
282 2017-07-06 18:31:47	0|Murch|[…], discard.
283 2017-07-06 18:32:03	0|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.
284 2017-07-06 18:32:26	0|Murch|what do you mean with "effective_value"?
285 2017-07-06 18:32:35	0|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...
286 2017-07-06 18:32:41	0|kanzure|...nk that's worth the face value of the output.
287 2017-07-06 18:32:59	0|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
288 2017-07-06 18:33:30	0|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.
289 2017-07-06 18:33:56	0|Murch|BnB + Core as a fallback should be even smaller.
290 2017-07-06 18:34:28	0|gmaxwell|I don't think there is any bloat concern on BNB. Thats part of why we're doing it first.
291 2017-07-06 18:34:43	0|morcos|The big question is how often does BnB find an answer
292 2017-07-06 18:34:49	0|morcos|I have no insight into that
293 2017-07-06 18:34:56	0|instagibbs|Murch, could you just do dumb fallback
294 2017-07-06 18:35:02	0|instagibbs|I think you did right?
295 2017-07-06 18:35:38	0|Murch|morcos: In my simulation with 12k outgoing payments, I found ~39% exact matches with BnB and ~0.6% with Core.
296 2017-07-06 18:35:43	0|morcos|If murch's simulation is on a larger than typical spendable utxo set then it may overestimate the benfit we gain from BnB
297 2017-07-06 18:35:56	0|Murch|morcos: Saying we have no idea, seems a bit of a stretch.
298 2017-07-06 18:35:58	0|morcos|12k outgoing payments from what utxo set per payment?
299 2017-07-06 18:36:13	0|morcos|is each one from the actual utxo set that that payment was made from?
300 2017-07-06 18:36:29	0|morcos|is that one big utxo set
301 2017-07-06 18:36:53	0|morcos|sure, i think BnB will make a huge difference for commercial applications with large utxo sets
302 2017-07-06 18:36:55	0|Murch|morcos: It's a sequence of 36k payments in total, 12k outgoing, 24k incoming.
303 2017-07-06 18:37:05	0|gmaxwell|morcos: he has a feed of input and output payment amounts simulate the wallet (e.g. how it's utxos evolve over time)
304 2017-07-06 18:37:05	0|morcos|but all to the same utxo set?
305 2017-07-06 18:37:10	0|Murch|yes
306 2017-07-06 18:37:14	0|gmaxwell|its*
307 2017-07-06 18:37:18	0|morcos|so thats far from typical
308 2017-07-06 18:37:37	0|sipa|morcos: but perhaps very significant on the overall utxo set
309 2017-07-06 18:37:39	0|achow101|isn't that dataset from moneypot's payments?
310 2017-07-06 18:37:51	0|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.
311 2017-07-06 18:37:54	0|sipa|morcos: as in, perhaps a large portion of the actual network comes from large player's wallets
312 2017-07-06 18:37:57	0|morcos|sipa: unknown.  what % of utxos belong to a big wallet vs small
313 2017-07-06 18:38:05	0|sipa|morcos: yes, i don't know either
314 2017-07-06 18:38:06	0|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
315 2017-07-06 18:38:25	0|Murch|achow101: Yes, the same
316 2017-07-06 18:38:28	0|morcos|gmaxwell: don't get me wrong.  i'm very in favor of doing BnB. its certainly not hurting small wallets
317 2017-07-06 18:38:43	0|bitcoin-git|[13bitcoin] 15laanwj pushed 4 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/30bc0f672626...5af657253498
318 2017-07-06 18:38:43	0|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.
319 2017-07-06 18:38:44	0|bitcoin-git|13bitcoin/06master 14928c681 15Matt Corallo: Use "replaceable" instead of "optintorbf" in createrawtransaction....
320 2017-07-06 18:38:44	0|bitcoin-git|13bitcoin/06master 14fb915d5 15Matt Corallo: Use "replaceable" instead of "optIntoRbf" in fundrawtransaction....
321 2017-07-06 18:38:45	0|bitcoin-git|13bitcoin/06master 1473c942e 15Matt Corallo: Use "replaceable" instead of "rbfoptin" in bitcoin-tx....
322 2017-07-06 18:38:50	0|gmaxwell|morcos: okay good!
323 2017-07-06 18:38:58	0|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
324 2017-07-06 18:39:11	0|sipa|morcos: agree - we don't know the impact
325 2017-07-06 18:39:12	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #10698: Be consistent in calling transactions "replaceable" for Opt-In RBF (06master...062017-06-replaceable-rpc-args) 02https://github.com/bitcoin/bitcoin/pull/10698
326 2017-07-06 18:39:18	0|Murch|morcos: Coin selection in a wallet that has significantly more outgoing payments than incoming (i.e. most end-user cases) is trivial.
327 2017-07-06 18:39:20	0|morcos|so we still have to be worried about utxo bloat in the event BnB fails
328 2017-07-06 18:39:23	0|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.
329 2017-07-06 18:39:26	0|morcos|This is what i'm talking about
330 2017-07-06 18:39:27	0|instagibbs|eh, economic node activity likely follows a power law
331 2017-07-06 18:39:38	0|gmaxwell|Just that it will do no harm and at least in some cases help a lot.
332 2017-07-06 18:39:40	0|instagibbs|maybe wont matter for small wallets you're right
333 2017-07-06 18:39:40	0|Murch|morcos: Coin selection in a wallet that has more incoming payments than outgoing should do very well with BnB.
334 2017-07-06 18:39:59	0|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
335 2017-07-06 18:40:07	0|morcos|Murch thought i was over worrying about bloat
336 2017-07-06 18:40:45	0|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.
337 2017-07-06 18:40:49	0|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.
338 2017-07-06 18:41:46	0|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.
339 2017-07-06 18:42:26	0|gmaxwell|morcos: okay so BnB is basically unrelated.
340 2017-07-06 18:42:28	0|instagibbs|I think we're agreeing here. For fallback we should pick something significantly higher if possible
341 2017-07-06 18:42:31	0|morcos|gmaxwell: yes
342 2017-07-06 18:43:06	0|Murch|Yeayeah
343 2017-07-06 18:43:36	0|morcos|while we're on the subject
344 2017-07-06 18:44:09	0|morcos|gmaxwell and everyone did you see my above question about how (bnb, knapsack) should be intermingled with (selectcoinsminconf (different params))
345 2017-07-06 18:44:32	0|morcos|at what point do you prefer no change but less confirmations or longer unconfirmed chain
346 2017-07-06 18:45:01	0|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.
347 2017-07-06 18:45:23	0|gmaxwell|But I think we should BNB longish chains for example.
348 2017-07-06 18:45:37	0|gmaxwell|because that ends them.
349 2017-07-06 18:45:53	0|gmaxwell|but obviously not overlong (24+) ones.
350 2017-07-06 18:45:56	0|morcos|but not before creating a tx which doesn't spend unconfirmed ?
351 2017-07-06 18:46:29	0|gmaxwell|OH on this subject. We need to consider the feerate of unconfirmed parents as part of their effective rate.
352 2017-07-06 18:46:32	0|gmaxwell|And CPFP them.
353 2017-07-06 18:46:33	0|morcos|actually, maybe it wouldn't be that hard to be kind of smart about it.
354 2017-07-06 18:47:01	0|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
355 2017-07-06 18:47:03	0|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.
356 2017-07-06 18:47:13	0|gmaxwell|Indeed.
357 2017-07-06 18:47:46	0|gmaxwell|I've seen some users screwed with this FWIW.
358 2017-07-06 18:47:46	0|morcos|i don't think you'd necessarily want to automatically CPFP a chain if you had other options
359 2017-07-06 18:48:06	0|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.
360 2017-07-06 18:48:20	0|instagibbs|you'd need to avoid bumping twice, by detecting if they are cousins in a chain
361 2017-07-06 18:48:33	0|gmaxwell|I think you might want to automatically CPFP any input that you set the same confirmed target or lower on.
362 2017-07-06 18:49:11	0|gmaxwell|instagibbs: well they won't be unless we're making multiple change outputs or paying ourselves.... but yes...
363 2017-07-06 18:49:39	0|gmaxwell|this suggests that perhaps we should be tracking what the fee settings were for those transactions.
364 2017-07-06 18:49:44	0|morcos|goodness, this is going to get complicated.
365 2017-07-06 18:49:50	0|gmaxwell|Hurray!
366 2017-07-06 18:50:02	0|gmaxwell|(this means we're starting to understand all that we don't know about the problem space)
367 2017-07-06 18:50:11	0|instagibbs|next we need to throw a general purpose optimizer at it
368 2017-07-06 18:50:28	0|rhavar|pretty sure that's the only sane solution if you want to automatically do CPFP and stuff
369 2017-07-06 18:50:35	0|gmaxwell|nah.
370 2017-07-06 18:50:57	0|gmaxwell|Other than having a bunch of conditionals I think this stuff isn't *that* gnarly.
371 2017-07-06 18:51:03	0|instagibbs|didn't close my statement with /s
372 2017-07-06 18:51:50	0|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.
373 2017-07-06 18:52:00	0|gmaxwell|and use the CPFP impact in the EV calculations.
374 2017-07-06 18:52:30	0|rhavar|I'm not sure it's a horrible idea to just write the whole thing up as a general purpose constrain solving problem
375 2017-07-06 18:52:40	0|rhavar|and just not include a constrain solver :P
376 2017-07-06 18:52:43	0|rhavar|have it as a plugin or something
377 2017-07-06 18:53:06	0|gmaxwell|rhavar: I've done this previously, but the actual solving isn't really that big a deal.
378 2017-07-06 18:53:11	0|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
379 2017-07-06 18:53:37	0|rhavar|And for commercial users, they can actually install some shared object plugin that calls out to a proper library
380 2017-07-06 18:54:03	0|gmaxwell|it's not magic in any case.
381 2017-07-06 18:54:36	0|rhavar|That's what I'm doing right at this moment, I pretty much brute force solutions with a cost metric
382 2017-07-06 18:54:43	0|gmaxwell|I think there is a AMSL statement of a toy coinselection problem that I wrote floating around out there somewhere.
383 2017-07-06 18:54:44	0|rhavar|and it does a *decent* job
384 2017-07-06 18:55:21	0|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) :)
385 2017-07-06 18:55:21	0|rhavar|I'll have a robust minizinc implementation pretty soon, if anyones interested
386 2017-07-06 18:56:25	0|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.
387 2017-07-06 18:56:34	0|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
388 2017-07-06 18:57:09	0|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. :)
389 2017-07-06 18:57:26	0|gmaxwell|but no issue supporting loadable things for people who want them.
390 2017-07-06 18:57:26	0|morcos|also the magic is in the metric isn't it
391 2017-07-06 18:57:56	0|rhavar|This is the cost function I use: https://gist.github.com/RHavar/0710144c713033d42f8f443a99fefbb7
392 2017-07-06 18:58:03	0|rhavar|I think it makes perfect sense for casual users too
393 2017-07-06 18:58:18	0|rhavar|Just instead of using a proper constrain solver, they can use a brute forcer
394 2017-07-06 18:58:26	0|rhavar|which is pretty trivial to write
395 2017-07-06 18:58:30	0|jtimon|meeting?
396 2017-07-06 18:58:42	0|sipa|soon!
397 2017-07-06 18:59:19	0|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.
398 2017-07-06 18:59:31	0|gmaxwell|(and my wallets have a lot more than two dozen inputs, and I'm just some guy)
399 2017-07-06 19:00:05	0|rhavar|I'm using a brute force search with ~2k inputs right now, and it does a *decent* job
400 2017-07-06 19:00:18	0|rhavar|not perfect though, that's why I'm paying for the minizinc impl
401 2017-07-06 19:00:38	0|rhavar|(I obviously don't search the entire space, I time out after 10 minutes)
402 2017-07-06 19:00:45	0|lightningbot|Meeting started Thu Jul  6 19:00:44 2017 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
403 2017-07-06 19:00:45	0|lightningbot|Useful Commands: #action #agreed #help #info #idea #link #topic.
404 2017-07-06 19:00:45	0|wumpus|#startmeeting
405 2017-07-06 19:00:52	0|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
406 2017-07-06 19:00:57	0|jonasschnelli|proposed topic: multiwallet endpoint vs json item
407 2017-07-06 19:00:57	0|sipa|LO
408 2017-07-06 19:00:57	0|wumpus|topics?
409 2017-07-06 19:01:01	0|achow101|hi
410 2017-07-06 19:01:05	0|cfields|hi
411 2017-07-06 19:01:10	0|kanzure|hi.
412 2017-07-06 19:01:16	0|wumpus|jonasschnelli: yeah, apparently we have to discuss that again, with all the competing PRs
413 2017-07-06 19:01:23	0|jonasschnelli|heh. Yes
414 2017-07-06 19:01:30	0|wumpus|jonasschnelli: though in principle we settled on endpoint a few weeks ago
415 2017-07-06 19:01:32	0|morcos|begging for review... lots of fee/wallet/estimate stuff that needs to make 0.15
416 2017-07-06 19:01:42	0|morcos|i already have 3 on high priority... sheepish grin
417 2017-07-06 19:01:54	0|wumpus|yes, high priority for review will as usual be first topic
418 2017-07-06 19:01:55	0|gmaxwell|morcos: We should do the things.
419 2017-07-06 19:01:56	0|jonasschnelli|We set endpoints, but some where also in favor of the JSON item solution
420 2017-07-06 19:02:02	0|wumpus|#topic high priority for review
421 2017-07-06 19:02:04	0|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
422 2017-07-06 19:02:17	0|wumpus|https://github.com/bitcoin/bitcoin/projects/8
423 2017-07-06 19:02:30	0|gmaxwell|by swap txindex he means turn it on/off on an already running node.
424 2017-07-06 19:02:45	0|jonasschnelli|I'll remove my #10240 from the list for now
425 2017-07-06 19:02:47	0|instagibbs|good to know...
426 2017-07-06 19:02:48	0|wumpus|without a reindex-chainstate I guess
427 2017-07-06 19:02:49	0|sipa|gmaxwell: you mean already created db?
428 2017-07-06 19:02:50	0|gribble|https://github.com/bitcoin/bitcoin/issues/10240 | Add HD wallet auto-restore functionality by jonasschnelli · Pull Request #10240 · bitcoin/bitcoin · GitHub
429 2017-07-06 19:03:02	0|wumpus|jonasschnelli: ok
430 2017-07-06 19:03:23	0|jonasschnelli|It's to big and will re-focus during early 0.16
431 2017-07-06 19:03:28	0|jtimon|maybe put #8498 in project 8 ?
432 2017-07-06 19:03:30	0|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
433 2017-07-06 19:03:34	0|luke-jr|wumpus: the arguments for endpoint seem strong IMO
434 2017-07-06 19:03:39	0|instagibbs|morcos, doesn;t help that they're an unconfirmed chain of PRs :)
435 2017-07-06 19:04:07	0|morcos|instagibbs: i know! :)  high priority review ones arent though
436 2017-07-06 19:04:08	0|luke-jr|guess we're not on that topic yet
437 2017-07-06 19:04:08	0|sipa|we need a chain length limit on PRs
438 2017-07-06 19:04:11	0|wumpus|jtimon: is that high priority to get into 0.15?
439 2017-07-06 19:04:18	0|wumpus|luke-jr: next topic
440 2017-07-06 19:04:26	0|BlueMatt|wumpus: I think 10179 is ready(ish) for a merge, which makes my high-prio of 10652 cleaner
441 2017-07-06 19:04:50	0|jtimon|wumpus: I haven't benchmarked, but it's an optimization and now also a "near bugfix"
442 2017-07-06 19:04:57	0|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
443 2017-07-06 19:05:52	0|wumpus|BlueMatt: agree
444 2017-07-06 19:06:17	0|sipa|#10179
445 2017-07-06 19:06:20	0|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
446 2017-07-06 19:07:13	0|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!
447 2017-07-06 19:07:28	0|morcos|or if you want to be sure to understand the new code!
448 2017-07-06 19:07:33	0|BlueMatt|well, that too
449 2017-07-06 19:07:45	0|Murch|Or if you want to understand the code in the first place! :)
450 2017-07-06 19:08:22	0|wumpus|:)
451 2017-07-06 19:08:52	0|wumpus|ok, so anything that needs to be added to project 8?
452 2017-07-06 19:09:16	0|morcos|i have other things needed for 0.15, but they are dependent on the ones i already have in 8
453 2017-07-06 19:09:29	0|morcos|also i already have 3
454 2017-07-06 19:09:29	0|wumpus|ok, just tag them for 0.15 then, don't need to be in that project
455 2017-07-06 19:09:37	0|jtimon|wumpus: doesn't that qualify for priority?
456 2017-07-06 19:09:37	0|wumpus|#topic RPC interface for multiwallet (again)
457 2017-07-06 19:09:56	0|instagibbs|can someone give an overview of what people are thinking on interface for multiwallet... i missed this
458 2017-07-06 19:09:57	0|jonasschnelli|Again we should decide wether we use Endpoints of JSON objects for multiwallet switch... helps to continue on PRs
459 2017-07-06 19:09:57	0|wumpus|jtimon: if the gain is unclear, I don't think so
460 2017-07-06 19:10:05	0|wumpus|instagibbs: please read the current PRs:
461 2017-07-06 19:10:08	0|sipa|wumpus: can we have #10571 #10579 in 0.15?
462 2017-07-06 19:10:09	0|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
463 2017-07-06 19:10:11	0|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
464 2017-07-06 19:10:11	0|jonasschnelli|The JSON object is simpler... less impect
465 2017-07-06 19:10:11	0|jtimon|wumpus: I think it's clearly a gain
466 2017-07-06 19:10:37	0|jonasschnelli|the endpoint approach may allow more in future...
467 2017-07-06 19:11:03	0|jtimon|I don't understand the criterion then
468 2017-07-06 19:11:16	0|wumpus|#10650 #10653
469 2017-07-06 19:11:17	0|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.
470 2017-07-06 19:11:18	0|gribble|https://github.com/bitcoin/bitcoin/issues/10650 | Multiwallet: add RPC endpoint support by jonasschnelli · Pull Request #10650 · bitcoin/bitcoin · GitHub
471 2017-07-06 19:11:19	0|gribble|https://github.com/bitcoin/bitcoin/issues/10653 | Simple, backwards compatible RPC multiwallet support by ryanofsky · Pull Request #10653 · bitcoin/bitcoin · GitHub
472 2017-07-06 19:11:27	0|luke-jr|I like the JSON interface, but I worry that when we split out the wallet it will break
473 2017-07-06 19:11:29	0|instagibbs|wumpus, add those to multiwallet project?
474 2017-07-06 19:11:35	0|wumpus|#10650
475 2017-07-06 19:11:37	0|gribble|https://github.com/bitcoin/bitcoin/issues/10650 | Multiwallet: add RPC endpoint support by jonasschnelli · Pull Request #10650 · bitcoin/bitcoin · GitHub
476 2017-07-06 19:11:37	0|jonasschnelli|It also only works with the new named based argumenst
477 2017-07-06 19:11:41	0|wumpus|eh what's the third one?
478 2017-07-06 19:12:01	0|luke-jr|endpoints seemed okay, until the API bump got tacked on..
479 2017-07-06 19:12:02	0|jonasschnelli|I guess the third one (based on Auth) has already been "rejected"? right?
480 2017-07-06 19:12:09	0|wumpus|I don't like the JSON based interface, having to add an optional wallet argument on every wallet call is easy to forget
481 2017-07-06 19:12:14	0|ryanofsky|#10661 works with positional arguments, not just named arguments
482 2017-07-06 19:12:16	0|gribble|https://github.com/bitcoin/bitcoin/issues/10661 | Add optional wallet=filename arguments to wallet RPCs by ryanofsky · Pull Request #10661 · bitcoin/bitcoin · GitHub
483 2017-07-06 19:12:22	0|wumpus|and if you forget it it defaults to the 'default wallet'
484 2017-07-06 19:12:26	0|wumpus|that's just too easy to mess up
485 2017-07-06 19:12:39	0|jonasschnelli|ryanofsky: thanks for clearing this up... wasn't aware, sry
486 2017-07-06 19:12:41	0|wumpus|the endpoint makes sure you can be connected to only one wallet with one RPC connection
487 2017-07-06 19:12:49	0|wumpus|jonasschnelli: right!
488 2017-07-06 19:12:55	0|ryanofsky|i think we should just get rid of the concept of default wallet
489 2017-07-06 19:13:05	0|wumpus|ryanofsky: on the long run, yes, but that's no option for 0.15
490 2017-07-06 19:13:06	0|luke-jr|ryanofsky: definitely not in 0.15
491 2017-07-06 19:13:13	0|kanzure|what about, if more than one wallet, then default wallet must be explicitly specified
492 2017-07-06 19:13:17	0|ryanofsky|if there's more than one wallet, it should just be an error not to specify a wallet
493 2017-07-06 19:13:20	0|wumpus|let's focus on what we want to do now
494 2017-07-06 19:13:31	0|luke-jr|then you break all existing sw
495 2017-07-06 19:13:32	0|wumpus|I think for 0.15 we should simply do the endpoint-based interface
496 2017-07-06 19:13:35	0|ryanofsky|we can do that right now
497 2017-07-06 19:13:37	0|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?
498 2017-07-06 19:13:38	0|ryanofsky|no need to wait
499 2017-07-06 19:13:53	0|sipa|i think as an end goal, endpoint-based selection is awesome, because it prepares for process separation
500 2017-07-06 19:13:53	0|wumpus|gmaxwell: the same is true for any RPC change
501 2017-07-06 19:13:57	0|jonasschnelli|gmaxwell: we can mark it unstable?
502 2017-07-06 19:14:00	0|jonasschnelli|v1 == unstable?
503 2017-07-06 19:14:09	0|jonasschnelli|use / (v0) if you want stability
504 2017-07-06 19:14:16	0|sipa|but if endpoints can't for example remove the non-wallet RPCs, that's sort of not really achieving that goal anyway
505 2017-07-06 19:14:18	0|wumpus|gmaxwell: adding an argument to every wallet RPC call is also such a massive change
506 2017-07-06 19:14:30	0|sipa|wumpus: with named args it's trivial, no?
507 2017-07-06 19:14:42	0|jonasschnelli|I can work on splitting the RPC calls in wallet / nonwallet
508 2017-07-06 19:14:48	0|gmaxwell|(I don't have strong opinions, just raising it)
509 2017-07-06 19:14:49	0|jonasschnelli|if we agree on endpoints
510 2017-07-06 19:14:52	0|ryanofsky|wumpus, are you saying 10661 is a massive change?
511 2017-07-06 19:14:52	0|sipa|and it shouldn't be adding it to every RPC; just catch it in the rpc handler
512 2017-07-06 19:14:55	0|wumpus|but the point is that it'd be something that has to be supported virtually forever
513 2017-07-06 19:14:59	0|luke-jr|(only supporting the default wallet, per rpcauth user, seems the best for backward/forward compatibility still)
514 2017-07-06 19:15:00	0|wumpus|and imo it's poorly thought out
515 2017-07-06 19:15:16	0|wumpus|but I don't care deeply
516 2017-07-06 19:15:21	0|wumpus|at this point we should simply make a choice
517 2017-07-06 19:15:26	0|gmaxwell|I don't really think named arguments is a great thing. It would make support easier in some software in the short term.
518 2017-07-06 19:15:26	0|wumpus|if we don't make a choice today and stick with it
519 2017-07-06 19:15:31	0|wumpus|we can forget multiwallet for 0.15
520 2017-07-06 19:15:37	0|gmaxwell|I think every criticism wumpus has on that one is spot on.
521 2017-07-06 19:15:37	0|jonasschnelli|ack!
522 2017-07-06 19:16:19	0|wumpus|gmaxwell: indeed - most RPC client libraries don't even support named arguments yet
523 2017-07-06 19:16:23	0|luke-jr|that gives more time to think out API change
524 2017-07-06 19:16:26	0|wumpus|gmaxwell: while changing the endpoint is easy, just change the URI
525 2017-07-06 19:16:49	0|wumpus|luke-jr: please don't bring back a third option
526 2017-07-06 19:16:54	0|BlueMatt|but, ok
527 2017-07-06 19:16:54	0|wumpus|luke-jr: that's not going to make it easier
528 2017-07-06 19:17:00	0|kanzure|luke-jr: are wallets assigned per rpcauth user already?
529 2017-07-06 19:17:08	0|jonasschnelli|no
530 2017-07-06 19:17:11	0|wumpus|no
531 2017-07-06 19:17:13	0|kanzure|uh..
532 2017-07-06 19:17:26	0|BlueMatt|guess I had a different impression than everyone else, then
533 2017-07-06 19:17:27	0|luke-jr|kanzure: there is no way to use multiwallet right now
534 2017-07-06 19:17:48	0|wumpus|BlueMatt: it's possible, and not hard to implement, but just not the right choice for this IMO
535 2017-07-06 19:17:57	0|jonasschnelli|What about using v1/wallet/y<filename> and mark it unstable (experimental?) for 0.15?
536 2017-07-06 19:18:00	0|ryanofsky|BlueMatt, that was my impression too, it's the basis for 10661 & 10653
537 2017-07-06 19:18:01	0|jonasschnelli|-y
538 2017-07-06 19:18:06	0|sipa|i officially no longer have an opibion on approach
539 2017-07-06 19:18:07	0|wumpus|jonasschnelli: sounds good to me
540 2017-07-06 19:18:11	0|BlueMatt|ok, I mean I dont have a very strong impression, i just always thought that seemed natural
541 2017-07-06 19:18:19	0|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
542 2017-07-06 19:18:21	0|BlueMatt|but, really, can we flip a coin?
543 2017-07-06 19:18:33	0|sipa|
544 2017-07-06 19:18:38	0|wumpus|let's just go with endpoints for now
545 2017-07-06 19:18:56	0|jonasschnelli|Somone disagree?
546 2017-07-06 19:18:58	0|midnightmagic|how the heck did you send a blank line
547 2017-07-06 19:18:59	0|jonasschnelli|Anyone
548 2017-07-06 19:19:02	0|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.
549 2017-07-06 19:19:04	0|wumpus|if no one cares deeply, let's just stick with the decision of a few weeks ago
550 2017-07-06 19:19:25	0|instagibbs|gmaxwell, ack
551 2017-07-06 19:19:30	0|jonasschnelli|gmaxwell: we could mark the whole multiwallet (incl. endpoint) as experimental in 0.15
552 2017-07-06 19:19:33	0|jonasschnelli|And stable in 0.16
553 2017-07-06 19:19:35	0|wumpus|midnightmagic: that wasn't a blank line, it as \x7f characters
554 2017-07-06 19:19:43	0|wumpus|gmaxwell: yes, multiwallet is unstable in 0.15, +1
555 2017-07-06 19:19:52	0|wumpus|gmaxwell: there's probably quite some things that need to change, still
556 2017-07-06 19:19:59	0|morcos|no opinon on the issue, but ACK on making a decision.
557 2017-07-06 19:20:18	0|jonasschnelli|ryanofsky: could you live with the endpoint solution?
558 2017-07-06 19:20:44	0|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.
559 2017-07-06 19:20:54	0|ryanofsky|of course, yeah
560 2017-07-06 19:20:54	0|wumpus|gmaxwell: yes
561 2017-07-06 19:21:13	0|jonasschnelli|okay. Let me finish the endpoint PR and hope it will make it into 0.15
562 2017-07-06 19:21:19	0|wumpus|jonasschnelli: great!
563 2017-07-06 19:21:33	0|jonasschnelli|/topic
564 2017-07-06 19:21:40	0|wumpus|ryanofsky: thanks
565 2017-07-06 19:22:00	0|luke-jr|jonasschnelli: can you do it on top of 7b73f24311639fdc79c22608c21e4bfcbc6d4243 ?
566 2017-07-06 19:22:06	0|jonasschnelli|pr #?
567 2017-07-06 19:22:09	0|wumpus|any other topics?
568 2017-07-06 19:22:54	0|wumpus|remember morcos was saying something about fee PRs, but not sure it was aimed as a topic
569 2017-07-06 19:22:57	0|sipa|wifi just fied in the BS office
570 2017-07-06 19:22:59	0|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) :)
571 2017-07-06 19:22:59	0|luke-jr|jonasschnelli: it's part of #10615
572 2017-07-06 19:23:00	0|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
573 2017-07-06 19:23:12	0|luke-jr|https://github.com/bitcoin/bitcoin/pull/10615/commits/7b73f24311639fdc79c22608c21e4bfcbc6d4243
574 2017-07-06 19:23:13	0|wumpus|gmaxwell: yeah!
575 2017-07-06 19:23:16	0|jonasschnelli|luke-jr: 7b73f24311639fdc79c22608c21e4bfcbc6d4243 pollutes server.h with CWallet... :/
576 2017-07-06 19:23:19	0|jonasschnelli|(later)
577 2017-07-06 19:23:30	0|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
578 2017-07-06 19:23:35	0|gmaxwell|So yes, there are a number of fee/change handling PRs which are urgent for 0.15.
579 2017-07-06 19:23:39	0|morcos|yeah i don't really have a topic, but i need some review
580 2017-07-06 19:23:43	0|morcos|some are bug fixes
581 2017-07-06 19:23:48	0|gmaxwell|But I don't know what to say beyond that since they're already on the high prio list.
582 2017-07-06 19:23:48	0|wumpus|#topic fee PRs
583 2017-07-06 19:23:54	0|morcos|some are RPC api finalization which would be good to get right
584 2017-07-06 19:24:04	0|jonasschnelli|another topic proposal could be: txoutsbyaddress (it's marked with the 0.15 milestone)
585 2017-07-06 19:24:38	0|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...
586 2017-07-06 19:24:43	0|wumpus|jonasschnelli: bleh, server.h should definitely not get a CWallet reference, it's meant to be not specific to bitcoin, let alone wallet
587 2017-07-06 19:25:02	0|jonasschnelli|wumpus: yes. I think the same
588 2017-07-06 19:25:17	0|luke-jr|wumpus: jonasschnelli: I don't see a better alternative.
589 2017-07-06 19:25:43	0|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
590 2017-07-06 19:25:45	0|luke-jr|(keep in mind not all calls will come from the RPC server)
591 2017-07-06 19:25:48	0|morcos|but seems like that is not going to happen
592 2017-07-06 19:25:53	0|jonasschnelli|luke-jr: https://github.com/bitcoin/bitcoin/pull/10650/files#diff-df7d84ff2f53fcb2a0dc15a3a51e55ceR36
593 2017-07-06 19:26:01	0|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
594 2017-07-06 19:26:07	0|gmaxwell|morcos: oh the gui doesn't have access to the new estimates?  thats unfortunate.
595 2017-07-06 19:26:15	0|gmaxwell|I guess I need to do some gui testing, haven't used it in a while.
596 2017-07-06 19:26:17	0|bitcoin-git|[13bitcoin] 15ryanofsky closed pull request #10661: Add optional wallet=filename arguments to wallet RPCs (06master...06pr/multiopt) 02https://github.com/bitcoin/bitcoin/pull/10661
597 2017-07-06 19:26:17	0|morcos|gmaxwell: no
598 2017-07-06 19:26:24	0|jonasschnelli|gmaxwell: just not the conf target > 26+
599 2017-07-06 19:26:28	0|luke-jr|jonasschnelli: that doesn't work for GUI or tests
600 2017-07-06 19:26:36	0|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
601 2017-07-06 19:26:40	0|luke-jr|anyhow, later..
602 2017-07-06 19:26:57	0|jonasschnelli|non-conservative would be simple (a checkbox?)
603 2017-07-06 19:27:16	0|jonasschnelli|a slider with fix positions make little sense... sliders are ment to be linear
604 2017-07-06 19:27:22	0|jonasschnelli|A dropdown could make more sense
605 2017-07-06 19:27:31	0|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
606 2017-07-06 19:27:43	0|luke-jr|"ASAP", "today", "this week", "eventually"
607 2017-07-06 19:28:06	0|jonasschnelli|luke-jr: names tend to bikeshed... but at least "conf-target in block  |  time"
608 2017-07-06 19:28:32	0|jonasschnelli|Or maybe "time | blocks | feerate"
609 2017-07-06 19:28:53	0|jonasschnelli|Ideally we would run coinselection when opening the dropdown to tell the (possible) absolute fee
610 2017-07-06 19:29:04	0|morcos|jonasschnelli: please no
611 2017-07-06 19:29:09	0|morcos|feerate selection first
612 2017-07-06 19:29:12	0|morcos|then coin selection
613 2017-07-06 19:29:15	0|jonasschnelli|heh.. I though somebody will complain. :)
614 2017-07-06 19:29:19	0|achow101|coin selection needs fee rate..
615 2017-07-06 19:29:21	0|gmaxwell|we can't realistically do that. We need the feerate to perform selection.
616 2017-07-06 19:29:33	0|morcos|in the future coin selection may be different depending on feerate anyway
617 2017-07-06 19:29:39	0|gmaxwell|(and will need it more in the future)
618 2017-07-06 19:29:40	0|jonasschnelli|gmaxwell: do it for all options ... *duck*
619 2017-07-06 19:29:49	0|luke-jr|>_<
620 2017-07-06 19:30:00	0|luke-jr|coin selection can be slow, unless that's been optimised
621 2017-07-06 19:30:01	0|jonasschnelli|Thoughs about the dropbox?
622 2017-07-06 19:30:11	0|sipa|"The next Bitcoin-Qt version requires a 4k screen for coin selection"
623 2017-07-06 19:30:15	0|BlueMatt|lol
624 2017-07-06 19:30:15	0|morcos|in any case, i think _something_ simple would be ideal so users have access to longer than 25 confirms
625 2017-07-06 19:30:17	0|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.
626 2017-07-06 19:30:19	0|jonasschnelli|I'm happy to do it if it's general accaptable (the dropbown)
627 2017-07-06 19:30:22	0|BlueMatt|sipa: ooo, I have those, sounds gogod!
628 2017-07-06 19:30:24	0|BlueMatt|good
629 2017-07-06 19:31:09	0|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.
630 2017-07-06 19:31:18	0|jtimon|what about a box with number of blocks instead of a dropbox ?
631 2017-07-06 19:31:27	0|morcos|jonasschnelli: sure. something, anything.  but recommend you build off my other PR #10706
632 2017-07-06 19:31:28	0|gribble|https://github.com/bitcoin/bitcoin/issues/10706 | Improve wallet fee logic and fix GUI bugs by morcos · Pull Request #10706 · bitcoin/bitcoin · GitHub
633 2017-07-06 19:31:30	0|jonasschnelli|I'll try the dropdown and see how it feels.. should not be that hard
634 2017-07-06 19:31:32	0|jtimon|er dropdown
635 2017-07-06 19:31:35	0|jonasschnelli|morcos: will do
636 2017-07-06 19:31:36	0|sipa|do we have to do GUI design in this meeting?
637 2017-07-06 19:31:44	0|luke-jr|XD
638 2017-07-06 19:31:51	0|Murch|gmawell, it could estimate with a blocktarget of ~6 and do that before the window opens? ;)
639 2017-07-06 19:31:53	0|morcos|no i was just hoping for someone else to volunteer since seems jonas has a lot to do
640 2017-07-06 19:32:11	0|Murch|or whatever the default is nowaays
641 2017-07-06 19:32:15	0|morcos|and 0.15 is fast approaching
642 2017-07-06 19:32:16	0|gmaxwell|sipa: that wasn't GUI design, quite the opposite, there are economic reasons that gui clumping people wouldn't be great.
643 2017-07-06 19:32:20	0|luke-jr|I could give it a shot, I guess.
644 2017-07-06 19:32:44	0|jonasschnelli|luke-jr: I just started... :)
645 2017-07-06 19:32:51	0|luke-jr|heh
646 2017-07-06 19:32:58	0|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!!
647 2017-07-06 19:33:51	0|wumpus|#topic txoutsbyaddress (it's marked with the 0.15 milestone)
648 2017-07-06 19:33:56	0|wumpus|I think we should remove that milestone
649 2017-07-06 19:34:07	0|gmaxwell|Sadly. Has anyone been working on it?
650 2017-07-06 19:34:13	0|wumpus|#9806  has been quite inactive
651 2017-07-06 19:34:15	0|gribble|https://github.com/bitcoin/bitcoin/issues/9806 | txoutsbyaddress index (take 3) by droark · Pull Request #9806 · bitcoin/bitcoin · GitHub
652 2017-07-06 19:34:16	0|jonasschnelli|I'm more interested about should we or or not add an index for that
653 2017-07-06 19:34:25	0|wumpus|not publicly at least
654 2017-07-06 19:34:37	0|jonasschnelli|The best index implementations is currently the one from Bitpay,.. not?
655 2017-07-06 19:34:44	0|gmaxwell|jonasschnelli: I think we should; unlike many other things it's actually sustainable.
656 2017-07-06 19:35:00	0|jonasschnelli|I tend to also think we should
657 2017-07-06 19:35:07	0|jonasschnelli|(after installed a BWS index)
658 2017-07-06 19:35:09	0|gmaxwell|the bitpay index stuff is utterly unmaintable and borderline abandonware; fwiw.
659 2017-07-06 19:35:21	0|jtimon|why not by scriptpubkey ? that seems more generic
660 2017-07-06 19:35:26	0|sipa|there is some indexd project
661 2017-07-06 19:35:31	0|jonasschnelli|The most stables index I could find so far is that one: https://github.com/bitcoin/bitcoin/pull/10370
662 2017-07-06 19:35:36	0|gmaxwell|jtimon: yes, I think that was suggested on the PR.
663 2017-07-06 19:35:43	0|instagibbs|dcousens has an external index project which I think sipa is referring to
664 2017-07-06 19:35:51	0|jonasschnelli|(it's the one BWS [Bitpay wallet service] is unsing in the fileld since a couple of years)
665 2017-07-06 19:36:28	0|gmaxwell|jonasschnelli: the UTXO indexes are special because they actually have viable scalablity...
666 2017-07-06 19:36:44	0|sipa|https://github.com/bitcoinjs/indexd
667 2017-07-06 19:36:48	0|gmaxwell|I think anyone depending on complete blockchain indexes will eventually be forced onto centeralized servers, unfortunately.
668 2017-07-06 19:37:03	0|gmaxwell|so I have much less interest in internal support (hooks for external things sound fine though)
669 2017-07-06 19:37:45	0|jonasschnelli|Agree. Maybe internal txoutsbyaddress and for the rest, use something like indexd that sipa mentioned
670 2017-07-06 19:38:09	0|instagibbs|https://github.com/bitcoinjs/indexd
671 2017-07-06 19:38:10	0|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
672 2017-07-06 19:38:14	0|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
673 2017-07-06 19:38:26	0|morcos|I've got to run, but someone please tag #10557 #10589 #10707 #10712 for 0.15
674 2017-07-06 19:38:27	0|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
675 2017-07-06 19:38:27	0|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
676 2017-07-06 19:38:28	0|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
677 2017-07-06 19:38:29	0|gribble|https://github.com/bitcoin/bitcoin/issues/10707 | Better API for estimatesmartfee RPC by morcos · Pull Request #10707 · bitcoin/bitcoin · GitHub
678 2017-07-06 19:38:31	0|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
679 2017-07-06 19:39:07	0|wumpus|huh what is gribble doing
680 2017-07-06 19:39:12	0|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.
681 2017-07-06 19:39:13	0|morcos|(sorry)
682 2017-07-06 19:39:13	0|wumpus|oh sure morcos
683 2017-07-06 19:39:22	0|wumpus|gmaxwell: yes!
684 2017-07-06 19:39:31	0|jonasschnelli|tagged
685 2017-07-06 19:39:57	0|jonasschnelli|gmaxwell: yes. For HD restores in pruned env. the utxo index is handy
686 2017-07-06 19:39:58	0|wumpus|gmaxwell: would be very niec to instantly query the balance, if history isn't important
687 2017-07-06 19:40:34	0|gmaxwell|rescan has become so slow for me at least that I'm kinda desperate for something like that.
688 2017-07-06 19:40:42	0|gmaxwell|I've lost days of time waiting on rescans.
689 2017-07-06 19:41:42	0|wumpus|next topic?
690 2017-07-06 19:42:09	0|sipa|nope.
691 2017-07-06 19:42:26	0|gmaxwell|wumpus: can you remind me of the 0.15 schedule?
692 2017-07-06 19:42:31	0|luke-jr|eh, UTXO isn't a substitute for rescanning.. you'd miss historical txs
693 2017-07-06 19:42:48	0|BlueMatt|#9961
694 2017-07-06 19:42:49	0|gribble|https://github.com/bitcoin/bitcoin/issues/9961 | Release schedule for 0.15.0 · Issue #9961 · bitcoin/bitcoin · GitHub
695 2017-07-06 19:42:58	0|gmaxwell|luke-jr: thus pruned wallet, ... it's fine to not have historical txs if you know you don't.
696 2017-07-06 19:43:13	0|gmaxwell|BlueMatt: thanks!
697 2017-07-06 19:43:16	0|wumpus|luke-jr: what if you don't care about history, and just want balance + possibly spending?
698 2017-07-06 19:43:22	0|BlueMatt|T-10 days to branch
699 2017-07-06 19:43:23	0|luke-jr|gmaxwell: but you'd end up with *some* historical tx in this case, with no deterministic reason why some are missing
700 2017-07-06 19:43:28	0|gmaxwell|luke-jr: you can also say that txes found on the blockchain aren't a replacement for having their metadata... :)
701 2017-07-06 19:43:36	0|luke-jr|I suppose we could import them as all change-only or something? :/
702 2017-07-06 19:43:39	0|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
703 2017-07-06 19:43:40	0|wumpus|BlueMatt: no, not to branch, to feature freeze
704 2017-07-06 19:43:51	0|sipa|wumpus: it'd be incompatible with hardware wallets, before segwit
705 2017-07-06 19:43:52	0|luke-jr|jonasschnelli: hmm, good idea
706 2017-07-06 19:43:59	0|sipa|as you need the full crediting txn
707 2017-07-06 19:44:01	0|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.
708 2017-07-06 19:44:14	0|BlueMatt|oh, sorry, yes, freeze
709 2017-07-06 19:44:17	0|wumpus|BlueMatt: branch is 2017-08-06, so a month away
710 2017-07-06 19:44:21	0|gmaxwell|luke-jr: I made an issue describing some ideas for that a while back.
711 2017-07-06 19:44:22	0|luke-jr|gmaxwell: I see, makes sense
712 2017-07-06 19:45:06	0|achow101|wumpus: can #10571 and #10579 be tagged for 0.15?
713 2017-07-06 19:45:07	0|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
714 2017-07-06 19:45:08	0|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
715 2017-07-06 19:45:22	0|gmaxwell|There are other reasons why building such things are attractive... (e.g. UTXO based sync can't provide the data to give history...)
716 2017-07-06 19:45:33	0|wumpus|achow101: sure
717 2017-07-06 19:45:45	0|achow101|thanks
718 2017-07-06 19:45:48	0|gmaxwell|ack
719 2017-07-06 19:48:55	0|sipa|early lunch?
720 2017-07-06 19:49:53	0|wumpus|ye fine with me
721 2017-07-06 19:49:55	0|lightningbot|Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-07-06-19.00.log.html
722 2017-07-06 19:49:55	0|lightningbot|Meeting ended Thu Jul  6 19:49:54 2017 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
723 2017-07-06 19:49:55	0|lightningbot|Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-07-06-19.00.html
724 2017-07-06 19:49:55	0|lightningbot|Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-07-06-19.00.txt
725 2017-07-06 19:49:55	0|wumpus|#endmeeting
726 2017-07-06 19:50:33	0|spudowiar|Hardware wallet support rebased and now supports change addresses properly
727 2017-07-06 19:50:39	0|jtimon|so why is #8498 not to be tagged for 0.15 nor project 8 ? I want to understand the criterion
728 2017-07-06 19:50:41	0|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
729 2017-07-06 19:50:50	0|jtimon|criteria
730 2017-07-06 19:52:30	0|wumpus|jtimon: well if others think it should be tagged 0.15 or be high priority for review it's fine with me
731 2017-07-06 19:52:38	0|spudowiar|There are a few things I need to tackle now
732 2017-07-06 19:52:50	0|spudowiar|a) How the plugin can tell whether it is Testnet or Mainnet
733 2017-07-06 19:52:56	0|wumpus|jtimon: I don't personally see it as urgent enough for that, it's an optimization without mentioning timings
734 2017-07-06 19:53:25	0|wumpus|jtimon: but that's just my opinion
735 2017-07-06 19:53:30	0|jtimon|I see, thanks
736 2017-07-06 19:53:35	0|spudowiar|b) How the plugin can show a UI? (e.g. TREZOR Pin Matrix)
737 2017-07-06 19:53:57	0|spudowiar|Maybe the plugin can just create a window itself
738 2017-07-06 19:54:13	0|wumpus|spudowiar: la) aunch it with a flag/option that specifies which block chain
739 2017-07-06 19:54:18	0|wumpus|spudowiar: b) yes, have it draw it itself
740 2017-07-06 19:54:53	0|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
741 2017-07-06 19:55:09	0|spudowiar|c) Multiple devices (I'm going to add a device identifier parameter and a listhwwdevices method to the plugin)
742 2017-07-06 19:55:12	0|wumpus|spudowiar: or have a command askPin() from the plugin that shows a simple Qt message box with a prompt
743 2017-07-06 19:55:20	0|spudowiar|wumpus: It has a special GUI though
744 2017-07-06 19:55:32	0|spudowiar|Hence why I chose that example
745 2017-07-06 19:55:38	0|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
746 2017-07-06 19:55:50	0|jtimon|but there's more checkinputs calls now than when I first coded the thing
747 2017-07-06 19:56:19	0|spudowiar|d) Simplify usage (e.g. without command line parameters)
748 2017-07-06 19:56:35	0|spudowiar|This would require to store the plugin name and the device identifier somewhere (probably bitcoin.conf to begin with)
749 2017-07-06 19:56:55	0|spudowiar|e) Need to test multisig
750 2017-07-06 19:56:58	0|wumpus|yes
751 2017-07-06 19:57:27	0|spudowiar|yes to what?
752 2017-07-06 19:58:00	0|wumpus|"This would require to store the plugin name and the device identifier somewhere (probably bitcoin.conf to begin with)"
753 2017-07-06 19:58:10	0|spudowiar|ok
754 2017-07-06 19:58:33	0|jtimon|#10195 and #10192 likely changed how much of an improvement #8498 is as well
755 2017-07-06 19:58:37	0|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
756 2017-07-06 19:58:39	0|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
757 2017-07-06 19:58:40	0|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
758 2017-07-06 19:58:49	0|spudowiar|Not going to bother with listhwwdevices for now (that would be useful for a GUI to select the hardware device)
759 2017-07-06 19:59:24	0|wumpus|jtimon: some kind of measurement would be nice, e.g. startup time with a large wallet
760 2017-07-06 20:00:01	0|wumpus|spudowiar: agreed, auto-detecting devices would be something for later
761 2017-07-06 20:00:07	0|jtimon|why a wallet? the improvements are in connectBlock and AcceptToMemoryPool
762 2017-07-06 20:00:36	0|jtimon|wumpus: specially on the latter
763 2017-07-06 20:00:56	0|wumpus|jtimon: I'm confused then - yes wallet would not be appropriate then
764 2017-07-06 20:01:33	0|spudowiar|Oh, and I need to get rid of boost::process dependency
765 2017-07-06 20:01:45	0|instagibbs|spudowiar, please do :P
766 2017-07-06 20:01:55	0|wumpus|I would first focus on functionality
767 2017-07-06 20:02:01	0|jonasschnelli|spudowiar: I think URI schema is the best option for the GUI
768 2017-07-06 20:02:02	0|spudowiar|instagibbs: Find me an alternative :) I don't know C++
769 2017-07-06 20:02:05	0|wumpus|then only when it works, on removing dependencies
770 2017-07-06 20:02:14	0|jonasschnelli|call sign://
771 2017-07-06 20:02:20	0|jonasschnelli|or bitcoinsign://
772 2017-07-06 20:02:20	0|wumpus|too easy to get stuck in yak shaving dependencies
773 2017-07-06 20:02:27	0|spudowiar|jonasschnelli: That overcomplicates things in my opinion
774 2017-07-06 20:02:50	0|instagibbs|wumpus, it's a super new module, only reason I care
775 2017-07-06 20:02:51	0|jonasschnelli|It's a clean separation... could work as a standard
776 2017-07-06 20:03:00	0|jonasschnelli|Otherwise other non-core application could not tab in
777 2017-07-06 20:03:00	0|spudowiar|jonasschnelli: How do you get the data back, anyway?
778 2017-07-06 20:03:11	0|instagibbs|I don't feel like installing it to test his work, so I've rolled my own solution until then
779 2017-07-06 20:03:32	0|spudowiar|jonasschnelli: Why can't non-Core applications use these plugins?
780 2017-07-06 20:03:33	0|jonasschnelli|Core sends: bitcoinsign://signtx?data=blabla&callback=bitcoincore
781 2017-07-06 20:03:43	0|jonasschnelli|spudowiar: you plugin would call back bitcoincore://
782 2017-07-06 20:03:44	0|sipa|why a URI...?
783 2017-07-06 20:03:46	0|spudowiar|So, Core needs to register its own protocol now?
784 2017-07-06 20:03:54	0|spudowiar|URIs are really unnecessary here
785 2017-07-06 20:03:58	0|jonasschnelli|sipa: URI is the only think that works in sandboxed env
786 2017-07-06 20:04:05	0|sipa|jonasschnelli: i don't understand
787 2017-07-06 20:04:07	0|jonasschnelli|(Android, iOS, OSX [soonish])
788 2017-07-06 20:04:20	0|sipa|?
789 2017-07-06 20:04:43	0|jonasschnelli|In sandboxed enviroments, interprocess communication is impossible, expect over URIs
790 2017-07-06 20:04:46	0|spudowiar|jonasschnelli: JSON-RPC is transport agnostic
791 2017-07-06 20:04:55	0|spudowiar|jonasschnelli: So you can do JSON-RPC over URI if you want, on those platforms
792 2017-07-06 20:05:03	0|spudowiar|I'd prefer not to register arbitrary protocols on my desktop though
793 2017-07-06 20:05:18	0|sipa|ok, so use some wrapper URI on those platforms
794 2017-07-06 20:05:20	0|spudowiar|Not when a perfectly suitable solution exists
795 2017-07-06 20:05:28	0|gmaxwell|what sipa said
796 2017-07-06 20:05:31	0|sipa|not as part of the IPC mechanism in general
797 2017-07-06 20:05:42	0|jonasschnelli|that makes sense....
798 2017-07-06 20:06:02	0|jonasschnelli|in my example: bitcoinsign://signtx?data=blabla&callback=bitcoincore the blabla elements could be the JSON/RPC layer
799 2017-07-06 20:06:19	0|spudowiar|Yep
800 2017-07-06 20:06:44	0|spudowiar|At the moment though, I require the JSON-RPC to be in roughly getrawtransaction format
801 2017-07-06 20:07:02	0|spudowiar|I want to strip parts of that out, then write documentation for the protocol
802 2017-07-06 20:07:55	0|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
803 2017-07-06 20:08:01	0|spudowiar|https://github.com/saleemrashid/bitcoin/blob/hardware-wallet/src/wallet/wallet.cpp#L1500
804 2017-07-06 20:26:42	0|bitcoin-git|[13bitcoin] 15theuni opened pull request #10756: net processing: swap out signals for an interface class (06master...06no-net-signals2) 02https://github.com/bitcoin/bitcoin/pull/10756
805 2017-07-06 20:27:46	0|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
806 2017-07-06 20:30:27	0|gmaxwell|<3
807 2017-07-06 20:31:42	0|gmaxwell|though it shows how much y'all have worn me down about C++ features that I'm cheering for inheretence. :)
808 2017-07-06 20:32:11	0|cfields|heh
809 2017-07-06 20:32:26	0|gmaxwell|my backtraces thank you, however.
810 2017-07-06 20:32:55	0|gmaxwell|I believe this may be measurably faster too... when I ripped out signals and replaced it with direct function calls it was.
811 2017-07-06 20:33:07	0|gmaxwell|the signals stuff has thread synchronization inside it.
812 2017-07-06 20:33:12	0|cfields|yea. I should add that to the PR description.. that might actually be the nicest part of the change
813 2017-07-06 20:33:28	0|cfields|gmaxwell: yea, i've owed you this PR for months now. Sorry for the delay.
814 2017-07-06 20:33:49	0|gmaxwell|Don't worry, I didn't remember.
815 2017-07-06 20:34:22	0|cfields|heh ok
816 2017-07-06 21:13:16	0|jamesob|any thoughts on adding a Dockerfile to the repo? might make setting up a dev environment marginally easier
817 2017-07-06 22:25:50	0|stalictite|what's the armory dev irc?
818 2017-07-06 22:26:04	0|stalictite|nvm got it
819 2017-07-06 23:21:35	0|bitcoin-git|[13bitcoin] 15jtimon opened pull request #10757: RPC: Introduce getperblockstats to plot things (06master...06b15-rpc-plotter) 02https://github.com/bitcoin/bitcoin/pull/10757
820 2017-07-06 23:27:39	0|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...
821 2017-07-06 23:34:15	0|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
822 2017-07-06 23:40:20	0|jtimon|not sure what the proper C++11 replacement for boost::split(plot_values, str_plot_values, boost::is_any_of(",")); would be
823 2017-07-06 23:41:04	0|sipa|i don't believe c++11 has a replacement for that
824 2017-07-06 23:41:12	0|jtimon|:(
825 2017-07-06 23:41:19	0|jtimon|c++14 ?
826 2017-07-06 23:41:38	0|sipa|https://stackoverflow.com/a/5167799
827 2017-07-06 23:44:00	0|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!
828 2017-07-06 23:45:33	0|jtimon|I would like a std::vector<std::string> std::string::split(std::string), like python
829 2017-07-06 23:46:19	0|sipa|you can write such a function :)
830 2017-07-06 23:46:21	0|jtimon|anyway, my build is failing to compile in some platforms, it seems univalue is not as multiplatform as I thought
831 2017-07-06 23:47:24	0|jtimon|yeah, I could write such a function and replace it everywhere I guess, instead of only using it in the new rpc function
832 2017-07-06 23:48:02	0|jtimon|oh, you mean for C++ ?
833 2017-07-06 23:50:16	0|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
834 2017-07-06 23:57:15	0|sipa|jtimon: in #10757 you're pushing a size_t into UniValue
835 2017-07-06 23:57:16	0|gribble|https://github.com/bitcoin/bitcoin/issues/10757 | RPC: Introduce getperblockstats to plot things by jtimon · Pull Request #10757 · bitcoin/bitcoin · GitHub
836 2017-07-06 23:57:22	0|sipa|size_t is platform dependent
837 2017-07-06 23:57:31	0|sipa|cast it to int64_t first
838 2017-07-06 23:57:49	0|jtimon|yeah, I thought I had to use to constructor for all ints, it'sjust a simple cast
839 2017-07-06 23:57:53	0|jtimon|thanks