1 2016-12-22 00:01:40	0|Chris_Stewart_5|instagibbs: Thank you
  2 2016-12-22 00:03:42	0|midnightmagic|getting bitcoin built on 10.04 is turning into quite the chore.
  3 2016-12-22 00:07:04	0|phantomcircuit|midnightmagic, why are you trying to build on 10.04?
  4 2016-12-22 00:08:25	0|midnightmagic|phantomcircuit: so I don't have to completely rebuild that machine from scratch, since modern kernels do not seem to support some of the hardware on that machine (including iwl4965agn)
  5 2016-12-22 00:09:18	0|phantomcircuit|you sure i have the driver for that on this debian system
  6 2016-12-22 00:11:11	0|phantomcircuit|midnightmagic, the 4965agn requires a binary blob firmware
  7 2016-12-22 00:11:29	0|midnightmagic|phantomcircuit: high-throughput usage in my wifi network freezes the card/driver/whatever and pauses all effective transmission. It must be full-duplex communication, so, tcp stream e.g., and not just a plain pingflood.
  8 2016-12-22 00:11:43	0|midnightmagic|phantomcircuit: yes, that it does. :)
  9 2016-12-22 05:04:09	0|bitcoin-git|[13bitcoin] 15anditto opened pull request #9407: Added missing colons in when running help command (06master...06minor-style-fixes) 02https://github.com/bitcoin/bitcoin/pull/9407
 10 2016-12-22 09:48:11	0|btcdrak|wumpus: what's the plan for 0.13.2 - I assume we dont need another RC for the version number thing.
 11 2016-12-22 10:01:42	0|gmaxwell|btcdrak: still three days to christmas, plenty of time for more RCs.
 12 2016-12-22 10:02:42	0|rabidus_|:D
 13 2016-12-22 10:03:57	0|btcdrak|"on the day of Christmas, my true love gave to me, a RC in a merkle tree"
 14 2016-12-22 10:04:47	0|gmaxwell|man I ran 0.13.2(rc) in valgrind overnight last night on my laptop (which was a day or so behind) and it only synced 111 blocks in about 8 hours.
 15 2016-12-22 10:07:01	0|midnightmagic|time to write a custom memory manager
 16 2016-12-22 10:16:15	0|bitcoin-git|13bitcoin/06master 14041331e 15MarcoFalke: Merge #9407: [Trivial] Added missing colons in when running help command...
 17 2016-12-22 10:16:15	0|bitcoin-git|13bitcoin/06master 14afe5b3f 15Anditto Heristyo: Added missing colons in when running help command
 18 2016-12-22 10:16:15	0|bitcoin-git|[13bitcoin] 15MarcoFalke pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/e8cfe1ee2d01...041331e1da23
 19 2016-12-22 10:16:29	0|bitcoin-git|[13bitcoin] 15MarcoFalke closed pull request #9407: [Trivial] Added missing colons in when running help command (06master...06minor-style-fixes) 02https://github.com/bitcoin/bitcoin/pull/9407
 20 2016-12-22 10:45:39	0|jonasschnelli|gmaxwell: "synced 111 blocks in about 8 hours" ... hah!
 21 2016-12-22 10:45:46	0|jonasschnelli|Whats the result? Any major leaks?
 22 2016-12-22 10:47:46	0|gmaxwell|no, course not.. bitcoind is leak free (ignoring the one shot openssl stupidity), I run every release in valgrind and have for a long time.  (QT I wasn't doing that.)
 23 2016-12-22 10:48:27	0|gmaxwell|valgrind's leak detection is really not the interesting feature.
 24 2016-12-22 10:48:46	0|gmaxwell|the inderesting feature is uninitilized memory access detection.
 25 2016-12-22 10:54:06	0|gmaxwell|it's just become increasingly slow, I guess due to transaction traffic growth. :(
 26 2016-12-22 10:58:50	0|luke-jr|LLVM's thing is somewhat faster, but.. a hassle to use and broken with some LLVM/kernel pairs :/
 27 2016-12-22 11:29:34	0|bitcoin-git|[13bitcoin] 15MarcoFalke closed pull request #9391: wallet: Remove sendfree (06master...06Mf1612-015walletSendFreeNONO) 02https://github.com/bitcoin/bitcoin/pull/9391
 28 2016-12-22 12:14:53	0|wumpus|btcdrak: that's mostly an academic concern, how large is the chance that no issues come up with rc1 :) but if none happen, yeah I tend to agree, version bump can be part of final
 29 2016-12-22 12:16:23	0|wumpus|btw what about the meetings around xmas? I won't be able to attend this week's and next one - should I cancel them or just find another chair?
 30 2016-12-22 12:18:01	0|gmaxwell|You mean today's? for this weeks'?  well we can always chat with whomever shows up, meeting or not.
 31 2016-12-22 12:18:07	0|wumpus|yes
 32 2016-12-22 12:19:08	0|gmaxwell|Hotel Ircfornia. You can check-out any time you like but you can never leave.
 33 2016-12-22 12:19:31	0|wumpus|but some people may be making time or getting up early for it or I dunno, if almost no one turns up that may be wasted effort
 34 2016-12-22 12:20:20	0|gmaxwell|I'll be around.
 35 2016-12-22 12:21:04	0|wumpus|ok, I guess you can be chair then :)
 36 2016-12-22 12:21:13	0|gmaxwell|k
 37 2016-12-22 13:44:42	0|morcos|instagibbs: heard you were thinking about allowing multiple outstanding block requests...
 38 2016-12-22 13:45:04	0|morcos|this is an idea of how to do it:  https://gist.github.com/morcos/c70ca4f4f3cedf26f1d37b324933afad
 39 2016-12-22 13:46:14	0|morcos|havent thought through yet how it might be implemented
 40 2016-12-22 13:47:48	0|morcos|i'm not sure that's 100% clear but there are a couple of different changes there
 41 2016-12-22 13:48:19	0|morcos|i think its kind of silly that we ignore cmpctblocks we receive from HB peers (if they don't immediately reconstruct) if we have an outstanding request for a cmpctblock from a LB peer.
 42 2016-12-22 13:50:09	0|instagibbs|trying to parse it now, it seems related to what I'm trying
 43 2016-12-22 13:52:00	0|instagibbs|Right now all I've attempted is to reply to a CMPCTBLOCK while the same block is in flight from another peer, responding up to 1 non-marked-as-hb peer, and responding to any marked-as-hb peer.
 44 2016-12-22 13:52:27	0|instagibbs|meaning if marked-as-hb is first, i wont respond to not-marked-as-hb peer
 45 2016-12-22 13:52:50	0|morcos|but you will respond to multiple hb peers?
 46 2016-12-22 13:53:56	0|morcos|i do think that if the first peer that sends you something is an HB peer, you should still request a cmpct block from a LB peer if they are the next one to inform you (via header)
 47 2016-12-22 13:54:07	0|instagibbs|Well, as-is yes, but I can make this "no" just as easily
 48 2016-12-22 13:55:17	0|morcos|basically i think if you consider a getdata BLOCKTXN or getdata BLOCK a second stage request, and a getdata CMPCTBLOCK a first stage request
 49 2016-12-22 13:56:39	0|morcos|you should be willing to always make sure you have at least two requests at as a high stage as you have opportunity for (except not 2 full BLOCK)
 50 2016-12-22 13:57:32	0|instagibbs|high stage? first? second? sorry this terminology is putting me in loops
 51 2016-12-22 13:57:33	0|morcos|eh, everytime i try to describe it even i don't think its clear
 52 2016-12-22 13:57:38	0|instagibbs|yeah...
 53 2016-12-22 13:57:58	0|morcos|i'll try another approach
 54 2016-12-22 13:58:06	0|instagibbs|Might be easier to talk about motivation, what we're gaining and avoiding
 55 2016-12-22 14:01:59	0|morcos|sorry i'm trying to build a spreadsheet, ha
 56 2016-12-22 14:02:13	0|instagibbs|oh jeez :)
 57 2016-12-22 14:02:36	0|morcos|my goal is to make it so that no one slow peer can stop one fast peer from getting the block to you as quickly as possible
 58 2016-12-22 14:02:50	0|morcos|as long as that fast peer is at least a compact block type (but he might be LB)
 59 2016-12-22 14:03:04	0|instagibbs|Agreed, my patch supposedly does this
 60 2016-12-22 18:33:08	0|dgenr8|morcos: does core try to ensure somehow that incoming txes paying the wallet are not dumped by mempool limiting?
 61 2016-12-22 18:36:26	0|gmaxwell|dgenr8: no doing so would be bad for privacy and reliablity (making the wallet think transactions were likely in other peoples mempools when they are not), and isn't needed.
 62 2016-12-22 18:43:17	0|dgenr8|gmaxwell: thanks
 63 2016-12-22 18:59:46	0|gmaxwell|#bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier
 64 2016-12-22 18:59:50	0|jonasschnelli|Hi
 65 2016-12-22 18:59:53	0|btcdrak|hi
 66 2016-12-22 18:59:53	0|CodeShark|hello
 67 2016-12-22 19:00:03	0|btcdrak|ping jl2012
 68 2016-12-22 19:00:03	0|gmaxwell|#startmeeting
 69 2016-12-22 19:00:05	0|kanzure|hi.
 70 2016-12-22 19:00:06	0|phantomcircuit|ping
 71 2016-12-22 19:00:27	0|jonasschnelli|gmaxwell: it's meetingstart I guess
 72 2016-12-22 19:00:36	0|jl2012|hi
 73 2016-12-22 19:00:42	0|gmaxwell|#meetingstart
 74 2016-12-22 19:00:50	0|jonasschnelli|well...
 75 2016-12-22 19:00:53	0|CodeShark|I just have one item on my agenda for today's meeting, but we don't have to go over it first
 76 2016-12-22 19:00:54	0|gmaxwell|hah the bot isn't here.
 77 2016-12-22 19:01:04	0|instagibbs|here
 78 2016-12-22 19:01:06	0|gmaxwell|well we don't need it. We can pretend its here.
 79 2016-12-22 19:01:11	0|jonasschnelli|Lightningbot has already xmas break,
 80 2016-12-22 19:01:16	0|jonasschnelli|sure
 81 2016-12-22 19:01:27	0|gmaxwell|In any case wumpus is out today, I'm sure many people are.
 82 2016-12-22 19:01:35	0|gmaxwell|Suggested topics?
 83 2016-12-22 19:01:40	0|CodeShark|WitnessMerkleBlock
 84 2016-12-22 19:01:54	0|jonasschnelli|If priorities allows, hd chain split and pub-key-der
 85 2016-12-22 19:02:02	0|btcdrak|lightningbot seems to be offline
 86 2016-12-22 19:02:10	0|CodeShark|we'll have to do it manually
 87 2016-12-22 19:02:16	0|CodeShark|unless there's a quick fix
 88 2016-12-22 19:02:35	0|cfields|sorry, here
 89 2016-12-22 19:02:48	0|gmaxwell|I presume everyone knows 0.13.2rc is out, and is busy testing it? :)
 90 2016-12-22 19:02:55	0|instagibbs|oh, no i didnt
 91 2016-12-22 19:02:57	0|CodeShark|+1 :)
 92 2016-12-22 19:03:07	0|instagibbs|#action test 0.13.2rc2
 93 2016-12-22 19:03:10	0|instagibbs|oh rc1 misread
 94 2016-12-22 19:03:36	0|gmaxwell|we tagged rc1, 0.13 branch is one PR ahead ... rc1 failed to bump the version. 0.13 branch does.
 95 2016-12-22 19:03:50	0|gmaxwell|Indeed:
 96 2016-12-22 19:04:05	0|gmaxwell|#action test 0.13.1rc1 or 0.13 branch
 97 2016-12-22 19:04:12	0|gmaxwell|(we're pretending the bot is here, remember.)
 98 2016-12-22 19:04:19	0|jonasschnelli|Yes. Testing here. Can't sign the gitian assets file right now,... key expired.
 99 2016-12-22 19:04:58	0|gmaxwell|jonasschnelli: you can always edit the expiration date on your pgp keys. the idea is to force others to get an updated copy of your key so they would have an oppturnity to learn of a revocation.
100 2016-12-22 19:05:11	0|jonasschnelli|I really should create a new one.
101 2016-12-22 19:05:24	0|MarcoFalke_web|?why
102 2016-12-22 19:05:26	0|jonasschnelli|I try to use a HWW
103 2016-12-22 19:05:29	0|instagibbs|gmaxwell, huh, TIL.
104 2016-12-22 19:05:49	0|gmaxwell|(So it's a good practice to set a short expiration and then just keep periodically pushing it forward so long as your key isn't compromised)
105 2016-12-22 19:06:04	0|gmaxwell|(e.g. short like a year and push it forward every six months)
106 2016-12-22 19:06:12	0|BlueMatt|next topic? I know everyone has their pet feature for 0.14, given that we're getting close to feature-freeze already - but I wanted to nominate my pet for review-help :)
107 2016-12-22 19:06:19	0|CodeShark|WitnessMerkleBlock :)
108 2016-12-22 19:06:27	0|instagibbs|shoot blueman
109 2016-12-22 19:06:34	0|CodeShark|but go for it, matt
110 2016-12-22 19:06:36	0|gmaxwell|CodeShark: we'rell get to it!
111 2016-12-22 19:06:39	0|CodeShark|:)
112 2016-12-22 19:06:43	0|jl2012|topic suggestion: excessive sighashing protection policy #8755 and #8654. Maybe too late for 0.14?
113 2016-12-22 19:06:45	0|gribble|https://github.com/bitcoin/bitcoin/issues/8755 | Implement excessive sighashing protection policy with tight sighash estimation by jl2012 · Pull Request #8755 · bitcoin/bitcoin · GitHub
114 2016-12-22 19:06:47	0|gribble|https://github.com/bitcoin/bitcoin/issues/8654 | Reuse sighash computations across evaluation (rebase of #4562) by jl2012 · Pull Request #8654 · bitcoin/bitcoin · GitHub
115 2016-12-22 19:06:57	0|gmaxwell|#topic 0.14 pet features
116 2016-12-22 19:07:25	0|instagibbs|When are we trying to freeze
117 2016-12-22 19:07:55	0|BlueMatt|but has opportunity to be a massive speedup in block-relay times
118 2016-12-22 19:07:56	0|jonasschnelli|gmaxwell did
119 2016-12-22 19:08:06	0|gmaxwell|jl2012: I don't know what wumpus is going to call for 0.14 though due to the net refactors I feel like we're going to have a relatively long finalization cycle for this release.
120 2016-12-22 19:08:07	0|BlueMatt|instagibbs: mid-january feature freeze, actual freeze later
121 2016-12-22 19:08:59	0|gmaxwell|I guess it would be good for people to propose 0.14 tags on whatever PRs are already in flight that you want in 0.14.
122 2016-12-22 19:09:35	0|cfields|gmaxwell: i don't think it'll be too bad. Sadly it looks like the real async changes aren't going to make it for 0.14. I think the only real gotcha right now is the assert that keeps finding new issues, but we'll need to remove that soon
123 2016-12-22 19:09:43	0|btcdrak|we should make a point to review 8755 and 8654.
124 2016-12-22 19:09:53	0|jonasschnelli|10 0.14 tags right now: https://github.com/bitcoin/bitcoin/pulls?q=is%3Aopen+is%3Apr+milestone%3A0.14.0
125 2016-12-22 19:09:56	0|instagibbs|#855
126 2016-12-22 19:09:58	0|gribble|https://github.com/bitcoin/bitcoin/issues/855 | Toggle hide by sje397 · Pull Request #855 · bitcoin/bitcoin · GitHub
127 2016-12-22 19:09:59	0|instagibbs|#8755
128 2016-12-22 19:10:00	0|BlueMatt|I believe cfields is gonna push a new version to #9289, which is pretty important, but also #9375
129 2016-12-22 19:10:01	0|gribble|https://github.com/bitcoin/bitcoin/issues/8755 | Implement excessive sighashing protection policy with tight sighash estimation by jl2012 · Pull Request #8755 · bitcoin/bitcoin · GitHub
130 2016-12-22 19:10:02	0|luke-jr|#7533 is annoying to rebase; would be nice to get multiwallet in, but not sure we have time (#8776 looks reasonably ready to merge?)
131 2016-12-22 19:10:03	0|gribble|https://github.com/bitcoin/bitcoin/issues/9289 | net: drop boost::thread_group by theuni · Pull Request #9289 · bitcoin/bitcoin · GitHub
132 2016-12-22 19:10:04	0|gribble|https://github.com/bitcoin/bitcoin/issues/9375 | Relay compact block messages prior to full block connection by TheBlueMatt · Pull Request #9375 · bitcoin/bitcoin · GitHub
133 2016-12-22 19:10:06	0|gribble|https://github.com/bitcoin/bitcoin/issues/7533 | RPC: sendrawtransaction: Allow the user to ignore/override specific rejections by luke-jr · Pull Request #7533 · bitcoin/bitcoin · GitHub
134 2016-12-22 19:10:07	0|gribble|https://github.com/bitcoin/bitcoin/issues/8776 | Wallet refactoring leading up to multiwallet by luke-jr · Pull Request #8776 · bitcoin/bitcoin · GitHub
135 2016-12-22 19:10:19	0|gmaxwell|cfields: I'm disappointed with how ineffective testing is at finding issues behind that assert.
136 2016-12-22 19:10:25	0|cfields|heh. let's take turns :)
137 2016-12-22 19:11:00	0|gmaxwell|luke-jr: What do you think remains for multiwallet just more review? I admit I haven't been looking at it. I'd certantly like to see it in.
138 2016-12-22 19:11:30	0|gmaxwell|luke-jr: I'm also reminded that you PRed a feature to sweep funds based on scanning the utxo set. Where is that right now?
139 2016-12-22 19:11:33	0|BlueMatt|cfields: I'm done with my pet, just noting that to make it happen its gonna be a lot of prs that build on each other in quick succession so gonna need help with review there
140 2016-12-22 19:11:47	0|luke-jr|gmaxwell: yes, pretty much; the other pre-multiwallet PR needs rebasing yet again, but that shouldn't be hard
141 2016-12-22 19:11:53	0|instagibbs|I'm working on a couple CB PRs that would be nice to be in. But both are quite raw, maybe shoot for at least the first.
142 2016-12-22 19:11:54	0|jonasschnelli|Multiwallet project page: https://github.com/bitcoin/bitcoin/projects/2
143 2016-12-22 19:12:40	0|luke-jr|sweepprivkeys is #9152 but hasn't had any review yet (besides concept discussion of rawtx interfaces and such)
144 2016-12-22 19:12:41	0|gribble|https://github.com/bitcoin/bitcoin/issues/9152 | Wallet/RPC: sweepprivkeys method to scan UTXO set and send to local wallet by luke-jr · Pull Request #9152 · bitcoin/bitcoin · GitHub
145 2016-12-22 19:12:55	0|jonasschnelli|IMO most important wallet features is the hd chain split
146 2016-12-22 19:13:03	0|jonasschnelli|Better fix sooner then later
147 2016-12-22 19:13:08	0|luke-jr|no objection to targetting 0.14 for it, but I don't consider it a huge priority since it is fairly isolated and easy to rebase
148 2016-12-22 19:14:07	0|jonasschnelli|sweepprivkey should fit into a the rawtx line. I think this is too late for 0.14
149 2016-12-22 19:14:18	0|jonasschnelli|Multiwallet probably also. This is an impactfull change.
150 2016-12-22 19:14:52	0|jonasschnelli|I think it would be great if someone could review #9294
151 2016-12-22 19:14:54	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
152 2016-12-22 19:15:18	0|gmaxwell|jonasschnelli: Because of the lack of backwards compatiblity there can be an argument for batching it with other wallet changes. Though I agree it is really important.
153 2016-12-22 19:15:46	0|jonasschnelli|I'd like to batch it with the HD-pubkey pr. But not sure if this is realistic.
154 2016-12-22 19:15:59	0|gmaxwell|jonasschnelli: HD-pubkey pr?
155 2016-12-22 19:15:59	0|jonasschnelli|IMO we should slowly think about a feature to use the wallet without privatekeys but with HD metadata.
156 2016-12-22 19:16:16	0|jonasschnelli|derive private-keys on the fly.
157 2016-12-22 19:17:00	0|jonasschnelli|#9298
158 2016-12-22 19:17:02	0|gribble|https://github.com/bitcoin/bitcoin/issues/9298 | An error has occurred and has been logged. Please contact this bot's administrator for more information.
159 2016-12-22 19:17:03	0|jcorgan|
160 2016-12-22 19:17:09	0|jonasschnelli|Not sure if this is the right approach
161 2016-12-22 19:17:31	0|gmaxwell|jonasschnelli: ah the change to not save private keys for the HD children but only derrive them when needed? yes, thats a wallet format change too.
162 2016-12-22 19:17:36	0|jonasschnelli|But if we once like to support a process handling the private keys (like GPG agent) or compatibility with hardware wallets, we need something like this
163 2016-12-22 19:17:50	0|CodeShark|it's the way to do it, ultimately
164 2016-12-22 19:17:58	0|gmaxwell|I'll review at least.
165 2016-12-22 19:18:13	0|jonasschnelli|Because both PRs are not downwareds comp., we should bundle them.
166 2016-12-22 19:18:19	0|jonasschnelli|But IMO the chain split is important.
167 2016-12-22 19:18:29	0|jonasschnelli|We shouldn't create to many wallet without the hd change chain
168 2016-12-22 19:18:34	0|jonasschnelli|*wallets
169 2016-12-22 19:18:46	0|gmaxwell|I'm a little concerned that we're thin on user visible features in 0.14, which will make uptake slower, ultimately resulting in slower testing and feedback-- it is what it is.
170 2016-12-22 19:18:58	0|jonasschnelli|Heh. Yes.
171 2016-12-22 19:19:03	0|CodeShark|add some animated gifs :p
172 2016-12-22 19:19:05	0|jonasschnelli|We could change the splash-screen...
173 2016-12-22 19:19:07	0|jonasschnelli|;-)
174 2016-12-22 19:19:35	0|jonasschnelli|Multiwallet would be realtitic if everyone helps reviewing
175 2016-12-22 19:19:41	0|gmaxwell|Replace the logo with a B engraved moon in celebration of the recent price activity. :P
176 2016-12-22 19:19:41	0|jonasschnelli|realistic for 0.14
177 2016-12-22 19:19:49	0|jonasschnelli|bah
178 2016-12-22 19:20:02	0|gmaxwell|I'll see what efforts I can drum up for multiwallet. I agree with that view.
179 2016-12-22 19:20:22	0|CodeShark|thanks for reviving this effort, luke-jr :)
180 2016-12-22 19:20:26	0|CodeShark|I had almost given up hope
181 2016-12-22 19:20:26	0|jcorgan|i'll throw my vote in for the hd chain split and only deriving keys on the fly
182 2016-12-22 19:20:28	0|jonasschnelli|What concerns me with multiwallet is the possible performance downsides.. needs more testing I guess.
183 2016-12-22 19:20:39	0|gmaxwell|jonasschnelli: have you done any work on they keypool management? e.g. removing all the keys up to a wallet observed key to that recovery works better?
184 2016-12-22 19:20:45	0|BlueMatt|gmaxwell: with #9375 alone we could argue "massive improvements in network-propagation speed
185 2016-12-22 19:20:46	0|gribble|https://github.com/bitcoin/bitcoin/issues/9375 | Relay compact block messages prior to full block connection by TheBlueMatt · Pull Request #9375 · bitcoin/bitcoin · GitHub
186 2016-12-22 19:20:52	0|luke-jr|I'm going to review the HD split stuff when the meeting is over.
187 2016-12-22 19:20:57	0|jonasschnelli|gmaxwell: I did,... but IMO it's non trivial.
188 2016-12-22 19:21:04	0|jonasschnelli|Problem: encrypted wallets
189 2016-12-22 19:21:16	0|gmaxwell|BlueMatt: yes sure, 0.14 is guarenteed to be very attractive to miners already. :) but not much else I think.
190 2016-12-22 19:21:19	0|jonasschnelli|You can't top up the keypool during some internal operations (like SyncTx)
191 2016-12-22 19:21:33	0|instagibbs|alright gotta bounce, tap me for needed review please
192 2016-12-22 19:21:40	0|luke-jr|CodeShark: ☺
193 2016-12-22 19:22:00	0|gmaxwell|jonasschnelli: why is that a problem?  You can still remove the keys, even if rescanning isn't magically solved in the first step. (and if the user unlocks before rescan it should be magically solved)
194 2016-12-22 19:22:00	0|luke-jr|jonasschnelli: people can always not-use multiwallet if performance is critical
195 2016-12-22 19:22:20	0|gmaxwell|luke-jr: I think he meant it might have performance regressions on the single wallet case.
196 2016-12-22 19:22:38	0|jonasschnelli|For rescan, yes. But for detecting running with an old wallet (without rescan), its harder
197 2016-12-22 19:22:46	0|jonasschnelli|old wallet = backup
198 2016-12-22 19:22:55	0|gmaxwell|jonasschnelli: oh can't top up during some internal operations... that would be a challenge.
199 2016-12-22 19:23:24	0|jonasschnelli|But agree, we should at least fix the rescan-with-an-old-hd-wallet feature
200 2016-12-22 19:23:33	0|jonasschnelli|I'll work on that.
201 2016-12-22 19:24:21	0|jonasschnelli|But IMO, multiwallet is the lowest hanging fruit for some nice wallet features in 0.14
202 2016-12-22 19:24:24	0|gmaxwell|jonasschnelli: even without fully improving rescan, we should be removing keys from the pool that we know from transactions that they are used.  It will help when people have started multiple copies of a wallet concurrently.
203 2016-12-22 19:24:38	0|gmaxwell|okay any other PRs we should discuss briefly for more attention for 0.14 before we move onto proposed topics that don't have PRs yet?
204 2016-12-22 19:24:49	0|luke-jr|gmaxwell: only thing I can think of that could impact it is the lookup of the specific wallet for RPC calls, but I would think that'd be fairly fast
205 2016-12-22 19:25:11	0|jonasschnelli|luke-jr: I think simplest thing would be URL endpoints.
206 2016-12-22 19:26:00	0|jonasschnelli|/<walletA> affects walletA.dat
207 2016-12-22 19:26:10	0|gmaxwell|#action review meeting log and review things people are working on for potentially 0.14.
208 2016-12-22 19:26:33	0|CodeShark|may I talk a little about WitnessMerkleBlocks?
209 2016-12-22 19:26:45	0|gmaxwell|#topic WitnessMerkleBlocks
210 2016-12-22 19:27:10	0|gmaxwell|CodeShark: You have the floor.
211 2016-12-22 19:27:16	0|CodeShark|thank you :)
212 2016-12-22 19:27:31	0|CodeShark|so I started working on a new message type that for filtered blocks that includes the path to coinbase and a partial merkle tree for the witnesses
213 2016-12-22 19:27:52	0|CodeShark|while I don't really like BIP37 at all, we currently lack another query mechanism that doesn't require full block downloads
214 2016-12-22 19:28:08	0|CodeShark|I started working on this code: I started working on a new message type that for filtered blocks that includes the path to coinbase
215 2016-12-22 19:28:10	0|CodeShark|argh
216 2016-12-22 19:28:14	0|CodeShark|clipboard error
217 2016-12-22 19:28:27	0|CodeShark|https://github.com/bitcoin/bitcoin/compare/master...CodeShark:WitnessMerkleBlock2
218 2016-12-22 19:28:47	0|CodeShark|in addition, rather than sending all the transactions as separate messages, it includes them in the same structure
219 2016-12-22 19:29:01	0|CodeShark|while this does not allow for some minor network optimizations, I believe these optimizations are misplaced
220 2016-12-22 19:29:13	0|gmaxwell|I think we like the proof style returns. Does your use case benefit from the bloom style queries? or, for example, would a getblocktxn like query be more useful to you?
221 2016-12-22 19:29:35	0|CodeShark|hmm - good question
222 2016-12-22 19:29:58	0|CodeShark|so getblocktxn would have you specify a block hash and a transaction index?
223 2016-12-22 19:30:06	0|gmaxwell|(I'm not sure you're familar with the BIP152 getblocktxn message, -- it is a "request transactions by their index in a block")
224 2016-12-22 19:30:18	0|CodeShark|oh...I haven't looked at that
225 2016-12-22 19:30:19	0|jonasschnelli|Is this related to the filter commitments?
226 2016-12-22 19:30:40	0|gmaxwell|Yes, you request transactions for a specific block hash by index, in a very efficient way, and get back a single message with the txn packed in it.
227 2016-12-22 19:30:59	0|jonasschnelli|https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-May/012636.html
228 2016-12-22 19:31:18	0|CodeShark|hmmm - that requires more roundtrips...but it's a more fundamentally important query
229 2016-12-22 19:31:46	0|gmaxwell|So I was thinking before that your particular need for witnesses could be answered by a version of getblocktxn whos reply included the membership proofs. But I wasn't sure if it fully covered your needs.
230 2016-12-22 19:32:12	0|BlueMatt|committed bloom filters could even be deployed w/o soft-forking them in - just have nodes be able to serve them for blocks
231 2016-12-22 19:32:25	0|CodeShark|yes, BlueMatt - I was thinking the same thing
232 2016-12-22 19:32:26	0|BlueMatt|might be expensive to generate, but would be an interesting test
233 2016-12-22 19:32:51	0|CodeShark|I'll have to look at getblocktxn more
234 2016-12-22 19:33:01	0|gmaxwell|In any case, if CodeShark thinks many of the interesting usecases could be answered by a query by index... I would rather work on that first.  I am realllly not eager to continue to invest in the pretty much known broken BIP37 approach.
235 2016-12-22 19:33:35	0|CodeShark|I'll definitely take a look
236 2016-12-22 19:33:38	0|BlueMatt|gmaxwell: agreed
237 2016-12-22 19:33:45	0|gmaxwell|(in particular I was thinking you could use BIP37 on the non-witness data, and when you need witnesses, query by index for them)
238 2016-12-22 19:34:16	0|CodeShark|extending BIP37 would be a stopgap measure at best - if we can deploy a better solution nearterm I'm all for it
239 2016-12-22 19:35:06	0|gmaxwell|Sounds good. In any case, I'm glad to help talk it through. I wouldn't want to force you to wait on the BIP37 replacement to do something, but if we can be less stopgap that would be better.
240 2016-12-22 19:35:25	0|CodeShark|excellent :)
241 2016-12-22 19:35:46	0|CodeShark|I'll look into BIP152 a bit more after the meeting
242 2016-12-22 19:36:07	0|gmaxwell|You should still have the option of requesting full blocks... and for privacy reasons I'd really suggest all SPV wallets expose that as at least an option generally.  But sure, I agree that we should figure how how to accomidate some kind of sparse fetching for you.
243 2016-12-22 19:36:08	0|CodeShark|I don't really have much more to say on this topic until I have a chance to tinker a bit with that
244 2016-12-22 19:36:37	0|gmaxwell|OKAY, what other topics have I forgotten.  We talked some about jonasschnelli's chain split in the prior topic.
245 2016-12-22 19:36:52	0|CodeShark|thanks, gmaxwell :)
246 2016-12-22 19:37:12	0|jonasschnelli|IMO the chain split needs review, thats all. :)
247 2016-12-22 19:38:52	0|cfields|<jl2012> topic suggestion: excessive sighashing protection policy #8755 and #8654. Maybe too late for 0.14?
248 2016-12-22 19:38:53	0|gribble|https://github.com/bitcoin/bitcoin/issues/8755 | Implement excessive sighashing protection policy with tight sighash estimation by jl2012 · Pull Request #8755 · bitcoin/bitcoin · GitHub
249 2016-12-22 19:38:55	0|gribble|https://github.com/bitcoin/bitcoin/issues/8654 | Reuse sighash computations across evaluation (rebase of #4562) by jl2012 · Pull Request #8654 · bitcoin/bitcoin · GitHub
250 2016-12-22 19:39:00	0|cfields|jl2012: did you have more to discuss there?
251 2016-12-22 19:39:05	0|gmaxwell|Another thing that needs review is #9138  really we don't have enough testing infrastructure for the wallet and fee estimation, so we really do count on eyeballs.
252 2016-12-22 19:39:08	0|gribble|https://github.com/bitcoin/bitcoin/issues/9138 | Improve fee estimation by morcos · Pull Request #9138 · bitcoin/bitcoin · GitHub
253 2016-12-22 19:40:00	0|jl2012|cfields: I hope people could read this: https://github.com/jl2012/bips/blob/sighash/bip-sighash.mediawiki . Didn't receive any reply on ML
254 2016-12-22 19:40:27	0|gmaxwell|#action read (and maybe reply) to https://github.com/jl2012/bips/blob/sighash/bip-sighash.mediawiki
255 2016-12-22 19:40:53	0|jl2012|That's a long post, but it explains the rationale of 8755 and 8654
256 2016-12-22 19:41:23	0|luke-jr|not quite Core-related, but it would be nice to get some BIP Comments posted now that BIP 2 is Active
257 2016-12-22 19:41:32	0|jonasschnelli|I have tagged 8755 and 8564 for 0.14.
258 2016-12-22 19:41:43	0|gmaxwell|jonasschnelli: thanks.
259 2016-12-22 19:41:57	0|gmaxwell|luke-jr: Can you explain briefly what BIP comments are for us?
260 2016-12-22 19:42:03	0|jl2012|8654 is also somewhat a risky refactor
261 2016-12-22 19:42:26	0|jl2012|a bug was found after it got several ACKs
262 2016-12-22 19:42:30	0|luke-jr|BIP Comments are simply put a GitHub wiki page where people can post a brief opinion on the BIP
263 2016-12-22 19:42:48	0|gmaxwell|jl2012: have we at least added a test that would have found that bug?
264 2016-12-22 19:43:06	0|gmaxwell|luke-jr: is there any procedure for providing one?
265 2016-12-22 19:43:13	0|luke-jr|the idea being to provide a central location users can use to differentiate between inadvisable and recommended BIPs
266 2016-12-22 19:43:14	0|jl2012|yes, it now includes the tests to detect that bug
267 2016-12-22 19:44:51	0|luke-jr|gmaxwell: just editing the wiki page, but should ideally be done after the BIP is proposed, and before that point comments ought to be posted to bitcoin-dev instead to allow the drafter to possibly revise the BIP to address concerns
268 2016-12-22 19:44:56	0|luke-jr|https://github.com/bitcoin/bips/blob/master/bip-0002.mediawiki#BIP_comments may be useful to read over
269 2016-12-22 19:45:08	0|gmaxwell|luke-jr: thanks!
270 2016-12-22 19:45:42	0|gmaxwell|Anything else?
271 2016-12-22 19:45:51	0|sipa|hi!
272 2016-12-22 19:45:53	0|sipa|i forgot
273 2016-12-22 19:46:04	0|sipa|good morning
274 2016-12-22 19:46:10	0|CodeShark|welcome!
275 2016-12-22 19:46:23	0|gmaxwell|sipa: we've assigned you all the work, so no worries.
276 2016-12-22 19:46:26	0|luke-jr|lol
277 2016-12-22 19:46:37	0|sipa|great
278 2016-12-22 19:46:54	0|gmaxwell|sipa: anything you'd like to discuss?
279 2016-12-22 19:47:09	0|jonasschnelli|morning sipa!
280 2016-12-22 19:47:50	0|sipa|gmaxwell: did you report that the per-txout cache is now a clear performance win?
281 2016-12-22 19:48:10	0|gmaxwell|I thought about that but did not!
282 2016-12-22 19:48:43	0|sipa|so: it turned out that in our earlier benchmark, some debug code was left that resulted in a database read for every txin, which was killing performance
283 2016-12-22 19:49:17	0|sipa|it's now around 30% faster to IBD, with sigchrck disabled, both for small and large fbcache
284 2016-12-22 19:49:23	0|sipa|so... work continues
285 2016-12-22 19:49:30	0|sipa|</report>
286 2016-12-22 19:49:35	0|luke-jr|wow, nice
287 2016-12-22 19:50:06	0|gmaxwell|Further speedups are expected.  In one sense this is bad news, since now we'll have to figure out how to make the migration. :)
288 2016-12-22 19:50:43	0|luke-jr|we've required reindexing before
289 2016-12-22 19:51:06	0|gmaxwell|luke-jr: the bigger the chain the larger the pill that is to swallow.
290 2016-12-22 19:51:10	0|sipa|we're investigating better cache eviction policies (instead of the wipe-cache-on-flush method...), no good results yet, but a few ideas remain
291 2016-12-22 19:51:18	0|gmaxwell|esp now that there are pruned nodes.
292 2016-12-22 19:51:32	0|luke-jr|but it's mostly the same problem as IBD for new users
293 2016-12-22 19:51:33	0|sipa|luke-jr: also, pruning is now stable... ideally we eon't require people to redownload to uograde a pruned node
294 2016-12-22 19:51:38	0|luke-jr|true re pruning
295 2016-12-22 19:52:06	0|sipa|anyway, i believe upgrading is theoretically possible, but it's not trivial (chainstate and undo files need processing)
296 2016-12-22 19:52:18	0|gmaxwell|I guess thats an interesting point to bring up: we've found the current wipe behavior is hard to beat, many things we tried that preserved entries were slightly _slower_. It appears that reading is fast and the caches improvement comes largely from preventing writes.
297 2016-12-22 19:52:25	0|luke-jr|upgrading is also consensus-critical, so it will be important to test it well
298 2016-12-22 19:52:41	0|sipa|luke-jr: agree, which is the annoying part
299 2016-12-22 19:54:54	0|gmaxwell|Okay. nothing else?
300 2016-12-22 19:54:59	0|luke-jr|5 minutes left.
301 2016-12-22 19:55:42	0|gmaxwell|okay. I think we can end early. Happy holidays everyone! and if you're travling, travel safely.
302 2016-12-22 19:55:59	0|luke-jr|^ +1
303 2016-12-22 19:56:04	0|gmaxwell|#endmeetingItDoesntMatterHowWeSpellItBecauseTheBotIsntHere
304 2016-12-22 19:56:24	0|luke-jr|it will matter when the log is replayed to the bot? :P
305 2016-12-22 19:56:29	0|gmaxwell|#endmeeting
306 2016-12-22 19:56:31	0|roasbeef|as is now, one wouldn't be able to use getblocktxn to fetch the transactions from blocks further than 10 blocks deep afaict
307 2016-12-22 19:56:36	0|roasbeef|will that policy be lifted?
308 2016-12-22 19:56:42	0|jonasschnelli|thanks gmaxwell for hosting.
309 2016-12-22 19:57:05	0|roasbeef|in lightning we'd have another use for it as the outpoints for chanenls are currently communicated using 8bytes the details the blockheight+txindex+txout
310 2016-12-22 19:57:07	0|phantomcircuit|roasbeef, why?
311 2016-12-22 19:57:14	0|gmaxwell|roasbeef: we're not even talking about getblocktxn itself there-- codeshark needs something that returns membership proofs and not just entries.
312 2016-12-22 19:57:41	0|gmaxwell|If there is a utility to making getblocktxn go further back, I think that could be discussed.
313 2016-12-22 19:57:57	0|luke-jr|oh, are we meeting next week?
314 2016-12-22 19:58:27	0|luke-jr|it's not a particularly relevant day in of itself, but it's during Christmas, and many people are probably still doing stuff?
315 2016-12-22 19:58:51	0|gmaxwell|In _general_ we've tried to be conservative about p2p methods that give remote hosts random access to the blockchain; they tend to be DOS vectors (random IO on a 100GB working set) and encourage abuse of the system ("blockchain FUSE module").
316 2016-12-22 19:59:37	0|gmaxwell|Wladimir won't be here for a meeting next week, but I believe I'm willing and able.  A lot of people will be out.
317 2016-12-22 20:00:03	0|CodeShark|I've done my traveling for the year already - I'm enjoying some time at home now, so I'll be around :)
318 2016-12-22 20:00:34	0|luke-jr|I can probably be here if we have a meeting, but if a lot of people will be out it may make more sense to just cancel
319 2016-12-22 20:01:08	0|gmaxwell|Okay, lets cancel it then. It isn't like were aren't talking here all the time in any case.
320 2016-12-22 20:01:11	0|sipa|i'll be at 33c3 for next meeting
321 2016-12-22 20:01:36	0|gmaxwell|roasbeef: so you should consider the current limitation on getblocktxn mostly a product of "existing uses had no need for more, and in principle we want to be conservative with this kind of query." rather than any specific need to not permit it.
322 2016-12-22 20:01:47	0|waxwing|sipa: are you giving a talk?
323 2016-12-22 20:01:51	0|sipa|waxwing: no
324 2016-12-22 20:02:11	0|waxwing|sipa: i think they have a Lightning round or something .. insert pun here :)
325 2016-12-22 20:02:19	0|bitcoin-git|[13bitcoin] 15jonasschnelli opened pull request #9408: Allow shutdown during LoadMempool, dump only when necessary (06master...062016/12/memp_dump) 02https://github.com/bitcoin/bitcoin/pull/9408
326 2016-12-22 20:04:17	0|gmaxwell|jonasschnelli: so why can't we repopulate the keypool during SyncTx ?
327 2016-12-22 20:04:31	0|jonasschnelli|it would require an unlock
328 2016-12-22 20:04:40	0|jonasschnelli|(in case of encrypted wallets)
329 2016-12-22 20:04:47	0|jonasschnelli|non-encrypted wallets, fine.
330 2016-12-22 20:04:48	0|gmaxwell|... but what if it is already unlocked?
331 2016-12-22 20:04:55	0|jonasschnelli|Then we could.
332 2016-12-22 20:05:08	0|jonasschnelli|We should do this,... but we can't leave the locked wallets in the dark.
333 2016-12-22 20:05:18	0|gmaxwell|we should do that, then making the rescan work is simply a matter of "unlock first, then rescan"-- not ideal but at least there is a procedure.
334 2016-12-22 20:06:15	0|gmaxwell|Once that works the way to handle rescan is to check if an unlock would be needed and pause the rescan until unlocked. (and in the GUI pop up the password dialog at that point)
335 2016-12-22 20:06:17	0|jonasschnelli|The problem is that there is no interruption point during SyncTx and currently no way to give user a feedback on that level
336 2016-12-22 20:06:32	0|jonasschnelli|Yes. Agree, something like that would be great
337 2016-12-22 20:06:44	0|jonasschnelli|Also, we need to define the gap limit.
338 2016-12-22 20:06:47	0|gmaxwell|Yes, but for rescan we can prompt to unlock before the keypool is empty.
339 2016-12-22 20:06:50	0|jonasschnelli|Which I rather select very high.
340 2016-12-22 20:07:17	0|gmaxwell|well thats just the keypool size. Which I think we should increase to at least 1000, I just haven't pressed for that because we haven't done the chainsplit and privkey on demand changes.
341 2016-12-22 20:07:49	0|jonasschnelli|Yes. 1000 seems to be sane.
342 2016-12-22 20:08:16	0|jonasschnelli|This would be very handy for HD rescans https://github.com/bitcoin/bitcoin/pull/7061
343 2016-12-22 20:08:28	0|jonasschnelli|You don't want to rescan down to genesis
344 2016-12-22 20:08:31	0|jonasschnelli|HD was introduces in 0.13
345 2016-12-22 20:08:48	0|jonasschnelli|Well,.. at least you should have an option to not go down to genesis
346 2016-12-22 20:09:09	0|jonasschnelli|Also, -rescan has no user feedback options, RPC rescan would allow that
347 2016-12-22 20:10:04	0|gmaxwell|I somewhat think that -rescan should be removed in favor of rpc / UI rescan.
348 2016-12-22 20:10:28	0|jonasschnelli|Yes. But most of the others where against that. Well,... pre HD though.
349 2016-12-22 20:10:57	0|gmaxwell|oh? okay. I missed or blissfully forgot that discussion.
350 2016-12-22 20:11:11	0|gmaxwell|We have too many parameters IMO and should constantly look for ones to remove.
351 2016-12-22 20:12:08	0|jonasschnelli|Yes.
352 2016-12-22 20:12:44	0|gmaxwell|rescan rpc could check if the wallet would need to be unlocked (is a locked HD wallet) and return an error, perhaps even have an override if you want to rescan without unlocking (e.g. if your keypool is already big enough)
353 2016-12-22 20:12:59	0|jonasschnelli|Yes.
354 2016-12-22 20:13:07	0|jonasschnelli|Also, we need to be carefull about the lock timeout. :)
355 2016-12-22 20:13:21	0|gmaxwell|I was thinking that perhaps the rescan should just block the timeout.
356 2016-12-22 20:13:50	0|gmaxwell|Though all this talk of rescans makes me feel dirty. Rescans are already a hack, (largely) incompatible with pruning, and unacceptably slow.
357 2016-12-22 20:13:59	0|jonasschnelli|Yes. Just careful to not leave the wallet unlocked in case of en error/execption
358 2016-12-22 20:14:18	0|jonasschnelli|gmaxwell: yes. UTXO rescan should be an alternative
359 2016-12-22 20:14:29	0|jonasschnelli|If you have pruned, you maybe just want to kick out your funds to a new addr.
360 2016-12-22 20:14:42	0|jonasschnelli|(and don't care about tx hist)
361 2016-12-22 20:14:44	0|gmaxwell|yes, though it isn't a good alternative either, because it leaves the wallet in a weird state where it doesn't know the history and doesn't know it doesn't know the history.
362 2016-12-22 20:15:15	0|jonasschnelli|Thats true. But IMO the only option if you prune.
363 2016-12-22 20:15:23	0|jonasschnelli|Execpt your willing to re-download
364 2016-12-22 20:15:30	0|gmaxwell|meaning you might do that with a wallet, then six months later forget that you did that, and then make errors that get you in trouble as a result.
365 2016-12-22 20:15:54	0|gmaxwell|jonasschnelli: sure but we could do better with the UI/RPC to make it clear that the wallet doesn't know the history before a particular point.
366 2016-12-22 20:16:09	0|jonasschnelli|Yes. That's possible.
367 2016-12-22 20:16:15	0|gmaxwell|We can define a "pruned wallet"  this is a wallet that only knows transactions up to height X,  and knows all its coins.
368 2016-12-22 20:16:19	0|jonasschnelli|Add something in getwalletinfo, ... add something to the UI
369 2016-12-22 20:16:50	0|jonasschnelli|Yes. We should do that.
370 2016-12-22 20:17:04	0|gmaxwell|And then when you want to use the utxo scanning you have to convert your wallet to a pruned wallet.  And the UI would show at the earliest position in the tx list  ---- history before block X not shown due to wallet pruning ----
371 2016-12-22 20:17:12	0|jonasschnelli|Not sure if we get this into 0.14. Xmas, then feature freeze is close.
372 2016-12-22 20:17:35	0|gmaxwell|and likewise rpc could show a dummy transaction in position 0 to indicate the same thing.
373 2016-12-22 20:17:40	0|jonasschnelli|Yes. I like that.
374 2016-12-22 20:17:59	0|jonasschnelli|Yes. The dummy transaction might work. But careful to not break API consumers.
375 2016-12-22 20:18:10	0|jonasschnelli|Otherwise just getwalletinfo
376 2016-12-22 20:18:13	0|gmaxwell|And anyone could prune an existing wallet... which would probably make a lot of commercial users happy when they've ended up with 500 MB transactions.
377 2016-12-22 20:18:30	0|jonasschnelli|heh. Yes. Ask jouke_ . :)
378 2016-12-22 20:18:34	0|gmaxwell|yea, you're right. better to not do the dummy... just an info field.
379 2016-12-22 20:18:39	0|gmaxwell|er 500 MB wallets.
380 2016-12-22 20:19:23	0|gmaxwell|in any case, this would give a rational way to handle these partial imports that wouldn't result in any surprises.
381 2016-12-22 20:19:35	0|gmaxwell|and "unpruning" a wallet would require a rescan.
382 2016-12-22 20:20:01	0|jonasschnelli|Right. You could switch back anytime.
383 2016-12-22 20:20:09	0|gmaxwell|I dunno if we could do this for 0.14-- some things might be somewhat hard to handle completely, e.g. conflict tracking.
384 2016-12-22 20:20:10	0|jonasschnelli|We could use the auxiliary block requests here
385 2016-12-22 20:20:39	0|jonasschnelli|In case we don't want the re-validate the historical stuff before pruning basepoint. Though, meh.
386 2016-12-22 20:20:52	0|gmaxwell|I don't think we care about revalidating, we already validated it once.
387 2016-12-22 20:21:28	0|jonasschnelli|https://github.com/bitcoin/bitcoin/pull/9171 works pretty neat.
388 2016-12-22 20:21:35	0|jonasschnelli|Includes RPC tests, etc.
389 2016-12-22 20:22:02	0|jonasschnelli|I tried to slice something out that could have reasons to be independent from the rest of the "SPV" work.
390 2016-12-22 20:22:37	0|jonasschnelli|There is also an short explanation https://github.com/bitcoin/bitcoin/pull/9171#issuecomment-267616678 how it work
391 2016-12-22 20:22:53	0|jonasschnelli|Ideal for pruned-wallet to full-wallet
392 2016-12-22 20:24:49	0|jonasschnelli|I'd also like gmaxwell, and sipa comment on luke-jr comment (https://github.com/bitcoin/bitcoin/pull/9294#discussion_r93689481)
393 2016-12-22 20:24:55	0|jonasschnelli|This is a fine-adjustment thing.
394 2016-12-22 20:25:08	0|jonasschnelli|I kinda agree with luke-jr
395 2016-12-22 20:25:31	0|jonasschnelli|though, if you set a keypool to 100, you probably don't 100 external keys + some internal keys.
396 2016-12-22 20:25:39	0|jonasschnelli|*don't expect
397 2016-12-22 20:38:56	0|luke-jr|I would expect 100 external + 100 internal
398 2016-12-22 20:40:49	0|sipa|internal can be 5 or so
399 2016-12-22 20:41:00	0|sipa|as change addresses are always used immediately
400 2016-12-22 20:41:05	0|sipa|and don't depend on other people
401 2016-12-22 20:41:21	0|sipa|though i guess it does not matter much
402 2016-12-22 20:41:39	0|sipa|agree that keypool=X should mean external keypool
403 2016-12-22 20:42:08	0|jonasschnelli|sipa: thanks for the feedback. Yes. Let me then change that.
404 2016-12-22 20:42:41	0|jonasschnelli|It might surprise heave getrawchangeaddress users (in conjunction with enctypted wallets).
405 2016-12-22 20:42:54	0|jonasschnelli|But I guess these are adge cases.
406 2016-12-22 20:43:03	0|jonasschnelli|Clear release notes may help there
407 2016-12-22 20:43:18	0|jonasschnelli|*heavy getrawchangeaddress users
408 2016-12-22 20:43:20	0|luke-jr|oh right, forgot it was HD >_<
409 2016-12-22 20:43:47	0|luke-jr|sipa: however, your change might not get mined in order?
410 2016-12-22 20:45:08	0|jonasschnelli|dropping out, influenza sick.
411 2016-12-22 20:45:56	0|luke-jr|jonasschnelli: ☹ get well soon
412 2016-12-22 20:46:26	0|morcos|Hey..  sorry I missed the meeting, and yes please review #9138, but I do have something else that I think is of high priority for 0.14
413 2016-12-22 20:46:28	0|gribble|https://github.com/bitcoin/bitcoin/issues/9138 | Improve fee estimation by morcos · Pull Request #9138 · bitcoin/bitcoin · GitHub
414 2016-12-22 20:46:51	0|morcos|BlueMatt: you mentioned #9375 will help propagation speed, but thats not necessarily true
415 2016-12-22 20:46:52	0|gribble|https://github.com/bitcoin/bitcoin/issues/9375 | Relay compact block messages prior to full block connection by TheBlueMatt · Pull Request #9375 · bitcoin/bitcoin · GitHub
416 2016-12-22 20:47:08	0|morcos|as long as we have these nodes that send headers very fast and then delay sending us the block
417 2016-12-22 20:47:29	0|morcos|9375 is insufficient.  i've been trying to test with it and find myself stymied by that problem.
418 2016-12-22 20:47:54	0|morcos|i think even more important than parallel ProcessMessages is the ability to intelligently have more than one block request (of some form) out at the same time
419 2016-12-22 20:48:19	0|morcos|I've been talkign about it with instagibbs, and have in my mind an outline of an idea.. but not 100% clear how to cleanly implement
420 2016-12-22 20:48:46	0|morcos|i think we'll want to be able to have more than 1 (probably 2 is sufficient) PartiallyDownloaded blocks in progress at the same time
421 2016-12-22 20:49:34	0|phantomcircuit|morcos, i dont think you want to have requests out for full blocks in parallel
422 2016-12-22 20:49:36	0|phantomcircuit|just sketches
423 2016-12-22 20:50:54	0|morcos|phantomcircuit: agreed, in short my idea is only if you have no outstanding request will you request a full block
424 2016-12-22 20:52:13	0|morcos|regardless of that, until you have 2 blocktxn requests outstanding, you'll request cmpctblocks from headers or blocktxns from cmpctblocks
425 2016-12-22 20:52:35	0|morcos|or roughly something like that...
426 2016-12-22 20:56:44	0|morcos|sdaftuar also ping on above when you get a chance ^
427 2016-12-22 22:20:12	0|BlueMatt|morcos: yes, initially I had thought that I should avoid PR'ing that until we had parallel process messages for that reason
428 2016-12-22 22:20:29	0|BlueMatt|morcos: however, the caching that that PR does will, by itself, fix a ton of the issues with being slow to send the block
429 2016-12-22 22:20:50	0|BlueMatt|indeed, not entirely, but somewhat
430 2016-12-22 22:21:00	0|BlueMatt|having parallel processmessages should fix much of the test
431 2016-12-22 22:21:52	0|BlueMatt|s/test/rest/
432 2016-12-22 22:25:26	0|gmaxwell|why is reading a block from disk so slow?
433 2016-12-22 22:25:40	0|gmaxwell|no doubt thats part of the reason that rescan is insanely slow.
434 2016-12-22 22:25:41	0|BlueMatt|IIRC we check the merkle tree on it
435 2016-12-22 22:25:56	0|gmaxwell|can we like.. not do that sometimes?
436 2016-12-22 22:26:08	0|BlueMatt|we may no longer
437 2016-12-22 22:26:12	0|BlueMatt|we used to...like 2 years ago
438 2016-12-22 22:26:31	0|BlueMatt|no, nvm, just CheckProofOfWork now
439 2016-12-22 22:27:55	0|BlueMatt|anyway, its slow because deserialize, I'd bet, but havent benchmarked deserialize + build compact block/blocktxn response
440 2016-12-22 22:30:11	0|gmaxwell|well I wouldn't be surprised if it was the deseralize, we know that rescan is quite slow.. but I don't know why.
441 2016-12-22 22:31:08	0|BlueMatt|there's a bench_bitcoin thing for deserialize and deserialize + CheckBlock
442 2016-12-22 22:31:10	0|BlueMatt|its like 10ms
443 2016-12-22 22:31:17	0|BlueMatt|or so
444 2016-12-22 22:31:28	0|BlueMatt|so not incredibly slow, but also definitely not fast
445 2016-12-22 22:32:03	0|sipa|i assume the deserialization is the slowest part
446 2016-12-22 22:32:22	0|BlueMatt|I believe that was the case when i checked
447 2016-12-22 22:34:01	0|gmaxwell|well 10ms * 100 peers is much of the slow results you were reporting.  I think you were saying lightsword was seeing 2 second service times?