1 2017-01-11 00:35:41	0|bitcoin-git|[13bitcoin] 15theuni closed pull request #9509: build: fix qt distdir builds (06master...06out-of-tree-build) 02https://github.com/bitcoin/bitcoin/pull/9509
  2 2017-01-11 01:11:04	0|bitcoin-git|[13bitcoin] 15theuni opened pull request #9513: build: fix qt distdir builds (retry) (06master...06out-of-tree-build) 02https://github.com/bitcoin/bitcoin/pull/9513
  3 2017-01-11 01:40:05	0|bitcoin-git|[13bitcoin] 15theuni opened pull request #9514: release: Windows signing script (06master...06win-signing-script) 02https://github.com/bitcoin/bitcoin/pull/9514
  4 2017-01-11 07:17:10	0|jonasschnelli|cfields: is this meant to be public: https://github.com/bitcoin/bitcoin/pull/9514/files#diff-6373b8b56e3d0425bbd3b0bb32c48162?
  5 2017-01-11 07:24:41	0|paveljanik|jonasschnelli, it is a certificate only
  6 2017-01-11 07:24:45	0|paveljanik|no privkey
  7 2017-01-11 07:25:20	0|jonasschnelli|paveljanik: okay. Not familiar with windows code signing...
  8 2017-01-11 07:25:41	0|paveljanik|-me is not familiar with Windows at all ů=0
  9 2017-01-11 07:25:43	0|paveljanik|;-)
 10 2017-01-11 09:06:52	0|bitcoin-git|[13bitcoin] 15kallewoof opened pull request #9516: Bug-fix: listsinceblock: use max depth value for blocks in reorg'd chains (06master...06listsinceblock-reorg-fix) 02https://github.com/bitcoin/bitcoin/pull/9516
 11 2017-01-11 11:56:22	0|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
 12 2017-01-11 11:57:05	0|jtimon|NicolasDorier: regarding your vision for libconsensus, do you mind if I make some more questions here?
 13 2017-01-11 11:57:20	0|NicolasDorier|sure
 14 2017-01-11 11:57:31	0|NicolasDorier|I think trying the following
 15 2017-01-11 11:57:35	0|NicolasDorier|brand new project
 16 2017-01-11 11:57:41	0|NicolasDorier|copy/pasta of bitcoin core
 17 2017-01-11 11:57:53	0|NicolasDorier|then stripping everything not related to consensus
 18 2017-01-11 11:58:05	0|NicolasDorier|removing all dependencies to third party libs
 19 2017-01-11 11:58:29	0|jtimon|well, copy paste from core or doing it in core ignoring the rest is not that different is it?
 20 2017-01-11 11:59:17	0|NicolasDorier|I think it is harder
 21 2017-01-11 11:59:36	0|NicolasDorier|like there is so much reference to the utxo storage in the consensus code.
 22 2017-01-11 12:00:05	0|NicolasDorier|I would prefer being able to strip that
 23 2017-01-11 12:00:22	0|NicolasDorier|rather than trying to make interfaces
 24 2017-01-11 12:00:25	0|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
 25 2017-01-11 12:01:04	0|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
 26 2017-01-11 12:01:31	0|jtimon|but then the client needs to know which ones will be relevant before calling
 27 2017-01-11 12:01:55	0|NicolasDorier|yes, and but the client know that
 28 2017-01-11 12:01:58	0|jtimon|and will need to fetch them even if the tx/block was already invalid because of something trivial
 29 2017-01-11 12:01:59	0|NicolasDorier|since he has the block
 30 2017-01-11 12:02:23	0|NicolasDorier|correct. But the client can verify PoW before fetching
 31 2017-01-11 12:02:30	0|jtimon|sure, just comparing with the function pointer version of it, in both cases it will need to have the data
 32 2017-01-11 12:02:59	0|jtimon|another discussion was how the client gets that data
 33 2017-01-11 12:03:12	0|NicolasDorier|this would be the client's business
 34 2017-01-11 12:03:19	0|NicolasDorier|this is simple enough stuff to do
 35 2017-01-11 12:03:37	0|NicolasDorier|iffunction pointer
 36 2017-01-11 12:03:57	0|NicolasDorier|it is complicated to use, and
 37 2017-01-11 12:04:17	0|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
 38 2017-01-11 12:04:22	0|NicolasDorier|if the implementation cross boundary between languages, there is huge perf hit
 39 2017-01-11 12:05:03	0|NicolasDorier|I don't think this is the right approach. I think it is just easier to ask the client to fetch everything preventively
 40 2017-01-11 12:05:30	0|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)
 41 2017-01-11 12:05:49	0|jtimon|right, just comparing the different approaches
 42 2017-01-11 12:06:10	0|NicolasDorier|this also make it harder for us to break users of consensus
 43 2017-01-11 12:06:27	0|NicolasDorier|because we would make no assumption on how they deal with their storage
 44 2017-01-11 12:06:56	0|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
 45 2017-01-11 12:07:42	0|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
 46 2017-01-11 12:07:48	0|jtimon|right, that's an advantage for both the abstracted storage API or the abstracted storage by prefetching
 47 2017-01-11 12:08:40	0|jtimon|the people that don't like to abstract the storage (at least greg and pieter), are happy with libconsensus depending on levelDB
 48 2017-01-11 12:09:08	0|NicolasDorier|I don't think libconsensus should have any dependencies
 49 2017-01-11 12:09:22	0|NicolasDorier|it should be plain dumb lib like libsecpk)#*R#)*$
 50 2017-01-11 12:09:33	0|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
 51 2017-01-11 12:09:46	0|NicolasDorier|yes other things as well
 52 2017-01-11 12:09:57	0|NicolasDorier|like CheckContextual *
 53 2017-01-11 12:10:04	0|jtimon|well, I think at the very least it should have libsecp256k1 as a dependency, but I agree it shouldn
 54 2017-01-11 12:10:08	0|NicolasDorier|yes
 55 2017-01-11 12:10:11	0|jtimon|'t depend on levelDB
 56 2017-01-11 12:10:37	0|jtimon|just pointing out that other people disagree
 57 2017-01-11 12:11:09	0|NicolasDorier|yes
 58 2017-01-11 12:11:16	0|jtimon|so maybe you would expose checkblock and verifyBlock separately
 59 2017-01-11 12:11:39	0|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
 60 2017-01-11 12:11:40	0|jtimon|makes sense, I thought about it
 61 2017-01-11 12:12:24	0|jtimon|do you plan to expose lower level functions like say verifyHeader or verifyTx ?
 62 2017-01-11 12:13:12	0|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
 63 2017-01-11 12:13:17	0|jtimon|yeah, I think I will finish my vision on top of 0.14 and then see what happens
 64 2017-01-11 12:13:17	0|NicolasDorier|it would
 65 2017-01-11 12:13:22	0|NicolasDorier|it would not check policy rules
 66 2017-01-11 12:13:46	0|jtimon|I was kind of doing that for 0.12 but I decided I would wait for bip9 and segwit instead
 67 2017-01-11 12:13:49	0|NicolasDorier|I am tempted to still use my C# script validator for mempool stuff
 68 2017-01-11 12:14:08	0|NicolasDorier|not including verifyTx
 69 2017-01-11 12:14:58	0|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
 70 2017-01-11 12:15:33	0|jtimon|C# script validator? you don't use the verifyScript in current libconsensus ?
 71 2017-01-11 12:15:56	0|NicolasDorier|NBitcoin has its own script validator yes
 72 2017-01-11 12:16:23	0|jtimon|libbitcoin has his own validator as well, but optionally they allow you to use libconsensus instead
 73 2017-01-11 12:16:37	0|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
 74 2017-01-11 12:17:12	0|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
 75 2017-01-11 12:17:28	0|jtimon|is there any reason why you don't use libconsensus::verifyScript in nbitcoin ? do you plan to do it later?
 76 2017-01-11 12:17:36	0|NicolasDorier|you can use it
 77 2017-01-11 12:17:50	0|NicolasDorier|I do not by default because there is deployment headache
 78 2017-01-11 12:18:05	0|NicolasDorier|pure C# code just run everywhere
 79 2017-01-11 12:18:06	0|jtimon|oh, so then NBitcoin optionally depends on libconsensus, got it
 80 2017-01-11 12:18:10	0|NicolasDorier|yes
 81 2017-01-11 12:19:11	0|NicolasDorier|I will also add a mode where you setup a trusted node, and just do not verify the blocks.
 82 2017-01-11 12:19:56	0|jtimon|what about caches? what do you plan for caches? bip9 cache, sigcache?
 83 2017-01-11 12:20:21	0|jtimon|I mean, how do you plan to handle that with your libconsensus ?
 84 2017-01-11 12:20:46	0|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
 85 2017-01-11 12:20:57	0|NicolasDorier|so libconsensus will not depends on CBlockIndex
 86 2017-01-11 12:21:35	0|NicolasDorier|hopefully, I would like to make that into libconsensus eventually though
 87 2017-01-11 12:21:53	0|jtimon|he has to count the 95% in the last diff adjustment period manually?
 88 2017-01-11 12:21:55	0|NicolasDorier|for the other cache, I have not decided yet I dont know
 89 2017-01-11 12:22:08	0|NicolasDorier|yes
 90 2017-01-11 12:22:11	0|NicolasDorier|not perfect for sure
 91 2017-01-11 12:22:48	0|jtimon|I guess no approach is perfect, all have drawbacks and advantages
 92 2017-01-11 12:23:17	0|jtimon|I don't think I have any more questions, thank you!
 93 2017-01-11 12:23:27	0|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
 94 2017-01-11 12:23:41	0|jtimon|and btw, congrats on completing a full node alt implementation, not an easy task
 95 2017-01-11 12:24:06	0|NicolasDorier|thanks, still stuff to do though. But happy with the results so far :D
 96 2017-01-11 12:24:31	0|NicolasDorier|it is compatible with config file of Core, and has also rpc server
 97 2017-01-11 12:24:50	0|NicolasDorier|my goal is to reuse the test suite of bitcoin core
 98 2017-01-11 12:24:54	0|NicolasDorier|as is
 99 2017-01-11 12:25:01	0|NicolasDorier|to test my implementation
100 2017-01-11 12:25:09	0|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 )
101 2017-01-11 12:25:11	0|gribble|https://github.com/bitcoin/bitcoin/issues/8493 | Untested: libconsensus: Expose VerifyHeader by jtimon · Pull Request #8493 · bitcoin/bitcoin · GitHub
102 2017-01-11 12:25:26	0|NicolasDorier|yes I remember
103 2017-01-11 12:26:11	0|jtimon|reusing bitcoin core's test suite is very interesting
104 2017-01-11 12:45:56	0|bitcoin-git|13bitcoin/06master 1467ca130 15Cory Fields: build: fix for out-of-tree/distdir qt builds
105 2017-01-11 12:45:56	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/5754e0341b7c...bbf193fef049
106 2017-01-11 12:45:57	0|bitcoin-git|13bitcoin/06master 14bbf193f 15Wladimir J. van der Laan: Merge #9513: build: fix qt distdir builds (retry)...
107 2017-01-11 12:46:11	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #9513: build: fix qt distdir builds (retry) (06master...06out-of-tree-build) 02https://github.com/bitcoin/bitcoin/pull/9513
108 2017-01-11 12:52:36	0|bitcoin-git|13bitcoin/06master 1474994c6 15Pieter Wuille: Improve style w.r.t. if
109 2017-01-11 12:52:36	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/bbf193fef049...593a00ce1935
110 2017-01-11 12:52:37	0|bitcoin-git|13bitcoin/06master 14593a00c 15Wladimir J. van der Laan: Merge #9506: RFC: Improve style for if indentation...
111 2017-01-11 12:52:52	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #9506: RFC: Improve style for if indentation (06master...06newstyle) 02https://github.com/bitcoin/bitcoin/pull/9506
112 2017-01-11 12:56:37	0|bitcoin-git|13bitcoin/06master 148217bd1 15fanquake: [depends] libevent 2.1.7rc
113 2017-01-11 12:56:37	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/593a00ce1935...ca615e6c05ef
114 2017-01-11 12:56:38	0|bitcoin-git|13bitcoin/06master 14ca615e6 15Wladimir J. van der Laan: Merge #9471: [depends] libevent 2.1.7rc...
115 2017-01-11 12:56:52	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #9471: [depends] libevent 2.1.7rc (06master...06depends-0-14-0-libevent) 02https://github.com/bitcoin/bitcoin/pull/9471
116 2017-01-11 13:01:09	0|wumpus|are there any remaining issues with #9375?
117 2017-01-11 13:01:12	0|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
118 2017-01-11 13:08:09	0|instagibbs|same q for #9400
119 2017-01-11 13:08:12	0|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
120 2017-01-11 13:12:43	0|sipa|wumpus: i was planning to review 9375 today
121 2017-01-11 13:13:29	0|wumpus|sipa: okay, great
122 2017-01-11 13:26:35	0|bitcoin-git|[13bitcoin] 15laanwj pushed 3 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/ca615e6c05ef...e2e624d9ce54
123 2017-01-11 13:26:36	0|bitcoin-git|13bitcoin/06master 141fc4ec7 15mrbandrews: Add pruneblockchain RPC to enable manual block file pruning.
124 2017-01-11 13:26:36	0|bitcoin-git|13bitcoin/06master 14afffeea 15Russell Yanofsky: fixup! Add pruneblockchain RPC to enable manual block file pruning....
125 2017-01-11 13:26:37	0|bitcoin-git|13bitcoin/06master 14e2e624d 15Wladimir J. van der Laan: Merge #7871: Manual block file pruning....
126 2017-01-11 13:52:57	0|bitcoin-git|[13bitcoin] 15kallewoof opened pull request #9517: [refactor] Switched httpserver.cpp to use RAII wrapped libevents. (06master...06raii-httpserver) 02https://github.com/bitcoin/bitcoin/pull/9517
127 2017-01-11 14:23:30	0|sipa|i wonder why unique_ptr does not have an emplace method like the stl containers have
128 2017-01-11 14:23:42	0|sipa|would be a neat and cheap way to avoid explicit new calls
129 2017-01-11 14:39:18	0|jtimon|oh, I didn't know about contrib/devtools/check-doc.py
130 2017-01-11 17:20:27	0|cfields|sipa: see std::make_unique in c++14. I assume that's what you mean?
131 2017-01-11 17:23:03	0|gmaxwell|Lets upgreade to C++14! :P
132 2017-01-11 17:44:45	0|sipa|cfields: but x.emplace(a,b) still looks nicer than x = std::make_unique<x_t>(a,b);
133 2017-01-11 17:51:18	0|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
134 2017-01-11 18:06:13	0|profall|Anyone have a link to the latest blockchain torrent?
135 2017-01-11 18:06:36	0|sipa|profall: the blockchain torrent has been discontinued (at least by the bitcoin core maintainers) since 0.10
136 2017-01-11 18:06:43	0|profall|ah ok
137 2017-01-11 18:06:50	0|sipa|as the bitcoin block download code is usually faster
138 2017-01-11 18:07:02	0|sipa|(it validates while downloading)
139 2017-01-11 18:07:30	0|profall|yea
140 2017-01-11 18:07:51	0|profall|I am still experiencing issues with my node randomly dropping out of sync every few hours
141 2017-01-11 18:07:59	0|profall|I thought maybe a fresh resync might fix something, not sure.
142 2017-01-11 18:08:09	0|sipa|define 'dropping out of sync'
143 2017-01-11 18:09:01	0|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.
144 2017-01-11 18:09:37	0|profall|This is an E3 processor, 100mbps connection in a datacenter, 16GB ram server. Not resource starved.
145 2017-01-11 18:10:14	0|sipa|anything in debug.log?
146 2017-01-11 18:11:39	0|profall|ping timeout 1200s
147 2017-01-11 18:11:59	0|profall|socket recv error Connection reset by peer (104)
148 2017-01-11 18:12:06	0|sipa|that's normal
149 2017-01-11 18:12:13	0|sipa|what version?
150 2017-01-11 18:12:20	0|sipa|of bitcoin core
151 2017-01-11 18:12:23	0|gmaxwell|well it's not normal if it happens to all peers?
152 2017-01-11 18:12:39	0|profall|0.13.2 on Linux
153 2017-01-11 18:13:02	0|profall|I downloaded it straight from the website rather then use the repo, just in case as well.
154 2017-01-11 18:13:19	0|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.
155 2017-01-11 18:13:22	0|sipa|could you share a few hours worth of debug.log somewhere?
156 2017-01-11 18:14:40	0|profall|Sure, ill PM you just give me a few moments to prepare it.
157 2017-01-11 18:24:34	0|profall|PM'd both of you with debug.log
158 2017-01-11 18:25:01	0|profall|Oops, realized it's empty...
159 2017-01-11 18:25:44	0|luke-jr|morcos: c0507f800475edf003adb744061d864741d3ee12796834d4d7f9a72b0bbd4fe6 is the only one on your list that shows up in my debug.log
160 2017-01-11 18:25:45	0|luke-jr|2017-01-10 21:23:32 not keeping orphan with rejected parents c0507f800475edf003adb744061d864741d3ee1279
161 2017-01-11 18:25:47	0|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)
162 2017-01-11 18:25:49	0|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
163 2017-01-11 18:26:13	0|profall|Resent
164 2017-01-11 18:33:36	0|gmaxwell|BlueMatt: can you confirm that the new addnode behavior in master is sufficient to get rid of your fibre proxy thing?
165 2017-01-11 18:33:48	0|BlueMatt|gmaxwell: based on what you wrote in your pull, yes
166 2017-01-11 18:34:05	0|gmaxwell|okay, so if it does what it says on the tin you think its good to go.  fine with me.
167 2017-01-11 18:34:08	0|BlueMatt|I'd need to go re-test to confirm, but I did test pre-merge
168 2017-01-11 18:34:12	0|BlueMatt|yea
169 2017-01-11 18:34:39	0|gmaxwell|(I just wanted to make sure if you needed any other features that I wrote them ASAP.)
170 2017-01-11 18:34:51	0|BlueMatt|heh, yea, all good thanks
171 2017-01-11 18:35:04	0|BlueMatt|in other news, I'm avoiding review because sick, and super pissed off about this :(
172 2017-01-11 18:39:40	0|sipa|pissed about being sick?
173 2017-01-11 18:39:56	0|BlueMatt|both - i have so much review to do :(
174 2017-01-11 18:47:16	0|sipa|should -maxmempool=0 imply -blocksonly ?
175 2017-01-11 18:48:25	0|gmaxwell|Probably, though blocksonly is still a hidden option.
176 2017-01-11 18:48:34	0|sipa|ah, really
177 2017-01-11 18:48:44	0|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.
178 2017-01-11 18:48:56	0|gmaxwell|probably thats too conservative, it's unlikely lots of nodes would run it.
179 2017-01-11 19:02:26	0|cfields|BlueMatt: heh, i'm very behind on review as well. slowly making my way through yours.
180 2017-01-11 19:03:36	0|sipa|likewise
181 2017-01-11 19:04:08	0|instagibbs|Someone have the list of high-priority review on hand
182 2017-01-11 19:05:10	0|sipa|i think we really want #9375 #9441 in
183 2017-01-11 19:05:13	0|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
184 2017-01-11 19:05:16	0|gribble|https://github.com/bitcoin/bitcoin/issues/9441 | Net: Massive speedup. Net locks overhaul by theuni · Pull Request #9441 · bitcoin/bitcoin · GitHub
185 2017-01-11 19:06:05	0|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) ?
186 2017-01-11 19:06:20	0|cfields|(i assume that question has been posed already)
187 2017-01-11 19:07:08	0|BlueMatt|cfields: if you announce a block which turns out to be invalid, WaitForValidation wont help :/
188 2017-01-11 19:07:13	0|instagibbs|Ok, I really cant comment on the net locks overhaul but I'll re-review the former
189 2017-01-11 19:07:48	0|cfields|BlueMatt: well presumably it'd drop out of the list, valid or no
190 2017-01-11 19:09:58	0|cfields|BlueMatt: i suppose at an even higher level it could just be WaitForBestChainActivated()
191 2017-01-11 19:11:41	0|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
192 2017-01-11 19:11:53	0|BlueMatt|ActivateBestChain literally is WaitForActivateBestChainActivated().....
193 2017-01-11 19:12:07	0|BlueMatt|its just the version for when you're already holding cs_main
194 2017-01-11 19:14:15	0|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.
195 2017-01-11 19:14:28	0|BlueMatt|"manipulated"?
196 2017-01-11 19:14:38	0|BlueMatt|I mean I hope that its pretty much free if you're already on the best chain
197 2017-01-11 19:32:07	0|bitcoin-git|[13bitcoin] 15ryanofsky opened pull request #9518: Return height of last block pruned by pruneblockchain RPC (06master...06pr/prune-height) 02https://github.com/bitcoin/bitcoin/pull/9518
198 2017-01-11 19:48:19	0|sipa|ryanofsky: feel like having a look at https://github.com/sipa/bitcoin/commits/pertxoutcache ?
199 2017-01-11 19:48:41	0|gmaxwell|I will be travling during the meeting tomorrow.
200 2017-01-11 20:14:53	0|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
201 2017-01-11 20:15:09	0|cfields|BlueMatt: trivial and unlikely, but still a side-effect :\
202 2017-01-11 20:16:10	0|cfields|rather, the processor reads from disk.
203 2017-01-11 20:26:07	0|morcos|luke-jr: that was a replay, that tx was mined on 01-03
204 2017-01-11 20:28:07	0|bitcoin-git|[13bitcoin] 15morcos opened pull request #9519: Exclude RBF replacement txs from fee estimation (06master...06excludeRBF) 02https://github.com/bitcoin/bitcoin/pull/9519
205 2017-01-11 21:59:23	0|bitcoin-git|13bitcoin/06master 14fe7e593 15Suhas Daftuar: Fix use-after-free in CTxMemPool::removeConflicts()
206 2017-01-11 21:59:23	0|bitcoin-git|[13bitcoin] 15sipa pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/e2e624d9ce54...05950427d310
207 2017-01-11 21:59:24	0|bitcoin-git|13bitcoin/06master 140595042 15Pieter Wuille: Merge #9507: Fix use-after-free in CTxMemPool::removeConflicts()...
208 2017-01-11 21:59:56	0|bitcoin-git|[13bitcoin] 15sipa closed pull request #9507: Fix use-after-free in CTxMemPool::removeConflicts() (06master...06fix-mempool-useafterfree) 02https://github.com/bitcoin/bitcoin/pull/9507
209 2017-01-11 22:08:29	0|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
210 2017-01-11 22:09:51	0|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.
211 2017-01-11 22:12:03	0|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.
212 2017-01-11 22:12:37	0|BlueMatt|yes, I did check for that when writing the code :p
213 2017-01-11 22:13:25	0|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
214 2017-01-11 22:13:34	0|BlueMatt|but that is definitely not a 0.14 refactor
215 2017-01-11 22:13:50	0|gmaxwell|great, but would I know to enforce that invariant if I were changing the code later?
216 2017-01-11 22:14:24	0|cfields|^^ what he said :)
217 2017-01-11 22:15:18	0|BlueMatt|wait, which callback are you referring to?
218 2017-01-11 22:15:48	0|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?
219 2017-01-11 22:17:04	0|cfields|ABS ?
220 2017-01-11 22:17:15	0|BlueMatt|activatebestchain
221 2017-01-11 22:17:24	0|BlueMatt|but the version that comes out when I've got a head-cold :p
222 2017-01-11 22:17:30	0|cfields|ah, ActivateBeStchain :p
223 2017-01-11 22:17:35	0|BlueMatt|yea, that
224 2017-01-11 22:18:10	0|sipa|Next PR: "Correct ActivateBestChain to ActivateBestShain"
225 2017-01-11 22:18:26	0|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
226 2017-01-11 22:18:43	0|BlueMatt|mmm, fair enough
227 2017-01-11 22:19:49	0|cfields|sipa: heh. Blockshain all the things!
228 2017-01-11 22:21:12	0|sipa|since 9 days ago, the memory usage of mapBlockIndex exceeded 100M
229 2017-01-11 22:22:02	0|sipa|it's using 224 bytes per entry
230 2017-01-11 22:22:17	0|sipa|some of which could be avoided
231 2017-01-11 22:22:32	0|BlueMatt|yes, lets fix that
232 2017-01-11 22:22:42	0|gmaxwell|not that much could be avoided though.
233 2017-01-11 22:23:00	0|sipa|it's using 2 allocations per entry
234 2017-01-11 22:23:11	0|sipa|(which are included in the 224 number)
235 2017-01-11 22:23:15	0|BlueMatt|wait, it is?
236 2017-01-11 22:23:19	0|sipa|it should be 0
237 2017-01-11 22:23:24	0|BlueMatt|gmaxwell: like 20 bytes per entry last I checked
238 2017-01-11 22:23:54	0|sipa|but at least 1 should be trivial to avoid
239 2017-01-11 22:24:17	0|sipa|using a map<uint256, CBlockIndex> instead of map<uint256, CBlockIndex*>
240 2017-01-11 22:24:29	0|gmaxwell|sipa: how can it be zero? the data structure grows and things keep around pointers to it? no.
241 2017-01-11 22:24:48	0|sipa|gmaxwell: direct hashtable
242 2017-01-11 22:25:01	0|sipa|and using map::iterators instead of CBlockIndex* all over the place
243 2017-01-11 22:25:25	0|gmaxwell|okay, perhaps we don't actually keep any of the pointers.
244 2017-01-11 22:25:38	0|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
245 2017-01-11 22:25:56	0|sipa|... post 0.14
246 2017-01-11 22:26:15	0|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.
247 2017-01-11 22:26:51	0|gmaxwell|even with all the overheads gone, it's a significant chunk of memory.
248 2017-01-11 22:27:20	0|sipa|right
249 2017-01-11 22:28:11	0|sipa|ideally we'd also split up the disk-storage part and the validity-related part
250 2017-01-11 22:28:22	0|sipa|into two structures
251 2017-01-11 23:16:43	0|bitcoin-git|[13bitcoin] 15sipa closed pull request #8170: Remove lookup-tx-by-utxo functionality (06master...06betternotxindex) 02https://github.com/bitcoin/bitcoin/pull/8170
252 2017-01-11 23:37:13	0|bitcoin-git|[13bitcoin] 15sipa opened pull request #9520: Deprecate non-txindex getrawtransaction and better warning (06master...06warntxindex) 02https://github.com/bitcoin/bitcoin/pull/9520
253 2017-01-11 23:56:09	0|sipa|some review on #9261 plz?
254 2017-01-11 23:56:11	0|gribble|https://github.com/bitcoin/bitcoin/issues/9261 | Add unstored orphans with rejected parents to recentRejects by morcos · Pull Request #9261 · bitcoin/bitcoin · GitHub