--- Day changed Mon Jun 27 2016
00:24 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection]
00:51 -!- molly [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
00:51 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev
00:51 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Read error: Connection reset by peer]
00:54 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-kzcybxcrbvfkhigv] has joined #bitcoin-core-dev
00:54 -!- molz [~molly@unaffiliated/molly] has quit [Ping timeout: 246 seconds]
00:54 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev
00:54 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Read error: Connection reset by peer]
00:55 -!- AaronvanW [~ewout@172pc231.sshunet.nl] has joined #bitcoin-core-dev
00:55 -!- AaronvanW [~ewout@172pc231.sshunet.nl] has quit [Changing host]
00:55 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
00:55 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev
00:58 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-core-dev
01:41 -!- jannes [~jannes@178.132.211.90] has joined #bitcoin-core-dev
02:13 -!- pedrobranco [~pedrobran@79.242.108.93.rev.vodafone.pt] has joined #bitcoin-core-dev
02:17 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev
02:47 < sipa> compiling bitcoind with -flto -O2 -g0 results in a 1.42x smaller binary than just -O2 -g0
02:47 < sipa> (dynamically linked)
02:47 < sipa> i haven't benchmarked to see if there is any performance difference
02:50 <@wumpus> lto also improves memory usage during compilation. But memory usage during linking was pretty bad.
02:50 < sipa> it is hard to compile though... it seems ./configure does not allow setting gcc-ar as ar binary
02:51 <@wumpus> we've been considering using it for gitian at some point, no idea why we don't yet
02:52 <@wumpus> $1/configure --with-incompatible-bdb  CC="${CLANGPATH}/bin/clang " CXX="${CLANGPATH}/bin/clang++" \
02:52 <@wumpus>     OBJCXX="${CLANGPATH}/bin/clang++" \
02:52 <@wumpus>     AR="${CLANGPATH}/bin/llvm-ar" RANLIB="${CLANGPATH}/bin/llvm-ranlib" \
02:52 <@wumpus>     CFLAGS="-flto -O2 -ggdb" CXXFLAGS="-flto -O2 -ggdb" LDFLAGS="-flto -O2 -ggdb -fuse-ld=gold"
02:52 <@wumpus> that's my configure line for clang lto
02:52 <@wumpus> gcc should be similar?
02:53 <@wumpus> the leveldb sub-build used to break overriding AR, but now that it is integrated it just works
02:53 < sipa> ah, the env variables go after ./confiugre?
02:54 <@wumpus> the 'official' convention is to put them after, yes, I don't know if it makes a difference in practice
02:54 <@wumpus> (but it would depend on the shell then)
02:54 < sipa> /usr/bin/ranlib: leveldb_libleveldb_a-filter_block.o: plugin needed to handle lto object
02:55 < sipa> ah wait
02:55 <@wumpus> and you do overlload ranlib?
02:56 < sipa> i set RANLIB=gcc-ranlib, not the full path
02:56 <@wumpus> well if you have only one and it is in your path, that should be ok
02:56 <@wumpus> I provide full paths because I have multiple toolchains installed, which aren't in the path
02:57 -!- jtimon [~quassel@217.31.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev
02:57 <@wumpus> so if it doesn't use your ranlib if you do RANLIB=xxx that's a build system bug
02:58 < sipa> lto memory usage has been significantly improved after 4.8 though
02:59 <@wumpus> yes, for 0.14 we should upgrade the build image to ubuntu 16.04, which has gcc 5.3.x
03:00 < sipa> from gcc 4.9 release notes:
03:00 < sipa> Memory usage building Firefox with debug enabled was reduced from 15GB to 3.5GB; link time from 1700 seconds to 350 seconds. 
03:05 <@wumpus> we need to upgrade the toolchain for windows too: https://github.com/bitcoin/bitcoin/pull/8249
03:05 < sipa> building with -O2 -g0 -flto here with make -j1 has max res memusage 850MiB here
03:05 < sipa> and that's during compiling of main.o, not linking
03:06 < sipa> linking has max 375MiB
03:06 < sipa> gcc 5.3.1
03:06 <@wumpus> ok, nice, so we can start recomming using lto to people that want to reduce compile memory usage and have sufficiantly new compiler
03:07 < sipa> with debug enabled it's likely more
03:07 < sipa> though debugging lto binaries is harder in any case
03:10 < sipa> trying the same without lto
03:10 < sipa> i can't imagine it to use more memory
03:11 <@wumpus> it's exactly what I expected, that compiling is faster and uses less memory with lto
03:14 < sipa> lto is purely additive at the compilation stage
03:14 < sipa> it builds normal single-object-optimized assembly output, and internal representation as well
03:14 <@wumpus> it emits intermediate code instead of processor code
03:14 <@wumpus> so can skip a step
03:15 < sipa> ah, since 4.9:
03:15 < sipa> When using a linker plugin, compiling with the -flto option now generates slim object files (.o) which only contain intermediate language representation for LTO. Use -ffat-lto-objects to create files which contain additionally the object code. To generate static libraries suitable for LTO processing, use gcc-ar and gcc-ranlib; to list symbols from a slim object file use gcc-nm. (This requires that ar, ranlib and nm have been compiled with...
03:15 <@wumpus> that's how it is for clang at least, maybe gcc is different in that regard
03:15 < sipa> plugin support.)
03:15 <@wumpus> clang -flto .o files are actually llvm bitcode
03:15 <@wumpus> ok, so gcc started doing the same
03:16 < sipa> max 995 MiB res when compiling without lto
03:18 <@wumpus> which joker is signalling TESTDUMMY on testnet? "errors": "Warning: unknown new rules activated (versionbit 28)" 
03:18 < sipa> trying with gcc 4.8 now
03:18 < sipa> no clue
03:27 < sipa> hmm, has anyone tried using the various sanitizers that gcc now has?
03:28 < sipa> -fsanitize=address -fsanitize=thread -fsanitize=leak -fsanitize=undefined
03:28 <@wumpus> I haven't
03:29 <@wumpus> would be interesting to try
03:29 < sipa> -fsanitize=address -fsanitize=thread -fsanitize=leak -fsanitize=undefini hadn't even heard about -fanitize=undefined
03:30 < sipa> i hadn't even heard about -fsanitize=undefined
03:33 -!- rimino [~rimino@2a02:587:3a12:fd00:20f6:f854:4f06:8a23] has joined #bitcoin-core-dev
03:34 -!- rimino [~rimino@2a02:587:3a12:fd00:20f6:f854:4f06:8a23] has quit [Client Quit]
03:34 -!- erasmospunk [~erasmospu@2a02:587:3a12:fd00:20f6:f854:4f06:8a23] has joined #bitcoin-core-dev
03:34 < sipa> compiling with g++-4.8 fails here:
03:34 < sipa> libbitcoin_util.a(libbitcoin_util_a-util.o): In function `boost::program_options::detail::basic_config_file_iterator<char>::getline(std::string&)':
03:35 < sipa> util.cpp:(.text._ZN5boost15program_options6detail26basic_config_file_iteratorIcE7getlineERSs[_ZN5boost15program_options6detail26basic_config_file_iteratorIcE7getlineERSs]+0x8e): undefined reference to `boost::program_options::to_internal(std::string const&)'
03:35 < sipa> i guess there is something deficient about my g++-4.8 setup
03:35 <@wumpus> my guess: ABI conflict between c++ libraries compiled with 5.3 and 4.8
03:35 <@wumpus> I'm sure compiling with 4.8 works, as it compiles fine on trusty
03:36 < sipa> yes, indeed
03:37 <@wumpus> a depends build with g++4.8 will probably also work on your system
03:37 <@wumpus> (as it has no external c++ dependencies)
03:38 <@wumpus> (and as long as you skip the GUI, building the depends is very fast)
03:39 -!- pedrobranco [~pedrobran@79.242.108.93.rev.vodafone.pt] has quit [Remote host closed the connection]
03:40 -!- pedrobranco [~pedrobran@79.242.108.93.rev.vodafone.pt] has joined #bitcoin-core-dev
03:46 -!- fengling [~fengling@58.135.95.133] has quit [Ping timeout: 240 seconds]
03:47 <@wumpus> doing a depends build with flto would be interesting as well, the final link could optimize use of all the dependencies too, although with qt that will probably be a memory explosion
03:51 -!- JackH [~Jack@79-73-186-51.dynamic.dsl.as9105.com] has joined #bitcoin-core-dev
04:03 -!- jtimon [~quassel@217.31.134.37.dynamic.jazztel.es] has quit [Read error: Connection reset by peer]
04:14 -!- fengling [~fengling@58.135.95.133] has joined #bitcoin-core-dev
04:18 < sipa> wumpus: jinx
04:18 -!- fengling [~fengling@58.135.95.133] has quit [Ping timeout: 240 seconds]
04:30 -!- Giszmo [~leo@pc-122-14-46-190.cm.vtr.net] has quit [Quit: Leaving.]
05:01 -!- erasmospunk [~erasmospu@2a02:587:3a12:fd00:20f6:f854:4f06:8a23] has quit [Quit: ttm]
05:03 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
05:09 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 260 seconds]
05:14 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
05:14 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Client Quit]
05:14 -!- cryptapus_afk is now known as cryptapus
05:15 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
05:15 -!- fengling [~fengling@58.135.95.133] has joined #bitcoin-core-dev
05:20 -!- fengling [~fengling@58.135.95.133] has quit [Ping timeout: 240 seconds]
06:05 < sdaftuar> wumpus: i assume the bit 28 activation on TESTNET is a bip109 thing (nothing to do with TESTDUMMY, which inadvertently reused the same bit)
06:05 <@wumpus> okay
06:05 < btcdrak> sdaftuar: correct.
06:08 < gmaxwell> oh I thought that was TESTDUMMY. 
06:09 < gmaxwell> if it were 109 I would have expected it to not trigger BIP9 due to the longer activation window and higher trehshold.
06:09 < gmaxwell> threshold*
06:11 < sdaftuar> it wasn't totally clear to me from the bip, but i assume the semantics specified there called for hte bit to continue to be set after activation:
06:11 < sdaftuar> Miners that support this BIP should set bit 0x10000000 in the block version until 1-Jan-2018. After that date, that bit can be safely re-used for future consensus rule upgrades.
06:13 < gmaxwell> Just so.
06:17 -!- fengling [~fengling@58.135.95.133] has joined #bitcoin-core-dev
06:19 < btcdrak> we should prolly have a switch to mute warnings we specifically want to ignore
06:19 -!- kcud_dab is now known as bad_duck
06:19 < sdaftuar> https://github.com/bitcoin/bitcoin/issues/8266
06:20 < btcdrak> oh ha! I've been too busy watching brexit :p
06:22 -!- fengling [~fengling@58.135.95.133] has quit [Ping timeout: 240 seconds]
06:22 <@wumpus> --ignore-testdummy 
06:23 <@wumpus> no, #8266 sounds better :)
06:24 < btcdrak> OP_CHECKSPATULAVERIFY <3
06:24 < sipa> ?
06:24 < btcdrak> sipa: see the ticket
06:25 < sipa> han
06:25 < sipa> ha!
06:43 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 252 seconds]
06:48 -!- zooko [~user@2601:281:8000:8387:44b0:6ae5:d06b:98c8] has joined #bitcoin-core-dev
06:52 -!- bsm1175321 is now known as bsm117532
06:56 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
07:00 < GitHub117> [bitcoin] laanwj opened pull request #8273: Bump `-dbcache` default to 300MiB (master...2016_06_dbcache) https://github.com/bitcoin/bitcoin/pull/8273
07:08 < GitHub139> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/1922e5a65458...5a06ebbf2d5f
07:08 < GitHub139> bitcoin/master 409f833 jl2012: RPC: Hide softfork if timeout is 0
07:08 < GitHub139> bitcoin/master 5a06ebb Wladimir J. van der Laan: Merge #8258: RPC: Hide softfork if timeout is 0...
07:08 < GitHub19> [bitcoin] laanwj closed pull request #8258: RPC: Hide softfork if timeout is 0 (master...bip9rpcdisable) https://github.com/bitcoin/bitcoin/pull/8258
07:16 < sipa> wumpus: how hard is it to add a python dependency? (specifically: siphash)
07:16 <@wumpus> you mean for testing? we'd prefer to not add one, a lot of people stumble on the zmq one
07:17 <@wumpus> AFAIK siphash is a single python file, why not just import it 
07:19 -!- fengling [~fengling@58.135.95.133] has joined #bitcoin-core-dev
07:21 < GitHub97> [bitcoin] laanwj closed pull request #8232: Add IRC link to README.md (master...patch-1) https://github.com/bitcoin/bitcoin/pull/8232
07:24 -!- fengling [~fengling@58.135.95.133] has quit [Ping timeout: 240 seconds]
07:25 -!- Giszmo [~leo@pc-122-14-46-190.cm.vtr.net] has joined #bitcoin-core-dev
08:03 < sipa> wumpus: ok, i'll just copy some code in
08:04 -!- Arnavion [arnavion@unaffiliated/arnavion] has quit [Quit: Arnavion]
08:04 -!- Arnavion [arnavion@unaffiliated/arnavion] has joined #bitcoin-core-dev
08:12 < dgenr8> would it not be a good idea to reserve bit 28 for sizeforks?
08:14 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has joined #bitcoin-core-dev
08:15 < paveljanik> e.g. reserve it for the softfork to 0.5M?
08:15 < paveljanik> or maybe 0.75M so we finally close these PRs to bump the default block size?
08:16 < sipa> for a hardfork you don't nedd bip9
08:16 < sipa> you can use bip 31 if you really want a means to indicate tgat the rules changed
08:19 < sipa> it's also not very relevant here: currently bit 28 is unusable for anything
08:20 -!- fengling [~fengling@58.135.95.133] has joined #bitcoin-core-dev
08:25 -!- fengling [~fengling@58.135.95.133] has quit [Ping timeout: 240 seconds]
08:26 < dgenr8> sipa: to be clear, are you saying you believe block version is unsuitable for signaling sizefork support?
08:27 < sipa> dgenr8: i believe bip9 is unsuitable for hardforks
08:29 < sipa> because it measures miner support, which is not relevant
08:30 -!- moli [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
08:31 < sipa> a hardfork is the ecosystem deciding to switch to new rules; if miners don't follow, that's their own problem
08:32 < dgenr8> so "yes" then? (since not only bip9 but anything in the block header is showing miner support)
08:32 < sipa> if for you a sizefork implies a hardfork, yes
08:32 -!- molly [~molly@unaffiliated/molly] has quit [Ping timeout: 244 seconds]
08:33 -!- Inaltoas1nistra [~jonathan@88-149-163-192.v4.ngi.it] has joined #bitcoin-core-dev
08:33 -!- Inaltoasinistra [~jonathan@212.124.183.127] has quit [Read error: Connection reset by peer]
08:36 < dgenr8> I think I detect another rabbit-hole softfork on the horizon
08:37 -!- zooko [~user@2601:281:8000:8387:44b0:6ae5:d06b:98c8] has quit [Remote host closed the connection]
08:38 -!- Inaltoasinistra [~jonathan@88-149-226-189.v4.ngi.it] has joined #bitcoin-core-dev
08:39 -!- Inaltoas1nistra [~jonathan@88-149-163-192.v4.ngi.it] has quit [Ping timeout: 260 seconds]
08:45 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 272 seconds]
08:47 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
08:53 < btcdrak> dgenr8: what does that mean?
08:54 < dgenr8> I would imagine something like the old adam3us expansion blocks proposal
08:55 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-kzcybxcrbvfkhigv] has quit [Quit: Connection closed for inactivity]
09:00 < dgenr8> sipa: the ecosystem would follow miners to a larger max block size, just as they are dragged along with all the softforks
09:00 < dgenr8> With either a soft or hard fork, the effect of not following is the same: total inability to validate part of the block
09:02 < dgenr8> the best thing for bitcoin is for you guys to adopt bip109
09:03 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 240 seconds]
09:13 -!- pedrobranco [~pedrobran@79.242.108.93.rev.vodafone.pt] has quit [Remote host closed the connection]
09:14 <@wumpus> bit 28 is the tabboo bit
09:14 <@wumpus> this is not the place for hard/soft fork disussion, and certainly not block size discussions
09:15 -!- pedrobranco [~pedrobran@79.242.108.93.rev.vodafone.pt] has joined #bitcoin-core-dev
09:16 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
09:16 -!- murch [~murch@p4FE3AFB1.dip0.t-ipconnect.de] has joined #bitcoin-core-dev
09:21 <@wumpus> with the current escalating reindex times, and utxo set size, there's no manouvring room either inside or in expansion blocks to increase transaction space
09:22 -!- fengling [~fengling@58.135.95.133] has joined #bitcoin-core-dev
09:24 < GitHub29> [bitcoin] laanwj opened pull request #8274: util: Update tinyformat (master...2016_06_update_tinyformat) https://github.com/bitcoin/bitcoin/pull/8274
09:26 -!- fengling [~fengling@58.135.95.133] has quit [Ping timeout: 240 seconds]
09:36 -!- afk11 [~afk11@109.255.154.81] has joined #bitcoin-core-dev
09:36 -!- afk11 [~afk11@109.255.154.81] has quit [Changing host]
09:36 -!- afk11 [~afk11@unaffiliated/afk11] has joined #bitcoin-core-dev
09:54 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection]
10:07 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 246 seconds]
10:10 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
10:13 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has left #bitcoin-core-dev []
10:14 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev
10:23 -!- fengling [~fengling@58.135.95.133] has joined #bitcoin-core-dev
10:28 -!- fengling [~fengling@58.135.95.133] has quit [Ping timeout: 240 seconds]
10:40 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 260 seconds]
10:46 -!- kadoban [~mud@unaffiliated/kadoban] has joined #bitcoin-core-dev
10:51 < GitHub53> [bitcoin] btcdrak opened pull request #8275: Remove bad chain alert partition check (master...partitionalerts) https://github.com/bitcoin/bitcoin/pull/8275
10:54 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
10:58 -!- kadoban [~mud@unaffiliated/kadoban] has quit [Ping timeout: 250 seconds]
11:05 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-xqudzjtynhsxfocy] has joined #bitcoin-core-dev
11:18 -!- pedrobranco [~pedrobran@79.242.108.93.rev.vodafone.pt] has quit [Remote host closed the connection]
11:21 -!- pedrobranco [~pedrobran@79.242.108.93.rev.vodafone.pt] has joined #bitcoin-core-dev
11:21 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 272 seconds]
11:24 -!- fengling [~fengling@58.135.95.133] has joined #bitcoin-core-dev
11:25 -!- pedrobranco [~pedrobran@79.242.108.93.rev.vodafone.pt] has quit [Ping timeout: 258 seconds]
11:27 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
11:29 -!- fengling [~fengling@58.135.95.133] has quit [Ping timeout: 240 seconds]
11:31 -!- Giszmo [~leo@pc-122-14-46-190.cm.vtr.net] has quit [Ping timeout: 276 seconds]
11:38 -!- pedrobranco [~pedrobran@167.225.61.94.rev.vodafone.pt] has joined #bitcoin-core-dev
11:42 -!- pedrobranco [~pedrobran@167.225.61.94.rev.vodafone.pt] has quit [Ping timeout: 258 seconds]
11:50 -!- Giszmo [~leo@pc-122-14-46-190.cm.vtr.net] has joined #bitcoin-core-dev
12:02 -!- molz [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
12:04 -!- moli [~molly@unaffiliated/molly] has quit [Ping timeout: 244 seconds]
12:18 < gmaxwell> wumpus: So I made this change:
12:18 < gmaxwell> +    nCacheSize = std::min(nCacheSize,(size_t)1024*1024);
12:18 < gmaxwell> in dbwrapper.cpp GetOptions
12:19 < gmaxwell> and a reindex with no txindex, and no signature checking went from 31021.760436 seconds before to 31360.383818000002 seconds after.
12:20 < gmaxwell> (dbcache settings default)
12:20 < gmaxwell> so I think this suggests the leveldb cache is doing almost nothing.
12:20 < gmaxwell> it's a 1% difference to go from the defaults to 1MB. 
12:22 < gmaxwell> going to try 2mb now and see if I can turn that into almost nothing.
12:26 -!- fengling [~fengling@58.135.95.133] has joined #bitcoin-core-dev
12:31 -!- fengling [~fengling@58.135.95.133] has quit [Ping timeout: 240 seconds]
12:32 < sipa> gmaxwell: with what dbcache size was your benchmark?
12:33 < sipa> my guess is that the leveldb cache becomes relatively less important as the chainstate cache grows
12:34 < gmaxwell> sipa: the default.
12:35 < gmaxwell> my plan was to determine if leveldb cache could be radically reduced without harming performance. Then give over all that memory to the coincache.
12:51 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 276 seconds]
13:07 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
13:12 -!- Guest23955 [~chatzilla@71-95-217-105.static.mtpk.ca.charter.com] has joined #bitcoin-core-dev
13:13 -!- Guest23955 is now known as roidster
13:16 -!- CubicEarth [~cubiceart@c-50-159-126-21.hsd1.wa.comcast.net] has joined #bitcoin-core-dev
13:19 < morcos> wumpus: RE: #8273: FWIW, I was the one I think who advocated for 300MB for the mempool and I now think that is more than is really necessary.
13:19 < morcos> I haven't seen if the ratio to wire size vs memory size has changed substantially with all the recent mempool changes, but previously 300MB of mempool was roughly 100MB of wire bytes.  I think thats a larger backlog than is necessary to handle normal operation.
13:20 < morcos> Although lowering that is something that may warrant a bit of testing.  There can be these weird feedback loops with eviction and tx time outs, and I wouldn't be sure that say 100MB mempool wouldn't somehow lead to worse network behavior.
13:23 < gmaxwell> morcos: it changed substantially.
13:23 < gmaxwell> it's about 150mb now.
13:25 < morcos> oh, its that much more efficient?  that's nice.  anyway, i'm just mentioning this, b/c i thought i saw discussion about potentially lowering maxmempool in conjunction with raising dbcache in order to not overly affect the total mem footprint.  i'd agree with doing that.
13:25 < gmaxwell>   "bytes": 149293989,
13:25 < gmaxwell>   "usage": 274484752,
13:27 < gmaxwell> for CPFP to work though it does need to be a fair bit bigger than it would otherwise.
13:27 -!- fengling [~fengling@58.135.95.133] has joined #bitcoin-core-dev
13:28 < morcos> gmaxwell: well i should look again, but last time i looked, i never saw it go over 100M of usage for things that weren't spam (defined as those 14kB tx that paid 15000 satoshis in fee)
13:29 < morcos> of course there was occasionally legitmate free or min fee rate txs mixed in with the spam.  but no size mempool will be big enough to reliably include those if they aren't paying higher price thant he spam
13:29 < gmaxwell> A useful question is, what is the probablity that a txn confirms during a measurement window, as a function of the worst 'depth' it expirenced in the mempool. 
13:30 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 260 seconds]
13:31 < morcos> I guess what I'm saying put another way is that any tx paying <= 1 sat per byte had an extremely variable chance of ever being confirmed at all
13:32 < morcos> Tx's paying > 1 sat per byte may be interesting to study more, but they seem to have always fit in a 100MB (usage) mempool.
13:32 < morcos> At least thats my casual observation
13:32 -!- fengling [~fengling@58.135.95.133] has quit [Ping timeout: 240 seconds]
13:33 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
13:56 -!- jannes [~jannes@178.132.211.90] has quit [Quit: Leaving]
13:59 -!- whphhg [whphhg@gateway/vpn/mullvad/x-itayxzjdvtjselou] has quit [Quit: Leaving]
14:02 -!- whphhg [whphhg@gateway/vpn/mullvad/x-crratuutxgattqxw] has joined #bitcoin-core-dev
14:06 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 276 seconds]
14:21 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
14:24 -!- grubles is now known as dingus
14:29 -!- fengling [~fengling@58.135.95.133] has joined #bitcoin-core-dev
14:34 -!- fengling [~fengling@58.135.95.133] has quit [Ping timeout: 240 seconds]
14:58 -!- Giszmo [~leo@pc-122-14-46-190.cm.vtr.net] has quit [Ping timeout: 246 seconds]
14:59 -!- Giszmo [~leo@pc-122-14-46-190.cm.vtr.net] has joined #bitcoin-core-dev
15:08 -!- dingus is now known as grubles
15:14 -!- moli [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
15:17 -!- molz [~molly@unaffiliated/molly] has quit [Ping timeout: 240 seconds]
15:22 -!- adamg [~akg@50.242.93.33] has quit [Ping timeout: 276 seconds]
15:25 -!- adamg [~akg@50.242.93.33] has joined #bitcoin-core-dev
15:30 -!- kadoban [~mud@unaffiliated/kadoban] has joined #bitcoin-core-dev
15:30 -!- fengling [~fengling@58.135.95.133] has joined #bitcoin-core-dev
15:35 -!- fengling [~fengling@58.135.95.133] has quit [Ping timeout: 240 seconds]
15:37 -!- murch [~murch@p4FE3AFB1.dip0.t-ipconnect.de] has quit [Ping timeout: 276 seconds]
15:37 -!- murch [~murch@p4FE3A24B.dip0.t-ipconnect.de] has joined #bitcoin-core-dev
15:39 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)]
15:41 -!- cryptapus is now known as cryptapus_afk
15:43 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev
15:48 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has quit [Ping timeout: 276 seconds]
15:49 -!- murch [~murch@p4FE3A24B.dip0.t-ipconnect.de] has quit [Ping timeout: 246 seconds]
15:53 -!- murch [~murch@p4FE390CA.dip0.t-ipconnect.de] has joined #bitcoin-core-dev
15:57 -!- murch [~murch@p4FE390CA.dip0.t-ipconnect.de] has quit [Ping timeout: 244 seconds]
15:59 -!- murch [~murch@p4FE38DE7.dip0.t-ipconnect.de] has joined #bitcoin-core-dev
16:03 -!- murch1 [~murch@p4FE3AF9B.dip0.t-ipconnect.de] has joined #bitcoin-core-dev
16:04 -!- murch [~murch@p4FE38DE7.dip0.t-ipconnect.de] has quit [Ping timeout: 272 seconds]
16:10 -!- murch1 [~murch@p4FE3AF9B.dip0.t-ipconnect.de] has quit [Ping timeout: 272 seconds]
16:11 -!- murch [~murch@p4FE3B323.dip0.t-ipconnect.de] has joined #bitcoin-core-dev
16:32 -!- fengling [~fengling@58.135.95.133] has joined #bitcoin-core-dev
16:37 -!- fengling [~fengling@58.135.95.133] has quit [Ping timeout: 240 seconds]
17:01 -!- pedrobranco [~pedrobran@167.225.61.94.rev.vodafone.pt] has joined #bitcoin-core-dev
17:05 -!- pedrobranco [~pedrobran@167.225.61.94.rev.vodafone.pt] has quit [Ping timeout: 244 seconds]
17:12 -!- fengling [~fengling@58.135.95.133] has joined #bitcoin-core-dev
17:45 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 246 seconds]
17:45 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-xqudzjtynhsxfocy] has quit [Quit: Connection closed for inactivity]
18:10 -!- xiangfu [~xiangfu@58.135.95.134] has joined #bitcoin-core-dev
18:43 -!- murch [~murch@p4FE3B323.dip0.t-ipconnect.de] has quit [Quit: Leaving.]
18:54 -!- justanotheruser [~Justan@unaffiliated/justanotheruser] has quit [Read error: Connection reset by peer]
18:54 -!- justanotheruser [~Justan@unaffiliated/justanotheruser] has joined #bitcoin-core-dev
18:55 -!- Giszmo [~leo@pc-122-14-46-190.cm.vtr.net] has quit [Ping timeout: 276 seconds]
19:08 -!- Giszmo [~leo@pc-122-14-46-190.cm.vtr.net] has joined #bitcoin-core-dev
19:24 -!- fanquake [~Adium@unaffiliated/fanquake] has joined #bitcoin-core-dev
19:25 -!- fanquake [~Adium@unaffiliated/fanquake] has quit [Client Quit]
21:14 -!- fengling [~fengling@58.135.95.133] has quit [Ping timeout: 240 seconds]
21:46 -!- fengling [~fengling@58.135.95.133] has joined #bitcoin-core-dev
22:26 < GitHub184> [bitcoin] pstratem opened pull request #8277: Refactor CBlockHeaderAndShortTxIDs::GetShortID into CTransaction (master...2016-06-26-ctransaction-getshortid) https://github.com/bitcoin/bitcoin/pull/8277
22:29 -!- Cory [~C@unaffiliated/cory] has quit [Ping timeout: 260 seconds]
22:51 -!- Cory [~C@unaffiliated/cory] has joined #bitcoin-core-dev
22:55 -!- Giszmo [~leo@pc-122-14-46-190.cm.vtr.net] has quit [Quit: Leaving.]
23:23 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
23:24 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
23:33 -!- tincap [6a331e9c@gateway/web/freenode/ip.106.51.30.156] has joined #bitcoin-core-dev
23:34 -!- tincap [6a331e9c@gateway/web/freenode/ip.106.51.30.156] has quit [Client Quit]
23:40 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection]