1 2017-06-15T00:03:45  *** nemgun has quit IRC
  2 2017-06-15T00:06:27  *** nemgun has joined #bitcoin-core-dev
  3 2017-06-15T00:11:44  *** jtimon has joined #bitcoin-core-dev
  4 2017-06-15T00:14:34  *** murch has quit IRC
  5 2017-06-15T00:15:03  *** jannes has quit IRC
  6 2017-06-15T00:23:35  *** Chris_Stewart_5 has quit IRC
  7 2017-06-15T00:24:52  *** goatturner has quit IRC
  8 2017-06-15T00:25:46  *** goatturner has joined #bitcoin-core-dev
  9 2017-06-15T00:26:51  *** goatturner has quit IRC
 10 2017-06-15T00:27:28  *** goatturner has joined #bitcoin-core-dev
 11 2017-06-15T00:54:57  *** Gnof has quit IRC
 12 2017-06-15T00:58:12  *** AaronvanW has quit IRC
 13 2017-06-15T01:00:06  *** AaronvanW has joined #bitcoin-core-dev
 14 2017-06-15T01:00:41  *** nemgun has quit IRC
 15 2017-06-15T01:03:48  *** goatturneer has joined #bitcoin-core-dev
 16 2017-06-15T01:04:38  *** AaronvanW has quit IRC
 17 2017-06-15T01:06:50  *** goatturner has quit IRC
 18 2017-06-15T01:30:05  *** dermoth has quit IRC
 19 2017-06-15T01:31:02  *** dermoth has joined #bitcoin-core-dev
 20 2017-06-15T01:33:11  *** Giszmo has quit IRC
 21 2017-06-15T01:39:42  *** Dyaheon has quit IRC
 22 2017-06-15T01:43:10  *** Dyaheon has joined #bitcoin-core-dev
 23 2017-06-15T01:45:17  *** unholymachine has quit IRC
 24 2017-06-15T01:49:57  *** dabura667_ has joined #bitcoin-core-dev
 25 2017-06-15T01:50:56  *** unholymachine has joined #bitcoin-core-dev
 26 2017-06-15T01:59:32  *** Ylbam has quit IRC
 27 2017-06-15T02:00:48  *** AaronvanW has joined #bitcoin-core-dev
 28 2017-06-15T02:05:14  *** AaronvanW has quit IRC
 29 2017-06-15T02:28:10  *** chjj has quit IRC
 30 2017-06-15T02:41:50  *** chjj has joined #bitcoin-core-dev
 31 2017-06-15T02:52:11  *** RubenSomsen has joined #bitcoin-core-dev
 32 2017-06-15T03:06:02  *** d9b4bef9 has quit IRC
 33 2017-06-15T03:07:08  *** d9b4bef9 has joined #bitcoin-core-dev
 34 2017-06-15T03:23:18  *** jamesob has joined #bitcoin-core-dev
 35 2017-06-15T03:43:24  *** bitwise has joined #bitcoin-core-dev
 36 2017-06-15T03:50:04  *** bitwise has quit IRC
 37 2017-06-15T03:54:56  *** apll has quit IRC
 38 2017-06-15T03:56:42  *** apll has joined #bitcoin-core-dev
 39 2017-06-15T04:01:28  *** AaronvanW has joined #bitcoin-core-dev
 40 2017-06-15T04:06:08  *** AaronvanW has quit IRC
 41 2017-06-15T04:08:23  *** altoz has quit IRC
 42 2017-06-15T04:09:27  *** jamesob has quit IRC
 43 2017-06-15T04:49:19  *** beatrootfarmer has joined #bitcoin-core-dev
 44 2017-06-15T04:53:08  *** goatturneer has quit IRC
 45 2017-06-15T05:17:43  *** [Author] has quit IRC
 46 2017-06-15T05:20:45  *** [Author] has joined #bitcoin-core-dev
 47 2017-06-15T06:02:17  *** AaronvanW has joined #bitcoin-core-dev
 48 2017-06-15T06:06:28  *** AaronvanW has quit IRC
 49 2017-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
 50 2017-06-15T06:13:28  <wumpus> (oh that's not true, fanquake replied)
 51 2017-06-15T06:14:17  *** Magma has quit IRC
 52 2017-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
 53 2017-06-15T06:17:04  <wumpus> but we can discuss at the meeting
 54 2017-06-15T06:20:37  *** goatturneer has joined #bitcoin-core-dev
 55 2017-06-15T06:22:55  *** Magma has joined #bitcoin-core-dev
 56 2017-06-15T06:23:31  *** nOgAnOo has joined #bitcoin-core-dev
 57 2017-06-15T06:23:50  *** beatrootfarmer has quit IRC
 58 2017-06-15T06:35:27  <gmaxwell> wumpus: you missed morcos commenting several hours earler about it.
 59 2017-06-15T06:35:52  <wumpus> gmaxwell: okay
 60 2017-06-15T06:38:46  * wumpus disables display of join/part events, it makes the backlog harder to keep track of
 61 2017-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!)
 62 2017-06-15T06:45:42  *** fanquake has joined #bitcoin-core-dev
 63 2017-06-15T06:49:38  *** RubenSomsen has quit IRC
 64 2017-06-15T06:53:01  *** d9b4bef9 has quit IRC
 65 2017-06-15T06:54:08  *** d9b4bef9 has joined #bitcoin-core-dev
 66 2017-06-15T07:00:58  *** riemann has quit IRC
 67 2017-06-15T07:03:04  *** AaronvanW has joined #bitcoin-core-dev
 68 2017-06-15T07:08:07  *** AaronvanW has quit IRC
 69 2017-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
 70 2017-06-15T07:09:53  <jonasschnelli> wumpus: you mean the comment is wrong?
 71 2017-06-15T07:10:20  <wumpus> no, I think it's correct, that's why I'm worried
 72 2017-06-15T07:10:30  <wumpus> if you can convince me it's wrong that would be great
 73 2017-06-15T07:10:31  <wumpus> :)
 74 2017-06-15T07:10:40  <jonasschnelli> okay... let me see
 75 2017-06-15T07:11:08  <wumpus> but unconditional lock-taking on cs_main should be avoided as much as possible in the GUI thread
 76 2017-06-15T07:11:45  <wumpus> and the timer isn't some separate thread, and neither is the signal handler for updateBalance
 77 2017-06-15T07:13:07  *** RubenSomsen has joined #bitcoin-core-dev
 78 2017-06-15T07:14:14  *** RubenSomsen has quit IRC
 79 2017-06-15T07:14:36  <jonasschnelli> wumpus: the PR 10251 would remove the timer... and..
 80 2017-06-15T07:14:38  *** RubenSomsen has joined #bitcoin-core-dev
 81 2017-06-15T07:14:47  <jonasschnelli> wumpus: the wallet would push balance updates to the GUI
 82 2017-06-15T07:15:12  <wumpus> so where would the balance computation happen?
 83 2017-06-15T07:15:34  *** riemann has joined #bitcoin-core-dev
 84 2017-06-15T07:15:38  <wumpus> functions like GetUnconfirmedWatchOnlyBalance are called from the GUI thread
 85 2017-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
 86 2017-06-15T07:16:24  <jonasschnelli> Hmm... yes. I see
 87 2017-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
 88 2017-06-15T07:17:03  <jonasschnelli> But only if a tx gets added or block connected/disconnected, right?
 89 2017-06-15T07:17:24  <wumpus> yes, which is very often
 90 2017-06-15T07:17:51  <wumpus> ideally the GUI thread would *never* hang itself based on notifications
 91 2017-06-15T07:17:55  <jonasschnelli> You think the TRY_LOCK in a poll routine performs better?
 92 2017-06-15T07:17:56  <wumpus> this is currently the case for that timer
 93 2017-06-15T07:18:11  <jonasschnelli> Yeah.. it should not be in the GUI thread
 94 2017-06-15T07:18:18  <wumpus> it optimizes for a different user experience - it's slower, but it never hangs the GUI thread
 95 2017-06-15T07:18:40  <wumpus> it wouldn't be a big deal if wallet functions didn't need cs_main
 96 2017-06-15T07:18:44  <wumpus> taking the wallet lock itself is ok
 97 2017-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
 98 2017-06-15T07:19:35  <jonasschnelli> That was my main intention (remove cs_main from GUI), but I guess I have made it worse
 99 2017-06-15T07:20:05  <jonasschnelli> I thought pushing would perform better then constant polling (even with a TRY_LOCK)
100 2017-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
101 2017-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
102 2017-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)
103 2017-06-15T07:21:36  <jonasschnelli> Can we recalculate the balance during MarkDirty (connect/disconnect block, etc.)?
104 2017-06-15T07:21:52  <wumpus> the whole point of the dirty stuff is not to do that
105 2017-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
106 2017-06-15T07:22:22  <jonasschnelli> The idea behind the dirty/caching is to no recalculate it at every call,.. right?
107 2017-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
108 2017-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?
109 2017-06-15T07:23:32  <jonasschnelli> I see..
110 2017-06-15T07:23:45  <jonasschnelli> [..] only compute it when necessary <-- make sense
111 2017-06-15T07:23:58  <jonasschnelli> the PR does that,.. but on the GUI thread
112 2017-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
113 2017-06-15T07:25:38  <jonasschnelli> wumpus: what about calling the getBalance() calls within a QThread and Q_EMIT balanceChanged once it's done?
114 2017-06-15T07:25:38  <wumpus> luke-jr: if we're unsure, it probably shouldn't be
115 2017-06-15T07:26:06  *** AaronvanW has joined #bitcoin-core-dev
116 2017-06-15T07:26:58  <wumpus> jonasschnelli: but then we're adding a thread
117 2017-06-15T07:27:47  <jonasschnelli> or use CScheduler?
118 2017-06-15T07:27:48  <wumpus> jonasschnelli: I do think eventually that's a better solution though: have a thread to communicate with the core
119 2017-06-15T07:28:03  <wumpus> never block in the GUI thread, have the GUI send commands/receive notifications from that thread
120 2017-06-15T07:28:33  <jonasschnelli> Yes. Some calls are synchronous though,.. they need redesign. But that must be done at some point
121 2017-06-15T07:28:35  <wumpus> but not a thread especially for updating balances, that's overkill, the current solution works ok
122 2017-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
123 2017-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
124 2017-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
125 2017-06-15T07:33:18  <wumpus> jonasschnelli: yes, sorry for being encouraging at first then backpedalling, but I hadn't seen this
126 2017-06-15T07:33:38  <jonasschnelli> Yes. Great review. I'm happy you brought that up
127 2017-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.
128 2017-06-15T07:34:59  <luke-jr> gmaxwell: or a lot of sigops in the generation tx possibly, but a very unlikely case
129 2017-06-15T07:35:08  <luke-jr> not sure even Eligius or p2pool would hit it
130 2017-06-15T07:36:33  <luke-jr> yeah, seems like it shouldn't be a practical problem thinking about it more
131 2017-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
132 2017-06-15T07:37:16  <wumpus> jonasschnelli: in this case that won't work due to lazy evaluation
133 2017-06-15T07:37:31  *** cysm_ has quit IRC
134 2017-06-15T07:37:35  <jonasschnelli> Yes. I see that point now...
135 2017-06-15T07:41:05  *** jtimon has quit IRC
136 2017-06-15T07:41:37  *** cysm has joined #bitcoin-core-dev
137 2017-06-15T07:50:57  *** arubi has quit IRC
138 2017-06-15T07:51:33  *** JackH has joined #bitcoin-core-dev
139 2017-06-15T07:51:34  *** arubi has joined #bitcoin-core-dev
140 2017-06-15T08:08:03  *** Dyaheon has quit IRC
141 2017-06-15T08:10:08  *** Dyaheon has joined #bitcoin-core-dev
142 2017-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
143 2017-06-15T08:34:26  *** laurentmt has joined #bitcoin-core-dev
144 2017-06-15T08:39:17  *** Gues_____ has joined #bitcoin-core-dev
145 2017-06-15T08:51:39  *** Gues_____ has quit IRC
146 2017-06-15T08:53:25  *** timothy has joined #bitcoin-core-dev
147 2017-06-15T08:54:20  *** BashCo has joined #bitcoin-core-dev
148 2017-06-15T09:17:57  *** laurentmt has quit IRC
149 2017-06-15T09:19:11  *** jannes has joined #bitcoin-core-dev
150 2017-06-15T09:27:08  *** beatrootfarmer has joined #bitcoin-core-dev
151 2017-06-15T09:30:41  *** goatturneer has quit IRC
152 2017-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
153 2017-06-15T09:48:43  *** Ylbam has joined #bitcoin-core-dev
154 2017-06-15T09:56:22  *** riemann has quit IRC
155 2017-06-15T10:12:07  *** Dyaheon has quit IRC
156 2017-06-15T10:13:48  *** Dyaheon has joined #bitcoin-core-dev
157 2017-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
158 2017-06-15T10:52:47  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/228c319a944b...7c72fb99afba
159 2017-06-15T10:52:47  <bitcoin-git> bitcoin/master e9cd778 Alex Morcos: Pass in smart fee slider value to coin control dialog...
160 2017-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...
161 2017-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
162 2017-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)
163 2017-06-15T10:57:17  <gribble> https://github.com/bitcoin/bitcoin/issues/10504 | GUI unresponsive during slow operations · Issue #10504 · bitcoin/bitcoin · GitHub
164 2017-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
165 2017-06-15T10:57:41  <wumpus> ryanofsky: no, hadn't seen yet, will take a look
166 2017-06-15T11:26:39  *** cryptapus_afk is now known as cryptapus
167 2017-06-15T11:39:08  <fanquake> wumpus going to build/release 14.2 tonight?
168 2017-06-15T11:41:14  <wumpus> fanquake: the release notes are so depressing now!
169 2017-06-15T11:41:44  <wumpus> but yes, I think we should just get it done
170 2017-06-15T11:41:50  <wumpus> 0.14.3 will be more exciting, I promise
171 2017-06-15T11:46:10  *** SopaXorzTaker has joined #bitcoin-core-dev
172 2017-06-15T11:46:13  <wumpus> so, one last time: did anyone hear of any issues with rc2?
173 2017-06-15T12:05:56  <paveljanik> silent night, ...
174 2017-06-15T12:06:13  <paveljanik> no issues
175 2017-06-15T12:08:18  <wumpus> agreed
176 2017-06-15T12:08:23  <wumpus> well, there we go
177 2017-06-15T12:09:03  <wumpus>  * [new tag]         v0.14.2 -> v0.14.2
178 2017-06-15T12:20:34  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/7c72fb99afba...c2ab38bdd57a
179 2017-06-15T12:20:34  <bitcoin-git> bitcoin/master 1bebfc8 Alex Morcos: Output Fee Estimation Calculations in CreateTransaction
180 2017-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...
181 2017-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
182 2017-06-15T12:37:35  *** dabura667_ has quit IRC
183 2017-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
184 2017-06-15T12:52:12  <fanquake> wumpus heh have to follow up with a quick 0.14.3 then.
185 2017-06-15T12:53:10  <wumpus> yes - 0.14.2 just has to get out because of the upnp vuln.
186 2017-06-15T12:54:52  *** apll has quit IRC
187 2017-06-15T12:55:10  *** RubenSomsen has quit IRC
188 2017-06-15T12:56:13  *** Chris_Stewart_5 has joined #bitcoin-core-dev
189 2017-06-15T12:56:37  *** apll has joined #bitcoin-core-dev
190 2017-06-15T13:02:21  *** apll has quit IRC
191 2017-06-15T13:03:00  *** apll has joined #bitcoin-core-dev
192 2017-06-15T13:15:41  *** RubenSomsen has joined #bitcoin-core-dev
193 2017-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...
194 2017-06-15T13:17:05  <jonasschnelli> The GUI responsiveness is ugly right now...
195 2017-06-15T13:17:51  <jonasschnelli> I wonder moving everything to ZMQ/RPC would be a viable approach (fully detach the GUI)
196 2017-06-15T13:18:11  <jonasschnelli> Ideally a clone of qt/ (to /qtdetatched)
197 2017-06-15T13:18:27  <jonasschnelli> Then it would allow to remove some functions which are not possible via ZMQ/RPC
198 2017-06-15T13:22:45  <ryanofsky> is that different than what I am doing with 10244?
199 2017-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
200 2017-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
201 2017-06-15T13:24:02  <wumpus> ryanofsky: but in itself that won't improve responsiveness, or does it also make callbacks asynchronous?
202 2017-06-15T13:26:05  <wumpus> I still have to look at it in detail, I think the idea makes sense though
203 2017-06-15T13:26:06  <ryanofsky> it doesn't affect responsiveness, though i do think the improved code organization would make improvements easier
204 2017-06-15T13:27:16  <ryanofsky> 10244 by itself doesn't change any behavior, all it does is replace direct calls with calls through interfaces
205 2017-06-15T13:27:25  <wumpus> right
206 2017-06-15T13:27:32  <wumpus> which makes sense
207 2017-06-15T13:27:38  *** mkarrer has quit IRC
208 2017-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
209 2017-06-15T13:29:15  <wumpus> why rename CFeeBumper to FeeBumper though?
210 2017-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
211 2017-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()
212 2017-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
213 2017-06-15T13:31:31  <wumpus> but why rename it?
214 2017-06-15T13:31:31  <ryanofsky> the other commits are almost entirely changes in src/qt and additions to src/ipc
215 2017-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
216 2017-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
217 2017-06-15T13:33:34  <ryanofsky> anyway happy to pull that commit into a separate pr
218 2017-06-15T13:34:00  <ryanofsky> happy to break it down
219 2017-06-15T13:34:10  <ryanofsky> but just know that one commit is an anomoly
220 2017-06-15T13:34:44  <ryanofsky> the other commits are uniform mechanical changes
221 2017-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
222 2017-06-15T13:35:09  <wumpus> ok, that's good
223 2017-06-15T13:35:21  <ryanofsky> ok, will pull that commit out
224 2017-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
225 2017-06-15T13:45:30  <ryanofsky> jonasschnelli, still curious to hear more about your qtdetached idea, and if 10244 would help with that
226 2017-06-15T13:46:20  <jonasschnelli> 10244 can probably help, but my first hurdle is: +2,217 −1,131
227 2017-06-15T13:46:21  <jonasschnelli> :)
228 2017-06-15T13:47:47  <jonasschnelli> ryanofsky: The general abstraction may be good... but it may be also possible though wallet-/clientmodel
229 2017-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
230 2017-06-15T13:48:16  <jonasschnelli> My (probably dumb) concept would be to have RPC calls in there...
231 2017-06-15T13:48:32  <ryanofsky> because all the other commits (except feebumper which i will pull out) follow the same pattern as first commit
232 2017-06-15T13:49:31  <jonasschnelli> I guess I would first tackle the asynchrony in the GUI layer...
233 2017-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
234 2017-06-15T13:50:00  <wumpus> my preferred priority would also be improving responsiveness first
235 2017-06-15T13:50:09  <jonasschnelli> Yes.
236 2017-06-15T13:50:24  <jonasschnelli> For that, we first need to analze what functions/locks are the worst
237 2017-06-15T13:50:29  <wumpus> though I think moving things to interfaces can help with that
238 2017-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
239 2017-06-15T13:50:46  <wumpus> as then it's clearer what the interface to the core thread should be
240 2017-06-15T13:50:48  <jonasschnelli> Turn those expensive calls into async and use a general NODE<->GUI thread?
241 2017-06-15T13:51:01  <ryanofsky> is there some way that my changes could make async improvments harder that i'm not seeing?
242 2017-06-15T13:51:21  <jonasschnelli> No... i don't say you change is not good
243 2017-06-15T13:51:32  <wumpus> not AFAIK
244 2017-06-15T13:51:38  <jonasschnelli> I'm just arguing about priorities
245 2017-06-15T13:51:54  <jonasschnelli> To get a +2,217 −1,131 change in, my experience tells me, ~0.5-1y
246 2017-06-15T13:53:46  <jonasschnelli> but ryanofsky change makes sense.. the additional layer *IPC* <-> *wallet/client-model* <-> GUI is probably okay...
247 2017-06-15T13:55:49  <ryanofsky> well hopefully it will take less than 0.5y to decide whether it's okay or not :)
248 2017-06-15T13:56:21  <jonasschnelli> hehe... I think the concept is good.
249 2017-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
250 2017-06-15T13:58:25  <jonasschnelli> Yes. Ideally... this would reduce some risks
251 2017-06-15T14:00:21  <wumpus> agree with doing it after the 0.15 split-off
252 2017-06-15T14:01:57  *** riemann has joined #bitcoin-core-dev
253 2017-06-15T14:02:43  <fanquake> to early for a 0.16 tag heh
254 2017-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
255 2017-06-15T14:04:11  <jonasschnelli> ryanofsky wumpus: is it only me or is the responsiveness in the current GUI worse then 0.13?
256 2017-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
257 2017-06-15T14:04:50  <fanquake> jonasschnelli in 0.14.2 or master?
258 2017-06-15T14:05:06  *** riemann has quit IRC
259 2017-06-15T14:05:16  <jonasschnelli> fanquake: I always run master and I often have some freezes...
260 2017-06-15T14:05:32  <jonasschnelli> I though my balance fix would reduce some... but sadly no
261 2017-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
262 2017-06-15T14:06:24  <jonasschnelli> Would a LogPrint (with microseconds) in our LOCK macro make sense to analyse the lock behavior better?
263 2017-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
264 2017-06-15T14:08:16  <fanquake> jonasschnelli during any particular actions?
265 2017-06-15T14:08:41  <jonasschnelli> fanquake: the freezes or the log print?
266 2017-06-15T14:08:44  <jonasschnelli> ryanofsky: Yes...
267 2017-06-15T14:08:53  <fanquake> the freezes
268 2017-06-15T14:09:20  <jonasschnelli> fanquake: Yes. Calling generate 1 followed by a sendtoaddress feels blockish
269 2017-06-15T14:10:47  <wumpus> I think there's too much overhead from logging to make that useful, also logging itself also locks
270 2017-06-15T14:11:00  <wumpus> so you'd have to exclude that; but you could try
271 2017-06-15T14:14:22  <jonasschnelli> I guess i'd use printf for a short hackish solution
272 2017-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.
273 2017-06-15T14:39:34  *** chjj has quit IRC
274 2017-06-15T14:45:55  <Lauda> aruby
275 2017-06-15T14:45:59  <Lauda> oops wrong channel
276 2017-06-15T14:48:29  *** arowser has quit IRC
277 2017-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
278 2017-06-15T15:05:37  *** Dyaheon has quit IRC
279 2017-06-15T15:06:01  *** Dyaheon has joined #bitcoin-core-dev
280 2017-06-15T15:07:57  *** chjj has joined #bitcoin-core-dev
281 2017-06-15T15:19:57  *** arowser has joined #bitcoin-core-dev
282 2017-06-15T15:29:50  *** fanquake has quit IRC
283 2017-06-15T15:33:33  *** JackH has quit IRC
284 2017-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
285 2017-06-15T15:47:37  *** Dizzle has joined #bitcoin-core-dev
286 2017-06-15T15:50:14  *** abpa has joined #bitcoin-core-dev
287 2017-06-15T16:12:24  *** PaulCapestany has quit IRC
288 2017-06-15T16:12:45  *** talmai has joined #bitcoin-core-dev
289 2017-06-15T16:16:48  *** PaulCapestany has joined #bitcoin-core-dev
290 2017-06-15T16:17:09  *** Guest___ has joined #bitcoin-core-dev
291 2017-06-15T16:39:03  *** Giszmo has joined #bitcoin-core-dev
292 2017-06-15T16:39:10  *** Guyver2 has joined #bitcoin-core-dev
293 2017-06-15T16:43:58  *** jtimon has joined #bitcoin-core-dev
294 2017-06-15T16:53:18  *** Guest___ has quit IRC
295 2017-06-15T17:00:13  *** ProfMac has joined #bitcoin-core-dev
296 2017-06-15T17:20:14  *** murch has joined #bitcoin-core-dev
297 2017-06-15T17:25:57  *** JackH has joined #bitcoin-core-dev
298 2017-06-15T17:34:56  *** davec has quit IRC
299 2017-06-15T17:35:53  <jnewbery> Is anyone using the 'comparison' part of the comparison test framework? Any objections to me retiring it? #10603
300 2017-06-15T17:35:54  <gribble> https://github.com/bitcoin/bitcoin/issues/10603 | Retire the comparison test framework · Issue #10603 · bitcoin/bitcoin · GitHub
301 2017-06-15T17:36:03  *** davec has joined #bitcoin-core-dev
302 2017-06-15T17:36:06  *** talmai has quit IRC
303 2017-06-15T17:36:22  *** Giszmo has quit IRC
304 2017-06-15T17:36:41  *** To7 has joined #bitcoin-core-dev
305 2017-06-15T17:40:55  *** talmai has joined #bitcoin-core-dev
306 2017-06-15T17:45:10  *** goatpig has quit IRC
307 2017-06-15T17:45:12  <wumpus> jnewbery: I'm fairly sure people are using it
308 2017-06-15T17:45:25  <wumpus> @(sdaftuar morcos BlueMatt)
309 2017-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
310 2017-06-15T17:46:23  <wumpus> okay
311 2017-06-15T17:46:30  <sdaftuar> the intention was to be able to compare many versions of the software
312 2017-06-15T17:46:43  <wumpus> but that isn't that useful in practice?
313 2017-06-15T17:46:49  <sdaftuar> but i don't think anyone (outside my proof of concept, way back when) actually tried to do that?
314 2017-06-15T17:47:44  <wumpus> would be a better question to ask then "should someone be doing those tests?"
315 2017-06-15T17:47:59  <sdaftuar> yeah i think that's the good question
316 2017-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
317 2017-06-15T17:48:25  <wumpus> I mean we could always add tests, maybe even in a travis crontab
318 2017-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
319 2017-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
320 2017-06-15T17:50:20  <sdaftuar> p2p-fullblocktest doesn't change very often though
321 2017-06-15T17:50:33  <sdaftuar> the risk seems like it'd be in consensus changes not yet deployed, eg something like segwit
322 2017-06-15T17:50:40  <sdaftuar> but those tests haven't changed much either
323 2017-06-15T17:52:37  *** timothy has quit IRC
324 2017-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
325 2017-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
326 2017-06-15T17:55:13  <jnewbery> The tests that use the comparison test framework are:
327 2017-06-15T17:55:13  <jnewbery> 10457
328 2017-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
329 2017-06-15T18:01:02  <gmaxwell> sdaftuar: we used it extensively in the past.
330 2017-06-15T18:01:18  <gmaxwell> rather the old bitcoinj tool. (to be clear)
331 2017-06-15T18:01:30  <sdaftuar> gmaxwell: right, we're still going to have p2p-fullblocktest
332 2017-06-15T18:01:39  <sdaftuar> which is approx. the same as the old bitcoinj tool
333 2017-06-15T18:02:01  <sdaftuar> the question is just, do we try to support/improve the ComparisonTestFramework thing as the implementation
334 2017-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
335 2017-06-15T18:02:56  <gmaxwell> OK.
336 2017-06-15T18:03:00  <sdaftuar> and working around p2p changes that the ComparisonTestFramework isn't designed for is pretty hacky
337 2017-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
338 2017-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.
339 2017-06-15T18:06:44  *** murch has quit IRC
340 2017-06-15T18:06:46  <sdaftuar> oh, yeah definitely agree with that
341 2017-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?
342 2017-06-15T18:07:48  <kanzure> branch coverage would be a good set of tests..
343 2017-06-15T18:07:58  <kanzure> er, script coverage. what is missing?
344 2017-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.
345 2017-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
346 2017-06-15T18:14:29  *** Giszmo has joined #bitcoin-core-dev
347 2017-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
348 2017-06-15T18:14:47  <gmaxwell> er. I don't agree (sadly)--
349 2017-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.
350 2017-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.
351 2017-06-15T18:17:25  <sdaftuar> that's true in theory, but i think that has mostly failed in practice
352 2017-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
353 2017-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
354 2017-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
355 2017-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
356 2017-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.
357 2017-06-15T18:19:59  <sipa> but that advantage does go away if you're just running a static scenario
358 2017-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)
359 2017-06-15T18:20:07  <gmaxwell> It's an orthorgonal and very powerful method of testing.
360 2017-06-15T18:20:08  *** Giszmo has quit IRC
361 2017-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
362 2017-06-15T18:20:11  <wumpus> right, if you can somehow generate random scenarios, it'd be useful
363 2017-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
364 2017-06-15T18:20:18  <gmaxwell> And yes, for static tests is not useful IMO.
365 2017-06-15T18:20:28  *** goatpig has joined #bitcoin-core-dev
366 2017-06-15T18:20:29  *** talmai has quit IRC
367 2017-06-15T18:20:31  <wumpus> yes, then it's like fuzzing two implementations at the same time and comparing
368 2017-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)
369 2017-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
370 2017-06-15T18:21:33  <gmaxwell> This is, e.g. how we tested the DER parser in libsecp256k1-- a harness with three implementations.
371 2017-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
372 2017-06-15T18:22:22  <ProfMac> Thanks wumpus.  I am doing a 2nd install from scratch, yesterday I could not get it to work.
373 2017-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
374 2017-06-15T18:23:37  <gmaxwell> Would that mean moving the test stimulus for those things from p2p to rpc?
375 2017-06-15T18:23:44  <sdaftuar> no, it shouldn't
376 2017-06-15T18:23:48  <gmaxwell> okay!
377 2017-06-15T18:24:25  <wumpus> that would mean that the comparison test code doesn't get tested itself anymore, and thus will code-rot
378 2017-06-15T18:24:36  <sdaftuar> wumpus: i fear it already has rotted :(
379 2017-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?
380 2017-06-15T18:24:56  <wumpus> ok...
381 2017-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
382 2017-06-15T18:27:14  *** talmai has joined #bitcoin-core-dev
383 2017-06-15T18:35:12  *** jannes has quit IRC
384 2017-06-15T18:43:17  *** talmai has quit IRC
385 2017-06-15T18:46:10  *** wangchun has quit IRC
386 2017-06-15T18:49:23  *** laurentmt has joined #bitcoin-core-dev
387 2017-06-15T18:50:56  <gmaxwell> meeting in 10 minutes.
388 2017-06-15T18:55:13  *** lichtamberg_ has joined #bitcoin-core-dev
389 2017-06-15T18:57:15  *** laurentmt has quit IRC
390 2017-06-15T18:58:11  *** twistedline has quit IRC
391 2017-06-15T19:00:04  <jonasschnelli> hi
392 2017-06-15T19:00:07  <wumpus> #startmeeting
393 2017-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.
394 2017-06-15T19:00:07  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
395 2017-06-15T19:00:24  <wumpus> PSA: v0.14.2 has been tagged, please start your gitian builders
396 2017-06-15T19:00:30  <wumpus> topics?
397 2017-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
398 2017-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
399 2017-06-15T19:00:36  <kanzure> hi.
400 2017-06-15T19:00:40  <paveljanik> Hi
401 2017-06-15T19:00:41  <achow101> hi
402 2017-06-15T19:00:42  <cfields> jonasschnelli: i just wrote a quick mutex locktime reporter, ping me after meeting if you'd like to discuss
403 2017-06-15T19:00:44  <sdaftuar> here
404 2017-06-15T19:00:45  <sipa> yow
405 2017-06-15T19:00:49  <gmaxwell> (I guess I should update my list)
406 2017-06-15T19:00:57  <jonasschnelli> cfields: awesome!
407 2017-06-15T19:01:03  <sipa> wumpus: you're requesting the presence of 2 instagibbses?
408 2017-06-15T19:01:07  <gmaxwell> cfields: finally someone did that, awesome.
409 2017-06-15T19:01:20  <cfields> well it's very dumb, but it's something :)
410 2017-06-15T19:01:21  <wumpus> sipa: yes!
411 2017-06-15T19:01:34  <sipa> cfields: -DDEBUG_LOCKCONTENTION?
412 2017-06-15T19:01:38  <luke-jr> lol
413 2017-06-15T19:01:38  <jonasschnelli> cfields: dumb is good
414 2017-06-15T19:01:51  <wumpus> #topic high priority for review
415 2017-06-15T19:02:04  <gmaxwell> https://github.com/bitcoin/bitcoin/projects/8
416 2017-06-15T19:02:08  <sipa> #10148 plz *puppyeyes*
417 2017-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
418 2017-06-15T19:02:26  <wumpus> 10148 is already on the list, I'm testing it
419 2017-06-15T19:02:30  <sipa> cool
420 2017-06-15T19:02:33  <sdaftuar> i'm working on an rpc test as well
421 2017-06-15T19:02:39  <sipa> sdaftuar: awesome!
422 2017-06-15T19:02:42  <sipa> can i help?
423 2017-06-15T19:03:00  <sdaftuar> i'll let you know!
424 2017-06-15T19:03:05  <sdaftuar> i think i almos thave it
425 2017-06-15T19:03:12  *** twistedline has joined #bitcoin-core-dev
426 2017-06-15T19:03:56  *** talmai has joined #bitcoin-core-dev
427 2017-06-15T19:04:08  <sipa> having thought more about it, i don't think #10339 will have any significant performance impact
428 2017-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
429 2017-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?
430 2017-06-15T19:04:48  <jonasschnelli> RPC support would be great
431 2017-06-15T19:04:53  <sipa> agree
432 2017-06-15T19:04:55  <jonasschnelli> You mean addressing wallet via RPC endpoint?
433 2017-06-15T19:04:55  <achow101> luke-jr: yes please
434 2017-06-15T19:05:08  <luke-jr> jonasschnelli: I mean each username has a different single wallet
435 2017-06-15T19:05:22  <jonasschnelli> luke-jr: hmm...
436 2017-06-15T19:05:24  <wumpus> sipa: ok, removing it from high priority then
437 2017-06-15T19:05:27  <jonasschnelli> I'd prefere endpoints
438 2017-06-15T19:05:39  <jonasschnelli> AUTH for wallet switching seems hackish
439 2017-06-15T19:05:41  <luke-jr> jonasschnelli: endpoints can be done later; I'm just trying to get the simplest stuff done first
440 2017-06-15T19:05:48  *** Dyaheon has quit IRC
441 2017-06-15T19:05:50  <jonasschnelli> endpoint is 10lines of code
442 2017-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
443 2017-06-15T19:05:57  <jonasschnelli> I can post it to you later
444 2017-06-15T19:06:00  <luke-jr> jonasschnelli: not securely ;p
445 2017-06-15T19:06:10  <luke-jr> jonasschnelli: I don't want JoinMarket to have access to my main wallet
446 2017-06-15T19:06:21  <jonasschnelli> there is no security in our RPC implementation :/
447 2017-06-15T19:06:24  <sipa> yay, wallet ACLs
448 2017-06-15T19:06:25  * sipa hides
449 2017-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
450 2017-06-15T19:06:31  <achow101> you could do some combination of both?
451 2017-06-15T19:06:31  <luke-jr> wumpus: different username is also a simple change to the URI
452 2017-06-15T19:06:43  <wumpus> we already support different usernames/passwords
453 2017-06-15T19:06:49  <jonasschnelli> use a passphase as wallet name
454 2017-06-15T19:06:55  <wumpus> it's an authentication feature, should not affect the wallet
455 2017-06-15T19:06:56  <jonasschnelli> same security as basic auth?
456 2017-06-15T19:07:23  <sipa> i think the first step should be either endpoint or a generic optional named parameter to select the wallet
457 2017-06-15T19:07:24  <luke-jr> wumpus: I see no distinction
458 2017-06-15T19:07:28  *** talmai has quit IRC
459 2017-06-15T19:07:28  <wumpus> sipa: yes
460 2017-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.
461 2017-06-15T19:07:34  <achow101> sipa: agreed
462 2017-06-15T19:07:43  <sipa> the choice of which user can access which wallets is orthogonal, i think
463 2017-06-15T19:07:50  <wumpus> gmaxwell: which is easy, the underlying stuff (rpcproxy, libevent) obviously supports it
464 2017-06-15T19:07:53  *** Dyaheon has joined #bitcoin-core-dev
465 2017-06-15T19:07:55  <sipa> but i would prefer not to tie users to wallets at the auth level
466 2017-06-15T19:07:57  <jonasschnelli> gmaxwell: yes Indeed
467 2017-06-15T19:08:48  <jonasschnelli> first stage, each user should be able to access each wallet....
468 2017-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.
469 2017-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
470 2017-06-15T19:08:54  <gmaxwell> (eventually)
471 2017-06-15T19:08:57  <luke-jr> jonasschnelli: no -.-
472 2017-06-15T19:09:11  <wumpus> gmaxwell: I really think that's going too far
473 2017-06-15T19:09:23  <gmaxwell> then why are we bothering?
474 2017-06-15T19:09:27  <wumpus> securing RPC for multiple users is absolutely a nightmare
475 2017-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
476 2017-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
477 2017-06-15T19:09:51  <sipa> wumpus: i think it's inevitable that we'll need that
478 2017-06-15T19:09:53  <wumpus> anyhow a security layer could always be added could be later if endpoint-based multiwallet is in place
479 2017-06-15T19:09:58  <wumpus> sipa: I think it's a mistake
480 2017-06-15T19:10:05  <wumpus> sipa: just like accounts was
481 2017-06-15T19:10:13  <wumpus> it's something that bitcoind shouldn't handle
482 2017-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.
483 2017-06-15T19:10:30  <luke-jr> jonasschnelli: no?
484 2017-06-15T19:10:59  <sipa> gmaxwell: i think that's an interesting use case; i don't think it should be the first step
485 2017-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
486 2017-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
487 2017-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)
488 2017-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).
489 2017-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
490 2017-06-15T19:12:20  <luke-jr> wumpus: then why do we have auth at all?
491 2017-06-15T19:12:32  <jonasschnelli> I really think we should keep hands away from multi-user/multi-wallet setup
492 2017-06-15T19:12:34  <wumpus> luke-jr: to gain access
493 2017-06-15T19:12:47  <wumpus> jonasschnelli: me too... seems something that needs to be a level on top, not handled by bitcoind itself
494 2017-06-15T19:12:55  <jonasschnelli> For now we should focus on single-user/multi-wallet (1:n)
495 2017-06-15T19:13:15  <jonasschnelli> n:n smells like a account-like-problem-re-incarnation
496 2017-06-15T19:13:20  <wumpus> anyhow if we have endpoint multi-wallet access, it'spossible to slap on a wallet/user auth mapping later
497 2017-06-15T19:13:34  <luke-jr> or vice-versa..
498 2017-06-15T19:13:38  <wumpus> that's "just" a matter of access control
499 2017-06-15T19:13:44  <jonasschnelli> yes. n:n may make sense.. but endpoint first seems much more logical
500 2017-06-15T19:13:48  <wumpus> yes
501 2017-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.
502 2017-06-15T19:14:06  <jonasschnelli> gmaxwell: Yes. Not directly related.
503 2017-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
504 2017-06-15T19:14:13  <wumpus> I just think that making bitcoind multi-user is a grave mistake
505 2017-06-15T19:14:18  <wumpus> but I"ll shut up about it...
506 2017-06-15T19:14:24  <jonasschnelli> I think the complexity is huge,.. leads to permission groups, etc.
507 2017-06-15T19:14:35  <wumpus> yes, exactly, some people wnat everything in bitcoind
508 2017-06-15T19:14:44  <gmaxwell> jonasschnelli: what? no it doesn't.
509 2017-06-15T19:14:47  <sipa> well it seems that multiple people want multiwallet for multiple reasons
510 2017-06-15T19:14:53  <sipa> i don't think that's a problem
511 2017-06-15T19:15:04  <sipa> and should not be a blocker for the basic functionality
512 2017-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
513 2017-06-15T19:15:11  <wumpus> making bitcoind some kind of systemd
514 2017-06-15T19:15:11  <jonasschnelli> if we start to use n:n, enterprises will probably use it for multi-user wallet backends...
515 2017-06-15T19:15:32  <luke-jr> wumpus: user:wallet makes a split off later simpler
516 2017-06-15T19:15:33  <jonasschnelli> and removing – if it gets to complicated – is hard or even impossible (like the accounting)
517 2017-06-15T19:15:34  <wumpus> jonasschnelli: yes exactly... and what if there's a bug in that
518 2017-06-15T19:15:37  <luke-jr> endpoints makes splitting off later complex
519 2017-06-15T19:15:48  *** chjj has quit IRC
520 2017-06-15T19:15:54  <wumpus> it moves all the (perceived) responsiblity for managing multi-user setups secure to us
521 2017-06-15T19:16:00  <jonasschnelli> luke-jr: endpoint would even work if each wallet runs in its own process
522 2017-06-15T19:16:04  <gmaxwell> How do we split wallets if we are using endpoints?
523 2017-06-15T19:16:08  <jonasschnelli> (though auth probably also)
524 2017-06-15T19:16:17  <luke-jr> jonasschnelli: huh? not really..?
525 2017-06-15T19:16:23  <jtimon> but multi-wallet doesn't imply multi-user, does it?
526 2017-06-15T19:16:25  <wumpus> gmaxwell: what do you mean with "split wallets"?
527 2017-06-15T19:16:36  <gmaxwell> split wallets int oseperate processes
528 2017-06-15T19:16:51  <wumpus> gmaxwell: different wallets have different URLs then
529 2017-06-15T19:17:04  <wumpus> gmaxwell: so it's just another change: change the port...
530 2017-06-15T19:17:17  <luke-jr> wumpus: ALL of these options are simple URI changes..
531 2017-06-15T19:17:27  <achow101> how would different endpoints work with bitcoin-cli or the debug console?
532 2017-06-15T19:17:28  <luke-jr> although some tools don't allow changing the URI right now
533 2017-06-15T19:17:31  <wumpus> versus
534 2017-06-15T19:17:39  <gmaxwell> achow101: thats why it isn't ten lines of code.
535 2017-06-15T19:17:42  <jonasschnelli> achow101: you can add: -wallet=filename
536 2017-06-15T19:17:55  <wumpus> achow101: just add an option
537 2017-06-15T19:18:03  <sipa> s/filename/name/
538 2017-06-15T19:18:09  <jonasschnelli> endpoints in bitcoin-cli is not really complex...
539 2017-06-15T19:18:10  <luke-jr> achow101: debug console isn't via RPC anyway
540 2017-06-15T19:18:11  <jonasschnelli> sipa: yes
541 2017-06-15T19:18:14  <achow101> but it certainly wouldn't work with debug console
542 2017-06-15T19:18:14  <gmaxwell> sipa +1
543 2017-06-15T19:18:39  <wumpus> as for debug console: you could ask the same question about authentication
544 2017-06-15T19:18:40  <gmaxwell> luke-jr: I think we'll need endpoints in any case regardless of auth to set a default.
545 2017-06-15T19:18:52  <luke-jr> gmaxwell: maybe
546 2017-06-15T19:18:52  <jonasschnelli> achow101: the whole GUI has no multiwallet interface
547 2017-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.
548 2017-06-15T19:18:59  <wumpus> debug console is not authenticated at all - so adding endpoint/auth support is likely the similar amount of work
549 2017-06-15T19:19:24  <wumpus> if access control is implemented, a single user could want to have access to multiple wallets anyhow
550 2017-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.
551 2017-06-15T19:19:31  <wumpus> so user=wallet is a bad abstraction
552 2017-06-15T19:19:36  <luke-jr> I already have the GUI done BTW
553 2017-06-15T19:19:43  <gmaxwell> yes you'll want to have access to multiple wallets from a single user regardless.
554 2017-06-15T19:19:44  <luke-jr> it's just based on the RPC branch
555 2017-06-15T19:19:51  <sipa> luke-jr: how does it let you select the wallet?
556 2017-06-15T19:19:52  <gmaxwell> luke-jr: how does gui handle the debug console?
557 2017-06-15T19:19:56  <jonasschnelli> A very hackish (and very old) endpoint impl
558 2017-06-15T19:19:57  <luke-jr> sipa: comboboxes
559 2017-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
560 2017-06-15T19:20:05  <luke-jr> one in the main window, and one in the debug window
561 2017-06-15T19:20:20  <gmaxwell> sounds more or less okay.
562 2017-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.
563 2017-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
564 2017-06-15T19:21:05  <gmaxwell> see above
565 2017-06-15T19:21:10  *** laurentmt has joined #bitcoin-core-dev
566 2017-06-15T19:21:21  <luke-jr> gmaxwell: it's more code, and not done yet
567 2017-06-15T19:21:23  <wumpus> well the default wallet could depend on the user, I don't really care
568 2017-06-15T19:21:31  <luke-jr> I can implement it, but IMO it will delay things to make it the next step
569 2017-06-15T19:21:32  <wumpus> though I'd prefer to get rid of 'default wallet', in time
570 2017-06-15T19:21:35  <jonasschnelli> maybe the GUI should have a node window (network, peers) and a wallet-window per wallet...
571 2017-06-15T19:21:52  <sipa> jonasschnelli: ugh
572 2017-06-15T19:21:58  <luke-jr> the user=>wallet stuff is literally done and well-tested (in Knots), just needs to be rebased
573 2017-06-15T19:21:59  <gmaxwell> jonasschnelli: that doesn't sound like a good UI. :P
574 2017-06-15T19:22:07  <sipa> jonasschnelli: /me remembers browsers before tabs
575 2017-06-15T19:22:08  <gmaxwell> at least not mandatory.
576 2017-06-15T19:22:13  <gmaxwell> what sipa says. :P
577 2017-06-15T19:22:20  <jonasschnelli> yeah... I like windows.. but I'm pretty alone nowadays with that
578 2017-06-15T19:22:31  <jonasschnelli> Yeah. Tabs make more sense I guess.
579 2017-06-15T19:22:37  <sipa> anyway, separate discussion
580 2017-06-15T19:22:52  * jonasschnelli think sipa certainly browses with lynx
581 2017-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
582 2017-06-15T19:23:15  <jonasschnelli> sipa: +1
583 2017-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.
584 2017-06-15T19:23:21  <achow101> sipa: ack
585 2017-06-15T19:23:22  <wumpus> sipa: same for me
586 2017-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?
587 2017-06-15T19:24:07  <achow101> probably
588 2017-06-15T19:24:09  <gmaxwell> luke-jr: does it also support one user with many wallets?
589 2017-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
590 2017-06-15T19:24:20  <gmaxwell> what wumpus says.
591 2017-06-15T19:24:28  <luke-jr> gmaxwell: the current code does not, but there's no reason the endpoints couldn't add that
592 2017-06-15T19:24:29  <wumpus> I really think we should just start with endpoints as sipa says
593 2017-06-15T19:24:52  <jnewbery> Isn't rpcuser deprecated anyway?
594 2017-06-15T19:24:54  <jonasschnelli> Yes. Let's start with endpoint.. I'll can write it next week because I already did once...
595 2017-06-15T19:24:57  <wumpus> I'm not going to NACK anything that makes progress though
596 2017-06-15T19:24:59  <luke-jr> jnewbery: it's rpcauth
597 2017-06-15T19:25:00  <sipa> jnewbery: rpcauth isn't
598 2017-06-15T19:25:01  <jonasschnelli> *I can
599 2017-06-15T19:25:29  <gmaxwell> jnewbery: rpcuser is, but this is rpcauth (rpcuser doesn't even have multiple users)
600 2017-06-15T19:25:29  <jtimon> jnewbery: is rpcuser deprecated? since when?
601 2017-06-15T19:25:38  <gmaxwell> jtimon: a year?
602 2017-06-15T19:25:39  <achow101> jtimon: it's deprecated since a long time ago
603 2017-06-15T19:25:42  <gmaxwell> it prints out a notice!
604 2017-06-15T19:25:50  <wumpus> rpcuser is deprecated, people are encouraged to use either rpcauth or cookie auth
605 2017-06-15T19:25:59  <wumpus> we won't remove it just yet ofcourse
606 2017-06-15T19:26:09  <jtimon> oh, deprecated as in "we want to remove this", but it actually still works, no?
607 2017-06-15T19:26:14  <paveljanik> 26 minutes...
608 2017-06-15T19:26:14  <luke-jr> right
609 2017-06-15T19:26:15  <achow101> yes
610 2017-06-15T19:26:17  <wumpus> that is what deprecated means, yes
611 2017-06-15T19:26:28  <jtimon> yeah, sorry
612 2017-06-15T19:26:29  <instagibbs> paveljanik, 34 to go :P
613 2017-06-15T19:26:43  <wumpus> paveljanik: what's so special about 26?
614 2017-06-15T19:26:49  <sipa> jonasschnelli: any progress on GUI for database upgrade?
615 2017-06-15T19:26:58  <wumpus> #topic GUI for database upgrade?
616 2017-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)
617 2017-06-15T19:27:00  <jonasschnelli> sipa: I sadly had only little time last and this week
618 2017-06-15T19:27:07  <luke-jr> wumpus: 21 is half of 42
619 2017-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)
620 2017-06-15T19:27:42  <sipa> jonasschnelli: it's not hard to estimate as txids are randomly distributed
621 2017-06-15T19:27:51  <gmaxwell> so you just look at the txid...
622 2017-06-15T19:27:54  <sipa> i can add code for that
623 2017-06-15T19:27:55  <gmaxwell> they're done in order.
624 2017-06-15T19:28:07  <gmaxwell> if it's at 0x01... then it's done 1/256 of it.
625 2017-06-15T19:28:12  <sipa> txid -> arith_uint256 -> * 100/2^256
626 2017-06-15T19:28:23  *** Aaronvan_ has joined #bitcoin-core-dev
627 2017-06-15T19:28:29  <jonasschnelli> Okay. The rest is simple (debug.log non newline [10%] progress   /  GUI splash screen progress with abort)
628 2017-06-15T19:28:39  <wumpus> BTW: jnewbery rebased the label API pull (#7729), a lot of thanks for that
629 2017-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
630 2017-06-15T19:28:50  <sipa> jonasschnelli: i'll write code for the progress estimation
631 2017-06-15T19:29:08  <jonasschnelli> sipa: Okay. Pass me over a commit and I'll finish the rest
632 2017-06-15T19:29:11  *** chjj has joined #bitcoin-core-dev
633 2017-06-15T19:29:14  <jnewbery> wumpus: no problem. I wanted to test drive it :)
634 2017-06-15T19:29:59  *** AaronvanW has quit IRC
635 2017-06-15T19:30:38  <gmaxwell> wumpus: \O/ on the label rebase.
636 2017-06-15T19:30:53  <wumpus> must have been a nightmare
637 2017-06-15T19:31:27  <wumpus> any other topics?
638 2017-06-15T19:31:51  <jonasschnelli> what about the rpc splitting,... has that been discussed so far?
639 2017-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
640 2017-06-15T19:32:06  <jonasschnelli> signrawwithkey, etc.?
641 2017-06-15T19:32:09  <wumpus> rpc splitting?
642 2017-06-15T19:32:26  <achow101> the PRs I made to unfuck signrawtx and validateaddress
643 2017-06-15T19:32:42  <wumpus> ah https://github.com/bitcoin/bitcoin/pull/10583
644 2017-06-15T19:32:47  <wumpus> #10583
645 2017-06-15T19:32:48  <jonasschnelli> achow101: yes. Those..
646 2017-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
647 2017-06-15T19:33:04  <wumpus> #topic split off wallet functionality from mixed wallet/non-wallet RPC calls
648 2017-06-15T19:33:08  <wumpus> or something
649 2017-06-15T19:33:22  <achow101> #10570
650 2017-06-15T19:33:23  <gribble> https://github.com/bitcoin/bitcoin/issues/10570 | [RPC] Split signrawtransaction into multiple distinct RPCs · Issue #10570 · bitcoin/bitcoin · GitHub
651 2017-06-15T19:33:45  <wumpus> concept ack (haven't gotten around to reviewing anything)
652 2017-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.
653 2017-06-15T19:33:59  <morcos> i'm here now.. haven't caught up on backlog
654 2017-06-15T19:34:06  <sipa> it breaks compatibility with a never documented or advertized feature :)
655 2017-06-15T19:34:07  <wumpus> well we could allow both, for one major version
656 2017-06-15T19:34:10  <gmaxwell> Though we might want to rename the old calls at the same time. (a suggestion for discussion)
657 2017-06-15T19:34:20  <sipa> (concatenating multiple tx hex strings, yuck)
658 2017-06-15T19:34:25  <wumpus> wut?
659 2017-06-15T19:34:32  <wumpus> ok, we're talking about different things
660 2017-06-15T19:34:37  <instagibbs> aside from mixing wallet/nonwallet, what's the issue with validateaddress?
661 2017-06-15T19:34:38  <gmaxwell> sipa: it was certantly advertised and known.
662 2017-06-15T19:34:40  <wumpus> I mean validateaddress/getaddressinfo
663 2017-06-15T19:34:42  <instagibbs> (or is that the issue)
664 2017-06-15T19:34:50  <achow101> instagibbs: that's the issue
665 2017-06-15T19:34:51  <sipa> wumpus: ah, i'm talking about signrawtransaction
666 2017-06-15T19:34:52  <gmaxwell> wumpus: he's talking about the signraw split to create the combine call.
667 2017-06-15T19:34:52  <wumpus> instagibbs: that is the issue
668 2017-06-15T19:34:57  <instagibbs> ok, are we killing off getinfo then too:
669 2017-06-15T19:34:59  <instagibbs> :)
670 2017-06-15T19:35:05  <achow101> hopefully :D
671 2017-06-15T19:35:10  *** chjj has quit IRC
672 2017-06-15T19:35:11  <wumpus> instagibbs: yes, but that's not the topic now
673 2017-06-15T19:35:16  <gmaxwell> I would miss getinfo. all the other commands take more typing. :P
674 2017-06-15T19:35:17  <wumpus> we're already confusing two things, let's add more!
675 2017-06-15T19:35:25  <gmaxwell> wumpus: okay!
676 2017-06-15T19:35:25  <instagibbs> eh, we're talking about blowing away validateaddress as is, sorry
677 2017-06-15T19:35:26  <wumpus> gmaxwell: hey I have a pull that implements it client side
678 2017-06-15T19:35:46  <gmaxwell> wumpus: lol.  can you name the rpc call "gi" :P even less typing.
679 2017-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
680 2017-06-15T19:35:55  <jonasschnelli> But I see the point with getting the UTXOs
681 2017-06-15T19:36:01  <sipa> let's rename all RPCs to get*info... for example s/sendtoaddress/getnewpaymenttxid/
682 2017-06-15T19:36:08  <gmaxwell> jonasschnelli: we need the UTXOs or its all awfulsauce.
683 2017-06-15T19:36:11  <instagibbs> sipa, lol
684 2017-06-15T19:36:16  <wumpus> #8843
685 2017-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
686 2017-06-15T19:36:18  <luke-jr> lol
687 2017-06-15T19:36:28  <luke-jr> getsignedtransaction
688 2017-06-15T19:36:31  <jonasschnelli> gmaxwell: I though the node RPC can spitout what you need to pass it into bitcoin-tx or so...
689 2017-06-15T19:36:48  <jonasschnelli> but I know... very inconvinient
690 2017-06-15T19:36:48  <luke-jr> getthistransactionbroadcast
691 2017-06-15T19:36:50  <luke-jr> :p
692 2017-06-15T19:36:51  <sipa> jonasschnelli: sure it can; it's just more convenient to not need that
693 2017-06-15T19:36:51  <wumpus> eventually closed it because the only person responding was luke-jr and he kept arguing against it
694 2017-06-15T19:37:08  <gmaxwell> jonasschnelli: and that adds steps to the process.. which is already long enough that it's prone to error.
695 2017-06-15T19:37:14  <sipa> jonasschnelli: it's called listunspent
696 2017-06-15T19:37:16  <jonasschnelli> It's just another source how people can shoot themselfs with exposing priv keys
697 2017-06-15T19:37:28  <gmaxwell> luke-jr: why do you hate freedom?
698 2017-06-15T19:37:32  <luke-jr> gmaxwell: !⁈
699 2017-06-15T19:37:35  <gmaxwell> haha
700 2017-06-15T19:37:52  *** murch has joined #bitcoin-core-dev
701 2017-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)
702 2017-06-15T19:38:54  <instagibbs> sipa, ok I see the motivation there
703 2017-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.
704 2017-06-15T19:39:01  <luke-jr> gmaxwell: I didn't even NACK it :o
705 2017-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
706 2017-06-15T19:39:21  <luke-jr> gmaxwell: use the GUI for that! :p
707 2017-06-15T19:39:31  <sipa> jonasschnelli: i have a vague proposal for that too, but it's more complicated
708 2017-06-15T19:39:37  <gmaxwell> luke-jr: again, why do you hate freedom? :P
709 2017-06-15T19:39:50  <sipa> jonasschnelli: and involves a new format for partially signed transactions...
710 2017-06-15T19:39:57  <wumpus> gmaxwell: anyhow we can easily reopen and rebase that PR, bitcoin-cli hardly changed since then
711 2017-06-15T19:40:01  <sipa> wumpus: ack
712 2017-06-15T19:40:03  <jonasschnelli> sipa: that contains everything you need to sign?
713 2017-06-15T19:40:08  <luke-jr> gmaxwell: make a shell alias to all the calls ;)
714 2017-06-15T19:40:23  <gmaxwell> it's so much easier to have a signing blob thing post segwit. :(
715 2017-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
716 2017-06-15T19:40:39  <sipa> jonasschnelli: yes, contains amounts, change info, prevouts being spent, ...
717 2017-06-15T19:40:40  <wumpus> yes, let's activate segwit
718 2017-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.
719 2017-06-15T19:40:47  * sipa revives segnet
720 2017-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)
721 2017-06-15T19:41:11  <luke-jr> we could just leave getinfo how it is ;)
722 2017-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)
723 2017-06-15T19:41:28  <sipa> jonasschnelli: pre-segwit however, it also needs to contain the full spent transactions :(
724 2017-06-15T19:41:33  <luke-jr> bitcoin-cli -getinfo only handles 1 sortof-use-case, and leaves the other 2 supported use cases unaddressed
725 2017-06-15T19:41:35  <sipa> gmaxwell: agree
726 2017-06-15T19:41:37  <wumpus> after promising to deprecate it for years... yeah, of course....
727 2017-06-15T19:41:52  <sipa> (disclaimer: achow101'w my intern this summer, i asked him to work on those)
728 2017-06-15T19:42:02  <jonasschnelli> sipa: [full spent transactions], I guess that's okay.
729 2017-06-15T19:42:25  <sipa> jonasschnelli: bitcoind unfortunately can't do that generically (you need the wallet for that)
730 2017-06-15T19:42:25  <wumpus> getinfo is going away, there's no going back now
731 2017-06-15T19:42:44  <luke-jr> let's add a getallinfo then
732 2017-06-15T19:42:46  <luke-jr> /s
733 2017-06-15T19:42:47  <wumpus> I've exactly documented what information you can find on what get*info command
734 2017-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.
735 2017-06-15T19:43:01  <wumpus> and the client-side getinfo is ther for user friendlyness, if people want it
736 2017-06-15T19:43:01  <sipa> i have no problem with removing it, with or without 8843
737 2017-06-15T19:43:15  <luke-jr> wumpus: it doesn't work in the debug window
738 2017-06-15T19:43:16  <sipa> i'm sure i'll curse a bit that getinfo isn't around anymore, and then change my habits
739 2017-06-15T19:43:34  <gmaxwell> sipa: I tried blocking it, you won't. the replacements right now are not usable.
740 2017-06-15T19:43:43  <luke-jr> :/
741 2017-06-15T19:43:50  <gmaxwell> But thats okay, wumpus suggestion would be fine, though luke has a point about the debug console.
742 2017-06-15T19:43:53  <wumpus> luke-jr: isn't all the information in the debug window *without* typing anything?
743 2017-06-15T19:43:57  <achow101> removing getinfo will mess with a ton of things that use getinfo for basic rpc connection checking too...
744 2017-06-15T19:44:11  <wumpus> achow101: and you're starting to bring that up *now*?
745 2017-06-15T19:44:12  <achow101> but I think it should be removed anyways
746 2017-06-15T19:44:12  <sipa> let's merge the getuptime rpc thing
747 2017-06-15T19:44:13  <gmaxwell> wumpus: if it isn't we should make it. problem solved.
748 2017-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
749 2017-06-15T19:44:23  <instagibbs> achow101, move to dumpprivkey obv
750 2017-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
751 2017-06-15T19:44:49  <sipa> oh, another topic: non-hardened key derivation
752 2017-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
753 2017-06-15T19:44:54  <instagibbs> sipa, ACK
754 2017-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.)
755 2017-06-15T19:45:01  <wumpus> I'm really disappointed that years after deciding to deprecate getinfo we're still having this discussion
756 2017-06-15T19:45:12  <luke-jr> wumpus: lol maybe :D
757 2017-06-15T19:45:14  <wumpus> anyhow next topic
758 2017-06-15T19:45:20  <gmaxwell> wumpus: sometimes you have to try things out to know their effects completely!
759 2017-06-15T19:45:30  <wumpus> #topic non-hardened key derivation
760 2017-06-15T19:45:32  <sipa> so
761 2017-06-15T19:45:53  <sipa> non-hardened key derivation has many use cases in addition to hardened
762 2017-06-15T19:46:02  <jonasschnelli> I guess NicolasDorier made good work there
763 2017-06-15T19:46:07  <wumpus> achow101: we should carefully note it in the release notes of course
764 2017-06-15T19:46:13  <sipa> however, they also have a gaping wide security hole when child private keys are exposed
765 2017-06-15T19:46:23  <wumpus> achow101: we could even make getinfo fail with a custom message
766 2017-06-15T19:46:29  <instagibbs> that plus dumpwallet will give you sads
767 2017-06-15T19:46:30  <sipa> thus, suggestion: allow a new wallet to be created with either harderned or unhardened keys
768 2017-06-15T19:46:40  <sipa> when you choose unhardened, dumpprivkey is disabled
769 2017-06-15T19:46:44  <instagibbs> xpub is only accessible through dumpwallet right now AFAIK
770 2017-06-15T19:46:45  <achow101> wumpus: returning null would probably not mess with anything
771 2017-06-15T19:46:49  <sipa> (but dumpmasterkey or whatever is still available)
772 2017-06-15T19:47:11  <achow101> sipa: there is no dumpmasterkey
773 2017-06-15T19:47:11  <jonasschnelli> instagibbs: dumpprivkey must be disabled anyways
774 2017-06-15T19:47:19  <luke-jr> sipa: I'd want to be able to mix them..
775 2017-06-15T19:47:23  <jonasschnelli> achow101: dumpmasterkey must be added
776 2017-06-15T19:47:30  <instagibbs> luke-jr, .... why
777 2017-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)
778 2017-06-15T19:47:37  <wumpus> dumpmasterkey, isn't there a PR for that?
779 2017-06-15T19:47:42  <jonasschnelli> no
780 2017-06-15T19:47:47  <luke-jr> instagibbs: to generate reusable payment tokens
781 2017-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
782 2017-06-15T19:47:51  <gmaxwell> sipa said or whatever for a reason. :P
783 2017-06-15T19:47:54  <achow101> jonasschnelli: I'm stil lwaiting #9504
784 2017-06-15T19:47:55  <gribble> https://github.com/bitcoin/bitcoin/issues/9504 | [RPC] dumpmasterprivkey command by achow101 · Pull Request #9504 · bitcoin/bitcoin · GitHub
785 2017-06-15T19:48:04  <jonasschnelli> oh...
786 2017-06-15T19:48:05  <luke-jr> sipa: sgtm
787 2017-06-15T19:48:09  <wumpus> see, I wasn't crazy
788 2017-06-15T19:48:25  <gmaxwell> wumpus: well, technically it doesn't prove that...
789 2017-06-15T19:48:26  <jonasschnelli> achow101: how can I not be aware of that PR... sorry for the missinfo
790 2017-06-15T19:48:34  <wumpus> gmaxwell: true
791 2017-06-15T19:48:37  <sipa> getmissinfo
792 2017-06-15T19:48:47  <jonasschnelli> :/
793 2017-06-15T19:48:56  <jonasschnelli> (I even commited on the PR ^^)
794 2017-06-15T19:48:59  <jonasschnelli> commented
795 2017-06-15T19:49:15  <wumpus> getmisinfo would really fit with the spirit of the times
796 2017-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.)
797 2017-06-15T19:49:24  *** chjj has joined #bitcoin-core-dev
798 2017-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
799 2017-06-15T19:49:47  <wumpus> anyhow, no problem with non-hardened key support
800 2017-06-15T19:49:58  <jonasschnelli> I guess with allowing xpub derivation, flexible keypath would be welcome..
801 2017-06-15T19:50:04  <jonasschnelli> People want to use BIP44
802 2017-06-15T19:50:06  <wumpus> as an option, not as default
803 2017-06-15T19:50:08  <gmaxwell> w/ disabling and it not being a default thing. sounds great to me.
804 2017-06-15T19:50:25  <achow101> sgtm
805 2017-06-15T19:50:51  <jonasschnelli> Yes. Would be a great change...
806 2017-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.)
807 2017-06-15T19:51:13  <jonasschnelli> I guess keypool handling would be much simpler with xpub derivation
808 2017-06-15T19:51:22  <gmaxwell> I doubt it?
809 2017-06-15T19:51:30  <instagibbs> I think it's the same-ish
810 2017-06-15T19:51:33  <jonasschnelli> Why would you need a keypool with xpub derivation?
811 2017-06-15T19:51:41  <gmaxwell> for scanning.
812 2017-06-15T19:51:41  <jonasschnelli> you derive when you need
813 2017-06-15T19:51:50  <instagibbs> you have master seed already, you can already do that
814 2017-06-15T19:51:50  <jonasschnelli> you always derive the lookup window in mem
815 2017-06-15T19:51:53  <gmaxwell> you need to scan forward to know when you're paid.
816 2017-06-15T19:52:05  <jonasschnelli> +1000 keys in mem should be ackish
817 2017-06-15T19:52:18  <jonasschnelli> (pubkeys)
818 2017-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.
819 2017-06-15T19:52:39  <gmaxwell> but otherwise I think its the same.
820 2017-06-15T19:52:56  <jonasschnelli> I'd say loading the keypool at wallet load takes almost the same (or longer)
821 2017-06-15T19:53:28  <jtimon> sipa: why would people want to dump child private keys?
822 2017-06-15T19:53:32  <gmaxwell> okay, this would make the change much more intrusive then I think.
823 2017-06-15T19:53:39  <instagibbs> jtimon, you want to stop them from doing so
824 2017-06-15T19:53:47  <gmaxwell> jtimon: same reason some people eat paste.  (they don't know better)
825 2017-06-15T19:53:52  <jonasschnelli> heh
826 2017-06-15T19:53:57  <sipa> jonasschnelli: the reason creating new keys is slow, is because we flush them all individually to disk
827 2017-06-15T19:54:11  <wumpus> yes...
828 2017-06-15T19:54:15  *** laurentmt has quit IRC
829 2017-06-15T19:54:17  <jtimon> gmaxwell: I see
830 2017-06-15T19:54:21  <jonasschnelli> Yes. In-mem non-bdb "keypool" would be much faster
831 2017-06-15T19:54:41  <gmaxwell> that flushing is not required anymore with hdwallets regardless, I believe.
832 2017-06-15T19:54:45  <sipa> gmaxwell: exactly
833 2017-06-15T19:55:00  <jonasschnelli> With xpub derivation, would there be really a need to write the pool to disk? I doubt it
834 2017-06-15T19:55:07  <gmaxwell> (we will still need a flush to know how many we've given out...)
835 2017-06-15T19:55:09  <wumpus> gmaxwell: good point!
836 2017-06-15T19:55:29  <jonasschnelli> All you need is the seed
837 2017-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.
838 2017-06-15T19:55:47  <achow101> you just need to write the path of the most recent key
839 2017-06-15T19:55:48  <jonasschnelli> gmaxwell: yes. thats a good point
840 2017-06-15T19:56:11  <jonasschnelli> achow101: Yes.
841 2017-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.
842 2017-06-15T19:56:38  <gmaxwell> e.g. starting up for the first time with a keypoool of 10000.
843 2017-06-15T19:58:26  <wumpus> two minutes to go
844 2017-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?
845 2017-06-15T19:58:52  <jonasschnelli> gmaxwell: HD restore?
846 2017-06-15T19:59:12  <jonasschnelli> https://github.com/bitcoin/bitcoin/pull/10240
847 2017-06-15T19:59:16  <gmaxwell> it's part of your restore pr? okay.
848 2017-06-15T19:59:25  <jonasschnelli> That makes all keys as used up to the one found
849 2017-06-15T19:59:30  <gmaxwell> great.
850 2017-06-15T19:59:34  <jonasschnelli> It can even temp. halt the sync if you prune, etc.
851 2017-06-15T19:59:39  <jonasschnelli> Needs overhaul and rebase...
852 2017-06-15T19:59:46  <jonasschnelli> It's already (too) big
853 2017-06-15T19:59:54  <jonasschnelli> ryanofsky gave me a hard time
854 2017-06-15T20:00:01  <sipa> #getmeetingendinfo
855 2017-06-15T20:00:12  <wumpus> #endmeeting
856 2017-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)
857 2017-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
858 2017-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
859 2017-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
860 2017-06-15T20:02:41  *** talmai has joined #bitcoin-core-dev
861 2017-06-15T20:04:27  *** lichtamberg_ has quit IRC
862 2017-06-15T20:07:34  <gmaxwell> wumpus: sorry to bog you with the getinfo stuff. :(
863 2017-06-15T20:08:55  <wumpus> gmaxwell: yes, no problem, don't mind resurrecting #8843
864 2017-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
865 2017-06-15T20:09:07  <wumpus> gmaxwell: just don't want to talk with luke-jr about it :p
866 2017-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.
867 2017-06-15T20:09:12  <gmaxwell> haha
868 2017-06-15T20:09:21  <gmaxwell> Well, he does hate freedom, after all.
869 2017-06-15T20:09:53  <sipa> gmaxwell: perhaps you should write a getmyinfo.sh with just queries for the things you're typically interested in :)
870 2017-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
871 2017-06-15T20:10:35  <wumpus> sipa: I have tons of those scripts
872 2017-06-15T20:10:47  <wumpus> e.g. to show # connections per interface in/out
873 2017-06-15T20:11:05  <wumpus> getinfo's output isn't *that* useful
874 2017-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 ;)
875 2017-06-15T20:11:18  <wumpus> luke-jr: well in that case I'd prefer just a python script
876 2017-06-15T20:11:51  <ProfMac> What git version introduced the file bitcoin/contrib/gitian-build.sh ?
877 2017-06-15T20:12:05  <wumpus> oh wait I'm talking to luke-jr about getinfo
878 2017-06-15T20:12:13  <luke-jr> :<
879 2017-06-15T20:12:23  *** owowo has quit IRC
880 2017-06-15T20:12:40  <morcos> at the risk of irritating everyone, i use getinfo all the time
881 2017-06-15T20:13:15  <gmaxwell> sipa: so then I'm happy while typical users suffer, I've tried to avoid doing that.
882 2017-06-15T20:13:18  <achow101> ProfMac: check the history in github
883 2017-06-15T20:13:23  <ProfMac> morcos, yep, me too.
884 2017-06-15T20:13:38  <gmaxwell> same reason I don't use the ncurses thing that I like.
885 2017-06-15T20:13:47  <luke-jr> gmaxwell: throw it in contrib/?
886 2017-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
887 2017-06-15T20:14:46  <wumpus> typical users may have very different wants, though
888 2017-06-15T20:14:47  <ProfMac> achow101, I've been in Google, github, for days.  Thought someone would just actually answer the question.
889 2017-06-15T20:14:57  <instagibbs> I've been weaning myself off of getinfo
890 2017-06-15T20:15:17  <wumpus> in any case, I'm all for keeping -getinfo client-side in bitcoin-cli, I'm rebasing 8843
891 2017-06-15T20:15:44  <achow101> ProfMac: it was introduced in this commit: https://github.com/bitcoin/bitcoin/commit/eda4cfb992d140c8471f6cc2bf16c4a106439225
892 2017-06-15T20:16:08  <Chris_Stewart_5> Why don't we return fee estimation information in sat/byte?
893 2017-06-15T20:16:24  <ProfMac> Thanks, achow101
894 2017-06-15T20:16:47  <jonasschnelli> gmaxwell: Yes. 20 is to little...
895 2017-06-15T20:16:57  <instagibbs> ProfMac, you can always `git log -p -M --follow -- file/path` to track those kind of questions
896 2017-06-15T20:16:58  <jonasschnelli> I guess I took BIP44 for a start.. but it's a single const
897 2017-06-15T20:17:06  <instagibbs> Chris_Stewart_5, because legacy, mostly
898 2017-06-15T20:17:21  *** owowo has joined #bitcoin-core-dev
899 2017-06-15T20:17:31  <wumpus> instagibbs: hah, 99% of the time that's the right answer to any 'why' question
900 2017-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
901 2017-06-15T20:19:35  *** SopaXorzTaker has quit IRC
902 2017-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
903 2017-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.
904 2017-06-15T20:21:15  <instagibbs> Any new interface certainly should be sat/byte
905 2017-06-15T20:21:45  <Chris_Stewart_5> ^
906 2017-06-15T20:21:56  <wumpus> and then you have multiple different conventions on different RPC calls
907 2017-06-15T20:23:38  *** RubenSomsen has quit IRC
908 2017-06-15T20:24:58  <sipa> nanobitcoins per Hart
909 2017-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
910 2017-06-15T20:25:27  <sipa> do we still show hashrate?
911 2017-06-15T20:25:46  <wumpus> other things are only marginally useful; how many times have you wanted to know the the wallet version?
912 2017-06-15T20:26:07  <wumpus> or "testnet":false, which is also false for regtest
913 2017-06-15T20:26:29  <wumpus> sipa: no, that seems to be gone :
914 2017-06-15T20:27:10  <instagibbs> new interface meaning RPC2.0 or whatever... not new calls
915 2017-06-15T20:27:59  <gmaxwell> To be clear I am joking about luke hating freedom.
916 2017-06-15T20:28:59  <wumpus> oh, I thought you were serious!
917 2017-06-15T20:29:12  <cfields> jonasschnelli / gmaxwell / sipa: https://pastebin.com/raw/eKhEiJR3
918 2017-06-15T20:29:20  <wumpus> https://github.com/bitcoin/bitcoin/pull/8843 rebased
919 2017-06-15T20:29:38  <jonasschnelli> cfields: ahh.. that look like a beautiful girl
920 2017-06-15T20:29:56  <cfields> :)
921 2017-06-15T20:29:58  <jonasschnelli> cfields: I expected a code diff at the bottom.... :)
922 2017-06-15T20:30:03  <cfields> guess that's what you had in mind, then?
923 2017-06-15T20:30:08  <cfields> heh, 1 sec
924 2017-06-15T20:30:19  <jonasschnelli> Yes. Have you tried to run it with the GUI?
925 2017-06-15T20:30:20  <cfields> it's per-thread/per-mutex/per-lock
926 2017-06-15T20:30:32  <cfields> no, just simple tests so far
927 2017-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
928 2017-06-15T20:30:59  <jonasschnelli> To bed my wife calls me to bed.. I'll play with the code soon
929 2017-06-15T20:31:05  <cfields> other than that, seems to work as expected
930 2017-06-15T20:31:17  <cfields> ok, i'll push to a branch
931 2017-06-15T20:31:25  <jonasschnelli> thanks
932 2017-06-15T20:31:35  <cfields> np, nnite
933 2017-06-15T20:31:47  <wumpus> cfields: nice!
934 2017-06-15T20:32:16  *** Giszmo has joined #bitcoin-core-dev
935 2017-06-15T20:34:20  <cfields> https://github.com/theuni/bitcoin/commit/be49a294a240ec81a901af1aaabbba2172d38dc1
936 2017-06-15T20:35:06  <cfields> jonasschnelli: for tomorrow ^^
937 2017-06-15T20:43:28  *** talmai has quit IRC
938 2017-06-15T20:43:53  *** abpa has quit IRC
939 2017-06-15T20:46:30  *** lichtamberg_ has joined #bitcoin-core-dev
940 2017-06-15T20:48:34  <cfields> er, that should s/locked/contended/ everywhere. it's showing any non-zero time taken to grab a lock.
941 2017-06-15T20:50:48  *** talmai has joined #bitcoin-core-dev
942 2017-06-15T20:50:56  *** RubenSomsen has joined #bitcoin-core-dev
943 2017-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
944 2017-06-15T21:01:09  *** goatpig has quit IRC
945 2017-06-15T21:07:55  *** Aaronvan_ is now known as AaronvanW
946 2017-06-15T21:08:46  *** lichtamberg_ has left #bitcoin-core-dev
947 2017-06-15T21:10:29  *** abpa has joined #bitcoin-core-dev
948 2017-06-15T21:11:57  *** cryptapus is now known as cryptapus_afk
949 2017-06-15T21:11:57  *** Dyaheon has quit IRC
950 2017-06-15T21:12:21  *** talmai has quit IRC
951 2017-06-15T21:12:55  *** Dyaheon has joined #bitcoin-core-dev
952 2017-06-15T21:16:35  *** abpa has quit IRC
953 2017-06-15T21:20:02  <ProfMac> pastebin or google docs?
954 2017-06-15T21:20:26  *** F-DK has joined #bitcoin-core-dev
955 2017-06-15T21:22:13  *** Giszmo has quit IRC
956 2017-06-15T21:27:17  *** abpa has joined #bitcoin-core-dev
957 2017-06-15T21:29:34  *** elkalamar has joined #bitcoin-core-dev
958 2017-06-15T21:30:39  *** talmai has joined #bitcoin-core-dev
959 2017-06-15T21:32:11  *** elkalamar has quit IRC
960 2017-06-15T21:33:07  *** F-DK has quit IRC
961 2017-06-15T21:35:38  *** Giszmo has joined #bitcoin-core-dev
962 2017-06-15T21:36:28  <ProfMac> I am stuck trying to do a gitian build.  I have made a Pastebin  https://pastebin.com/eXPaQsLf
963 2017-06-15T21:37:04  *** talmai has quit IRC
964 2017-06-15T21:39:30  *** goatpig has joined #bitcoin-core-dev
965 2017-06-15T21:44:47  *** Giszmo has quit IRC
966 2017-06-15T22:06:32  *** Guyver2 has quit IRC
967 2017-06-15T22:10:06  *** Dizzle has quit IRC
968 2017-06-15T22:10:08  *** Chris_Stewart_5 has quit IRC
969 2017-06-15T22:11:45  *** murch has quit IRC
970 2017-06-15T22:25:11  *** timothy has joined #bitcoin-core-dev
971 2017-06-15T22:26:54  *** nemgun has joined #bitcoin-core-dev
972 2017-06-15T22:27:39  *** timothy has quit IRC
973 2017-06-15T22:30:07  *** marcoagner has quit IRC
974 2017-06-15T22:34:37  *** nemgun has quit IRC
975 2017-06-15T22:35:24  *** Chris_Stewart_5 has joined #bitcoin-core-dev
976 2017-06-15T22:38:35  *** chjj has quit IRC
977 2017-06-15T22:39:07  *** jtimon has quit IRC
978 2017-06-15T22:42:37  *** marcoagner has joined #bitcoin-core-dev
979 2017-06-15T22:46:05  *** abpa has quit IRC
980 2017-06-15T22:46:45  *** abpa has joined #bitcoin-core-dev
981 2017-06-15T22:52:38  *** laurentmt has joined #bitcoin-core-dev
982 2017-06-15T22:53:33  *** chjj has joined #bitcoin-core-dev
983 2017-06-15T22:59:09  *** laurentmt has quit IRC
984 2017-06-15T22:59:29  *** laurentmt has joined #bitcoin-core-dev
985 2017-06-15T23:14:07  *** Giszmo has joined #bitcoin-core-dev
986 2017-06-15T23:16:34  *** Dyaheon has quit IRC
987 2017-06-15T23:18:07  *** Dyaheon has joined #bitcoin-core-dev
988 2017-06-15T23:24:19  *** chjj has quit IRC
989 2017-06-15T23:38:00  *** chjj has joined #bitcoin-core-dev
990 2017-06-15T23:42:29  *** elkalamar has joined #bitcoin-core-dev
991 2017-06-15T23:48:57  *** laurentmt has quit IRC