1 2016-09-02 00:23:04	0|GitHub92|[13bitcoin] 15gmaxwell opened pull request #8644: [0.13 backport] Check for compatibility with download in FindNextBlocksToDownload (060.13...06findnext_backport) 02https://github.com/bitcoin/bitcoin/pull/8644
  2 2016-09-02 00:24:59	0|gmaxwell|Do we want to backport, "Reduce default number of blocks to check at startup"?  It's a trivial fix to long startup time complaints, and arguably the dbcache increase in 0.13 was a startup time regression for some people.
  3 2016-09-02 00:25:59	0|GitHub29|[13bitcoin] 15droark opened pull request #8645: Remove unused Qt 4.6 patch. (06master...06master) 02https://github.com/bitcoin/bitcoin/pull/8645
  4 2016-09-02 00:26:36	0|sipa|i would be fime with that, though calling it a bugfix is a stretch
  5 2016-09-02 00:27:16	0|gmaxwell|well I gave a pragmatic argument for it being one.
  6 2016-09-02 00:27:33	0|gmaxwell|but I don't think I needed to, it's pretty obviously riskless with no "interface" impact.
  7 2016-09-02 00:28:10	0|sipa|yes, i agree it has very low risk
  8 2016-09-02 00:28:26	0|gmaxwell|which I think beyond 'fix' should be the goal for point releases, nothing that is going to turn a working deployment into a broken one.
  9 2016-09-02 00:32:19	0|luke-jr|sounds reasonable to do, in any case
 10 2016-09-02 00:36:01	0|GitHub176|[13bitcoin] 15gmaxwell opened pull request #8646: [0.13 backport] Reduce default number of blocks to check at startup (060.13...06reduceblocks_backport) 02https://github.com/bitcoin/bitcoin/pull/8646
 11 2016-09-02 00:44:16	0|GitHub102|[13bitcoin] 15gmaxwell opened pull request #8648: [0.13 backport] Precompute sighashes (060.13...06precompute_backport) 02https://github.com/bitcoin/bitcoin/pull/8648
 12 2016-09-02 00:44:22	0|gmaxwell|wumpus: feel free to close my backport prs if you don't find them helpful, I was just feeling usless simply saying X or Y should be backported rather than doing it.
 13 2016-09-02 01:38:43	0|jl2012|We need a nulldummy only bip?
 14 2016-09-02 01:42:03	0|jl2012|And I already have a PR for empty failing signature https://github.com/bitcoin/bitcoin/pull/8634
 15 2016-09-02 02:04:56	0|cfields|sdaftuar: did you say you were able to reproduce the segwit.py failure locally?
 16 2016-09-02 02:05:39	0|cfields|sdaftuar: if so: https://github.com/theuni/bitcoin/commit/fa88a425c0c1089ab75ea9223699286f40c8eea7
 17 2016-09-02 02:06:11	0|cfields|it's pretty hackish, needs a cleanup. But should be enough to determine if it fixes the problem
 18 2016-09-02 02:07:18	0|cfields|wumpus: let me know if ^^ is what you had in mind
 19 2016-09-02 02:09:13	0|cfields|that not only eliminates polling, but also drops cs_main locking, so i should think it'd be a good bit quicker
 20 2016-09-02 05:03:30	0|GitHub186|[13bitcoin] 15JeremyRubin opened pull request #8650: Make tests much faster by replacing BOOST_CHECK with FAST_CHECK (06master...06faster_tests) 02https://github.com/bitcoin/bitcoin/pull/8650
 21 2016-09-02 05:13:56	0|gmaxwell|down with 'test frameworks'.
 22 2016-09-02 05:48:57	0|jeremyrubin|gmaxwell: Hear, hear!
 23 2016-09-02 05:51:10	0|GitHub124|13bitcoin/06master 14854f1af 15Pieter Wuille: Make the dummy argument to getaddednodeinfo optional
 24 2016-09-02 05:51:10	0|GitHub124|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/f061415d12ce...91990ee01dab
 25 2016-09-02 05:51:11	0|GitHub124|13bitcoin/06master 1491990ee 15Wladimir J. van der Laan: Merge #8272: Make the dummy argument to getaddednodeinfo optional...
 26 2016-09-02 05:51:15	0|GitHub133|[13bitcoin] 15laanwj closed pull request #8272: Make the dummy argument to getaddednodeinfo optional (06master...06optionaladdnodedummy) 02https://github.com/bitcoin/bitcoin/pull/8272
 27 2016-09-02 05:52:07	0|gmaxwell|jeremyrubin: I had someone 'testframeworkize' one of my tests in another project and it caused it to go from 45 second runtime something like an hour.
 28 2016-09-02 06:15:00	0|jeremyrubin|gross :/
 29 2016-09-02 07:44:05	0|jonasschnelli|Hmm... IBDing from a local peer (same host) seems to take much longer the bootstraping from random peers.
 30 2016-09-02 07:46:21	0|gmaxwell|early in the sync it fetches to few a number of blocks at a time, so fetching from a single peer is slow. hardly matters overall.
 31 2016-09-02 07:46:31	0|gmaxwell|other than that, they'll obviously contend a bit for IO
 32 2016-09-02 07:46:50	0|gmaxwell|I'm not aware of any other reasons for slowdowns other than that.
 33 2016-09-02 07:47:23	0|paveljanik|jonasschnelli, OS X<
 34 2016-09-02 07:47:25	0|paveljanik|?
 35 2016-09-02 07:48:02	0|jonasschnelli|paveljanik: no debian on my Intel(R) Xeon(R) CPU E3-1275 v5 @ 3.60GHz
 36 2016-09-02 07:48:28	0|paveljanik|I had the same issue on OS X in the past. unplugging the network cable, turning off firewall helped 8)
 37 2016-09-02 07:48:44	0|gmaxwell|are you only looking at the first 150k blocks? or are you seeing the rate per block slower later?
 38 2016-09-02 07:48:47	0|paveljanik|the process named powerd took 100% of CPU power
 39 2016-09-02 07:49:30	0|jonasschnelli|gmaxwell: It took more then 1h for progress=0.035480
 40 2016-09-02 07:49:54	0|jonasschnelli|(where is did sync with random peers up to progress 1.0 in ~3h [2 month ago though])
 41 2016-09-02 07:50:56	0|gmaxwell|better to look at time vs height, e.g. grab a chunk of 100 blocks wherever it is and comare the blocks per second at that height with the same height in your prior logs.
 42 2016-09-02 07:50:59	0|jonasschnelli|Also... my extremely scientific measure of how fast the tail -f output scrolls though.... did tell me its slower
 43 2016-09-02 07:51:57	0|jonasschnelli|I guess i let it sync up to h400'000 and then compare it against a sync from random peers
 44 2016-09-02 07:52:28	0|jonasschnelli|The only differences are: -prune=550 and connecting to a node thats running on the same machine (in sync, should not cause a huge slowdown)
 45 2016-09-02 07:53:01	0|gmaxwell|prune might make it slower.
 46 2016-09-02 07:53:21	0|gmaxwell|after all it's writing things to only delete it after.
 47 2016-09-02 07:53:21	0|jonasschnelli|the prune data eviction seems pretty fast
 48 2016-09-02 07:53:35	0|jonasschnelli|it's running on a 1GB/s SSD
 49 2016-09-02 07:55:19	0|gmaxwell|I doubt anyone has benmarked prune vs not, if you told me that it was doing some linear scan of all the blocks to decide what to prune, every block-- and was thus massively slower, I wouldn't not be too surprised.
 50 2016-09-02 07:57:01	0|GitHub55|13bitcoin/06master 14cdd79eb 15Jorge Timón: C++11: s/boost::scoped_ptr/std::unique_ptr/
 51 2016-09-02 07:57:01	0|GitHub55|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/91990ee01dab...6f939c9080a3
 52 2016-09-02 07:57:02	0|GitHub55|13bitcoin/06master 146f939c9 15Wladimir J. van der Laan: Merge #8629: C++11: s/boost::scoped_ptr/std::unique_ptr/...
 53 2016-09-02 07:57:16	0|GitHub51|[13bitcoin] 15laanwj closed pull request #8629: C++11: s/boost::scoped_ptr/std::unique_ptr/ (06master...060.13-boost-scoped-ptr) 02https://github.com/bitcoin/bitcoin/pull/8629
 54 2016-09-02 08:00:15	0|sipa|pruning causes flushing
 55 2016-09-02 08:01:11	0|gmaxwell|oh obviously, it needs to make sure that after a restart it can continue, so it hast to at least be consistent to the point where it pruned.
 56 2016-09-02 08:10:44	0|jonasschnelli|What is the reason for the txn_count=0x00 in the headers p2p message?
 57 2016-09-02 08:13:10	0|sipa|because CBlockHeader did not originally exist
 58 2016-09-02 08:13:30	0|sipa|and headers messages just contained a CBlock with 0 transactions
 59 2016-09-02 08:13:55	0|jonasschnelli|thanks.
 60 2016-09-02 08:20:17	0|jeremyrubin|Is it correct that the maximum number of items deleted from sigcache while checking a block is max sigops?
 61 2016-09-02 08:20:59	0|sipa|i believe so
 62 2016-09-02 08:21:56	0|jeremyrubin|And is that "MAX_BLOCK_SIGOPS_COST" or is that something else
 63 2016-09-02 08:22:04	0|jeremyrubin|because I see a 20k number floating around too
 64 2016-09-02 08:22:08	0|jeremyrubin|but MAX_BLOCK_SIGOPS_COST=80k
 65 2016-09-02 08:22:32	0|sipa|yes, 4x factor from segwit
 66 2016-09-02 08:22:57	0|sipa|sigops in non-witness part count as 4, in witness part they count as 1
 67 2016-09-02 08:23:40	0|jeremyrubin|so if you have 0 sigops in witness, you can have the full 80k?
 68 2016-09-02 08:24:13	0|sipa|if you have 0 sigops in non-witness
 69 2016-09-02 08:24:15	0|sipa|yes
 70 2016-09-02 08:24:19	0|jeremyrubin|ok cool
 71 2016-09-02 08:24:23	0|sipa|pre segwit the max is 20k
 72 2016-09-02 08:24:29	0|sipa|post segwit it is 80k
 73 2016-09-02 08:58:43	0|jonasschnelli|with disabled pruning it took also >1h for progress=0.031407... now trying a sync from random peers
 74 2016-09-02 09:00:16	0|gmaxwell|you're killin me with the testing with just the first 3%.
 75 2016-09-02 09:00:41	0|jonasschnelli|gmaxwell: heh. You think comparing the first 3% does not make sense?
 76 2016-09-02 09:01:14	0|jonasschnelli|I just try to not waste time. :)
 77 2016-09-02 09:01:33	0|gmaxwell|it's very unrepresentative, as I explaned earlier. We only fetch 16 blocks per peer at a time ... early in the chain this is far too few to keep the system well pipelined, because the blocks take no work to process. :)
 78 2016-09-02 09:02:42	0|jonasschnelli|gmaxwell: Okay. I see. But anyways, a sync with a single local peer will then take always longer, right?
 79 2016-09-02 09:03:18	0|gmaxwell|yes, somewhat. the difference will only be in the initial part of the chain, but go away later-- at least, whatever issue was due to that.
 80 2016-09-02 09:04:09	0|gmaxwell|it's like the 0.13 vs 0.12 reindex, the 0.13 reindex spends 20 minutes at the front reading headers. So it starts off 20 minutes behind, it still finishes earlier.
 81 2016-09-02 09:04:35	0|gmaxwell|but if you were to compare reintext for 0.13 vs 0.12 for the first 3% you would likely find 0.13 was much slower. :)
 82 2016-09-02 09:44:16	0|GitHub197|[13bitcoin] 15sipa opened pull request #8651: Predeclare PrecomputedTransactionData as struct (06master...06classtructblah) 02https://github.com/bitcoin/bitcoin/pull/8651
 83 2016-09-02 09:48:03	0|GitHub77|[13bitcoin] 15yurizhykin opened pull request #8652: [qa]: remove root test directory for RPC tests (06master...06cleanup) 02https://github.com/bitcoin/bitcoin/pull/8652
 84 2016-09-02 10:26:27	0|GitHub76|[13bitcoin] 15laanwj pushed 3 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/6f939c9080a3...381d0ddc8aaa
 85 2016-09-02 10:26:28	0|GitHub76|13bitcoin/06master 14a159f25 15Pavel Janík: Remove redundand (and shadowing) declaration
 86 2016-09-02 10:26:28	0|GitHub76|13bitcoin/06master 14cce3024 15Pavel Janík: Do not shadow local variable, cleanup
 87 2016-09-02 10:26:29	0|GitHub76|13bitcoin/06master 14381d0dd 15Wladimir J. van der Laan: Merge #8449: [Trivial] Do not shadow local variable, cleanup...
 88 2016-09-02 10:26:32	0|GitHub190|[13bitcoin] 15laanwj closed pull request #8449: [Trivial] Do not shadow local variable, cleanup (06master...0620160803_shadow_blockencodings) 02https://github.com/bitcoin/bitcoin/pull/8449
 89 2016-09-02 10:52:19	0|GitHub29|13bitcoin/06master 14b7c349d 15Pavel Janík: Do not shadow variables in networking code
 90 2016-09-02 10:52:19	0|GitHub29|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/381d0ddc8aaa...cbe9ae8c69b9
 91 2016-09-02 10:52:20	0|GitHub29|13bitcoin/06master 14cbe9ae8 15Wladimir J. van der Laan: Merge #8466: [Trivial] Do not shadow variables in networking code...
 92 2016-09-02 10:52:24	0|GitHub92|[13bitcoin] 15laanwj closed pull request #8466: [Trivial] Do not shadow variables in networking code (06master...0620160805_Wshadow_net) 02https://github.com/bitcoin/bitcoin/pull/8466
 93 2016-09-02 11:38:48	0|cfields|jonasschnelli: so your comment on #8085 may not be relevant to those changes?
 94 2016-09-02 11:42:09	0|GitHub97|[13bitcoin] 15jl2012 closed pull request #8533: Implement LOW_S and NULLDUMMY softfork (BIP146) (06master...06bip146) 02https://github.com/bitcoin/bitcoin/pull/8533
 95 2016-09-02 12:58:13	0|cfields|wumpus: re-ping incase you missed in backog. what do you think of the approach here to fix the travis timeouts? https://github.com/theuni/bitcoin/commit/fa88a425c0c1089ab75ea9223699286f40c8eea7
 96 2016-09-02 13:23:58	0|GitHub117|[13bitcoin] 15sstone opened pull request #8653: doc (trivial): add tip for cross-builds on ubuntu (06master...06wip-doccrosscompile) 02https://github.com/bitcoin/bitcoin/pull/8653
 97 2016-09-02 13:41:14	0|sipa|cfields: looks good to me
 98 2016-09-02 13:41:59	0|sipa|jonasschnelli: 3%, how many blocks is that?
 99 2016-09-02 13:42:54	0|jonasschnelli|sipa: aprox 211000
100 2016-09-02 13:43:16	0|jonasschnelli|My assumption is that IBD with a single peer is much slower... but can't prove it right now.
101 2016-09-02 13:43:18	0|sipa|jonasschnelli: that seems very wrong
102 2016-09-02 13:43:26	0|sipa|it should take minutes to get to 211000
103 2016-09-02 13:43:58	0|sipa|not an hour
104 2016-09-02 13:44:12	0|sipa|the effect greg talks about it real, but shouldn't last more than a few minutes
105 2016-09-02 13:44:36	0|jonasschnelli|2016-09-02 08:58:49 UpdateTip: new best=0000000000000345b371caa3f829cacbe2b4d38ecd15a5a02031efae79934d15 height=211000
106 2016-09-02 13:44:39	0|jonasschnelli|2016-09-02 07:56:40 Bitcoin version v0.13.99.0-df98230
107 2016-09-02 13:57:01	0|jonasschnelli|sipa: I guess its caused by --enable-debug
108 2016-09-02 13:58:44	0|sipa|oh, yes, that will slow things down tremendously
109 2016-09-02 14:00:02	0|jonasschnelli|sry for the noise... I should finally remember to disable debug mode when benachmarking.
110 2016-09-02 15:15:47	0|sturles|a/away
111 2016-09-02 15:25:40	0|cfields|sipa: thanks
112 2016-09-02 15:26:20	0|cfields|jonasschnelli: so I should ignore https://github.com/bitcoin/bitcoin/pull/8085#issuecomment-244077083 ?
113 2016-09-02 15:26:41	0|jonasschnelli|cfields: I think so...
114 2016-09-02 15:26:50	0|jonasschnelli|I'm working on more authentic IBD benchmarks.
115 2016-09-02 15:27:39	0|cfields|jonasschnelli: ok. apples to apples IBD is a good idea though. I'll do some syncs over the weekend
116 2016-09-02 15:28:11	0|jonasschnelli|cfields: Yes. I was fooled (again) by the bias of --enable-debug and --prune
117 2016-09-02 15:30:12	0|cfields|jonasschnelli: ah, heh. I've fallen into the same trap. Turns out profiles generated with -O0 (for better info) aren't at all representative of real-world usage
118 2016-09-02 15:30:29	0|cfields|so it makes sense that it'd be a major performance killer
119 2016-09-02 15:33:27	0|gmaxwell|jonasschnelli: I think you got caught on debug before, you realize now I'm gonna start asking you? "Are you benchmarking with enable debug again?" :P
120 2016-09-02 15:34:05	0|jonasschnelli|heh... yes.
121 2016-09-02 15:34:07	0|btcdrak|Jonas 'debug' schnelli
122 2016-09-02 15:34:09	0|sdaftuar|cfields: i don't think i have seen segwit.py fail locally for the reason mentioned in #8532
123 2016-09-02 15:34:19	0|sdaftuar|gmaxwell: please set up an irc autoresponder so the rest of us don't forget to ask him too :)
124 2016-09-02 15:34:49	0|cfields|sdaftuar: ah, ok
125 2016-09-02 15:36:11	0|sdaftuar|it seems like the most common reason my rpc tests fail is the communicat() timeout thing i reported in #8649, and then new test runs failing when old bitcoind's haven't been killed from prior test runs (sigh)
126 2016-09-02 15:44:57	0|GitHub85|[13bitcoin] 15jl2012 opened pull request #8654: Reuse sighash computations across evaluation (rebase of #4562) (06master...06sighashcache) 02https://github.com/bitcoin/bitcoin/pull/8654
127 2016-09-02 15:56:23	0|wumpus|cfields: looking
128 2016-09-02 15:59:05	0|wumpus|cfields: looks good to me, doesn't even require any new signals!
129 2016-09-02 16:00:36	0|wumpus|cfields: any reason to not put the signal subscription/unsubscription in StartRPC/StopRPC?
130 2016-09-02 16:01:09	0|wumpus|cfields: oh duh, those are general methods
131 2016-09-02 16:01:29	0|wumpus|cfields: if there was a rpcblockchain.init/deinit, it would fit there
132 2016-09-02 16:02:32	0|wumpus|cfields: but this is ok; maybe mark the RPC calls that they are primarily meant for testing and/or set them as hidden?
133 2016-09-02 16:03:00	0|wumpus|(e.g. I can see complaints from people hanging the RPC server this way with no clue what they're doing)
134 2016-09-02 16:03:29	0|sipa|agree
135 2016-09-02 16:05:25	0|cfields|wumpus: yep, makes sense
136 2016-09-02 16:05:44	0|cfields|and yes, i kinda abused the existing signals there. I figured you'd be grumpier about it, hence the poke rather than PR :)
137 2016-09-02 16:07:48	0|wumpus|cfields: well the important thing is that all other processing has been done at the time of the signal; does this guarantee that?
138 2016-09-02 16:08:22	0|wumpus|(I guess the answer is yes, as there is no async processing, although it could depend on the order in which the handlers are called?)
139 2016-09-02 16:09:20	0|sipa|by default i think handlers are called in the order they were added
140 2016-09-02 16:09:43	0|cfields|wumpus: i believe it's fine, but i'll double-check.
141 2016-09-02 16:10:22	0|cfields|wumpus: since it abuses the ui signal, i'm not sure we need to worry about the order? Looking to see who else receives that
142 2016-09-02 16:11:29	0|wumpus|sipa: yes, but that is a really fragile thing to rely on
143 2016-09-02 16:11:59	0|wumpus|cfields: ok, yes that makes sense, if the UI signal is last
144 2016-09-02 16:12:18	0|wumpus|cfields: indeed there's no need to be worried doing things concurrently with the GUI
145 2016-09-02 16:12:33	0|wumpus|(usually that won't be running anyhow during RPC testing, although it's possible)
146 2016-09-02 16:12:47	0|cfields|it doesn't guarantee that we've acted on relaying appropriately, though all we could guarantee there anyway is that we've queued up some messages
147 2016-09-02 16:13:31	0|cfields|right
148 2016-09-02 16:16:00	0|cfields|yes, only other user is qt for updating gui
149 2016-09-02 16:27:58	0|GitHub78|[13bitcoin] 15paveljanik opened pull request #8655: Do not shadow variables (trivials) (06master...0620160902_Wshadow_trivials) 02https://github.com/bitcoin/bitcoin/pull/8655
150 2016-09-02 16:52:13	0|phantomcircuit|jonasschnelli, the p2p network contains a bunch of nodes which exist only to monitor people and as a side effect have bizarre behaviour
151 2016-09-02 18:58:04	0|GitHub12|[13bitcoin] 15paveljanik opened pull request #8656: Do not shadow global variable fileout (06master...0620160902_Wshadow_fileout) 02https://github.com/bitcoin/bitcoin/pull/8656
152 2016-09-02 19:01:24	0|instagibbs|sipa, where is chainActive loaded on init? Having trouble tracking that down.
153 2016-09-02 19:04:20	0|sipa|instagibbs: ActivateBestChain?
154 2016-09-02 19:04:26	0|sipa|LoadBlockIndex?
155 2016-09-02 19:06:49	0|instagibbs|eh yes, but it got moved around and I'm flailing
156 2016-09-02 19:07:04	0|instagibbs|I'll track it down
157 2016-09-02 19:09:59	0|instagibbs|ah i misunderstood what wallet init was doing with it, nevermind, thanks
158 2016-09-02 20:09:27	0|GitHub70|[13bitcoin] 15paveljanik opened pull request #8658: WIP/DO NOT MERGE: Remove unused statements in serialization (06master...0620160902_nVersion_serialization_cleanup) 02https://github.com/bitcoin/bitcoin/pull/8658