12019-01-25T00:01:14 *** mistergo1d has quit IRC
22019-01-25T00:11:53 *** mn9495881 has joined #bitcoin-core-dev
32019-01-25T00:12:47 *** miknotauro has quit IRC
42019-01-25T00:15:57 *** Krellan has joined #bitcoin-core-dev
52019-01-25T00:24:26 *** Krellan has quit IRC
62019-01-25T00:27:53 *** pinheadmz has joined #bitcoin-core-dev
72019-01-25T00:29:54 *** promag has quit IRC
82019-01-25T00:31:05 *** Skirmant has joined #bitcoin-core-dev
92019-01-25T00:38:16 *** Krellan has joined #bitcoin-core-dev
102019-01-25T00:43:35 *** mistergold has quit IRC
112019-01-25T00:43:55 *** mistergold has joined #bitcoin-core-dev
122019-01-25T00:50:18 *** pinheadmz has quit IRC
132019-01-25T00:54:14 *** bitcoin-git has joined #bitcoin-core-dev
142019-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
152019-01-25T00:54:15 *** bitcoin-git has left #bitcoin-core-dev
162019-01-25T00:54:46 *** pinheadmz has joined #bitcoin-core-dev
172019-01-25T01:00:24 *** bitcoin-git has joined #bitcoin-core-dev
182019-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
192019-01-25T01:00:25 *** bitcoin-git has left #bitcoin-core-dev
202019-01-25T01:00:52 *** promag has joined #bitcoin-core-dev
212019-01-25T01:05:21 *** promag has quit IRC
222019-01-25T01:05:33 *** IzoooO has quit IRC
232019-01-25T01:07:01 *** cyber55 has joined #bitcoin-core-dev
242019-01-25T01:16:05 *** michaels_ has quit IRC
252019-01-25T01:18:35 *** mistergo1d has joined #bitcoin-core-dev
262019-01-25T01:18:52 *** ThomasLuong has quit IRC
272019-01-25T01:21:56 *** mistergold has quit IRC
282019-01-25T01:26:17 *** justan0theruser has joined #bitcoin-core-dev
292019-01-25T01:28:48 *** justanotheruser has quit IRC
302019-01-25T01:28:55 *** justan0theruser is now known as justanotheruser
312019-01-25T01:32:53 *** Evel-Knievel has quit IRC
322019-01-25T01:33:31 *** promag has joined #bitcoin-core-dev
332019-01-25T01:36:10 *** Evel-Knievel has joined #bitcoin-core-dev
342019-01-25T01:37:45 *** promag has quit IRC
352019-01-25T01:40:20 *** jgb has joined #bitcoin-core-dev
362019-01-25T01:40:44 *** jgb is now known as Guest29703
372019-01-25T01:53:26 *** mistergold has joined #bitcoin-core-dev
382019-01-25T01:56:56 *** mistergo1d has quit IRC
392019-01-25T02:00:17 *** dermoth has quit IRC
402019-01-25T02:06:34 *** pinheadmz has quit IRC
412019-01-25T02:11:08 *** ThomasLuong has joined #bitcoin-core-dev
422019-01-25T02:13:54 *** dermoth has joined #bitcoin-core-dev
432019-01-25T02:16:39 *** pinheadmz has joined #bitcoin-core-dev
442019-01-25T02:34:10 *** pinheadmz has quit IRC
452019-01-25T02:38:41 *** mistergo1d has joined #bitcoin-core-dev
462019-01-25T02:41:43 *** mistergold has quit IRC
472019-01-25T02:44:06 *** bitcoin-git has joined #bitcoin-core-dev
482019-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
492019-01-25T02:44:06 *** bitcoin-git has left #bitcoin-core-dev
502019-01-25T03:09:06 *** Krellan has quit IRC
512019-01-25T03:14:26 *** Skirmant has quit IRC
522019-01-25T03:44:46 *** bitcoin-git has joined #bitcoin-core-dev
532019-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
542019-01-25T03:44:46 *** bitcoin-git has left #bitcoin-core-dev
552019-01-25T03:56:24 *** bitcoin-git has joined #bitcoin-core-dev
562019-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
572019-01-25T03:56:24 *** bitcoin-git has left #bitcoin-core-dev
582019-01-25T04:05:30 *** bitcoin-git has joined #bitcoin-core-dev
592019-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
602019-01-25T04:05:30 *** bitcoin-git has left #bitcoin-core-dev
612019-01-25T04:08:04 *** bitcoin-git has joined #bitcoin-core-dev
622019-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
632019-01-25T04:08:04 *** bitcoin-git has left #bitcoin-core-dev
642019-01-25T04:26:43 *** bitcoin-git has joined #bitcoin-core-dev
652019-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
662019-01-25T04:26:43 *** bitcoin-git has left #bitcoin-core-dev
672019-01-25T04:31:09 *** bitcoin-git has joined #bitcoin-core-dev
682019-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
692019-01-25T04:31:09 *** bitcoin-git has left #bitcoin-core-dev
702019-01-25T05:07:38 *** dermoth has quit IRC
712019-01-25T05:08:14 *** dermoth has joined #bitcoin-core-dev
722019-01-25T05:35:11 *** promag has joined #bitcoin-core-dev
732019-01-25T05:37:30 *** mistergold has joined #bitcoin-core-dev
742019-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])?
752019-01-25T05:38:22 *** mistergo1d has quit IRC
762019-01-25T05:39:38 *** promag has quit IRC
772019-01-25T05:41:34 *** Murch has quit IRC
782019-01-25T05:41:38 <sipa> jonasschnelli: yes, not all places where descriptors are useful require a range
792019-01-25T05:42:07 <sipa> specifically, a wallet doesn't, as it can automatically extend the ranges
802019-01-25T05:42:10 <jonasschnelli> sipa: but it could be an optional element that may be ignored by the application logic
812019-01-25T05:42:39 <jonasschnelli> sipa: say I want to import p2wpkh script from an xpub from 100 to 200
822019-01-25T05:42:55 <sipa> then you need a record with that descriptor, and that range
832019-01-25T05:43:07 <sipa> there is other metadata you need that has no place in a desceiptor
842019-01-25T05:43:15 <sipa> like whether or not to treat it as change
852019-01-25T05:43:21 <sipa> or what hw device is associated with it
862019-01-25T05:43:27 <jonasschnelli> Yes. That is a point.
872019-01-25T05:58:13 *** mistergo1d has joined #bitcoin-core-dev
882019-01-25T06:00:21 *** _luc_ has joined #bitcoin-core-dev
892019-01-25T06:01:26 *** mistergold has quit IRC
902019-01-25T06:01:38 *** _luc_ has quit IRC
912019-01-25T06:01:59 *** DeanGuss has joined #bitcoin-core-dev
922019-01-25T06:12:46 *** mistergo1d has quit IRC
932019-01-25T06:14:23 *** bitcoin-git has joined #bitcoin-core-dev
942019-01-25T06:14:23 <bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/72bd4ab867e3...d14ef5721ffc
952019-01-25T06:14:23 <bitcoin-git> bitcoin/master b09dab0 Akio Nakamura: Prevent mutex lock fail even if --enable-debug...
962019-01-25T06:14:23 <bitcoin-git> bitcoin/master d14ef57 MarcoFalke: Merge #15233: Prevent mutex lock fail even if --enable-debug...
972019-01-25T06:14:23 *** bitcoin-git has left #bitcoin-core-dev
982019-01-25T06:14:32 *** pinheadmz has joined #bitcoin-core-dev
992019-01-25T06:15:14 *** bitcoin-git has joined #bitcoin-core-dev
1002019-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
1012019-01-25T06:15:14 *** bitcoin-git has left #bitcoin-core-dev
1022019-01-25T06:26:04 *** bitcoin-git has joined #bitcoin-core-dev
1032019-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
1042019-01-25T06:26:04 *** bitcoin-git has left #bitcoin-core-dev
1052019-01-25T06:26:05 *** jb55 has joined #bitcoin-core-dev
1062019-01-25T06:28:05 *** cyber55 has quit IRC
1072019-01-25T06:29:15 *** cyber55 has joined #bitcoin-core-dev
1082019-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..)
1092019-01-25T06:37:11 *** pinheadmz has quit IRC
1102019-01-25T06:42:31 *** pinheadmz has joined #bitcoin-core-dev
1112019-01-25T06:48:24 *** spinza has quit IRC
1122019-01-25T06:52:43 *** spinza has joined #bitcoin-core-dev
1132019-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
1142019-01-25T06:55:22 <jonasschnelli> Maybe as a starter just run one build (wallet + QT) on nativ travis osx and run the tests?
1152019-01-25T06:55:47 *** miknotauro has joined #bitcoin-core-dev
1162019-01-25T06:56:06 <jonasschnelli> Running the cross compiled macos binaries would indeed be great...
1172019-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
1182019-01-25T06:58:18 *** pinheadmz has quit IRC
1192019-01-25T07:01:01 <sipa> what does "since macos is very likely non apple native" mean?
1202019-01-25T07:01:38 <jonasschnelli> the travis macOS is probably an emulated macOS... not a Apple native... probably some sort of Hackintosh
1212019-01-25T07:02:12 <jonasschnelli> the test results are eventually not directly identical... but I may be wrong.
1222019-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/)
1232019-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
1242019-01-25T07:03:35 <jonasschnelli> kallewoof: Yeah. I have read this... but I wonder how they do it
1252019-01-25T07:03:54 <jonasschnelli> macOS runs only on mac
1262019-01-25T07:04:07 <jonasschnelli> expect you modify it in a pretty nasty way
1272019-01-25T07:04:45 <jonasschnelli> (which I what makes me say the test results may not be completely representative)
1282019-01-25T07:04:46 <sipa> they may well have negotiated a license agreement with apple
1292019-01-25T07:05:02 <jonasschnelli> could be... but unlikely
1302019-01-25T07:05:34 <jonasschnelli> But they maybe have a couple of mac pros or so running those jobs
1312019-01-25T07:05:53 <echeveria> jonasschnelli: itâs not modified much actually.
1322019-01-25T07:05:59 <jonasschnelli> AFAIK there are no drivers for non mac hardware, etc.
1332019-01-25T07:06:18 <jonasschnelli> echeveria: what means "not much"? :)
1342019-01-25T07:06:22 <echeveria> jonasschnelli: thereâs a kernel module, DONTSTEALMACOS.kext, and other than that itâs just driver support mostly.
1352019-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.
1362019-01-25T07:07:39 <jonasschnelli> Yeah. I heard about this. But I guess not very efficient...
1372019-01-25T07:07:59 <jonasschnelli> Mac Mini is probably the nightmare of a server data center admin...
1382019-01-25T07:08:45 <sipa> it looks like they run on actual mac hardware
1392019-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.
1402019-01-25T07:09:25 <echeveria> similar to Travis, building Bitcoin Core, I menâs.
1412019-01-25T07:09:25 <jonasschnelli> Good to know...
1422019-01-25T07:09:27 <echeveria> mean.
1432019-01-25T07:09:45 <jonasschnelli> however, a travis macOS job would probably be a good thing...
1442019-01-25T07:10:06 <sipa> agree.
1452019-01-25T07:10:17 <jonasschnelli> Curious to know if you can run the GUI process and take a screenshot...
1462019-01-25T07:18:24 *** ThomasLuong has quit IRC
1472019-01-25T07:23:23 *** trillhc3 has joined #bitcoin-core-dev
1482019-01-25T07:23:23 *** trillhc2 has quit IRC
1492019-01-25T07:31:53 *** bitcoin-git has joined #bitcoin-core-dev
1502019-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
1512019-01-25T07:31:53 *** bitcoin-git has left #bitcoin-core-dev
1522019-01-25T07:47:46 *** bitcoin-git has joined #bitcoin-core-dev
1532019-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
1542019-01-25T07:47:46 *** bitcoin-git has left #bitcoin-core-dev
1552019-01-25T08:08:39 *** hebasto has joined #bitcoin-core-dev
1562019-01-25T08:23:35 *** BGL has quit IRC
1572019-01-25T08:28:50 *** promag has joined #bitcoin-core-dev
1582019-01-25T08:33:26 *** promag has quit IRC
1592019-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 ...)
1602019-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
1612019-01-25T08:54:47 *** JackH has quit IRC
1622019-01-25T08:57:00 *** miknotauro has quit IRC
1632019-01-25T09:12:55 *** IGHOR has quit IRC
1642019-01-25T09:32:39 *** jungly has joined #bitcoin-core-dev
1652019-01-25T09:34:39 *** BGL has joined #bitcoin-core-dev
1662019-01-25T09:35:26 *** JackH has joined #bitcoin-core-dev
1672019-01-25T09:36:38 *** bitcoin-git has joined #bitcoin-core-dev
1682019-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
1692019-01-25T09:36:38 *** bitcoin-git has left #bitcoin-core-dev
1702019-01-25T09:37:27 *** bitcoin-git has joined #bitcoin-core-dev
1712019-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
1722019-01-25T09:37:27 *** bitcoin-git has left #bitcoin-core-dev
1732019-01-25T09:42:30 *** kallewoof has quit IRC
1742019-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
1752019-01-25T10:03:52 *** kexkey has quit IRC
1762019-01-25T10:07:40 *** setpill has joined #bitcoin-core-dev
1772019-01-25T10:09:40 *** Zenton has joined #bitcoin-core-dev
1782019-01-25T10:12:23 *** spinza has quit IRC
1792019-01-25T10:31:22 *** spinza has joined #bitcoin-core-dev
1802019-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 :)
1812019-01-25T10:48:34 <hebasto> provoostenator: thanks
1822019-01-25T11:07:01 *** trillhc3 has quit IRC
1832019-01-25T11:27:47 *** Skirmant has joined #bitcoin-core-dev
1842019-01-25T11:46:49 *** IGHOR has joined #bitcoin-core-dev
1852019-01-25T11:48:19 *** bitcoin-git has joined #bitcoin-core-dev
1862019-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
1872019-01-25T11:48:19 *** bitcoin-git has left #bitcoin-core-dev
1882019-01-25T11:50:21 *** IGHOR has joined #bitcoin-core-dev
1892019-01-25T11:53:26 *** lnostdal has quit IRC
1902019-01-25T11:54:27 *** lnostdal has joined #bitcoin-core-dev
1912019-01-25T11:55:23 *** IGHOR has quit IRC
1922019-01-25T11:58:01 *** IGHOR has joined #bitcoin-core-dev
1932019-01-25T13:00:56 *** luke-jr has quit IRC
1942019-01-25T13:10:02 *** rh0nj has quit IRC
1952019-01-25T13:11:07 *** rh0nj has joined #bitcoin-core-dev
1962019-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)
1972019-01-25T13:19:37 <gribble> https://github.com/bitcoin/bitcoin/issues/15101 | gui: Add WalletController by promag · Pull Request #15101 · bitcoin/bitcoin · GitHub
1982019-01-25T13:23:34 <hebasto> could someone restart travis for #15239?
1992019-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
2002019-01-25T13:40:44 *** hebasto has quit IRC
2012019-01-25T14:37:24 *** lnostdal has quit IRC
2022019-01-25T14:38:06 *** spinza has quit IRC
2032019-01-25T14:38:47 *** lnostdal has joined #bitcoin-core-dev
2042019-01-25T14:44:53 *** Aaronvan_ is now known as AaronvanW
2052019-01-25T14:45:23 *** Guyver2 has joined #bitcoin-core-dev
2062019-01-25T15:03:14 *** spinza has joined #bitcoin-core-dev
2072019-01-25T15:05:05 *** setpill has quit IRC
2082019-01-25T15:07:48 *** lnostdal has quit IRC
2092019-01-25T15:10:23 *** spaced0ut has joined #bitcoin-core-dev
2102019-01-25T15:17:49 *** phwalkr has joined #bitcoin-core-dev
2112019-01-25T15:23:19 *** lnostdal has joined #bitcoin-core-dev
2122019-01-25T15:30:41 *** miknotauro has joined #bitcoin-core-dev
2132019-01-25T15:34:36 *** pinheadmz has joined #bitcoin-core-dev
2142019-01-25T15:48:31 *** michaelsdunn1 has joined #bitcoin-core-dev
2152019-01-25T15:48:53 *** pinheadmz has quit IRC
2162019-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
2172019-01-25T16:16:29 *** hebasto has joined #bitcoin-core-dev
2182019-01-25T16:20:38 *** luke-jr has joined #bitcoin-core-dev
2192019-01-25T16:23:50 *** bitcoin-git has joined #bitcoin-core-dev
2202019-01-25T16:23:50 <bitcoin-git> [bitcoin] lcornelius101 opened pull request #15261: update firmwear (master...master) https://github.com/bitcoin/bitcoin/pull/15261
2212019-01-25T16:23:50 *** bitcoin-git has left #bitcoin-core-dev
2222019-01-25T16:26:23 *** bitcoin-git has joined #bitcoin-core-dev
2232019-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
2242019-01-25T16:26:23 *** bitcoin-git has left #bitcoin-core-dev
2252019-01-25T16:30:45 *** lukedashjr has joined #bitcoin-core-dev
2262019-01-25T16:34:26 *** luke-jr has quit IRC
2272019-01-25T16:35:23 *** lukedashjr is now known as luke-jr
2282019-01-25T16:41:23 *** jungly has quit IRC
2292019-01-25T16:41:32 *** miknotauro has quit IRC
2302019-01-25T16:56:19 *** bitcoin-git has joined #bitcoin-core-dev
2312019-01-25T16:56:19 <bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/d14ef5721ffc...ab46fe6ec1b3
2322019-01-25T16:56:19 <bitcoin-git> bitcoin/master f618c58 Ben Woosley: Docs: Update python docs to reflect that wildcard imports are disallowed
2332019-01-25T16:56:19 <bitcoin-git> bitcoin/master ab46fe6 MarcoFalke: Merge #15249: Docs: Update python docs to reflect that wildcard imports are disallowed...
2342019-01-25T16:56:19 *** bitcoin-git has left #bitcoin-core-dev
2352019-01-25T16:56:51 *** pinheadmz has joined #bitcoin-core-dev
2362019-01-25T16:57:13 *** bitcoin-git has joined #bitcoin-core-dev
2372019-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
2382019-01-25T16:57:14 *** bitcoin-git has left #bitcoin-core-dev
2392019-01-25T17:08:56 *** Zenton has quit IRC
2402019-01-25T17:12:32 *** JackH has quit IRC
2412019-01-25T17:30:51 *** ThomasLuong has joined #bitcoin-core-dev
2422019-01-25T18:06:58 *** Murch has joined #bitcoin-core-dev
2432019-01-25T18:11:40 *** mistergold has joined #bitcoin-core-dev
2442019-01-25T18:22:07 *** jarthur has joined #bitcoin-core-dev
2452019-01-25T18:31:36 *** miknotauro has joined #bitcoin-core-dev
2462019-01-25T18:37:26 *** bitcoin-git has joined #bitcoin-core-dev
2472019-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
2482019-01-25T18:37:26 *** bitcoin-git has left #bitcoin-core-dev
2492019-01-25T18:44:55 *** mistergold has quit IRC
2502019-01-25T18:47:32 *** DeanGuss has quit IRC
2512019-01-25T18:48:05 *** DeanGuss has joined #bitcoin-core-dev
2522019-01-25T18:57:11 <provoostenator> Do we have a wallet meeting today or am I off by one again?
2532019-01-25T18:59:56 *** mistergold has joined #bitcoin-core-dev
2542019-01-25T19:01:07 <achow101> wallet meeting?
2552019-01-25T19:01:16 <sipa> present
2562019-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 :)
2572019-01-25T19:03:15 <provoostenator> Suggested topic: wallet goals for 0.18
2582019-01-25T19:04:02 <sipa> do we have sufficient people for meeting?
2592019-01-25T19:05:14 *** dermoth has quit IRC
2602019-01-25T19:05:19 <achow101> maybe after the mass ping?
2612019-01-25T19:05:41 *** dermoth has joined #bitcoin-core-dev
2622019-01-25T19:06:03 <sipa> engage the mass ping.
2632019-01-25T19:07:38 <gmaxwell> no pingy?
2642019-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
2652019-01-25T19:08:19 <achow101> jnewbery maaku fanquake promag provoostenator aj Chris_Stewart_5 dongcarl gwillen jamesob ken281221 ryanofsky gleb
2662019-01-25T19:08:39 <gwillen> good morning programs
2672019-01-25T19:08:58 <sipa> #startmeeting
2682019-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.
2692019-01-25T19:08:58 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
2702019-01-25T19:09:03 <meshcollider> Hi yeah my internet is very spotty so I probably won't be here for most of this sorry :)
2712019-01-25T19:09:20 <sipa> okay
2722019-01-25T19:09:53 <provoostenator> https://github.com/bitcoin/bitcoin/milestone/35
2732019-01-25T19:09:58 <sipa> #topic wallet goals for 0.18
2742019-01-25T19:10:26 <gmaxwell> This is relevant
2752019-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
2762019-01-25T19:10:27 <gmaxwell> wumpus fanquake ...)
2772019-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
2782019-01-25T19:10:27 <gmaxwell> Request #13756 · bitcoin/bitcoin · GitHub
2792019-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
2802019-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
2812019-01-25T19:10:35 <provoostenator> +1
2822019-01-25T19:10:40 <sipa> gmaxwell: thanks
2832019-01-25T19:11:38 <sipa> gwillen: will you have time in the near future to rebase/address comments in #14978 ?
2842019-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:
2852019-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
2862019-01-25T19:12:12 <provoostenator> Though that may be a bit ambitious.
2872019-01-25T19:12:18 <achow101> how likely is it for #14491, #14075, and #14021 to get into 0.18?
2882019-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
2892019-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
2902019-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
2912019-01-25T19:12:38 <achow101> (those are required for HWI)
2922019-01-25T19:13:46 <provoostenator> I think descriptor imports is pretty close
2932019-01-25T19:14:07 <gwillen> sipa: yes, I will definitely try to go another round on 14978 ASAP
2942019-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
2952019-01-25T19:14:44 <provoostenator> The key origin PR is tiny (on top of desciptor), with lots of tests
2962019-01-25T19:15:02 <sipa> provoostenator: cool, so that should be easy once descriptor import is in
2972019-01-25T19:15:15 <provoostenator> The keypool import stuff still has me a bit in doubt what the right approach is.
2982019-01-25T19:15:21 <achow101> gwillen: I rebased and updated #13932 last night
2992019-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
3002019-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.
3012019-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.
3022019-01-25T19:16:45 <provoostenator> gmaxwell: we could make importing descriptors without xpub fail, unless opted in?
3032019-01-25T19:16:53 <gwillen> achow101: sweet, thanks! I will go look.
3042019-01-25T19:16:59 <provoostenator> (xpub or other checksummed approach)
3052019-01-25T19:17:07 <gwillen> sipa: ok, I will prioritize, thanks
3062019-01-25T19:17:08 <sipa> gmaxwell: the xpubs inside descriptors have a checksum, though the paths/functions don't
3072019-01-25T19:17:21 <gmaxwell> provoostenator: if the part of the descriptor outside of the xpub is corrupted funds are still lost.
3082019-01-25T19:17:45 <gmaxwell> That may be a little less likely, but its still exposed.
3092019-01-25T19:17:52 <provoostenator> That seems somewhat unlikely though for the most basic descriptors.
3102019-01-25T19:18:19 <provoostenator> Because the parser will fail, unless the error happens to produce another valid descriptor.
3112019-01-25T19:18:55 <gmaxwell> What does wsh(multi(3,xpub661MyMwAqRbcFW31YEwpkMuc5THy2PSt5bDMsktWQcFF8syAmRUapSCGu8ED9W6oDMSgv6Zz8idoc4a6mr8BDzTJY47LJhkJ8UB7WEGuduB/1/0/*,xpub69H7F5d8KSRgmmdJg2KhpAK8SR3DjMwAdkxj3ZuxV27CprR9LgpeyGmXUbC6wb7ERfvrnKZjXoUmmDznezpbZb7ap6r1D3tgFxHmwMkQTPH/0/0/*)) do?
3122019-01-25T19:19:28 <gmaxwell> (3 of 2 multisig)
3132019-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.
3142019-01-25T19:20:08 <provoostenator> (a generic problem if we had any kind of checksum mechanism to the descriptor language)
3152019-01-25T19:20:21 <gmaxwell> in any case, filtering to xpubs unless overridden seems like a good idea, at least.
3162019-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
3172019-01-25T19:20:46 <sipa> also, anything with a private key has a checksum
3182019-01-25T19:20:50 <gmaxwell> but it still seems far too dangerous to ever have users using directly to import keys.
3192019-01-25T19:20:59 <provoostenator> 3 of 2 multisig should hopefully fail as an invalid descriptor? Could be worth adding a test for that...
3202019-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.
3212019-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.
3222019-01-25T19:22:28 <gwillen> provoostenator: yeah, we would have to go "oops, lack of checksum was an omission in the spec, new spec"
3232019-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.
3242019-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
3252019-01-25T19:22:44 <sipa> gwillen: that's the great thing about not having a spec
3262019-01-25T19:22:53 <achow101> provoostenator: it's not like descriptors are really standardized yet though...
3272019-01-25T19:22:54 <gwillen> sipa: :D
3282019-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.
3292019-01-25T19:23:32 <gmaxwell> That you'd just use after editing, if you intended to edit.
3302019-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.
3312019-01-25T19:23:49 <sipa> provoostenator, gmaxwell: that seems reasonable
3322019-01-25T19:24:13 <sipa> i don't mind breaking compatibility at this point
3332019-01-25T19:24:19 <provoostenator> Yeah, we would need some utility to calculate the checksum for those making descriptors manually.
3342019-01-25T19:24:34 <gmaxwell> Seems straightforward.
3352019-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
3362019-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
3372019-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?
3382019-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.
3392019-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
3402019-01-25T19:26:53 <gwillen> but I don't have a better idea in hand
3412019-01-25T19:27:15 * sipa fires up BCH code search?
3422019-01-25T19:27:19 <gwillen> there's no obvious better place to put it
3432019-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.
3442019-01-25T19:28:05 <gmaxwell> If someone wants to do extra work to screw themselves, oh well.
3452019-01-25T19:28:08 <instagibbs> Put bytes in pseudorandom places, annoying to extract and by then, might as well validate it
3462019-01-25T19:28:15 <instagibbs> (sarcasm font)
3472019-01-25T19:28:27 <gmaxwell> But the default should be as safe as we can make it without undue tradeoffs.
3482019-01-25T19:28:46 <gmaxwell> sipa: whats the character set of descriptors?
3492019-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.
3502019-01-25T19:29:16 <gmaxwell> sipa: (does it form a field...)
3512019-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.
3522019-01-25T19:30:03 <provoostenator> I'm in favor of prime power.
3532019-01-25T19:30:33 <gmaxwell> I don't think right now descriptors have a defined charset?
3542019-01-25T19:30:33 *** Randolf has joined #bitcoin-core-dev
3552019-01-25T19:30:38 <sipa> gmaxwell: indeed
3562019-01-25T19:30:49 <sipa> but at least 0-9 a-z A-Z / * [ ]
3572019-01-25T19:30:54 <gmaxwell> alphanum + some extras like /,()[]* ?
3582019-01-25T19:31:02 <gmaxwell> oh right mixed case.
3592019-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)
3602019-01-25T19:31:28 <gwillen> can't you always just add "virtual" characters to the charset until you reach a prime power
3612019-01-25T19:31:36 <gwillen> at the expense of increasing checksum size a bit
3622019-01-25T19:31:43 *** BITTREX has joined #bitcoin-core-dev
3632019-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.
3642019-01-25T19:32:11 <gmaxwell> gwillen: no, because the check digit could be one of those characters.
3652019-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.
3662019-01-25T19:33:38 <gmaxwell> and doing something dumb (sha256, ugh) would be still better than nothing.
3672019-01-25T19:33:57 <sipa> we can reuse bech32 character set easily
3682019-01-25T19:34:11 <sipa> and use something like what bech32 does for the prefix
3692019-01-25T19:34:22 <gmaxwell> sipa: with the hrp han... right...
3702019-01-25T19:34:25 <sipa> (which works for all of ascii)
3712019-01-25T19:34:34 <gmaxwell> doesn't have the great distance properties, but probably good enough.
3722019-01-25T19:34:57 <sipa> before we move to a different topic... what general length of checksum are people thinking is acceptable?
3732019-01-25T19:35:07 <gwillen> how would people feel about the syntax being something like "(descriptor,checksum)" instead of "descriptor,checksum"
3742019-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
3752019-01-25T19:35:58 <gmaxwell> sipa: descriptors are already long, I don't see a problem with adding 5-8 extra characters.
3762019-01-25T19:36:18 <gwillen> (also, the checksum charset should exclude "()[]*/.", it should be alphanum, for the same reason)
3772019-01-25T19:36:22 <provoostenator> Sticking to bech32 characters would be nice.
3782019-01-25T19:36:42 <provoostenator> Because longer term it's probably nice if desciptors can be printed as QR codes.
3792019-01-25T19:36:50 <provoostenator> I'm thinking paper backups.
3802019-01-25T19:36:53 <provoostenator> (of pub keys)
3812019-01-25T19:37:05 <gmaxwell> I guess spaces are syntatically meaningless in descriptors? if so checksum should be computed after stripping them.
3822019-01-25T19:37:18 *** lnostdal has quit IRC
3832019-01-25T19:37:22 <instagibbs> spaces are currently rejected anywhere
3842019-01-25T19:37:26 <instagibbs> in Core
3852019-01-25T19:37:27 <gwillen> oof, it would be good if descriptor format were canonical, no spaces
3862019-01-25T19:37:29 <gmaxwell> provoostenator: well unfortunately the other characters in descriptors make QR codes inefficient.
3872019-01-25T19:37:30 <gwillen> :+1:
3882019-01-25T19:37:34 <gmaxwell> oh okay, cool.
3892019-01-25T19:37:44 <sipa> gmaxwell: i think the parser will reject anything with spaces
3902019-01-25T19:37:52 <instagibbs> sipa, it will(I've lost time figuring this out)
3912019-01-25T19:38:01 <instagibbs> the error message is quite vague
3922019-01-25T19:38:03 <gmaxwell> instagibbs: improve error messages?
3932019-01-25T19:38:07 <instagibbs> gmaxwell, yeah
3942019-01-25T19:38:33 <gmaxwell> sorry for the derail, but I'm glad there seems to be support for fixing this.
3952019-01-25T19:39:01 <sipa> gmaxwell: fwiw, your 3-of-2 multisig descriptor is rejected
3962019-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
3972019-01-25T19:39:38 <gmaxwell> sipa: thats great.
3982019-01-25T19:39:50 <gmaxwell> or 2 of 2 instead of 1 of 2.
3992019-01-25T19:39:57 <gmaxwell> sipa: is 0 of 2 rejected? :P
4002019-01-25T19:39:59 <sipa> and i think p2sh descriptors with multisig redeemscripts over 510 bytes are also rejected
4012019-01-25T19:40:12 <sipa> gmaxwell: yes, 0 of 2 is also rejected
4022019-01-25T19:40:20 <gmaxwell> The fact that a lot of mistakes will fail the parser also favors a weaker check.
4032019-01-25T19:40:32 <sipa> ok, let's move to a different topic
4042019-01-25T19:40:36 <sipa> if there are others?
4052019-01-25T19:43:01 <gmaxwell> Is anyone working on improving avoidpartialspends?
4062019-01-25T19:43:02 <jnewbery> for wallet goals for v0.18, I'm hopeful we can finish multiwallet in the GUI
4072019-01-25T19:43:12 <jnewbery> promag's been doing great work
4082019-01-25T19:43:17 <gmaxwell> It's off by default, which makes it kinda useless in terms of overall privacy effects.
4092019-01-25T19:43:24 <sipa> gmaxwell: what needs to be done?
4102019-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.
4112019-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
4122019-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)
4132019-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.
4142019-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.
4152019-01-25T19:45:55 <gmaxwell> result*
4162019-01-25T19:45:58 <sipa> right
4172019-01-25T19:46:10 <sipa> i agree that makes it pretty pointless
4182019-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.
4192019-01-25T19:47:14 <gmaxwell> This returns to a larger open question about fees now vs fees later.
4202019-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
4212019-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?
4222019-01-25T19:48:23 <gmaxwell> and/or with a threshold you'll pay in extra fees?
4232019-01-25T19:48:32 <sdaftuar> yeah, we should just do that.
4242019-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.
4252019-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.
4262019-01-25T19:50:24 <sipa> gmaxwell: don'
4272019-01-25T19:50:28 <sipa> gmaxwell: don't we already have that?
4282019-01-25T19:50:40 <sipa> (using long term fee estimation)
4292019-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.
4302019-01-25T19:52:19 *** lnostdal has joined #bitcoin-core-dev
4312019-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.
4322019-01-25T19:53:07 *** BITTREX has quit IRC
4332019-01-25T19:53:08 <gmaxwell> (well not litterally right now, there are fees at the moment.. :P)
4342019-01-25T19:53:35 <sipa> right
4352019-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.
4362019-01-25T19:54:55 <gmaxwell> If fees are high only be willing to pay slightly more, if fees are low use it.
4372019-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)
4382019-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.
4392019-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.
4402019-01-25T19:58:15 *** bitcoin-git has joined #bitcoin-core-dev
4412019-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
4422019-01-25T19:58:15 *** bitcoin-git has left #bitcoin-core-dev
4432019-01-25T19:59:48 <sipa> last half minute topic?
4442019-01-25T20:00:25 <sipa> #endmeeting
4452019-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)
4462019-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
4472019-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
4482019-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
4492019-01-25T20:00:55 *** DeanGuss has quit IRC
4502019-01-25T20:01:07 <jnewbery> If anyone else is interested in getting multiwallet GUI merged for 0.18, PRs are tracked in #13059
4512019-01-25T20:01:08 <gribble> https://github.com/bitcoin/bitcoin/issues/13059 | Dynamic wallet load / create / unload · Issue #13059 · bitcoin/bitcoin · GitHub
4522019-01-25T20:01:56 *** miknotauro has quit IRC
4532019-01-25T20:08:50 *** BITTREX has joined #bitcoin-core-dev
4542019-01-25T20:09:26 *** bitcoin-git has joined #bitcoin-core-dev
4552019-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
4562019-01-25T20:09:26 *** bitcoin-git has left #bitcoin-core-dev
4572019-01-25T20:15:26 *** BITTREX has quit IRC
4582019-01-25T20:15:57 *** BITTREX has joined #bitcoin-core-dev
4592019-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...
4602019-01-25T20:27:16 *** laurentmt has joined #bitcoin-core-dev
4612019-01-25T20:27:20 <sipa> gmaxwell: jimpo was working on that
4622019-01-25T20:29:24 *** Zenton has joined #bitcoin-core-dev
4632019-01-25T20:29:56 *** BITTREX has quit IRC
4642019-01-25T20:31:42 *** Randolf has quit IRC
4652019-01-25T20:45:34 *** hebasto has quit IRC
4662019-01-25T20:45:34 *** laurentmt has quit IRC
4672019-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.
4682019-01-25T20:52:54 <provoostenator> And then recommend that computer programs don't pass around the human readable versions.
4692019-01-25T20:53:20 <sipa> provoostenator: i was considering that too
4702019-01-25T20:53:24 <provoostenator> (or we can do both, i.e. also adding a checksum for the human readable one)
4712019-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?
4722019-01-25T20:53:35 <provoostenator> But that also solves my checksum concern.
4732019-01-25T20:53:40 <sipa> but i think it won't be used really, as it removes the human readability
4742019-01-25T20:53:49 <sipa> and i think that reafability is part of the appeal
4752019-01-25T20:54:02 <provoostenator> I think it's still useful for communication between programs.
4762019-01-25T20:56:13 <sipa> another question is what length the code should be designed for
4772019-01-25T20:56:16 <provoostenator> "But that also solves" (not sure what I as trying to say)
4782019-01-25T20:56:46 <gmaxwell> sipa: "long" or at least a code which is distance 1 for arbritarily long would be good.
4792019-01-25T20:58:22 <sipa> 1024 won't be long enough as a maximum
4802019-01-25T20:58:42 <sipa> gmaxwell: every code is distance 1 ;)
4812019-01-25T20:58:51 <sipa> (including no checksum at all)
4822019-01-25T20:58:52 <provoostenator> I can't actually think of that many situations where I _want_ to type descriptors.
4832019-01-25T20:59:14 <sipa> provoostenator: agree, but i may want to compose them
4842019-01-25T20:59:22 <sipa> and copy paste them
4852019-01-25T20:59:32 <sipa> gmaxwell: and every bch code is distance 2
4862019-01-25T20:59:46 *** Krellan has joined #bitcoin-core-dev
4872019-01-25T20:59:48 <sipa> at infinite length
4882019-01-25T21:00:03 <sipa> the question is up to what length it is distance 3 and higher
4892019-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.
4902019-01-25T21:01:01 <provoostenator> And calls like getaddressinfo should probably show both the human readable and the bch version
4912019-01-25T21:01:37 *** bitcoin-git has joined #bitcoin-core-dev
4922019-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
4932019-01-25T21:01:37 *** bitcoin-git has left #bitcoin-core-dev
4942019-01-25T21:01:38 <provoostenator> import should somewhat resist the human readable version
4952019-01-25T21:01:55 <provoostenator> (except with a checksum)
4962019-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.
4972019-01-25T21:06:54 <provoostenator> Except descriptors are for more compact and lend themselves better to writing by hand.
4982019-01-25T21:09:43 *** bitcoin-git has joined #bitcoin-core-dev
4992019-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
5002019-01-25T21:09:44 *** bitcoin-git has left #bitcoin-core-dev
5012019-01-25T21:23:35 <sipa> provoostenator: if the checksum is just appended we don't really need two versions
5022019-01-25T21:35:03 *** bitcoin-git has joined #bitcoin-core-dev
5032019-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
5042019-01-25T21:35:03 *** bitcoin-git has left #bitcoin-core-dev
5052019-01-25T21:40:55 *** ddustin has joined #bitcoin-core-dev
5062019-01-25T21:48:17 *** promag has joined #bitcoin-core-dev
5072019-01-25T21:52:12 *** emilengler has joined #bitcoin-core-dev
5082019-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 ?
5092019-01-25T21:56:47 <ddustin> emilengler: https://en.bitcoin.it/wiki/Protocol_documentation
5102019-01-25T21:56:56 <emilengler> thank you
5112019-01-25T21:59:05 *** mistergo1d has joined #bitcoin-core-dev
5122019-01-25T21:59:44 *** millerti has joined #bitcoin-core-dev
5132019-01-25T22:02:27 *** mistergold has quit IRC
5142019-01-25T22:11:05 *** jarthur has quit IRC
5152019-01-25T22:16:26 *** Guyver2 has quit IRC
5162019-01-25T22:28:36 *** spinza has quit IRC
5172019-01-25T22:34:44 *** rex4539 has joined #bitcoin-core-dev
5182019-01-25T22:44:25 *** jim_layhee has joined #bitcoin-core-dev
5192019-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
5202019-01-25T22:47:15 <jim_layhee> Error: Unable to start HTTP server. See debug log for details.
5212019-01-25T22:47:24 <jim_layhee> any ideas?
5222019-01-25T22:47:38 *** spinza has joined #bitcoin-core-dev
5232019-01-25T22:49:15 *** phwalkr has quit IRC
5242019-01-25T22:51:52 <promag> thanks jnewbery
5252019-01-25T22:52:12 <promag> sorry for the lack of updates.. had a bad week
5262019-01-25T22:59:46 <sipa> gmaxwell: degree 8, distance 4, length 11275
5272019-01-25T23:00:20 <sipa> (note that one character error may cause 2 weight difference due to expansion)
5282019-01-25T23:02:16 *** michaelsdunn1 has quit IRC
5292019-01-25T23:17:03 *** jim_layhee has quit IRC
5302019-01-25T23:21:21 *** DeanGuss has joined #bitcoin-core-dev
5312019-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.
5322019-01-25T23:27:49 <sipa> gmaxwell: no
5332019-01-25T23:28:06 <sipa> you're thinking off the ability to detect an arbitrarily large odd number of errors
5342019-01-25T23:29:02 <gmaxwell> derp ah
5352019-01-25T23:29:31 *** spaced0ut has quit IRC
5362019-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.