< bitcoin-git> [bitcoin] theuni opened pull request #9441: WIP: Massive net speedup. Net locks overhaul. (master...connman-locks) https://github.com/bitcoin/bitcoin/pull/9441
< gmaxwell> man, the maximum size of a stanard txn being so long really makes smarter block trasfer a pita.
< btcdrak> gmaxwell: how so?
< gmaxwell> because it makes the amount of data needed to recover from even a single missing transaction highly variable.
< morcos> gmaxwell: yeah i keep thinking that too.. but we could put some of that intelligence in the sender
< wbnns> @gmaxwell @wumpus_ Hello, just wanted you check-in regarding the Alert System Retirement notice currently appearing across the tops of all pages on Bitcoin.org - is there a specific date it would be okay to remove it?
< wbnns> It will still be available here (the notification just won't show at the top of every page): https://bitcoin.org/en/alerts
< kinlo> is the alert page going away? The bitcoin protocol for the alert system is being retired, but is the https://bitcoin.org/en/alerts going away?
< wbnns> Also, if you all are open to it, was wondering if it might be a good idea in the future, whenever there is a new release, to do an informational alert (like the current one) so people will be informed of the new version.
< wbnns> Something like, "Bitcoin Core v0.13.1 is now available." - which could link to an alert page providing the release notes: https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-0.13.1.md
< wbnns> @kinlo Hi, no, I'm not aware of any plans for that to be removed.
< Lauda> 0.13.2 still not RC2?
< gmaxwell> Lauda: I'm doubting there will be an RC2. No issues have been reported for RC1 AFAIK.
< Lauda> It will just jump to final? Any ETA?
< Lauda> Very nice to hear that though.
< luke-jr> checking whether to build Bitcoin Core GUI… no (Qt)
< luke-jr> ^ not sure (Qt) belongs
< luke-jr> wumpus_: I have a fix for https://github.com/bitcoin/bitcoin/pull/7522 if you can reopen
< Chris_Stewart_5> Isn't there a chance for malleability in OP_CHECKMULTSIG scripts even with BIP146
< Chris_Stewart_5> For instance, I'm spending a 2/3 and I provide 3 total digital signatures, 2 valid and 1 invalid?
< Chris_Stewart_5> and then I can put whatever junk I watn into the invalid one?
< sipa> CMS for 2-of-3 only takes 2 signatures as input
< sipa> and 3 public keys
< jonasschnelli> hmm.... there is something wrong with the seeder:
< jonasschnelli> 2933 jonassc+ 20 0 1202368 9108 3340 S 399.1 0.0 217270:46 dnsseed
< jonasschnelli> (399% CPU)
< luke-jr> others more actively here welcome to reopen 7522 as well :p
< luke-jr> jonasschnelli: CPU idle on mine
< Chris_Stewart_5> sipa: The malleability I was talking about then would be caught by CLEANSTACK right?
< bitcoin-git> [bitcoin] gmaxwell opened pull request #9442: Do not use signals for communication between net and net_processing. (master...no_node_signals) https://github.com/bitcoin/bitcoin/pull/9442
< bitcoin-git> [bitcoin] gmaxwell closed pull request #9442: Do not use signals for communication between net and net_processing. (master...no_node_signals) https://github.com/bitcoin/bitcoin/pull/9442
< bitcoin-git> [bitcoin] gmaxwell closed pull request #9415: Reduce latency of ThreadMessageHandler. (3.2x speedup for IBD to 200k) (master...better_sleep) https://github.com/bitcoin/bitcoin/pull/9415
< bitcoin-git> [bitcoin] gmaxwell closed pull request #8800: Fetch w/o CB if mempool empty, don't use HB mode if blocks only. (master...no-hb-in-bo) https://github.com/bitcoin/bitcoin/pull/8800
< bitcoin-git> [bitcoin] gmaxwell closed pull request #9424: Change LogAcceptCategory to use uint32_t rather than sets of strings. (master...log_category_simplify) https://github.com/bitcoin/bitcoin/pull/9424
< BlueMatt> gmaxwell: why close #9424? I think its something we want, though maybe there are other review priorities for 0.14
< gribble> https://github.com/bitcoin/bitcoin/issues/9424 | Change LogAcceptCategory to use uint32_t rather than sets of strings. by gmaxwell · Pull Request #9424 · bitcoin/bitcoin · GitHub
< gmaxwell> BlueMatt: no feedback, even though I've nagged people, and it's now conflicted.
< BlueMatt> gmaxwell: so reopen post-feature-freeze?
< gmaxwell> sure, if people want it. It makes changes over the code base due to needing to change LogPrintF, I'm not intrested in maintaining it when there has been no feedback at all, and for all I know people hate it because it violates some style principle that I don't know about or understand and would disagree with if I did. :)
< gmaxwell> codes all there, it isn't going anywhere. It's not an impressive feat of engineering or anything. :)
< BlueMatt> gmaxwell: suresure, but, yes, I like it...maybe easier to get review for that after 0.14 branch or so
< BlueMatt> or maybe feature-freeze since its just a refactor-ish
< BlueMatt> gmaxwell: also #8800
< gribble> https://github.com/bitcoin/bitcoin/issues/8800 | An error has occurred and has been logged. Please contact this bot's administrator for more information.
< gmaxwell> BlueMatt: I think that one is really unimportant compared to basically everything else.
< gmaxwell> there is a huge backlog of things which are more important and easier to merge.
< BlueMatt> gmaxwell: yea, ok, fair enough
< morcos> BlueMatt: I'm working on a patch to allow multiple blocks in flight at the same time.. and i'm stuck on what to do when you receive one of them
< morcos> In #9352 sdaftuar took the approach that you don't want to MarkBlockReceived until after you know the block is valid
< gribble> https://github.com/bitcoin/bitcoin/issues/9352 | Attempt reconstruction from all compact block announcements by sdaftuar · Pull Request #9352 · bitcoin/bitcoin · GitHub
< morcos> i suppose to cover the case of malleated witness data
< morcos> should we be refactoring all the code to take that approach? it requires a different solution in #9400
< gribble> https://github.com/bitcoin/bitcoin/issues/9400 | Set peers as HB peers upon full block validation by instagibbs · Pull Request #9400 · bitcoin/bitcoin · GitHub
< luke-jr> was it this meeting that got cancelled?
< gmaxwell> no meeting this week
< bitcoin-git> [bitcoin] jl2012 opened pull request #9443: Repairing the large-work fork warning system (master...forkwarning) https://github.com/bitcoin/bitcoin/pull/9443
< jl2012> oh, because of holiday?
< gmaxwell> Yes. Sorry, mentioned in last weeks meeting. But perhaps it should have been better announced. My fault.
< btcdrak> lightningbot is fixed btw.
< lightningbot> btcdrak: Error: "is" is not a valid command.
< btcdrak> lol
< gmaxwell> for some definition of 'fixed'.
< btcdrak> well at least it's here this time :-p
< jl2012> if anyone is interested, please take a look : #9443
< gribble> https://github.com/bitcoin/bitcoin/issues/9443 | Repairing the large-work fork warning system by jl2012 · Pull Request #9443 · bitcoin/bitcoin · GitHub
< jl2012> This is a fix for the broken warning system
< morcos> OK I have a patch that allows 2 simultaneous blocks in flight and combines 9375, 9252 and 9400... I'll test it and report back.. got to run for the night