< 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
< 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 54.199.196.58.. 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?
< 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 '> >'.