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.