1 2017-04-19 02:58:25	0|bitcoin-git|[13bitcoin] 15jimmysong opened pull request #10229: Tests: Add test for getdifficulty (06master...06test_getdifficulty) 02https://github.com/bitcoin/bitcoin/pull/10229
  2 2017-04-19 07:38:13	0|wumpus|git add --patch is so useful
  3 2017-04-19 07:40:05	0|wumpus|it's essential if you want to add just some changes in a file to a commit but not all. Only discovered this recently, don't ask what hacks I was doing to accomplish that before...
  4 2017-04-19 07:41:02	0|sipa|you can also use it split existing commits
  5 2017-04-19 07:41:25	0|sipa|during a rebase, while editing a commit, use git reset HEAD~
  6 2017-04-19 07:41:40	0|sipa|then git add -p to select the changes to be in the first half
  7 2017-04-19 07:41:54	0|sipa|git commit -m first; git commit -am second
  8 2017-04-19 07:42:18	0|wumpus|'git gui' can also be used for this (you can stage and unstage individual lines, even), but usually work in the console so that was kind of annoying
  9 2017-04-19 07:42:28	0|wumpus|ah great
 10 2017-04-19 07:42:53	0|sipa|and then git rebase --continue
 11 2017-04-19 07:59:13	0|wumpus|is there anything (almost) ready for merging?
 12 2017-04-19 08:26:02	0|wumpus|thought #10143 was, but needs some minor changes still
 13 2017-04-19 08:26:04	0|gribble|https://github.com/bitcoin/bitcoin/issues/10143 | [net] Allow disconnectnode RPC to be called with node id by jnewbery · Pull Request #10143 · bitcoin/bitcoin · GitHub
 14 2017-04-19 08:33:07	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #9524: rpc: Don't FlushStateToDisk when pruneblockchain(0) (06master...06Mf1701-qaPruning) 02https://github.com/bitcoin/bitcoin/pull/9524
 15 2017-04-19 08:42:27	0|paveljanik|wumpus, #10226?
 16 2017-04-19 08:42:28	0|gribble|https://github.com/bitcoin/bitcoin/issues/10226 | wallet: Use boost to more portably ensure -wallet specifies only a filename by luke-jr · Pull Request #10226 · bitcoin/bitcoin · GitHub
 17 2017-04-19 08:44:56	0|wumpus|yes, that one is very straightforward
 18 2017-04-19 08:55:40	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/9111df9673be...64c45aada702
 19 2017-04-19 08:55:41	0|bitcoin-git|13bitcoin/06master 1464c45aa 15Wladimir J. van der Laan: Merge #10226: wallet: Use boost to more portably ensure -wallet specifies only a filename...
 20 2017-04-19 08:55:41	0|bitcoin-git|13bitcoin/06master 14a4186dd 15Luke Dashjr: wallet: Use boost to more portably ensure -wallet specifies only a filename
 21 2017-04-19 08:56:05	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #10226: wallet: Use boost to more portably ensure -wallet specifies only a filename (06master...06refactor_wallet_pathsep) 02https://github.com/bitcoin/bitcoin/pull/10226
 22 2017-04-19 09:15:33	0|bitcoin-git|13bitcoin/06master 14608bbcc 15Matt Corallo: [qt] Stop treating coinbase outputs differently: show them at 1conf
 23 2017-04-19 09:15:33	0|bitcoin-git|[13bitcoin] 15jonasschnelli pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/64c45aada702...e96486cbebc6
 24 2017-04-19 09:15:34	0|bitcoin-git|13bitcoin/06master 14e96486c 15Jonas Schnelli: Merge #10221: Stop treating coinbase outputs differently in GUI: show them at 1conf...
 25 2017-04-19 09:15:54	0|bitcoin-git|[13bitcoin] 15jonasschnelli closed pull request #10221: Stop treating coinbase outputs differently in GUI: show them at 1conf (06master...062017-04-no-coinbase-display-lag) 02https://github.com/bitcoin/bitcoin/pull/10221
 26 2017-04-19 09:21:01	0|jonasschnelli|Anyone has an opinion on: https://github.com/bitcoin/bitcoin/pull/9502
 27 2017-04-19 09:21:18	0|jonasschnelli|I think it's useful even if there is the "hidden" feature of clicking the peers-statusbar-icon
 28 2017-04-19 10:24:33	0|jonasschnelli|I think this is RFM: https://github.com/bitcoin/bitcoin/pull/9827
 29 2017-04-19 10:29:33	0|wumpus|yep, thanks
 30 2017-04-19 10:30:26	0|bitcoin-git|13bitcoin/06master 1430abce7 15Russell Yanofsky: Improve ScanForWalletTransactions return value...
 31 2017-04-19 10:30:26	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/e96486cbebc6...c91ca0ace9bd
 32 2017-04-19 10:30:27	0|bitcoin-git|13bitcoin/06master 14c91ca0a 15Wladimir J. van der Laan: Merge #9827: Improve ScanForWalletTransactions return value...
 33 2017-04-19 10:30:40	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #9827: Improve ScanForWalletTransactions return value (06master...06pr/scanret) 02https://github.com/bitcoin/bitcoin/pull/9827
 34 2017-04-19 10:37:17	0|wumpus|jonasschnelli: and yes I think it can be a useful feature
 35 2017-04-19 10:37:32	0|jonasschnelli|wumpus: Thanks for the review.
 36 2017-04-19 10:37:37	0|jonasschnelli|Will fix your points soon
 37 2017-04-19 12:31:05	0|instagibbs|wumpus, git add -p also works line by line, in manual edit mode
 38 2017-04-19 12:32:29	0|instagibbs|'s' to keep splitting chunks, if not granular enough, 'e' for manual editor. A bit confusing at first but description is at end.
 39 2017-04-19 12:36:52	0|wumpus|instagibbs: ah :) thanks
 40 2017-04-19 14:19:35	0|BlueMatt|fully-flushed state prior to block disconnect seems perfectly reasonable
 41 2017-04-19 14:19:35	0|BlueMatt|sipa: re #10148: I'm still super unconvinced that multi-head is worth it. in the future optimization space of "flush in chunks in the background", there is relatively little harm in requiring that mid-flush-states be in only one direction - either you're during ibd, in which cas I'd certainly hope this is already the case, or you're not in which case it should be relatively rare that your disk cant keep up and enforcing a
 42 2017-04-19 14:19:38	0|gribble|https://github.com/bitcoin/bitcoin/issues/10148 | [WIP] Use non-atomic flushing with block replay by sipa · Pull Request #10148 · bitcoin/bitcoin · GitHub
 43 2017-04-19 14:19:52	0|BlueMatt|sipa: not to mention multihead is super hard to review right now since we dont even have the write side of it implemented
 44 2017-04-19 14:20:00	0|BlueMatt|so the assumptions on the read side just seem arbitrary
 45 2017-04-19 14:20:07	0|BlueMatt|(and complicated)
 46 2017-04-19 14:20:15	0|sipa|BlueMatt: i don't think it's reasonanle to require a full flush before a reorg
 47 2017-04-19 14:21:05	0|sipa|reorgs should lead to network-wide slowdowns
 48 2017-04-19 14:21:29	0|sipa|and the write side is partially implemented; i'm writing a test for it now
 49 2017-04-19 14:25:07	0|BlueMatt|sipa: why? if your node cant finish flushing its state before the next block comes in 9 times out of 10 you have no hope of staying up to date anyway
 50 2017-04-19 14:25:36	0|sipa|BlueMatt: the idea is that you'd be flushing continuously
 51 2017-04-19 14:25:42	0|sipa|and never fully flush
 52 2017-04-19 14:25:49	0|BlueMatt|sipa: why?
 53 2017-04-19 14:25:56	0|BlueMatt|why would you want to never fully flush
 54 2017-04-19 14:26:01	0|BlueMatt|that'd mean startup would always be painfully slow
 55 2017-04-19 14:26:01	0|sipa|because wiping your cache is retarded
 56 2017-04-19 14:26:17	0|BlueMatt|well then dont wipe cache when you flush :)
 57 2017-04-19 14:26:25	0|BlueMatt|thats an orthogonal issue, i think
 58 2017-04-19 14:26:30	0|sipa|it isn't
 59 2017-04-19 14:26:40	0|sipa|if you don't wipe when you flush, you need to flush more frequently
 60 2017-04-19 14:26:59	0|sipa|and we've benchmarked that (before non-atomic flush)... it's slower
 61 2017-04-19 14:27:00	0|BlueMatt|what happened to always flushing in the background?
 62 2017-04-19 14:27:41	0|sipa|we're already flushing outside of normal block connection
 63 2017-04-19 14:27:59	0|sipa|it's still just more CPU to not wipe your cache
 64 2017-04-19 14:28:09	0|morcos|sipa: at the very least this is an unnecessarily complicated optimization for right now
 65 2017-04-19 14:28:12	0|sipa|(again, before non-atomic)
 66 2017-04-19 14:28:34	0|morcos|this code is difficult to reason about with high certainty and i think BlueMatt is right that multi-head really compounds that
 67 2017-04-19 14:28:48	0|morcos|If we decide we need it later, we can discuss it then...
 68 2017-04-19 14:29:08	0|sipa|morcos: i think both the test code i'm writing and the recovery code would he hardly any simpler without it
 69 2017-04-19 14:29:24	0|morcos|Ideally I think we would do #10195 first and not make that contingent on 10148 (w or w/o multihead)
 70 2017-04-19 14:29:24	0|sipa|it still needs to be able to deal with reorgs, just not multi-headed ones
 71 2017-04-19 14:29:26	0|gribble|https://github.com/bitcoin/bitcoin/issues/10195 | Switch chainstate db and cache to per-txout model by sipa · Pull Request #10195 · bitcoin/bitcoin · GitHub
 72 2017-04-19 14:29:37	0|sipa|oh
 73 2017-04-19 14:29:43	0|sipa|that's certainly possible
 74 2017-04-19 14:30:54	0|morcos|the issue i see with 10148 is that it seems like a lot of complication to solve a relatively simple problem about the way leveldb flushes...   it seems to me it would make more sense to review flush/don't erase strategies with 10195 as a first step
 75 2017-04-19 14:31:00	0|BlueMatt|sipa: I'm more than happy to revisit multihead after per-utxo, but right now I'm super worried about the complication in it
 76 2017-04-19 14:31:30	0|sipa|BlueMatt: if i put an assert(blockhead.size() == 2), would you be happy about it?
 77 2017-04-19 14:31:44	0|morcos|maybe we eventually want to do 10148, but i'm hesitant to rework cache writiing in 2 big ways at the same time...
 78 2017-04-19 14:32:01	0|sipa|i think 10148 is much more urgent
 79 2017-04-19 14:32:18	0|sipa|it dramatically changes our memory usage
 80 2017-04-19 14:32:26	0|morcos|so does 10195?
 81 2017-04-19 14:32:38	0|sipa|how so?
 82 2017-04-19 14:32:57	0|morcos|for the same cache performance you can have a much smaller cache
 83 2017-04-19 14:33:30	0|sipa|eh, slightly
 84 2017-04-19 14:33:55	0|sipa|anyway, i'm happy to rebase 10195 without 10148
 85 2017-04-19 14:34:04	0|sipa|i just assumed we'd want 10148 sooner
 86 2017-04-19 14:34:46	0|BlueMatt|sipa: possibly I'd be ok with an assert like that, but then why have the much more complicated code in our consensus logic when we can push that review to when we actually remove the assert, right where it should be? Otherwise you have dormant code and people wont sufficiently review it when it becomes active?
 87 2017-04-19 14:34:51	0|morcos|really?  only slightly?  i haven't tested 10195 yet, but it was my memory that a lot of the cache mem usage was taken up with dead weight from txs you bring along
 88 2017-04-19 14:35:01	0|BlueMatt|I tend to agree that I like 10148, personally
 89 2017-04-19 14:35:15	0|BlueMatt|i mean both, dont really care tooo much about order, just dont think we need to worry about multi-head
 90 2017-04-19 14:35:23	0|sipa|morcos: but with 10195 you get duplication instead
 91 2017-04-19 14:35:39	0|morcos|in memory?
 92 2017-04-19 14:35:42	0|sipa|yes
 93 2017-04-19 14:35:55	0|morcos|oh i havent' reveiwed 10195 yet, i was envisioning a structure without duplication
 94 2017-04-19 14:35:55	0|sipa|if multiple outputs for the same tx are in the cache, they become independent entries
 95 2017-04-19 14:36:03	0|morcos|like a multi level cache
 96 2017-04-19 14:36:20	0|sipa|we can think about that later, first switch the model to be per-txout
 97 2017-04-19 14:36:44	0|morcos|ok, well i'll shut up until i review more... but i have to say, the complication of 10148 turns me off from getting to 10195!
 98 2017-04-19 14:37:01	0|sipa|have you seen the commit i just added to 10148?
 99 2017-04-19 14:37:36	0|sipa|well, yesterdat
100 2017-04-19 14:37:41	0|morcos|Yes...  And the part that is confusing is the Multiple reorganizations
101 2017-04-19 14:37:55	0|morcos|Thats still not clear to me exactly what scenario you guys are envisioning that results in that
102 2017-04-19 14:38:20	0|BlueMatt|frankly, we only have 2.5 months before 0.15 feature freeze, and we're gonna get in half of what people are PRing these days
103 2017-04-19 14:38:37	0|sipa|multiple reorgs, with partial flushing
104 2017-04-19 14:38:41	0|morcos|the rest of that comment is very good though
105 2017-04-19 14:39:21	0|BlueMatt|unless we never fully flush, but if we never fully flush startup will /always/ be painfully slow
106 2017-04-19 14:39:25	0|BlueMatt|which i also dont think is acceptable
107 2017-04-19 14:39:39	0|sipa|how so?
108 2017-04-19 14:39:45	0|sipa|it would just lag a few blocks behind
109 2017-04-19 14:40:01	0|sdaftuar|how would it only be a few blocks behind?
110 2017-04-19 14:40:36	0|sipa|at least it's configurable... during IBD it could lag behind more
111 2017-04-19 14:40:53	0|BlueMatt|during ibd you only need single-head, though, I think
112 2017-04-19 14:40:59	0|BlueMatt|it should be pretty much all serial
113 2017-04-19 14:41:09	0|sipa|sure, but i don't want two separate recovery algorithms
114 2017-04-19 14:41:15	0|BlueMatt|huh?
115 2017-04-19 14:41:42	0|morcos|I just think its too many steps at once...   Matt and Suhas are trying to explain to me what the series of events that happens here is and I just don't understand
116 2017-04-19 14:41:50	0|BlueMatt|sipa: I'm saying never support recovery of multiple reorgs at once
117 2017-04-19 14:42:09	0|sipa|BlueMatt: it's maybe 5 lines less code!
118 2017-04-19 14:42:29	0|sipa|instead of rolling back from one branch, you roll back from all of them
119 2017-04-19 14:42:31	0|morcos|I don't understand what a partial flush is
120 2017-04-19 14:42:40	0|sipa|morcos: write some of the entries in your cache to disk
121 2017-04-19 14:42:45	0|sipa|instead of all
122 2017-04-19 14:42:47	0|morcos|And then what?
123 2017-04-19 14:42:53	0|BlueMatt|and then...thats it?
124 2017-04-19 14:42:54	0|sipa|continue
125 2017-04-19 14:43:18	0|sipa|you're running out of memory, pick a few dirty entries in the cache, and write those to disk
126 2017-04-19 14:43:24	0|sipa|and perhaps delete a few non-dirty entries
127 2017-04-19 14:43:26	0|sipa|and continue
128 2017-04-19 14:43:38	0|sipa|there are tons of tweaks and analysis possible to find good strategies
129 2017-04-19 14:43:48	0|sipa|but non-atomic flushing makes all of it safe
130 2017-04-19 14:43:55	0|BlueMatt|sipa: but 20 more edge cases in consensus code, 30 more lines of comments to explain why its ok. the previous stuff was very reviewable, now its super tricky unless we /also/ implement the write side (I know you said you have that, but can we leave that for a separate pr?)
131 2017-04-19 14:44:03	0|morcos|So while you are writing those entries, no one else is modifying the cache...  but then you give up the lock before you've flushed the whole cache, so then when people modify the cache more..  ok i guess  i get it.
132 2017-04-19 14:44:20	0|morcos|But why can't we save that for a later "improvement" , why is it necessary now?
133 2017-04-19 14:44:34	0|sipa|morcos: because the algorithm is the same
134 2017-04-19 14:44:47	0|sipa|can we just put an assert in it, that forces it to be the simple case?
135 2017-04-19 14:45:01	0|sipa|so you can review it assuming it only needs to deal with the simple case
136 2017-04-19 14:45:11	0|morcos|What am I missing, why do you want to have the code there if we are not using it?
137 2017-04-19 14:45:24	0|sipa|it's 5 lines...
138 2017-04-19 14:45:29	0|sipa|yes, i can remove it
139 2017-04-19 14:47:01	0|sipa|but it's nice to at least have the database format support multihead, so it's not yet another backward compatible upgrade that needs upgrade
140 2017-04-19 14:47:26	0|BlueMatt|hardly? just means you cant downgrade after an unclear shutdown?
141 2017-04-19 14:47:39	0|sipa|plus new code that needs to deal with the old case
142 2017-04-19 14:47:41	0|BlueMatt|but maybe others are?
143 2017-04-19 14:47:50	0|sdaftuar|you can still downgrade with a -reindex-chainstate!
144 2017-04-19 14:47:57	0|sipa|ok...
145 2017-04-19 14:49:14	0|sipa|would you be fine with a database format that just has a record saying "rollback block X, rollforward block Y, rollback block Z", and the recovery code literally follows those steps?
146 2017-04-19 14:49:52	0|sipa|actually, that's pretty complicated on the write side
147 2017-04-19 14:50:41	0|BlueMatt|possibly, though the "might have had stuff from a future branch way down the line partially flushed" stuff just makes it harder to review consensus-critical crap
148 2017-04-19 14:51:15	0|sipa|sigh, ok, i'll try to simplify the code as much as possible to only deal with a single reorg
149 2017-04-19 14:51:28	0|morcos|sipa: i'm not sure that your approach is wrong..  i think its just a lot to hit someone all at once in thinking about it
150 2017-04-19 14:51:39	0|sipa|morcos: fair enough
151 2017-04-19 14:51:49	0|BlueMatt|sipa: thanks, now lets get this all merged for 0.14 =D
152 2017-04-19 14:51:53	0|BlueMatt|ehh, 15
153 2017-04-19 14:51:55	0|morcos|you might be right that it is a more elegant approach if you have this end goal in mind down the road
154 2017-04-19 14:52:22	0|morcos|but we're stuck trying to recreate the logical progression you went through to end up there
155 2017-04-19 14:52:28	0|sipa|understood
156 2017-04-19 14:52:50	0|morcos|that said... i'm getting more comfortable with it after hashing it out a bit
157 2017-04-19 14:52:50	0|sdaftuar|sipa: did you ever test the performance of flush-without-wiping with a per-utxo model?
158 2017-04-19 14:53:42	0|sipa|sdaftuar: i haven't
159 2017-04-19 15:02:02	0|morcos|sipa: another simple improvement would be to instead of having a 2.0x factor for cache memory usage to just track usage =  all cache usage + dirty coins usage
160 2017-04-19 15:02:50	0|sipa|morcos: i really hope that the non-atomic flushing after simplifying will be simple enough to be reviewed
161 2017-04-19 15:24:09	0|sdaftuar|wumpus: i think #9942 is ready for merge
162 2017-04-19 15:24:12	0|gribble|https://github.com/bitcoin/bitcoin/issues/9942 | Refactor CBlockPolicyEstimator by morcos · Pull Request #9942 · bitcoin/bitcoin · GitHub
163 2017-04-19 15:24:52	0|bitcoin-git|[13bitcoin] 15jet0 opened pull request #10230: Merge pull request #1 from bitcoin/master (06master...06freeze) 02https://github.com/bitcoin/bitcoin/pull/10230
164 2017-04-19 15:25:03	0|bitcoin-git|[13bitcoin] 15jet0 closed pull request #10230: Merge pull request #1 from bitcoin/master (06master...06freeze) 02https://github.com/bitcoin/bitcoin/pull/10230
165 2017-04-19 15:31:44	0|jonasschnelli|I have significant freezes in the GUI with current master catching up a couple of days on mainnet..
166 2017-04-19 15:33:01	0|jonasschnelli|I think this was re-introduced with https://github.com/bitcoin/bitcoin/pull/9583
167 2017-04-19 15:33:26	0|jonasschnelli|Although not sure...
168 2017-04-19 15:34:43	0|Lauda|^happens to me occasionally in 0.14.0
169 2017-04-19 15:36:00	0|BlueMatt|jonasschnelli: great! review #10179 :p
170 2017-04-19 15:36:02	0|gribble|https://github.com/bitcoin/bitcoin/issues/10179 | Give CValidationInterface Support for calling notifications on the CScheduler Thread by TheBlueMatt · Pull Request #10179 · bitcoin/bitcoin · GitHub
171 2017-04-19 15:38:40	0|jonasschnelli|BlueMatt: Oh... I totally forgot that one.. thanks. Will try.
172 2017-04-19 15:41:22	0|BlueMatt|jonasschnelli: that doesnt do anything by itself
173 2017-04-19 15:41:26	0|BlueMatt|the real change is the pr after it
174 2017-04-19 15:41:29	0|BlueMatt|but its blocking :)
175 2017-04-19 15:41:33	0|jonasschnelli|Okay... thanks.
176 2017-04-19 15:41:55	0|jonasschnelli|I think the freezes i face are caused by something different then the 9583
177 2017-04-19 15:43:03	0|sipa|BlueMatt: ha, blocking.
178 2017-04-19 15:44:43	0|BlueMatt|lol
179 2017-04-19 15:45:20	0|BlueMatt|jonasschnelli: you may still wish to test my branch which is based on that (https://github.com/TheBlueMatt/bitcoin/tree/2017-01-wallet-cache-inmempool-4, I think, though i believe travis didnt like it last time, i need to go back and fix it prior to pring it)
180 2017-04-19 15:45:25	0|BlueMatt|would be good feedback if it is faster :)
181 2017-04-19 15:46:00	0|jonasschnelli|BlueMatt: Yes. I'll give it a try and a review once I have tracked the current freeze down
182 2017-04-19 15:46:12	0|jonasschnelli|*tracked down the current freeze
183 2017-04-19 15:52:24	0|cfields|jonasschnelli: https://github.com/bitcoin/bitcoin/issues/10209#issuecomment-295311664
184 2017-04-19 15:52:27	0|cfields|$10 says it's that :)
185 2017-04-19 15:53:21	0|jonasschnelli|cfields: But don't I need https://github.com/bitcoin/bitcoin/issues/10228?
186 2017-04-19 15:53:54	0|cfields|jonasschnelli: 10228 just keeps it from happening in the future. Problem is that your bitcoin-config.h is busted atm
187 2017-04-19 15:54:04	0|cfields|(i strongly suspect, anyway)
188 2017-04-19 15:54:20	0|jonasschnelli|ah... I see. That seams reasonable...
189 2017-04-19 15:55:10	0|cfields|jonasschnelli: specifically MSG_DONTWAIT. Are you seeing a warning about it when you build?
190 2017-04-19 15:55:24	0|jonasschnelli|oh.. maybe. :|
191 2017-04-19 15:55:53	0|cfields|if so, this is your problem, and autogen will fix you right up.
192 2017-04-19 16:05:42	0|bitcoin-git|[13bitcoin] 15jonasschnelli opened pull request #10231: [Qt] Reduce a significant cs_main lock freeze (06master...062017/04/qt_freeze) 02https://github.com/bitcoin/bitcoin/pull/10231
193 2017-04-19 16:08:13	0|cfields|jonasschnelli: why not subscribe to UpdatedBlockTip() and cache it there?
194 2017-04-19 16:14:31	0|jonasschnelli|cfields: IMO we don't have a signal that covers the bestheader (not bestblock)
195 2017-04-19 16:15:34	0|jonasschnelli|ermm... we have NotifyHeaderTip
196 2017-04-19 16:16:41	0|jonasschnelli|cfields: Do you think it would be preferable to cache it in the GUI clientmodel instead of the core validation part (validation.cpp)?
197 2017-04-19 16:16:45	0|cfields|jonasschnelli: heh, I just grepped to the same conclusion :)
198 2017-04-19 16:17:14	0|jonasschnelli|cfields: Yes. I could cache it in "static void BlockTipChanged(ClientModel *clientmodel, bool initialSync, const CBlockIndex *pIndex, bool fHeader)"
199 2017-04-19 16:17:18	0|jonasschnelli|when fHeader == true
200 2017-04-19 16:17:40	0|cfields|jonasschnelli: i think it makes sense for each subsystem to maintain their own view of those things, yes
201 2017-04-19 16:17:55	0|jonasschnelli|Yes. Let me change this... I don't think there are valid use cases outside the GUI
202 2017-04-19 16:17:59	0|cfields|(not sure everyone would agree with that, but that's the direction we've been moving in)
203 2017-04-19 16:18:02	0|jonasschnelli|cfields: indeed.
204 2017-04-19 16:19:49	0|cfields|jonasschnelli: the exception obviously being if you need atomic access to a few locally cached things, in which case you have to be careful to keep everything in sync. But if it's just for the gui, I think caching it there makes sense.
205 2017-04-19 16:20:22	0|jonasschnelli|Yes. Right... i'll change the PR
206 2017-04-19 16:37:25	0|cfields|jonasschnelli: any reason we can't do the same thing for the other cs_main takers in there?
207 2017-04-19 16:37:46	0|jonasschnelli|cfields: Yes. We should do similar things there... i'll have a look
208 2017-04-19 16:37:50	0|cfields|(adding new ui events, i mean)
209 2017-04-19 16:39:30	0|cfields|jonasschnelli: great :)
210 2017-04-19 16:42:28	0|morcos|Here is my attempt at a high level description of the current fee estimation algorithm.
211 2017-04-19 16:42:31	0|morcos|https://gist.github.com/morcos/d3637f015bc4e607e1fd10d8351e9f41
212 2017-04-19 16:42:48	0|morcos|gmaxwell: Please let me know if ^ is what you had in mind
213 2017-04-19 16:43:07	0|morcos|I thought it best to explain the basic concept of how it currently works without getting into the changes yet
214 2017-04-19 16:46:26	0|bitcoin-git|[13bitcoin] 15luke-jr opened pull request #10232: release-notes: Accurately explain getblocktemplate improvements (060.14...060.14_relnotes_mining) 02https://github.com/bitcoin/bitcoin/pull/10232
215 2017-04-19 16:49:57	0|sipa|morcos: very clear
216 2017-04-19 16:50:21	0|bitcoin-git|[13bitcoin] 15jet0 opened pull request #10233: Wallet: Support not reusing addresses (06master...06freezea) 02https://github.com/bitcoin/bitcoin/pull/10233
217 2017-04-19 16:52:52	0|morcos|sipa: heh, had a bug in it though!
218 2017-04-19 16:59:53	0|bitcoin-git|[13bitcoin] 15jnewbery opened pull request #10234: [net] listbanned RPC and QT should show correct banned subnets (06master...06list_banned_correctly) 02https://github.com/bitcoin/bitcoin/pull/10234
219 2017-04-19 17:13:03	0|sipa|BlueMatt, morcos, sdaftuar: i hope it's easier to review now
220 2017-04-19 17:13:14	0|bitcoin-git|[13bitcoin] 15TheBlueMatt opened pull request #10235: Track keypool entries as internal vs external in memory (06master...062017-04-wallet-more-keypool-cache) 02https://github.com/bitcoin/bitcoin/pull/10235
221 2017-04-19 17:13:14	0|sipa|i'll leave the WIP marker in until I had a test for the reorganization
222 2017-04-19 17:13:15	0|sdaftuar|sipa: thanks, i'm taking a look
223 2017-04-19 17:13:59	0|BlueMatt|sipa: thanks, will review
224 2017-04-19 17:14:57	0|jonasschnelli|BlueMatt: re: https://github.com/bitcoin/bitcoin/pull/10184#issuecomment-295350649
225 2017-04-19 17:15:00	0|jonasschnelli|Yes. Makse sense..
226 2017-04-19 17:15:10	0|jonasschnelli|though the argument of "little money" is dangerous..
227 2017-04-19 17:15:18	0|sipa|sdaftuar, BlueMatt: thank you
228 2017-04-19 17:15:32	0|jonasschnelli|Years back some of us probably had little money on VPS's which now has worth a six digit number. :)
229 2017-04-19 17:15:52	0|jonasschnelli|And while you move your keys away from your VPS,... there is no guarantee they where not compromised..
230 2017-04-19 17:16:12	0|jonasschnelli|the security requirements can change over time and most people won't sweep the funds to a new address
231 2017-04-19 17:16:54	0|sipa|but agree that there is not argument why it shouldn't work
232 2017-04-19 17:16:55	0|jonasschnelli|But I know... i also run nodes on external root servers and sometimes,.. they have a some test mainnet coins
233 2017-04-19 17:17:00	0|BlueMatt|jonasschnelli: I'm not saying its a *good* idea, just that if people want to do it we shouldnt try to break it
234 2017-04-19 17:17:04	0|sipa|new key creation performance has been horrible for ages
235 2017-04-19 17:17:11	0|BlueMatt|(some people buy insurance, too :p)
236 2017-04-19 17:17:16	0|sipa|we should improve that when we can, period
237 2017-04-19 17:18:15	0|jonasschnelli|Yes. Sure... I just in general think it's good to show some critical respons whenever someone mentions AWS or Azure. :)
238 2017-04-19 17:18:23	0|BlueMatt|fair
239 2017-04-19 17:18:38	0|sipa|btw
240 2017-04-19 17:18:56	0|jonasschnelli|see! :-)
241 2017-04-19 17:18:57	0|BlueMatt|lol
242 2017-04-19 17:19:08	0|sipa|though i do consider that my own damned fault
243 2017-04-19 17:19:12	0|jonasschnelli|so it even happens to core devs. :)
244 2017-04-19 18:01:22	0|gmaxwell|BlueMatt:  I don't understand your complaint about multiple head. It's strictly safer than not having it.
245 2017-04-19 18:02:13	0|gmaxwell|I agree it will be easier to reason about the effects of multi-head after were're per-txout, and I expect we won't make intentional use of it until then.
246 2017-04-19 18:04:39	0|sipa|gmaxwell: multi-head is only needed once we do multiple partial flushes
247 2017-04-19 18:05:36	0|sipa|gmaxwell: we *do* need reorg support immediately, but not necessarily support for multiple reorgs at once
248 2017-04-19 18:07:12	0|BlueMatt|gmaxwell: I'm happy to re-review post-per-utxo
249 2017-04-19 18:08:34	0|BlueMatt|but right now the review burden is high, and I'm not convinced of its usefulness unless we actually have a write side that we're gonna merge :)
250 2017-04-19 18:09:12	0|sipa|BlueMatt: well the advantage would be not breaking backward compatibility
251 2017-04-19 18:09:21	0|sipa|but per-txout will break that anyway
252 2017-04-19 18:09:26	0|BlueMatt|yes, also not sold on that :)
253 2017-04-19 18:09:28	0|BlueMatt|indeed
254 2017-04-19 18:09:48	0|gmaxwell|the same code fixes reorgs to that, the extra stuff that does things for multi-head is just a no-op otherwise.
255 2017-04-19 18:10:29	0|BlueMatt|gmaxwell: can we not have no-ops in consensus-critical logic?
256 2017-04-19 18:11:36	0|gmaxwell|so then if there is some corner case we should corrupt the state rather than just handling it?
257 2017-04-19 18:12:12	0|sipa|gmaxwell: there is no way we can now end up in a situation that needs multi-head support
258 2017-04-19 18:12:34	0|sipa|unless there is a bug in the code, and in that case it's unlikely the multi-head code actually does the right thing
259 2017-04-19 18:14:00	0|sipa|my reason for having it in the first place was because i don't consider it much more complicated, so it's easier to get it in now than changing it again later
260 2017-04-19 18:14:10	0|sipa|but it seems people disagree it's easy to understand
261 2017-04-19 18:49:13	0|luke-jr|wumpus: might make sense to backport #10207
262 2017-04-19 18:49:15	0|gribble|https://github.com/bitcoin/bitcoin/issues/10207 | Clarify importprivkey help text ... example of blank label without rescan by wtogami · Pull Request #10207 · bitcoin/bitcoin · GitHub
263 2017-04-19 18:58:38	0|luke-jr|why is abortrescan not allowed in safe mode?
264 2017-04-19 18:58:55	0|sipa|lol
265 2017-04-19 19:07:39	0|jonasschnelli|luke-jr: heh... is that already merged?
266 2017-04-19 19:07:57	0|luke-jr|seems so
267 2017-04-19 19:56:40	0|luke-jr|Travis jobs are randomly cancelling?
268 2017-04-19 20:04:16	0|BlueMatt|luke-jr: they do that automagically if you force push before they run now
269 2017-04-19 20:07:21	0|luke-jr|BlueMatt: it doesn't *look* like jonasschnelli is force-pushing on #10231
270 2017-04-19 20:07:23	0|gribble|https://github.com/bitcoin/bitcoin/issues/10231 | [Qt] Reduce a significant cs_main lock freeze by jonasschnelli · Pull Request #10231 · bitcoin/bitcoin · GitHub
271 2017-04-19 20:07:40	0|BlueMatt|luke-jr: oh, then i dont know
272 2017-04-19 20:07:48	0|BlueMatt|i think people can also manually cancel their own jobs
273 2017-04-19 20:07:53	0|BlueMatt|maybe someone hit it on accident
274 2017-04-19 20:08:07	0|luke-jr|hmm