< jl2012> I talked to wangchun. F2pool has stopped setting the csv bit.
< phantomcircuit> jl2012: i dont think it matters the soft fork is locked in either way
< phantomcircuit> (i could be wrong here but im prettty sure im not)
< gmaxwell> phantomcircuit: it doesn't.
< btcdrak> jl2012: need to ask antpool to unset it also.
< instagibbs> phantomcircuit, there is just some concern of blocks having bits set that a client wont understand
< instagibbs> alerts for no reason(more than we already have now)
< btcdrak> yes. please see latest article on website
< GitHub115> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/961893f26e5c...760a6c7cb2ea
< GitHub115> bitcoin/master b3e1348 Jonas Schnelli: [Qt] fix a bug where the SplashScreen will not be hidden during startup
< GitHub115> bitcoin/master 760a6c7 Wladimir J. van der Laan: Merge #8231: [Qt] fix a bug where the SplashScreen will not be hidden during startup...
< GitHub92> [bitcoin] laanwj closed pull request #8231: [Qt] fix a bug where the SplashScreen will not be hidden during startup (master...2016/06/qt_min_fix) https://github.com/bitcoin/bitcoin/pull/8231
< GitHub180> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/760a6c7cb2ea...9e45ef1ef031
< GitHub180> bitcoin/master 4cbe05b Wladimir J. van der Laan: qt: Periodic transifex update...
< GitHub180> bitcoin/master 9e45ef1 Wladimir J. van der Laan: Merge #8234: qt: Periodic transifex update...
< GitHub197> [bitcoin] laanwj closed pull request #8234: qt: Periodic transifex update (master...2016_06_transifex_update) https://github.com/bitcoin/bitcoin/pull/8234
< GitHub34> [bitcoin] MarcoFalke opened pull request #8236: [doc] 0.12.2: prepare release notes (0.12...Mf1606-docReleaseNotes) https://github.com/bitcoin/bitcoin/pull/8236
< fanquake> wumpus Some issues that can be closed #7861 #7873 #7866
< fanquake> Also #6701 should have been closed by #7667
< fanquake> Possibly also #6702
< fanquake> #7872 can also be closed. Not sure why this account has opened so many random/meaningless issues.
< MarcoFalke> done
< gmaxwell> Anyone have exact IsSuperMajority heights for BIP30/65/66 on mainnet and testnet handy, by any chance?
< btcdrak> gmaxwell: BIP65 was activated on block #388380
< btcdrak> luke-jr: maybe we should update the BIPs with activation blocks when they activate
< btcdrak> gmaxwell: do you mean BIP34? according to the BIP text "Block number 227,835 (timestamp 2013-03-24 15:49:13 GMT) was the last version 1 block."
< gmaxwell> uhh. is reindex broken on master for anyone else?
< gmaxwell> oh it's not broken.
< gmaxwell> it just looks funny now that it scans headers first.
< gmaxwell> hm. we might get bug reports on that.
<@wumpus> those mrCertified issues are crazy, didn't notice them before, thanks for closing fanquake/MarcoFalke
< sipa> btcdrak: bips.md has more info
< GitHub199> [bitcoin] laanwj pushed 1 new commit to 0.11: https://github.com/bitcoin/bitcoin/commit/0cd4fb6570f67d40891673bc8c41e473b9753c63
< GitHub199> bitcoin/0.11 0cd4fb6 Wladimir J. van der Laan: qt: Final translation update on 0.11 branch...
< gmaxwell> so the first point where if (block.nVersion >= 2 && IsSuperMajority(2, pindexPrev, consensusParams.nMajorityEnforceBlockUpgrade, consensusParams))
< gmaxwell> is true is 224413, which seems to suggest that the BIP34 height in the chainparams is wrong?
< gmaxwell> nevermind. activated vs enforced.
<@wumpus> phew
< sipa> gmaxwell: what looks funny about it?
< sipa> gmaxwell: the chainparams value is the first point where it activated and never went to non-activated anymore
<@wumpus> maybe add a comment to prevent people panicking from this again in the future :)
< gmaxwell> I will.
< gmaxwell> I was in the process of making a patch to remove all the IsSuperMajority code, and replace with simple height checks.
< gmaxwell> I think it's weird that we end up with network connections while reindexing.
<@wumpus> outgoing or incoming?
< gmaxwell> outgoing.
<@wumpus> in principle the network code is simply running while reindexing, it just doesn't request blocks nor transactions
<@wumpus> I don't think that's necessarily wrong
< gmaxwell> I'm probably only really noticing because I have debugging turned up and the invs are filling up my logs.
< gmaxwell> Is it useful to have connections up while reindexing?
< sipa> i guess it may make sense for addr relay
<@wumpus> no, but it also doesn't hurt, there doesn't need to be a strong coupling between network code and chain handling code
< sipa> we could extend the dont-request-blocks rule to dont-request-transactions too
<@wumpus> I think that's already the case?
< gmaxwell> doesn't appear to be requesting any.
< gmaxwell> The negatives I can think of: wastes network resources, might defeat "is it working" monitoring. Otherwise, I agree.
<@wumpus> there is also a paralellism aspect: there will already be connections to request blocks on when the reindexing finished
< gmaxwell> Thats a point.
<@wumpus> in any case there doesn't seem to be a strong reason to special-case this, so let's not
<@wumpus> the amount of network resources 'wasted' during reindex must be negible compared to a running node, and if you really care about (say when benchmarking) that and want to do a pure reindex, pass -connect=0 and disable listening...
< sipa> wumpus: unfortunately, there is a bug around that
< sipa> wumpus: we don't start requesting headers when reindex finishes
< sipa> so only when an inv for a new block arrives, actual sync continues after a reindex
< gmaxwell> We should probably release note that reindex may look inactive for a period of time at the beginning.
<@wumpus> that seems wrong
< sipa> we should fix it
< sipa> i'll file an issue if there is none already
< gmaxwell> indeed, but after 3 hours, an extra block delay is not the end of the world. :)
<@wumpus> on the other hand reindex is just a tool to fix for broken databases, which unfortunately happen much more than they should, but it shouldn't be something people are doing day in day out
<@wumpus> so I suppose the +/- 10 minute delay is indeed not the end of the world
< gmaxwell> I think that at some not far future version we should rename reindex to work around bad instructions on the internet that have people reindexing every time they see a shadow.
<@wumpus> nah
< sipa> -really-reindex
< gmaxwell> --rebuild-state
< sipa> well we do have -reindex-chainstate now
< sipa> but -reindex itself is still useful when your block files are corrupted
<@wumpus> for better or worse, there are many legitimate issues solved by a reindex, seems almost sadistic to break all kinds of well-meant guides on the internet. Even if it results in slightly more reindexes besing run all in all.
< sipa> of course
< gmaxwell> not yet, but in some near future where awesome improvements reduce the use for ever running it, of course.
< sipa> same with rescan
<@wumpus> I'm not a fan of the rename-an-option-to-prevent-people-from-doing-it school if the option isn't a danger of monetary loss
< sipa> at least the very common advice to fix random problems with a -rescan has died out
<@wumpus> if there was a purge-privatekeys option for the wallet I would want to rename it eveery release :p
< sipa> haha
< gmaxwell> okay. I won't argue for it, I was only motivated by the fact that many of the old reasons are gone.
< sipa> --steal-my-coins
< sipa> gmaxwell: do you have evidence of -reindex commonly being suggested for the wrong reasons?
< gmaxwell> E.g. someone in #bitcoin two days ago was exasperated while on day three of a reindex on an rpi3 that was totally unneeded.
<@wumpus> the utxo backup fallback woud still be a good idea, we should aim to get it into 0.14
< gmaxwell> In that case, it was listed as a mandatory step for moving chainstate from x86 to rpi, suggested due non-portability that no longer exists.
< sipa> wumpus: agree
<@wumpus> gmaxwell: was that a guide on the wiki? if so it'd be easy to fix
<@wumpus> if not, we should probably contact the author
< gmaxwell> (also, for pruning to someday become a default option, we must reduce the incidence of reindex to ~0)
<@wumpus> do you have a link to that guide?
< gmaxwell> I thought I asked him, but I didn't. I asked now.
< GitHub189> [bitcoin] fanquake opened pull request #8238: [WIP][depends] ZeroMQ 4.1.5 && ZMQ on Windows (master...depends-zeromq-4-1-5) https://github.com/bitcoin/bitcoin/pull/8238
< fanquake> Was #6702 solved by #7667 ?
< fanquake> Can probably close #7724, sipa replied and it seems that the issue is user hardware.
< fanquake> #7735 Isn't going to happen any time soon, and can probably be closed.
< fanquake> #7979 can be closed.
<@wumpus> thanks, done
< fanquake> #7725 Looks closable, seems like the issue was related directory permissions.
< fanquake> #7733 Could be closed as wontfix, as documentation was linked to elsewhere. Unless we need to follow up and add links to the README or something?
<@wumpus> agree
< sipa> fanquake: thanks a lot for going through those issues!
<@wumpus> https://github.com/bitcoin/bitcoin/issues/4095 is a qt issue, and a curious one at that, anyone ever managed to reproduce this?
<@wumpus> yes, thanks!
< fanquake> #5758 Seems to have gone stale, no followup replies.
< sipa> fanquake: closed 1.5 years ago?
<@wumpus> wrong number I think
< sipa> we need a checksum digit in PR numbers
< fanquake> Sorry, #5785
<@wumpus> <:
< sipa> ack on merging compact blocks?
< fanquake> #6472 && #7341 can probably be closed now that we've switched to Qt5.6.1
< fanquake> Can close #7834 - Changes to the macports portfile have been made upstream, and parallel builds are working ok normally.
< btcdrak> sipa: ack.
<@wumpus> I've been testing compact blocks on one of my ARM nodes for quite some time, no issues
< instagibbs> I see no reason to block merging. Only nits/minor improvements left which can be taken on later.
<@wumpus> agree
<@wumpus> okay, hold on tight
< * btcdrak> drum roll
< GitHub185> [bitcoin] laanwj pushed 19 new commits to master: https://github.com/bitcoin/bitcoin/compare/9e45ef1ef031...e9d76a161d30
< GitHub185> bitcoin/master 96806c3 Pieter Wuille: Stop trimming when mapTx is empty
< GitHub185> bitcoin/master 7c29ec9 Matt Corallo: If AcceptBlockHeader returns true, pindex will be set....
< GitHub185> bitcoin/master cbda71c Matt Corallo: Move context-required checks from CheckBlockHeader to Contextual...
< GitHub25> [bitcoin] laanwj closed pull request #8068: Compact Blocks (master...udp) https://github.com/bitcoin/bitcoin/pull/8068
<@wumpus> ^^
< fanquake> Woo
< instagibbs> \o/
< btcdrak> oh man
< btcdrak> yis!
< shangzhou> wow
< GitHub170> [bitcoin] laanwj pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/e9d76a161d30...9f1807af2422
< GitHub170> bitcoin/master b7bf037 Wladimir J. van der Laan: doc: Mention ARM executables in release process...
< GitHub170> bitcoin/master 05f64c9 Wladimir J. van der Laan: doc: Mention Linux ARM builds in release notes
< GitHub170> bitcoin/master 06f40ef Wladimir J. van der Laan: depends: Mention aarch64 as common cross-compile target
< GitHub183> [bitcoin] laanwj closed pull request #8233: Mention Linux ARM executables in release process and notes (master...2016_06_release_process_arm) https://github.com/bitcoin/bitcoin/pull/8233
<@wumpus> is there any way to see (in the GUI or through RPC) if a wallet is BIP32?
< sipa> i'm rebasing segwit on top of compact blocks; they'll be mutually exclusive until we define a means to negotiate witness-or-not in compact blocks
< sipa> so compact blocks won't work on test where segwit is already defined
< sipa> s/won't work/won't be used/
<@wumpus> makes sense for the first version, being clear that it should not stay that way
< sipa> yes, and fixing it is trivial
< sipa> but i feel that's beyond the scope of segwit
< sipa> as that will at the very least testing how they interact in the real world
<@wumpus> yes
<@wumpus> though there is the risk that miners may see segwit as a step back, if its activation disables compact blocks
< sipa> we definitely need to have segwit+compactblock support defined and implement before picking a start time for segwit
< instagibbs> sipa, for 0.13 you mean?
< btcdrak> sipa: so step 1 is to merge in master, then step 2 work out the segwit+cb support, then step 3 set starttime?
< sipa> yes
<@wumpus> oh! yes that order makes sense
< instagibbs> cb doesn't matter for 0.12.2, so backport with activation can move forward regardless, right?
<@wumpus> right, cb doesn't matter for 0.12.2
< sipa> indeed, backport of segwit and definition of cb+segwit can happen in parallel
< sipa> when both are done, we can pick a start time
< btcdrak> neat :)
< btcdrak> so I assume after CB rebase, it's merge time?
< sipa> i'm unconfortable with the fact that the codebase since 7910 started and now has diverged so much that the recent changes and integration are not very transparent to review
< sipa> not so much that nobody has looked at them, but more that there isn't a good way to know whether you've seen everythong
< sipa> you can look at the merge commit in 7910
< sipa> but it's pretty big by now
< btcdrak> i thought we're not merging 7910, but the other cleaned up version?
< sipa> yes, of course
< sipa> but 8049 has been rebased constantly
< btcdrak> also I assume we need to reactivate/hf testnet?
< sipa> testnet activation is included in both
< sipa> but for example, #7935 introduced the concept of gbt_force (bip9 rollouts which the GBT client needs explicit support for)
< sipa> in rebased segwit (#8149), the commit that adds GBT support for segwit also introduces the integration with gbt_force
< sipa> in the old segwit patch (#7910), that integration is completely hidden inside the merge commit with master
< sipa> other than that, i don't think waiting with merge makes much sense...
< sipa> looking at the merge commit in 7910 may make sense
< sipa> (git show will show you all conflicts it resolved, but the format with double +/- signs is not so simple to read)
< fanquake> sipa great work
< GitHub86> [bitcoin] laanwj opened pull request #8240: doc: Mention Windows XP end of support in release notes (master...2016_06_windows_xp) https://github.com/bitcoin/bitcoin/pull/8240
< GitHub198> [bitcoin] laanwj pushed 2 new commits to 0.12: https://github.com/bitcoin/bitcoin/compare/f3eebcf5158f...9adad33938ec
< GitHub198> bitcoin/0.12 ffff324 MarcoFalke: [doc] 0.12: prepare release notes
< GitHub192> [bitcoin] laanwj closed pull request #8236: [doc] 0.12.2: prepare release notes (0.12...Mf1606-docReleaseNotes) https://github.com/bitcoin/bitcoin/pull/8236
< GitHub198> bitcoin/0.12 9adad33 Wladimir J. van der Laan: Merge #8236: [doc] 0.12.2: prepare release notes...
< GitHub54> [bitcoin] laanwj opened pull request #8241: 0.13: Disable bad chain alerts (master...2016_06_alexit) https://github.com/bitcoin/bitcoin/pull/8241
< GitHub1> [bitcoin] paveljanik opened pull request #8242: Check if the macro PKG_PROG_PKG_CONFIG was expanded. (master...20160622_check_pkg-config) https://github.com/bitcoin/bitcoin/pull/8242