12019-01-24T00:03:36 *** Zenton has joined #bitcoin-core-dev
22019-01-24T00:14:19 *** _luc_ has joined #bitcoin-core-dev
32019-01-24T00:18:27 *** miknotauro has quit IRC
42019-01-24T00:28:49 *** promag has joined #bitcoin-core-dev
52019-01-24T00:30:32 *** ThomasLuong has quit IRC
62019-01-24T00:33:20 *** promag has quit IRC
72019-01-24T00:34:30 *** jarthur has quit IRC
82019-01-24T00:37:49 *** AaronvanW has quit IRC
92019-01-24T01:01:33 *** Randolf has joined #bitcoin-core-dev
102019-01-24T01:03:05 *** AaronvanW has joined #bitcoin-core-dev
112019-01-24T01:08:26 *** AaronvanW has quit IRC
122019-01-24T01:10:20 *** michaelsdunn1 has joined #bitcoin-core-dev
132019-01-24T01:15:00 *** pinheadmz has quit IRC
142019-01-24T01:18:06 *** michaelsdunn1 has quit IRC
152019-01-24T01:22:20 *** AaronvanW has joined #bitcoin-core-dev
162019-01-24T01:26:39 *** AaronvanW has quit IRC
172019-01-24T01:40:07 *** AaronvanW has joined #bitcoin-core-dev
182019-01-24T01:40:57 *** _luc_ has quit IRC
192019-01-24T01:43:54 *** _luc_ has joined #bitcoin-core-dev
202019-01-24T01:44:26 *** AaronvanW has quit IRC
212019-01-24T01:47:56 *** _luc_ has quit IRC
222019-01-24T01:58:39 *** AaronvanW has joined #bitcoin-core-dev
232019-01-24T02:00:23 *** spinza has quit IRC
242019-01-24T02:02:45 *** AaronvanW has quit IRC
252019-01-24T02:05:12 *** spinza has joined #bitcoin-core-dev
262019-01-24T02:17:23 *** michaelsdunn1 has joined #bitcoin-core-dev
272019-01-24T02:21:16 *** mistergold has joined #bitcoin-core-dev
282019-01-24T02:36:08 *** Dean_Guss has joined #bitcoin-core-dev
292019-01-24T02:37:13 *** pinheadmz has joined #bitcoin-core-dev
302019-01-24T02:38:55 *** DeanGuss has quit IRC
312019-01-24T02:43:57 *** Murch has quit IRC
322019-01-24T02:50:58 *** Murch has joined #bitcoin-core-dev
332019-01-24T02:53:57 *** drexl has joined #bitcoin-core-dev
342019-01-24T02:55:52 *** AaronvanW has joined #bitcoin-core-dev
352019-01-24T02:59:56 *** AaronvanW has quit IRC
362019-01-24T03:07:18 *** promag has joined #bitcoin-core-dev
372019-01-24T03:10:26 *** pinheadmz has quit IRC
382019-01-24T03:10:29 *** AaronvanW has joined #bitcoin-core-dev
392019-01-24T03:11:30 *** promag has quit IRC
402019-01-24T03:14:38 *** AaronvanW has quit IRC
412019-01-24T03:15:01 *** Murch has quit IRC
422019-01-24T03:26:18 *** miknotauro has joined #bitcoin-core-dev
432019-01-24T03:27:18 *** michaelsdunn1 has quit IRC
442019-01-24T03:27:59 *** michaelsdunn1 has joined #bitcoin-core-dev
452019-01-24T03:29:17 *** AaronvanW has joined #bitcoin-core-dev
462019-01-24T03:29:44 *** _luc_ has joined #bitcoin-core-dev
472019-01-24T03:33:26 *** AaronvanW has quit IRC
482019-01-24T03:33:56 *** _luc_ has quit IRC
492019-01-24T03:33:57 *** Ryjl_ has joined #bitcoin-core-dev
502019-01-24T03:38:06 *** DougieBot5000_ has joined #bitcoin-core-dev
512019-01-24T03:38:31 *** michaelsdunn1 has quit IRC
522019-01-24T03:38:36 *** DougieBot5000 has quit IRC
532019-01-24T03:38:37 *** DougieBot5000_ is now known as DougieBot5000
542019-01-24T03:47:06 <jonasschnelli> descriptor question: is pkh([<fingerprint>/44'/0'/0']<xpub>/1/*) equivalent to pkh(<xpub>/44'/0'/0'/1/*)?
552019-01-24T03:47:09 <jonasschnelli> sipa ^
562019-01-24T03:48:29 <jonasschnelli> or does the xpub represent the key at /44'/0'/0'?
572019-01-24T03:50:28 *** promag has joined #bitcoin-core-dev
582019-01-24T03:51:14 *** ddustin has joined #bitcoin-core-dev
592019-01-24T03:54:50 *** promag has quit IRC
602019-01-24T03:58:00 *** pinheadmz has joined #bitcoin-core-dev
612019-01-24T04:02:04 <sipa> xpub represents the key are 44'/0'/0'
622019-01-24T04:02:11 <sipa> but if so, they're equivalent
632019-01-24T04:15:17 *** pinheadmz has quit IRC
642019-01-24T04:15:48 *** jarthur has joined #bitcoin-core-dev
652019-01-24T04:18:43 *** pinheadmz has joined #bitcoin-core-dev
662019-01-24T04:23:55 *** AaronvanW has joined #bitcoin-core-dev
672019-01-24T04:27:56 *** AaronvanW has quit IRC
682019-01-24T04:34:18 *** pinheadmz has quit IRC
692019-01-24T04:41:05 *** pinheadmz has joined #bitcoin-core-dev
702019-01-24T04:42:12 *** AaronvanW has joined #bitcoin-core-dev
712019-01-24T04:46:26 *** AaronvanW has quit IRC
722019-01-24T04:47:03 *** Ryjl_ has quit IRC
732019-01-24T04:48:34 *** AaronvanW has joined #bitcoin-core-dev
742019-01-24T04:52:58 *** AaronvanW has quit IRC
752019-01-24T04:57:01 *** pinheadmz has quit IRC
762019-01-24T05:00:42 *** AaronvanW has joined #bitcoin-core-dev
772019-01-24T05:04:56 *** AaronvanW has quit IRC
782019-01-24T05:09:57 *** millerti has quit IRC
792019-01-24T05:20:43 *** ccook has quit IRC
802019-01-24T05:34:44 *** ccook has joined #bitcoin-core-dev
812019-01-24T05:37:11 *** hebasto has joined #bitcoin-core-dev
822019-01-24T05:46:16 <hebasto> fanquake: hi, would you mind reviewing #13998?
832019-01-24T05:46:19 <gribble> https://github.com/bitcoin/bitcoin/issues/13998 | Scripts and tools: gitian-build.py improvements and corrections by hebasto · Pull Request #13998 · bitcoin/bitcoin · GitHub
842019-01-24T06:05:32 *** jarthur has quit IRC
852019-01-24T06:08:29 *** booyah_ is now known as booyah
862019-01-24T06:09:26 <jonasschnelli> sipa: so the [<fingerprint>/44'/0'/0'] part is pure metadata that is irrelevant to the child-key-derivation / script derivation?
872019-01-24T06:11:44 <sipa> yes
882019-01-24T06:15:29 *** AaronvanW has joined #bitcoin-core-dev
892019-01-24T06:20:20 *** AaronvanW has quit IRC
902019-01-24T06:20:51 <gkrizek> wumpus #15196 should be ready to merge
912019-01-24T06:20:54 <gribble> https://github.com/bitcoin/bitcoin/issues/15196 | [test]: Update all subprocess.check_output functions to be Python 3.4 compatible by gkrizek · Pull Request #15196 · bitcoin/bitcoin · GitHub
922019-01-24T06:28:36 *** pinheadmz has joined #bitcoin-core-dev
932019-01-24T06:34:08 *** AaronvanW has joined #bitcoin-core-dev
942019-01-24T06:38:27 *** AaronvanW has quit IRC
952019-01-24T06:41:48 *** AaronvanW has joined #bitcoin-core-dev
962019-01-24T06:44:20 *** bitcoin-git has joined #bitcoin-core-dev
972019-01-24T06:44:20 <bitcoin-git> [bitcoin] jonasschnelli pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/82cf6813a4ef...73a6bac9fffa
982019-01-24T06:44:20 <bitcoin-git> bitcoin/master fdf82ba Graham Krizek: Update all subprocess.check_output functions in CI scripts to be Python 3.4 compatible...
992019-01-24T06:44:20 <bitcoin-git> bitcoin/master 73a6bac Jonas Schnelli: Merge #15196: [test]: Update all subprocess.check_output functions to be Python 3.4 compatible...
1002019-01-24T06:44:20 *** bitcoin-git has left #bitcoin-core-dev
1012019-01-24T06:44:46 *** pinheadmz has quit IRC
1022019-01-24T06:45:05 *** lmk22 has joined #bitcoin-core-dev
1032019-01-24T06:45:06 *** bitcoin-git has joined #bitcoin-core-dev
1042019-01-24T06:45:06 <bitcoin-git> [bitcoin] jonasschnelli closed pull request #15196: [test]: Update all subprocess.check_output functions to be Python 3.4 compatible (master...cron-ci-fix) https://github.com/bitcoin/bitcoin/pull/15196
1052019-01-24T06:45:06 *** bitcoin-git has left #bitcoin-core-dev
1062019-01-24T06:45:52 *** pinheadmz has joined #bitcoin-core-dev
1072019-01-24T06:46:12 *** AaronvanW has quit IRC
1082019-01-24T06:49:08 <gkrizek> Thanks jonasschnelli
1092019-01-24T06:49:21 <jonasschnelli> gkrizek: thanks for the PR
1102019-01-24T06:52:50 *** AaronvanW has joined #bitcoin-core-dev
1112019-01-24T06:53:48 *** owowo has quit IRC
1122019-01-24T06:57:16 *** AaronvanW has quit IRC
1132019-01-24T06:57:39 *** IzooooOOO has quit IRC
1142019-01-24T06:59:08 *** owowo has joined #bitcoin-core-dev
1152019-01-24T07:15:34 *** _luc_ has joined #bitcoin-core-dev
1162019-01-24T07:21:00 * luke-jr realises the gitian static binaries don't actually work on non-Ubuntu systems -.-
1172019-01-24T07:21:16 <luke-jr> bitcoin-0.17.1/bin/bitcoin-qt: relocation error: bitcoin-0.17.1/bin/bitcoin-qt: symbol __chk_fail, version GLIBC_2.3.4 not defined in file libc.so.6 with link time reference
1182019-01-24T07:23:33 <luke-jr> apparently since 2015, which wumpus closed with no explanation? https://github.com/bitcoin/bitcoin/issues/6628
1192019-01-24T07:27:00 *** fanquake has joined #bitcoin-core-dev
1202019-01-24T07:27:11 <fanquake> hebasto will do
1212019-01-24T07:29:21 *** fanquake has quit IRC
1222019-01-24T07:30:32 *** AaronvanW has joined #bitcoin-core-dev
1232019-01-24T07:30:38 <aj> luke-jr: looks like it was required at one point for lsb compliance https://refspecs.linuxfoundation.org/LSB_5.0.0/LSB-Core-generic/LSB-Core-generic.html#TBL-LIBC-SYSTE-INTS
1242019-01-24T07:30:53 *** Randolf has quit IRC
1252019-01-24T07:31:54 *** Randolf has joined #bitcoin-core-dev
1262019-01-24T07:34:56 *** AaronvanW has quit IRC
1272019-01-24T07:36:02 *** rh0nj has quit IRC
1282019-01-24T07:37:07 *** rh0nj has joined #bitcoin-core-dev
1292019-01-24T07:42:14 *** trillhc has joined #bitcoin-core-dev
1302019-01-24T07:46:15 *** Dean_Guss has quit IRC
1312019-01-24T07:46:43 *** Dean_Guss has joined #bitcoin-core-dev
1322019-01-24T07:48:23 *** AaronvanW has joined #bitcoin-core-dev
1332019-01-24T07:49:11 *** bitcoin-git has joined #bitcoin-core-dev
1342019-01-24T07:49:12 <bitcoin-git> [bitcoin] kallewoof opened pull request #15241: travis: add --enable-debug macos build (master...travis-enable-debug-macos) https://github.com/bitcoin/bitcoin/pull/15241
1352019-01-24T07:49:12 *** bitcoin-git has left #bitcoin-core-dev
1362019-01-24T07:53:27 *** AaronvanW has quit IRC
1372019-01-24T08:03:07 *** promag has joined #bitcoin-core-dev
1382019-01-24T08:06:39 *** AaronvanW has joined #bitcoin-core-dev
1392019-01-24T08:07:10 <hebasto> fanquake: thanks
1402019-01-24T08:09:13 *** promag has quit IRC
1412019-01-24T08:11:08 *** AaronvanW has quit IRC
1422019-01-24T08:15:38 *** _luc_ has quit IRC
1432019-01-24T08:17:29 *** promag has joined #bitcoin-core-dev
1442019-01-24T08:19:44 *** pinheadmz has quit IRC
1452019-01-24T08:21:56 *** promag has quit IRC
1462019-01-24T08:24:33 *** AaronvanW has joined #bitcoin-core-dev
1472019-01-24T08:28:47 *** AaronvanW has quit IRC
1482019-01-24T08:35:37 *** AaronvanW has joined #bitcoin-core-dev
1492019-01-24T08:39:56 *** AaronvanW has quit IRC
1502019-01-24T08:42:07 *** luke-jr has quit IRC
1512019-01-24T08:42:40 *** AaronvanW has joined #bitcoin-core-dev
1522019-01-24T08:46:54 *** AaronvanW has quit IRC
1532019-01-24T08:47:16 *** luke-jr has joined #bitcoin-core-dev
1542019-01-24T08:48:28 *** JackH has quit IRC
1552019-01-24T08:49:17 *** Dean_Guss has quit IRC
1562019-01-24T08:49:40 *** Dean_Guss has joined #bitcoin-core-dev
1572019-01-24T09:00:32 *** AaronvanW has joined #bitcoin-core-dev
1582019-01-24T09:03:30 *** setpill has joined #bitcoin-core-dev
1592019-01-24T09:04:56 *** AaronvanW has quit IRC
1602019-01-24T09:15:40 *** promag has joined #bitcoin-core-dev
1612019-01-24T09:18:12 *** AaronvanW has joined #bitcoin-core-dev
1622019-01-24T09:22:52 *** AaronvanW has quit IRC
1632019-01-24T09:29:02 *** fanquake has joined #bitcoin-core-dev
1642019-01-24T09:32:10 *** JackH has joined #bitcoin-core-dev
1652019-01-24T09:35:59 *** AaronvanW has joined #bitcoin-core-dev
1662019-01-24T09:40:28 *** AaronvanW has quit IRC
1672019-01-24T09:54:52 *** AaronvanW has joined #bitcoin-core-dev
1682019-01-24T09:59:07 *** AaronvanW has quit IRC
1692019-01-24T10:03:35 *** kexkey has quit IRC
1702019-01-24T10:18:26 *** miknotauro has quit IRC
1712019-01-24T10:19:04 *** Guyver2 has joined #bitcoin-core-dev
1722019-01-24T10:19:29 *** brianhoffman has quit IRC
1732019-01-24T10:20:03 *** ExtraCrispy has joined #bitcoin-core-dev
1742019-01-24T10:29:22 *** AaronvanW has joined #bitcoin-core-dev
1752019-01-24T10:43:48 *** Apocalyptic has quit IRC
1762019-01-24T10:44:52 *** Apocalyptic has joined #bitcoin-core-dev
1772019-01-24T10:52:29 *** zshlyk has quit IRC
1782019-01-24T10:55:07 *** zshlyk has joined #bitcoin-core-dev
1792019-01-24T10:59:18 *** spinza has quit IRC
1802019-01-24T11:08:24 *** spinza has joined #bitcoin-core-dev
1812019-01-24T11:19:28 *** laurentmt has joined #bitcoin-core-dev
1822019-01-24T11:24:44 *** laurentmt has quit IRC
1832019-01-24T11:27:08 *** laurentmt has joined #bitcoin-core-dev
1842019-01-24T11:32:52 *** AaronvanW has quit IRC
1852019-01-24T11:35:27 *** AaronvanW has joined #bitcoin-core-dev
1862019-01-24T11:52:01 *** hebasto has quit IRC
1872019-01-24T11:52:57 *** IZooo has joined #bitcoin-core-dev
1882019-01-24T11:53:22 <IZooo> Hello !
1892019-01-24T11:55:42 *** dermoth has quit IRC
1902019-01-24T11:56:10 *** dermoth has joined #bitcoin-core-dev
1912019-01-24T11:57:44 *** AaronvanW has quit IRC
1922019-01-24T11:58:32 *** AaronvanW has joined #bitcoin-core-dev
1932019-01-24T12:25:41 *** laurentmt has quit IRC
1942019-01-24T12:27:29 *** _luc_ has joined #bitcoin-core-dev
1952019-01-24T12:31:56 *** _luc_ has quit IRC
1962019-01-24T12:42:22 *** promag has quit IRC
1972019-01-24T12:55:02 *** AaronvanW has quit IRC
1982019-01-24T13:04:46 *** AaronvanW has joined #bitcoin-core-dev
1992019-01-24T13:15:40 *** promag has joined #bitcoin-core-dev
2002019-01-24T13:16:47 *** _luc_ has joined #bitcoin-core-dev
2012019-01-24T13:17:12 *** AaronvanW has quit IRC
2022019-01-24T13:18:58 *** bitcoin-git has joined #bitcoin-core-dev
2032019-01-24T13:18:58 <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/73a6bac9fffa...5eb32d23841b
2042019-01-24T13:18:58 <bitcoin-git> bitcoin/master 5a5ea93 David A. Harding: Doc: add information about security to the JSON-RPC doc
2052019-01-24T13:18:58 <bitcoin-git> bitcoin/master 5eb32d2 Wladimir J. van der Laan: Merge #15223: Doc: add information about security to the JSON-RPC doc...
2062019-01-24T13:18:58 *** bitcoin-git has left #bitcoin-core-dev
2072019-01-24T13:19:49 *** bitcoin-git has joined #bitcoin-core-dev
2082019-01-24T13:19:49 <bitcoin-git> [bitcoin] laanwj closed pull request #15223: Doc: add information about security to the JSON-RPC doc (master...2019-01-rpc-security) https://github.com/bitcoin/bitcoin/pull/15223
2092019-01-24T13:19:49 *** bitcoin-git has left #bitcoin-core-dev
2102019-01-24T13:21:26 *** _luc_ has quit IRC
2112019-01-24T13:22:32 *** qwert has joined #bitcoin-core-dev
2122019-01-24T13:25:49 <promag> achow101: I'm getting "libc++abi.dylib: terminating with uncaught exception of type std::__1::system_error: mutex lock failed: Invalid argument" in #15225 on startup
2132019-01-24T13:25:51 <gribble> https://github.com/bitcoin/bitcoin/issues/15225 | GUI: Change the receive button to respond to keypool state changing by achow101 · Pull Request #15225 · bitcoin/bitcoin · GitHub
2142019-01-24T13:26:02 *** ddustin has quit IRC
2152019-01-24T13:26:15 <promag> rebuild does't help
2162019-01-24T13:26:41 *** ddustin has joined #bitcoin-core-dev
2172019-01-24T13:27:00 <promag> lldb gives "frame #9: 0x000000010033d532 bitcoin-qt`(anonymous namespace)::RNGState::MixExtract(this=0x000000010269af80, out="", num=4335447936, hasher=0x00007ffeefbfc4d8, strong_seed=<unavailable>) at random.cpp:355 [opt]"
2182019-01-24T13:27:03 <gribble> https://github.com/bitcoin/bitcoin/issues/9 | Fix for GUI on Macs and latest wxWidgets by gavinandresen · Pull Request #9 · bitcoin/bitcoin · GitHub
2192019-01-24T13:27:15 *** qwert has quit IRC
2202019-01-24T13:27:20 <promag> should clear ccache? :/
2212019-01-24T13:30:53 *** ddustin has quit IRC
2222019-01-24T13:34:14 *** laurentmt has joined #bitcoin-core-dev
2232019-01-24T13:53:02 *** timothy has joined #bitcoin-core-dev
2242019-01-24T13:55:46 *** brianhoffman has joined #bitcoin-core-dev
2252019-01-24T14:24:31 *** spinza has quit IRC
2262019-01-24T14:25:44 *** bitcoin-git has joined #bitcoin-core-dev
2272019-01-24T14:25:44 <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/5eb32d23841b...72bd4ab867e3
2282019-01-24T14:25:44 <bitcoin-git> bitcoin/master a36d97d Suhas Daftuar: Default -whitelistforcerelay to off
2292019-01-24T14:25:44 <bitcoin-git> bitcoin/master 72bd4ab Wladimir J. van der Laan: Merge #15193: Default -whitelistforcerelay to off...
2302019-01-24T14:25:44 *** bitcoin-git has left #bitcoin-core-dev
2312019-01-24T14:26:24 *** bitcoin-git has joined #bitcoin-core-dev
2322019-01-24T14:26:24 <bitcoin-git> [bitcoin] laanwj closed pull request #15193: Default -whitelistforcerelay to off (master...2019-01-forcerelayoff) https://github.com/bitcoin/bitcoin/pull/15193
2332019-01-24T14:26:24 *** bitcoin-git has left #bitcoin-core-dev
2342019-01-24T14:28:32 *** spinza has joined #bitcoin-core-dev
2352019-01-24T14:30:15 *** DrOlmer has joined #bitcoin-core-dev
2362019-01-24T14:31:44 *** promag has quit IRC
2372019-01-24T14:34:40 *** DrOlmer has quit IRC
2382019-01-24T14:41:35 *** fanquake_ has joined #bitcoin-core-dev
2392019-01-24T14:43:25 *** AaronvanW has joined #bitcoin-core-dev
2402019-01-24T14:44:19 *** fanquake has quit IRC
2412019-01-24T14:46:42 *** spaced0ut has joined #bitcoin-core-dev
2422019-01-24T14:49:06 *** Aaronvan_ has joined #bitcoin-core-dev
2432019-01-24T14:51:33 *** AaronvanW has quit IRC
2442019-01-24T14:52:22 *** fanquake_ has quit IRC
2452019-01-24T14:57:30 *** fanquake has joined #bitcoin-core-dev
2462019-01-24T14:57:44 <fanquake> wumpus could you block Vant13425, they are spamming at the moment
2472019-01-24T14:57:46 *** bitcoin-git has joined #bitcoin-core-dev
2482019-01-24T14:57:46 <bitcoin-git> [bitcoin] jnewbery opened pull request #15243: [doc] add notes on release notes (master...release_notes) https://github.com/bitcoin/bitcoin/pull/15243
2492019-01-24T14:57:46 *** bitcoin-git has left #bitcoin-core-dev
2502019-01-24T15:09:36 *** elichai2 has joined #bitcoin-core-dev
2512019-01-24T15:15:32 *** hebasto has joined #bitcoin-core-dev
2522019-01-24T15:16:30 *** promag has joined #bitcoin-core-dev
2532019-01-24T15:19:18 *** timothy has quit IRC
2542019-01-24T15:19:20 <promag> achow101: sorry, it's not your PR, master fails for me. Looks like the problem was introduced in #14955
2552019-01-24T15:19:23 <gribble> https://github.com/bitcoin/bitcoin/issues/14955 | Switch all RNG code to the built-in PRNG by sipa · Pull Request #14955 · bitcoin/bitcoin · GitHub
2562019-01-24T15:21:26 *** cubancorona has joined #bitcoin-core-dev
2572019-01-24T15:22:19 <sipa> promag: there is already an open PR to fix it
2582019-01-24T15:22:56 <sipa> #15223
2592019-01-24T15:22:58 <gribble> https://github.com/bitcoin/bitcoin/issues/15223 | Doc: add information about security to the JSON-RPC doc by harding · Pull Request #15223 · bitcoin/bitcoin · GitHub
2602019-01-24T15:23:05 <sipa> hmm, no
2612019-01-24T15:23:10 <promag> 15233
2622019-01-24T15:23:12 <sipa> #15233
2632019-01-24T15:23:14 <gribble> https://github.com/bitcoin/bitcoin/issues/15233 | Prevent mutex lock fail even if --enable-debug by AkioNak · Pull Request #15233 · bitcoin/bitcoin · GitHub
2642019-01-24T15:24:08 <promag> how come #14955 got merged with this problem?
2652019-01-24T15:24:12 <gribble> https://github.com/bitcoin/bitcoin/issues/14955 | Switch all RNG code to the built-in PRNG by sipa · Pull Request #14955 · bitcoin/bitcoin · GitHub
2662019-01-24T15:25:22 *** fanquake has quit IRC
2672019-01-24T15:25:58 <promag> provoostenator: I think you test on macos?
2682019-01-24T15:30:36 *** michaelsdunn1 has joined #bitcoin-core-dev
2692019-01-24T15:31:09 *** michaels_ has joined #bitcoin-core-dev
2702019-01-24T15:34:47 *** michaelsdunn1 has quit IRC
2712019-01-24T15:35:08 *** jhfrontz has quit IRC
2722019-01-24T15:35:35 *** jhfrontz has joined #bitcoin-core-dev
2732019-01-24T15:40:35 <sipa> promag: it needs --enable-debug to detect
2742019-01-24T15:41:15 <promag> right, I have configure with CPPFLAGS=-DDEBUG_LOCKORDER
2752019-01-24T15:42:15 <provoostenator> promag: yes
2762019-01-24T15:42:54 <promag> actually I always have that enabled
2772019-01-24T15:44:00 <provoostenator> That's a good one to use next time, yes. Can we make Travis do that as well?
2782019-01-24T15:44:21 <promag> it does I think
2792019-01-24T15:44:43 <promag> it checks lock order
2802019-01-24T15:45:04 <provoostenator> But Travis didn't fail. Is there a test that would catch this?
2812019-01-24T15:46:40 <sipa> travis doesn't run osx, does it?
2822019-01-24T15:47:09 <promag> not sure, looks like this is macos only?
2832019-01-24T15:47:14 <sipa> yes
2842019-01-24T15:48:00 <promag> I'll review the fix
2852019-01-24T15:48:49 *** laurentmt has quit IRC
2862019-01-24T15:49:36 <provoostenator> Travis machine 10 cross compiles to bitcoin-x86_64-apple-darwin14, but that only compiles and doesn't run tests (obviously).
2872019-01-24T15:50:10 <provoostenator> There's this though: https://docs.travis-ci.com/user/reference/osx/ (never tried it)
2882019-01-24T15:53:09 <promag> ok
2892019-01-24T15:56:47 <provoostenator> See also #15241
2902019-01-24T15:56:49 <gribble> https://github.com/bitcoin/bitcoin/issues/15241 | travis: add --enable-debug macos build by kallewoof · Pull Request #15241 · bitcoin/bitcoin · GitHub
2912019-01-24T15:57:08 *** pinheadmz has joined #bitcoin-core-dev
2922019-01-24T16:07:08 *** mistergold has joined #bitcoin-core-dev
2932019-01-24T16:09:52 *** kexkey has joined #bitcoin-core-dev
2942019-01-24T16:17:12 *** promag has quit IRC
2952019-01-24T16:17:40 *** setpill has quit IRC
2962019-01-24T16:23:26 *** MrPaz has quit IRC
2972019-01-24T16:29:34 *** promag has joined #bitcoin-core-dev
2982019-01-24T16:33:56 *** promag has quit IRC
2992019-01-24T16:37:34 *** miknotauro has joined #bitcoin-core-dev
3002019-01-24T16:43:22 *** Randolf has quit IRC
3012019-01-24T17:04:46 *** promag has joined #bitcoin-core-dev
3022019-01-24T17:05:09 *** jhfrontz has quit IRC
3032019-01-24T17:08:50 *** Murch has joined #bitcoin-core-dev
3042019-01-24T17:11:11 *** Murch has quit IRC
3052019-01-24T17:15:46 *** promag has quit IRC
3062019-01-24T17:17:56 *** JackH has quit IRC
3072019-01-24T17:21:40 *** sfhi has joined #bitcoin-core-dev
3082019-01-24T17:21:53 *** ThomasLuong has joined #bitcoin-core-dev
3092019-01-24T17:26:56 *** promag has joined #bitcoin-core-dev
3102019-01-24T17:29:24 <wumpus> did github stop turning commit ids into links?
3112019-01-24T17:29:53 <wumpus> seeing a lot of (ut)ACKs with commit ids that stay plain text, see e.g. https://github.com/bitcoin/bitcoin/pull/15112
3122019-01-24T17:30:25 *** ddustin has joined #bitcoin-core-dev
3132019-01-24T17:32:51 *** cubancorona has quit IRC
3142019-01-24T17:33:11 *** cubancorona has joined #bitcoin-core-dev
3152019-01-24T17:33:53 *** trillhc2 has joined #bitcoin-core-dev
3162019-01-24T17:34:38 *** ddustin has quit IRC
3172019-01-24T17:36:16 *** trillhc has quit IRC
3182019-01-24T17:37:35 *** mistergo1d has joined #bitcoin-core-dev
3192019-01-24T17:38:40 *** mistergold has quit IRC
3202019-01-24T17:42:56 <promag> wumpus: I think that's the case when the commit is garbage
3212019-01-24T17:43:11 <promag> and is no longer available
3222019-01-24T17:43:47 <promag> there's also the case when 7chars is not enough
3232019-01-24T17:44:23 <promag> enough because there's multiple commits with the same 7 initial chars
3242019-01-24T17:57:23 *** pinheadmz has quit IRC
3252019-01-24T17:58:07 *** miknotauro has quit IRC
3262019-01-24T18:00:08 *** JackH has joined #bitcoin-core-dev
3272019-01-24T18:00:37 <wumpus> promag: I'm suddenly seeing it a lot though, did everyone suddenly start mispasting commit ids?
3282019-01-24T18:01:11 <wumpus> of course I know that a garbage commit ID won't be turned into a link
3292019-01-24T18:02:26 <promag> idk, it must be a gh problem
3302019-01-24T18:03:01 *** sfhi has quit IRC
3312019-01-24T18:05:24 *** Murch has joined #bitcoin-core-dev
3322019-01-24T18:10:43 *** bitcoin-git has joined #bitcoin-core-dev
3332019-01-24T18:10:44 <bitcoin-git> [bitcoin] instagibbs opened pull request #15244: gdb attaching to process during tests has non-sudo solution (master...gdb_ptrace) https://github.com/bitcoin/bitcoin/pull/15244
3342019-01-24T18:10:44 *** bitcoin-git has left #bitcoin-core-dev
3352019-01-24T18:14:19 *** promag has quit IRC
3362019-01-24T18:17:06 *** michaelsdunn1 has joined #bitcoin-core-dev
3372019-01-24T18:17:06 *** michaelsdunn1 has joined #bitcoin-core-dev
3382019-01-24T18:19:07 *** michaels_ has quit IRC
3392019-01-24T18:23:10 *** harrigan has quit IRC
3402019-01-24T18:23:19 *** harrigan has joined #bitcoin-core-dev
3412019-01-24T18:31:27 *** ThomasLuong has quit IRC
3422019-01-24T18:32:55 *** ThomasLuong has joined #bitcoin-core-dev
3432019-01-24T18:36:35 *** pinheadmz has joined #bitcoin-core-dev
3442019-01-24T18:37:11 *** mistergold has joined #bitcoin-core-dev
3452019-01-24T18:40:11 *** rex4539 has quit IRC
3462019-01-24T18:40:12 *** mistergo1d has quit IRC
3472019-01-24T18:45:01 *** rh0nj has quit IRC
3482019-01-24T18:46:07 *** rh0nj has joined #bitcoin-core-dev
3492019-01-24T18:52:34 *** promag has joined #bitcoin-core-dev
3502019-01-24T18:53:23 *** promag_ has joined #bitcoin-core-dev
3512019-01-24T18:56:56 *** promag has quit IRC
3522019-01-24T18:57:12 *** ddustin has joined #bitcoin-core-dev
3532019-01-24T18:59:03 *** mistergo1d has joined #bitcoin-core-dev
3542019-01-24T19:00:13 <achow101> meeting?
3552019-01-24T19:00:15 <jnewbery> hi
3562019-01-24T19:00:19 <gleb> hi
3572019-01-24T19:00:33 <sipa> hi
3582019-01-24T19:00:54 <wumpus> #startmeeting
3592019-01-24T19:00:54 <lightningbot> Meeting started Thu Jan 24 19:00:54 2019 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
3602019-01-24T19:00:54 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
3612019-01-24T19:00:55 <provoostenator> hi
3622019-01-24T19:01:14 <moneyball> topic proposed by jnewbery: Chaincode summer residency: looking for (remote) mentors and recommendations for residents
3632019-01-24T19:01:20 <sipa> suggested topic: globals and initialization order
3642019-01-24T19:01:50 <promag_> hi
3652019-01-24T19:01:51 <wumpus> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101 meshcollider jnewbery maaku fanquake promag provoostenator aj Chris_Stewart_5 dongcarl gwillen jamesob ken281221 ryanofsky gleb
3662019-01-24T19:01:54 <instagibbs> hi
3672019-01-24T19:01:55 <meshcollider> hi
3682019-01-24T19:01:57 *** promag_ is now known as promag
3692019-01-24T19:01:58 <jamesob> yo
3702019-01-24T19:02:03 <gwillen> \o
3712019-01-24T19:02:06 <marcinja> hi
3722019-01-24T19:02:08 *** mistergold has quit IRC
3732019-01-24T19:02:29 <wumpus> #topic High priority for review
3742019-01-24T19:03:02 *** a__ has joined #bitcoin-core-dev
3752019-01-24T19:03:09 <wumpus> #11082 #14491 #14711 #14897 #15153 #15226
3762019-01-24T19:03:13 <gribble> https://github.com/bitcoin/bitcoin/issues/11082 | Add new bitcoin_rw.conf file that is used for settings modified by this software itself by luke-jr · Pull Request #11082 · bitcoin/bitcoin · GitHub
3772019-01-24T19:03:16 <gribble> https://github.com/bitcoin/bitcoin/issues/14491 | Allow descriptor imports with importmulti by MeshCollider · Pull Request #14491 · bitcoin/bitcoin · GitHub
3782019-01-24T19:03:21 <gribble> https://github.com/bitcoin/bitcoin/issues/14711 | Remove uses of chainActive and mapBlockIndex in wallet code by ryanofsky · Pull Request #14711 · bitcoin/bitcoin · GitHub
3792019-01-24T19:03:23 <gribble> https://github.com/bitcoin/bitcoin/issues/14897 | randomize GETDATA(tx) request order and introduce bias toward outbound by naumenkogs · Pull Request #14897 · bitcoin/bitcoin · GitHub
3802019-01-24T19:03:25 <gribble> https://github.com/bitcoin/bitcoin/issues/15153 | gui: Add Open Wallet menu by promag · Pull Request #15153 · bitcoin/bitcoin · GitHub
3812019-01-24T19:03:27 <gribble> https://github.com/bitcoin/bitcoin/issues/15226 | Allow creating blank (empty) wallets (alternative) by achow101 · Pull Request #15226 · bitcoin/bitcoin · GitHub
3822019-01-24T19:03:47 *** Dean_Guss has quit IRC
3832019-01-24T19:03:55 <wumpus> anything to be added or removed?
3842019-01-24T19:04:20 <achow101> can I have #15225 on hi prio?
3852019-01-24T19:04:23 <gribble> https://github.com/bitcoin/bitcoin/issues/15225 | GUI: Change the receive button to respond to keypool state changing by achow101 · Pull Request #15225 · bitcoin/bitcoin · GitHub
3862019-01-24T19:04:27 <promag> regarding open wallet menu - there are concerns regarding blocking GUI - is this something to avoid or can it be improved in 0.18.1?
3872019-01-24T19:04:30 <jamesob> #15118
3882019-01-24T19:04:33 <gribble> https://github.com/bitcoin/bitcoin/issues/15118 | Refactor block file logic by jimpo · Pull Request #15118 · bitcoin/bitcoin · GitHub
3892019-01-24T19:04:37 <achow101> it's actually a blocker for 15226
3902019-01-24T19:05:07 <wumpus> 14711 should be almost mergeable
3912019-01-24T19:05:13 <jnewbery> +1 for #15118. It blocks #14121
3922019-01-24T19:05:15 <gribble> https://github.com/bitcoin/bitcoin/issues/15118 | Refactor block file logic by jimpo · Pull Request #15118 · bitcoin/bitcoin · GitHub
3932019-01-24T19:05:19 <gribble> https://github.com/bitcoin/bitcoin/issues/14121 | Index for BIP 157 block filters by jimpo · Pull Request #14121 · bitcoin/bitcoin · GitHub
3942019-01-24T19:05:22 <wumpus> though promag keeps commenting so I'm not sure xD
3952019-01-24T19:05:39 <gwillen> I am hoping for movement on #13932 but I think it needs love from achow101 more than review at present
3962019-01-24T19:05:42 <gribble> https://github.com/bitcoin/bitcoin/issues/13932 | Additional utility RPCs for PSBT by achow101 · Pull Request #13932 · bitcoin/bitcoin · GitHub
3972019-01-24T19:05:55 *** michaels_ has joined #bitcoin-core-dev
3982019-01-24T19:05:57 <achow101> gwillen: oh yeah, I forgot to update that
3992019-01-24T19:06:06 <promag> wumpus: :(
4002019-01-24T19:06:09 <gwillen> achow101: lmk if there's any way I can help!
4012019-01-24T19:07:16 <wumpus> promag: I don't mean that negatively! if there's issues there's issues no matter *when* you find them, just mean it postpones the merge if there's new review comments
4022019-01-24T19:07:58 <wumpus> ok added #15225 #15118
4032019-01-24T19:08:00 <gribble> https://github.com/bitcoin/bitcoin/issues/15225 | GUI: Change the receive button to respond to keypool state changing by achow101 · Pull Request #15225 · bitcoin/bitcoin · GitHub
4042019-01-24T19:08:02 <gribble> https://github.com/bitcoin/bitcoin/issues/15118 | Refactor block file logic by jimpo · Pull Request #15118 · bitcoin/bitcoin · GitHub
4052019-01-24T19:08:05 <jamesob> wumpus: thanks
4062019-01-24T19:08:09 <wumpus> let's also try to remove (merge) a few this weke
4072019-01-24T19:08:36 <phantomcircuit> hi
4082019-01-24T19:09:02 <wumpus> 8 is kind of a lot to have on the list, and closer to the release the focus shifts to the milestone instead of this list
4092019-01-24T19:09:13 *** michaelsdunn1 has quit IRC
4102019-01-24T19:10:00 <sdaftuar> #15141 is ready for review again btw
4112019-01-24T19:10:03 <wumpus> so 2019-02-01 is string freeze, 2019-02-15 is feature freeze for 0.18
4122019-01-24T19:10:04 <gribble> https://github.com/bitcoin/bitcoin/issues/15141 | Rewrite DoS interface between validation and net_processing by sdaftuar · Pull Request #15141 · bitcoin/bitcoin · GitHub
4132019-01-24T19:10:04 <sdaftuar> oops
4142019-01-24T19:10:18 <sdaftuar> oh, wait i did type that correcly
4152019-01-24T19:10:26 <sipa> sdaftuar: cool will review
4162019-01-24T19:10:27 <jonasschnelli> hi
4172019-01-24T19:11:07 <wumpus> #topic Globals and initialization order (sipa)
4182019-01-24T19:11:21 <sipa> hi!
4192019-01-24T19:11:56 <sipa> we currently have a bit of a mix in the codebase for dealing with initialization order of globals
4202019-01-24T19:12:29 <sipa> some things are explicitly initialized using init functions, called from main/test startup
4212019-01-24T19:12:42 <sipa> some things are initialized just using global initializers
4222019-01-24T19:13:08 <sipa> and some things are using once/init-on-first-use-block-scoped-statics
4232019-01-24T19:13:32 <sipa> and mixing them is pretty fragile
4242019-01-24T19:14:16 <wumpus> I prefer explicit initializer functions unless it's simply setting a value, at least it's perfectly clear what the order is in which things get initialized
4252019-01-24T19:14:37 <wumpus> which is very important if things depend on each other
4262019-01-24T19:14:49 <wumpus> also things running before main() is quite annoying for debugging
4272019-01-24T19:14:52 <sipa> the problem is that with explicit initializer functions, things don't work when called from global initializer
4282019-01-24T19:16:08 <wumpus> (and things that take significant time to run certainly shouldn't be called from global initializers, as they'll delay showing even, say, the help message, which doesn't need any initialization at all)
4292019-01-24T19:16:32 <sipa> and i think we actually had a long-standing problem with the RNG, which was used possibly before being initialized (since #14955 it uses an init-on-first use construction, which should always be fine)
4302019-01-24T19:16:36 <gribble> https://github.com/bitcoin/bitcoin/issues/14955 | Switch all RNG code to the built-in PRNG by sipa · Pull Request #14955 · bitcoin/bitcoin · GitHub
4312019-01-24T19:17:18 <wumpus> anyhow that's my opinion on it, I'm aware the codebase is quite crazy in that regard, we've had initialation order issues since the first release...
4322019-01-24T19:17:44 <promag> sipa: what's your preference?
4332019-01-24T19:17:49 <sipa> so i'm getting more and more in favor of using this init-on-first-use construction in more places
4342019-01-24T19:17:56 *** csknk has joined #bitcoin-core-dev
4352019-01-24T19:17:57 <wumpus> meh
4362019-01-24T19:18:00 <sipa> since it's compatible with everything
4372019-01-24T19:18:12 <wumpus> it's hard to reason about
4382019-01-24T19:18:14 *** pinheadmz has quit IRC
4392019-01-24T19:18:35 <jimpo> I also like explicit initialization of non-trivial things
4402019-01-24T19:18:36 <wumpus> accidentally using something before something else will suddenly change the initialization order
4412019-01-24T19:18:38 <wumpus> instead of just fail
4422019-01-24T19:18:46 <wumpus> we've seen that with logging, for example
4432019-01-24T19:18:58 <sipa> that's because logging using a global initialized
4442019-01-24T19:19:01 <provoostenator> I'm in favor of having fewer globals :-) But otherwise haven't really developed a preference in C++
4452019-01-24T19:19:28 <promag> I prefer explicit order initialization
4462019-01-24T19:19:49 <wumpus> initializing on first use also doesn't really regard initialization dependencies
4472019-01-24T19:19:49 <luke-jr> wumpus: in a bad way? the only time I can think of order mattering is when we're pre-config-files-loaded
4482019-01-24T19:20:09 <sipa> wumpus: how so?
4492019-01-24T19:20:10 <wumpus> like "we need to have the datadirectory set before writing to it"
4502019-01-24T19:20:13 <luke-jr> (thinking RNG specifically)
4512019-01-24T19:20:38 <sipa> oh, i'm not really talking about application level things
4522019-01-24T19:21:09 <sipa> more things like RNG, logging objects (not actually setting the logfile, which happens later), libsecp, ...
4532019-01-24T19:21:21 <sipa> syncronization debugging state
4542019-01-24T19:21:31 <wumpus> if it's really only setting a value to a data structure I agree it's different, but if there's extensive work that might depend on other or OS things, it gets hairy fast
4552019-01-24T19:21:51 <wumpus> only allocating a data structure on first use is fine...
4562019-01-24T19:22:03 <gmaxwell> It's also important to avoid undefined behavior over and above just avoiding doing the wrong thing.
4572019-01-24T19:22:24 <sipa> basically the RNG right now can't use the SHA module, because the RNG is invoked from global constructors (and it works fine with it), and SHA needs explicit initialzation
4582019-01-24T19:22:46 <wumpus> but I think we agree that global constructors are bad
4592019-01-24T19:22:49 <wumpus> that's one thing :)
4602019-01-24T19:23:04 <sipa> so i think there are two solutions to that... avoid global constructors everywhere, or make everything work fine on first use
4612019-01-24T19:23:55 <wumpus> (I here mean global constructors as 'runs before main', not the static initializers that run on first use)
4622019-01-24T19:24:03 <sipa> wumpus: right
4632019-01-24T19:24:31 <sipa> wumpus: so what's your opinion on solving this particular issue?
4642019-01-24T19:24:35 <gmaxwell> Or make SHA module's autodetect get resolved by the linker, using the GCC extension that does that. :P
4652019-01-24T19:25:20 <gmaxwell> (doesn't address the general question about dependencies between global constructors)
4662019-01-24T19:25:23 <wumpus> sipa: so move to initialization on first use or explicit initialization, whatever makes sense in the case, move away from global initializers that do anything more significant than assigning a constant value
4672019-01-24T19:25:27 <sipa> we can get rid of all globals whose construction needs randomness, but making the SHA256 code autodetect on first use seems a simpler change
4682019-01-24T19:25:53 <wumpus> I really like how you got rid of CInit, for example
4692019-01-24T19:26:04 <gmaxwell> The downside of autodetect on first use is that it would make every call to sha256 slightly slower. :(
4702019-01-24T19:26:46 <gmaxwell> One way to compensate for that would be make sure that there is a batch sha256 function that does many of them and only does the detection once, and be sure to use it where possible.
4712019-01-24T19:27:12 <sipa> gmaxwell: hmm?
4722019-01-24T19:27:38 <sipa> i benchmarked it as a 1.8ns slowdown here to use an on-first-use construction
4732019-01-24T19:27:49 <gmaxwell> sipa: I assume 'autodetect on first use' means "Check a synchronized variable every time the function is run".
4742019-01-24T19:27:55 <sipa> gmaxwell: nope!
4752019-01-24T19:28:24 <sipa> it actually compiles to both a synchronized and unsynchronized variable, and in the initialized case, only the latter is checked
4762019-01-24T19:28:33 <gmaxwell> Okay, 1.8ns doesn't sound that terrible. What the runtime of the function on that host?
4772019-01-24T19:28:36 <wumpus> nice
4782019-01-24T19:28:55 <gmaxwell> sipa: how does it know its initialized?
4792019-01-24T19:29:26 <wumpus> though this is a compiler implementation specific thing, clang and gcc might not do it the same way?
4802019-01-24T19:29:37 <sipa> gmaxwell: it's just a boolean; when the boolean is false, it means it could be initialized or not (to be checked using synchronized primitives), if it is true, it is guaranteed to be initialized
4812019-01-24T19:30:10 *** pinheadmz has joined #bitcoin-core-dev
4822019-01-24T19:30:22 <sipa> from cppreference.com:If multiple threads attempt to initialize the same static local variable concurrently, the initialization occurs exactly once (similar behavior can be obtained for arbitrary functions with std::call_once).
4832019-01-24T19:30:26 <sipa> Note: usual implementations of this feature use variants of the double-checked locking pattern, which reduces runtime overhead for already-initialized local statics to a single non-atomic boolean comparison.
4842019-01-24T19:30:41 <wumpus> good to know
4852019-01-24T19:31:02 <gmaxwell> in any case, I think that seems an obviously better way to handle it. Residual performance concerns could be handled by my above batching suggestion (which would be a win regardless because of function call overheads). MOST places where we'd have this concern wouldn't be a big performance bottleneck like sha256 is.
4862019-01-24T19:31:19 <wumpus> exactly
4872019-01-24T19:31:25 <wumpus> maybe sha256 is just special here
4882019-01-24T19:31:41 <wumpus> and we can at least decide for the general case
4892019-01-24T19:31:45 <sipa> agree
4902019-01-24T19:32:02 <sipa> enough on this topic, i think
4912019-01-24T19:32:05 <wumpus> ok!
4922019-01-24T19:32:23 <gmaxwell> well I could see the same problem showing up for crc32 and being worse, because 1.8ns would be like a 2x slowdown for it. :P but otherwise I can't come up with much where a 1.8ns slowdown would matter.
4932019-01-24T19:32:39 <wumpus> #topic Chaincode summer residency (jnewbery)
4942019-01-24T19:32:40 <luke-jr> could have the calls be pointers that get changed on initialisation (I thought we already did?)
4952019-01-24T19:32:45 *** Krellan has quit IRC
4962019-01-24T19:32:56 <jnewbery> hi
4972019-01-24T19:33:06 <wumpus> luke-jr: that means the overhead of an indirect function call every time, that's worse than checking a boolean
4982019-01-24T19:33:19 <jnewbery> we're hosting the next iteration of the Chaincode residency this summer
4992019-01-24T19:33:34 <jnewbery> it'll be in our new office in Midtown Manhattan
5002019-01-24T19:33:41 <jnewbery> details are here: https://residency.chaincode.com/
5012019-01-24T19:34:00 <wumpus> great!
5022019-01-24T19:34:05 <jnewbery> we'll take care of sourcing residents, paying travel/accommodation/stipend and hosting them in our office
5032019-01-24T19:34:20 <sipa> nice!
5042019-01-24T19:34:35 <provoostenator> nice!
5052019-01-24T19:34:48 <jnewbery> it's 2-3 weeks of seminars followed by 2 months of project work. We're expecting the residents to make really meaningful contributions to Bitcoin Core and other Bitcoin/Lightning projects while they're here
5062019-01-24T19:35:05 <jnewbery> I bring this up here because we need help for a couple of things:
5072019-01-24T19:35:51 <jnewbery> 1. We (Chaincode) will be doing the heavy lifting for the seminar series and hosting, but we need (remote) mentors for the 2 month project period.
5082019-01-24T19:36:03 <kanzure> what are the responsibilities of the mentors
5092019-01-24T19:36:12 *** Randolf has joined #bitcoin-core-dev
5102019-01-24T19:36:31 <jnewbery> each resident will be paired with a mentor. We're looking for 1 hour per week video calls with the resident to help guide them in their project
5112019-01-24T19:37:13 <jnewbery> obviously chaincoders and their peers will be on hand for incidental questions during the week, and the mentor will be providing overall guidance helping with the project
5122019-01-24T19:37:28 <meshcollider> Will the peers be chosen based on areas of knowledge
5132019-01-24T19:37:43 <instagibbs> jnewbery, what's the action item here? ping you if interested in mentoring?
5142019-01-24T19:38:01 <jamesob> oh don't worry instagibbs, we've already signed you up
5152019-01-24T19:38:06 <jamesob> ;)
5162019-01-24T19:38:08 <jnewbery> We'll try to pair residents with mentors who have overlapping interests obviously
5172019-01-24T19:38:16 <jnewbery> instagibbs - I'll be reaching out individually
5182019-01-24T19:38:40 <instagibbs> hah
5192019-01-24T19:38:50 <instagibbs> ok, so check e-mails DMs
5202019-01-24T19:39:07 <jnewbery> 2. We're looking for recommendations for residents. If you know anyone who wants to immerse themselves in Bitcoin/Lightning over summer and is excited about making a real contribution to the project, please send them our way
5212019-01-24T19:39:23 <jnewbery> Adam Jonas is taking the lead on organizing this one
5222019-01-24T19:39:41 <jnewbery> So you can ping him or me if you have any questions
5232019-01-24T19:40:15 <jnewbery> that's it!
5242019-01-24T19:40:37 <wumpus> ok! thanks for organizing this
5252019-01-24T19:40:46 <jnewbery> We're really excited about this one. The longer format means we're expecting to have a lot of great contributions from the residents
5262019-01-24T19:41:09 <wumpus> hope so!
5272019-01-24T19:41:43 <wumpus> any other topics?
5282019-01-24T19:42:19 <jnewbery> one reminder: I'd encourage people to use moneyball's #proposedmeetingtopic to propose meeting topics during the week!
5292019-01-24T19:42:33 <gmaxwell> Could I nag for review on #14929 ? it's getting forced to rebase faster than its being reviewed...
5302019-01-24T19:42:36 <gribble> https://github.com/bitcoin/bitcoin/issues/14929 | net: Allow connections from misbehavior banned peers by gmaxwell · Pull Request #14929 · bitcoin/bitcoin · GitHub
5312019-01-24T19:43:06 <sdaftuar> gmaxwell: yep i'm actually in the middle of re-reviewing so i can re-ack
5322019-01-24T19:43:18 <wumpus> #action review #14929
5332019-01-24T19:43:19 <sipa> add to high priority?
5342019-01-24T19:43:21 <gribble> https://github.com/bitcoin/bitcoin/issues/14929 | net: Allow connections from misbehavior banned peers by gmaxwell · Pull Request #14929 · bitcoin/bitcoin · GitHub
5352019-01-24T19:43:35 <wumpus> ok
5362019-01-24T19:44:32 <gmaxwell> Thanks.
5372019-01-24T19:46:21 <wumpus> that... concludes the meeting, I guess
5382019-01-24T19:47:19 <wumpus> #endmeeting
5392019-01-24T19:47:19 <lightningbot> Meeting ended Thu Jan 24 19:47:19 2019 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
5402019-01-24T19:47:19 <lightningbot> Minutes: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2019/bitcoin-core-dev.2019-01-24-19.00.html
5412019-01-24T19:47:19 <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2019/bitcoin-core-dev.2019-01-24-19.00.txt
5422019-01-24T19:47:19 <lightningbot> Log: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2019/bitcoin-core-dev.2019-01-24-19.00.log.html
5432019-01-24T19:48:04 <achow101> does anyone have an opinion on whether encrypting a blank wallet should generate a seed for it?
5442019-01-24T19:48:52 <luke-jr> hmm, it might be nice to have all the security-critical stuff generated at once
5452019-01-24T19:49:26 <luke-jr> eg, so people who have a no-RNG system can make the wallet easily on one that has a RNG and then backup/restore it
5462019-01-24T19:49:48 <luke-jr> but that may be independent of encryption or not
5472019-01-24T19:49:57 <wumpus> is it even sensible
5482019-01-24T19:50:06 <wumpus> to encrypt a blank wallet? encryption only protects private data, after all
5492019-01-24T19:50:25 <achow101> the only thing I can think of is encrypting a blank wallet and then importing privat ekeys
5502019-01-24T19:50:48 <wumpus> ah yes
5512019-01-24T19:52:01 <gmaxwell> I like the idea that "if you have a wallet file, you can back that up, and your backup is not likely to be surprise invalidated."
5522019-01-24T19:52:28 <gmaxwell> under that thinking: wallets should be born encrypted and also born with their master keys.
5532019-01-24T19:52:55 <gmaxwell> If you import things, you invalidate backups, sucks to be you. At least the import (docs) can warn you of this.
5542019-01-24T19:53:17 <gmaxwell> I dunno if "wallet which is blank except for imported keys" is a case we should care much about supporting.
5552019-01-24T19:54:41 <gmaxwell> luke-jr: I'd like us to have wallet loading take the high entropy data from a loaded wallet (e.g. encrypted master key, or first key in non-encrypted wallets) and hash that into the RNG state. That would achieve what you want as a side effect.
5562019-01-24T19:54:46 <achow101> since I want blank wallets as a stepping stone to born encrypted wallets, I prefer that encrypting would generate the seed
5572019-01-24T19:55:00 <gmaxwell> luke-jr: (similarly, we should also be hashing any rpcauth credentials into the RNG state)
5582019-01-24T19:55:12 <gmaxwell> I see.
5592019-01-24T19:55:59 <achow101> but other people may want blank wallets for other reasons, which is why I ask
5602019-01-24T19:56:01 <gmaxwell> achow101: well I don't think it would be terrible to have blank wallets with no keys in them at all. At least they'd be obviously smaller? Long term though we should try to get it so that under normal workflows if there is a file there, thats the file you should be backing up.
5612019-01-24T19:56:27 <luke-jr> achow101: consider that some wallets might never have a seed
5622019-01-24T19:57:17 <achow101> luke-jr: we don't make non-hd wallets anymore.
5632019-01-24T19:57:51 <luke-jr> achow101: I'm thinking watch-JBOK-only
5642019-01-24T19:58:07 *** csknk has quit IRC
5652019-01-24T20:01:26 <achow101> luke-jr: right. I think that's the only case to not set a seed when encrypting
5662019-01-24T20:01:39 *** a__ has quit IRC
5672019-01-24T20:01:52 <luke-jr> well, watch-only means encryption is meaningless
5682019-01-24T20:01:57 <luke-jr> so nevermind that case
5692019-01-24T20:02:16 <achow101> oh, i thought you meant importing the privkeys
5702019-01-24T20:02:25 *** sc_ has joined #bitcoin-core-dev
5712019-01-24T20:02:30 <luke-jr> I suppose there might be a use case for that
5722019-01-24T20:02:46 <achow101> (that's what we were taling about earlier)
5732019-01-24T20:02:48 *** sc_ is now known as Guest55956
5742019-01-24T20:02:49 <luke-jr> but that seems roughly equivalent to non-HD wallets which isn't supported
5752019-01-24T20:05:28 <gwillen> I mean, it still makes sense to have support for legacy imported non-HD wallets
5762019-01-24T20:05:37 <luke-jr> gwillen: sure
5772019-01-24T20:05:55 <luke-jr> but the topic is strictly new wallets AFAIK
5782019-01-24T20:06:04 <gwillen> in fact, I think in the multiwallet world, it would make sense to split wallets into like (*) normal HD wallets, (*) watchonly wallets, (*) legacy importonly wallet
5792019-01-24T20:06:09 <gwillen> *nods*
5802019-01-24T20:06:30 <gwillen> but if you're going to import privkeys then you do want a blank empty wallet with no seed and encryption
5812019-01-24T20:07:12 <gmaxwell> I don't think we generally want to support that case so much as to special case it.
5822019-01-24T20:07:26 <gmaxwell> Having an extra seed and keys you don't use is harmless.
5832019-01-24T20:07:49 <gwillen> well, I'm afraid of it leading to "oopses"
5842019-01-24T20:07:53 <gmaxwell> (other than making the wallet bigger, but it's already going to be fairly big if you're importing a bunch of keys)
5852019-01-24T20:08:06 <luke-jr> gmaxwell: well, you don't want to accidentally use one of the keys
5862019-01-24T20:08:12 <gmaxwell> any manual private key handling already leads to oopses, which is why we already strongly discourage it.
5872019-01-24T20:08:14 <gwillen> like, when I was testing my new offline signing stuff, it autogenerated a change address using the wallet seed that I didn't want
5882019-01-24T20:08:18 <gwillen> and sent my change to it, oops
5892019-01-24T20:08:40 <gmaxwell> And exactly what would an imported keys only wallet do?
5902019-01-24T20:08:43 <gwillen> which I realized about 10 minutes before doing a live demo and frantically sent it back ;-)
5912019-01-24T20:08:58 <gwillen> I mean, it would let you spend from your legacy keys from your old wallet
5922019-01-24T20:09:10 <gwillen> although I guess that's messy if you don't spend all at once
5932019-01-24T20:09:15 <luke-jr> gmaxwell: if it has no solution, throw an error
5942019-01-24T20:09:18 <gwillen> because you still have to handle change _somehow_
5952019-01-24T20:09:22 <achow101> gwillen: that implies address reuse, no?
5962019-01-24T20:09:23 <gmaxwell> gwillen: right.
5972019-01-24T20:09:36 <gmaxwell> It implies: this is just not a supported case.
5982019-01-24T20:09:49 <luke-jr> you might have imported a keypool too
5992019-01-24T20:10:05 <luke-jr> not sure if it's possible to mark them as such, but we do allow manually specifying change addresses
6002019-01-24T20:10:23 <gmaxwell> If you're going to manually specify change addresses, you don't have gwillen's problem.
6012019-01-24T20:10:45 <luke-jr> gmaxwell: if you forget to, it's better to get an exception than potentially lose funds
6022019-01-24T20:12:07 <achow101> I think the question is really whether this is a case that happens frequently enough that it is something we should support
6032019-01-24T20:12:28 <gmaxwell> There are 1001 other wallet features that deserve love, attention, writing, and review... going through and breaking the design assumption that you can always get a key from a signable wallet just to support a currently unsupported and known risky usage, seems like a really bad idea. Esp when the subject of doing it came up as an excercise in thinking about how some other case is handled,
6042019-01-24T20:12:28 <gmaxwell> rather than someone showing up and saying "it should support this and heres why"
6052019-01-24T20:12:29 <achow101> to support it requires adding more parameters to encryptwallet and getting a born encrypted wallet needs another step
6062019-01-24T20:12:46 <luke-jr> achow101: I can't think of a good reason to support it
6072019-01-24T20:13:48 <luke-jr> any case where it *might* make sense can also do a watch-only wallet and provide private keys to signraw as needed I think
6082019-01-24T20:15:57 <achow101> agreed
6092019-01-24T20:17:18 <gmaxwell> unrelated, it would be kinda neat if there were a backupwallet rpc that made a watching wallet by playing the keypools arbritarily far forward and then writing out a wallet without private keys.
6102019-01-24T20:19:31 *** hebasto has quit IRC
6112019-01-24T20:21:38 <provoostenator> gmaxwell: or just use a descriptor to import whatever you want in a watch-only wallet, requires: #14075
6122019-01-24T20:21:41 <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
6132019-01-24T20:23:11 <gmaxwell> Using a single descriptor forces you to use security toxic non-hardened keys. Plus doing that (using the descriptor at all) violates the principle that directly handling keys is risky and fault prone.
6142019-01-24T20:23:53 <gmaxwell> Note that descriptors don't have checksums, a simple typo or copy-paste error can result in your funds blasting off into space.
6152019-01-24T20:24:18 <provoostenator> achow: as for encrypting an empty wallet, easiest might be to just a bool param where user can decide if a seed is added
6162019-01-24T20:24:52 <sipa> gmaxwell: the idea is for descriptor wallets to contained cached pre-expanded public keys
6172019-01-24T20:25:03 <provoostenator> gmaxwell: you could use hardened derivation too if you include a private key in the descriptor (which is not saved)
6182019-01-24T20:25:13 <provoostenator> (and that currently doesn't work probably)
6192019-01-24T20:25:25 <sipa> so you can use hardened bip32 keys as descriptor; they need access to the private key to derive, but not to otherwise use
6202019-01-24T20:26:11 <gmaxwell> provoostenator: fair on that point, doesn't address my second point... and that also means you're likely leaving private keys in your shell history.
6212019-01-24T20:26:48 <gwillen> hrm, why do descriptors _not_ have checksums?
6222019-01-24T20:26:59 *** promag has quit IRC
6232019-01-24T20:27:17 <gwillen> given their intended uses it seems like maybe they should
6242019-01-24T20:27:21 <gmaxwell> because they weren't intended to be some general construct for transporting keys around?
6252019-01-24T20:27:21 <sipa> gwillen: they're human editable
6262019-01-24T20:27:22 <provoostenator> gmaxwell: assuming the private keys are on a different device, that device could return an array of descriptors, one for each pubkey, in import format.
6272019-01-24T20:27:39 <provoostenator> As for checksums: that sounds solveable.
6282019-01-24T20:27:56 <gmaxwell> provoostenator: sweet, then you get a multiplicative blowup in possibilities to corrupt the data and cause funds to go off into space.
6292019-01-24T20:28:08 <sipa> gwillen: inside the wallet we could store them with a checksum, or even have a more efficient binary encoding
6302019-01-24T20:28:14 <gwillen> *nods*
6312019-01-24T20:28:40 <sipa> which would still be human accessible for transport, if they're intended to be treated as a black box
6322019-01-24T20:28:56 <gmaxwell> sipa: but its when humans touch them that they're most likely to get corrupted.
6332019-01-24T20:29:22 <gmaxwell> (as the now hundreds of millions lost in eth land due to corrupted addresses attest to...)
6342019-01-24T20:29:38 <gmaxwell> (humans and application boundaries)
6352019-01-24T20:30:13 <gmaxwell> The original descriptor work was largely wallet internal... it's mostly later efforts that have been turning them into a general key import/export thing. This seems ill-advised to me.
6362019-01-24T20:30:19 <provoostenator> So we need something to replace xpub that has a better checksum? Or does that still data corruption risk? Because something goes wrong inside of Bitcoin Core during the import?
6372019-01-24T20:31:27 <gmaxwell> xpub actually has a checksum, it's sufficient, as it was intended for use as an address.
6382019-01-24T20:32:29 <provoostenator> In #14912 I'm using xpubs all the way. The HWI tool (achow101) gets xpub(s) from the device.
6392019-01-24T20:32:34 <gribble> https://github.com/bitcoin/bitcoin/issues/14912 | [WIP] External signer support (e.g. hardware wallet) by Sjors · Pull Request #14912 · bitcoin/bitcoin · GitHub
6402019-01-24T20:32:59 <provoostenator> (though I'm not sure _how_ they are obtained from the device, that's probably worth double checking)
6412019-01-24T20:33:10 <gmaxwell> Corruption inside bitcoin is also a concern, but a strictly less serious one than corruption by humans or across application boundaries.
6422019-01-24T20:33:19 <provoostenator> If the device spits out a normal public key and the script converts it to an xpub then there's no point.
6432019-01-24T20:33:33 <achow101> provoostenator: it depends on the device. some give xpubs, other give pubkeys + chaincode which then become xpubs
6442019-01-24T20:33:39 <gmaxwell> For HWI you might want to consider an enrolling process that gets a signed message with one of the imported watch keys, to prove that the device can sign for the keys you're importing.
6452019-01-24T20:33:59 <provoostenator> Also there's a feature to show an address on the device display. We could make that mandatory for the receive address functionality to be on the safe side.
6462019-01-24T20:34:17 <gmaxwell> Which is analogous to the process bitcoin uses internally when generating keys: it signs a message and verifies, to make sure that the generated address/key actually work.
6472019-01-24T20:34:42 <achow101> gmaxwell: currently we have a displayaddress command where the address for a given derivation path is shown on the device's screen (if it has one). you can then compare that to the address the wallet gives you for that path
6482019-01-24T20:35:18 <provoostenator> Though perhaps betetr is to 1) import using xpubs and then 2) checking all imported keys with a call to the device
6492019-01-24T20:35:20 <gmaxwell> achow101: thats good, but I think thats more effective at checking for correct pairing than checking for corruption.
6502019-01-24T20:36:24 <gmaxwell> getting the device to sign something that you can verify is probably the gold standard for corruption checking. I'm not sure about how the devices work, but is it currently possible to import a device that you don't know the pin for, thus cannot actually sign with?
6512019-01-24T20:37:18 <provoostenator> You can always forget the pin and lose your backup. But the normal flow is that you unlock the device with the pin before it's willing to give your computer any pubkeys.
6522019-01-24T20:37:28 *** mistergold has joined #bitcoin-core-dev
6532019-01-24T20:37:45 <achow101> i think for all devices you need the pin/passphrase to do anything with it
6542019-01-24T20:38:16 <provoostenator> Capabilities vary per deivce, see this table: https://github.com/achow101/HWI#device-support
6552019-01-24T20:39:14 <gmaxwell> Okay, thats useful. I'm not sure if there are other ways that you could export keys but turn out not to be able to sign, except a device fault.
6562019-01-24T20:39:22 <provoostenator> Ideally we'd ask the device to sign something to prove it really has the keys. I don't know if devices can do that though, especially without user interaction.
6572019-01-24T20:39:49 <gmaxwell> ISTM that it wouldn't be too hard for the enrollment process though to ask the device to sign a message.. you're user interacting on the import to enter the pin in any case, no?
6582019-01-24T20:39:54 <achow101> signing anything requires user interaction
6592019-01-24T20:40:03 <achow101> otherwise it would be a huge security hole
6602019-01-24T20:40:07 <gmaxwell> But so does the import?
6612019-01-24T20:40:16 *** Randolf has quit IRC
6622019-01-24T20:40:23 <provoostenator> gmaxwell: the problem is that the device probably only signs 1 thing at a time, so checking 1000 addresses would be tedious.
6632019-01-24T20:40:34 <gmaxwell> I don't think it's necessary to check all the addresses.
6642019-01-24T20:40:39 <provoostenator> So then the next best thing is essentially just importing again and double checking.
6652019-01-24T20:40:40 <gmaxwell> But it's a big gain to check at least one.
6662019-01-24T20:41:03 <gmaxwell> provoostenator: importing again doesn't tell you that the device actually can sign, however.
6672019-01-24T20:41:28 *** mistergo1d has quit IRC
6682019-01-24T20:41:55 <achow101> for implementation with core, you could definitely make it import then sign a message
6692019-01-24T20:42:05 <achow101> right now where using HWI is manual, you do that manually
6702019-01-24T20:42:56 <gmaxwell> So for example, imagine a device doing public derrivation, botches the generation of the public key, and it caches that value (since its slow I bet all implementations store it). Any number of imports would give keys, they'd all look fine, but the device would fail to be able to sign for any of its keys.
6712019-01-24T20:43:05 <provoostenator> I suspect most devices don't cache public keys, and only store the seed. So if they can derive a valid address they can sign it.
6722019-01-24T20:43:17 <gmaxwell> With public derrivation in use, I can't think of any likely issue where it could sign for one key but not another.
6732019-01-24T20:43:23 <provoostenator> (until they can't, which is where backups become important)
6742019-01-24T20:44:09 <gmaxwell> If they don't cache the master pubkey, then indeed multiple imports would be different under that proposed failure mode.
6752019-01-24T20:44:37 <achow101> I don't think they cache the pubkeys, but that could change at any time and be different between devices
6762019-01-24T20:44:43 <gmaxwell> Though a 'also try to get a signed message on import' would catch faults in both implementations.
6772019-01-24T20:45:01 <achow101> deriving multiple keys with just different indexes is slow as fuck on all devices
6782019-01-24T20:45:04 <gmaxwell> Basically getting a signature is a fully general test to make sure signing works.
6792019-01-24T20:45:37 <gmaxwell> achow101: I was thinking they'd cache the master, not the child keys. but who knows, as you note it could change at any time.
6802019-01-24T20:45:37 <provoostenator> To the degree cache exists, it might also be ephemeral, so in that case asking the user to unplug and replug, might help.
6812019-01-24T20:45:50 <provoostenator> But this all varies per device. I agree signing would be better.
6822019-01-24T20:46:15 <achow101> gmaxwell: they all require hardened derivation at some point IIRC, so caching the master wouldn't be particularly helpful
6832019-01-24T20:46:15 <provoostenator> But devices don't like having code that can sign arbitrary stuff, for risk of an attacking abusing that.
6842019-01-24T20:46:21 <gmaxwell> right. Well we can only go so far too. :) But the standard we've set internally to bitcoin core is sign-after-generate.
6852019-01-24T20:46:38 <provoostenator> (sign arbitrary stuff without user approving, and checking all the details)
6862019-01-24T20:47:01 <gmaxwell> At enrollment time, a user approving one signature seems reasonsable.
6872019-01-24T20:47:12 <provoostenator> "internally to bitcoin core is sign-after-generate" - I didn't know we did that, that seems smart.
6882019-01-24T20:47:36 *** cubancorona has quit IRC
6892019-01-24T20:48:05 <gmaxwell> It's a response to a real failure-- in other wallet software a few years back-- that resulted in an extreme amount funds loss (that unfortunately is non-public).
6902019-01-24T20:48:11 <provoostenator> Even devices that don't have an official sign message feature, Bitcoin Core could just have it sign a fake transaction.
6912019-01-24T20:48:17 <gmaxwell> Indeed.
6922019-01-24T20:48:27 <provoostenator> (provably fake ideally)
6932019-01-24T20:48:53 <gmaxwell> 0 value, locktimed almost-forever far in the future would be nice.
6942019-01-24T20:49:03 <provoostenator> Or with a relative lock time after the heath death of the universe.
6952019-01-24T20:49:21 <gmaxwell> I think it would be nice to even do more than what Bitcoin Core currently does.. but priorities, the sign/verify after generate is a pretty general protection at least.
6962019-01-24T20:49:28 <achow101> provoostenator: that's actually largely not possible for most devices since they verify inputs
6972019-01-24T20:49:48 <achow101> oh, actually if you claim it's segwit that's fine
6982019-01-24T20:49:51 <provoostenator> Ah that pesky Segwit thing, but they still sign legacy transactions...
6992019-01-24T20:50:06 <provoostenator> Or you mean the other way around?
7002019-01-24T20:50:25 <achow101> sign a segwit input. they don't verify those inputs
7012019-01-24T20:51:06 <provoostenator> Ah ok, so for legacy they insist on seeing an entire transaction with inputs? That does get tedious.
7022019-01-24T20:51:23 <achow101> yeah
7032019-01-24T20:51:24 <provoostenator> But that could also be fake right?
7042019-01-24T20:51:33 <provoostenator> Spending non-existing coins.
7052019-01-24T20:51:42 <achow101> sure, but that's more work
7062019-01-24T20:51:58 <provoostenator> Indeed
7072019-01-24T20:56:41 <provoostenator> So I'll probably add something to my PR in the signerfetchkeys RPC method, which imports the keys, to call sign message on the device with one of the keys, and then check the result.
7082019-01-24T20:57:17 <provoostenator> Although there's no way to undo an import, at the RPC method would fail with a giant error telling the user to delete their new wallet and retry the import.
7092019-01-24T20:57:31 <provoostenator> *, at least the RPC...
7102019-01-24T20:59:22 *** Guest55956 has quit IRC
7112019-01-24T21:07:19 *** spaced0ut has quit IRC
7122019-01-24T21:12:41 *** promag has joined #bitcoin-core-dev
7132019-01-24T21:13:45 *** Guyver2 has quit IRC
7142019-01-24T21:29:30 *** molz has quit IRC
7152019-01-24T21:29:34 *** bitcoin-git has joined #bitcoin-core-dev
7162019-01-24T21:29:34 <bitcoin-git> [bitcoin] instagibbs opened pull request #15245: remove deprecated mentions of signrawtransaction from fundraw help (master...fundraw_signraw) https://github.com/bitcoin/bitcoin/pull/15245
7172019-01-24T21:29:34 *** bitcoin-git has left #bitcoin-core-dev
7182019-01-24T21:32:47 *** mistergo1d has joined #bitcoin-core-dev
7192019-01-24T21:36:04 *** mistergold has quit IRC
7202019-01-24T21:38:45 *** Krellan has joined #bitcoin-core-dev
7212019-01-24T21:41:16 *** IZooo has quit IRC
7222019-01-24T21:41:20 *** IzoooO has joined #bitcoin-core-dev
7232019-01-24T21:42:58 *** Krellan has quit IRC
7242019-01-24T21:45:44 *** mistergold has joined #bitcoin-core-dev
7252019-01-24T21:49:30 *** mistergo1d has quit IRC
7262019-01-24T21:57:47 *** elichai2 has quit IRC
7272019-01-24T22:07:43 *** zivl has joined #bitcoin-core-dev
7282019-01-24T22:09:26 *** bitcoin-git has joined #bitcoin-core-dev
7292019-01-24T22:09:26 <bitcoin-git> [bitcoin] MarcoFalke opened pull request #15246: qa: Add tests for invalid message headers (master...Mf1901-qaMsgHeader) https://github.com/bitcoin/bitcoin/pull/15246
7302019-01-24T22:09:26 *** bitcoin-git has left #bitcoin-core-dev
7312019-01-24T22:09:58 *** ddustin has quit IRC
7322019-01-24T22:10:27 *** ddustin has joined #bitcoin-core-dev
7332019-01-24T22:14:56 *** ddustin has quit IRC
7342019-01-24T22:29:42 *** spinza has quit IRC
7352019-01-24T22:39:57 *** spinza has joined #bitcoin-core-dev
7362019-01-24T22:46:50 *** molz has joined #bitcoin-core-dev
7372019-01-24T22:54:48 *** harrigan has quit IRC
7382019-01-24T22:54:57 *** harrigan has joined #bitcoin-core-dev
7392019-01-24T23:00:23 *** mistergo1d has joined #bitcoin-core-dev
7402019-01-24T23:03:31 *** mistergold has quit IRC
7412019-01-24T23:25:28 *** pinheadmz has quit IRC
7422019-01-24T23:26:14 <meshcollider> sipa: I've been thinking about your comment here: https://github.com/bitcoin/bitcoin/pull/14491#discussion_r247192015
7432019-01-24T23:26:54 <meshcollider> current behaviour is that all pubkeys are added as watchonly if theyre provided in the pubkeys field of importmulti, even if they appear only in subscripts
7442019-01-24T23:27:17 <meshcollider> do we want to keep that behaviuor?
7452019-01-24T23:29:07 <sipa> meshcollider: you can only specify pubkeys for importmulti when they're actually used as pubkey hashes
7462019-01-24T23:29:12 <sipa> right?
7472019-01-24T23:29:21 <sipa> and not for example a pubkey in a multisig
7482019-01-24T23:29:41 <meshcollider> yeah but if you use pubkey hashes in a P2SH script is it intentionally that the pubkey itself becomes watched
7492019-01-24T23:29:51 <sipa> sure
7502019-01-24T23:29:54 <sipa> that's ok
7512019-01-24T23:29:54 <meshcollider> ok
7522019-01-24T23:30:00 <sipa> (and inevitable for now)
7532019-01-24T23:30:11 <sipa> well, it's not ok - but it isn't changing policy
7542019-01-24T23:30:41 <sipa> if you want to watch a P2WPKH you shouldn't need to also watch the corresponding P2PK and P2PKH, but for now that's inevitable
7552019-01-24T23:30:42 <meshcollider> right
7562019-01-24T23:30:54 <sipa> however, if you're able to spend the P2WPKH, you're also able to spend the P2PK/P2PKH
7572019-01-24T23:31:17 <sipa> this is not the case for multisig; if you want to watch the multisig, you shouldn't also watch P2PKH for the keys in it
7582019-01-24T23:34:00 <sipa> does that make sense?
7592019-01-24T23:34:00 *** jb55 has quit IRC
7602019-01-24T23:36:21 <meshcollider> yes
7612019-01-24T23:36:39 <meshcollider> I just wanted to check the current behaviour was correct
7622019-01-24T23:37:26 *** Zenton has quit IRC
7632019-01-24T23:44:29 *** miknotauro has joined #bitcoin-core-dev
7642019-01-24T23:45:06 *** mn9495 has joined #bitcoin-core-dev
7652019-01-24T23:45:46 *** bitcoin-git has joined #bitcoin-core-dev
7662019-01-24T23:45:46 <bitcoin-git> [bitcoin] MarcoFalke opened pull request #15247: qa: Use wallet to retrieve raw transactions (master...Mf1901-qaWalletRaw) https://github.com/bitcoin/bitcoin/pull/15247
7672019-01-24T23:45:46 *** bitcoin-git has left #bitcoin-core-dev
7682019-01-24T23:46:15 *** mn9495 has quit IRC
7692019-01-24T23:47:55 *** mn949588 has joined #bitcoin-core-dev
7702019-01-24T23:56:14 *** mn949588 has quit IRC
7712019-01-24T23:56:31 *** mn949588 has joined #bitcoin-core-dev
7722019-01-24T23:57:15 *** mistergold has joined #bitcoin-core-dev