1 2019-01-25T00:01:14  *** mistergo1d has quit IRC
  2 2019-01-25T00:11:53  *** mn9495881 has joined #bitcoin-core-dev
  3 2019-01-25T00:12:47  *** miknotauro has quit IRC
  4 2019-01-25T00:15:57  *** Krellan has joined #bitcoin-core-dev
  5 2019-01-25T00:24:26  *** Krellan has quit IRC
  6 2019-01-25T00:27:53  *** pinheadmz has joined #bitcoin-core-dev
  7 2019-01-25T00:29:54  *** promag has quit IRC
  8 2019-01-25T00:31:05  *** Skirmant has joined #bitcoin-core-dev
  9 2019-01-25T00:38:16  *** Krellan has joined #bitcoin-core-dev
 10 2019-01-25T00:43:35  *** mistergold has quit IRC
 11 2019-01-25T00:43:55  *** mistergold has joined #bitcoin-core-dev
 12 2019-01-25T00:50:18  *** pinheadmz has quit IRC
 13 2019-01-25T00:54:14  *** bitcoin-git has joined #bitcoin-core-dev
 14 2019-01-25T00:54:15  <bitcoin-git> [bitcoin] MarcoFalke opened pull request #15248: rpc: Compile on GCC4.8 (master...Mf1901-rpcCompileGCC48) https://github.com/bitcoin/bitcoin/pull/15248
 15 2019-01-25T00:54:15  *** bitcoin-git has left #bitcoin-core-dev
 16 2019-01-25T00:54:46  *** pinheadmz has joined #bitcoin-core-dev
 17 2019-01-25T01:00:24  *** bitcoin-git has joined #bitcoin-core-dev
 18 2019-01-25T01:00:25  <bitcoin-git> [bitcoin] Empact opened pull request #15249: Docs: Update python docs to reflect that wildcard imports are disallowed (master...wildcard-imports-doc) https://github.com/bitcoin/bitcoin/pull/15249
 19 2019-01-25T01:00:25  *** bitcoin-git has left #bitcoin-core-dev
 20 2019-01-25T01:00:52  *** promag has joined #bitcoin-core-dev
 21 2019-01-25T01:05:21  *** promag has quit IRC
 22 2019-01-25T01:05:33  *** IzoooO has quit IRC
 23 2019-01-25T01:07:01  *** cyber55 has joined #bitcoin-core-dev
 24 2019-01-25T01:16:05  *** michaels_ has quit IRC
 25 2019-01-25T01:18:35  *** mistergo1d has joined #bitcoin-core-dev
 26 2019-01-25T01:18:52  *** ThomasLuong has quit IRC
 27 2019-01-25T01:21:56  *** mistergold has quit IRC
 28 2019-01-25T01:26:17  *** justan0theruser has joined #bitcoin-core-dev
 29 2019-01-25T01:28:48  *** justanotheruser has quit IRC
 30 2019-01-25T01:28:55  *** justan0theruser is now known as justanotheruser
 31 2019-01-25T01:32:53  *** Evel-Knievel has quit IRC
 32 2019-01-25T01:33:31  *** promag has joined #bitcoin-core-dev
 33 2019-01-25T01:36:10  *** Evel-Knievel has joined #bitcoin-core-dev
 34 2019-01-25T01:37:45  *** promag has quit IRC
 35 2019-01-25T01:40:20  *** jgb has joined #bitcoin-core-dev
 36 2019-01-25T01:40:44  *** jgb is now known as Guest29703
 37 2019-01-25T01:53:26  *** mistergold has joined #bitcoin-core-dev
 38 2019-01-25T01:56:56  *** mistergo1d has quit IRC
 39 2019-01-25T02:00:17  *** dermoth has quit IRC
 40 2019-01-25T02:06:34  *** pinheadmz has quit IRC
 41 2019-01-25T02:11:08  *** ThomasLuong has joined #bitcoin-core-dev
 42 2019-01-25T02:13:54  *** dermoth has joined #bitcoin-core-dev
 43 2019-01-25T02:16:39  *** pinheadmz has joined #bitcoin-core-dev
 44 2019-01-25T02:34:10  *** pinheadmz has quit IRC
 45 2019-01-25T02:38:41  *** mistergo1d has joined #bitcoin-core-dev
 46 2019-01-25T02:41:43  *** mistergold has quit IRC
 47 2019-01-25T02:44:06  *** bitcoin-git has joined #bitcoin-core-dev
 48 2019-01-25T02:44:06  <bitcoin-git> [bitcoin] sipa opened pull request #15250: Use RdSeed when available, and reduce RdRand load (master...201901_rdseed) https://github.com/bitcoin/bitcoin/pull/15250
 49 2019-01-25T02:44:06  *** bitcoin-git has left #bitcoin-core-dev
 50 2019-01-25T03:09:06  *** Krellan has quit IRC
 51 2019-01-25T03:14:26  *** Skirmant has quit IRC
 52 2019-01-25T03:44:46  *** bitcoin-git has joined #bitcoin-core-dev
 53 2019-01-25T03:44:46  <bitcoin-git> [bitcoin] fanquake opened pull request #15251: [0.17] doc: Remove errant paste from walletcreatefundedpsbt for nLocktime replaceable (0.17...017-backport-15213) https://github.com/bitcoin/bitcoin/pull/15251
 54 2019-01-25T03:44:46  *** bitcoin-git has left #bitcoin-core-dev
 55 2019-01-25T03:56:24  *** bitcoin-git has joined #bitcoin-core-dev
 56 2019-01-25T03:56:24  <bitcoin-git> [bitcoin] fanquake opened pull request #15252: [0.17] Backport: Update zmq to 4.3.1 (0.17...017-backport-15188) https://github.com/bitcoin/bitcoin/pull/15252
 57 2019-01-25T03:56:24  *** bitcoin-git has left #bitcoin-core-dev
 58 2019-01-25T04:05:30  *** bitcoin-git has joined #bitcoin-core-dev
 59 2019-01-25T04:05:30  <bitcoin-git> [bitcoin] Empact opened pull request #15253: Net: Consistently log outgoing INV messages (master...inv-log) https://github.com/bitcoin/bitcoin/pull/15253
 60 2019-01-25T04:05:30  *** bitcoin-git has left #bitcoin-core-dev
 61 2019-01-25T04:08:04  *** bitcoin-git has joined #bitcoin-core-dev
 62 2019-01-25T04:08:04  <bitcoin-git> [bitcoin] Empact opened pull request #15254: Trivial: fixup a few doxygen comments (master...doxygen-comments) https://github.com/bitcoin/bitcoin/pull/15254
 63 2019-01-25T04:08:04  *** bitcoin-git has left #bitcoin-core-dev
 64 2019-01-25T04:26:43  *** bitcoin-git has joined #bitcoin-core-dev
 65 2019-01-25T04:26:43  <bitcoin-git> [bitcoin] Empact closed pull request #15231: Drop defunct Windows compat fixes (master...ai-addrconfig) https://github.com/bitcoin/bitcoin/pull/15231
 66 2019-01-25T04:26:43  *** bitcoin-git has left #bitcoin-core-dev
 67 2019-01-25T04:31:09  *** bitcoin-git has joined #bitcoin-core-dev
 68 2019-01-25T04:31:09  <bitcoin-git> [bitcoin] gkrizek opened pull request #15255: [tests] Remove travis_wait from lint script (master...remove-travis_wait) https://github.com/bitcoin/bitcoin/pull/15255
 69 2019-01-25T04:31:09  *** bitcoin-git has left #bitcoin-core-dev
 70 2019-01-25T05:07:38  *** dermoth has quit IRC
 71 2019-01-25T05:08:14  *** dermoth has joined #bitcoin-core-dev
 72 2019-01-25T05:35:11  *** promag has joined #bitcoin-core-dev
 73 2019-01-25T05:37:30  *** mistergold has joined #bitcoin-core-dev
 74 2019-01-25T05:37:32  <jonasschnelli> Is there another reason then complexity that the script descriptors do not have a range specifier? Like wpkh(xpub6DJ2dNUysrn5Vt36jH2KLBT2i1auw1tTSSomg8PhqNiUtx8QX2SvC9nrHu81fT41fvDUnhMjEzQgXnQjKEu3oaqMSzhSrHMxyyoEAmUHQbY/0/*[100-200])?
 75 2019-01-25T05:38:22  *** mistergo1d has quit IRC
 76 2019-01-25T05:39:38  *** promag has quit IRC
 77 2019-01-25T05:41:34  *** Murch has quit IRC
 78 2019-01-25T05:41:38  <sipa> jonasschnelli: yes, not all places where descriptors are useful require a range
 79 2019-01-25T05:42:07  <sipa> specifically, a wallet doesn't, as it can automatically extend the ranges
 80 2019-01-25T05:42:10  <jonasschnelli> sipa: but it could be an optional element that may be ignored by the application logic
 81 2019-01-25T05:42:39  <jonasschnelli> sipa: say I want to import p2wpkh script from an xpub from 100 to 200
 82 2019-01-25T05:42:55  <sipa> then you need a record with that descriptor, and that range
 83 2019-01-25T05:43:07  <sipa> there is other metadata you need that has no place in a desceiptor
 84 2019-01-25T05:43:15  <sipa> like whether or not to treat it as change
 85 2019-01-25T05:43:21  <sipa> or what hw device is associated with it
 86 2019-01-25T05:43:27  <jonasschnelli> Yes. That is a point.
 87 2019-01-25T05:58:13  *** mistergo1d has joined #bitcoin-core-dev
 88 2019-01-25T06:00:21  *** _luc_ has joined #bitcoin-core-dev
 89 2019-01-25T06:01:26  *** mistergold has quit IRC
 90 2019-01-25T06:01:38  *** _luc_ has quit IRC
 91 2019-01-25T06:01:59  *** DeanGuss has joined #bitcoin-core-dev
 92 2019-01-25T06:12:46  *** mistergo1d has quit IRC
 93 2019-01-25T06:14:23  *** bitcoin-git has joined #bitcoin-core-dev
 94 2019-01-25T06:14:23  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/72bd4ab867e3...d14ef5721ffc
 95 2019-01-25T06:14:23  <bitcoin-git> bitcoin/master b09dab0 Akio Nakamura: Prevent mutex lock fail even if --enable-debug...
 96 2019-01-25T06:14:23  <bitcoin-git> bitcoin/master d14ef57 MarcoFalke: Merge #15233: Prevent mutex lock fail even if --enable-debug...
 97 2019-01-25T06:14:23  *** bitcoin-git has left #bitcoin-core-dev
 98 2019-01-25T06:14:32  *** pinheadmz has joined #bitcoin-core-dev
 99 2019-01-25T06:15:14  *** bitcoin-git has joined #bitcoin-core-dev
100 2019-01-25T06:15:14  <bitcoin-git> [bitcoin] MarcoFalke closed pull request #15233: Prevent mutex lock fail even if --enable-debug (master...fix_mutex_lock_fail) https://github.com/bitcoin/bitcoin/pull/15233
101 2019-01-25T06:15:14  *** bitcoin-git has left #bitcoin-core-dev
102 2019-01-25T06:26:04  *** bitcoin-git has joined #bitcoin-core-dev
103 2019-01-25T06:26:04  <bitcoin-git> [bitcoin] kallewoof closed pull request #15241: travis: add --enable-debug macos build (master...travis-enable-debug-macos) https://github.com/bitcoin/bitcoin/pull/15241
104 2019-01-25T06:26:04  *** bitcoin-git has left #bitcoin-core-dev
105 2019-01-25T06:26:05  *** jb55 has joined #bitcoin-core-dev
106 2019-01-25T06:28:05  *** cyber55 has quit IRC
107 2019-01-25T06:29:15  *** cyber55 has joined #bitcoin-core-dev
108 2019-01-25T06:33:25  <kallewoof> looks like adding 'osx' as an os is possible in travis (but would result in 2* the number of builds, if I understand... and there is a bunch of docker stuff in there now that wasn't there when I fiddled last..)
109 2019-01-25T06:37:11  *** pinheadmz has quit IRC
110 2019-01-25T06:42:31  *** pinheadmz has joined #bitcoin-core-dev
111 2019-01-25T06:48:24  *** spinza has quit IRC
112 2019-01-25T06:52:43  *** spinza has joined #bitcoin-core-dev
113 2019-01-25T06:52:56  <sipa> kallewoof: ideally we'd be able to test the linux cross-compiled macos binaries... but that's tricky as it means tranferrings builds from one run to another
114 2019-01-25T06:55:22  <jonasschnelli> Maybe as a starter just run one build (wallet + QT) on nativ travis osx and run the tests?
115 2019-01-25T06:55:47  *** miknotauro has joined #bitcoin-core-dev
116 2019-01-25T06:56:06  <jonasschnelli> Running the cross compiled macos binaries would indeed be great...
117 2019-01-25T06:57:41  <jonasschnelli> But since macOS is very likely non apple nativ and even if – its a form of a BSD, we could eventually use the same cross compile toolchain used under linux to somehow emulate the cross compile process and run the test
118 2019-01-25T06:58:18  *** pinheadmz has quit IRC
119 2019-01-25T07:01:01  <sipa> what does "since macos is very likely non apple native" mean?
120 2019-01-25T07:01:38  <jonasschnelli> the travis macOS is probably an emulated macOS... not a Apple native... probably some sort of Hackintosh
121 2019-01-25T07:02:12  <jonasschnelli> the test results are eventually not directly identical... but I may be wrong.
122 2019-01-25T07:02:52  <kallewoof> i think they are running on an actual macOS actually.. "Travis CI uses macOS 10.13 and Xcode 9.4.1 by default" (https://docs.travis-ci.com/user/reference/osx/)
123 2019-01-25T07:02:54  <jonasschnelli> AFAIK Apple (by the TOC) does not allow virtualization of its macOS on non mac hardware ... and I don't expect that travis has a bunch of iMac laying around
124 2019-01-25T07:03:35  <jonasschnelli> kallewoof: Yeah. I have read this... but I wonder how they do it
125 2019-01-25T07:03:54  <jonasschnelli> macOS runs only on mac
126 2019-01-25T07:04:07  <jonasschnelli> expect you modify it in a pretty nasty way
127 2019-01-25T07:04:45  <jonasschnelli> (which I what makes me say the test results may not be completely representative)
128 2019-01-25T07:04:46  <sipa> they may well have negotiated a license agreement with apple
129 2019-01-25T07:05:02  <jonasschnelli> could be... but unlikely
130 2019-01-25T07:05:34  <jonasschnelli> But they maybe have a couple of mac pros or so running those jobs
131 2019-01-25T07:05:53  <echeveria> jonasschnelli: it’s not modified much actually.
132 2019-01-25T07:05:59  <jonasschnelli> AFAIK there are no drivers for non mac hardware, etc.
133 2019-01-25T07:06:18  <jonasschnelli> echeveria: what means "not much"? :)
134 2019-01-25T07:06:22  <echeveria> jonasschnelli: there’s a kernel module, DONTSTEALMACOS.kext, and other than that it’s just driver support mostly.
135 2019-01-25T07:07:11  <echeveria> most services just virtualize OS X on a farm of Mac Minis anyway, which doesn’t violate the license and sort of fits into a data center.
136 2019-01-25T07:07:39  <jonasschnelli> Yeah. I heard about this. But I guess not very efficient...
137 2019-01-25T07:07:59  <jonasschnelli> Mac Mini is probably the nightmare of a server data center admin...
138 2019-01-25T07:08:45  <sipa> it looks like they run on actual mac hardware
139 2019-01-25T07:08:49  <echeveria> they run mostly alright for this sort of target. I know a developer that has a dedicated Mac Mini build server for their binary distribution in a similar way to bitcoin core.
140 2019-01-25T07:09:25  <echeveria> similar to Travis, building Bitcoin Core, I men’s.
141 2019-01-25T07:09:25  <jonasschnelli> Good to know...
142 2019-01-25T07:09:27  <echeveria> mean.
143 2019-01-25T07:09:45  <jonasschnelli> however, a travis macOS job would probably be a good thing...
144 2019-01-25T07:10:06  <sipa> agree.
145 2019-01-25T07:10:17  <jonasschnelli> Curious to know if you can run the GUI process and take a screenshot...
146 2019-01-25T07:18:24  *** ThomasLuong has quit IRC
147 2019-01-25T07:23:23  *** trillhc3 has joined #bitcoin-core-dev
148 2019-01-25T07:23:23  *** trillhc2 has quit IRC
149 2019-01-25T07:31:53  *** bitcoin-git has joined #bitcoin-core-dev
150 2019-01-25T07:31:53  <bitcoin-git> [bitcoin] Empact opened pull request #15257: Scripts and tools: Bump flake8 to 3.6.0 (master...flake-36) https://github.com/bitcoin/bitcoin/pull/15257
151 2019-01-25T07:31:53  *** bitcoin-git has left #bitcoin-core-dev
152 2019-01-25T07:47:46  *** bitcoin-git has joined #bitcoin-core-dev
153 2019-01-25T07:47:46  <bitcoin-git> [bitcoin] Empact opened pull request #15258: Scripts and tools: Fix devtools/copyright_header.py to always honor exclusions (master...copyright-header-abs) https://github.com/bitcoin/bitcoin/pull/15258
154 2019-01-25T07:47:46  *** bitcoin-git has left #bitcoin-core-dev
155 2019-01-25T08:08:39  *** hebasto has joined #bitcoin-core-dev
156 2019-01-25T08:23:35  *** BGL has quit IRC
157 2019-01-25T08:28:50  *** promag has joined #bitcoin-core-dev
158 2019-01-25T08:33:26  *** promag has quit IRC
159 2019-01-25T08:45:35  <kallewoof> I can't make the meetings as always, but would like to add #13756 to priority for review list, unless people object. (ping wumpus fanquake ...)
160 2019-01-25T08:45:38  <gribble> https://github.com/bitcoin/bitcoin/issues/13756 | wallet: "avoid_reuse" wallet flag for improved privacy by kallewoof · Pull Request #13756 · bitcoin/bitcoin · GitHub
161 2019-01-25T08:54:47  *** JackH has quit IRC
162 2019-01-25T08:57:00  *** miknotauro has quit IRC
163 2019-01-25T09:12:55  *** IGHOR has quit IRC
164 2019-01-25T09:32:39  *** jungly has joined #bitcoin-core-dev
165 2019-01-25T09:34:39  *** BGL has joined #bitcoin-core-dev
166 2019-01-25T09:35:26  *** JackH has joined #bitcoin-core-dev
167 2019-01-25T09:36:38  *** bitcoin-git has joined #bitcoin-core-dev
168 2019-01-25T09:36:38  <bitcoin-git> [bitcoin] domob1812 opened pull request #15259: Use real HTTP bind address in curl RPC help (master...decoupled-rpchelp) https://github.com/bitcoin/bitcoin/pull/15259
169 2019-01-25T09:36:38  *** bitcoin-git has left #bitcoin-core-dev
170 2019-01-25T09:37:27  *** bitcoin-git has joined #bitcoin-core-dev
171 2019-01-25T09:37:27  <bitcoin-git> [bitcoin] domob1812 closed pull request #15181: Use correct RPC port in help curl example (master...rpchelp-port) https://github.com/bitcoin/bitcoin/pull/15181
172 2019-01-25T09:37:27  *** bitcoin-git has left #bitcoin-core-dev
173 2019-01-25T09:42:30  *** kallewoof has quit IRC
174 2019-01-25T09:51:23  <provoostenator> kallewoof: +1 for the avoid_reuse PR. I'll also do a git range-diff on it to what changes since my last ACK
175 2019-01-25T10:03:52  *** kexkey has quit IRC
176 2019-01-25T10:07:40  *** setpill has joined #bitcoin-core-dev
177 2019-01-25T10:09:40  *** Zenton has joined #bitcoin-core-dev
178 2019-01-25T10:12:23  *** spinza has quit IRC
179 2019-01-25T10:31:22  *** spinza has joined #bitcoin-core-dev
180 2019-01-25T10:32:10  <meshcollider> I'm not sure whether I'll have internet at the start of the wallet meeting, so sipa can you host it this week please :)
181 2019-01-25T10:48:34  <hebasto> provoostenator: thanks
182 2019-01-25T11:07:01  *** trillhc3 has quit IRC
183 2019-01-25T11:27:47  *** Skirmant has joined #bitcoin-core-dev
184 2019-01-25T11:46:49  *** IGHOR has joined #bitcoin-core-dev
185 2019-01-25T11:48:19  *** bitcoin-git has joined #bitcoin-core-dev
186 2019-01-25T11:48:19  <bitcoin-git> [bitcoin] DesWurstes closed pull request #15151: [Consensus] [P2P] [Utils and libraries] Cleanup (master...patch-6) https://github.com/bitcoin/bitcoin/pull/15151
187 2019-01-25T11:48:19  *** bitcoin-git has left #bitcoin-core-dev
188 2019-01-25T11:50:21  *** IGHOR has joined #bitcoin-core-dev
189 2019-01-25T11:53:26  *** lnostdal has quit IRC
190 2019-01-25T11:54:27  *** lnostdal has joined #bitcoin-core-dev
191 2019-01-25T11:55:23  *** IGHOR has quit IRC
192 2019-01-25T11:58:01  *** IGHOR has joined #bitcoin-core-dev
193 2019-01-25T13:00:56  *** luke-jr has quit IRC
194 2019-01-25T13:10:02  *** rh0nj has quit IRC
195 2019-01-25T13:11:07  *** rh0nj has joined #bitcoin-core-dev
196 2019-01-25T13:19:34  <hebasto> promag: FYI, after merging #15101 the <qt/walletmodel.h> header gets required even with --disable-wallet (https://github.com/bitcoin/bitcoin/pull/14879#issuecomment-457569766)
197 2019-01-25T13:19:37  <gribble> https://github.com/bitcoin/bitcoin/issues/15101 | gui: Add WalletController by promag · Pull Request #15101 · bitcoin/bitcoin · GitHub
198 2019-01-25T13:23:34  <hebasto> could someone restart travis for #15239?
199 2019-01-25T13:23:36  <gribble> https://github.com/bitcoin/bitcoin/issues/15239 | scripts and tools: Move non-linux build source tarballs to "bitcoin-binaries/version" directory by hebasto · Pull Request #15239 · bitcoin/bitcoin · GitHub
200 2019-01-25T13:40:44  *** hebasto has quit IRC
201 2019-01-25T14:37:24  *** lnostdal has quit IRC
202 2019-01-25T14:38:06  *** spinza has quit IRC
203 2019-01-25T14:38:47  *** lnostdal has joined #bitcoin-core-dev
204 2019-01-25T14:44:53  *** Aaronvan_ is now known as AaronvanW
205 2019-01-25T14:45:23  *** Guyver2 has joined #bitcoin-core-dev
206 2019-01-25T15:03:14  *** spinza has joined #bitcoin-core-dev
207 2019-01-25T15:05:05  *** setpill has quit IRC
208 2019-01-25T15:07:48  *** lnostdal has quit IRC
209 2019-01-25T15:10:23  *** spaced0ut has joined #bitcoin-core-dev
210 2019-01-25T15:17:49  *** phwalkr has joined #bitcoin-core-dev
211 2019-01-25T15:23:19  *** lnostdal has joined #bitcoin-core-dev
212 2019-01-25T15:30:41  *** miknotauro has joined #bitcoin-core-dev
213 2019-01-25T15:34:36  *** pinheadmz has joined #bitcoin-core-dev
214 2019-01-25T15:48:31  *** michaelsdunn1 has joined #bitcoin-core-dev
215 2019-01-25T15:48:53  *** pinheadmz has quit IRC
216 2019-01-25T16:14:13  <instagibbs> would someone be annoyed if I changed all "transaction hash" public-facing docs/help to say "transaction id" or is that over-pedanticism
217 2019-01-25T16:16:29  *** hebasto has joined #bitcoin-core-dev
218 2019-01-25T16:20:38  *** luke-jr has joined #bitcoin-core-dev
219 2019-01-25T16:23:50  *** bitcoin-git has joined #bitcoin-core-dev
220 2019-01-25T16:23:50  <bitcoin-git> [bitcoin] lcornelius101 opened pull request #15261: update firmwear (master...master) https://github.com/bitcoin/bitcoin/pull/15261
221 2019-01-25T16:23:50  *** bitcoin-git has left #bitcoin-core-dev
222 2019-01-25T16:26:23  *** bitcoin-git has joined #bitcoin-core-dev
223 2019-01-25T16:26:23  <bitcoin-git> [bitcoin] practicalswift opened pull request #15262: build: Enable C++14 in build, require C++14 compiler. (master...c++14) https://github.com/bitcoin/bitcoin/pull/15262
224 2019-01-25T16:26:23  *** bitcoin-git has left #bitcoin-core-dev
225 2019-01-25T16:30:45  *** lukedashjr has joined #bitcoin-core-dev
226 2019-01-25T16:34:26  *** luke-jr has quit IRC
227 2019-01-25T16:35:23  *** lukedashjr is now known as luke-jr
228 2019-01-25T16:41:23  *** jungly has quit IRC
229 2019-01-25T16:41:32  *** miknotauro has quit IRC
230 2019-01-25T16:56:19  *** bitcoin-git has joined #bitcoin-core-dev
231 2019-01-25T16:56:19  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/d14ef5721ffc...ab46fe6ec1b3
232 2019-01-25T16:56:19  <bitcoin-git> bitcoin/master f618c58 Ben Woosley: Docs: Update python docs to reflect that wildcard imports are disallowed
233 2019-01-25T16:56:19  <bitcoin-git> bitcoin/master ab46fe6 MarcoFalke: Merge #15249: Docs: Update python docs to reflect that wildcard imports are disallowed...
234 2019-01-25T16:56:19  *** bitcoin-git has left #bitcoin-core-dev
235 2019-01-25T16:56:51  *** pinheadmz has joined #bitcoin-core-dev
236 2019-01-25T16:57:13  *** bitcoin-git has joined #bitcoin-core-dev
237 2019-01-25T16:57:14  <bitcoin-git> [bitcoin] MarcoFalke closed pull request #15249: Docs: Update python docs to reflect that wildcard imports are disallowed (master...wildcard-imports-doc) https://github.com/bitcoin/bitcoin/pull/15249
238 2019-01-25T16:57:14  *** bitcoin-git has left #bitcoin-core-dev
239 2019-01-25T17:08:56  *** Zenton has quit IRC
240 2019-01-25T17:12:32  *** JackH has quit IRC
241 2019-01-25T17:30:51  *** ThomasLuong has joined #bitcoin-core-dev
242 2019-01-25T18:06:58  *** Murch has joined #bitcoin-core-dev
243 2019-01-25T18:11:40  *** mistergold has joined #bitcoin-core-dev
244 2019-01-25T18:22:07  *** jarthur has joined #bitcoin-core-dev
245 2019-01-25T18:31:36  *** miknotauro has joined #bitcoin-core-dev
246 2019-01-25T18:37:26  *** bitcoin-git has joined #bitcoin-core-dev
247 2019-01-25T18:37:26  <bitcoin-git> [bitcoin] sipa opened pull request #15263: Descriptor expansions only need pubkey entries for PKH/WPKH (master...201901_flatprovider_pkh) https://github.com/bitcoin/bitcoin/pull/15263
248 2019-01-25T18:37:26  *** bitcoin-git has left #bitcoin-core-dev
249 2019-01-25T18:44:55  *** mistergold has quit IRC
250 2019-01-25T18:47:32  *** DeanGuss has quit IRC
251 2019-01-25T18:48:05  *** DeanGuss has joined #bitcoin-core-dev
252 2019-01-25T18:57:11  <provoostenator> Do we have a wallet meeting today or am I off by one again?
253 2019-01-25T18:59:56  *** mistergold has joined #bitcoin-core-dev
254 2019-01-25T19:01:07  <achow101> wallet meeting?
255 2019-01-25T19:01:16  <sipa> present
256 2019-01-25T19:01:46  <achow101> <meshcollider> I'm not sure whether I'll have internet at the start of the wallet meeting, so sipa can you host it this week please :)
257 2019-01-25T19:03:15  <provoostenator> Suggested topic: wallet goals for 0.18
258 2019-01-25T19:04:02  <sipa> do we have sufficient people for meeting?
259 2019-01-25T19:05:14  *** dermoth has quit IRC
260 2019-01-25T19:05:19  <achow101> maybe after the mass ping?
261 2019-01-25T19:05:41  *** dermoth has joined #bitcoin-core-dev
262 2019-01-25T19:06:03  <sipa> engage the mass ping.
263 2019-01-25T19:07:38  <gmaxwell> no pingy?
264 2019-01-25T19:08:18  <achow101> #bitcoin-core-dev Wallet Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101 meshcollider
265 2019-01-25T19:08:19  <achow101>  jnewbery maaku fanquake promag provoostenator aj Chris_Stewart_5 dongcarl gwillen jamesob ken281221 ryanofsky gleb
266 2019-01-25T19:08:39  <gwillen> good morning programs
267 2019-01-25T19:08:58  <sipa> #startmeeting
268 2019-01-25T19:08:58  <lightningbot> Meeting started Fri Jan 25 19:08:58 2019 UTC.  The chair is sipa. Information about MeetBot at http://wiki.debian.org/MeetBot.
269 2019-01-25T19:08:58  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
270 2019-01-25T19:09:03  <meshcollider> Hi yeah my internet is very spotty so I probably won't be here for most of this sorry :)
271 2019-01-25T19:09:20  <sipa> okay
272 2019-01-25T19:09:53  <provoostenator> https://github.com/bitcoin/bitcoin/milestone/35
273 2019-01-25T19:09:58  <sipa> #topic wallet goals for 0.18
274 2019-01-25T19:10:26  <gmaxwell> This is relevant
275 2019-01-25T19:10:27  <gmaxwell> 00:45:35 < kallewoof> I can't make the meetings as always, but would like to add #13756 to priority for review list, unless people object. (ping
276 2019-01-25T19:10:27  <gmaxwell>                       wumpus fanquake ...)
277 2019-01-25T19:10:27  <gmaxwell> 00:45:38 < gribble> https://github.com/bitcoin/bitcoin/issues/13756 | wallet: "avoid_reuse" wallet flag for improved privacy by kallewoof · Pull
278 2019-01-25T19:10:27  <gmaxwell>                     Request #13756 · bitcoin/bitcoin · GitHub
279 2019-01-25T19:10:29  <gribble> https://github.com/bitcoin/bitcoin/issues/13756 | wallet: "avoid_reuse" wallet flag for improved privacy by kallewoof · Pull Request #13756 · bitcoin/bitcoin · GitHub
280 2019-01-25T19:10:32  <gribble> https://github.com/bitcoin/bitcoin/issues/13756 | wallet: "avoid_reuse" wallet flag for improved privacy by kallewoof · Pull Request #13756 · bitcoin/bitcoin · GitHub
281 2019-01-25T19:10:35  <provoostenator> +1
282 2019-01-25T19:10:40  <sipa> gmaxwell: thanks
283 2019-01-25T19:11:38  <sipa> gwillen: will you have time in the near future to rebase/address comments in #14978 ?
284 2019-01-25T19:11:38  <provoostenator> I'd also love to get a number of pull requests into this release that would allow using achow101's HWI library:
285 2019-01-25T19:11:42  <gribble> https://github.com/bitcoin/bitcoin/issues/14978 | Factor out PSBT utilities from RPCs for use in GUI code; related refactoring. by gwillen · Pull Request #14978 · bitcoin/bitcoin · GitHub
286 2019-01-25T19:12:12  <provoostenator> Though that may be a bit ambitious.
287 2019-01-25T19:12:18  <achow101> how likely is it for #14491, #14075, and #14021 to get into 0.18?
288 2019-01-25T19:12:22  <gribble> https://github.com/bitcoin/bitcoin/issues/14491 | Allow descriptor imports with importmulti by MeshCollider · Pull Request #14491 · bitcoin/bitcoin · GitHub
289 2019-01-25T19:12:25  <gribble> https://github.com/bitcoin/bitcoin/issues/14075 | Import watch only pubkeys to the keypool if private keys are disabled by achow101 · Pull Request #14075 · bitcoin/bitcoin · GitHub
290 2019-01-25T19:12:27  <gribble> https://github.com/bitcoin/bitcoin/issues/14021 | Import key origin data through descriptors in importmulti by achow101 · Pull Request #14021 · bitcoin/bitcoin · GitHub
291 2019-01-25T19:12:38  <achow101> (those are required for HWI)
292 2019-01-25T19:13:46  <provoostenator> I think descriptor imports is pretty close
293 2019-01-25T19:14:07  <gwillen> sipa: yes, I will definitely try to go another round on 14978 ASAP
294 2019-01-25T19:14:37  <sipa> i'm hoping to open a PR for signing with a descriptor soon, but ideally on top of your PR
295 2019-01-25T19:14:44  <provoostenator> The key origin PR is tiny (on top of desciptor), with lots of tests
296 2019-01-25T19:15:02  <sipa> provoostenator: cool, so that should be easy once descriptor import is in
297 2019-01-25T19:15:15  <provoostenator> The keypool import stuff still has me a bit in doubt what the right approach is.
298 2019-01-25T19:15:21  <achow101> gwillen: I rebased and updated #13932 last night
299 2019-01-25T19:15:24  <gribble> https://github.com/bitcoin/bitcoin/issues/13932 | Additional utility RPCs for PSBT by achow101 · Pull Request #13932 · bitcoin/bitcoin · GitHub
300 2019-01-25T19:16:01  <provoostenator> I commented "I would prefer if TopUpKeyPool can deal with imported keys.", though I'm not sure how realistic that is without a complete wallet descriptor support redo.
301 2019-01-25T19:16:03  <gmaxwell> Is there anything we can do to head off funds loss from typos/copypaste errors with decriptor importing?  The use of descriptors as user/api handled key material seems like a step backward for Bitcoin,  as we're now introducing ways for simple typos (or clbuttic errors) to cause funds to go off to space.
302 2019-01-25T19:16:45  <provoostenator> gmaxwell: we could make importing descriptors without xpub fail, unless opted in?
303 2019-01-25T19:16:53  <gwillen> achow101: sweet, thanks! I will go look.
304 2019-01-25T19:16:59  <provoostenator> (xpub or other checksummed approach)
305 2019-01-25T19:17:07  <gwillen> sipa: ok, I will prioritize, thanks
306 2019-01-25T19:17:08  <sipa> gmaxwell: the xpubs inside descriptors have a checksum, though the paths/functions don't
307 2019-01-25T19:17:21  <gmaxwell> provoostenator: if the part of the descriptor outside of the xpub is corrupted funds are still lost.
308 2019-01-25T19:17:45  <gmaxwell> That may be a little less likely, but its still exposed.
309 2019-01-25T19:17:52  <provoostenator> That seems somewhat unlikely though for the most basic descriptors.
310 2019-01-25T19:18:19  <provoostenator> Because the parser will fail, unless the error happens to produce another valid descriptor.
311 2019-01-25T19:18:55  <gmaxwell> What does wsh(multi(3,xpub661MyMwAqRbcFW31YEwpkMuc5THy2PSt5bDMsktWQcFF8syAmRUapSCGu8ED9W6oDMSgv6Zz8idoc4a6mr8BDzTJY47LJhkJ8UB7WEGuduB/1/0/*,xpub69H7F5d8KSRgmmdJg2KhpAK8SR3DjMwAdkxj3ZuxV27CprR9LgpeyGmXUbC6wb7ERfvrnKZjXoUmmDznezpbZb7ap6r1D3tgFxHmwMkQTPH/0/0/*)) do?
312 2019-01-25T19:19:28  <gmaxwell> (3 of 2 multisig)
313 2019-01-25T19:19:32  <provoostenator> We could use the Electrum style xpub, ypub, zpub, etc-pub to indicate what type we expect the descriptor to be. But there's no software that could produce the data.
314 2019-01-25T19:20:08  <provoostenator> (a generic problem if we had any kind of checksum mechanism to the descriptor language)
315 2019-01-25T19:20:21  <gmaxwell> in any case, filtering to xpubs unless overridden seems like a good idea, at least.
316 2019-01-25T19:20:44  <gwillen> given that the xpubs themselves already have a checksum, you could add a checksum of _just_ everything else to the end, it could be very short and still be sufficient
317 2019-01-25T19:20:46  <sipa> also, anything with a private key has a checksum
318 2019-01-25T19:20:50  <gmaxwell> but it still seems far too dangerous to ever have users using directly to import keys.
319 2019-01-25T19:20:59  <provoostenator> 3 of 2 multisig should hopefully fail as an invalid descriptor?  Could be worth adding a test for that...
320 2019-01-25T19:21:52  <provoostenator> gwillen: the problem is, what software will make the checksum? We'd have to define a standard for that too. Maybe that's a good thing.
321 2019-01-25T19:22:11  <gmaxwell> one could adjust the descriptor language to support a ",checksum" at the end. Even if it just blindly supported them with the checkvalue truncated to facilitate editing, it would provide some protection against other corruption. I dunno.
322 2019-01-25T19:22:28  <gwillen> provoostenator: yeah, we would have to go "oops, lack of checksum was an omission in the spec, new spec"
323 2019-01-25T19:22:43  <gmaxwell> I don't really understand how it got to this point. When descriptors were first defined, I didn't expect them to be used for key management in liue of importing addresses.
324 2019-01-25T19:22:44  <gwillen> which makes sense if they are going to be an interchange format, which it seems they are otherwise well-suited for, except this issue
325 2019-01-25T19:22:44  <sipa> gwillen: that's the great thing about not having a spec
326 2019-01-25T19:22:53  <achow101> provoostenator: it's not like descriptors are really standardized yet though...
327 2019-01-25T19:22:54  <gwillen> sipa: :D
328 2019-01-25T19:23:22  <gmaxwell> I do worry about breaking editability. Though there could just be a simple utility(function) to recompute the checksum on any descriptor.
329 2019-01-25T19:23:32  <gmaxwell> That you'd just use after editing, if you intended to edit.
330 2019-01-25T19:23:38  <provoostenator> gmaxwell: the optional ,checksum makes sense. And then importmulti could refuse descriptors without such checksum, unless "I-know-what-I'm-doing" is added to the command.
331 2019-01-25T19:23:49  <sipa> provoostenator, gmaxwell: that seems reasonable
332 2019-01-25T19:24:13  <sipa> i don't mind breaking compatibility at this point
333 2019-01-25T19:24:19  <provoostenator> Yeah, we would need some utility to calculate the checksum for those making descriptors manually.
334 2019-01-25T19:24:34  <gmaxwell> Seems straightforward.
335 2019-01-25T19:25:15  <sipa> gmaxwell: i think i imagined initially that indeed there would be syntactic sugar encodings for common subsets of descriptors (like zpub etc) with checksums etc
336 2019-01-25T19:25:59  <sipa> but it seems people (myself included) are pretty excited about having the descriptor itself be a visible thing... so adding a checksum to the descriptor itself makes sense
337 2019-01-25T19:26:18  <gmaxwell> Better to fix it now, if not later.   I wonder if we need the 'accept import override' if there is a utility function that just adds the checksum?
338 2019-01-25T19:26:45  <gmaxwell> Yea, I think they're cool, I'm excited about having them available too.  Just dreading the footgun. But it seems there is a solution.
339 2019-01-25T19:26:47  <gwillen> the voice in the back of my head worries about the checksum being an optional thing stuck on the end, that people will strip it or ignore it
340 2019-01-25T19:26:53  <gwillen> but I don't have a better idea in hand
341 2019-01-25T19:27:15  * sipa fires up BCH code search?
342 2019-01-25T19:27:19  <gwillen> there's no obvious better place to put it
343 2019-01-25T19:27:53  <gmaxwell> gwillen: well we could mandate it, and not have anything that ignores it, but have a utility function that regenerates.
344 2019-01-25T19:28:05  <gmaxwell> If someone wants to do extra work to screw themselves, oh well.
345 2019-01-25T19:28:08  <instagibbs> Put bytes in pseudorandom places, annoying to extract and by then, might as well validate it
346 2019-01-25T19:28:15  <instagibbs> (sarcasm font)
347 2019-01-25T19:28:27  <gmaxwell> But the default should be as safe as we can make it without undue tradeoffs.
348 2019-01-25T19:28:46  <gmaxwell> sipa: whats the character set of descriptors?
349 2019-01-25T19:28:53  <provoostenator> Or you could design the descriptor language such that there's no way to accidentally break it with a N character mistake.
350 2019-01-25T19:29:16  <gmaxwell> sipa: (does it form a field...)
351 2019-01-25T19:29:43  <gmaxwell> provoostenator: it's easy to do that if the number of candidate characters is a prime power. Otherwise we only know how to make it immune to a 1 character mistake.
352 2019-01-25T19:30:03  <provoostenator> I'm in favor of prime power.
353 2019-01-25T19:30:33  <gmaxwell> I don't think right now descriptors have a defined charset?
354 2019-01-25T19:30:33  *** Randolf has joined #bitcoin-core-dev
355 2019-01-25T19:30:38  <sipa> gmaxwell: indeed
356 2019-01-25T19:30:49  <sipa> but at least 0-9 a-z A-Z / * [ ]
357 2019-01-25T19:30:54  <gmaxwell> alphanum + some extras like /,()[]* ?
358 2019-01-25T19:31:02  <gmaxwell> oh right mixed case.
359 2019-01-25T19:31:26  <provoostenator> Pubkeys and privkeys have defined charset, so you can include the checksum part of those in the total checksum? (or just checksum the whole thing)
360 2019-01-25T19:31:28  <gwillen> can't you always just add "virtual" characters to the charset until you reach a prime power
361 2019-01-25T19:31:36  <gwillen> at the expense of increasing checksum size a bit
362 2019-01-25T19:31:43  *** BITTREX has joined #bitcoin-core-dev
363 2019-01-25T19:31:56  <gmaxwell> Checksum can be defined over a smaller charset, with a folding routine so that outside of character set characters get treated as some inside set character for checksum purposes.
364 2019-01-25T19:32:11  <gmaxwell> gwillen: no, because the check digit could be one of those characters.
365 2019-01-25T19:33:19  <gmaxwell> You could however make the checksum base 25, encoded to alpha, and then fold all other characters to it... in any case, probably not something to hash out in the meeting.
366 2019-01-25T19:33:38  <gmaxwell> and doing something dumb (sha256, ugh) would be still better than nothing.
367 2019-01-25T19:33:57  <sipa> we can reuse bech32 character set easily
368 2019-01-25T19:34:11  <sipa> and use something like what bech32 does for the prefix
369 2019-01-25T19:34:22  <gmaxwell> sipa: with the hrp han... right...
370 2019-01-25T19:34:25  <sipa> (which works for all of ascii)
371 2019-01-25T19:34:34  <gmaxwell> doesn't have the great distance properties, but probably good enough.
372 2019-01-25T19:34:57  <sipa> before we move to a different topic... what general length of checksum are people thinking is acceptable?
373 2019-01-25T19:35:07  <gwillen> how would people feel about the syntax being something like "(descriptor,checksum)" instead of "descriptor,checksum"
374 2019-01-25T19:35:26  <gwillen> adding two extra characters is kind of silly but it feels to me like it would make the checksum less likely to get lost in copy-paste confusion
375 2019-01-25T19:35:58  <gmaxwell> sipa: descriptors are already long, I don't see a problem with adding 5-8 extra characters.
376 2019-01-25T19:36:18  <gwillen> (also, the checksum charset should exclude "()[]*/.", it should be alphanum, for the same reason)
377 2019-01-25T19:36:22  <provoostenator> Sticking to bech32 characters would be nice.
378 2019-01-25T19:36:42  <provoostenator> Because longer term it's probably nice if desciptors can be printed as QR codes.
379 2019-01-25T19:36:50  <provoostenator> I'm thinking paper backups.
380 2019-01-25T19:36:53  <provoostenator> (of pub keys)
381 2019-01-25T19:37:05  <gmaxwell> I guess spaces are syntatically meaningless in descriptors? if so checksum should be computed after stripping them.
382 2019-01-25T19:37:18  *** lnostdal has quit IRC
383 2019-01-25T19:37:22  <instagibbs> spaces are currently rejected anywhere
384 2019-01-25T19:37:26  <instagibbs> in Core
385 2019-01-25T19:37:27  <gwillen> oof, it would be good if descriptor format were canonical, no spaces
386 2019-01-25T19:37:29  <gmaxwell> provoostenator: well unfortunately the other characters in descriptors make QR codes inefficient.
387 2019-01-25T19:37:30  <gwillen> :+1:
388 2019-01-25T19:37:34  <gmaxwell> oh okay, cool.
389 2019-01-25T19:37:44  <sipa> gmaxwell: i think the parser will reject anything with spaces
390 2019-01-25T19:37:52  <instagibbs> sipa, it will(I've lost time figuring this out)
391 2019-01-25T19:38:01  <instagibbs> the error message is quite vague
392 2019-01-25T19:38:03  <gmaxwell> instagibbs: improve error messages?
393 2019-01-25T19:38:07  <instagibbs> gmaxwell, yeah
394 2019-01-25T19:38:33  <gmaxwell> sorry for the derail, but I'm glad there seems to be support for fixing this.
395 2019-01-25T19:39:01  <sipa> gmaxwell: fwiw, your 3-of-2 multisig descriptor is rejected
396 2019-01-25T19:39:37  <instagibbs> I mean you might accidentally do a wrong number or something, 1-of-2 instead of 2-of-2, similar failure
397 2019-01-25T19:39:38  <gmaxwell> sipa: thats great.
398 2019-01-25T19:39:50  <gmaxwell> or 2 of 2 instead of 1 of 2.
399 2019-01-25T19:39:57  <gmaxwell> sipa: is 0 of 2 rejected? :P
400 2019-01-25T19:39:59  <sipa> and i think p2sh descriptors with multisig redeemscripts over 510 bytes are also rejected
401 2019-01-25T19:40:12  <sipa> gmaxwell: yes, 0 of 2 is also rejected
402 2019-01-25T19:40:20  <gmaxwell> The fact that a lot of mistakes will fail the parser also favors a weaker check.
403 2019-01-25T19:40:32  <sipa> ok, let's move to a different topic
404 2019-01-25T19:40:36  <sipa> if there are others?
405 2019-01-25T19:43:01  <gmaxwell> Is anyone working on improving avoidpartialspends?
406 2019-01-25T19:43:02  <jnewbery> for wallet goals for v0.18, I'm hopeful we can finish multiwallet in the GUI
407 2019-01-25T19:43:12  <jnewbery> promag's been doing great work
408 2019-01-25T19:43:17  <gmaxwell> It's off by default, which makes it kinda useless in terms of overall privacy effects.
409 2019-01-25T19:43:24  <sipa> gmaxwell: what needs to be done?
410 2019-01-25T19:43:57  <gmaxwell> sipa: It needs to grow a value threshold. "Avoidpartialspends unless the fee would increase by more than X"  which we could ship enabled.
411 2019-01-25T19:44:28  <gmaxwell> And privacy maniacs could turn it on unconditionally, but everyone would at least be happy with a threshold of 0. :P
412 2019-01-25T19:44:59  <gmaxwell> (I think we should set the threshold by default to the dust limit or something similar, the exact value doesn't matter too much)
413 2019-01-25T19:45:22  <gmaxwell> Reminder: this is the wallet feature that causes it to try to spend all payments to a reused address at once.
414 2019-01-25T19:45:50  <gmaxwell> Doing so can cause higher fees, so its off by default, and as a reasult I doubt anyone uses it.
415 2019-01-25T19:45:55  <gmaxwell> result*
416 2019-01-25T19:45:58  <sipa> right
417 2019-01-25T19:46:10  <sipa> i agree that makes it pretty pointless
418 2019-01-25T19:46:59  <gmaxwell> sometimes it doesn't even increase fees at all, I know of now reason why people wouldn't prefer it in at least that case.  But even when it causes higher fees, usually it's just pulling in fees from the future, not really paying more.
419 2019-01-25T19:47:14  <gmaxwell> This returns to a larger open question about fees now vs fees later.
420 2019-01-25T19:47:45  <sdaftuar> gmaxwell: one concern i had with unconditional use of avoidpartialspends was edge cases with small value inputs.  eg i dust your wallet with junk, and cause you trouble
421 2019-01-25T19:47:59  <sdaftuar> i think we mitigated that mostly, maybe entirely, with a cap on the number of inputs we could pull in?
422 2019-01-25T19:48:23  <gmaxwell> and/or with a threshold you'll pay in extra fees?
423 2019-01-25T19:48:32  <sdaftuar> yeah, we should just do that.
424 2019-01-25T19:49:06  <gmaxwell> but I agree there should be a cap on the group size, but I'm not sure how best to do that.
425 2019-01-25T19:50:11  <gmaxwell> For the longer term question, I think eventually we want the wallet fee estimation to have an idea of "fees expected to be higher/lower in the future", and in response we should favor or disfavor including more inputs.
426 2019-01-25T19:50:24  <sipa> gmaxwell: don'
427 2019-01-25T19:50:28  <sipa> gmaxwell: don't we already have that?
428 2019-01-25T19:50:40  <sipa> (using long term fee estimation)
429 2019-01-25T19:51:27  <gmaxwell> I think we do in one really narrow case (we use the long term fee for estimating the cost of spending the change output in BNB)? I don't think we have it more generally.
430 2019-01-25T19:52:19  *** lnostdal has joined #bitcoin-core-dev
431 2019-01-25T19:52:25  <gmaxwell> I think because fees have been low most of the time in the last 6 months not a lot of attention is going to them, ... which is unfortunate at least in terms of right now would be a great time for wallets to be agressively aggregating.
432 2019-01-25T19:53:07  *** BITTREX has quit IRC
433 2019-01-25T19:53:08  <gmaxwell> (well not litterally right now, there are fees at the moment.. :P)
434 2019-01-25T19:53:35  <sipa> right
435 2019-01-25T19:54:21  <gmaxwell> so okay well that would be a bonus feature for avoidpartial: use long term vs current to switch between threshold vs always on.
436 2019-01-25T19:54:55  <gmaxwell> If fees are high only be willing to pay slightly more, if fees are low use it.
437 2019-01-25T19:55:50  <jnewbery> BitGo claim to already do 'predictive UTXO management' (ie use more inputs when fees are expected to be higher in future, and fewer inputs when fees are expected to be lower in future)
438 2019-01-25T19:56:26  <gmaxwell> it's been discussed a lot in the past, it's just not clear how well it can work without a human hand available to rescue it if it becomes stupid.
439 2019-01-25T19:57:17  <gmaxwell> It's a lot easier to do smart stuff if you can count on an expert non-artifical-intelligence to override if it goes dumb, you don't have to solve ever corner case or potential avenue for abuse.
440 2019-01-25T19:58:15  *** bitcoin-git has joined #bitcoin-core-dev
441 2019-01-25T19:58:15  <bitcoin-git> [bitcoin] jamesob opened pull request #15264: validation: remove useless uncache accounting in ATMPW (master...2019-01-remove-useless-uncaching-atmpw) https://github.com/bitcoin/bitcoin/pull/15264
442 2019-01-25T19:58:15  *** bitcoin-git has left #bitcoin-core-dev
443 2019-01-25T19:59:48  <sipa> last half minute topic?
444 2019-01-25T20:00:25  <sipa> #endmeeting
445 2019-01-25T20:00:25  <lightningbot> Meeting ended Fri Jan 25 20:00:25 2019 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
446 2019-01-25T20:00:25  <lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2019/bitcoin-core-dev.2019-01-25-19.08.html
447 2019-01-25T20:00:25  <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2019/bitcoin-core-dev.2019-01-25-19.08.txt
448 2019-01-25T20:00:25  <lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2019/bitcoin-core-dev.2019-01-25-19.08.log.html
449 2019-01-25T20:00:55  *** DeanGuss has quit IRC
450 2019-01-25T20:01:07  <jnewbery> If anyone else is interested in getting multiwallet GUI merged for 0.18, PRs are tracked in #13059
451 2019-01-25T20:01:08  <gribble> https://github.com/bitcoin/bitcoin/issues/13059 | Dynamic wallet load / create / unload · Issue #13059 · bitcoin/bitcoin · GitHub
452 2019-01-25T20:01:56  *** miknotauro has quit IRC
453 2019-01-25T20:08:50  *** BITTREX has joined #bitcoin-core-dev
454 2019-01-25T20:09:26  *** bitcoin-git has joined #bitcoin-core-dev
455 2019-01-25T20:09:26  <bitcoin-git> [bitcoin] sdaftuar opened pull request #15265: Flush without erasing cache during periodic and pruning flushes (master...2019-01-periodic-flush-dont-wipe) https://github.com/bitcoin/bitcoin/pull/15265
456 2019-01-25T20:09:26  *** bitcoin-git has left #bitcoin-core-dev
457 2019-01-25T20:15:26  *** BITTREX has quit IRC
458 2019-01-25T20:15:57  *** BITTREX has joined #bitcoin-core-dev
459 2019-01-25T20:23:08  <gmaxwell> talk of multiwallet gui makes me wonder if anyone is working on using BIP157 filters for rescan?  Personally I found multiwallet not super useful, due to the need to rescan wallets that were left unloaded, and it taking 8 hours to do so...
460 2019-01-25T20:27:16  *** laurentmt has joined #bitcoin-core-dev
461 2019-01-25T20:27:20  <sipa> gmaxwell: jimpo was working on that
462 2019-01-25T20:29:24  *** Zenton has joined #bitcoin-core-dev
463 2019-01-25T20:29:56  *** BITTREX has quit IRC
464 2019-01-25T20:31:42  *** Randolf has quit IRC
465 2019-01-25T20:45:34  *** hebasto has quit IRC
466 2019-01-25T20:45:34  *** laurentmt has quit IRC
467 2019-01-25T20:52:35  <provoostenator> gmaxwell sipa: re descriptor checksums, maybe we should just keep human readable descriptors without a checksum, and define a separate (bech32) serialization that has the same information.
468 2019-01-25T20:52:54  <provoostenator> And then recommend that computer programs don't pass around the human readable versions.
469 2019-01-25T20:53:20  <sipa> provoostenator: i was considering that too
470 2019-01-25T20:53:24  <provoostenator> (or we can do both, i.e. also adding a checksum for the human readable one)
471 2019-01-25T20:53:30  <gmaxwell> that seems unlikely to work, unless you'd actually suggest we refuse to accept the human readable ones as input?
472 2019-01-25T20:53:35  <provoostenator> But that also solves my checksum concern.
473 2019-01-25T20:53:40  <sipa> but i think it won't be used really, as it removes the human readability
474 2019-01-25T20:53:49  <sipa> and i think that reafability is part of the appeal
475 2019-01-25T20:54:02  <provoostenator> I think it's still useful for communication between programs.
476 2019-01-25T20:56:13  <sipa> another question is what length the code should be designed for
477 2019-01-25T20:56:16  <provoostenator> "But that also solves" (not sure what I as trying to say)
478 2019-01-25T20:56:46  <gmaxwell> sipa: "long" or at least a code which is distance 1 for arbritarily long would be good.
479 2019-01-25T20:58:22  <sipa> 1024 won't be long enough as a maximum
480 2019-01-25T20:58:42  <sipa> gmaxwell: every code is distance 1 ;)
481 2019-01-25T20:58:51  <sipa> (including no checksum at all)
482 2019-01-25T20:58:52  <provoostenator> I can't actually think of that many situations where I _want_ to type descriptors.
483 2019-01-25T20:59:14  <sipa> provoostenator: agree, but i may want to compose them
484 2019-01-25T20:59:22  <sipa> and copy paste them
485 2019-01-25T20:59:32  <sipa> gmaxwell: and every bch code is distance 2
486 2019-01-25T20:59:46  *** Krellan has joined #bitcoin-core-dev
487 2019-01-25T20:59:48  <sipa> at infinite length
488 2019-01-25T21:00:03  <sipa> the question is up to what length it is distance 3 and higher
489 2019-01-25T21:00:03  <provoostenator> Yes, composing makes sense. That's where plain text helps, and checksum is by definition pointless, because your brain is the source.
490 2019-01-25T21:01:01  <provoostenator> And calls like getaddressinfo should probably show both the human readable and the bch version
491 2019-01-25T21:01:37  *** bitcoin-git has joined #bitcoin-core-dev
492 2019-01-25T21:01:37  <bitcoin-git> [bitcoin] MarcoFalke opened pull request #15266: memory: Construct globals on first use (master...Mf1901-cofu) https://github.com/bitcoin/bitcoin/pull/15266
493 2019-01-25T21:01:37  *** bitcoin-git has left #bitcoin-core-dev
494 2019-01-25T21:01:38  <provoostenator> import should somewhat resist the human readable version
495 2019-01-25T21:01:55  <provoostenator> (except with a checksum)
496 2019-01-25T21:06:30  <provoostenator> It's basically similar to how PSBT is mostly moved around as base64 (and binary), but can be inspected as JSON.
497 2019-01-25T21:06:54  <provoostenator> Except descriptors are for more compact and lend themselves better to writing by hand.
498 2019-01-25T21:09:43  *** bitcoin-git has joined #bitcoin-core-dev
499 2019-01-25T21:09:44  <bitcoin-git> [bitcoin] jamesob closed pull request #15264: validation: remove useless uncache accounting in ATMPW (master...2019-01-remove-useless-uncaching-atmpw) https://github.com/bitcoin/bitcoin/pull/15264
500 2019-01-25T21:09:44  *** bitcoin-git has left #bitcoin-core-dev
501 2019-01-25T21:23:35  <sipa> provoostenator: if the checksum is just appended we don't really need two versions
502 2019-01-25T21:35:03  *** bitcoin-git has joined #bitcoin-core-dev
503 2019-01-25T21:35:03  <bitcoin-git> [bitcoin] jamesob opened pull request #15267: doc: explain AcceptToMemoryPoolWorker's coins_to_uncache (master...2019-01-atmpw-uncache-coins-doc) https://github.com/bitcoin/bitcoin/pull/15267
504 2019-01-25T21:35:03  *** bitcoin-git has left #bitcoin-core-dev
505 2019-01-25T21:40:55  *** ddustin has joined #bitcoin-core-dev
506 2019-01-25T21:48:17  *** promag has joined #bitcoin-core-dev
507 2019-01-25T21:52:12  *** emilengler has joined #bitcoin-core-dev
508 2019-01-25T21:53:05  <emilengler> Is there a good overview/documentation on how the communication between nodes works ? If yes, can someone provide a link ?
509 2019-01-25T21:56:47  <ddustin> emilengler: https://en.bitcoin.it/wiki/Protocol_documentation
510 2019-01-25T21:56:56  <emilengler> thank you
511 2019-01-25T21:59:05  *** mistergo1d has joined #bitcoin-core-dev
512 2019-01-25T21:59:44  *** millerti has joined #bitcoin-core-dev
513 2019-01-25T22:02:27  *** mistergold has quit IRC
514 2019-01-25T22:11:05  *** jarthur has quit IRC
515 2019-01-25T22:16:26  *** Guyver2 has quit IRC
516 2019-01-25T22:28:36  *** spinza has quit IRC
517 2019-01-25T22:34:44  *** rex4539 has joined #bitcoin-core-dev
518 2019-01-25T22:44:25  *** jim_layhee has joined #bitcoin-core-dev
519 2019-01-25T22:47:10  <jim_layhee> hello all, I'm trying to run bitcoind in regtest. configured using ./configure --without-gui --disable-wallet on osx and i get the following error when trying to start using ./bitcoind -regtest -daemon
520 2019-01-25T22:47:15  <jim_layhee> Error: Unable to start HTTP server. See debug log for details.
521 2019-01-25T22:47:24  <jim_layhee> any ideas?
522 2019-01-25T22:47:38  *** spinza has joined #bitcoin-core-dev
523 2019-01-25T22:49:15  *** phwalkr has quit IRC
524 2019-01-25T22:51:52  <promag> thanks jnewbery
525 2019-01-25T22:52:12  <promag> sorry for the lack of updates.. had a bad week
526 2019-01-25T22:59:46  <sipa> gmaxwell: degree 8, distance 4, length 11275
527 2019-01-25T23:00:20  <sipa> (note that one character error may cause 2 weight difference due to expansion)
528 2019-01-25T23:02:16  *** michaelsdunn1 has quit IRC
529 2019-01-25T23:17:03  *** jim_layhee has quit IRC
530 2019-01-25T23:21:21  *** DeanGuss has joined #bitcoin-core-dev
531 2019-01-25T23:23:35  <gmaxwell> sipa: re earlier, I thought to support detecting one error at arbritary lengths the code had to have a +1 term.
532 2019-01-25T23:27:49  <sipa> gmaxwell: no
533 2019-01-25T23:28:06  <sipa> you're thinking off the ability to detect an arbitrarily large odd number of errors
534 2019-01-25T23:29:02  <gmaxwell> derp ah
535 2019-01-25T23:29:31  *** spaced0ut has quit IRC
536 2019-01-25T23:29:51  <gmaxwell> The fact that wanting a smaller checksum charset than the rest (to avoid including delimiters) results in error expansion is kind of annoying.