< 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
< 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
< 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?
< 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.
< 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.
< 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
< 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