< 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
< 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
< 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!
< 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
< 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