< 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():