< bitcoin-git> [bitcoin] sipa pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/75e898c094ee...be3e042c20e2
< bitcoin-git> bitcoin/master 656dbd8 practicalswift: Perform member initialization in initialization lists where possible
< bitcoin-git> bitcoin/master be3e042 Pieter Wuille: Merge #10523: Perform member initialization in initialization lists where possible...
< bitcoin-git> [bitcoin] sipa closed pull request #10523: Perform member initialization in initialization lists where possible (master...initialization-list) https://github.com/bitcoin/bitcoin/pull/10523
< cfields> gitian builders: 0.14.2rc2 sigs are pushed
< bitcoin-git> [bitcoin] practicalswift opened pull request #10546: Remove unused Boost includes (master...remove-unused-boost-includes) https://github.com/bitcoin/bitcoin/pull/10546
< timothy> hi, do you think -bip148 option will be included in 0.14.2 final?
< wumpus> timothy: no
< timothy> wumpus: bad :P
< 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
< wumpus> yeah I know...
< timothy> it's disabled by default and optional :P
< wumpus> I'm sure there will be a bip148 variant of -final
< wumpus> and you can always just cherry-pick the UASF commit on top while testing
< timothy> the UASF commits, since luke-jr is working on DoS stuff
< bitcoin-git> [bitcoin] laanwj pushed 1 new commit to 0.14: https://github.com/bitcoin/bitcoin/commit/7a643511b474d53f952d3cd403af51aabd104044
< bitcoin-git> bitcoin/0.14 7a64351 Wladimir J. van der Laan: doc: Fill in details about miniupnp CVE-2017-8798
< wumpus> anything else that needs special notice in the 0.14.2 changelog?
< bitcoin-git> [bitcoin] practicalswift opened pull request #10547: Use std::random::mt19937/uniform_int_distribution (C++11) instead of boost::random equivalents (master...remove-boost-random-dependency) https://github.com/bitcoin/bitcoin/pull/10547
< gmaxwell> what why do we have any of that? grr scheduler.
< wumpus> yea that should use our own fast random context
< 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
< bitcoin-git> [bitcoin] practicalswift opened pull request #10548: Use std::unordered_{map,set} (C++11) instead of boost::unordered_{map,set} (master...unordered_map) https://github.com/bitcoin/bitcoin/pull/10548
< bitcoin-git> [bitcoin] jnewbery closed pull request #10540: [WIP] Salvage wallet should not set the aggressive flag on Db::verify() (master...fixsalvage) https://github.com/bitcoin/bitcoin/pull/10540
< bitcoin-git> [bitcoin] laanwj pushed 9 new commits to master: https://github.com/bitcoin/bitcoin/compare/be3e042c20e2...46311e792f4e
< bitcoin-git> bitcoin/master 578ec80 Luke Dashjr: RPC: rawtransaction: Add RBF support for createrawtransaction
< bitcoin-git> bitcoin/master 891c5ee Luke Dashjr: Wallet: Refactor FundTransaction to accept parameters via CCoinControl
< bitcoin-git> bitcoin/master 36bcab2 Luke Dashjr: RPC/Wallet: Add RBF support for fundrawtransaction
< bitcoin-git> [bitcoin] laanwj closed pull request #9672: Opt-into-RBF for RPC & bitcoin-tx (master...rpc_rbf) https://github.com/bitcoin/bitcoin/pull/9672
< wumpus> any opinion on reverting https://github.com/bitcoin/bitcoin/pull/9672 ? seems to have been a bit of a mistake
< 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
< wumpus> yes I agree
< wumpus> anyhow can be added later I guess, and your comments should still be addressed
< wumpus> let's wait for luke-jr's response
< 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.
< wumpus> thanks for weighing in, maybe that's what confused me too
< wumpus> checking for QT... no
< wumpus> checking for QT... no
< wumpus> strange, that appears double on freebsd at least
< timothy> wumpus: me too (fedora 26)
< wumpus> timothy: that's also a case in which QT is not detected?
< timothy> qt4 and qt5
< timothy> PKG_CHECK_MODULES([QT], [$qt5_modules], [QT_INCLUDES="$QT_CFLAGS"; have_qt=yes],[have_qt=no])
< timothy> PKG_CHECK_MODULES([QT], [$qt4_modules], [QT_INCLUDES="$QT_CFLAGS"; have_qt=yes], [have_qt=no])
< wumpus> oh, it makes sense then, if only the message was clear about that :)
< timothy> yes, I'll propose a pull request to change QT with QT5 and QT4
< bitcoin-git> [bitcoin] drizzt opened pull request #10549: Avoid printing generic and duplicated "checking for QT" during ./configure (master...check_qt) https://github.com/bitcoin/bitcoin/pull/10549
< timothy> wumpus: ^^
< wumpus> timothy: thanks!
< timothy> (un)likely I work often with autotools :P
< 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.
< 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
< 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
< 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
< sipa> or change it to HaveCoinInCache?
< sipa> ah no, nvm
< bitcoin-git> [bitcoin] pavlosantoniou closed pull request #10530: Fix possibly unsafe accesses of array in class base_uint<BITS> (master...master) https://github.com/bitcoin/bitcoin/pull/10530
< bitcoin-git> [bitcoin] pavlosantoniou reopened pull request #10530: Fix possibly unsafe accesses of array in class base_uint<BITS> (master...master) https://github.com/bitcoin/bitcoin/pull/10530
< luke-jr> wumpus: BIP148 is a softfork. We typically consider those bugfixes and only added on minor bumps..
< 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
< luke-jr> wumpus: I don't see the point in reverting unless there's an actual problem.
< 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)
< 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
< sipa> i'm going to delete my line from that table - i don't think it can represent nuanced opinions
< jcorgan> i think the "wanting" terminology is confusing
< jcorgan> as is the "deficient"
< jcorgan> sipa: "wanting" means you like it but think community support is lacking
< sipa> i don't like it
< jcorgan> that is not how I would take it at first read, and clearly not how you feel
< sipa> i would be happy if it worked, but i don't believe it can
< jcorgan> i suggest you keep yourself there but just keep the prefer 141 and the rest empty
< BlueMatt> luke-jr: "We typically consider [soft forks] bugfixes and only added on minor bumps.." <-- NO, WE DO NOT
< luke-jr> BlueMatt: lolwut? even Segwit was added on a minor bump
< 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
< BlueMatt> just because it was a minor version number does not mean its a "minor bump"
< 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
< jtimon> who is proposing to change that (ie enabling activation of consensus changes only on minor versions)?
< BlueMatt> jtimon: I dont think anyone, I just found luke's comments laughably insulting to the effort that goes into consensus changes
< 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
< wumpus> never between rcs though
< BlueMatt> lol @ merge consensus changes between rcs
< BlueMatt> actually lol
< jtimon> oh, I see, luke wants bip148 for 14.2 ?
< luke-jr> wumpus: point taken
< luke-jr> jtimon: that would be ideal, but wumpus makes a good point that it's too late for 0.14.2
< 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
< 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.
< jtimon> yeah I read that
< jtimon> oh, sorry
< 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...)
< BlueMatt> more recent consensus changes have been 6+ month review and tweak cycles, even for simple things
< luke-jr> BlueMatt: being vulnerable to miners producing a long chain of invalid blocks, is the bug fixed by (any) softforks
< * BlueMatt> proposes redlisting soft fork again, clearly its a bugfix so must be merged *now*
< luke-jr> but call it what you like, it's beside the point
< BlueMatt> no, you're missing the point, this is consensus, not a fucking joke
< luke-jr> bugs aren't a joke
< BlueMatt> you appear to be dead-set on taking it as one
< sipa> luke-jr: i don't think you can consider not implementing an new and backward-compatible consensus change a bug
< sipa> luke-jr: i wouldn't call 0.13.0 buggy when segwit actives; at best, it is outdated
< sipa> the whole point of softforks is that nobody is required to adopt the rule
< luke-jr> to retain full node security, you need to adopt the rule
< 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
< sipa> luke-jr: what? no
< BlueMatt> "oops, miners are enforcing redlisting, you need to upgrade"
< luke-jr> BlueMatt: false equivalency is not helping
< sipa> how is that a false equivalency?
< 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
< morcos> Can we talk about when we're upgrading to C++17 instead?
< BlueMatt> ACK
< BlueMatt> is filesystem in 17?
< BlueMatt> or is that 15?
< BlueMatt> 14
< * sipa> wants std::this_thread::sleep(10ms);
< luke-jr> hopefully compilers support it sooner than C++11
< BlueMatt> sipa: wait, thats not 11?
< sipa> BlueMatt: no, c++14
< BlueMatt> ohoh, the ms postfix, yea
< sipa> still no concepts :(
< sipa> not even in 17
< wumpus> we supported c++11 in.. 2016, so extrapolating that, c++17 will be usable in 2022
< luke-jr> :/
< wumpus> don't shoot me, I'm just the messenger :)
< sipa> c++11 took much longer to be actually available in compilers
< sipa> c++14 is already default in gcc 6
< sipa> the changes in 14 and 17 are also much smaller than the c++03-c++11 changes
< wumpus> std::optional is pretty nice
< luke-jr> how long until GCC 6 is on major distros?
< luke-jr> Gentoo just got GCC 5 like a month ago
< BlueMatt> debian? 2025?
< jtimon> sure, ack on moving to c++14, what do we need to do?
< sipa> i think GCC 5 fully supports c++14
< BlueMatt> oh, thats a lie, wow, next debian is gcc 6
< luke-jr> RHEL tends to be the slowest these days
< sipa> and c++17... doesn't exist yet
< luke-jr> from what I've seen
< wumpus> std::string_view is very useful too
< luke-jr> lo, was morcos just trolling
< BlueMatt> morcos' xkcd 356 is good
< wumpus> recent versions of clang already support a lot of c++17 features, even though it doesn't officially exist yet
< 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]
< 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>
< sipa> hahaha
< jtimon> s/coon/soon
< wumpus> bitcoin core compiles almost entirely without changes in c++17 mode, btw
< luke-jr> wumpus: that's a nice start at least
< wumpus> there were some minor things last time I tried
< jtimon> wumpus: awesome, what are the almost no changes?
< wumpus> but those might be clang-weirdnesses as well
< wumpus> should be in my cloudabi branch, let me see
< 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 :(
< * BlueMatt> really wants to make all CBlockIndexes const :(
< sipa> BlueMatt: what do you do with the mutable fields?
< sipa> (nChainTx, nStatus, nFile, ...)
< BlueMatt> sipa: ehh, sorry, const outside of validation.cpp
< sipa> ah!
< sipa> yes!
< BlueMatt> ie exposed versions in headers are all const, and mapBlockIndex is const too
< BlueMatt> sipa: its the next one queued after #10279
< 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
< achow101> wumpus: did you change your gitian key?
< achow101> or sign with the wrong one?
< wumpus> I've added a signing subkey
< wumpus> it's the same I use for signing commits
< jtimon> wumpus: yeah, that's a very small diff
< achow101> wumpus: ah, ok. Apparently I don't have that key
< jtimon> BlueMatt: been there
< wumpus> achow101: --refresh-keys should get it AFAIK
< BlueMatt> jtimon: ehh, its normal 'round here, review is hard
< jtimon> yep, and time consuming
< BlueMatt> with good reason
< jtimon> not saying otherwise
< bitcoin-git> [bitcoin] achow101 opened pull request #10551: [Tests] Wallet encryption functional tests (master...wallet-encrypt-test) https://github.com/bitcoin/bitcoin/pull/10551
< luke-jr> btcdrak: are you planning to do a 0.14 addrindex?
< jtimon> yeah, I'm interested in knowing that too
< sipa> :(
< BlueMatt> :) ?
< jtimon> for an explorer
< sipa> i wish people wouldn't build solutions that require a fully indexed unpruned blockchain
< jtimon> sipa: although honestly like it as I have it with only blockheight, blockhash and txid for searching
< luke-jr> sipa: I agree, but a 0.14 addrindex will be less annoying than supporting 0.13 longer than necessary XD
< BlueMatt> sipa: is deserializing bandb/addrdb any more expensive than any other deserialization?
< BlueMatt> its vector operations, mostly, just like the rest, no?
< BlueMatt> re: 10248: so I dont see why it matters
< sipa> BlueMatt: code simplification
< BlueMatt> hmm? no, i mean i like 10248
< BlueMatt> and dont think the removal of the ability to skip deserialize on hash mismatch is worth worrying about
< sipa> oh, i agree
< 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
< wumpus> so 10248 is fine
< BlueMatt> if you can modify my bandb........
< BlueMatt> something something wallet in same folder
< wumpus> you can also change the hash, sure
< wumpus> the checksum is there against accidental corruption, and checking the hash on the fly is just as good for that
< sipa> i'd change your bitcoind :p
< wumpus> and if there is any way for a corruption to *crash* the deserialization I guess there's worse problems
< 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
< bitcoin-git> [bitcoin] jtimon closed pull request #10427: Consensus: Introduce static GetScriptFlags (mostly MOVEONLY) (master...b15-consensus-script-flags-min) https://github.com/bitcoin/bitcoin/pull/10427
< BlueMatt> ryanofsky: probably not?
< ryanofsky> ok, thx for sanity check
< bitcoin-git> [bitcoin] sipa pushed 11 new commits to master: https://github.com/bitcoin/bitcoin/compare/46311e792f4e...e801084decf4
< bitcoin-git> bitcoin/master 37e864e Pieter Wuille: Add FastRandomContext::rand256() and ::randbytes()...
< bitcoin-git> bitcoin/master 90620d6 Pieter Wuille: scripted-diff: Rename cuckoo tests' local rand context...
< bitcoin-git> bitcoin/master 124d13a Pieter Wuille: Merge test_random.h into test_bitcoin.h
< bitcoin-git> [bitcoin] sipa closed pull request #10321: Use FastRandomContext for all tests (master...fast_rand_tests) https://github.com/bitcoin/bitcoin/pull/10321
< jtimon> btw, I got #9717 out of #10339 as requested
< gribble> https://github.com/bitcoin/bitcoin/issues/9717 | Pow: Remove fCheckPOW from CheckBlockHeader by jtimon · Pull Request #9717 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/10339 | Optimization: Calculate block hash less times by jtimon · Pull Request #10339 · bitcoin/bitcoin · GitHub