< phantomcircuit>
wumpus, opinion on modifying CONTIBUTORS.md to include "Reviewers should include the id of the commits which they reviewed in their comments."
< GitHub148>
[bitcoin] pstratem opened pull request #7185: Note that reviewers should mention the id of the commits they reviewed. (master...2015-12-07-contributingackcommit) https://github.com/bitcoin/bitcoin/pull/7185
< phantomcircuit>
Luke-Jr, please comment on pr mentioning commithash
< * phantomcircuit>
runs
< morcos>
phantomcircuit: i apologize for the ultra bikeshed, but isn't it a bit annoying to print out two memory usage stats right next to each other, one 1000-based and one 1024-based
< phantomcircuit>
morcos, fixed
< Luke-Jr>
gmaxwell: for blocks 300031..309685 (excluding outliers), of 2,701,513 total non-generation transactions, approximately 160,289 (5.93%) were mined by priority
< morcos>
Luke-Jr: and how many of those would not have made it in by fee? (what do you mean excluding outliers?)
< Luke-Jr>
morcos: excluding blocks which my code was unable to determine the priority/fee boundary
< aj>
Luke-Jr: can you tell how much of a discount they got? (ie, delta between the max/avg fee priority txs paid, versus min/avg fee non-priority txs paid)
< dcousens>
Luke-Jr: were those blocks full?
< Luke-Jr>
dcousens: unlikely
< dcousens>
Luke-Jr: so how can you definitively say they wouldn't have been included otherwise?
< Luke-Jr>
dcousens: I can't, and it doesn't seem relevant.
< dcousens>
Luke-Jr: " were mined by
< dcousens>
priority"
< Luke-Jr>
if impossible requests are made, I'm just going to go back to "onus of proof is on the remove-priority camp" :P
< Luke-Jr>
dcousens: yes, that's true regardless of whether they would have been included otherwise
< dcousens>
Luke-Jr: haha, agreed that onus on proof is definitely on remove-priority
< dcousens>
simply because, if its being used, then, maybe the altruism is worth keeping
< gmaxwell>
Luke-Jr: I think people are just trying to get clarity on what you measured and now.
< gmaxwell>
how*
< gmaxwell>
5% certantly sounds like more than just only benefiting old timers!
< GitHub88>
bitcoin/master af9510e Murch: Moved set reduction to the end of ApproximateBestSubset to reduce performance impact
< GitHub88>
bitcoin/master fc0f52d Murch: Added a test for the pruning of extraneous inputs after ApproximateBestSet
< wumpus>
curious, two nodes w/ /bitcoinj:0.12.2/ send almost 150kB of ping messages in less than a day: "ping": 145376, that's... abnormal at the least
< wumpus>
one vps at linode and one at fdcserver.net
< wumpus>
looking at their conntimes about ~10.5 bytes of ping traffic per second
< wumpus>
(for normal nodes this is ~0.15)
< wumpus>
I wonder why...
< tulip>
wumpus: just from observation nodes seem to ping an awful lot. even if you just did a pong a second ago you can end up pinging again in the next. maybe we could have a cool down for pings just to reduce the chat a bit?
< wumpus>
I'm seeing none of this behavior from bitcoin core nodes
< tulip>
I'm not sure anything stops wonky node implementations from going crazy with pings.
< wumpus>
either this is some specific abuse/attack, or a bug in a certain spy node implementation :-)
< tulip>
hm well you'll ping late if you're loaded down right? maybe there's some cpu usage related leakage somewhere.
< tulip>
it would reveal your process block time for example, as you don't reply to pings while doing that. you'll end up dropping your peers if you sit for 20 minutes reorganising for example.
< tulip>
I don't see that as useful information. buggy is probably more realistic and more likely.
< gmaxwell>
wumpus: :(
< gmaxwell>
wumpus: there is a privacy attack that looks like that.
< gmaxwell>
In the current code, sending lots of pings destroys any trickle delays.
< gmaxwell>
thus the patch from pieter that pulls back out the patch from phantomcircuit.