12017-01-05T00:17:32  *** Guyver2 has quit IRC
  22017-01-05T00:36:37  *** instagibbs has quit IRC
  32017-01-05T00:37:17  *** instagibbs has joined #bitcoin-core-dev
  42017-01-05T01:00:39  *** abpa has quit IRC
  52017-01-05T01:04:00  *** juscamarena has quit IRC
  62017-01-05T01:18:21  *** juscamarena has joined #bitcoin-core-dev
  72017-01-05T01:40:53  *** abpa has joined #bitcoin-core-dev
  82017-01-05T01:41:12  *** abpa has quit IRC
  92017-01-05T01:57:26  *** Ylbam has quit IRC
 102017-01-05T02:07:54  *** Squidicc has joined #bitcoin-core-dev
 112017-01-05T02:11:25  *** Squidicuz has quit IRC
 122017-01-05T02:32:58  *** Chris_Stewart_5 has quit IRC
 132017-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.
 142017-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
 152017-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
 162017-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.
 172017-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
 182017-01-05T02:38:27  <gmaxwell> okay bot, we got the picture.
 192017-01-05T02:40:54  <sipa> haha
 202017-01-05T02:41:06  <sipa> maybe it needs rate limiting
 212017-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?
 222017-01-05T02:49:13  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 232017-01-05T02:49:43  *** juscamarena has quit IRC
 242017-01-05T02:55:54  *** CubicEarth has joined #bitcoin-core-dev
 252017-01-05T02:58:30  *** Chris_Stewart_5 has quit IRC
 262017-01-05T02:58:34  <sipa> btcdrak: i don't think it triggers based on things it says itself
 272017-01-05T03:05:20  *** trippysalmon has quit IRC
 282017-01-05T03:05:20  *** wolfspraul has quit IRC
 292017-01-05T03:05:20  *** tadasv has quit IRC
 302017-01-05T03:05:27  *** wolfspraul has joined #bitcoin-core-dev
 312017-01-05T03:05:33  *** trippysalmon has joined #bitcoin-core-dev
 322017-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
 332017-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
 342017-01-05T03:08:07  *** tadasv has joined #bitcoin-core-dev
 352017-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
 362017-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.
 372017-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
 382017-01-05T03:16:31  *** windsok has quit IRC
 392017-01-05T03:52:11  *** windsok has joined #bitcoin-core-dev
 402017-01-05T03:56:35  *** Victor_sueca has joined #bitcoin-core-dev
 412017-01-05T03:59:16  *** Victorsueca has quit IRC
 422017-01-05T04:00:37  *** Squidicc has quit IRC
 432017-01-05T04:00:58  *** Squidicuz has joined #bitcoin-core-dev
 442017-01-05T04:05:03  *** chris2000 has joined #bitcoin-core-dev
 452017-01-05T04:08:25  *** chris200_ has quit IRC
 462017-01-05T04:10:41  *** CubicEarth has quit IRC
 472017-01-05T05:30:17  *** roidster has quit IRC
 482017-01-05T06:06:07  *** kadoban has quit IRC
 492017-01-05T06:15:53  *** cannon-c has joined #bitcoin-core-dev
 502017-01-05T06:36:55  *** dcousens has quit IRC
 512017-01-05T06:40:17  *** justanotheruser is now known as leibnitz
 522017-01-05T06:40:28  *** leibnitz is now known as OfficialLeibniz
 532017-01-05T06:59:51  *** Squidicc has joined #bitcoin-core-dev
 542017-01-05T07:00:15  *** dermoth has quit IRC
 552017-01-05T07:01:10  *** dermoth has joined #bitcoin-core-dev
 562017-01-05T07:03:01  *** Squidicuz has quit IRC
 572017-01-05T07:05:41  *** arubi has joined #bitcoin-core-dev
 582017-01-05T07:40:25  *** To7 has joined #bitcoin-core-dev
 592017-01-05T07:41:39  *** LeMiner has joined #bitcoin-core-dev
 602017-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
 612017-01-05T07:48:20  *** PRab_ has joined #bitcoin-core-dev
 622017-01-05T07:49:55  *** PRab has quit IRC
 632017-01-05T07:50:08  *** PRab_ is now known as PRab
 642017-01-05T07:51:33  *** BashCo has quit IRC
 652017-01-05T07:52:11  *** BashCo has joined #bitcoin-core-dev
 662017-01-05T07:56:37  *** BashCo has quit IRC
 672017-01-05T08:09:01  *** Squidicc has quit IRC
 682017-01-05T08:11:55  *** udiWertheimer has quit IRC
 692017-01-05T08:13:51  *** BashCo has joined #bitcoin-core-dev
 702017-01-05T08:14:25  *** BashCo_ has joined #bitcoin-core-dev
 712017-01-05T08:17:38  *** Ylbam has joined #bitcoin-core-dev
 722017-01-05T08:17:57  *** BashCo has quit IRC
 732017-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.
 742017-01-05T08:32:13  *** juscamarena has joined #bitcoin-core-dev
 752017-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.
 762017-01-05T08:35:05  *** juscamarena__ has joined #bitcoin-core-dev
 772017-01-05T08:35:13  *** juscamarena_ has joined #bitcoin-core-dev
 782017-01-05T08:35:20  *** juscamarena__ has quit IRC
 792017-01-05T08:36:37  *** waxwing has quit IRC
 802017-01-05T08:44:34  *** waxwing has joined #bitcoin-core-dev
 812017-01-05T08:57:49  *** Squidicuz has joined #bitcoin-core-dev
 822017-01-05T09:12:23  *** paveljanik has quit IRC
 832017-01-05T09:29:13  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/7dac1e5e9e88...70145064153a
 842017-01-05T09:29:13  <bitcoin-git> bitcoin/master 0388afe Luke Dashjr: Let autoconf detect presence of EVP_MD_CTX_new...
 852017-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...
 862017-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
 872017-01-05T09:29:48  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/70145064153a...48d7e0d5e463
 882017-01-05T09:29:48  <bitcoin-git> bitcoin/master ce370c1 Pieter Wuille: Mark the minconf parameter to move as ignored
 892017-01-05T09:29:49  <bitcoin-git> bitcoin/master 48d7e0d Wladimir J. van der Laan: Merge #9474: Mark the minconf parameter to move as ignored...
 902017-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
 912017-01-05T09:30:09  *** Alina-malina has quit IRC
 922017-01-05T09:37:33  *** Alina-malina has joined #bitcoin-core-dev
 932017-01-05T09:43:53  <wumpus> jonasschnelli: wow
 942017-01-05T09:49:27  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/48d7e0d5e463...c4b7d4f79c85
 952017-01-05T09:49:27  <bitcoin-git> bitcoin/master 407cdd6 Pieter Wuille: Do not evaluate hidden LogPrint arguments
 962017-01-05T09:49:28  <bitcoin-git> bitcoin/master c4b7d4f Wladimir J. van der Laan: Merge #9417: Do not evaluate hidden LogPrint arguments...
 972017-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
 982017-01-05T09:51:45  *** Guyver2 has joined #bitcoin-core-dev
 992017-01-05T10:00:47  <jonasschnelli> Currently verifying my data..
1002017-01-05T10:01:05  <jonasschnelli> But I guess we had 1563 PRs opened in 2016.
1012017-01-05T10:01:28  <jonasschnelli> 1032 merged (66%)
1022017-01-05T10:01:47  <jonasschnelli> 146 still open (~9%)
1032017-01-05T10:02:09  <jonasschnelli> 385 closed (~24.6%)
1042017-01-05T10:02:28  <jonasschnelli> (though the last one may have some false-positives [manual closed merges])
1052017-01-05T10:02:42  <wumpus> it at least feels like it was a really busy year in that regard
1062017-01-05T10:11:05  *** MarcoFalke has joined #bitcoin-core-dev
1072017-01-05T10:11:49  <bitcoin-git> [bitcoin] laanwj pushed 5 new commits to master: https://github.com/bitcoin/bitcoin/compare/c4b7d4f79c85...cfe41d7a6034
1082017-01-05T10:11:50  <bitcoin-git> bitcoin/master e5534d2 Karl-Johan Alm: Added std::unique_ptr<> wrappers with deleters for libevent modules.
1092017-01-05T10:11:51  <bitcoin-git> bitcoin/master 7f7f102 Karl-Johan Alm: Switched bitcoin-cli.cpp to use RAII unique pointers with deleters.
1102017-01-05T10:11:51  <bitcoin-git> bitcoin/master 280a559 Karl-Johan Alm: Added some simple tests for the RAII-style events.
1112017-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
1122017-01-05T10:17:12  *** jannes has joined #bitcoin-core-dev
1132017-01-05T10:19:58  <bitcoin-git> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/cfe41d7a6034...406f35d99d0f
1142017-01-05T10:19:59  <bitcoin-git> bitcoin/master d5aa198 Doug: Allow linearization scripts to support hash byte reversal...
1152017-01-05T10:19:59  <bitcoin-git> bitcoin/master 3c8f63b Doug: Make linearize scripts Python 3-compatible.
1162017-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)...
1172017-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
1182017-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?
1192017-01-05T10:24:37  *** Alina-malina has quit IRC
1202017-01-05T10:25:09  <kallewoof> Should've asked on #bitcoin-dev. Migrating, sorry.
1212017-01-05T10:27:15  *** Alina-malina has joined #bitcoin-core-dev
1222017-01-05T10:33:03  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/406f35d99d0f...4cfd57d2e382
1232017-01-05T10:33:03  <bitcoin-git> bitcoin/master 73f4119 Karl-Johan Alm: Refactoring: Removed using namespace <xxx> from bench/ and test/ source files.
1242017-01-05T10:33:04  <bitcoin-git> bitcoin/master 4cfd57d MarcoFalke: Merge #9281: Refactor: Remove using namespace <xxx> from bench/ & test/ sources...
1252017-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
1262017-01-05T10:33:35  <wumpus> kallewoof: depends on the reason for 'sometimes' I suppose :)
1272017-01-05T10:36:40  <wumpus> I'd say random non-deterministic behavior is never intended
1282017-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
1292017-01-05T10:39:07  *** dcousens has joined #bitcoin-core-dev
1302017-01-05T10:41:56  *** fanquake has joined #bitcoin-core-dev
1312017-01-05T10:42:05  <kallewoof> @wumpus: http://pastebin.com/EqupZuFM (missing case) vs http://pastebin.com/Phy6mN3G (present case).
1322017-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.
1332017-01-05T10:47:27  <wumpus> I wonder, does listing transactions not in blocks make sense at all for "listsinceblock"
1342017-01-05T10:47:51  <wumpus> apparently it's a difference with regard to what unconfirmed/conflicted transactions are listed
1352017-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.
1362017-01-05T10:48:07  *** Alina-malina has quit IRC
1372017-01-05T10:48:07  *** Alina-malina has joined #bitcoin-core-dev
1382017-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.
1392017-01-05T10:50:01  <wumpus> in that case not showing "orphaned" transactions would be better
1402017-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
1412017-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.
1422017-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.
1432017-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?
1442017-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
1452017-01-05T10:52:38  <wumpus> fanquake: well we're far from being able to remove those workaround
1462017-01-05T10:52:48  <wumpus> fanquake: it should stil support building with stable libevent :)
1472017-01-05T10:52:58  <wumpus> just with new libevent it can use the new features
1482017-01-05T10:53:07  <wumpus> (which it already does, in some places)
1492017-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
1502017-01-05T10:53:36  <fanquake> Might even be a proper release!
1512017-01-05T10:54:02  <wumpus> the only option for us I see there would be to copy the file somewhere and host it there
1522017-01-05T10:54:31  <fanquake> Yes we can do that also, we already host some files as a backup on bitcoincore.org.
1532017-01-05T10:54:50  <fanquake> I'd like to put Boost on there so we can remove our last use of SourceForge.
1542017-01-05T10:55:16  <wumpus> should ask cfields for that though, I don't have access to that server AFAIK
1552017-01-05T10:56:18  <fanquake> Yes I'll bring it up with him later on.
1562017-01-05T10:57:26  <fanquake> Does #9475 mean a 0.13.3 release quite soon? Or waiting a while longer for more bug reports.
1572017-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
1582017-01-05T10:58:01  <wumpus> fanquake: if you ask me, I don't think a build system issue necessitates an urgent release
1592017-01-05T10:58:06  <wumpus> we should focus on 0.14.0 now
1602017-01-05T11:01:14  <wumpus> #9475 should just go on the stack of things to include when a 0.13.3 is released
1612017-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
1622017-01-05T11:07:04  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/4cfd57d2e382...ce43630d1e97
1632017-01-05T11:07:04  <bitcoin-git> bitcoin/master d29505d jonnynewbs: Fix transaction size comments. Size now refers to virtual size as defined in BIP141.
1642017-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....
1652017-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
1662017-01-05T11:21:00  *** luke-jr has quit IRC
1672017-01-05T11:21:09  *** luke-jr has joined #bitcoin-core-dev
1682017-01-05T11:22:33  *** jtimon has joined #bitcoin-core-dev
1692017-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
1702017-01-05T11:28:05  <MarcoFalke> wumpus: The rpcauth still needs a `make translate` to show up properly for translators in transifex.
1712017-01-05T11:28:16  <MarcoFalke> Not super important, but letting you know.
1722017-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?
1732017-01-05T11:29:15  <MarcoFalke> Thus, we could catch failures early
1742017-01-05T11:29:37  <MarcoFalke> (Not after they have been propagated to transifex)
1752017-01-05T11:39:52  *** Alsazia has joined #bitcoin-core-dev
1762017-01-05T11:39:56  <Alsazia> Premium link generator (30+ host supported) ---> www.galileo.pw
1772017-01-05T11:39:58  *** Alsazia has quit IRC
1782017-01-05T11:43:31  <phantomcircuit> wumpus, listsinceblock should almost certainly not list things which aren't actually in a block
1792017-01-05T11:55:44  *** d9b4bef9 has quit IRC
1802017-01-05T11:55:44  *** sdaftuar has quit IRC
1812017-01-05T11:55:45  *** gluytium has quit IRC
1822017-01-05T11:55:45  *** Evel-Knievel has quit IRC
1832017-01-05T11:55:45  *** crescendo has quit IRC
1842017-01-05T11:55:45  *** adam3us has quit IRC
1852017-01-05T11:55:45  *** baldur has quit IRC
1862017-01-05T11:55:45  *** da2ce7 has quit IRC
1872017-01-05T11:55:45  *** BlueMatt has quit IRC
1882017-01-05T11:55:45  *** phantomcircuit has quit IRC
1892017-01-05T11:55:45  *** thokon00 has quit IRC
1902017-01-05T11:55:45  *** pigeons has quit IRC
1912017-01-05T11:55:45  *** bad_duck has quit IRC
1922017-01-05T11:55:52  *** bad_duck has joined #bitcoin-core-dev
1932017-01-05T11:55:53  *** pigeons has joined #bitcoin-core-dev
1942017-01-05T11:55:53  *** gluytium has joined #bitcoin-core-dev
1952017-01-05T11:55:55  *** thokon00 has joined #bitcoin-core-dev
1962017-01-05T11:55:59  *** crescendo has joined #bitcoin-core-dev
1972017-01-05T11:56:00  *** sdaftuar has joined #bitcoin-core-dev
1982017-01-05T11:56:01  *** Evel-Knievel has joined #bitcoin-core-dev
1992017-01-05T11:56:06  *** baldur has joined #bitcoin-core-dev
2002017-01-05T11:56:08  *** d9b4bef9 has joined #bitcoin-core-dev
2012017-01-05T11:56:23  *** crescendo has quit IRC
2022017-01-05T11:56:24  *** crescendo has joined #bitcoin-core-dev
2032017-01-05T11:56:26  *** phantomcircuit has joined #bitcoin-core-dev
2042017-01-05T11:56:27  *** sdaftuar has quit IRC
2052017-01-05T11:56:27  *** sdaftuar has joined #bitcoin-core-dev
2062017-01-05T11:56:39  *** pigeons is now known as Guest73955
2072017-01-05T11:57:51  *** adam3us has joined #bitcoin-core-dev
2082017-01-05T11:57:54  *** da2ce7 has joined #bitcoin-core-dev
2092017-01-05T11:58:07  *** BlueMatt has joined #bitcoin-core-dev
2102017-01-05T11:58:07  *** BlueMatt has joined #bitcoin-core-dev
2112017-01-05T12:01:38  *** cannon-c has quit IRC
2122017-01-05T12:04:45  *** dcousens has quit IRC
2132017-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
2142017-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
2152017-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)
2162017-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.
2172017-01-05T13:04:40  *** laurentmt has joined #bitcoin-core-dev
2182017-01-05T13:05:58  *** laurentmt has quit IRC
2192017-01-05T13:19:13  *** gielbier is now known as gielbier-irc
2202017-01-05T13:23:45  *** Chris_Stewart_5 has joined #bitcoin-core-dev
2212017-01-05T13:31:52  *** Chris_Stewart_5 has quit IRC
2222017-01-05T13:33:41  <sipa> kallewoof: is it about double spends tgat your node has seen? they're not usually relayed by the network
2232017-01-05T13:35:41  <sipa> fanquake: he's in NY
2242017-01-05T13:36:01  *** paveljanik has joined #bitcoin-core-dev
2252017-01-05T13:45:40  *** jtimon has quit IRC
2262017-01-05T13:45:51  *** Chris_Stewart_5 has joined #bitcoin-core-dev
2272017-01-05T13:50:58  <fanquake> Just chased that code in 9451 back to "First commit"
2282017-01-05T14:05:10  *** AaronvanW has joined #bitcoin-core-dev
2292017-01-05T14:11:36  <wumpus> fanquake: hah, nice catch
2302017-01-05T14:14:05  *** BCBot_ has joined #bitcoin-core-dev
2312017-01-05T14:15:06  *** LeMiner has quit IRC
2322017-01-05T14:15:06  *** TD-Linux has quit IRC
2332017-01-05T14:15:06  *** LeMiner has joined #bitcoin-core-dev
2342017-01-05T14:15:06  *** LeMiner has joined #bitcoin-core-dev
2352017-01-05T14:15:07  *** BCBot has quit IRC
2362017-01-05T14:15:16  *** TD--Linux has joined #bitcoin-core-dev
2372017-01-05T14:16:27  <phantomcircuit> fanquake, i believe i was right there?
2382017-01-05T14:16:33  <phantomcircuit> seems to be about multi byte op codes
2392017-01-05T14:17:21  <sipa> even then it was redundant
2402017-01-05T14:17:28  <sipa> but it did make more sense
2412017-01-05T14:19:13  *** Giszmo has joined #bitcoin-core-dev
2422017-01-05T14:30:19  *** chris2000 has quit IRC
2432017-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
2442017-01-05T14:36:56  <phantomcircuit> i can fuzz test 9451 but not at the moment
2452017-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.
2462017-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.
2472017-01-05T14:44:25  <fanquake> Although your changeset seems to be smaller than the previous attempt. 59 files now vs 75 previous.
2482017-01-05T15:03:03  *** Chris_Stewart_5 has quit IRC
2492017-01-05T15:18:37  *** Chris_Stewart_5 has joined #bitcoin-core-dev
2502017-01-05T15:21:40  *** BashCo_ has quit IRC
2512017-01-05T15:22:18  *** BashCo has joined #bitcoin-core-dev
2522017-01-05T15:26:32  *** BashCo has quit IRC
2532017-01-05T15:33:43  *** kinlo has quit IRC
2542017-01-05T15:38:22  *** kinlo has joined #bitcoin-core-dev
2552017-01-05T15:46:16  *** BashCo has joined #bitcoin-core-dev
2562017-01-05T15:46:26  *** roidster has joined #bitcoin-core-dev
2572017-01-05T15:46:49  *** Squidicuz has quit IRC
2582017-01-05T15:47:19  *** Squidicuz has joined #bitcoin-core-dev
2592017-01-05T15:50:01  *** d9b4bef9 has quit IRC
2602017-01-05T15:51:08  *** d9b4bef9 has joined #bitcoin-core-dev
2612017-01-05T16:05:40  *** fanquake has quit IRC
2622017-01-05T16:21:12  *** gielbier-irc is now known as gielbier
2632017-01-05T16:34:49  *** MarcoFalke has left #bitcoin-core-dev
2642017-01-05T16:39:57  *** kadoban has joined #bitcoin-core-dev
2652017-01-05T16:52:35  *** abpa has joined #bitcoin-core-dev
2662017-01-05T17:05:35  *** LeMiner2 has joined #bitcoin-core-dev
2672017-01-05T17:08:02  *** LeMiner has quit IRC
2682017-01-05T17:08:02  *** LeMiner2 is now known as LeMiner
2692017-01-05T17:22:25  *** laurentmt has joined #bitcoin-core-dev
2702017-01-05T17:29:06  *** To7 has quit IRC
2712017-01-05T17:35:25  *** Squidicuz has quit IRC
2722017-01-05T17:35:51  *** Squidicuz has joined #bitcoin-core-dev
2732017-01-05T17:40:20  *** TD--Linux is now known as TD-Linux
2742017-01-05T17:40:20  *** TD-Linux has joined #bitcoin-core-dev
2752017-01-05T17:40:21  *** instagibbs has quit IRC
2762017-01-05T17:41:37  *** Chris_Stewart_5 has quit IRC
2772017-01-05T17:43:53  <gmaxwell> sipa:
2782017-01-05T17:43:55  <gmaxwell> ./.bitcoin/debug.log.reindex1  11670.622538
2792017-01-05T17:43:59  <gmaxwell> ./.bitcoin/debug.log.reindex2  12182.296543
2802017-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.
2812017-01-05T17:46:00  <gmaxwell> so it took eight and a half minutes longer, or a 4% slowdown.
2822017-01-05T17:54:53  *** Chris_Stewart_5 has joined #bitcoin-core-dev
2832017-01-05T18:08:56  *** jtimon has joined #bitcoin-core-dev
2842017-01-05T18:10:58  *** Chris_Stewart_5 has quit IRC
2852017-01-05T18:17:34  <sipa> gmaxwell: i made a graph of progress (according to my pr) vs time
2862017-01-05T18:17:43  <sipa> on my laptoo
2872017-01-05T18:17:46  <sipa> *laptoo
2882017-01-05T18:17:48  <sipa> *laptoP
2892017-01-05T18:18:12  <sipa> and it shows a very clear change in slope at 295000
2902017-01-05T18:19:18  *** Guest73955 is now known as pigeons
2912017-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
2922017-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.
2932017-01-05T18:20:08  <gmaxwell> so it makes a difference there, sure.. but it's only a small part of the chain.
2942017-01-05T18:22:34  *** LeMiner2 has joined #bitcoin-core-dev
2952017-01-05T18:24:57  *** Chris_Stewart_5 has joined #bitcoin-core-dev
2962017-01-05T18:25:02  *** LeMiner has quit IRC
2972017-01-05T18:25:02  *** LeMiner2 is now known as LeMiner
2982017-01-05T18:39:05  *** Sosumi has joined #bitcoin-core-dev
2992017-01-05T18:47:16  <morcos> gmaxwell: it works!  at least to 16
3002017-01-05T18:47:57  <morcos> and beyond with some minor'ish tweaks that might be overfitting to checkqueue
3012017-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
3022017-01-05T18:50:47  <gmaxwell> morcos: even without the checkqueue changes?
3032017-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
3042017-01-05T18:51:06  <gmaxwell> BlueMatt: you mean the huge volume of things that are going to miss 0.14? :(
3052017-01-05T18:51:17  <BlueMatt> gmaxwell: yea, probably :(
3062017-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
3072017-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 :/
3082017-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. :)
3092017-01-05T18:53:40  *** Squidicc has joined #bitcoin-core-dev
3102017-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
3112017-01-05T18:53:48  <sipa> gmaxwell: rebase #9319 ?
3122017-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
3132017-01-05T18:54:10  <BlueMatt> yea, super want that one for 0.14, and should be an easy target
3142017-01-05T18:54:19  <BlueMatt> already has some acks, too
3152017-01-05T18:55:19  <sipa> can i have a few more acks on #8610? i think the rewrite invalidated prior review
3162017-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
3172017-01-05T18:56:06  <gmaxwell> sipa: oh I didn't know one was needed there.
3182017-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?
3192017-01-05T18:56:09  *** LiberalSquash has joined #bitcoin-core-dev
3202017-01-05T18:56:13  *** LiberalSquash has left #bitcoin-core-dev
3212017-01-05T18:56:22  <sipa> morcos: yes, just that
3222017-01-05T18:56:32  <sipa> morcos: i mean compared to before implementing your approach
3232017-01-05T18:56:33  <gmaxwell> oh now I kinda wish I didn't load that PR...
3242017-01-05T18:57:01  *** Squidicuz has quit IRC
3252017-01-05T18:58:18  <BlueMatt> sipa: done (I recalled that I had already reviewed half of it yesterday...)
3262017-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)
3272017-01-05T18:59:55  <sipa> BLING
3282017-01-05T18:59:56  <gribble> https://github.com/bitcoin/bitcoin/issues/9138 | Improve fee estimation by morcos · Pull Request #9138 · bitcoin/bitcoin · GitHub
3292017-01-05T18:59:57  <BlueMatt> meeting
3302017-01-05T19:00:13  <sipa> morcos: i was waiting for acks
3312017-01-05T19:00:15  <wumpus> #startmeeting
3322017-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.
3332017-01-05T19:00:15  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
3342017-01-05T19:00:17  <jl2012> may I propose a topic first? need to sleep
3352017-01-05T19:00:22  <petertodd> hi
3362017-01-05T19:00:26  <BlueMatt> jl2012: go
3372017-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
3382017-01-05T19:00:44  <jonasschnelli> Hi
3392017-01-05T19:00:49  <jl2012> proposed topic: repair the fork warning system: https://github.com/bitcoin/bitcoin/pull/9443
3402017-01-05T19:01:00  <wumpus> #topic  repair the fork warning system
3412017-01-05T19:01:09  <sipa> concept ack on fixing it if it's broken!
3422017-01-05T19:01:12  *** instagibbs_ has joined #bitcoin-core-dev
3432017-01-05T19:01:17  <BlueMatt> concept ack 100%
3442017-01-05T19:01:22  <wumpus> haha yes concept ack. Haven't looked at the code yet.
3452017-01-05T19:01:28  <sipa> i haven't had time to look at the details... 0.14 is getting close
3462017-01-05T19:01:28  <jl2012> but this is more than just fixing it
3472017-01-05T19:01:37  <BlueMatt> but we've fucked that up several times already, so needs careful review, I think
3482017-01-05T19:01:44  <instagibbs_> here
3492017-01-05T19:01:56  <sipa> jl2012: elaborate?
3502017-01-05T19:02:04  <jl2012> it also stores invalid headers
3512017-01-05T19:02:07  <morcos> jl2012: are you trying to say you think it NEEDS to be in 0.14
3522017-01-05T19:02:43  <phantomcircuit> huh what
3532017-01-05T19:02:43  <jtimon> oh, meeting, wasn't planning on attending today, but really nothing to do until one hour from now...
3542017-01-05T19:02:45  <phantomcircuit> oh
3552017-01-05T19:02:47  <jl2012> specifically, it stores valid headers under an invalid block
3562017-01-05T19:03:00  <kanzure> hi.
3572017-01-05T19:03:01  <jl2012> also, headers with invalid nVersion are stored
3582017-01-05T19:03:10  <sipa> jl2012: but those do have valid PoW?
3592017-01-05T19:03:14  <jl2012> yes
3602017-01-05T19:03:22  <jl2012> and valid nTime
3612017-01-05T19:03:23  <sipa> iirc that is our only invariant for the storage of headers
3622017-01-05T19:03:30  <BlueMatt> jl2012: do we need to store them or can we just store them in memory?
3632017-01-05T19:03:38  <BlueMatt> but, I'm fine either way
3642017-01-05T19:04:03  <BlueMatt> looking at invalid headers with valid pow for user-warnings sounds good to me
3652017-01-05T19:04:09  <wumpus> stored headers are forever, both on disk and in memory, unfortunately
3662017-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
3672017-01-05T19:04:14  <luke-jr> jl2012: does this do anything to address that nodes sending us such chains will be DoS banned
3682017-01-05T19:04:15  <luke-jr> ?
3692017-01-05T19:04:29  <jl2012> won't be banned
3702017-01-05T19:04:32  *** brg444 has joined #bitcoin-core-dev
3712017-01-05T19:04:34  <sipa> (but i shouldn't comment on that before looking at code)
3722017-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. :(
3732017-01-05T19:04:58  <wumpus> the alternative to fixing it would be to just disable the system, at least for 0.14
3742017-01-05T19:05:04  <BlueMatt> gmaxwell: having reliable warning messages is the first step towards fixing that trust :)
3752017-01-05T19:05:04  <luke-jr> jl2012: so this removes the DoS banning for invalid blocks?
3762017-01-05T19:05:21  <jl2012> luke-jr: just for valid header
3772017-01-05T19:05:31  <wumpus> shipping it broken, especially with risk of false positives, indeed isn't going to do anything good
3782017-01-05T19:05:41  <jl2012> if the block content is invalid (e.g. invalid script), still banned
3792017-01-05T19:06:00  <gmaxwell> There is currently no false positive risk from it AFAIK.
3802017-01-05T19:06:03  <luke-jr> jl2012: which will lead to you not getting future headers
3812017-01-05T19:06:07  <petertodd> jl2012: to be clear, if the block is too large it will be banned as well?
3822017-01-05T19:06:09  <wumpus> having to store more data forever just to be able to warn seems a bit inefficient to me though
3832017-01-05T19:06:27  <jtimon> mhmm, the block is still invalid here, no? https://github.com/bitcoin/bitcoin/pull/9443/files#diff-24efdb00bfbe56b140fb006b562cc70bR3038
3842017-01-05T19:06:29  <wumpus> the block headers are never pruned, and all loaded into memory at start
3852017-01-05T19:06:30  <BlueMatt> petertodd: i dont think it changes anything wrt consensus code? the way I read it
3862017-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.
3872017-01-05T19:06:35  <jl2012> petertodd: should be, I don't change that part
3882017-01-05T19:06:37  <BlueMatt> petertodd: /any/ consensus logic
3892017-01-05T19:06:42  <sipa> i wonder if we need a detection of internal consensus errors (database corruption, CPU overheating, ...)
3902017-01-05T19:06:54  <petertodd> gmaxwell: we can deserialize if it's only a little bit too large though IIRC
3912017-01-05T19:06:58  <sipa> because 99.999% of all fork warning that are seen in practice as just broken nodes
3922017-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.
3932017-01-05T19:07:23  <gmaxwell> sipa: I think we do.
3942017-01-05T19:07:53  <gmaxwell> sipa: which ultimately should be used to trigger recovery from chainstate backup automatically. (I think)
3952017-01-05T19:07:55  <sipa> but i don't know how without having a thread in the background that computes Pi or so :p
3962017-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?
3972017-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...
3982017-01-05T19:08:43  *** CubicEarth has joined #bitcoin-core-dev
3992017-01-05T19:09:01  <jl2012> morcos: I think that has broken for a few versions
4002017-01-05T19:09:22  <gmaxwell> Broken just means that it won't trigger in all cases it might trigger, right?
4012017-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
4022017-01-05T19:09:25  <jl2012> so you may consider it as a new feature
4032017-01-05T19:09:33  <jl2012> gmaxwell: yes
4042017-01-05T19:09:35  <sipa> well it can be considered for 0.14.1 or so
4052017-01-05T19:09:43  <sipa> if it's a bugfix (which i think it is)
4062017-01-05T19:10:00  <wumpus> I wonder if it can be done without storing more headers though
4072017-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
4082017-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.
4092017-01-05T19:10:35  <wumpus> I really don't like storing otherwise unnecessary data forever
4102017-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?
4112017-01-05T19:10:49  <sipa> we could prune old header chains
4122017-01-05T19:10:54  <sipa> (both from disk and memory)
4132017-01-05T19:10:59  <BlueMatt> or that
4142017-01-05T19:11:03  <BlueMatt> from memory....sounds hard
4152017-01-05T19:11:08  <wumpus> we could, sure, but right now we don't, so should be careful not to store more than necessary
4162017-01-05T19:11:09  <BlueMatt> on-disk/restart-only sounds doable
4172017-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
4182017-01-05T19:11:14  <jtimon> re: invariant for storage of headers: remind you that matt moved the nTime check from CheckBlockHeader() to ContextualCheckBlockHeader()
4192017-01-05T19:11:15  <sipa> yeah, on restart it trivial
4202017-01-05T19:11:25  <wumpus> yes on startup would be good enough
4212017-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?
4222017-01-05T19:11:47  <sipa> agree
4232017-01-05T19:11:49  <jl2012> ok, please move on
4242017-01-05T19:11:54  <gmaxwell> I'd like improvements here, but I don't think it's 0.14 critical.
4252017-01-05T19:12:00  <wumpus> other proposed topics?
4262017-01-05T19:12:10  <BlueMatt> 0.14 prs-to-review...
4272017-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
4282017-01-05T19:12:20  <wumpus> BlueMatt: https://github.com/bitcoin/bitcoin/pulls?q=is%3Aopen+is%3Apr+milestone%3A0.14.0
4292017-01-05T19:12:35  <BlueMatt> wumpus: many of those are almost certainly not gonna make it
4302017-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
4312017-01-05T19:12:55  <wumpus> BlueMatt: that's a chicken-egg problem though as it depends on who reviews it
4322017-01-05T19:13:00  <BlueMatt> true
4332017-01-05T19:13:13  <sipa> so the topic here for the discussion should be what to prioritize for review
4342017-01-05T19:13:16  <wumpus> I agree, though
4352017-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
4362017-01-05T19:13:31  <cfields> agree with sipa
4372017-01-05T19:13:47  <BlueMatt> and think it would be a huge improvement for some use-cases
4382017-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
4392017-01-05T19:13:53  <sipa> so open question: what would people like to see in 0.14, if review effort wasn't a bottleneck
4402017-01-05T19:14:01  <wumpus> named arguments
4412017-01-05T19:14:03  <BlueMatt> or, what is the priority
4422017-01-05T19:14:03  <gmaxwell> I really feel uncomfortable with last minute concurrency changes.
4432017-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 ? )
4442017-01-05T19:14:13  <luke-jr> there was some desire for #8775 #8694 #7533 in 0.14, but they're not tagged as such
4452017-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
4462017-01-05T19:14:17  <gribble> https://github.com/bitcoin/bitcoin/issues/8694 | Basic multiwallet support by luke-jr · Pull Request #8694 · bitcoin/bitcoin · GitHub
4472017-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
4482017-01-05T19:14:21  <jtimon> custom chainparams really
4492017-01-05T19:14:23  <BlueMatt> gmaxwell: it tries very hard to limit concurrency changes - its whitelisted on messages, plus other things
4502017-01-05T19:14:39  <wumpus> gmaxwell: same
4512017-01-05T19:14:54  <morcos> i'd like to see the improvements to block relay #9375, #9441, #9447 and possibly parallel ProcessMessages
4522017-01-05T19:14:56  <BlueMatt> gmaxwell: no open prs of mine make any significant concurrency changes
4532017-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
4542017-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
4552017-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
4562017-01-05T19:15:08  <BlueMatt> gmaxwell: or at least they try hard not to
4572017-01-05T19:15:14  <BlueMatt> s/not//
4582017-01-05T19:15:18  <cfields> wumpus: +1 for named arguments. Will re-review.
4592017-01-05T19:15:31  <gmaxwell> BlueMatt: we really have inadequate testing there, as cfield's version assert has shown us.
4602017-01-05T19:15:35  <morcos> +1 on named arguments as well... will amke future PR's easier/better
4612017-01-05T19:15:49  <BlueMatt> gmaxwell: helgrind works well, it turns out :), but, agreed
4622017-01-05T19:16:03  <gmaxwell> BlueMatt: only if you actually execute the codepaths.
4632017-01-05T19:16:15  <BlueMatt> sure
4642017-01-05T19:16:29  <gmaxwell> Where are we with the multiwallet support?
4652017-01-05T19:16:35  <cfields> BlueMatt: maybe you could briefly describe what you're hoping to immediately improve?
4662017-01-05T19:16:46  <instagibbs_> gmaxwell: there's one refactor outsanding I believe
4672017-01-05T19:16:59  <luke-jr> gmaxwell: 3 PRs left, 9375 and 9441
4682017-01-05T19:17:15  <sipa> 9441? sure?
4692017-01-05T19:17:21  <luke-jr> err
4702017-01-05T19:17:23  <instagibbs_> 8775
4712017-01-05T19:17:26  <luke-jr> 8775 8694*
4722017-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.
4732017-01-05T19:17:37  <gribble> https://github.com/bitcoin/bitcoin/issues/8660 | txoutsbyaddress index (take 2) by djpnewton · Pull Request #8660 · bitcoin/bitcoin · GitHub
4742017-01-05T19:18:01  <wumpus> gmaxwell: yes, that's unfortunate
4752017-01-05T19:18:39  <sipa> i'd like to see #9441 in to get the performance benefit
4762017-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
4772017-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
4782017-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...
4792017-01-05T19:19:02  <BlueMatt> yes, so multiwallet and at least the currently-open net prs are review focus
4802017-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.
4812017-01-05T19:19:19  <morcos> ok well if i had to pick one, i think 9375 makes a huge difference
4822017-01-05T19:19:42  <wumpus> gmaxwell: looks like droark might pick it up
4832017-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.
4842017-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
4852017-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)
4862017-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
4872017-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.
4882017-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
4892017-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
4902017-01-05T19:22:44  <BlueMatt> ?
4912017-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)
4922017-01-05T19:22:59  <sipa> i'll focus on the net locks overhault, named args, early compact block relay
4932017-01-05T19:23:01  <morcos> gmaxwell: so 9441 doesn't count as concurrency changes you are worried about merging now
4942017-01-05T19:23:12  <gmaxwell> wumpus: that was my feeling too but yea.
4952017-01-05T19:23:18  <morcos> +1 sipa's list
4962017-01-05T19:23:27  <gmaxwell> morcos: right, I think it's invasive but it shouldn't be meaningfully creating new concurrency.
4972017-01-05T19:23:41  <wumpus> sgtm
4982017-01-05T19:23:44  <wumpus> #action focus on the net locks overhault, named args, early compact block relay
4992017-01-05T19:23:46  <BlueMatt> sip, ok, named args it is, also multi-wallet?
5002017-01-05T19:24:10  <BlueMatt> a
5012017-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.
5022017-01-05T19:24:11  <BlueMatt> sipa
5032017-01-05T19:24:16  <instagibbs_> luke-jr: might make sense to split out QT stuff for time
5042017-01-05T19:24:29  <luke-jr> instagibbs_: planning to do so, once 8775 is merged
5052017-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
5062017-01-05T19:24:35  <jtimon> which pr is named args?
5072017-01-05T19:24:48  <sipa> jtimon: #8811
5082017-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
5092017-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)
5102017-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
5112017-01-05T19:25:00  <BlueMatt> gmaxwell: so hopefully its easier to be comfortable with it
5122017-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.
5132017-01-05T19:25:08  <luke-jr> instagibbs_: although Qt stuff ties in with RPC stuff for the debug window
5142017-01-05T19:25:11  <wumpus> morcos: if something is ready for merge you should let me know :)
5152017-01-05T19:25:33  <morcos> well at this point, my judgement isn't to be trusted.. :)
5162017-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.
5172017-01-05T19:26:08  <jonasschnelli> Multiwallet: I think need to rebase this one: #8764
5182017-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
5192017-01-05T19:26:13  <BlueMatt> gmaxwell: yes, hence scaling it back...been discussing it a bunch with folks in the past few days
5202017-01-05T19:26:28  <luke-jr> jonasschnelli: that kinda conflicts with the current multiwallet stuff
5212017-01-05T19:26:29  <jonasschnelli> Maybe https://github.com/bitcoin/bitcoin/projects/2 needs update
5222017-01-05T19:27:09  <jtimon> maybe https://github.com/bitcoin/bitcoin/projects/6 needs to be...closed?
5232017-01-05T19:27:32  <luke-jr> might be more efficient to do 8764 after the basic parts are in
5242017-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.
5252017-01-05T19:29:01  <gmaxwell> I don't know why #9312 isn't merged yet.
5262017-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
5272017-01-05T19:29:22  <morcos> #9404 is super easy now, although needs rebase after #9465 is merged
5282017-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
5292017-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
5302017-01-05T19:29:45  <sipa> i read a few things about accidental extreme fee
5312017-01-05T19:30:32  <jtimon> maybe related to estimate fee for the very next block now disabled? (no idea, just thinking out loud)
5322017-01-05T19:30:39  <sipa> is that related to 9138 ?
5332017-01-05T19:30:41  <wumpus> gmaxwell: same holds for you, if something is ready for merging you should let me know
5342017-01-05T19:30:49  <sipa> or 9404?
5352017-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 )
5362017-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
5372017-01-05T19:31:12  <wumpus> 9312 clearly is
5382017-01-05T19:31:21  <morcos> sipa: both, well disabling fee estimates for 1 already went in, not part of 9138
5392017-01-05T19:31:24  <luke-jr> jtimon: https://www.reddit.com/r/Bitcoin/comments/5ltw5n/bitcoin_core_v0131_sends_enormously_high_fee/
5402017-01-05T19:31:35  <luke-jr> perhaps ^ should be our next topic
5412017-01-05T19:31:35  <morcos> but both could cause high fees
5422017-01-05T19:31:37  <wumpus> I think I stopped paying attention there when a certain person started trolling then lost track of it.
5432017-01-05T19:31:39  <sipa> can someone explain what causes this?
5442017-01-05T19:31:46  <sipa> (i don't visit reddit)
5452017-01-05T19:31:49  <morcos> yes
5462017-01-05T19:31:51  *** TomMc has joined #bitcoin-core-dev
5472017-01-05T19:31:55  <BlueMatt> ^ that
5482017-01-05T19:32:00  <kanzure> luke-jr: see 9404, i think
5492017-01-05T19:32:04  <gmaxwell> luke-jr: I believe its fixed by 9404.  Of course, I can't know for sure, not enough info.
5502017-01-05T19:32:39  *** CubicEarth has quit IRC
5512017-01-05T19:32:39  <sipa> oh, is it change unnecessarily converted to fee?
5522017-01-05T19:32:40  <instagibbs_> gmaxwell: so it's wallet-related code, not estimation
5532017-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
5542017-01-05T19:32:46  <luke-jr> gmaxwell: well, OP's post there said he's using estimatefee :/
5552017-01-05T19:32:57  <morcos> gmaxwell: 9404 is already rebased on 9465 as of this morning, so easy peasy to review now
5562017-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.
5572017-01-05T19:33:07  <gmaxwell> morcos: oh missed that, will review.
5582017-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.
5592017-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
5602017-01-05T19:33:41  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/ce43630d1e97...a72f76ca3d5d
5612017-01-05T19:33:41  <bitcoin-git> bitcoin/master 5f0e27f Alex Morcos: Increase mempool expiry time to 2 weeks
5622017-01-05T19:33:42  <bitcoin-git> bitcoin/master a72f76c Wladimir J. van der Laan: Merge #9312: Increase mempool expiry time to 2 weeks...
5632017-01-05T19:33:42  <luke-jr> gmaxwell: he sent you the debug log, did that indicate anything useful?
5642017-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
5652017-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?
5662017-01-05T19:34:20  <gmaxwell> luke-jr: no. unfortunately.
5672017-01-05T19:34:43  <gmaxwell> well it didn't suggest that the known ways that estimatefee could be high weren't being hit.
5682017-01-05T19:34:45  <jonasschnelli> gmaxwell: we don't. But I'm working on it. Got distracted with SPV/BFD and 2016 visualisation.
5692017-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.
5702017-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
5712017-01-05T19:35:22  <sipa> morcos: ok
5722017-01-05T19:35:28  <jonasschnelli> gmaxwell: I'm happy if you do it.
5732017-01-05T19:35:30  <sipa> let's get those fixes in
5742017-01-05T19:36:10  <jonasschnelli> gmaxwell: maybe use some prework form https://github.com/bitcoin/bitcoin/pull/9370
5752017-01-05T19:36:14  <gmaxwell> TBH I knew about the issue fied by 9404 long ago, but I thought it had since been fixed... :(
5762017-01-05T19:37:14  <gmaxwell> jonasschnelli: oh I thought I'd acked the fundraw reuse fix.. will review.
5772017-01-05T19:37:36  <jonasschnelli> The correct one is: https://github.com/bitcoin/bitcoin/pull/9377
5782017-01-05T19:38:06  <jonasschnelli> The one above is an older try that could be useful for hd restore.
5792017-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.
5802017-01-05T19:38:47  <jonasschnelli> https://vimeo.com/198242328
5812017-01-05T19:38:51  <jonasschnelli> Password coredev
5822017-01-05T19:38:57  <jonasschnelli> (will be there for a couple of mins)
5832017-01-05T19:39:14  <jonasschnelli> (sorry to spam the meeting)
5842017-01-05T19:39:27  <gmaxwell> okay I concept acked, well I'll complete the review.
5852017-01-05T19:40:04  <luke-jr> jonasschnelli: why password protect it and post the password in public? :P
5862017-01-05T19:40:16  <jonasschnelli> Security by obscurity.
5872017-01-05T19:40:18  <petertodd> luke-jr: MILITARY LEVEL BLOCKCHAIN SECURITY
5882017-01-05T19:40:24  <jonasschnelli> heh
5892017-01-05T19:40:41  <wumpus> hehe
5902017-01-05T19:41:06  <petertodd> anyway, I think that constitutes an "effective access control" under the DMCA...
5912017-01-05T19:41:22  <gmaxwell> Who called this meeting?
5922017-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)
5932017-01-05T19:41:47  <jonasschnelli> sipa: Thanks, will adapt
5942017-01-05T19:41:58  <instagibbs_> any other topics?
5952017-01-05T19:42:50  <wumpus> apparently not!
5962017-01-05T19:42:58  <instagibbs_> everyone's watching the video
5972017-01-05T19:43:08  <kanzure> chainparams?
5982017-01-05T19:43:20  <wumpus> looks like we'll close the first meeting of 2017 early
5992017-01-05T19:43:29  <kanzure> 8994
6002017-01-05T19:43:30  <wumpus> what is there to discuss about chainparams?
6012017-01-05T19:43:46  <kanzure> for 0.14, i think.
6022017-01-05T19:43:53  <BlueMatt> final list of things to focus for review? multi-wallet, currently-open net prs, fee ones, what else?
6032017-01-05T19:44:07  <BlueMatt> oh, and multiargs
6042017-01-05T19:44:14  <BlueMatt> rpcarg thing
6052017-01-05T19:44:17  <jonasschnelli> and hd chain-split/rstore
6062017-01-05T19:44:23  <jtimon> wumpus, on my part #8994
6072017-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
6082017-01-05T19:44:39  <gmaxwell> I think that is really a lot less important than everything else listed.
6092017-01-05T19:44:58  <gmaxwell> (as people using that are also probably using git master)
6102017-01-05T19:44:58  <morcos> are we really trying to get all these wallet changes in?
6112017-01-05T19:45:03  <wumpus> yes it doesn't seem to make a lot of sense to focus last-minute review attention on that
6122017-01-05T19:45:04  <jtimon> sure, feedback is still welcomed though
6132017-01-05T19:45:08  <morcos> should we focus on some over others?
6142017-01-05T19:45:11  <BlueMatt> morcos: yea, I think thats more than will make it, but that was the list
6152017-01-05T19:45:11  <gmaxwell> (so merging it after 14 means just weeks of delay for someone who wants to use it)
6162017-01-05T19:45:20  <gmaxwell> jtimon: fair enough.
6172017-01-05T19:45:24  <wumpus> morcos: the fee fixes obviously have priority
6182017-01-05T19:45:44  <jtimon> I doubt it will get to 0.14 that's why I asked "how realistic..."
6192017-01-05T19:45:45  <wumpus> anything that can cause users to spend unnecessary coins should be first priority
6202017-01-05T19:45:52  <morcos> well i guess i meant between hd-chain/split and multiwallet
6212017-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
6222017-01-05T19:46:07  <instagibbs_> I think multiwallet would be great... lots of demand for something like that
6232017-01-05T19:46:14  <gmaxwell> I would prioritize fee fixes, net/relay things, hd/rescan improvements, multiwallet, the thousand other open PRs.
6242017-01-05T19:46:17  <instagibbs_> but yes bigger changes
6252017-01-05T19:46:26  <morcos> gmaxwell: in order?
6262017-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.
6272017-01-05T19:46:35  <morcos> don't forget named args?
6282017-01-05T19:46:38  <gmaxwell> morcos: yes that was an order.
6292017-01-05T19:46:39  <instagibbs_> >thousand other open PRs
6302017-01-05T19:46:50  <jonasschnelli> gmaxwell: Would multiwallet in 0.14 include the GUI?
6312017-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
6322017-01-05T19:47:08  <jonasschnelli> Have we already discussed how to select the wallet over RPC?
6332017-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
6342017-01-05T19:47:13  <wumpus> it will need a lot of last-minute fixes Im sure
6352017-01-05T19:47:26  <luke-jr> jonasschnelli: a number of times :p
6362017-01-05T19:47:30  <wumpus> a big feature like that is not done once it's merged
6372017-01-05T19:47:53  <luke-jr> wumpus: it's not actually that big at this point
6382017-01-05T19:48:14  <gmaxwell> At least on my earlier review it seemed like most of it was the refactors.
6392017-01-05T19:48:17  <gmaxwell> Which helps.
6402017-01-05T19:48:20  <luke-jr> 99% of it is renaming pwalletMain to pwallet in rpc files
6412017-01-05T19:48:36  <jonasschnelli> But we need to be careful. Running with many wallets needs some testing.
6422017-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
6432017-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
6442017-01-05T19:48:45  <jonasschnelli> Even if it's code-wise trivial
6452017-01-05T19:49:16  <luke-jr> overall, I think multiwallet can be delayed in Core if other things need time
6462017-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
6472017-01-05T19:49:31  <wumpus> agree with morcos
6482017-01-05T19:49:39  <sipa> 0.13 slipping now would indeed be terrible!
6492017-01-05T19:49:44  <luke-jr> heh
6502017-01-05T19:49:48  <sipa> ;)
6512017-01-05T19:49:49  <gmaxwell> hah
6522017-01-05T19:50:22  <wumpus> lol
6532017-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.
6542017-01-05T19:51:07  <gmaxwell> I do believe the release will be delayed from fixes for just the things we already have in now.
6552017-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?
6562017-01-05T19:51:21  <wumpus> gmaxwell: I don't want to let it slip on features in any case, on bugfixes is more acceptable
6572017-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
6582017-01-05T19:51:30  <wumpus> so it's clear what to focus on then
6592017-01-05T19:51:30  <BlueMatt> so....thats a thing
6602017-01-05T19:51:43  <gmaxwell> wumpus: right, well ... you could just merge everything outstanding and then all slips are bugfix related! :P
6612017-01-05T19:51:46  <instagibbs_> BlueMatt: there a list?
6622017-01-05T19:51:47  <BlueMatt> oh, sorry, 1 has an open pr
6632017-01-05T19:52:02  <wumpus> BlueMatt: are the issues tagged appropriately?
6642017-01-05T19:52:09  <BlueMatt> yes, tagged 0.14, i believe
6652017-01-05T19:52:13  <wumpus> ok
6662017-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.
6672017-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
6682017-01-05T19:52:46  <BlueMatt> at least #9479, #9027, #9148 and #9212
6692017-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.
6702017-01-05T19:52:48  <BlueMatt> maybe others
6712017-01-05T19:52:48  <gribble> https://github.com/bitcoin/bitcoin/issues/9027 | Unbounded reorg memory usage · Issue #9027 · bitcoin/bitcoin · GitHub
6722017-01-05T19:52:49  <sipa> confirming what cfields said
6732017-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
6742017-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
6752017-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
6762017-01-05T19:52:52  <gmaxwell> completion*
6772017-01-05T19:52:53  <gribble> https://github.com/bitcoin/bitcoin/issues/9240 | Remove txConflicted by morcos · Pull Request #9240 · bitcoin/bitcoin · GitHub
6782017-01-05T19:52:54  <gribble> https://github.com/bitcoin/bitcoin/issues/9371 | Notify on removal by morcos · Pull Request #9371 · bitcoin/bitcoin · GitHub
6792017-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?
6802017-01-05T19:53:32  <sipa> a revert can be do at the last minute
6812017-01-05T19:53:39  <sipa> *done
6822017-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
6832017-01-05T19:53:43  <BlueMatt> yea, we can revert on the 0.14 branch at that point?
6842017-01-05T19:53:44  <gribble> https://github.com/bitcoin/bitcoin/issues/9240 | Remove txConflicted by morcos · Pull Request #9240 · bitcoin/bitcoin · GitHub
6852017-01-05T19:53:51  * jtimon reiterates his dissapointment on not having removed checkpoints for everything except progress estimation, that doesn't have a PR...
6862017-01-05T19:54:35  <sipa> jtimon: 9472 removes checkpoints for the purpose of progress estimation
6872017-01-05T19:54:39  <morcos> sipa: well i like 9371, but it overlaps a lot with #8549 and we haven't resolved direction
6882017-01-05T19:54:40  <sipa> :)
6892017-01-05T19:54:40  <jtimon> I mean gmaxwell you had that practically done already
6902017-01-05T19:54:41  <gribble> https://github.com/bitcoin/bitcoin/issues/8549 | zmq: mempool notifications by jmcorgan · Pull Request #8549 · bitcoin/bitcoin · GitHub
6912017-01-05T19:54:52  <jtimon> sipa: oh, nice, will have a look
6922017-01-05T19:54:59  *** brg444 has quit IRC
6932017-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.
6942017-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
6952017-01-05T19:55:44  <wumpus> sorry s/Madars/Morcos
6962017-01-05T19:56:02  <wumpus> morcos: this means it can only support one client listening for removals at most
6972017-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)
6982017-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
6992017-01-05T19:56:39  <wumpus> morcos: for the rest I'm ok with it, and it doesn't conflict with 8549 too much
7002017-01-05T19:56:58  <sipa> gmaxwell: what about the idea of once crossing a certain amount of work, requiring a higher minimum difficulty?
7012017-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.
7022017-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
7032017-01-05T19:57:22  <sipa> ah, right, consensus change
7042017-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.
7052017-01-05T19:57:52  <wumpus> morcos: I just don't like making a notification mechanism stateful, but that may be a personal thing
7062017-01-05T19:58:15  <jtimon> thanks for the info, wasn't up to date on the subject
7072017-01-05T19:58:16  <wumpus> morcos: but ok maybe this is the only way to handle reorgs sanely
7082017-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.
7092017-01-05T19:58:20  <morcos> but isn't that what we've just done on purpose with ConnectTrace?
7102017-01-05T19:58:38  <morcos> i guess not quite the same thing... but accomplishes same goal
7112017-01-05T19:58:45  <jtimon> maybe in this 2 minutes...should I rebase the super-trivial #9279 ?
7122017-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
7132017-01-05T19:59:04  * luke-jr ponders if it would make sense to increase min difficulty to 50% of current difficulty.
7142017-01-05T19:59:09  <wumpus> morcos: well at least that's an external object passed in
7152017-01-05T19:59:23  *** BlueMatt has left #bitcoin-core-dev
7162017-01-05T19:59:27  *** BlueMatt has joined #bitcoin-core-dev
7172017-01-05T19:59:28  *** CubicEarth has joined #bitcoin-core-dev
7182017-01-05T19:59:28  *** brg444 has joined #bitcoin-core-dev
7192017-01-05T19:59:32  <sipa> gmaxwell: maybe you should explain your idea to luke-jr
7202017-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
7212017-01-05T20:00:04  <gmaxwell> sipa: https://github.com/gmaxwell/bitcoin/commit/2db190b183c5204da23191ca642c7f6cad412ae3
7222017-01-05T20:00:06  <instagibbs_> time of meeting has ended
7232017-01-05T20:00:11  <wumpus> #endmeeting
7242017-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)
7252017-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
7262017-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
7272017-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
7282017-01-05T20:00:32  <bitcoin-git> [bitcoin] jonasschnelli pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/a72f76ca3d5d...fd7d8c7b35ae
7292017-01-05T20:00:32  <bitcoin-git> bitcoin/master 54f8026 Jonas Schnelli: [CoinControl] Allow non-wallet owned change addresses
7302017-01-05T20:00:33  <bitcoin-git> bitcoin/master fd7d8c7 Jonas Schnelli: Merge #9413: [CoinControl] Allow non-wallet owned change addresses...
7312017-01-05T20:00:35  <jtimon> #9279 would make libconsensus lighter :p
7322017-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
7332017-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
7342017-01-05T20:01:12  <gmaxwell> sipa: presumably that explains the idea precisely enough. :)
7352017-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
7362017-01-05T20:01:26  <wumpus> morcos: then the whole list of removed transactions could be passed to all listeners
7372017-01-05T20:01:44  <morcos> yes i think thats what i meant
7382017-01-05T20:01:47  <wumpus> morcos: and it's listener-agnostic without calling a signal for every transaction
7392017-01-05T20:02:06  <jtimon> what about fetching the minimum difficulty from the 6 biggest mining pools?
7402017-01-05T20:02:12  * jtimon hides
7412017-01-05T20:02:29  <gmaxwell> /kb jtimon
7422017-01-05T20:02:32  <wumpus> morcos: not sure what the batching granularity should be in that case though
7432017-01-05T20:02:41  <petertodd> jtimon: so long as we have a service that defines which those 6 pools are
7442017-01-05T20:02:42  <wumpus> morcos: per block, per reorg?
7452017-01-05T20:02:56  <jtimon> kb ?
7462017-01-05T20:03:00  <kanzure> kickban
7472017-01-05T20:03:00  <BlueMatt> jtimon: lol
7482017-01-05T20:03:01  <jonasschnelli> jtimon: heh. Read this: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-January/013432.html
7492017-01-05T20:03:11  <luke-jr> gmaxwell: sounds reasonable
7502017-01-05T20:03:13  <morcos> wumpus: well i batched it per lock of cs_main i think
7512017-01-05T20:03:26  <BlueMatt> jonasschnelli: lol, I hope that was a joke too
7522017-01-05T20:03:45  <morcos> which basically is ActivateBestChain(or Step can't remember) and per AcceptToMemoryPool
7532017-01-05T20:04:01  <jtimon> jonasschnelli: right, sorry, should have said 5, didn't remember correctly :p
7542017-01-05T20:04:07  <jonasschnelli> haha
7552017-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.
7562017-01-05T20:04:45  <gmaxwell> luke-jr: which I've not bothered thinking through.
7572017-01-05T20:04:53  *** jannes has quit IRC
7582017-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?
7592017-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)
7602017-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).
7612017-01-05T20:06:09  <luke-jr> jtimon: not just spaniards!
7622017-01-05T20:06:28  <jtimon> who else?
7632017-01-05T20:06:29  <luke-jr> gmaxwell: throw a JSON exception? ☺
7642017-01-05T20:06:37  <luke-jr> jtimon: we also do gifts on the Epiphany here
7652017-01-05T20:07:06  <jtimon> interesting, will ask more next time we meet, sorry everyone else for the offtopic
7662017-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).
7672017-01-05T20:07:57  <luke-jr> gmaxwell: yes, if it makes sense to continue that chain
7682017-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.
7692017-01-05T20:08:57  * luke-jr shrugs
7702017-01-05T20:08:58  <adiabat> luke-jr: but what about if the hashrate is actually down 5X "naturally"; e.g. global thermonuclear war? :)
7712017-01-05T20:09:21  <gmaxwell> adiabat: we're not talking about 5x. We're talking about 1/20000th.
7722017-01-05T20:09:26  <luke-jr> ^
7732017-01-05T20:09:49  <adiabat> luke-jr: ahh, you mean 4X on min-difficulty
7742017-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.
7752017-01-05T20:10:06  <adiabat> luke-jr: yeah not even thermonuclear war acheives that.
7762017-01-05T20:10:39  <gmaxwell> maybe it does, but then who cares? y'all be dead in those cases.
7772017-01-05T20:11:40  <luke-jr> XD
7782017-01-05T20:12:07  <kanzure> death is merely a temporary inconvenience for thermonuclear scaling
7792017-01-05T20:12:19  <gmaxwell> in any case, raising the minimum difficulty was one of the two remaining issues for checkpoint removal.
7802017-01-05T20:12:27  <gmaxwell> The other is the signature checking bypass.
7812017-01-05T20:12:36  <luke-jr> kanzure: I'm not sure it's scaling to decrease demand.
7822017-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)
7832017-01-05T20:14:04  <gmaxwell> https://github.com/bitcoin/bitcoin/pull/9180
7842017-01-05T20:15:22  *** instagibbs has joined #bitcoin-core-dev
7852017-01-05T20:16:00  <luke-jr> would it be so terrible to keep a single "checkpoint" just for sigcheck bypass?
7862017-01-05T20:16:13  *** instagibbs_ has quit IRC
7872017-01-05T20:17:25  *** jtimon has quit IRC
7882017-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.
7892017-01-05T20:17:58  <luke-jr> what if it's a param the user can specify?
7902017-01-05T20:18:07  <luke-jr> (with a sane default)
7912017-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.
7922017-01-05T20:19:01  <luke-jr> :<
7932017-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.
7942017-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.
7952017-01-05T20:20:30  <luke-jr> what if we have multiple such values, all but one of which are bogus valid chains? ☺
7962017-01-05T20:20:45  *** CubicEarth has quit IRC
7972017-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.
7982017-01-05T20:24:13  *** CubicEarth has joined #bitcoin-core-dev
7992017-01-05T20:26:54  <gmaxwell> luke-jr:  in any case we are in an optimally bad situation now.
8002017-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.
8012017-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.
8022017-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)
8032017-01-05T20:30:31  <gmaxwell> (but I don't think the position is an absurd one)
8042017-01-05T20:32:07  *** CubicEarth has quit IRC
8052017-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
8062017-01-05T20:33:03  <gmaxwell> m alone for now.
8072017-01-05T20:33:23  <sdaftuar> gmaxwell: +1, seems reasonable to me.
8082017-01-05T20:34:30  <luke-jr> Ancestors of that block get scriptchecked..?
8092017-01-05T20:34:42  <gmaxwell> er don't get scriptchecked. :)
8102017-01-05T20:35:48  <luke-jr> ok, that sounds pretty much like what I thought the near-term goal already was ☺
8112017-01-05T20:37:57  <gmaxwell> okay, well I'll go PR the scriptcheck skipping change I guess.
8122017-01-05T20:40:23  *** wvr has joined #bitcoin-core-dev
8132017-01-05T20:47:15  *** Chris_Stewart_5 has quit IRC
8142017-01-05T20:49:00  <gmaxwell> I guess I'll open this question up to more than sipa:
8152017-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?
8162017-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.)
8172017-01-05T20:50:59  <BlueMatt> are we staunchly against having a "class CWallet" in !define WALLET?
8182017-01-05T20:51:11  <BlueMatt> forward declaration, that is
8192017-01-05T20:59:24  <luke-jr> that would make things so much simpler XD
8202017-01-05T21:03:04  *** Chris_Stewart_5 has joined #bitcoin-core-dev
8212017-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.
8222017-01-05T21:07:12  *** Sosumi has quit IRC
8232017-01-05T21:07:20  *** Lauda has quit IRC
8242017-01-05T21:07:31  *** Lauda has joined #bitcoin-core-dev
8252017-01-05T21:07:46  <gmaxwell> I suppose it could be a dummy class CWallet that exists in that case though.
8262017-01-05T21:08:02  <gmaxwell> e.g. has no methods or fields.
8272017-01-05T21:08:57  <BlueMatt> gmaxwell: not dummy, forward declartion
8282017-01-05T21:09:03  <BlueMatt> gmaxwell: i think in this case it will still compile
8292017-01-05T21:09:14  <BlueMatt> since there are no actual uses of it, just a pointer to it
8302017-01-05T21:09:23  <BlueMatt> which the compiler knows how to do, even without knowing shit about the class
8312017-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.
8322017-01-05T21:12:01  <gmaxwell> but I'm not the person likely to have useful opinions on that.
8332017-01-05T21:12:26  <BlueMatt> I kinda agree, i /think/ forward decl will work, easy to test at least
8342017-01-05T21:12:51  *** laurentmt has quit IRC
8352017-01-05T21:13:07  <sipa> if it compiles with just a forward declaration, it should be fine
8362017-01-05T21:13:18  <sipa> and i guess it should
8372017-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
8382017-01-05T21:14:05  <luke-jr> so I can use a fwd decl?
8392017-01-05T21:14:42  <BlueMatt> luke-jr: try it, if it compiles, yes :)
8402017-01-05T21:14:56  <luke-jr> pretty sure it will
8412017-01-05T21:14:57  * sipa is strongly against code that does not compile
8422017-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
8432017-01-05T21:15:45  <luke-jr> sipa: but..!
8442017-01-05T21:16:03  <sipa> luke-jr: i know, i know. bitcoin would be much more secure if it didn't compile
8452017-01-05T21:16:05  <gmaxwell> sipa: code that does not compile never crashes.
8462017-01-05T21:16:08  <luke-jr> lol
8472017-01-05T21:17:06  <BlueMatt> it also doesn't have bugs
8482017-01-05T21:17:10  <BlueMatt> (for some definition of bugs)
8492017-01-05T21:17:21  <BlueMatt> then again nothing has bugs for some definition of bugs
8502017-01-05T21:18:55  <luke-jr> but also everything has bugs for some definition of bugs <.<
8512017-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
8522017-01-05T21:19:46  <luke-jr> and may have to still use the ugly cast in Qt code to pass through signals/slots, dunno
8532017-01-05T21:20:45  *** Guyver2 has quit IRC
8542017-01-05T21:32:33  *** CubicEarth has joined #bitcoin-core-dev
8552017-01-05T21:37:27  <bitcoin-git> [bitcoin] sipa pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/fd7d8c7b35ae...a7d55c933853
8562017-01-05T21:37:27  <bitcoin-git> bitcoin/master b3d7b1c Gregory Maxwell: Wallet: Do not perform ECDSA in the fee calculation inner loop....
8572017-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....
8582017-01-05T21:37:41  *** CubicEarth has quit IRC
8592017-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
8602017-01-05T21:52:45  <bitcoin-git> [bitcoin] sipa pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/a7d55c933853...c252685aa586
8612017-01-05T21:52:46  <bitcoin-git> bitcoin/master ba3cecf Pieter Wuille: Share unused mempool memory with coincache...
8622017-01-05T21:52:46  <bitcoin-git> bitcoin/master c252685 Pieter Wuille: Merge #8610: Share unused mempool memory with coincache...
8632017-01-05T22:22:41  <bitcoin-git> [bitcoin] sipa pushed 11 new commits to master: https://github.com/bitcoin/bitcoin/compare/c252685aa586...f646275b90b1
8642017-01-05T22:22:42  <bitcoin-git> bitcoin/master 4df4479 Alex Morcos: Remove extraneous LogPrint from fee estimation...
8652017-01-05T22:22:42  <bitcoin-git> bitcoin/master 60ac00d Alex Morcos: Don't track transactions at all during IBD....
8662017-01-05T22:22:43  <bitcoin-git> bitcoin/master 84f7ab0 Alex Morcos: Remove member variable hadNoDependencies from CTxMemPoolEntry...
8672017-01-05T22:22:52  <bitcoin-git> [bitcoin] sipa closed pull request #9138: Improve fee estimation (master...refactorFeeEstimation) https://github.com/bitcoin/bitcoin/pull/9138
8682017-01-05T22:33:24  <instagibbs> BlueMatt, if it doesn't compile there is no unexpected behavior :)
8692017-01-05T22:36:52  <gmaxwell> luke-jr: fking signals/slots.
8702017-01-05T22:49:25  *** CubicEarth has joined #bitcoin-core-dev
8712017-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?
8722017-01-05T23:00:22  *** CubicEarth has quit IRC
8732017-01-05T23:34:05  *** CubicEarth has joined #bitcoin-core-dev
8742017-01-05T23:37:12  <luke-jr> a bigger concern I think is that logging is not enabled until it's too late
8752017-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
8762017-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?
8772017-01-05T23:58:18  *** brg444 has quit IRC
8782017-01-05T23:59:30  *** brg444 has joined #bitcoin-core-dev