1 2016-09-23 00:11:43	0|GitHub44|[13bitcoin] 15gmaxwell opened pull request #8800: Fetch w/o CB if mempool empty, don't use HB mode if blocks only. (06master...06no-hb-in-bo) 02https://github.com/bitcoin/bitcoin/pull/8800
  2 2016-09-23 00:12:32	0|gmaxwell|hm. that allow edits thing defaults to on, so next time someone PRs their whole altcoin to our repo we could go and replace their code with bitcoin? :P  "we upgraded your altcoin, enjoy!"
  3 2016-09-23 00:13:20	0|luke-jr|lol
  4 2016-09-23 00:14:59	0|sipa|gmaxwell: only the PRed branch opens up
  5 2016-09-23 00:15:17	0|sipa|ah, for that example that may be sufficient, actually...
  6 2016-09-23 00:22:36	0|gmaxwell|yes, that was what I was thinking.
  7 2016-09-23 00:24:59	0|sipa|we should see what happens if you PR to two projects at once
  8 2016-09-23 04:58:54	0|luke-jr|do we currently have a way to turn off NODE_NETWORK without enabling pruning?
  9 2016-09-23 05:00:05	0|gmaxwell|no, why would we?
 10 2016-09-23 05:00:20	0|luke-jr|so people don't IBD off me <.<
 11 2016-09-23 05:00:33	0|gmaxwell|oh well set the upload limiter to a tiny number. :)
 12 2016-09-23 05:00:40	0|gmaxwell|and you'll hang up on them when they do.
 13 2016-09-23 05:00:53	0|luke-jr|yeah, I'd rather just not have them ask though
 14 2016-09-23 05:01:19	0|luke-jr|otoh, I guess I have no reason to discourage light clients from connecting to me..
 15 2016-09-23 05:01:40	0|gmaxwell|fwiw, I found more bandwidth was being used by bitcoinj clients than ibding bitcoin core.
 16 2016-09-23 05:02:40	0|luke-jr|O.o
 17 2016-09-23 05:02:46	0|luke-jr|that's unexpected
 18 2016-09-23 08:38:04	0|phantomcircuit|i was thinking of using an RAII wrapper for the CWalletDB pointer in CWallet
 19 2016-09-23 08:38:18	0|phantomcircuit|does anybody have an opinion on how that should be structured
 20 2016-09-23 08:43:08	0|phantomcircuit|luke-jr: they do all kinds of silly things compared to 1MB/10 minutes
 21 2016-09-23 08:43:44	0|luke-jr|phantomcircuit: IBD isn't 1 MB/10 min
 22 2016-09-23 08:59:13	0|wallet42|is there a proposal of having NODE_2WEEKS or something like that? a node that guarantees the serve of all block headers + the bodies for the past 2016 blocks but nothing earlier?
 23 2016-09-23 09:00:39	0|luke-jr|wallet42: no, I don't know that there's value to it
 24 2016-09-23 09:01:12	0|luke-jr|wallet42: next step seems like it would be something where nodes all store a random assortment of history similar to bittorrent swarms, but even that's unnecessary today
 25 2016-09-23 09:02:53	0|wallet42|i think sipa posted a while ago a histogram showing the #getblocks[height]
 26 2016-09-23 09:03:22	0|wallet42|and its obviously heavily dispropotionate towards the recent blocks
 27 2016-09-23 09:05:12	0|wallet42|if you can configure the node to only serve the last 2 weeks (especially with the NODE_BLOOM overhead) it makes it cheaper. also 2 weeks of blocks can be held completly in RAM/mmap so running the bloom filter doesnt even requires HDD/SDD access
 28 2016-09-23 09:05:18	0|luke-jr|yes, but there is no shortage of dumb servers that serve the full chain anyway
 29 2016-09-23 09:08:12	0|blaker|hi bitcoin core devs. I am at a conference where a talk later today called 'exploiting trust in deterministic builds' is going to be presented. Since you use reproducible builds maybe it is of interest. paper should be available via springer
 30 2016-09-23 09:36:09	0|jl2012|It seems #8499 is considered as a blocker for 0.13.1. Could I do anything to make the review easier?
 31 2016-09-23 10:37:27	0|wumpus|gmaxwell: it ended up where most of my projects go, unfortunately. to the long backlog, I still intend to do it some time. Or anyone else can pick it up if they want.
 32 2016-09-23 10:45:39	0|GitHub132|13bitcoin/06master 14f839350 15Pavel Janík: Do not shadow in src/qt
 33 2016-09-23 10:45:39	0|GitHub132|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/2b514aa2eae6...5d0219d983b6
 34 2016-09-23 10:45:40	0|GitHub132|13bitcoin/06master 145d0219d 15Wladimir J. van der Laan: Merge #8793: Do not shadow in src/qt...
 35 2016-09-23 10:45:54	0|GitHub128|[13bitcoin] 15laanwj closed pull request #8793: Do not shadow in src/qt (06master...0620160922_Wshadow_qt) 02https://github.com/bitcoin/bitcoin/pull/8793
 36 2016-09-23 10:55:30	0|phantomcircuit|wallet42: there have been various ideas for doing some kind of sharding they all have issues though
 37 2016-09-23 10:55:37	0|phantomcircuit|you really dont want to rebalance constantly
 38 2016-09-23 10:55:49	0|phantomcircuit|but you also dont want the blocks a node stores to be based on when it joined the network
 39 2016-09-23 10:56:09	0|phantomcircuit|achieving both goals turns out to be non trivial
 40 2016-09-23 10:57:08	0|sipa|i've been keeping statistics on the depth of blocks being requested from my node
 41 2016-09-23 10:57:45	0|sipa|the tip is of course by far the most requested (though i'm not counting CB HB mode sends)
 42 2016-09-23 10:58:18	0|sipa|but after about 2 months deep the distribution is almost uniform down to genesis
 43 2016-09-23 10:58:55	0|luke-jr|how long have you been keeping statistics? (2 months? :P)
 44 2016-09-23 10:59:10	0|sipa|eh, yes
 45 2016-09-23 10:59:36	0|sipa|but the numbers i'm aggregating are for the block depth compared to the tip at the time it was requested
 46 2016-09-23 10:59:43	0|luke-jr|oh, hm
 47 2016-09-23 10:59:45	0|sipa|not absolute height
 48 2016-09-23 11:02:01	0|sipa|it's much more spread out than i had anticipated, actually
 49 2016-09-23 11:02:19	0|sipa|this implies that a lot of people sync while being 1-2 months behind
 50 2016-09-23 11:02:37	0|sipa|overall, it's 7.5 million block downloads
 51 2016-09-23 11:02:45	0|sipa|so not just some random outliers
 52 2016-09-23 11:03:40	0|sipa|about 100k of which are at the tip
 53 2016-09-23 11:07:05	0|sipa|and there are strange peaks around 820 deep and 1970 deep
 54 2016-09-23 11:56:31	0|GitHub8|13bitcoin/06master 146d0ced1 15Gregory Maxwell: Do not set an addr time penalty when a peer advertises itself....
 55 2016-09-23 11:56:31	0|GitHub8|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/5d0219d983b6...d2e46558ba0e
 56 2016-09-23 11:56:32	0|GitHub8|13bitcoin/06master 14d2e4655 15Wladimir J. van der Laan: Merge #8661: Do not set an addr time penalty when a peer advertises itself....
 57 2016-09-23 11:56:38	0|GitHub141|[13bitcoin] 15laanwj closed pull request #8661: Do not set an addr time penalty when a peer advertises itself. (06master...06addrman_nopenalty_self) 02https://github.com/bitcoin/bitcoin/pull/8661
 58 2016-09-23 13:15:33	0|jonasschnelli|Anyone interested in reviewing the "generic"-statistics PR (currently mempool only)? https://github.com/bitcoin/bitcoin/pull/8501
 59 2016-09-23 13:15:52	0|jonasschnelli|The GUI mempool stats are based on that PR
 60 2016-09-23 15:32:31	0|dgenr8|sipa: it sounds like an exponential dropoff from existing nodes syncing, plus a constant level of new nodes being spun up or reloaded
 61 2016-09-23 16:18:53	0|jonasschnelli|To bad github doesn't allow editing a review after posting it
 62 2016-09-23 16:19:06	0|jonasschnelli|or do I miss something?
 63 2016-09-23 16:19:35	0|achow101|jonasschnelli: nope, not missing anything.
 64 2016-09-23 16:19:52	0|jonasschnelli|hmm.. I hope they will add this soon
 65 2016-09-23 16:23:16	0|GitHub48|[13bitcoin] 15jonasschnelli pushed 8 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/d2e46558ba0e...24f72e9f3fd0
 66 2016-09-23 16:23:17	0|GitHub48|13bitcoin/06master 140904c3c 15Jonas Schnelli: [Refactor] refactor function that forms human readable text out of a timeoffset
 67 2016-09-23 16:23:17	0|GitHub48|13bitcoin/06master 14bd44a04 15Jonas Schnelli: [Qt] make Out-Of-Sync warning icon clickable
 68 2016-09-23 16:23:18	0|GitHub48|13bitcoin/06master 14a001f18 15Jonas Schnelli: [Qt] Always pass the numBlocksChanged signal for headers tip changed
 69 2016-09-23 16:23:21	0|GitHub168|[13bitcoin] 15jonasschnelli closed pull request #8371: [Qt] Add out-of-sync modal info layer (06master...062016/07/UI-out-of-sync) 02https://github.com/bitcoin/bitcoin/pull/8371
 70 2016-09-23 16:41:30	0|morcos|cfields: gentle ping
 71 2016-09-23 16:41:46	0|cfields|morcos: pong
 72 2016-09-23 16:41:56	0|morcos|just wanted to follow up on the copy-move
 73 2016-09-23 16:42:15	0|morcos|i thought you had already had move to prevector though in that branch?
 74 2016-09-23 16:42:20	0|cfields|morcos: i messed with the move stuff yesterday. I can push my changes if you'd like, but i traced through to see where it's called (I put asserts in the moves), and they're almost zero
 75 2016-09-23 16:42:48	0|morcos|ah, so we need to make moves of transactions or scripts or something?
 76 2016-09-23 16:42:54	0|cfields|morcos: so i think if there's any benefit that you're seeing, it's probably in a very subtle change:
 77 2016-09-23 16:43:15	0|cfields|morcos: that's what i did in the commit, so they're all movable now. but, we're pretty good about not doing that
 78 2016-09-23 16:43:22	0|cfields|(there are .swap()s all over the place)
 79 2016-09-23 16:43:44	0|morcos|its a clear benefit, but unfortunately in one of the vagaries of this stuff, the benefit is reduced with jeremy's replacement for the boost lockfree queue.  not sure why in the world that would be the case
 80 2016-09-23 16:44:16	0|morcos|where are the few places its called?
 81 2016-09-23 16:44:22	0|cfields|i have few possible explanations there
 82 2016-09-23 16:44:31	0|cfields|brb 2 min
 83 2016-09-23 16:48:54	0|cfields|morcos: ok, back. First let me push up those changes so we can be sure we're comparing the same things. 1 min.
 84 2016-09-23 16:56:38	0|cfields|morcos: sigh. as usual, i had my wires crossed. I was looking at the wrong branch. Yea, the moves are already in there so you're already testing with that
 85 2016-09-23 16:57:43	0|cfields|apparently i re-did that yesterday with no memory of doing it the first time...
 86 2016-09-23 16:57:48	0|morcos|cfields: np. but do you still think it shouldn't be much improvement?
 87 2016-09-23 16:57:51	0|morcos|oh no
 88 2016-09-23 16:57:53	0|morcos|ha
 89 2016-09-23 16:58:21	0|cfields|morcos: i don't think there are many moves, no. I think jeremy's code might've gotten rid of the few that are there. sec
 90 2016-09-23 17:02:17	0|cfields|hm, maybe not. looks like it just saves on allocation
 91 2016-09-23 17:04:12	0|cfields|morcos: it should be pretty easy to compare copies/moves before/after the checkqueue changes. We could just add static incrementors for all copies and moves and see how they change
 92 2016-09-23 17:04:54	0|cfields|morcos: do you have a specific bench you've been using to test?
 93 2016-09-23 17:07:49	0|morcos|cfields: sorry i wasn't clear.  it wasn't the checkqueue changes.  it was the sigcache lock contention fix.  i had been using a boost lockfree queue and jeremy wrote a custom "cuckoo cache" which i like the design of a lot
 94 2016-09-23 17:08:08	0|morcos|without your copy/move changes they are equivalent , but with, the boost lock free queue improves more
 95 2016-09-23 17:08:11	0|morcos|very odd
 96 2016-09-23 17:08:13	0|morcos|should be unrelated i think
 97 2016-09-23 17:08:20	0|morcos|anyway, don't worry about it
 98 2016-09-23 17:08:54	0|morcos|only thing that would be useful if you could point me to where the moves happen the most..  but i'm going down 3 other rabbit holes at the moment, so don't get distracted from whatever you're doing
 99 2016-09-23 17:08:56	0|cfields|oh, i see. Sounds like you had some copies/moves in your boost branch, then
100 2016-09-23 17:09:38	0|sipa|cuckoo cache, sounds fancy!
101 2016-09-23 17:10:52	0|morcos|sipa: it's cool!
102 2016-09-23 17:11:26	0|sipa|i know cuckoo hashtables
103 2016-09-23 17:11:34	0|sipa|it is related?
104 2016-09-23 17:11:39	0|morcos|yep
105 2016-09-23 17:14:04	0|cfields|morcos: i believe the only hot move is in the checkqueue. https://github.com/bitcoin/bitcoin/blob/master/src/checkqueue.h#L150
106 2016-09-23 17:14:20	0|cfields|and obviously that's not very significant
107 2016-09-23 17:15:25	0|morcos|cool thx
108 2016-09-23 17:18:29	0|cfields|morcos: and here are my changes to make the moves go away: http://pastebin.com/raw/LpGPzjFu
109 2016-09-23 17:19:38	0|cfields|the emplace in CheckInputs could be significant if don't have something like that in your branch already
110 2016-09-23 18:18:20	0|jeremyrubin|ls
111 2016-09-23 18:18:25	0|jeremyrubin|oops
112 2016-09-23 18:18:52	0|jeremyrubin|cfields: that code already exists on his branch
113 2016-09-23 18:27:49	0|morcos|sipa: if you don't know, i'll try to figure it out.  But among the consequences of the txChanged PR that made syncWithWallets happen in ActivateBestChain instead of ConnectTip, is you could get a reordering of when SyncWithWallets is called on various txs
114 2016-09-23 18:28:46	0|morcos|For instance if during the processing of ABC, you both connect tips and disconnect them trying to find the longest valid chain...  for all the connects you'll be building up syncWithWallets to call at the end and for all the disconnects you'll be calling SyncWithWallets as you go
115 2016-09-23 18:29:05	0|morcos|i don't have a good mental model for how SyncWithWallets should be used
116 2016-09-23 18:29:10	0|morcos|perhaps i should be asking jonasschnelli
117 2016-09-23 18:47:36	0|cfields|jeremyrubin: ah, thanks
118 2016-09-23 18:52:36	0|morcos|sipa: jonasschnelli: well, as far as i can tell it seems ok i guess..  but i don't know how to be very confident
119 2016-09-23 19:50:12	0|GitHub166|[13bitcoin] 15tjps opened pull request #8801: [trivial] Switching from Boost for-each macros to C++11 for-each (06master...06tjps_foreach) 02https://github.com/bitcoin/bitcoin/pull/8801