1 2017-09-21T00:07:07  *** duringo has joined #bitcoin-core-dev
  2 2017-09-21T00:10:35  *** duringo_ has quit IRC
  3 2017-09-21T00:21:39  <bitcoin-git> [bitcoin] TheBlueMatt opened pull request #11377: Disallow uncompressed pubkeys in bitcoin-tx [multisig] output adds (master...2017-09-bitcoin-tx-uncompressed-segwit) https://github.com/bitcoin/bitcoin/pull/11377
  4 2017-09-21T00:30:22  *** goatpig has quit IRC
  5 2017-09-21T00:43:24  <phantomcircuit> gmaxwell, why wouldn't it work?
  6 2017-09-21T00:43:29  <phantomcircuit> it's just slowish
  7 2017-09-21T00:54:37  *** Ylbam has quit IRC
  8 2017-09-21T00:58:57  <bitcoin-git> [bitcoin] btc1-prevention opened pull request #11378: Update COPYING (master...patch-1) https://github.com/bitcoin/bitcoin/pull/11378
  9 2017-09-21T01:01:09  *** dabura667 has joined #bitcoin-core-dev
 10 2017-09-21T01:02:28  *** JackH has quit IRC
 11 2017-09-21T01:15:47  <bitcoin-git> [bitcoin] fanquake closed pull request #11378: Update COPYING (master...patch-1) https://github.com/bitcoin/bitcoin/pull/11378
 12 2017-09-21T01:17:58  *** promag has joined #bitcoin-core-dev
 13 2017-09-21T01:22:05  *** promag has quit IRC
 14 2017-09-21T01:26:36  *** StopAndDecrypty is now known as StopAndDecrypt
 15 2017-09-21T01:45:36  *** Miezel has joined #bitcoin-core-dev
 16 2017-09-21T01:51:49  *** RubenSomsen has joined #bitcoin-core-dev
 17 2017-09-21T01:56:21  *** thrasher` has quit IRC
 18 2017-09-21T01:58:57  *** thrasher` has joined #bitcoin-core-dev
 19 2017-09-21T01:59:46  *** AaronvanW has quit IRC
 20 2017-09-21T02:05:06  *** AaronvanW has joined #bitcoin-core-dev
 21 2017-09-21T02:20:21  *** justanotheruser has joined #bitcoin-core-dev
 22 2017-09-21T02:25:01  *** rosenfs_ has quit IRC
 23 2017-09-21T02:25:14  *** tknp has quit IRC
 24 2017-09-21T02:45:55  *** JackH has joined #bitcoin-core-dev
 25 2017-09-21T02:48:17  *** Giszmo has quit IRC
 26 2017-09-21T02:48:42  *** harrymm has quit IRC
 27 2017-09-21T02:50:19  *** harrymm has joined #bitcoin-core-dev
 28 2017-09-21T02:51:35  *** harrymm1 has quit IRC
 29 2017-09-21T02:52:13  *** harrymm_ has joined #bitcoin-core-dev
 30 2017-09-21T02:53:26  *** harrymm_ has left #bitcoin-core-dev
 31 2017-09-21T03:16:54  <meshcollider> Is anything in the share/certs/ directory actually relevant anymore? Seems pretty outdated
 32 2017-09-21T03:21:09  <achow101> meshcollider: yes, that's information about the codesigning certs
 33 2017-09-21T03:22:01  *** d9b4bef9 has quit IRC
 34 2017-09-21T03:22:38  <achow101> the threat mitigation part is outdated I think because of the detached sigs thing. the codesigned binaries are now gitian built
 35 2017-09-21T03:23:08  *** d9b4bef9 has joined #bitcoin-core-dev
 36 2017-09-21T03:29:48  <kallewoof> Would it be worth it to add a replay protection mechanism in Bitcoin where a NOP is replaced with <height> <blockhash> OP_CHECKBLOCKVERIFY which would fail if the hash of the block at the given height did not match <blockhash>? (It would probably require that <height> was less than <current height> - 100 to avoid nasty double spends at reorgs...)
 37 2017-09-21T03:31:24  <kallewoof> Actually, I don't think that would solve anything, since old UTXOs would still be replayed, just unspendable. Nevermind.
 38 2017-09-21T03:33:53  *** justanotheruser has quit IRC
 39 2017-09-21T03:36:12  <achow101> meshcollider: well I suppose the keys there are outdated as it looks like the codesigned stuff uses a more recent cert
 40 2017-09-21T03:36:29  <achow101> cfields: would you mind updating that? or do you think it should be removed entirely?
 41 2017-09-21T03:37:23  <meshcollider> achow101: yeah that's what I thought, this is stuff from 5 years ago
 42 2017-09-21T03:38:51  <achow101> meshcollider: the keys there are expired too
 43 2017-09-21T03:44:17  <cfields> achow101: yea, i think it can just be removed. The signing process is documented (and scripted)
 44 2017-09-21T03:44:31  <achow101> cfields: where is it documented?
 45 2017-09-21T03:44:53  <cfields> achow101: in the gitian build instructions
 46 2017-09-21T03:45:19  <achow101> oh I see.
 47 2017-09-21T03:45:29  <achow101> where is this script: detached-sig-create.sh?
 48 2017-09-21T03:45:33  <achow101> I only see one for osx
 49 2017-09-21T03:45:35  <bitcoin-git> [bitcoin] MeshCollider opened pull request #11380: Remove outdated share/certs/ directory (master...201709_remove_old_certs) https://github.com/bitcoin/bitcoin/pull/11380
 50 2017-09-21T03:45:44  <achow101> and not one for windows
 51 2017-09-21T03:45:45  <cfields> I've helped a few other projects (litecoin, for ex), build using our process. The last one (i forget who, now) was able to sign without my assistance.
 52 2017-09-21T03:45:57  *** RubenSomsen has quit IRC
 53 2017-09-21T03:46:40  <cfields> hmm, we have one for windows as of 0.15. surely i updated the instructions for it. Checking.
 54 2017-09-21T03:47:26  <cfields> (the script/cert are in contrib/windeploy )
 55 2017-09-21T03:47:40  <achow101> ah, I see it now.
 56 2017-09-21T03:47:50  <achow101> missed that earlier
 57 2017-09-21T03:48:34  <achow101> no certs for osx? (I don't see any in macdeploy)
 58 2017-09-21T03:48:38  <cfields> well, there aren't instructions in that gitian doc like i thought there were. Will add.
 59 2017-09-21T03:49:23  <achow101> the gitian doc has instructions for running the scripts
 60 2017-09-21T03:49:34  <achow101> err the release process doc
 61 2017-09-21T03:49:36  <meshcollider> cfields: might be in the release process doc
 62 2017-09-21T03:50:25  <cfields> no, I got distracted from finishing the osx tool, so committed osx certs can't be used yet
 63 2017-09-21T03:50:32  <cfields> ah, maybe that's it
 64 2017-09-21T03:50:49  *** justanotheruser has joined #bitcoin-core-dev
 65 2017-09-21T03:51:18  <cfields> anyway, gitian spits out "*unsigned.tar.gz", which the signer just untars and runs ./detached-sig-create.sh. Very straigtforward.
 66 2017-09-21T03:51:31  <cfields> but if it's not fully written up, I can do so
 67 2017-09-21T03:52:00  *** ghost43 has quit IRC
 68 2017-09-21T03:52:05  <achow101> it's written up here: https://github.com/bitcoin/bitcoin/blob/master/doc/release-process.md#next-steps
 69 2017-09-21T03:52:12  *** RubenSomsen has joined #bitcoin-core-dev
 70 2017-09-21T03:52:29  *** ghost43 has joined #bitcoin-core-dev
 71 2017-09-21T03:52:31  <achow101> why are there 3 certs in win-codesign.cert?
 72 2017-09-21T03:52:46  <achow101> oh, 2 are comodo's and one is ours
 73 2017-09-21T03:52:48  <cfields> yea, there we go
 74 2017-09-21T03:52:58  <cfields> yea, it's the whole chain
 75 2017-09-21T03:53:45  <achow101> Is the osx one the same as the one in share/certs?
 76 2017-09-21T03:53:50  <achow101> it expires in 2018
 77 2017-09-21T03:55:14  <cfields> probably so
 78 2017-09-21T03:55:43  <meshcollider> so they should be moved instead of removed?
 79 2017-09-21T03:56:16  <achow101> meshcollider: the windows one should be removed
 80 2017-09-21T03:56:34  <achow101> don't know about the osx one, but it probably can't be used with the osx script provided in contrib/macdeploy
 81 2017-09-21T03:56:50  <achow101> (I don't have a mac to check if the signature matches that cert)
 82 2017-09-21T03:57:01  <cfields> the stuff in share/certs is informational only, it isn't used atm
 83 2017-09-21T03:57:31  <cfields> the windows certs in contrib/windeploy are actually used by the signing/re-attaching process
 84 2017-09-21T03:58:19  <cfields> the cert chain could be ripped out of an osx binary with some hacking (or maybe there's a tool for it?)
 85 2017-09-21T03:59:34  <achow101> cfields: is there some way to check the detached sigs?
 86 2017-09-21T04:00:06  <cfields> what do you mean by check?
 87 2017-09-21T04:00:29  <achow101> like extract the chain out of them
 88 2017-09-21T04:00:43  <achow101> or see if they verify to that cert
 89 2017-09-21T04:02:35  *** RubenSomsen has quit IRC
 90 2017-09-21T04:03:21  <cfields> checking
 91 2017-09-21T04:10:57  <cfields> the binary contains the same localKeyID as the committed .pem
 92 2017-09-21T04:12:06  <achow101> ok, thanks
 93 2017-09-21T04:12:29  <achow101> I wonder if gavin made bitcoin xt or bitcoin classic releases signed with that key...
 94 2017-09-21T04:14:52  <cfields> not afaik
 95 2017-09-21T04:15:31  <cfields> fwiw: https://pastebin.com/raw/UZKRpdPc
 96 2017-09-21T04:15:31  <achow101> I assume that he isn't stupid enough to do that
 97 2017-09-21T04:15:47  <cfields> anyone on osx can reproduce ^^
 98 2017-09-21T04:16:09  <achow101> is codesign some osx utility?
 99 2017-09-21T04:16:34  <cfields> yea
100 2017-09-21T04:17:22  *** tknp has joined #bitcoin-core-dev
101 2017-09-21T04:17:23  <cfields> i patched an ios tool to do osx signing a while ago. It's 99% ready, just never finished it/hooked it up
102 2017-09-21T04:18:03  <cfields> https://github.com/theuni/osx-codesign
103 2017-09-21T04:19:04  <achow101> why?
104 2017-09-21T04:19:05  * luke-jr wonders how hard it would be to get iOS and Android builds of the GUI
105 2017-09-21T04:19:05  *** RubenSomsen has joined #bitcoin-core-dev
106 2017-09-21T04:19:27  <achow101> luke-jr: supposedly qt supports android in some way
107 2017-09-21T04:19:41  <cfields> achow101: why what?
108 2017-09-21T04:19:52  <luke-jr> achow101: yes, or I wouldn't even consider it a possibility :p
109 2017-09-21T04:20:23  <luke-jr> (it also supports iOS)
110 2017-09-21T04:20:24  <achow101> cfields: why did you make an osx signing tool if there already is one?
111 2017-09-21T04:20:41  <achow101> (the one existing being whatever is used now)
112 2017-09-21T04:20:52  <achow101> luke-jr: it does?
113 2017-09-21T04:20:57  <luke-jr> achow101: yes
114 2017-09-21T04:21:01  <luke-jr> http://doc.qt.io/qt-5/ios-support.html
115 2017-09-21T04:21:12  <cfields> achow101: oh, sorry. portable tool. Works from Linux.
116 2017-09-21T04:22:04  <achow101> cfields: ah. ok. I figured it was probably also that it is open source
117 2017-09-21T04:22:27  <cfields> achow101: well most (all?) of osx userspace is open-source. It's just a tangled web.
118 2017-09-21T04:23:17  <luke-jr> cfields: pretty sure the GUI stuff isn't?
119 2017-09-21T04:24:06  <cfields> luke-jr: that would make sense
120 2017-09-21T04:29:04  <meshcollider> luke-jr: that can't even be considered until SPV mode is added though right, no way android is going to run Qt with even a pruned blockchain and full UTXO set lol
121 2017-09-21T04:31:23  <achow101> meshcollider: it can run bitcoind
122 2017-09-21T04:31:29  <achow101> look up ABCore
123 2017-09-21T04:32:12  <achow101> and android devices (smartphones in general) are getting more powerful and have more ram
124 2017-09-21T04:32:23  <cfields> meshcollider: no reason why it should be less performant than gnu/linux on an arm machine
125 2017-09-21T04:35:08  <meshcollider> hmm that's true, I've just never even considered trying to run a full node on a smartphone
126 2017-09-21T04:35:40  <meshcollider> that's an interesting idea
127 2017-09-21T05:00:41  *** tknp has quit IRC
128 2017-09-21T05:23:20  *** ghost43 has quit IRC
129 2017-09-21T05:23:33  *** ghost43 has joined #bitcoin-core-dev
130 2017-09-21T05:58:56  *** PRab has quit IRC
131 2017-09-21T06:05:12  *** PRab has joined #bitcoin-core-dev
132 2017-09-21T06:22:26  *** dcousens has joined #bitcoin-core-dev
133 2017-09-21T06:39:32  *** promag has joined #bitcoin-core-dev
134 2017-09-21T06:42:34  *** promag has quit IRC
135 2017-09-21T06:48:12  *** BashCo has quit IRC
136 2017-09-21T07:05:48  *** afk11 has quit IRC
137 2017-09-21T07:07:21  *** afk11 has joined #bitcoin-core-dev
138 2017-09-21T07:09:50  *** ThomasV has joined #bitcoin-core-dev
139 2017-09-21T07:11:09  *** promag has joined #bitcoin-core-dev
140 2017-09-21T07:12:03  *** BashCo has joined #bitcoin-core-dev
141 2017-09-21T07:15:58  *** promag has quit IRC
142 2017-09-21T07:16:11  *** ThomasV has quit IRC
143 2017-09-21T07:19:06  *** LeMiner2 has joined #bitcoin-core-dev
144 2017-09-21T07:21:36  *** LeMiner has quit IRC
145 2017-09-21T07:21:36  *** LeMiner2 is now known as LeMiner
146 2017-09-21T07:37:47  *** ThomasV has joined #bitcoin-core-dev
147 2017-09-21T08:09:40  *** SopaXorzTaker has joined #bitcoin-core-dev
148 2017-09-21T08:12:08  *** privateglacier has joined #bitcoin-core-dev
149 2017-09-21T08:13:20  *** timothy has joined #bitcoin-core-dev
150 2017-09-21T08:24:04  *** alreadylate has joined #bitcoin-core-dev
151 2017-09-21T08:31:43  *** AaronvanW has quit IRC
152 2017-09-21T08:33:55  *** AaronvanW has joined #bitcoin-core-dev
153 2017-09-21T08:34:35  *** paveljanik has joined #bitcoin-core-dev
154 2017-09-21T08:34:40  *** paveljanik has joined #bitcoin-core-dev
155 2017-09-21T08:35:11  *** Aaronvan_ has joined #bitcoin-core-dev
156 2017-09-21T08:38:23  *** AaronvanW has quit IRC
157 2017-09-21T08:38:43  <esotericnonsense> my smartphone is multiple years old and is more powerful than many machines i've synced a node from
158 2017-09-21T08:39:53  <esotericnonsense> much better than a raspberry pi anyway :)\
159 2017-09-21T08:40:26  *** promag has joined #bitcoin-core-dev
160 2017-09-21T08:41:27  *** Aaronvan_ has quit IRC
161 2017-09-21T08:44:36  *** promag has quit IRC
162 2017-09-21T08:46:39  *** privateglacier has quit IRC
163 2017-09-21T08:56:44  *** promag has joined #bitcoin-core-dev
164 2017-09-21T09:06:13  *** ula has quit IRC
165 2017-09-21T09:07:43  *** Geoffy has joined #bitcoin-core-dev
166 2017-09-21T09:15:23  *** sdfgsdfg_ has joined #bitcoin-core-dev
167 2017-09-21T09:15:33  *** Miezel has quit IRC
168 2017-09-21T09:16:39  <sdfgsdfg_> ohio, how much until LN is tested on mainnet ?
169 2017-09-21T09:16:53  *** Miezel has joined #bitcoin-core-dev
170 2017-09-21T09:37:11  <kallewoof> Someone wrote a post about that on reddit. One of the devs said two weeks I think. (LN is actually not bitcoin core, but a separate client entirely.)
171 2017-09-21T09:41:18  *** Miezel has quit IRC
172 2017-09-21T09:46:13  <meshcollider> link: https://www.reddit.com/r/Bitcoin/comments/714x2k/what_is_the_status_of_the_lightning_network/dn8docc/
173 2017-09-21T09:50:44  <promag> wumpus: is there a thread pool for RPC handling?
174 2017-09-21T10:01:12  *** dabura667 has quit IRC
175 2017-09-21T10:19:27  *** RubenSomsen has quit IRC
176 2017-09-21T10:25:29  *** promag has quit IRC
177 2017-09-21T10:28:25  *** promag has joined #bitcoin-core-dev
178 2017-09-21T10:30:28  *** sdfgsdfg_ has quit IRC
179 2017-09-21T10:33:23  *** sdfgsdfg has joined #bitcoin-core-dev
180 2017-09-21T10:38:24  *** ThomasV has quit IRC
181 2017-09-21T10:43:30  *** promag has quit IRC
182 2017-09-21T10:47:33  *** RubenSomsen has joined #bitcoin-core-dev
183 2017-09-21T11:07:22  *** ThomasV has joined #bitcoin-core-dev
184 2017-09-21T11:29:17  *** NielsvG has joined #bitcoin-core-dev
185 2017-09-21T11:30:05  *** ThomasV has quit IRC
186 2017-09-21T11:30:51  *** m8tion has joined #bitcoin-core-dev
187 2017-09-21T11:36:20  *** goatpig has joined #bitcoin-core-dev
188 2017-09-21T11:41:41  *** duringo has joined #bitcoin-core-dev
189 2017-09-21T11:52:10  *** promag has joined #bitcoin-core-dev
190 2017-09-21T11:52:17  *** duringo has quit IRC
191 2017-09-21T12:05:33  *** arubi has quit IRC
192 2017-09-21T12:05:33  *** dermoth has quit IRC
193 2017-09-21T12:05:33  *** intcat has quit IRC
194 2017-09-21T12:05:33  *** ghost43 has quit IRC
195 2017-09-21T12:05:33  *** afk11 has quit IRC
196 2017-09-21T12:13:54  *** SopaXorzTaker has quit IRC
197 2017-09-21T12:15:36  *** SopaXorzTaker has joined #bitcoin-core-dev
198 2017-09-21T12:21:37  *** laurentmt has joined #bitcoin-core-dev
199 2017-09-21T12:29:14  *** ThomasV has joined #bitcoin-core-dev
200 2017-09-21T12:32:38  *** duringo has joined #bitcoin-core-dev
201 2017-09-21T12:37:18  *** ghost43 has joined #bitcoin-core-dev
202 2017-09-21T12:37:20  *** arubi has joined #bitcoin-core-dev
203 2017-09-21T12:37:21  *** afk11 has joined #bitcoin-core-dev
204 2017-09-21T12:37:23  *** intcat has joined #bitcoin-core-dev
205 2017-09-21T12:38:04  *** laurentmt has quit IRC
206 2017-09-21T12:49:02  *** duringo_ has joined #bitcoin-core-dev
207 2017-09-21T12:49:02  *** duringo has quit IRC
208 2017-09-21T12:49:41  *** laurentmt has joined #bitcoin-core-dev
209 2017-09-21T12:49:43  *** laurentmt has quit IRC
210 2017-09-21T12:58:40  *** promag has quit IRC
211 2017-09-21T12:58:57  *** promag has joined #bitcoin-core-dev
212 2017-09-21T13:06:34  *** duringo_ has quit IRC
213 2017-09-21T13:10:10  *** Giszmo has joined #bitcoin-core-dev
214 2017-09-21T13:12:35  *** dermoth has joined #bitcoin-core-dev
215 2017-09-21T13:12:42  *** dcousens has quit IRC
216 2017-09-21T13:14:50  *** dcousens has joined #bitcoin-core-dev
217 2017-09-21T13:17:20  *** Guyver2 has joined #bitcoin-core-dev
218 2017-09-21T13:29:52  *** promag has quit IRC
219 2017-09-21T13:40:00  *** Giszmo has quit IRC
220 2017-09-21T13:45:08  *** promag has joined #bitcoin-core-dev
221 2017-09-21T13:50:15  *** harrymm has quit IRC
222 2017-09-21T13:51:28  *** justanotheruser has quit IRC
223 2017-09-21T13:52:11  *** harrymm has joined #bitcoin-core-dev
224 2017-09-21T13:53:19  *** Giszmo has joined #bitcoin-core-dev
225 2017-09-21T13:55:21  *** alreadylate has quit IRC
226 2017-09-21T13:56:01  *** alreadylate has joined #bitcoin-core-dev
227 2017-09-21T13:59:48  *** RubenSomsen has quit IRC
228 2017-09-21T14:01:36  *** ossifrage has quit IRC
229 2017-09-21T14:08:15  *** alreadylate has quit IRC
230 2017-09-21T14:12:36  *** Miezel has joined #bitcoin-core-dev
231 2017-09-21T14:14:30  *** promag has quit IRC
232 2017-09-21T14:14:40  *** ossifrage has joined #bitcoin-core-dev
233 2017-09-21T14:18:11  *** RubenSomsen has joined #bitcoin-core-dev
234 2017-09-21T14:28:19  *** harrymm has quit IRC
235 2017-09-21T14:29:21  *** dcousens has quit IRC
236 2017-09-21T14:29:41  *** RubenSomsen has quit IRC
237 2017-09-21T14:33:58  *** Geoffy has quit IRC
238 2017-09-21T14:34:58  *** alreadylate has joined #bitcoin-core-dev
239 2017-09-21T14:40:53  *** StopAndDecrypt_ has quit IRC
240 2017-09-21T14:48:54  *** laurentmt has joined #bitcoin-core-dev
241 2017-09-21T14:54:39  *** StopAndDecrypt_ has joined #bitcoin-core-dev
242 2017-09-21T15:00:36  *** laurentmt has quit IRC
243 2017-09-21T15:07:07  *** meshcollider has quit IRC
244 2017-09-21T15:10:50  *** harrymm has joined #bitcoin-core-dev
245 2017-09-21T15:13:44  <bitcoin-git> [bitcoin] aqibbak opened pull request #11381: Update .travis.yml (master...patch-1) https://github.com/bitcoin/bitcoin/pull/11381
246 2017-09-21T15:19:08  *** jtimon has quit IRC
247 2017-09-21T15:19:36  *** Giszmo has quit IRC
248 2017-09-21T15:23:01  *** alreadylate has quit IRC
249 2017-09-21T15:25:51  *** alreadylate has joined #bitcoin-core-dev
250 2017-09-21T15:29:07  *** harrymm has quit IRC
251 2017-09-21T15:30:45  *** harrymm has joined #bitcoin-core-dev
252 2017-09-21T15:34:09  <wumpus> promag: yes, the HTTP worker threads
253 2017-09-21T15:39:48  *** laurentmt has joined #bitcoin-core-dev
254 2017-09-21T15:41:02  *** laurentmt has quit IRC
255 2017-09-21T15:45:08  *** BashCo has quit IRC
256 2017-09-21T15:46:44  *** veleiro has joined #bitcoin-core-dev
257 2017-09-21T15:47:37  *** Giszmo has joined #bitcoin-core-dev
258 2017-09-21T15:48:28  *** Murch has joined #bitcoin-core-dev
259 2017-09-21T15:51:18  *** Murch has quit IRC
260 2017-09-21T16:01:19  *** Geoffy has joined #bitcoin-core-dev
261 2017-09-21T16:15:04  *** promag has joined #bitcoin-core-dev
262 2017-09-21T16:15:49  *** alreadylate has quit IRC
263 2017-09-21T16:19:05  *** promag has quit IRC
264 2017-09-21T16:35:15  *** sdfgsdfg has quit IRC
265 2017-09-21T16:46:32  *** laurentmt has joined #bitcoin-core-dev
266 2017-09-21T16:46:56  *** Giszmo has quit IRC
267 2017-09-21T16:47:49  *** laurentmt has quit IRC
268 2017-09-21T16:49:55  *** BashCo has joined #bitcoin-core-dev
269 2017-09-21T17:03:37  <ossifrage> The 'reindexing blocks on disk...' progress bar flaps around quite a bit, not exactly a stable progress bar
270 2017-09-21T17:05:06  *** Giszmo has joined #bitcoin-core-dev
271 2017-09-21T17:10:47  *** m8tion has quit IRC
272 2017-09-21T17:23:12  *** RubenSomsen has joined #bitcoin-core-dev
273 2017-09-21T17:24:37  <wumpus> at least better than not showing progress at all
274 2017-09-21T17:25:05  <ossifrage> wumpus, yeah it just was flapping between "5 year" and "3 years" behind, which is a bit extreme
275 2017-09-21T17:26:02  <gmaxwell> huh....
276 2017-09-21T17:26:06  <gmaxwell> it shouldn't do that
277 2017-09-21T17:26:18  <ossifrage> I restarted the node with txindex=1
278 2017-09-21T17:26:24  *** Deadhand has quit IRC
279 2017-09-21T17:26:46  <ossifrage> I set dbcache to 4096
280 2017-09-21T17:27:27  *** Ylbam has joined #bitcoin-core-dev
281 2017-09-21T17:27:53  <wumpus> I expect there to be larger variance in the beginning, once it gets to the blocks that are actually filled, it's probably more stable
282 2017-09-21T17:28:41  <ossifrage> I thought the estimate was just based on block count not transaction count?
283 2017-09-21T17:29:12  <sipa> no, it's based on transaction count
284 2017-09-21T17:29:38  *** ThomasV has quit IRC
285 2017-09-21T17:29:50  <ossifrage> Now it is flapping + 1 year
286 2017-09-21T17:30:23  *** Deadhand has joined #bitcoin-core-dev
287 2017-09-21T17:32:16  *** promag has joined #bitcoin-core-dev
288 2017-09-21T17:36:51  *** promag has quit IRC
289 2017-09-21T17:40:02  <wumpus> I've never seen it flapping here, though I must say I haven't ever paid close attention to it, after all it's hardly something you can wait for to complete :)
290 2017-09-21T17:43:33  <ossifrage> Maybe it is specific to reindexing with txindex=1... Oddly it doesn't seem to be io bound or cpu bound (none of the threads consume 100% cpu). Lock contention? Or maybe blocking on fsync()?
291 2017-09-21T17:44:29  <wumpus> that's just in the beginning, it will get cpu bound soon enough
292 2017-09-21T17:45:37  <bitcoin-git> [bitcoin] MarcoFalke closed pull request #11381: Update .travis.yml (master...patch-1) https://github.com/bitcoin/bitcoin/pull/11381
293 2017-09-21T17:46:05  <gmaxwell> if its flaping then it doesn't work like I understood...
294 2017-09-21T17:46:35  *** promag has joined #bitcoin-core-dev
295 2017-09-21T17:48:12  *** timothy has quit IRC
296 2017-09-21T17:48:13  <ossifrage> Both the bar and the text are flapping but the "Progress x%" is counting up smoothly (that must be just block height?)
297 2017-09-21T17:48:18  <wumpus> before it gets to the blocks that require serious validation I expect it's mostly waiting for i/o latency (reading blocks from disk, updating db), interspersed with a bit of cpu use
298 2017-09-21T17:48:19  *** promag has quit IRC
299 2017-09-21T17:48:32  *** promag has joined #bitcoin-core-dev
300 2017-09-21T17:51:59  <wumpus> I don't think it has used block height as a progress measure in the UI since 0.5.x or so
301 2017-09-21T17:53:23  <wumpus> block height is pretty useless for that because it starts off really fast and then slows down more and more
302 2017-09-21T17:53:58  *** promag has quit IRC
303 2017-09-21T18:06:16  *** Murch has joined #bitcoin-core-dev
304 2017-09-21T18:12:35  *** Chris_Stewart_5 has joined #bitcoin-core-dev
305 2017-09-21T18:13:18  *** Giszmo has quit IRC
306 2017-09-21T18:25:32  *** laurentmt has joined #bitcoin-core-dev
307 2017-09-21T18:30:52  *** Giszmo has joined #bitcoin-core-dev
308 2017-09-21T18:38:45  *** laurentmt has quit IRC
309 2017-09-21T18:41:41  *** Chris_Stewart_5 has quit IRC
310 2017-09-21T18:56:30  *** meshcollider has joined #bitcoin-core-dev
311 2017-09-21T18:58:28  *** Chris_Stewart_5 has joined #bitcoin-core-dev
312 2017-09-21T19:00:11  <sipa> meetung?
313 2017-09-21T19:00:26  <wumpus> #startmeeting
314 2017-09-21T19:00:26  <lightningbot> Meeting started Thu Sep 21 19:00:26 2017 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
315 2017-09-21T19:00:26  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
316 2017-09-21T19:00:49  <wumpus> #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 jl2012 achow101
317 2017-09-21T19:00:55  <kanzure> hi.
318 2017-09-21T19:00:59  <sipa> hi.
319 2017-09-21T19:01:04  <meshcollider> hello
320 2017-09-21T19:01:09  <cfields> hi
321 2017-09-21T19:01:24  <sdaftuar> hey
322 2017-09-21T19:01:26  <luke-jr> hi
323 2017-09-21T19:01:42  <jnewbery> hello
324 2017-09-21T19:02:06  <achow101> hi
325 2017-09-21T19:02:17  <wumpus> so PSA: we've released with a single patch #11332, compared to 0.15.0, to solve the qt crash issue for some users
326 2017-09-21T19:02:18  <gribble> https://github.com/bitcoin/bitcoin/issues/11332 | Fix possible crash with invalid nCustomFeeRadio in QSettings (achow101, TheBlueMatt) by jonasschnelli · Pull Request #11332 · bitcoin/bitcoin · GitHub
327 2017-09-21T19:02:26  <sdaftuar> yay
328 2017-09-21T19:02:49  <wumpus> #topic high-priority for review
329 2017-09-21T19:03:10  <achow101> #10871 please?
330 2017-09-21T19:03:12  <gribble> https://github.com/bitcoin/bitcoin/issues/10871 | Handle getinfo in bitcoin-cli w/ -getinfo (revival of #8843) by achow101 · Pull Request #10871 · bitcoin/bitcoin · GitHub
331 2017-09-21T19:03:21  *** Geoffy has quit IRC
332 2017-09-21T19:03:31  <wumpus> I don't think we made much progress on review, this week (me included)
333 2017-09-21T19:03:49  <BlueMatt> no, we (or at least I) did not :(
334 2017-09-21T19:04:23  <sipa> regarding that: i've seen several reports of people wondering what happened because getinfo doesn't work... i guess they went from 0.14 to 0.5.99 and never saw the deprecation
335 2017-09-21T19:04:50  <gmaxwell> Well they shouldn't run 0.5, that would be bad.
336 2017-09-21T19:04:50  <wumpus> added 10871
337 2017-09-21T19:04:51  <BlueMatt> heh, so, what, when a new release is announced they just build master? :(
338 2017-09-21T19:05:07  <luke-jr> Maybe `bitcoin-cli getinfo` should print a message informing the user about the new RPCs, like we did when bitcoind client got deprecated
339 2017-09-21T19:05:12  <gmaxwell> BlueMatt: some people do that.
340 2017-09-21T19:05:15  <wumpus> luke-jr: also thought about that
341 2017-09-21T19:05:19  <BlueMatt> gmaxwell: wat
342 2017-09-21T19:05:26  <luke-jr> lol
343 2017-09-21T19:05:34  <wumpus> luke-jr: it should at least print a deprecated message
344 2017-09-21T19:05:44  <sipa> BlueMatt: gmaxwell is joking about my typo (0.5 instead of 0.15)
345 2017-09-21T19:05:46  <BlueMatt> gmaxwell: so...what you're saying is we should start using a "develop" branch with master pointing to released versions?
346 2017-09-21T19:05:54  <BlueMatt> sipa: i figured......
347 2017-09-21T19:05:54  <wumpus> luke-jr: instead of just about a missing call, as if it's never existed
348 2017-09-21T19:06:21  <sipa> i like the approach being used for the estimatefee deprecation
349 2017-09-21T19:06:23  <luke-jr> BlueMatt: github lets you change the default branch, so we could just make it the latest stable branch
350 2017-09-21T19:06:24  <goatpig> dont poeple typically pull tags, not just the head of a branch (in this case master)
351 2017-09-21T19:06:26  <wumpus> BlueMatt: or we can just change the github default branch to something else, you know
352 2017-09-21T19:06:31  <luke-jr> problem is, it's also the default for PRs…
353 2017-09-21T19:06:34  <BlueMatt> wumpus: yea, possible
354 2017-09-21T19:06:36  <sipa> where it disappears, but you have a cmdline switch to re-enable
355 2017-09-21T19:06:40  <BlueMatt> I mean really not joking there that's a serious issue
356 2017-09-21T19:06:49  <wumpus> but yes, PRs also go there by default, whichi s kinda annoying
357 2017-09-21T19:06:55  <BlueMatt> people building master right after release is usually bad cause we merge lots of fun stuff on master right after release :/
358 2017-09-21T19:06:56  <achow101> topic suggestion: deprecation stuff a la #11031
359 2017-09-21T19:06:57  <gribble> https://github.com/bitcoin/bitcoin/issues/11031 | [rpc] deprecate estimatefee by jnewbery · Pull Request #11031 · bitcoin/bitcoin · GitHub
360 2017-09-21T19:07:05  <luke-jr> I suppose we can expect developers to be smarter than users
361 2017-09-21T19:07:22  <gmaxwell> BlueMatt: I am not saying we should, just pointing out people do that. We have warnings on master... so I don't worry too much.
362 2017-09-21T19:07:22  <cfields> sipa: i like that too. or even an rpc arg like -force-deprecated.
363 2017-09-21T19:07:27  <wumpus> PRs to branches are really annoying, so I'd prefer to just keep the status quo there
364 2017-09-21T19:07:33  <BlueMatt> gmaxwell: yea, maybe we should make the warnings louder?
365 2017-09-21T19:07:37  <BlueMatt> that may be acceptable similar
366 2017-09-21T19:07:38  <sipa> i think the reports  saw were from pretty much first time users "how do i set this up", and following a guide to build from source
367 2017-09-21T19:07:43  <luke-jr> cfields: better to force the user to be involved IMO
368 2017-09-21T19:07:55  <sipa> wumpus: agree
369 2017-09-21T19:08:06  <wumpus> it can't be the release announcement, as I mention the exact tag to check out there...
370 2017-09-21T19:08:13  <jonasschnelli> hi
371 2017-09-21T19:08:15  <cfields> luke-jr: that's what i meant.
372 2017-09-21T19:08:31  <luke-jr> cfields: a RPC arg wouldn't have the user involved
373 2017-09-21T19:08:44  <BlueMatt> maybe bitcoind should need a -iknowthisisunreleasedunstableversion option :(
374 2017-09-21T19:08:46  <luke-jr> software would just set it
375 2017-09-21T19:08:48  <wumpus> maybe would make sense to add a git clone command in there too for people that can't figure that out themselves
376 2017-09-21T19:08:58  <BlueMatt> or configure could take it
377 2017-09-21T19:09:05  <luke-jr> BlueMatt: default to testnet?
378 2017-09-21T19:09:17  <cfields> luke-jr: oh ok, different definitions of user. i see what you mean.
379 2017-09-21T19:09:19  <wumpus> configure already has that information, so that'd make sense
380 2017-09-21T19:09:21  <BlueMatt> ./configure --this-version-is-unreleased-and-possibly-unstable
381 2017-09-21T19:09:37  <BlueMatt> that would make people think twice and make people fix their guides
382 2017-09-21T19:09:43  <luke-jr> s/unstable/insecure/ ☺
383 2017-09-21T19:09:50  <achow101> luke-jr: we would forget to make it default to mainnet for releases
384 2017-09-21T19:10:01  <BlueMatt> heh, ok, at the risk of bikeshedding, I vote cfields implement it...I dunno anything 'bout autotools
385 2017-09-21T19:10:02  <BlueMatt> :p
386 2017-09-21T19:10:04  <luke-jr> achow101: would we? release-process.md
387 2017-09-21T19:10:04  <wumpus> I've never forget to set IS_RELEASE to true for releases
388 2017-09-21T19:10:21  <wumpus> a few times we've forgot to bump the version number but only for *minor* releases
389 2017-09-21T19:10:22  <luke-jr> or just have -testnet default to !IS_RELEASE
390 2017-09-21T19:10:43  <cfields> heh
391 2017-09-21T19:10:46  <wumpus> and for branches the IS_RELEASE is always true anyhow
392 2017-09-21T19:10:49  <BlueMatt> luke-jr: I kinda like it not modifying the bitcoind at all now that i think about it
393 2017-09-21T19:11:01  <sipa> wumpus: an alternative would be to have a bitcoin-releases repo (under the same org), to which only release tags get pushed
394 2017-09-21T19:11:04  <BlueMatt> build the same bitcoind, but make people type something that says "is not release"
395 2017-09-21T19:11:13  <sipa> wumpus: and direct people to clone from there if they just want stable things
396 2017-09-21T19:11:16  <sipa> but meh...
397 2017-09-21T19:11:23  <wumpus> sipa: I don't know...
398 2017-09-21T19:11:29  <BlueMatt> sipa: heh, if we make it not build from bitcoin/bitcoin, ok
399 2017-09-21T19:11:33  <wumpus> I really prefer not to mess with the repopsotiry too much
400 2017-09-21T19:11:44  <jonasschnelli> agree with wumpus
401 2017-09-21T19:11:45  <morcos> This doesn't seem that large a problem to me...
402 2017-09-21T19:11:48  <sipa> wumpus: yes, agree - i don't think we should do anything
403 2017-09-21T19:11:48  <wumpus> agree
404 2017-09-21T19:11:54  <wumpus> any other topics?
405 2017-09-21T19:11:59  <BlueMatt> agreed, though I'd vote for a configure flag
406 2017-09-21T19:11:59  <achow101> we could move the repo to bitcoin-core and break all of those guides :)
407 2017-09-21T19:12:03  <gmaxwell> yea, I think we don't need to do anything except hunt down and kill people with bad guides. :P
408 2017-09-21T19:12:03  <sipa> achow101 had a topic
409 2017-09-21T19:12:06  <BlueMatt> its not a huge issue, but it sounds rather dangerous
410 2017-09-21T19:12:11  <sipa> (though maybe we've covered it already)
411 2017-09-21T19:12:13  <gmaxwell> perhaps increase the profile of tarball downloads.
412 2017-09-21T19:12:18  <BlueMatt> and I dont think hunting down guide-writers is possible
413 2017-09-21T19:12:25  <wumpus> gmaxwell: now that sounds like a good action item
414 2017-09-21T19:12:33  <wumpus> $action hunt down and kill people with bad guides
415 2017-09-21T19:12:44  <gmaxwell> BlueMatt: publishers, not technically authors.
416 2017-09-21T19:12:49  <jnewbery> any other feedback on the approach in #11031? I think it's a useful pattern for deprecating RPCs (which we'll need to do a few times)
417 2017-09-21T19:12:51  <gribble> https://github.com/bitcoin/bitcoin/issues/11031 | [rpc] deprecate estimatefee by jnewbery · Pull Request #11031 · bitcoin/bitcoin · GitHub
418 2017-09-21T19:13:27  <wumpus> #topic deprecation stuff a la #11031
419 2017-09-21T19:13:29  <gribble> https://github.com/bitcoin/bitcoin/issues/11031 | [rpc] deprecate estimatefee by jnewbery · Pull Request #11031 · bitcoin/bitcoin · GitHub
420 2017-09-21T19:13:37  <luke-jr> there's only 363 0.15.99 nodes
421 2017-09-21T19:14:02  <BlueMatt> luke-jr: I'd expect there to be ~0 on mainnet aside from some developer test nodes, fwiw
422 2017-09-21T19:14:18  <achow101> I think that we might run into a problem where people just have -deprecatedrpc (or whatever it is called) and enable all deprecated behavior until it disappears
423 2017-09-21T19:14:43  <BlueMatt> achow101: thats fine, at least they were made to type "I know this is going away soon"
424 2017-09-21T19:14:47  <BlueMatt> so they cant show up and complain that its gone
425 2017-09-21T19:14:48  <cfields> jnewbery: i like it (better than an rpc arg, on second thought), though the name could use some bikeshedding :(
426 2017-09-21T19:15:05  <jonasschnelli> luke-jr: my crawler counts 2496
427 2017-09-21T19:15:16  <jonasschnelli> oh.. no .99,.. sry
428 2017-09-21T19:15:51  <wumpus> I also prefer command line arg to rpc arg
429 2017-09-21T19:15:59  <wumpus> it's enough to type it once
430 2017-09-21T19:16:04  <jnewbery> achow101: it's designed such that the user needs to include `-enablerpcmethod=<method1> -enablerpcmethod=<method2> ...` to avoid the problem of a user just setting `-enablealldepractedrpcmethods` and forgetting
431 2017-09-21T19:16:42  <jnewbery> cfields: yes, name could probably be improved
432 2017-09-21T19:16:45  <gmaxwell> yea, don't have a deprecatedall, it needs to be specific.
433 2017-09-21T19:16:50  <wumpus> the purpose is just to signal, not to overburden a user with extra work updating their client applications (apart from getting rid of using the RPC call in the first place)
434 2017-09-21T19:16:53  <meshcollider> hmm yeah "-enablerpcmethod=" should probably have the word "deprecated" in it
435 2017-09-21T19:17:00  <wumpus> yes
436 2017-09-21T19:17:11  <achow101> I propose calling it -enableddeprecatedrpc
437 2017-09-21T19:17:17  <jonasschnelli> ack
438 2017-09-21T19:17:18  <wumpus> otherwise it sounds more like a silly security feature
439 2017-09-21T19:17:20  <meshcollider> +!
440 2017-09-21T19:17:32  *** Geoffy has joined #bitcoin-core-dev
441 2017-09-21T19:17:33  <meshcollider> s/!/1/
442 2017-09-21T19:17:57  <sipa> -yesimnaughtyandneedtoupdatemyclienttonotuserpcmethod=name
443 2017-09-21T19:18:15  <achow101> although maybe enabled may not necessarily be the best word for that since we have PRCs that themselves are not deprecated but have deprecated output fields and only the deprecated output fields would show if that option is set
444 2017-09-21T19:18:33  <luke-jr> thought: should rpcuser auth always throw RPC_METHOD_DEPRECATED? if so, how does the user bypass it?
445 2017-09-21T19:18:43  <morcos> -deprecatedrpc is good enough
446 2017-09-21T19:18:45  <luke-jr> maybe -enabledeprecated= would be better
447 2017-09-21T19:18:51  <wumpus> morcos: yes!
448 2017-09-21T19:18:51  <morcos> in a light pink
449 2017-09-21T19:18:53  <gmaxwell> -backwardscompatibilitylaunchcode=0xdeadbeef234828429342893429  < that could trigger fields that are going away. :P
450 2017-09-21T19:19:05  <wumpus> hehehe
451 2017-09-21T19:19:16  <gmaxwell> (and you need to read the release notes to get the launch code)
452 2017-09-21T19:19:21  <gmaxwell> (or source)
453 2017-09-21T19:19:29  <jnewbery> ok, -deprecatedrpc it is
454 2017-09-21T19:19:35  <wumpus> release notes scavenger hunt
455 2017-09-21T19:19:37  <cfields> gmaxwell: where the launchcode is the git commit, so it changes every day until release
456 2017-09-21T19:20:16  <cfields> jnewbery: ack
457 2017-09-21T19:20:17  <gmaxwell> well the idea there was that each depricated feature would have its own code. So you'd look up the code and specify it.
458 2017-09-21T19:20:19  <luke-jr> gmaxwell: too strong for mere deprecation IMO
459 2017-09-21T19:20:41  <gmaxwell> luke-jr: yes, though it solved the how about deprecated fields case.
460 2017-09-21T19:20:46  <luke-jr> something like that feels more like to allow changing consensus-critical stuff
461 2017-09-21T19:20:55  <achow101> I suppose we can then put all of the deprecated account RPCs behind that argument
462 2017-09-21T19:21:06  <cfields> gmaxwell: you're deprecating me? :(
463 2017-09-21T19:21:11  <wumpus> yes
464 2017-09-21T19:21:14  <luke-jr> gmaxwell: how about if the "launch code" matches the method name for methods? :p
465 2017-09-21T19:21:22  <luke-jr> and "accounts" for accounts
466 2017-09-21T19:21:29  <wumpus> in the case of accounts it'd be a group not one single call
467 2017-09-21T19:21:30  <luke-jr> "rpcuser" for -rpcuser
468 2017-09-21T19:21:42  <wumpus> right
469 2017-09-21T19:21:55  <luke-jr> this code already fits that paradigm I think, except for the param name
470 2017-09-21T19:21:57  <achow101> luke-jr: doing that for rpcuser is going to annoy a lot of people
471 2017-09-21T19:22:16  <luke-jr> achow101: yes, that can be discussed separately; it was an example
472 2017-09-21T19:22:19  <wumpus> I  think we should keep the discussion of what things to deprecate separate
473 2017-09-21T19:22:26  <sipa> agree
474 2017-09-21T19:22:33  <achow101> ok
475 2017-09-21T19:23:56  <jonasschnelli> removing the account support via -depracaterpc and positioned arguments seems pretty difficult and/or dangerous.
476 2017-09-21T19:24:08  <jnewbery> achow101: As long as you're happy with that I'll update 11031 with the new name so you can rebase your various RPC deprecation PRs on it
477 2017-09-21T19:24:18  <luke-jr> "rpc" probably shouldn't be in the arg name.
478 2017-09-21T19:24:43  <jonasschnelli> users may be confuse why account are deprecated but still work while -depacaterpc=accounts
479 2017-09-21T19:24:59  <luke-jr> -enabledeprecated seemed nicer IMO
480 2017-09-21T19:25:05  <achow101> jnewbery: I guess so. I haven't looked over 11031 in a while so I want to review it before rebasing
481 2017-09-21T19:25:12  <wumpus> jonasschnelli: it's just the account rpcs that are deprecated, accounts themselves will work as labels
482 2017-09-21T19:25:16  <meshcollider> jonasschnelli: are you suggesting disable the account system completely?
483 2017-09-21T19:25:23  <meshcollider> (without deprecation)
484 2017-09-21T19:25:48  <jonasschnelli> wumpus: yes. That makes sense.
485 2017-09-21T19:25:52  <wumpus> we'll not rip out the account arguments from any non-account RPC calls
486 2017-09-21T19:26:00  <wumpus> just that move etc are deprecated
487 2017-09-21T19:26:22  <achow101> topic suggestion: what to deprecate
488 2017-09-21T19:26:36  <jonasschnelli> But the transition of having a -enabledepracatedrpc= and not disabling the depracated account features seems not to be ideal.. although I guess it's okay
489 2017-09-21T19:27:02  <wumpus> I doubt there is any ideal way to deprecate a monster like the accounts feature, tbh
490 2017-09-21T19:27:06  <luke-jr> wumpus: getbalance <non-*> should fail too
491 2017-09-21T19:27:35  <wumpus> luke-jr: yes
492 2017-09-21T19:28:05  *** chjj has joined #bitcoin-core-dev
493 2017-09-21T19:28:13  <luke-jr> jonasschnelli: no "rpc" :/
494 2017-09-21T19:28:17  <wumpus> do we have any more upbeat topic than deprecation?
495 2017-09-21T19:28:37  <gmaxwell> China blocking bitcoin?
496 2017-09-21T19:28:38  <gmaxwell> (not really)
497 2017-09-21T19:28:39  <meshcollider> segwit wallet support progress?
498 2017-09-21T19:28:43  <gmaxwell> That
499 2017-09-21T19:28:52  <sipa> i'll have a PR soon
500 2017-09-21T19:28:52  <wumpus> #topic segwit wallet support progress
501 2017-09-21T19:28:55  <wumpus> thanks
502 2017-09-21T19:29:06  <sipa> otherwise, review #11167
503 2017-09-21T19:29:07  <gmaxwell> sipa: Have you heard from thomasv about them blocking v>0
504 2017-09-21T19:29:09  <gribble> https://github.com/bitcoin/bitcoin/issues/11167 | Full BIP173 (Bech32) support by sipa · Pull Request #11167 · bitcoin/bitcoin · GitHub
505 2017-09-21T19:29:26  <sipa> gmaxwell: yes, we discussed it in here yesterday
506 2017-09-21T19:29:26  <achow101> sipa: how soon is soon
507 2017-09-21T19:29:33  <sipa> achow101: this week, i hope
508 2017-09-21T19:29:58  <jonasschnelli> sipa: are you also tackling the GUI?
509 2017-09-21T19:30:04  <gmaxwell> did you take my advice and call the new file key-i-key-i-o.cpp
510 2017-09-21T19:30:11  <sipa> jonasschnelli: no, i'll need help for that
511 2017-09-21T19:30:21  <sipa> gmaxwell: just key_io
512 2017-09-21T19:30:32  <meshcollider> haha
513 2017-09-21T19:30:35  <jonasschnelli> sipa: please point me to your branch after the meeting so I can start to work on that
514 2017-09-21T19:30:58  <sipa> (for context, gmaxwell is talking about the followup #11372, which is not for 0.15.1)
515 2017-09-21T19:30:59  <gribble> https://github.com/bitcoin/bitcoin/issues/11372 | Address encoding cleanup by sipa · Pull Request #11372 · bitcoin/bitcoin · GitHub
516 2017-09-21T19:31:01  <gmaxwell> There should be almost no GUI intersection, other than perhaps offering the default overrides in the gui.
517 2017-09-21T19:31:23  <sipa> yeah, i expect some expert mode setting to choose the address type - but otherwise it can just use the default
518 2017-09-21T19:31:36  <gmaxwell> oh right, point of use switching, sure.
519 2017-09-21T19:31:43  *** ThomasV has joined #bitcoin-core-dev
520 2017-09-21T19:31:49  <jonasschnelli> sipa: yes. That is what I though...
521 2017-09-21T19:32:07  <sipa> not that much to say about the topic otherwise
522 2017-09-21T19:32:14  <gmaxwell> jonasschnelli: another thing in the GUI is that we should eventually have a BIP173 error hinter.  We need a monospace text entry field that can be told to underline characters or something like that.
523 2017-09-21T19:32:25  <gmaxwell> (not necessarily a 0.15.1 feature in any case)
524 2017-09-21T19:32:29  <jonasschnelli> Yes! I just wanted to write that
525 2017-09-21T19:32:53  <gmaxwell> well sipa's bip173 patch doesn't have the error finder in it.
526 2017-09-21T19:33:03  <sipa> i think there is another question, that ThomasV brought up yesterday
527 2017-09-21T19:33:14  <sipa> what to do with private key import/export for segwit addresses
528 2017-09-21T19:33:24  <gmaxwell> Though we've written one (a port of it to JS is on that demo page)... it deserves a nice gui handling though (even the js demo is kind of lame, in that it can't highlight inline)
529 2017-09-21T19:33:33  <wumpus> some importmulti ?
530 2017-09-21T19:33:35  <achow101> sipa: importmulti
531 2017-09-21T19:33:36  <sipa> importmulti can handle this natively
532 2017-09-21T19:33:44  <wumpus> ok, seems good enough for me then
533 2017-09-21T19:33:50  <gmaxwell> importmulti was my first thought too.
534 2017-09-21T19:33:54  <achow101> deprecate the other import* rpcs
535 2017-09-21T19:33:54  <sipa> but perhaps at least a warning for importprivkey / dumpprivkey is needed
536 2017-09-21T19:34:01  <wumpus> just highlight that the old import* rpcs don't work with segwit
537 2017-09-21T19:34:07  <jonasschnelli> sipa: yes. Or depracate?
538 2017-09-21T19:34:11  <gmaxwell> When we do the changes that split the key types later, we'll have more to think about. Right now any key is all keytypes.
539 2017-09-21T19:34:18  <wumpus> or deprecate them at some point, but not for a minor release
540 2017-09-21T19:34:30  <sipa> right
541 2017-09-21T19:34:39  <gmaxwell> we can announce an intent at any time. (I think we just did.)
542 2017-09-21T19:34:46  <ThomasV> importmulti does not seem as easy to use as a serialized format
543 2017-09-21T19:34:54  <wumpus> yes, intent+reason could be menitoned in the release notes
544 2017-09-21T19:35:09  <sipa> ThomasV: i consider that a feature :)
545 2017-09-21T19:35:12  <gmaxwell> ThomasV: because of versioning issues, we're not going to solve a new serialized format right now.
546 2017-09-21T19:35:23  <jonasschnelli> importmulti is a bit cumbersome to use,... but should the okay for an RPC layer
547 2017-09-21T19:35:24  <wumpus> importing keys in bitcoin core is considered advanced functionality anyhow
548 2017-09-21T19:36:02  <sipa> ThomasV: as said, i don't mind discussing a more convenient import format for some use case, but we're not going to solve that instantly
549 2017-09-21T19:36:07  <jonasschnelli> importaddress and key with the current rescan-everything approach must go away at some point anyways
550 2017-09-21T19:36:18  <wumpus> jonasschnelli: yeah... that too
551 2017-09-21T19:36:25  <ThomasV> gmaxwell: we were also considering an import format along the lines of bip124
552 2017-09-21T19:36:28  <gmaxwell> raw key handling frequently results in funds loss, even for advanced users too.. but I do think we should ultimately be embedding the required metadata to actually use a key. but it's not something we can really do right now.
553 2017-09-21T19:36:55  <achow101> the bech32-for-privkeys thing could be something for segwit only and have a the witness version number included in that?
554 2017-09-21T19:37:10  <wumpus> achow101: yes
555 2017-09-21T19:37:25  <sipa> achow101: yes, or no - i'm not sure
556 2017-09-21T19:37:29  <gmaxwell> achow101: witness version number isn't the right data.
557 2017-09-21T19:37:40  <sipa> i think we need a 'pure private key' format, which is just a key
558 2017-09-21T19:37:43  <instagibbs> doesn't tell you how it's being used, specifically
559 2017-09-21T19:37:45  <sipa> to minimize the data needed for backup
560 2017-09-21T19:37:58  <wumpus> more like a 'key use'
561 2017-09-21T19:37:59  <gmaxwell> it effectively needs to communicate the scriptpubkey (perhaps be template reference).
562 2017-09-21T19:38:01  <sipa> the associated addresses/chains/... can be stored separately
563 2017-09-21T19:38:02  <jonasschnelli> Not sure if we should really support exporting / importing private keys over an RPC layer in the long run
564 2017-09-21T19:38:14  <luke-jr> sipa: but if you're going for minimal, you'd backup the seed, not the keys?
565 2017-09-21T19:38:15  <sipa> jonasschnelli: yeah... that's a hard question
566 2017-09-21T19:38:23  <gmaxwell> sipa: still needs metadata.
567 2017-09-21T19:38:29  <sipa> gmaxwell: how so?
568 2017-09-21T19:38:40  <wumpus> right, you could backup the seed, and some metadata, no need to backup the keys themselves
569 2017-09-21T19:38:42  <achow101> <scriptpubkey>|<privkey(s)>
570 2017-09-21T19:39:01  <gmaxwell> I mean you need to know _what_ chains or key types are expected. Otherwise it's a lossy search problem to figure out what you should be actually getting.
571 2017-09-21T19:39:10  <wumpus> yes
572 2017-09-21T19:39:12  <sipa> gmaxwell: sure, but i think that can be separate
573 2017-09-21T19:39:47  <sipa> ideally, your wallet has 1 piece of actually secret data, and then a bunch of chains/addresses/scripts/... that use keys derived from that secret data
574 2017-09-21T19:39:51  <gmaxwell> it's critical data without which you can't recover the keys... and with which you can.  (maybe you could bruteforce it out, under somewhat reasonble assumptions...)
575 2017-09-21T19:40:08  <jonasschnelli> Conceptual, we should work towards private key separation with a daemon (or agent) and core only deals with public keys. The private-keys agent/tool could still be in the repository (or different one)
576 2017-09-21T19:40:12  <gmaxwell> it's also potentially a rather small amount of data.
577 2017-09-21T19:40:30  <sipa> gmaxwell: an example i came up yesterday is CLTV scripts
578 2017-09-21T19:40:43  <sipa> there is no way you can enumerate all CLTV scripts from a particular seed
579 2017-09-21T19:41:02  <gmaxwell> no, indeed, but the inability to back up CLTV cleanly was one of the motivations for CSV.
580 2017-09-21T19:41:16  <sipa> but perhaps there is no need, if you have built-in backups of the chain data (which don't risk monetary loss), and a separate backup of the private key
581 2017-09-21T19:41:30  <luke-jr> so three levels of data really: the seed itself, the types/chains/etc, and the comments/labels
582 2017-09-21T19:41:36  <sipa> the private key in that case is just a piece of secret data, referred to by the chains
583 2017-09-21T19:41:48  <gmaxwell> asking people to handle two critical to maintain pieces of information instead of one would be unfortunate.
584 2017-09-21T19:42:10  <gmaxwell> (and by unfortunate I mean result in non-negligible funds loss in practice)
585 2017-09-21T19:42:24  <luke-jr> gmaxwell: maybe concatenate seed + types/chains/etc in practice
586 2017-09-21T19:42:36  <sipa> sure, for simple situations you can create a convenient format that handles both simultaneously
587 2017-09-21T19:42:38  <gmaxwell> sure. that would be okay to.
588 2017-09-21T19:42:40  <wumpus> you could encode it into one identifier somehow...
589 2017-09-21T19:42:43  <wumpus> sounds easy enough
590 2017-09-21T19:42:45  <gmaxwell> (re to both luke and sipa)
591 2017-09-21T19:42:59  <sipa> but i expect there to be cases where you really just want to backup a key, and will handle the metadata (which is too complicated) yourself
592 2017-09-21T19:43:02  <gmaxwell> the logical seperation sounds fine, but for at least the common case there should be some format for combined data.
593 2017-09-21T19:43:21  <sipa> sure
594 2017-09-21T19:43:22  <morcos> +1 for the common case combined format
595 2017-09-21T19:43:32  <gmaxwell> A possible metadata flag is  'external, good luck'. :)
596 2017-09-21T19:44:13  <jonasschnelli> X509
597 2017-09-21T19:44:20  <sipa> JSONx!!
598 2017-09-21T19:44:21  <ThomasV> lol
599 2017-09-21T19:44:26  * jonasschnelli *ducks*
600 2017-09-21T19:44:40  <wumpus> you could always back up the key and metadata separately, then combine them before importing, or have import accept multiple formats, this is just details
601 2017-09-21T19:44:49  <gmaxwell> Could just have a box where people can just type in x86 machine code and it will decode the result for you ...  almost as flexible as x509.
602 2017-09-21T19:44:57  <gmaxwell> :-)
603 2017-09-21T19:45:10  <luke-jr> XD
604 2017-09-21T19:45:20  <sipa> ok, other topics?
605 2017-09-21T19:45:29  <wumpus> nice, though too easy to use, should be some ancient 8-bit assembly like z80 or 6502
606 2017-09-21T19:46:08  <sipa> INTERCAL
607 2017-09-21T19:46:13  <luke-jr> suggested topic: it would be really nice to get #7533 in, since it is a constant rebase hell otherwise; comments on how to improve the code quality (ugh, macros) appreciated
608 2017-09-21T19:46:15  <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
609 2017-09-21T19:46:16  <gmaxwell> I've had to use 6502 assembly in the last couple years ... (for a mystery hunt puzzle)
610 2017-09-21T19:46:26  <wumpus> yeah
611 2017-09-21T19:47:07  <wumpus> gmaxwell: did you still manage to? :)
612 2017-09-21T19:47:08  <gmaxwell> other topics: did people see on the mailing list that there is a new Dandelion post?
613 2017-09-21T19:47:16  <jnewbery> wumpus: you suggested topic high-priority for review earlier. Did you want to discuss individual PRs or were you just asking if people had PRs they want added to the list?
614 2017-09-21T19:47:38  <meshcollider> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-September/015030.html
615 2017-09-21T19:47:42  <wumpus> #topic Dandelion post
616 2017-09-21T19:48:18  <wumpus> jnewbery: both is ok, though there are too many PRs on the list right now, would prefer some to be reviewed first - the point of it focusing review is lost if we just add all PRs in there :)
617 2017-09-21T19:48:38  <gmaxwell> I don't know that I have much to say, other that I thought it should get some attention (I know not everyone reads the list closely). I think this will be a good thing to implement and the people working on it are pretty eager.
618 2017-09-21T19:48:48  <gmaxwell> (and responsive)
619 2017-09-21T19:49:40  <jnewbery> wumpus: ok, tit-for-tat. I'll review a couple of those in the next week. Can you add #10740. I think it's ready for initial review
620 2017-09-21T19:49:40  <wumpus> thanks for mentioning it, I indeed missed it
621 2017-09-21T19:49:42  <gribble> https://github.com/bitcoin/bitcoin/issues/10740 | [wallet] dynamic loading/unloading of wallets by jnewbery · Pull Request #10740 · bitcoin/bitcoin · GitHub
622 2017-09-21T19:49:55  <wumpus> #link https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-September/015030.html
623 2017-09-21T19:50:12  * BlueMatt is curious how this interacts with the questions about mempool sync
624 2017-09-21T19:50:20  <BlueMatt> though I havent read the dandelion stuff much
625 2017-09-21T19:50:43  <wumpus> jnewbery: ok added
626 2017-09-21T19:50:43  <gmaxwell> BlueMatt: externally to it. Basically it's a quiet forwarding thing that has little to no mempool interaction.
627 2017-09-21T19:50:53  <jnewbery> wumpus: thanks!
628 2017-09-21T19:50:58  <gmaxwell> BlueMatt: so that public distribution of transactions happens away from the source.
629 2017-09-21T19:51:36  <BlueMatt> gmaxwell: well based on the dandelion tl; dr i just got, it seems to me that dandelion is essentially the old mempool-sync proposal of "relay txn to only one, maybe two peers but then do sync of your mempool with your peers every so often to propagate things more fully"
630 2017-09-21T19:51:48  <BlueMatt> except they replace sync with "broadcast after a while"
631 2017-09-21T19:52:07  <gmaxwell> BlueMatt: kind of. it's not in your mempool though when it passes through in the one at a time propagation.
632 2017-09-21T19:52:35  <sipa> BlueMatt: but dandelion has rebroadcast too, which can't be avoided (if you dandelion-forwarded a TX, but don't see it N seconds later on the normal network, you yourself start broadcasting it normally)
633 2017-09-21T19:52:57  <morcos> sipa: why not dandelion it again?
634 2017-09-21T19:53:23  <BlueMatt> sipa: yes, I'm asking for comparison between dandelion and the old mempool-sync proposal of gmaxwell
635 2017-09-21T19:53:34  <sipa> morcos: the dandelion stem isn't expected to reach the entire network
636 2017-09-21T19:53:54  <BlueMatt> it sounds to me like the gmaxwell proposal is effeciely similar, though maybe dandelion pointed out (correctly, I suppose) that you want to not add it to your mempool until later to preserve privacy
637 2017-09-21T19:53:56  <sipa> so you still need something outside of dandelion-forward and mempool reconciliation
638 2017-09-21T19:54:00  <gmaxwell> Peer hands you a txn with a private flag. Assuming the txn is valid wrt your mempool, you set it aside and forward it on to a single other peer (determinstically selected based on the input peer).  At random, you drop the private flag when you relay it with some fixed probablity.   If the txn is offered by other peers you fetch it.
639 2017-09-21T19:54:33  *** promag has joined #bitcoin-core-dev
640 2017-09-21T19:54:36  <gmaxwell> If after a timeout you never see it from other peers you broadcast it yourself.. but that only happens if someone in the 'stem' path drops the ball.
641 2017-09-21T19:54:56  <sipa> BlueMatt: there seems to be some overlap, but i don't think dandelion+sync is a complete solution
642 2017-09-21T19:55:07  <gmaxwell> so it is similar to my relay improvement proposal, but the privacy requirements mean that it doesn't accomplish syncing itself.
643 2017-09-21T19:55:09  *** jtimon has joined #bitcoin-core-dev
644 2017-09-21T19:55:12  <morcos> sipa: hmm, i was just asking if you didn't see it, why you wouldn't repeat the whole process assuming the stem got cut somehwere, and hoping that you can get to the fluff on try 2.  why fall back to old method
645 2017-09-21T19:55:39  <BlueMatt> wait, wait doesnt "(determinstically selected based on the input peer)" imply that you can still group transactions from a single source based on where you first saw them....sure where you first saw them wont be the guy who created it, but it'll still be the same for all txn from the same guy
646 2017-09-21T19:55:44  <BlueMatt> maybe I should shut up and go read it
647 2017-09-21T19:55:44  <sipa> morcos: the 'fluff' is just normal tx relay
648 2017-09-21T19:55:48  <gmaxwell> BlueMatt: so it is like my relay bandwidth improving proposal, without improving relay bandwidth. :P
649 2017-09-21T19:56:20  <BlueMatt> heh, yea, ok
650 2017-09-21T19:56:28  <gmaxwell> BlueMatt: only if you are inside the stem yourself.  (this was a change their latest work makes)
651 2017-09-21T19:56:38  <BlueMatt> hmm, alright
652 2017-09-21T19:57:24  <gmaxwell> the tradeoff is that if you don't do the determinstic routing and the sender sends lots of txn you are certian to be in the stem for some of them.
653 2017-09-21T19:57:49  <gmaxwell> basically related to the guardnodes problem in tor.
654 2017-09-21T19:57:58  *** SopaXorzTaker has quit IRC
655 2017-09-21T19:58:38  <gmaxwell> in any case, it would be good to have more critical eyes on their design. I've only just started thinking about the implications of the change to determinstic paths.
656 2017-09-21T19:58:48  *** promag has quit IRC
657 2017-09-21T19:59:49  *** timothy has joined #bitcoin-core-dev
658 2017-09-21T20:00:01  <sipa> PLOINK
659 2017-09-21T20:00:11  <wumpus> yes, extrememly important for privacy to not make any mistakes here
660 2017-09-21T20:00:18  <wumpus> #endmeeting
661 2017-09-21T20:00:18  <lightningbot> Meeting ended Thu Sep 21 20:00:18 2017 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
662 2017-09-21T20:00:18  <lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-09-21-19.00.html
663 2017-09-21T20:00:18  <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-09-21-19.00.txt
664 2017-09-21T20:00:18  <lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-09-21-19.00.log.html
665 2017-09-21T20:00:37  <gmaxwell> wumpus: At least the current behavior is weak enough that it would be hard to not make an improvement. :)
666 2017-09-21T20:00:50  <BlueMatt> hah, yea, that ^
667 2017-09-21T20:02:24  <wumpus> sure
668 2017-09-21T20:04:39  <gmaxwell> unrelated, my gpg encryption subkey expired a bit ago.  I just replaced it with a newly generated one... with the rationale that its good to rotate such things, and unlike identity keys, easy to rotate them. I can still decrypt with the old one for now.
669 2017-09-21T20:05:13  <wumpus> your new key is on the keyserver?
670 2017-09-21T20:05:37  <achow101> does anyone know when verack was added to the protocol? It's not in the first version but I can't find any documentation about it
671 2017-09-21T20:05:50  <wumpus> apparently it is, refresh-key worked gpg:            new subkeys: 1
672 2017-09-21T20:06:02  <gmaxwell> wumpus: yes. as of about the beginning of the meeting.
673 2017-09-21T20:06:18  <sipa> achow101: 0.2.9
674 2017-09-21T20:08:03  <achow101> sipa: thanks
675 2017-09-21T20:08:43  <wumpus> sipa: achow101: seems it's missing here https://bitcoin.org/en/developer-reference#protocol-versions
676 2017-09-21T20:09:01  <achow101> wumpus: yeah, I noticed
677 2017-09-21T20:09:03  <wumpus> only mentions adding the checksum field there
678 2017-09-21T20:09:18  <achow101> I assume that's because that's all the commit message mentions too
679 2017-09-21T20:09:19  <wumpus> please file a PR :)
680 2017-09-21T20:10:06  <luke-jr> FYI https://www.blackhat.com/eu-17/briefings/schedule/#how-to-hack-a-turned-off-computer-or-running-unsigned-code-in-intel-management-engine-8668
681 2017-09-21T20:10:44  <wumpus> luke-jr: :-(
682 2017-09-21T20:10:56  * luke-jr wonders if it's really only Skylake+
683 2017-09-21T20:13:11  <BlueMatt> #11116 could probably use a merge
684 2017-09-21T20:13:13  <gribble> https://github.com/bitcoin/bitcoin/issues/11116 | [script] Unit tests for script/standard and IsMine functions. by jimpo · Pull Request #11116 · bitcoin/bitcoin · GitHub
685 2017-09-21T20:13:14  *** SopaXorzTaker has joined #bitcoin-core-dev
686 2017-09-21T20:15:17  *** RubenSomsen has quit IRC
687 2017-09-21T20:16:10  *** timothy has quit IRC
688 2017-09-21T20:16:46  <bitcoin-git> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/98212745c8ac...49f3d57eeb66
689 2017-09-21T20:16:47  <bitcoin-git> bitcoin/master d7afe2d Jim Posen: [script] Unit tests for script/standard functions
690 2017-09-21T20:16:47  <bitcoin-git> bitcoin/master 7a1e873 Jim Posen: [script] Unit tests for IsMine...
691 2017-09-21T20:16:48  <bitcoin-git> bitcoin/master 49f3d57 Wladimir J. van der Laan: Merge #11116: [script] Unit tests for script/standard and IsMine functions....
692 2017-09-21T20:17:23  <bitcoin-git> [bitcoin] laanwj closed pull request #11116: [script] Unit tests for script/standard and IsMine functions. (master...script-standard-tests) https://github.com/bitcoin/bitcoin/pull/11116
693 2017-09-21T20:21:06  *** Miezel has quit IRC
694 2017-09-21T20:25:57  *** Chris_Stewart_5 has quit IRC
695 2017-09-21T20:31:26  *** Guyver2 has quit IRC
696 2017-09-21T20:46:30  *** promag has joined #bitcoin-core-dev
697 2017-09-21T20:50:28  *** promag has quit IRC
698 2017-09-21T21:20:46  *** ThomasV has quit IRC
699 2017-09-21T21:22:16  *** promag has joined #bitcoin-core-dev
700 2017-09-21T21:26:53  *** alxlu has quit IRC
701 2017-09-21T21:30:05  *** Miezel has joined #bitcoin-core-dev
702 2017-09-21T21:32:06  *** promag has quit IRC
703 2017-09-21T21:36:01  *** Miezel has joined #bitcoin-core-dev
704 2017-09-21T21:36:41  *** promag has joined #bitcoin-core-dev
705 2017-09-21T21:40:19  <promag> wumpus: jnewbery: is there a strong reason to #10740 have high priority review?
706 2017-09-21T21:40:21  <gribble> https://github.com/bitcoin/bitcoin/issues/10740 | [wallet] dynamic loading/unloading of wallets by jnewbery · Pull Request #10740 · bitcoin/bitcoin · GitHub
707 2017-09-21T21:42:31  <jnewbery> promag: because it's likely to take quite a bit of review and I'd like it in for 0.16. It will also provide a resolution to the keypool topup corner cases that prevented a full fix for that issue getting into v0.15.
708 2017-09-21T21:44:15  <luke-jr> #10615 and GUI support should go before 10740..
709 2017-09-21T21:44:16  <gribble> https://github.com/bitcoin/bitcoin/issues/10615 | RPC: Allow rpcauth configs to specify a 4th parameter naming a specific wallet (multiwallet RPC support) by luke-jr · Pull Request #10615 · bitcoin/bitcoin · GitHub
710 2017-09-21T21:44:24  *** duringo has joined #bitcoin-core-dev
711 2017-09-21T21:44:58  <luke-jr> far more important to be able to actually use it, than dynamic open/close
712 2017-09-21T21:45:27  *** NicolasDorier has quit IRC
713 2017-09-21T21:45:27  *** rodarmor has quit IRC
714 2017-09-21T21:46:00  *** trotski2000 has quit IRC
715 2017-09-21T21:46:15  <promag> luke-jr: no PR for GUI support right?
716 2017-09-21T21:46:33  *** btcdrak has quit IRC
717 2017-09-21T21:46:33  *** jl2012 has quit IRC
718 2017-09-21T21:47:06  *** chainhead has quit IRC
719 2017-09-21T21:47:39  *** Lightsword has quit IRC
720 2017-09-21T21:48:02  *** spinza has quit IRC
721 2017-09-21T21:48:12  *** Muis has quit IRC
722 2017-09-21T21:48:12  *** xHire has quit IRC
723 2017-09-21T21:48:12  *** pindarhk_ has quit IRC
724 2017-09-21T21:48:16  *** trotski2000 has joined #bitcoin-core-dev
725 2017-09-21T21:49:37  *** intcat has quit IRC
726 2017-09-21T21:49:54  *** pindarhk_ has joined #bitcoin-core-dev
727 2017-09-21T21:50:05  *** xHire has joined #bitcoin-core-dev
728 2017-09-21T21:50:12  <luke-jr> promag: no, because it's built on top of 10615
729 2017-09-21T21:50:12  *** LeMiner has quit IRC
730 2017-09-21T21:50:33  *** intcat has joined #bitcoin-core-dev
731 2017-09-21T21:50:36  <luke-jr> promag: the branch is named multiwallet_gui
732 2017-09-21T21:50:57  <promag> mind I take a look?
733 2017-09-21T21:51:18  *** Muis has joined #bitcoin-core-dev
734 2017-09-21T21:53:30  *** chainhead has joined #bitcoin-core-dev
735 2017-09-21T21:54:18  <promag> so the concept is to have a combobox to choose the wallet in the mainwindow?
736 2017-09-21T21:54:28  *** Lightsword has joined #bitcoin-core-dev
737 2017-09-21T21:54:42  <luke-jr> promag: yes, it works pretty well
738 2017-09-21T21:55:40  <luke-jr> been shipping it in Knots since 0.13 ;)
739 2017-09-21T21:56:40  <luke-jr> maybe I should open a PR so it at least has that
740 2017-09-21T21:56:44  <promag> does it restores the current wallet when it starts?
741 2017-09-21T21:56:53  <luke-jr> promag: no
742 2017-09-21T21:57:20  <luke-jr> maybe it should
743 2017-09-21T21:57:36  <promag> yeah, like the geometry stuff
744 2017-09-21T21:57:43  *** Miezel has quit IRC
745 2017-09-21T21:59:32  *** duringo_ has joined #bitcoin-core-dev
746 2017-09-21T21:59:32  *** duringo has quit IRC
747 2017-09-21T22:00:50  *** rodarmor has joined #bitcoin-core-dev
748 2017-09-21T22:00:52  *** NicolasDorier has joined #bitcoin-core-dev
749 2017-09-21T22:05:52  *** promag has quit IRC
750 2017-09-21T22:06:46  *** promag has joined #bitcoin-core-dev
751 2017-09-21T22:07:54  *** promag_ has joined #bitcoin-core-dev
752 2017-09-21T22:07:54  *** promag has quit IRC
753 2017-09-21T22:08:57  <luke-jr> promag_: not sure it makes sense for the wallet, since presumably you'd be using all the wallets (you don't reposition the GUI geometry normally)
754 2017-09-21T22:09:24  <bitcoin-git> [bitcoin] luke-jr opened pull request #11383: Basic Multiwallet GUI support (master...multiwallet_gui) https://github.com/bitcoin/bitcoin/pull/11383
755 2017-09-21T22:09:46  *** promag_ has quit IRC
756 2017-09-21T22:09:57  *** promag has joined #bitcoin-core-dev
757 2017-09-21T22:10:24  *** spinza has joined #bitcoin-core-dev
758 2017-09-21T22:11:48  *** promag has quit IRC
759 2017-09-21T22:12:02  *** promag has joined #bitcoin-core-dev
760 2017-09-21T22:12:05  <promag> nowadays apps usually restore the state
761 2017-09-21T22:12:11  <promag> "you continue where you left"
762 2017-09-21T22:12:42  <promag> tks for the PR
763 2017-09-21T22:13:03  *** veleiro has left #bitcoin-core-dev
764 2017-09-21T22:13:09  <promag> we can explore that idea later
765 2017-09-21T22:20:09  *** duringo__ has joined #bitcoin-core-dev
766 2017-09-21T22:22:02  *** Cheeseo has joined #bitcoin-core-dev
767 2017-09-21T22:23:48  *** duringo_ has quit IRC
768 2017-09-21T22:42:18  *** Giszmo has quit IRC
769 2017-09-21T22:44:21  *** duringo___ has joined #bitcoin-core-dev
770 2017-09-21T22:48:00  *** duringo__ has quit IRC
771 2017-09-21T22:50:35  *** Cheeseo has quit IRC
772 2017-09-21T23:03:22  *** Giszmo has joined #bitcoin-core-dev
773 2017-09-21T23:12:58  *** SopaXorzTaker has quit IRC
774 2017-09-21T23:31:37  *** Miezel has joined #bitcoin-core-dev
775 2017-09-21T23:33:01  *** vicenteH has quit IRC
776 2017-09-21T23:34:53  *** RubenSomsen has joined #bitcoin-core-dev
777 2017-09-21T23:42:29  *** justanotheruser has joined #bitcoin-core-dev
778 2017-09-21T23:46:17  *** sdfgsdfg has joined #bitcoin-core-dev
779 2017-09-21T23:46:24  *** jl2012 has joined #bitcoin-core-dev
780 2017-09-21T23:46:52  *** btcdrak has joined #bitcoin-core-dev
781 2017-09-21T23:49:26  *** Chris_Stewart_5 has joined #bitcoin-core-dev
782 2017-09-21T23:50:10  *** justanotheruser has quit IRC
783 2017-09-21T23:55:39  *** seone has quit IRC