< bitcoin-git> [bitcoin] promag opened pull request #11594: Improve -disablewallet parameter interaction (master...2017-11-disable-wallet) https://github.com/bitcoin/bitcoin/pull/11594
< promag> fanquake is the lucky luke of github labels
< bitcoin-git> [bitcoin] T-Pham opened pull request #11595: Update error messages in bitcoin-cli.cpp (master...patch-1) https://github.com/bitcoin/bitcoin/pull/11595
< dcousens> if `getblock` fails because we are pruning... could it be possible to instead the route the call to a network peer for the block?
< dcousens> (`getblock`, the rpc call)
< gmaxwell> dcousens: that is a minor amplification attack.
< gmaxwell> moreover, no one should be getblocking you for things you can't serve.
< dcousens> gmaxwell: my use case is a separate index that wants to catch up to a pruning local bitcoind
< dcousens> in no way would I intend for that RPC to be public
< sipa> dcousens: i think that will be easy to support after we have lightweight mode (which will require that the wallet can also ask for a block to be downloaded)
< sipa> concept ack, but it may be far out
< dcousens> sipa: fair enough :), so many other things to fix first, and data duplication isn't that bad in the mean time. Users could still run pruned nodes, they simply have to do it *after* the initial sync
< dcousens> aka, could use the pruning RPC
< gmaxwell> dcousens: then you want manual pruning, no
< dcousens> gmaxwell: well, its not ideal, but it works - unless the `indexd` db is lost, then you need to reset both.
< dcousens> I think some of the bigger deployments for `indexd` this are either imaging monthly anyway, so they run the pruning about that length
< wumpus> MarcoFalke: yes, it seems we're not going to get around backporting some of the support PRs, I personally think backporting #10756 is ok, not pretty but trying to patch everything up while backporting is likely more risky than doing that
< gribble> https://github.com/bitcoin/bitcoin/issues/10756 | net processing: swap out signals for an interface class by theuni · Pull Request #10756 · bitcoin/bitcoin · GitHub
< BlueMatt> sipa: yo
< sipa> ow
< BlueMatt> sipa: sorry, I think there's lots of net context here that is being missed :(
< BlueMatt> sipa: I have, on a few branches, an explicit goal of net_processing not relying on *when* FinalizeNode is called
< BlueMatt> plus the ForEachNode garbage needs to die
< sipa> agree on the last point
< BlueMatt> where CNodeState will have the CNode* in it (but it is much more restricted as a "socket reference" essentially - a thing you pass to CConnman to tell it where to send a message)
< sipa> but FinalizeNode should, regardless of when it is called, call the scheduler to remove any pending actions for that peer, no?
< BlueMatt> but eg the pr I linked to to remove the cs_vNodes lock in ForEachNode almost breaks that logic anyway
< BlueMatt> scheduler?
< BlueMatt> FinalizeNode isnt on scheduler?
< BlueMatt> since it takes things out of vNodes, calls FinalizeNode on it, but the ForEachNode function will be working on a copy of vNodes
< BlueMatt> cfields: also
< sipa> BlueMatt: the issue here is that there is an action called from the scheduler which may be running while a node is being finalized, no?
< BlueMatt> in this case its not, because cs_main, but, yes
< BlueMatt> keep in mind also that scheduler is allowed to be multiple threads
< sipa> sure, but thinking a bit ahead when cs_main is broken up
< BlueMatt> even if it isnt atm
< sipa> sure
< sipa> hmm, i see - the scheduled action isn't specific for the peer
< BlueMatt> when interacting with CConnman I think we should be making essentially 0 assumptions about order of operations cause net frameworks are always all kinds of random
< BlueMatt> anyway, I think the pr is more than fine as-is
< BlueMatt> it should not be considered a bug for the nodestate to be missing during a ForEachNode
< BlueMatt> at least in new code
< sipa> BlueMatt: yes, i withdraw my comment about the assert - violating it is much less of a assumption failure then i thought
< promag> for those that have 1 min free, I would like to get some concept ack/nack in #11402
< gribble> https://github.com/bitcoin/bitcoin/issues/11402 | [wallet] Use shared pointer for wallet instances by promag · Pull Request #11402 · bitcoin/bitcoin · GitHub
< BlueMatt> #11100 backport or no? MarcoFalke was asking
< gribble> https://github.com/bitcoin/bitcoin/issues/11100 | Fix confusing blockmax{size,weight} options, dont default to throwing away money by TheBlueMatt · Pull Request #11100 · bitcoin/bitcoin · GitHub
< MarcoFalke> is already huge, so I assumed 11100 wouldn't make it any worse.
< BlueMatt> I cant say I have a hugely strong opinion
< BlueMatt> its obviously a miner-only fix
< BlueMatt> it would be nice to get it in if miners switch to as their 0.15 upgrade, but I'm not sure how common that will be
< BlueMatt> there are still a number of miners that appear to be mining small blocks due to this misconfiguration
< sdaftuar> i would prefer to include it for that ^ reason
< BlueMatt> (which is a chunk of the "but segwit has only been a small increase" arguments - miner misconfiguration)
< gmaxwell> 11100 is simple and harmless, and should really be backported.
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/1b8c88451b05...bfb270acfa30
< bitcoin-git> bitcoin/master 720d9e8 Jonas Schnelli: [Wallet] always show help-line of wallet encryption calls
< bitcoin-git> bitcoin/master bfb270a MarcoFalke: Merge #11590: [Wallet] always show help-line of wallet encryption calls...
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #11590: [Wallet] always show help-line of wallet encryption calls (master...2017/10/enc_wallet_help) https://github.com/bitcoin/bitcoin/pull/11590
< MarcoFalke> fn github commit sorting
< MarcoFalke> Someone should complain about that
< sipa> i alreayd have, years ago
< sdaftuar> sipa: i think #11560 is ready for merge now (only difference from the commit you ack'ed is the const change)
< gribble> https://github.com/bitcoin/bitcoin/issues/11560 | Connect to a new outbound peer if our tip is stale by sdaftuar · Pull Request #11560 · bitcoin/bitcoin · GitHub
< cfields> query ryanofsky
< * cfields> dropped a /
< * MarcoFalke> picks up a / and hands it to cfields
< wumpus> hehe
< bitcoin-git> [bitcoin] practicalswift opened pull request #11596: Add missing cs_main locks when accessing chainActive (master...chainActive) https://github.com/bitcoin/bitcoin/pull/11596
< bitcoin-git> [bitcoin] kallewoof opened pull request #11597: [trivial] Fix error message & styling for when new fee rate < min mem… (master...171102-feebumper-lowerfeetxt) https://github.com/bitcoin/bitcoin/pull/11597
< jonasschnelli> Is the meeting now in 1h21min?
< jonasschnelli> (wintertime)
< sdaftuar> 20 minutes
< jonasschnelli> Thanks
< sipa> *drumroll*
< achow101> meeting?
< BlueMatt> *rimshot*
< wumpus> #startmeeting
< lightningbot> Meeting started Thu Nov 2 19:01:26 2017 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
< lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
< jonasschnelli> hi
< achow101> hi
< meshcollider> hi
< jtimon> hi
< wumpus> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101 meshcollider jnewbery maaku fanquake promag
< instagibbs> here
< sdaftuar> hello
< cfields> hi
< BlueMatt> 15.0.2
< MarcoFalke> #topic
< wumpus> yes, good idea
< achow101> it seems like things keep getting added to the milestone
< cfields> i think the outstanding PRs are pretty much ready to go
< wumpus> great!
< wumpus> achow101: only cfields's libevent fix
< BlueMatt> 11593 needs more review, 11560 could just be merged
< morcos> there are 3 PR's left in question: #11100 #11560 #11593
< BlueMatt> though I think 11593 is pretty reviewable
< gribble> https://github.com/bitcoin/bitcoin/issues/11100 | Fix confusing blockmax{size,weight} options, dont default to throwing away money by TheBlueMatt · Pull Request #11100 · bitcoin/bitcoin · GitHub
< kanzure> hi.
< meshcollider> and more backports
< gribble> https://github.com/bitcoin/bitcoin/issues/11560 | Connect to a new outbound peer if our tip is stale by sdaftuar · Pull Request #11560 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/11593 | rpc: work-around an upstream libevent bug by theuni · Pull Request #11593 · bitcoin/bitcoin · GitHub
< BlueMatt> plus backports needs fixing
< wumpus> the other one is just the backports which need to be done to support all that
< morcos> i think whichever we can't merge to master and backport right now, we need to just skip..
< achow101> backports is failing travis right now
< morcos> BlueMatt: backports for all others are fine... sdaftuar has tiny test fix
< BlueMatt> yea
< wumpus> ok
< morcos> although they could use more review, both sdaftuar and ryanofsky are reviewing now
< morcos> so we should just make decisions on those last 3 PR's.. 11100 is in master, so question is only whether to add it to backports? any objections?
< wumpus> none apparently
< gmaxwell> I really want to see 11100 appear in a release.
< BlueMatt> backports are already huge, but thats a simple pr and would be very nice to have
< gmaxwell> It's not the only misconfig now (I see blocks that clearly have minrelay fee cranked up-- e.g. legacy of 0.11-era mempool bloat attacks) but it's the biggest one.
< wumpus> although I think we should stop moving the goalposts
< MarcoFalke> ok, will amend the pull with sdaftuar's fix and 11100
< sipa> 11560 is mergable i think
< gmaxwell> Well, if there are any issues in backporting, feel free to drop IMO.
< BlueMatt> agreed
< wumpus> the point of is to protect against an immediate problem, and we should release it if it improves the situation anything from
< BlueMatt> ok, last point of order then is the libevent fix
< BlueMatt> cfields: you want to say anything?
< jtimon> ack on #11100 backport
< gribble> https://github.com/bitcoin/bitcoin/issues/11100 | Fix confusing blockmax{size,weight} options, dont default to throwing away money by TheBlueMatt · Pull Request #11100 · bitcoin/bitcoin · GitHub
< cfields> i've narrowed the workaround even further, it basically just affects a single stable release
< jtimon> curious, why backport all in one pr?
< BlueMatt> (the release that people have been switching to as they upgrade ubuntu, afaiu, fwiw)
< wumpus> jtimon: because many things depend on each other
< promag> hi
< MarcoFalke> jtimon: I am not going to push to non-master branches
< wumpus> jtimon: many of them are not trivial, stand-alone backports... if only
< MarcoFalke> also what wumpus said
< cfields> grr, sorry, irc client fell off
< wumpus> this way there's at least the chance to review, and for travis to test the backported code
< * sipa> picks up the irc lcient and hands it to cfields
< MarcoFalke> So action merge and bp 11560?
< sipa> MarcoFalke: ack
< achow101> +1
< jonasschnelli> BTW: should we also consider upgrading depends openssl due to CVE-2017-3736?
< jonasschnelli> Only BIP70 stuff is affected though
< BlueMatt> +merge and bp 11560
< bitcoin-git> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/bfb270acfa30...7008b07005c5
< bitcoin-git> bitcoin/master 6b58360 Cory Fields: rpc: work-around an upstream libevent bug...
< bitcoin-git> bitcoin/master 97932cd Cory Fields: rpc: further constrain the libevent workaround...
< bitcoin-git> bitcoin/master 7008b07 Wladimir J. van der Laan: Merge #11593: rpc: work-around an upstream libevent bug...
< wumpus> jonasschnelli: how dangerous is that?
< jonasschnelli> Not really...
< jonasschnelli> dangerous
< gmaxwell> jonasschnelli: man, openssl upgrades are really hard to review. :(
< wumpus> if not, let postpone it to 0.15.1?
< bitcoin-git> [bitcoin] laanwj closed pull request #11593: rpc: work-around an upstream libevent bug (master...fix-libevent-cb) https://github.com/bitcoin/bitcoin/pull/11593
< jonasschnelli> but we are using open ssl 1.0.1k which is no longer maintained
< sipa> The amount of resources
< sipa> required for such an attack would be very significant and likely only
< sipa> accessible to a limited number of attackers. An attacker would
< sipa> additionally need online access to an unpatched system using the target
< sipa> private key in a scenario with persistent DH parameters and a private
< sipa> key that is shared between multiple clients.
< gmaxwell> I'd rather be spending effort into further eliminating openssl. :)
< jonasschnelli> 0.15.1 should be fine IMO
< jtimon> is anybody using bip70?
< jonasschnelli> BIP70 without openssl is non-trivial to impossible
< jonasschnelli> we could remove BIP70 support... *duck* (luke-jr)
< achow101> jtimon: I'm pretty sure bitpay does
< BlueMatt> we could remove the ssl-checking part of bip70
< jonasschnelli> (no tests, no active maintenance)
< morcos> cfields: are there any changes to our httpserver/libevent code between master and 0.15, or its fine to just backport 11593 without thinking abou tit
< jtimon> achow101: thanks
< BlueMatt> and just treat it as a "better payment field"
< gmaxwell> meh, lets not discuss that now.
< jonasschnelli> Yes
< cfields> morcos: i'll double-check, but 99% a dumb backport is enough
< bitcoin-git> [bitcoin] laanwj pushed 6 new commits to master: https://github.com/bitcoin/bitcoin/compare/7008b07005c5...2f959a58744d
< bitcoin-git> bitcoin/master 2d4327d Suhas Daftuar: net: Allow connecting to extra outbound peers
< bitcoin-git> bitcoin/master db32a65 Suhas Daftuar: Track tip update time and last new block announcement from each peer
< bitcoin-git> bitcoin/master ac7b37c Suhas Daftuar: Connect to an extra outbound peer if our tip is stale...
< jonasschnelli> I'd say action: upgrade openssl depends for 0.15.1 or 0.16
< morcos> woohoo!
< bitcoin-git> [bitcoin] laanwj closed pull request #11560: Connect to a new outbound peer if our tip is stale (master...2017-10-stale-tip-new-peer) https://github.com/bitcoin/bitcoin/pull/11560
< achow101> oh, look at that!
< jonasschnelli> \o/
< sdaftuar> yay!
< gmaxwell> our work here is done.
< wumpus> whee
< wumpus> yep, ship it
< sdaftuar> we're shipping master right
< cfields> "This only affects processors that support the BMI1, BMI2 and ADX extensions like
< cfields> Intel Broadwell (5th generation) and later or AMD Ryzen."
< gmaxwell> :P
< achow101> it compiles, shit it
< achow101> *ship
< sipa> ok, backports are go
< wumpus> yes, we're releasing instead of :p
< morcos> achow101: exactly
< sipa> i do want to stress that these backports may be non-trivial compared to most point releases
< wumpus> yes, definitely
< BlueMatt> yea :(
< sipa> and we should review the patches, and possibly still decide to drop some
< gmaxwell> all the more reason to get a RC out stat.
< cfields> right. in addition to the usual checks, everyone should check their own fixes
< meshcollider> its massive for a point-point release lol
< wumpus> yes, that's what rcs are for
< sipa> absolutely
< wumpus> meshcollider: it's completely silly for a .0.2
< achow101> we've got two weeks
< MarcoFalke> its not even a point-release
< sipa> just pointing out that we're not really done
< meshcollider> so rc today?
< cfields> wumpus: don't forget the version bumps :)
< BlueMatt> hopefully? review backports
< sipa> meshcollider: review backports first
< gmaxwell> it's only a pointpoint release because we communicated the extended SW wallet support would be in 0.15.1. Otherwise this would be 0.15.1.
< wumpus> cfields: good point
< sdaftuar> #11592
< gribble> https://github.com/bitcoin/bitcoin/issues/11592 | WIP 0.15: Backports by MarcoFalke · Pull Request #11592 · bitcoin/bitcoin · GitHub
< achow101> so review backports and rc tomorrow?
< wumpus> gmaxwell: I understand, but I expected a much smaller release
< sipa> wumpus: so did we all, i think
< wumpus> normally we don't even publically announce minor-minor releases, let alone have an extended rc cycle
< wumpus> but that's definitely needed now
< achow101> note to self for future: don't promise things in version numbers
< jtimon> achow101:
< jtimon> +1
< sipa> we should have called it 0.15.$SEGWIT
< wumpus> achow101: good point
< gmaxwell> beyond the B2X split fix, I think this release is pretty trivial.
< sipa> but i agree, achow101
< gmaxwell> fixes*
< wumpus> don't promise things, period :)
< jonasschnelli> ^ (especially not on a timeline)
< gmaxwell> well if you'd be more comfortable calling it 0.15.1 I'd support that too. it's not like it's a big deal to say 'nope segwit stuff got pushed back due to snafu-mitigation'
< jtimon> I would prefer to call it 0.15.1, but not a big deal\
< cfields> from now on, we'll promise new features at block heights rather than timestamps :p
< sipa> we could of course also include #11167 (support for sending to bech32) and call it 0.15.1 *ducks*
< gribble> https://github.com/bitcoin/bitcoin/issues/11167 | Full BIP173 (Bech32) support by sipa · Pull Request #11167 · bitcoin/bitcoin · GitHub
< gmaxwell> too bad that has a bunch of refactors.
< bitcoin-git> [bitcoin] laanwj pushed 1 new commit to 0.15: https://github.com/bitcoin/bitcoin/commit/01e173f5b8985ad5ec14c1621531a003635f9800
< bitcoin-git> bitcoin/0.15 01e173f Wladimir J. van der Laan: build: Bump version to
< sipa> (that's not a serious suggestion, please let's not delay things further)
< wumpus> oh okay, calling it 0.15.1 is also ok with me
< gmaxwell> for some context there, new electrum shipped that has 'segwit wallet support' -- which for them is BIP173 only.
< jonasschnelli> 0.15.1 seems to make more sense to me... I don't think many people do expect SW Wallet support
< wumpus> ok
< gmaxwell> so already getting some reports of not being able to send to it from Bitcoin Core, ::sigh:: :)
< wumpus> yes, definitely better
< sipa> gmaxwell: well, electrum's problem
< jonasschnelli> Slow transition.... no hurry
< wumpus> indeed, just a matter of time
< wumpus> some software can be ahead of others, that's what you'll always have
< instagibbs> Electrum supports multiwallet, it's fine
< wumpus> great
< sdaftuar> release notes? anyone started that?
< wumpus> so, everyone agree that the release will be 0.15.1?
< sdaftuar> wumpus: sounds good
< jonasschnelli> wumpus: ack
< gmaxwell> sounds fine.
< promag> lgtm
< sipa> ack
< meshcollider> is there a TODO for release notes
< meshcollider> can only find 16.0
< wumpus> meshcollider: on the 0.15 branch
< bitcoin-git> [bitcoin] laanwj force-pushed 0.15 from 01e173f to f224cbc: https://github.com/bitcoin/bitcoin/commits/0.15
< bitcoin-git> bitcoin/0.15 f224cbc Wladimir J. van der Laan: build: Bump version to 0.15.1...
< achow101> 0.15.1 is fine with me
< wumpus> an actual point release, this feels much better
< meshcollider> wumpus: I mean an issue like 11054
< wumpus> release notes are certainly important, though they don't need to be ready for rc1
< morcos> one comment about the version
< morcos> i talked to Alyssa from CoinDesk abou tthis
< morcos> not sure if they published an article or about to
< wumpus> meshcollider: no, we don't make topics that for minor releases generally
< meshcollider> ah ok
< jtimon> morcos: should be easy to correct their article, no?
< wumpus> if you're in contact with them please let them know this is not the .1 they're expecting
< jonasschnelli> morcos: Maybe tell here that the SW2X aware version is now 0.15.1 and SW wallet version is *unknown" for now?
< morcos> yeah i don't see anything majorly published, i'll tell her now
< morcos> who knows if she was going to even say anything
< jtimon> just s/0.15.1/0.15.2 and s/
< wumpus> yes, segwit wallet delayed due to necessary s2x preparations :(
< BlueMatt> s/necessary/hopefully unecessary, though possibly necessary/
< sipa> arguably these were necessary preprations anyway - they're not specific to 2X
< BlueMatt> indeed
< wumpus> BlueMatt: better to be prepared at least
< BlueMatt> we now have outbound peer rotation!
< sipa> we just had to prioritize these P2P improvements
< jonasschnelli> but more pressing since SW2X
< BlueMatt> :bottlepop emoji"
< BlueMatt> :
< wumpus> sipa: sure, but the reason this was prioeritized over segwit I mean
< gmaxwell> yes, are generally good improvements which we should have done eventually regardless.
< morcos> ok i emailed her, i'm fine to switch it, i just wanted to be sure there wasn't already some article out there
< jonasschnelli> Who cares. :)
< sipa> i went back and edited some reddit comments i made about 0.15.1
< sipa> i think it's fine
< gmaxwell> morcos: inaccurate details in a press article about bitcoin?! Good thing you prevent that from ever happening.
< jonasschnelli> Things are in-move....
< BlueMatt> lolol
< wumpus> then after this we can do segwit wallet as 0.15.2, or 0.16.0, depending on what makes sense in the time frame that things are ready
< jonasschnelli> Yeah.. I would not promis 0.15.2 now (even if it's very likely to happen with SW Wallet)
< sipa> ya
< wumpus> jonasschnelli: indeed
< jtimon> perhaps we could consider doing 0.16 faster instead of doing a 0.15.2 release with segwit?
< jonasschnelli> features are not tied to releases... releases are tied to the planed timeframe
< jtimon> I guess it would be a bad precedent
< BlueMatt> ok, more topics?
< wumpus> jtimon: I'm ok with that - though the original reasoning was exactly opposite, add some time to 0.16 to be able to do a segwit release in between - but yeah, things have changed
< gmaxwell> so 0.16 release next week?
< * gmaxwell> ducks
< jonasschnelli> ;-)
< BlueMatt> #action activate segwit?
< wumpus> jtimon: also to not have another hairy, big set of backports
< wumpus> gmaxwell: always optimistic :)
< jtimon> wumpus: yeah I'm perhaps more worried about the latter
< * MarcoFalke> have been obtained by ChainCode
< jonasschnelli> \o/
< sipa> MarcoFalke: congrats!
< wumpus> congratulations MarcoFalke
< cfields> MarcoFalke: congrats :)
< gmaxwell> MarcoFalke: congrats.
< jonasschnelli> MarcoFalke: Congrats. Have fun in NY!
< sdaftuar> MarcoFalke: welcome! :)
< instagibbs> what does that bring the commit % to :P
< jtimon> yeah, cool
< BlueMatt> instagibbs: shhhhhhhhhhh
< instagibbs> congrats!
< cfields> heh
< BlueMatt> in the future, all coredev.tech events are required to occur in ny to minimize total flight time =D
< meshcollider> \o/
< jtimon> chaincode conspiracies coming...
< instagibbs> Eastern US powerhouse too :)
< MarcoFalke> instagibbs: It's not retroactive ;)
< morcos> instagibbs: which ones, the ones we do ourselves or the ones under our blockstream contract?
< jonasschnelli> ChainCodeLabs marketing departure must confront now with new ChainCode Core conspiracy
< instagibbs> morcos, one and the same, right?
< jtimon> BlueMatt: lol
< achow101> chaincore
< jonasschnelli> heh
< cfields> BlockChain
< cfields> wait...
< sdaftuar> lol
< gmaxwell> lol
< morcos> took you long enough
< jonasschnelli> lol
< sipa> ChainStream
< wumpus> hah!
< jtimon> codestream
< jtimon> anyway, other topics?
< wumpus> let's get backporting then
< gmaxwell> I thought we were gonna ship master! :P
< jtimon> but that's afterwards, release 0.15.1, then rc master the day after, no?
< wumpus> we coulld do that too and make people choose :p
< wumpus> YAH
< wumpus> #endmeeting
< lightningbot> Meeting ended Thu Nov 2 19:42:15 2017 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
< sipa> "Bitcoin Core now comes in multiple flavours! Bitcoin Core Home, Bitcoin Core Pro, Bitcoin Core XP, ..."
< jtimon> random non-priority review begging: https://github.com/bitcoin/bitcoin/pull/8994
< instagibbs> Bitcoin Core ME, don't forget ME
< achow101> Bitcoin Core Server Edition
< BlueMatt> achow101: no, thats FIBRE
< bitcoin-git> [bitcoin] jtimon closed pull request #11430: Add BIP16 to consensus params for consistency (master...b16-bip90-bip16) https://github.com/bitcoin/bitcoin/pull/11430
< cfields> MarcoFalke: any especially non-trivial backports we should give extra scrutiny?
< MarcoFalke> cfields: They are mostly clean cherry-picks (beside one or two minor conflicts)
< MarcoFalke> I am mostly worried about silent merge conflicts
< cfields> ok great, i was nervous that the signals/interface change might've introduced a bunch of conflicts
< MarcoFalke> but it compiles, so everything must be right
< MarcoFalke> right?
< cfields> hah, good enough
< BlueMatt> I mean our tests are prefect, right?
< sdaftuar> nothing could possibly go wrong
< jtimon> MarcoFalke: of course, it even passes travis, can't be wrong
< BlueMatt> someone wanna close #11575? Looks like his wallet got corrupted by sitting around for a few years....nothing to be done, he's just asking for support now...
< gribble> https://github.com/bitcoin/bitcoin/issues/11575 | CDBEnv::EnvShutdown: Error -30974 shutting down database environment: DB_RUNRECOVERY: Fatal error, run database recovery · Issue #11575 · bitcoin/bitcoin · GitHub
< karelb> Oh. I came to watch the meeting, I am one hour late because of daylight saving time.
< karelb> FINE
< meshcollider> heh DST is fun like that ;)
< * instagibbs> wondering if US DST will screw me up
< achow101> DST ends on sunday in the US
< meshcollider> does the whole US have one DST shift, or is it different for different parts?
< instagibbs> depends on state I believe
< achow101> It's state by state, but those that have DST shift at the same time IIRC
< BlueMatt> hey! we can make travis bitch on here when master builds fail
< BlueMatt> ...maybe we should do that
< bitcoin-git> [bitcoin] TheBlueMatt opened pull request #11598: Make travis complain on #bitcoin-core-dev when builds fail (master...2017-10-travis-irc-notifications) https://github.com/bitcoin/bitcoin/pull/11598
< bitcoin-git> [bitcoin] TheBlueMatt closed pull request #11598: Make travis complain on #bitcoin-core-dev when builds fail (master...2017-10-travis-irc-notifications) https://github.com/bitcoin/bitcoin/pull/11598
< bomberb17> ?
< travis-ci> TheBlueMatt/bitcoin#674 (2017-10-travis-irc-notifications - f9cd8b4 : Matt Corallo): The build passed.
< travis-ci> Change view : https://github.com/TheBlueMatt/bitcoin/compare/5d465e396249^...f9cd8b458a92
< gribble> https://github.com/bitcoin/bitcoin/issues/674 | Cannot compile Mac · Issue #674 · bitcoin/bitcoin · GitHub
< BlueMatt> lol, cfields you were right
< cfields> heh
< gmaxwell> bot warz
< sipa> we must go deeper
< sipa> cfields: https://github.com/bitcoin/bitcoin/pull/11389#discussion_r146683391 -> what do you suggest I replace it with?
< sipa> i wanted to use std::numeric_limits<int64_t>::max_value, but that required adding an extra include
< gmaxwell> an extra include to bring in numeric limits sounds reasonable, ... they should be included pretty much everywhere regardless....
< gmaxwell> an extra include of a boost header OTOH ...
< cfields> sipa: just dropping the 'U' would be enough to shut me up
< sipa> cfields: oh!