< rebroad> please could someone tell me where I can find the doc on gitian building for windows and arm?
< rebroad> oh found it
< GitHub14> [bitcoin] fanquake opened pull request #8742: Specify Protobuf version 2 in paymentrequest.proto (master...proto2-vs-proto3) https://github.com/bitcoin/bitcoin/pull/8742
< GitHub3> [bitcoin] fanquake opened pull request #8743: Remove old manpages from contrib/debian in favour of doc/man (master...remove-old-manpages) https://github.com/bitcoin/bitcoin/pull/8743
< dgenr8> how does gitian know not to try to build qt for arm?
< jonasschnelli> dgenr8: the configure (autoconf) process will auto-detect the qt libraries..
< jonasschnelli> If not available, it will be built headless.
< jonasschnelli> You might want to check the bitcoin-qt.m4 macro file
< jonasschnelli> dgenr8: and the magic point where qt gets not compiled for ARM is here: https://github.com/bitcoin/bitcoin/blob/master/depends/packages/packages.mk#L7
< GitHub99> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/a82e5d8220bb...1e5799c52535
< GitHub99> bitcoin/master fa27d99 MarcoFalke: [qa] create_cache: Delete temp dir when done
< GitHub99> bitcoin/master 1e5799c MarcoFalke: Merge #8713: [qa] create_cache: Delete temp dir when done...
< GitHub24> [bitcoin] MarcoFalke closed pull request #8713: [qa] create_cache: Delete temp dir when done (master...Mf1609-qaCacheTempdir) https://github.com/bitcoin/bitcoin/pull/8713
< GitHub149> [bitcoin] MarcoFalke opened pull request #8744: [0.13.1] qa Backports (0.13...Mf1609-qaBackports) https://github.com/bitcoin/bitcoin/pull/8744
< rebroad> would anyone know why there's code in addrman.cpp to randomize the addresses sent in response to a getaddr?
< rebroad> weird.... block 430068 has a checksum ox 0x00000000
< rebroad> of
< rebroad> hmmm, then again it came from which is doing various weird things...
< sdaftuar> BlueMatt: sipa: there's an issue with the way the announce bit is set in 8393 (you can't change it). github isn't letting me comment on the pull right now for some reason though
< sdaftuar> BlueMatt: anyway it's confusing to me to figure out what the logic for changing it should be
< rebroad> why aren't problems with LogPrint detected at compile time as they would be with printf?
< BlueMatt> should fix it
< BlueMatt> oh ffs, now github is sending me two emails for every comment
< sdaftuar> BlueMatt: thanks, that looks right
< sipa> rebroad: compiler magic
< sipa> rebroad: the c compiler recognizes printf in a special way
< GitHub44> [bitcoin] jonasschnelli opened pull request #8745: [PoC] Add wallet inspection and modification tool "bitcoin-wallet-tool" (master...2016/09/wallet-tool) https://github.com/bitcoin/bitcoin/pull/8745
< luke-jr> sipa: well, it's possible to get printf-formatting rules on other functions, but LogPrintf isn't as picky as real printf [cc: rebroad]
< sipa> right, doing so would make the compiler warn about many things that are just fine for LogPrintf
< GitHub64> [bitcoin] achow101 opened pull request #8746: [Qt][RPC] Hide passphrases in debug console history (master...hide-walletpassphrase) https://github.com/bitcoin/bitcoin/pull/8746
< jonasschnelli> Luke-Jr: Did you had a look at the TinyFormat.h we are using?
< dgenr8> jonasschnelli: perfect, thank you!
< Chris_Stewart_5> Does a full node remove a competing chain after X amount of blocks being ahead of it? Can a full node store competing chains for a small amount of time?
< sipa> if there is no pruning, we never prune
< sipa> if we do, we prune after some time
< sipa> regardless of whether it's main chain or not
< Chris_Stewart_5> Hmm interesting. I've always wondered about this. So it will store ALL blocks indefinitely as long as they are valid ( meet POW threshold, all valid txs, etc?)
< sipa> even invalid blocks
< sipa> because not all checks can be done immediately
< Chris_Stewart_5> Like time on the relative scale of performing all sigops? Or time for something else that takes much longer?
< Chris_Stewart_5> sigops in the block*
< sipa> signature checks can only be done once we build the chainstate for tjat block, which requires processing the previous blocks
< sipa> if there is a reorganization, we don't do that until the chain takes over the other chain
< Chris_Stewart_5> Interesting, thanks for the explanation.
< sipa> but we do certainly validate pow and syntactic correctness before storing blocks on dizk
< sipa> *disk
< sipa> which means an attack to fill up nodes' disks would be very expensove
< sipa> *expensive
< Chris_Stewart_5> yeah, that was what I just thinking about
< Chris_Stewart_5> What is the relative cost of a SHA256(SHA256()) compared to an ECDSA signature verification?
< Chris_Stewart_5> because if i'm understanding this correctly, to store that block we need to still build the merkle tree to check POW validity
< sipa> an ecdsa verification is equivalent to hashing around 15kB
< GitHub107> [bitcoin] jonnynewbs opened pull request #8747: [rpc] Fix transaction size comments and RPC help text. (master...rpc_comments) https://github.com/bitcoin/bitcoin/pull/8747
< Chris_Stewart_5> much cheaper i guess, haha.
< jl2012> why SIGPUSHONLY is not a policy?
< luke-jr> ?
< sipa> it is part of strictenc, no?
< luke-jr> Author: Johnson Lau <jl2012@users.noreply.github.com>
< luke-jr> jl2012: is this intentional?
< luke-jr> jonasschnelli: no
< luke-jr> are we closing nested templates with >> now? is that safe?
< sipa> yes
< sipa> it's required to be supported by c++11
< sipa> you can't do it in c++03, as the lexer is required by the standard there to treat >> is a single token
< sipa> also, (personal opinion on style), i despise '> >'.
< luke-jr> >.>
< midnightmagic> that's 1940s /w 2
< midnightmagic> :-( sorry.