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