1 2017-01-05T00:17:32  *** Guyver2 has quit IRC
  2 2017-01-05T00:36:37  *** instagibbs has quit IRC
  3 2017-01-05T00:37:17  *** instagibbs has joined #bitcoin-core-dev
  4 2017-01-05T01:00:39  *** abpa has quit IRC
  5 2017-01-05T01:04:00  *** juscamarena has quit IRC
  6 2017-01-05T01:18:21  *** juscamarena has joined #bitcoin-core-dev
  7 2017-01-05T01:40:53  *** abpa has joined #bitcoin-core-dev
  8 2017-01-05T01:41:12  *** abpa has quit IRC
  9 2017-01-05T01:57:26  *** Ylbam has quit IRC
 10 2017-01-05T02:07:54  *** Squidicc has joined #bitcoin-core-dev
 11 2017-01-05T02:11:25  *** Squidicuz has quit IRC
 12 2017-01-05T02:32:58  *** Chris_Stewart_5 has quit IRC
 13 2017-01-05T02:35:58  <gmaxwell> morcos: I'd like to review #9404 but it would be easier to do if you rebased on #9465 if you think you'll be doing that anyways.
 14 2017-01-05T02:36:00  <gribble> https://github.com/bitcoin/bitcoin/issues/9404 | Make a second pass with same coins in CreateTransaction. by morcos · Pull Request #9404 · bitcoin/bitcoin · GitHub
 15 2017-01-05T02:36:01  <gribble> https://github.com/bitcoin/bitcoin/issues/9465 | [Wallet] Do not perform ECDSA signing in the fee calculation inner loop. by gmaxwell · Pull Request #9465 · bitcoin/bitcoin · GitHub
 16 2017-01-05T02:38:07  <gmaxwell> morcos: will #9404 increase the number of cases where you get change back when you were really trying to send all your funds? hm. I guess not, if you're doing a subtract fee from amount the second pass will subtract less.
 17 2017-01-05T02:38:09  <gribble> https://github.com/bitcoin/bitcoin/issues/9404 | Make a second pass with same coins in CreateTransaction. by morcos · Pull Request #9404 · bitcoin/bitcoin · GitHub
 18 2017-01-05T02:38:27  <gmaxwell> okay bot, we got the picture.
 19 2017-01-05T02:40:54  <sipa> haha
 20 2017-01-05T02:41:06  <sipa> maybe it needs rate limiting
 21 2017-01-05T02:43:07  <btcdrak> what happens if you quote ticket A, which references B and in the title of B reference A? would gribble flood the channel?
 22 2017-01-05T02:49:13  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 23 2017-01-05T02:49:43  *** juscamarena has quit IRC
 24 2017-01-05T02:55:54  *** CubicEarth has joined #bitcoin-core-dev
 25 2017-01-05T02:58:30  *** Chris_Stewart_5 has quit IRC
 26 2017-01-05T02:58:34  <sipa> btcdrak: i don't think it triggers based on things it says itself
 27 2017-01-05T03:05:20  *** trippysalmon has quit IRC
 28 2017-01-05T03:05:20  *** wolfspraul has quit IRC
 29 2017-01-05T03:05:20  *** tadasv has quit IRC
 30 2017-01-05T03:05:27  *** wolfspraul has joined #bitcoin-core-dev
 31 2017-01-05T03:05:33  *** trippysalmon has joined #bitcoin-core-dev
 32 2017-01-05T03:06:55  <morcos> gmaxwell: yep, i was going to do that, 9465 (just leave off the # if you don't want the bot) looks good to me, was just going to let it sit for a day before i rebased
 33 2017-01-05T03:08:07  <morcos> 9404 shouldn't have any affect when you were trying to send all your funds..  it only kicks in if you already had change and that change was big enough to absorb fees
 34 2017-01-05T03:08:07  *** tadasv has joined #bitcoin-core-dev
 35 2017-01-05T03:08:59  <morcos> i also have #9343 which makes a change to cases when you are subtractFeeFromAmount'ing which i think will make future improvements easier if we're willing to accept the change in behavior
 36 2017-01-05T03:09:01  <gribble> https://github.com/bitcoin/bitcoin/issues/9343 | An error has occurred and has been logged. Please contact this bot's administrator for more information.
 37 2017-01-05T03:10:50  <morcos> in any case, i think we should evaluate these as to whether they are better behavior than existing but not hold them to too high a standard b/c i think only a reasonable simple change has a chance for 0.14..  after that we can try to do something more complete
 38 2017-01-05T03:16:31  *** windsok has quit IRC
 39 2017-01-05T03:52:11  *** windsok has joined #bitcoin-core-dev
 40 2017-01-05T03:56:35  *** Victor_sueca has joined #bitcoin-core-dev
 41 2017-01-05T03:59:16  *** Victorsueca has quit IRC
 42 2017-01-05T04:00:37  *** Squidicc has quit IRC
 43 2017-01-05T04:00:58  *** Squidicuz has joined #bitcoin-core-dev
 44 2017-01-05T04:05:03  *** chris2000 has joined #bitcoin-core-dev
 45 2017-01-05T04:08:25  *** chris200_ has quit IRC
 46 2017-01-05T04:10:41  *** CubicEarth has quit IRC
 47 2017-01-05T05:30:17  *** roidster has quit IRC
 48 2017-01-05T06:06:07  *** kadoban has quit IRC
 49 2017-01-05T06:15:53  *** cannon-c has joined #bitcoin-core-dev
 50 2017-01-05T06:36:55  *** dcousens has quit IRC
 51 2017-01-05T06:40:17  *** justanotheruser is now known as leibnitz
 52 2017-01-05T06:40:28  *** leibnitz is now known as OfficialLeibniz
 53 2017-01-05T06:59:51  *** Squidicc has joined #bitcoin-core-dev
 54 2017-01-05T07:00:15  *** dermoth has quit IRC
 55 2017-01-05T07:01:10  *** dermoth has joined #bitcoin-core-dev
 56 2017-01-05T07:03:01  *** Squidicuz has quit IRC
 57 2017-01-05T07:05:41  *** arubi has joined #bitcoin-core-dev
 58 2017-01-05T07:40:25  *** To7 has joined #bitcoin-core-dev
 59 2017-01-05T07:41:39  *** LeMiner has joined #bitcoin-core-dev
 60 2017-01-05T07:47:37  <jonasschnelli> Hah. Eric Voskuli's answer to this nails it: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-January/013431.html
 61 2017-01-05T07:48:20  *** PRab_ has joined #bitcoin-core-dev
 62 2017-01-05T07:49:55  *** PRab has quit IRC
 63 2017-01-05T07:50:08  *** PRab_ is now known as PRab
 64 2017-01-05T07:51:33  *** BashCo has quit IRC
 65 2017-01-05T07:52:11  *** BashCo has joined #bitcoin-core-dev
 66 2017-01-05T07:56:37  *** BashCo has quit IRC
 67 2017-01-05T08:09:01  *** Squidicc has quit IRC
 68 2017-01-05T08:11:55  *** udiWertheimer has quit IRC
 69 2017-01-05T08:13:51  *** BashCo has joined #bitcoin-core-dev
 70 2017-01-05T08:14:25  *** BashCo_ has joined #bitcoin-core-dev
 71 2017-01-05T08:17:38  *** Ylbam has joined #bitcoin-core-dev
 72 2017-01-05T08:17:57  *** BashCo has quit IRC
 73 2017-01-05T08:20:04  <gmaxwell> morcos: I agree that we need to focus on small improvements that make things simply better at the moment, and that a big redesign is out of scope at the moment.
 74 2017-01-05T08:32:13  *** juscamarena has joined #bitcoin-core-dev
 75 2017-01-05T08:33:11  <jonasschnelli> We had 15208 github comments in 2016, from 517 users. That's an avg of ~41.5 comments per day.
 76 2017-01-05T08:35:05  *** juscamarena__ has joined #bitcoin-core-dev
 77 2017-01-05T08:35:13  *** juscamarena_ has joined #bitcoin-core-dev
 78 2017-01-05T08:35:20  *** juscamarena__ has quit IRC
 79 2017-01-05T08:36:37  *** waxwing has quit IRC
 80 2017-01-05T08:44:34  *** waxwing has joined #bitcoin-core-dev
 81 2017-01-05T08:57:49  *** Squidicuz has joined #bitcoin-core-dev
 82 2017-01-05T09:12:23  *** paveljanik has quit IRC
 83 2017-01-05T09:29:13  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/7dac1e5e9e88...70145064153a
 84 2017-01-05T09:29:13  <bitcoin-git> bitcoin/master 0388afe Luke Dashjr: Let autoconf detect presence of EVP_MD_CTX_new...
 85 2017-01-05T09:29:14  <bitcoin-git> bitcoin/master 7014506 Wladimir J. van der Laan: Merge #9475: Let autoconf detect presence of EVP_MD_CTX_new...
 86 2017-01-05T09:29:30  <bitcoin-git> [bitcoin] laanwj closed pull request #9475: Let autoconf detect presence of EVP_MD_CTX_new (master...EVP_MD_CTX_new) https://github.com/bitcoin/bitcoin/pull/9475
 87 2017-01-05T09:29:48  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/70145064153a...48d7e0d5e463
 88 2017-01-05T09:29:48  <bitcoin-git> bitcoin/master ce370c1 Pieter Wuille: Mark the minconf parameter to move as ignored
 89 2017-01-05T09:29:49  <bitcoin-git> bitcoin/master 48d7e0d Wladimir J. van der Laan: Merge #9474: Mark the minconf parameter to move as ignored...
 90 2017-01-05T09:30:08  <bitcoin-git> [bitcoin] laanwj closed pull request #9474: Mark the minconf parameter to move as ignored (master...stale_minconf_parameter) https://github.com/bitcoin/bitcoin/pull/9474
 91 2017-01-05T09:30:09  *** Alina-malina has quit IRC
 92 2017-01-05T09:37:33  *** Alina-malina has joined #bitcoin-core-dev
 93 2017-01-05T09:43:53  <wumpus> jonasschnelli: wow
 94 2017-01-05T09:49:27  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/48d7e0d5e463...c4b7d4f79c85
 95 2017-01-05T09:49:27  <bitcoin-git> bitcoin/master 407cdd6 Pieter Wuille: Do not evaluate hidden LogPrint arguments
 96 2017-01-05T09:49:28  <bitcoin-git> bitcoin/master c4b7d4f Wladimir J. van der Laan: Merge #9417: Do not evaluate hidden LogPrint arguments...
 97 2017-01-05T09:49:42  <bitcoin-git> [bitcoin] laanwj closed pull request #9417: Do not evaluate hidden LogPrint arguments (master...bypass_debug) https://github.com/bitcoin/bitcoin/pull/9417
 98 2017-01-05T09:51:45  *** Guyver2 has joined #bitcoin-core-dev
 99 2017-01-05T10:00:47  <jonasschnelli> Currently verifying my data..
100 2017-01-05T10:01:05  <jonasschnelli> But I guess we had 1563 PRs opened in 2016.
101 2017-01-05T10:01:28  <jonasschnelli> 1032 merged (66%)
102 2017-01-05T10:01:47  <jonasschnelli> 146 still open (~9%)
103 2017-01-05T10:02:09  <jonasschnelli> 385 closed (~24.6%)
104 2017-01-05T10:02:28  <jonasschnelli> (though the last one may have some false-positives [manual closed merges])
105 2017-01-05T10:02:42  <wumpus> it at least feels like it was a really busy year in that regard
106 2017-01-05T10:11:05  *** MarcoFalke has joined #bitcoin-core-dev
107 2017-01-05T10:11:49  <bitcoin-git> [bitcoin] laanwj pushed 5 new commits to master: https://github.com/bitcoin/bitcoin/compare/c4b7d4f79c85...cfe41d7a6034
108 2017-01-05T10:11:50  <bitcoin-git> bitcoin/master e5534d2 Karl-Johan Alm: Added std::unique_ptr<> wrappers with deleters for libevent modules.
109 2017-01-05T10:11:51  <bitcoin-git> bitcoin/master 7f7f102 Karl-Johan Alm: Switched bitcoin-cli.cpp to use RAII unique pointers with deleters.
110 2017-01-05T10:11:51  <bitcoin-git> bitcoin/master 280a559 Karl-Johan Alm: Added some simple tests for the RAII-style events.
111 2017-01-05T10:12:05  <bitcoin-git> [bitcoin] laanwj closed pull request #9387: [Refactor] RAII of libevent stuff using unique ptrs with deleters (master...raii-libevents) https://github.com/bitcoin/bitcoin/pull/9387
112 2017-01-05T10:17:12  *** jannes has joined #bitcoin-core-dev
113 2017-01-05T10:19:58  <bitcoin-git> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/cfe41d7a6034...406f35d99d0f
114 2017-01-05T10:19:59  <bitcoin-git> bitcoin/master d5aa198 Doug: Allow linearization scripts to support hash byte reversal...
115 2017-01-05T10:19:59  <bitcoin-git> bitcoin/master 3c8f63b Doug: Make linearize scripts Python 3-compatible.
116 2017-01-05T10:20:00  <bitcoin-git> bitcoin/master 406f35d Wladimir J. van der Laan: Merge #9373: Linearize script update (hash byte reversal and Python 3 support)...
117 2017-01-05T10:20:11  <bitcoin-git> [bitcoin] laanwj closed pull request #9373: Linearize script update (hash byte reversal and Python 3 support) (master...linearize-update) https://github.com/bitcoin/bitcoin/pull/9373
118 2017-01-05T10:23:22  <kallewoof> I am noticing that listsinceblock is sometimes including and sometimes not including a transaction that was double-spent and discarded by the network. Is this expected?
119 2017-01-05T10:24:37  *** Alina-malina has quit IRC
120 2017-01-05T10:25:09  <kallewoof> Should've asked on #bitcoin-dev. Migrating, sorry.
121 2017-01-05T10:27:15  *** Alina-malina has joined #bitcoin-core-dev
122 2017-01-05T10:33:03  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/406f35d99d0f...4cfd57d2e382
123 2017-01-05T10:33:03  <bitcoin-git> bitcoin/master 73f4119 Karl-Johan Alm: Refactoring: Removed using namespace <xxx> from bench/ and test/ source files.
124 2017-01-05T10:33:04  <bitcoin-git> bitcoin/master 4cfd57d MarcoFalke: Merge #9281: Refactor: Remove using namespace <xxx> from bench/ & test/ sources...
125 2017-01-05T10:33:16  <bitcoin-git> [bitcoin] MarcoFalke closed pull request #9281: Refactor: Remove using namespace <xxx> from bench/ & test/ sources (master...no-using-namespace-bench-test) https://github.com/bitcoin/bitcoin/pull/9281
126 2017-01-05T10:33:35  <wumpus> kallewoof: depends on the reason for 'sometimes' I suppose :)
127 2017-01-05T10:36:40  <wumpus> I'd say random non-deterministic behavior is never intended
128 2017-01-05T10:37:39  <bitcoin-git> [bitcoin] kallewoof opened pull request #9476: Refactor: Remove using namespace <xxx> from rpc/ & script/ sources (master...no-using-namespace-rpc-script) https://github.com/bitcoin/bitcoin/pull/9476
129 2017-01-05T10:39:07  *** dcousens has joined #bitcoin-core-dev
130 2017-01-05T10:41:56  *** fanquake has joined #bitcoin-core-dev
131 2017-01-05T10:42:05  <kallewoof> @wumpus: http://pastebin.com/EqupZuFM (missing case) vs http://pastebin.com/Phy6mN3G (present case).
132 2017-01-05T10:46:53  <kallewoof> It is an automated test. Only thing I can think of is some weird timing, but I'm being very generous with letting things sync so not sure what's going on.
133 2017-01-05T10:47:27  <wumpus> I wonder, does listing transactions not in blocks make sense at all for "listsinceblock"
134 2017-01-05T10:47:51  <wumpus> apparently it's a difference with regard to what unconfirmed/conflicted transactions are listed
135 2017-01-05T10:48:03  <kallewoof> My assumption was that it would list anything affecting me given the last state of the block chain from the hash I give. I.e. if a tx was dropped it would be present.
136 2017-01-05T10:48:07  *** Alina-malina has quit IRC
137 2017-01-05T10:48:07  *** Alina-malina has joined #bitcoin-core-dev
138 2017-01-05T10:48:51  <kallewoof> Specifically an invoice system would do listsinceblock periodically to ensure payments did not get double spent or similar. As it is, you have to do extra work to detect those.
139 2017-01-05T10:50:01  <wumpus> in that case not showing "orphaned" transactions would be better
140 2017-01-05T10:50:49  <wumpus> but a difference like that could indeed be due to a timing or race condition, e.g. block not yet processed by the wallet
141 2017-01-05T10:50:50  <kallewoof> What is the proper way to detect a double spend, in that case? I thought listsinceblock seemed ideal. And it is, at least sometimes.
142 2017-01-05T10:51:20  <fanquake> wumpus Spoke with theuni about some depends changes yesterday, so waiting on some feedback from him about most of those prs.
143 2017-01-05T10:52:04  <fanquake> re libevent, I think potential code improvements should be in a followup PR? Such as removing work arounds, any no-longer needed version checks etc?
144 2017-01-05T10:52:23  <wumpus> fanquake: I think the libevent change is ok, not sure about the remark about that the hash is potentially not stable
145 2017-01-05T10:52:38  <wumpus> fanquake: well we're far from being able to remove those workaround
146 2017-01-05T10:52:48  <wumpus> fanquake: it should stil support building with stable libevent :)
147 2017-01-05T10:52:58  <wumpus> just with new libevent it can use the new features
148 2017-01-05T10:53:07  <wumpus> (which it already does, in some places)
149 2017-01-05T10:53:26  <fanquake> wumpus Yea I would have thought it would be stable also. However, there could be a "more stable" URL before 0.14.0
150 2017-01-05T10:53:36  <fanquake> Might even be a proper release!
151 2017-01-05T10:54:02  <wumpus> the only option for us I see there would be to copy the file somewhere and host it there
152 2017-01-05T10:54:31  <fanquake> Yes we can do that also, we already host some files as a backup on bitcoincore.org.
153 2017-01-05T10:54:50  <fanquake> I'd like to put Boost on there so we can remove our last use of SourceForge.
154 2017-01-05T10:55:16  <wumpus> should ask cfields for that though, I don't have access to that server AFAIK
155 2017-01-05T10:56:18  <fanquake> Yes I'll bring it up with him later on.
156 2017-01-05T10:57:26  <fanquake> Does #9475 mean a 0.13.3 release quite soon? Or waiting a while longer for more bug reports.
157 2017-01-05T10:57:28  <gribble> https://github.com/bitcoin/bitcoin/issues/9475 | Let autoconf detect presence of EVP_MD_CTX_new by luke-jr · Pull Request #9475 · bitcoin/bitcoin · GitHub
158 2017-01-05T10:58:01  <wumpus> fanquake: if you ask me, I don't think a build system issue necessitates an urgent release
159 2017-01-05T10:58:06  <wumpus> we should focus on 0.14.0 now
160 2017-01-05T11:01:14  <wumpus> #9475 should just go on the stack of things to include when a 0.13.3 is released
161 2017-01-05T11:01:16  <gribble> https://github.com/bitcoin/bitcoin/issues/9475 | Let autoconf detect presence of EVP_MD_CTX_new by luke-jr · Pull Request #9475 · bitcoin/bitcoin · GitHub
162 2017-01-05T11:07:04  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/4cfd57d2e382...ce43630d1e97
163 2017-01-05T11:07:04  <bitcoin-git> bitcoin/master d29505d jonnynewbs: Fix transaction size comments. Size now refers to virtual size as defined in BIP141.
164 2017-01-05T11:07:05  <bitcoin-git> bitcoin/master ce43630 Wladimir J. van der Laan: Merge #8747: [rpc] Fix transaction size comments and RPC help text....
165 2017-01-05T11:07:12  <bitcoin-git> [bitcoin] laanwj closed pull request #8747: [rpc] Fix transaction size comments and RPC help text. (master...rpc_comments) https://github.com/bitcoin/bitcoin/pull/8747
166 2017-01-05T11:21:00  *** luke-jr has quit IRC
167 2017-01-05T11:21:09  *** luke-jr has joined #bitcoin-core-dev
168 2017-01-05T11:22:33  *** jtimon has joined #bitcoin-core-dev
169 2017-01-05T11:25:56  <bitcoin-git> [bitcoin] MarcoFalke closed pull request #9473: doc: Parameterize rpcauth help text for translation (master...Mf1701-transPara) https://github.com/bitcoin/bitcoin/pull/9473
170 2017-01-05T11:28:05  <MarcoFalke> wumpus: The rpcauth still needs a `make translate` to show up properly for translators in transifex.
171 2017-01-05T11:28:16  <MarcoFalke> Not super important, but letting you know.
172 2017-01-05T11:29:04  <MarcoFalke> Would you mind to create a pull request for `make translate` updates whenever this hasn't been done in months?
173 2017-01-05T11:29:15  <MarcoFalke> Thus, we could catch failures early
174 2017-01-05T11:29:37  <MarcoFalke> (Not after they have been propagated to transifex)
175 2017-01-05T11:39:52  *** Alsazia has joined #bitcoin-core-dev
176 2017-01-05T11:39:56  <Alsazia> Premium link generator (30+ host supported) ---> www.galileo.pw
177 2017-01-05T11:39:58  *** Alsazia has quit IRC
178 2017-01-05T11:43:31  <phantomcircuit> wumpus, listsinceblock should almost certainly not list things which aren't actually in a block
179 2017-01-05T11:55:44  *** d9b4bef9 has quit IRC
180 2017-01-05T11:55:44  *** sdaftuar has quit IRC
181 2017-01-05T11:55:45  *** gluytium has quit IRC
182 2017-01-05T11:55:45  *** Evel-Knievel has quit IRC
183 2017-01-05T11:55:45  *** crescendo has quit IRC
184 2017-01-05T11:55:45  *** adam3us has quit IRC
185 2017-01-05T11:55:45  *** baldur has quit IRC
186 2017-01-05T11:55:45  *** da2ce7 has quit IRC
187 2017-01-05T11:55:45  *** BlueMatt has quit IRC
188 2017-01-05T11:55:45  *** phantomcircuit has quit IRC
189 2017-01-05T11:55:45  *** thokon00 has quit IRC
190 2017-01-05T11:55:45  *** pigeons has quit IRC
191 2017-01-05T11:55:45  *** bad_duck has quit IRC
192 2017-01-05T11:55:52  *** bad_duck has joined #bitcoin-core-dev
193 2017-01-05T11:55:53  *** pigeons has joined #bitcoin-core-dev
194 2017-01-05T11:55:53  *** gluytium has joined #bitcoin-core-dev
195 2017-01-05T11:55:55  *** thokon00 has joined #bitcoin-core-dev
196 2017-01-05T11:55:59  *** crescendo has joined #bitcoin-core-dev
197 2017-01-05T11:56:00  *** sdaftuar has joined #bitcoin-core-dev
198 2017-01-05T11:56:01  *** Evel-Knievel has joined #bitcoin-core-dev
199 2017-01-05T11:56:06  *** baldur has joined #bitcoin-core-dev
200 2017-01-05T11:56:08  *** d9b4bef9 has joined #bitcoin-core-dev
201 2017-01-05T11:56:23  *** crescendo has quit IRC
202 2017-01-05T11:56:24  *** crescendo has joined #bitcoin-core-dev
203 2017-01-05T11:56:26  *** phantomcircuit has joined #bitcoin-core-dev
204 2017-01-05T11:56:27  *** sdaftuar has quit IRC
205 2017-01-05T11:56:27  *** sdaftuar has joined #bitcoin-core-dev
206 2017-01-05T11:56:39  *** pigeons is now known as Guest73955
207 2017-01-05T11:57:51  *** adam3us has joined #bitcoin-core-dev
208 2017-01-05T11:57:54  *** da2ce7 has joined #bitcoin-core-dev
209 2017-01-05T11:58:07  *** BlueMatt has joined #bitcoin-core-dev
210 2017-01-05T11:58:07  *** BlueMatt has joined #bitcoin-core-dev
211 2017-01-05T12:01:38  *** cannon-c has quit IRC
212 2017-01-05T12:04:45  *** dcousens has quit IRC
213 2017-01-05T12:12:26  <wumpus> MarcoFalke: the reason for having only a relatively small translation window is that it doesn't matter whether "make translate" is before that in the meantime
214 2017-01-05T12:12:43  <wumpus> MarcoFalke: during the translation window (e.g. starting this month for 0.14) we have to make sure it is up to date though
215 2017-01-05T12:29:00  <wumpus> (well that's one of the reasons; the other is to prevent translators from wasting time translating messages in the meantime that go away before the release anyway)
216 2017-01-05T12:39:57  <fanquake> Pretty sure theuni has a patch to fix the weird 9472 error. However he's on a plane I think.
217 2017-01-05T13:04:40  *** laurentmt has joined #bitcoin-core-dev
218 2017-01-05T13:05:58  *** laurentmt has quit IRC
219 2017-01-05T13:19:13  *** gielbier is now known as gielbier-irc
220 2017-01-05T13:23:45  *** Chris_Stewart_5 has joined #bitcoin-core-dev
221 2017-01-05T13:31:52  *** Chris_Stewart_5 has quit IRC
222 2017-01-05T13:33:41  <sipa> kallewoof: is it about double spends tgat your node has seen? they're not usually relayed by the network
223 2017-01-05T13:35:41  <sipa> fanquake: he's in NY
224 2017-01-05T13:36:01  *** paveljanik has joined #bitcoin-core-dev
225 2017-01-05T13:45:40  *** jtimon has quit IRC
226 2017-01-05T13:45:51  *** Chris_Stewart_5 has joined #bitcoin-core-dev
227 2017-01-05T13:50:58  <fanquake> Just chased that code in 9451 back to "First commit"
228 2017-01-05T14:05:10  *** AaronvanW has joined #bitcoin-core-dev
229 2017-01-05T14:11:36  <wumpus> fanquake: hah, nice catch
230 2017-01-05T14:14:05  *** BCBot_ has joined #bitcoin-core-dev
231 2017-01-05T14:15:06  *** LeMiner has quit IRC
232 2017-01-05T14:15:06  *** TD-Linux has quit IRC
233 2017-01-05T14:15:06  *** LeMiner has joined #bitcoin-core-dev
234 2017-01-05T14:15:06  *** LeMiner has joined #bitcoin-core-dev
235 2017-01-05T14:15:07  *** BCBot has quit IRC
236 2017-01-05T14:15:16  *** TD--Linux has joined #bitcoin-core-dev
237 2017-01-05T14:16:27  <phantomcircuit> fanquake, i believe i was right there?
238 2017-01-05T14:16:33  <phantomcircuit> seems to be about multi byte op codes
239 2017-01-05T14:17:21  <sipa> even then it was redundant
240 2017-01-05T14:17:28  <sipa> but it did make more sense
241 2017-01-05T14:19:13  *** Giszmo has joined #bitcoin-core-dev
242 2017-01-05T14:30:19  *** chris2000 has quit IRC
243 2017-01-05T14:34:28  <bitcoin-git> [bitcoin] kallewoof opened pull request #9478: Trivial refactor: BOOST_FOREACH(a, b) -> for (a : b) (master...replace-boostforeach) https://github.com/bitcoin/bitcoin/pull/9478
244 2017-01-05T14:36:56  <phantomcircuit> i can fuzz test 9451 but not at the moment
245 2017-01-05T14:42:44  <fanquake> kallewoof See the discussion in #8718 re bulk BOOST_FOREACH changes. Have a feel opinion may still be as it was a few months ago.
246 2017-01-05T14:42:46  <gribble> https://github.com/bitcoin/bitcoin/issues/8718 | An error has occurred and has been logged. Please contact this bot's administrator for more information.
247 2017-01-05T14:44:25  <fanquake> Although your changeset seems to be smaller than the previous attempt. 59 files now vs 75 previous.
248 2017-01-05T15:03:03  *** Chris_Stewart_5 has quit IRC
249 2017-01-05T15:18:37  *** Chris_Stewart_5 has joined #bitcoin-core-dev
250 2017-01-05T15:21:40  *** BashCo_ has quit IRC
251 2017-01-05T15:22:18  *** BashCo has joined #bitcoin-core-dev
252 2017-01-05T15:26:32  *** BashCo has quit IRC
253 2017-01-05T15:33:43  *** kinlo has quit IRC
254 2017-01-05T15:38:22  *** kinlo has joined #bitcoin-core-dev
255 2017-01-05T15:46:16  *** BashCo has joined #bitcoin-core-dev
256 2017-01-05T15:46:26  *** roidster has joined #bitcoin-core-dev
257 2017-01-05T15:46:49  *** Squidicuz has quit IRC
258 2017-01-05T15:47:19  *** Squidicuz has joined #bitcoin-core-dev
259 2017-01-05T15:50:01  *** d9b4bef9 has quit IRC
260 2017-01-05T15:51:08  *** d9b4bef9 has joined #bitcoin-core-dev
261 2017-01-05T16:05:40  *** fanquake has quit IRC
262 2017-01-05T16:21:12  *** gielbier-irc is now known as gielbier
263 2017-01-05T16:34:49  *** MarcoFalke has left #bitcoin-core-dev
264 2017-01-05T16:39:57  *** kadoban has joined #bitcoin-core-dev
265 2017-01-05T16:52:35  *** abpa has joined #bitcoin-core-dev
266 2017-01-05T17:05:35  *** LeMiner2 has joined #bitcoin-core-dev
267 2017-01-05T17:08:02  *** LeMiner has quit IRC
268 2017-01-05T17:08:02  *** LeMiner2 is now known as LeMiner
269 2017-01-05T17:22:25  *** laurentmt has joined #bitcoin-core-dev
270 2017-01-05T17:29:06  *** To7 has quit IRC
271 2017-01-05T17:35:25  *** Squidicuz has quit IRC
272 2017-01-05T17:35:51  *** Squidicuz has joined #bitcoin-core-dev
273 2017-01-05T17:40:20  *** TD--Linux is now known as TD-Linux
274 2017-01-05T17:40:20  *** TD-Linux has joined #bitcoin-core-dev
275 2017-01-05T17:40:21  *** instagibbs has quit IRC
276 2017-01-05T17:41:37  *** Chris_Stewart_5 has quit IRC
277 2017-01-05T17:43:53  <gmaxwell> sipa:
278 2017-01-05T17:43:55  <gmaxwell> ./.bitcoin/debug.log.reindex1  11670.622538
279 2017-01-05T17:43:59  <gmaxwell> ./.bitcoin/debug.log.reindex2  12182.296543
280 2017-01-05T17:45:26  <gmaxwell> These are reindex times on a dbcache=2000 host from the time it hit block one till it hit tip, the first is normal, the second is with all signature checks enabled.
281 2017-01-05T17:46:00  <gmaxwell> so it took eight and a half minutes longer, or a 4% slowdown.
282 2017-01-05T17:54:53  *** Chris_Stewart_5 has joined #bitcoin-core-dev
283 2017-01-05T18:08:56  *** jtimon has joined #bitcoin-core-dev
284 2017-01-05T18:10:58  *** Chris_Stewart_5 has quit IRC
285 2017-01-05T18:17:34  <sipa> gmaxwell: i made a graph of progress (according to my pr) vs time
286 2017-01-05T18:17:43  <sipa> on my laptoo
287 2017-01-05T18:17:46  <sipa> *laptoo
288 2017-01-05T18:17:48  <sipa> *laptoP
289 2017-01-05T18:18:12  <sipa> and it shows a very clear change in slope at 295000
290 2017-01-05T18:19:18  *** Guest73955 is now known as pigeons
291 2017-01-05T18:19:25  <gmaxwell> I'm doing a par4 run, to get more figures, in case verification parallelism beyond 4 actually works now. :P
292 2017-01-05T18:19:51  <gmaxwell> But there being a change in slope doesn't refute my figures. sync is very fast at 295k and the utxo set is small.
293 2017-01-05T18:20:08  <gmaxwell> so it makes a difference there, sure.. but it's only a small part of the chain.
294 2017-01-05T18:22:34  *** LeMiner2 has joined #bitcoin-core-dev
295 2017-01-05T18:24:57  *** Chris_Stewart_5 has joined #bitcoin-core-dev
296 2017-01-05T18:25:02  *** LeMiner has quit IRC
297 2017-01-05T18:25:02  *** LeMiner2 is now known as LeMiner
298 2017-01-05T18:39:05  *** Sosumi has joined #bitcoin-core-dev
299 2017-01-05T18:47:16  <morcos> gmaxwell: it works!  at least to 16
300 2017-01-05T18:47:57  <morcos> and beyond with some minor'ish tweaks that might be overfitting to checkqueue
301 2017-01-05T18:50:39  <BlueMatt> note: meeting in 10 minutes...obviously a major point of discussion will be the huge volume of outstanding things for 0.14
302 2017-01-05T18:50:47  <gmaxwell> morcos: even without the checkqueue changes?
303 2017-01-05T18:50:59  <BlueMatt> if y'all get the time prior to the meeting, please think a bit about what you want for 0.14, and what you dont think needs to make it
304 2017-01-05T18:51:06  <gmaxwell> BlueMatt: you mean the huge volume of things that are going to miss 0.14? :(
305 2017-01-05T18:51:17  <BlueMatt> gmaxwell: yea, probably :(
306 2017-01-05T18:51:27  <morcos> yeah the cuckoocache was the immediate bottle neck, so with that, we've definitely got improvement , but from 8 -> 16 isn't that great
307 2017-01-05T18:51:37  <BlueMatt> need to be able to prioritize review for what can make it in a week, and what wouldnt without an extra week :/
308 2017-01-05T18:51:55  <gmaxwell> morcos: if it really was we could have gotten a similar speedup by bypassing the cache in IBD. :P oh well. :)
309 2017-01-05T18:53:40  *** Squidicc has joined #bitcoin-core-dev
310 2017-01-05T18:53:48  <morcos> gmaxwell: ah yes i guess i wasn't talking about IBD...   well i don't remember now what my IBD results were, but i'd be surprised if you couldn't go past 4 previously...  actually having to do the signtures makes the parrellism more valuable
311 2017-01-05T18:53:48  <sipa> gmaxwell: rebase #9319 ?
312 2017-01-05T18:53:50  <gribble> https://github.com/bitcoin/bitcoin/issues/9319 | Break addnode out from the outbound connection limits. by gmaxwell · Pull Request #9319 · bitcoin/bitcoin · GitHub
313 2017-01-05T18:54:10  <BlueMatt> yea, super want that one for 0.14, and should be an easy target
314 2017-01-05T18:54:19  <BlueMatt> already has some acks, too
315 2017-01-05T18:55:19  <sipa> can i have a few more acks on #8610? i think the rewrite invalidated prior review
316 2017-01-05T18:55:21  <gribble> https://github.com/bitcoin/bitcoin/issues/8610 | Share unused mempool memory with coincache by sipa · Pull Request #8610 · bitcoin/bitcoin · GitHub
317 2017-01-05T18:56:06  <gmaxwell> sipa: oh I didn't know one was needed there.
318 2017-01-05T18:56:08  <morcos> sipa: you didn't specify what you changed the last time, i looked and it seemed just the lock inversion fix?
319 2017-01-05T18:56:09  *** LiberalSquash has joined #bitcoin-core-dev
320 2017-01-05T18:56:13  *** LiberalSquash has left #bitcoin-core-dev
321 2017-01-05T18:56:22  <sipa> morcos: yes, just that
322 2017-01-05T18:56:32  <sipa> morcos: i mean compared to before implementing your approach
323 2017-01-05T18:56:33  <gmaxwell> oh now I kinda wish I didn't load that PR...
324 2017-01-05T18:57:01  *** Squidicuz has quit IRC
325 2017-01-05T18:58:18  <BlueMatt> sipa: done (I recalled that I had already reviewed half of it yesterday...)
326 2017-01-05T18:59:54  <morcos> if you guys trust my rebases, just merge #9138 already...  please?  (next time in exchange for more willing reviewers of fee estimation, i will break into smaller PR's)
327 2017-01-05T18:59:55  <sipa> BLING
328 2017-01-05T18:59:56  <gribble> https://github.com/bitcoin/bitcoin/issues/9138 | Improve fee estimation by morcos · Pull Request #9138 · bitcoin/bitcoin · GitHub
329 2017-01-05T18:59:57  <BlueMatt> meeting
330 2017-01-05T19:00:13  <sipa> morcos: i was waiting for acks
331 2017-01-05T19:00:15  <wumpus> #startmeeting
332 2017-01-05T19:00:15  <lightningbot> Meeting started Thu Jan  5 19:00:15 2017 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
333 2017-01-05T19:00:15  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
334 2017-01-05T19:00:17  <jl2012> may I propose a topic first? need to sleep
335 2017-01-05T19:00:22  <petertodd> hi
336 2017-01-05T19:00:26  <BlueMatt> jl2012: go
337 2017-01-05T19:00:39  <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
338 2017-01-05T19:00:44  <jonasschnelli> Hi
339 2017-01-05T19:00:49  <jl2012> proposed topic: repair the fork warning system: https://github.com/bitcoin/bitcoin/pull/9443
340 2017-01-05T19:01:00  <wumpus> #topic  repair the fork warning system
341 2017-01-05T19:01:09  <sipa> concept ack on fixing it if it's broken!
342 2017-01-05T19:01:12  *** instagibbs_ has joined #bitcoin-core-dev
343 2017-01-05T19:01:17  <BlueMatt> concept ack 100%
344 2017-01-05T19:01:22  <wumpus> haha yes concept ack. Haven't looked at the code yet.
345 2017-01-05T19:01:28  <sipa> i haven't had time to look at the details... 0.14 is getting close
346 2017-01-05T19:01:28  <jl2012> but this is more than just fixing it
347 2017-01-05T19:01:37  <BlueMatt> but we've fucked that up several times already, so needs careful review, I think
348 2017-01-05T19:01:44  <instagibbs_> here
349 2017-01-05T19:01:56  <sipa> jl2012: elaborate?
350 2017-01-05T19:02:04  <jl2012> it also stores invalid headers
351 2017-01-05T19:02:07  <morcos> jl2012: are you trying to say you think it NEEDS to be in 0.14
352 2017-01-05T19:02:43  <phantomcircuit> huh what
353 2017-01-05T19:02:43  <jtimon> oh, meeting, wasn't planning on attending today, but really nothing to do until one hour from now...
354 2017-01-05T19:02:45  <phantomcircuit> oh
355 2017-01-05T19:02:47  <jl2012> specifically, it stores valid headers under an invalid block
356 2017-01-05T19:03:00  <kanzure> hi.
357 2017-01-05T19:03:01  <jl2012> also, headers with invalid nVersion are stored
358 2017-01-05T19:03:10  <sipa> jl2012: but those do have valid PoW?
359 2017-01-05T19:03:14  <jl2012> yes
360 2017-01-05T19:03:22  <jl2012> and valid nTime
361 2017-01-05T19:03:23  <sipa> iirc that is our only invariant for the storage of headers
362 2017-01-05T19:03:30  <BlueMatt> jl2012: do we need to store them or can we just store them in memory?
363 2017-01-05T19:03:38  <BlueMatt> but, I'm fine either way
364 2017-01-05T19:04:03  <BlueMatt> looking at invalid headers with valid pow for user-warnings sounds good to me
365 2017-01-05T19:04:09  <wumpus> stored headers are forever, both on disk and in memory, unfortunately
366 2017-01-05T19:04:10  <sipa> there may be some DoS avenues that open up due to it, if they get accepted for chains that fork off early on
367 2017-01-05T19:04:14  <luke-jr> jl2012: does this do anything to address that nodes sending us such chains will be DoS banned
368 2017-01-05T19:04:15  <luke-jr> ?
369 2017-01-05T19:04:29  <jl2012> won't be banned
370 2017-01-05T19:04:32  *** brg444 has joined #bitcoin-core-dev
371 2017-01-05T19:04:34  <sipa> (but i shouldn't comment on that before looking at code)
372 2017-01-05T19:04:38  <gmaxwell> I feel pretty blah about the utlity of that warning system, and warnings in general. I think we've burned people out with false warnings, and they weren't used usefully by most to begin with. :(
373 2017-01-05T19:04:58  <wumpus> the alternative to fixing it would be to just disable the system, at least for 0.14
374 2017-01-05T19:05:04  <BlueMatt> gmaxwell: having reliable warning messages is the first step towards fixing that trust :)
375 2017-01-05T19:05:04  <luke-jr> jl2012: so this removes the DoS banning for invalid blocks?
376 2017-01-05T19:05:21  <jl2012> luke-jr: just for valid header
377 2017-01-05T19:05:31  <wumpus> shipping it broken, especially with risk of false positives, indeed isn't going to do anything good
378 2017-01-05T19:05:41  <jl2012> if the block content is invalid (e.g. invalid script), still banned
379 2017-01-05T19:06:00  <gmaxwell> There is currently no false positive risk from it AFAIK.
380 2017-01-05T19:06:03  <luke-jr> jl2012: which will lead to you not getting future headers
381 2017-01-05T19:06:07  <petertodd> jl2012: to be clear, if the block is too large it will be banned as well?
382 2017-01-05T19:06:09  <wumpus> having to store more data forever just to be able to warn seems a bit inefficient to me though
383 2017-01-05T19:06:27  <jtimon> mhmm, the block is still invalid here, no? https://github.com/bitcoin/bitcoin/pull/9443/files#diff-24efdb00bfbe56b140fb006b562cc70bR3038
384 2017-01-05T19:06:29  <wumpus> the block headers are never pruned, and all loaded into memory at start
385 2017-01-05T19:06:30  <BlueMatt> petertodd: i dont think it changes anything wrt consensus code? the way I read it
386 2017-01-05T19:06:33  <gmaxwell> petertodd: we can't even deseralize it if its too large so how would we even know if the contet were invalid.
387 2017-01-05T19:06:35  <jl2012> petertodd: should be, I don't change that part
388 2017-01-05T19:06:37  <BlueMatt> petertodd: /any/ consensus logic
389 2017-01-05T19:06:42  <sipa> i wonder if we need a detection of internal consensus errors (database corruption, CPU overheating, ...)
390 2017-01-05T19:06:54  <petertodd> gmaxwell: we can deserialize if it's only a little bit too large though IIRC
391 2017-01-05T19:06:58  <sipa> because 99.999% of all fork warning that are seen in practice as just broken nodes
392 2017-01-05T19:07:03  <gmaxwell> An invarient we have right now is that we depnd on banning to make sure all our connection slots are not consumed by peers that are on an incompatible blockchain.
393 2017-01-05T19:07:23  <gmaxwell> sipa: I think we do.
394 2017-01-05T19:07:53  <gmaxwell> sipa: which ultimately should be used to trigger recovery from chainstate backup automatically. (I think)
395 2017-01-05T19:07:55  <sipa> but i don't know how without having a thread in the background that computes Pi or so :p
396 2017-01-05T19:08:15  <morcos> jl2012: i'd like to understand the context of the discussion, is that about the change in general or whether it shoudl be in 0.14.   Is the current status of master somehow worse than 13.1/2?
397 2017-01-05T19:08:25  <wumpus> detecting database corruption on disk is pretty easy as everything is CRC-ed, CPU overheating or memory corruption on the other hand...
398 2017-01-05T19:08:43  *** CubicEarth has joined #bitcoin-core-dev
399 2017-01-05T19:09:01  <jl2012> morcos: I think that has broken for a few versions
400 2017-01-05T19:09:22  <gmaxwell> Broken just means that it won't trigger in all cases it might trigger, right?
401 2017-01-05T19:09:23  <wumpus> good to know, yes, if it's been broken for a few versions there's no hurry to fix it for 0.14
402 2017-01-05T19:09:25  <jl2012> so you may consider it as a new feature
403 2017-01-05T19:09:33  <jl2012> gmaxwell: yes
404 2017-01-05T19:09:35  <sipa> well it can be considered for 0.14.1 or so
405 2017-01-05T19:09:43  <sipa> if it's a bugfix (which i think it is)
406 2017-01-05T19:10:00  <wumpus> I wonder if it can be done without storing more headers though
407 2017-01-05T19:10:02  <luke-jr> but it doesn't sounds like this PR will actually fix it, and fixing it may be more complicated than it seems due to the point gmaxwell raised
408 2017-01-05T19:10:17  <gmaxwell> My understanding is that there are cases where invalid blocks make us ignore later headers (normally a good thing) which will prevent them from triggering the warning.
409 2017-01-05T19:10:35  <wumpus> I really don't like storing otherwise unnecessary data forever
410 2017-01-05T19:10:42  <BlueMatt> wumpus: store only headers required to prove to yourself upon restart that you should display a warning, and prune the (separate) storage for that?
411 2017-01-05T19:10:49  <sipa> we could prune old header chains
412 2017-01-05T19:10:54  <sipa> (both from disk and memory)
413 2017-01-05T19:10:59  <BlueMatt> or that
414 2017-01-05T19:11:03  <BlueMatt> from memory....sounds hard
415 2017-01-05T19:11:08  <wumpus> we could, sure, but right now we don't, so should be careful not to store more than necessary
416 2017-01-05T19:11:09  <BlueMatt> on-disk/restart-only sounds doable
417 2017-01-05T19:11:14  <petertodd> wumpus: provided theres a reasonable minimum PoW to storing it, it'll never be all *that* much extra data given it's just headers
418 2017-01-05T19:11:14  <jtimon> re: invariant for storage of headers: remind you that matt moved the nTime check from CheckBlockHeader() to ContextualCheckBlockHeader()
419 2017-01-05T19:11:15  <sipa> yeah, on restart it trivial
420 2017-01-05T19:11:25  <wumpus> yes on startup would be good enough
421 2017-01-05T19:11:33  <morcos> I think it would be wise to use our limited time to concentrate on things people think are really important for 0.14, it doesn't sound like anyone is making that argument about this change?
422 2017-01-05T19:11:47  <sipa> agree
423 2017-01-05T19:11:49  <jl2012> ok, please move on
424 2017-01-05T19:11:54  <gmaxwell> I'd like improvements here, but I don't think it's 0.14 critical.
425 2017-01-05T19:12:00  <wumpus> other proposed topics?
426 2017-01-05T19:12:10  <BlueMatt> 0.14 prs-to-review...
427 2017-01-05T19:12:14  <luke-jr> morcos: this change is mostly useful to plan for a future hardfork, but I don't think it's critical it's in 0.14
428 2017-01-05T19:12:20  <wumpus> BlueMatt: https://github.com/bitcoin/bitcoin/pulls?q=is%3Aopen+is%3Apr+milestone%3A0.14.0
429 2017-01-05T19:12:35  <BlueMatt> wumpus: many of those are almost certainly not gonna make it
430 2017-01-05T19:12:38  <morcos> luke-jr: heh, ok, i'll put tha ton my hard-fork planning list, i have it handy right here
431 2017-01-05T19:12:55  <wumpus> BlueMatt: that's a chicken-egg problem though as it depends on who reviews it
432 2017-01-05T19:13:00  <BlueMatt> true
433 2017-01-05T19:13:13  <sipa> so the topic here for the discussion should be what to prioritize for review
434 2017-01-05T19:13:16  <wumpus> I agree, though
435 2017-01-05T19:13:29  <BlueMatt> well if we're short for topics parallel processmessages...if folks think they will not have time to review it, then I'll skip it, but I have one based on cory's current net pr at https://github.com/theuni/bitcoin/compare/connman-locks...TheBlueMatt:2017-01-parallel-processmessages?expand=1
436 2017-01-05T19:13:31  <cfields> agree with sipa
437 2017-01-05T19:13:47  <BlueMatt> and think it would be a huge improvement for some use-cases
438 2017-01-05T19:13:49  <wumpus> I just meant that the lis is already very long, so let's at least try not to add much more
439 2017-01-05T19:13:53  <sipa> so open question: what would people like to see in 0.14, if review effort wasn't a bottleneck
440 2017-01-05T19:14:01  <wumpus> named arguments
441 2017-01-05T19:14:03  <BlueMatt> or, what is the priority
442 2017-01-05T19:14:03  <gmaxwell> I really feel uncomfortable with last minute concurrency changes.
443 2017-01-05T19:14:06  <jtimon> proposed topic: custom blockchains for 0.14 (ie how realistic it is to hope to get https://github.com/bitcoin/bitcoin/pull/8994 merged for 0.14 ? )
444 2017-01-05T19:14:13  <luke-jr> there was some desire for #8775 #8694 #7533 in 0.14, but they're not tagged as such
445 2017-01-05T19:14:15  <gribble> https://github.com/bitcoin/bitcoin/issues/8775 | RPC refactoring: Access wallet using new GetWalletForJSONRPCRequest by luke-jr · Pull Request #8775 · bitcoin/bitcoin · GitHub
446 2017-01-05T19:14:17  <gribble> https://github.com/bitcoin/bitcoin/issues/8694 | Basic multiwallet support by luke-jr · Pull Request #8694 · bitcoin/bitcoin · GitHub
447 2017-01-05T19:14:19  <gribble> https://github.com/bitcoin/bitcoin/issues/7533 | RPC: sendrawtransaction: Allow the user to ignore/override specific rejections by luke-jr · Pull Request #7533 · bitcoin/bitcoin · GitHub
448 2017-01-05T19:14:21  <jtimon> custom chainparams really
449 2017-01-05T19:14:23  <BlueMatt> gmaxwell: it tries very hard to limit concurrency changes - its whitelisted on messages, plus other things
450 2017-01-05T19:14:39  <wumpus> gmaxwell: same
451 2017-01-05T19:14:54  <morcos> i'd like to see the improvements to block relay #9375, #9441, #9447 and possibly parallel ProcessMessages
452 2017-01-05T19:14:56  <BlueMatt> gmaxwell: no open prs of mine make any significant concurrency changes
453 2017-01-05T19:14:57  <gribble> https://github.com/bitcoin/bitcoin/issues/9375 | Relay compact block messages prior to full block connection by TheBlueMatt · Pull Request #9375 · bitcoin/bitcoin · GitHub
454 2017-01-05T19:14:59  <gribble> https://github.com/bitcoin/bitcoin/issues/9441 | Net: Massive speedup. Net locks overhaul by theuni · Pull Request #9441 · bitcoin/bitcoin · GitHub
455 2017-01-05T19:15:00  <gribble> https://github.com/bitcoin/bitcoin/issues/9447 | Allow 2 simultaneous block downloads by morcos · Pull Request #9447 · bitcoin/bitcoin · GitHub
456 2017-01-05T19:15:08  <BlueMatt> gmaxwell: or at least they try hard not to
457 2017-01-05T19:15:14  <BlueMatt> s/not//
458 2017-01-05T19:15:18  <cfields> wumpus: +1 for named arguments. Will re-review.
459 2017-01-05T19:15:31  <gmaxwell> BlueMatt: we really have inadequate testing there, as cfield's version assert has shown us.
460 2017-01-05T19:15:35  <morcos> +1 on named arguments as well... will amke future PR's easier/better
461 2017-01-05T19:15:49  <BlueMatt> gmaxwell: helgrind works well, it turns out :), but, agreed
462 2017-01-05T19:16:03  <gmaxwell> BlueMatt: only if you actually execute the codepaths.
463 2017-01-05T19:16:15  <BlueMatt> sure
464 2017-01-05T19:16:29  <gmaxwell> Where are we with the multiwallet support?
465 2017-01-05T19:16:35  <cfields> BlueMatt: maybe you could briefly describe what you're hoping to immediately improve?
466 2017-01-05T19:16:46  <instagibbs_> gmaxwell: there's one refactor outsanding I believe
467 2017-01-05T19:16:59  <luke-jr> gmaxwell: 3 PRs left, 9375 and 9441
468 2017-01-05T19:17:15  <sipa> 9441? sure?
469 2017-01-05T19:17:21  <luke-jr> err
470 2017-01-05T19:17:23  <instagibbs_> 8775
471 2017-01-05T19:17:26  <luke-jr> 8775 8694*
472 2017-01-05T19:17:35  <gmaxwell> I had been hoping for that and the utxo scriptpubkey index (#8660) in 0.14, but it looks like the latter has been abandoned by its requester.
473 2017-01-05T19:17:37  <gribble> https://github.com/bitcoin/bitcoin/issues/8660 | txoutsbyaddress index (take 2) by djpnewton · Pull Request #8660 · bitcoin/bitcoin · GitHub
474 2017-01-05T19:18:01  <wumpus> gmaxwell: yes, that's unfortunate
475 2017-01-05T19:18:39  <sipa> i'd like to see #9441 in to get the performance benefit
476 2017-01-05T19:18:39  <BlueMatt> cfields: specifically, because many miners rely on bitcoind submitblock -> p2p network latency to relay their blocks out, this ends up being pretty important for miners in several ways, so speeding up the relay (hopefully without introducing a ton of new concurrency outside of cmpctblock/getblocktxn/blocktxn message processing) would be a massive win for many miners
477 2017-01-05T19:18:41  <gribble> https://github.com/bitcoin/bitcoin/issues/9441 | Net: Massive speedup. Net locks overhaul by theuni · Pull Request #9441 · bitcoin/bitcoin · GitHub
478 2017-01-05T19:18:44  <jtimon> for efficiency, maybe https://github.com/bitcoin/bitcoin/pull/8498 helps, but nobody has found the time to benchmark that in years...
479 2017-01-05T19:19:02  <BlueMatt> yes, so multiwallet and at least the currently-open net prs are review focus
480 2017-01-05T19:19:03  <gmaxwell> wumpus: I think it's suffered less attention than it would have recieved because it's poorly labled and people keep thinking its a blockchain index.
481 2017-01-05T19:19:19  <morcos> ok well if i had to pick one, i think 9375 makes a huge difference
482 2017-01-05T19:19:42  <wumpus> gmaxwell: looks like droark might pick it up
483 2017-01-05T19:20:04  <gmaxwell> BlueMatt: well I had a PR that removed the biggest source of submitblock latency-- it's a couple lines changes,  I assume its functionality has been duplicated in one of cfields overlapping PRs that I closed that one in favor of.
484 2017-01-05T19:20:22  <morcos> if nothing else the caching of the block/cmpctblock that you are about to send to all your peers reduces the time per per from 25ms to <1ms
485 2017-01-05T19:20:58  <BlueMatt> gmaxwell: yes, its in the "Net: Massive speedup" one, but the validation time cost (which the parallel getblocktxn/processmessages stuff + the fast relay stuff fixes)
486 2017-01-05T19:21:23  <BlueMatt> gmaxwell: for current-tip you really want both, but the net stuff you're referring to isnt the only thing here
487 2017-01-05T19:21:25  <gmaxwell> I am going to be irritated if 9441 misses 0.14.  I had an alternative PR that resulted in the same speedup which I think was much less invasive, but I closed it because cfields prefered the other change because it serviced his overall refactor planning.
488 2017-01-05T19:22:01  <BlueMatt> I think that one is pretty far along, its gotten a lot of eyes even if not so much acks
489 2017-01-05T19:22:42  <BlueMatt> <BlueMatt> yes, so multiwallet and at least the currently-open net prs are review focus <-- any other things to add to that list
490 2017-01-05T19:22:44  <BlueMatt> ?
491 2017-01-05T19:22:54  <wumpus> gmaxwell: let's focus on making that one get in then (I do think there's some regression risk, as it's a pretty invasive change to do last minute)
492 2017-01-05T19:22:59  <sipa> i'll focus on the net locks overhault, named args, early compact block relay
493 2017-01-05T19:23:01  <morcos> gmaxwell: so 9441 doesn't count as concurrency changes you are worried about merging now
494 2017-01-05T19:23:12  <gmaxwell> wumpus: that was my feeling too but yea.
495 2017-01-05T19:23:18  <morcos> +1 sipa's list
496 2017-01-05T19:23:27  <gmaxwell> morcos: right, I think it's invasive but it shouldn't be meaningfully creating new concurrency.
497 2017-01-05T19:23:41  <wumpus> sgtm
498 2017-01-05T19:23:44  <wumpus> #action focus on the net locks overhault, named args, early compact block relay
499 2017-01-05T19:23:46  <BlueMatt> sip, ok, named args it is, also multi-wallet?
500 2017-01-05T19:24:10  <BlueMatt> a
501 2017-01-05T19:24:11  <gmaxwell> The caching improvements as part of early compact block are nice. One option is if we feel uncomfortable about early compact blocks is that we disable that part and just take the caching.
502 2017-01-05T19:24:11  <BlueMatt> sipa
503 2017-01-05T19:24:16  <instagibbs_> luke-jr: might make sense to split out QT stuff for time
504 2017-01-05T19:24:29  <luke-jr> instagibbs_: planning to do so, once 8775 is merged
505 2017-01-05T19:24:33  <wumpus> multi-wallet may be still too many PRs away for 0.14 , dunno how realistic it is to get that in, though we certainly can make progress with the refactors
506 2017-01-05T19:24:35  <jtimon> which pr is named args?
507 2017-01-05T19:24:48  <sipa> jtimon: #8811
508 2017-01-05T19:24:51  <gribble> https://github.com/bitcoin/bitcoin/issues/8811 | rpc: Add support for JSON-RPC named arguments by laanwj · Pull Request #8811 · bitcoin/bitcoin · GitHub
509 2017-01-05T19:24:51  <morcos> Obviously I think 9138 (improve fee estimation) needs to be merged, but i think its ACK'ed enough (excpet it had some rebases)
510 2017-01-05T19:24:54  <BlueMatt> gmaxwell: the fast-relay stuff there has been /super/ scaled back...at this point its only a) if its the first thing you're annoucing at that height, and b) if its built directly on your tip
511 2017-01-05T19:25:00  <BlueMatt> gmaxwell: so hopefully its easier to be comfortable with it
512 2017-01-05T19:25:02  <gmaxwell> On the remaining multiwallet, I felt one of the outstanding refactor PRs introduced a fair amount of not very C++ish code, but who am I to judge? and I didn't know what to recommend instead, so I asked sipa to look at it but I doubt he's had a chance yet.
513 2017-01-05T19:25:08  <luke-jr> instagibbs_: although Qt stuff ties in with RPC stuff for the debug window
514 2017-01-05T19:25:11  <wumpus> morcos: if something is ready for merge you should let me know :)
515 2017-01-05T19:25:33  <morcos> well at this point, my judgement isn't to be trusted.. :)
516 2017-01-05T19:25:53  <gmaxwell> BlueMatt: remaining concerns are things like "are we going to accidentally DOS attack our peers by announcing something and then reorging" and things like that.
517 2017-01-05T19:26:08  <jonasschnelli> Multiwallet: I think need to rebase this one: #8764
518 2017-01-05T19:26:10  <gribble> https://github.com/bitcoin/bitcoin/issues/8764 | [Wallet] get rid of pwalletMain, add simple CWallets infrastructure by jonasschnelli · Pull Request #8764 · bitcoin/bitcoin · GitHub
519 2017-01-05T19:26:13  <BlueMatt> gmaxwell: yes, hence scaling it back...been discussing it a bunch with folks in the past few days
520 2017-01-05T19:26:28  <luke-jr> jonasschnelli: that kinda conflicts with the current multiwallet stuff
521 2017-01-05T19:26:29  <jonasschnelli> Maybe https://github.com/bitcoin/bitcoin/projects/2 needs update
522 2017-01-05T19:27:09  <jtimon> maybe https://github.com/bitcoin/bitcoin/projects/6 needs to be...closed?
523 2017-01-05T19:27:32  <luke-jr> might be more efficient to do 8764 after the basic parts are in
524 2017-01-05T19:28:51  <gmaxwell> For 0.14 I really want to see the second pass through createtransaction change from morcos in... fixes some concerning fee overpayment corner case.
525 2017-01-05T19:29:01  <gmaxwell> I don't know why #9312 isn't merged yet.
526 2017-01-05T19:29:03  <gribble> https://github.com/bitcoin/bitcoin/issues/9312 | Increase mempool expiry time to 2 weeks by morcos · Pull Request #9312 · bitcoin/bitcoin · GitHub
527 2017-01-05T19:29:22  <morcos> #9404 is super easy now, although needs rebase after #9465 is merged
528 2017-01-05T19:29:24  <gribble> https://github.com/bitcoin/bitcoin/issues/9404 | Smarter coordination of change and fee in CreateTransaction. by morcos · Pull Request #9404 · bitcoin/bitcoin · GitHub
529 2017-01-05T19:29:25  <gribble> https://github.com/bitcoin/bitcoin/issues/9465 | [Wallet] Do not perform ECDSA signing in the fee calculation inner loop. by gmaxwell · Pull Request #9465 · bitcoin/bitcoin · GitHub
530 2017-01-05T19:29:45  <sipa> i read a few things about accidental extreme fee
531 2017-01-05T19:30:32  <jtimon> maybe related to estimate fee for the very next block now disabled? (no idea, just thinking out loud)
532 2017-01-05T19:30:39  <sipa> is that related to 9138 ?
533 2017-01-05T19:30:41  <wumpus> gmaxwell: same holds for you, if something is ready for merging you should let me know
534 2017-01-05T19:30:49  <sipa> or 9404?
535 2017-01-05T19:31:01  <gmaxwell> #9404 though I really want it in, I haven't actually reviewed the code becuase I know it'll be simpler after 9465. (the story there is a user reported an issue that might be that fee bug, I went go fix it, realized it would be easier to fix after factoring out the signing.. did that.. then realized your preexisting patch was already the fix I wanted. :P )
536 2017-01-05T19:31:02  <gribble> https://github.com/bitcoin/bitcoin/issues/9404 | Smarter coordination of change and fee in CreateTransaction. by morcos · Pull Request #9404 · bitcoin/bitcoin · GitHub
537 2017-01-05T19:31:12  <wumpus> 9312 clearly is
538 2017-01-05T19:31:21  <morcos> sipa: both, well disabling fee estimates for 1 already went in, not part of 9138
539 2017-01-05T19:31:24  <luke-jr> jtimon: https://www.reddit.com/r/Bitcoin/comments/5ltw5n/bitcoin_core_v0131_sends_enormously_high_fee/
540 2017-01-05T19:31:35  <luke-jr> perhaps ^ should be our next topic
541 2017-01-05T19:31:35  <morcos> but both could cause high fees
542 2017-01-05T19:31:37  <wumpus> I think I stopped paying attention there when a certain person started trolling then lost track of it.
543 2017-01-05T19:31:39  <sipa> can someone explain what causes this?
544 2017-01-05T19:31:46  <sipa> (i don't visit reddit)
545 2017-01-05T19:31:49  <morcos> yes
546 2017-01-05T19:31:51  *** TomMc has joined #bitcoin-core-dev
547 2017-01-05T19:31:55  <BlueMatt> ^ that
548 2017-01-05T19:32:00  <kanzure> luke-jr: see 9404, i think
549 2017-01-05T19:32:04  <gmaxwell> luke-jr: I believe its fixed by 9404.  Of course, I can't know for sure, not enough info.
550 2017-01-05T19:32:39  *** CubicEarth has quit IRC
551 2017-01-05T19:32:39  <sipa> oh, is it change unnecessarily converted to fee?
552 2017-01-05T19:32:40  <instagibbs_> gmaxwell: so it's wallet-related code, not estimation
553 2017-01-05T19:32:41  <morcos> the 9404 case is caused when you select coins to pay for a tx, calculate fee and realize you dont' have enough, so you have to go and reselect coins.  you end up selecting many fewer for whatever reason, and now you have enough fee of course, and you end up paying the fee you calculated for the prior iteration
554 2017-01-05T19:32:46  <luke-jr> gmaxwell: well, OP's post there said he's using estimatefee :/
555 2017-01-05T19:32:57  <morcos> gmaxwell: 9404 is already rebased on 9465 as of this morning, so easy peasy to review now
556 2017-01-05T19:32:59  <gmaxwell> But the user seemed to be reporting that it payed several times the fee estimator figures (at least thats my read on it), which supports 9404 over 9138  though 9138 needs to go in too.
557 2017-01-05T19:33:07  <gmaxwell> morcos: oh missed that, will review.
558 2017-01-05T19:33:22  <jonasschnelli> #9294 should also go into 0.14 (needs overhaul, my turn) and some form of a HD rescan would be great.
559 2017-01-05T19:33:24  <gribble> https://github.com/bitcoin/bitcoin/issues/9294 | Use internal HD chain for change outputs (hd split) by jonasschnelli · Pull Request #9294 · bitcoin/bitcoin · GitHub
560 2017-01-05T19:33:41  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/ce43630d1e97...a72f76ca3d5d
561 2017-01-05T19:33:41  <bitcoin-git> bitcoin/master 5f0e27f Alex Morcos: Increase mempool expiry time to 2 weeks
562 2017-01-05T19:33:42  <bitcoin-git> bitcoin/master a72f76c Wladimir J. van der Laan: Merge #9312: Increase mempool expiry time to 2 weeks...
563 2017-01-05T19:33:42  <luke-jr> gmaxwell: he sent you the debug log, did that indicate anything useful?
564 2017-01-05T19:33:56  <bitcoin-git> [bitcoin] laanwj closed pull request #9312: Increase mempool expiry time to 2 weeks (master...longerexpiry) https://github.com/bitcoin/bitcoin/pull/9312
565 2017-01-05T19:34:07  <gmaxwell> jonasschnelli:  do we still have nothing that removes key from the keypool when they show up in transactions out of order, so that a rescan while unlocked would successfully find everything?
566 2017-01-05T19:34:20  <gmaxwell> luke-jr: no. unfortunately.
567 2017-01-05T19:34:43  <gmaxwell> well it didn't suggest that the known ways that estimatefee could be high weren't being hit.
568 2017-01-05T19:34:45  <jonasschnelli> gmaxwell: we don't. But I'm working on it. Got distracted with SPV/BFD and 2016 visualisation.
569 2017-01-05T19:35:10  <gmaxwell> jonasschnelli: okay, I'll do it if you don't have time; I just figured you are much more recently familar with that code than I. Sorry to nag.
570 2017-01-05T19:35:11  <morcos> sipa: its also possible that fee estimation could temporarily be very high..  was MUCH more likely for estimatefee 1 though, which has already been disabled
571 2017-01-05T19:35:22  <sipa> morcos: ok
572 2017-01-05T19:35:28  <jonasschnelli> gmaxwell: I'm happy if you do it.
573 2017-01-05T19:35:30  <sipa> let's get those fixes in
574 2017-01-05T19:36:10  <jonasschnelli> gmaxwell: maybe use some prework form https://github.com/bitcoin/bitcoin/pull/9370
575 2017-01-05T19:36:14  <gmaxwell> TBH I knew about the issue fied by 9404 long ago, but I thought it had since been fixed... :(
576 2017-01-05T19:37:14  <gmaxwell> jonasschnelli: oh I thought I'd acked the fundraw reuse fix.. will review.
577 2017-01-05T19:37:36  <jonasschnelli> The correct one is: https://github.com/bitcoin/bitcoin/pull/9377
578 2017-01-05T19:38:06  <jonasschnelli> The one above is an older try that could be useful for hd restore.
579 2017-01-05T19:38:41  <jonasschnelli> Fun topic: 2016 Git Visualisation: I'd created a draft video, need feedback to overhaul it and place it on the bitcoincore.org website.
580 2017-01-05T19:38:47  <jonasschnelli> https://vimeo.com/198242328
581 2017-01-05T19:38:51  <jonasschnelli> Password coredev
582 2017-01-05T19:38:57  <jonasschnelli> (will be there for a couple of mins)
583 2017-01-05T19:39:14  <jonasschnelli> (sorry to spam the meeting)
584 2017-01-05T19:39:27  <gmaxwell> okay I concept acked, well I'll complete the review.
585 2017-01-05T19:40:04  <luke-jr> jonasschnelli: why password protect it and post the password in public? :P
586 2017-01-05T19:40:16  <jonasschnelli> Security by obscurity.
587 2017-01-05T19:40:18  <petertodd> luke-jr: MILITARY LEVEL BLOCKCHAIN SECURITY
588 2017-01-05T19:40:24  <jonasschnelli> heh
589 2017-01-05T19:40:41  <wumpus> hehe
590 2017-01-05T19:41:06  <petertodd> anyway, I think that constitutes an "effective access control" under the DMCA...
591 2017-01-05T19:41:22  <gmaxwell> Who called this meeting?
592 2017-01-05T19:41:28  <sipa> jonasschnelli: short comment: overuse of capitalization (why are Day and Commit capitalized) and dashes (Code-contributors should be written with a space in between)
593 2017-01-05T19:41:47  <jonasschnelli> sipa: Thanks, will adapt
594 2017-01-05T19:41:58  <instagibbs_> any other topics?
595 2017-01-05T19:42:50  <wumpus> apparently not!
596 2017-01-05T19:42:58  <instagibbs_> everyone's watching the video
597 2017-01-05T19:43:08  <kanzure> chainparams?
598 2017-01-05T19:43:20  <wumpus> looks like we'll close the first meeting of 2017 early
599 2017-01-05T19:43:29  <kanzure> 8994
600 2017-01-05T19:43:30  <wumpus> what is there to discuss about chainparams?
601 2017-01-05T19:43:46  <kanzure> for 0.14, i think.
602 2017-01-05T19:43:53  <BlueMatt> final list of things to focus for review? multi-wallet, currently-open net prs, fee ones, what else?
603 2017-01-05T19:44:07  <BlueMatt> oh, and multiargs
604 2017-01-05T19:44:14  <BlueMatt> rpcarg thing
605 2017-01-05T19:44:17  <jonasschnelli> and hd chain-split/rstore
606 2017-01-05T19:44:23  <jtimon> wumpus, on my part #8994
607 2017-01-05T19:44:25  <gribble> https://github.com/bitcoin/bitcoin/issues/8994 | Testchains: Introduce custom chain whose constructor... by jtimon · Pull Request #8994 · bitcoin/bitcoin · GitHub
608 2017-01-05T19:44:39  <gmaxwell> I think that is really a lot less important than everything else listed.
609 2017-01-05T19:44:58  <gmaxwell> (as people using that are also probably using git master)
610 2017-01-05T19:44:58  <morcos> are we really trying to get all these wallet changes in?
611 2017-01-05T19:45:03  <wumpus> yes it doesn't seem to make a lot of sense to focus last-minute review attention on that
612 2017-01-05T19:45:04  <jtimon> sure, feedback is still welcomed though
613 2017-01-05T19:45:08  <morcos> should we focus on some over others?
614 2017-01-05T19:45:11  <BlueMatt> morcos: yea, I think thats more than will make it, but that was the list
615 2017-01-05T19:45:11  <gmaxwell> (so merging it after 14 means just weeks of delay for someone who wants to use it)
616 2017-01-05T19:45:20  <gmaxwell> jtimon: fair enough.
617 2017-01-05T19:45:24  <wumpus> morcos: the fee fixes obviously have priority
618 2017-01-05T19:45:44  <jtimon> I doubt it will get to 0.14 that's why I asked "how realistic..."
619 2017-01-05T19:45:45  <wumpus> anything that can cause users to spend unnecessary coins should be first priority
620 2017-01-05T19:45:52  <morcos> well i guess i meant between hd-chain/split and multiwallet
621 2017-01-05T19:45:59  <BlueMatt> i think maybe multi-wallet is less likely so maybe less priority, but maybe others disagree since that would be a super nice user-facing feature
622 2017-01-05T19:46:07  <instagibbs_> I think multiwallet would be great... lots of demand for something like that
623 2017-01-05T19:46:14  <gmaxwell> I would prioritize fee fixes, net/relay things, hd/rescan improvements, multiwallet, the thousand other open PRs.
624 2017-01-05T19:46:17  <instagibbs_> but yes bigger changes
625 2017-01-05T19:46:26  <morcos> gmaxwell: in order?
626 2017-01-05T19:46:34  <gmaxwell> There is a lot of demand for multiwallet and I feel like if we don't get it done it'll continue to slip.
627 2017-01-05T19:46:35  <morcos> don't forget named args?
628 2017-01-05T19:46:38  <gmaxwell> morcos: yes that was an order.
629 2017-01-05T19:46:39  <instagibbs_> >thousand other open PRs
630 2017-01-05T19:46:50  <jonasschnelli> gmaxwell: Would multiwallet in 0.14 include the GUI?
631 2017-01-05T19:47:07  <wumpus> I think 0.14 multiwallet is too late - better to merge it as first thing for 0.15, then improve it in master
632 2017-01-05T19:47:08  <jonasschnelli> Have we already discussed how to select the wallet over RPC?
633 2017-01-05T19:47:09  <luke-jr> multiwallet is in Knots already, so may be less important in that sense (since users who want it can get it); stuff like HD split can't really go in Knots without being more final
634 2017-01-05T19:47:13  <wumpus> it will need a lot of last-minute fixes Im sure
635 2017-01-05T19:47:26  <luke-jr> jonasschnelli: a number of times :p
636 2017-01-05T19:47:30  <wumpus> a big feature like that is not done once it's merged
637 2017-01-05T19:47:53  <luke-jr> wumpus: it's not actually that big at this point
638 2017-01-05T19:48:14  <gmaxwell> At least on my earlier review it seemed like most of it was the refactors.
639 2017-01-05T19:48:17  <gmaxwell> Which helps.
640 2017-01-05T19:48:20  <luke-jr> 99% of it is renaming pwalletMain to pwallet in rpc files
641 2017-01-05T19:48:36  <jonasschnelli> But we need to be careful. Running with many wallets needs some testing.
642 2017-01-05T19:48:42  <morcos> sorry i'm not trying to be a downer, but both 9375 (fast compact block relay) and 9441 (net speedup) are big heavy review changes, so we shouldn't spread ourselves too thin if we realyl want those in
643 2017-01-05T19:48:43  <wumpus> in any case there are plenty of PRs to focus on, as said before they can't make it all in
644 2017-01-05T19:48:45  <jonasschnelli> Even if it's code-wise trivial
645 2017-01-05T19:49:16  <luke-jr> overall, I think multiwallet can be delayed in Core if other things need time
646 2017-01-05T19:49:21  <wumpus> if we can't make any choices to postpone things, either 0.13 will slip incredibly (I'd hate that) or we'll have to randomly drop things last minute
647 2017-01-05T19:49:31  <wumpus> agree with morcos
648 2017-01-05T19:49:39  <sipa> 0.13 slipping now would indeed be terrible!
649 2017-01-05T19:49:44  <luke-jr> heh
650 2017-01-05T19:49:48  <sipa> ;)
651 2017-01-05T19:49:49  <gmaxwell> hah
652 2017-01-05T19:50:22  <wumpus> lol
653 2017-01-05T19:50:47  <gmaxwell> wumpus: if we slip it we slip it, but if people are active on review and testing I think we don't need to.  I really wish the net changes were less invasive but thats water under the bridge now.
654 2017-01-05T19:51:07  <gmaxwell> I do believe the release will be delayed from fixes for just the things we already have in now.
655 2017-01-05T19:51:16  <luke-jr> am I likely to be of any help reviewing the net stuff if I'm not up to speed on the net refactoring so far?
656 2017-01-05T19:51:21  <wumpus> gmaxwell: I don't want to let it slip on features in any case, on bugfixes is more acceptable
657 2017-01-05T19:51:27  <BlueMatt> note: we have at least 4 regressions in master which are 0.14-blocking which do not yet have prs open to fix them
658 2017-01-05T19:51:30  <wumpus> so it's clear what to focus on then
659 2017-01-05T19:51:30  <BlueMatt> so....thats a thing
660 2017-01-05T19:51:43  <gmaxwell> wumpus: right, well ... you could just merge everything outstanding and then all slips are bugfix related! :P
661 2017-01-05T19:51:46  <instagibbs_> BlueMatt: there a list?
662 2017-01-05T19:51:47  <BlueMatt> oh, sorry, 1 has an open pr
663 2017-01-05T19:52:02  <wumpus> BlueMatt: are the issues tagged appropriately?
664 2017-01-05T19:52:09  <BlueMatt> yes, tagged 0.14, i believe
665 2017-01-05T19:52:13  <wumpus> ok
666 2017-01-05T19:52:28  <gmaxwell> AFAIK we are not actually waiting on the competion of any feature changes. (except perhaps some rescan improvements).. E.g. almost everything I think we might have in 0.14 has a PR already open.
667 2017-01-05T19:52:32  <cfields> to reviewers, don't let the amount of commits in 9441 scare you. Almost all of them are very tiny, explicitly to make review easier
668 2017-01-05T19:52:46  <BlueMatt> at least #9479, #9027, #9148 and #9212
669 2017-01-05T19:52:48  <gribble> https://github.com/bitcoin/bitcoin/issues/9479 | An error has occurred and has been logged. Please contact this bot's administrator for more information.
670 2017-01-05T19:52:48  <BlueMatt> maybe others
671 2017-01-05T19:52:48  <gribble> https://github.com/bitcoin/bitcoin/issues/9027 | Unbounded reorg memory usage · Issue #9027 · bitcoin/bitcoin · GitHub
672 2017-01-05T19:52:49  <sipa> confirming what cfields said
673 2017-01-05T19:52:49  <gribble> https://github.com/bitcoin/bitcoin/issues/9148 | Wallet RPCs can return stale info due to ProcessNewBlock Race · Issue #9148 · bitcoin/bitcoin · GitHub
674 2017-01-05T19:52:50  <gribble> https://github.com/bitcoin/bitcoin/issues/9212 | Assertion failed: (nSendVersion != 0), function GetSendVersion, file ./net.h, line 775. · Issue #9212 · bitcoin/bitcoin · GitHub
675 2017-01-05T19:52:51  <morcos> oh shit, yeah sorry, one is mine..  , lets quickly decide which direction we want to take on that.  Do we revert #9240 or do we not care about the notifications?  I think #9371 is too late for 0.14
676 2017-01-05T19:52:52  <gmaxwell> completion*
677 2017-01-05T19:52:53  <gribble> https://github.com/bitcoin/bitcoin/issues/9240 | Remove txConflicted by morcos · Pull Request #9240 · bitcoin/bitcoin · GitHub
678 2017-01-05T19:52:54  <gribble> https://github.com/bitcoin/bitcoin/issues/9371 | Notify on removal by morcos · Pull Request #9371 · bitcoin/bitcoin · GitHub
679 2017-01-05T19:53:27  <sipa> morcos: if 9371 is too late, we need to revert 9240... but maybe that is not something we need to know now?
680 2017-01-05T19:53:32  <sipa> a revert can be do at the last minute
681 2017-01-05T19:53:39  <sipa> *done
682 2017-01-05T19:53:42  <morcos> If we're reverting #9240, it'll conflict, definitely with 9138 and probably already, so let me know and I'll make a revert PR
683 2017-01-05T19:53:43  <BlueMatt> yea, we can revert on the 0.14 branch at that point?
684 2017-01-05T19:53:44  <gribble> https://github.com/bitcoin/bitcoin/issues/9240 | Remove txConflicted by morcos · Pull Request #9240 · bitcoin/bitcoin · GitHub
685 2017-01-05T19:53:51  * jtimon reiterates his dissapointment on not having removed checkpoints for everything except progress estimation, that doesn't have a PR...
686 2017-01-05T19:54:35  <sipa> jtimon: 9472 removes checkpoints for the purpose of progress estimation
687 2017-01-05T19:54:39  <morcos> sipa: well i like 9371, but it overlaps a lot with #8549 and we haven't resolved direction
688 2017-01-05T19:54:40  <sipa> :)
689 2017-01-05T19:54:40  <jtimon> I mean gmaxwell you had that practically done already
690 2017-01-05T19:54:41  <gribble> https://github.com/bitcoin/bitcoin/issues/8549 | zmq: mempool notifications by jmcorgan · Pull Request #8549 · bitcoin/bitcoin · GitHub
691 2017-01-05T19:54:52  <jtimon> sipa: oh, nice, will have a look
692 2017-01-05T19:54:59  *** brg444 has quit IRC
693 2017-01-05T19:55:29  <gmaxwell> jtimon: not going to have one either, not any time soon (1) it requires a consensus change; and I don't have the appetite to carry forward in the adversarial climate of the mailing list (which I am not on for a long time now), and (2)  Sipa disagrees with my one strategy for removing the signature checking dependency, and petertodd disagrees with the other.
694 2017-01-05T19:55:37  <wumpus> Madars: what I don't like about 9371 is that is that it keeps the list of removed transactions on mempool, instead of an external object listening for signals
695 2017-01-05T19:55:44  <wumpus> sorry s/Madars/Morcos
696 2017-01-05T19:56:02  <wumpus> morcos: this means it can only support one client listening for removals at most
697 2017-01-05T19:56:08  <gmaxwell> (sipa disagrees that we can just check all signatures; petertodd disagrees with the proposal that we use burried by 30 days of work+other conditions)
698 2017-01-05T19:56:18  <jtimon> gmaxwell: mhmm, I didn't remember a consensus change, must be missing something, but sure, if it needs it, definitely no time to do it for 0.14
699 2017-01-05T19:56:39  <wumpus> morcos: for the rest I'm ok with it, and it doesn't conflict with 8549 too much
700 2017-01-05T19:56:58  <sipa> gmaxwell: what about the idea of once crossing a certain amount of work, requiring a higher minimum difficulty?
701 2017-01-05T19:57:09  <gmaxwell> jtimon: the part of it that didn't either need a consensus change (uppping the minimum difficulty) and didn't change the signature checking,  has already been merged.
702 2017-01-05T19:57:17  <morcos> wumpus: i was trying to keep notifications from happening while we were locked in reorg..   couldn't we later make it so the mempoolremovaltracker could interface with multiple clients or something
703 2017-01-05T19:57:22  <sipa> ah, right, consensus change
704 2017-01-05T19:57:31  <gmaxwell> sipa: it's a consensus change, and I implemented it, and asked for review which jtimon gave some, but... consensus change.
705 2017-01-05T19:57:52  <wumpus> morcos: I just don't like making a notification mechanism stateful, but that may be a personal thing
706 2017-01-05T19:58:15  <jtimon> thanks for the info, wasn't up to date on the subject
707 2017-01-05T19:58:16  <wumpus> morcos: but ok maybe this is the only way to handle reorgs sanely
708 2017-01-05T19:58:19  <gmaxwell> but I really have no interest in writing a bit and getting treated like shit by zander and voskull or whatever other trolls inhabit the list today.
709 2017-01-05T19:58:20  <morcos> but isn't that what we've just done on purpose with ConnectTrace?
710 2017-01-05T19:58:38  <morcos> i guess not quite the same thing... but accomplishes same goal
711 2017-01-05T19:58:45  <jtimon> maybe in this 2 minutes...should I rebase the super-trivial #9279 ?
712 2017-01-05T19:58:46  <gribble> https://github.com/bitcoin/bitcoin/issues/9279 | Consensus: Move CFeeRate out of libconsensus by jtimon · Pull Request #9279 · bitcoin/bitcoin · GitHub
713 2017-01-05T19:59:04  * luke-jr ponders if it would make sense to increase min difficulty to 50% of current difficulty.
714 2017-01-05T19:59:09  <wumpus> morcos: well at least that's an external object passed in
715 2017-01-05T19:59:23  *** BlueMatt has left #bitcoin-core-dev
716 2017-01-05T19:59:27  *** BlueMatt has joined #bitcoin-core-dev
717 2017-01-05T19:59:28  *** CubicEarth has joined #bitcoin-core-dev
718 2017-01-05T19:59:28  *** brg444 has joined #bitcoin-core-dev
719 2017-01-05T19:59:32  <sipa> gmaxwell: maybe you should explain your idea to luke-jr
720 2017-01-05T19:59:54  <morcos> i know... but so many layers..  anyway, ok we'll see what happens..  i'll make the revert later if i need to
721 2017-01-05T20:00:04  <gmaxwell> sipa: https://github.com/gmaxwell/bitcoin/commit/2db190b183c5204da23191ca642c7f6cad412ae3
722 2017-01-05T20:00:06  <instagibbs_> time of meeting has ended
723 2017-01-05T20:00:11  <wumpus> #endmeeting
724 2017-01-05T20:00:11  <lightningbot> Meeting ended Thu Jan  5 20:00:11 2017 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
725 2017-01-05T20:00:11  <lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-01-05-19.00.html
726 2017-01-05T20:00:11  <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-01-05-19.00.txt
727 2017-01-05T20:00:11  <lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-01-05-19.00.log.html
728 2017-01-05T20:00:32  <bitcoin-git> [bitcoin] jonasschnelli pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/a72f76ca3d5d...fd7d8c7b35ae
729 2017-01-05T20:00:32  <bitcoin-git> bitcoin/master 54f8026 Jonas Schnelli: [CoinControl] Allow non-wallet owned change addresses
730 2017-01-05T20:00:33  <bitcoin-git> bitcoin/master fd7d8c7 Jonas Schnelli: Merge #9413: [CoinControl] Allow non-wallet owned change addresses...
731 2017-01-05T20:00:35  <jtimon> #9279 would make libconsensus lighter :p
732 2017-01-05T20:00:37  <gribble> https://github.com/bitcoin/bitcoin/issues/9279 | Consensus: Move CFeeRate out of libconsensus by jtimon · Pull Request #9279 · bitcoin/bitcoin · GitHub
733 2017-01-05T20:00:47  <bitcoin-git> [bitcoin] jonasschnelli closed pull request #9413: [CoinControl] Allow non-wallet owned change addresses (master...2016/12/qt_cc_change) https://github.com/bitcoin/bitcoin/pull/9413
734 2017-01-05T20:01:12  <gmaxwell> sipa: presumably that explains the idea precisely enough. :)
735 2017-01-05T20:01:15  <wumpus> morcos: I guess your mechanism could be extended to multiple clients if the start/stop timespans for storing mempool removals are not determined by the client
736 2017-01-05T20:01:26  <wumpus> morcos: then the whole list of removed transactions could be passed to all listeners
737 2017-01-05T20:01:44  <morcos> yes i think thats what i meant
738 2017-01-05T20:01:47  <wumpus> morcos: and it's listener-agnostic without calling a signal for every transaction
739 2017-01-05T20:02:06  <jtimon> what about fetching the minimum difficulty from the 6 biggest mining pools?
740 2017-01-05T20:02:12  * jtimon hides
741 2017-01-05T20:02:29  <gmaxwell> /kb jtimon
742 2017-01-05T20:02:32  <wumpus> morcos: not sure what the batching granularity should be in that case though
743 2017-01-05T20:02:41  <petertodd> jtimon: so long as we have a service that defines which those 6 pools are
744 2017-01-05T20:02:42  <wumpus> morcos: per block, per reorg?
745 2017-01-05T20:02:56  <jtimon> kb ?
746 2017-01-05T20:03:00  <kanzure> kickban
747 2017-01-05T20:03:00  <BlueMatt> jtimon: lol
748 2017-01-05T20:03:01  <jonasschnelli> jtimon: heh. Read this: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-January/013432.html
749 2017-01-05T20:03:11  <luke-jr> gmaxwell: sounds reasonable
750 2017-01-05T20:03:13  <morcos> wumpus: well i batched it per lock of cs_main i think
751 2017-01-05T20:03:26  <BlueMatt> jonasschnelli: lol, I hope that was a joke too
752 2017-01-05T20:03:45  <morcos> which basically is ActivateBestChain(or Step can't remember) and per AcceptToMemoryPool
753 2017-01-05T20:04:01  <jtimon> jonasschnelli: right, sorry, should have said 5, didn't remember correctly :p
754 2017-01-05T20:04:07  <jonasschnelli> haha
755 2017-01-05T20:04:32  <gmaxwell> luke-jr: A bip for it would probably want to specify how the timestamps must be distorted if difficulty gets down to the limit x 4.
756 2017-01-05T20:04:45  <gmaxwell> luke-jr: which I've not bothered thinking through.
757 2017-01-05T20:04:53  *** jannes has quit IRC
758 2017-01-05T20:05:36  <luke-jr> gmaxwell: I'd be inclined to suggest if we ever got to that point, a PoW change may be necessary just to avoid attacks from the ex-miners?
759 2017-01-05T20:05:57  <jtimon> anyway, should go back to vacations, we spaniards give the christmas presents tomorrow and stuff (yeah we like doing things late)
760 2017-01-05T20:06:04  <gmaxwell> luke-jr: I fully agree. but it would be a little crazy if the software just ... breaks. on its own (e.g. picks a difficulty whos blocks they won't accept).
761 2017-01-05T20:06:09  <luke-jr> jtimon: not just spaniards!
762 2017-01-05T20:06:28  <jtimon> who else?
763 2017-01-05T20:06:29  <luke-jr> gmaxwell: throw a JSON exception? ☺
764 2017-01-05T20:06:37  <luke-jr> jtimon: we also do gifts on the Epiphany here
765 2017-01-05T20:07:06  <jtimon> interesting, will ask more next time we meet, sorry everyone else for the offtopic
766 2017-01-05T20:07:33  <gmaxwell> luke-jr: it should be as simple as (if difficulty < 4 * limit, there is a maximum timestamp for exach block).
767 2017-01-05T20:07:57  <luke-jr> gmaxwell: yes, if it makes sense to continue that chain
768 2017-01-05T20:08:38  <gmaxwell> maybe four lines of code, just would take a little thinking to figure out the right four lines.  doesn't even have to be a consensus rule, just a thing that createnetblock does.
769 2017-01-05T20:08:57  * luke-jr shrugs
770 2017-01-05T20:08:58  <adiabat> luke-jr: but what about if the hashrate is actually down 5X "naturally"; e.g. global thermonuclear war? :)
771 2017-01-05T20:09:21  <gmaxwell> adiabat: we're not talking about 5x. We're talking about 1/20000th.
772 2017-01-05T20:09:26  <luke-jr> ^
773 2017-01-05T20:09:49  <adiabat> luke-jr: ahh, you mean 4X on min-difficulty
774 2017-01-05T20:09:56  <gmaxwell> luke-jr: it probably doesn't make sense to continue the chain, but it would be goofy if in tests the system fails on its own because of the rule.
775 2017-01-05T20:10:06  <adiabat> luke-jr: yeah not even thermonuclear war acheives that.
776 2017-01-05T20:10:39  <gmaxwell> maybe it does, but then who cares? y'all be dead in those cases.
777 2017-01-05T20:11:40  <luke-jr> XD
778 2017-01-05T20:12:07  <kanzure> death is merely a temporary inconvenience for thermonuclear scaling
779 2017-01-05T20:12:19  <gmaxwell> in any case, raising the minimum difficulty was one of the two remaining issues for checkpoint removal.
780 2017-01-05T20:12:27  <gmaxwell> The other is the signature checking bypass.
781 2017-01-05T20:12:36  <luke-jr> kanzure: I'm not sure it's scaling to decrease demand.
782 2017-01-05T20:13:44  <gmaxwell> I have two proposals for that: (1) we just get rid of it,  sipa doesn't like this.  (2) we replace it with a non-checkpoint based bypass but instead a proof of work based one, and petertodd opposed the best proposal thus far (and I assume otherws would too)
783 2017-01-05T20:14:04  <gmaxwell> https://github.com/bitcoin/bitcoin/pull/9180
784 2017-01-05T20:15:22  *** instagibbs has joined #bitcoin-core-dev
785 2017-01-05T20:16:00  <luke-jr> would it be so terrible to keep a single "checkpoint" just for sigcheck bypass?
786 2017-01-05T20:16:13  *** instagibbs_ has quit IRC
787 2017-01-05T20:17:25  *** jtimon has quit IRC
788 2017-01-05T20:17:30  <gmaxwell> luke-jr: for the purpose of people misunderstanding the security model I think thats just as bad as what we have now.
789 2017-01-05T20:17:58  <luke-jr> what if it's a param the user can specify?
790 2017-01-05T20:18:07  <luke-jr> (with a sane default)
791 2017-01-05T20:18:26  <gmaxwell> luke-jr: the fact that you can -checkpoints=0 now doesn't prevent people from mistaking that for the origin of the security of the history.
792 2017-01-05T20:19:01  <luke-jr> :<
793 2017-01-05T20:19:42  <gmaxwell> I have been thinking that maybe a configurable known good value ANDed with the 9180 process might be good enough. But I'm not sure.
794 2017-01-05T20:20:26  <gmaxwell> and the continued obession with checkpoints by people (esp. academics) makes me want to not work on bitcoin anymore, so I might not be thinking about it objectively.
795 2017-01-05T20:20:30  <luke-jr> what if we have multiple such values, all but one of which are bogus valid chains? ☺
796 2017-01-05T20:20:45  *** CubicEarth has quit IRC
797 2017-01-05T20:21:57  <gmaxwell> from a security perspective if I was happy with PR9180 on its own, then I'd be happy with it anded with a restriction on what chain(s) it applies to.  So I think thats fine, but the problem is that people focus on the freeking hardcoded value, so what I hoped to do was just eliminate it.
798 2017-01-05T20:24:13  *** CubicEarth has joined #bitcoin-core-dev
799 2017-01-05T20:26:54  <gmaxwell> luke-jr:  in any case we are in an optimally bad situation now.
800 2017-01-05T20:28:37  <gmaxwell> because these hardcoded values pin the consensus we won't move them forward, and won't find out if making them do less would resolve the people confusing them for the security model, but because they (maybe) make a meaningful impact on IBD speed we won't take them out.
801 2017-01-05T20:29:22  <gmaxwell> and the alternative of using POW can be argued to give more control of the system to miners, so thats opposed too.
802 2017-01-05T20:29:54  <gmaxwell> (I don't share that belief because the threshold is so large that miners that could do that could simply confiscate all the coins anyways by replacing the chain back to 295k)
803 2017-01-05T20:30:31  <gmaxwell> (but I don't think the position is an absurd one)
804 2017-01-05T20:32:07  *** CubicEarth has quit IRC
805 2017-01-05T20:32:57  <gmaxwell> luke-jr: perhaps we can do this in the short term.  Introduce a "all prior signatures known good" blockhash which is used for script checking but doesn't pin the chain. Ancestors of that block get scriptchecked.. and then we can set that to a current height.  Then the chain pining checkpoints can be eliminated once we've done something about the header flooding... but regardless we can leave the
806 2017-01-05T20:33:03  <gmaxwell> m alone for now.
807 2017-01-05T20:33:23  <sdaftuar> gmaxwell: +1, seems reasonable to me.
808 2017-01-05T20:34:30  <luke-jr> Ancestors of that block get scriptchecked..?
809 2017-01-05T20:34:42  <gmaxwell> er don't get scriptchecked. :)
810 2017-01-05T20:35:48  <luke-jr> ok, that sounds pretty much like what I thought the near-term goal already was ☺
811 2017-01-05T20:37:57  <gmaxwell> okay, well I'll go PR the scriptcheck skipping change I guess.
812 2017-01-05T20:40:23  *** wvr has joined #bitcoin-core-dev
813 2017-01-05T20:47:15  *** Chris_Stewart_5 has quit IRC
814 2017-01-05T20:49:00  <gmaxwell> I guess I'll open this question up to more than sipa:
815 2017-01-05T20:49:01  <gmaxwell> 22:48 <gmaxwell> I'm not impressed by the bare pointer twizzling in this commit:  https://github.com/bitcoin/bitcoin/pull/8775/files#diff-ad6efdc354b57bd1fa29fc3abb6e2872R233 esp with the type punning can  you suggest to luke a more C++ way to do this?
816 2017-01-05T20:49:06  <gmaxwell> 22:49 <gmaxwell> (thats also the code I would have written, but I'd feel I was probably doing it wrong while doing it.)
817 2017-01-05T20:50:59  <BlueMatt> are we staunchly against having a "class CWallet" in !define WALLET?
818 2017-01-05T20:51:11  <BlueMatt> forward declaration, that is
819 2017-01-05T20:59:24  <luke-jr> that would make things so much simpler XD
820 2017-01-05T21:03:04  *** Chris_Stewart_5 has joined #bitcoin-core-dev
821 2017-01-05T21:07:07  <gmaxwell> I think the problem is that it may not compile since disabling the wallet at compile time changes our dependencies.
822 2017-01-05T21:07:12  *** Sosumi has quit IRC
823 2017-01-05T21:07:20  *** Lauda has quit IRC
824 2017-01-05T21:07:31  *** Lauda has joined #bitcoin-core-dev
825 2017-01-05T21:07:46  <gmaxwell> I suppose it could be a dummy class CWallet that exists in that case though.
826 2017-01-05T21:08:02  <gmaxwell> e.g. has no methods or fields.
827 2017-01-05T21:08:57  <BlueMatt> gmaxwell: not dummy, forward declartion
828 2017-01-05T21:09:03  <BlueMatt> gmaxwell: i think in this case it will still compile
829 2017-01-05T21:09:14  <BlueMatt> since there are no actual uses of it, just a pointer to it
830 2017-01-05T21:09:23  <BlueMatt> which the compiler knows how to do, even without knowing shit about the class
831 2017-01-05T21:11:52  <gmaxwell> Makes sense. Even to my C loving eyes, the code in 8775 struck me as pretty yucky.  If it's forward declared and you try to use it when you shouldn't the result will fail to compile or link. So.. seems fine to me.
832 2017-01-05T21:12:01  <gmaxwell> but I'm not the person likely to have useful opinions on that.
833 2017-01-05T21:12:26  <BlueMatt> I kinda agree, i /think/ forward decl will work, easy to test at least
834 2017-01-05T21:12:51  *** laurentmt has quit IRC
835 2017-01-05T21:13:07  <sipa> if it compiles with just a forward declaration, it should be fine
836 2017-01-05T21:13:18  <sipa> and i guess it should
837 2017-01-05T21:13:32  <sipa> i wouldn't want that in a longer-term solution, but that code will be in flux for a while
838 2017-01-05T21:14:05  <luke-jr> so I can use a fwd decl?
839 2017-01-05T21:14:42  <BlueMatt> luke-jr: try it, if it compiles, yes :)
840 2017-01-05T21:14:56  <luke-jr> pretty sure it will
841 2017-01-05T21:14:57  * sipa is strongly against code that does not compile
842 2017-01-05T21:15:00  <gmaxwell> If it works and someone thinks its somehow worse than functions with void pointers in their typedefs and typecasting all over the place I will argue with them. :P
843 2017-01-05T21:15:45  <luke-jr> sipa: but..!
844 2017-01-05T21:16:03  <sipa> luke-jr: i know, i know. bitcoin would be much more secure if it didn't compile
845 2017-01-05T21:16:05  <gmaxwell> sipa: code that does not compile never crashes.
846 2017-01-05T21:16:08  <luke-jr> lol
847 2017-01-05T21:17:06  <BlueMatt> it also doesn't have bugs
848 2017-01-05T21:17:10  <BlueMatt> (for some definition of bugs)
849 2017-01-05T21:17:21  <BlueMatt> then again nothing has bugs for some definition of bugs
850 2017-01-05T21:18:55  <luke-jr> but also everything has bugs for some definition of bugs <.<
851 2017-01-05T21:19:31  <luke-jr> btw, this doesn't look like it's going to change more than a few lines of code in this particular PR
852 2017-01-05T21:19:46  <luke-jr> and may have to still use the ugly cast in Qt code to pass through signals/slots, dunno
853 2017-01-05T21:20:45  *** Guyver2 has quit IRC
854 2017-01-05T21:32:33  *** CubicEarth has joined #bitcoin-core-dev
855 2017-01-05T21:37:27  <bitcoin-git> [bitcoin] sipa pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/fd7d8c7b35ae...a7d55c933853
856 2017-01-05T21:37:27  <bitcoin-git> bitcoin/master b3d7b1c Gregory Maxwell: Wallet: Do not perform ECDSA in the fee calculation inner loop....
857 2017-01-05T21:37:27  <bitcoin-git> bitcoin/master a7d55c9 Pieter Wuille: Merge #9465: [Wallet] Do not perform ECDSA signing in the fee calculation inner loop....
858 2017-01-05T21:37:41  *** CubicEarth has quit IRC
859 2017-01-05T21:37:45  <bitcoin-git> [bitcoin] sipa closed pull request #9465: [Wallet] Do not perform ECDSA signing in the fee calculation inner loop. (master...no_signing_in_inner_loop) https://github.com/bitcoin/bitcoin/pull/9465
860 2017-01-05T21:52:45  <bitcoin-git> [bitcoin] sipa pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/a7d55c933853...c252685aa586
861 2017-01-05T21:52:46  <bitcoin-git> bitcoin/master ba3cecf Pieter Wuille: Share unused mempool memory with coincache...
862 2017-01-05T21:52:46  <bitcoin-git> bitcoin/master c252685 Pieter Wuille: Merge #8610: Share unused mempool memory with coincache...
863 2017-01-05T22:22:41  <bitcoin-git> [bitcoin] sipa pushed 11 new commits to master: https://github.com/bitcoin/bitcoin/compare/c252685aa586...f646275b90b1
864 2017-01-05T22:22:42  <bitcoin-git> bitcoin/master 4df4479 Alex Morcos: Remove extraneous LogPrint from fee estimation...
865 2017-01-05T22:22:42  <bitcoin-git> bitcoin/master 60ac00d Alex Morcos: Don't track transactions at all during IBD....
866 2017-01-05T22:22:43  <bitcoin-git> bitcoin/master 84f7ab0 Alex Morcos: Remove member variable hadNoDependencies from CTxMemPoolEntry...
867 2017-01-05T22:22:52  <bitcoin-git> [bitcoin] sipa closed pull request #9138: Improve fee estimation (master...refactorFeeEstimation) https://github.com/bitcoin/bitcoin/pull/9138
868 2017-01-05T22:33:24  <instagibbs> BlueMatt, if it doesn't compile there is no unexpected behavior :)
869 2017-01-05T22:36:52  <gmaxwell> luke-jr: fking signals/slots.
870 2017-01-05T22:49:25  *** CubicEarth has joined #bitcoin-core-dev
871 2017-01-05T22:59:40  <gmaxwell> morcos: do you think it would be reasonable for CreateTransaction or its kin to log the feerate its using for its construction?  So that if there is further concern about strange fees there is log evidence if the strange fee was a result of the estimator vs something else?
872 2017-01-05T23:00:22  *** CubicEarth has quit IRC
873 2017-01-05T23:34:05  *** CubicEarth has joined #bitcoin-core-dev
874 2017-01-05T23:37:12  <luke-jr> a bigger concern I think is that logging is not enabled until it's too late
875 2017-01-05T23:37:50  <luke-jr> so unless you log it by default (which may be reasonable for manual activity?), it won't be there when you want it
876 2017-01-05T23:38:44  <luke-jr> maybe log it by default ASAP and we can quiet it in a few releases after things have been sufficiently resolved?
877 2017-01-05T23:58:18  *** brg444 has quit IRC
878 2017-01-05T23:59:30  *** brg444 has joined #bitcoin-core-dev