< GitHub54> [bitcoin] arowser opened pull request #7078: uint256::GetCheapHash bigendian compatibility (master...ppc) https://github.com/bitcoin/bitcoin/pull/7078
< GitHub96> [bitcoin] gmaxwell opened pull request #7079: Prevent peer flooding inv request queue (redux) (redux) (master...setAskFor) https://github.com/bitcoin/bitcoin/pull/7079
< gmaxwell> Luke-Jr: where is your sigops limiting patch?
< gmaxwell> what are you setting it to?
< Luke-Jr> 20
< gmaxwell> okay, thats safe, I think, in terms of not getting tripped up by transactions with lots of p2pkh outputs. Can you PR that with the default of 20?
< gmaxwell> each p2pkh output adds 34 bytes, so still above your threshold.
< gmaxwell> ratio of limits is 50, so in theory 20 could still be used in an attack, but not a very interesting attack.
< Luke-Jr> should the default be 34 then?
< gmaxwell> Luke-Jr: well the other thing this screws over is non-p2sh multisig,
< Luke-Jr> "screws over" only in policy.. and frankly, people should policy be blocking bare multisig anyway
< gmaxwell> I think 20 is fine.
< Luke-Jr> k
< gmaxwell> It makes attacking uninteresting... at worst the attack effectively limits the blocksize to 400k. Which isn't so far from the average in any case.
< GitHub1> [bitcoin] luke-jr opened pull request #7081: -bytespersigop option to additionally limit sigops in transactions we relay and mine (master...bytespersigop) https://github.com/bitcoin/bitcoin/pull/7081
< Luke-Jr> gmaxwell: ^
< GitHub70> [bitcoin] gmaxwell opened pull request #7082: Do not absolutely protect local peers and make eviction more aggressive. (master...evict_more) https://github.com/bitcoin/bitcoin/pull/7082
< phantomcircuit> first ssd failure
< phantomcircuit> gmaxwell, well... being able to process the expensive script sigs in parallel would improve the pipelining
< BlueMatt> comical gcc brokenness of the day: gcc does not print a warning (even with -Wextra) when you compile this http://pastebin.com/BFH5xzx0
< BlueMatt> hint: it prints "1 2" not "1 3"
< aj> BlueMatt: hmm llvm/clang doesn't either...
< gmaxwell> In C code I generally consider use of [] in prototypes to be an error in and of itself; I'd never considered the lovely interactions with C++.
< midnightmagic> like a weird sort of .. union or something.
< gmaxwell> well I guessed the correct behavior (knowing from the setup it would be 'weird'), that it would behave like a type coerced struct. But I was surprised that didn't elicit a warning.
< gmaxwell> So much for type safty, then again array protypes do awful stuff in plain C.
< midnightmagic> I always thought arrays made a lot of sense in C, personally, but C++ prototypes aren't nearly so intelligible..
< aj> midnightmagic: you can get the same behaviour in C with struct A { int a; } struct B { struct A a; int b; } and go(&bs[0].a); though it's a bit more obvious what you're doing wrong there...
< sdaftuar_> sipa: i think i'm going to rework the direct fetch logic in 6494... not sure how i missed this before but i realized this morning (while trying to fix a different issue) that limiting direct fetch to the blocks announced in a headers message is a bit broken
< sdaftuar_> really we want to direct fetch all the blocks that lead to the tip (even if we already had an intermediate header, and hence it wasn't announced to us)
< bsm1175321> BlueMatt that sucks. It's because sizeof(A) = 4 and sizeof(B) = 8.
< sipa> BlueMatt: in function prototypes, [] reduces to *, so your function is accepring a pointer to A :)
< sipa> (though a warning would be appropriate, even if it's strictly allowed)
< bsm1175321> I agree a warning would be appropriate. It's just mean.
< sipa> they have other "helpful" warnings anyway for perfectly legal things, like not using the result of a comparison, or ambiguous parenthesis
< GitHub151> [bitcoin] MarcoFalke opened pull request #7083: [init] Print OpenSSL version fix (master...MarcoFalke-2015-initOpenSSL) https://github.com/bitcoin/bitcoin/pull/7083
< sdaftuar> sipa: it looks like the parallel fetch logic causes a node to download towards a tip that has the same work as chainActive.Tip(), can you confirm that is correct and intentional?
< sdaftuar> i had written the direct fetch logic to only fetch towards a tip that had more work than chainActive.Tip(); i assume i should change it to match what's happening in FindNextBlocksToDownload
< sipa> sdaftuar: it's intentional, but you're making me question the reason behind it
< sdaftuar> sipa: well i don't think it's crazy to download it -- seems like it would help reorgs propagate faster between peers on different forks
< sipa> sdaftuar: it is ppssible that we already have the tip, and in fact had it earlier than the tip we are currently at; if we fetch the blocks in between, we should switch to it
< sdaftuar> ah good point
< sdaftuar> oh
< sdaftuar> no i think that's incorrect
< sipa> that is testable, though
< sdaftuar> we shouldn't and don't prefer a block unless it and all parents arrived first
< sipa> i think you're right that we shouldn't
< sipa> but i think we do
< sdaftuar> #6010
< sdaftuar> we fixed this earlier this year
< sipa> we only compare the tips nSequence
< sipa> oh, ok!
< BlueMatt> sipa: yea, I knew it wouldnt work when I wrote it, I was just writing code and was like "oh i should...wait, no, that cant work....I wonder if that even compiles...wait, no warning?!"
< sipa> BlueMatt: fair reaction
< sdaftuar> i think i'll just make the direct fetch logic mirror the existing behavior in FindNextBlocksToDownload...
< sipa> sdaftuar: ack
< gmaxwell> BlueMatt: ping on PR 6915
< GitHub164> [bitcoin] MarcoFalke opened pull request #7084: mempool: Replace maxFeeRate of 10000*minRelayTxFee with maxTxFee (master...MarcoFalke-2015-mempoolMaxTxFee) https://github.com/bitcoin/bitcoin/pull/7084
< MarcoFalke> sdaftuar, Do you plan to address the nit in 7063?
< MarcoFalke> The code looks clean so you get my ACK anyway, just asking.
< sdaftuar> MarcoFalke: i was going to look at it again next week if it wasn't merged by then! trying to get the other PRs tagged for 0.12 ready before the feature freeze
< sdaftuar> sipa: i'm going to push updates to 6494. i had to rework the direct fetch logic somewhat substantially :( would you prefer to see the original commit you already reviewed, or should i squash down now?
< sipa> sdaftuar: feel free to squash
< sdaftuar> sipa: thanks, done
< sdaftuar> BlueMatt: regarding #6915, do you think we should just repeat the logic that's in CheckFinalTx each place we invoke mempool.removeForReorg():
< sdaftuar> const int64_t nBlockTime = (flags & LOCKTIME_MEDIAN_TIME_PAST)
< sdaftuar> ? chainActive.Tip()->GetMedianTimePast()
< sdaftuar> : GetAdjustedTime();
< sdaftuar> that seems not so bad, just tried it out and replaced the last commit in #6915 with one that does this instead.
< BlueMatt> sdaftuar: wait, I'm confused...this doesnt seem right
< BlueMatt> sdaftuar: the rule is block-time-cannot-go-back-from-MTP
< BlueMatt> sdaftuar: so the rule for mempool removal should be max(GMTP(), GetAdjustedTime())
< BlueMatt> oops, nvm
< BlueMatt> anyway, I'd prefer to not duplicate the code....can we pull that out into a function?
< BlueMatt> but, yea, i like that better
< * BlueMatt> -> lunch