1 2017-01-17 02:19:39	0|BlueMatt|ejects one (which looks pretty much mergeable to me) and preferably the extra message handler waker (9561, which is both trivial and a big gain)
  2 2017-01-17 02:19:39	0|BlueMatt|wumpus: fwiw, i vote we hold merge window for a day or two for things already pending incl the hd split (which I think is one more set of fixups, hopefully tomorrow, away, and is not as hard to review as it looks), bumpfee pending discussion tomorrow (I'm pretty happy with it if we fix the two pending issues - listunspent, which may just be a docs change, and getbalance, which may also just be a docs change), the compact-block-orphan-r
  3 2017-01-17 02:19:48	0|BlueMatt|but I'd understand if thats not a popular opinion
  4 2017-01-17 02:29:32	0|fanquake|wummpus / sipa are you around?
  5 2017-01-17 02:29:36	0|fanquake|*wumpus
  6 2017-01-17 02:34:22	0|fanquake|Or anyone with admin on bitcoin/bitcoin, there is a user spamming the repo with links/comments.
  7 2017-01-17 02:35:35	0|fanquake|I have deleted most for now.
  8 2017-01-17 02:43:21	0|sipa|sigh
  9 2017-01-17 02:43:29	0|sipa|sorry, i can't really access github now
 10 2017-01-17 03:25:41	0|sipa|fanquake: blocked
 11 2017-01-17 03:55:17	0|bitcoin-git|[13bitcoin] 15sipa pushed 3 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/812714fd80e9...6696b4635ceb
 12 2017-01-17 03:55:18	0|bitcoin-git|13bitcoin/06master 14241d893 15Matt Corallo: Wake message handling thread when we receive a new block...
 13 2017-01-17 03:55:18	0|bitcoin-git|13bitcoin/06master 14f13914a 15Matt Corallo: Make WakeMessageHandler public
 14 2017-01-17 03:55:19	0|bitcoin-git|13bitcoin/06master 146696b46 15Pieter Wuille: Merge #9561: Wake message handling thread when we receive a new block...
 15 2017-01-17 03:55:32	0|bitcoin-git|[13bitcoin] 15sipa closed pull request #9561: Wake message handling thread when we receive a new block (06master...062017-01-wakeup-on-new-block) 02https://github.com/bitcoin/bitcoin/pull/9561
 16 2017-01-17 04:12:41	0|sipa|BlueMatt: sorry, need sleep first
 17 2017-01-17 04:13:15	0|BlueMatt|I still vote we push back freeze a day or two, given today was a holiday in the us and many folks werent working all weekend
 18 2017-01-17 04:13:19	0|BlueMatt|:p
 19 2017-01-17 04:14:13	0|BlueMatt|and so I can shamelessly get folks to review #9535 :p
 20 2017-01-17 04:14:15	0|gribble|https://github.com/bitcoin/bitcoin/issues/9535 | Split CNode::cs_vSend: message processing and message sending by TheBlueMatt · Pull Request #9535 · bitcoin/bitcoin · GitHub
 21 2017-01-17 04:31:33	0|luke-jr|I ended up being away for yesterday & today, so another day or two may be helpful
 22 2017-01-17 09:24:48	0|wumpus|I've extended the section on named arguments in the release notes a bit: https://github.com/bitcoin-core/bitcoin-devwiki/wiki/0.14.0-Release-notes#support-for-json-rpc-named-arguments
 23 2017-01-17 10:47:20	0|bitcoin-git|[13bitcoin] 15jdust69 opened pull request #9568: 10.13 (06master...060.13) 02https://github.com/bitcoin/bitcoin/pull/9568
 24 2017-01-17 10:48:16	0|bitcoin-git|[13bitcoin] 15fanquake closed pull request #9568: 10.13 (06master...060.13) 02https://github.com/bitcoin/bitcoin/pull/9568
 25 2017-01-17 12:16:30	0|bitcoin-git|[13bitcoin] 15fanquake closed pull request #9263: release notes: Explicitly mention the removal of free transactions, and do not commit to removal of priority in any given release (06master...06relnotes_freetxn) 02https://github.com/bitcoin/bitcoin/pull/9263
 26 2017-01-17 12:36:30	0|morcos|luke-jr: what is the point of doing the release notes on a wiki, if you are going to just merge changes that were explicitly NACK'ed when those same changs were proposed in a PR
 27 2017-01-17 12:36:50	0|morcos|all that is going to do is lead to a childish edit war and make it so none of us can use the wiki for release notes
 28 2017-01-17 12:37:07	0|morcos|if you know you have a controversial change you want to make you shouldln't just make it and hope no one notices
 29 2017-01-17 12:37:20	0|morcos|this is not a proper way of working with other people
 30 2017-01-17 14:07:16	0|BlueMatt|jonasschnelli: hey
 31 2017-01-17 14:07:23	0|BlueMatt|how much longer will you be around?
 32 2017-01-17 14:07:32	0|jonasschnelli|BlueMatt: 1-2h at least
 33 2017-01-17 14:07:36	0|jonasschnelli|hi
 34 2017-01-17 14:07:48	0|BlueMatt|ok, will circle back around after breakfast and hopefully we can finish this
 35 2017-01-17 14:08:10	0|jonasschnelli|Yes. I guess and hope I fixed most/all of you points... tell me, if there is more
 36 2017-01-17 14:08:33	0|BlueMatt|i think it should be good if you hit all the stuff i commented on, i gave it a pretty decent review the first go-around, but it needs another one when I'm awake post-breakfast
 37 2017-01-17 14:08:55	0|jonasschnelli|Yes. I think your review was very valuable...
 38 2017-01-17 14:09:15	0|jonasschnelli|We should not rush that change... but hurry up for 0.14. :)=
 39 2017-01-17 14:10:18	0|BlueMatt|heh, yea, I recommended pushing back yesterday because I'm confident we can get this one in
 40 2017-01-17 14:10:47	0|jonasschnelli|Yes. I mean if we find something after the freeze, there is time to fix it before the 0.14 release...
 41 2017-01-17 14:11:08	0|BlueMatt|yup
 42 2017-01-17 14:19:02	0|sipa|do we want to be a mentoring org for GSOC?
 43 2017-01-17 14:20:21	0|BlueMatt|does anyone feel like they have time?
 44 2017-01-17 14:20:45	0|BlueMatt|i mean in theory, maybe, but....
 45 2017-01-17 14:20:53	0|sipa|yeah...
 46 2017-01-17 14:21:26	0|sipa|i feel like we should make time for such projects
 47 2017-01-17 14:21:37	0|sipa|but easier said than done
 48 2017-01-17 14:22:03	0|BlueMatt|yea
 49 2017-01-17 14:22:09	0|BlueMatt|obviously agreed
 50 2017-01-17 14:44:26	0|BlueMatt|jonasschnelli: any chance we can s/(used for change outputs, only appears if HD is enabled otherwise there is no need for internal keys)/(used for change outputs, only appears if HD split is enabled, otherwise external keys are used)/
 51 2017-01-17 14:44:48	0|BlueMatt|and make the corresponding change the the logic
 52 2017-01-17 14:44:54	0|BlueMatt|should make the docs wayyy clearer
 53 2017-01-17 14:45:10	0|jonasschnelli|BlueMatt: Okay. Makese sense I guess.
 54 2017-01-17 14:45:16	0|jonasschnelli|I liked the idea form luke-jr...
 55 2017-01-17 14:45:29	0|jonasschnelli|keypoolsize: {"internal": x, "external": y}
 56 2017-01-17 14:45:32	0|jonasschnelli|But breaks the API
 57 2017-01-17 14:45:40	0|BlueMatt|yea, agreed lets not break the api
 58 2017-01-17 14:45:48	0|jonasschnelli|okay.. will update
 59 2017-01-17 14:46:28	0|jonasschnelli|BlueMatt. one meh though...
 60 2017-01-17 14:46:38	0|jonasschnelli|Do we want to expose "HD split is enabled" to the user?
 61 2017-01-17 14:46:54	0|jonasschnelli|"HD split" as a label can be confusing...
 62 2017-01-17 14:47:07	0|BlueMatt|hum, or maybe just "only appears if wallet is using this feature, otherwise external keys are used"?
 63 2017-01-17 14:47:12	0|jonasschnelli|We could name it "HD internal keypool" or similar
 64 2017-01-17 14:47:21	0|jonasschnelli|yes. Your text is good
 65 2017-01-17 14:47:24	0|jonasschnelli|Let me take it
 66 2017-01-17 14:47:30	0|BlueMatt|ok, cool
 67 2017-01-17 14:51:25	0|jonasschnelli|BlueMatt: https://github.com/bitcoin/bitcoin/pull/9294/commits/eeeb52afc3b25836588b2b7c6b704a5a6498e1d1
 68 2017-01-17 14:51:31	0|jonasschnelli|Added to #9294
 69 2017-01-17 14:51:34	0|gribble|https://github.com/bitcoin/bitcoin/issues/9294 | Use internal HD chain for change outputs (hd split) by jonasschnelli · Pull Request #9294 · bitcoin/bitcoin · GitHub
 70 2017-01-17 14:51:44	0|BlueMatt|thanks
 71 2017-01-17 15:01:20	0|BlueMatt|jonasschnelli: do we normally bump wallet versions at release? I think we just set them based on next version pre-merge
 72 2017-01-17 15:01:50	0|jonasschnelli|BlueMatt: in 0.13, we bumped to 130000 after the tag/version.bump was made
 73 2017-01-17 15:02:10	0|BlueMatt|ehh, ok
 74 2017-01-17 15:02:20	0|jonasschnelli|Otherwise you can't test it and all tests will fail
 75 2017-01-17 15:02:28	0|BlueMatt|oh, ok, didnt realize that
 76 2017-01-17 15:02:36	0|BlueMatt|can you not catch(...) in deserialize?
 77 2017-01-17 15:02:46	0|BlueMatt|we always throw std::ios_base::failure when we read oob
 78 2017-01-17 15:02:58	0|jonasschnelli|BlueMatt: the problem there is, that CKeyPool has no record version...
 79 2017-01-17 15:03:07	0|jonasschnelli|maybe we could check is CDataStream has more bytes?
 80 2017-01-17 15:03:12	0|BlueMatt|yes, catch(std::ios_base::failure&)
 81 2017-01-17 15:03:18	0|jonasschnelli|ah.. okay.
 82 2017-01-17 15:03:41	0|BlueMatt|otherwise you'll catch all kinds of fun garbage that should really reach top-of-thread and assert
 83 2017-01-17 15:03:49	0|jonasschnelli|Yes. Indeed.
 84 2017-01-17 15:07:21	0|jonasschnelli|BlueMatt: https://github.com/bitcoin/bitcoin/pull/9294/commits/a874b75a180a9e967a3d936cf46df11f8531b70a
 85 2017-01-17 15:07:47	0|jonasschnelli|I wonder if a simple "are there more bytes?" check would be more appropriate at this place
 86 2017-01-17 15:08:30	0|jonasschnelli|On the other hand, a failed deserialization at this point shoud always flag the CKeyPool item fInternal=false
 87 2017-01-17 15:13:04	0|BlueMatt|jonasschnelli: ok, the only remaining concern i have is performance - there are a bunch of loops over disk reads introduced for folks who upgrade
 88 2017-01-17 15:13:37	0|jonasschnelli|Yes. This could be optimised...
 89 2017-01-17 15:13:52	0|jonasschnelli|I expect BDB to be sort of fast...
 90 2017-01-17 15:14:12	0|BlueMatt|I think you may be surprised
 91 2017-01-17 15:14:16	0|BlueMatt|but if its an issue its an easy fix
 92 2017-01-17 15:14:27	0|instagibbs|that can be fixed post-freeze, yeS?
 93 2017-01-17 15:14:32	0|jonasschnelli|Yes. CKeyPool should have been fixed long time ago...
 94 2017-01-17 15:15:01	0|BlueMatt|instagibbs: if it turns out to be a major regression, I'd say yes
 95 2017-01-17 15:15:20	0|jonasschnelli|BlueMatt: I can test it with a 100k keypool wallet... and compare
 96 2017-01-17 15:16:44	0|jonasschnelli|Oh.. lets better start with 50k...
 97 2017-01-17 15:17:09	0|jonasschnelli|or with 5k,... CKey.Verify() is slow..
 98 2017-01-17 15:17:32	0|BlueMatt|heh
 99 2017-01-17 15:18:05	0|sipa|CKey.Verify() can verify 10000 keys per second
100 2017-01-17 15:18:16	0|sipa|the slow part is the sync to bdb after every keypool change
101 2017-01-17 15:22:50	0|jonasschnelli|okay.. I see..
102 2017-01-17 15:37:27	0|jonasschnelli|BlueMatt: With a 5k wallet, its slightly slower on my Core i7 2.9 GHZ..
103 2017-01-17 15:37:30	0|jonasschnelli|getnewaddress: real	0m0.219s
104 2017-01-17 15:39:31	0|BlueMatt|vs?
105 2017-01-17 15:40:09	0|jonasschnelli|real	0m0.104s
106 2017-01-17 15:40:12	0|jonasschnelli|(0.13)
107 2017-01-17 15:41:09	0|jonasschnelli|BlueMatt: I think it's acceptable but we should work on a fix/better-memory map
108 2017-01-17 15:41:20	0|BlueMatt|I think its fine for now, I'll let phantomcircuit fix it when he complains
109 2017-01-17 15:42:06	0|bitcoin-git|[13bitcoin] 15TheBlueMatt closed pull request #9419: Stop Using cs_main for CNodeState/State() (06master...062016-12-nodestate) 02https://github.com/bitcoin/bitcoin/pull/9419
110 2017-01-17 15:43:09	0|bitcoin-git|[13bitcoin] 15TheBlueMatt closed pull request #9488: Parallel ThreadMessageHandler (06master...062017-01-parallel-processmessages) 02https://github.com/bitcoin/bitcoin/pull/9488
111 2017-01-17 15:43:41	0|jonasschnelli|BlueMatt: oh. Keep in mind, that 0.13er wallet has only 5k keys while the 0.14er wallet has 200% key (=10k)
112 2017-01-17 15:43:41	0|jonasschnelli|So.. then the number look even better
113 2017-01-17 16:10:07	0|morph|hi
114 2017-01-17 17:12:53	0|luke-jr|morcos: YOUR changes were NACK'd.
115 2017-01-17 17:16:12	0|morcos|luke-jr: i didn't have any release note changes except 9531 which were merged with only ACK's. But I'm not going to waste everyone's time arguing with you about this.  I find you very difficult to work with, and so I will just avoid it where possible.
116 2017-01-17 17:16:55	0|morcos|I've made my view point on the release notes clear.. If you want to go around changing things behind people's backs, I'm not going to take on the task of trying to stop you.  But you should be aware your actions reflect poorly on all of us.
117 2017-01-17 17:17:37	0|luke-jr|morcos: trying to use Core as a vehicle for political agendas is what reflects poorly.
118 2017-01-17 17:18:33	0|sipa|luke-jr: stop it
119 2017-01-17 17:18:44	0|sipa|there have been more than enough arguments
120 2017-01-17 17:18:52	0|sipa|sorry, people disagree with you
121 2017-01-17 17:18:55	0|sipa|accept it
122 2017-01-17 17:19:20	0|luke-jr|disagreement means we should agree to disagree by having an option, not that you should just get your way and force your opinion on others
123 2017-01-17 17:19:32	0|luke-jr|this would all be over if you would just leave it be.
124 2017-01-17 17:20:23	0|BlueMatt|this may be true for some thing, but we dont generally support options that are used by +/- one person, especially if they have really big costs to doing so
125 2017-01-17 17:20:35	0|BlueMatt|s
126 2017-01-17 17:20:49	0|luke-jr|BlueMatt: the cost to leaving the code in place until it gets in someone's de facto way is literally zero.
127 2017-01-17 17:21:23	0|BlueMatt|no it is not, it has not been, and it will not be
128 2017-01-17 17:22:14	0|luke-jr|I already suggested a compromise that it can be removed at the first occasion of it being a burden to someone who wants to change something there.
129 2017-01-17 17:22:22	0|BlueMatt|we're waayyyyy past that point
130 2017-01-17 17:22:42	0|sipa|luke-jr: the discussion about it has dragged on for ages, and just the disagreement about it is draining people who want to work on the project
131 2017-01-17 17:22:52	0|sipa|it is clear that thid code is useless at this point
132 2017-01-17 17:22:56	0|BlueMatt|the compromise is that if you want to support it, you can add additional rpcs which give you access to the appropriate data so you can call prioritizetransaction (ie the fee-bumping command)
133 2017-01-17 17:22:57	0|luke-jr|then morcos went and made that inflammatory comment
134 2017-01-17 17:23:07	0|sipa|we're doing everyone a favor by just getting past it
135 2017-01-17 17:23:10	0|luke-jr|sipa: so stop creating disagreement for no reason
136 2017-01-17 17:23:36	0|BlueMatt|the disagreement is that only you disagree, at this point
137 2017-01-17 17:23:36	0|sipa|luke-jr: i can say the same
138 2017-01-17 17:23:43	0|BlueMatt|hell, even other miners disagree with you
139 2017-01-17 17:23:54	0|luke-jr|except I'm not the one who keeps bringing it up and forcing the issue.
140 2017-01-17 17:24:04	0|sipa|luke-jr: you're turning a piece of outdated logic from a mouse into an elephant, and i'm tired of having this discussion
141 2017-01-17 17:24:06	0|BlueMatt|because everyone wants to just remove the damn code already
142 2017-01-17 17:24:06	0|luke-jr|BlueMatt: some miners perhaps. others don't.
143 2017-01-17 17:24:20	0|BlueMatt|oh? who other than you?
144 2017-01-17 17:24:22	0|luke-jr|nobody is forcing the ones who don't want it to use it.
145 2017-01-17 17:24:24	0|BlueMatt|(and dont say wizkid)
146 2017-01-17 17:24:34	0|luke-jr|wizkid057 doesn't count now?
147 2017-01-17 17:24:40	0|BlueMatt|the amount of work that has gone into maintaining this feature just for eligius is insane
148 2017-01-17 17:24:47	0|BlueMatt|we maintain no other feature for one person/group
149 2017-01-17 17:25:01	0|BlueMatt|if that were our policy we'd still have tonal numbering in bitcoin core
150 2017-01-17 17:25:17	0|luke-jr|"still" implying we ever did
151 2017-01-17 17:25:24	0|BlueMatt|well, ok, we'd have
152 2017-01-17 17:25:26	0|BlueMatt|s/still//
153 2017-01-17 17:25:28	0|BlueMatt|g
154 2017-01-17 17:25:28	0|BlueMatt|same thin
155 2017-01-17 17:28:58	0|luke-jr|not to mention there's no evidence it's only used by one person.
156 2017-01-17 17:31:43	0|sipa|there is evidence that only a small percentage of the hash rate uses it (look at the feerate of blocks in transactions... it's clearly feerate sorted, except for a small percentage of txn at the beginning of a very occasional block)
157 2017-01-17 17:32:08	0|sipa|furthermore, it is completely useless as a spam prevention mechanism without wallets targetting it
158 2017-01-17 17:32:44	0|sipa|i'm done arguing about this
159 2017-01-17 17:33:00	0|sipa|we'll remove priority mining in 0.15, as far as i'm concerned
160 2017-01-17 17:33:21	0|luke-jr|that's simply not true at all. priority works without any targetting.
161 2017-01-17 17:34:03	0|sipa|come on
162 2017-01-17 17:35:23	0|sipa|a perfectly legitimate wallet's transaction would be treated completely arbitrarily under it
163 2017-01-17 17:35:42	0|sipa|all it would accomplish is favor a few people with very old coi s
164 2017-01-17 17:36:02	0|sipa|until they start spending recent change
165 2017-01-17 17:38:06	0|luke-jr|*any* age/value weighs more than unconfirmed TXOs.
166 2017-01-17 17:38:23	0|sipa|if you choose to keep arguing this, i will choose to ignore you
167 2017-01-17 17:41:13	0|luke-jr|fine, remove priority. be a jerk and do it before there's even a slightly useful purpose in doing so. but then it's time to stop pretending Core is a politically-neutral reference implementation, since it's de facto being used as a vehicle to force network policy. all you're doing is proving the haters right.
168 2017-01-17 18:01:36	0|BlueMatt|luke-jr: if there were no way to implement it in the supported apis, maybe you'd have a point...but right now it is /trivial/ to implement priority exactly how you like it in a little python script which loops over the mempool and does manual prioritization
169 2017-01-17 18:02:06	0|BlueMatt|luke-jr: if you can honestly tell me you've implemented that, and it wasnt performant enough or there was some other issue preventing it from being practical, maybe I'd have some sympathy, but until then....
170 2017-01-17 18:08:15	0|luke-jr|BlueMatt: so just busyloop over RPC mempool listing, maintain an entire copy of the mempool state outside bitcoind, and act as a proxy for explicit miner prioritisation? I can't even imagine a way to do this effectively; it's certainly a heck of a lot more work, less reliable, and far less efficient.
171 2017-01-17 18:09:00	0|BlueMatt|less efficient? yes, lot more work? I dont believe so...go implement it and prove me wrong
172 2017-01-17 18:09:09	0|BlueMatt|i dont think it needs state, just iterate over and clear prioritization as you go
173 2017-01-17 18:10:15	0|BlueMatt|high_prio = stack(); for transaction in getrawmempool(): if calculate_priority(tx) is highest in stack: place in stack; for transaction not in stack but previously prioritzed: deprioritize; for transaction in stack: prioritize appropriately
174 2017-01-17 18:10:23	0|BlueMatt|if thats more than 100 lines of python I'd be surprised
175 2017-01-17 18:10:56	0|BlueMatt|and if its too ineffecient for you, please add an rpc which provides all the info needed for calculate_priority so that its super effecient
176 2017-01-17 18:11:13	0|BlueMatt|I'd be more than happy to review that
177 2017-01-17 18:13:30	0|luke-jr|to have such an RPC means having about half of the priority code stay in Core
178 2017-01-17 18:13:42	0|luke-jr|because it comes from the input txouts
179 2017-01-17 18:13:49	0|BlueMatt|dont think so? such an rpc could easily only provide things like foreach input: provide txout info
180 2017-01-17 18:14:04	0|BlueMatt|and that is way more general than priority
181 2017-01-17 18:14:14	0|BlueMatt|it allows folks to implement other crazy rules
182 2017-01-17 18:14:19	0|BlueMatt|like "spends from address x"
183 2017-01-17 18:14:31	0|BlueMatt|(well, admittedly you can kinda already do that by seeing the pubkey)
184 2017-01-17 18:14:33	0|luke-jr|but fetching txouts is where the inefficiency came from?
185 2017-01-17 18:14:53	0|BlueMatt|fetching txouts is the tightest loop in the above pseudocode
186 2017-01-17 18:14:55	0|BlueMatt|so I'd think so
187 2017-01-17 18:15:50	0|BlueMatt|wumpus: yo
188 2017-01-17 18:15:53	0|BlueMatt|you still around?
189 2017-01-17 18:27:55	0|luke-jr|BlueMatt: let's continue that topic (or not) post-freeze. either way, it will be easier to maintain priority in Knots than external. and in the meantime, if we haven't frozen yet, I should get back to reviewing stuff
190 2017-01-17 18:28:18	0|BlueMatt|its unclear to me if we've frozen or not :/
191 2017-01-17 18:28:29	0|luke-jr|well, finishing up review certainly can't hurt either way
192 2017-01-17 18:28:39	0|BlueMatt|I mean either we froze, or we have 4 outstnding prs that either go in or dont (todayish, preferably)
193 2017-01-17 18:28:43	0|BlueMatt|yea, fair point
194 2017-01-17 18:55:31	0|bitcoin-git|[13bitcoin] 15jnewbery opened pull request #9569: Setting -blocksonly sets -maxmempool to zero. (06master...06blocksonlynomempoolsharing) 02https://github.com/bitcoin/bitcoin/pull/9569
195 2017-01-17 20:37:06	0|wumpus|BlueMatt: no, we've not frozen yet, that's when we split off the 0.14 branch
196 2017-01-17 20:39:11	0|BlueMatt|wumpus: oh, I'm confused now...the release schedule says feature freeze today, branch in feb
197 2017-01-17 20:40:54	0|wumpus|BlueMatt: I'm confused apaprently, yes branch is before first -rc, it has been the other way around but it means a lot of more backporting so this is okay
198 2017-01-17 20:44:07	0|wumpus|the only other freeze there is today is "translation string freeze", but that makes little sense without feature freeze
199 2017-01-17 20:44:48	0|wumpus|let's move the feature freeze (and translation freeze) to thursday
200 2017-01-17 20:46:26	0|BlueMatt|my pending list is #8456, #9294 # 9499 and #9535...of those I believe only 9499 has string changes
201 2017-01-17 20:46:31	0|gribble|https://github.com/bitcoin/bitcoin/issues/8456 | [RPC] Simplified bumpfee command. by mrbandrews · Pull Request #8456 · bitcoin/bitcoin · GitHub
202 2017-01-17 20:46:34	0|gribble|https://github.com/bitcoin/bitcoin/issues/9294 | Use internal HD chain for change outputs (hd split) by jonasschnelli · Pull Request #9294 · bitcoin/bitcoin · GitHub
203 2017-01-17 20:46:36	0|gribble|https://github.com/bitcoin/bitcoin/issues/9535 | Split CNode::cs_vSend: message processing and message sending by TheBlueMatt · Pull Request #9535 · bitcoin/bitcoin · GitHub
204 2017-01-17 20:47:08	0|BlueMatt|I dont think anything else is reasonably gonna make a feature freeze
205 2017-01-17 20:47:19	0|BlueMatt|so we could also just call translation string freeze when #9499 is merged
206 2017-01-17 20:47:21	0|gribble|https://github.com/bitcoin/bitcoin/issues/9499 | Use recent-rejects, orphans, and recently-replaced txn for compact-block-reconstruction by TheBlueMatt · Pull Request #9499 · bitcoin/bitcoin · GitHub
207 2017-01-17 20:47:38	0|BlueMatt|(rpc help text is not translated, correct?)
208 2017-01-17 20:47:40	0|wumpus|sounds good to me
209 2017-01-17 20:47:44	0|wumpus|no, rpc help is not translated
210 2017-01-17 20:47:49	0|BlueMatt|ok, good
211 2017-01-17 20:48:45	0|wumpus|9535 isn't even tagged for 0.14.0?!
212 2017-01-17 20:49:02	0|BlueMatt|no, but is too trivial and big win for me to not include in my list :p
213 2017-01-17 20:49:31	0|BlueMatt|but if it slips thats ok
214 2017-01-17 20:49:33	0|wumpus|I think we should focus on the current list, there's still 6 things on there
215 2017-01-17 20:49:40	0|BlueMatt|as long as 9499 doesnt
216 2017-01-17 20:49:44	0|wumpus|https://github.com/bitcoin/bitcoin/pulls?q=is%3Aopen+is%3Apr+milestone%3A0.14.0
217 2017-01-17 20:49:47	0|BlueMatt|half of the current list is bugfixes
218 2017-01-17 20:49:56	0|BlueMatt|of which there are several more coming (see issues tagged for 14)
219 2017-01-17 20:50:18	0|gribble|https://github.com/bitcoin/bitcoin/issues/9148 | Wallet RPCs can return stale info due to ProcessNewBlock Race · Issue #9148 · bitcoin/bitcoin · GitHub
220 2017-01-17 20:50:36	0|BlueMatt|which is nontrivial :(
221 2017-01-17 20:50:37	0|wumpus|bumpfee, internal hd chain, fundrawtransaction, improve progress display are all features I'd say
222 2017-01-17 20:50:50	0|BlueMatt|oh fuck, how did i miss the display one
223 2017-01-17 20:51:02	0|BlueMatt|no, the fundraw one is def a bugfix
224 2017-01-17 20:51:06	0|wumpus|exclude RBF replacement and recent-rejects seem bugfixes
225 2017-01-17 20:51:17	0|BlueMatt|recent-rejects is more a feature
226 2017-01-17 20:51:22	0|wumpus|ok
227 2017-01-17 20:51:53	0|BlueMatt|without the fundarw one it re-uses change addresses
228 2017-01-17 20:52:01	0|BlueMatt|which is very not so good
229 2017-01-17 20:52:21	0|BlueMatt|fuck, jonasschnelli #9377 needs rebase
230 2017-01-17 20:52:23	0|gribble|https://github.com/bitcoin/bitcoin/issues/9377 | fundrawtransaction: Keep change-output keys by default, make it optional by jonasschnelli · Pull Request #9377 · bitcoin/bitcoin · GitHub
231 2017-01-17 20:52:23	0|wumpus|I slotted it as feature as it adds to the RPC API
232 2017-01-17 20:52:42	0|BlueMatt|oh it does add
233 2017-01-17 20:52:42	0|wumpus|anyhow it's important to get in that's for sure
234 2017-01-17 20:52:50	0|BlueMatt|hum, we could probably implement it more cleanly
235 2017-01-17 20:52:59	0|BlueMatt|well, cleanly meaning less diff
236 2017-01-17 20:53:02	0|BlueMatt|but, yea, needs to happen for 14
237 2017-01-17 20:53:09	0|wumpus|is there time for that and still review the stuff before 0.14?
238 2017-01-17 20:53:33	0|BlueMatt|my concern for 14 isnt the open stuff, its the bugs that need fixing that arent even pr'ed yet
239 2017-01-17 20:53:44	0|BlueMatt|eg #9148 is a serious issue and the fix is not tiny
240 2017-01-17 20:53:45	0|gribble|https://github.com/bitcoin/bitcoin/issues/9148 | Wallet RPCs can return stale info due to ProcessNewBlock Race · Issue #9148 · bitcoin/bitcoin · GitHub
241 2017-01-17 20:53:49	0|wumpus|the diff for #9377 is not that large
242 2017-01-17 20:53:51	0|gribble|https://github.com/bitcoin/bitcoin/issues/9377 | fundrawtransaction: Keep change-output keys by default, make it optional by jonasschnelli · Pull Request #9377 · bitcoin/bitcoin · GitHub
243 2017-01-17 20:54:03	0|BlueMatt|yea, I'm not too worried about that one, will review soon
244 2017-01-17 20:54:48	0|BlueMatt|I also plan to do a helgrind run again this or next week, whenever we decide which net pulls will make it, which is gonna result in a nontrivial number of "Convert X to std::atomic" commits
245 2017-01-17 20:55:57	0|BlueMatt|the walletnotify one (#9479 / $9371) is also gonna take some work
246 2017-01-17 20:55:59	0|gribble|https://github.com/bitcoin/bitcoin/issues/9479 | An error has occurred and has been logged. Please contact this bot's administrator for more information.
247 2017-01-17 20:56:22	0|BlueMatt|but i havent dug into that one as of yet
248 2017-01-17 20:56:28	0|BlueMatt|morcos and y'all seem on it
249 2017-01-17 20:58:01	0|BlueMatt|ok, so string freeze is whenever #9499 and #9461 make it, otherwise when feature freeze happens
250 2017-01-17 20:58:03	0|gribble|https://github.com/bitcoin/bitcoin/issues/9499 | Use recent-rejects, orphans, and recently-replaced txn for compact-block-reconstruction by TheBlueMatt · Pull Request #9499 · bitcoin/bitcoin · GitHub
251 2017-01-17 20:58:05	0|gribble|https://github.com/bitcoin/bitcoin/issues/9461 | [Qt] Improve progress display during headers-sync and peer-finding by jonasschnelli · Pull Request #9461 · bitcoin/bitcoin · GitHub
252 2017-01-17 20:58:16	0|BlueMatt|jonasschnelli: can you fix the outstanding comments on #9461?
253 2017-01-17 20:58:18	0|gribble|https://github.com/bitcoin/bitcoin/issues/9461 | [Qt] Improve progress display during headers-sync and peer-finding by jonasschnelli · Pull Request #9461 · bitcoin/bitcoin · GitHub
254 2017-01-17 21:25:26	0|BlueMatt|'tf
255 2017-01-17 21:25:48	0|BlueMatt|so I'm pretty sure, right now, if you receive a coinbase payout in a block, turn off your node, and then restart without checkblocks, your payout will not display
256 2017-01-17 21:26:24	0|BlueMatt|because no NotifyTransactionChanged will ever fire to the gui
257 2017-01-17 21:27:18	0|BlueMatt|i mean super edge-case-y but still
258 2017-01-17 21:32:15	0|sipa|is that a recent regression?
259 2017-01-17 21:33:31	0|BlueMatt|looks super old
260 2017-01-17 21:33:35	0|BlueMatt|but didnt check
261 2017-01-17 21:33:41	0|BlueMatt|restarting gui will fix it, though, afaict
262 2017-01-17 23:53:54	0|bitcoin-git|[13bitcoin] 15TheBlueMatt opened pull request #9570: Block Wallet RPCs until wallet is synced to our current chain (06master...062017-01-fix-wallet-rpc-stale) 02https://github.com/bitcoin/bitcoin/pull/9570
263 2017-01-17 23:56:55	0|gmaxwell|I thought the fundraw change change made it in already. darn.