12017-01-11T00:11:32  *** CodeShark has quit IRC
  22017-01-11T00:11:32  *** aspect_ has quit IRC
  32017-01-11T00:12:51  *** norotartagen has quit IRC
  42017-01-11T00:13:48  *** norotartagen has joined #bitcoin-core-dev
  52017-01-11T00:14:46  *** CodeShark has joined #bitcoin-core-dev
  62017-01-11T00:21:39  *** aspect_ has joined #bitcoin-core-dev
  72017-01-11T00:28:55  *** fanquake has joined #bitcoin-core-dev
  82017-01-11T00:33:18  *** xinxi has joined #bitcoin-core-dev
  92017-01-11T00:35:40  <bitcoin-git> [bitcoin] theuni closed pull request #9509: build: fix qt distdir builds (master...out-of-tree-build) https://github.com/bitcoin/bitcoin/pull/9509
 102017-01-11T00:39:01  *** jannes has quit IRC
 112017-01-11T00:47:35  *** jtimon has quit IRC
 122017-01-11T00:58:46  *** abpa has quit IRC
 132017-01-11T01:08:33  *** xinxi has quit IRC
 142017-01-11T01:10:34  *** Cheeseo has joined #bitcoin-core-dev
 152017-01-11T01:10:46  *** Cheeseo has joined #bitcoin-core-dev
 162017-01-11T01:11:02  <bitcoin-git> [bitcoin] theuni opened pull request #9513: build: fix qt distdir builds (retry) (master...out-of-tree-build) https://github.com/bitcoin/bitcoin/pull/9513
 172017-01-11T01:21:48  *** MarcoFalke has quit IRC
 182017-01-11T01:24:12  *** moli has joined #bitcoin-core-dev
 192017-01-11T01:38:13  *** abpa has joined #bitcoin-core-dev
 202017-01-11T01:40:04  <bitcoin-git> [bitcoin] theuni opened pull request #9514: release: Windows signing script (master...win-signing-script) https://github.com/bitcoin/bitcoin/pull/9514
 212017-01-11T01:41:35  *** xinxi has joined #bitcoin-core-dev
 222017-01-11T01:43:29  *** fanquake has quit IRC
 232017-01-11T01:47:28  *** Ylbam has quit IRC
 242017-01-11T02:17:07  *** xinxi has quit IRC
 252017-01-11T02:33:53  *** xinxi has joined #bitcoin-core-dev
 262017-01-11T02:38:09  *** xinxi has quit IRC
 272017-01-11T02:39:15  *** abpa has quit IRC
 282017-01-11T02:47:58  *** xinxi has joined #bitcoin-core-dev
 292017-01-11T02:48:35  *** Chris_Stewart_5 has quit IRC
 302017-01-11T03:04:41  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 312017-01-11T03:21:17  *** Victorsueca has joined #bitcoin-core-dev
 322017-01-11T03:24:01  *** Victor_sueca has quit IRC
 332017-01-11T03:28:12  *** Chris_Stewart_5 has quit IRC
 342017-01-11T03:28:17  *** justanotheruser has joined #bitcoin-core-dev
 352017-01-11T03:49:01  *** xinxi has quit IRC
 362017-01-11T03:51:32  *** windsok has quit IRC
 372017-01-11T03:56:02  *** xinxi has joined #bitcoin-core-dev
 382017-01-11T04:19:38  *** chris200_ has joined #bitcoin-core-dev
 392017-01-11T04:22:11  *** Alopex has quit IRC
 402017-01-11T04:22:32  *** chris2000 has quit IRC
 412017-01-11T04:23:16  *** Alopex has joined #bitcoin-core-dev
 422017-01-11T04:24:47  *** dcousens has quit IRC
 432017-01-11T04:34:56  *** windsok has joined #bitcoin-core-dev
 442017-01-11T04:57:10  *** chjj has quit IRC
 452017-01-11T04:57:12  *** xinxi has quit IRC
 462017-01-11T04:59:40  *** xinxi has joined #bitcoin-core-dev
 472017-01-11T05:00:11  *** Alopex has quit IRC
 482017-01-11T05:01:17  *** Alopex has joined #bitcoin-core-dev
 492017-01-11T05:04:11  *** Lauda has quit IRC
 502017-01-11T05:30:35  *** adiabat has quit IRC
 512017-01-11T05:39:06  *** Lauda has joined #bitcoin-core-dev
 522017-01-11T05:57:34  *** chjj has joined #bitcoin-core-dev
 532017-01-11T06:04:54  *** justanotheruser is now known as OfficialLeibniz
 542017-01-11T06:49:04  *** tunafizz has quit IRC
 552017-01-11T06:49:20  *** dcousens has joined #bitcoin-core-dev
 562017-01-11T06:54:02  *** tunafizz has joined #bitcoin-core-dev
 572017-01-11T07:17:09  <jonasschnelli> cfields: is this meant to be public: https://github.com/bitcoin/bitcoin/pull/9514/files#diff-6373b8b56e3d0425bbd3b0bb32c48162?
 582017-01-11T07:21:36  *** xinxi has quit IRC
 592017-01-11T07:24:40  <paveljanik> jonasschnelli, it is a certificate only
 602017-01-11T07:24:44  <paveljanik> no privkey
 612017-01-11T07:25:18  <jonasschnelli> paveljanik: okay. Not familiar with windows code signing...
 622017-01-11T07:25:39  <paveljanik> -me is not familiar with Windows at all ů=0
 632017-01-11T07:25:41  <paveljanik> ;-)
 642017-01-11T07:37:02  *** BitBully has joined #bitcoin-core-dev
 652017-01-11T08:11:07  *** BashCo has quit IRC
 662017-01-11T08:11:45  *** BashCo has joined #bitcoin-core-dev
 672017-01-11T08:16:05  *** BashCo has quit IRC
 682017-01-11T08:16:05  *** davec has quit IRC
 692017-01-11T08:16:24  *** davec has joined #bitcoin-core-dev
 702017-01-11T08:17:26  *** BitBully has quit IRC
 712017-01-11T08:18:59  *** BitBully has joined #bitcoin-core-dev
 722017-01-11T08:36:40  *** BashCo has joined #bitcoin-core-dev
 732017-01-11T08:40:55  *** BitBully has quit IRC
 742017-01-11T08:47:25  *** Guyver2 has joined #bitcoin-core-dev
 752017-01-11T09:06:50  <bitcoin-git> [bitcoin] kallewoof opened pull request #9516: Bug-fix: listsinceblock: use max depth value for blocks in reorg'd chains (master...listsinceblock-reorg-fix) https://github.com/bitcoin/bitcoin/pull/9516
 762017-01-11T09:41:25  *** waxwing has quit IRC
 772017-01-11T09:41:33  *** MarcoFalke has joined #bitcoin-core-dev
 782017-01-11T10:23:38  *** Ylbam has joined #bitcoin-core-dev
 792017-01-11T11:08:42  *** AaronvanW has joined #bitcoin-core-dev
 802017-01-11T11:08:43  *** AaronvanW has quit IRC
 812017-01-11T11:08:43  *** AaronvanW has joined #bitcoin-core-dev
 822017-01-11T11:09:37  *** jannes has joined #bitcoin-core-dev
 832017-01-11T11:10:51  *** dcousens has quit IRC
 842017-01-11T11:15:02  *** pavel_ has joined #bitcoin-core-dev
 852017-01-11T11:18:08  *** paveljanik has quit IRC
 862017-01-11T11:24:34  *** cjamthagen has quit IRC
 872017-01-11T11:26:42  *** BitBully has joined #bitcoin-core-dev
 882017-01-11T11:32:00  *** BitBully has quit IRC
 892017-01-11T11:38:02  *** cjamthagen has joined #bitcoin-core-dev
 902017-01-11T11:40:46  *** BashCo has quit IRC
 912017-01-11T11:40:52  *** BashCo_ has joined #bitcoin-core-dev
 922017-01-11T11:54:53  *** jtimon has joined #bitcoin-core-dev
 932017-01-11T11:56:20  <jtimon> rewarding 8994 (custom chainparams), how important it is that it loads the chainparams from a different conf file instead of regular args and the existing config file? the arguments will be ignored for main, testnet and regtest anyway
 942017-01-11T11:57:04  <jtimon> NicolasDorier: regarding your vision for libconsensus, do you mind if I make some more questions here?
 952017-01-11T11:57:18  <NicolasDorier> sure
 962017-01-11T11:57:29  <NicolasDorier> I think trying the following
 972017-01-11T11:57:34  <NicolasDorier> brand new project
 982017-01-11T11:57:40  <NicolasDorier> copy/pasta of bitcoin core
 992017-01-11T11:57:52  <NicolasDorier> then stripping everything not related to consensus
1002017-01-11T11:58:04  <NicolasDorier> removing all dependencies to third party libs
1012017-01-11T11:58:27  <jtimon> well, copy paste from core or doing it in core ignoring the rest is not that different is it?
1022017-01-11T11:59:16  <NicolasDorier> I think it is harder
1032017-01-11T11:59:35  <NicolasDorier> like there is so much reference to the utxo storage in the consensus code.
1042017-01-11T12:00:04  <NicolasDorier> I would prefer being able to strip that
1052017-01-11T12:00:21  <NicolasDorier> rather than trying to make interfaces
1062017-01-11T12:00:24  <jtimon> anyway, one frequent discussion is abstract storage yes no, you told me you say yes (like BlueMatt and me), but it seems your way of doing it it's a bit different. ie instead of function pointers, your API assumes that all the needed data will be provided directly in the parameters
1072017-01-11T12:01:03  *** MarcoFalke has left #bitcoin-core-dev
1082017-01-11T12:01:03  <NicolasDorier> I changed my mind. I think the consensus lib does not have to know anything about storage, I think we can ask the client to pass the UTXO necessary for validating the block
1092017-01-11T12:01:15  *** MarcoFalke has joined #bitcoin-core-dev
1102017-01-11T12:01:30  <jtimon> but then the client needs to know which ones will be relevant before calling
1112017-01-11T12:01:54  <NicolasDorier> yes, and but the client know that
1122017-01-11T12:01:57  <jtimon> and will need to fetch them even if the tx/block was already invalid because of something trivial
1132017-01-11T12:01:57  <NicolasDorier> since he has the block
1142017-01-11T12:02:22  <NicolasDorier> correct. But the client can verify PoW before fetching
1152017-01-11T12:02:28  <jtimon> sure, just comparing with the function pointer version of it, in both cases it will need to have the data
1162017-01-11T12:02:57  <jtimon> another discussion was how the client gets that data
1172017-01-11T12:03:11  <NicolasDorier> this would be the client's business
1182017-01-11T12:03:17  <NicolasDorier> this is simple enough stuff to do
1192017-01-11T12:03:35  <NicolasDorier> iffunction pointer
1202017-01-11T12:03:56  <NicolasDorier> it is complicated to use, and
1212017-01-11T12:04:16  <jtimon> matt advocated for, using a function pointer like interface, he would expose something like processBlock rather than only verifyBlock, that way if the block is valid it will also call the necessary function pointer api for the abstracted storage to store the new block, update the utxo, etc
1222017-01-11T12:04:20  <NicolasDorier> if the implementation cross boundary between languages, there is huge perf hit
1232017-01-11T12:05:02  <NicolasDorier> I don't think this is the right approach. I think it is just easier to ask the client to fetch everything preventively
1242017-01-11T12:05:29  <jtimon> right, that's the advantage of your approach, less performance hit by avoiding the function pointers (although more in some cases by prefetching everything)
1252017-01-11T12:05:47  <jtimon> right, just comparing the different approaches
1262017-01-11T12:06:08  <NicolasDorier> this also make it harder for us to break users of consensus
1272017-01-11T12:06:25  <NicolasDorier> because we would make no assumption on how they deal with their storage
1282017-01-11T12:06:55  <jtimon> in my model, there was no processBlock, just verifyBlock that tells you whether a block is valid or not and nothing else: the caller needs to update the storage and manage reorg and the like on his own
1292017-01-11T12:07:40  <NicolasDorier> one method is not enough, you need also to verify PoW for example. The client wants to verify PoW before pulling out the UTXOs from storage
1302017-01-11T12:07:47  <jtimon> right, that's an advantage for both the abstracted storage API or the abstracted storage by prefetching
1312017-01-11T12:08:39  <jtimon> the people that don't like to abstract the storage (at least greg and pieter), are happy with libconsensus depending on levelDB
1322017-01-11T12:09:07  <NicolasDorier> I don't think libconsensus should have any dependencies
1332017-01-11T12:09:21  <NicolasDorier> it should be plain dumb lib like libsecpk)#*R#)*$
1342017-01-11T12:09:31  <jtimon> so you would expose a function to verify pow before fetching the data? why just pow? there's many things that can be validated without storage
1352017-01-11T12:09:44  <NicolasDorier> yes other things as well
1362017-01-11T12:09:56  <NicolasDorier> like CheckContextual *
1372017-01-11T12:10:02  <jtimon> well, I think at the very least it should have libsecp256k1 as a dependency, but I agree it shouldn
1382017-01-11T12:10:06  <NicolasDorier> yes
1392017-01-11T12:10:10  <jtimon> 't depend on levelDB
1402017-01-11T12:10:35  <jtimon> just pointing out that other people disagree
1412017-01-11T12:11:07  <NicolasDorier> yes
1422017-01-11T12:11:15  <jtimon> so maybe you would expose checkblock and verifyBlock separately
1432017-01-11T12:11:38  <NicolasDorier> but what I plan to do is making it the way I see, using it with my C# full node, and if people are happy with it proposing to Core
1442017-01-11T12:11:39  <jtimon> makes sense, I thought about it
1452017-01-11T12:12:22  <jtimon> do you plan to expose lower level functions like say verifyHeader or verifyTx ?
1462017-01-11T12:13:11  <NicolasDorier> mh depends if my full node need it. VerifyHeader yes, VerifyTx might be good for mempool, but the problem is that it should not check policy rules
1472017-01-11T12:13:15  <NicolasDorier> it would
1482017-01-11T12:13:16  <jtimon> yeah, I think I will finish my vision on top of 0.14 and then see what happens
1492017-01-11T12:13:21  <NicolasDorier> it would not check policy rules
1502017-01-11T12:13:44  <jtimon> I was kind of doing that for 0.12 but I decided I would wait for bip9 and segwit instead
1512017-01-11T12:13:47  <NicolasDorier> I am tempted to still use my C# script validator for mempool stuff
1522017-01-11T12:14:07  <NicolasDorier> not including verifyTx
1532017-01-11T12:14:56  <jtimon> right, verifyTx would not check policy rules, perhaps we can have a verifyAndAcceptTx function too, but that's more bitcoin core specific I think
1542017-01-11T12:15:31  <jtimon> C# script validator? you don't use the verifyScript in current libconsensus ?
1552017-01-11T12:15:55  <NicolasDorier> NBitcoin has its own script validator yes
1562017-01-11T12:16:22  <jtimon> libbitcoin has his own validator as well, but optionally they allow you to use libconsensus instead
1572017-01-11T12:16:36  <NicolasDorier> right now the full node I did does not depends on libconsensus, but I want people to be able to activate it if they want
1582017-01-11T12:17:10  <NicolasDorier> the user can turn it for the script validation as well if he wants, but I want to verify the full block with libconsensus
1592017-01-11T12:17:27  <jtimon> is there any reason why you don't use libconsensus::verifyScript in nbitcoin ? do you plan to do it later?
1602017-01-11T12:17:34  <NicolasDorier> you can use it
1612017-01-11T12:17:49  <NicolasDorier> I do not by default because there is deployment headache
1622017-01-11T12:18:03  <NicolasDorier> pure C# code just run everywhere
1632017-01-11T12:18:05  <jtimon> oh, so then NBitcoin optionally depends on libconsensus, got it
1642017-01-11T12:18:09  <NicolasDorier> yes
1652017-01-11T12:19:10  <NicolasDorier> I will also add a mode where you setup a trusted node, and just do not verify the blocks.
1662017-01-11T12:19:55  <jtimon> what about caches? what do you plan for caches? bip9 cache, sigcache?
1672017-01-11T12:20:19  <jtimon> I mean, how do you plan to handle that with your libconsensus ?
1682017-01-11T12:20:45  <NicolasDorier> not yes thought about it. BIP9 I think the easiest at beginning is that the user does it. I plan in v1 that the user will pass the consensus flags to activate
1692017-01-11T12:20:56  <NicolasDorier> so libconsensus will not depends on CBlockIndex
1702017-01-11T12:21:33  <NicolasDorier> hopefully, I would like to make that into libconsensus eventually though
1712017-01-11T12:21:52  <jtimon> he has to count the 95% in the last diff adjustment period manually?
1722017-01-11T12:21:54  <NicolasDorier> for the other cache, I have not decided yet I dont know
1732017-01-11T12:22:06  <NicolasDorier> yes
1742017-01-11T12:22:10  <NicolasDorier> not perfect for sure
1752017-01-11T12:22:46  <jtimon> I guess no approach is perfect, all have drawbacks and advantages
1762017-01-11T12:23:15  <jtimon> I don't think I have any more questions, thank you!
1772017-01-11T12:23:26  <NicolasDorier> I think it is possible to make it part of libconsensus, but not yet thought about it, I would like a v1 without CBlockIndex
1782017-01-11T12:23:40  <jtimon> and btw, congrats on completing a full node alt implementation, not an easy task
1792017-01-11T12:24:05  <NicolasDorier> thanks, still stuff to do though. But happy with the results so far :D
1802017-01-11T12:24:29  <NicolasDorier> it is compatible with config file of Core, and has also rpc server
1812017-01-11T12:24:48  <NicolasDorier> my goal is to reuse the test suite of bitcoin core
1822017-01-11T12:24:53  <NicolasDorier> as is
1832017-01-11T12:25:00  <NicolasDorier> to test my implementation
1842017-01-11T12:25:08  <jtimon> in my approach I planned to expose a getConsensusFlags, but it would depend on a function_pointer-based API for CBlockIndex (the same I was using for verifyHeader in #8493 )
1852017-01-11T12:25:10  <gribble> https://github.com/bitcoin/bitcoin/issues/8493 | Untested: libconsensus: Expose VerifyHeader by jtimon · Pull Request #8493 · bitcoin/bitcoin · GitHub
1862017-01-11T12:25:24  <NicolasDorier> yes I remember
1872017-01-11T12:26:10  <jtimon> reusing bitcoin core's test suite is very interesting
1882017-01-11T12:45:54  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/5754e0341b7c...bbf193fef049
1892017-01-11T12:45:54  <bitcoin-git> bitcoin/master 67ca130 Cory Fields: build: fix for out-of-tree/distdir qt builds
1902017-01-11T12:45:55  <bitcoin-git> bitcoin/master bbf193f Wladimir J. van der Laan: Merge #9513: build: fix qt distdir builds (retry)...
1912017-01-11T12:46:09  <bitcoin-git> [bitcoin] laanwj closed pull request #9513: build: fix qt distdir builds (retry) (master...out-of-tree-build) https://github.com/bitcoin/bitcoin/pull/9513
1922017-01-11T12:52:34  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/bbf193fef049...593a00ce1935
1932017-01-11T12:52:35  <bitcoin-git> bitcoin/master 74994c6 Pieter Wuille: Improve style w.r.t. if
1942017-01-11T12:52:35  <bitcoin-git> bitcoin/master 593a00c Wladimir J. van der Laan: Merge #9506: RFC: Improve style for if indentation...
1952017-01-11T12:52:50  <bitcoin-git> [bitcoin] laanwj closed pull request #9506: RFC: Improve style for if indentation (master...newstyle) https://github.com/bitcoin/bitcoin/pull/9506
1962017-01-11T12:56:35  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/593a00ce1935...ca615e6c05ef
1972017-01-11T12:56:36  <bitcoin-git> bitcoin/master 8217bd1 fanquake: [depends] libevent 2.1.7rc
1982017-01-11T12:56:36  <bitcoin-git> bitcoin/master ca615e6 Wladimir J. van der Laan: Merge #9471: [depends] libevent 2.1.7rc...
1992017-01-11T12:56:50  <bitcoin-git> [bitcoin] laanwj closed pull request #9471: [depends] libevent 2.1.7rc (master...depends-0-14-0-libevent) https://github.com/bitcoin/bitcoin/pull/9471
2002017-01-11T13:01:07  <wumpus> are there any remaining issues with #9375?
2012017-01-11T13:01:10  <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
2022017-01-11T13:02:46  *** Chris_Stewart_5 has joined #bitcoin-core-dev
2032017-01-11T13:08:08  <instagibbs> same q for #9400
2042017-01-11T13:08:10  <gribble> https://github.com/bitcoin/bitcoin/issues/9400 | Set peers as HB peers upon full block validation by instagibbs · Pull Request #9400 · bitcoin/bitcoin · GitHub
2052017-01-11T13:12:41  <sipa> wumpus: i was planning to review 9375 today
2062017-01-11T13:13:27  <wumpus> sipa: okay, great
2072017-01-11T13:26:33  <bitcoin-git> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/ca615e6c05ef...e2e624d9ce54
2082017-01-11T13:26:34  <bitcoin-git> bitcoin/master 1fc4ec7 mrbandrews: Add pruneblockchain RPC to enable manual block file pruning.
2092017-01-11T13:26:35  <bitcoin-git> bitcoin/master afffeea Russell Yanofsky: fixup! Add pruneblockchain RPC to enable manual block file pruning....
2102017-01-11T13:26:35  <bitcoin-git> bitcoin/master e2e624d Wladimir J. van der Laan: Merge #7871: Manual block file pruning....
2112017-01-11T13:42:39  *** AaronvanW has quit IRC
2122017-01-11T13:46:11  *** AaronvanW_ has joined #bitcoin-core-dev
2132017-01-11T13:51:10  *** thokon00 has left #bitcoin-core-dev
2142017-01-11T13:52:56  <bitcoin-git> [bitcoin] kallewoof opened pull request #9517: [refactor] Switched httpserver.cpp to use RAII wrapped libevents. (master...raii-httpserver) https://github.com/bitcoin/bitcoin/pull/9517
2152017-01-11T14:23:28  <sipa> i wonder why unique_ptr does not have an emplace method like the stl containers have
2162017-01-11T14:23:40  <sipa> would be a neat and cheap way to avoid explicit new calls
2172017-01-11T14:25:12  *** Guest3710 has joined #bitcoin-core-dev
2182017-01-11T14:26:38  *** AaronvanW_ has quit IRC
2192017-01-11T14:27:08  *** AaronvanW has joined #bitcoin-core-dev
2202017-01-11T14:27:09  *** AaronvanW has quit IRC
2212017-01-11T14:27:09  *** AaronvanW has joined #bitcoin-core-dev
2222017-01-11T14:39:17  <jtimon> oh, I didn't know about contrib/devtools/check-doc.py
2232017-01-11T15:01:04  *** BashCo_ has quit IRC
2242017-01-11T15:11:05  *** BashCo has joined #bitcoin-core-dev
2252017-01-11T15:15:02  *** Chris_Stewart_5 has quit IRC
2262017-01-11T15:20:29  *** AaronvanW has quit IRC
2272017-01-11T15:28:37  *** AaronvanW_ has joined #bitcoin-core-dev
2282017-01-11T15:28:51  *** Chris_Stewart_5 has joined #bitcoin-core-dev
2292017-01-11T15:40:58  *** AaronvanW_ has quit IRC
2302017-01-11T15:43:23  *** xinxi has joined #bitcoin-core-dev
2312017-01-11T16:00:52  *** AaronvanW has joined #bitcoin-core-dev
2322017-01-11T16:55:47  *** paveljanik has joined #bitcoin-core-dev
2332017-01-11T16:55:52  *** abpa has joined #bitcoin-core-dev
2342017-01-11T17:03:05  *** Chris_St1 has joined #bitcoin-core-dev
2352017-01-11T17:03:31  *** Chris_Stewart_5 has quit IRC
2362017-01-11T17:03:46  *** Chris_St1 has quit IRC
2372017-01-11T17:05:25  *** Chris_Stewart_5 has joined #bitcoin-core-dev
2382017-01-11T17:08:17  *** xinxi has quit IRC
2392017-01-11T17:20:25  <cfields> sipa: see std::make_unique in c++14. I assume that's what you mean?
2402017-01-11T17:23:02  <gmaxwell> Lets upgreade to C++14! :P
2412017-01-11T17:23:29  *** xinxi has joined #bitcoin-core-dev
2422017-01-11T17:28:08  *** BashCo has quit IRC
2432017-01-11T17:28:43  *** BashCo has joined #bitcoin-core-dev
2442017-01-11T17:36:07  *** Guest719 has joined #bitcoin-core-dev
2452017-01-11T17:36:26  *** BashCo has quit IRC
2462017-01-11T17:37:11  *** Guest719 is now known as roidster
2472017-01-11T17:44:43  <sipa> cfields: but x.emplace(a,b) still looks nicer than x = std::make_unique<x_t>(a,b);
2482017-01-11T17:50:16  * luke-jr always found emplace to look ugly, but doesn't care enough to argue it
2492017-01-11T17:51:16  <cfields> sipa: ah, i see what you mean. seems a bit clumsy to me though, as emplace implies that you're constructing a new value in place, rather than replacing a (the) current one
2502017-01-11T18:01:37  *** BashCo has joined #bitcoin-core-dev
2512017-01-11T18:06:12  <profall> Anyone have a link to the latest blockchain torrent?
2522017-01-11T18:06:34  <sipa> profall: the blockchain torrent has been discontinued (at least by the bitcoin core maintainers) since 0.10
2532017-01-11T18:06:42  <profall> ah ok
2542017-01-11T18:06:48  <sipa> as the bitcoin block download code is usually faster
2552017-01-11T18:07:00  <sipa> (it validates while downloading)
2562017-01-11T18:07:28  <profall> yea
2572017-01-11T18:07:49  <profall> I am still experiencing issues with my node randomly dropping out of sync every few hours
2582017-01-11T18:07:58  <profall> I thought maybe a fresh resync might fix something, not sure.
2592017-01-11T18:08:08  <sipa> define 'dropping out of sync'
2602017-01-11T18:08:59  <profall> It'll be on the correct block if compared to blockchain.info or any other explorer. Then I will come back a few hours later and it'll be stuck on some block from 2 hours ago and not in sync anymore.
2612017-01-11T18:09:36  <profall> This is an E3 processor, 100mbps connection in a datacenter, 16GB ram server. Not resource starved.
2622017-01-11T18:10:12  <sipa> anything in debug.log?
2632017-01-11T18:11:37  <profall> ping timeout 1200s
2642017-01-11T18:11:58  <profall> socket recv error Connection reset by peer (104)
2652017-01-11T18:12:05  <sipa> that's normal
2662017-01-11T18:12:11  <sipa> what version?
2672017-01-11T18:12:18  <sipa> of bitcoin core
2682017-01-11T18:12:22  <gmaxwell> well it's not normal if it happens to all peers?
2692017-01-11T18:12:37  <profall> 0.13.2 on Linux
2702017-01-11T18:13:01  <profall> I downloaded it straight from the website rather then use the repo, just in case as well.
2712017-01-11T18:13:17  <gmaxwell> profall: can you send one of us a copy of your debug log including one of these incidents?  the debug log will identify your IP and potentially some of your transactions if you're using it as a wallet.
2722017-01-11T18:13:20  <sipa> could you share a few hours worth of debug.log somewhere?
2732017-01-11T18:14:39  <profall> Sure, ill PM you just give me a few moments to prepare it.
2742017-01-11T18:23:20  *** jannes has quit IRC
2752017-01-11T18:24:33  <profall> PM'd both of you with debug.log
2762017-01-11T18:24:53  *** [b__b] has quit IRC
2772017-01-11T18:24:59  <profall> Oops, realized it's empty...
2782017-01-11T18:25:11  *** [b__b] has joined #bitcoin-core-dev
2792017-01-11T18:25:43  <luke-jr> morcos: c0507f800475edf003adb744061d864741d3ee12796834d4d7f9a72b0bbd4fe6 is the only one on your list that shows up in my debug.log
2802017-01-11T18:25:44  <luke-jr> 2017-01-10 21:23:32 not keeping orphan with rejected parents c0507f800475edf003adb744061d864741d3ee1279
2812017-01-11T18:25:45  <luke-jr> And its parent was rejected because… 2017-01-10 21:23:32 d97b0571f984420ffebb8f4e69e3d1ed1467797105ad602747ff1ddff322ff40 from peer=14 was not accepted: bad-txns-inputs-spent (code 18)
2822017-01-11T18:25:47  <luke-jr> looks like a double-spend? … so the competing parent probably had enough fee for the mempool, but not enough to be mined, and d97b0571f9 didn't have enough more to replace it
2832017-01-11T18:25:48  * luke-jr wonders if this might be exploitable
2842017-01-11T18:26:12  <profall> Resent
2852017-01-11T18:33:34  <gmaxwell> BlueMatt: can you confirm that the new addnode behavior in master is sufficient to get rid of your fibre proxy thing?
2862017-01-11T18:33:46  <BlueMatt> gmaxwell: based on what you wrote in your pull, yes
2872017-01-11T18:34:03  <gmaxwell> okay, so if it does what it says on the tin you think its good to go.  fine with me.
2882017-01-11T18:34:06  <BlueMatt> I'd need to go re-test to confirm, but I did test pre-merge
2892017-01-11T18:34:11  <BlueMatt> yea
2902017-01-11T18:34:37  <gmaxwell> (I just wanted to make sure if you needed any other features that I wrote them ASAP.)
2912017-01-11T18:34:50  <BlueMatt> heh, yea, all good thanks
2922017-01-11T18:35:03  <BlueMatt> in other news, I'm avoiding review because sick, and super pissed off about this :(
2932017-01-11T18:39:39  <sipa> pissed about being sick?
2942017-01-11T18:39:55  <BlueMatt> both - i have so much review to do :(
2952017-01-11T18:40:02  *** Chris_Stewart_5 has quit IRC
2962017-01-11T18:41:35  *** Chris_Stewart_5 has joined #bitcoin-core-dev
2972017-01-11T18:47:15  <sipa> should -maxmempool=0 imply -blocksonly ?
2982017-01-11T18:48:23  <gmaxwell> Probably, though blocksonly is still a hidden option.
2992017-01-11T18:48:33  <sipa> ah, really
3002017-01-11T18:48:43  <gmaxwell> It's hidden because it would probably be better if we had a service bit related to it before having lots of nodes running it.
3012017-01-11T18:48:55  <gmaxwell> probably thats too conservative, it's unlikely lots of nodes would run it.
3022017-01-11T18:49:42  *** jtimon has quit IRC
3032017-01-11T18:54:34  *** chjj has quit IRC
3042017-01-11T18:56:14  *** jtimon has joined #bitcoin-core-dev
3052017-01-11T19:02:25  <cfields> BlueMatt: heh, i'm very behind on review as well. slowly making my way through yours.
3062017-01-11T19:02:30  *** owowo has quit IRC
3072017-01-11T19:03:35  <sipa> likewise
3082017-01-11T19:04:06  <instagibbs> Someone have the list of high-priority review on hand
3092017-01-11T19:05:09  <sipa> i think we really want #9375 #9441 in
3102017-01-11T19:05:11  <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
3112017-01-11T19:05:14  <gribble> https://github.com/bitcoin/bitcoin/issues/9441 | Net: Massive speedup. Net locks overhaul by theuni · Pull Request #9441 · bitcoin/bitcoin · GitHub
3122017-01-11T19:06:04  <cfields> BlueMatt: I've been stuck on the ActivateBestChain() kludge for quite a while now. I don't like it, but with no better argument than "it's ugly". Would it be reasonable instead to maintain a list of announced-but-not-stored hashes, combined with maybe just a quick hack like WaitForValidation(hash) ?
3132017-01-11T19:06:18  <cfields> (i assume that question has been posed already)
3142017-01-11T19:06:26  *** owowo has joined #bitcoin-core-dev
3152017-01-11T19:06:26  *** owowo has joined #bitcoin-core-dev
3162017-01-11T19:06:26  *** owowo has joined #bitcoin-core-dev
3172017-01-11T19:07:07  <BlueMatt> cfields: if you announce a block which turns out to be invalid, WaitForValidation wont help :/
3182017-01-11T19:07:11  <instagibbs> Ok, I really cant comment on the net locks overhaul but I'll re-review the former
3192017-01-11T19:07:47  <cfields> BlueMatt: well presumably it'd drop out of the list, valid or no
3202017-01-11T19:09:56  <cfields> BlueMatt: i suppose at an even higher level it could just be WaitForBestChainActivated()
3212017-01-11T19:11:40  <BlueMatt> cfields: i mean the ActivateBestChain kludge is only there for the case where you caught the cs_main lock right in the middle of ProcessNewBlock where it unlocks cs_main for a sec
3222017-01-11T19:11:52  <BlueMatt> ActivateBestChain literally is WaitForActivateBestChainActivated().....
3232017-01-11T19:12:06  <BlueMatt> its just the version for when you're already holding cs_main
3242017-01-11T19:14:14  <cfields> BlueMatt: understood. Just seems scary to allow that to be manipulated so easily. Like I said though, I can't come up with any realistic issue with it.
3252017-01-11T19:14:27  <BlueMatt> "manipulated"?
3262017-01-11T19:14:37  <BlueMatt> I mean I hope that its pretty much free if you're already on the best chain
3272017-01-11T19:30:48  *** chjj has joined #bitcoin-core-dev
3282017-01-11T19:32:05  <bitcoin-git> [bitcoin] ryanofsky opened pull request #9518: Return height of last block pruned by pruneblockchain RPC (master...pr/prune-height) https://github.com/bitcoin/bitcoin/pull/9518
3292017-01-11T19:48:18  <sipa> ryanofsky: feel like having a look at https://github.com/sipa/bitcoin/commits/pertxoutcache ?
3302017-01-11T19:48:40  <gmaxwell> I will be travling during the meeting tomorrow.
3312017-01-11T19:57:04  *** Chris_Stewart_5 has quit IRC
3322017-01-11T19:59:04  *** chjj has quit IRC
3332017-01-11T20:02:13  *** chjj has joined #bitcoin-core-dev
3342017-01-11T20:03:19  *** xinxi has quit IRC
3352017-01-11T20:04:49  *** roidster has quit IRC
3362017-01-11T20:05:06  *** atroxes has quit IRC
3372017-01-11T20:05:34  *** atroxes has joined #bitcoin-core-dev
3382017-01-11T20:11:28  *** atroxes has quit IRC
3392017-01-11T20:12:25  *** Chris_Stewart_5 has joined #bitcoin-core-dev
3402017-01-11T20:12:47  *** atroxes has joined #bitcoin-core-dev
3412017-01-11T20:14:51  <cfields> BlueMatt: as an example of an unintended side-effect: miner mines a block, hands it to ProcessNewBlock, ProcessMessages (incoming GETBLOCKS) swoops in _just_ after AcceptBlock and runs ActivateBestChain, before the mining thread gets a chance to. As a result, miner has to read the block from disk
3422017-01-11T20:15:08  <cfields> BlueMatt: trivial and unlikely, but still a side-effect :\
3432017-01-11T20:16:09  <cfields> rather, the processor reads from disk.
3442017-01-11T20:20:57  *** xinxi has joined #bitcoin-core-dev
3452017-01-11T20:25:54  *** laurentmt has joined #bitcoin-core-dev
3462017-01-11T20:26:06  <morcos> luke-jr: that was a replay, that tx was mined on 01-03
3472017-01-11T20:27:02  *** xinxi has quit IRC
3482017-01-11T20:28:05  <bitcoin-git> [bitcoin] morcos opened pull request #9519: Exclude RBF replacement txs from fee estimation (master...excludeRBF) https://github.com/bitcoin/bitcoin/pull/9519
3492017-01-11T20:30:59  *** xinxi has joined #bitcoin-core-dev
3502017-01-11T20:40:02  *** d9b4bef9 has quit IRC
3512017-01-11T20:41:08  *** d9b4bef9 has joined #bitcoin-core-dev
3522017-01-11T20:42:50  *** laurentmt has quit IRC
3532017-01-11T20:48:24  *** xinxi_ has joined #bitcoin-core-dev
3542017-01-11T20:51:28  *** xinxi has quit IRC
3552017-01-11T20:52:11  *** adiabat has joined #bitcoin-core-dev
3562017-01-11T20:53:23  *** ClockCat has joined #bitcoin-core-dev
3572017-01-11T20:57:48  *** laurentmt has joined #bitcoin-core-dev
3582017-01-11T20:58:58  *** laurentmt has quit IRC
3592017-01-11T21:10:40  *** xinxi_ has quit IRC
3602017-01-11T21:12:16  *** roidster has joined #bitcoin-core-dev
3612017-01-11T21:23:47  *** roidster has quit IRC
3622017-01-11T21:59:22  <bitcoin-git> [bitcoin] sipa pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/e2e624d9ce54...05950427d310
3632017-01-11T21:59:22  <bitcoin-git> bitcoin/master fe7e593 Suhas Daftuar: Fix use-after-free in CTxMemPool::removeConflicts()
3642017-01-11T21:59:23  <bitcoin-git> bitcoin/master 0595042 Pieter Wuille: Merge #9507: Fix use-after-free in CTxMemPool::removeConflicts()...
3652017-01-11T21:59:55  <bitcoin-git> [bitcoin] sipa closed pull request #9507: Fix use-after-free in CTxMemPool::removeConflicts() (master...fix-mempool-useafterfree) https://github.com/bitcoin/bitcoin/pull/9507
3662017-01-11T22:08:28  <BlueMatt> cfields: I suppose I'm not too concerned by that kind of super-crazy race....in the future we probably do want to cache stuff like that more
3672017-01-11T22:09:50  <cfields> BlueMatt: i'm not at all concerned by it. My only concern is that it's entirely non-obvious what the side-effects are. And that they're bound to change in the future.
3682017-01-11T22:12:02  <cfields> BlueMatt: The first path I was chasing down was whether or not, in the same scenario, the miner's validationinterface would only receive a null pointer (in the case of the dummy ActivateBestChain) rather than the real block. That's obviously not the case. My fear, though, is that if that _were_ the case, we might not have noticed.
3692017-01-11T22:12:36  <BlueMatt> yes, I did check for that when writing the code :p
3702017-01-11T22:13:24  <BlueMatt> cfields: I think the (real) solution is to make callbacks out of ValidationInterface go in a background thread, and make ProcessNewBlock hold the cs_main lock the whole time
3712017-01-11T22:13:32  <BlueMatt> but that is definitely not a 0.14 refactor
3722017-01-11T22:13:49  <gmaxwell> great, but would I know to enforce that invariant if I were changing the code later?
3732017-01-11T22:14:23  <cfields> ^^ what he said :)
3742017-01-11T22:15:17  <BlueMatt> wait, which callback are you referring to?
3752017-01-11T22:15:47  <BlueMatt> it was already the case that ActivateBestChain could be called "loose" and connect a block, so I dont think I changed the requirements on ABS?
3762017-01-11T22:16:28  *** jtimon has quit IRC
3772017-01-11T22:17:03  <cfields> ABS ?
3782017-01-11T22:17:13  <BlueMatt> activatebestchain
3792017-01-11T22:17:23  <BlueMatt> but the version that comes out when I've got a head-cold :p
3802017-01-11T22:17:28  <cfields> ah, ActivateBeStchain :p
3812017-01-11T22:17:33  <BlueMatt> yea, that
3822017-01-11T22:18:09  <sipa> Next PR: "Correct ActivateBestChain to ActivateBestShain"
3832017-01-11T22:18:25  <cfields> no, that didn't change, but there's now a publicly triggerable way to (try to) force an ABS between ProcessBlock and the ABS below it
3842017-01-11T22:18:42  <BlueMatt> mmm, fair enough
3852017-01-11T22:19:48  <cfields> sipa: heh. Blockshain all the things!
3862017-01-11T22:21:10  <sipa> since 9 days ago, the memory usage of mapBlockIndex exceeded 100M
3872017-01-11T22:22:00  <sipa> it's using 224 bytes per entry
3882017-01-11T22:22:15  <sipa> some of which could be avoided
3892017-01-11T22:22:31  <BlueMatt> yes, lets fix that
3902017-01-11T22:22:40  <gmaxwell> not that much could be avoided though.
3912017-01-11T22:22:59  <sipa> it's using 2 allocations per entry
3922017-01-11T22:23:09  <sipa> (which are included in the 224 number)
3932017-01-11T22:23:14  <BlueMatt> wait, it is?
3942017-01-11T22:23:17  <sipa> it should be 0
3952017-01-11T22:23:23  <BlueMatt> gmaxwell: like 20 bytes per entry last I checked
3962017-01-11T22:23:53  <sipa> but at least 1 should be trivial to avoid
3972017-01-11T22:24:16  <sipa> using a map<uint256, CBlockIndex> instead of map<uint256, CBlockIndex*>
3982017-01-11T22:24:27  <gmaxwell> sipa: how can it be zero? the data structure grows and things keep around pointers to it? no.
3992017-01-11T22:24:47  <sipa> gmaxwell: direct hashtable
4002017-01-11T22:25:00  <sipa> and using map::iterators instead of CBlockIndex* all over the place
4012017-01-11T22:25:24  <gmaxwell> okay, perhaps we don't actually keep any of the pointers.
4022017-01-11T22:25:36  <sipa> but if we're going to do that, i'd want a proper encapsulation too, that has its own lock, and has accessor methods for the fields that can be accessed without lock
4032017-01-11T22:25:54  <sipa> ... post 0.14
4042017-01-11T22:26:14  <gmaxwell> sipa: well if the work is done to change how its accessed it should be encapsulated enough so that it could be diskbacked without changing any of the code.
4052017-01-11T22:26:49  <gmaxwell> even with all the overheads gone, it's a significant chunk of memory.
4062017-01-11T22:27:19  <sipa> right
4072017-01-11T22:27:51  *** kadoban has quit IRC
4082017-01-11T22:28:01  *** kadoban has joined #bitcoin-core-dev
4092017-01-11T22:28:10  <sipa> ideally we'd also split up the disk-storage part and the validity-related part
4102017-01-11T22:28:20  <sipa> into two structures
4112017-01-11T22:40:44  *** Guyver2 has quit IRC
4122017-01-11T23:11:04  *** xinxi has joined #bitcoin-core-dev
4132017-01-11T23:15:04  *** xinxi has quit IRC
4142017-01-11T23:16:42  <bitcoin-git> [bitcoin] sipa closed pull request #8170: Remove lookup-tx-by-utxo functionality (master...betternotxindex) https://github.com/bitcoin/bitcoin/pull/8170
4152017-01-11T23:32:41  *** cheese_ has joined #bitcoin-core-dev
4162017-01-11T23:37:02  *** Guest3710 has quit IRC
4172017-01-11T23:37:12  <bitcoin-git> [bitcoin] sipa opened pull request #9520: Deprecate non-txindex getrawtransaction and better warning (master...warntxindex) https://github.com/bitcoin/bitcoin/pull/9520
4182017-01-11T23:41:10  *** Magma has quit IRC
4192017-01-11T23:41:37  *** Magma has joined #bitcoin-core-dev
4202017-01-11T23:48:34  *** Magma has quit IRC
4212017-01-11T23:48:57  *** Magma has joined #bitcoin-core-dev
4222017-01-11T23:56:08  <sipa> some review on #9261 plz?
4232017-01-11T23:56:09  <gribble> https://github.com/bitcoin/bitcoin/issues/9261 | Add unstored orphans with rejected parents to recentRejects by morcos · Pull Request #9261 · bitcoin/bitcoin · GitHub