1 2017-01-11T00:11:32  *** CodeShark has quit IRC
  2 2017-01-11T00:11:32  *** aspect_ has quit IRC
  3 2017-01-11T00:12:51  *** norotartagen has quit IRC
  4 2017-01-11T00:13:48  *** norotartagen has joined #bitcoin-core-dev
  5 2017-01-11T00:14:46  *** CodeShark has joined #bitcoin-core-dev
  6 2017-01-11T00:21:39  *** aspect_ has joined #bitcoin-core-dev
  7 2017-01-11T00:28:55  *** fanquake has joined #bitcoin-core-dev
  8 2017-01-11T00:33:18  *** xinxi has joined #bitcoin-core-dev
  9 2017-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
 10 2017-01-11T00:39:01  *** jannes has quit IRC
 11 2017-01-11T00:47:35  *** jtimon has quit IRC
 12 2017-01-11T00:58:46  *** abpa has quit IRC
 13 2017-01-11T01:08:33  *** xinxi has quit IRC
 14 2017-01-11T01:10:34  *** Cheeseo has joined #bitcoin-core-dev
 15 2017-01-11T01:10:46  *** Cheeseo has joined #bitcoin-core-dev
 16 2017-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
 17 2017-01-11T01:21:48  *** MarcoFalke has quit IRC
 18 2017-01-11T01:24:12  *** moli has joined #bitcoin-core-dev
 19 2017-01-11T01:38:13  *** abpa has joined #bitcoin-core-dev
 20 2017-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
 21 2017-01-11T01:41:35  *** xinxi has joined #bitcoin-core-dev
 22 2017-01-11T01:43:29  *** fanquake has quit IRC
 23 2017-01-11T01:47:28  *** Ylbam has quit IRC
 24 2017-01-11T02:17:07  *** xinxi has quit IRC
 25 2017-01-11T02:33:53  *** xinxi has joined #bitcoin-core-dev
 26 2017-01-11T02:38:09  *** xinxi has quit IRC
 27 2017-01-11T02:39:15  *** abpa has quit IRC
 28 2017-01-11T02:47:58  *** xinxi has joined #bitcoin-core-dev
 29 2017-01-11T02:48:35  *** Chris_Stewart_5 has quit IRC
 30 2017-01-11T03:04:41  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 31 2017-01-11T03:21:17  *** Victorsueca has joined #bitcoin-core-dev
 32 2017-01-11T03:24:01  *** Victor_sueca has quit IRC
 33 2017-01-11T03:28:12  *** Chris_Stewart_5 has quit IRC
 34 2017-01-11T03:28:17  *** justanotheruser has joined #bitcoin-core-dev
 35 2017-01-11T03:49:01  *** xinxi has quit IRC
 36 2017-01-11T03:51:32  *** windsok has quit IRC
 37 2017-01-11T03:56:02  *** xinxi has joined #bitcoin-core-dev
 38 2017-01-11T04:19:38  *** chris200_ has joined #bitcoin-core-dev
 39 2017-01-11T04:22:11  *** Alopex has quit IRC
 40 2017-01-11T04:22:32  *** chris2000 has quit IRC
 41 2017-01-11T04:23:16  *** Alopex has joined #bitcoin-core-dev
 42 2017-01-11T04:24:47  *** dcousens has quit IRC
 43 2017-01-11T04:34:56  *** windsok has joined #bitcoin-core-dev
 44 2017-01-11T04:57:10  *** chjj has quit IRC
 45 2017-01-11T04:57:12  *** xinxi has quit IRC
 46 2017-01-11T04:59:40  *** xinxi has joined #bitcoin-core-dev
 47 2017-01-11T05:00:11  *** Alopex has quit IRC
 48 2017-01-11T05:01:17  *** Alopex has joined #bitcoin-core-dev
 49 2017-01-11T05:04:11  *** Lauda has quit IRC
 50 2017-01-11T05:30:35  *** adiabat has quit IRC
 51 2017-01-11T05:39:06  *** Lauda has joined #bitcoin-core-dev
 52 2017-01-11T05:57:34  *** chjj has joined #bitcoin-core-dev
 53 2017-01-11T06:04:54  *** justanotheruser is now known as OfficialLeibniz
 54 2017-01-11T06:49:04  *** tunafizz has quit IRC
 55 2017-01-11T06:49:20  *** dcousens has joined #bitcoin-core-dev
 56 2017-01-11T06:54:02  *** tunafizz has joined #bitcoin-core-dev
 57 2017-01-11T07:17:09  <jonasschnelli> cfields: is this meant to be public: https://github.com/bitcoin/bitcoin/pull/9514/files#diff-6373b8b56e3d0425bbd3b0bb32c48162?
 58 2017-01-11T07:21:36  *** xinxi has quit IRC
 59 2017-01-11T07:24:40  <paveljanik> jonasschnelli, it is a certificate only
 60 2017-01-11T07:24:44  <paveljanik> no privkey
 61 2017-01-11T07:25:18  <jonasschnelli> paveljanik: okay. Not familiar with windows code signing...
 62 2017-01-11T07:25:39  <paveljanik> -me is not familiar with Windows at all ů=0
 63 2017-01-11T07:25:41  <paveljanik> ;-)
 64 2017-01-11T07:37:02  *** BitBully has joined #bitcoin-core-dev
 65 2017-01-11T08:11:07  *** BashCo has quit IRC
 66 2017-01-11T08:11:45  *** BashCo has joined #bitcoin-core-dev
 67 2017-01-11T08:16:05  *** BashCo has quit IRC
 68 2017-01-11T08:16:05  *** davec has quit IRC
 69 2017-01-11T08:16:24  *** davec has joined #bitcoin-core-dev
 70 2017-01-11T08:17:26  *** BitBully has quit IRC
 71 2017-01-11T08:18:59  *** BitBully has joined #bitcoin-core-dev
 72 2017-01-11T08:36:40  *** BashCo has joined #bitcoin-core-dev
 73 2017-01-11T08:40:55  *** BitBully has quit IRC
 74 2017-01-11T08:47:25  *** Guyver2 has joined #bitcoin-core-dev
 75 2017-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
 76 2017-01-11T09:41:25  *** waxwing has quit IRC
 77 2017-01-11T09:41:33  *** MarcoFalke has joined #bitcoin-core-dev
 78 2017-01-11T10:23:38  *** Ylbam has joined #bitcoin-core-dev
 79 2017-01-11T11:08:42  *** AaronvanW has joined #bitcoin-core-dev
 80 2017-01-11T11:08:43  *** AaronvanW has quit IRC
 81 2017-01-11T11:08:43  *** AaronvanW has joined #bitcoin-core-dev
 82 2017-01-11T11:09:37  *** jannes has joined #bitcoin-core-dev
 83 2017-01-11T11:10:51  *** dcousens has quit IRC
 84 2017-01-11T11:15:02  *** pavel_ has joined #bitcoin-core-dev
 85 2017-01-11T11:18:08  *** paveljanik has quit IRC
 86 2017-01-11T11:24:34  *** cjamthagen has quit IRC
 87 2017-01-11T11:26:42  *** BitBully has joined #bitcoin-core-dev
 88 2017-01-11T11:32:00  *** BitBully has quit IRC
 89 2017-01-11T11:38:02  *** cjamthagen has joined #bitcoin-core-dev
 90 2017-01-11T11:40:46  *** BashCo has quit IRC
 91 2017-01-11T11:40:52  *** BashCo_ has joined #bitcoin-core-dev
 92 2017-01-11T11:54:53  *** jtimon has joined #bitcoin-core-dev
 93 2017-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
 94 2017-01-11T11:57:04  <jtimon> NicolasDorier: regarding your vision for libconsensus, do you mind if I make some more questions here?
 95 2017-01-11T11:57:18  <NicolasDorier> sure
 96 2017-01-11T11:57:29  <NicolasDorier> I think trying the following
 97 2017-01-11T11:57:34  <NicolasDorier> brand new project
 98 2017-01-11T11:57:40  <NicolasDorier> copy/pasta of bitcoin core
 99 2017-01-11T11:57:52  <NicolasDorier> then stripping everything not related to consensus
100 2017-01-11T11:58:04  <NicolasDorier> removing all dependencies to third party libs
101 2017-01-11T11:58:27  <jtimon> well, copy paste from core or doing it in core ignoring the rest is not that different is it?
102 2017-01-11T11:59:16  <NicolasDorier> I think it is harder
103 2017-01-11T11:59:35  <NicolasDorier> like there is so much reference to the utxo storage in the consensus code.
104 2017-01-11T12:00:04  <NicolasDorier> I would prefer being able to strip that
105 2017-01-11T12:00:21  <NicolasDorier> rather than trying to make interfaces
106 2017-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
107 2017-01-11T12:01:03  *** MarcoFalke has left #bitcoin-core-dev
108 2017-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
109 2017-01-11T12:01:15  *** MarcoFalke has joined #bitcoin-core-dev
110 2017-01-11T12:01:30  <jtimon> but then the client needs to know which ones will be relevant before calling
111 2017-01-11T12:01:54  <NicolasDorier> yes, and but the client know that
112 2017-01-11T12:01:57  <jtimon> and will need to fetch them even if the tx/block was already invalid because of something trivial
113 2017-01-11T12:01:57  <NicolasDorier> since he has the block
114 2017-01-11T12:02:22  <NicolasDorier> correct. But the client can verify PoW before fetching
115 2017-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
116 2017-01-11T12:02:57  <jtimon> another discussion was how the client gets that data
117 2017-01-11T12:03:11  <NicolasDorier> this would be the client's business
118 2017-01-11T12:03:17  <NicolasDorier> this is simple enough stuff to do
119 2017-01-11T12:03:35  <NicolasDorier> iffunction pointer
120 2017-01-11T12:03:56  <NicolasDorier> it is complicated to use, and
121 2017-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
122 2017-01-11T12:04:20  <NicolasDorier> if the implementation cross boundary between languages, there is huge perf hit
123 2017-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
124 2017-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)
125 2017-01-11T12:05:47  <jtimon> right, just comparing the different approaches
126 2017-01-11T12:06:08  <NicolasDorier> this also make it harder for us to break users of consensus
127 2017-01-11T12:06:25  <NicolasDorier> because we would make no assumption on how they deal with their storage
128 2017-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
129 2017-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
130 2017-01-11T12:07:47  <jtimon> right, that's an advantage for both the abstracted storage API or the abstracted storage by prefetching
131 2017-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
132 2017-01-11T12:09:07  <NicolasDorier> I don't think libconsensus should have any dependencies
133 2017-01-11T12:09:21  <NicolasDorier> it should be plain dumb lib like libsecpk)#*R#)*$
134 2017-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
135 2017-01-11T12:09:44  <NicolasDorier> yes other things as well
136 2017-01-11T12:09:56  <NicolasDorier> like CheckContextual *
137 2017-01-11T12:10:02  <jtimon> well, I think at the very least it should have libsecp256k1 as a dependency, but I agree it shouldn
138 2017-01-11T12:10:06  <NicolasDorier> yes
139 2017-01-11T12:10:10  <jtimon> 't depend on levelDB
140 2017-01-11T12:10:35  <jtimon> just pointing out that other people disagree
141 2017-01-11T12:11:07  <NicolasDorier> yes
142 2017-01-11T12:11:15  <jtimon> so maybe you would expose checkblock and verifyBlock separately
143 2017-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
144 2017-01-11T12:11:39  <jtimon> makes sense, I thought about it
145 2017-01-11T12:12:22  <jtimon> do you plan to expose lower level functions like say verifyHeader or verifyTx ?
146 2017-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
147 2017-01-11T12:13:15  <NicolasDorier> it would
148 2017-01-11T12:13:16  <jtimon> yeah, I think I will finish my vision on top of 0.14 and then see what happens
149 2017-01-11T12:13:21  <NicolasDorier> it would not check policy rules
150 2017-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
151 2017-01-11T12:13:47  <NicolasDorier> I am tempted to still use my C# script validator for mempool stuff
152 2017-01-11T12:14:07  <NicolasDorier> not including verifyTx
153 2017-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
154 2017-01-11T12:15:31  <jtimon> C# script validator? you don't use the verifyScript in current libconsensus ?
155 2017-01-11T12:15:55  <NicolasDorier> NBitcoin has its own script validator yes
156 2017-01-11T12:16:22  <jtimon> libbitcoin has his own validator as well, but optionally they allow you to use libconsensus instead
157 2017-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
158 2017-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
159 2017-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?
160 2017-01-11T12:17:34  <NicolasDorier> you can use it
161 2017-01-11T12:17:49  <NicolasDorier> I do not by default because there is deployment headache
162 2017-01-11T12:18:03  <NicolasDorier> pure C# code just run everywhere
163 2017-01-11T12:18:05  <jtimon> oh, so then NBitcoin optionally depends on libconsensus, got it
164 2017-01-11T12:18:09  <NicolasDorier> yes
165 2017-01-11T12:19:10  <NicolasDorier> I will also add a mode where you setup a trusted node, and just do not verify the blocks.
166 2017-01-11T12:19:55  <jtimon> what about caches? what do you plan for caches? bip9 cache, sigcache?
167 2017-01-11T12:20:19  <jtimon> I mean, how do you plan to handle that with your libconsensus ?
168 2017-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
169 2017-01-11T12:20:56  <NicolasDorier> so libconsensus will not depends on CBlockIndex
170 2017-01-11T12:21:33  <NicolasDorier> hopefully, I would like to make that into libconsensus eventually though
171 2017-01-11T12:21:52  <jtimon> he has to count the 95% in the last diff adjustment period manually?
172 2017-01-11T12:21:54  <NicolasDorier> for the other cache, I have not decided yet I dont know
173 2017-01-11T12:22:06  <NicolasDorier> yes
174 2017-01-11T12:22:10  <NicolasDorier> not perfect for sure
175 2017-01-11T12:22:46  <jtimon> I guess no approach is perfect, all have drawbacks and advantages
176 2017-01-11T12:23:15  <jtimon> I don't think I have any more questions, thank you!
177 2017-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
178 2017-01-11T12:23:40  <jtimon> and btw, congrats on completing a full node alt implementation, not an easy task
179 2017-01-11T12:24:05  <NicolasDorier> thanks, still stuff to do though. But happy with the results so far :D
180 2017-01-11T12:24:29  <NicolasDorier> it is compatible with config file of Core, and has also rpc server
181 2017-01-11T12:24:48  <NicolasDorier> my goal is to reuse the test suite of bitcoin core
182 2017-01-11T12:24:53  <NicolasDorier> as is
183 2017-01-11T12:25:00  <NicolasDorier> to test my implementation
184 2017-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 )
185 2017-01-11T12:25:10  <gribble> https://github.com/bitcoin/bitcoin/issues/8493 | Untested: libconsensus: Expose VerifyHeader by jtimon · Pull Request #8493 · bitcoin/bitcoin · GitHub
186 2017-01-11T12:25:24  <NicolasDorier> yes I remember
187 2017-01-11T12:26:10  <jtimon> reusing bitcoin core's test suite is very interesting
188 2017-01-11T12:45:54  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/5754e0341b7c...bbf193fef049
189 2017-01-11T12:45:54  <bitcoin-git> bitcoin/master 67ca130 Cory Fields: build: fix for out-of-tree/distdir qt builds
190 2017-01-11T12:45:55  <bitcoin-git> bitcoin/master bbf193f Wladimir J. van der Laan: Merge #9513: build: fix qt distdir builds (retry)...
191 2017-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
192 2017-01-11T12:52:34  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/bbf193fef049...593a00ce1935
193 2017-01-11T12:52:35  <bitcoin-git> bitcoin/master 74994c6 Pieter Wuille: Improve style w.r.t. if
194 2017-01-11T12:52:35  <bitcoin-git> bitcoin/master 593a00c Wladimir J. van der Laan: Merge #9506: RFC: Improve style for if indentation...
195 2017-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
196 2017-01-11T12:56:35  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/593a00ce1935...ca615e6c05ef
197 2017-01-11T12:56:36  <bitcoin-git> bitcoin/master 8217bd1 fanquake: [depends] libevent 2.1.7rc
198 2017-01-11T12:56:36  <bitcoin-git> bitcoin/master ca615e6 Wladimir J. van der Laan: Merge #9471: [depends] libevent 2.1.7rc...
199 2017-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
200 2017-01-11T13:01:07  <wumpus> are there any remaining issues with #9375?
201 2017-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
202 2017-01-11T13:02:46  *** Chris_Stewart_5 has joined #bitcoin-core-dev
203 2017-01-11T13:08:08  <instagibbs> same q for #9400
204 2017-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
205 2017-01-11T13:12:41  <sipa> wumpus: i was planning to review 9375 today
206 2017-01-11T13:13:27  <wumpus> sipa: okay, great
207 2017-01-11T13:26:33  <bitcoin-git> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/ca615e6c05ef...e2e624d9ce54
208 2017-01-11T13:26:34  <bitcoin-git> bitcoin/master 1fc4ec7 mrbandrews: Add pruneblockchain RPC to enable manual block file pruning.
209 2017-01-11T13:26:35  <bitcoin-git> bitcoin/master afffeea Russell Yanofsky: fixup! Add pruneblockchain RPC to enable manual block file pruning....
210 2017-01-11T13:26:35  <bitcoin-git> bitcoin/master e2e624d Wladimir J. van der Laan: Merge #7871: Manual block file pruning....
211 2017-01-11T13:42:39  *** AaronvanW has quit IRC
212 2017-01-11T13:46:11  *** AaronvanW_ has joined #bitcoin-core-dev
213 2017-01-11T13:51:10  *** thokon00 has left #bitcoin-core-dev
214 2017-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
215 2017-01-11T14:23:28  <sipa> i wonder why unique_ptr does not have an emplace method like the stl containers have
216 2017-01-11T14:23:40  <sipa> would be a neat and cheap way to avoid explicit new calls
217 2017-01-11T14:25:12  *** Guest3710 has joined #bitcoin-core-dev
218 2017-01-11T14:26:38  *** AaronvanW_ has quit IRC
219 2017-01-11T14:27:08  *** AaronvanW has joined #bitcoin-core-dev
220 2017-01-11T14:27:09  *** AaronvanW has quit IRC
221 2017-01-11T14:27:09  *** AaronvanW has joined #bitcoin-core-dev
222 2017-01-11T14:39:17  <jtimon> oh, I didn't know about contrib/devtools/check-doc.py
223 2017-01-11T15:01:04  *** BashCo_ has quit IRC
224 2017-01-11T15:11:05  *** BashCo has joined #bitcoin-core-dev
225 2017-01-11T15:15:02  *** Chris_Stewart_5 has quit IRC
226 2017-01-11T15:20:29  *** AaronvanW has quit IRC
227 2017-01-11T15:28:37  *** AaronvanW_ has joined #bitcoin-core-dev
228 2017-01-11T15:28:51  *** Chris_Stewart_5 has joined #bitcoin-core-dev
229 2017-01-11T15:40:58  *** AaronvanW_ has quit IRC
230 2017-01-11T15:43:23  *** xinxi has joined #bitcoin-core-dev
231 2017-01-11T16:00:52  *** AaronvanW has joined #bitcoin-core-dev
232 2017-01-11T16:55:47  *** paveljanik has joined #bitcoin-core-dev
233 2017-01-11T16:55:52  *** abpa has joined #bitcoin-core-dev
234 2017-01-11T17:03:05  *** Chris_St1 has joined #bitcoin-core-dev
235 2017-01-11T17:03:31  *** Chris_Stewart_5 has quit IRC
236 2017-01-11T17:03:46  *** Chris_St1 has quit IRC
237 2017-01-11T17:05:25  *** Chris_Stewart_5 has joined #bitcoin-core-dev
238 2017-01-11T17:08:17  *** xinxi has quit IRC
239 2017-01-11T17:20:25  <cfields> sipa: see std::make_unique in c++14. I assume that's what you mean?
240 2017-01-11T17:23:02  <gmaxwell> Lets upgreade to C++14! :P
241 2017-01-11T17:23:29  *** xinxi has joined #bitcoin-core-dev
242 2017-01-11T17:28:08  *** BashCo has quit IRC
243 2017-01-11T17:28:43  *** BashCo has joined #bitcoin-core-dev
244 2017-01-11T17:36:07  *** Guest719 has joined #bitcoin-core-dev
245 2017-01-11T17:36:26  *** BashCo has quit IRC
246 2017-01-11T17:37:11  *** Guest719 is now known as roidster
247 2017-01-11T17:44:43  <sipa> cfields: but x.emplace(a,b) still looks nicer than x = std::make_unique<x_t>(a,b);
248 2017-01-11T17:50:16  * luke-jr always found emplace to look ugly, but doesn't care enough to argue it
249 2017-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
250 2017-01-11T18:01:37  *** BashCo has joined #bitcoin-core-dev
251 2017-01-11T18:06:12  <profall> Anyone have a link to the latest blockchain torrent?
252 2017-01-11T18:06:34  <sipa> profall: the blockchain torrent has been discontinued (at least by the bitcoin core maintainers) since 0.10
253 2017-01-11T18:06:42  <profall> ah ok
254 2017-01-11T18:06:48  <sipa> as the bitcoin block download code is usually faster
255 2017-01-11T18:07:00  <sipa> (it validates while downloading)
256 2017-01-11T18:07:28  <profall> yea
257 2017-01-11T18:07:49  <profall> I am still experiencing issues with my node randomly dropping out of sync every few hours
258 2017-01-11T18:07:58  <profall> I thought maybe a fresh resync might fix something, not sure.
259 2017-01-11T18:08:08  <sipa> define 'dropping out of sync'
260 2017-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.
261 2017-01-11T18:09:36  <profall> This is an E3 processor, 100mbps connection in a datacenter, 16GB ram server. Not resource starved.
262 2017-01-11T18:10:12  <sipa> anything in debug.log?
263 2017-01-11T18:11:37  <profall> ping timeout 1200s
264 2017-01-11T18:11:58  <profall> socket recv error Connection reset by peer (104)
265 2017-01-11T18:12:05  <sipa> that's normal
266 2017-01-11T18:12:11  <sipa> what version?
267 2017-01-11T18:12:18  <sipa> of bitcoin core
268 2017-01-11T18:12:22  <gmaxwell> well it's not normal if it happens to all peers?
269 2017-01-11T18:12:37  <profall> 0.13.2 on Linux
270 2017-01-11T18:13:01  <profall> I downloaded it straight from the website rather then use the repo, just in case as well.
271 2017-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.
272 2017-01-11T18:13:20  <sipa> could you share a few hours worth of debug.log somewhere?
273 2017-01-11T18:14:39  <profall> Sure, ill PM you just give me a few moments to prepare it.
274 2017-01-11T18:23:20  *** jannes has quit IRC
275 2017-01-11T18:24:33  <profall> PM'd both of you with debug.log
276 2017-01-11T18:24:53  *** [b__b] has quit IRC
277 2017-01-11T18:24:59  <profall> Oops, realized it's empty...
278 2017-01-11T18:25:11  *** [b__b] has joined #bitcoin-core-dev
279 2017-01-11T18:25:43  <luke-jr> morcos: c0507f800475edf003adb744061d864741d3ee12796834d4d7f9a72b0bbd4fe6 is the only one on your list that shows up in my debug.log
280 2017-01-11T18:25:44  <luke-jr> 2017-01-10 21:23:32 not keeping orphan with rejected parents c0507f800475edf003adb744061d864741d3ee1279
281 2017-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)
282 2017-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
283 2017-01-11T18:25:48  * luke-jr wonders if this might be exploitable
284 2017-01-11T18:26:12  <profall> Resent
285 2017-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?
286 2017-01-11T18:33:46  <BlueMatt> gmaxwell: based on what you wrote in your pull, yes
287 2017-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.
288 2017-01-11T18:34:06  <BlueMatt> I'd need to go re-test to confirm, but I did test pre-merge
289 2017-01-11T18:34:11  <BlueMatt> yea
290 2017-01-11T18:34:37  <gmaxwell> (I just wanted to make sure if you needed any other features that I wrote them ASAP.)
291 2017-01-11T18:34:50  <BlueMatt> heh, yea, all good thanks
292 2017-01-11T18:35:03  <BlueMatt> in other news, I'm avoiding review because sick, and super pissed off about this :(
293 2017-01-11T18:39:39  <sipa> pissed about being sick?
294 2017-01-11T18:39:55  <BlueMatt> both - i have so much review to do :(
295 2017-01-11T18:40:02  *** Chris_Stewart_5 has quit IRC
296 2017-01-11T18:41:35  *** Chris_Stewart_5 has joined #bitcoin-core-dev
297 2017-01-11T18:47:15  <sipa> should -maxmempool=0 imply -blocksonly ?
298 2017-01-11T18:48:23  <gmaxwell> Probably, though blocksonly is still a hidden option.
299 2017-01-11T18:48:33  <sipa> ah, really
300 2017-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.
301 2017-01-11T18:48:55  <gmaxwell> probably thats too conservative, it's unlikely lots of nodes would run it.
302 2017-01-11T18:49:42  *** jtimon has quit IRC
303 2017-01-11T18:54:34  *** chjj has quit IRC
304 2017-01-11T18:56:14  *** jtimon has joined #bitcoin-core-dev
305 2017-01-11T19:02:25  <cfields> BlueMatt: heh, i'm very behind on review as well. slowly making my way through yours.
306 2017-01-11T19:02:30  *** owowo has quit IRC
307 2017-01-11T19:03:35  <sipa> likewise
308 2017-01-11T19:04:06  <instagibbs> Someone have the list of high-priority review on hand
309 2017-01-11T19:05:09  <sipa> i think we really want #9375 #9441 in
310 2017-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
311 2017-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
312 2017-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) ?
313 2017-01-11T19:06:18  <cfields> (i assume that question has been posed already)
314 2017-01-11T19:06:26  *** owowo has joined #bitcoin-core-dev
315 2017-01-11T19:06:26  *** owowo has joined #bitcoin-core-dev
316 2017-01-11T19:06:26  *** owowo has joined #bitcoin-core-dev
317 2017-01-11T19:07:07  <BlueMatt> cfields: if you announce a block which turns out to be invalid, WaitForValidation wont help :/
318 2017-01-11T19:07:11  <instagibbs> Ok, I really cant comment on the net locks overhaul but I'll re-review the former
319 2017-01-11T19:07:47  <cfields> BlueMatt: well presumably it'd drop out of the list, valid or no
320 2017-01-11T19:09:56  <cfields> BlueMatt: i suppose at an even higher level it could just be WaitForBestChainActivated()
321 2017-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
322 2017-01-11T19:11:52  <BlueMatt> ActivateBestChain literally is WaitForActivateBestChainActivated().....
323 2017-01-11T19:12:06  <BlueMatt> its just the version for when you're already holding cs_main
324 2017-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.
325 2017-01-11T19:14:27  <BlueMatt> "manipulated"?
326 2017-01-11T19:14:37  <BlueMatt> I mean I hope that its pretty much free if you're already on the best chain
327 2017-01-11T19:30:48  *** chjj has joined #bitcoin-core-dev
328 2017-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
329 2017-01-11T19:48:18  <sipa> ryanofsky: feel like having a look at https://github.com/sipa/bitcoin/commits/pertxoutcache ?
330 2017-01-11T19:48:40  <gmaxwell> I will be travling during the meeting tomorrow.
331 2017-01-11T19:57:04  *** Chris_Stewart_5 has quit IRC
332 2017-01-11T19:59:04  *** chjj has quit IRC
333 2017-01-11T20:02:13  *** chjj has joined #bitcoin-core-dev
334 2017-01-11T20:03:19  *** xinxi has quit IRC
335 2017-01-11T20:04:49  *** roidster has quit IRC
336 2017-01-11T20:05:06  *** atroxes has quit IRC
337 2017-01-11T20:05:34  *** atroxes has joined #bitcoin-core-dev
338 2017-01-11T20:11:28  *** atroxes has quit IRC
339 2017-01-11T20:12:25  *** Chris_Stewart_5 has joined #bitcoin-core-dev
340 2017-01-11T20:12:47  *** atroxes has joined #bitcoin-core-dev
341 2017-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
342 2017-01-11T20:15:08  <cfields> BlueMatt: trivial and unlikely, but still a side-effect :\
343 2017-01-11T20:16:09  <cfields> rather, the processor reads from disk.
344 2017-01-11T20:20:57  *** xinxi has joined #bitcoin-core-dev
345 2017-01-11T20:25:54  *** laurentmt has joined #bitcoin-core-dev
346 2017-01-11T20:26:06  <morcos> luke-jr: that was a replay, that tx was mined on 01-03
347 2017-01-11T20:27:02  *** xinxi has quit IRC
348 2017-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
349 2017-01-11T20:30:59  *** xinxi has joined #bitcoin-core-dev
350 2017-01-11T20:40:02  *** d9b4bef9 has quit IRC
351 2017-01-11T20:41:08  *** d9b4bef9 has joined #bitcoin-core-dev
352 2017-01-11T20:42:50  *** laurentmt has quit IRC
353 2017-01-11T20:48:24  *** xinxi_ has joined #bitcoin-core-dev
354 2017-01-11T20:51:28  *** xinxi has quit IRC
355 2017-01-11T20:52:11  *** adiabat has joined #bitcoin-core-dev
356 2017-01-11T20:53:23  *** ClockCat has joined #bitcoin-core-dev
357 2017-01-11T20:57:48  *** laurentmt has joined #bitcoin-core-dev
358 2017-01-11T20:58:58  *** laurentmt has quit IRC
359 2017-01-11T21:10:40  *** xinxi_ has quit IRC
360 2017-01-11T21:12:16  *** roidster has joined #bitcoin-core-dev
361 2017-01-11T21:23:47  *** roidster has quit IRC
362 2017-01-11T21:59:22  <bitcoin-git> [bitcoin] sipa pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/e2e624d9ce54...05950427d310
363 2017-01-11T21:59:22  <bitcoin-git> bitcoin/master fe7e593 Suhas Daftuar: Fix use-after-free in CTxMemPool::removeConflicts()
364 2017-01-11T21:59:23  <bitcoin-git> bitcoin/master 0595042 Pieter Wuille: Merge #9507: Fix use-after-free in CTxMemPool::removeConflicts()...
365 2017-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
366 2017-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
367 2017-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.
368 2017-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.
369 2017-01-11T22:12:36  <BlueMatt> yes, I did check for that when writing the code :p
370 2017-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
371 2017-01-11T22:13:32  <BlueMatt> but that is definitely not a 0.14 refactor
372 2017-01-11T22:13:49  <gmaxwell> great, but would I know to enforce that invariant if I were changing the code later?
373 2017-01-11T22:14:23  <cfields> ^^ what he said :)
374 2017-01-11T22:15:17  <BlueMatt> wait, which callback are you referring to?
375 2017-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?
376 2017-01-11T22:16:28  *** jtimon has quit IRC
377 2017-01-11T22:17:03  <cfields> ABS ?
378 2017-01-11T22:17:13  <BlueMatt> activatebestchain
379 2017-01-11T22:17:23  <BlueMatt> but the version that comes out when I've got a head-cold :p
380 2017-01-11T22:17:28  <cfields> ah, ActivateBeStchain :p
381 2017-01-11T22:17:33  <BlueMatt> yea, that
382 2017-01-11T22:18:09  <sipa> Next PR: "Correct ActivateBestChain to ActivateBestShain"
383 2017-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
384 2017-01-11T22:18:42  <BlueMatt> mmm, fair enough
385 2017-01-11T22:19:48  <cfields> sipa: heh. Blockshain all the things!
386 2017-01-11T22:21:10  <sipa> since 9 days ago, the memory usage of mapBlockIndex exceeded 100M
387 2017-01-11T22:22:00  <sipa> it's using 224 bytes per entry
388 2017-01-11T22:22:15  <sipa> some of which could be avoided
389 2017-01-11T22:22:31  <BlueMatt> yes, lets fix that
390 2017-01-11T22:22:40  <gmaxwell> not that much could be avoided though.
391 2017-01-11T22:22:59  <sipa> it's using 2 allocations per entry
392 2017-01-11T22:23:09  <sipa> (which are included in the 224 number)
393 2017-01-11T22:23:14  <BlueMatt> wait, it is?
394 2017-01-11T22:23:17  <sipa> it should be 0
395 2017-01-11T22:23:23  <BlueMatt> gmaxwell: like 20 bytes per entry last I checked
396 2017-01-11T22:23:53  <sipa> but at least 1 should be trivial to avoid
397 2017-01-11T22:24:16  <sipa> using a map<uint256, CBlockIndex> instead of map<uint256, CBlockIndex*>
398 2017-01-11T22:24:27  <gmaxwell> sipa: how can it be zero? the data structure grows and things keep around pointers to it? no.
399 2017-01-11T22:24:47  <sipa> gmaxwell: direct hashtable
400 2017-01-11T22:25:00  <sipa> and using map::iterators instead of CBlockIndex* all over the place
401 2017-01-11T22:25:24  <gmaxwell> okay, perhaps we don't actually keep any of the pointers.
402 2017-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
403 2017-01-11T22:25:54  <sipa> ... post 0.14
404 2017-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.
405 2017-01-11T22:26:49  <gmaxwell> even with all the overheads gone, it's a significant chunk of memory.
406 2017-01-11T22:27:19  <sipa> right
407 2017-01-11T22:27:51  *** kadoban has quit IRC
408 2017-01-11T22:28:01  *** kadoban has joined #bitcoin-core-dev
409 2017-01-11T22:28:10  <sipa> ideally we'd also split up the disk-storage part and the validity-related part
410 2017-01-11T22:28:20  <sipa> into two structures
411 2017-01-11T22:40:44  *** Guyver2 has quit IRC
412 2017-01-11T23:11:04  *** xinxi has joined #bitcoin-core-dev
413 2017-01-11T23:15:04  *** xinxi has quit IRC
414 2017-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
415 2017-01-11T23:32:41  *** cheese_ has joined #bitcoin-core-dev
416 2017-01-11T23:37:02  *** Guest3710 has quit IRC
417 2017-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
418 2017-01-11T23:41:10  *** Magma has quit IRC
419 2017-01-11T23:41:37  *** Magma has joined #bitcoin-core-dev
420 2017-01-11T23:48:34  *** Magma has quit IRC
421 2017-01-11T23:48:57  *** Magma has joined #bitcoin-core-dev
422 2017-01-11T23:56:08  <sipa> some review on #9261 plz?
423 2017-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