< phantomcircuit> sipa: is the block/headers synchronziation strategy documented anywhere?
< phantomcircuit> (mostly im interested in the intended operation)
< sipa> phantomcircuit: it's complicated...
< phantomcircuit> sipa, that's uh
< phantomcircuit> sipa, can you explain it to me?
< sipa> yes
< sipa> during initial sync, we send a getheaders to one peer only; outside of it we send it to all
< sipa> from headers responses we learn what blocks peers have
< sipa> and then in sendmessages determine which blocks to fetch from whom, subject to various conditions
< sipa> that's the parallel fetch
< sipa> there is also the direct fetch, in response to a block 'inv', which (a) sends a getheaders from that inv (b) sends a getdata if we believe we're close to being synced
< sipa> and then there is bip130, which introduces direct fetch in response to headers
< sipa> phantomcircuit: for more detail i need to look at the code
< phantomcircuit> sipa, ok that's helpful
< sipa> an invariant is that we never send a second request for a block that is already in flight, but we have timeouts that will disconnect (but not ban) a peer that takes too long
< gmaxwell> with compact blocks that could potentially be relaxed in the future. fetching a redundant compact block is not going to push you over being able to keep up with the network.
< gmaxwell> nor would a redundant blocktxn so long as it was less than half the block worth of data.
< GitHub139> [bitcoin] fanquake opened pull request #8252: [trivial] Add aarch64 to depends .gitignore (master...depends-aarch-gitignore) https://github.com/bitcoin/bitcoin/pull/8252
< GitHub135> [bitcoin] fanquake opened pull request #8253: [TEST] [Travis] Remove hostname workaround (master...remove-travis-workaround) https://github.com/bitcoin/bitcoin/pull/8253
< GitHub29> [bitcoin] fanquake opened pull request #8254: [doc] Add OSX ZMQ requirement to QA readme (master...qa-readme-zmq) https://github.com/bitcoin/bitcoin/pull/8254
<@wumpus> so, time to merge segwit today?
< GitHub67> [bitcoin] fsb4000 opened pull request #8256: BUG: bitcoin-qt crash (master...patch-4) https://github.com/bitcoin/bitcoin/pull/8256
< GitHub13> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/08338942b50f...c2c69edf37b5
< GitHub13> bitcoin/master d241487 fanquake: [doc] Add OS X ZMQ requirement to QA readme
< GitHub13> bitcoin/master c2c69ed MarcoFalke: Merge #8254: [doc] Add OSX ZMQ requirement to QA readme...
< GitHub132> [bitcoin] MarcoFalke closed pull request #8254: [doc] Add OSX ZMQ requirement to QA readme (master...qa-readme-zmq) https://github.com/bitcoin/bitcoin/pull/8254
< GitHub155> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/c2c69edf37b5...5cd35d3dbc8b
< GitHub155> bitcoin/master 133deb8 Pieter Wuille: Mark my dnsseed as supporting filtering
< GitHub155> bitcoin/master 5cd35d3 Wladimir J. van der Laan: Merge #8247: Mark my dnsseed as supporting filtering...
< GitHub107> [bitcoin] laanwj closed pull request #8247: Mark my dnsseed as supporting filtering (master...newseed) https://github.com/bitcoin/bitcoin/pull/8247
< GitHub66> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/5cd35d3dbc8b...af2421c291c4
< GitHub66> bitcoin/master d7828ab fsb4000: check that transactionView->selectionModel()->selectedRows(0) exists
< GitHub66> bitcoin/master af2421c Wladimir J. van der Laan: Merge #8256: BUG: bitcoin-qt crash...
< GitHub124> [bitcoin] laanwj closed pull request #8256: BUG: bitcoin-qt crash (master...patch-4) https://github.com/bitcoin/bitcoin/pull/8256
< Lauda> Has the source of the re-index slowdown been discovered?
<@wumpus> I don't think so? I don't think it's even clear yet whether there is one, but you should refer to the issue: https://github.com/bitcoin/bitcoin/issues/8245
<@wumpus> you could help by doing reindex tests with different revisions/versions
< Lauda> Does someone have a link to download a/some version(s)? I'd waste additionaly time building them otherwise
< Lauda> I'd be happy to help.
< Lauda> additional*
< MarcoFalke> Lauda: there are nightly builds
< Lauda> Where?
< Lauda> Thanks. I'm on it, and will post the results once done.
< sipa> the ThreadSafeMessageBox for "Do you want to reindex now" only has an BTN_ABORT button?
< sipa> why is it even a yes/no question then
<@wumpus> it should have a yes/no button
<@wumpus> if not, that's a regression
<@wumpus> it's the only place where the return value of ThreadSafeMessageBox is used
<@wumpus> if there is only one return value that's pertty pointless
< sipa> i think that function should just be replaced with two simpler functions void UIMessage(string) and bool UIQuestion(string)
< sipa> ah, MODAL is used for payment protocol
< sipa> isn't that unnecessarily intrusive?
<@wumpus> adding an UIQuestion would make sense, it could return a default value in case of no ui
<@wumpus> I don't think it's a good time to change the rest of that stuff
< sipa> agree
< sipa> i'll make a minimal change for 0.13, and a follow-up refactor for master post branching
<@wumpus> sounds good to me
<@wumpus> sipa: it should have an OK button too
<@wumpus> sipa: MSG_ERROR = (ICON_ERROR | BTN_OK | MODAL)
< sipa> ah!
<@wumpus> CClientUIInterface::MSG_ERROR | CClientUIInterface::BTN_ABORT
< sipa> that's confusing, but agree
<@wumpus> so it has an OK and ABORT button
<@wumpus> yes, well, that stuff was inherited from the wx client, I agree it would be better in terms of UIMessage, UIQuestion, the MODAL stuff is only used within the GUI code itself so could use something else
<@wumpus> (the problem there is that paymentserver wasn't designed in the typical qt way with a model and view, so instead of displaying a alert directly, which would be weird in server code, it works around that by abusing the core->ui messaging system :-)
<@wumpus> so once you start refactoring you'll probably bump against all kinds of things which grew over time and don't exactly fit into the new, cleaned vision
<@wumpus> paymentserver should have a dedicated signal for messages to the user
<@wumpus> (and the GUI should subscribe to that)
< sipa> there are 9 call sites to ThreadSafeMessageBox
< sipa> that's more than i expected, but not particularly much either
<@wumpus> must of the calls are InitMessage/InitWarnings
<@wumpus> InitError*
< sipa> i call those as a single call site
< sipa> *count
<@wumpus> I know, but I mean, all in al the function is used quite a lot
< sipa> right
<@wumpus> ideally the core would communicate with the GUI through status codes/bits instead of sending whole messages
<@wumpus> I mean, the user-facing text belongs in the GUI
<@wumpus> the _(...) workaround which is hooked by the GUI is pretty weird
< sipa> yes
<@wumpus> then again, it was never really urgent to change, at least it works
<@wumpus> these are things you can spent weeks on, without anything affecting the user-facing side
< GitHub195> [bitcoin] sipa opened pull request #8257: Do not ask a UI question from bitcoind (master...noask) https://github.com/bitcoin/bitcoin/pull/8257
<@wumpus> okay, here we go
<@wumpus> IRC flood upcoming
< btcdrak> LOL
< * wumpus> kicks github
< GitHub54> [bitcoin] laanwj pushed 28 new commits to master: https://github.com/bitcoin/bitcoin/compare/af2421c291c4...d61283781402
< GitHub54> bitcoin/master ecacfd9 Pieter Wuille: --- [SEGWIT] begin: P2P/node/consensus ---
< GitHub54> bitcoin/master 7030d9e Pieter Wuille: BIP144: Serialization, hashes, relay (sender side)...
< GitHub54> bitcoin/master 449f9b8 Pieter Wuille: BIP141: Witness program
< GitHub34> [bitcoin] laanwj closed pull request #8149: Segregated witness rebased (master...segwit-master2) https://github.com/bitcoin/bitcoin/pull/8149
<@wumpus> that's disappointing, does it print only at most three commits?
< jl2012> \o/
< * sipa> vacation.
< achow101> woo!
<@wumpus> sipa: yes like true developers, let's do a release now and go on holiday :')
< sipa> of course
<@wumpus> it's deployed! seeya!
< Ylbam> lol
< Ylbam> anyway \o/
< GitHub158> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/d61283781402...5cdc54b4b62d
< GitHub158> bitcoin/master f70bcfc fanquake: [trivial] Add aarch64 to depends .gitignore
< GitHub158> bitcoin/master 5cdc54b Wladimir J. van der Laan: Merge #8252: [trivial] Add aarch64 to depends .gitignore...
< GitHub8> [bitcoin] laanwj closed pull request #8252: [trivial] Add aarch64 to depends .gitignore (master...depends-aarch-gitignore) https://github.com/bitcoin/bitcoin/pull/8252
< achow101> so what about the deployment stuff for segwit?
<@wumpus> achow101: it's all described here: https://bitcoincore.org/en/2016/06/24/segwit-next-steps/
< instagibbs> \o/
< achow101> When do we decide deployment parameters
< instagibbs> achow101, after/during backport i think
<@wumpus> yes
< achow101> ok
<@wumpus> needs to be determined for the 0.12.2 release
< GitHub18> [bitcoin] sipa closed pull request #7910: Segregated witness (master...segwit-master) https://github.com/bitcoin/bitcoin/pull/7910
< gmaxwell> Yippie.
<@wumpus> yes, congrats everyone!
< GitHub9> [bitcoin] jl2012 opened pull request #8258: RPC: Hide softfork if timeout is 0 (master...bip9rpcdisable) https://github.com/bitcoin/bitcoin/pull/8258
< GitHub53> [bitcoin] jl2012 closed pull request #8209: Showing "not_applicable" if BIP9 timeout is 0 (master...patch-13) https://github.com/bitcoin/bitcoin/pull/8209
< helo> pretty exciting
< GitHub154> [bitcoin] NicolasDorier opened pull request #8259: Cache hashes (master...cachedhashes) https://github.com/bitcoin/bitcoin/pull/8259
< randy-waterhouse> so git head should run fine on on testnet3 without any additional config changes or needs to go on segnet?
< gmaxwell> yes, though there may not be enough testnet nodes with it yet that you can get it to work right without an addnode.
< gmaxwell> One of the todos coming out of the meeting this week was to get more segwit testnet nodes up.
< randy-waterhouse> k, thnx ... what is the "Rewinding" part doing?
< gmaxwell> What it says-- segwit has been active on testnet for a couple months-- but your node wasn't able to verify the segwit rules... so it's undoing the chain and revalidating it to make sure there were no violations since it activated.
< gmaxwell> If you had been running segwit code on testnet before it activated you wouldn't have expirenced that.
< randy-waterhouse> ok, looks like I'm gonna need some addnodes, can I find a list of seggers?
< randy-waterhouse> or is it segwitters?
< randy-waterhouse> nm ... found one randomly
< randy-waterhouse> 119.246.245.241
< sipa> i think we should call transactions with an invalid witness segfaults
< randy-waterhouse> please no segfaults
< randy-waterhouse> and here come the blocks ... my blockchain will never be the same again
< randy-waterhouse> feels like I just exited something
< randy-waterhouse> blexit