12017-06-15T00:03:45  *** nemgun has quit IRC
  22017-06-15T00:06:27  *** nemgun has joined #bitcoin-core-dev
  32017-06-15T00:11:44  *** jtimon has joined #bitcoin-core-dev
  42017-06-15T00:14:34  *** murch has quit IRC
  52017-06-15T00:15:03  *** jannes has quit IRC
  62017-06-15T00:23:35  *** Chris_Stewart_5 has quit IRC
  72017-06-15T00:24:52  *** goatturner has quit IRC
  82017-06-15T00:25:46  *** goatturner has joined #bitcoin-core-dev
  92017-06-15T00:26:51  *** goatturner has quit IRC
 102017-06-15T00:27:28  *** goatturner has joined #bitcoin-core-dev
 112017-06-15T00:54:57  *** Gnof has quit IRC
 122017-06-15T00:58:12  *** AaronvanW has quit IRC
 132017-06-15T01:00:06  *** AaronvanW has joined #bitcoin-core-dev
 142017-06-15T01:00:41  *** nemgun has quit IRC
 152017-06-15T01:03:48  *** goatturneer has joined #bitcoin-core-dev
 162017-06-15T01:04:38  *** AaronvanW has quit IRC
 172017-06-15T01:06:50  *** goatturner has quit IRC
 182017-06-15T01:30:05  *** dermoth has quit IRC
 192017-06-15T01:31:02  *** dermoth has joined #bitcoin-core-dev
 202017-06-15T01:33:11  *** Giszmo has quit IRC
 212017-06-15T01:39:42  *** Dyaheon has quit IRC
 222017-06-15T01:43:10  *** Dyaheon has joined #bitcoin-core-dev
 232017-06-15T01:45:17  *** unholymachine has quit IRC
 242017-06-15T01:49:57  *** dabura667_ has joined #bitcoin-core-dev
 252017-06-15T01:50:56  *** unholymachine has joined #bitcoin-core-dev
 262017-06-15T01:59:32  *** Ylbam has quit IRC
 272017-06-15T02:00:48  *** AaronvanW has joined #bitcoin-core-dev
 282017-06-15T02:05:14  *** AaronvanW has quit IRC
 292017-06-15T02:28:10  *** chjj has quit IRC
 302017-06-15T02:41:50  *** chjj has joined #bitcoin-core-dev
 312017-06-15T02:52:11  *** RubenSomsen has joined #bitcoin-core-dev
 322017-06-15T03:06:02  *** d9b4bef9 has quit IRC
 332017-06-15T03:07:08  *** d9b4bef9 has joined #bitcoin-core-dev
 342017-06-15T03:23:18  *** jamesob has joined #bitcoin-core-dev
 352017-06-15T03:43:24  *** bitwise has joined #bitcoin-core-dev
 362017-06-15T03:50:04  *** bitwise has quit IRC
 372017-06-15T03:54:56  *** apll has quit IRC
 382017-06-15T03:56:42  *** apll has joined #bitcoin-core-dev
 392017-06-15T04:01:28  *** AaronvanW has joined #bitcoin-core-dev
 402017-06-15T04:06:08  *** AaronvanW has quit IRC
 412017-06-15T04:08:23  *** altoz has quit IRC
 422017-06-15T04:09:27  *** jamesob has quit IRC
 432017-06-15T04:49:19  *** beatrootfarmer has joined #bitcoin-core-dev
 442017-06-15T04:53:08  *** goatturneer has quit IRC
 452017-06-15T05:17:43  *** [Author] has quit IRC
 462017-06-15T05:20:45  *** [Author] has joined #bitcoin-core-dev
 472017-06-15T06:02:17  *** AaronvanW has joined #bitcoin-core-dev
 482017-06-15T06:06:28  *** AaronvanW has quit IRC
 492017-06-15T06:12:50  <wumpus> morcos: I think 0.14.2 is ready to go, but I asked yesterday and got no respnses at all
 502017-06-15T06:13:28  <wumpus> (oh that's not true, fanquake replied)
 512017-06-15T06:14:17  *** Magma has quit IRC
 522017-06-15T06:14:54  <wumpus> I'd like to get your display issue in, but that would mean another week and another rc, and I'm not sure it warrants it
 532017-06-15T06:17:04  <wumpus> but we can discuss at the meeting
 542017-06-15T06:20:37  *** goatturneer has joined #bitcoin-core-dev
 552017-06-15T06:22:55  *** Magma has joined #bitcoin-core-dev
 562017-06-15T06:23:31  *** nOgAnOo has joined #bitcoin-core-dev
 572017-06-15T06:23:50  *** beatrootfarmer has quit IRC
 582017-06-15T06:35:27  <gmaxwell> wumpus: you missed morcos commenting several hours earler about it.
 592017-06-15T06:35:52  <wumpus> gmaxwell: okay
 602017-06-15T06:38:46  * wumpus disables display of join/part events, it makes the backlog harder to keep track of
 612017-06-15T06:43:29  <wumpus> (didn't use to be the case here as it was a quite small channel, but a lot of people have joined here since, welcome everyone!)
 622017-06-15T06:45:42  *** fanquake has joined #bitcoin-core-dev
 632017-06-15T06:49:38  *** RubenSomsen has quit IRC
 642017-06-15T06:53:01  *** d9b4bef9 has quit IRC
 652017-06-15T06:54:08  *** d9b4bef9 has joined #bitcoin-core-dev
 662017-06-15T07:00:58  *** riemann has quit IRC
 672017-06-15T07:03:04  *** AaronvanW has joined #bitcoin-core-dev
 682017-06-15T07:08:07  *** AaronvanW has quit IRC
 692017-06-15T07:09:04  <wumpus> jonasschnelli: sorry if I'm completely off with https://github.com/bitcoin/bitcoin/pull/10251#issuecomment-308647720, has been a while I've touched that code, but I have some concerns
 702017-06-15T07:09:53  <jonasschnelli> wumpus: you mean the comment is wrong?
 712017-06-15T07:10:20  <wumpus> no, I think it's correct, that's why I'm worried
 722017-06-15T07:10:30  <wumpus> if you can convince me it's wrong that would be great
 732017-06-15T07:10:31  <wumpus> :)
 742017-06-15T07:10:40  <jonasschnelli> okay... let me see
 752017-06-15T07:11:08  <wumpus> but unconditional lock-taking on cs_main should be avoided as much as possible in the GUI thread
 762017-06-15T07:11:45  <wumpus> and the timer isn't some separate thread, and neither is the signal handler for updateBalance
 772017-06-15T07:13:07  *** RubenSomsen has joined #bitcoin-core-dev
 782017-06-15T07:14:14  *** RubenSomsen has quit IRC
 792017-06-15T07:14:36  <jonasschnelli> wumpus: the PR 10251 would remove the timer... and..
 802017-06-15T07:14:38  *** RubenSomsen has joined #bitcoin-core-dev
 812017-06-15T07:14:47  <jonasschnelli> wumpus: the wallet would push balance updates to the GUI
 822017-06-15T07:15:12  <wumpus> so where would the balance computation happen?
 832017-06-15T07:15:34  *** riemann has joined #bitcoin-core-dev
 842017-06-15T07:15:38  <wumpus> functions like GetUnconfirmedWatchOnlyBalance are called from the GUI thread
 852017-06-15T07:15:56  <wumpus> so if the balance is dirty, the computation happens in the GUI thread, after aquiring cs_main and cs_wallet unconditionally
 862017-06-15T07:16:24  <jonasschnelli> Hmm... yes. I see
 872017-06-15T07:16:38  <wumpus> up to six times - for every type of balance, this could take ~6 minutes on a slower machine during heavy lock contention
 882017-06-15T07:17:03  <jonasschnelli> But only if a tx gets added or block connected/disconnected, right?
 892017-06-15T07:17:24  <wumpus> yes, which is very often
 902017-06-15T07:17:51  <wumpus> ideally the GUI thread would *never* hang itself based on notifications
 912017-06-15T07:17:55  <jonasschnelli> You think the TRY_LOCK in a poll routine performs better?
 922017-06-15T07:17:56  <wumpus> this is currently the case for that timer
 932017-06-15T07:18:11  <jonasschnelli> Yeah.. it should not be in the GUI thread
 942017-06-15T07:18:18  <wumpus> it optimizes for a different user experience - it's slower, but it never hangs the GUI thread
 952017-06-15T07:18:40  <wumpus> it wouldn't be a big deal if wallet functions didn't need cs_main
 962017-06-15T07:18:44  <wumpus> taking the wallet lock itself is ok
 972017-06-15T07:19:14  <wumpus> but the cs_main lock is terrible, never grab it from the GUI thread if possible, and if you need to, and it's just to update information, use TRY_LOCK
 982017-06-15T07:19:35  <jonasschnelli> That was my main intention (remove cs_main from GUI), but I guess I have made it worse
 992017-06-15T07:20:05  <jonasschnelli> I thought pushing would perform better then constant polling (even with a TRY_LOCK)
1002017-06-15T07:20:40  <jonasschnelli> Because, if you can LOCK in a TRY_LOCK, I would have expected to also block further calls that want to aquire the LOCK during the time you calculate the balances
1012017-06-15T07:20:43  <bitcoin-git> [bitcoin] luke-jr opened pull request #10595: Bugfix: RPC/Mining: Use pre-segwit sigops and limits, when working with non-segwit GBT clients (master...gbt_nosegwit_fix) https://github.com/bitcoin/bitcoin/pull/10595
1022017-06-15T07:20:59  <wumpus> (for user-initiated things such as sending a transaction, it's more acceptable, though there too I'd prefer a solution that doesn't block the GUI thread)
1032017-06-15T07:21:36  <jonasschnelli> Can we recalculate the balance during MarkDirty (connect/disconnect block, etc.)?
1042017-06-15T07:21:52  <wumpus> the whole point of the dirty stuff is not to do that
1052017-06-15T07:22:16  <wumpus> e.g.: if you're going to recalculate the balance *every* time it gets dirty, you don't need a cache
1062017-06-15T07:22:22  <jonasschnelli> The idea behind the dirty/caching is to no recalculate it at every call,.. right?
1072017-06-15T07:23:09  <wumpus> the markdirty is lazy evaluation: we know that the balance might have changed, but computing it can be expensive, so only compute it when necessary
1082017-06-15T07:23:18  <jonasschnelli> Ideally the balance calls return the cache and the calls that have the power to invalidate the cache could recalculate?
1092017-06-15T07:23:32  <jonasschnelli> I see..
1102017-06-15T07:23:45  <jonasschnelli> [..] only compute it when necessary <-- make sense
1112017-06-15T07:23:58  <jonasschnelli> the PR does that,.. but on the GUI thread
1122017-06-15T07:24:55  <luke-jr> wumpus: I may not be able to make the meeting, but FWIW I am unsure if 10595 should be a blocker for v0.14.2 or not
1132017-06-15T07:25:38  <jonasschnelli> wumpus: what about calling the getBalance() calls within a QThread and Q_EMIT balanceChanged once it's done?
1142017-06-15T07:25:38  <wumpus> luke-jr: if we're unsure, it probably shouldn't be
1152017-06-15T07:26:06  *** AaronvanW has joined #bitcoin-core-dev
1162017-06-15T07:26:58  <wumpus> jonasschnelli: but then we're adding a thread
1172017-06-15T07:27:47  <jonasschnelli> or use CScheduler?
1182017-06-15T07:27:48  <wumpus> jonasschnelli: I do think eventually that's a better solution though: have a thread to communicate with the core
1192017-06-15T07:28:03  <wumpus> never block in the GUI thread, have the GUI send commands/receive notifications from that thread
1202017-06-15T07:28:33  <jonasschnelli> Yes. Some calls are synchronous though,.. they need redesign. But that must be done at some point
1212017-06-15T07:28:35  <wumpus> but not a thread especially for updating balances, that's overkill, the current solution works ok
1222017-06-15T07:29:32  <jonasschnelli> I think a tool where we can see what lock gets triggered how much and how long it has spent time in there would be of great value for the GUI
1232017-06-15T07:29:39  <wumpus> the poll timer also offers congestion control: if a lot of transactions come in, it won't recompute the balance every time
1242017-06-15T07:32:53  <jonasschnelli> wumpus: thanks for having a look into this and it seems to have be a waste of time... let me work towards the GUI<->Core communication thread
1252017-06-15T07:33:18  <wumpus> jonasschnelli: yes, sorry for being encouraging at first then backpedalling, but I hadn't seen this
1262017-06-15T07:33:38  <jonasschnelli> Yes. Great review. I'm happy you brought that up
1272017-06-15T07:33:57  <gmaxwell> luke-jr: the gbt thing?  I don't see how its a potential issue unless you are adding _more_ transactions to your block than the template gave you, which I doubt anyone does right now.
1282017-06-15T07:34:59  <luke-jr> gmaxwell: or a lot of sigops in the generation tx possibly, but a very unlikely case
1292017-06-15T07:35:08  <luke-jr> not sure even Eligius or p2pool would hit it
1302017-06-15T07:36:33  <luke-jr> yeah, seems like it shouldn't be a practical problem thinking about it more
1312017-06-15T07:36:52  <wumpus> jonasschnelli: and in general design direction you're right - direct notification is better than polling, but it works best if all the information can be passed in through the signal so that there's no need for a round-trip
1322017-06-15T07:37:16  <wumpus> jonasschnelli: in this case that won't work due to lazy evaluation
1332017-06-15T07:37:31  *** cysm_ has quit IRC
1342017-06-15T07:37:35  <jonasschnelli> Yes. I see that point now...
1352017-06-15T07:41:05  *** jtimon has quit IRC
1362017-06-15T07:41:37  *** cysm has joined #bitcoin-core-dev
1372017-06-15T07:50:57  *** arubi has quit IRC
1382017-06-15T07:51:33  *** JackH has joined #bitcoin-core-dev
1392017-06-15T07:51:34  *** arubi has joined #bitcoin-core-dev
1402017-06-15T08:08:03  *** Dyaheon has quit IRC
1412017-06-15T08:10:08  *** Dyaheon has joined #bitcoin-core-dev
1422017-06-15T08:18:21  <bitcoin-git> [bitcoin] benma opened pull request #10596: Add vConnect to CConnman::Options (master...connmanoptions_connect) https://github.com/bitcoin/bitcoin/pull/10596
1432017-06-15T08:34:26  *** laurentmt has joined #bitcoin-core-dev
1442017-06-15T08:39:17  *** Gues_____ has joined #bitcoin-core-dev
1452017-06-15T08:51:39  *** Gues_____ has quit IRC
1462017-06-15T08:53:25  *** timothy has joined #bitcoin-core-dev
1472017-06-15T08:54:20  *** BashCo has joined #bitcoin-core-dev
1482017-06-15T09:17:57  *** laurentmt has quit IRC
1492017-06-15T09:19:11  *** jannes has joined #bitcoin-core-dev
1502017-06-15T09:27:08  *** beatrootfarmer has joined #bitcoin-core-dev
1512017-06-15T09:30:41  *** goatturneer has quit IRC
1522017-06-15T09:39:13  <bitcoin-git> [bitcoin] practicalswift opened pull request #10597: scripted-diff: Make use of C++11:s improved handling of two consecutive right angle brackets (master...right-angle-brackets) https://github.com/bitcoin/bitcoin/pull/10597
1532017-06-15T09:48:43  *** Ylbam has joined #bitcoin-core-dev
1542017-06-15T09:56:22  *** riemann has quit IRC
1552017-06-15T10:12:07  *** Dyaheon has quit IRC
1562017-06-15T10:13:48  *** Dyaheon has joined #bitcoin-core-dev
1572017-06-15T10:44:42  <bitcoin-git> [bitcoin] laanwj closed pull request #10588: doc: Note preexisting bug in display of fee calculation in coin control (0.14...notebug) https://github.com/bitcoin/bitcoin/pull/10588
1582017-06-15T10:52:47  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/228c319a944b...7c72fb99afba
1592017-06-15T10:52:47  <bitcoin-git> bitcoin/master e9cd778 Alex Morcos: Pass in smart fee slider value to coin control dialog...
1602017-06-15T10:52:48  <bitcoin-git> bitcoin/master 7c72fb9 Wladimir J. van der Laan: Merge #10582: Pass in smart fee slider value to coin control dialog...
1612017-06-15T10:53:17  <bitcoin-git> [bitcoin] laanwj closed pull request #10582: Pass in smart fee slider value to coin control dialog (master...fixcoincontrolfee) https://github.com/bitcoin/bitcoin/pull/10582
1622017-06-15T10:57:17  <ryanofsky> wumpus, jonasschnelli: related to this topic, not sure if you saw #10504 (also had a question for you in #10244)
1632017-06-15T10:57:17  <gribble> https://github.com/bitcoin/bitcoin/issues/10504 | GUI unresponsive during slow operations · Issue #10504 · bitcoin/bitcoin · GitHub
1642017-06-15T10:57:19  <gribble> https://github.com/bitcoin/bitcoin/issues/10244 | [qt] Add abstraction layer for accessing node and wallet functionality from gui by ryanofsky · Pull Request #10244 · bitcoin/bitcoin · GitHub
1652017-06-15T10:57:41  <wumpus> ryanofsky: no, hadn't seen yet, will take a look
1662017-06-15T11:26:39  *** cryptapus_afk is now known as cryptapus
1672017-06-15T11:39:08  <fanquake> wumpus going to build/release 14.2 tonight?
1682017-06-15T11:41:14  <wumpus> fanquake: the release notes are so depressing now!
1692017-06-15T11:41:44  <wumpus> but yes, I think we should just get it done
1702017-06-15T11:41:50  <wumpus> 0.14.3 will be more exciting, I promise
1712017-06-15T11:46:10  *** SopaXorzTaker has joined #bitcoin-core-dev
1722017-06-15T11:46:13  <wumpus> so, one last time: did anyone hear of any issues with rc2?
1732017-06-15T12:05:56  <paveljanik> silent night, ...
1742017-06-15T12:06:13  <paveljanik> no issues
1752017-06-15T12:08:18  <wumpus> agreed
1762017-06-15T12:08:23  <wumpus> well, there we go
1772017-06-15T12:09:03  <wumpus>  * [new tag]         v0.14.2 -> v0.14.2
1782017-06-15T12:20:34  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/7c72fb99afba...c2ab38bdd57a
1792017-06-15T12:20:34  <bitcoin-git> bitcoin/master 1bebfc8 Alex Morcos: Output Fee Estimation Calculations in CreateTransaction
1802017-06-15T12:20:35  <bitcoin-git> bitcoin/master c2ab38b Wladimir J. van der Laan: Merge #10284: Always log debug information for fee calculation in CreateTransaction...
1812017-06-15T12:20:59  <bitcoin-git> [bitcoin] laanwj closed pull request #10284: Always log debug information for fee calculation in CreateTransaction (master...debugEstimates) https://github.com/bitcoin/bitcoin/pull/10284
1822017-06-15T12:37:35  *** dabura667_ has quit IRC
1832017-06-15T12:45:14  <bitcoin-git> [bitcoin] paveljanik opened pull request #10598: Supress struct/class mismatch warnings introduced in #10284 (master...20170615_FeeCalculation_structclass) https://github.com/bitcoin/bitcoin/pull/10598
1842017-06-15T12:52:12  <fanquake> wumpus heh have to follow up with a quick 0.14.3 then.
1852017-06-15T12:53:10  <wumpus> yes - 0.14.2 just has to get out because of the upnp vuln.
1862017-06-15T12:54:52  *** apll has quit IRC
1872017-06-15T12:55:10  *** RubenSomsen has quit IRC
1882017-06-15T12:56:13  *** Chris_Stewart_5 has joined #bitcoin-core-dev
1892017-06-15T12:56:37  *** apll has joined #bitcoin-core-dev
1902017-06-15T13:02:21  *** apll has quit IRC
1912017-06-15T13:03:00  *** apll has joined #bitcoin-core-dev
1922017-06-15T13:15:41  *** RubenSomsen has joined #bitcoin-core-dev
1932017-06-15T13:16:54  <jonasschnelli> ryanofsky: Yes. Saw it... as soon as I have a bit more time (currently occupied with DigitalBitbox work) i'll give you response...
1942017-06-15T13:17:05  <jonasschnelli> The GUI responsiveness is ugly right now...
1952017-06-15T13:17:51  <jonasschnelli> I wonder moving everything to ZMQ/RPC would be a viable approach (fully detach the GUI)
1962017-06-15T13:18:11  <jonasschnelli> Ideally a clone of qt/ (to /qtdetatched)
1972017-06-15T13:18:27  <jonasschnelli> Then it would allow to remove some functions which are not possible via ZMQ/RPC
1982017-06-15T13:22:45  <ryanofsky> is that different than what I am doing with 10244?
1992017-06-15T13:23:16  <ryanofsky> 10244 removes direct calls from qt -> node wallet and replaces then with calls through interfaces which could be implemented locally or through any rpc mechanism
2002017-06-15T13:23:34  <bitcoin-git> [bitcoin] NicolasDorier reopened pull request #9991: listreceivedbyaddress Filter Address (master...listreceivedbyaddress-filtered) https://github.com/bitcoin/bitcoin/pull/9991
2012017-06-15T13:24:02  <wumpus> ryanofsky: but in itself that won't improve responsiveness, or does it also make callbacks asynchronous?
2022017-06-15T13:26:05  <wumpus> I still have to look at it in detail, I think the idea makes sense though
2032017-06-15T13:26:06  <ryanofsky> it doesn't affect responsiveness, though i do think the improved code organization would make improvements easier
2042017-06-15T13:27:16  <ryanofsky> 10244 by itself doesn't change any behavior, all it does is replace direct calls with calls through interfaces
2052017-06-15T13:27:25  <wumpus> right
2062017-06-15T13:27:32  <wumpus> which makes sense
2072017-06-15T13:27:38  *** mkarrer has quit IRC
2082017-06-15T13:28:36  <wumpus> and when there's interfaces, we can add signals to them, to subscribe to to make the UI updates asynchronous
2092017-06-15T13:29:15  <wumpus> why rename CFeeBumper to FeeBumper though?
2102017-06-15T13:29:46  <wumpus> it would be better if this was separated into GUI changes, and core changes, I think in current state this is way too large
2112017-06-15T13:29:55  <ryanofsky> or even if we don't do that, it makes it easier to identify where blocking calls are happening, because they will all look like m_ipc_node->something() or m_ipc_wallet->something()
2122017-06-15T13:31:03  <ryanofsky> the feebumper commit is the one commit that actually makes substantial core changes, i can pull that into a separate pr
2132017-06-15T13:31:31  <wumpus> but why rename it?
2142017-06-15T13:31:31  <ryanofsky> the other commits are almost entirely changes in src/qt and additions to src/ipc
2152017-06-15T13:32:47  <ryanofsky> i renamed it because the commit had to update every single reference to it anyway, so i figured it'd be good to follow the current naming convention
2162017-06-15T13:33:32  <wumpus> it seems a bit too much to try to do all that in one PR, in my opinion, but don't know what others think
2172017-06-15T13:33:34  <ryanofsky> anyway happy to pull that commit into a separate pr
2182017-06-15T13:34:00  <ryanofsky> happy to break it down
2192017-06-15T13:34:10  <ryanofsky> but just know that one commit is an anomoly
2202017-06-15T13:34:44  <ryanofsky> the other commits are uniform mechanical changes
2212017-06-15T13:34:52  <wumpus> I don't personally particularly care if there's a large GUI change, but core changes need to be reviewable easily, so combining functionality changes with a rename will make it harder
2222017-06-15T13:35:09  <wumpus> ok, that's good
2232017-06-15T13:35:21  <ryanofsky> ok, will pull that commit out
2242017-06-15T13:42:43  <ryanofsky> there is another smaller change which affects locking in wallet.cpp. will make a separate pr for that too. after this 10244 should only touch src/qt/ and src/ipc/ files, no core files
2252017-06-15T13:45:30  <ryanofsky> jonasschnelli, still curious to hear more about your qtdetached idea, and if 10244 would help with that
2262017-06-15T13:46:20  <jonasschnelli> 10244 can probably help, but my first hurdle is: +2,217 −1,131
2272017-06-15T13:46:21  <jonasschnelli> :)
2282017-06-15T13:47:47  <jonasschnelli> ryanofsky: The general abstraction may be good... but it may be also possible though wallet-/clientmodel
2292017-06-15T13:48:15  <ryanofsky> i guess i'd really appreciate feedback on the first commit: https://github.com/bitcoin/bitcoin/pull/10244/commits/7aeea1e0e54a773f8283605e9e4f9051cbf1ea87
2302017-06-15T13:48:16  <jonasschnelli> My (probably dumb) concept would be to have RPC calls in there...
2312017-06-15T13:48:32  <ryanofsky> because all the other commits (except feebumper which i will pull out) follow the same pattern as first commit
2322017-06-15T13:49:31  <jonasschnelli> I guess I would first tackle the asynchrony in the GUI layer...
2332017-06-15T13:49:57  <jonasschnelli> That needs to be done anyways and can have a quicker end user benefit when we would run all node communication in a designated thread
2342017-06-15T13:50:00  <wumpus> my preferred priority would also be improving responsiveness first
2352017-06-15T13:50:09  <jonasschnelli> Yes.
2362017-06-15T13:50:24  <jonasschnelli> For that, we first need to analze what functions/locks are the worst
2372017-06-15T13:50:29  <wumpus> though I think moving things to interfaces can help with that
2382017-06-15T13:50:41  <ryanofsky> can you guys explain your reasoning? to me it seems like this is basically unrelated, but could only make things easier not harder
2392017-06-15T13:50:46  <wumpus> as then it's clearer what the interface to the core thread should be
2402017-06-15T13:50:48  <jonasschnelli> Turn those expensive calls into async and use a general NODE<->GUI thread?
2412017-06-15T13:51:01  <ryanofsky> is there some way that my changes could make async improvments harder that i'm not seeing?
2422017-06-15T13:51:21  <jonasschnelli> No... i don't say you change is not good
2432017-06-15T13:51:32  <wumpus> not AFAIK
2442017-06-15T13:51:38  <jonasschnelli> I'm just arguing about priorities
2452017-06-15T13:51:54  <jonasschnelli> To get a +2,217 −1,131 change in, my experience tells me, ~0.5-1y
2462017-06-15T13:53:46  <jonasschnelli> but ryanofsky change makes sense.. the additional layer *IPC* <-> *wallet/client-model* <-> GUI is probably okay...
2472017-06-15T13:55:49  <ryanofsky> well hopefully it will take less than 0.5y to decide whether it's okay or not :)
2482017-06-15T13:56:21  <jonasschnelli> hehe... I think the concept is good.
2492017-06-15T13:57:52  <ryanofsky> feedback so far is helpful though, definitely makes sense to keep all core changes out of the pr and make it qt-only
2502017-06-15T13:58:25  <jonasschnelli> Yes. Ideally... this would reduce some risks
2512017-06-15T14:00:21  <wumpus> agree with doing it after the 0.15 split-off
2522017-06-15T14:01:57  *** riemann has joined #bitcoin-core-dev
2532017-06-15T14:02:43  <fanquake> to early for a 0.16 tag heh
2542017-06-15T14:03:49  <bitcoin-git> [bitcoin] practicalswift closed pull request #10597: scripted-diff: Make use of the improved handling of two consecutive right angle brackets in C++11 (master...right-angle-brackets) https://github.com/bitcoin/bitcoin/pull/10597
2552017-06-15T14:04:11  <jonasschnelli> ryanofsky wumpus: is it only me or is the responsiveness in the current GUI worse then 0.13?
2562017-06-15T14:04:41  <jonasschnelli> ryanofsky: I guess some minor fixes could speed up the GUI and there would still be time for 0.15
2572017-06-15T14:04:50  <fanquake> jonasschnelli in 0.14.2 or master?
2582017-06-15T14:05:06  *** riemann has quit IRC
2592017-06-15T14:05:16  <jonasschnelli> fanquake: I always run master and I often have some freezes...
2602017-06-15T14:05:32  <jonasschnelli> I though my balance fix would reduce some... but sadly no
2612017-06-15T14:06:02  <ryanofsky> i can't say because i didn't really use the gui in 0.13, and even now tend to only use gui with small wallets, few transactions
2622017-06-15T14:06:24  <jonasschnelli> Would a LogPrint (with microseconds) in our LOCK macro make sense to analyse the lock behavior better?
2632017-06-15T14:07:55  <ryanofsky> that seems like would probably tell you where freezes are happening, maybe there is also a way to hook into qt to warn about event handlers that take a long time to run
2642017-06-15T14:08:16  <fanquake> jonasschnelli during any particular actions?
2652017-06-15T14:08:41  <jonasschnelli> fanquake: the freezes or the log print?
2662017-06-15T14:08:44  <jonasschnelli> ryanofsky: Yes...
2672017-06-15T14:08:53  <fanquake> the freezes
2682017-06-15T14:09:20  <jonasschnelli> fanquake: Yes. Calling generate 1 followed by a sendtoaddress feels blockish
2692017-06-15T14:10:47  <wumpus> I think there's too much overhead from logging to make that useful, also logging itself also locks
2702017-06-15T14:11:00  <wumpus> so you'd have to exclude that; but you could try
2712017-06-15T14:14:22  <jonasschnelli> I guess i'd use printf for a short hackish solution
2722017-06-15T14:15:23  <wumpus> in any case, I'm not sure how much you'd learn, all LOCKs in GUI code and calls to core functions that take locks on cs_main are a problem. THough possibly you can find the ones that occur most frequently if you also log where it's taken.
2732017-06-15T14:39:34  *** chjj has quit IRC
2742017-06-15T14:45:55  <Lauda> aruby
2752017-06-15T14:45:59  <Lauda> oops wrong channel
2762017-06-15T14:48:29  *** arowser has quit IRC
2772017-06-15T14:56:02  <bitcoin-git> [bitcoin] ryanofsky opened pull request #10600: Make feebumper class stateless (master...pr/ipc-bump) https://github.com/bitcoin/bitcoin/pull/10600
2782017-06-15T15:05:37  *** Dyaheon has quit IRC
2792017-06-15T15:06:01  *** Dyaheon has joined #bitcoin-core-dev
2802017-06-15T15:07:57  *** chjj has joined #bitcoin-core-dev
2812017-06-15T15:19:57  *** arowser has joined #bitcoin-core-dev
2822017-06-15T15:29:50  *** fanquake has quit IRC
2832017-06-15T15:33:33  *** JackH has quit IRC
2842017-06-15T15:35:42  <bitcoin-git> [bitcoin] practicalswift opened pull request #10602: Make clang-format use C++11 features (e.g. A<A<int>> instead of A<A<int> >) (master...clang-format-cpp11) https://github.com/bitcoin/bitcoin/pull/10602
2852017-06-15T15:47:37  *** Dizzle has joined #bitcoin-core-dev
2862017-06-15T15:50:14  *** abpa has joined #bitcoin-core-dev
2872017-06-15T16:12:24  *** PaulCapestany has quit IRC
2882017-06-15T16:12:45  *** talmai has joined #bitcoin-core-dev
2892017-06-15T16:16:48  *** PaulCapestany has joined #bitcoin-core-dev
2902017-06-15T16:17:09  *** Guest___ has joined #bitcoin-core-dev
2912017-06-15T16:39:03  *** Giszmo has joined #bitcoin-core-dev
2922017-06-15T16:39:10  *** Guyver2 has joined #bitcoin-core-dev
2932017-06-15T16:43:58  *** jtimon has joined #bitcoin-core-dev
2942017-06-15T16:53:18  *** Guest___ has quit IRC
2952017-06-15T17:00:13  *** ProfMac has joined #bitcoin-core-dev
2962017-06-15T17:20:14  *** murch has joined #bitcoin-core-dev
2972017-06-15T17:25:57  *** JackH has joined #bitcoin-core-dev
2982017-06-15T17:34:56  *** davec has quit IRC
2992017-06-15T17:35:53  <jnewbery> Is anyone using the 'comparison' part of the comparison test framework? Any objections to me retiring it? #10603
3002017-06-15T17:35:54  <gribble> https://github.com/bitcoin/bitcoin/issues/10603 | Retire the comparison test framework · Issue #10603 · bitcoin/bitcoin · GitHub
3012017-06-15T17:36:03  *** davec has joined #bitcoin-core-dev
3022017-06-15T17:36:06  *** talmai has quit IRC
3032017-06-15T17:36:22  *** Giszmo has quit IRC
3042017-06-15T17:36:41  *** To7 has joined #bitcoin-core-dev
3052017-06-15T17:40:55  *** talmai has joined #bitcoin-core-dev
3062017-06-15T17:45:10  *** goatpig has quit IRC
3072017-06-15T17:45:12  <wumpus> jnewbery: I'm fairly sure people are using it
3082017-06-15T17:45:25  <wumpus> @(sdaftuar morcos BlueMatt)
3092017-06-15T17:46:12  <sdaftuar> wumpus: i've talked to jnewbery about it offline a bit; i mostly think we don't really use it
3102017-06-15T17:46:23  <wumpus> okay
3112017-06-15T17:46:30  <sdaftuar> the intention was to be able to compare many versions of the software
3122017-06-15T17:46:43  <wumpus> but that isn't that useful in practice?
3132017-06-15T17:46:49  <sdaftuar> but i don't think anyone (outside my proof of concept, way back when) actually tried to do that?
3142017-06-15T17:47:44  <wumpus> would be a better question to ask then "should someone be doing those tests?"
3152017-06-15T17:47:59  <sdaftuar> yeah i think that's the good question
3162017-06-15T17:48:17  <jnewbery> The way those test cases are actually used in practice is that test_runner.py runs them with a single node. In theory they could be run with multiple nodes and the states compared, but as far as I'm aware no-one does that
3172017-06-15T17:48:25  <wumpus> I mean we could always add tests, maybe even in a travis crontab
3182017-06-15T17:48:56  <sdaftuar> in practice, it seems like we've never really written tests where the outcome wasn't fixed and known, and therefore hardcoded in the test itself
3192017-06-15T17:49:25  <sdaftuar> i guess it's possibel we could introduce a change to bitcoind and the corresponding test and accidentally introduce a comparison failure
3202017-06-15T17:50:20  <sdaftuar> p2p-fullblocktest doesn't change very often though
3212017-06-15T17:50:33  <sdaftuar> the risk seems like it'd be in consensus changes not yet deployed, eg something like segwit
3222017-06-15T17:50:40  <sdaftuar> but those tests haven't changed much either
3232017-06-15T17:52:37  *** timothy has quit IRC
3242017-06-15T17:52:55  <jnewbery> I think the risk seems low. The individual tests are written quite prescriptively, so in order to break a 'comparison' without breaking running the test with an individual node, someone would probably need to update the individual test case to change the expectation
3252017-06-15T17:53:23  <jnewbery> Anyway, I'd be interested to hear whether anyone out there is using them or has any input. Issue 10603
3262017-06-15T17:55:13  <jnewbery> The tests that use the comparison test framework are:
3272017-06-15T17:55:13  <jnewbery> 10457
3282017-06-15T17:55:23  <jnewbery> bip65-cltv-p2p.py bip68-112-113-p2p.py bip9-softforks.py bipdersig-p2p.py invalidblockrequest.py invalidtxrequest.py p2p-fullblocktest.py
3292017-06-15T18:01:02  <gmaxwell> sdaftuar: we used it extensively in the past.
3302017-06-15T18:01:18  <gmaxwell> rather the old bitcoinj tool. (to be clear)
3312017-06-15T18:01:30  <sdaftuar> gmaxwell: right, we're still going to have p2p-fullblocktest
3322017-06-15T18:01:39  <sdaftuar> which is approx. the same as the old bitcoinj tool
3332017-06-15T18:02:01  <sdaftuar> the question is just, do we try to support/improve the ComparisonTestFramework thing as the implementation
3342017-06-15T18:02:43  <sdaftuar> which i think has mostly been a not very helpful infrastructure... the tests in that framework are hard to read
3352017-06-15T18:02:56  <gmaxwell> OK.
3362017-06-15T18:03:00  <sdaftuar> and working around p2p changes that the ComparisonTestFramework isn't designed for is pretty hacky
3372017-06-15T18:03:13  <bitcoin-git> [bitcoin] jnewbery opened pull request #10604: Expose multiwallet in getwalletinfo and add multiwallet test (master...multiwallet_test) https://github.com/bitcoin/bitcoin/pull/10604
3382017-06-15T18:05:48  <gmaxwell> sorry, I tuned in to the end of the conversation. I mostly started commenting because I strongly disagree with the claim that that the existing test cases were at all close enough to comprehensive to guarentee consensus consistency with another implementation. We don't even come close to 100% branch coverage in script.
3392017-06-15T18:06:44  *** murch has quit IRC
3402017-06-15T18:06:46  <sdaftuar> oh, yeah definitely agree with that
3412017-06-15T18:07:05  <sdaftuar> i think the question is, should we be working towards comparison style tests, along the lines of what the comparisontestframework was intended for?
3422017-06-15T18:07:48  <kanzure> branch coverage would be a good set of tests..
3432017-06-15T18:07:58  <kanzure> er, script coverage. what is missing?
3442017-06-15T18:11:51  <gmaxwell> sdaftuar: I think they're secondary to other kinds of tests.  Comparison is primarily useful if we have good random behavior generation and can verify consistency.
3452017-06-15T18:13:06  <sdaftuar> that makes sense to me...  my thought was that it would be more helpful to rewrite our comparison tests (which are currently just evaluating a single node anyway) in an imperative style, to make them easier to maintain and debug
3462017-06-15T18:14:29  *** Giszmo has joined #bitcoin-core-dev
3472017-06-15T18:14:31  <sdaftuar> and in retrospect, i think if we did want a comparison test framework, it probably makes more sense to scrap trying to do it over p2p, and just test consensus with submitblock or something.  less prone to maintenance headache
3482017-06-15T18:14:47  <gmaxwell> er. I don't agree (sadly)--
3492017-06-15T18:16:04  <gmaxwell> for two reasons:  p2p means its more duarable across versions (e.g. you can test an alternative implementation), and p2p means its testing the interface that actually matters; it would catch thing like failures in the block fetching state machine.
3502017-06-15T18:16:49  <gmaxwell> Comparing other implementations can increase the sensitivity of the tests even if we'd never expect someone to use the other implementation.
3512017-06-15T18:17:25  <sdaftuar> that's true in theory, but i think that has mostly failed in practice
3522017-06-15T18:18:04  <sdaftuar> at least, we have never implemented the full range of p2p behaviors in a single piece of python test harness code
3532017-06-15T18:18:20  <wumpus> what I'm not sure about is how the comparision test is better than just running the tests against the other implementation
3542017-06-15T18:19:30  <sdaftuar> so for instance, we end up implementing kludges and workarounds in the python test code in order to eg ensure block delivery to a particular implementation. see for instance how we handle announcing and relaying a block, after we turned off direct fetch on inv's in bitcoind
3552017-06-15T18:19:47  <sipa> wumpus: i guess the advantage is that you can randomly generate scenarios and compare them, rather than needing a test writer who knows what the result is supposed to be
3562017-06-15T18:19:48  <gmaxwell> wumpus: see my comment about randomly generated behavior.  If you have a random sequence of operations you can test certian invariants, but the random generator doesn't know the exact result-- but it can let us know when two different implementations behaved differently.
3572017-06-15T18:19:59  <sipa> but that advantage does go away if you're just running a static scenario
3582017-06-15T18:20:01  <jnewbery> gmaxwell: I think really for stability across versions, you want to have a known good node that you use RPCs on to create blocks and transactions, then connect that node to nodes-under-test of different versions. Otherwise you need to update the tests whenever any p2p logic changes (eg headers first, etc)
3592017-06-15T18:20:07  <gmaxwell> It's an orthorgonal and very powerful method of testing.
3602017-06-15T18:20:08  *** Giszmo has quit IRC
3612017-06-15T18:20:08  <sdaftuar> it seems to me that the more durable thing is to have specific p2p tests that exercise the code paths we want to test
3622017-06-15T18:20:11  <wumpus> right, if you can somehow generate random scenarios, it'd be useful
3632017-06-15T18:20:13  <ProfMac> Is this the best place to ask questions re: setting up the virtualbox / debian / gitian build environment according to https://github.com/bitcoin/bitcoin/blob/master/doc/gitian-building.md#create-a-new-virtualbox-vm  The first question is at #installing-gitian, when I do the git clone https://github.com/bitcoin/bitcoin should I be in ~ or in vm-builder-0.12.4+bzr494
3642017-06-15T18:20:18  <gmaxwell> And yes, for static tests is not useful IMO.
3652017-06-15T18:20:28  *** goatpig has joined #bitcoin-core-dev
3662017-06-15T18:20:29  *** talmai has quit IRC
3672017-06-15T18:20:31  <wumpus> yes, then it's like fuzzing two implementations at the same time and comparing
3682017-06-15T18:20:50  <gmaxwell> Rather if we get interesting patterns out of a comparison, we could seralize those into a static test (and add the exact comparison points)
3692017-06-15T18:21:18  <wumpus> ProfMac: where doesn't matter, as long as you consistently use same the directory, though cloning bitcoin under the vm-builder directory likely is not what you want
3702017-06-15T18:21:33  <gmaxwell> This is, e.g. how we tested the DER parser in libsecp256k1-- a harness with three implementations.
3712017-06-15T18:21:35  <jnewbery> ok, so how about I change those static tests to use the standard test framework? I won't delete the comparison test framework code so if someone wants to use it for randomized testing, they can still do that
3722017-06-15T18:22:22  <ProfMac> Thanks wumpus.  I am doing a 2nd install from scratch, yesterday I could not get it to work.
3732017-06-15T18:22:47  <sipa> jnewbery: if all they are doing is testing a scenario where it's obvious from the test code what the expected behaviour is, sure
3742017-06-15T18:23:37  <gmaxwell> Would that mean moving the test stimulus for those things from p2p to rpc?
3752017-06-15T18:23:44  <sdaftuar> no, it shouldn't
3762017-06-15T18:23:48  <gmaxwell> okay!
3772017-06-15T18:24:25  <wumpus> that would mean that the comparison test code doesn't get tested itself anymore, and thus will code-rot
3782017-06-15T18:24:36  <sdaftuar> wumpus: i fear it already has rotted :(
3792017-06-15T18:24:53  <ProfMac> So I'm going to continue with the 3 git clone commands in "~/opt/gitian", anyone see any red flags or offer a better naming scheme?
3802017-06-15T18:24:56  <wumpus> ok...
3812017-06-15T18:25:56  <sdaftuar> i mean that in the sense, we already have hacky workarounds in eg p2p-fullblocktest to deal with shortcomings in the framework
3822017-06-15T18:27:14  *** talmai has joined #bitcoin-core-dev
3832017-06-15T18:35:12  *** jannes has quit IRC
3842017-06-15T18:43:17  *** talmai has quit IRC
3852017-06-15T18:46:10  *** wangchun has quit IRC
3862017-06-15T18:49:23  *** laurentmt has joined #bitcoin-core-dev
3872017-06-15T18:50:56  <gmaxwell> meeting in 10 minutes.
3882017-06-15T18:55:13  *** lichtamberg_ has joined #bitcoin-core-dev
3892017-06-15T18:57:15  *** laurentmt has quit IRC
3902017-06-15T18:58:11  *** twistedline has quit IRC
3912017-06-15T19:00:04  <jonasschnelli> hi
3922017-06-15T19:00:07  <wumpus> #startmeeting
3932017-06-15T19:00:07  <lightningbot> Meeting started Thu Jun 15 19:00:07 2017 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
3942017-06-15T19:00:07  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
3952017-06-15T19:00:24  <wumpus> PSA: v0.14.2 has been tagged, please start your gitian builders
3962017-06-15T19:00:30  <wumpus> topics?
3972017-06-15T19:00:34  <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
3982017-06-15T19:00:34  <wumpus> #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 jl2012 instagibbs achow101
3992017-06-15T19:00:36  <kanzure> hi.
4002017-06-15T19:00:40  <paveljanik> Hi
4012017-06-15T19:00:41  <achow101> hi
4022017-06-15T19:00:42  <cfields> jonasschnelli: i just wrote a quick mutex locktime reporter, ping me after meeting if you'd like to discuss
4032017-06-15T19:00:44  <sdaftuar> here
4042017-06-15T19:00:45  <sipa> yow
4052017-06-15T19:00:49  <gmaxwell> (I guess I should update my list)
4062017-06-15T19:00:57  <jonasschnelli> cfields: awesome!
4072017-06-15T19:01:03  <sipa> wumpus: you're requesting the presence of 2 instagibbses?
4082017-06-15T19:01:07  <gmaxwell> cfields: finally someone did that, awesome.
4092017-06-15T19:01:20  <cfields> well it's very dumb, but it's something :)
4102017-06-15T19:01:21  <wumpus> sipa: yes!
4112017-06-15T19:01:34  <sipa> cfields: -DDEBUG_LOCKCONTENTION?
4122017-06-15T19:01:38  <luke-jr> lol
4132017-06-15T19:01:38  <jonasschnelli> cfields: dumb is good
4142017-06-15T19:01:51  <wumpus> #topic high priority for review
4152017-06-15T19:02:04  <gmaxwell> https://github.com/bitcoin/bitcoin/projects/8
4162017-06-15T19:02:08  <sipa> #10148 plz *puppyeyes*
4172017-06-15T19:02:10  <gribble> https://github.com/bitcoin/bitcoin/issues/10148 | Use non-atomic flushing with block replay by sipa · Pull Request #10148 · bitcoin/bitcoin · GitHub
4182017-06-15T19:02:26  <wumpus> 10148 is already on the list, I'm testing it
4192017-06-15T19:02:30  <sipa> cool
4202017-06-15T19:02:33  <sdaftuar> i'm working on an rpc test as well
4212017-06-15T19:02:39  <sipa> sdaftuar: awesome!
4222017-06-15T19:02:42  <sipa> can i help?
4232017-06-15T19:03:00  <sdaftuar> i'll let you know!
4242017-06-15T19:03:05  <sdaftuar> i think i almos thave it
4252017-06-15T19:03:12  *** twistedline has joined #bitcoin-core-dev
4262017-06-15T19:03:56  *** talmai has joined #bitcoin-core-dev
4272017-06-15T19:04:08  <sipa> having thought more about it, i don't think #10339 will have any significant performance impact
4282017-06-15T19:04:11  <gribble> https://github.com/bitcoin/bitcoin/issues/10339 | Optimization: Calculate block hash less times by jtimon · Pull Request #10339 · bitcoin/bitcoin · GitHub
4292017-06-15T19:04:22  <luke-jr> basic multiwallet was merged. I hope to have the next step (RPC support) later today. ACK to add to priority then?
4302017-06-15T19:04:48  <jonasschnelli> RPC support would be great
4312017-06-15T19:04:53  <sipa> agree
4322017-06-15T19:04:55  <jonasschnelli> You mean addressing wallet via RPC endpoint?
4332017-06-15T19:04:55  <achow101> luke-jr: yes please
4342017-06-15T19:05:08  <luke-jr> jonasschnelli: I mean each username has a different single wallet
4352017-06-15T19:05:22  <jonasschnelli> luke-jr: hmm...
4362017-06-15T19:05:24  <wumpus> sipa: ok, removing it from high priority then
4372017-06-15T19:05:27  <jonasschnelli> I'd prefere endpoints
4382017-06-15T19:05:39  <jonasschnelli> AUTH for wallet switching seems hackish
4392017-06-15T19:05:41  <luke-jr> jonasschnelli: endpoints can be done later; I'm just trying to get the simplest stuff done first
4402017-06-15T19:05:48  *** Dyaheon has quit IRC
4412017-06-15T19:05:50  <jonasschnelli> endpoint is 10lines of code
4422017-06-15T19:05:54  <wumpus> I'd also prefer endpoints, makes it easier to move wallets to external processes etc just by changing the url
4432017-06-15T19:05:57  <jonasschnelli> I can post it to you later
4442017-06-15T19:06:00  <luke-jr> jonasschnelli: not securely ;p
4452017-06-15T19:06:10  <luke-jr> jonasschnelli: I don't want JoinMarket to have access to my main wallet
4462017-06-15T19:06:21  <jonasschnelli> there is no security in our RPC implementation :/
4472017-06-15T19:06:24  <sipa> yay, wallet ACLs
4482017-06-15T19:06:25  * sipa hides
4492017-06-15T19:06:30  <wumpus> please don't use auth, it's not supposed to be a multi-user authentication mult-wallet, that just adds another nightmare difficult to support like accounts
4502017-06-15T19:06:31  <achow101> you could do some combination of both?
4512017-06-15T19:06:31  <luke-jr> wumpus: different username is also a simple change to the URI
4522017-06-15T19:06:43  <wumpus> we already support different usernames/passwords
4532017-06-15T19:06:49  <jonasschnelli> use a passphase as wallet name
4542017-06-15T19:06:55  <wumpus> it's an authentication feature, should not affect the wallet
4552017-06-15T19:06:56  <jonasschnelli> same security as basic auth?
4562017-06-15T19:07:23  <sipa> i think the first step should be either endpoint or a generic optional named parameter to select the wallet
4572017-06-15T19:07:24  <luke-jr> wumpus: I see no distinction
4582017-06-15T19:07:28  *** talmai has quit IRC
4592017-06-15T19:07:28  <wumpus> sipa: yes
4602017-06-15T19:07:28  <gmaxwell> endpoints won't be ten lines of code. After all, we'll need to add support for them to bitcoin-cli, the test framework, etc.
4612017-06-15T19:07:34  <achow101> sipa: agreed
4622017-06-15T19:07:43  <sipa> the choice of which user can access which wallets is orthogonal, i think
4632017-06-15T19:07:50  <wumpus> gmaxwell: which is easy, the underlying stuff (rpcproxy, libevent) obviously supports it
4642017-06-15T19:07:53  *** Dyaheon has joined #bitcoin-core-dev
4652017-06-15T19:07:55  <sipa> but i would prefer not to tie users to wallets at the auth level
4662017-06-15T19:07:57  <jonasschnelli> gmaxwell: yes Indeed
4672017-06-15T19:08:48  <jonasschnelli> first stage, each user should be able to access each wallet....
4682017-06-15T19:08:48  <gmaxwell> obviously we do want to have username/wallet binding, right?  This lets you be more confident e.g. that your joinmarket install isn't going to screw up your ordinary wallet, for example.
4692017-06-15T19:08:48  <wumpus> sipa: me neither, it just seems a level violation, and causes wrong expectations that giving access to RPC to one wallet is secure in any way
4702017-06-15T19:08:54  <gmaxwell> (eventually)
4712017-06-15T19:08:57  <luke-jr> jonasschnelli: no -.-
4722017-06-15T19:09:11  <wumpus> gmaxwell: I really think that's going too far
4732017-06-15T19:09:23  <gmaxwell> then why are we bothering?
4742017-06-15T19:09:27  <wumpus> securing RPC for multiple users is absolutely a nightmare
4752017-06-15T19:09:32  <jonasschnelli> luke-jr: the first logical extendable step would be that, no? Adding wallet selecting via AUTH is something you need to throw away later
4762017-06-15T19:09:49  <luke-jr> well, if I can't isolate JoinMarket this way, I have no interest in doing it.. so I can just move on to GUI and leave RPC support in Knots only
4772017-06-15T19:09:51  <sipa> wumpus: i think it's inevitable that we'll need that
4782017-06-15T19:09:53  <wumpus> anyhow a security layer could always be added could be later if endpoint-based multiwallet is in place
4792017-06-15T19:09:58  <wumpus> sipa: I think it's a mistake
4802017-06-15T19:10:05  <wumpus> sipa: just like accounts was
4812017-06-15T19:10:13  <wumpus> it's something that bitcoind shouldn't handle
4822017-06-15T19:10:27  <gmaxwell> I think what luke would like to accomplish is making multiwallet immediately useful for the application of combining multiple applicatoins onto one bitcoind; rather than having to run seperate bitcoinds for each thing that needs a wallet that you're running.
4832017-06-15T19:10:30  <luke-jr> jonasschnelli: no?
4842017-06-15T19:10:59  <sipa> gmaxwell: i think that's an interesting use case; i don't think it should be the first step
4852017-06-15T19:11:04  <wumpus> that's just inviting bugs, there's no way we can make that secure, the RPC is not a secure endpoint and is regarded as compeltely  trusted
4862017-06-15T19:11:34  <wumpus> it would escalate a bug in e.g. a single RPC command to a security issue, right now RPC access = fully trusted
4872017-06-15T19:11:36  <jonasschnelli> luke-jr: I don't know the JoinMarket use case very well.. but if you give it access to your node, it could shutdown, add peers, etc. (in case you don't trust that software)
4882017-06-15T19:11:45  <gmaxwell> This is also important to us at blockstream and we will end up maintaining a fork of Bitcoin with it. (though luke wasn't doing this work at our request).
4892017-06-15T19:11:58  <luke-jr> jonasschnelli: even if we add endpoint multiwallet and ACLs later, we still want a way to select a default wallet for each user
4902017-06-15T19:12:20  <luke-jr> wumpus: then why do we have auth at all?
4912017-06-15T19:12:32  <jonasschnelli> I really think we should keep hands away from multi-user/multi-wallet setup
4922017-06-15T19:12:34  <wumpus> luke-jr: to gain access
4932017-06-15T19:12:47  <wumpus> jonasschnelli: me too... seems something that needs to be a level on top, not handled by bitcoind itself
4942017-06-15T19:12:55  <jonasschnelli> For now we should focus on single-user/multi-wallet (1:n)
4952017-06-15T19:13:15  <jonasschnelli> n:n smells like a account-like-problem-re-incarnation
4962017-06-15T19:13:20  <wumpus> anyhow if we have endpoint multi-wallet access, it'spossible to slap on a wallet/user auth mapping later
4972017-06-15T19:13:34  <luke-jr> or vice-versa..
4982017-06-15T19:13:38  <wumpus> that's "just" a matter of access control
4992017-06-15T19:13:44  <jonasschnelli> yes. n:n may make sense.. but endpoint first seems much more logical
5002017-06-15T19:13:48  <wumpus> yes
5012017-06-15T19:13:51  <gmaxwell> jonasschnelli: I do not follow your comment with account like problems. The problem with accounts is that they weren't wallets but users expected them to be and treated them like ones.
5022017-06-15T19:14:06  <jonasschnelli> gmaxwell: Yes. Not directly related.
5032017-06-15T19:14:10  <sipa> i don't think access control is necessarily that complicated; have a global permission and wallet specific permission; configure which users have which
5042017-06-15T19:14:13  <wumpus> I just think that making bitcoind multi-user is a grave mistake
5052017-06-15T19:14:18  <wumpus> but I"ll shut up about it...
5062017-06-15T19:14:24  <jonasschnelli> I think the complexity is huge,.. leads to permission groups, etc.
5072017-06-15T19:14:35  <wumpus> yes, exactly, some people wnat everything in bitcoind
5082017-06-15T19:14:44  <gmaxwell> jonasschnelli: what? no it doesn't.
5092017-06-15T19:14:47  <sipa> well it seems that multiple people want multiwallet for multiple reasons
5102017-06-15T19:14:53  <sipa> i don't think that's a problem
5112017-06-15T19:15:04  <sipa> and should not be a blocker for the basic functionality
5122017-06-15T19:15:07  <wumpus> this is one the reason why the wallet should have been split off to a separate process / library I guess... now it all needs to be compounded
5132017-06-15T19:15:11  <wumpus> making bitcoind some kind of systemd
5142017-06-15T19:15:11  <jonasschnelli> if we start to use n:n, enterprises will probably use it for multi-user wallet backends...
5152017-06-15T19:15:32  <luke-jr> wumpus: user:wallet makes a split off later simpler
5162017-06-15T19:15:33  <jonasschnelli> and removing – if it gets to complicated – is hard or even impossible (like the accounting)
5172017-06-15T19:15:34  <wumpus> jonasschnelli: yes exactly... and what if there's a bug in that
5182017-06-15T19:15:37  <luke-jr> endpoints makes splitting off later complex
5192017-06-15T19:15:48  *** chjj has quit IRC
5202017-06-15T19:15:54  <wumpus> it moves all the (perceived) responsiblity for managing multi-user setups secure to us
5212017-06-15T19:16:00  <jonasschnelli> luke-jr: endpoint would even work if each wallet runs in its own process
5222017-06-15T19:16:04  <gmaxwell> How do we split wallets if we are using endpoints?
5232017-06-15T19:16:08  <jonasschnelli> (though auth probably also)
5242017-06-15T19:16:17  <luke-jr> jonasschnelli: huh? not really..?
5252017-06-15T19:16:23  <jtimon> but multi-wallet doesn't imply multi-user, does it?
5262017-06-15T19:16:25  <wumpus> gmaxwell: what do you mean with "split wallets"?
5272017-06-15T19:16:36  <gmaxwell> split wallets int oseperate processes
5282017-06-15T19:16:51  <wumpus> gmaxwell: different wallets have different URLs then
5292017-06-15T19:17:04  <wumpus> gmaxwell: so it's just another change: change the port...
5302017-06-15T19:17:17  <luke-jr> wumpus: ALL of these options are simple URI changes..
5312017-06-15T19:17:27  <achow101> how would different endpoints work with bitcoin-cli or the debug console?
5322017-06-15T19:17:28  <luke-jr> although some tools don't allow changing the URI right now
5332017-06-15T19:17:31  <wumpus> http://127.0.0.1:8333/wallet1 versus http://127.0.0.1:8334/wallet2
5342017-06-15T19:17:39  <gmaxwell> achow101: thats why it isn't ten lines of code.
5352017-06-15T19:17:42  <jonasschnelli> achow101: you can add: -wallet=filename
5362017-06-15T19:17:55  <wumpus> achow101: just add an option
5372017-06-15T19:18:03  <sipa> s/filename/name/
5382017-06-15T19:18:09  <jonasschnelli> endpoints in bitcoin-cli is not really complex...
5392017-06-15T19:18:10  <luke-jr> achow101: debug console isn't via RPC anyway
5402017-06-15T19:18:11  <jonasschnelli> sipa: yes
5412017-06-15T19:18:14  <achow101> but it certainly wouldn't work with debug console
5422017-06-15T19:18:14  <gmaxwell> sipa +1
5432017-06-15T19:18:39  <wumpus> as for debug console: you could ask the same question about authentication
5442017-06-15T19:18:40  <gmaxwell> luke-jr: I think we'll need endpoints in any case regardless of auth to set a default.
5452017-06-15T19:18:52  <luke-jr> gmaxwell: maybe
5462017-06-15T19:18:52  <jonasschnelli> achow101: the whole GUI has no multiwallet interface
5472017-06-15T19:18:58  <gmaxwell> luke-jr: because that will be what you need to make it usable to work with multiple wallets as a single user.
5482017-06-15T19:18:59  <wumpus> debug console is not authenticated at all - so adding endpoint/auth support is likely the similar amount of work
5492017-06-15T19:19:24  <wumpus> if access control is implemented, a single user could want to have access to multiple wallets anyhow
5502017-06-15T19:19:25  <gmaxwell> debug console should perhaps get a dropdown, and yes, it will be the same work either way.. probably easier with endpoints.
5512017-06-15T19:19:31  <wumpus> so user=wallet is a bad abstraction
5522017-06-15T19:19:36  <luke-jr> I already have the GUI done BTW
5532017-06-15T19:19:43  <gmaxwell> yes you'll want to have access to multiple wallets from a single user regardless.
5542017-06-15T19:19:44  <luke-jr> it's just based on the RPC branch
5552017-06-15T19:19:51  <sipa> luke-jr: how does it let you select the wallet?
5562017-06-15T19:19:52  <gmaxwell> luke-jr: how does gui handle the debug console?
5572017-06-15T19:19:56  <jonasschnelli> A very hackish (and very old) endpoint impl
5582017-06-15T19:19:57  <luke-jr> sipa: comboboxes
5592017-06-15T19:20:03  <jonasschnelli> A very hackish (and very old) endpoint impl for bitcoin-cli: https://github.com/jonasschnelli/bitcoin/blob/2015/05/corewallet/src/bitcoin-cli.cpp#L134
5602017-06-15T19:20:05  <luke-jr> one in the main window, and one in the debug window
5612017-06-15T19:20:20  <gmaxwell> sounds more or less okay.
5622017-06-15T19:20:56  <gmaxwell> luke-jr: so why not implement endpoints first?  surely even if your own use needs account you can carry a 5 line patch to allow accounts to select the default wallet.
5632017-06-15T19:20:57  <luke-jr> wumpus: even if a single user can access multiple wallets, we still want a way to choose the default
5642017-06-15T19:21:05  <gmaxwell> see above
5652017-06-15T19:21:10  *** laurentmt has joined #bitcoin-core-dev
5662017-06-15T19:21:21  <luke-jr> gmaxwell: it's more code, and not done yet
5672017-06-15T19:21:23  <wumpus> well the default wallet could depend on the user, I don't really care
5682017-06-15T19:21:31  <luke-jr> I can implement it, but IMO it will delay things to make it the next step
5692017-06-15T19:21:32  <wumpus> though I'd prefer to get rid of 'default wallet', in time
5702017-06-15T19:21:35  <jonasschnelli> maybe the GUI should have a node window (network, peers) and a wallet-window per wallet...
5712017-06-15T19:21:52  <sipa> jonasschnelli: ugh
5722017-06-15T19:21:58  <luke-jr> the user=>wallet stuff is literally done and well-tested (in Knots), just needs to be rebased
5732017-06-15T19:21:59  <gmaxwell> jonasschnelli: that doesn't sound like a good UI. :P
5742017-06-15T19:22:07  <sipa> jonasschnelli: /me remembers browsers before tabs
5752017-06-15T19:22:08  <gmaxwell> at least not mandatory.
5762017-06-15T19:22:13  <gmaxwell> what sipa says. :P
5772017-06-15T19:22:20  <jonasschnelli> yeah... I like windows.. but I'm pretty alone nowadays with that
5782017-06-15T19:22:31  <jonasschnelli> Yeah. Tabs make more sense I guess.
5792017-06-15T19:22:37  <sipa> anyway, separate discussion
5802017-06-15T19:22:52  * jonasschnelli think sipa certainly browses with lynx
5812017-06-15T19:23:04  <sipa> i would really prefer endpoints or optional named argument to select a wallet, and deal with the authentication question later
5822017-06-15T19:23:15  <jonasschnelli> sipa: +1
5832017-06-15T19:23:16  <gmaxwell> luke-jr: in any case, seems to me the path forward is to do the endpoints thing, and having auth pick default is a simple change which is either sufficiently non-objectionable or at least a trivial patch to carry.
5842017-06-15T19:23:21  <achow101> sipa: ack
5852017-06-15T19:23:22  <wumpus> sipa: same for me
5862017-06-15T19:23:27  <luke-jr> would anyone NACK if I go forward with user->wallet mappings since they're basically ready, and then do endpoints based on that?
5872017-06-15T19:24:07  <achow101> probably
5882017-06-15T19:24:09  <gmaxwell> luke-jr: does it also support one user with many wallets?
5892017-06-15T19:24:12  <wumpus> well as we determined above, a user may want to have access to multiple wallets, so a single user->wallet mapping just doesn't cut it, even if you want to add access control
5902017-06-15T19:24:20  <gmaxwell> what wumpus says.
5912017-06-15T19:24:28  <luke-jr> gmaxwell: the current code does not, but there's no reason the endpoints couldn't add that
5922017-06-15T19:24:29  <wumpus> I really think we should just start with endpoints as sipa says
5932017-06-15T19:24:52  <jnewbery> Isn't rpcuser deprecated anyway?
5942017-06-15T19:24:54  <jonasschnelli> Yes. Let's start with endpoint.. I'll can write it next week because I already did once...
5952017-06-15T19:24:57  <wumpus> I'm not going to NACK anything that makes progress though
5962017-06-15T19:24:59  <luke-jr> jnewbery: it's rpcauth
5972017-06-15T19:25:00  <sipa> jnewbery: rpcauth isn't
5982017-06-15T19:25:01  <jonasschnelli> *I can
5992017-06-15T19:25:29  <gmaxwell> jnewbery: rpcuser is, but this is rpcauth (rpcuser doesn't even have multiple users)
6002017-06-15T19:25:29  <jtimon> jnewbery: is rpcuser deprecated? since when?
6012017-06-15T19:25:38  <gmaxwell> jtimon: a year?
6022017-06-15T19:25:39  <achow101> jtimon: it's deprecated since a long time ago
6032017-06-15T19:25:42  <gmaxwell> it prints out a notice!
6042017-06-15T19:25:50  <wumpus> rpcuser is deprecated, people are encouraged to use either rpcauth or cookie auth
6052017-06-15T19:25:59  <wumpus> we won't remove it just yet ofcourse
6062017-06-15T19:26:09  <jtimon> oh, deprecated as in "we want to remove this", but it actually still works, no?
6072017-06-15T19:26:14  <paveljanik> 26 minutes...
6082017-06-15T19:26:14  <luke-jr> right
6092017-06-15T19:26:15  <achow101> yes
6102017-06-15T19:26:17  <wumpus> that is what deprecated means, yes
6112017-06-15T19:26:28  <jtimon> yeah, sorry
6122017-06-15T19:26:29  <instagibbs> paveljanik, 34 to go :P
6132017-06-15T19:26:43  <wumpus> paveljanik: what's so special about 26?
6142017-06-15T19:26:49  <sipa> jonasschnelli: any progress on GUI for database upgrade?
6152017-06-15T19:26:58  <wumpus> #topic GUI for database upgrade?
6162017-06-15T19:27:00  <gmaxwell> And we've wasted a perfectly good half hour. :P  luke should put up patches and we can yell at him on github, but I think I would really prefer if the first cut does multiple wallets for a user... (if nothing else, that is the easiest thing to test)
6172017-06-15T19:27:00  <jonasschnelli> sipa: I sadly had only little time last and this week
6182017-06-15T19:27:07  <luke-jr> wumpus: 21 is half of 42
6192017-06-15T19:27:18  <jonasschnelli> sipa: I looked into it and wanted to ask you how I get the max size of a db cursor (to calc progress)
6202017-06-15T19:27:42  <sipa> jonasschnelli: it's not hard to estimate as txids are randomly distributed
6212017-06-15T19:27:51  <gmaxwell> so you just look at the txid...
6222017-06-15T19:27:54  <sipa> i can add code for that
6232017-06-15T19:27:55  <gmaxwell> they're done in order.
6242017-06-15T19:28:07  <gmaxwell> if it's at 0x01... then it's done 1/256 of it.
6252017-06-15T19:28:12  <sipa> txid -> arith_uint256 -> * 100/2^256
6262017-06-15T19:28:23  *** Aaronvan_ has joined #bitcoin-core-dev
6272017-06-15T19:28:29  <jonasschnelli> Okay. The rest is simple (debug.log non newline [10%] progress   /  GUI splash screen progress with abort)
6282017-06-15T19:28:39  <wumpus> BTW: jnewbery rebased the label API pull (#7729), a lot of thanks for that
6292017-06-15T19:28:41  <gribble> https://github.com/bitcoin/bitcoin/issues/7729 | rpc: introduce label API for wallet by laanwj · Pull Request #7729 · bitcoin/bitcoin · GitHub
6302017-06-15T19:28:50  <sipa> jonasschnelli: i'll write code for the progress estimation
6312017-06-15T19:29:08  <jonasschnelli> sipa: Okay. Pass me over a commit and I'll finish the rest
6322017-06-15T19:29:11  *** chjj has joined #bitcoin-core-dev
6332017-06-15T19:29:14  <jnewbery> wumpus: no problem. I wanted to test drive it :)
6342017-06-15T19:29:59  *** AaronvanW has quit IRC
6352017-06-15T19:30:38  <gmaxwell> wumpus: \O/ on the label rebase.
6362017-06-15T19:30:53  <wumpus> must have been a nightmare
6372017-06-15T19:31:27  <wumpus> any other topics?
6382017-06-15T19:31:51  <jonasschnelli> what about the rpc splitting,... has that been discussed so far?
6392017-06-15T19:32:04  <jnewbery> There had been quite a few refactors. I think the rebase was good, but reviewers should look out for anything that looks off
6402017-06-15T19:32:06  <jonasschnelli> signrawwithkey, etc.?
6412017-06-15T19:32:09  <wumpus> rpc splitting?
6422017-06-15T19:32:26  <achow101> the PRs I made to unfuck signrawtx and validateaddress
6432017-06-15T19:32:42  <wumpus> ah https://github.com/bitcoin/bitcoin/pull/10583
6442017-06-15T19:32:47  <wumpus> #10583
6452017-06-15T19:32:48  <jonasschnelli> achow101: yes. Those..
6462017-06-15T19:32:48  <gribble> https://github.com/bitcoin/bitcoin/issues/10583 | [RPC] Split part of validateaddress into getaddressinfo by achow101 · Pull Request #10583 · bitcoin/bitcoin · GitHub
6472017-06-15T19:33:04  <wumpus> #topic split off wallet functionality from mixed wallet/non-wallet RPC calls
6482017-06-15T19:33:08  <wumpus> or something
6492017-06-15T19:33:22  <achow101> #10570
6502017-06-15T19:33:23  <gribble> https://github.com/bitcoin/bitcoin/issues/10570 | [RPC] Split signrawtransaction into multiple distinct RPCs · Issue #10570 · bitcoin/bitcoin · GitHub
6512017-06-15T19:33:45  <wumpus> concept ack (haven't gotten around to reviewing anything)
6522017-06-15T19:33:48  <gmaxwell> I think those changes all make sense.  Someone commented about breaking compatibility, but its for a new major version and it will be easy for callers to update their behavior.
6532017-06-15T19:33:59  <morcos> i'm here now.. haven't caught up on backlog
6542017-06-15T19:34:06  <sipa> it breaks compatibility with a never documented or advertized feature :)
6552017-06-15T19:34:07  <wumpus> well we could allow both, for one major version
6562017-06-15T19:34:10  <gmaxwell> Though we might want to rename the old calls at the same time. (a suggestion for discussion)
6572017-06-15T19:34:20  <sipa> (concatenating multiple tx hex strings, yuck)
6582017-06-15T19:34:25  <wumpus> wut?
6592017-06-15T19:34:32  <wumpus> ok, we're talking about different things
6602017-06-15T19:34:37  <instagibbs> aside from mixing wallet/nonwallet, what's the issue with validateaddress?
6612017-06-15T19:34:38  <gmaxwell> sipa: it was certantly advertised and known.
6622017-06-15T19:34:40  <wumpus> I mean validateaddress/getaddressinfo
6632017-06-15T19:34:42  <instagibbs> (or is that the issue)
6642017-06-15T19:34:50  <achow101> instagibbs: that's the issue
6652017-06-15T19:34:51  <sipa> wumpus: ah, i'm talking about signrawtransaction
6662017-06-15T19:34:52  <gmaxwell> wumpus: he's talking about the signraw split to create the combine call.
6672017-06-15T19:34:52  <wumpus> instagibbs: that is the issue
6682017-06-15T19:34:57  <instagibbs> ok, are we killing off getinfo then too:
6692017-06-15T19:34:59  <instagibbs> :)
6702017-06-15T19:35:05  <achow101> hopefully :D
6712017-06-15T19:35:10  *** chjj has quit IRC
6722017-06-15T19:35:11  <wumpus> instagibbs: yes, but that's not the topic now
6732017-06-15T19:35:16  <gmaxwell> I would miss getinfo. all the other commands take more typing. :P
6742017-06-15T19:35:17  <wumpus> we're already confusing two things, let's add more!
6752017-06-15T19:35:25  <gmaxwell> wumpus: okay!
6762017-06-15T19:35:25  <instagibbs> eh, we're talking about blowing away validateaddress as is, sorry
6772017-06-15T19:35:26  <wumpus> gmaxwell: hey I have a pull that implements it client side
6782017-06-15T19:35:46  <gmaxwell> wumpus: lol.  can you name the rpc call "gi" :P even less typing.
6792017-06-15T19:35:47  <jonasschnelli> IMO having a non wallet sign rawtx where priv keys are passed aroung in a shell over a possible TCP channel is not ideal.. but we already have it... I though instead of splitting it off, move it to the tool
6802017-06-15T19:35:55  <jonasschnelli> But I see the point with getting the UTXOs
6812017-06-15T19:36:01  <sipa> let's rename all RPCs to get*info... for example s/sendtoaddress/getnewpaymenttxid/
6822017-06-15T19:36:08  <gmaxwell> jonasschnelli: we need the UTXOs or its all awfulsauce.
6832017-06-15T19:36:11  <instagibbs> sipa, lol
6842017-06-15T19:36:16  <wumpus> #8843
6852017-06-15T19:36:17  <gribble> https://github.com/bitcoin/bitcoin/issues/8843 | rpc: Handle `getinfo` client-side in bitcoin-cli w/ `-getinfo` by laanwj · Pull Request #8843 · bitcoin/bitcoin · GitHub
6862017-06-15T19:36:18  <luke-jr> lol
6872017-06-15T19:36:28  <luke-jr> getsignedtransaction
6882017-06-15T19:36:31  <jonasschnelli> gmaxwell: I though the node RPC can spitout what you need to pass it into bitcoin-tx or so...
6892017-06-15T19:36:48  <jonasschnelli> but I know... very inconvinient
6902017-06-15T19:36:48  <luke-jr> getthistransactionbroadcast
6912017-06-15T19:36:50  <luke-jr> :p
6922017-06-15T19:36:51  <sipa> jonasschnelli: sure it can; it's just more convenient to not need that
6932017-06-15T19:36:51  <wumpus> eventually closed it because the only person responding was luke-jr and he kept arguing against it
6942017-06-15T19:37:08  <gmaxwell> jonasschnelli: and that adds steps to the process.. which is already long enough that it's prone to error.
6952017-06-15T19:37:14  <sipa> jonasschnelli: it's called listunspent
6962017-06-15T19:37:16  <jonasschnelli> It's just another source how people can shoot themselfs with exposing priv keys
6972017-06-15T19:37:28  <gmaxwell> luke-jr: why do you hate freedom?
6982017-06-15T19:37:32  <luke-jr> gmaxwell: !⁈
6992017-06-15T19:37:35  <gmaxwell> haha
7002017-06-15T19:37:52  *** murch has joined #bitcoin-core-dev
7012017-06-15T19:38:30  <sipa> jonasschnelli: but the functionality already exists, and i very much like removing it from the wallet (so people at least won't accidentally mix up privkey based operations with wallet stuff)
7022017-06-15T19:38:54  <instagibbs> sipa, ok I see the motivation there
7032017-06-15T19:38:58  <gmaxwell> anyways, I can just say that I have tried to stop using getinfo and failed. Mostly because typing getnetworkinfo getblockchainfo getfooooooooooinfo and then wading through a bunch of things when I want to see: How many connections, which block am I at, and what wallet am I running (which I can tell via the balance). :P  just personal feedback.
7042017-06-15T19:39:01  <luke-jr> gmaxwell: I didn't even NACK it :o
7052017-06-15T19:39:04  <jonasschnelli> Yes... I guess that makes sense. I kinda hoped once we touch that we could move it away from the node into a sep. process
7062017-06-15T19:39:21  <luke-jr> gmaxwell: use the GUI for that! :p
7072017-06-15T19:39:31  <sipa> jonasschnelli: i have a vague proposal for that too, but it's more complicated
7082017-06-15T19:39:37  <gmaxwell> luke-jr: again, why do you hate freedom? :P
7092017-06-15T19:39:50  <sipa> jonasschnelli: and involves a new format for partially signed transactions...
7102017-06-15T19:39:57  <wumpus> gmaxwell: anyhow we can easily reopen and rebase that PR, bitcoin-cli hardly changed since then
7112017-06-15T19:40:01  <sipa> wumpus: ack
7122017-06-15T19:40:03  <jonasschnelli> sipa: that contains everything you need to sign?
7132017-06-15T19:40:08  <luke-jr> gmaxwell: make a shell alias to all the calls ;)
7142017-06-15T19:40:23  <gmaxwell> it's so much easier to have a signing blob thing post segwit. :(
7152017-06-15T19:40:37  <bitcoin-git> [bitcoin] laanwj reopened pull request #8843: rpc: Handle `getinfo` client-side in bitcoin-cli w/ `-getinfo` (master...2016_09_getinfo_clientside) https://github.com/bitcoin/bitcoin/pull/8843
7162017-06-15T19:40:39  <sipa> jonasschnelli: yes, contains amounts, change info, prevouts being spent, ...
7172017-06-15T19:40:40  <wumpus> yes, let's activate segwit
7182017-06-15T19:40:46  <gmaxwell> luke-jr: I don't like customizing my expirence of bitcoin too much because then I'll just patch around everything that stinks.
7192017-06-15T19:40:47  * sipa revives segnet
7202017-06-15T19:41:09  <jonasschnelli> sipa: That's also something we could re-use for the detatched signing standard (a.k.a hardware wallet standard)
7212017-06-15T19:41:11  <luke-jr> we could just leave getinfo how it is ;)
7222017-06-15T19:41:26  <gmaxwell> in any case, we're offtopic. I think that achow's PRs are all nice incremental improvements and we should take them (after review)
7232017-06-15T19:41:28  <sipa> jonasschnelli: pre-segwit however, it also needs to contain the full spent transactions :(
7242017-06-15T19:41:33  <luke-jr> bitcoin-cli -getinfo only handles 1 sortof-use-case, and leaves the other 2 supported use cases unaddressed
7252017-06-15T19:41:35  <sipa> gmaxwell: agree
7262017-06-15T19:41:37  <wumpus> after promising to deprecate it for years... yeah, of course....
7272017-06-15T19:41:52  <sipa> (disclaimer: achow101'w my intern this summer, i asked him to work on those)
7282017-06-15T19:42:02  <jonasschnelli> sipa: [full spent transactions], I guess that's okay.
7292017-06-15T19:42:25  <sipa> jonasschnelli: bitcoind unfortunately can't do that generically (you need the wallet for that)
7302017-06-15T19:42:25  <wumpus> getinfo is going away, there's no going back now
7312017-06-15T19:42:44  <luke-jr> let's add a getallinfo then
7322017-06-15T19:42:46  <luke-jr> /s
7332017-06-15T19:42:47  <wumpus> I've exactly documented what information you can find on what get*info command
7342017-06-15T19:42:54  <gmaxwell> I am fine with it going away, but I don't believe we replaced it as well as we thought we did.
7352017-06-15T19:43:01  <wumpus> and the client-side getinfo is ther for user friendlyness, if people want it
7362017-06-15T19:43:01  <sipa> i have no problem with removing it, with or without 8843
7372017-06-15T19:43:15  <luke-jr> wumpus: it doesn't work in the debug window
7382017-06-15T19:43:16  <sipa> i'm sure i'll curse a bit that getinfo isn't around anymore, and then change my habits
7392017-06-15T19:43:34  <gmaxwell> sipa: I tried blocking it, you won't. the replacements right now are not usable.
7402017-06-15T19:43:43  <luke-jr> :/
7412017-06-15T19:43:50  <gmaxwell> But thats okay, wumpus suggestion would be fine, though luke has a point about the debug console.
7422017-06-15T19:43:53  <wumpus> luke-jr: isn't all the information in the debug window *without* typing anything?
7432017-06-15T19:43:57  <achow101> removing getinfo will mess with a ton of things that use getinfo for basic rpc connection checking too...
7442017-06-15T19:44:11  <wumpus> achow101: and you're starting to bring that up *now*?
7452017-06-15T19:44:12  <achow101> but I think it should be removed anyways
7462017-06-15T19:44:12  <sipa> let's merge the getuptime rpc thing
7472017-06-15T19:44:13  <gmaxwell> wumpus: if it isn't we should make it. problem solved.
7482017-06-15T19:44:22  <bitcoin-git> [bitcoin] ryanofsky opened pull request #10605: Add AssertLockHeld assertions in CWallet::ListCoins (master...pr/listlock) https://github.com/bitcoin/bitcoin/pull/10605
7492017-06-15T19:44:23  <instagibbs> achow101, move to dumpprivkey obv
7502017-06-15T19:44:33  <wumpus> gmaxwell: the first tab of the debug window pretty much shows everything, and indeed, if it isn't it could be added
7512017-06-15T19:44:49  <sipa> oh, another topic: non-hardened key derivation
7522017-06-15T19:44:51  <achow101> wumpus: well most of those things are old website scripts that were written once and never touched again by the authors
7532017-06-15T19:44:54  <instagibbs> sipa, ACK
7542017-06-15T19:44:54  <gmaxwell> luke-jr: I think ^ is how we should handle the gui.  (also important to make it copy/pasteable if it isn't.)
7552017-06-15T19:45:01  <wumpus> I'm really disappointed that years after deciding to deprecate getinfo we're still having this discussion
7562017-06-15T19:45:12  <luke-jr> wumpus: lol maybe :D
7572017-06-15T19:45:14  <wumpus> anyhow next topic
7582017-06-15T19:45:20  <gmaxwell> wumpus: sometimes you have to try things out to know their effects completely!
7592017-06-15T19:45:30  <wumpus> #topic non-hardened key derivation
7602017-06-15T19:45:32  <sipa> so
7612017-06-15T19:45:53  <sipa> non-hardened key derivation has many use cases in addition to hardened
7622017-06-15T19:46:02  <jonasschnelli> I guess NicolasDorier made good work there
7632017-06-15T19:46:07  <wumpus> achow101: we should carefully note it in the release notes of course
7642017-06-15T19:46:13  <sipa> however, they also have a gaping wide security hole when child private keys are exposed
7652017-06-15T19:46:23  <wumpus> achow101: we could even make getinfo fail with a custom message
7662017-06-15T19:46:29  <instagibbs> that plus dumpwallet will give you sads
7672017-06-15T19:46:30  <sipa> thus, suggestion: allow a new wallet to be created with either harderned or unhardened keys
7682017-06-15T19:46:40  <sipa> when you choose unhardened, dumpprivkey is disabled
7692017-06-15T19:46:44  <instagibbs> xpub is only accessible through dumpwallet right now AFAIK
7702017-06-15T19:46:45  <achow101> wumpus: returning null would probably not mess with anything
7712017-06-15T19:46:49  <sipa> (but dumpmasterkey or whatever is still available)
7722017-06-15T19:47:11  <achow101> sipa: there is no dumpmasterkey
7732017-06-15T19:47:11  <jonasschnelli> instagibbs: dumpprivkey must be disabled anyways
7742017-06-15T19:47:19  <luke-jr> sipa: I'd want to be able to mix them..
7752017-06-15T19:47:23  <jonasschnelli> achow101: dumpmasterkey must be added
7762017-06-15T19:47:30  <instagibbs> luke-jr, .... why
7772017-06-15T19:47:31  <gmaxwell> this is a lot more interesting with multiwallet support in place, since the cases where you want that are mostly secondary wallets (like incoming payments with keys generated by your webserver)
7782017-06-15T19:47:37  <wumpus> dumpmasterkey, isn't there a PR for that?
7792017-06-15T19:47:42  <jonasschnelli> no
7802017-06-15T19:47:47  <luke-jr> instagibbs: to generate reusable payment tokens
7812017-06-15T19:47:49  <sipa> luke-jr: i guess that's fine; just disable dumpwallet, and dumpprivkey selectively for keys derived in a non-hardened fashion
7822017-06-15T19:47:51  <gmaxwell> sipa said or whatever for a reason. :P
7832017-06-15T19:47:54  <achow101> jonasschnelli: I'm stil lwaiting #9504
7842017-06-15T19:47:55  <gribble> https://github.com/bitcoin/bitcoin/issues/9504 | [RPC] dumpmasterprivkey command by achow101 · Pull Request #9504 · bitcoin/bitcoin · GitHub
7852017-06-15T19:48:04  <jonasschnelli> oh...
7862017-06-15T19:48:05  <luke-jr> sipa: sgtm
7872017-06-15T19:48:09  <wumpus> see, I wasn't crazy
7882017-06-15T19:48:25  <gmaxwell> wumpus: well, technically it doesn't prove that...
7892017-06-15T19:48:26  <jonasschnelli> achow101: how can I not be aware of that PR... sorry for the missinfo
7902017-06-15T19:48:34  <wumpus> gmaxwell: true
7912017-06-15T19:48:37  <sipa> getmissinfo
7922017-06-15T19:48:47  <jonasschnelli> :/
7932017-06-15T19:48:56  <jonasschnelli> (I even commited on the PR ^^)
7942017-06-15T19:48:59  <jonasschnelli> commented
7952017-06-15T19:49:15  <wumpus> getmisinfo would really fit with the spirit of the times
7962017-06-15T19:49:19  <gmaxwell> Anyways, I think that sounds okay. These applications will likely need a couple of extra RPCs too. no need to design here however.  (e.g. it will need to export the extended public key.)
7972017-06-15T19:49:24  *** chjj has joined #bitcoin-core-dev
7982017-06-15T19:49:33  <sipa> not much more to say about the topic - just pointing out that if we disable dumping child private keys, my concern with non-hardered derivation largely goes away
7992017-06-15T19:49:47  <wumpus> anyhow, no problem with non-hardened key support
8002017-06-15T19:49:58  <jonasschnelli> I guess with allowing xpub derivation, flexible keypath would be welcome..
8012017-06-15T19:50:04  <jonasschnelli> People want to use BIP44
8022017-06-15T19:50:06  <wumpus> as an option, not as default
8032017-06-15T19:50:08  <gmaxwell> w/ disabling and it not being a default thing. sounds great to me.
8042017-06-15T19:50:25  <achow101> sgtm
8052017-06-15T19:50:51  <jonasschnelli> Yes. Would be a great change...
8062017-06-15T19:50:59  <gmaxwell> also so long as we do the extra rpcs to make it actually useful (like extract the extended public keys, and whatever else is needed to handle an external address generator.)
8072017-06-15T19:51:13  <jonasschnelli> I guess keypool handling would be much simpler with xpub derivation
8082017-06-15T19:51:22  <gmaxwell> I doubt it?
8092017-06-15T19:51:30  <instagibbs> I think it's the same-ish
8102017-06-15T19:51:33  <jonasschnelli> Why would you need a keypool with xpub derivation?
8112017-06-15T19:51:41  <gmaxwell> for scanning.
8122017-06-15T19:51:41  <jonasschnelli> you derive when you need
8132017-06-15T19:51:50  <instagibbs> you have master seed already, you can already do that
8142017-06-15T19:51:50  <jonasschnelli> you always derive the lookup window in mem
8152017-06-15T19:51:53  <gmaxwell> you need to scan forward to know when you're paid.
8162017-06-15T19:52:05  <jonasschnelli> +1000 keys in mem should be ackish
8172017-06-15T19:52:18  <jonasschnelli> (pubkeys)
8182017-06-15T19:52:26  <gmaxwell> yes, the keypool doesn't technically need to be saved on disk, though it may be faster to do so then to generate thousands of addresses at every wallet load.
8192017-06-15T19:52:39  <gmaxwell> but otherwise I think its the same.
8202017-06-15T19:52:56  <jonasschnelli> I'd say loading the keypool at wallet load takes almost the same (or longer)
8212017-06-15T19:53:28  <jtimon> sipa: why would people want to dump child private keys?
8222017-06-15T19:53:32  <gmaxwell> okay, this would make the change much more intrusive then I think.
8232017-06-15T19:53:39  <instagibbs> jtimon, you want to stop them from doing so
8242017-06-15T19:53:47  <gmaxwell> jtimon: same reason some people eat paste.  (they don't know better)
8252017-06-15T19:53:52  <jonasschnelli> heh
8262017-06-15T19:53:57  <sipa> jonasschnelli: the reason creating new keys is slow, is because we flush them all individually to disk
8272017-06-15T19:54:11  <wumpus> yes...
8282017-06-15T19:54:15  *** laurentmt has quit IRC
8292017-06-15T19:54:17  <jtimon> gmaxwell: I see
8302017-06-15T19:54:21  <jonasschnelli> Yes. In-mem non-bdb "keypool" would be much faster
8312017-06-15T19:54:41  <gmaxwell> that flushing is not required anymore with hdwallets regardless, I believe.
8322017-06-15T19:54:45  <sipa> gmaxwell: exactly
8332017-06-15T19:55:00  <jonasschnelli> With xpub derivation, would there be really a need to write the pool to disk? I doubt it
8342017-06-15T19:55:07  <gmaxwell> (we will still need a flush to know how many we've given out...)
8352017-06-15T19:55:09  <wumpus> gmaxwell: good point!
8362017-06-15T19:55:29  <jonasschnelli> All you need is the seed
8372017-06-15T19:55:44  <gmaxwell> jonasschnelli: no, not a need, though why result in more distinct codepaths?  I would expect it to also make loading faster.
8382017-06-15T19:55:47  <achow101> you just need to write the path of the most recent key
8392017-06-15T19:55:48  <jonasschnelli> gmaxwell: yes. thats a good point
8402017-06-15T19:56:11  <jonasschnelli> achow101: Yes.
8412017-06-15T19:56:14  <gmaxwell> achow101: yes, every new address still needs to do a wallet flush.  But on bulk key creation we do not need a flush for each operation.
8422017-06-15T19:56:38  <gmaxwell> e.g. starting up for the first time with a keypoool of 10000.
8432017-06-15T19:58:26  <wumpus> two minutes to go
8442017-06-15T19:58:33  <gmaxwell> jonasschnelli: did you ever get around to implementing the change where any key that is noticed used on the blockchain marks all the earlier keys in its chain as used?
8452017-06-15T19:58:52  <jonasschnelli> gmaxwell: HD restore?
8462017-06-15T19:59:12  <jonasschnelli> https://github.com/bitcoin/bitcoin/pull/10240
8472017-06-15T19:59:16  <gmaxwell> it's part of your restore pr? okay.
8482017-06-15T19:59:25  <jonasschnelli> That makes all keys as used up to the one found
8492017-06-15T19:59:30  <gmaxwell> great.
8502017-06-15T19:59:34  <jonasschnelli> It can even temp. halt the sync if you prune, etc.
8512017-06-15T19:59:39  <jonasschnelli> Needs overhaul and rebase...
8522017-06-15T19:59:46  <jonasschnelli> It's already (too) big
8532017-06-15T19:59:54  <jonasschnelli> ryanofsky gave me a hard time
8542017-06-15T20:00:01  <sipa> #getmeetingendinfo
8552017-06-15T20:00:12  <wumpus> #endmeeting
8562017-06-15T20:00:12  <lightningbot> Meeting ended Thu Jun 15 20:00:12 2017 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
8572017-06-15T20:00:12  <lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-06-15-19.00.html
8582017-06-15T20:00:12  <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-06-15-19.00.txt
8592017-06-15T20:00:12  <lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-06-15-19.00.log.html
8602017-06-15T20:02:41  *** talmai has joined #bitcoin-core-dev
8612017-06-15T20:04:27  *** lichtamberg_ has quit IRC
8622017-06-15T20:07:34  <gmaxwell> wumpus: sorry to bog you with the getinfo stuff. :(
8632017-06-15T20:08:55  <wumpus> gmaxwell: yes, no problem, don't mind resurrecting #8843
8642017-06-15T20:08:56  <gribble> https://github.com/bitcoin/bitcoin/issues/8843 | rpc: Handle `getinfo` client-side in bitcoin-cli w/ `-getinfo` by laanwj · Pull Request #8843 · bitcoin/bitcoin · GitHub
8652017-06-15T20:09:07  <wumpus> gmaxwell: just don't want to talk with luke-jr about it :p
8662017-06-15T20:09:07  <gmaxwell> I think the main challenges for it in an interactive setting is that the replacements spam the screen with information which is not what I'm interested in, and it takes about three commands to check on them.  Thats not reason to not get rid of getinfo at all, and I support getting rid of it, but think we need something like your PR.  I'll give it a look.
8672017-06-15T20:09:12  <gmaxwell> haha
8682017-06-15T20:09:21  <gmaxwell> Well, he does hate freedom, after all.
8692017-06-15T20:09:53  <sipa> gmaxwell: perhaps you should write a getmyinfo.sh with just queries for the things you're typically interested in :)
8702017-06-15T20:09:58  <wumpus> I mean the reason for deprecating it is that we didn't want to add any more info to it, also it combines wallet and non-wallet information which doesn't work with multiwallet
8712017-06-15T20:10:35  <wumpus> sipa: I have tons of those scripts
8722017-06-15T20:10:47  <wumpus> e.g. to show # connections per interface in/out
8732017-06-15T20:11:05  <wumpus> getinfo's output isn't *that* useful
8742017-06-15T20:11:05  <luke-jr> maybe -getinfo should take a -getinfodata which can go in the config file, to tell it what data to fetch from what RPCs ;)
8752017-06-15T20:11:18  <wumpus> luke-jr: well in that case I'd prefer just a python script
8762017-06-15T20:11:51  <ProfMac> What git version introduced the file bitcoin/contrib/gitian-build.sh ?
8772017-06-15T20:12:05  <wumpus> oh wait I'm talking to luke-jr about getinfo
8782017-06-15T20:12:13  <luke-jr> :<
8792017-06-15T20:12:23  *** owowo has quit IRC
8802017-06-15T20:12:40  <morcos> at the risk of irritating everyone, i use getinfo all the time
8812017-06-15T20:13:15  <gmaxwell> sipa: so then I'm happy while typical users suffer, I've tried to avoid doing that.
8822017-06-15T20:13:18  <achow101> ProfMac: check the history in github
8832017-06-15T20:13:23  <ProfMac> morcos, yep, me too.
8842017-06-15T20:13:38  <gmaxwell> same reason I don't use the ncurses thing that I like.
8852017-06-15T20:13:47  <luke-jr> gmaxwell: throw it in contrib/?
8862017-06-15T20:13:58  <wumpus> e.g. scripts like this work, it's not a work of art but meh https://gist.github.com/laanwj/27241686db0db712cd94f692a491ad78
8872017-06-15T20:14:46  <wumpus> typical users may have very different wants, though
8882017-06-15T20:14:47  <ProfMac> achow101, I've been in Google, github, for days.  Thought someone would just actually answer the question.
8892017-06-15T20:14:57  <instagibbs> I've been weaning myself off of getinfo
8902017-06-15T20:15:17  <wumpus> in any case, I'm all for keeping -getinfo client-side in bitcoin-cli, I'm rebasing 8843
8912017-06-15T20:15:44  <achow101> ProfMac: it was introduced in this commit: https://github.com/bitcoin/bitcoin/commit/eda4cfb992d140c8471f6cc2bf16c4a106439225
8922017-06-15T20:16:08  <Chris_Stewart_5> Why don't we return fee estimation information in sat/byte?
8932017-06-15T20:16:24  <ProfMac> Thanks, achow101
8942017-06-15T20:16:47  <jonasschnelli> gmaxwell: Yes. 20 is to little...
8952017-06-15T20:16:57  <instagibbs> ProfMac, you can always `git log -p -M --follow -- file/path` to track those kind of questions
8962017-06-15T20:16:58  <jonasschnelli> I guess I took BIP44 for a start.. but it's a single const
8972017-06-15T20:17:06  <instagibbs> Chris_Stewart_5, because legacy, mostly
8982017-06-15T20:17:21  *** owowo has joined #bitcoin-core-dev
8992017-06-15T20:17:31  <wumpus> instagibbs: hah, 99% of the time that's the right answer to any 'why' question
9002017-06-15T20:18:42  <Chris_Stewart_5> I suppose that is hard to change too for fear of people paying large fees if they don't get the memo
9012017-06-15T20:19:35  *** SopaXorzTaker has quit IRC
9022017-06-15T20:20:37  <wumpus> once a custom is ingrained, it usually turns out the cost and risk of change doesn't weigh up against any possible benefits
9032017-06-15T20:21:13  <ProfMac> Thanks instagibbs.  I'm just spinning up to speed with git.  I made a deterministic vm description and a Ubuntu preseed file de novo and am now making a local git repository, then spinning up the deterministic bitcoin build.  Lots of coffee and new thought patterns.
9042017-06-15T20:21:15  <instagibbs> Any new interface certainly should be sat/byte
9052017-06-15T20:21:45  <Chris_Stewart_5> ^
9062017-06-15T20:21:56  <wumpus> and then you have multiple different conventions on different RPC calls
9072017-06-15T20:23:38  *** RubenSomsen has quit IRC
9082017-06-15T20:24:58  <sipa> nanobitcoins per Hart
9092017-06-15T20:25:16  <wumpus> some of the output of getinfo is also blatantly deceptive by now, e.g. it shows one proxy, while every network can have its own proxy
9102017-06-15T20:25:27  <sipa> do we still show hashrate?
9112017-06-15T20:25:46  <wumpus> other things are only marginally useful; how many times have you wanted to know the the wallet version?
9122017-06-15T20:26:07  <wumpus> or "testnet":false, which is also false for regtest
9132017-06-15T20:26:29  <wumpus> sipa: no, that seems to be gone :
9142017-06-15T20:27:10  <instagibbs> new interface meaning RPC2.0 or whatever... not new calls
9152017-06-15T20:27:59  <gmaxwell> To be clear I am joking about luke hating freedom.
9162017-06-15T20:28:59  <wumpus> oh, I thought you were serious!
9172017-06-15T20:29:12  <cfields> jonasschnelli / gmaxwell / sipa: https://pastebin.com/raw/eKhEiJR3
9182017-06-15T20:29:20  <wumpus> https://github.com/bitcoin/bitcoin/pull/8843 rebased
9192017-06-15T20:29:38  <jonasschnelli> cfields: ahh.. that look like a beautiful girl
9202017-06-15T20:29:56  <cfields> :)
9212017-06-15T20:29:58  <jonasschnelli> cfields: I expected a code diff at the bottom.... :)
9222017-06-15T20:30:03  <cfields> guess that's what you had in mind, then?
9232017-06-15T20:30:08  <cfields> heh, 1 sec
9242017-06-15T20:30:19  <jonasschnelli> Yes. Have you tried to run it with the GUI?
9252017-06-15T20:30:20  <cfields> it's per-thread/per-mutex/per-lock
9262017-06-15T20:30:32  <cfields> no, just simple tests so far
9272017-06-15T20:30:58  <cfields> something about threadnames are busted, and it's not sorted yet. and the only threshold for display is that the time is non-zero
9282017-06-15T20:30:59  <jonasschnelli> To bed my wife calls me to bed.. I'll play with the code soon
9292017-06-15T20:31:05  <cfields> other than that, seems to work as expected
9302017-06-15T20:31:17  <cfields> ok, i'll push to a branch
9312017-06-15T20:31:25  <jonasschnelli> thanks
9322017-06-15T20:31:35  <cfields> np, nnite
9332017-06-15T20:31:47  <wumpus> cfields: nice!
9342017-06-15T20:32:16  *** Giszmo has joined #bitcoin-core-dev
9352017-06-15T20:34:20  <cfields> https://github.com/theuni/bitcoin/commit/be49a294a240ec81a901af1aaabbba2172d38dc1
9362017-06-15T20:35:06  <cfields> jonasschnelli: for tomorrow ^^
9372017-06-15T20:43:28  *** talmai has quit IRC
9382017-06-15T20:43:53  *** abpa has quit IRC
9392017-06-15T20:46:30  *** lichtamberg_ has joined #bitcoin-core-dev
9402017-06-15T20:48:34  <cfields> er, that should s/locked/contended/ everywhere. it's showing any non-zero time taken to grab a lock.
9412017-06-15T20:50:48  *** talmai has joined #bitcoin-core-dev
9422017-06-15T20:50:56  *** RubenSomsen has joined #bitcoin-core-dev
9432017-06-15T20:58:29  <bitcoin-git> [bitcoin] benma opened pull request #10607: scripted-diff: stop using the gArgs wrappers (master...gargs_wrappers) https://github.com/bitcoin/bitcoin/pull/10607
9442017-06-15T21:01:09  *** goatpig has quit IRC
9452017-06-15T21:07:55  *** Aaronvan_ is now known as AaronvanW
9462017-06-15T21:08:46  *** lichtamberg_ has left #bitcoin-core-dev
9472017-06-15T21:10:29  *** abpa has joined #bitcoin-core-dev
9482017-06-15T21:11:57  *** cryptapus is now known as cryptapus_afk
9492017-06-15T21:11:57  *** Dyaheon has quit IRC
9502017-06-15T21:12:21  *** talmai has quit IRC
9512017-06-15T21:12:55  *** Dyaheon has joined #bitcoin-core-dev
9522017-06-15T21:16:35  *** abpa has quit IRC
9532017-06-15T21:20:02  <ProfMac> pastebin or google docs?
9542017-06-15T21:20:26  *** F-DK has joined #bitcoin-core-dev
9552017-06-15T21:22:13  *** Giszmo has quit IRC
9562017-06-15T21:27:17  *** abpa has joined #bitcoin-core-dev
9572017-06-15T21:29:34  *** elkalamar has joined #bitcoin-core-dev
9582017-06-15T21:30:39  *** talmai has joined #bitcoin-core-dev
9592017-06-15T21:32:11  *** elkalamar has quit IRC
9602017-06-15T21:33:07  *** F-DK has quit IRC
9612017-06-15T21:35:38  *** Giszmo has joined #bitcoin-core-dev
9622017-06-15T21:36:28  <ProfMac> I am stuck trying to do a gitian build.  I have made a Pastebin  https://pastebin.com/eXPaQsLf
9632017-06-15T21:37:04  *** talmai has quit IRC
9642017-06-15T21:39:30  *** goatpig has joined #bitcoin-core-dev
9652017-06-15T21:44:47  *** Giszmo has quit IRC
9662017-06-15T22:06:32  *** Guyver2 has quit IRC
9672017-06-15T22:10:06  *** Dizzle has quit IRC
9682017-06-15T22:10:08  *** Chris_Stewart_5 has quit IRC
9692017-06-15T22:11:45  *** murch has quit IRC
9702017-06-15T22:25:11  *** timothy has joined #bitcoin-core-dev
9712017-06-15T22:26:54  *** nemgun has joined #bitcoin-core-dev
9722017-06-15T22:27:39  *** timothy has quit IRC
9732017-06-15T22:30:07  *** marcoagner has quit IRC
9742017-06-15T22:34:37  *** nemgun has quit IRC
9752017-06-15T22:35:24  *** Chris_Stewart_5 has joined #bitcoin-core-dev
9762017-06-15T22:38:35  *** chjj has quit IRC
9772017-06-15T22:39:07  *** jtimon has quit IRC
9782017-06-15T22:42:37  *** marcoagner has joined #bitcoin-core-dev
9792017-06-15T22:46:05  *** abpa has quit IRC
9802017-06-15T22:46:45  *** abpa has joined #bitcoin-core-dev
9812017-06-15T22:52:38  *** laurentmt has joined #bitcoin-core-dev
9822017-06-15T22:53:33  *** chjj has joined #bitcoin-core-dev
9832017-06-15T22:59:09  *** laurentmt has quit IRC
9842017-06-15T22:59:29  *** laurentmt has joined #bitcoin-core-dev
9852017-06-15T23:14:07  *** Giszmo has joined #bitcoin-core-dev
9862017-06-15T23:16:34  *** Dyaheon has quit IRC
9872017-06-15T23:18:07  *** Dyaheon has joined #bitcoin-core-dev
9882017-06-15T23:24:19  *** chjj has quit IRC
9892017-06-15T23:38:00  *** chjj has joined #bitcoin-core-dev
9902017-06-15T23:42:29  *** elkalamar has joined #bitcoin-core-dev
9912017-06-15T23:48:57  *** laurentmt has quit IRC