12016-06-27T00:07:44 *** Guyver2 has quit IRC
22016-06-27T00:15:40 *** Chris_Stewart_5 has joined #bitcoin-core-dev
32016-06-27T00:31:05 *** murch has quit IRC
42016-06-27T00:32:33 *** AaronvanW has quit IRC
52016-06-27T00:38:36 *** JackH has quit IRC
62016-06-27T00:42:12 *** Chris_Stewart_5 has quit IRC
72016-06-27T00:43:06 *** Chris_Stewart_5 has joined #bitcoin-core-dev
82016-06-27T00:43:36 *** justanotheruser is now known as UnderCoder
92016-06-27T00:47:10 *** UnderCoder is now known as justanotheruser
102016-06-27T00:48:41 *** Chris_Stewart_5 has quit IRC
112016-06-27T01:05:36 *** Chris_Stewart_5 has joined #bitcoin-core-dev
122016-06-27T01:19:33 *** belcher has quit IRC
132016-06-27T01:19:55 *** jtimon has quit IRC
142016-06-27T01:25:45 *** Ylbam has quit IRC
152016-06-27T01:35:12 *** Chris_Stewart_5 has quit IRC
162016-06-27T01:36:03 *** fengling has joined #bitcoin-core-dev
172016-06-27T02:05:45 *** Chris_Stewart_5 has joined #bitcoin-core-dev
182016-06-27T02:06:28 *** adiabat has quit IRC
192016-06-27T02:12:38 *** molz has joined #bitcoin-core-dev
202016-06-27T02:15:51 *** moli has quit IRC
212016-06-27T02:23:42 *** Chris_Stewart_5 has quit IRC
222016-06-27T03:31:18 *** harrymm has quit IRC
232016-06-27T03:49:07 *** harrymm has joined #bitcoin-core-dev
242016-06-27T03:59:24 *** Giszmo has joined #bitcoin-core-dev
252016-06-27T04:12:31 *** challisto has quit IRC
262016-06-27T04:14:31 *** harrymm has quit IRC
272016-06-27T04:36:05 *** harrymm has joined #bitcoin-core-dev
282016-06-27T04:37:06 *** fengling has quit IRC
292016-06-27T04:47:17 *** fengling has joined #bitcoin-core-dev
302016-06-27T04:59:06 *** fengling has quit IRC
312016-06-27T05:29:07 *** fengling has joined #bitcoin-core-dev
322016-06-27T05:30:22 *** kadoban has joined #bitcoin-core-dev
332016-06-27T05:38:52 *** gabridome has quit IRC
342016-06-27T05:39:26 *** Alopex has quit IRC
352016-06-27T05:40:23 *** gabridome has joined #bitcoin-core-dev
362016-06-27T05:40:31 *** Alopex has joined #bitcoin-core-dev
372016-06-27T05:43:54 *** Anduck has quit IRC
382016-06-27T05:58:04 *** paveljanik has quit IRC
392016-06-27T06:19:52 *** kadoban has quit IRC
402016-06-27T07:24:26 *** BashCo has quit IRC
412016-06-27T07:51:12 *** molly has joined #bitcoin-core-dev
422016-06-27T07:51:13 *** BashCo has joined #bitcoin-core-dev
432016-06-27T07:51:48 *** BashCo has quit IRC
442016-06-27T07:54:04 *** Ylbam has joined #bitcoin-core-dev
452016-06-27T07:54:15 *** molz has quit IRC
462016-06-27T07:54:26 *** BashCo has joined #bitcoin-core-dev
472016-06-27T07:54:45 *** BashCo has quit IRC
482016-06-27T07:55:18 *** AaronvanW has joined #bitcoin-core-dev
492016-06-27T07:55:18 *** AaronvanW has quit IRC
502016-06-27T07:55:18 *** AaronvanW has joined #bitcoin-core-dev
512016-06-27T07:55:25 *** BashCo has joined #bitcoin-core-dev
522016-06-27T07:58:15 *** paveljanik has joined #bitcoin-core-dev
532016-06-27T08:41:10 *** jannes has joined #bitcoin-core-dev
542016-06-27T09:13:12 *** pedrobranco has joined #bitcoin-core-dev
552016-06-27T09:17:39 *** Guyver2 has joined #bitcoin-core-dev
562016-06-27T09:47:07 <sipa> compiling bitcoind with -flto -O2 -g0 results in a 1.42x smaller binary than just -O2 -g0
572016-06-27T09:47:28 <sipa> (dynamically linked)
582016-06-27T09:47:29 <sipa> i haven't benchmarked to see if there is any performance difference
592016-06-27T09:50:41 <wumpus> lto also improves memory usage during compilation. But memory usage during linking was pretty bad.
602016-06-27T09:50:54 <sipa> it is hard to compile though... it seems ./configure does not allow setting gcc-ar as ar binary
612016-06-27T09:51:33 <wumpus> we've been considering using it for gitian at some point, no idea why we don't yet
622016-06-27T09:52:34 <wumpus> $1/configure --with-incompatible-bdb CC="${CLANGPATH}/bin/clang " CXX="${CLANGPATH}/bin/clang++" \
632016-06-27T09:52:35 <wumpus> OBJCXX="${CLANGPATH}/bin/clang++" \
642016-06-27T09:52:35 <wumpus> AR="${CLANGPATH}/bin/llvm-ar" RANLIB="${CLANGPATH}/bin/llvm-ranlib" \
652016-06-27T09:52:35 <wumpus> CFLAGS="-flto -O2 -ggdb" CXXFLAGS="-flto -O2 -ggdb" LDFLAGS="-flto -O2 -ggdb -fuse-ld=gold"
662016-06-27T09:52:42 <wumpus> that's my configure line for clang lto
672016-06-27T09:52:49 <wumpus> gcc should be similar?
682016-06-27T09:53:46 <wumpus> the leveldb sub-build used to break overriding AR, but now that it is integrated it just works
692016-06-27T09:53:47 <sipa> ah, the env variables go after ./confiugre?
702016-06-27T09:54:16 <wumpus> the 'official' convention is to put them after, yes, I don't know if it makes a difference in practice
712016-06-27T09:54:26 <wumpus> (but it would depend on the shell then)
722016-06-27T09:54:37 <sipa> /usr/bin/ranlib: leveldb_libleveldb_a-filter_block.o: plugin needed to handle lto object
732016-06-27T09:55:26 <sipa> ah wait
742016-06-27T09:55:28 <wumpus> and you do overlload ranlib?
752016-06-27T09:56:25 <sipa> i set RANLIB=gcc-ranlib, not the full path
762016-06-27T09:56:39 <wumpus> well if you have only one and it is in your path, that should be ok
772016-06-27T09:56:55 <wumpus> I provide full paths because I have multiple toolchains installed, which aren't in the path
782016-06-27T09:57:07 *** jtimon has joined #bitcoin-core-dev
792016-06-27T09:57:44 <wumpus> so if it doesn't use your ranlib if you do RANLIB=xxx that's a build system bug
802016-06-27T09:58:48 <sipa> lto memory usage has been significantly improved after 4.8 though
812016-06-27T09:59:44 <wumpus> yes, for 0.14 we should upgrade the build image to ubuntu 16.04, which has gcc 5.3.x
822016-06-27T10:00:05 <sipa> from gcc 4.9 release notes:
832016-06-27T10:00:06 <sipa> Memory usage building Firefox with debug enabled was reduced from 15GB to 3.5GB; link time from 1700 seconds to 350 seconds.
842016-06-27T10:05:27 <wumpus> we need to upgrade the toolchain for windows too: https://github.com/bitcoin/bitcoin/pull/8249
852016-06-27T10:05:38 <sipa> building with -O2 -g0 -flto here with make -j1 has max res memusage 850MiB here
862016-06-27T10:05:51 <sipa> and that's during compiling of main.o, not linking
872016-06-27T10:06:00 <sipa> linking has max 375MiB
882016-06-27T10:06:18 <sipa> gcc 5.3.1
892016-06-27T10:06:36 <wumpus> ok, nice, so we can start recomming using lto to people that want to reduce compile memory usage and have sufficiantly new compiler
902016-06-27T10:07:06 <sipa> with debug enabled it's likely more
912016-06-27T10:07:25 <sipa> though debugging lto binaries is harder in any case
922016-06-27T10:10:26 <sipa> trying the same without lto
932016-06-27T10:10:43 <sipa> i can't imagine it to use more memory
942016-06-27T10:11:59 <wumpus> it's exactly what I expected, that compiling is faster and uses less memory with lto
952016-06-27T10:14:16 <sipa> lto is purely additive at the compilation stage
962016-06-27T10:14:42 <sipa> it builds normal single-object-optimized assembly output, and internal representation as well
972016-06-27T10:14:52 <wumpus> it emits intermediate code instead of processor code
982016-06-27T10:14:55 <wumpus> so can skip a step
992016-06-27T10:15:09 <sipa> ah, since 4.9:
1002016-06-27T10:15:11 <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...
1012016-06-27T10:15:12 <wumpus> that's how it is for clang at least, maybe gcc is different in that regard
1022016-06-27T10:15:17 <sipa> plugin support.)
1032016-06-27T10:15:27 <wumpus> clang -flto .o files are actually llvm bitcode
1042016-06-27T10:15:58 <wumpus> ok, so gcc started doing the same
1052016-06-27T10:16:19 <sipa> max 995 MiB res when compiling without lto
1062016-06-27T10:18:30 <wumpus> which joker is signalling TESTDUMMY on testnet? "errors": "Warning: unknown new rules activated (versionbit 28)"
1072016-06-27T10:18:36 <sipa> trying with gcc 4.8 now
1082016-06-27T10:18:40 <sipa> no clue
1092016-06-27T10:27:43 <sipa> hmm, has anyone tried using the various sanitizers that gcc now has?
1102016-06-27T10:28:08 <sipa> -fsanitize=address -fsanitize=thread -fsanitize=leak -fsanitize=undefined
1112016-06-27T10:28:58 <wumpus> I haven't
1122016-06-27T10:29:32 <wumpus> would be interesting to try
1132016-06-27T10:29:57 <sipa> -fsanitize=address -fsanitize=thread -fsanitize=leak -fsanitize=undefini hadn't even heard about -fanitize=undefined
1142016-06-27T10:30:38 <sipa> i hadn't even heard about -fsanitize=undefined
1152016-06-27T10:33:49 *** rimino has joined #bitcoin-core-dev
1162016-06-27T10:34:27 *** rimino has quit IRC
1172016-06-27T10:34:44 *** erasmospunk has joined #bitcoin-core-dev
1182016-06-27T10:34:57 <sipa> compiling with g++-4.8 fails here:
1192016-06-27T10:34:57 <sipa> libbitcoin_util.a(libbitcoin_util_a-util.o): In function `boost::program_options::detail::basic_config_file_iterator<char>::getline(std::string&)':
1202016-06-27T10:35:01 <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&)'
1212016-06-27T10:35:13 <sipa> i guess there is something deficient about my g++-4.8 setup
1222016-06-27T10:35:39 <wumpus> my guess: ABI conflict between c++ libraries compiled with 5.3 and 4.8
1232016-06-27T10:35:50 <wumpus> I'm sure compiling with 4.8 works, as it compiles fine on trusty
1242016-06-27T10:36:16 <sipa> yes, indeed
1252016-06-27T10:37:37 <wumpus> a depends build with g++4.8 will probably also work on your system
1262016-06-27T10:37:49 <wumpus> (as it has no external c++ dependencies)
1272016-06-27T10:38:48 <wumpus> (and as long as you skip the GUI, building the depends is very fast)
1282016-06-27T10:39:53 *** pedrobranco has quit IRC
1292016-06-27T10:40:56 *** pedrobranco has joined #bitcoin-core-dev
1302016-06-27T10:46:26 *** fengling has quit IRC
1312016-06-27T10:47:22 <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
1322016-06-27T10:51:40 *** JackH has joined #bitcoin-core-dev
1332016-06-27T11:03:12 *** jtimon has quit IRC
1342016-06-27T11:14:04 *** fengling has joined #bitcoin-core-dev
1352016-06-27T11:18:23 <sipa> wumpus: jinx
1362016-06-27T11:18:46 *** fengling has quit IRC
1372016-06-27T11:30:02 *** Giszmo has quit IRC
1382016-06-27T12:01:53 *** erasmospunk has quit IRC
1392016-06-27T12:03:11 *** Chris_Stewart_5 has joined #bitcoin-core-dev
1402016-06-27T12:09:52 *** Chris_Stewart_5 has quit IRC
1412016-06-27T12:14:07 *** Chris_Stewart_5 has joined #bitcoin-core-dev
1422016-06-27T12:14:47 *** Chris_Stewart_5 has quit IRC
1432016-06-27T12:14:54 *** cryptapus_afk is now known as cryptapus
1442016-06-27T12:15:04 *** Chris_Stewart_5 has joined #bitcoin-core-dev
1452016-06-27T12:15:35 *** fengling has joined #bitcoin-core-dev
1462016-06-27T12:20:26 *** fengling has quit IRC
1472016-06-27T13:05:28 <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)
1482016-06-27T13:05:40 <wumpus> okay
1492016-06-27T13:05:46 <btcdrak> sdaftuar: correct.
1502016-06-27T13:08:38 <gmaxwell> oh I thought that was TESTDUMMY.
1512016-06-27T13:09:42 <gmaxwell> if it were 109 I would have expected it to not trigger BIP9 due to the longer activation window and higher trehshold.
1522016-06-27T13:09:49 <gmaxwell> threshold*
1532016-06-27T13:11:28 <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:
1542016-06-27T13:11:34 <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.
1552016-06-27T13:13:32 <gmaxwell> Just so.
1562016-06-27T13:17:43 *** fengling has joined #bitcoin-core-dev
1572016-06-27T13:19:32 <btcdrak> we should prolly have a switch to mute warnings we specifically want to ignore
1582016-06-27T13:19:44 *** kcud_dab is now known as bad_duck
1592016-06-27T13:19:46 <sdaftuar> https://github.com/bitcoin/bitcoin/issues/8266
1602016-06-27T13:20:20 <btcdrak> oh ha! I've been too busy watching brexit :p
1612016-06-27T13:22:26 *** fengling has quit IRC
1622016-06-27T13:22:43 <wumpus> --ignore-testdummy
1632016-06-27T13:23:01 <wumpus> no, #8266 sounds better :)
1642016-06-27T13:24:19 <btcdrak> OP_CHECKSPATULAVERIFY <3
1652016-06-27T13:24:34 <sipa> ?
1662016-06-27T13:24:45 <btcdrak> sipa: see the ticket
1672016-06-27T13:25:00 <sipa> han
1682016-06-27T13:25:02 <sipa> ha!
1692016-06-27T13:43:34 *** Chris_Stewart_5 has quit IRC
1702016-06-27T13:48:51 *** zooko has joined #bitcoin-core-dev
1712016-06-27T13:52:05 *** bsm1175321 is now known as bsm117532
1722016-06-27T13:56:46 *** Chris_Stewart_5 has joined #bitcoin-core-dev
1732016-06-27T14:00:41 <GitHub117> [bitcoin] laanwj opened pull request #8273: Bump `-dbcache` default to 300MiB (master...2016_06_dbcache) https://github.com/bitcoin/bitcoin/pull/8273
1742016-06-27T14:08:16 <GitHub139> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/1922e5a65458...5a06ebbf2d5f
1752016-06-27T14:08:16 <GitHub139> bitcoin/master 409f833 jl2012: RPC: Hide softfork if timeout is 0
1762016-06-27T14:08:17 <GitHub139> bitcoin/master 5a06ebb Wladimir J. van der Laan: Merge #8258: RPC: Hide softfork if timeout is 0...
1772016-06-27T14:08:26 <GitHub19> [bitcoin] laanwj closed pull request #8258: RPC: Hide softfork if timeout is 0 (master...bip9rpcdisable) https://github.com/bitcoin/bitcoin/pull/8258
1782016-06-27T14:16:29 <sipa> wumpus: how hard is it to add a python dependency? (specifically: siphash)
1792016-06-27T14:16:50 <wumpus> you mean for testing? we'd prefer to not add one, a lot of people stumble on the zmq one
1802016-06-27T14:17:19 <wumpus> AFAIK siphash is a single python file, why not just import it
1812016-06-27T14:19:13 *** fengling has joined #bitcoin-core-dev
1822016-06-27T14:21:56 <GitHub97> [bitcoin] laanwj closed pull request #8232: Add IRC link to README.md (master...patch-1) https://github.com/bitcoin/bitcoin/pull/8232
1832016-06-27T14:24:06 *** fengling has quit IRC
1842016-06-27T14:25:14 *** Giszmo has joined #bitcoin-core-dev
1852016-06-27T15:03:21 <sipa> wumpus: ok, i'll just copy some code in
1862016-06-27T15:04:18 *** Arnavion has quit IRC
1872016-06-27T15:04:39 *** Arnavion has joined #bitcoin-core-dev
1882016-06-27T15:12:28 <dgenr8> would it not be a good idea to reserve bit 28 for sizeforks?
1892016-06-27T15:14:17 *** MarcoFalke has joined #bitcoin-core-dev
1902016-06-27T15:15:23 <paveljanik> e.g. reserve it for the softfork to 0.5M?
1912016-06-27T15:15:53 <paveljanik> or maybe 0.75M so we finally close these PRs to bump the default block size?
1922016-06-27T15:16:14 <sipa> for a hardfork you don't nedd bip9
1932016-06-27T15:16:34 <sipa> you can use bip 31 if you really want a means to indicate tgat the rules changed
1942016-06-27T15:19:20 <sipa> it's also not very relevant here: currently bit 28 is unusable for anything
1952016-06-27T15:20:45 *** fengling has joined #bitcoin-core-dev
1962016-06-27T15:25:26 *** fengling has quit IRC
1972016-06-27T15:26:28 <dgenr8> sipa: to be clear, are you saying you believe block version is unsuitable for signaling sizefork support?
1982016-06-27T15:27:19 <sipa> dgenr8: i believe bip9 is unsuitable for hardforks
1992016-06-27T15:29:52 <sipa> because it measures miner support, which is not relevant
2002016-06-27T15:30:55 *** moli has joined #bitcoin-core-dev
2012016-06-27T15:31:38 <sipa> a hardfork is the ecosystem deciding to switch to new rules; if miners don't follow, that's their own problem
2022016-06-27T15:32:15 <dgenr8> so "yes" then? (since not only bip9 but anything in the block header is showing miner support)
2032016-06-27T15:32:42 <sipa> if for you a sizefork implies a hardfork, yes
2042016-06-27T15:32:58 *** molly has quit IRC
2052016-06-27T15:33:26 *** Inaltoas1nistra has joined #bitcoin-core-dev
2062016-06-27T15:33:40 *** Inaltoasinistra has quit IRC
2072016-06-27T15:36:07 <dgenr8> I think I detect another rabbit-hole softfork on the horizon
2082016-06-27T15:37:39 *** zooko has quit IRC
2092016-06-27T15:38:27 *** Inaltoasinistra has joined #bitcoin-core-dev
2102016-06-27T15:39:04 *** Inaltoas1nistra has quit IRC
2112016-06-27T15:45:32 *** Chris_Stewart_5 has quit IRC
2122016-06-27T15:47:46 *** Chris_Stewart_5 has joined #bitcoin-core-dev
2132016-06-27T15:53:23 <btcdrak> dgenr8: what does that mean?
2142016-06-27T15:54:19 <dgenr8> I would imagine something like the old adam3us expansion blocks proposal
2152016-06-27T15:55:45 *** Ylbam has quit IRC
2162016-06-27T16:00:36 <dgenr8> sipa: the ecosystem would follow miners to a larger max block size, just as they are dragged along with all the softforks
2172016-06-27T16:00:42 <dgenr8> With either a soft or hard fork, the effect of not following is the same: total inability to validate part of the block
2182016-06-27T16:02:52 <dgenr8> the best thing for bitcoin is for you guys to adopt bip109
2192016-06-27T16:03:04 *** Chris_Stewart_5 has quit IRC
2202016-06-27T16:13:37 *** pedrobranco has quit IRC
2212016-06-27T16:14:20 <wumpus> bit 28 is the tabboo bit
2222016-06-27T16:14:48 <wumpus> this is not the place for hard/soft fork disussion, and certainly not block size discussions
2232016-06-27T16:15:58 *** pedrobranco has joined #bitcoin-core-dev
2242016-06-27T16:16:13 *** Chris_Stewart_5 has joined #bitcoin-core-dev
2252016-06-27T16:16:32 *** murch has joined #bitcoin-core-dev
2262016-06-27T16:21:59 <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
2272016-06-27T16:22:15 *** fengling has joined #bitcoin-core-dev
2282016-06-27T16:24:26 <GitHub29> [bitcoin] laanwj opened pull request #8274: util: Update tinyformat (master...2016_06_update_tinyformat) https://github.com/bitcoin/bitcoin/pull/8274
2292016-06-27T16:26:46 *** fengling has quit IRC
2302016-06-27T16:36:21 *** afk11 has joined #bitcoin-core-dev
2312016-06-27T16:36:21 *** afk11 has quit IRC
2322016-06-27T16:36:21 *** afk11 has joined #bitcoin-core-dev
2332016-06-27T16:54:22 *** BashCo has quit IRC
2342016-06-27T17:07:15 *** Chris_Stewart_5 has quit IRC
2352016-06-27T17:10:05 *** Chris_Stewart_5 has joined #bitcoin-core-dev
2362016-06-27T17:13:37 *** MarcoFalke has left #bitcoin-core-dev
2372016-06-27T17:14:47 *** BashCo has joined #bitcoin-core-dev
2382016-06-27T17:23:15 *** fengling has joined #bitcoin-core-dev
2392016-06-27T17:28:06 *** fengling has quit IRC
2402016-06-27T17:40:24 *** Chris_Stewart_5 has quit IRC
2412016-06-27T17:46:27 *** kadoban has joined #bitcoin-core-dev
2422016-06-27T17:51:04 <GitHub53> [bitcoin] btcdrak opened pull request #8275: Remove bad chain alert partition check (master...partitionalerts) https://github.com/bitcoin/bitcoin/pull/8275
2432016-06-27T17:54:36 *** Chris_Stewart_5 has joined #bitcoin-core-dev
2442016-06-27T17:58:49 *** kadoban has quit IRC
2452016-06-27T18:05:11 *** Ylbam has joined #bitcoin-core-dev
2462016-06-27T18:18:46 *** pedrobranco has quit IRC
2472016-06-27T18:21:08 *** pedrobranco has joined #bitcoin-core-dev
2482016-06-27T18:21:20 *** Chris_Stewart_5 has quit IRC
2492016-06-27T18:24:46 *** fengling has joined #bitcoin-core-dev
2502016-06-27T18:25:32 *** pedrobranco has quit IRC
2512016-06-27T18:27:00 *** Chris_Stewart_5 has joined #bitcoin-core-dev
2522016-06-27T18:29:26 *** fengling has quit IRC
2532016-06-27T18:31:33 *** Giszmo has quit IRC
2542016-06-27T18:38:24 *** pedrobranco has joined #bitcoin-core-dev
2552016-06-27T18:42:47 *** pedrobranco has quit IRC
2562016-06-27T18:50:50 *** Giszmo has joined #bitcoin-core-dev
2572016-06-27T19:02:17 *** molz has joined #bitcoin-core-dev
2582016-06-27T19:04:48 *** moli has quit IRC
2592016-06-27T19:18:43 <gmaxwell> wumpus: So I made this change:
2602016-06-27T19:18:44 <gmaxwell> + nCacheSize = std::min(nCacheSize,(size_t)1024*1024);
2612016-06-27T19:18:56 <gmaxwell> in dbwrapper.cpp GetOptions
2622016-06-27T19:19:43 <gmaxwell> and a reindex with no txindex, and no signature checking went from 31021.760436 seconds before to 31360.383818000002 seconds after.
2632016-06-27T19:20:06 <gmaxwell> (dbcache settings default)
2642016-06-27T19:20:19 <gmaxwell> so I think this suggests the leveldb cache is doing almost nothing.
2652016-06-27T19:20:43 <gmaxwell> it's a 1% difference to go from the defaults to 1MB.
2662016-06-27T19:22:27 <gmaxwell> going to try 2mb now and see if I can turn that into almost nothing.
2672016-06-27T19:26:13 *** fengling has joined #bitcoin-core-dev
2682016-06-27T19:31:06 *** fengling has quit IRC
2692016-06-27T19:32:58 <sipa> gmaxwell: with what dbcache size was your benchmark?
2702016-06-27T19:33:26 <sipa> my guess is that the leveldb cache becomes relatively less important as the chainstate cache grows
2712016-06-27T19:34:22 <gmaxwell> sipa: the default.
2722016-06-27T19:35:22 <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.
2732016-06-27T19:51:30 *** Chris_Stewart_5 has quit IRC
2742016-06-27T20:07:14 *** Chris_Stewart_5 has joined #bitcoin-core-dev
2752016-06-27T20:12:56 *** Guest23955 has joined #bitcoin-core-dev
2762016-06-27T20:13:44 *** Guest23955 is now known as roidster
2772016-06-27T20:16:03 *** CubicEarth has joined #bitcoin-core-dev
2782016-06-27T20:19:17 <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.
2792016-06-27T20:19:29 <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.
2802016-06-27T20:20:29 <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.
2812016-06-27T20:23:52 <gmaxwell> morcos: it changed substantially.
2822016-06-27T20:23:59 <gmaxwell> it's about 150mb now.
2832016-06-27T20:25:34 <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.
2842016-06-27T20:25:50 <gmaxwell> "bytes": 149293989,
2852016-06-27T20:25:50 <gmaxwell> "usage": 274484752,
2862016-06-27T20:27:07 <gmaxwell> for CPFP to work though it does need to be a fair bit bigger than it would otherwise.
2872016-06-27T20:27:46 *** fengling has joined #bitcoin-core-dev
2882016-06-27T20:28:09 <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)
2892016-06-27T20:29:05 <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
2902016-06-27T20:29:27 <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.
2912016-06-27T20:30:57 *** Chris_Stewart_5 has quit IRC
2922016-06-27T20:31:41 <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
2932016-06-27T20:32:09 <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.
2942016-06-27T20:32:18 <morcos> At least thats my casual observation
2952016-06-27T20:32:26 *** fengling has quit IRC
2962016-06-27T20:33:13 *** Chris_Stewart_5 has joined #bitcoin-core-dev
2972016-06-27T20:56:01 *** jannes has quit IRC
2982016-06-27T20:59:11 *** whphhg has quit IRC
2992016-06-27T21:02:31 *** whphhg has joined #bitcoin-core-dev
3002016-06-27T21:06:15 *** Chris_Stewart_5 has quit IRC
3012016-06-27T21:21:26 *** Chris_Stewart_5 has joined #bitcoin-core-dev
3022016-06-27T21:24:51 *** grubles is now known as dingus
3032016-06-27T21:29:20 *** fengling has joined #bitcoin-core-dev
3042016-06-27T21:34:06 *** fengling has quit IRC
3052016-06-27T21:58:48 *** Giszmo has quit IRC
3062016-06-27T21:59:31 *** Giszmo has joined #bitcoin-core-dev
3072016-06-27T22:08:34 *** dingus is now known as grubles
3082016-06-27T22:14:56 *** moli has joined #bitcoin-core-dev
3092016-06-27T22:17:04 *** molz has quit IRC
3102016-06-27T22:22:18 *** adamg has quit IRC
3112016-06-27T22:25:27 *** adamg has joined #bitcoin-core-dev
3122016-06-27T22:30:35 *** kadoban has joined #bitcoin-core-dev
3132016-06-27T22:30:48 *** fengling has joined #bitcoin-core-dev
3142016-06-27T22:35:46 *** fengling has quit IRC
3152016-06-27T22:37:15 *** murch has quit IRC
3162016-06-27T22:37:51 *** murch has joined #bitcoin-core-dev
3172016-06-27T22:39:02 *** Guyver2 has quit IRC
3182016-06-27T22:41:30 *** cryptapus is now known as cryptapus_afk
3192016-06-27T22:43:42 *** cryptapus has joined #bitcoin-core-dev
3202016-06-27T22:48:57 *** cryptapus has quit IRC
3212016-06-27T22:49:33 *** murch has quit IRC
3222016-06-27T22:53:03 *** murch has joined #bitcoin-core-dev
3232016-06-27T22:57:38 *** murch has quit IRC
3242016-06-27T22:59:36 *** murch has joined #bitcoin-core-dev
3252016-06-27T23:03:04 *** murch1 has joined #bitcoin-core-dev
3262016-06-27T23:04:26 *** murch has quit IRC
3272016-06-27T23:10:46 *** murch1 has quit IRC
3282016-06-27T23:11:33 *** murch has joined #bitcoin-core-dev
3292016-06-27T23:32:18 *** fengling has joined #bitcoin-core-dev
3302016-06-27T23:37:06 *** fengling has quit IRC