12020-02-28T00:00:02 *** tvn has quit IRC
22020-02-28T00:08:31 *** TheRec has joined #bitcoin-core-dev
32020-02-28T00:08:31 *** TheRec has joined #bitcoin-core-dev
42020-02-28T00:13:39 *** Chris_Stewart_5 has quit IRC
52020-02-28T00:18:13 *** Guest23538 has left #bitcoin-core-dev
62020-02-28T00:19:20 *** murrayn has joined #bitcoin-core-dev
72020-02-28T00:28:13 *** darkbyte1 has quit IRC
82020-02-28T00:31:47 *** darkbyte1 has joined #bitcoin-core-dev
92020-02-28T00:37:38 *** bitcoin-git has joined #bitcoin-core-dev
102020-02-28T00:37:39 <bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/1615043935ef...fe63d79eabf1
112020-02-28T00:37:39 <bitcoin-git> bitcoin/master 7644567 Dan Gershony: Add missing step in win deployment instructions
122020-02-28T00:37:40 <bitcoin-git> bitcoin/master fe63d79 fanquake: Merge #18212: doc: add missing step in win deployment instructions
132020-02-28T00:37:42 *** bitcoin-git has left #bitcoin-core-dev
142020-02-28T00:37:58 *** bitcoin-git has joined #bitcoin-core-dev
152020-02-28T00:37:58 <bitcoin-git> [bitcoin] fanquake merged pull request #18212: doc: add missing step in win deployment instructions (master...patch-1) https://github.com/bitcoin/bitcoin/pull/18212
162020-02-28T00:37:59 *** bitcoin-git has left #bitcoin-core-dev
172020-02-28T00:54:42 *** paxed1 has joined #bitcoin-core-dev
182020-02-28T01:14:42 *** braydonf has joined #bitcoin-core-dev
192020-02-28T01:20:51 *** lightlike has quit IRC
202020-02-28T01:21:46 *** belcher has quit IRC
212020-02-28T01:31:09 *** dviola has joined #bitcoin-core-dev
222020-02-28T01:40:27 *** promag has quit IRC
232020-02-28T02:01:31 *** AaronvanW has quit IRC
242020-02-28T02:15:43 *** dviola has quit IRC
252020-02-28T02:16:46 *** Highway61 has quit IRC
262020-02-28T02:19:13 *** Dean_Guss has joined #bitcoin-core-dev
272020-02-28T02:40:31 *** AaronvanW has joined #bitcoin-core-dev
282020-02-28T02:46:01 *** AaronvanW has quit IRC
292020-02-28T02:47:08 *** SiAnDoG_ has joined #bitcoin-core-dev
302020-02-28T02:47:26 *** MasterdonX has quit IRC
312020-02-28T02:49:05 *** MasterdonX has joined #bitcoin-core-dev
322020-02-28T03:00:01 *** paxed1 has quit IRC
332020-02-28T03:07:15 *** captjakk has joined #bitcoin-core-dev
342020-02-28T03:20:23 *** Trixar_za has joined #bitcoin-core-dev
352020-02-28T03:26:49 *** hadjiszs has quit IRC
362020-02-28T03:38:10 *** felixfoertsch23 has joined #bitcoin-core-dev
372020-02-28T03:39:24 *** felixfoertsch has quit IRC
382020-02-28T03:53:03 *** Dean_Guss has quit IRC
392020-02-28T04:02:08 *** harrigan_ has quit IRC
402020-02-28T04:03:19 *** harrigan has joined #bitcoin-core-dev
412020-02-28T04:14:11 *** bitcoin-git has joined #bitcoin-core-dev
422020-02-28T04:14:11 <bitcoin-git> [bitcoin] fanquake opened pull request #18218: [0.19] Further 0.19 backports (0.19...futher-0-19-backports) https://github.com/bitcoin/bitcoin/pull/18218
432020-02-28T04:14:12 *** bitcoin-git has left #bitcoin-core-dev
442020-02-28T04:18:22 *** _andrewtoth_ has joined #bitcoin-core-dev
452020-02-28T04:26:48 *** captjakk has quit IRC
462020-02-28T04:32:56 *** bitcoin-git has joined #bitcoin-core-dev
472020-02-28T04:32:56 <bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/fe63d79eabf1...eae48ec84c4d
482020-02-28T04:32:57 <bitcoin-git> bitcoin/master fa45d60 MarcoFalke: test: Reduce unneeded whitelist permissions in tests
492020-02-28T04:32:57 <bitcoin-git> bitcoin/master eae48ec fanquake: Merge #18209: test: Reduce unneeded whitelist permissions in tests
502020-02-28T04:32:59 *** bitcoin-git has left #bitcoin-core-dev
512020-02-28T04:33:16 *** bitcoin-git has joined #bitcoin-core-dev
522020-02-28T04:33:16 <bitcoin-git> [bitcoin] fanquake merged pull request #18209: test: Reduce unneeded whitelist permissions in tests (master...2002-qaLimitWhitelist) https://github.com/bitcoin/bitcoin/pull/18209
532020-02-28T04:33:18 *** bitcoin-git has left #bitcoin-core-dev
542020-02-28T04:43:13 *** AaronvanW has joined #bitcoin-core-dev
552020-02-28T05:15:55 *** AaronvanW has quit IRC
562020-02-28T05:25:04 *** darkbyte1 has quit IRC
572020-02-28T05:30:26 *** ppisati has quit IRC
582020-02-28T05:34:47 *** sdddddd has quit IRC
592020-02-28T05:36:37 *** tryphe has quit IRC
602020-02-28T05:36:58 *** tryphe has joined #bitcoin-core-dev
612020-02-28T05:37:10 *** ppisati has joined #bitcoin-core-dev
622020-02-28T05:48:10 *** sdddddd has joined #bitcoin-core-dev
632020-02-28T06:00:01 *** Trixar_za has quit IRC
642020-02-28T06:01:28 *** bitcoin-git has joined #bitcoin-core-dev
652020-02-28T06:01:28 <bitcoin-git> [bitcoin] corollari opened pull request #18219: doc: Add warning against wallet.dat re-use (master...doc-wallet-copy) https://github.com/bitcoin/bitcoin/pull/18219
662020-02-28T06:01:29 *** bitcoin-git has left #bitcoin-core-dev
672020-02-28T06:22:12 *** jchris has joined #bitcoin-core-dev
682020-02-28T06:35:15 *** goat_ has quit IRC
692020-02-28T06:57:29 *** tryphe_ has joined #bitcoin-core-dev
702020-02-28T06:59:25 *** Highway61 has joined #bitcoin-core-dev
712020-02-28T07:00:43 *** tryphe has quit IRC
722020-02-28T07:12:55 *** AaronvanW has joined #bitcoin-core-dev
732020-02-28T07:17:07 *** TheRec has quit IRC
742020-02-28T07:40:39 *** vasild has joined #bitcoin-core-dev
752020-02-28T07:43:43 *** vasild_ has quit IRC
762020-02-28T07:45:47 *** AaronvanW has quit IRC
772020-02-28T07:53:16 *** marcoagner has joined #bitcoin-core-dev
782020-02-28T08:09:59 *** brianhoffman has quit IRC
792020-02-28T08:10:20 *** brianhoffman has joined #bitcoin-core-dev
802020-02-28T08:10:23 *** tryphe_ has quit IRC
812020-02-28T08:10:32 *** promag has joined #bitcoin-core-dev
822020-02-28T08:10:36 *** Victorsueca has quit IRC
832020-02-28T08:10:42 *** promag_ has joined #bitcoin-core-dev
842020-02-28T08:10:49 *** tryphe_ has joined #bitcoin-core-dev
852020-02-28T08:11:17 *** promag_ has joined #bitcoin-core-dev
862020-02-28T08:11:44 *** Victorsueca has joined #bitcoin-core-dev
872020-02-28T08:12:12 *** darkbyte1 has joined #bitcoin-core-dev
882020-02-28T08:15:08 *** promag has quit IRC
892020-02-28T08:15:52 *** promag_ has quit IRC
902020-02-28T08:22:50 *** sipa has quit IRC
912020-02-28T08:26:24 *** filchef has joined #bitcoin-core-dev
922020-02-28T08:28:07 *** sipa has joined #bitcoin-core-dev
932020-02-28T08:33:00 *** Emcy has quit IRC
942020-02-28T08:43:07 *** promag has joined #bitcoin-core-dev
952020-02-28T08:48:19 *** marcoagner has quit IRC
962020-02-28T08:52:10 *** promag has quit IRC
972020-02-28T08:53:47 *** promag has joined #bitcoin-core-dev
982020-02-28T08:58:07 *** promag has quit IRC
992020-02-28T08:59:54 *** sdjkertuz has quit IRC
1002020-02-28T09:00:01 *** jchris has quit IRC
1012020-02-28T09:10:01 *** kljasdfvv has joined #bitcoin-core-dev
1022020-02-28T09:21:45 *** schmichael1 has joined #bitcoin-core-dev
1032020-02-28T09:23:34 *** TheRec has joined #bitcoin-core-dev
1042020-02-28T09:23:34 *** TheRec has joined #bitcoin-core-dev
1052020-02-28T09:34:27 *** promag has joined #bitcoin-core-dev
1062020-02-28T09:42:50 *** AaronvanW has joined #bitcoin-core-dev
1072020-02-28T09:49:59 *** timothy has joined #bitcoin-core-dev
1082020-02-28T10:01:34 *** SiAnDoG_ has quit IRC
1092020-02-28T10:07:22 *** timothy has quit IRC
1102020-02-28T10:09:36 *** timothy has joined #bitcoin-core-dev
1112020-02-28T10:15:51 *** AaronvanW has quit IRC
1122020-02-28T10:16:06 *** AaronvanW has joined #bitcoin-core-dev
1132020-02-28T10:19:03 *** filchef has quit IRC
1142020-02-28T10:32:04 *** bitcoin-git has joined #bitcoin-core-dev
1152020-02-28T10:32:04 <bitcoin-git> [bitcoin] Sjors opened pull request #18220: psbt: AnalyzePSBT set next to FINALIZER when all inputs need finalizing (master...2020/02/analyze_psbt) https://github.com/bitcoin/bitcoin/pull/18220
1162020-02-28T10:32:15 *** bitcoin-git has left #bitcoin-core-dev
1172020-02-28T11:17:43 *** promag has quit IRC
1182020-02-28T11:24:15 *** promag has joined #bitcoin-core-dev
1192020-02-28T11:26:08 *** promag has quit IRC
1202020-02-28T11:26:35 *** kristapsk_ has quit IRC
1212020-02-28T11:26:55 *** kristapsk_ has joined #bitcoin-core-dev
1222020-02-28T11:27:35 *** promag has joined #bitcoin-core-dev
1232020-02-28T11:28:09 *** _andrewtoth_ has quit IRC
1242020-02-28T11:28:54 *** ghost43 has quit IRC
1252020-02-28T11:29:07 *** _andrewtoth_ has joined #bitcoin-core-dev
1262020-02-28T11:29:13 *** ghost43 has joined #bitcoin-core-dev
1272020-02-28T11:41:15 *** dviola has joined #bitcoin-core-dev
1282020-02-28T11:42:42 *** sdddddd has quit IRC
1292020-02-28T11:57:18 *** Giderey36 has joined #bitcoin-core-dev
1302020-02-28T12:00:02 *** schmichael1 has quit IRC
1312020-02-28T12:03:42 *** sdddddd has joined #bitcoin-core-dev
1322020-02-28T12:07:23 *** Giderey36 has quit IRC
1332020-02-28T12:21:59 *** prae has joined #bitcoin-core-dev
1342020-02-28T12:30:32 *** Livestradamus has quit IRC
1352020-02-28T12:30:55 *** Livestradamus has joined #bitcoin-core-dev
1362020-02-28T12:34:12 *** Giderey36 has joined #bitcoin-core-dev
1372020-02-28T12:34:21 *** manantial has joined #bitcoin-core-dev
1382020-02-28T12:39:50 *** lnostdal has joined #bitcoin-core-dev
1392020-02-28T12:40:58 *** ghost43 has quit IRC
1402020-02-28T12:41:43 *** ghost43 has joined #bitcoin-core-dev
1412020-02-28T12:46:38 *** promag has quit IRC
1422020-02-28T12:46:39 *** Chris_Stewart_5 has joined #bitcoin-core-dev
1432020-02-28T12:50:20 *** AaronvanW has quit IRC
1442020-02-28T13:04:10 *** IGHOR has quit IRC
1452020-02-28T13:05:23 *** IGHOR has joined #bitcoin-core-dev
1462020-02-28T13:13:27 *** goatpig has joined #bitcoin-core-dev
1472020-02-28T13:14:19 *** _andrewtoth_ has quit IRC
1482020-02-28T13:14:19 *** andrewtoth_ has joined #bitcoin-core-dev
1492020-02-28T13:16:24 *** darkbyte1 has quit IRC
1502020-02-28T13:25:00 *** AaronvanW has joined #bitcoin-core-dev
1512020-02-28T13:29:31 *** AaronvanW has quit IRC
1522020-02-28T13:44:20 *** darkbyte1 has joined #bitcoin-core-dev
1532020-02-28T14:00:47 *** bitcoin-git has joined #bitcoin-core-dev
1542020-02-28T14:00:48 <bitcoin-git> [bitcoin] dangershony opened pull request #18223: Add new filer type p2wpkh to blockfilterindex (master...nutrino-p2wpkh-filters) https://github.com/bitcoin/bitcoin/pull/18223
1552020-02-28T14:00:48 *** bitcoin-git has left #bitcoin-core-dev
1562020-02-28T14:02:13 *** AaronvanW has joined #bitcoin-core-dev
1572020-02-28T14:06:32 *** Emcy has joined #bitcoin-core-dev
1582020-02-28T14:14:31 *** Emcy has quit IRC
1592020-02-28T14:16:36 *** promag has joined #bitcoin-core-dev
1602020-02-28T14:34:26 <provoostenator> Random thought: why doesn't Git have SegWit, so you can pre-ACK a rebase? :-)
1612020-02-28T14:34:49 *** AaronvanW has quit IRC
1622020-02-28T14:35:54 *** Guyver2 has joined #bitcoin-core-dev
1632020-02-28T14:50:53 *** Emcy has joined #bitcoin-core-dev
1642020-02-28T14:56:22 *** Emcy has quit IRC
1652020-02-28T15:00:01 *** prae has quit IRC
1662020-02-28T15:01:56 *** mol has quit IRC
1672020-02-28T15:21:16 *** threadlock has joined #bitcoin-core-dev
1682020-02-28T15:33:42 *** as_pnn has joined #bitcoin-core-dev
1692020-02-28T15:38:52 *** jarthur has joined #bitcoin-core-dev
1702020-02-28T15:50:32 *** bitcoin-git has joined #bitcoin-core-dev
1712020-02-28T15:50:33 <bitcoin-git> [bitcoin] MarcoFalke pushed 4 commits to master: https://github.com/bitcoin/bitcoin/compare/eae48ec84c4d...e5753fa4e808
1722020-02-28T15:50:33 <bitcoin-git> bitcoin/master cbd345a Sebastian Falbesoner: test: test OP_CSV empty stack fail in feature_csv_activation.py
1732020-02-28T15:50:34 <bitcoin-git> bitcoin/master 09f706a Sebastian Falbesoner: test: check for OP_CSV empty stack fail reject reason in feature_csv_activ...
1742020-02-28T15:50:35 <bitcoin-git> bitcoin/master 5ffaf88 Sebastian Falbesoner: test: eliminiated magic numbers in feature_csv_activation.py
1752020-02-28T15:50:36 *** bitcoin-git has left #bitcoin-core-dev
1762020-02-28T15:50:57 *** bitcoin-git has joined #bitcoin-core-dev
1772020-02-28T15:50:57 <bitcoin-git> [bitcoin] MarcoFalke merged pull request #17921: test: test OP_CSV empty stack fail in feature_csv_activation.py (master...20200113-test-check-for-empty-stack-op_csv) https://github.com/bitcoin/bitcoin/pull/17921
1782020-02-28T15:50:58 *** bitcoin-git has left #bitcoin-core-dev
1792020-02-28T15:51:54 *** _andrewtoth_ has joined #bitcoin-core-dev
1802020-02-28T15:53:03 *** andrewtoth_ has quit IRC
1812020-02-28T15:55:27 *** rafalcpp has joined #bitcoin-core-dev
1822020-02-28T15:57:05 *** AaronvanW has joined #bitcoin-core-dev
1832020-02-28T15:57:43 *** _andrewtoth_ has quit IRC
1842020-02-28T15:58:40 *** guest534543 has joined #bitcoin-core-dev
1852020-02-28T16:01:04 *** Kiminuo has quit IRC
1862020-02-28T16:07:55 *** goatpig has quit IRC
1872020-02-28T16:08:12 *** emilengler has joined #bitcoin-core-dev
1882020-02-28T16:13:49 *** promag has quit IRC
1892020-02-28T16:14:15 *** emilengler has joined #bitcoin-core-dev
1902020-02-28T16:15:14 *** promag has joined #bitcoin-core-dev
1912020-02-28T16:28:21 *** bitcoin-git has joined #bitcoin-core-dev
1922020-02-28T16:28:21 <bitcoin-git> [bitcoin] instagibbs opened pull request #18224: Make AnalyzePSBT next role calculation simple, correct (master...analyze_psbt_role_simple) https://github.com/bitcoin/bitcoin/pull/18224
1932020-02-28T16:28:26 *** bitcoin-git has left #bitcoin-core-dev
1942020-02-28T16:30:47 *** AaronvanW has quit IRC
1952020-02-28T16:32:59 *** bitcoin-git has joined #bitcoin-core-dev
1962020-02-28T16:32:59 <bitcoin-git> [bitcoin] Sjors closed pull request #18220: psbt: AnalyzePSBT set next to"finalizer" when all inputs need finalizing (master...2020/02/analyze_psbt) https://github.com/bitcoin/bitcoin/pull/18220
1972020-02-28T16:33:00 *** bitcoin-git has left #bitcoin-core-dev
1982020-02-28T16:36:08 *** Talkless has joined #bitcoin-core-dev
1992020-02-28T16:37:25 *** promag has quit IRC
2002020-02-28T16:39:45 *** goatpig has joined #bitcoin-core-dev
2012020-02-28T16:40:11 *** ghost43 has quit IRC
2022020-02-28T16:40:25 *** goatpig has joined #bitcoin-core-dev
2032020-02-28T16:41:00 *** goatpig has joined #bitcoin-core-dev
2042020-02-28T16:41:03 *** ghost43 has joined #bitcoin-core-dev
2052020-02-28T16:44:13 *** promag has joined #bitcoin-core-dev
2062020-02-28T16:45:07 *** goatpig has quit IRC
2072020-02-28T16:45:26 *** goatpig has joined #bitcoin-core-dev
2082020-02-28T16:49:54 *** goatpig_ has joined #bitcoin-core-dev
2092020-02-28T16:50:23 *** goatpig has quit IRC
2102020-02-28T17:06:28 *** _andrewtoth_ has joined #bitcoin-core-dev
2112020-02-28T17:18:34 *** Talkless has quit IRC
2122020-02-28T17:21:20 *** _andrewtoth_ has quit IRC
2132020-02-28T17:21:44 *** _andrewtoth_ has joined #bitcoin-core-dev
2142020-02-28T17:23:14 *** promag has quit IRC
2152020-02-28T17:24:43 *** kljasdfvv has quit IRC
2162020-02-28T17:26:57 *** pinheadmz has quit IRC
2172020-02-28T17:27:01 *** SiAnDoG_ has joined #bitcoin-core-dev
2182020-02-28T17:29:58 *** bitcoin-git has joined #bitcoin-core-dev
2192020-02-28T17:29:58 <bitcoin-git> [bitcoin] MarcoFalke opened pull request #18225: util: Fail to parse empty string in ParseMoney (master...2002-utilMoney) https://github.com/bitcoin/bitcoin/pull/18225
2202020-02-28T17:29:59 *** bitcoin-git has left #bitcoin-core-dev
2212020-02-28T17:31:28 *** bitcoin-git has joined #bitcoin-core-dev
2222020-02-28T17:31:28 <bitcoin-git> [bitcoin] instagibbs closed pull request #18214: wallet: Give slightly more understandable advice when needing -fallbackfee (master...fallback_msg) https://github.com/bitcoin/bitcoin/pull/18214
2232020-02-28T17:31:29 *** bitcoin-git has left #bitcoin-core-dev
2242020-02-28T17:32:29 *** ghost43 has quit IRC
2252020-02-28T17:33:45 *** ghost43 has joined #bitcoin-core-dev
2262020-02-28T17:40:42 *** promag has joined #bitcoin-core-dev
2272020-02-28T17:40:53 *** bitcoin-git has joined #bitcoin-core-dev
2282020-02-28T17:40:53 <bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/e5753fa4e808...73cfa070e5e4
2292020-02-28T17:40:53 <bitcoin-git> bitcoin/master c72a11a Yancy Ribbens: test: Add cost_of_change parameter assertions to bnb_search_test
2302020-02-28T17:40:54 <bitcoin-git> bitcoin/master 73cfa07 MarcoFalke: Merge #18195: test: Add cost_of_change parameter assertions to bnb_search_...
2312020-02-28T17:40:55 *** bitcoin-git has left #bitcoin-core-dev
2322020-02-28T17:41:13 *** bitcoin-git has joined #bitcoin-core-dev
2332020-02-28T17:41:13 <bitcoin-git> [bitcoin] MarcoFalke merged pull request #18195: test: Add cost_of_change parameter assertions to bnb_search_test (master...add-coinselection-cost-of-change-test-cases) https://github.com/bitcoin/bitcoin/pull/18195
2342020-02-28T17:41:14 *** bitcoin-git has left #bitcoin-core-dev
2352020-02-28T17:44:46 *** promag has quit IRC
2362020-02-28T18:00:01 *** threadlock has quit IRC
2372020-02-28T18:01:29 *** roconnor has joined #bitcoin-core-dev
2382020-02-28T18:02:58 *** sdaftuar has quit IRC
2392020-02-28T18:03:23 *** sdaftuar has joined #bitcoin-core-dev
2402020-02-28T18:05:23 *** kristapsk_ is now known as kristapsk
2412020-02-28T18:09:24 *** bitcoin-git has joined #bitcoin-core-dev
2422020-02-28T18:09:25 <bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/73cfa070e5e4...5ad80bec3f31
2432020-02-28T18:09:25 <bitcoin-git> bitcoin/master 3d9b41e fanquake: build: add --enable-determinism configure flag
2442020-02-28T18:09:26 <bitcoin-git> bitcoin/master 5ad80be Wladimir J. van der Laan: Merge #18135: build: add --enable-determinism configure flag
2452020-02-28T18:09:28 *** bitcoin-git has left #bitcoin-core-dev
2462020-02-28T18:09:43 *** bitcoin-git has joined #bitcoin-core-dev
2472020-02-28T18:09:43 <bitcoin-git> [bitcoin] laanwj merged pull request #18135: build: add --enable-determinism configure flag (master...no_insert_timestamp_ld) https://github.com/bitcoin/bitcoin/pull/18135
2482020-02-28T18:09:45 *** bitcoin-git has left #bitcoin-core-dev
2492020-02-28T18:11:04 *** bitcoin-git has joined #bitcoin-core-dev
2502020-02-28T18:11:04 <bitcoin-git> [bitcoin] jkczyz closed pull request #17557: util: Refactor message hashing into a utility function (master...2019-11-hash-message) https://github.com/bitcoin/bitcoin/pull/17557
2512020-02-28T18:11:06 *** bitcoin-git has left #bitcoin-core-dev
2522020-02-28T18:13:29 *** mrostecki has quit IRC
2532020-02-28T18:13:37 *** captjakk has joined #bitcoin-core-dev
2542020-02-28T18:14:01 *** icota[m] has quit IRC
2552020-02-28T18:15:38 *** AaronvanW has joined #bitcoin-core-dev
2562020-02-28T18:22:00 *** pabelanger1 has joined #bitcoin-core-dev
2572020-02-28T18:29:16 *** Chris_Stewart_5 has quit IRC
2582020-02-28T18:30:44 *** Chris_Stewart_5 has joined #bitcoin-core-dev
2592020-02-28T18:31:01 *** rafalcpp has quit IRC
2602020-02-28T18:31:44 *** fox2p has joined #bitcoin-core-dev
2612020-02-28T18:33:35 *** icota[m] has joined #bitcoin-core-dev
2622020-02-28T18:34:12 *** mrostecki has joined #bitcoin-core-dev
2632020-02-28T18:44:02 *** timothy has quit IRC
2642020-02-28T19:00:28 <achow101> wallet meeting?
2652020-02-28T19:00:28 <meshcollider> Wallet meeting time, does anyone have topics?
2662020-02-28T19:00:40 <meshcollider> #startmeeting
2672020-02-28T19:00:40 <lightningbot> Meeting started Fri Feb 28 19:00:40 2020 UTC. The chair is meshcollider. Information about MeetBot at http://wiki.debian.org/MeetBot.
2682020-02-28T19:00:40 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
2692020-02-28T19:00:46 <meshcollider> #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 jnewbery maaku fanquake promag provoostenator aj Chris_Stewart_5 dongcarl gwillen jamesob ken281221 ryanofsky gleb moneyball ariard digi_james amiti fjahr
2702020-02-28T19:00:47 <meshcollider> jeremyrubin emilengler jonatack hebasto jb55
2712020-02-28T19:00:51 <kanzure> hi
2722020-02-28T19:00:54 <achow101> hi
2732020-02-28T19:00:56 <provoostenator> hi
2742020-02-28T19:01:08 <jonatack> hi
2752020-02-28T19:01:37 <meshcollider> We have quite a few PRs very close to merge, so I'll go through them today
2762020-02-28T19:01:49 <meshcollider> Topics?
2772020-02-28T19:02:46 <achow101> descriptor normalization? (not really wallet though)
2782020-02-28T19:02:50 <provoostenator> topic suggestion multisig wallet creation
2792020-02-28T19:04:13 <achow101> multisig wallet creation?
2802020-02-28T19:05:23 <provoostenator> #18142
2812020-02-28T19:05:24 <gribble> https://github.com/bitcoin/bitcoin/issues/18142 | Coordinate multi-sig wallet · Issue #18142 · bitcoin/bitcoin · GitHub
2822020-02-28T19:06:01 <provoostenator> I'm trying to come up with a (file) format that can be used to setup a multisig wallet.
2832020-02-28T19:06:19 <provoostenator> So far I was able to implement something in JSON.
2842020-02-28T19:06:35 <provoostenator> I plan to write a script that can convert HWI output to that format...
2852020-02-28T19:06:39 <achow101> I feel like this is achievable using miniscript policies
2862020-02-28T19:06:50 <achow101> the only issue being determining the threshold
2872020-02-28T19:06:53 <provoostenator> Yes, that's what it uses
2882020-02-28T19:07:09 <provoostenator> There is a global policy, thresh_m
2892020-02-28T19:07:14 <provoostenator> And then each signer gives a sub policy
2902020-02-28T19:07:25 <provoostenator> Which are then combined into a wallet policy
2912020-02-28T19:07:55 <provoostenator> In my example it's the most trivial policy possible, because in practice most walelts can only do a regular multisig of pubkeys
2922020-02-28T19:08:43 <provoostenator> But the format allows for as complex a (sub)policy as you want, if wallets understand it.
2932020-02-28T19:09:03 <achow101> it would be preferable to be able to compose, and recursively compose, arbitrary miniscript policies
2942020-02-28T19:09:26 <meshcollider> Isn't that what hes saying
2952020-02-28T19:09:37 <provoostenator> Yes, minus the recursive bit
2962020-02-28T19:09:54 <meshcollider> When would recursive composition be useful
2972020-02-28T19:09:55 <sipa> miniscript policies can be composed, but the resulting (optimal) scripts aren't a composition of the constituent policies
2982020-02-28T19:10:19 <sipa> provoostenator: what fo you need beyond miniscript policies in your format?
2992020-02-28T19:10:31 <provoostenator> Correct, but for dumb wallets I'm thinking of a policy "compiler" that is extremely dumb
3002020-02-28T19:10:47 <provoostenator> So that the end result can only be check_multisig
3012020-02-28T19:11:08 <achow101> meshcollider: I was thinking something like participant_1 is really a multisig of participant_4 and 5
3022020-02-28T19:11:18 <achow101> but that sub policy hasn't been constructed yet
3032020-02-28T19:11:23 <provoostenator> Here's tesnet example: https://gist.github.com/Sjors/c7342cb27a7cf5f2d35469bb06eae4f4
3042020-02-28T19:12:53 <achow101> what's not clear to me is why we need a file format?
3052020-02-28T19:13:10 <provoostenator> Well, so far it's just a JSON format, doesn't ahve to be a file
3062020-02-28T19:13:10 <achow101> can't you just pass around a miniscript policy, maybe with placeholders, and let people add things to it?
3072020-02-28T19:13:16 <provoostenator> But it's something you can pass around
3082020-02-28T19:13:28 <provoostenator> It contains sub policies for each signer
3092020-02-28T19:13:30 <provoostenator> And keys
3102020-02-28T19:13:49 <provoostenator> And optionally a friendly name and info about capabilities
3112020-02-28T19:14:04 <provoostenator> One of the participants can collect that info and combine it.
3122020-02-28T19:14:24 <provoostenator> And then figure out the overall policy, miniscript and descriptor. And then send that back to the participants
3132020-02-28T19:15:14 <provoostenator> It would be nice if miniscript supported actual placeholders though
3142020-02-28T19:15:34 <achow101> I guess what I'm asking is why can't you just pass around a single miniscript policy string that people modify
3152020-02-28T19:15:36 <provoostenator> Then you can announce the overal policy _before_ collecting info from indiviual signers.
3162020-02-28T19:16:09 <provoostenator> Oh I see, that's possible too, but it requires that participants actually can parse miniscript, which I'm not assuming
3172020-02-28T19:16:21 *** jb55 has quit IRC
3182020-02-28T19:16:45 <provoostenator> Simple string concatenation is enough to handle the format I have so far.
3192020-02-28T19:16:46 <instagibbs> oh hi
3202020-02-28T19:16:55 *** jb55 has joined #bitcoin-core-dev
3212020-02-28T19:17:01 <meshcollider> Is the assumption that all the participants are completely trustworh
3222020-02-28T19:17:08 <meshcollider> Trustworthy*
3232020-02-28T19:17:10 <achow101> but participants have to be able parse miniscript at the end anyways, no?
3242020-02-28T19:17:24 <provoostenator> meshcollider: there's room for arbirary fields, so they don't have to be
3252020-02-28T19:17:44 <achow101> you have to trust participants to not mess with other participant's policies
3262020-02-28T19:17:59 <provoostenator> There's also room for e.g. musig related info, not something that would fit in a miniscript policy that you pass around
3272020-02-28T19:18:17 <meshcollider> achow101: idk if that's an assumption we want to make?
3282020-02-28T19:18:44 <instagibbs> meshcollider, sure seems like something an attacker might do
3292020-02-28T19:19:04 <achow101> meshcollider: well at the end, you can verify whether you are still in the policy
3302020-02-28T19:19:22 <achow101> and under what conditions your sub policy would be reached
3312020-02-28T19:19:27 <achow101> that's the point of miniscript
3322020-02-28T19:19:47 <sipa> provoostenator: the participants need to be able to reason about the policy of the final descriptor that comes out
3332020-02-28T19:19:55 <sipa> miniscript enables that
3342020-02-28T19:19:58 <provoostenator> You probably have to check the first receive address via some other channel to make sure everyone is looking at the same policy
3352020-02-28T19:20:16 <sipa> without generic script.reasoning logic like that i don't think what you're trying is secure
3362020-02-28T19:20:19 <provoostenator> Miniscript enables it in the general case.
3372020-02-28T19:20:23 <achow101> provoostenator: but for musig, and taproot in general, I would expect there to be different miniscript things for that
3382020-02-28T19:20:30 <provoostenator> But in the simple case you can still reason about thresh(2,pk(3442193e),pk(bd16bee5))
3392020-02-28T19:20:41 <instagibbs> I think spelling out exactly what you're enabling and protecting against would help for your PoC
3402020-02-28T19:20:41 <sipa> sure
3412020-02-28T19:20:52 <provoostenator> I'm trying to make it useful pre-miniscript, but in a forward compatible format.
3422020-02-28T19:21:23 <sipa> i suspect getting people to adopt a file format will be harder and slower than integration of miniscript :)
3432020-02-28T19:21:35 <provoostenator> instagibbs: personally I'm happy if it can do m-of-n with devices that I initially trust
3442020-02-28T19:21:46 <sipa> especially when its usefulness is extremely likited before that poijt in time
3452020-02-28T19:21:46 <instagibbs> provoostenator, ok, that we can reason about with nothing too fancy :)
3462020-02-28T19:21:59 <instagibbs> miniscript really does need network effects to be worth it
3472020-02-28T19:22:03 <provoostenator> Yes, the ad hoc format used by ColdCard does the trick
3482020-02-28T19:23:11 <instagibbs> meanwhile I think pressuring hww devs to support things like display xpub, register some sorta descriptor like thing, is the best thing to do
3492020-02-28T19:23:27 *** Chris_Stewart_5 has quit IRC
3502020-02-28T19:23:42 <meshcollider> True
3512020-02-28T19:23:42 <instagibbs> gets you usable n-of-m at least
3522020-02-28T19:23:43 <provoostenator> So ColdCard registers xpubs, I don't think any other hww does anything similar
3532020-02-28T19:23:58 <instagibbs> provoostenator, indeed, btchip says it's on the roadmap(no convincing needed at least)
3542020-02-28T19:24:08 <achow101> I would prefer people to just use miniscript and then compose policies within a miniscript policy itself, rather than a file format
3552020-02-28T19:24:25 <provoostenator> This may be a chicken-egg thing where people want a standard first, but a standard is hard to develop without practical experience.
3562020-02-28T19:24:51 <provoostenator> achow101: first thing we'd need for that is xpub & origin support in descriptors
3572020-02-28T19:25:29 <provoostenator> And ideally placeholder support, so a signer knows where they can insert stuff
3582020-02-28T19:25:33 <sipa> it's already there?
3592020-02-28T19:25:44 <achow101> in miniscript you mean?
3602020-02-28T19:25:44 <sipa> (xpub and origin support)
3612020-02-28T19:25:51 <provoostenator> sipa on your site I could only add pk(fingerprint)
3622020-02-28T19:25:53 *** belcher has joined #bitcoin-core-dev
3632020-02-28T19:26:00 <provoostenator> Or you mean your PR?
3642020-02-28T19:26:01 *** bitcoin-git has joined #bitcoin-core-dev
3652020-02-28T19:26:01 <bitcoin-git> [bitcoin] Empact opened pull request #18226: refactor: Consolidate unnecessary base58 interfaces (master...2020-02-base58) https://github.com/bitcoin/bitcoin/pull/18226
3662020-02-28T19:26:12 *** bitcoin-git has left #bitcoin-core-dev
3672020-02-28T19:26:40 <achow101> I expect that the existing xpub, origin, and general KEY expression stuff in descriptors will be in miniscript
3682020-02-28T19:26:42 <sipa> provoostenator: ah you mean in miniscript
3692020-02-28T19:26:53 <provoostenator> yes
3702020-02-28T19:26:57 <sipa> the compiler just passes through whatever key expressions you use
3712020-02-28T19:27:07 <sipa> into the descriptor outout
3722020-02-28T19:27:12 <provoostenator> So e.g. wallet 1 starts and wants to invite 1 more wallet
3732020-02-28T19:27:13 <sipa> it trats them as strings
3742020-02-28T19:27:28 *** Emcy has joined #bitcoin-core-dev
3752020-02-28T19:27:54 <provoostenator> Wallet 1 announces thresh_m(2, c_pk(xpub...),FREE_SPOT_FOR_YOU)
3762020-02-28T19:28:09 <provoostenator> And then wallet 2 fills in that spot,
3772020-02-28T19:29:08 <sipa> the hard part is letting wallets verify that the resulting script/descriptor includes the policy they want
3782020-02-28T19:29:24 <sipa> which isn't implemented in my c++ miniscript code
3792020-02-28T19:29:31 <sipa> rust-miniscript may
3802020-02-28T19:29:52 <achow101> sipa: I believe rust-miniscript lets you "pull up" a miniscript to the policy
3812020-02-28T19:29:55 <instagibbs> "they want" seems like another patch of thorns
3822020-02-28T19:30:19 <achow101> andytoshi also said it was trivial to do so
3832020-02-28T19:31:36 *** ghost43 has quit IRC
3842020-02-28T19:32:43 <sipa> yeah, it is
3852020-02-28T19:32:59 *** ghost43 has joined #bitcoin-core-dev
3862020-02-28T19:33:05 <instagibbs> not sure what "pull up" means exactly but I'll defer that to me actually learning miniscript
3872020-02-28T19:33:22 <sipa> instagibbs: compiler goes from policy to miniscript
3882020-02-28T19:33:40 <sipa> "pull up" means going the other direction
3892020-02-28T19:33:47 <sipa> that step is easy
3902020-02-28T19:33:54 <achow101> "decompile miniscript"
3912020-02-28T19:33:55 <sipa> but then reasoning about the policy may not be
3922020-02-28T19:34:08 <instagibbs> i see, you mean someone brings compiled miniscript, you can graft it in, sure
3932020-02-28T19:34:15 <sipa> no
3942020-02-28T19:34:35 <instagibbs> ohhh sorry misreading
3952020-02-28T19:34:45 <instagibbs> way over-reading what achow said, ignore
3962020-02-28T19:34:49 <sipa> it's just about: someome gives you a script, figure out what it "does", semantically
3972020-02-28T19:35:01 <instagibbs> yes
3982020-02-28T19:36:16 <sipa> like... someone "included" your policy in a compiled script
3992020-02-28T19:36:20 <meshcollider> Because you don't only want to check your spending condition, you really need to check no other paths have been added that shouldn't be there
4002020-02-28T19:36:27 <sipa> maybe they combined it with an and(X,false)
4012020-02-28T19:36:56 <sipa> meshcollider: indeed
4022020-02-28T19:37:19 <instagibbs> "should be" lots of worms in cans ;P
4032020-02-28T19:37:43 <instagibbs> n-of-m is good or bad depending on who is in the set
4042020-02-28T19:37:43 <sipa> or did they compile it into a ridiculously inefficient script?
4052020-02-28T19:39:44 <sipa> i think what may be generically possible is where you have a super-policy super(A,B,C) that is agreed upon out of band (e.g. 2-of-3 multisig)
4062020-02-28T19:39:56 <sipa> and then let participants fill in their own A, B C
4072020-02-28T19:40:20 <sipa> the composability of policies means that you generally shouldn't care about what others' A B and C are
4082020-02-28T19:40:30 <meshcollider> Isn't that what provoostenator did anyway
4092020-02-28T19:40:38 <meshcollider> Well, limiting super = thresh
4102020-02-28T19:40:39 *** vasild_ has joined #bitcoin-core-dev
4112020-02-28T19:41:16 <instagibbs> Provided you're talking to the right folks gathering A,B,C, I think so :)
4122020-02-28T19:41:37 <sipa> the hard part in this case is where does the super-policy come from
4132020-02-28T19:41:44 <provoostenator> meshcollider: not limiting the policy, but even limiting the compiler
4142020-02-28T19:42:14 <provoostenator> *not only
4152020-02-28T19:44:23 *** vasild has quit IRC
4162020-02-28T19:46:01 *** dviola has quit IRC
4172020-02-28T19:47:54 <meshcollider> Alright achow101 do you want to talk about descriptor normalisation now
4182020-02-28T19:48:15 <achow101> sure
4192020-02-28T19:48:25 <meshcollider> I think the multiwallet needs more thought out of meeting
4202020-02-28T19:48:34 <meshcollider> Multisig wallet*
4212020-02-28T19:48:50 <instagibbs> (topic for coredev)
4222020-02-28T19:48:50 <achow101> we can add it to kanzure's list of discussion topics
4232020-02-28T19:49:06 <kanzure> okay
4242020-02-28T19:49:16 <achow101> I kind of tried to do this descriptor xpub normalization in #18163
4252020-02-28T19:49:18 <gribble> https://github.com/bitcoin/bitcoin/issues/18163 | descriptors: Use xpub at last hardened step if possible by achow101 · Pull Request #18163 · bitcoin/bitcoin · GitHub
4262020-02-28T19:49:53 <achow101> closed it in favor of the xpub cache, but I think it might still be useful to do
4272020-02-28T19:50:46 <achow101> basically if we get a descriptor with a xprv and a bunch of hardened steps, then we can make an equivalent descriptor which has the xpub at the last hardened step and the hardened steps and that xprv become the origin info
4282020-02-28T19:52:06 <achow101> we lose the ability to round trip such descriptors, but I think it's still useful to be able to do this for things like exports
4292020-02-28T19:52:10 <provoostenator> That seemed sane to me
4302020-02-28T19:53:10 <achow101> we can also go a step further and do it to all descriptors with xpubs, just derive as far as possible
4312020-02-28T19:53:34 <achow101> it's all the same at the end, just might be confusing to users
4322020-02-28T19:53:51 <meshcollider> Derive even the non-hardened steps and just have the /* at the end?
4332020-02-28T19:54:15 <achow101> yeah
4342020-02-28T19:54:34 <provoostenator> I find hardened a more intuitive place to cut off
4352020-02-28T19:54:51 <provoostenator> It also keeps the xpub in the expected place for BIP44/49/84 style descriptors
4362020-02-28T19:54:57 <meshcollider> Yeah I don't think there's any point to doing work that anyone else could do anyway
4372020-02-28T19:55:15 <achow101> it has the effect of making the xpub cache part of the descriptor
4382020-02-28T19:55:28 <achow101> since in xpub cache, we derive as far as possible and cache that xpub
4392020-02-28T19:55:49 <provoostenator> I think that cache policy should just be internal
4402020-02-28T19:56:27 <meshcollider> Yep I can see maybe why xpriv/hardened -> xpub is useful but not other than that
4412020-02-28T19:56:48 <achow101> less derivations to do
4422020-02-28T19:57:45 <provoostenator> That seems like a tiny benefit compared to loading a wallet and expanding 1000 keys
4432020-02-28T20:00:17 <achow101> so with just the hardened derivation, that's something people think we should still try?
4442020-02-28T20:00:44 <achow101> I think the main concern is that we lose information
4452020-02-28T20:01:16 <sipa> it's only human-relevant information
4462020-02-28T20:01:30 <sipa> as the semantics of the normalized descriptor are the same as the original
4472020-02-28T20:02:23 <achow101> right, but if getdescriptorinfo returned a normalized descriptor, that would probably confuse people
4482020-02-28T20:02:24 <sipa> but i'm still hesitant to just always do it
4492020-02-28T20:02:29 <sipa> agree
4502020-02-28T20:02:43 <sipa> it seems unnecessary, except perhaps in certain opt-in cases
4512020-02-28T20:03:27 <achow101> the main use is imports into our wallet, and exporting watch only to other wallets
4522020-02-28T20:03:59 <sipa> but you could do it at export time?
4532020-02-28T20:04:34 <achow101> it would require access to private keys
4542020-02-28T20:04:39 <achow101> it'd be nice if it didn't
4552020-02-28T20:04:47 <sipa> or to the xpub cache?
4562020-02-28T20:05:11 <achow101> with the xpub cache, it would give the xpub at the end of derivation
4572020-02-28T20:05:26 <sipa> which is just as good, no?
4582020-02-28T20:05:34 <achow101> still confusing to users
4592020-02-28T20:05:46 <sipa> not more so than an xpub in the middle?
4602020-02-28T20:05:55 <achow101> and possibly to wallets that may try to interpret the derivation info to figure out change/not-change
4612020-02-28T20:06:09 <provoostenator> Especially the latter
4622020-02-28T20:06:13 <sipa> the origin info would still be there
4632020-02-28T20:06:14 <achow101> (I suspect that would be something that wallets try to do)
4642020-02-28T20:06:18 <sipa> which would have that information
4652020-02-28T20:06:44 <provoostenator> E.g. with a ColdCard you register an xpub, which covers receive and change
4662020-02-28T20:06:58 <provoostenator> So it would be confused by a desciptor that has the xpub 1 level down
4672020-02-28T20:07:15 <provoostenator> Then again, you can't really export a single descriptor anyway
4682020-02-28T20:07:41 <achow101> I suppose we can bring this up again once we get to allowing descriptor exports
4692020-02-28T20:07:46 <sipa> yeah
4702020-02-28T20:08:16 <provoostenator> I wouldn't mind being able to describe receive and change  in single descriptor, but that's another can of worms.
4712020-02-28T20:08:26 <sipa> yes :)
4722020-02-28T20:08:32 <achow101> xpub cache covers what we need to do now, so we can think on this later :)
4732020-02-28T20:08:39 *** bitcoin-git has joined #bitcoin-core-dev
4742020-02-28T20:08:39 <bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/5ad80bec3f31...9aa8145bc024
4752020-02-28T20:08:40 <bitcoin-git> bitcoin/master 54be4e7 Sebastian Falbesoner: test: check specific reject reasons in feature_csv_activation.py
4762020-02-28T20:08:41 <bitcoin-git> bitcoin/master 9aa8145 MarcoFalke: Merge #17959: test: check specific reject reasons in feature_csv_activatio...
4772020-02-28T20:08:42 *** bitcoin-git has left #bitcoin-core-dev
4782020-02-28T20:09:00 <instagibbs> oh we're 8 minutes over
4792020-02-28T20:09:03 *** bitcoin-git has joined #bitcoin-core-dev
4802020-02-28T20:09:03 <bitcoin-git> [bitcoin] MarcoFalke merged pull request #17959: test: check specific reject reasons in feature_csv_activation.py (master...20200118-test-check-reject-reasons-in-feature-csv-activation) https://github.com/bitcoin/bitcoin/pull/17959
4812020-02-28T20:09:04 *** bitcoin-git has left #bitcoin-core-dev
4822020-02-28T20:10:30 <achow101> any other topics?
4832020-02-28T20:10:57 <instagibbs> PSBT GUI review: do it
4842020-02-28T20:11:12 <gwillen> apropos of that actually instagibbs, I saw you commented about showing change addresses
4852020-02-28T20:11:28 <gwillen> I am pretty fuzzy on the story of "safely detecting change addresses" in this setting
4862020-02-28T20:11:48 <achow101> Change detection is always fuzzy
4872020-02-28T20:11:50 <provoostenator> On the send dialog you can know which one is change
4882020-02-28T20:11:59 <provoostenator> On the load PSBT I wouldn't bother for now.
4892020-02-28T20:12:01 <instagibbs> in normal sends it ellides those outputs... but PSBT signing is not the typical case, in many cases
4902020-02-28T20:12:10 <instagibbs> provoostenator, right
4912020-02-28T20:12:11 <gwillen> yeah, my assumption was not to bother for signing, and to show all addresses
4922020-02-28T20:12:37 <provoostenator> It's probably some property on rcp that you can look at, the normal confirm dialog knows.
4932020-02-28T20:13:03 <sipa> you can show the net balance effect a transaction has on your wallet, independent of knowing what is change or not, right?
4942020-02-28T20:13:14 <gwillen> not when signing, no wallet
4952020-02-28T20:13:24 <achow101> no wallet?
4962020-02-28T20:13:28 <sipa> ah, without wallet you can't even talk about the concept of change
4972020-02-28T20:13:33 <instagibbs> it might be a dumb key store
4982020-02-28T20:13:35 <instagibbs> achow101,
4992020-02-28T20:13:37 <gwillen> well, hm, I guess I am assuming that in general, when signing offline, you are just a dumb key store, yeah
5002020-02-28T20:13:57 <gwillen> you may not have the blockchain, and you may only have keys to some subpart of whatever inputs you're signing for
5012020-02-28T20:14:09 <sipa> gwillen: well a sane key store (one that can verify what it's signing) must have a pre-registered descriptor set
5022020-02-28T20:14:11 <achow101> For change detection, you should be able to just ask the wallet if a particular destination IsChange and do your change detection like that
5032020-02-28T20:14:22 <achow101> but that assumes the PSBT belongs to that wallet
5042020-02-28T20:14:24 <sipa> gwillen: if you don't have that, talking about balance or change is meaningless
5052020-02-28T20:14:27 <gwillen> sipa: do we have a sane key store, though, in the sense
5062020-02-28T20:14:35 <achow101> gwillen: we will soon(tm)
5072020-02-28T20:14:47 <sipa> gwillen: well, our wallet is
5082020-02-28T20:14:58 <gwillen> in particular, the case I am most interested in is signing for a multisig
5092020-02-28T20:15:01 <provoostenator> Right, fun fact about the current keystore: getrawchange address wil give you an address from the receive chain
5102020-02-28T20:15:20 <gwillen> in which case there is a lot more information needed before one could safely conclude that some output is "change"
5112020-02-28T20:15:27 <sipa> my point is just that if you want to do signing without such knowledge (which is a totally reasonable thing to do in some cases), you must accept that that means there is no such thing as change detection and shouldn't bother
5122020-02-28T20:15:32 <gwillen> *nods*
5132020-02-28T20:15:36 *** Giderey36 has quit IRC
5142020-02-28T20:15:41 <instagibbs> gwillen, well, is today's wallet IsChange would fail for any multisig address
5152020-02-28T20:15:44 <gwillen> anyway instagibbs this was apropos of your comment asking why we display the change
5162020-02-28T20:15:50 <instagibbs> if its a descriptor wallet change-ness is stored
5172020-02-28T20:15:58 <instagibbs> anyways, it's fine for now
5182020-02-28T20:16:05 * sipa -> lunch
5192020-02-28T20:16:05 <gwillen> the answer is that I'm assuming in almost any interesting case we can't tell
5202020-02-28T20:16:17 <gwillen> and so there's no point in special-casing the boring cases where we can
5212020-02-28T20:16:20 <instagibbs> gwillen, disagree I think?
5222020-02-28T20:16:30 <achow101> gwillen: I don't think that's an assumption in descriptor wallets
5232020-02-28T20:16:43 <achow101> since in descriptor wallets you import the descriptor and mark it as change or not
5242020-02-28T20:16:44 <gwillen> well we don't have those yet, so
5252020-02-28T20:16:51 <gwillen> when we have those I will revisit :-)
5262020-02-28T20:17:06 <sipa> i don't see what descriptor wallets have to do with this, actually
5272020-02-28T20:17:18 <sipa> either you have a wallet, and you can ask what it would consider change
5282020-02-28T20:17:23 <sipa> or you don't
5292020-02-28T20:17:31 <achow101> you can do the same change detection stuff now as you would in the future, it's exposed in the same way
5302020-02-28T20:17:43 <achow101> we just won't detect multisig or funny script things as change
5312020-02-28T20:17:52 <instagibbs> `IsChange()` works for random imports already AFAIK, you just can't put in keypool
5322020-02-28T20:17:56 <meshcollider> Anyway I think let's end the official meeting
5332020-02-28T20:17:59 <meshcollider> #endmeeting
5342020-02-28T20:17:59 <lightningbot> Meeting ended Fri Feb 28 20:17:59 2020 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
5352020-02-28T20:17:59 <lightningbot> Minutes: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2020/bitcoin-core-dev.2020-02-28-19.00.html
5362020-02-28T20:17:59 <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2020/bitcoin-core-dev.2020-02-28-19.00.txt
5372020-02-28T20:17:59 <lightningbot> Log: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2020/bitcoin-core-dev.2020-02-28-19.00.log.html
5382020-02-28T20:18:26 <instagibbs> i.e., importmulti, mark it as internal address, now it'll be marked as `IsChange` internally
5392020-02-28T20:18:42 <gwillen> hmmmm, so if I have a Core wallet that I use offline, with a watchonly copy that I use online, with PSBT, change detection should actually Just Work
5402020-02-28T20:18:53 <gwillen> well hm, though, with a normal Core wallet you do not have public derivation
5412020-02-28T20:18:56 <instagibbs> obviously if you're thinking of a HD chain multisig it probably needs descriptor wallets to be ez
5422020-02-28T20:18:57 <gwillen> so you can't meaningfully do this
5432020-02-28T20:19:06 <instagibbs> right this only works with one-off keys
5442020-02-28T20:19:08 <gwillen> I'm trying to think of a scenario where you can meaningfully do this
5452020-02-28T20:19:17 <gwillen> and have it work without shenanigans
5462020-02-28T20:19:33 <gwillen> well with one-off keys there is no such thing as change, unless you're reusing addresses
5472020-02-28T20:20:05 <gwillen> unless you mean like, one-off exporting your keypool watchonly, and then doing it again manually each time you run out
5482020-02-28T20:20:07 <achow101> gwillen: what I'm saying is that you should use IsChange and we will later refine what IsChange returns true for
5492020-02-28T20:20:07 <instagibbs> yes there is, when manually creating tx
5502020-02-28T20:20:14 <instagibbs> I agree it's not generally usable
5512020-02-28T20:20:25 <gwillen> I am not going to use IsChange if there is not a single case where it actually works right now
5522020-02-28T20:20:37 <gwillen> untested codepaths break
5532020-02-28T20:20:37 <achow101> it will work for single key things
5542020-02-28T20:20:47 <instagibbs> ^
5552020-02-28T20:20:52 <gwillen> so far it appears to me that we have failed to produce a case where that would be useful
5562020-02-28T20:21:09 <achow101> your standard single hardware wallet case
5572020-02-28T20:21:15 <instagibbs> I literally tested your branch and was befuddled when i was confronted with this
5582020-02-28T20:21:35 <achow101> using importmulti, I import a bunch of receive keys into the keypool, and a bunch of change keys
5592020-02-28T20:21:41 *** emilengler has quit IRC
5602020-02-28T20:21:49 <achow101> when I do all the psbt things after signing, I look at the gui and it's showing me the change address
5612020-02-28T20:21:50 <gwillen> you just manually import them, and then import again when you run out?
5622020-02-28T20:21:54 *** emilengler has joined #bitcoin-core-dev
5632020-02-28T20:22:09 <achow101> IsChange would tell you that the change address is change because I had imported those into the change keypool
5642020-02-28T20:22:10 <instagibbs> import 10k or whatever yes
5652020-02-28T20:22:12 <achow101> there's your usecase
5662020-02-28T20:22:12 <gwillen> I mean, I'm happy to support this if it is something that anybody would actually do
5672020-02-28T20:22:16 <instagibbs> I do it!
5682020-02-28T20:22:19 <gwillen> heh, ok
5692020-02-28T20:22:20 <achow101> me too!
5702020-02-28T20:22:25 <instagibbs> thanks <3
5712020-02-28T20:22:43 <gwillen> do you object to still displaying the change, but marking it as change
5722020-02-28T20:22:57 <achow101> that's fine with me
5732020-02-28T20:23:00 <instagibbs> if it's marked change somehow it's fine
5742020-02-28T20:23:03 <gwillen> :+1:
5752020-02-28T20:23:15 <instagibbs> more info for a power user is better
5762020-02-28T20:23:23 <gwillen> I will also add a note, if we do not detect change, explaining that change is a nebulous concept
5772020-02-28T20:23:30 <gwillen> and think about whether I should also include it even if we do
5782020-02-28T20:23:45 *** ddustin has joined #bitcoin-core-dev
5792020-02-28T20:23:54 <gwillen> (just explaining that anything we detect as change is change, but we may not detect all things a user would consider change)
5802020-02-28T20:24:08 *** bitcoin-git has joined #bitcoin-core-dev
5812020-02-28T20:24:09 <bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/9aa8145bc024...7a266a679d66
5822020-02-28T20:24:09 <bitcoin-git> bitcoin/master 7bf4ce4 Sebastian Falbesoner: refactor: test/bench: dedup SetupDummyInputs()
5832020-02-28T20:24:10 <bitcoin-git> bitcoin/master 7a266a6 MarcoFalke: Merge #18173: refactor: test/bench: deduplicate SetupDummyInputs()
5842020-02-28T20:24:12 *** bitcoin-git has left #bitcoin-core-dev
5852020-02-28T20:24:25 *** ddustin has joined #bitcoin-core-dev
5862020-02-28T20:24:26 <instagibbs> descriptor change should be super straight forward and recoverable in an offline setting
5872020-02-28T20:24:29 *** bitcoin-git has joined #bitcoin-core-dev
5882020-02-28T20:24:29 <bitcoin-git> [bitcoin] MarcoFalke merged pull request #18173: refactor: test/bench: deduplicate SetupDummyInputs() (master...20200218-refactor-dedup-SetupDummyInputs) https://github.com/bitcoin/bitcoin/pull/18173
5892020-02-28T20:24:30 *** bitcoin-git has left #bitcoin-core-dev
5902020-02-28T20:24:46 <instagibbs> and transparent with respect to your work
5912020-02-28T20:27:41 *** emilengler has quit IRC
5922020-02-28T20:27:55 *** emilengler has joined #bitcoin-core-dev
5932020-02-28T20:29:15 *** ddustin has quit IRC
5942020-02-28T20:41:10 *** ddustin has joined #bitcoin-core-dev
5952020-02-28T20:51:58 *** captjakk has quit IRC
5962020-02-28T20:56:08 *** captjakk has joined #bitcoin-core-dev
5972020-02-28T21:00:02 *** pabelanger1 has quit IRC
5982020-02-28T21:03:03 *** tryphe_ is now known as tryphe
5992020-02-28T21:09:34 *** bitcoin-git has joined #bitcoin-core-dev
6002020-02-28T21:09:34 <bitcoin-git> [bitcoin] MarcoFalke opened pull request #18228: test: Add missing syncwithvalidationinterfacequeue (master...2002-testFixRace) https://github.com/bitcoin/bitcoin/pull/18228
6012020-02-28T21:09:35 *** bitcoin-git has left #bitcoin-core-dev
6022020-02-28T21:10:04 *** ddustin has quit IRC
6032020-02-28T21:14:20 *** ghost43 has quit IRC
6042020-02-28T21:14:38 *** ghost43 has joined #bitcoin-core-dev
6052020-02-28T21:18:00 *** ddustin has joined #bitcoin-core-dev
6062020-02-28T21:19:13 *** ddustin has joined #bitcoin-core-dev
6072020-02-28T21:20:13 *** jackgassett has joined #bitcoin-core-dev
6082020-02-28T21:20:20 *** ddustin has joined #bitcoin-core-dev
6092020-02-28T21:22:04 *** ddustin has joined #bitcoin-core-dev
6102020-02-28T21:40:21 *** Guyver2 has quit IRC
6112020-02-28T21:45:45 *** emilengler has quit IRC
6122020-02-28T21:48:19 <andytoshi> sipa: achow101: the term is lift, not "pull up" :)
6132020-02-28T21:48:41 <andytoshi> for going from a miniscript (or descriptor, or policy, or simplicity program, or whatever) to an abstract policy
6142020-02-28T21:52:26 *** bitcoin-git has joined #bitcoin-core-dev
6152020-02-28T21:52:27 <bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/7a266a679d66...1a51cd1ac5a0
6162020-02-28T21:52:27 <bitcoin-git> bitcoin/master dc9305b fanquake: random: don't special case clock usage on macOS
6172020-02-28T21:52:28 <bitcoin-git> bitcoin/master 1a51cd1 Wladimir J. van der Laan: Merge #17800: random: don't special case clock usage on macOS
6182020-02-28T21:52:30 *** bitcoin-git has left #bitcoin-core-dev
6192020-02-28T21:52:56 *** bitcoin-git has joined #bitcoin-core-dev
6202020-02-28T21:52:56 <bitcoin-git> [bitcoin] laanwj merged pull request #17800: random: don't special case clock usage on macOS (master...random_macos_clocks) https://github.com/bitcoin/bitcoin/pull/17800
6212020-02-28T21:52:57 *** bitcoin-git has left #bitcoin-core-dev
6222020-02-28T21:53:16 <achow101> andytoshi: I think the term you're looking for is "elevator" :p
6232020-02-28T21:53:17 *** Kiminuo has joined #bitcoin-core-dev
6242020-02-28T21:53:21 <andytoshi> loll
6252020-02-28T21:53:48 <andytoshi> https://en.wikipedia.org/wiki/Lift_(mathematics) i think it's self-evident from this wiki page why the term lift is appropriate
6262020-02-28T21:55:37 <fanquake> I reckon "Tor functor" is the most interesting term in that article.
6272020-02-28T21:56:31 *** guest534543 has quit IRC
6282020-02-28T21:56:41 <sipa> andytoshi: lift is one partof what we were talking about... not sure if we have a term for "analysing if i like a policy"
6292020-02-28T21:56:54 *** promag has joined #bitcoin-core-dev
6302020-02-28T21:57:31 <sipa> and thanks... i forgot the term :)
6312020-02-28T22:03:01 *** bitcoin-git has joined #bitcoin-core-dev
6322020-02-28T22:03:01 <bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/1a51cd1ac5a0...eca4d8ef6aff
6332020-02-28T22:03:02 <bitcoin-git> bitcoin/master 16d6113 Jonas Schnelli: Refactor message transport packaging
6342020-02-28T22:03:02 <bitcoin-git> bitcoin/master eca4d8e MarcoFalke: Merge #16562: Refactor message transport packaging
6352020-02-28T22:03:04 *** bitcoin-git has left #bitcoin-core-dev
6362020-02-28T22:04:06 *** bitcoin-git has joined #bitcoin-core-dev
6372020-02-28T22:04:06 <bitcoin-git> [bitcoin] MarcoFalke merged pull request #16562: Refactor message transport packaging (master...2019/06/net_refactor_2) https://github.com/bitcoin/bitcoin/pull/16562
6382020-02-28T22:04:08 *** bitcoin-git has left #bitcoin-core-dev
6392020-02-28T22:16:00 <andytoshi> sipa: well, "analyzing like a policy" is done (in rust-bitcoin) by first lifting to a policy, then doing the analysis :)
6402020-02-28T22:16:15 <andytoshi> because it would've been a looot of typing to implement all the analysis directly on the miniscript type
6412020-02-28T22:17:53 *** justanotheruser has quit IRC
6422020-02-28T22:18:04 *** justanotheruser has joined #bitcoin-core-dev
6432020-02-28T22:18:53 <sipa> andytoshi: obviously
6442020-02-28T22:28:11 *** luke-jr has quit IRC
6452020-02-28T22:29:39 *** luke-jr has joined #bitcoin-core-dev
6462020-02-28T22:34:01 *** bitcoin-git has joined #bitcoin-core-dev
6472020-02-28T22:34:01 <bitcoin-git> [bitcoin] Empact closed pull request #18226: refactor: Consolidate unnecessary base58 interfaces (master...2020-02-base58) https://github.com/bitcoin/bitcoin/pull/18226
6482020-02-28T22:34:03 *** bitcoin-git has left #bitcoin-core-dev
6492020-02-28T22:35:00 *** jarthur has quit IRC
6502020-02-28T22:47:40 *** EagleTM has joined #bitcoin-core-dev
6512020-02-28T22:59:35 *** bitcoin-git has joined #bitcoin-core-dev
6522020-02-28T22:59:35 <bitcoin-git> [bitcoin] Empact opened pull request #18229: Drop unused MACH time headers (master...2020-02-mach-headers) https://github.com/bitcoin/bitcoin/pull/18229
6532020-02-28T22:59:36 *** belcher has quit IRC
6542020-02-28T22:59:36 *** bitcoin-git has left #bitcoin-core-dev
6552020-02-28T23:02:27 *** manantial has quit IRC
6562020-02-28T23:06:29 *** captjakk has quit IRC
6572020-02-28T23:08:16 *** captjakk has joined #bitcoin-core-dev
6582020-02-28T23:23:01 *** captjakk has quit IRC
6592020-02-28T23:29:42 *** manantial has joined #bitcoin-core-dev
6602020-02-28T23:45:25 *** manantial has quit IRC
6612020-02-28T23:53:24 *** Chris_Stewart_5 has joined #bitcoin-core-dev