< GitHub92>
[bitcoin] laanwj opened pull request #7795: UpdateTip: log only one line at most per block (master...2016_04_block_warning_logging_inline) https://github.com/bitcoin/bitcoin/pull/7795
< GitHub86>
[bitcoin] MarcoFalke opened pull request #7796: [amount] Add support for negative fee rates (master...Mf1604-amountNeg64) https://github.com/bitcoin/bitcoin/pull/7796
< gmaxwell>
Is there some computationally efficient way that I can take a mempool txn and determine its chain depth in the mempool?
< sipa>
i'd say check the code that limits it?
< gmaxwell>
Fair recommendation.. looks like it walks, I guess thats not that awful, was thinking of sorting invs but it needs to be a topological sort.
< sipa>
given that it is limited in depth, walking is worst-case constant time :)
< gmaxwell>
it's a bit annoying because a txn can have multiple parents, and you need to walk all to discover the worst case depth.
< gmaxwell>
can't easily be cached since new blocks will invalidate.
< GitHub173>
[bitcoin] mruddy opened pull request #7797: RPC: fix generatetoaddress failing to parse address (master...generatetoaddress-fix) https://github.com/bitcoin/bitcoin/pull/7797
< GitHub108>
[bitcoin] MarcoFalke opened pull request #7798: [travis] Print the commit which was evaluated (master...Mf1604-travisCommitLog) https://github.com/bitcoin/bitcoin/pull/7798
< GitHub142>
bitcoin/master 4b9dfd6 Pavel Janík: Add note about using the Qt official binary installer.
< GitHub142>
bitcoin/master e0b3e19 Wladimir J. van der Laan: Merge #7789: [Doc] Add note about using the Qt official binary installer....
< GitHub31>
[bitcoin] laanwj closed pull request #7789: [Doc] Add note about using the Qt official binary installer. (master...20160402_Qt56_official_installer_note) https://github.com/bitcoin/bitcoin/pull/7789
< btcdrak>
MarcoFalke: after 0.12.1 is tagged, it might be worth backporting the stuff around python required for Ubuntu 16.04
< wumpus>
yes, probably
< sdaftuar>
gmaxwell: saw your comment above about topological sort
< sdaftuar>
gmaxwell: if you don't actually care about "depth", and just want a sort that puts dependent transactions after their ancestors, then you can sort by nCountWithAncestors
< sdaftuar>
which gets updated as blocks are found
< sipa>
sdaftuar: i assume he also wants it sorted by decreasing feerate
< sdaftuar>
ah
< sdaftuar>
that sounds like what the new CNB does
< gmaxwell>
sdaftuar: no thats exactly what I want. Glad I asked.
< gmaxwell>
sdaftuar: ah, I didn't see that because I was on 0.12. :)
< btcdrak>
gmaxwell: I took a stab at 0.12 release notes for the softfork, if you have time, could you check for accuracy/completeness? https://github.com/bitcoin/bitcoin/pull/7800
< sdaftuar>
gmaxwell: if you're working on something that you intend for 0.12 (as opposed to master), i have some suggestions
< sdaftuar>
gmaxwell: i wrote up code at one point (before i realized the nCountWithAncestors thing) that would walk the transaction graph, along the lines of Kahn's algorithm iirc
< sdaftuar>
i could dig that up, but morcos had the idea of just first sorting by entry time to mempool, which should be close to right
< sdaftuar>
and then looping over the resulting sorted list, and checking if the tx is clear of dependencies
< gmaxwell>
I'm contemplating just using the same score to order them that createnewblock does now.
< GitHub101>
[bitcoin] MarcoFalke opened pull request #7803: [qa] maxblocksinflight: Actually enable test (master...Mf1604-qaTestMaxBlocks) https://github.com/bitcoin/bitcoin/pull/7803
< GitHub61>
[bitcoin] MarcoFalke opened pull request #7802: [qa] httpbasics: Actually test second connection (master...Mf1604-qaTestHttp) https://github.com/bitcoin/bitcoin/pull/7802
< GitHub135>
[bitcoin] sipa opened pull request #7804: Track block download times per individual block (master...betterkicktimeout) https://github.com/bitcoin/bitcoin/pull/7804
< sipa>
wumpus: i wonder if we could/should fetch the entire description (or even all discussion) of a PR, and include it in the merge commit...
< gmaxwell>
I would like that.
< gmaxwell>
it irritates the hell out of me that the git history often doesn't even include an adequate description of the change, because it's all in the PR.
< sipa>
on the other hand, PR descriptions are sometimes not updated when the scope/implementation changes significantly
< sipa>
you can consider that a bad thing, but if you see the description just as the first message of the discussion, maybe the correct solution is just including the entire discussion
< sipa>
text is cheap
< sipa>
that would make the commits also more independent from github (as currently the merge commit does list the github PR number, but to grasp all the details you often need to actually go to github)
< btcdrak>
sipa: yeah I tried that once but really the merge script would have to be redone in something like python so you can parse the github API data.
< gmaxwell>
whole thing need not be redone, it could call a helper.
< gmaxwell>
could also add the phase of the moon and current best block, if we wanted. :)
< btcdrak>
sipa: check #5623
< MarcoFalke>
btcdrak, the script is already python /contrib/devtools/github-merge.py
< btcdrak>
oh the shell script went away
< btcdrak>
well then that's easy, just pull the title from a fetch of https://api.github.com/repos/$REPO/pulls/$PULL
< MarcoFalke>
Should be trivial to include the text from GitHub, but I am worried that typing `git log` will make you scroll the whole day
< btcdrak>
you can make a lot more interesting merge commit messages too
< MarcoFalke>
we already fetch the title ;)
< btcdrak>
omg. have been under a rock.
< sipa>
btcdrak: yes, that's why i brought it up, because it should be easy to add more now
< btcdrak>
sipa: +1 on adding the entire discussion history to the merge commit
< sipa>
MarcoFalke: that's a decent concern... we could fetch the github discussion, make a commit that puts it in $REPO/share/github-discussion/$PR.md or something, and include that commit in the merge...
< MarcoFalke>
sipa, exactly my thought. Just make a blob and do an octomerge
< sipa>
it's something i dislike right now: commits that refer to pull requests; the git source tree is something that should make sense without having access to github
< btcdrak>
I think the commit message should contain the PR body text.
< btcdrak>
merge* commit message
< gmaxwell>
Well this isn't a replacement for having a useful commit message.