< sipa> jnewbery: i saw
< jnewbery> Block file upgrade code removed here: https://github.com/bitcoin/bitcoin/pull/9822
< jnewbery> It's a bit pedantic - probably no-one is running pre-0.8 anymore. I have a slight preference to include the upgrade advice, but won't be too upset if other people vote to remove it.
< sipa> oh, it was actually removed!
< sipa> ok
< sipa> jnewbery: i've also changed all v0.15 notation into 'version' or 'Bitcoin Core'
< jnewbery> I saw. Looks good to me.
< Emcy_> 'On Windows, do not forget to uninstall all earlier versions of the Bitcoin client first.' Is this really *necessary*. No one ever does this
< Emcy_> over the top installs happen
< luke-jr> Emcy_: I have no idea, but we said that in older versions
< luke-jr> Emcy_: if you can confirm it isn't needed, maybe it can be removed
< Emcy_> it seems to be one of those fluff recommendations that windows software makes, like 'reboot your machine after install' as if anyone really does that.
< Emcy_> If its just copying new files over the top i dont see why its necessary. Ill try it when 0.15 comes out
< theymos> I've never given the advice to uninstall first. In fact, that could conceivably cause problems because uninstalling sometimes creates a one-time run-at-boot task which removes some files that the uninstaller couldn't immediately remove.
< theymos> (Speaking generally here -- I've never looked at the Bitcoin Core installer.)
< Emcy_> thats true
< Emcy_> tahts what it says in those draft rls notes though, twice in fact and the second time makes it sound like not-boilerplate
< Emcy_> thats why i asked
< theymos> Old versions recommended installing over the old one: https://bitcoin.org/en/release/v0.12.0
< theymos> The uninstall note must've been added recently. Maybe there's some reason for it, or maybe it was added in error.
< gmaxwell> I've always told people to overinstall.
< gmaxwell> I would be kinda worried about someone managing to delete their chain or wallet if I instructed them to remove!
< gmaxwell> might be useful to investigate the history to see if there was a reason or if it was a copyediting error.
< gmaxwell> generally I'm super scared about telling users to remove or delete anything; lest the next thing I see from them was "okay, I used the system recovery DVD"
< Emcy_> lol
< luke-jr> Emcy_: when 0.15 comes out, it will be too late to change..
< luke-jr> theymos: I copied the uninstall bit from 0.8 or 0.9 IIRC
< luke-jr> where are we at with a 0.14.3 with BIP148? I'm going to miss next meeting most likely again :/
< bitcoin-git> [bitcoin] coblee opened pull request #10968: Add instructions for parallel gitian builds. (master...coblee_multi_core) https://github.com/bitcoin/bitcoin/pull/10968
< BitMEX_Wally> There is a chainsplit in testnet and my 14.1 node is refusing to follow the longest chain after I ran invalidateblock on the short chain
< BitMEX_Wally> getchaintips shows the longest chain as 'headers-only'
< arubi> which block is that BitMEX_Wally ?
< BitMEX_Wally> {
< BitMEX_Wally> "height": 1155846,
< BitMEX_Wally> "hash": "00000000c164f6ac32ee23d104a81d7308d23b7a54745b4d613442c8a6c6ee1e",
< BitMEX_Wally> "branchlen": 41,
< BitMEX_Wally> "status": "headers-only"
< BitMEX_Wally> },
< arubi> I have it too
< arubi> well, if the node doesn't have the blocks then it can't change to the other chain. maybe someone testing lite wallets?
< BitMEX_Wally> My other node is following that chain
< BitMEX_Wally> So are block explorers: https://live.blockcypher.com/btc-testnet/
< gmaxwell> it's really common for the testnet chain with the most work to have fewer blocks FWIW.
< BitMEX_Wally> So how do I get my node to download those blocks? It is currently stuck on 1155805 / 00000000000005757375cdb666a319cf6758d54af7a19da42a96a0551f342d6b and not updating
< BitMEX_Wally> This chain has the most work as far as I can tell
< BitMEX_Wally> height=1155846 log2_work=69.338015
< gmaxwell> BitMEX_Wally: run getblockchainfo to see how much work you have in useful units
< gmaxwell> "chainwork": "000000000000000000000000000000000000000000000028707f523ddd5abd07",
< BitMEX_Wally> "chain": "test",
< BitMEX_Wally> "blocks": 1155805,
< BitMEX_Wally> "headers": 1155846,
< BitMEX_Wally> "bestblockhash": "00000000000005757375cdb666a319cf6758d54af7a19da42a96a0551f342d6b",
< BitMEX_Wally> "difficulty": 2597896.746553252,
< BitMEX_Wally> "mediantime": 1501547517,
< BitMEX_Wally> "verificationprogress": 0.9997853208317297,
< BitMEX_Wally> "chainwork": "0000000000000000000000000000000000000000000000286d17360b5491b2c3",
< BitMEX_Wally> "pruned": false,
< BitMEX_Wally> "softforks": [
< gmaxwell> okay thats less work than I have. Do you see any invalid in getchaintips or your debug log?
< BitMEX_Wally> [
< BitMEX_Wally> {
< BitMEX_Wally> "height": 1155846,
< BitMEX_Wally> "hash": "00000000c164f6ac32ee23d104a81d7308d23b7a54745b4d613442c8a6c6ee1e",
< BitMEX_Wally> "branchlen": 41,
< BitMEX_Wally> "status": "headers-only"
< BitMEX_Wally> },
< BitMEX_Wally> {
< BitMEX_Wally> "height": 1155831,
< BitMEX_Wally> "hash": "000000000000066cd029ad78432f1c8d30e24459e407cc8f834a4b251bd83640",
< BitMEX_Wally> "branchlen": 26,
< BitMEX_Wally> "status": "invalid"
< BitMEX_Wally> },
< BitMEX_Wally> {
< BitMEX_Wally> "height": 1155807,
< BitMEX_Wally> "hash": "0000000000014b01c3ae388401c8c2d0945ec953f695ea50d357c7bf8bef2279",
< BitMEX_Wally> "branchlen": 2,
< BitMEX_Wally> "status": "invalid"
< BitMEX_Wally> },
< BitMEX_Wally> {
< BitMEX_Wally> "height": 1155805,
< sipa> please don't copy-paste more than 3 lines
< BitMEX_Wally> "hash": "00000000000005757375cdb666a319cf6758d54af7a19da42a96a0551f342d6b",
< BitMEX_Wally> "branchlen": 0,
< BitMEX_Wally> "status": "active"
< BitMEX_Wally> },
< gmaxwell> 000000000000066cd029ad78432f1c8d30e24459e407cc8f834a4b251bd83640 is in my best chain here...
< gmaxwell> BitMEX_Wally: so now you need to look in your debug.log to see why 000000000000066cd029ad78432f1c8d30e24459e407cc8f834a4b251bd83640 was rejected as invalid.
< BitMEX_Wally> 1155846 / 00000000c164f6ac32ee23d104a81d7308d23b7a54745b4d613442c8a6c6ee1e has "chainwork": "00000000000000000000000000000000000000000000002872d1f10daeee43fa",
< gmaxwell> look at debug.log and search for 000000000000066cd029ad78432f1c8d30e24459e407cc8f834a4b251bd83640
< BitMEX_Wally> I marked 000000000000066cd029ad78432f1c8d30e24459e407cc8f834a4b251bd83640 as invalid because the other chain had more work
<@sipa> you can undo invalidateblock using reconsiderblock
< BitMEX_Wally> Yeah, but then I would be on chain 1155831 again, which is not most work?
< gmaxwell> my nodes have never seen 00000000c164f6ac32ee23d104a81d7308d23b7a54745b4d613442c8a6c6ee1e
< BitMEX_Wally> 2017-08-01 06:34:13 UpdateTip: new best=00000000c164f6ac32ee23d104a81d7308d23b7a54745b4d613442c8a6c6ee1e height=1155846 log2_work=69.338015 tx=14687012 date=2017-08-01 06:34:10 progress=1.000000 cache=0.7MiB(1148tx)
< BitMEX_Wally> 2017-08-01 05:47:57 UpdateTip: new best=000000000000066cd029ad78432f1c8d30e24459e407cc8f834a4b251bd83640 height=1155831 version=0x20000000 log2_work=69.337605 tx=14686762 date='2017-08-01 05:47:46' progress=1.000000 cache=0.9MiB(2990tx)
< BitMEX_Wally> These are my 2 nodes
< BitMEX_Wally> The longest one definitely has more work
< sipa> are they running the same software?
< BitMEX_Wally> No
< sipa> what are they running?
< BitMEX_Wally> First one (longest) is running v0.12.1
< gmaxwell> gonna guess the more work one is probably segwit invalid.
< BitMEX_Wally> Ahh
< sipa> seems likely, yes
< gmaxwell> oh I just see in your chaintips that you have two invalid blocks there.
< BitMEX_Wally> Why are people still mining it *sigh*
< gmaxwell> I see smartbits explorer is consistent with my nodes.
< gmaxwell> and I know their explorer is backed by a node that actually verifies things.
< BitMEX_Wally> Ok so I will tell my other node to invalidate those blocks
< BitMEX_Wally> Then I will put it behind another SegWit ndoe
< gmaxwell> sounds like a good idea.
< BitMEX_Wally> Ok that worked. Sorry to bother you Greg
< gmaxwell> Don't be. Always feel free to bring concerns like this here!
< wumpus> MarcoFalke: sipa: certs should be renewed, thanks for the reminder
< wumpus> I feel kind of uncomfortable runinng certbot as root automatically in a crontab, though for availablility it'd probably be a good idea
< wumpus> manually babysitting servers in timely manner is not something I'm good at
< sam_c> i don't like the idea either
< bitcoin-git> [bitcoin] laanwj pushed 6 new commits to master: https://github.com/bitcoin/bitcoin/compare/42307c4bf363...bd924241e7dc
< bitcoin-git> bitcoin/master eda888e Matt Corallo: Fix some LoadChainTip-related init-order bugs....
< bitcoin-git> bitcoin/master b0f3249 Matt Corallo: More user-friendly error message if UTXO DB runs ahead of block DB...
< bitcoin-git> bitcoin/master ff3a219 Matt Corallo: Call RewindBlockIndex even if we're about to run -reindex-chainstate...
< bitcoin-git> [bitcoin] laanwj closed pull request #10758: Fix some chainstate-init-order bugs. (master...2014-07-nonatomic-flush-fixes) https://github.com/bitcoin/bitcoin/pull/10758
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/bd924241e7dc...754aa02b8a72
< bitcoin-git> bitcoin/master efeb273 Pieter Wuille: Force on-the-fly compaction during pertxout upgrade
< bitcoin-git> bitcoin/master 754aa02 Wladimir J. van der Laan: Merge #10526: Force on-the-fly compaction during pertxout upgrade...
< bitcoin-git> [bitcoin] laanwj closed pull request #10526: Force on-the-fly compaction during pertxout upgrade (master...compactrange) https://github.com/bitcoin/bitcoin/pull/10526
< bitcoin-git> [bitcoin] practicalswift opened pull request #10969: Declare single-argument (non-converting) constructors "explicit" (master...explicit) https://github.com/bitcoin/bitcoin/pull/10969
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/754aa02b8a72...f66c59650527
< bitcoin-git> bitcoin/master e222dc2 Andrew Chow: Replace ismine with producesignature check in witnessifier...
< bitcoin-git> bitcoin/master f66c596 Wladimir J. van der Laan: Merge #10788: [RPC] Fix addwitnessaddress by replacing ismine with producesignature...
< bitcoin-git> [bitcoin] laanwj closed pull request #10788: [RPC] Fix addwitnessaddress by replacing ismine with producesignature (master...fix-addwitnessaddress) https://github.com/bitcoin/bitcoin/pull/10788
< iglobalvn> got
< gmaxwell> Updated my banned node list.
< bitcoin-git> [bitcoin] theuni opened pull request #10971: build: fix missing warnings and sse42 in depends builds (master...fix-config-override) https://github.com/bitcoin/bitcoin/pull/10971
< bitcoin-git> [bitcoin] practicalswift opened pull request #10972: Check return value of addr.GetKeyID(keyid) on custom change address change (master...GetKeyID-assertion) https://github.com/bitcoin/bitcoin/pull/10972
< earlz> Has anyone successfully cross-compiled Bitcoin Core for a raspberry pi? If so, is that process documented somewhere?
< earlz> I saw one tutorial on how to compile it on-device, but I'd rather spend less than 1 day compiling
< sipa> earlz: more, there are release binaries for ARM
< bitcoin-git> [bitcoin] ryanofsky opened pull request #10973: WIP: Add IPC layer between node and wallet (master...pr/wipc-sep) https://github.com/bitcoin/bitcoin/pull/10973
< earlz> sipa: how are those made though? Gitian?
< cfields> yes
< earlz> ah