1 2017-06-07 00:00:47	0|bitcoin-git|13bitcoin/06master 14656dbd8 15practicalswift: Perform member initialization in initialization lists where possible
  2 2017-06-07 00:00:47	0|bitcoin-git|[13bitcoin] 15sipa pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/75e898c094ee...be3e042c20e2
  3 2017-06-07 00:00:48	0|bitcoin-git|13bitcoin/06master 14be3e042 15Pieter Wuille: Merge #10523: Perform member initialization in initialization lists where possible...
  4 2017-06-07 00:01:22	0|bitcoin-git|[13bitcoin] 15sipa closed pull request #10523: Perform member initialization in initialization lists where possible (06master...06initialization-list) 02https://github.com/bitcoin/bitcoin/pull/10523
  5 2017-06-07 02:40:42	0|cfields|gitian builders: 0.14.2rc2 sigs are pushed
  6 2017-06-07 09:45:38	0|bitcoin-git|[13bitcoin] 15practicalswift opened pull request #10546: Remove unused Boost includes (06master...06remove-unused-boost-includes) 02https://github.com/bitcoin/bitcoin/pull/10546
  7 2017-06-07 10:27:52	0|wumpus|0.14.2rc2 executables up https://bitcoin.org/bin/bitcoin-core-0.14.2/test.rc2/
  8 2017-06-07 10:47:42	0|timothy|hi, do you think -bip148 option will be included in 0.14.2 final?
  9 2017-06-07 10:52:31	0|SopaXorzTaker|https://bitcointalk.org/index.php?topic=1955073.0
 10 2017-06-07 10:52:37	0|wumpus|timothy: no
 11 2017-06-07 10:53:07	0|timothy|wumpus: bad :P
 12 2017-06-07 10:53:09	0|wumpus|there's no agreement to add bip148 support to core at all, and adding a major feature like that between rcs doesn't happen
 13 2017-06-07 10:53:18	0|wumpus|yeah I know...
 14 2017-06-07 10:54:49	0|timothy|it's disabled by default and optional :P
 15 2017-06-07 10:56:47	0|wumpus|I'm sure there will be a bip148 variant of -final
 16 2017-06-07 10:57:19	0|wumpus|and you can always just cherry-pick the UASF commit on top while testing
 17 2017-06-07 10:58:09	0|timothy|the UASF commits, since luke-jr is working on DoS stuff
 18 2017-06-07 11:07:41	0|bitcoin-git|13bitcoin/060.14 147a64351 15Wladimir J. van der Laan: doc: Fill in details about miniupnp CVE-2017-8798
 19 2017-06-07 11:07:41	0|bitcoin-git|[13bitcoin] 15laanwj pushed 1 new commit to 060.14: 02https://github.com/bitcoin/bitcoin/commit/7a643511b474d53f952d3cd403af51aabd104044
 20 2017-06-07 11:08:05	0|wumpus|anything else that needs special notice in the 0.14.2 changelog?
 21 2017-06-07 11:13:18	0|wumpus|ref: https://github.com/bitcoin/bitcoin/blob/0.14/doc/release-notes.md
 22 2017-06-07 12:19:03	0|bitcoin-git|[13bitcoin] 15practicalswift opened pull request #10547: Use std::random::mt19937/uniform_int_distribution (C++11) instead of boost::random equivalents (06master...06remove-boost-random-dependency) 02https://github.com/bitcoin/bitcoin/pull/10547
 23 2017-06-07 12:27:19	0|gmaxwell|what why do we have any of that? grr scheduler.
 24 2017-06-07 12:27:35	0|wumpus|yea that should use our own fast random context
 25 2017-06-07 12:30:44	0|wumpus|though this allows for direct conversion of the code, I don't think there's much of a point as we use no fancy statistical distribution stuff at all
 26 2017-06-07 13:10:50	0|bitcoin-git|[13bitcoin] 15practicalswift opened pull request #10548: Use std::unordered_{map,set} (C++11) instead of boost::unordered_{map,set} (06master...06unordered_map) 02https://github.com/bitcoin/bitcoin/pull/10548
 27 2017-06-07 13:31:47	0|bitcoin-git|[13bitcoin] 15jnewbery closed pull request #10540: [WIP] Salvage wallet should not set the aggressive flag on Db::verify() (06master...06fixsalvage) 02https://github.com/bitcoin/bitcoin/pull/10540
 28 2017-06-07 13:32:11	0|bitcoin-git|[13bitcoin] 15laanwj pushed 9 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/be3e042c20e2...46311e792f4e
 29 2017-06-07 13:32:12	0|bitcoin-git|13bitcoin/06master 14578ec80 15Luke Dashjr: RPC: rawtransaction: Add RBF support for createrawtransaction
 30 2017-06-07 13:32:12	0|bitcoin-git|13bitcoin/06master 14891c5ee 15Luke Dashjr: Wallet: Refactor FundTransaction to accept parameters via CCoinControl
 31 2017-06-07 13:32:13	0|bitcoin-git|13bitcoin/06master 1436bcab2 15Luke Dashjr: RPC/Wallet: Add RBF support for fundrawtransaction
 32 2017-06-07 13:32:32	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #9672: Opt-into-RBF for RPC & bitcoin-tx (06master...06rpc_rbf) 02https://github.com/bitcoin/bitcoin/pull/9672
 33 2017-06-07 14:14:04	0|wumpus|any opinion on reverting https://github.com/bitcoin/bitcoin/pull/9672 ? seems to have been a bit of a mistake
 34 2017-06-07 14:24:29	0|jnewbery|no need to revert. I was just voicing surprise that it got merged without response to review comments or test cases for the new functionality in bitcoin-tx
 35 2017-06-07 14:26:14	0|wumpus|yes I agree
 36 2017-06-07 14:27:12	0|wumpus|anyhow can be added later I guess, and your comments should still be addressed
 37 2017-06-07 14:38:15	0|wumpus|let's wait for luke-jr's response
 38 2017-06-07 15:11:06	0|jonasschnelli|wumpus, jnewbery: Yes. I think 9672 is okay. No need to revert... if there is something, we can fix it up later. Some of the commits also have reviews/utACKs in other PRs.
 39 2017-06-07 15:16:23	0|wumpus|thanks for weighing in, maybe that's what confused me too
 40 2017-06-07 15:44:30	0|wumpus|checking for QT... no
 41 2017-06-07 15:44:30	0|wumpus|checking for QT... no
 42 2017-06-07 15:44:37	0|wumpus|strange, that appears double on freebsd at least
 43 2017-06-07 16:44:30	0|timothy|wumpus: me too (fedora 26)
 44 2017-06-07 16:45:01	0|wumpus|timothy: that's also a case in which QT is not detected?
 45 2017-06-07 16:45:51	0|timothy|qt4 and qt5
 46 2017-06-07 16:45:57	0|timothy|PKG_CHECK_MODULES([QT], [$qt5_modules], [QT_INCLUDES="$QT_CFLAGS"; have_qt=yes],[have_qt=no])
 47 2017-06-07 16:45:58	0|timothy|PKG_CHECK_MODULES([QT], [$qt4_modules], [QT_INCLUDES="$QT_CFLAGS"; have_qt=yes], [have_qt=no])
 48 2017-06-07 16:47:25	0|wumpus|oh, it makes sense then, if only the message was clear about that :)
 49 2017-06-07 16:47:41	0|timothy|yes, I'll propose a pull request to change QT with QT5 and QT4
 50 2017-06-07 16:54:48	0|bitcoin-git|[13bitcoin] 15drizzt opened pull request #10549: Avoid printing generic and duplicated "checking for QT" during ./configure (06master...06check_qt) 02https://github.com/bitcoin/bitcoin/pull/10549
 51 2017-06-07 16:55:13	0|timothy|wumpus: ^^
 52 2017-06-07 16:56:00	0|wumpus|timothy: thanks!
 53 2017-06-07 16:56:30	0|timothy|(un)likely I work often with autotools :P
 54 2017-06-07 16:59:39	0|morcos|sipa: i'm still reviewing #10195, but i think i have one issue.  if you agree, i can fix it after i finish review if you want, or you can.
 55 2017-06-07 16:59:45	0|gribble|https://github.com/bitcoin/bitcoin/issues/10195 | Switch chainstate db and cache to per-txout model by sipa · Pull Request #10195 · bitcoin/bitcoin · GitHub
 56 2017-06-07 17:00:20	0|morcos|in ATMP, it seems like it will be too slow to do HaveCoins for every outpoint of a new tx, in the common case, that's hitting disk for every outpoint of every new tx
 57 2017-06-07 17:01:32	0|morcos|we can probably ditch that whole block of code altogether, and rely on AlreadyHave which is called just before ATMP in net_processing, or if we need to because of other places ATMP is called, we can duplicate the idea of just checking 1 or 2 outputs that AlreadyHave uses
 58 2017-06-07 17:02:28	0|sipa|or change it to HaveCoinInCache?
 59 2017-06-07 17:02:44	0|sipa|ah no, nvm
 60 2017-06-07 17:21:00	0|bitcoin-git|[13bitcoin] 15pavlosantoniou closed pull request #10530: Fix possibly unsafe accesses of array in class base_uint<BITS> (06master...06master) 02https://github.com/bitcoin/bitcoin/pull/10530
 61 2017-06-07 17:23:47	0|bitcoin-git|[13bitcoin] 15pavlosantoniou reopened pull request #10530: Fix possibly unsafe accesses of array in class base_uint<BITS> (06master...06master) 02https://github.com/bitcoin/bitcoin/pull/10530
 62 2017-06-07 18:04:58	0|luke-jr|wumpus: BIP148 is a softfork. We typically consider those bugfixes and only added on minor bumps..
 63 2017-06-07 18:05:35	0|luke-jr|[10:58:08] <timothy> the UASF commits, since luke-jr is working on DoS stuff <-- for now, it may be safer to omit some of the DoS stuff; that's additional on top of BIP148 (not necessary), and has less review so far
 64 2017-06-07 18:07:49	0|luke-jr|wumpus: I don't see the point in reverting unless there's an actual problem.
 65 2017-06-07 18:15:56	0|jtimon|if you are included in https://en.bitcoin.it/wiki/Segwit_support please check that your position is not misrepresented (mine was by mistake)
 66 2017-06-07 18:18:36	0|sipa|luke-jr: i don't "want" BIP148. I want segwit, as I think it's necessary for Bitcoin's future. BIP148 is a overly risky means of obtaining that. That does not mean I oppose it if there were tremendous support, but on itself I think it's a bad idea
 67 2017-06-07 18:19:45	0|sipa|i'm going to delete my line from that table - i don't think it can represent nuanced opinions
 68 2017-06-07 18:20:24	0|jcorgan|i think the "wanting" terminology is confusing
 69 2017-06-07 18:20:36	0|jcorgan|as is the "deficient"
 70 2017-06-07 18:21:05	0|jcorgan|sipa: "wanting" means you like it but think community support is lacking
 71 2017-06-07 18:21:16	0|sipa|i don't like it
 72 2017-06-07 18:21:24	0|jcorgan|that is not how I would take it at first read, and clearly not how you feel
 73 2017-06-07 18:21:27	0|sipa|i would be happy if it worked, but i don't believe it can
 74 2017-06-07 18:22:16	0|jcorgan|i suggest you keep yourself there but just keep the prefer 141 and the rest empty
 75 2017-06-07 18:23:49	0|BlueMatt|luke-jr: "We typically consider [soft forks] bugfixes and only added on minor bumps.." <-- NO, WE DO NOT
 76 2017-06-07 18:24:09	0|luke-jr|BlueMatt: lolwut? even Segwit was added on a minor bump
 77 2017-06-07 18:24:18	0|BlueMatt|we consider them CONSENSUS CHANGES, and release them in minor version so as to avoid forcing anyone to upgrade to a soft fork for other major-version features they want
 78 2017-06-07 18:24:38	0|BlueMatt|just because it was a minor version number does not mean its a "minor bump"
 79 2017-06-07 18:27:03	0|BlueMatt|if anything, the fact that we release them in minor versions indicates how seriously we take them, not the inverse - they are the only thing in that release (+/-) and get an entire release cycle dedicated just to them
 80 2017-06-07 18:28:37	0|jtimon|who is proposing to change that (ie enabling activation of consensus changes only on minor versions)?
 81 2017-06-07 18:29:07	0|BlueMatt|jtimon: I dont think anyone, I just found luke's comments laughably insulting to the effort that goes into consensus changes
 82 2017-06-07 18:29:22	0|sipa|luke-jr: i think the point is that yes softforks can be merged in minor release, but no that does not mean that any softfork will be merged
 83 2017-06-07 18:29:45	0|wumpus|never between rcs though
 84 2017-06-07 18:30:12	0|BlueMatt|lol @ merge consensus changes between rcs
 85 2017-06-07 18:30:15	0|BlueMatt|actually lol
 86 2017-06-07 18:30:17	0|jtimon|oh, I see, luke wants bip148 for 14.2 ?
 87 2017-06-07 18:30:52	0|luke-jr|wumpus: point taken
 88 2017-06-07 18:31:16	0|luke-jr|jtimon: that would be ideal, but wumpus makes a good point that it's too late for 0.14.2
 89 2017-06-07 18:32:41	0|jtimon|yeah I assumed that was clear. I'm unconvinced a variation of bip149 cannot be merged before mov15 though, so maybe it could make it to 0.14.3
 90 2017-06-07 18:34:11	0|luke-jr|[18:29:06] <BlueMatt> jtimon: I dont think anyone, I just found luke's comments laughably insulting to the effort that goes into consensus changes <-- effort goes into traditional bugfixes as well. "bugfix" does not make any implication of effort.
 91 2017-06-07 18:34:31	0|jtimon|yeah I read that
 92 2017-06-07 18:34:46	0|jtimon|oh, sorry
 93 2017-06-07 18:35:21	0|BlueMatt|luke-jr: well then let me rephrase, consensus changes are *not* bugfixes....they could be if there was an actual bug, but so far we havent seen one (and, no, "segwit hasnt happened" is not a bug...)
 94 2017-06-07 18:35:55	0|BlueMatt|more recent consensus changes have been 6+ month review and tweak cycles, even for simple things
 95 2017-06-07 18:36:18	0|luke-jr|BlueMatt: being vulnerable to miners producing a long chain of invalid blocks, is the bug fixed by (any) softforks
 96 2017-06-07 18:36:57	0|luke-jr|but call it what you like, it's beside the point
 97 2017-06-07 18:37:16	0|BlueMatt|no, you're missing the point, this is consensus, not a fucking joke
 98 2017-06-07 18:37:25	0|luke-jr|bugs aren't a joke
 99 2017-06-07 18:38:17	0|BlueMatt|you appear to be dead-set on taking it as one
100 2017-06-07 18:38:41	0|sipa|luke-jr: i don't think you can consider not implementing an new and backward-compatible consensus change a bug
101 2017-06-07 18:38:57	0|sipa|luke-jr: i wouldn't call 0.13.0 buggy when segwit actives; at best, it is outdated
102 2017-06-07 18:39:21	0|sipa|the whole point of softforks is that nobody is required to adopt the rule
103 2017-06-07 18:39:46	0|luke-jr|to retain full node security, you need to adopt the rule
104 2017-06-07 18:40:04	0|BlueMatt|the idea that its a "bug" (or even an issue) for a user to *not* "upgrade" to enforce a soft fork is laughable...if that were the case, Bitcoin would pretty clearly have no long-term value
105 2017-06-07 18:40:09	0|sipa|luke-jr: what? no
106 2017-06-07 18:40:14	0|BlueMatt|"oops, miners are enforcing redlisting, you need to upgrade"
107 2017-06-07 18:40:51	0|luke-jr|BlueMatt: false equivalency is not helping
108 2017-06-07 18:41:11	0|sipa|how is that a false equivalency?
109 2017-06-07 18:41:17	0|BlueMatt|luke-jr: I absolutely do not believe it is false equivalency, actually. We're talking about what precedent is being set for Bitcoin's future and how changes are made in Bitcoin
110 2017-06-07 18:41:43	0|morcos|Can we talk about when we're upgrading to C++17 instead?
111 2017-06-07 18:41:48	0|BlueMatt|ACK
112 2017-06-07 18:41:56	0|BlueMatt|is filesystem in 17?
113 2017-06-07 18:41:58	0|BlueMatt|or is that 15?
114 2017-06-07 18:42:06	0|BlueMatt|14
115 2017-06-07 18:42:12	0|luke-jr|hopefully compilers support it sooner than C++11
116 2017-06-07 18:42:19	0|BlueMatt|sipa: wait, thats not 11?
117 2017-06-07 18:42:25	0|sipa|BlueMatt: no, c++14
118 2017-06-07 18:42:30	0|BlueMatt|ohoh, the ms postfix, yea
119 2017-06-07 18:43:07	0|sipa|still no concepts :(
120 2017-06-07 18:43:13	0|sipa|not even in 17
121 2017-06-07 18:47:12	0|wumpus|we supported c++11 in.. 2016, so extrapolating that, c++17 will be usable in 2022
122 2017-06-07 18:47:33	0|luke-jr|:/
123 2017-06-07 18:47:51	0|wumpus|don't shoot me, I'm just the messenger :)
124 2017-06-07 18:50:04	0|sipa|c++11 took much longer to be actually available in compilers
125 2017-06-07 18:50:11	0|sipa|c++14 is already default in gcc 6
126 2017-06-07 18:50:35	0|sipa|the changes in 14 and 17 are also much smaller than the c++03-c++11 changes
127 2017-06-07 18:50:46	0|wumpus|std::optional is pretty nice
128 2017-06-07 18:51:07	0|luke-jr|how long until GCC 6 is on major distros?
129 2017-06-07 18:51:20	0|luke-jr|Gentoo just got GCC 5 like a month ago
130 2017-06-07 18:51:39	0|BlueMatt|debian? 2025?
131 2017-06-07 18:51:47	0|jtimon|sure, ack on moving to c++14, what do we need to do?
132 2017-06-07 18:52:01	0|sipa|i think GCC 5 fully supports c++14
133 2017-06-07 18:52:17	0|BlueMatt|oh, thats a lie, wow, next debian is gcc 6
134 2017-06-07 18:52:40	0|luke-jr|RHEL tends to be the slowest these days
135 2017-06-07 18:52:42	0|sipa|and c++17... doesn't exist yet
136 2017-06-07 18:52:45	0|luke-jr|from what I've seen
137 2017-06-07 18:52:59	0|wumpus|std::string_view is very useful too
138 2017-06-07 18:53:00	0|luke-jr|lo, was morcos just trolling
139 2017-06-07 18:54:07	0|BlueMatt|morcos' xkcd 356 is good
140 2017-06-07 18:54:24	0|wumpus|recent versions of clang already support a lot of c++17 features, even though it doesn't officially exist yet
141 2017-06-07 18:54:44	0|sipa|Clang finished support for C++14 in 3.4 though under the standard name c++1y.[23] GCC finished support for C++14 in GCC 5, and made C++14 the default C++ standard in GCC 6.[24] Microsoft Visual Studio 2015 has support for some but not all C++14 features.[25]
142 2017-06-07 18:55:05	0|jtimon|luke-jr: does it matter? the important part is that if we don't move to c++14 coon some people may start moving to ripple, they had c++14 almost from launch </bad joke>
143 2017-06-07 18:55:16	0|sipa|hahaha
144 2017-06-07 18:55:51	0|jtimon|s/coon/soon
145 2017-06-07 18:55:56	0|wumpus|bitcoin core compiles almost entirely without changes in c++17 mode, btw
146 2017-06-07 18:56:14	0|luke-jr|wumpus: that's a nice start at least
147 2017-06-07 18:56:16	0|wumpus|there were some minor things last time I tried
148 2017-06-07 18:56:33	0|jtimon|wumpus: awesome, what are the almost no changes?
149 2017-06-07 18:56:41	0|wumpus|but those might be clang-weirdnesses as well
150 2017-06-07 18:57:03	0|wumpus|should be in my cloudabi branch, let me see
151 2017-06-07 18:58:08	0|wumpus|jtimon: https://github.com/laanwj/bitcoin/commit/efeec33d19752de7480f1e8d0fbcd79e49548910
152 2017-06-07 18:59:27	0|BlueMatt|god I keep finding things and being like "wait, didnt I change that???" only to realize its in a queued-next PR based on one still pending :(
153 2017-06-07 19:00:14	0|sipa|BlueMatt: what do you do with the mutable fields?
154 2017-06-07 19:00:25	0|sipa|(nChainTx, nStatus, nFile, ...)
155 2017-06-07 19:00:27	0|BlueMatt|sipa: ehh, sorry, const outside of validation.cpp
156 2017-06-07 19:00:37	0|sipa|ah!
157 2017-06-07 19:00:38	0|sipa|yes!
158 2017-06-07 19:00:44	0|BlueMatt|ie exposed versions in headers are all const, and mapBlockIndex is const too
159 2017-06-07 19:01:03	0|BlueMatt|sipa: its the next one queued after #10279
160 2017-06-07 19:01:07	0|gribble|https://github.com/bitcoin/bitcoin/issues/10279 | Add a CChainState class to validation.cpp to take another step towards clarifying internal interfaces by TheBlueMatt · Pull Request #10279 · bitcoin/bitcoin · GitHub
161 2017-06-07 19:16:38	0|achow101|wumpus: did you change your gitian key?
162 2017-06-07 19:16:50	0|achow101|or sign with the wrong one?
163 2017-06-07 19:18:26	0|wumpus|I've added a signing subkey
164 2017-06-07 19:18:34	0|wumpus|it's the same I use for signing commits
165 2017-06-07 19:20:04	0|jtimon|wumpus: yeah, that's a very small diff
166 2017-06-07 19:20:32	0|achow101|wumpus: ah, ok. Apparently I don't have that key
167 2017-06-07 19:21:19	0|jtimon|BlueMatt: been there
168 2017-06-07 19:24:10	0|wumpus|achow101: --refresh-keys should get it AFAIK
169 2017-06-07 19:24:52	0|BlueMatt|jtimon: ehh, its normal 'round here, review is hard
170 2017-06-07 19:25:26	0|jtimon|yep, and time consuming
171 2017-06-07 19:25:39	0|BlueMatt|with good reason
172 2017-06-07 19:25:49	0|jtimon|not saying otherwise
173 2017-06-07 19:36:00	0|bitcoin-git|[13bitcoin] 15achow101 opened pull request #10551: [Tests] Wallet encryption functional tests (06master...06wallet-encrypt-test) 02https://github.com/bitcoin/bitcoin/pull/10551
174 2017-06-07 19:40:43	0|luke-jr|btcdrak: are you planning to do a 0.14 addrindex?
175 2017-06-07 19:44:25	0|jtimon|yeah, I'm interested in knowing that too
176 2017-06-07 19:44:39	0|sipa|:(
177 2017-06-07 19:44:58	0|BlueMatt|:) ?
178 2017-06-07 19:45:07	0|jtimon|for an explorer
179 2017-06-07 19:46:03	0|sipa|i wish people wouldn't build solutions that require a fully indexed unpruned blockchain
180 2017-06-07 19:47:01	0|jtimon|sipa: although honestly like it as I have it with only blockheight, blockhash and txid for searching
181 2017-06-07 19:47:25	0|luke-jr|sipa: I agree, but a 0.14 addrindex will be less annoying than supporting 0.13 longer than necessary XD
182 2017-06-07 20:02:14	0|BlueMatt|sipa: is deserializing bandb/addrdb any more expensive than any other deserialization?
183 2017-06-07 20:02:20	0|BlueMatt|its vector operations, mostly, just like the rest, no?
184 2017-06-07 20:02:35	0|BlueMatt|re: 10248: so I dont see why it matters
185 2017-06-07 20:10:32	0|sipa|BlueMatt: code simplification
186 2017-06-07 20:10:47	0|BlueMatt|hmm? no, i mean i like 10248
187 2017-06-07 20:11:02	0|BlueMatt|and dont think the removal of the ability to skip deserialize on hash mismatch is worth worrying about
188 2017-06-07 20:12:58	0|sipa|oh, i agree
189 2017-06-07 20:14:23	0|wumpus|yes it doesn't really matter in this case, the hash is not a MAC and it's unlikely the bandb/addrdb will be used as an attack vector in any case
190 2017-06-07 20:14:30	0|wumpus|so 10248 is fine
191 2017-06-07 20:14:43	0|BlueMatt|if you can modify my bandb........
192 2017-06-07 20:14:53	0|BlueMatt|something something wallet in same folder
193 2017-06-07 20:15:00	0|wumpus|you can also change the hash, sure
194 2017-06-07 20:16:49	0|wumpus|the checksum is there against accidental corruption, and checking the hash on the fly is just as good for that
195 2017-06-07 20:16:57	0|sipa|i'd change your bitcoind :p
196 2017-06-07 20:18:15	0|wumpus|and if there is any way for a corruption to *crash* the deserialization I guess there's worse problems
197 2017-06-07 20:52:21	0|ryanofsky|should it be necessary to lock mempool.cs before calling atmp? is this lock needed: https://github.com/bitcoin/bitcoin/blob/master/src/wallet/wallet.cpp#L1546
198 2017-06-07 21:04:53	0|bitcoin-git|[13bitcoin] 15jtimon closed pull request #10427: Consensus: Introduce static GetScriptFlags (mostly MOVEONLY) (06master...06b15-consensus-script-flags-min) 02https://github.com/bitcoin/bitcoin/pull/10427
199 2017-06-07 21:59:44	0|BlueMatt|ryanofsky: probably not?
200 2017-06-07 22:04:01	0|ryanofsky|ok, thx for sanity check
201 2017-06-07 22:12:44	0|bitcoin-git|[13bitcoin] 15sipa pushed 11 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/46311e792f4e...e801084decf4
202 2017-06-07 22:12:45	0|bitcoin-git|13bitcoin/06master 1437e864e 15Pieter Wuille: Add FastRandomContext::rand256() and ::randbytes()...
203 2017-06-07 22:12:45	0|bitcoin-git|13bitcoin/06master 1490620d6 15Pieter Wuille: scripted-diff: Rename cuckoo tests' local rand context...
204 2017-06-07 22:12:46	0|bitcoin-git|13bitcoin/06master 14124d13a 15Pieter Wuille: Merge test_random.h into test_bitcoin.h
205 2017-06-07 22:13:05	0|bitcoin-git|[13bitcoin] 15sipa closed pull request #10321: Use FastRandomContext for all tests (06master...06fast_rand_tests) 02https://github.com/bitcoin/bitcoin/pull/10321
206 2017-06-07 22:31:43	0|jtimon|btw, I got #9717 out of #10339 as requested
207 2017-06-07 22:31:44	0|gribble|https://github.com/bitcoin/bitcoin/issues/9717 | Pow: Remove fCheckPOW from CheckBlockHeader by jtimon · Pull Request #9717 · bitcoin/bitcoin · GitHub
208 2017-06-07 22:31:45	0|gribble|https://github.com/bitcoin/bitcoin/issues/10339 | Optimization: Calculate block hash less times by jtimon · Pull Request #10339 · bitcoin/bitcoin · GitHub