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) 02https://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) 02https://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) 02https://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) 02https://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) 02https://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) 02https://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) 02https://github.com/bitcoin/bitcoin/pull/11583