1 2016-08-02 00:18:40	0|GitHub23|[13bitcoin] 15pstratem opened pull request #8445: Move CWallet::setKeyPool to private section of CWallet. (06master...062016-07-01-cwallet-api-cleanup) 02https://github.com/bitcoin/bitcoin/pull/8445
 2 2016-08-02 01:08:57	0|Chris_Stewart_5|is there a line of code I can change somewhere to compile the entire project with c++11 standard?
 3 2016-08-02 01:10:57	0|sipa|we already do
 4 2016-08-02 01:12:48	0|sipa|as in: you can't compile the 0.13 codebase with c++03 anymore
 5 2016-08-02 01:14:19	0|Chris_Stewart_5|I'm still learning C++ build systems. What file is this specified in exactly? I've searched configure.ac, Makefile.am, Makefile.in
 6 2016-08-02 01:14:33	0|Chris_Stewart_5|The only reference to 'c++11' I can find is wrt to boost inside of configure.ac
 7 2016-08-02 01:16:57	0|sipa|line 59
 8 2016-08-02 01:17:27	0|sipa|AX_CXX_COMPILE_STDCXX([11], [noext], [mandatory])
 9 2016-08-02 01:18:06	0|Chris_Stewart_5|Ahh ok. Thank you
10 2016-08-02 01:18:55	0|phantomcircuit|a bunch of the tests in wallet/test/rpc_wallet_tests.cpp seem to be pretty confused
11 2016-08-02 01:19:06	0|phantomcircuit|things like calling getbalance on an address instead of an account and stuff
12 2016-08-02 01:26:39	0|sipa|phantomcircuit: wah
13 2016-08-02 01:34:24	0|phantomcircuit|sipa: yeah... line 104
14 2016-08-02 01:34:27	0|phantomcircuit|BOOST_CHECK_NO_THROW(CallRPC("getbalance " + demoAddress.ToString()));
15 2016-08-02 01:34:34	0|phantomcircuit|that's basically completely meaningless
16 2016-08-02 02:15:29	0|kanzure|https://twitter.com/kanzure/status/760297796411002880
17 2016-08-02 05:50:07	0|wumpus|phantomcircuit: I don't think rpc_wallet_tests.cpp should ideally exist at all
18 2016-08-02 05:50:18	0|wumpus|phantomcircuit: it is from before we had the RPC functional tests framework
19 2016-08-02 05:50:49	0|wumpus|unit tests that check RPC behavior, except for the most basic level, aren't really unit tests
20 2016-08-02 05:51:17	0|wumpus|so if someone takes care that everything that is in rpc_wallet_tests.cpp and is worthwhile is being tested in the RPC wallet tests, the file can go
21 2016-08-02 05:51:54	0|phantomcircuit|wumpus: great im pretty sure we're already doing that and this is doing a bunch of reallllly weird stuff
22 2016-08-02 05:52:02	0|wumpus|great
23 2016-08-02 06:27:26	0|GitHub156|[13bitcoin] 15laanwj pushed 6 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/ea268747b6d4...63c03dd41cc0
24 2016-08-02 06:27:27	0|GitHub156|13bitcoin/06master 1456c87e9 15Suhas Daftuar: Allow changing BIP9 parameters on regtest
25 2016-08-02 06:27:27	0|GitHub156|13bitcoin/06master 149c8593d 15Pieter Wuille: Implement SipHash in Python
26 2016-08-02 06:27:28	0|GitHub156|13bitcoin/06master 14a8689fd 15Suhas Daftuar: Tests: refactor compact size serialization in mininode
27 2016-08-02 06:27:36	0|GitHub180|[13bitcoin] 15laanwj closed pull request #8418: Add tests for compact blocks (06master...06cb-testing) 02https://github.com/bitcoin/bitcoin/pull/8418
28 2016-08-02 08:30:47	0|GitHub103|[13bitcoin] 15paveljanik opened pull request #8446: BIP9 parameters on regtest cleanup (06master...0620160802_shadow_bip9params) 02https://github.com/bitcoin/bitcoin/pull/8446
29 2016-08-02 11:18:24	0|wumpus|cfields: I don't get it, I don't manage to compile master for ARM anymore: https://github.com/bitcoin/bitcoin/issues/8447  however, in travis it's working. What could be the difference, that I'm compiling my own toolchain?
30 2016-08-02 11:19:10	0|wumpus|I guess I'll try in a trusty VM
31 2016-08-02 11:30:48	0|wumpus|maybe this is false alarm and the g++ compiler produced by crosstool lacks some feature to support the c++11 threading primitives, or I've just forgot to pass some setting
32 2016-08-02 15:10:00	0|GitHub15|[13bitcoin] 15laanwj closed pull request #8436: Update release-notes.md (060.13...06patch-1) 02https://github.com/bitcoin/bitcoin/pull/8436
33 2016-08-02 18:57:03	0|Sanakov|Hello everybod: Yesterday we launched https://www.bitfuse.org; Share your files and get paid in bitcoins.
34 2016-08-02 18:57:08	0|Sanakov|Please let me know what you think of the website.
35 2016-08-02 19:03:30	0|molz|Sanakov, wrong channel
36 2016-08-02 19:07:36	0|Sanakov|where
37 2016-08-02 19:07:49	0|Sanakov|do I post stuff like this then? Any suggestions
38 2016-08-02 19:07:50	0|Sanakov|Thank you
39 2016-08-02 19:24:59	0|instagibbs|Sanakov, #bitcoin-otc
40 2016-08-02 19:27:53	0|Sanakov|thanks
41 2016-08-02 19:59:29	0|morcos|cfields: sipa: i've benchmarked the cumulative results of what jeremy and i have been working on.
42 2016-08-02 19:59:39	0|morcos|http://imgur.com/a/WPvi1
43 2016-08-02 20:00:21	0|sipa|morcos: nice!
44 2016-08-02 20:00:26	0|sipa|morcos: what is tipcache?
45 2016-08-02 20:00:38	0|morcos|still a bit more work to go before PR's and we probably need to figure out how to apply NicolasDorier's hash cache as well
46 2016-08-02 20:00:59	0|morcos|tipcache is a permanent CCoinsViewCache in front of pcoinstip instead of creating a new one each ConnectBlock
47 2016-08-02 20:01:34	0|morcos|its prepopulated every 30 secs by the inputs necessary for a block created by CreateNewBlock (takes on average 13ms)
48 2016-08-02 20:01:47	0|sipa|ha
49 2016-08-02 20:01:56	0|morcos|and its only cleared after a block is connected
50 2016-08-02 20:02:12	0|morcos|this also serves to keep pcoinsTip itself properly warm
51 2016-08-02 20:02:41	0|sipa|interesting
52 2016-08-02 20:02:51	0|morcos|so all these tests are with about 550M of total caches  (300M dbcache, 100M sigcache, approx 150M tipcache)  or 450M dbache if not using tipcache
53 2016-08-02 20:03:42	0|morcos|so overal cpu running time is increased of course using tipcache, but it happens out of critical path and its quick enough that its not hurting anything i dont' think 13ms every 30 secs
54 2016-08-02 20:06:40	0|sipa|morcos: i can do benchmarks on a 52-core system, if you have code for me to test
55 2016-08-02 20:06:46	0|sipa|s/core/thread/
56 2016-08-02 20:07:28	0|jeremyrubin|woooo
57 2016-08-02 20:07:34	0|morcos|ah, ok good , yeah i have 16 cores / 32 threads
58 2016-08-02 20:07:42	0|jeremyrubin|How many cores?
59 2016-08-02 20:08:07	0|sipa|2 chips, each 13 cores, each 2 threads
60 2016-08-02 20:08:18	0|gmaxwell|s/13/14/
61 2016-08-02 20:08:19	0|morcos|i tried setting scriptcheck threads to 24 or 32 and it slowed down a lot in all versions
62 2016-08-02 20:08:38	0|sipa|oops, 56, not 52
63 2016-08-02 20:08:47	0|jeremyrubin|how is the memory bus configured?
64 2016-08-02 20:09:04	0|jeremyrubin|im curious how the lockfree stuff is implemented
65 2016-08-02 20:09:19	0|jeremyrubin|nvm
66 2016-08-02 20:10:20	0|jeremyrubin|(but in general, if someone better understands the lockfree stuff there are a bunch of low hanging fruit optimizations to investigate, although as is it's already fast enough to forget about for a while)
67 2016-08-02 20:10:40	0|morcos|in any case the question there will only be whether it gets slower, as there isn't much room to get faster by more parallelism without changes.  waiting on verification is pretty minimal now.
68 2016-08-02 20:10:58	0|morcos|i suppose it could help a lot on startup/reindex, where you don't have warm caches (sig or pcoinstip)
69 2016-08-02 20:11:22	0|jeremyrubin|quick q: best way to give up cpu cycles
70 2016-08-02 20:11:34	0|jeremyrubin|eg, sleep(0), this_thread::yield()
71 2016-08-02 20:11:44	0|sipa|jeremyrubin: i wonder about the same
72 2016-08-02 20:11:58	0|gmaxwell|jeremyrubin: it's numa. with 4-way parallel memory on each of the two chips.
73 2016-08-02 20:12:21	0|morcos|sipa: have you figured out what the optimal number of scriptcheck threads is for you do do a reindex is right now?
74 2016-08-02 20:12:52	0|sipa|morcos: i have not; will do
75 2016-08-02 20:15:00	0|sipa|morcos: how do you benchmark? use -debug=bench numbers?
76 2016-08-02 20:15:58	0|morcos|sipa: yes thats what i've been doing
77 2016-08-02 20:16:23	0|morcos|although for reindex, i guess the actual time elapsed is most interesting
78 2016-08-02 20:17:16	0|sipa|for the graph you posted above... where do those come from?
79 2016-08-02 20:18:04	0|morcos|thats using sdaftuar's simulation mode over the first 3 days of may (470 blocks)
80 2016-08-02 20:18:23	0|morcos|so a bit biased by having no mempool at the beginning of that period..
81 2016-08-02 22:49:05	0|NicolasDorier|Actually, the bug I pointed out yestersday about time-too-new may really be a problem: https://www.reddit.com/r/Bitcoin/comments/4vsvvm/bitcoind_stuck_at_block_422168_timestamp_too_far/.
82 2016-08-02 22:49:05	0|NicolasDorier|Having seen that independently, I tried to make a test to reproduce the bug in regnet. However I could not reproduce: If the block was rejected for time-too-new, then later rebroadcasted it worked fine and was reconsidered. I've not tried with header first propagation though
83 2016-08-02 23:32:21	0|gmaxwell|NicolasDorier: maybe if its rejected during the startup checks.
84 2016-08-02 23:32:37	0|gmaxwell|e.g. set time forward, accept a block. shut down, turn time back. restart.
85 2016-08-02 23:37:08	0|sipa|NicolasDorier: i don't understand the logs there
86 2016-08-02 23:37:39	0|sipa|the "CheckBlockHeader(): block timestamp too far in the future" message is something that implies a header is being received that at the time of receipt is too far in the future
87 2016-08-02 23:38:04	0|sipa|while the "AcceptBlockHeader: block is marked invalid" message is about the header being marked as invalid in the database
88 2016-08-02 23:38:56	0|sipa|the two should never occur together
89 2016-08-02 23:39:07	0|sipa|as the first should result in us not storing the header at all