12017-07-06T00:12:46 *** owowo has quit IRC
22017-07-06T00:14:06 *** coredump_ has joined #bitcoin-core-dev
32017-07-06T00:15:54 *** Chris_Stewart_5 has joined #bitcoin-core-dev
42017-07-06T00:16:46 *** tmddzk has quit IRC
52017-07-06T00:17:43 *** owowo has joined #bitcoin-core-dev
62017-07-06T00:18:45 *** AaronvanW_ has quit IRC
72017-07-06T00:31:21 *** PaulCapestany has joined #bitcoin-core-dev
82017-07-06T00:35:17 *** PaulCapestany has quit IRC
92017-07-06T00:44:46 *** CubicEarth has quit IRC
102017-07-06T00:44:49 <kanzure> i am unsure of the interactions between MIN_FINAL_CHANGE and the targeted fee rate and whether that should be the assumed fee rate for eventually spending the change output.
112017-07-06T00:48:24 <kanzure> oh, "achow101's implementation uses a 1008 block feerate estimate" for the change output amount check before decide burn to miner fee?
122017-07-06T00:49:36 <achow101> kanzure: the 1008 block feerate estimate is for the cost of change. It's the maximum of the feerate and the min relay fee
132017-07-06T00:50:23 <kanzure> "and now you're also throwing away the change output itself,so you are potentially overpaying the newly needed fee by double the cost of creating the change" <--- why not redo the final size estimate and calculate new fee, then redo coin selection for potentially fewer inputs? keep list of n best options, break after grinding for i dunno 10k rounds.
142017-07-06T00:51:02 <gmaxwell> because complex hairball.
152017-07-06T00:51:17 <gmaxwell> Achow's stuff doesn't have that issue, the branch and bound thing assumes always that there will be no change.
162017-07-06T00:51:18 <kanzure> is there a writeup of a wishlist for simulators in this area, or is that also hairball land?
172017-07-06T00:52:32 <kanzure> there was already some area in core that attempts to redo coin selection by increasing the amount and trying again; some of this could probably be consolidated.
182017-07-06T00:56:15 <kanzure> i have this weird case where i have to use two "change" outputs, one of them i can burn to miner fee if it's too small, the other one i need to go back and pick other inputs until i can piggyback. anyway, lots of questions around utxo results after actual usage, i will have to write a simulator at some point.
192017-07-06T00:58:09 *** handlex has quit IRC
202017-07-06T00:59:49 *** dabura667 has joined #bitcoin-core-dev
212017-07-06T01:00:23 <kanzure> (can't help but think of this like iterative rocket equation calculation until elon musk is sure that his rocket will land at zero velocity with zero fuel left, except for coins we're not targeting total fee exhaustion of course.)
222017-07-06T01:05:59 *** Ylbam has quit IRC
232017-07-06T01:06:33 *** talmai has quit IRC
242017-07-06T01:09:04 *** chjj has quit IRC
252017-07-06T01:10:22 *** Murch has quit IRC
262017-07-06T01:21:09 *** chjj has joined #bitcoin-core-dev
272017-07-06T01:34:47 *** fanquake has joined #bitcoin-core-dev
282017-07-06T01:37:19 <fanquake> Would anyone object to #8550 going into 0.15 ?
292017-07-06T01:37:21 <gribble> https://github.com/bitcoin/bitcoin/issues/8550 | [Qt] Add interactive mempool graph by jonasschnelli · Pull Request #8550 · bitcoin/bitcoin · GitHub
302017-07-06T01:43:45 *** Dyaheon has quit IRC
312017-07-06T01:44:54 *** Dyaheon has joined #bitcoin-core-dev
322017-07-06T01:45:15 *** Chris_Stewart_5 has quit IRC
332017-07-06T01:47:22 <gmaxwell> :(
342017-07-06T01:47:33 <gmaxwell> Thats the graph that doesn't break things up by feerate?
352017-07-06T01:47:43 <gmaxwell> those sorts of graphs have had really bad effects in social media.
362017-07-06T01:48:05 <gmaxwell> People flood with minrelay fee txn to push the numbers up. and then spam with OMG MEMPOOL FULL SELL BITCOINS NOW
372017-07-06T01:48:35 <gmaxwell> Since rate breaking up graphs became more common those minrelay floods seem to have stopped.
382017-07-06T02:08:39 <fanquake> Well we can adjust the graph to break the txs up and display however we'd like, but I think having that info available to node operators would be a plus.
392017-07-06T02:19:23 <morcos> fanquake: that PR is based on #8501 which seems like hasn't gotten work in quite some time
402017-07-06T02:19:24 <gribble> https://github.com/bitcoin/bitcoin/issues/8501 | Add mempool statistics collector by jonasschnelli · Pull Request #8501 · bitcoin/bitcoin · GitHub
412017-07-06T02:19:43 <morcos> in any case I don't think it's making it for 0.15 at this point
422017-07-06T02:20:59 *** chjj has quit IRC
432017-07-06T02:27:02 *** talmai has joined #bitcoin-core-dev
442017-07-06T02:31:07 <fanquake> morcos Fair enough. Will concentrate on other PRs. Need to put aside some time to look through all your fee work.
452017-07-06T02:52:20 *** talmai has quit IRC
462017-07-06T02:57:04 *** arowser has quit IRC
472017-07-06T03:03:10 *** fanquake has quit IRC
482017-07-06T03:04:44 *** arowser has joined #bitcoin-core-dev
492017-07-06T03:04:52 *** stalictite has joined #bitcoin-core-dev
502017-07-06T03:20:41 *** RubenSomsen has joined #bitcoin-core-dev
512017-07-06T03:46:09 *** Alina-malina has quit IRC
522017-07-06T03:56:50 *** Alina-malina has joined #bitcoin-core-dev
532017-07-06T04:09:23 *** mol has quit IRC
542017-07-06T04:11:08 *** molz has joined #bitcoin-core-dev
552017-07-06T04:15:28 *** stalictite has quit IRC
562017-07-06T05:08:45 *** RubenSomsen has quit IRC
572017-07-06T05:09:57 *** fanquake has joined #bitcoin-core-dev
582017-07-06T05:11:49 *** pindarhk__ has joined #bitcoin-core-dev
592017-07-06T05:17:51 *** michagogo_ has joined #bitcoin-core-dev
602017-07-06T05:19:09 *** kinlo_ has joined #bitcoin-core-dev
612017-07-06T05:22:24 *** pindarhk_ has quit IRC
622017-07-06T05:22:24 *** michagogo has quit IRC
632017-07-06T05:22:25 *** kinlo has quit IRC
642017-07-06T05:22:28 *** pindarhk__ is now known as pindarhk_
652017-07-06T05:22:30 *** kinlo_ is now known as kinlo
662017-07-06T05:22:37 *** michagogo_ is now known as michagogo
672017-07-06T05:25:43 *** Lilly2 has quit IRC
682017-07-06T05:26:18 *** lifeofguenter has quit IRC
692017-07-06T05:27:20 *** lifeofguenter has joined #bitcoin-core-dev
702017-07-06T05:27:34 *** Felipe2 has joined #bitcoin-core-dev
712017-07-06T05:31:33 *** cryptapus_afk has quit IRC
722017-07-06T05:32:50 *** cryptapus_afk has joined #bitcoin-core-dev
732017-07-06T05:32:50 *** cryptapus_afk has joined #bitcoin-core-dev
742017-07-06T05:38:57 *** afk11 has quit IRC
752017-07-06T05:41:05 *** arubi has quit IRC
762017-07-06T05:45:12 *** afk11 has joined #bitcoin-core-dev
772017-07-06T05:45:17 *** arubi has joined #bitcoin-core-dev
782017-07-06T05:47:39 *** chjj has joined #bitcoin-core-dev
792017-07-06T05:48:44 *** jtimon has joined #bitcoin-core-dev
802017-07-06T05:50:43 <jtimon> sipa: something seems wrong with how can I access the CTxOut of an input with AccessByTxid(/Coin in.prevout.hash but without needing in.prevout.n?
812017-07-06T05:51:17 <jtimon> I bet I'm missing something, but not sure what
822017-07-06T05:53:38 <jtimon> oh, there's no in.prevout.n anymore, nevermind
832017-07-06T05:55:33 <jtimon> wait...I'll think more about this, I know how to fing the PR that's relevant
842017-07-06T05:57:19 *** atroxes has quit IRC
852017-07-06T06:02:55 *** atroxes has joined #bitcoin-core-dev
862017-07-06T06:18:12 *** city22 has joined #bitcoin-core-dev
872017-07-06T06:19:36 *** waxwing has quit IRC
882017-07-06T06:20:04 *** MarcoFalke has quit IRC
892017-07-06T06:20:12 *** MarcoFalke has joined #bitcoin-core-dev
902017-07-06T06:20:14 *** waxwing has joined #bitcoin-core-dev
912017-07-06T06:21:00 *** petertodd has quit IRC
922017-07-06T06:21:28 *** jnewbery has quit IRC
932017-07-06T06:21:43 *** jnewbery has joined #bitcoin-core-dev
942017-07-06T06:22:32 *** petertodd has joined #bitcoin-core-dev
952017-07-06T06:33:38 <gmaxwell> jtimon: you cannot. The database doesn't efficiently support that access anymore, it shouldn't generally be needed.
962017-07-06T06:38:48 <jtimon> gmaxwell: my point is...how can it even guarantee the input looked for is the one that is gotten without passing n? it seems like all instances of AccessByTxid should be replaced wiht inputs.AccessCoin(tx.vin[n].prevout) or a similar wrapper
972017-07-06T06:39:30 <jtimon> summary: AccessByTxid seems completely uinsafe to me at this point unless I'm missing something
982017-07-06T06:39:52 <jtimon> which is not uncommon
992017-07-06T06:41:44 *** waxwing has quit IRC
1002017-07-06T06:41:45 *** waxwing has joined #bitcoin-core-dev
1012017-07-06T06:41:59 *** Ylbam has joined #bitcoin-core-dev
1022017-07-06T06:45:43 *** pigma64 has joined #bitcoin-core-dev
1032017-07-06T06:45:44 *** pigma64 has quit IRC
1042017-07-06T06:50:51 <sipa> jtimon: AccessByTxid is only for finding height/coinbase
1052017-07-06T06:50:59 <sipa> obviously you can't use it to find an actual output
1062017-07-06T06:52:06 <jtimon> oh, I see, that's what I was missing
1072017-07-06T06:52:27 <sipa> it's also extremely slow
1082017-07-06T06:52:44 <jtimon> it still seems weird that you have access to some arvitrary txout from it though
1092017-07-06T06:52:58 <sipa> i guess
1102017-07-06T06:53:26 <wumpus> please don't do anything on transifex, especially with the "0.15.x" resource, I was running the script to copy over the translation strings from 0.14 and something weird happened, not sure why but it looked like someone overwrote the translation strings (even though it's locked)
1112017-07-06T06:54:51 <jtimon> it shouldn't retun a full coin class, or something, anyway, thank you for the missing piece
1122017-07-06T06:55:35 *** pigma64 has joined #bitcoin-core-dev
1132017-07-06T06:56:13 <sipa> seems very reasonable to document that
1142017-07-06T06:58:45 <sipa> gmaxwell: finding CTxOuts is totally doable though... you just need AccessCoin not AccessByTxid
1152017-07-06T06:59:41 <sipa> (Coin contains a CTxOut and fCoinbase and nHeight)
1162017-07-06T07:10:58 *** timothy has joined #bitcoin-core-dev
1172017-07-06T07:12:57 *** LeMiner2 has joined #bitcoin-core-dev
1182017-07-06T07:15:36 *** LeMiner has quit IRC
1192017-07-06T07:15:37 *** LeMiner2 is now known as LeMiner
1202017-07-06T07:21:20 *** fanquake has quit IRC
1212017-07-06T07:22:58 *** chjj has quit IRC
1222017-07-06T07:31:14 *** jtimon has quit IRC
1232017-07-06T07:39:39 *** tiagotrs has joined #bitcoin-core-dev
1242017-07-06T07:46:58 <bitcoin-git> [bitcoin] laanwj pushed 1 new commit to master: https://github.com/bitcoin/bitcoin/commit/191d12b07377393c9eb67770ff5cb8e9a1c5cd7c
1252017-07-06T07:46:58 <bitcoin-git> bitcoin/master 191d12b Wladimir J. van der Laan: qt: First translations update for 0.15
1262017-07-06T07:48:16 <wumpus> transifex copy was successful this time - copied translations (+metadata) from 0.14 to 0.15, and updated 0.15 resource with new messages, set to auto-update from master (don't forget to change when 0.15 branches off), unlocked - should be good to go
1272017-07-06T07:48:47 *** Evel-Knievel has joined #bitcoin-core-dev
1282017-07-06T07:49:12 *** coredump_ has quit IRC
1292017-07-06T07:51:03 *** laurentmt has joined #bitcoin-core-dev
1302017-07-06T07:52:08 *** laurentmt has quit IRC
1312017-07-06T08:01:02 *** RubenSomsen has joined #bitcoin-core-dev
1322017-07-06T08:08:33 <wumpus> https://lists.linuxfoundation.org/pipermail/bitcoin-core-dev/2017-July/000042.html
1332017-07-06T08:16:57 <luke-jr> I guess 0.15 will probably miss multiwallet :/
1342017-07-06T08:17:14 <luke-jr> (at least in terms of it being actually usable in the GUI)
1352017-07-06T08:18:36 *** instagibbs has quit IRC
1362017-07-06T08:19:23 *** instagibbs has joined #bitcoin-core-dev
1372017-07-06T08:25:03 *** elkalamar_ has quit IRC
1382017-07-06T08:46:10 *** NotME_ has joined #bitcoin-core-dev
1392017-07-06T09:02:10 *** riemann has joined #bitcoin-core-dev
1402017-07-06T09:17:39 *** JackH has joined #bitcoin-core-dev
1412017-07-06T09:18:09 *** goatpig has joined #bitcoin-core-dev
1422017-07-06T09:29:16 <wumpus> we should aim for basic RPC multiwallet
1432017-07-06T09:29:28 <wumpus> full GUI multiwallet is not realistic for 0.15
1442017-07-06T09:30:38 <wumpus> darn, forgot to add a tree-sha512 to the last commit on master
1452017-07-06T09:32:07 *** coredump_ has joined #bitcoin-core-dev
1462017-07-06T09:35:42 <wumpus> why don't we have a "skip these commits for treesha512 check" and only "treesha512 root commit"?
1472017-07-06T09:36:46 *** bordeaux_facile is now known as toinetoine
1482017-07-06T09:38:37 *** toinetoine is now known as bordeaux_facile
1492017-07-06T09:39:08 <wumpus> argh updating the root commit didn't work, it also checks the root
1502017-07-06T09:43:35 *** RubenSomsen has quit IRC
1512017-07-06T09:44:18 <wumpus> BlueMatt: how to fix this?
1522017-07-06T09:46:35 *** jannes has quit IRC
1532017-07-06T09:46:37 <wumpus> ... I guess merging a PR with a treehash, then updating the root commit to that would work
1542017-07-06T09:46:52 *** jannes has joined #bitcoin-core-dev
1552017-07-06T09:49:11 <wumpus> another option would be to force-push the last commit with a treehash, but it's been in master too long
1562017-07-06T09:49:18 <wumpus> neither is really nice
1572017-07-06T09:51:26 <luke-jr> take the last one with a treehash, and merge the current master into it?
1582017-07-06T09:52:01 <luke-jr> could force-push the last commit and open a PR with the real master, if that makes it easier
1592017-07-06T09:55:17 <wumpus> that's a smart idea, your first idea is fully fast-forwardable, right?
1602017-07-06T10:03:09 <wumpus> seems to work locally, thanks
1612017-07-06T10:03:36 *** RubenSomsen has joined #bitcoin-core-dev
1622017-07-06T10:04:02 <wumpus> here goes nothing...
1632017-07-06T10:04:11 <bitcoin-git> [bitcoin] laanwj pushed 1 new commit to master: https://github.com/bitcoin/bitcoin/commit/a5cd829a0b51b69a2e7d5e93f55196f7d67a7462
1642017-07-06T10:04:11 <bitcoin-git> bitcoin/master a5cd829 Wladimir J. van der Laan: Merge branch qt-translations into master...
1652017-07-06T10:13:51 *** city22 has quit IRC
1662017-07-06T10:16:48 *** coredump_ has quit IRC
1672017-07-06T10:17:37 *** AaronvanW has joined #bitcoin-core-dev
1682017-07-06T10:19:08 *** Aaronvan_ has joined #bitcoin-core-dev
1692017-07-06T10:23:13 *** AaronvanW has quit IRC
1702017-07-06T10:24:33 *** marcoagner has quit IRC
1712017-07-06T10:24:48 <wumpus> yay Fixed: bitcoin/bitcoin#19612 (master - a5cd829)
1722017-07-06T10:24:49 <gribble> https://github.com/bitcoin/bitcoin/issues/19612 | HTTP Error 404: Not Found
1732017-07-06T10:36:04 *** marcoagner has joined #bitcoin-core-dev
1742017-07-06T11:01:20 *** timothy has quit IRC
1752017-07-06T11:03:34 *** Guyver2 has joined #bitcoin-core-dev
1762017-07-06T11:44:15 *** Alina-malina has quit IRC
1772017-07-06T11:44:15 *** Alina-malina has joined #bitcoin-core-dev
1782017-07-06T11:48:06 *** F2ee has joined #bitcoin-core-dev
1792017-07-06T11:57:23 *** dabura667 has quit IRC
1802017-07-06T11:58:23 *** F2ee has quit IRC
1812017-07-06T12:02:15 *** justan0theruser has joined #bitcoin-core-dev
1822017-07-06T12:04:49 *** justanotheruser has quit IRC
1832017-07-06T12:47:44 *** timothy has joined #bitcoin-core-dev
1842017-07-06T12:53:56 *** tiagotrs has quit IRC
1852017-07-06T12:54:09 *** afk11 has quit IRC
1862017-07-06T12:54:41 *** afk11 has joined #bitcoin-core-dev
1872017-07-06T12:57:37 *** RubenSomsen has quit IRC
1882017-07-06T13:10:50 *** unholymachine has quit IRC
1892017-07-06T13:13:20 *** unholymachine has joined #bitcoin-core-dev
1902017-07-06T13:13:41 *** Chris_Stewart_5 has joined #bitcoin-core-dev
1912017-07-06T13:19:24 <bitcoin-git> [bitcoin] laanwj opened pull request #10753: test: Check RPC argument mapping (master...2017_07_rpc_argument_check) https://github.com/bitcoin/bitcoin/pull/10753
1922017-07-06T13:29:56 *** dseg has joined #bitcoin-core-dev
1932017-07-06T13:50:29 *** dseg has quit IRC
1942017-07-06T13:51:10 *** stalictite has joined #bitcoin-core-dev
1952017-07-06T13:54:07 *** RoyceX has joined #bitcoin-core-dev
1962017-07-06T13:54:20 *** Cheeseo has quit IRC
1972017-07-06T13:55:44 <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/a5cd829a0b51...be824984626f
1982017-07-06T13:55:44 <bitcoin-git> bitcoin/master bd00fa5 John Newbery: [test] don't run dbcrash.py on Travis
1992017-07-06T13:55:46 <bitcoin-git> bitcoin/master be82498 Wladimir J. van der Laan: Merge #10743: [test] don't run dbcrash.py on Travis...
2002017-07-06T13:56:15 <bitcoin-git> [bitcoin] laanwj closed pull request #10743: [test] don't run dbcrash.py on Travis (master...dontrundbcrash) https://github.com/bitcoin/bitcoin/pull/10743
2012017-07-06T14:20:26 *** tiagotrs has joined #bitcoin-core-dev
2022017-07-06T14:20:53 *** AaronvanW has joined #bitcoin-core-dev
2032017-07-06T14:22:58 *** Aaronvan_ has quit IRC
2042017-07-06T14:57:23 *** riemann has quit IRC
2052017-07-06T15:05:21 *** Guyver2_ has joined #bitcoin-core-dev
2062017-07-06T15:07:53 *** Guyver2 has quit IRC
2072017-07-06T15:07:54 *** Guyver2_ is now known as Guyver2
2082017-07-06T15:07:57 *** Murch has joined #bitcoin-core-dev
2092017-07-06T15:22:48 *** tiagotrs has quit IRC
2102017-07-06T15:24:31 *** tiagotrs has joined #bitcoin-core-dev
2112017-07-06T15:31:53 <BlueMatt> wumpus: ugh, please add the pre-push-hook locally
2122017-07-06T15:32:01 * BlueMatt goes to check whats up
2132017-07-06T15:45:19 <BlueMatt> wumpus: oh, yes, thanks luke-jr, clever solution
2142017-07-06T15:45:52 <morcos> achow101: instagibbs: Murch: I have a couple questions about branch&bound, effective value and change
2152017-07-06T15:46:05 <Murch> okay
2162017-07-06T15:46:36 <morcos> So I see how we are accounting for output size via output_fee and input_size via nInputBytes
2172017-07-06T15:46:47 <morcos> But how are we accounting for fees paid on the fixed part of a tx
2182017-07-06T15:47:01 <morcos> Won't we necessarily fail if we get too close to an exact match?
2192017-07-06T15:47:36 <morcos> Second question: Why are we using the longest possible estimate for the creation of change?
2202017-07-06T15:47:41 <Murch> We first get an estimate for the fee rate. Since we know which outputs we want to create for recipients, we can calculate the amount of fee for the outputs.
2212017-07-06T15:48:05 <Murch> We add that and the cost of the transaction overhead to the target
2222017-07-06T15:48:23 <Murch> So, when we select inputs, we can deduct the cost of the inputs from each that we select and thus we have accumulated all fees necessary.
2232017-07-06T15:48:51 <morcos> The transaction overhead piece is the part I was missing
2242017-07-06T15:48:54 <morcos> maybe i just missed it
2252017-07-06T15:49:41 <Murch> Do you mean specifically in the code? I think that achow101 was missing something there, and we discovered the bug in review recently. I'm not sure if he already fixed it.
2262017-07-06T15:50:33 <morcos> ok. yeah thats what i meant
2272017-07-06T15:50:43 <morcos> i'm mostly asking questions about his code
2282017-07-06T15:50:54 <Murch> Re 2nd Q: BnB only creates transactions without change outputs. Since we can account for the fees of the overhead and outputs in advance, and the fees for the inputs on the fly, we're good. So I don't get what you mean with "creation of change".
2292017-07-06T15:51:18 <morcos> I mean the cost of change_
2302017-07-06T15:51:30 <morcos> we're calculating it using a smart fee estimate for 1008 blocks
2312017-07-06T15:51:44 <morcos> when in reality it'll cost us whatever fee we're using for this transaction creation
2322017-07-06T15:51:54 <Murch> Well, actually, this is the part that I'm not comfortable with yet.
2332017-07-06T15:52:12 <Murch> Obviously, the only amount that we're clearly saving is the cost of creating a change output.
2342017-07-06T15:53:09 <Murch> However, in my simulation, I got a cost reduction by allowing the larger window of "cost of input+output". I was assuming _fixed feerates_ though.
2352017-07-06T15:53:18 <morcos> ah i see, i'd missed that
2362017-07-06T15:53:30 <morcos> well what i'm saying is something different again
2372017-07-06T15:53:45 <Murch> I think that it would need some experimentation to determine whether it is actually a net-benefit to have the larger window and thus save the change more often or not.
2382017-07-06T15:53:54 <morcos> actually waht we might want is something similar to what i did in #10712
2392017-07-06T15:53:55 <gribble> https://github.com/bitcoin/bitcoin/issues/10712 | Add change output if necessary to reduce excess fee by morcos · Pull Request #10712 · bitcoin/bitcoin · GitHub
2402017-07-06T15:54:12 <morcos> but my point was the change_feerate we are using is possibly too low
2412017-07-06T15:54:19 <Murch> One of the Trezor people implemented BnB for BitcoinJS this week, and came to the conclusion that "cost of change = change * current feerate" has greater savings.
2422017-07-06T15:54:23 <morcos> maybe that is a good feerate to use for assumption of spending the change output in the future
2432017-07-06T15:54:27 <Murch> So I would suggest that we go with that first.
2442017-07-06T15:55:01 <morcos> might it make sense to cache the best result found so far and keep searching
2452017-07-06T15:55:30 <morcos> and have two thresholds, one which is good enough to stop searching further, and one which is good enough if its the best thing we came to at the end of the exhaustive search (or hitting max tries)
2462017-07-06T15:56:54 <morcos> In any case we're possibly willing to just throw away the amount of fees determined by change_feerate right? i'd be very hesitant to just use 1008 for that
2472017-07-06T15:57:15 * instagibbs reading backlog
2482017-07-06T15:57:24 <morcos> I've seen that number as high as 100 sat/byte, not sure poeple would want to throw away that much, at least not without looking for a better exact match
2492017-07-06T15:57:45 <Murch> My gut feeling is that this would increase the size of the selected input sets. That would both increase the variance of the input set size, and perhaps reduce the utxo pool more quickly, perhaps reducing overall effectiveness of BnB.
2502017-07-06T15:58:05 <morcos> sorry, what would?
2512017-07-06T15:58:06 <Murch> More experiments would inform us, I guess.
2522017-07-06T15:58:17 <Murch> finding the "best solution".
2532017-07-06T15:58:28 <Murch> Also would probably increase the search times a lot
2542017-07-06T15:58:43 <Murch> mh
2552017-07-06T15:58:53 <Murch> sorry, I'm too slow
2562017-07-06T15:58:55 <morcos> yeah i was a bit concerned about that
2572017-07-06T15:59:44 <Murch> So 1) for the window of determining the exact match, I would use the same fee rate as for the transaction * size of a change output.
2582017-07-06T16:00:10 <morcos> Yes even plus the dust threshold of the output itself
2592017-07-06T16:00:13 <morcos> as done in 10712
2602017-07-06T16:00:32 <instagibbs> Murch, im sorry you mean don't consider a future spend of it?
2612017-07-06T16:00:40 <Murch> 2) I would go with the first solution instead of the best solution, because it reduces variance in input set size, reduces computation time, and will probably be more conducive to finding many exact matches.
2622017-07-06T16:00:57 <instagibbs> oh sorry, you mean use same feerate for both output size and future input
2632017-07-06T16:00:59 <morcos> I'll defer to your judgement on that
2642017-07-06T16:01:15 <morcos> no instagibbs i think he means don't consider future input
2652017-07-06T16:01:30 <instagibbs> due to the bitcoinjs experiments?
2662017-07-06T16:01:32 <morcos> but i'm suggesting we should consider future input via GetDustThreshold
2672017-07-06T16:01:38 <Murch> instagibbs: I'm concerned that we're overestimating the saved cost
2682017-07-06T16:01:47 <morcos> In addition to current fee rate times size of creating output
2692017-07-06T16:01:50 *** Guyver2_ has joined #bitcoin-core-dev
2702017-07-06T16:01:58 <instagibbs> Murch, explain?
2712017-07-06T16:02:11 <Murch> @instagibbs: Yeah.
2722017-07-06T16:02:21 *** jtimon has joined #bitcoin-core-dev
2732017-07-06T16:03:06 <morcos> I think it's exactly this calculation we should use: https://github.com/bitcoin/bitcoin/pull/10712/files#diff-b2bb174788c7409b671c46ccc86034bdR2762
2742017-07-06T16:03:09 <Murch> So, my experiments for my thesis assumed a fixed fee rate for the whole cycle. This allows me to be sure of the saved cost of "input + output"
2752017-07-06T16:03:53 *** Guyver2 has quit IRC
2762017-07-06T16:04:01 <Murch> Fixed fee rate is not a valid assumption IRL, so it's hard to estimate the saved cost for the input.
2772017-07-06T16:04:02 *** Guyver2_ is now known as Guyver2
2782017-07-06T16:04:20 <Murch> We see frequent changes in fees in a range of factor 50.
2792017-07-06T16:04:43 <instagibbs> Yes, but if fees really do move up on longer-term I don't see why we'd ignore it
2802017-07-06T16:05:05 <Murch> Now, currently there are four implementations of BnB that I'm aware of: My science project, Core, BitcoinJS, and what I'm working on for BitGo right now.
2812017-07-06T16:05:09 <instagibbs> more aggressive non-change making has privacy advantages on top that I don't think we should ignore
2822017-07-06T16:05:48 <morcos> I think we have to distinguish between giving up and generating the change (in which case htere is a cost) and saying ok well this solution isn't close enough that we're willing to just discard the difference
2832017-07-06T16:05:48 <Murch> Karel implementing the BitcoinJS one, has done some more experiments and informed me that just using the "output as cost of change" resulted in lower total fees.
2842017-07-06T16:06:25 <Murch> instagibbs: Smaller window might cause larger input sets, so it might actually work towards that end. It's hard to tell. ;)
2852017-07-06T16:06:26 <instagibbs> Murch, what about how many change outputs are made vs
2862017-07-06T16:06:29 <morcos> and potentially trying again
2872017-07-06T16:06:32 <instagibbs> and how much are you saving
2882017-07-06T16:07:46 <instagibbs> not asking for an answer right here, just think it's important to consider
2892017-07-06T16:07:55 <Murch> instagibbs: I don't know. Maybe I was overestimating that effect myself, as I asked Karel whether the rate dropped significantly by making the window smaller.
2902017-07-06T16:08:05 *** owowo has quit IRC
2912017-07-06T16:08:15 <Murch> instagibbs AFAIU, it didn't though.
2922017-07-06T16:08:19 <morcos> This all depends on assumptions about the distributions of the utxos in the pool. It's going to be different for different people. In some cases making window larger will just cause you to waste money
2932017-07-06T16:08:48 <Murch> instagibbs: Yes definitely need to consider that. Also the average input size and whether it exhausts our smaller inputs too quickly to do later exact matches.
2942017-07-06T16:08:48 <morcos> B/c you would have found a smaller exact match. In other cases a larger window will allow you to find an exact match when you otherwise wouldn't have
2952017-07-06T16:09:00 <morcos> Do we have any good data sets for a large number of users to evaluate this on at all
2962017-07-06T16:09:09 <Murch> morcos "â¦wasting moneyâ¦" exactly.
2972017-07-06T16:09:13 <instagibbs> not public ones
2982017-07-06T16:09:13 <instagibbs> :P
2992017-07-06T16:09:30 <Murch> instagibbs: yep.
3002017-07-06T16:10:31 <Murch> I'm gonna do a little more experiments in the coming week to evaluate the algorithm for our internal use. I also have another project though, so I can't give you a timeline. I might have more information on some point though.
3012017-07-06T16:10:38 <Murch> Can't share the data of course. ;)
3022017-07-06T16:10:45 *** owowo has joined #bitcoin-core-dev
3032017-07-06T16:13:45 <morcos> Does the KnapsackSolver still try to find an exact match if BnB fails?
3042017-07-06T16:13:50 <morcos> Is that worth doing still?
3052017-07-06T16:14:08 <instagibbs> likely not worth it
3062017-07-06T16:14:08 <morcos> I'm just trying to figure out whether we cna assume we'll probably have change if BnB fails
3072017-07-06T16:14:21 <instagibbs> I think we should toss all of that and assume we get change
3082017-07-06T16:14:51 <instagibbs> we can definitely get data for that once we have BnB being used...
3092017-07-06T16:14:54 <morcos> If so, then we definitely at least want to use the current fee rate times the size of the change out put, plus dustthreshold of output size
3102017-07-06T16:15:18 <morcos> Whether we want to do that on a first pass or maybe do two passes or something, I don't know...
3112017-07-06T16:15:53 <instagibbs> "use" in what sense, sorry
3122017-07-06T16:16:09 <morcos> for the cost_of_change
3132017-07-06T16:16:18 <instagibbs> k
3142017-07-06T16:16:48 <instagibbs> remind me what the second term is accomplishing?
3152017-07-06T16:17:05 <morcos> Also I think we need a lot more reasoning about how we intermingle the (BNB, knapsack) ordering with the (MinConf=6, MinConf=1, MinConf=0 (various chain lengths) ..) ordering
3162017-07-06T16:17:13 <instagibbs> just a small window on top?
3172017-07-06T16:17:32 <morcos> You can't create a change output smaller than DustThreshold anyway
3182017-07-06T16:18:03 <instagibbs> I just need to read the branch again, ignore my q
3192017-07-06T16:18:17 <morcos> so if you found a match where once you paid for the fees required to create the change output (at the feerate this tx is using) you only have < dust left for the change, then you'd just eliminate the change later anyway. So why not look for an exact match
3202017-07-06T16:18:34 <instagibbs> yep
3212017-07-06T16:18:50 *** timothy has quit IRC
3222017-07-06T16:18:59 <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/be824984626f...30bc0f672626
3232017-07-06T16:18:59 <bitcoin-git> bitcoin/master b8bb425 Michael Rotarius: REST/RPC example update
3242017-07-06T16:19:00 <bitcoin-git> bitcoin/master 30bc0f6 Wladimir J. van der Laan: Merge #10710: REST/RPC example update...
3252017-07-06T16:19:05 *** timothy has joined #bitcoin-core-dev
3262017-07-06T16:19:32 <bitcoin-git> [bitcoin] laanwj closed pull request #10710: REST/RPC example update (master...docupt) https://github.com/bitcoin/bitcoin/pull/10710
3272017-07-06T16:19:33 <morcos> Right now it looks to me at a cursory glance like we first try using BNB on all of the minConf orderings... So potentially we are going to create a long chain of unconfirmed txs just b/c they don't generate change (luckily that's anti-self-reinfocing)
3282017-07-06T16:20:15 <morcos> That doesn't seem to me necessarily what the user wants? But I don't know what the right order is.
3292017-07-06T16:20:40 <morcos> It would be good if there was a lot more documentation about the logic in that PR. The old code was already way under documented, lets not repeat that mistake
3302017-07-06T16:21:01 <instagibbs> that block of SCMC could have a comment header explaining the steps
3312017-07-06T16:22:05 *** Aaronvan_ has joined #bitcoin-core-dev
3322017-07-06T16:22:41 *** Aaronva__ has joined #bitcoin-core-dev
3332017-07-06T16:24:18 *** AaronvanW has quit IRC
3342017-07-06T16:25:36 *** laurentmt has joined #bitcoin-core-dev
3352017-07-06T16:26:01 *** laurentmt has quit IRC
3362017-07-06T16:26:09 *** Aaronvan_ has quit IRC
3372017-07-06T16:29:37 <Murch> sorry, something came up. I agree that the KnapsackSolver should not try to find an exact match anymore. It's also not good at it anyway.
3382017-07-06T16:32:53 <Murch> In most cases when it would find an exact match, it would throw it out because it can't pay the fees in subsequence.
3392017-07-06T16:55:00 *** Felipe2 has quit IRC
3402017-07-06T16:57:33 <bitcoin-git> [bitcoin] laanwj pushed 37 new commits to 0.14: https://github.com/bitcoin/bitcoin/compare/fc61c8322bd7...91be5e3c1e45
3412017-07-06T16:57:34 <bitcoin-git> bitcoin/0.14 d28d583 Suhas Daftuar: Bugfix: PrioritiseTransaction updates the mempool tx counter...
3422017-07-06T16:57:34 <bitcoin-git> bitcoin/0.14 71463a7 Suhas Daftuar: [qa] Test prioritise_transaction / getblocktemplate interaction...
3432017-07-06T16:57:35 <bitcoin-git> bitcoin/0.14 ef810c4 practicalswift: [trivial] Fix a typo (introduced two days ago) in the default fee warning...
3442017-07-06T17:02:38 *** spudowiar has joined #bitcoin-core-dev
3452017-07-06T17:02:49 <spudowiar> To confirm, UniValues can only be appended to, not modified, right?
3462017-07-06T17:03:59 *** justanotheruser has joined #bitcoin-core-dev
3472017-07-06T17:05:48 *** justanotheruser has quit IRC
3482017-07-06T17:06:11 *** justanotheruser has joined #bitcoin-core-dev
3492017-07-06T17:06:52 *** justan0theruser has quit IRC
3502017-07-06T17:08:44 *** Chris_Stewart_5 has quit IRC
3512017-07-06T17:09:27 *** tiagotrs has quit IRC
3522017-07-06T17:14:14 *** timothy has quit IRC
3532017-07-06T17:17:28 <instagibbs> seems that way
3542017-07-06T17:18:53 <spudowiar> Copying the object to modify it seems wrong
3552017-07-06T17:19:41 <spudowiar> I might copy the function from core_write to CWallet and modify it for my usecase
3562017-07-06T17:20:12 <spudowiar> There are quite a few neat changes I could make then
3572017-07-06T17:22:24 *** stalictite has quit IRC
3582017-07-06T17:26:07 *** stalictite has joined #bitcoin-core-dev
3592017-07-06T17:26:28 *** Aaronva__ has quit IRC
3602017-07-06T17:26:38 *** AaronvanW has joined #bitcoin-core-dev
3612017-07-06T17:31:34 <wumpus> correct - you shouldn't need to edit univalue object, either consume them or generate them
3622017-07-06T17:32:05 <wumpus> they're meant for being used on the interface, not meant as a lasting data representation format
3632017-07-06T17:32:22 *** Chris_Stewart_5 has joined #bitcoin-core-dev
3642017-07-06T17:37:23 *** chjj has joined #bitcoin-core-dev
3652017-07-06T17:38:15 <instagibbs> morcos, interesting to note that a successful BnB on a long chain ends that chain for the user. Once we're using effective value everywhere you can do two quick SelectCoins calls, but then you still have that judgment call of which is better.
3662017-07-06T17:40:25 <morcos> instagibbs: yeah its not obvious to me what the right outcome is, but i think we explicitly need to think about it. I think we'd do better creating change from confirmed outputs before extending a chain, at least until we do something smart with whole chain fee control.
3672017-07-06T17:40:57 <morcos> but for instance we might prefer to create no-change from 1-confirm inputs before creating change from 6-confirm inputs
3682017-07-06T17:41:06 <instagibbs> Indeed that would be better, but I'd still like to revisit BnB if we cant do knapsack w/ confirmed
3692017-07-06T17:41:43 *** donaloconnor has joined #bitcoin-core-dev
3702017-07-06T17:42:27 <instagibbs> Throw-away idea: Let the transaction construction loop happen once, never accept the first result, then you can compare the two,
3712017-07-06T17:43:01 <instagibbs> the first will always fail anyways
3722017-07-06T17:44:17 <morcos> sipa: style ruling please, this time i think i checked developer notes first. If I have a static class member like CWallet::fallbackFee should that be g_fallback_fee or m_fallback_fee?
3732017-07-06T17:45:13 <sipa> not a constant?
3742017-07-06T17:45:54 <morcos> well its a command line argument
3752017-07-06T17:46:19 <sipa> i guess technically that would be a member field, but personally i very much think we should avoid non-const static members, and make them globals instead
3762017-07-06T17:46:52 <wumpus> it's an interesting case
3772017-07-06T17:47:14 <morcos> ok, i'm happy to do that. just global but declared in wallet.h ?
3782017-07-06T17:47:25 <sipa> sounds good to me
3792017-07-06T17:47:30 <wumpus> not convinced a global is better
3802017-07-06T17:47:38 <sipa> static class members effectively are globals
3812017-07-06T17:47:47 <sipa> they're just abusing the class as a namespace
3822017-07-06T17:47:49 <wumpus> at least the class provides some kind of scoping
3832017-07-06T17:47:57 <morcos> thats why my guess was CWallet::g_discard_rate
3842017-07-06T17:47:59 <wumpus> well it's better than throwing everything into the global namespace
3852017-07-06T17:48:19 <sipa> i guess the right approach is to actually have good namespacing
3862017-07-06T17:48:29 <wumpus> sure
3872017-07-06T17:48:52 *** chjj has quit IRC
3882017-07-06T17:48:57 <wumpus> but now it could collide with something e.g. outside of wallet, it's not clear it's for the wallet
3892017-07-06T17:49:06 <wumpus> m_fallback_fee could be anything, also a mempool thing
3902017-07-06T17:49:21 <gmaxwell> Keep in mind that we avoid spending third party unconfirmed inputs for security reasons; and our own for privacy (otherwise the change is immediately distinguishable)
3912017-07-06T17:50:07 <morcos> so what am i doing then?
3922017-07-06T17:50:42 <morcos> the existing similar variables are static class members for now
3932017-07-06T17:50:48 <sipa> if it's a static member variable, call it CWallet::m_fallback_fee
3942017-07-06T17:51:08 <wumpus> better to keep it consistent and make this one too, morcos, I'd say
3952017-07-06T17:51:11 *** RubenSomsen has joined #bitcoin-core-dev
3962017-07-06T17:51:12 <wumpus> and yes call it m_fallback_fee
3972017-07-06T17:51:13 <morcos> ok, i'll do that for now.. if we want to , we can clean up all of them later
3982017-07-06T17:51:17 <sipa> ack
3992017-07-06T17:51:41 <morcos> btw, i think it would be nice to have helper functions for all these command line arguments
4002017-07-06T17:51:51 <sipa> yes...
4012017-07-06T17:52:11 <morcos> so we could sort of declare the argument, its help string, its min and max value, etc.. all in one place
4022017-07-06T17:52:27 <wumpus> we have a PR that improves argument handling IIRC
4032017-07-06T17:52:39 <wumpus> would be nice post-0.15
4042017-07-06T17:57:41 <wumpus> would be nice to finally be able to close #1044
4052017-07-06T17:57:42 <gribble> https://github.com/bitcoin/bitcoin/issues/1044 | Problems with command-line options silently ignored · Issue #1044 · bitcoin/bitcoin · GitHub
4062017-07-06T17:57:57 <sipa> yes...
4072017-07-06T17:58:01 <wumpus> which should be easy if all command line arguments are registered
4082017-07-06T17:58:16 <spudowiar> Yea or nay: Adding a const CWallet& parameter to TxToUniv which adds hdKeypath to your own inputs and the change outputs?
4092017-07-06T17:58:30 <spudowiar> Or should I create a new version of TxToUniv?
4102017-07-06T18:00:42 <instagibbs> I don't think that function has any knowledge of wallet
4112017-07-06T18:01:57 <wumpus> yes it is not a wallet function, core_io etc has no wallet dependency
4122017-07-06T18:02:18 <wumpus> if you need one for the wallet, define your own
4132017-07-06T18:02:30 <spudowiar> instagibbs: Hence adding the const CWallet& parameter :)
4142017-07-06T18:02:48 <sipa> spudowiar: that would make the function dependent on the wallet, which we want to avoid
4152017-07-06T18:02:50 <instagibbs> I more mean it's a layer violation
4162017-07-06T18:02:58 <spudowiar> sipa: Only if you provide the wallet parameter
4172017-07-06T18:03:07 <wumpus> one that takes a CWalletTx, defined in the wallet library
4182017-07-06T18:03:16 <sipa> spudowiar: you don't understanf
4192017-07-06T18:03:16 <morcos> gmaxwell: This is the discard_rate idea: https://github.com/morcos/bitcoin/commit/fd8104a9f074ca588d44defe015b0ace77dbc7fc
4202017-07-06T18:03:20 <wumpus> spudowiar: no, he means a compile-time dependency
4212017-07-06T18:03:27 <spudowiar> Oh, gotcha, sorry :)
4222017-07-06T18:03:29 <spudowiar> I just realised :)
4232017-07-06T18:03:32 <wumpus> spudowiar: core_io etc do not include wallet.h at all ,they don't link against the wallet stuff
4242017-07-06T18:03:39 <spudowiar> I didn't realise it was in bitcoin-common
4252017-07-06T18:03:42 <sipa> spudowiar: if the function takes a wallet argument, it becomes code that cannot exist without the wallet code being present too
4262017-07-06T18:03:57 <morcos> gmaxwell: very simple, but i fear there are too many outstanding other wallet fee PR's to bother with that for now (i built it on top of them since it interacts)
4272017-07-06T18:04:09 <sipa> spudowiar: in general, the wallet is intended to be separated off at some point, and even if it isn't, it's good practices to reduce dependencies between modules
4282017-07-06T18:04:48 <wumpus> anyhow, functionality that should be present when buildilng without the wallet relies on TxToUniv
4292017-07-06T18:04:56 <gmaxwell> morcos: I like.
4302017-07-06T18:05:16 <morcos> instagibbs: Murch: achow101: It's this discard rate idea that I'd use to set your window in BnB as well. In addition to the cost of creating the change at the current fee level.
4312017-07-06T18:06:10 <achow101> discard rate?
4322017-07-06T18:06:19 <achow101> (sorry, I've missed most of the conversation here)
4332017-07-06T18:06:21 <wumpus> cfields: could you take a look at #10508 - it is a tests PR, but involves some small build system changes, would be nice if you could take a look
4342017-07-06T18:06:22 <morcos> See link 10 lines up
4352017-07-06T18:06:22 <gribble> https://github.com/bitcoin/bitcoin/issues/10508 | Run Qt wallet tests on travis by ryanofsky · Pull Request #10508 · bitcoin/bitcoin · GitHub
4362017-07-06T18:06:50 <achow101> ah, ok
4372017-07-06T18:07:22 <cfields> wumpus: grr, i was thinking I was missing a reponse to a build PR, but I couldn't track it down. Sorry. Looking now.
4382017-07-06T18:09:36 <instagibbs> morcos, TLDR: max(min(1008 smart unconservative smart fee, static_discard_rate)), dustRelayFee)
4392017-07-06T18:09:38 *** chjj has joined #bitcoin-core-dev
4402017-07-06T18:10:14 <morcos> instagibbs: yes. GetDustThreshold(^ that)
4412017-07-06T18:12:17 <instagibbs> seems reasonable, user can always protect super-dustRelayFee change if they decide to
4422017-07-06T18:17:44 *** chjj has quit IRC
4432017-07-06T18:17:51 <Murch> morcos: That would be a good price estimate for the input cost of the saved change output.
4442017-07-06T18:19:48 <morcos> Murch: yes that's what i'm saying... and after #10712 its the calculation that is used to say oh wow we're paying way too much fee, lets add change
4452017-07-06T18:19:49 <gribble> https://github.com/bitcoin/bitcoin/issues/10712 | Add change output if necessary to reduce excess fee by morcos · Pull Request #10712 · bitcoin/bitcoin · GitHub
4462017-07-06T18:21:18 <morcos> I'm actually not 100% convinced 10712 is a good idea.. It will lead to a bit more utxo bloat. The true fix is to be smarter about never creating small change which requires effective fee rates.
4472017-07-06T18:25:29 <kanzure> is the sentiment that the 1008 block estimatesmartfee for change output size minimum threshold is a bad thing due to utxo bloat ?
4482017-07-06T18:25:57 <instagibbs> kanzure, right now the wallet is just really bad at targeting good change size outputs or exact matches
4492017-07-06T18:26:01 <instagibbs> so it kind of lands in the middle
4502017-07-06T18:27:08 <kanzure> in another 'wallet' (not core) (it's not a wallet) i was going to ask for two fee rates, one for the non-change outputs and another for an estimation of the minimum size of any possible change output below which to burn to miner fee.
4512017-07-06T18:27:38 <instagibbs> right, that's the above idea
4522017-07-06T18:27:47 <instagibbs> discardRate, where it's ok to drop it
4532017-07-06T18:28:37 <kanzure> if all outputs were required to be multisig p2sh then we could insist that everyone just transfers their change in the same output, and they can worry about spending it later. </joking, not practical>
4542017-07-06T18:30:07 <Murch> morcos: I don't think I have a good overview of what's going on yet, but generally I'd suggest that we aim for clearcut scenarios:
4552017-07-06T18:30:20 <Murch> 1) Try to create no change output (use BnB)
4562017-07-06T18:30:46 <Murch> 2) If fail: Try to create change output greater than min_change
4572017-07-06T18:31:25 <Murch> 3) small number of cases that don't fit in any other bucket: If change output is too small to keep discard.
4582017-07-06T18:31:46 <Murch> [â¦], discard.
4592017-07-06T18:32:02 <morcos> Murch: 100% agree, but the real issue is once we have effective_value we can do both those things. even part 2 requires a good effective value.
4602017-07-06T18:32:25 <Murch> what do you mean with "effective_value"?
4612017-07-06T18:32:34 <kanzure> instagibbs: unfortunately we edge up to this fundamental tradeoff between discardRate, utxo bloat minimization, and folks losing money because small outputs are essentially unspendable (some always, some intermittently). essentially, certain payment amounts-- from certain inputs-- are simply not workable. if 10 more seconds of coin selection computation could solve this for a user, i thi...
4622017-07-06T18:32:40 <kanzure> ...nk that's worth the face value of the output.
4632017-07-06T18:32:58 <morcos> An additionaly issue however is I don't think its the best idea in the world to add tons of inputs that have barely positive effective value when we are payin a high fee rate, but thats possibly a later improvement
4642017-07-06T18:33:29 <Murch> morcos: I think you're worrying too much about utxo bloat. In my simulation, BnB + RandomSelection as fallback had a much lower average UTXO Pool size than Core selection.
4652017-07-06T18:33:56 <Murch> BnB + Core as a fallback should be even smaller.
4662017-07-06T18:34:28 <gmaxwell> I don't think there is any bloat concern on BNB. Thats part of why we're doing it first.
4672017-07-06T18:34:42 <morcos> The big question is how often does BnB find an answer
4682017-07-06T18:34:48 <morcos> I have no insight into that
4692017-07-06T18:34:55 <instagibbs> Murch, could you just do dumb fallback
4702017-07-06T18:35:01 <instagibbs> I think you did right?
4712017-07-06T18:35:37 <Murch> morcos: In my simulation with 12k outgoing payments, I found ~39% exact matches with BnB and ~0.6% with Core.
4722017-07-06T18:35:42 <morcos> If murch's simulation is on a larger than typical spendable utxo set then it may overestimate the benfit we gain from BnB
4732017-07-06T18:35:55 <Murch> morcos: Saying we have no idea, seems a bit of a stretch.
4742017-07-06T18:35:57 <morcos> 12k outgoing payments from what utxo set per payment?
4752017-07-06T18:36:12 <morcos> is each one from the actual utxo set that that payment was made from?
4762017-07-06T18:36:28 <morcos> is that one big utxo set
4772017-07-06T18:36:52 <morcos> sure, i think BnB will make a huge difference for commercial applications with large utxo sets
4782017-07-06T18:36:54 <Murch> morcos: It's a sequence of 36k payments in total, 12k outgoing, 24k incoming.
4792017-07-06T18:37:04 <morcos> but all to the same utxo set?
4802017-07-06T18:37:05 <gmaxwell> morcos: he has a feed of input and output payment amounts simulate the wallet (e.g. how it's utxos evolve over time)
4812017-07-06T18:37:09 <Murch> yes
4822017-07-06T18:37:13 <gmaxwell> its*
4832017-07-06T18:37:17 <morcos> so thats far from typical
4842017-07-06T18:37:36 <sipa> morcos: but perhaps very significant on the overall utxo set
4852017-07-06T18:37:38 <achow101> isn't that dataset from moneypot's payments?
4862017-07-06T18:37:50 <gmaxwell> morcos: well it's actual for at least one user, we don't know how it represents everyone but users like this are a non-trivial amount of the total network behavior.
4872017-07-06T18:37:54 <sipa> morcos: as in, perhaps a large portion of the actual network comes from large player's wallets
4882017-07-06T18:37:56 <morcos> sipa: unknown. what % of utxos belong to a big wallet vs small
4892017-07-06T18:38:04 <sipa> morcos: yes, i don't know either
4902017-07-06T18:38:05 <Murch> I've also consolidated the incoming payments 4 to 1, to make a scenario with 6k incoming payments and 12k outgoing payments. It still did great on UTXO set reduction
4912017-07-06T18:38:24 <Murch> achow101: Yes, the same
4922017-07-06T18:38:27 <morcos> gmaxwell: don't get me wrong. i'm very in favor of doing BnB. its certainly not hurting small wallets
4932017-07-06T18:38:42 <gmaxwell> Im not sure of the thrust of the discussion here, but I do not see how the BnB could be anything worse than a small improvement.
4942017-07-06T18:38:43 <bitcoin-git> [bitcoin] laanwj pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/30bc0f672626...5af657253498
4952017-07-06T18:38:44 <bitcoin-git> bitcoin/master 928c681 Matt Corallo: Use "replaceable" instead of "optintorbf" in createrawtransaction....
4962017-07-06T18:38:44 <bitcoin-git> bitcoin/master fb915d5 Matt Corallo: Use "replaceable" instead of "optIntoRbf" in fundrawtransaction....
4972017-07-06T18:38:45 <bitcoin-git> bitcoin/master 73c942e Matt Corallo: Use "replaceable" instead of "rbfoptin" in bitcoin-tx....
4982017-07-06T18:38:49 <gmaxwell> morcos: okay good!
4992017-07-06T18:38:57 <morcos> all i'm arguing is we can't look at this increase to 39% exact matches and assume its going to have a huge effect on the overall utxo set which is made up of many smaller sets
5002017-07-06T18:39:11 <sipa> morcos: agree - we don't know the impact
5012017-07-06T18:39:11 <bitcoin-git> [bitcoin] laanwj closed pull request #10698: Be consistent in calling transactions "replaceable" for Opt-In RBF (master...2017-06-replaceable-rpc-args) https://github.com/bitcoin/bitcoin/pull/10698
5022017-07-06T18:39:17 <Murch> morcos: Coin selection in a wallet that has significantly more outgoing payments than incoming (i.e. most end-user cases) is trivial.
5032017-07-06T18:39:19 <morcos> so we still have to be worried about utxo bloat in the event BnB fails
5042017-07-06T18:39:22 <gmaxwell> oh sure, I think it's fair to say that we don't know how much of an improvement it will be in aggregate.
5052017-07-06T18:39:25 <morcos> This is what i'm talking about
5062017-07-06T18:39:26 <instagibbs> eh, economic node activity likely follows a power law
5072017-07-06T18:39:37 <gmaxwell> Just that it will do no harm and at least in some cases help a lot.
5082017-07-06T18:39:39 <Murch> morcos: Coin selection in a wallet that has more incoming payments than outgoing should do very well with BnB.
5092017-07-06T18:39:39 <instagibbs> maybe wont matter for small wallets you're right
5102017-07-06T18:39:59 <morcos> balancing users wasting their small utxos when they are getting very little to negative effective value from it vs at some point needing to aggregate those to avoid bloat
5112017-07-06T18:40:06 <morcos> Murch thought i was over worrying about bloat
5122017-07-06T18:40:45 <Murch> morcos: Well, but UTXO set being generally split over more different wallets is not something we can influence on the coinselection level in the first place. That's on the adoption level.
5132017-07-06T18:40:48 <gmaxwell> morcos: well in achow101's implementation he is using (and would switch to exactly) something just like the dustfee metric you just linked to, I don't think we have to worry about waste if using that.
5142017-07-06T18:41:46 <morcos> gmaxwell: the case i'm talking about is if we don't succeed in BnB, then what change do we aim for. We certainly would like to get higher than something governed by the discard rate.
5152017-07-06T18:42:25 <gmaxwell> morcos: okay so BnB is basically unrelated.
5162017-07-06T18:42:27 <instagibbs> I think we're agreeing here. For fallback we should pick something significantly higher if possible
5172017-07-06T18:42:30 <morcos> gmaxwell: yes
5182017-07-06T18:43:05 <Murch> Yeayeah
5192017-07-06T18:43:35 <morcos> while we're on the subject
5202017-07-06T18:44:08 <morcos> gmaxwell and everyone did you see my above question about how (bnb, knapsack) should be intermingled with (selectcoinsminconf (different params))
5212017-07-06T18:44:31 <morcos> at what point do you prefer no change but less confirmations or longer unconfirmed chain
5222017-07-06T18:45:00 <gmaxwell> morcos: yes, I have some agreement though there are privacy implications. We don't spend 6 conf or less from third parties for security reasons. And we try to avoid spending our own at less than 6 conf to avoid blowing up any privacy change has.
5232017-07-06T18:45:06 *** chjj has joined #bitcoin-core-dev
5242017-07-06T18:45:23 <gmaxwell> But I think we should BNB longish chains for example.
5252017-07-06T18:45:36 <gmaxwell> because that ends them.
5262017-07-06T18:45:53 <gmaxwell> but obviously not overlong (24+) ones.
5272017-07-06T18:45:55 <morcos> but not before creating a tx which doesn't spend unconfirmed ?
5282017-07-06T18:46:28 <gmaxwell> OH on this subject. We need to consider the feerate of unconfirmed parents as part of their effective rate.
5292017-07-06T18:46:31 <gmaxwell> And CPFP them.
5302017-07-06T18:46:32 <morcos> actually, maybe it wouldn't be that hard to be kind of smart about it.
5312017-07-06T18:47:00 <morcos> yes , well before that step, you could only consider extending chains which pay a feerate at least as high as the one you are paying
5322017-07-06T18:47:02 <gmaxwell> For example if you managed to make a very low fee payment A, then make payment B with better fee settings. If B spends from A it needs to CPFP A up to B's target feerate.
5332017-07-06T18:47:12 <gmaxwell> Indeed.
5342017-07-06T18:47:45 <gmaxwell> I've seen some users screwed with this FWIW.
5352017-07-06T18:47:46 <morcos> i don't think you'd necessarily want to automatically CPFP a chain if you had other options
5362017-07-06T18:48:05 <gmaxwell> They made a payment with a very low rate shortly after startup, then the next day they made another payment that paid a reasonable rate, but was a child.
5372017-07-06T18:48:19 <instagibbs> you'd need to avoid bumping twice, by detecting if they are cousins in a chain
5382017-07-06T18:48:33 <gmaxwell> I think you might want to automatically CPFP any input that you set the same confirmed target or lower on.
5392017-07-06T18:49:10 <gmaxwell> instagibbs: well they won't be unless we're making multiple change outputs or paying ourselves.... but yes...
5402017-07-06T18:49:39 <gmaxwell> this suggests that perhaps we should be tracking what the fee settings were for those transactions.
5412017-07-06T18:49:44 <morcos> goodness, this is going to get complicated.
5422017-07-06T18:49:49 <gmaxwell> Hurray!
5432017-07-06T18:50:01 <gmaxwell> (this means we're starting to understand all that we don't know about the problem space)
5442017-07-06T18:50:10 <instagibbs> next we need to throw a general purpose optimizer at it
5452017-07-06T18:50:27 <rhavar> pretty sure that's the only sane solution if you want to automatically do CPFP and stuff
5462017-07-06T18:50:34 <gmaxwell> nah.
5472017-07-06T18:50:57 <gmaxwell> Other than having a bunch of conditionals I think this stuff isn't *that* gnarly.
5482017-07-06T18:51:02 <instagibbs> didn't close my statement with /s
5492017-07-06T18:51:49 <gmaxwell> The hurestic would be that you first consider unconfirmeds that either are at the target or higher feerate or at the current target or lower... ... but always CPFP things up to the current destination rate.
5502017-07-06T18:51:59 <gmaxwell> and use the CPFP impact in the EV calculations.
5512017-07-06T18:52:29 <rhavar> I'm not sure it's a horrible idea to just write the whole thing up as a general purpose constrain solving problem
5522017-07-06T18:52:39 <rhavar> and just not include a constrain solver :P
5532017-07-06T18:52:42 <rhavar> have it as a plugin or something
5542017-07-06T18:53:05 <gmaxwell> rhavar: I've done this previously, but the actual solving isn't really that big a deal.
5552017-07-06T18:53:10 *** RubenSomsen has quit IRC
5562017-07-06T18:53:11 <rhavar> For casual wallet users, they're only going to have a couple of inputs and outputs -- you can pretty much brute force the space
5572017-07-06T18:53:36 <rhavar> And for commercial users, they can actually install some shared object plugin that calls out to a proper library
5582017-07-06T18:54:02 <gmaxwell> it's not magic in any case.
5592017-07-06T18:54:35 <rhavar> That's what I'm doing right at this moment, I pretty much brute force solutions with a cost metric
5602017-07-06T18:54:42 <gmaxwell> I think there is a AMSL statement of a toy coinselection problem that I wrote floating around out there somewhere.
5612017-07-06T18:54:44 <rhavar> and it does a *decent* job
5622017-07-06T18:55:20 <rhavar> I'll have a robust minizinc implementation pretty soon, if anyones interested
5632017-07-06T18:55:21 <gmaxwell> rhavar: sure and thats what it does internally, it's just using a different cost design than you. (A dumb one that is optimizing under assumptions like addresses are never reused) :)
5642017-07-06T18:56:24 <gmaxwell> unfortunately, last I checked there are no sutable solvers that we can distribute... but I wouldn't have any issue with having an interface to call out to something.
5652017-07-06T18:56:33 <rhavar> I guess what I mean, is if you actually support loading a .so plugin or something -- you can pretty much not worry about it
5662017-07-06T18:57:08 <gmaxwell> rhavar: except like, you know, we need to worry about that 99% of users (including commercial ones) that aren't going to solve this for themselves, and not better than we will. :)
5672017-07-06T18:57:25 <morcos> also the magic is in the metric isn't it
5682017-07-06T18:57:25 <gmaxwell> but no issue supporting loadable things for people who want them.
5692017-07-06T18:57:55 <rhavar> This is the cost function I use: https://gist.github.com/RHavar/0710144c713033d42f8f443a99fefbb7
5702017-07-06T18:58:03 <rhavar> I think it makes perfect sense for casual users too
5712017-07-06T18:58:17 <rhavar> Just instead of using a proper constrain solver, they can use a brute forcer
5722017-07-06T18:58:25 <rhavar> which is pretty trivial to write
5732017-07-06T18:58:29 <jtimon> meeting?
5742017-07-06T18:58:41 <sipa> soon!
5752017-07-06T18:59:18 <gmaxwell> rhavar: you perhaps overestimate how far you can go with bruteforce... :P once you have more than two dozen inputs it starts becoming intractable.
5762017-07-06T18:59:31 <gmaxwell> (and my wallets have a lot more than two dozen inputs, and I'm just some guy)
5772017-07-06T19:00:04 <rhavar> I'm using a brute force search with ~2k inputs right now, and it does a *decent* job
5782017-07-06T19:00:17 <rhavar> not perfect though, that's why I'm paying for the minizinc impl
5792017-07-06T19:00:37 <rhavar> (I obviously don't search the entire space, I time out after 10 minutes)
5802017-07-06T19:00:44 <wumpus> #startmeeting
5812017-07-06T19:00:44 <lightningbot> Meeting started Thu Jul 6 19:00:44 2017 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
5822017-07-06T19:00:44 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
5832017-07-06T19:00:51 <gmaxwell> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier
5842017-07-06T19:00:56 <jonasschnelli> proposed topic: multiwallet endpoint vs json item
5852017-07-06T19:00:56 <sipa> LO
5862017-07-06T19:00:56 <wumpus> topics?
5872017-07-06T19:01:01 <achow101> hi
5882017-07-06T19:01:04 <cfields> hi
5892017-07-06T19:01:10 <kanzure> hi.
5902017-07-06T19:01:15 <wumpus> jonasschnelli: yeah, apparently we have to discuss that again, with all the competing PRs
5912017-07-06T19:01:22 <jonasschnelli> heh. Yes
5922017-07-06T19:01:29 <wumpus> jonasschnelli: though in principle we settled on endpoint a few weeks ago
5932017-07-06T19:01:31 <morcos> begging for review... lots of fee/wallet/estimate stuff that needs to make 0.15
5942017-07-06T19:01:41 <morcos> i already have 3 on high priority... sheepish grin
5952017-07-06T19:01:53 <wumpus> yes, high priority for review will as usual be first topic
5962017-07-06T19:01:54 <gmaxwell> morcos: We should do the things.
5972017-07-06T19:01:55 <jonasschnelli> We set endpoints, but some where also in favor of the JSON item solution
5982017-07-06T19:02:01 <wumpus> #topic high priority for review
5992017-07-06T19:02:04 <BlueMatt> PSA: if you're running master, be very careful not to swap -txindex on your db: the check to prevent you from doing so is broken and you could corrupt your chainstate
6002017-07-06T19:02:17 <wumpus> https://github.com/bitcoin/bitcoin/projects/8
6012017-07-06T19:02:29 <gmaxwell> by swap txindex he means turn it on/off on an already running node.
6022017-07-06T19:02:40 *** chjj has quit IRC
6032017-07-06T19:02:44 <jonasschnelli> I'll remove my #10240 from the list for now
6042017-07-06T19:02:46 <instagibbs> good to know...
6052017-07-06T19:02:47 <wumpus> without a reindex-chainstate I guess
6062017-07-06T19:02:49 <sipa> gmaxwell: you mean already created db?
6072017-07-06T19:02:50 <gribble> https://github.com/bitcoin/bitcoin/issues/10240 | Add HD wallet auto-restore functionality by jonasschnelli · Pull Request #10240 · bitcoin/bitcoin · GitHub
6082017-07-06T19:03:01 <wumpus> jonasschnelli: ok
6092017-07-06T19:03:22 <jonasschnelli> It's to big and will re-focus during early 0.16
6102017-07-06T19:03:27 <jtimon> maybe put #8498 in project 8 ?
6112017-07-06T19:03:30 <gribble> https://github.com/bitcoin/bitcoin/issues/8498 | Near-Bugfix: Optimization: Minimize the number of times it is checked that no money... by jtimon · Pull Request #8498 · bitcoin/bitcoin · GitHub
6122017-07-06T19:03:33 <luke-jr> wumpus: the arguments for endpoint seem strong IMO
6132017-07-06T19:03:38 <instagibbs> morcos, doesn;t help that they're an unconfirmed chain of PRs :)
6142017-07-06T19:04:06 <morcos> instagibbs: i know! :) high priority review ones arent though
6152017-07-06T19:04:07 <sipa> we need a chain length limit on PRs
6162017-07-06T19:04:08 <luke-jr> guess we're not on that topic yet
6172017-07-06T19:04:11 <wumpus> jtimon: is that high priority to get into 0.15?
6182017-07-06T19:04:17 <wumpus> luke-jr: next topic
6192017-07-06T19:04:25 <BlueMatt> wumpus: I think 10179 is ready(ish) for a merge, which makes my high-prio of 10652 cleaner
6202017-07-06T19:04:49 <jtimon> wumpus: I haven't benchmarked, but it's an optimization and now also a "near bugfix"
6212017-07-06T19:04:56 <morcos> BlueMatt: i was just rereviewing that, but don't wait on me, i'm out of sync these days and doing all posthumous review
6222017-07-06T19:05:51 <wumpus> BlueMatt: agree
6232017-07-06T19:06:16 <sipa> #10179
6242017-07-06T19:06:19 <gribble> https://github.com/bitcoin/bitcoin/issues/10179 | Give CValidationInterface Support for calling notifications on the CScheduler Thread by TheBlueMatt · Pull Request #10179 · bitcoin/bitcoin · GitHub
6252017-07-06T19:07:13 <BlueMatt> yes, second PSA: never shy away from postumous review! the feeling that its not contributing to moving things forward is wrong, if you think something got merged without enough acks, just review it!
6262017-07-06T19:07:27 <morcos> or if you want to be sure to understand the new code!
6272017-07-06T19:07:32 <BlueMatt> well, that too
6282017-07-06T19:07:44 <Murch> Or if you want to understand the code in the first place! :)
6292017-07-06T19:08:21 <wumpus> :)
6302017-07-06T19:08:51 <wumpus> ok, so anything that needs to be added to project 8?
6312017-07-06T19:09:15 <morcos> i have other things needed for 0.15, but they are dependent on the ones i already have in 8
6322017-07-06T19:09:28 <morcos> also i already have 3
6332017-07-06T19:09:28 <wumpus> ok, just tag them for 0.15 then, don't need to be in that project
6342017-07-06T19:09:36 <wumpus> #topic RPC interface for multiwallet (again)
6352017-07-06T19:09:36 <jtimon> wumpus: doesn't that qualify for priority?
6362017-07-06T19:09:55 <instagibbs> can someone give an overview of what people are thinking on interface for multiwallet... i missed this
6372017-07-06T19:09:56 <wumpus> jtimon: if the gain is unclear, I don't think so
6382017-07-06T19:09:57 <jonasschnelli> Again we should decide wether we use Endpoints of JSON objects for multiwallet switch... helps to continue on PRs
6392017-07-06T19:10:05 <wumpus> instagibbs: please read the current PRs:
6402017-07-06T19:10:08 <sipa> wumpus: can we have #10571 #10579 in 0.15?
6412017-07-06T19:10:09 <gribble> https://github.com/bitcoin/bitcoin/issues/10571 | [RPC]Move transaction combining from signrawtransaction to new RPC by achow101 · Pull Request #10571 · bitcoin/bitcoin · GitHub
6422017-07-06T19:10:10 <gribble> https://github.com/bitcoin/bitcoin/issues/10579 | [RPC] Split signrawtransaction into wallet and non-wallet RPC command by achow101 · Pull Request #10579 · bitcoin/bitcoin · GitHub
6432017-07-06T19:10:10 <jonasschnelli> The JSON object is simpler... less impect
6442017-07-06T19:10:10 <jtimon> wumpus: I think it's clearly a gain
6452017-07-06T19:10:36 <jonasschnelli> the endpoint approach may allow more in future...
6462017-07-06T19:11:02 <jtimon> I don't understand the criterion then
6472017-07-06T19:11:16 <wumpus> #10650 #10653
6482017-07-06T19:11:17 <jonasschnelli> In the JSON object approach (where you choose the wallet bases on a JSON array item), I don't like that the actual switch in in the JSON layer.
6492017-07-06T19:11:17 <gribble> https://github.com/bitcoin/bitcoin/issues/10650 | Multiwallet: add RPC endpoint support by jonasschnelli · Pull Request #10650 · bitcoin/bitcoin · GitHub
6502017-07-06T19:11:18 *** str4d has joined #bitcoin-core-dev
6512017-07-06T19:11:18 <gribble> https://github.com/bitcoin/bitcoin/issues/10653 | Simple, backwards compatible RPC multiwallet support by ryanofsky · Pull Request #10653 · bitcoin/bitcoin · GitHub
6522017-07-06T19:11:26 <luke-jr> I like the JSON interface, but I worry that when we split out the wallet it will break
6532017-07-06T19:11:29 <instagibbs> wumpus, add those to multiwallet project?
6542017-07-06T19:11:35 <wumpus> #10650
6552017-07-06T19:11:36 <jonasschnelli> It also only works with the new named based argumenst
6562017-07-06T19:11:36 <gribble> https://github.com/bitcoin/bitcoin/issues/10650 | Multiwallet: add RPC endpoint support by jonasschnelli · Pull Request #10650 · bitcoin/bitcoin · GitHub
6572017-07-06T19:11:40 <wumpus> eh what's the third one?
6582017-07-06T19:12:00 <luke-jr> endpoints seemed okay, until the API bump got tacked on..
6592017-07-06T19:12:02 <jonasschnelli> I guess the third one (based on Auth) has already been "rejected"? right?
6602017-07-06T19:12:08 <wumpus> I don't like the JSON based interface, having to add an optional wallet argument on every wallet call is easy to forget
6612017-07-06T19:12:14 <ryanofsky> #10661 works with positional arguments, not just named arguments
6622017-07-06T19:12:15 <gribble> https://github.com/bitcoin/bitcoin/issues/10661 | Add optional wallet=filename arguments to wallet RPCs by ryanofsky · Pull Request #10661 · bitcoin/bitcoin · GitHub
6632017-07-06T19:12:21 <wumpus> and if you forget it it defaults to the 'default wallet'
6642017-07-06T19:12:26 <wumpus> that's just too easy to mess up
6652017-07-06T19:12:38 <jonasschnelli> ryanofsky: thanks for clearing this up... wasn't aware, sry
6662017-07-06T19:12:40 <wumpus> the endpoint makes sure you can be connected to only one wallet with one RPC connection
6672017-07-06T19:12:49 <wumpus> jonasschnelli: right!
6682017-07-06T19:12:54 <ryanofsky> i think we should just get rid of the concept of default wallet
6692017-07-06T19:13:04 <wumpus> ryanofsky: on the long run, yes, but that's no option for 0.15
6702017-07-06T19:13:05 <luke-jr> ryanofsky: definitely not in 0.15
6712017-07-06T19:13:13 <kanzure> what about, if more than one wallet, then default wallet must be explicitly specified
6722017-07-06T19:13:17 <ryanofsky> if there's more than one wallet, it should just be an error not to specify a wallet
6732017-07-06T19:13:20 <wumpus> let's focus on what we want to do now
6742017-07-06T19:13:30 <luke-jr> then you break all existing sw
6752017-07-06T19:13:31 <wumpus> I think for 0.15 we should simply do the endpoint-based interface
6762017-07-06T19:13:34 <ryanofsky> we can do that right now
6772017-07-06T19:13:36 <gmaxwell> wumpus: what do you think about the concern that the endpoint stuff establishes a new API that we'll be stuck supporting but haven't given much thought to?
6782017-07-06T19:13:37 <ryanofsky> no need to wait
6792017-07-06T19:13:52 <sipa> i think as an end goal, endpoint-based selection is awesome, because it prepares for process separation
6802017-07-06T19:13:53 <wumpus> gmaxwell: the same is true for any RPC change
6812017-07-06T19:13:56 <jonasschnelli> gmaxwell: we can mark it unstable?
6822017-07-06T19:14:00 <jonasschnelli> v1 == unstable?
6832017-07-06T19:14:09 <jonasschnelli> use / (v0) if you want stability
6842017-07-06T19:14:15 <sipa> but if endpoints can't for example remove the non-wallet RPCs, that's sort of not really achieving that goal anyway
6852017-07-06T19:14:18 <wumpus> gmaxwell: adding an argument to every wallet RPC call is also such a massive change
6862017-07-06T19:14:29 <sipa> wumpus: with named args it's trivial, no?
6872017-07-06T19:14:41 <jonasschnelli> I can work on splitting the RPC calls in wallet / nonwallet
6882017-07-06T19:14:47 <gmaxwell> (I don't have strong opinions, just raising it)
6892017-07-06T19:14:48 <jonasschnelli> if we agree on endpoints
6902017-07-06T19:14:50 *** chjj has joined #bitcoin-core-dev
6912017-07-06T19:14:51 <ryanofsky> wumpus, are you saying 10661 is a massive change?
6922017-07-06T19:14:51 <sipa> and it shouldn't be adding it to every RPC; just catch it in the rpc handler
6932017-07-06T19:14:55 <wumpus> but the point is that it'd be something that has to be supported virtually forever
6942017-07-06T19:14:58 <luke-jr> (only supporting the default wallet, per rpcauth user, seems the best for backward/forward compatibility still)
6952017-07-06T19:14:59 <wumpus> and imo it's poorly thought out
6962017-07-06T19:15:16 <wumpus> but I don't care deeply
6972017-07-06T19:15:21 <wumpus> at this point we should simply make a choice
6982017-07-06T19:15:25 <wumpus> if we don't make a choice today and stick with it
6992017-07-06T19:15:26 <gmaxwell> I don't really think named arguments is a great thing. It would make support easier in some software in the short term.
7002017-07-06T19:15:30 <wumpus> we can forget multiwallet for 0.15
7012017-07-06T19:15:36 <jonasschnelli> ack!
7022017-07-06T19:15:36 <gmaxwell> I think every criticism wumpus has on that one is spot on.
7032017-07-06T19:15:44 *** str4d has quit IRC
7042017-07-06T19:15:56 * luke-jr suggests rpcauth-based default wallet, and we can figure out endpoints for 0.16
7052017-07-06T19:16:18 <wumpus> gmaxwell: indeed - most RPC client libraries don't even support named arguments yet
7062017-07-06T19:16:22 <luke-jr> that gives more time to think out API change
7072017-07-06T19:16:25 <wumpus> gmaxwell: while changing the endpoint is easy, just change the URI
7082017-07-06T19:16:48 <wumpus> luke-jr: please don't bring back a third option
7092017-07-06T19:16:52 * BlueMatt always kinda assumed named args would allow us to add things like multiwallet/different number precision/etc in the future, as a simple add-on to every RPC without any massive code change everywhere
7102017-07-06T19:16:53 <wumpus> luke-jr: that's not going to make it easier
7112017-07-06T19:16:54 <BlueMatt> but, ok
7122017-07-06T19:16:59 <kanzure> luke-jr: are wallets assigned per rpcauth user already?
7132017-07-06T19:17:07 <jonasschnelli> no
7142017-07-06T19:17:10 <wumpus> no
7152017-07-06T19:17:12 <kanzure> uh..
7162017-07-06T19:17:26 <BlueMatt> guess I had a different impression than everyone else, then
7172017-07-06T19:17:26 <luke-jr> kanzure: there is no way to use multiwallet right now
7182017-07-06T19:17:47 <wumpus> BlueMatt: it's possible, and not hard to implement, but just not the right choice for this IMO
7192017-07-06T19:17:56 <jonasschnelli> What about using v1/wallet/y<filename> and mark it unstable (experimental?) for 0.15?
7202017-07-06T19:17:59 <ryanofsky> BlueMatt, that was my impression too, it's the basis for 10661 & 10653
7212017-07-06T19:18:00 <jonasschnelli> -y
7222017-07-06T19:18:05 <sipa> i officially no longer have an opibion on approach
7232017-07-06T19:18:07 <wumpus> jonasschnelli: sounds good to me
7242017-07-06T19:18:10 <BlueMatt> ok, I mean I dont have a very strong impression, i just always thought that seemed natural
7252017-07-06T19:18:18 <luke-jr> wumpus: we should have a per-user default wallet *regardless* of the other options; merging it first is a clean way to defer choosing between the others
7262017-07-06T19:18:20 <BlueMatt> but, really, can we flip a coin?
7272017-07-06T19:18:32 <sipa>
7282017-07-06T19:18:38 <wumpus> let's just go with endpoints for now
7292017-07-06T19:18:55 <jonasschnelli> Somone disagree?
7302017-07-06T19:18:57 <midnightmagic> how the heck did you send a blank line
7312017-07-06T19:18:59 <jonasschnelli> Anyone
7322017-07-06T19:19:01 <gmaxwell> I think we could say that the endpoint version totally unstable and will change to answer the concern that we're setting an api there premately.
7332017-07-06T19:19:04 <wumpus> if no one cares deeply, let's just stick with the decision of a few weeks ago
7342017-07-06T19:19:25 <instagibbs> gmaxwell, ack
7352017-07-06T19:19:29 <jonasschnelli> gmaxwell: we could mark the whole multiwallet (incl. endpoint) as experimental in 0.15
7362017-07-06T19:19:33 <jonasschnelli> And stable in 0.16
7372017-07-06T19:19:34 <wumpus> midnightmagic: that wasn't a blank line, it as \x7f characters
7382017-07-06T19:19:42 <wumpus> gmaxwell: yes, multiwallet is unstable in 0.15, +1
7392017-07-06T19:19:51 <wumpus> gmaxwell: there's probably quite some things that need to change, still
7402017-07-06T19:19:58 <morcos> no opinon on the issue, but ACK on making a decision.
7412017-07-06T19:20:17 <jonasschnelli> ryanofsky: could you live with the endpoint solution?
7422017-07-06T19:20:43 <gmaxwell> I think in general we should get into a practice of new API's being explicitly unstable in their first release. We've mulliganed quite a few times.
7432017-07-06T19:20:53 <wumpus> gmaxwell: yes
7442017-07-06T19:20:53 <ryanofsky> of course, yeah
7452017-07-06T19:21:13 <jonasschnelli> okay. Let me finish the endpoint PR and hope it will make it into 0.15
7462017-07-06T19:21:18 <wumpus> jonasschnelli: great!
7472017-07-06T19:21:33 <jonasschnelli> /topic
7482017-07-06T19:21:40 <wumpus> ryanofsky: thanks
7492017-07-06T19:21:59 <luke-jr> jonasschnelli: can you do it on top of 7b73f24311639fdc79c22608c21e4bfcbc6d4243 ?
7502017-07-06T19:22:06 <jonasschnelli> pr #?
7512017-07-06T19:22:08 <wumpus> any other topics?
7522017-07-06T19:22:48 *** annanay25 has quit IRC
7532017-07-06T19:22:53 <wumpus> remember morcos was saying something about fee PRs, but not sure it was aimed as a topic
7542017-07-06T19:22:56 *** annanay25 has joined #bitcoin-core-dev
7552017-07-06T19:22:56 <sipa> wifi just fied in the BS office
7562017-07-06T19:22:58 <luke-jr> jonasschnelli: it's part of #10615
7572017-07-06T19:22:59 <gmaxwell> I just want to say that master continues to be mostly awesome and performing great. I'm really excited about this next release. (esp if we get our act togeather on multiwallet) :)
7582017-07-06T19:23:00 <gribble> https://github.com/bitcoin/bitcoin/issues/10615 | RPC: Allow rpcauth configs to specify a 4th parameter naming a specific wallet (multiwallet RPC support) by luke-jr · Pull Request #10615 · bitcoin/bitcoin · GitHub
7592017-07-06T19:23:11 <luke-jr> https://github.com/bitcoin/bitcoin/pull/10615/commits/7b73f24311639fdc79c22608c21e4bfcbc6d4243
7602017-07-06T19:23:13 <wumpus> gmaxwell: yeah!
7612017-07-06T19:23:15 <jonasschnelli> luke-jr: 7b73f24311639fdc79c22608c21e4bfcbc6d4243 pollutes server.h with CWallet... :/
7622017-07-06T19:23:18 <jonasschnelli> (later)
7632017-07-06T19:23:29 <BlueMatt> there are a bunch of fee PRs which I think are very useful, and we should try desperately to make progress on them for 15
7642017-07-06T19:23:34 <gmaxwell> So yes, there are a number of fee/change handling PRs which are urgent for 0.15.
7652017-07-06T19:23:38 <morcos> yeah i don't really have a topic, but i need some review
7662017-07-06T19:23:42 <morcos> some are bug fixes
7672017-07-06T19:23:47 <gmaxwell> But I don't know what to say beyond that since they're already on the high prio list.
7682017-07-06T19:23:48 <wumpus> #topic fee PRs
7692017-07-06T19:23:53 <morcos> some are RPC api finalization which would be good to get right
7702017-07-06T19:24:03 <jonasschnelli> another topic proposal could be: txoutsbyaddress (it's marked with the 0.15 milestone)
7712017-07-06T19:24:38 <morcos> I'm not sure if I broke it up in the easiest way possible for review, but am hesitant to try to reorganize this late in the game...
7722017-07-06T19:24:42 <wumpus> jonasschnelli: bleh, server.h should definitely not get a CWallet reference, it's meant to be not specific to bitcoin, let alone wallet
7732017-07-06T19:25:02 <jonasschnelli> wumpus: yes. I think the same
7742017-07-06T19:25:16 <luke-jr> wumpus: jonasschnelli: I don't see a better alternative.
7752017-07-06T19:25:43 <morcos> sounds like jonasschnelli also has his hands full with multiwallet and i think it would have been nice to get access to longer fee estimates in the GUI
7762017-07-06T19:25:44 <luke-jr> (keep in mind not all calls will come from the RPC server)
7772017-07-06T19:25:48 <morcos> but seems like that is not going to happen
7782017-07-06T19:25:52 <jonasschnelli> luke-jr: https://github.com/bitcoin/bitcoin/pull/10650/files#diff-df7d84ff2f53fcb2a0dc15a3a51e55ceR36
7792017-07-06T19:26:00 <wumpus> luke-jr: there are certainly alternatives, more general ways to attach custom data to a structure, but let's leave this for another time
7802017-07-06T19:26:06 <gmaxwell> morcos: oh the gui doesn't have access to the new estimates? thats unfortunate.
7812017-07-06T19:26:14 <gmaxwell> I guess I need to do some gui testing, haven't used it in a while.
7822017-07-06T19:26:16 <morcos> gmaxwell: no
7832017-07-06T19:26:16 <bitcoin-git> [bitcoin] ryanofsky closed pull request #10661: Add optional wallet=filename arguments to wallet RPCs (master...pr/multiopt) https://github.com/bitcoin/bitcoin/pull/10661
7842017-07-06T19:26:23 <jonasschnelli> gmaxwell: just not the conf target > 26+
7852017-07-06T19:26:27 <luke-jr> jonasschnelli: that doesn't work for GUI or tests
7862017-07-06T19:26:35 <morcos> no way to ask for non-conservative. but at least after one of my PR's it'll default to that if tx is replaceable
7872017-07-06T19:26:39 <luke-jr> anyhow, later..
7882017-07-06T19:26:57 <jonasschnelli> non-conservative would be simple (a checkbox?)
7892017-07-06T19:27:15 <jonasschnelli> a slider with fix positions make little sense... sliders are ment to be linear
7902017-07-06T19:27:22 <jonasschnelli> A dropdown could make more sense
7912017-07-06T19:27:26 * luke-jr likes dropdown
7922017-07-06T19:27:30 <morcos> jonasschnelli: yes sort of. the way it is implemented elsewhere is it defaults to the opposite of opt in rbf, but you coudl force it either way
7932017-07-06T19:27:43 <luke-jr> "ASAP", "today", "this week", "eventually"
7942017-07-06T19:28:05 <jonasschnelli> luke-jr: names tend to bikeshed... but at least "conf-target in block | time"
7952017-07-06T19:28:13 * luke-jr shrugs
7962017-07-06T19:28:31 <jonasschnelli> Or maybe "time | blocks |Â feerate"
7972017-07-06T19:28:52 <jonasschnelli> Ideally we would run coinselection when opening the dropdown to tell the (possible) absolute fee
7982017-07-06T19:29:03 <morcos> jonasschnelli: please no
7992017-07-06T19:29:08 <morcos> feerate selection first
8002017-07-06T19:29:12 <morcos> then coin selection
8012017-07-06T19:29:14 <jonasschnelli> heh.. I though somebody will complain. :)
8022017-07-06T19:29:18 <achow101> coin selection needs fee rate..
8032017-07-06T19:29:20 <gmaxwell> we can't realistically do that. We need the feerate to perform selection.
8042017-07-06T19:29:32 <morcos> in the future coin selection may be different depending on feerate anyway
8052017-07-06T19:29:38 <gmaxwell> (and will need it more in the future)
8062017-07-06T19:29:39 <jonasschnelli> gmaxwell: do it for all options ... *duck*
8072017-07-06T19:29:48 <luke-jr> >_<
8082017-07-06T19:29:59 <luke-jr> coin selection can be slow, unless that's been optimised
8092017-07-06T19:30:00 <jonasschnelli> Thoughs about the dropbox?
8102017-07-06T19:30:10 <sipa> "The next Bitcoin-Qt version requires a 4k screen for coin selection"
8112017-07-06T19:30:14 <morcos> in any case, i think _something_ simple would be ideal so users have access to longer than 25 confirms
8122017-07-06T19:30:15 <BlueMatt> lol
8132017-07-06T19:30:17 <gmaxwell> jonasschnelli: well we'd like to be able to do good selections which won't be instant. thats something that could be expiremented with later.
8142017-07-06T19:30:18 <jonasschnelli> I'm happy to do it if it's general accaptable (the dropbown)
8152017-07-06T19:30:21 <BlueMatt> sipa: ooo, I have those, sounds gogod!
8162017-07-06T19:30:23 <BlueMatt> good
8172017-07-06T19:31:08 <gmaxwell> well we do want multiple near term options because of market effects. e.g. 2,3,4,5,6,72,today,two days, three days, five days, 1 week... or something.
8182017-07-06T19:31:17 <jtimon> what about a box with number of blocks instead of a dropbox ?
8192017-07-06T19:31:26 <morcos> jonasschnelli: sure. something, anything. but recommend you build off my other PR #10706
8202017-07-06T19:31:27 <gribble> https://github.com/bitcoin/bitcoin/issues/10706 | Improve wallet fee logic and fix GUI bugs by morcos · Pull Request #10706 · bitcoin/bitcoin · GitHub
8212017-07-06T19:31:29 <jonasschnelli> I'll try the dropdown and see how it feels.. should not be that hard
8222017-07-06T19:31:31 <jtimon> er dropdown
8232017-07-06T19:31:34 <jonasschnelli> morcos: will do
8242017-07-06T19:31:35 <sipa> do we have to do GUI design in this meeting?
8252017-07-06T19:31:43 <luke-jr> XD
8262017-07-06T19:31:50 <Murch> gmawell, it could estimate with a blocktarget of ~6 and do that before the window opens? ;)
8272017-07-06T19:31:52 <morcos> no i was just hoping for someone else to volunteer since seems jonas has a lot to do
8282017-07-06T19:32:11 <Murch> or whatever the default is nowaays
8292017-07-06T19:32:14 <morcos> and 0.15 is fast approaching
8302017-07-06T19:32:16 <gmaxwell> sipa: that wasn't GUI design, quite the opposite, there are economic reasons that gui clumping people wouldn't be great.
8312017-07-06T19:32:19 <luke-jr> I could give it a shot, I guess.
8322017-07-06T19:32:44 <jonasschnelli> luke-jr: I just started... :)
8332017-07-06T19:32:50 <luke-jr> heh
8342017-07-06T19:32:57 <morcos> either or, i'll let you guys work it out, but i'm bad at gUI, but i did make several changes already in the prior PR. thanks!!
8352017-07-06T19:33:50 <wumpus> #topic txoutsbyaddress (it's marked with the 0.15 milestone)
8362017-07-06T19:33:55 <wumpus> I think we should remove that milestone
8372017-07-06T19:34:06 <gmaxwell> Sadly. Has anyone been working on it?
8382017-07-06T19:34:12 <wumpus> #9806 has been quite inactive
8392017-07-06T19:34:14 <gribble> https://github.com/bitcoin/bitcoin/issues/9806 | txoutsbyaddress index (take 3) by droark · Pull Request #9806 · bitcoin/bitcoin · GitHub
8402017-07-06T19:34:15 <jonasschnelli> I'm more interested about should we or or not add an index for that
8412017-07-06T19:34:24 <wumpus> not publicly at least
8422017-07-06T19:34:37 <jonasschnelli> The best index implementations is currently the one from Bitpay,.. not?
8432017-07-06T19:34:43 <gmaxwell> jonasschnelli: I think we should; unlike many other things it's actually sustainable.
8442017-07-06T19:34:59 <jonasschnelli> I tend to also think we should
8452017-07-06T19:35:01 *** chjj has quit IRC
8462017-07-06T19:35:06 <jonasschnelli> (after installed a BWS index)
8472017-07-06T19:35:08 <gmaxwell> the bitpay index stuff is utterly unmaintable and borderline abandonware; fwiw.
8482017-07-06T19:35:21 <jtimon> why not by scriptpubkey ? that seems more generic
8492017-07-06T19:35:25 <sipa> there is some indexd project
8502017-07-06T19:35:30 <jonasschnelli> The most stables index I could find so far is that one: https://github.com/bitcoin/bitcoin/pull/10370
8512017-07-06T19:35:36 <gmaxwell> jtimon: yes, I think that was suggested on the PR.
8522017-07-06T19:35:42 <instagibbs> dcousens has an external index project which I think sipa is referring to
8532017-07-06T19:35:50 <jonasschnelli> (it's the one BWS [Bitpay wallet service] is unsing in the fileld since a couple of years)
8542017-07-06T19:36:27 <gmaxwell> jonasschnelli: the UTXO indexes are special because they actually have viable scalablity...
8552017-07-06T19:36:43 <sipa> https://github.com/bitcoinjs/indexd
8562017-07-06T19:36:48 <gmaxwell> I think anyone depending on complete blockchain indexes will eventually be forced onto centeralized servers, unfortunately.
8572017-07-06T19:37:02 <gmaxwell> so I have much less interest in internal support (hooks for external things sound fine though)
8582017-07-06T19:37:44 <jonasschnelli> Agree. Maybe internal txoutsbyaddress and for the rest, use something like indexd that sipa mentioned
8592017-07-06T19:38:08 <instagibbs> https://github.com/bitcoinjs/indexd
8602017-07-06T19:38:09 <wumpus> UTXO indexes would be nice, I'd love to have more query functionality for the UTXO set, we have to track that anyway with a full node
8612017-07-06T19:38:14 <jcorgan> i've taken to using zmq to notify of new txes/blocks and the REST API to retrieve parsed info about them, for indexing externally
8622017-07-06T19:38:25 <morcos> I've got to run, but someone please tag #10557 #10589 #10707 #10712 for 0.15
8632017-07-06T19:38:26 <gribble> https://github.com/bitcoin/bitcoin/issues/10557 | Make check to distinguish between orphan txs and old txs more efficient. by morcos · Pull Request #10557 · bitcoin/bitcoin · GitHub
8642017-07-06T19:38:27 <jonasschnelli> I guess one reason why some of the centralized services (like the BWS) still is based on 0.12.1 is because the indexes where never added to Core master branch
8652017-07-06T19:38:28 <gribble> https://github.com/bitcoin/bitcoin/issues/10589 | More economical fee estimates for RBF and RPC options to control by morcos · Pull Request #10589 · bitcoin/bitcoin · GitHub
8662017-07-06T19:38:29 <gribble> https://github.com/bitcoin/bitcoin/issues/10707 | Better API for estimatesmartfee RPC by morcos · Pull Request #10707 · bitcoin/bitcoin · GitHub
8672017-07-06T19:38:30 <gribble> https://github.com/bitcoin/bitcoin/issues/10712 | Add change output if necessary to reduce excess fee by morcos · Pull Request #10712 · bitcoin/bitcoin · GitHub
8682017-07-06T19:39:06 <wumpus> huh what is gribble doing
8692017-07-06T19:39:12 <gmaxwell> wumpus: right. also if ever we support having pruned wallets (wallets that don't know their full history, but do have their full coins), the txout index is something we need for it... but not other indexes.
8702017-07-06T19:39:12 <wumpus> oh sure morcos
8712017-07-06T19:39:12 <morcos> (sorry)
8722017-07-06T19:39:21 <wumpus> gmaxwell: yes!
8732017-07-06T19:39:30 <jonasschnelli> tagged
8742017-07-06T19:39:56 <jonasschnelli> gmaxwell: yes. For HD restores in pruned env. the utxo index is handy
8752017-07-06T19:39:57 <wumpus> gmaxwell: would be very niec to instantly query the balance, if history isn't important
8762017-07-06T19:40:33 <gmaxwell> rescan has become so slow for me at least that I'm kinda desperate for something like that.
8772017-07-06T19:40:41 <gmaxwell> I've lost days of time waiting on rescans.
8782017-07-06T19:41:42 <wumpus> next topic?
8792017-07-06T19:42:09 <sipa> nope.
8802017-07-06T19:42:25 <gmaxwell> wumpus: can you remind me of the 0.15 schedule?
8812017-07-06T19:42:30 <luke-jr> eh, UTXO isn't a substitute for rescanning.. you'd miss historical txs
8822017-07-06T19:42:48 <BlueMatt> #9961
8832017-07-06T19:42:48 <gribble> https://github.com/bitcoin/bitcoin/issues/9961 | Release schedule for 0.15.0 · Issue #9961 · bitcoin/bitcoin · GitHub
8842017-07-06T19:42:58 <gmaxwell> luke-jr: thus pruned wallet, ... it's fine to not have historical txs if you know you don't.
8852017-07-06T19:43:13 <gmaxwell> BlueMatt: thanks!
8862017-07-06T19:43:15 <wumpus> luke-jr: what if you don't care about history, and just want balance + possibly spending?
8872017-07-06T19:43:21 <BlueMatt> T-10 days to branch
8882017-07-06T19:43:22 <luke-jr> gmaxwell: but you'd end up with *some* historical tx in this case, with no deterministic reason why some are missing
8892017-07-06T19:43:27 <gmaxwell> luke-jr: you can also say that txes found on the blockchain aren't a replacement for having their metadata... :)
8902017-07-06T19:43:35 <luke-jr> I suppose we could import them as all change-only or something? :/
8912017-07-06T19:43:38 <jonasschnelli> luke-jr: you can scan in the background for the history in a very slow manner once you have done it via the UTXO set index
8922017-07-06T19:43:40 <wumpus> BlueMatt: no, not to branch, to feature freeze
8932017-07-06T19:43:50 <sipa> wumpus: it'd be incompatible with hardware wallets, before segwit
8942017-07-06T19:43:51 <luke-jr> jonasschnelli: hmm, good idea
8952017-07-06T19:43:58 <sipa> as you need the full crediting txn
8962017-07-06T19:44:00 <gmaxwell> luke-jr: no you wouldn't: my suggestion is that a pruned wallet basically have a line shown in the UI where nothing is there before it except a move like ledger entry that shows the earlier balance.
8972017-07-06T19:44:13 <BlueMatt> oh, sorry, yes, freeze
8982017-07-06T19:44:16 <wumpus> BlueMatt: branch is 2017-08-06, so a month away
8992017-07-06T19:44:20 <gmaxwell> luke-jr: I made an issue describing some ideas for that a while back.
9002017-07-06T19:44:21 <luke-jr> gmaxwell: I see, makes sense
9012017-07-06T19:45:05 <achow101> wumpus: can #10571 and #10579 be tagged for 0.15?
9022017-07-06T19:45:07 <gribble> https://github.com/bitcoin/bitcoin/issues/10571 | [RPC]Move transaction combining from signrawtransaction to new RPC by achow101 · Pull Request #10571 · bitcoin/bitcoin · GitHub
9032017-07-06T19:45:08 <gribble> https://github.com/bitcoin/bitcoin/issues/10579 | [RPC] Split signrawtransaction into wallet and non-wallet RPC command by achow101 · Pull Request #10579 · bitcoin/bitcoin · GitHub
9042017-07-06T19:45:21 <gmaxwell> There are other reasons why building such things are attractive... (e.g. UTXO based sync can't provide the data to give history...)
9052017-07-06T19:45:32 <wumpus> achow101: sure
9062017-07-06T19:45:44 <achow101> thanks
9072017-07-06T19:45:48 <gmaxwell> ack
9082017-07-06T19:48:55 <sipa> early lunch?
9092017-07-06T19:49:52 <wumpus> ye fine with me
9102017-07-06T19:49:54 <wumpus> #endmeeting
9112017-07-06T19:49:54 <lightningbot> Meeting ended Thu Jul 6 19:49:54 2017 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
9122017-07-06T19:49:54 <lightningbot> Minutes: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-07-06-19.00.html
9132017-07-06T19:49:54 <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-07-06-19.00.txt
9142017-07-06T19:49:54 <lightningbot> Log: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-07-06-19.00.log.html
9152017-07-06T19:50:32 <spudowiar> Hardware wallet support rebased and now supports change addresses properly
9162017-07-06T19:50:39 <jtimon> so why is #8498 not to be tagged for 0.15 nor project 8 ? I want to understand the criterion
9172017-07-06T19:50:40 <gribble> https://github.com/bitcoin/bitcoin/issues/8498 | Near-Bugfix: Optimization: Minimize the number of times it is checked that no money... by jtimon · Pull Request #8498 · bitcoin/bitcoin · GitHub
9182017-07-06T19:50:49 <jtimon> criteria
9192017-07-06T19:52:29 <wumpus> jtimon: well if others think it should be tagged 0.15 or be high priority for review it's fine with me
9202017-07-06T19:52:37 <spudowiar> There are a few things I need to tackle now
9212017-07-06T19:52:49 <spudowiar> a) How the plugin can tell whether it is Testnet or Mainnet
9222017-07-06T19:52:56 <wumpus> jtimon: I don't personally see it as urgent enough for that, it's an optimization without mentioning timings
9232017-07-06T19:53:24 <wumpus> jtimon: but that's just my opinion
9242017-07-06T19:53:29 <jtimon> I see, thanks
9252017-07-06T19:53:35 <spudowiar> b) How the plugin can show a UI? (e.g. TREZOR Pin Matrix)
9262017-07-06T19:53:57 <spudowiar> Maybe the plugin can just create a window itself
9272017-07-06T19:54:12 <wumpus> spudowiar: la) aunch it with a flag/option that specifies which block chain
9282017-07-06T19:54:18 <wumpus> spudowiar: b) yes, have it draw it itself
9292017-07-06T19:54:52 <jtimon> well, the timinigs changed over time. now acceptToMemoryPool is not as redundant in fee calculation as it sued to be, and the number of places where checkinouts have been called from has been varying as well
9302017-07-06T19:55:08 *** talmai has joined #bitcoin-core-dev
9312017-07-06T19:55:09 <spudowiar> c) Multiple devices (I'm going to add a device identifier parameter and a listhwwdevices method to the plugin)
9322017-07-06T19:55:11 <wumpus> spudowiar: or have a command askPin() from the plugin that shows a simple Qt message box with a prompt
9332017-07-06T19:55:19 <spudowiar> wumpus: It has a special GUI though
9342017-07-06T19:55:31 <spudowiar> Hence why I chose that example
9352017-07-06T19:55:38 <wumpus> spudowiar: if it has a special gui it should definitely draw it itself, bitcoin qt can't get into the UI delegation/embedding business
9362017-07-06T19:55:50 <jtimon> but there's more checkinputs calls now than when I first coded the thing
9372017-07-06T19:56:19 <spudowiar> d) Simplify usage (e.g. without command line parameters)
9382017-07-06T19:56:34 <spudowiar> This would require to store the plugin name and the device identifier somewhere (probably bitcoin.conf to begin with)
9392017-07-06T19:56:54 <spudowiar> e) Need to test multisig
9402017-07-06T19:56:57 <wumpus> yes
9412017-07-06T19:57:26 <spudowiar> yes to what?
9422017-07-06T19:57:59 <wumpus> "This would require to store the plugin name and the device identifier somewhere (probably bitcoin.conf to begin with)"
9432017-07-06T19:58:10 <spudowiar> ok
9442017-07-06T19:58:32 <jtimon> #10195 and #10192 likely changed how much of an improvement #8498 is as well
9452017-07-06T19:58:36 <gribble> https://github.com/bitcoin/bitcoin/issues/10195 | Switch chainstate db and cache to per-txout model by sipa · Pull Request #10195 · bitcoin/bitcoin · GitHub
9462017-07-06T19:58:38 <gribble> https://github.com/bitcoin/bitcoin/issues/10192 | Cache full script execution results in addition to signatures by TheBlueMatt · Pull Request #10192 · bitcoin/bitcoin · GitHub
9472017-07-06T19:58:40 <gribble> https://github.com/bitcoin/bitcoin/issues/8498 | Near-Bugfix: Optimization: Minimize the number of times it is checked that no money... by jtimon · Pull Request #8498 · bitcoin/bitcoin · GitHub
9482017-07-06T19:58:48 <spudowiar> Not going to bother with listhwwdevices for now (that would be useful for a GUI to select the hardware device)
9492017-07-06T19:59:23 <wumpus> jtimon: some kind of measurement would be nice, e.g. startup time with a large wallet
9502017-07-06T20:00:00 <wumpus> spudowiar: agreed, auto-detecting devices would be something for later
9512017-07-06T20:00:06 <jtimon> why a wallet? the improvements are in connectBlock and AcceptToMemoryPool
9522017-07-06T20:00:35 <jtimon> wumpus: specially on the latter
9532017-07-06T20:00:55 <wumpus> jtimon: I'm confused then - yes wallet would not be appropriate then
9542017-07-06T20:01:32 <spudowiar> Oh, and I need to get rid of boost::process dependency
9552017-07-06T20:01:44 <instagibbs> spudowiar, please do :P
9562017-07-06T20:01:54 <wumpus> I would first focus on functionality
9572017-07-06T20:02:00 <jonasschnelli> spudowiar: I think URI schema is the best option for the GUI
9582017-07-06T20:02:01 <spudowiar> instagibbs: Find me an alternative :) I don't know C++
9592017-07-06T20:02:05 <wumpus> then only when it works, on removing dependencies
9602017-07-06T20:02:13 <jonasschnelli> call sign://
9612017-07-06T20:02:19 <wumpus> too easy to get stuck in yak shaving dependencies
9622017-07-06T20:02:19 <jonasschnelli> or bitcoinsign://
9632017-07-06T20:02:26 <spudowiar> jonasschnelli: That overcomplicates things in my opinion
9642017-07-06T20:02:49 <instagibbs> wumpus, it's a super new module, only reason I care
9652017-07-06T20:02:51 <jonasschnelli> It's a clean separation... could work as a standard
9662017-07-06T20:02:59 <jonasschnelli> Otherwise other non-core application could not tab in
9672017-07-06T20:03:00 <spudowiar> jonasschnelli: How do you get the data back, anyway?
9682017-07-06T20:03:10 <instagibbs> I don't feel like installing it to test his work, so I've rolled my own solution until then
9692017-07-06T20:03:31 <spudowiar> jonasschnelli: Why can't non-Core applications use these plugins?
9702017-07-06T20:03:32 <jonasschnelli> Core sends: bitcoinsign://signtx?data=blabla&callback=bitcoincore
9712017-07-06T20:03:43 <jonasschnelli> spudowiar: you plugin would call back bitcoincore://
9722017-07-06T20:03:44 <sipa> why a URI...?
9732017-07-06T20:03:45 <spudowiar> So, Core needs to register its own protocol now?
9742017-07-06T20:03:53 <spudowiar> URIs are really unnecessary here
9752017-07-06T20:03:57 <jonasschnelli> sipa: URI is the only think that works in sandboxed env
9762017-07-06T20:04:04 <sipa> jonasschnelli: i don't understand
9772017-07-06T20:04:07 <jonasschnelli> (Android, iOS, OSX [soonish])
9782017-07-06T20:04:20 <sipa> ?
9792017-07-06T20:04:42 <jonasschnelli> In sandboxed enviroments, interprocess communication is impossible, expect over URIs
9802017-07-06T20:04:45 <spudowiar> jonasschnelli: JSON-RPC is transport agnostic
9812017-07-06T20:04:55 <spudowiar> jonasschnelli: So you can do JSON-RPC over URI if you want, on those platforms
9822017-07-06T20:05:03 <spudowiar> I'd prefer not to register arbitrary protocols on my desktop though
9832017-07-06T20:05:17 <sipa> ok, so use some wrapper URI on those platforms
9842017-07-06T20:05:19 <spudowiar> Not when a perfectly suitable solution exists
9852017-07-06T20:05:27 <gmaxwell> what sipa said
9862017-07-06T20:05:30 <sipa> not as part of the IPC mechanism in general
9872017-07-06T20:05:41 <jonasschnelli> that makes sense....
9882017-07-06T20:06:01 <jonasschnelli> in my example: bitcoinsign://signtx?data=blabla&callback=bitcoincore the blabla elements could be the JSON/RPC layer
9892017-07-06T20:06:18 <spudowiar> Yep
9902017-07-06T20:06:43 <spudowiar> At the moment though, I require the JSON-RPC to be in roughly getrawtransaction format
9912017-07-06T20:07:01 <spudowiar> I want to strip parts of that out, then write documentation for the protocol
9922017-07-06T20:07:55 <jonasschnelli> I have a branch somewhere where the GUI can select watchonly unspents and create a hex-tx instead when signing... I once thought you may should be able to forware that unsigned hex tx (including utxos) to another app via URI-schema
9932017-07-06T20:08:00 <spudowiar> https://github.com/saleemrashid/bitcoin/blob/hardware-wallet/src/wallet/wallet.cpp#L1500
9942017-07-06T20:08:44 *** spudowiar has quit IRC
9952017-07-06T20:14:05 *** clarkmoody has joined #bitcoin-core-dev
9962017-07-06T20:15:18 *** talmai has quit IRC
9972017-07-06T20:26:41 <bitcoin-git> [bitcoin] theuni opened pull request #10756: net processing: swap out signals for an interface class (master...no-net-signals2) https://github.com/bitcoin/bitcoin/pull/10756
9982017-07-06T20:27:45 <cfields> BlueMatt: I was holding off on ^^ because I thought it might stomp on some of your other PRs, but after taking a look, I think it might actually make your life a little easier
9992017-07-06T20:28:00 *** Aaronvan_ has joined #bitcoin-core-dev
10002017-07-06T20:29:49 *** talmai has joined #bitcoin-core-dev
10012017-07-06T20:30:26 <gmaxwell> <3
10022017-07-06T20:31:08 *** AaronvanW has quit IRC
10032017-07-06T20:31:41 <gmaxwell> though it shows how much y'all have worn me down about C++ features that I'm cheering for inheretence. :)
10042017-07-06T20:32:11 <cfields> heh
10052017-07-06T20:32:25 <gmaxwell> my backtraces thank you, however.
10062017-07-06T20:32:54 <gmaxwell> I believe this may be measurably faster too... when I ripped out signals and replaced it with direct function calls it was.
10072017-07-06T20:33:06 <gmaxwell> the signals stuff has thread synchronization inside it.
10082017-07-06T20:33:12 <cfields> yea. I should add that to the PR description.. that might actually be the nicest part of the change
10092017-07-06T20:33:27 <cfields> gmaxwell: yea, i've owed you this PR for months now. Sorry for the delay.
10102017-07-06T20:33:48 <gmaxwell> Don't worry, I didn't remember.
10112017-07-06T20:34:21 <cfields> heh ok
10122017-07-06T20:41:26 *** talmai has quit IRC
10132017-07-06T20:43:55 *** talmai has joined #bitcoin-core-dev
10142017-07-06T20:49:01 *** talmai has quit IRC
10152017-07-06T20:54:38 *** Aaronvan_ is now known as AaronvanW
10162017-07-06T20:55:30 *** Guyver2_ has joined #bitcoin-core-dev
10172017-07-06T20:56:43 *** Guyver2 has quit IRC
10182017-07-06T20:56:43 *** Guyver2_ is now known as Guyver2
10192017-07-06T21:12:30 *** jamesob has joined #bitcoin-core-dev
10202017-07-06T21:13:15 <jamesob> any thoughts on adding a Dockerfile to the repo? might make setting up a dev environment marginally easier
10212017-07-06T21:20:25 *** jamesob has quit IRC
10222017-07-06T21:22:09 *** jtimon has quit IRC
10232017-07-06T21:42:53 *** Chris_Stewart_5 has quit IRC
10242017-07-06T21:46:48 *** paracyst is now known as pex
10252017-07-06T21:46:58 *** pex is now known as paracyst
10262017-07-06T22:17:13 *** vicenteH has quit IRC
10272017-07-06T22:17:26 *** chjj has joined #bitcoin-core-dev
10282017-07-06T22:19:24 *** stalictite has quit IRC
10292017-07-06T22:20:50 *** jtimon has joined #bitcoin-core-dev
10302017-07-06T22:23:21 *** stalictite has joined #bitcoin-core-dev
10312017-07-06T22:25:49 <stalictite> what's the armory dev irc?
10322017-07-06T22:26:03 <stalictite> nvm got it
10332017-07-06T22:27:04 *** sanada` has joined #bitcoin-core-dev
10342017-07-06T22:28:52 *** sanada has quit IRC
10352017-07-06T22:32:21 *** Guyver2 has quit IRC
10362017-07-06T22:51:28 *** chjj has quit IRC
10372017-07-06T23:05:06 *** chjj has joined #bitcoin-core-dev
10382017-07-06T23:20:43 *** Dyaheon has quit IRC
10392017-07-06T23:21:20 *** Dyaheon has joined #bitcoin-core-dev
10402017-07-06T23:21:35 <bitcoin-git> [bitcoin] jtimon opened pull request #10757: RPC: Introduce getperblockstats to plot things (master...b15-rpc-plotter) https://github.com/bitcoin/bitcoin/pull/10757
10412017-07-06T23:27:38 <jtimon> I "had" to delete ~/.bitcoin yesterday until I learned how to cleanup things in docker (damm, should have just copied it to another disk), otherwise I could have seen the historic min fee and feerate per block that I've always wanted to see...
10422017-07-06T23:34:14 <jtimon> I hope it's well tested, I rarely introduce new features and didn't run the coverage thing, but I think I cover all the new code
10432017-07-06T23:35:31 *** chjj has quit IRC
10442017-07-06T23:40:20 <jtimon> not sure what the proper C++11 replacement for boost::split(plot_values, str_plot_values, boost::is_any_of(",")); would be
10452017-07-06T23:41:03 <sipa> i don't believe c++11 has a replacement for that
10462017-07-06T23:41:11 <jtimon> :(
10472017-07-06T23:41:18 <jtimon> c++14 ?
10482017-07-06T23:41:38 <sipa> https://stackoverflow.com/a/5167799
10492017-07-06T23:44:00 <jtimon> yeah, I think the best I found was that or close to that, but it's still very ugly imo, you can still see the loop!
10502017-07-06T23:45:32 <jtimon> I would like a std::vector<std::string> std::string::split(std::string), like python
10512017-07-06T23:46:18 <sipa> you can write such a function :)
10522017-07-06T23:46:20 <jtimon> anyway, my build is failing to compile in some platforms, it seems univalue is not as multiplatform as I thought
10532017-07-06T23:47:23 <jtimon> yeah, I could write such a function and replace it everywhere I guess, instead of only using it in the new rpc function
10542017-07-06T23:48:02 <jtimon> oh, you mean for C++ ?
10552017-07-06T23:48:09 *** chjj has joined #bitcoin-core-dev
10562017-07-06T23:50:16 <jtimon> we don't use it all that much in bitcoin https://0bin.net/paste/p8nz4NJTOuyw622R#A-qZ020Wy3jsQcl6Py3H1KDYJkxjrO7QnCqmauzad7L but I guess that's another idea for a scripted-diff PR
10572017-07-06T23:57:14 <sipa> jtimon: in #10757 you're pushing a size_t into UniValue
10582017-07-06T23:57:15 <gribble> https://github.com/bitcoin/bitcoin/issues/10757 | RPC: Introduce getperblockstats to plot things by jtimon · Pull Request #10757 · bitcoin/bitcoin · GitHub
10592017-07-06T23:57:21 <sipa> size_t is platform dependent
10602017-07-06T23:57:30 <sipa> cast it to int64_t first
10612017-07-06T23:57:48 <jtimon> yeah, I thought I had to use to constructor for all ints, it'sjust a simple cast
10622017-07-06T23:57:52 <jtimon> thanks