1 2017-10-30 00:57:40 0|fanquake|cfields Could the fact that our GCC func attribute macro is missing the check for fallthrough be contributing to any issues?
2 2017-10-30 03:10:31 0|cluelessperson|;;blocks
3 2017-10-30 03:10:31 0|gribble|492291
4 2017-10-30 03:10:35 0|cluelessperson|WOOT
5 2017-10-30 03:10:41 0|cluelessperson|first pruned up up
6 2017-10-30 03:12:26 0|cluelessperson|looks like a pruned node of 550 MB took me from 2017-10-29 21:37:55 to 2017-10-30 03:10:21 to sync.
7 2017-10-30 03:14:21 0|esotericnonsense|\o/
8 2017-10-30 03:14:45 0|cluelessperson|End pruned size, 3.6 GB
9 2017-10-30 03:15:07 0|cluelessperson|508Mblocks
10 2017-10-30 03:15:15 0|cluelessperson|3.0Gchainstate
11 2017-10-30 03:15:27 0|cluelessperson|115Mdebug.log
12 2017-10-30 03:16:25 0|esotericnonsense|cluelessperson: if the log is not sensitive it might be useful for https://github.com/bitcoin/bitcoin/pull/11359
13 2017-10-30 03:16:59 0|esotericnonsense|this PR does not seem popular (sdaftuar's comments on flushes will likely lead to a better solution)
14 2017-10-30 03:17:22 0|esotericnonsense|but from the log file it should be possible to guess at time wasted :)
15 2017-10-30 03:21:34 0|cluelessperson|esotericnonsense: These are just tests pointed at the localhost node, on a PCISSD, so yeah, I can share
16 2017-10-30 03:21:45 0|cluelessperson|esotericnonsense: you want me to just attach the log file to that link?
17 2017-10-30 03:22:08 0|esotericnonsense|cluelessperson: re your chat in #bitcoin if you actually want to and have time it would be nice to see a benchmark of non-pruning sync time against the same target (e.g. without network node variance)
18 2017-10-30 03:22:22 0|esotericnonsense|sure maybe gzip it or something though :P
19 2017-10-30 03:23:09 0|cluelessperson|esotericnonsense: to summarize agreed point, you'd like me to resync under the same conditions, without pruning?
20 2017-10-30 03:23:20 0|cluelessperson|esotericnonsense: allowing you to view pruned and non-pruned results?
21 2017-10-30 03:23:46 0|esotericnonsense|yeah. it's not that important, I already know the results, i'm just interested in precisely how much fastr it ends up being
22 2017-10-30 03:23:48 0|esotericnonsense|faster*
23 2017-10-30 03:25:00 0|cluelessperson|esotericnonsense: how much faster pruning ends up being? or not pruning ends up being than pruned?
24 2017-10-30 03:25:08 0|cluelessperson|and GO!
25 2017-10-30 03:25:10 0|cluelessperson|it's running
26 2017-10-30 03:25:31 0|esotericnonsense|cluelessperson: not pruning should be faster because the utxo cache gets flushed completely on every prune event
27 2017-10-30 03:25:45 0|esotericnonsense|which is every ~128mb
28 2017-10-30 03:25:51 0|cluelessperson|ah
29 2017-10-30 03:26:38 0|cluelessperson|esotericnonsense: for the record, these are my settings https://hastebin.com/raw/povagogajo
30 2017-10-30 03:27:27 0|cluelessperson|esotericnonsense: I have the dbcache set to 10000
31 2017-10-30 03:30:37 0|cluelessperson|esotericnonsense: it looks faster
32 2017-10-30 03:31:56 0|esotericnonsense|it won't make much difference until you get a sizeable dbcache but yeah it is faster. just wondering whether it's actually say half the time. i killed it at block 200K because I only have one ssd and need the space :P
33 2017-10-30 03:32:58 0|cluelessperson|esotericnonsense: it's already at 10%
34 2017-10-30 04:35:24 0|cluelessperson|esotericnonsense: well, unfortunately, I ran out of space
35 2017-10-30 04:35:29 0|cluelessperson|esotericnonsense: but it seems WAY faster
36 2017-10-30 09:33:39 0|bitcoin-git|[13bitcoin] 15practicalswift opened pull request #11577: Fix warnings (-Wsign-compare) when building with DEBUG_ADDRMAN (06master...06DEBUG_ADDRMAN-warnings) 02 https://github.com/bitcoin/bitcoin/pull/11577
37 2017-10-30 13:36:58 0|bitcoin-git|[13bitcoin] 15practicalswift opened pull request #11578: net: Add missing lock in ProcessHeadersMessage(...) (06master...06ProcessHeadersMessage) 02 https://github.com/bitcoin/bitcoin/pull/11578
38 2017-10-30 13:58:50 0|bitcoin-git|[13bitcoin] 15gladosconn opened pull request #11579: Fix int uint64_t comparison warning. (06master...06master) 02 https://github.com/bitcoin/bitcoin/pull/11579
39 2017-10-30 14:31:39 0|bitcoin-git|[13bitcoin] 15gladosconn closed pull request #11579: Fix int uint64_t comparison warning. (06master...06master) 02 https://github.com/bitcoin/bitcoin/pull/11579
40 2017-10-30 14:45:38 0|bitcoin-git|[13bitcoin] 15TheBlueMatt opened pull request #11580: Do not send (potentially) invalid headers in response to getheaders (06master...062017-10-getheaders-valid-only) 02 https://github.com/bitcoin/bitcoin/pull/11580
41 2017-10-30 14:56:50 0|wxss|sipa mentioned undocumented -stopatheight here yesterday. Is the opposite possible, to restart downloading at/from a specified block height?
42 2017-10-30 14:57:23 0|promag|BlueMatt: mapBlockIndex can contain "invalid" blocks (where IsValid(BLOCK_VALID_SCRIPTS) is false)?
43 2017-10-30 15:01:36 0|sipa|promag: yes, absolutely
44 2017-10-30 15:01:44 0|sipa|as blocks are only validated after storing them
45 2017-10-30 15:01:54 0|jimpo|promag: They wouldn't necessarily be "invalid", just not known to be valid.
46 2017-10-30 15:02:11 0|sipa|mapBlockIndex only guarantees that the *headers* are valid
47 2017-10-30 15:02:23 0|jimpo|Though I think the index includes invalid blocks as well
48 2017-10-30 15:02:32 0|sipa|the blocks themselves are downloaded afterwards, and may turn out to be invalid
49 2017-10-30 15:02:53 0|sipa|jimpo: yes, we store invalid blocks in the index
50 2017-10-30 15:03:16 0|promag|and once invalid it is kept in the index?
51 2017-10-30 15:03:21 0|sipa|yes
52 2017-10-30 15:03:28 0|sipa|the header will be marked as invalid even
53 2017-10-30 15:04:36 0|promag|so the following can be simplified:
54 2017-10-30 15:04:38 0|promag|if (punish_duplicate_invalid && mapBlockIndex.find(first_invalid_header.GetHash()) != mapBlockIndex.end())
55 2017-10-30 15:04:59 0|promag|because if the header is invalid then it is not in the block index right?
56 2017-10-30 15:06:11 0|promag|since above you said "mapBlockIndex only guarantees that the *headers* are valid"
57 2017-10-30 15:07:54 0|luke-jr|hmm, is there a good overview of what is needed to add -usehd=0 back in?
58 2017-10-30 15:08:19 0|BlueMatt|promag: you mean in sdaftuar's pr?
59 2017-10-30 15:08:22 0|luke-jr|basically just make sure it works without a default key, right?
60 2017-10-30 15:08:43 0|BlueMatt|promag: no, the point of that check is to see if the header was accepted (ie if it is known to be a valid header)
61 2017-10-30 15:15:58 0|promag|@BlueMatt please correct me if this isn't the same: if (punish_duplicate_invalid && !first_invalid_header.IsNull())
62 2017-10-30 16:56:57 0|sdaftuar|can someone tag #11578 for backport to 0.15.0.2?
63 2017-10-30 16:56:59 0|gribble|https://github.com/bitcoin/bitcoin/issues/11578 | net: Add missing lock in ProcessHeadersMessage(...) by practicalswift ÷ Pull Request #11578 ÷ bitcoin/bitcoin ÷ GitHub
64 2017-10-30 17:04:40 0|wumpus|sdaftuar: done
65 2017-10-30 17:04:47 0|sdaftuar|thanks!
66 2017-10-30 17:17:41 0|achow101|luke-jr: it has to work without a default key and cannot be downgraded
67 2017-10-30 17:18:37 0|achow101|promag: the first_invalid_header could be in mapBlockIndex
68 2017-10-30 17:21:50 0|achow101|promag: specifically if a block was invalid but the header was valid, the header would be in mapBlockIndex. if another peer sent us the exact same header, it would still be in mapBlockIndex and that is what that if statement is checking for
69 2017-10-30 18:27:52 0|sdaftuar|has travis been flaky lately? i'm seeing a wallet.py error in one of the functional tests runs for #11560
70 2017-10-30 18:27:54 0|gribble|https://github.com/bitcoin/bitcoin/issues/11560 | Connect to a new outbound peer if our tip is stale by sdaftuar ÷ Pull Request #11560 ÷ bitcoin/bitcoin ÷ GitHub
71 2017-10-30 18:29:39 0|sipa|badstatusline
72 2017-10-30 18:29:46 0|sipa|(line 2818)
73 2017-10-30 18:30:00 0|sdaftuar|yeah i don't know what would cause that
74 2017-10-30 18:30:46 0|sipa|let's try restarting
75 2017-10-30 18:32:14 0|sdaftuar|restarted
76 2017-10-30 18:34:42 0|BlueMatt|ryanofsky: did you actually see the test in #11531 hang?
77 2017-10-30 18:34:44 0|gribble|https://github.com/bitcoin/bitcoin/issues/11531 | Check that new headers are not a descendant of an invalid block (more effeciently) by TheBlueMatt ÷ Pull Request #11531 ÷ bitcoin/bitcoin ÷ GitHub
78 2017-10-30 18:34:46 0|BlueMatt|I can bump the timeout there
79 2017-10-30 18:34:55 0|ryanofsky|no
80 2017-10-30 18:35:40 0|ryanofsky|the code just seems unnecessarily complicated and probably flaky
81 2017-10-30 18:36:35 0|BlueMatt|I mean all I can do is bump the timeout there, really
82 2017-10-30 18:36:47 0|BlueMatt|I think when i go to rewrite the dos logic stuff soon it will change behavior
83 2017-10-30 18:36:53 0|BlueMatt|and no need for the test to test for it
84 2017-10-30 18:39:06 0|ryanofsky|can you simplify the test by skipping the ping and just waiting for the disconnect?
85 2017-10-30 18:40:09 0|BlueMatt|no, because I believe it currently does not disconnect
86 2017-10-30 18:40:12 0|BlueMatt|right now it uses the ping path
87 2017-10-30 18:40:17 0|BlueMatt|but really it should be disconnecting
88 2017-10-30 18:41:26 0|ryanofsky|then i don't see what you lose by dropping the exception handler completely and updating the test when you do add a disconnect
89 2017-10-30 18:41:43 0|BlueMatt|because I'm probably gonna need the exception handler in like a month
90 2017-10-30 18:41:52 0|BlueMatt|and testing for something that bitcoind really shouldnt be doing anyway is kinda nonsense
91 2017-10-30 18:42:28 0|ryanofsky|how do you even know the exception handler works?
92 2017-10-30 18:43:48 0|BlueMatt|i tested it :)
93 2017-10-30 18:44:20 0|BlueMatt|iirc you can just change the dos points for whatever case its using to make the block invalid trivially and it'll keep chugging along
94 2017-10-30 18:48:22 0|ryanofsky|ok well do what you want, but if were me i would opt for not adding a potentially flaky 1-sec timeout and confusing code that doesn't get executed
95 2017-10-30 18:50:08 0|bitcoin-git|[13bitcoin] 15luke-jr opened pull request #11582: wallet: Restore -usehd=0 option (06master...06usehd) 02 https://github.com/bitcoin/bitcoin/pull/11582
96 2017-10-30 18:52:50 0|BlueMatt|i mean its not like we dont have other timeouts in the tests, no?
97 2017-10-30 18:52:58 0|BlueMatt|I can set it higher if that makes it much less flaky
98 2017-10-30 20:17:04 0|maaku|does anyone have a list of version bits currently being used, including unofficially?
99 2017-10-30 20:19:26 0|ossifrage|I wonder what the 0.15.x based btc1 code did to break networking during initial block download (it runs for a while, then all the peers timeout, then I get nothing but version handshake timeouts and it makes minimal further progress with 0 or 1 peers)
100 2017-10-30 20:37:07 0|gmaxwell|ossifrage: sounds like you're confirming something like wxss's result-- but sadly, this is offtopic for here, as we don't debug adversarial fork's problems here. :)
101 2017-10-30 20:38:39 0|ossifrage|gmaxwell, I agree, I was just curious how it could break in such a odd way.
102 2017-10-30 20:55:34 0|wxss|gmaxwell, absolutely agree. My issue was different, but this is not the place for analyzing it further
103 2017-10-30 23:01:35 0|bitcoin-git|[13bitcoin] 15TheBlueMatt opened pull request #11583: Do not make it trivial for inbound peers to generate log entries (06master...062017-10-no-net-log) 02 https://github.com/bitcoin/bitcoin/pull/11583