< iniana> phantomcircuit, gmaxwell: Tried synching from scratch in a clean dir, but it is just as slow. I am wondering if it has something to do with the fact that I am running it in a Qubes AppVM. Funny thing is I was synching another (pruned) node from scratch in a whonix (tor-only) VM, and it went unexpectedly fast. Though that VM had the blockchain stored on an SSD.
< gmaxwell> iniana: syncing from scratch with your dbcache increased?
< iniana> gmaxwell: yes, lowered it from 4k to 2k when I realized I only had 4G of memory assigned to the VM
< iniana> the tor VM had default dbcache
< gmaxwell> with a dbcache of 2000 its unlikely that your slowness is related to disk io... but perhaps the vm is just doing something awful.
< iniana> gmaxwell: yeah, will try the fedora-based VM instead of Debian and see if that makes a difference
< tbear> If a bitcoin transaction is stuck from low payout fee like .0000012 how long should I wait before doing something plz? been 3 days thx
< tbear> hi lowest payouts should be where transaction doesn't get stuck
< tbear> If a bitcoin transaction is stuck from low payout fee like .0000012 how long should I wait before doing something plz? been 3 days thx
< instagibbs> tbear, #bitcoin is a better venue for this question
< tbear> thx nobody replied
< instagibbs> well it's off-topic here sorry
< tbear> lowest payouts should be where transaction doesn't get stuck
< tbear> ok thx bye geese
< instagibbs> I am not a gaggle of geese
< GitHub92> [bitcoin] sipa pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/862fd24b40b4...58f0c929a3d7
< GitHub92> bitcoin/master e4f73c7 fanquake: [Doc] Update implemented BIPs list
< GitHub92> bitcoin/master 58f0c92 Pieter Wuille: Merge #8121: [Doc] Update implemented BIPs list...
< GitHub78> [bitcoin] sipa closed pull request #8121: [Doc] Update implemented BIPs list (master...missing_bips) https://github.com/bitcoin/bitcoin/pull/8121
< GitHub3> [bitcoin] sipa pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/58f0c929a3d7...01d8359983e2
< GitHub3> bitcoin/master 4d8993b Gregory Maxwell: Defer inserting into maprelay until just before relaying....
< GitHub3> bitcoin/master 01d8359 Pieter Wuille: Merge #8082: Defer inserting into maprelay until just before relaying....
< GitHub19> [bitcoin] sipa closed pull request #8082: Defer inserting into maprelay until just before relaying. (master...just_in_time_maprelay) https://github.com/bitcoin/bitcoin/pull/8082
< GitHub68> [bitcoin] sipa pushed 13 new commits to master: https://github.com/bitcoin/bitcoin/compare/01d8359983e2...b89ef131147f
< GitHub68> bitcoin/master a545127 Pieter Wuille: Squashed 'src/crypto/ctaes/' content from commit cd3c3ac...
< GitHub68> bitcoin/master cd2be44 Pieter Wuille: Merge commit 'a545127fbccef4ee674d18d43732ce00ba97f782' as 'src/crypto/ctaes'
< GitHub68> bitcoin/master 6bec172 Pieter Wuille: Add ctaes-based constant time AES implementation
< GitHub164> [bitcoin] sipa closed pull request #7689: Replace OpenSSL AES with ctaes-based version (master...const_aes) https://github.com/bitcoin/bitcoin/pull/7689
< GitHub44> [bitcoin] sipa pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/b89ef131147f...6a22373771ed
< GitHub44> bitcoin/master 383fc10 Suhas Daftuar: Only use AddInventoryKnown for transactions...
< GitHub44> bitcoin/master 6a22373 Pieter Wuille: Merge #7960: Only use AddInventoryKnown for transactions...
< GitHub91> [bitcoin] sipa closed pull request #7960: Only use AddInventoryKnown for transactions (master...block-inv-filter) https://github.com/bitcoin/bitcoin/pull/7960
< gmaxwell> sipa: now that ctaes is in, are we only left the RNG stopping the removal of openssl in bitcoind?
< sipa> yes
< gmaxwell> next step in that would be getting in a seeder, I guess.
< GitHub178> [bitcoin] sipa pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/6a22373771ed...7fa8d7585984
< GitHub178> bitcoin/master 88f14b9 Pieter Wuille: Include signal.h for sig_atomic_t in WIN32
< GitHub178> bitcoin/master 7fa8d75 Pieter Wuille: Merge #8112: Include signal.h for sig_atomic_t in WIN32...
< GitHub5> [bitcoin] kazcw closed pull request #8052: rpc tests: increase http timeout (master...rpcwallet-test-timeout) https://github.com/bitcoin/bitcoin/pull/8052
< cfields_> luke-jr: thanks, will take a look. Pretty sure I'm happy now though.
< sipa> luke-jr: why are you excess flood'ing all the time? :)
< luke-jr> sipa: TCP packet gets lost, waits for re-xmit, freenode reassembles that packet + the packets following it and decides it's too much "at once"
< luke-jr> makes me wonder if I should just hack my router to send all TCP packets twice
< luke-jr> looks like i have ~20% packet loss over IPv6 only at the moment :/
< sipa> ouch
< midnightmagic> You finally solved that problem?
< luke-jr> midnightmagic: solved what?
< sipa> jonasschnelli: ask instagibbs
< jonasschnelli> sipa: you mean why AddKeyPubKey instead of AddKey?
< sipa> jonasschnelli: yes
< jonasschnelli> sipa: Yes. Should also be possible. :)
< jonasschnelli> AddKeyPubKey is virtual so,... yes. Let me change this
< sipa> AddKey is also virtual
< jonasschnelli> sipa: wait. There is a reason for AddKeyPubKey
< jonasschnelli> CKey.GetPubKey() does not cache
< sipa> updated my comment, thanks :)
< jonasschnelli> sipa: "Agree about adding a named constant." -> do you mean using a constant for 0x80000000?
< sipa> yes
< jonasschnelli> sipa: Or i could use the same style you used in key.cpp (if ((nChild >> 31) == 0) {)
< jonasschnelli> though, I'm in favor of | 0x80000000
< sipa> a named constant is most readable :)
< instagibbs> oh that comment was quite a while ago, but i was wrong, I distinctly remember :)
< jonasschnelli> instagibbs: you where right... but you where wrong saying you where wrong. :)
< instagibbs> oh yeah, I think sipa had it right
< midnightmagic> luke-jr: or at least analyzed it. the constant excess flooding
< luke-jr> midnightmagic: it's mostly an educated guess right now
< midnightmagic> the retransmit period should be fast enough to handle one or two missing packets occasionally
< GitHub165> [bitcoin] sipa pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/7fa8d7585984...2e0a99037dcc
< GitHub165> bitcoin/master 16cf85f Pieter Wuille: Revert "Include signal.h for sig_atomic_t in WIN32"...
< GitHub165> bitcoin/master a886dbf Pieter Wuille: Use std::atomic for fRequestShutdown and fReopenDebugLog
< GitHub165> bitcoin/master 2e0a990 Pieter Wuille: Merge #8123: Use std::atomic for fRequestShutdown and fReopenDebugLog...
< GitHub26> [bitcoin] sipa closed pull request #8123: Use std::atomic for fRequestShutdown and fReopenDebugLog (master...notsigbutatomic) https://github.com/bitcoin/bitcoin/pull/8123
< GitHub116> [bitcoin] sipa pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/2e0a99037dcc...715e9fd7454f
< GitHub116> bitcoin/master ee9f4a5 Jorge Timón: Consensus: Decouple from chainparams.o and timedata.o...
< GitHub116> bitcoin/master 715e9fd Pieter Wuille: Merge #8077: Consensus: Decouple from chainparams.o and timedata.o...
< GitHub45> [bitcoin] sipa closed pull request #8077: Consensus: Decouple from chainparams.o and timedata.o (master...0.12-consensus-chainparams) https://github.com/bitcoin/bitcoin/pull/8077
< GitHub127> [bitcoin] MarcoFalke closed pull request #7947: Global params cleanup (master...global-params-cleanup) https://github.com/bitcoin/bitcoin/pull/7947
< GitHub109> [bitcoin] luke-jr opened pull request #8132: wallet: Add key generation type (master...keygentype) https://github.com/bitcoin/bitcoin/pull/8132
< GitHub27> [bitcoin] MarcoFalke closed pull request #7985: [Consensus] Add nAdjustedTime parameter to CheckBlock and CheckBlockHeader. (master...2016-05-01-checkblock-header) https://github.com/bitcoin/bitcoin/pull/7985
< gmaxwell> Whats the minimum ubuntu release to build master with now (with the C++11 requirement)
< sipa> 14.04 lts works
< gmaxwell> Does 13 not work?
< sipa> it may, but i don't see a way to search its repository
< sipa> precise (12.04) has gcc 4.7
< sipa> i think we use features from 4.8 though
< gmaxwell> it looks like our test doesn't work with 4.7. So 12.x is no, 14.x is yes. And 13 is dunno.
< sipa> maybe not
< sipa> well 13 is not supported anymore
< sipa> 12.04 and 14.04 are
< btcdrak> petrov is having dependency issues, not sure which version of Ubuntu
< sipa> maybe the configure test is too strong
< sipa> because it tests for full c++11 language support
< sipa> but the only thing we may be using in 4.8 is inheriting constructors
< sipa> i don't think we use thread local storage yet
< sipa> so i think 4.7 may work, if we'd disable the test
< btcdrak> cfields_: ping ^
< cfields_> i believe 4.7 was missing a few pretty major things. atomics, maybe?
< btcdrak> ok so he needs gcc 4.8 in that case.
< cfields_> don't quote me on that. checking.
< sipa> some tweaks to the memory model were made in 4.8 still
< sipa> but atomics exist since 4.4
< cfields_> ah right, thread_local in 4.8
< cfields_> btcdrak: fwiw, i'm able to compile w/ my ancient raring install. I'm unsure if I grabbed the toolchain from a ppa, or if it exists in-repo
< cfields_> btcdrak: either way, if gcc-4.8/g++-4.8 are installed, you can just use: ./configure CXX=g++-4.8 CC=gcc-4.8
< gmaxwell> we may want to write some instructions for users on somewhat older systems.
< sipa> cfields_: raring is 13.04
< sipa> right?
< cfields_> it'd likely be easier to get someone building with clang, since those get backported more often. iirc clang 3.3 is enough.
< cfields_> sipa: yep. like i said though, i'm unsure if the gcc-4.8 here came from the ubuntu repos. checking.
< sipa> clang 3.1 is likely even enough, as long as we don't use tls
< cfields_> haven't we merged some of the tls PRs already?
< sipa> not afaik
< cfields_> ah
< sipa> nope
< sipa> 8007 did, but got changed to using atomics instead
< cfields_> ah damn, looks like my 4.8 came from a ppa
< cfields_> I think i'd be uneasy recommending 4.7 though. That'd mean we're walking on eggshells.
< gmaxwell> I'm much happier with GCC 4.8 in general.
< gmaxwell> does setban not disconnect newly banned peers?
< sipa> seems not
< sipa> but there is disconnectnode
< gmaxwell> help on disconnect node is not very helpful. the argument is "the node"
< gmaxwell> like, do I digitize the whole peer and provide it in hex on the commandline? :)
< gmaxwell> apparently it wants the fully qualified inbound address and port.
< GitHub51> [bitcoin] theuni opened pull request #8133: build: Finish up out-of-tree changes (master...out-of-tree-clean) https://github.com/bitcoin/bitcoin/pull/8133