12019-10-17T00:00:01 *** glyph1 has quit IRC
22019-10-17T00:03:21 *** Ox207fffff has quit IRC
32019-10-17T00:05:28 *** jarthur_ has joined #bitcoin-core-dev
42019-10-17T00:07:51 *** Ox207fffff has joined #bitcoin-core-dev
52019-10-17T00:08:37 *** jarthur has quit IRC
62019-10-17T00:09:39 *** jarthur_ has quit IRC
72019-10-17T00:17:24 *** sunweaver1 has joined #bitcoin-core-dev
82019-10-17T00:18:57 *** pinheadmz has quit IRC
92019-10-17T00:19:11 *** fox2p has quit IRC
102019-10-17T00:21:43 *** fox2p has joined #bitcoin-core-dev
112019-10-17T00:26:32 *** pinheadmz has joined #bitcoin-core-dev
122019-10-17T00:28:15 *** jarthur has joined #bitcoin-core-dev
132019-10-17T00:32:51 *** justanotheruser has quit IRC
142019-10-17T00:36:17 *** pinheadmz has quit IRC
152019-10-17T00:36:41 *** bitcoin-git has joined #bitcoin-core-dev
162019-10-17T00:36:41 <bitcoin-git> [bitcoin] fanquake opened pull request #17169: doc: correct function name in ReportHardwareRand() (master...random_doc_inithardwarerand) https://github.com/bitcoin/bitcoin/pull/17169
172019-10-17T00:36:42 *** bitcoin-git has left #bitcoin-core-dev
182019-10-17T00:49:25 *** justanotheruser has joined #bitcoin-core-dev
192019-10-17T00:54:05 *** DeanGuss has joined #bitcoin-core-dev
202019-10-17T01:07:35 *** arik_ has quit IRC
212019-10-17T01:08:59 *** arik_ has joined #bitcoin-core-dev
222019-10-17T01:15:01 *** pinheadmz has joined #bitcoin-core-dev
232019-10-17T01:25:36 *** arik_ has quit IRC
242019-10-17T01:31:29 *** jarthur has quit IRC
252019-10-17T02:01:56 *** DeanGuss has quit IRC
262019-10-17T02:02:27 *** millerti has quit IRC
272019-10-17T02:05:42 *** emilengler has joined #bitcoin-core-dev
282019-10-17T02:08:25 *** felixfoertsch23 has joined #bitcoin-core-dev
292019-10-17T02:09:23 *** felixfoertsch has quit IRC
302019-10-17T02:33:44 *** tripleslash has joined #bitcoin-core-dev
312019-10-17T02:43:55 *** Highway61 has quit IRC
322019-10-17T02:45:25 *** DeanGuss has joined #bitcoin-core-dev
332019-10-17T02:51:11 *** jarthur has joined #bitcoin-core-dev
342019-10-17T02:51:52 *** DeanGuss has quit IRC
352019-10-17T02:57:30 *** promag has joined #bitcoin-core-dev
362019-10-17T03:00:01 *** sunweaver1 has quit IRC
372019-10-17T03:02:12 *** promag has quit IRC
382019-10-17T03:12:48 *** andytoshi has quit IRC
392019-10-17T03:17:14 *** DeanGuss has joined #bitcoin-core-dev
402019-10-17T03:17:35 *** angvp has joined #bitcoin-core-dev
412019-10-17T03:26:24 *** mycomputer has quit IRC
422019-10-17T03:50:21 *** justanotheruser has quit IRC
432019-10-17T03:55:18 *** justanotheruser has joined #bitcoin-core-dev
442019-10-17T03:57:26 *** justanotheruser has quit IRC
452019-10-17T04:00:33 *** justanotheruser has joined #bitcoin-core-dev
462019-10-17T04:07:56 *** DeanGuss has quit IRC
472019-10-17T04:16:38 *** felixfoertsch23 has quit IRC
482019-10-17T04:16:47 *** felixfoertsch has joined #bitcoin-core-dev
492019-10-17T04:39:57 *** jkczyz has joined #bitcoin-core-dev
502019-10-17T04:56:54 *** shesek` has joined #bitcoin-core-dev
512019-10-17T04:56:54 *** shesek has quit IRC
522019-10-17T04:58:20 *** kergjo has joined #bitcoin-core-dev
532019-10-17T05:00:45 *** kergjo has quit IRC
542019-10-17T05:01:31 *** pinheadmz_ has joined #bitcoin-core-dev
552019-10-17T05:03:31 *** pinheadmz has quit IRC
562019-10-17T05:03:31 *** pinheadmz_ is now known as pinheadmz
572019-10-17T05:15:57 <meshcollider> Ok so regarding #16341, who is currently reviewing or intending to review? promag mentioned that he was going to yesterday. Just to get a rough idea. jnewbery / sipa are either of you planning to?
582019-10-17T05:15:59 <gribble> https://github.com/bitcoin/bitcoin/issues/16341 | Introduce ScriptPubKeyMan interface and use it for key and script management (aka wallet boxes) by achow101 · Pull Request #16341 · bitcoin/bitcoin · GitHub
592019-10-17T05:23:07 <sipa> definitely plannimg to
602019-10-17T05:24:04 *** Guyver2 has joined #bitcoin-core-dev
612019-10-17T05:25:28 *** Skirmant has quit IRC
622019-10-17T05:25:49 *** Skirmant has joined #bitcoin-core-dev
632019-10-17T05:58:04 *** shesek` has quit IRC
642019-10-17T05:58:06 *** shesek`` has joined #bitcoin-core-dev
652019-10-17T06:00:01 *** angvp has quit IRC
662019-10-17T06:07:49 *** Guyver2 has quit IRC
672019-10-17T06:12:12 *** shesek` has joined #bitcoin-core-dev
682019-10-17T06:13:23 *** shesek`` has quit IRC
692019-10-17T06:17:38 *** WhereIsMySpoon has joined #bitcoin-core-dev
702019-10-17T06:17:49 *** Victorsueca has quit IRC
712019-10-17T06:18:37 *** bsm1175321 has quit IRC
722019-10-17T06:18:57 *** Victorsueca has joined #bitcoin-core-dev
732019-10-17T06:51:17 *** jkczyz has quit IRC
742019-10-17T07:03:42 *** Francisco_ has left #bitcoin-core-dev
752019-10-17T07:05:38 *** _Francisco_ has joined #bitcoin-core-dev
762019-10-17T07:06:40 *** Emcy has quit IRC
772019-10-17T07:11:05 *** rex4539 has joined #bitcoin-core-dev
782019-10-17T07:19:37 *** jkczyz has joined #bitcoin-core-dev
792019-10-17T07:22:11 *** marcoagner has joined #bitcoin-core-dev
802019-10-17T07:24:40 *** jkczyz has quit IRC
812019-10-17T07:32:51 *** jonatack has quit IRC
822019-10-17T07:36:12 <jeremyrubin> There aren't RPCs which support raw scripts are there?
832019-10-17T07:36:37 <sipa> what does that mean?
842019-10-17T07:37:20 <jeremyrubin> e.g., in sendmany you pass a associative list of addresses and values
852019-10-17T07:37:22 <sipa> decodescript certainly does, in a way
862019-10-17T07:39:03 <jeremyrubin> but I guess there's not a decent way to make a transaction to a raw piece of ASM
872019-10-17T07:39:30 <sipa> no, asm is ambiguous even
882019-10-17T07:39:39 <sipa> you can't convert it back to script
892019-10-17T07:39:55 <jeremyrubin> err hexstr
902019-10-17T07:41:02 <sipa> with a lot of imagination, sendrawtransaction/fundrawtransacrion/... support that
912019-10-17T07:41:10 <sipa> but that's it
922019-10-17T07:41:13 <jeremyrubin> hence 'decent'
932019-10-17T07:47:53 *** kljasdfvv has quit IRC
942019-10-17T07:49:31 *** kljasdfvv has joined #bitcoin-core-dev
952019-10-17T08:27:08 *** AaronvanW has joined #bitcoin-core-dev
962019-10-17T08:28:10 *** promag has joined #bitcoin-core-dev
972019-10-17T08:30:54 *** promag_ has joined #bitcoin-core-dev
982019-10-17T08:34:37 *** EagleTM has joined #bitcoin-core-dev
992019-10-17T08:35:08 *** promag_ has quit IRC
1002019-10-17T08:38:36 *** jarthur has quit IRC
1012019-10-17T08:44:01 *** jonatack has joined #bitcoin-core-dev
1022019-10-17T08:44:30 *** designwish has quit IRC
1032019-10-17T08:48:50 *** Highway61 has joined #bitcoin-core-dev
1042019-10-17T08:49:36 *** tsujp has quit IRC
1052019-10-17T08:49:55 *** tsujp_ has joined #bitcoin-core-dev
1062019-10-17T09:00:01 *** WhereIsMySpoon has quit IRC
1072019-10-17T09:06:15 *** designwish has joined #bitcoin-core-dev
1082019-10-17T09:09:01 *** gwillen has quit IRC
1092019-10-17T09:09:39 *** EagleTM has quit IRC
1102019-10-17T09:11:47 *** sipa has quit IRC
1112019-10-17T09:15:34 *** timothy has joined #bitcoin-core-dev
1122019-10-17T09:17:04 *** votesmith has quit IRC
1132019-10-17T09:17:17 *** mota has joined #bitcoin-core-dev
1142019-10-17T09:18:13 *** profmac has quit IRC
1152019-10-17T09:20:30 *** jkczyz has joined #bitcoin-core-dev
1162019-10-17T09:22:22 *** sipa has joined #bitcoin-core-dev
1172019-10-17T09:23:44 *** votesmith has joined #bitcoin-core-dev
1182019-10-17T09:24:57 *** jkczyz has quit IRC
1192019-10-17T09:30:28 *** profmac has joined #bitcoin-core-dev
1202019-10-17T09:30:49 *** jonatack has quit IRC
1212019-10-17T09:31:18 *** jonatack has joined #bitcoin-core-dev
1222019-10-17T09:44:38 *** oyvkva has quit IRC
1232019-10-17T09:44:53 *** oyvkva_ has joined #bitcoin-core-dev
1242019-10-17T09:45:29 *** Emcy has joined #bitcoin-core-dev
1252019-10-17T09:50:55 <promag> meshcollider: yes, I'm reviewing that one.
1262019-10-17T09:53:31 <meshcollider> ð
1272019-10-17T09:56:03 *** rex4539 has quit IRC
1282019-10-17T10:08:51 *** spinza has quit IRC
1292019-10-17T10:18:50 *** rex4539 has joined #bitcoin-core-dev
1302019-10-17T10:29:43 *** Mael-Rolland has joined #bitcoin-core-dev
1312019-10-17T11:12:24 *** waxwing_ has left #bitcoin-core-dev
1322019-10-17T11:13:09 *** waxwing has joined #bitcoin-core-dev
1332019-10-17T11:18:40 *** morcos has quit IRC
1342019-10-17T11:19:09 *** jb551 has quit IRC
1352019-10-17T11:19:09 *** kristapsk has quit IRC
1362019-10-17T11:19:09 *** SiAnDoG has quit IRC
1372019-10-17T11:19:09 *** braydonf has quit IRC
1382019-10-17T11:19:09 *** mryandao has quit IRC
1392019-10-17T11:19:09 *** afk11 has quit IRC
1402019-10-17T11:19:36 *** sipa has quit IRC
1412019-10-17T11:19:36 *** lowentropy has quit IRC
1422019-10-17T11:19:36 *** astro has quit IRC
1432019-10-17T11:19:36 *** ghost43 has quit IRC
1442019-10-17T11:19:36 *** sdaftuar has quit IRC
1452019-10-17T11:19:36 *** arubi has quit IRC
1462019-10-17T11:21:21 *** jkczyz has joined #bitcoin-core-dev
1472019-10-17T11:26:14 *** jkczyz has quit IRC
1482019-10-17T11:28:32 *** m1rror8955363887 has joined #bitcoin-core-dev
1492019-10-17T11:32:31 *** braydonf has joined #bitcoin-core-dev
1502019-10-17T11:32:39 *** lowentropy has joined #bitcoin-core-dev
1512019-10-17T11:33:23 *** mryandao has joined #bitcoin-core-dev
1522019-10-17T11:33:25 *** jb551 has joined #bitcoin-core-dev
1532019-10-17T11:33:26 *** afk11 has joined #bitcoin-core-dev
1542019-10-17T11:36:39 *** sdaftuar has joined #bitcoin-core-dev
1552019-10-17T11:38:21 *** astro has joined #bitcoin-core-dev
1562019-10-17T11:39:32 *** ghost43 has joined #bitcoin-core-dev
1572019-10-17T11:40:31 *** Mael-Rolland has quit IRC
1582019-10-17T11:44:15 *** sipa has joined #bitcoin-core-dev
1592019-10-17T12:00:02 *** mota has quit IRC
1602019-10-17T12:17:22 *** pdurbin1 has joined #bitcoin-core-dev
1612019-10-17T12:23:18 *** spinza has joined #bitcoin-core-dev
1622019-10-17T12:24:43 *** bitcoin-git has joined #bitcoin-core-dev
1632019-10-17T12:24:44 <bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/46d6930f8c7b...4f42284fc0c5
1642019-10-17T12:24:44 <bitcoin-git> bitcoin/master f59bbb6 Jim Posen: test: Fix bug in blockfilter_index_tests.
1652019-10-17T12:24:45 <bitcoin-git> bitcoin/master 4f42284 MarcoFalke: Merge #17140: test: Fix bug in blockfilter_index_tests.
1662019-10-17T12:24:47 *** bitcoin-git has left #bitcoin-core-dev
1672019-10-17T12:25:04 *** bitcoin-git has joined #bitcoin-core-dev
1682019-10-17T12:25:04 <bitcoin-git> [bitcoin] MarcoFalke merged pull request #17140: test: Fix bug in blockfilter_index_tests. (master...fix-index-test) https://github.com/bitcoin/bitcoin/pull/17140
1692019-10-17T12:25:05 *** bitcoin-git has left #bitcoin-core-dev
1702019-10-17T12:26:15 *** Mael-Rolland has joined #bitcoin-core-dev
1712019-10-17T12:26:20 *** EagleTM has joined #bitcoin-core-dev
1722019-10-17T12:28:32 *** bitcoin-git has joined #bitcoin-core-dev
1732019-10-17T12:28:32 <bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/4f42284fc0c5...fcf1ebde3db9
1742019-10-17T12:28:33 <bitcoin-git> bitcoin/master 5013171 fanquake: doc: correct function name in ReportHardwareRand()
1752019-10-17T12:28:33 <bitcoin-git> bitcoin/master fcf1ebd MarcoFalke: Merge #17169: doc: correct function name in ReportHardwareRand()
1762019-10-17T12:28:44 *** bitcoin-git has left #bitcoin-core-dev
1772019-10-17T12:29:02 *** bitcoin-git has joined #bitcoin-core-dev
1782019-10-17T12:29:02 <bitcoin-git> [bitcoin] MarcoFalke merged pull request #17169: doc: correct function name in ReportHardwareRand() (master...random_doc_inithardwarerand) https://github.com/bitcoin/bitcoin/pull/17169
1792019-10-17T12:29:03 *** bitcoin-git has left #bitcoin-core-dev
1802019-10-17T12:38:05 *** timothy has quit IRC
1812019-10-17T12:38:47 *** davterra has joined #bitcoin-core-dev
1822019-10-17T12:40:17 *** Emcy has quit IRC
1832019-10-17T12:40:58 *** Mael-Rolland has quit IRC
1842019-10-17T12:42:36 *** tsujp_ has quit IRC
1852019-10-17T12:48:03 *** tsujp has joined #bitcoin-core-dev
1862019-10-17T12:49:35 *** Emcy has joined #bitcoin-core-dev
1872019-10-17T12:52:31 *** bitcoin-git has joined #bitcoin-core-dev
1882019-10-17T12:52:31 <bitcoin-git> [bitcoin] ch4ot1c opened pull request #17172: doc: Update list of valid PR areas (master...doc/pr-areas) https://github.com/bitcoin/bitcoin/pull/17172
1892019-10-17T12:52:32 *** bitcoin-git has left #bitcoin-core-dev
1902019-10-17T12:57:30 *** Sentineo has quit IRC
1912019-10-17T13:01:33 *** Sentineo has joined #bitcoin-core-dev
1922019-10-17T13:16:18 *** jonatack has quit IRC
1932019-10-17T13:16:37 *** jonatack_ has joined #bitcoin-core-dev
1942019-10-17T13:22:19 *** jkczyz has joined #bitcoin-core-dev
1952019-10-17T13:26:58 *** jkczyz has quit IRC
1962019-10-17T13:27:59 *** EagleTM has quit IRC
1972019-10-17T13:41:23 *** bitcoin-git has joined #bitcoin-core-dev
1982019-10-17T13:41:23 <bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/fcf1ebde3db9...048e456fc408
1992019-10-17T13:41:24 <bitcoin-git> bitcoin/master 85016e5 Andrew Toth: [rpc] Fix broken bitcoin-cli examples
2002019-10-17T13:41:24 <bitcoin-git> bitcoin/master 048e456 Wladimir J. van der Laan: Merge #17119: doc: Fix broken bitcoin-cli examples
2012019-10-17T13:41:26 *** bitcoin-git has left #bitcoin-core-dev
2022019-10-17T13:41:53 *** jonatack_ has quit IRC
2032019-10-17T13:41:54 *** bitcoin-git has joined #bitcoin-core-dev
2042019-10-17T13:41:54 <bitcoin-git> [bitcoin] laanwj merged pull request #17119: doc: Fix broken bitcoin-cli examples (master...example-fixes) https://github.com/bitcoin/bitcoin/pull/17119
2052019-10-17T13:41:57 *** bitcoin-git has left #bitcoin-core-dev
2062019-10-17T13:42:55 *** jonatack_ has joined #bitcoin-core-dev
2072019-10-17T13:45:48 *** ddustin has joined #bitcoin-core-dev
2082019-10-17T13:50:28 *** ddustin has quit IRC
2092019-10-17T13:52:52 *** rex4539 has quit IRC
2102019-10-17T13:53:15 *** rex4539 has joined #bitcoin-core-dev
2112019-10-17T13:53:58 *** rex4539 has joined #bitcoin-core-dev
2122019-10-17T13:54:38 *** rex4539 has joined #bitcoin-core-dev
2132019-10-17T13:55:28 *** rex4539 has quit IRC
2142019-10-17T14:17:44 *** rex4539 has joined #bitcoin-core-dev
2152019-10-17T14:26:24 *** lightlike has joined #bitcoin-core-dev
2162019-10-17T14:28:20 *** ensign has joined #bitcoin-core-dev
2172019-10-17T14:37:20 *** mdunnio has joined #bitcoin-core-dev
2182019-10-17T14:38:18 *** timothy has joined #bitcoin-core-dev
2192019-10-17T14:39:31 *** tsujp has quit IRC
2202019-10-17T14:39:37 *** bitcoin-git has joined #bitcoin-core-dev
2212019-10-17T14:39:39 <bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/048e456fc408...ec3ed5a44878
2222019-10-17T14:39:40 <bitcoin-git> bitcoin/master 1f6c650 Sjors Provoost: travis: run tests on macOS native
2232019-10-17T14:39:41 <bitcoin-git> bitcoin/master ec3ed5a MarcoFalke: Merge #16597: Travis: run full test suite on native macOS
2242019-10-17T14:39:43 *** bitcoin-git has left #bitcoin-core-dev
2252019-10-17T14:40:07 *** bitcoin-git has joined #bitcoin-core-dev
2262019-10-17T14:40:08 <bitcoin-git> [bitcoin] MarcoFalke merged pull request #16597: Travis: run full test suite on native macOS (master...2019/08/travis-macos) https://github.com/bitcoin/bitcoin/pull/16597
2272019-10-17T14:40:09 *** bitcoin-git has left #bitcoin-core-dev
2282019-10-17T14:41:31 *** EagleTM has joined #bitcoin-core-dev
2292019-10-17T14:42:15 *** mdunnio has quit IRC
2302019-10-17T14:53:12 *** bitcoin-git has joined #bitcoin-core-dev
2312019-10-17T14:53:13 <bitcoin-git> [bitcoin] MarcoFalke opened pull request #17176: ci: Cleanup macOS runs (master...1910-ciMac) https://github.com/bitcoin/bitcoin/pull/17176
2322019-10-17T14:53:15 *** bitcoin-git has left #bitcoin-core-dev
2332019-10-17T14:55:34 *** bitcoin-git has joined #bitcoin-core-dev
2342019-10-17T14:55:34 <bitcoin-git> [bitcoin] fjahr opened pull request #17177: doc: Describe log files + consistent paths in test READMEs (master...pr15830) https://github.com/bitcoin/bitcoin/pull/17177
2352019-10-17T14:55:46 *** bitcoin-git has left #bitcoin-core-dev
2362019-10-17T14:58:58 *** davterra has quit IRC
2372019-10-17T15:00:02 *** pdurbin1 has quit IRC
2382019-10-17T15:02:18 *** mdunnio has joined #bitcoin-core-dev
2392019-10-17T15:03:09 *** jonatack_ has quit IRC
2402019-10-17T15:09:34 *** mdunnio has quit IRC
2412019-10-17T15:16:39 *** gwillen has joined #bitcoin-core-dev
2422019-10-17T15:16:59 *** mdunnio has joined #bitcoin-core-dev
2432019-10-17T15:17:26 *** Darki1 has joined #bitcoin-core-dev
2442019-10-17T15:21:03 *** captjakk has joined #bitcoin-core-dev
2452019-10-17T15:23:11 *** jkczyz has joined #bitcoin-core-dev
2462019-10-17T15:27:47 *** hebasto has joined #bitcoin-core-dev
2472019-10-17T15:27:58 *** jkczyz has quit IRC
2482019-10-17T15:33:10 *** afk11 has quit IRC
2492019-10-17T15:33:34 *** afk11 has joined #bitcoin-core-dev
2502019-10-17T15:35:58 *** davterra has joined #bitcoin-core-dev
2512019-10-17T15:58:47 *** captjakk has quit IRC
2522019-10-17T15:59:57 *** captjakk has joined #bitcoin-core-dev
2532019-10-17T16:00:05 *** kljasdfvv has quit IRC
2542019-10-17T16:16:52 *** astro has quit IRC
2552019-10-17T16:19:38 *** mdunnio has quit IRC
2562019-10-17T16:22:21 *** astro has joined #bitcoin-core-dev
2572019-10-17T16:23:21 *** jungly has quit IRC
2582019-10-17T16:25:13 *** Guyver2 has joined #bitcoin-core-dev
2592019-10-17T16:26:27 *** rabidus has quit IRC
2602019-10-17T16:28:25 *** rabidus has joined #bitcoin-core-dev
2612019-10-17T16:29:34 *** mdunnio has joined #bitcoin-core-dev
2622019-10-17T16:31:34 *** mdunnio has quit IRC
2632019-10-17T16:35:20 *** jkczyz has joined #bitcoin-core-dev
2642019-10-17T16:35:41 *** afk11` has joined #bitcoin-core-dev
2652019-10-17T16:37:52 *** afk11 has quit IRC
2662019-10-17T16:40:05 *** mdunnio has joined #bitcoin-core-dev
2672019-10-17T16:42:00 *** angins has joined #bitcoin-core-dev
2682019-10-17T16:44:50 *** mdunnio has quit IRC
2692019-10-17T16:46:08 *** BlueMatt has quit IRC
2702019-10-17T16:48:29 *** BlueMatt has joined #bitcoin-core-dev
2712019-10-17T16:48:47 *** ddustin has joined #bitcoin-core-dev
2722019-10-17T16:49:56 *** ddustin has joined #bitcoin-core-dev
2732019-10-17T16:50:16 *** mdunnio has joined #bitcoin-core-dev
2742019-10-17T16:54:55 *** mdunnio has quit IRC
2752019-10-17T16:58:20 *** kristapsk has joined #bitcoin-core-dev
2762019-10-17T17:00:31 *** mdunnio has joined #bitcoin-core-dev
2772019-10-17T17:05:05 *** mdunnio has quit IRC
2782019-10-17T17:10:41 *** mdunnio has joined #bitcoin-core-dev
2792019-10-17T17:14:53 *** mdunnio has quit IRC
2802019-10-17T17:16:06 *** mdunnio has joined #bitcoin-core-dev
2812019-10-17T17:18:58 *** justanotheruser has quit IRC
2822019-10-17T17:19:06 *** jonatack_ has joined #bitcoin-core-dev
2832019-10-17T17:20:32 *** timothy has quit IRC
2842019-10-17T17:20:53 *** mmgen has joined #bitcoin-core-dev
2852019-10-17T17:36:57 <sipa> jonasschnelli: where is your latest v2 p2p protocol draft?
2862019-10-17T17:37:46 *** justanotheruser has joined #bitcoin-core-dev
2872019-10-17T17:39:54 <sipa> gleb: re #17163... are you sure that no lightweight clients do their own IP address management? maybe they don't currently, but that sounds like a bug
2882019-10-17T17:39:56 <gribble> https://github.com/bitcoin/bitcoin/issues/17163 | p2p: Avoid relaying ADDR messages to SPV clients by naumenkogs · Pull Request #17163 · bitcoin/bitcoin · GitHub
2892019-10-17T17:43:01 <jonasschnelli> sipa: https://gist.github.com/jonasschnelli/c530ea8421b8d0e80c51486325587c52
2902019-10-17T17:44:29 *** arik_ has joined #bitcoin-core-dev
2912019-10-17T17:47:39 <wumpus> sipa: I also wasn't sure the tight coupling between lightweight validation and no IP address management, but apparently it's an accepted thing
2922019-10-17T17:48:10 <wumpus> tbh, I think everyone that cares about decent address management gave up on SPV nodes long ago
2932019-10-17T17:48:42 <wumpus> so it's not wrong, but it wouldn't have to be a necessary correlation
2942019-10-17T17:49:05 <gleb> sipa: This was my intuition. Maybe, we should allow them to ask (we can discuss that), but we certainly don't want to rely on them when we choose 1/2 peers to forward a <10 addr message.
2952019-10-17T17:50:07 <sipa> gleb: agree there; i commented on your PR
2962019-10-17T17:54:54 <gleb> Let's ask others at the meeting in an hour :) Should be pretty quick.
2972019-10-17T17:58:27 *** jkczyz has quit IRC
2982019-10-17T18:00:02 *** Darki1 has quit IRC
2992019-10-17T18:01:27 <gleb> Another idea would be to add a service flag? Sounds reasonable to me protocol-wise, but I'm not sure I have the right intuition.
3002019-10-17T18:03:50 <wumpus> you want a way to be able to signify that nodes don't want to receive addr messages at all?
3012019-10-17T18:03:54 *** bitcoin-git has joined #bitcoin-core-dev
3022019-10-17T18:03:54 <bitcoin-git> [bitcoin] fanquake closed pull request #17172: doc: Update list of valid PR areas (master...doc/pr-areas) https://github.com/bitcoin/bitcoin/pull/17172
3032019-10-17T18:04:06 *** bitcoin-git has left #bitcoin-core-dev
3042019-10-17T18:06:01 <wumpus> might be able to smuggle that into addrv2 somehow; it has a proposed message for a peer to signify support for v2 addrsses, maybe it could signify 'no addr support' as well
3052019-10-17T18:06:16 *** jkczyz has joined #bitcoin-core-dev
3062019-10-17T18:06:24 *** mdunnio has quit IRC
3072019-10-17T18:08:28 *** mdunnio has joined #bitcoin-core-dev
3082019-10-17T18:08:34 <luke-jr> maybe there should be a node mode that *only* relays addr messages, and sipa could only return those with his DNS seed :P
3092019-10-17T18:08:37 <fanquake> rex4539 This might be the error message you were talking about the other day #17179
3102019-10-17T18:08:38 <gribble> https://github.com/bitcoin/bitcoin/issues/17179 | macos: shutdown on first run due to -psn_ parameter · Issue #17179 · bitcoin/bitcoin · GitHub
3112019-10-17T18:09:43 <rex4539> Yes, this was it :)
3122019-10-17T18:10:36 <fanquake> Good to know at least 1 other person has been (clean) testing rc1 on macOS
3132019-10-17T18:10:59 <wumpus> why does this happen with rc1 though?
3142019-10-17T18:11:09 <wumpus> and not with other versions
3152019-10-17T18:11:55 <luke-jr> another Qt thing?
3162019-10-17T18:12:01 <luke-jr> like the duplicate URIs
3172019-10-17T18:12:05 <fanquake> It might be because we are doing more strict argument passing now? It's also only happens when you run Bitcoin Core for the very first time
3182019-10-17T18:12:09 <wumpus> oh, maybe Qt filtered it out before
3192019-10-17T18:12:19 <wumpus> right
3202019-10-17T18:12:42 <luke-jr> https://stackoverflow.com/questions/10242115/os-x-strange-psn-command-line-parameter-when-launched-from-finder
3212019-10-17T18:12:49 <wumpus> Qt's argument handling probebly kind of shielded us from platform specific craziness like this
3222019-10-17T18:12:49 <fanquake> heh, so qt does filter it out yes
3232019-10-17T18:13:02 <fanquake> from qtbase: "// eat "-psn_xxxx" on Mac, which is passed when starting an app from Finder."
3242019-10-17T18:13:03 <wumpus> like the files handling
3252019-10-17T18:13:21 <luke-jr> fanquake: is it near the duplicate URI filtering code? maybe someone should go through all that
3262019-10-17T18:14:02 <fanquake> Will link to the tree in a sec
3272019-10-17T18:14:32 <wumpus> everyone on every OS now has to suffer basically because of a buggy browser issue on windows :-)
3282019-10-17T18:14:34 <fanquake> https://code.qt.io/cgit/qt/qtbase.git/tree/src/gui/kernel/qguiapplication.cpp?h=5.9.8#n1377
3292019-10-17T18:17:21 *** chrissie1 has joined #bitcoin-core-dev
3302019-10-17T18:17:57 <luke-jr> so we should chdir too..?
3312019-10-17T18:18:12 <luke-jr> or do we even care
3322019-10-17T18:20:13 *** watchtower has joined #bitcoin-core-dev
3332019-10-17T18:20:17 *** jonatack_ has quit IRC
3342019-10-17T18:23:26 *** watchtower has quit IRC
3352019-10-17T18:24:35 <fanquake> I don't think we care. I'm not sure why they are changing directory code was added. The commit is from 7 years ago, and doesn't have much detail. However they were doing the psn filtering before that was added.
3362019-10-17T18:26:17 <gleb> luke-jr: jokes aside, I was considering separating addr-relay from tx-relay and block-relay. Because I think topology leakage is cumulative, haha. But that requires a lot of analysis.
3372019-10-17T18:30:09 *** arik_ has quit IRC
3382019-10-17T18:30:46 *** bitcoin-git has joined #bitcoin-core-dev
3392019-10-17T18:30:47 <bitcoin-git> [bitcoin] JeremyCrookshank opened pull request #17180: gui: Improved wording/explanation of Bitcoin sends amount box (master...sendamounttooltip) https://github.com/bitcoin/bitcoin/pull/17180
3402019-10-17T18:30:48 *** bitcoin-git has left #bitcoin-core-dev
3412019-10-17T18:32:37 *** Skirmant has quit IRC
3422019-10-17T18:35:43 *** Skirmant has joined #bitcoin-core-dev
3432019-10-17T18:37:34 *** drbrule has joined #bitcoin-core-dev
3442019-10-17T18:37:59 *** bitcoin-git has joined #bitcoin-core-dev
3452019-10-17T18:37:59 <bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/ec3ed5a44878...88eff969c201
3462019-10-17T18:37:59 <bitcoin-git> bitcoin/master 9576614 Martin Erlandsson: doc: Describe log files + consistent paths in test READMEs
3472019-10-17T18:38:00 <bitcoin-git> bitcoin/master 88eff96 MarcoFalke: Merge #17177: doc: Describe log files + consistent paths in test READMEs
3482019-10-17T18:38:12 *** bitcoin-git has left #bitcoin-core-dev
3492019-10-17T18:38:29 *** bitcoin-git has joined #bitcoin-core-dev
3502019-10-17T18:38:29 <bitcoin-git> [bitcoin] MarcoFalke merged pull request #17177: doc: Describe log files + consistent paths in test READMEs (master...pr15830) https://github.com/bitcoin/bitcoin/pull/17177
3512019-10-17T18:38:41 *** bitcoin-git has left #bitcoin-core-dev
3522019-10-17T18:39:39 <warren> I'm here for the weekly meeting, that's in 20 minutes?
3532019-10-17T18:40:01 <wumpus> yes
3542019-10-17T18:49:08 *** mdunnio has quit IRC
3552019-10-17T18:49:31 <dongcarl> gleb: Not 100% sure what you mean in your latest comment on #17163
3562019-10-17T18:49:33 <gribble> https://github.com/bitcoin/bitcoin/issues/17163 | p2p: Avoid relaying ADDR messages to SPV clients by naumenkogs · Pull Request #17163 · bitcoin/bitcoin · GitHub
3572019-10-17T18:49:58 *** mdunnio has joined #bitcoin-core-dev
3582019-10-17T18:50:20 <dongcarl> "Older nodes are very likely to forward their <10 addr messages in the blackhole" because they might forward to newer nodes that will ignore addr messages from incoming connections like sipa described?
3592019-10-17T18:52:41 <gleb> Yes
3602019-10-17T18:53:59 *** bitcoin-git has joined #bitcoin-core-dev
3612019-10-17T18:53:59 <bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/88eff969c201...4daadce36cfe
3622019-10-17T18:54:00 <bitcoin-git> bitcoin/master fa04673 MarcoFalke: chain: Set all CBlockIndex members to null, remove SetNull helper
3632019-10-17T18:54:00 <bitcoin-git> bitcoin/master 4daadce fanquake: Merge #17162: chain: Remove CBlockIndex::SetNull helper
3642019-10-17T18:54:12 *** bitcoin-git has left #bitcoin-core-dev
3652019-10-17T18:54:29 *** bitcoin-git has joined #bitcoin-core-dev
3662019-10-17T18:54:29 <bitcoin-git> [bitcoin] fanquake merged pull request #17162: chain: Remove CBlockIndex::SetNull helper (master...1910-docChainLocks) https://github.com/bitcoin/bitcoin/pull/17162
3672019-10-17T18:54:41 *** bitcoin-git has left #bitcoin-core-dev
3682019-10-17T18:57:04 <dongcarl> gleb: "it's very likely that this "stem" will end up at a private node very fast (just graph-wise), and it will drop it on the floor" private node being a node with only outgoing connections?
3692019-10-17T18:58:45 <gleb> dongcarl: also yes.
3702019-10-17T18:59:11 <dongcarl> gleb: if this private node only has outgoing connections, why would it drop anything on the floor?
3712019-10-17T19:00:02 *** jb551 has quit IRC
3722019-10-17T19:00:03 *** mryandao has quit IRC
3732019-10-17T19:00:04 <gleb> Because I assume that if we enforce a rule "don't accept addr from inbounds", then this private node won't even try to relay it further (as the receiver will discard it)
3742019-10-17T19:00:10 <gleb> .
3752019-10-17T19:00:22 <dongcarl> gleb: oh I see...
3762019-10-17T19:00:31 <wumpus> #startmeeting
3772019-10-17T19:00:31 <lightningbot> Meeting started Thu Oct 17 19:00:31 2019 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
3782019-10-17T19:00:31 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
3792019-10-17T19:00:32 <jnewbery> hi
3802019-10-17T19:00:34 *** jb551 has joined #bitcoin-core-dev
3812019-10-17T19:00:34 <warren> hi
3822019-10-17T19:00:34 <kanzure> hi
3832019-10-17T19:00:38 <gleb> hi
3842019-10-17T19:00:41 <moneyball> hi
3852019-10-17T19:00:44 <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 moneyball kvaciral
3862019-10-17T19:00:48 <jonasschnelli> hi
3872019-10-17T19:00:49 <fanquake> hi
3882019-10-17T19:01:05 <dongcarl> hi
3892019-10-17T19:01:10 <jeremyrubin> hi
3902019-10-17T19:01:13 <wumpus> one proposed topic for today: taproot proposal next steps; possible review sessions (moneyball)
3912019-10-17T19:01:22 *** mryandao has joined #bitcoin-core-dev
3922019-10-17T19:01:37 <sipa> hi
3932019-10-17T19:01:49 <moneyball> wumpus: i assume we'll do high priority list first?
3942019-10-17T19:01:50 <aj> hola
3952019-10-17T19:02:13 <promag> hi
3962019-10-17T19:02:19 <wumpus> moneyball: yes, let's start with that (I wait a bit in case people have additional last minute topics to propose)
3972019-10-17T19:02:55 <wumpus> #topic High priority for review
3982019-10-17T19:03:02 <achow101> hi
3992019-10-17T19:03:12 <wumpus> https://github.com/bitcoin/bitcoin/projects/8
4002019-10-17T19:03:18 <promag> please add 17135
4012019-10-17T19:03:30 <wumpus> #17135
4022019-10-17T19:03:32 <gribble> https://github.com/bitcoin/bitcoin/issues/17135 | gui: Make polling in ClientModel asynchronous by promag · Pull Request #17135 · bitcoin/bitcoin · GitHub
4032019-10-17T19:04:06 <fanquake> promag: can you fill out the description in that PR? Why is it high-prio?
4042019-10-17T19:04:30 <wumpus> promag: ok done
4052019-10-17T19:04:58 <promag> fanquake: IMO they are necessary for 0.19, also #16963 #17120
4062019-10-17T19:05:01 <promag> ty
4072019-10-17T19:05:01 <gribble> https://github.com/bitcoin/bitcoin/issues/16963 | wallet: Fix unique_ptr usage in boost::signals2 by promag · Pull Request #16963 · bitcoin/bitcoin · GitHub
4082019-10-17T19:05:03 <wumpus> yes, would be nice if you also say what it is blocking
4092019-10-17T19:05:04 <gribble> https://github.com/bitcoin/bitcoin/issues/17120 | gui: Fix start timer from non QThread by promag · Pull Request #17120 · bitcoin/bitcoin · GitHub
4102019-10-17T19:05:19 <wumpus> seems to big a change for 0.19.0 at least
4112019-10-17T19:05:24 <wumpus> 0.19.1 maybe
4122019-10-17T19:06:38 <promag> I'll update description sure
4132019-10-17T19:06:46 <fanquake> I'll re-review 16963
4142019-10-17T19:07:16 <fanquake> I'm not sure there's too much else to discuss high-prio wise other than hopefully people are doing some rc1 testing
4152019-10-17T19:07:18 <promag> but it's meant to fix #17112
4162019-10-17T19:07:20 <gribble> https://github.com/bitcoin/bitcoin/issues/17112 | v0.19.0rc1 GUI repeatedly not responding · Issue #17112 · bitcoin/bitcoin · GitHub
4172019-10-17T19:07:34 <fanquake> Maybe jump into the taproot discussion?
4182019-10-17T19:07:49 <wumpus> promag: that's just too deep a rabbit hole to fix before the release, is it really a reversion in 0.19?
4192019-10-17T19:08:09 <promag> yes
4202019-10-17T19:08:16 <wumpus> where did it happen then?
4212019-10-17T19:08:32 <promag> see https://github.com/bitcoin/bitcoin/issues/17112#issuecomment-541659632
4222019-10-17T19:09:18 <wumpus> ok
4232019-10-17T19:09:35 <wumpus> I still think adding the GUI async stuff last minute is risky
4242019-10-17T19:09:59 <sipa> is there a simpler way to fix the issue itself?
4252019-10-17T19:10:00 <promag> well it's still a HP decision
4262019-10-17T19:10:16 <sipa> harry potter? health points? hewlett-packard?
4272019-10-17T19:10:17 <wumpus> I mean it's the obvious thing to do long term but between rcs?
4282019-10-17T19:10:31 <promag> heh, high prio
4292019-10-17T19:10:42 <sipa> oh lol, sorry, that should have been obvious :)
4302019-10-17T19:11:18 <promag> wumpus: it's fine if we postpone the that change, but let's decide that then :p
4312019-10-17T19:11:36 <aj> gui hangs would cause a lot of user complaints though?
4322019-10-17T19:11:55 <wumpus> yes, but we've always have lots of GUI hangs during initial sync
4332019-10-17T19:12:07 <jonasschnelli> Yes. This has been there for a long time
4342019-10-17T19:12:16 <wumpus> this lock just makes it slightly worse I guess
4352019-10-17T19:12:25 <jonasschnelli> No need for risky fixes in rc-timeframe
4362019-10-17T19:12:28 <sipa> if it's a visible regression it seems reasonable to fix it, but is it possible to just say undo the change that caused it rather than fixing the root issue?
4372019-10-17T19:12:36 <jonasschnelli> Better do proper fixes in 0.20
4382019-10-17T19:12:36 <wumpus> but this is always been a problem and I don't think we're going to solve it for 0.19.0
4392019-10-17T19:12:45 <wumpus> can we fix it by reverting something instead?
4402019-10-17T19:12:46 <promag> Jackielove4u: tested that PR in win/linux/macos and compared to 0.18
4412019-10-17T19:12:51 <wumpus> (on the 0.19 branch I mean)
4422019-10-17T19:12:54 <promag> 0.19rc is really bad in that regards
4432019-10-17T19:12:54 <wumpus> instead of adding more code
4442019-10-17T19:12:59 <jonasschnelli> Its not an easy fix
4452019-10-17T19:13:02 <jonasschnelli> It requires conceptual changes
4462019-10-17T19:13:17 <wumpus> no, it's not an easy fix, it's changing things in a very differnt place than where the problem was introduced
4472019-10-17T19:13:18 <sipa> jonasschnelli: well there was a specific PR that caused it, or at least worsened it
4482019-10-17T19:13:24 *** captjakk has quit IRC
4492019-10-17T19:13:30 <promag> yeah revert is another option I guess, MarcoFalke_?
4502019-10-17T19:13:35 <sipa> i'd like to know if we can revert that PR instead
4512019-10-17T19:13:38 <wumpus> so this basically means we're delaying 0.19.0 indefnintely
4522019-10-17T19:13:40 <jonasschnelli> sipa: maybe a part of it. But GUI unresponsivenes was always an issue
4532019-10-17T19:13:41 <wumpus> until the GUI is async
4542019-10-17T19:13:51 *** arubi has joined #bitcoin-core-dev
4552019-10-17T19:13:54 <jonasschnelli> The GUI was not created to be async
4562019-10-17T19:13:56 <sipa> jonasschnelli: i'm very much aware; but i'm not talking about fixing the root issue, only the regression
4572019-10-17T19:13:57 <wumpus> which is not soemthing I can get behind, sorry
4582019-10-17T19:14:08 <promag> BTW, the same approach is already used in WalletController
4592019-10-17T19:14:56 <jonasschnelli> sipa: sure. If we can fix the regression in a sane way we may want it in 0.19. But unclear of 17120 fixes that
4602019-10-17T19:15:01 *** mdunnio has quit IRC
4612019-10-17T19:15:11 <jonasschnelli> s/of/if
4622019-10-17T19:15:50 <sipa> jonasschnelli: i'm literally suggesting reverting the PR that caused it, nothing more
4632019-10-17T19:16:03 <fanquake> so revert #14193 ?
4642019-10-17T19:16:07 <wumpus> that would be ok with me
4652019-10-17T19:16:07 <gribble> https://github.com/bitcoin/bitcoin/issues/14193 | validation: Add missing mempool locks by MarcoFalke · Pull Request #14193 · bitcoin/bitcoin · GitHub
4662019-10-17T19:16:14 *** rockhouse has quit IRC
4672019-10-17T19:16:14 *** victorSN has quit IRC
4682019-10-17T19:16:28 <valwal> hi
4692019-10-17T19:16:35 <promag> ok, I'll revert it in 0.19 and see how it goes
4702019-10-17T19:16:37 *** rockhouse has joined #bitcoin-core-dev
4712019-10-17T19:16:46 <fanquake> Does that not mean we are back with whatever problems that was meant to fix?
4722019-10-17T19:16:51 <wumpus> what we're arguing against is making changes to GUI asynchronicity before the 0.19.0 release, I think if it's possible to revert the locking change that caused it in the first place that's a more direct and safer option
4732019-10-17T19:17:01 <jonasschnelli> Yes
4742019-10-17T19:17:13 *** victorSN has joined #bitcoin-core-dev
4752019-10-17T19:17:26 <wumpus> but #17135 adds an extra thread, that's not a trivial fix
4762019-10-17T19:17:28 *** mdunnio has joined #bitcoin-core-dev
4772019-10-17T19:17:28 <gribble> https://github.com/bitcoin/bitcoin/issues/17135 | gui: Make polling in ClientModel asynchronous by promag · Pull Request #17135 · bitcoin/bitcoin · GitHub
4782019-10-17T19:17:40 <wumpus> all we know it might make locking issues worse somewhere
4792019-10-17T19:17:41 <jonasschnelli> Reverting #14193 (merged in july, invasive) may be not super easy
4802019-10-17T19:17:44 <gribble> https://github.com/bitcoin/bitcoin/issues/14193 | validation: Add missing mempool locks by MarcoFalke · Pull Request #14193 · bitcoin/bitcoin · GitHub
4812019-10-17T19:17:47 <fanquake> MarcoFalke: Had you seen inconsistent mempool reads prior to 14193?
4822019-10-17T19:18:22 *** ajonas has joined #bitcoin-core-dev
4832019-10-17T19:18:52 <wumpus> which is okay for a release schedule for 0.20.0 where there's a long time to go before the actual release, but not something to do last minute
4842019-10-17T19:19:15 <promag> I'll just submit the revert commit to 0.19, ask for gitian build and let's see how testing goes
4852019-10-17T19:19:23 <wumpus> promag: thanks!
4862019-10-17T19:19:40 <jonasschnelli> promag: nice!
4872019-10-17T19:19:45 <achow101> could just add a known issue to the release notes and tell people to not mess around in the gui during IBD?
4882019-10-17T19:20:04 <wumpus> achow101: that would be the fallback then, yes
4892019-10-17T19:20:18 <promag> achow101: I think it's not just ibd - not sure
4902019-10-17T19:20:30 <achow101> i would be somewhat surprised if people were actually doing things in the gui during ibd
4912019-10-17T19:21:01 <jonasschnelli> achow101: I guess the UX stopper is, if someone wants to get an address or so while he is syncing the last 2-3 days
4922019-10-17T19:21:11 <wumpus> not only IBD but also when you catch up after having not run it for a while
4932019-10-17T19:21:13 <jonasschnelli> (laptop users, etc.)
4942019-10-17T19:21:21 <wumpus> that's usually the most annoying time for it to happen
4952019-10-17T19:21:26 <jonasschnelli> indeed
4962019-10-17T19:21:29 <wumpus> espeiclaly when you want to send a transaction quickly
4972019-10-17T19:21:31 <promag> the problem is more evident in windows because windows show that app is not responding that can cause some frustration
4982019-10-17T19:21:36 <sipa> #17135 does not look crazy, and may be worth considered... but my preference is reverting
4992019-10-17T19:21:38 <gribble> https://github.com/bitcoin/bitcoin/issues/17135 | gui: Make polling in ClientModel asynchronous by promag · Pull Request #17135 · bitcoin/bitcoin · GitHub
5002019-10-17T19:21:44 <wumpus> but anyhow this is not new, and can't be solved before 0.19.0
5012019-10-17T19:22:07 <wumpus> sipa: it's not crazy but it does add a new thread
5022019-10-17T19:22:14 <jonasschnelli> I tested 17135 a bit and I still had freezes. It's better but not solved.
5032019-10-17T19:22:23 <wumpus> I think that's a big change between rcs
5042019-10-17T19:22:28 <sipa> wumpus: agree it's a big change to do at this stage
5052019-10-17T19:22:47 <jonasschnelli> Lets aim for the mempool locks revert and add more fixes in 0.20
5062019-10-17T19:22:54 <promag> jonasschnelli: I'd love to know more about that :D
5072019-10-17T19:22:56 <wumpus> and... it's annoying but not a crash issue
5082019-10-17T19:23:20 <achow101> would reverting the locks cause other problems?
5092019-10-17T19:23:21 <promag> wumpus: yeah but people can force kill upon these hangs
5102019-10-17T19:23:23 <jonasschnelli> promag: yeah. Currently setting up a test env to better reproduce those locks
5112019-10-17T19:23:25 <achow101> I guess it wouldn't really be a regression..
5122019-10-17T19:23:59 * jonasschnelli wishes the GUI would just work via RPC
5132019-10-17T19:24:06 <warren> deadlock can happen in headless bitcoind?
5142019-10-17T19:24:11 *** real_or_random has quit IRC
5152019-10-17T19:24:24 <sipa> warren: this discussion is about Qt GUI only
5162019-10-17T19:24:28 <warren> ok thx
5172019-10-17T19:24:30 <promag> next topic?
5182019-10-17T19:24:50 <fanquake> cc moneyball
5192019-10-17T19:24:55 <moneyball> Hi
5202019-10-17T19:24:56 *** mryandao has quit IRC
5212019-10-17T19:24:59 *** mryandao_ has joined #bitcoin-core-dev
5222019-10-17T19:25:14 <jnewbery> MarcoFalke has been responding but his messages aren't getting through
5232019-10-17T19:25:16 <wumpus> #topic Taproot proposal (moneyball)
5242019-10-17T19:25:36 <moneyball> aj, harding, and i have been discussing organizing a review of the schnorr/taproot/tapscript proposals
5252019-10-17T19:25:37 <wumpus> jnewbery: oh no :( is he logged in to nickserv
5262019-10-17T19:25:42 <moneyball> our thinking is here https://docs.google.com/document/d/1G48-yhZMLLMZW68Bq59h_FBi__pwFKoWKF1D385I38Y/edit#
5272019-10-17T19:26:00 <moneyball> it would be a 7 week series ending by end of year
5282019-10-17T19:26:07 <promag> jnewbery: MarcoFalke_ been there too :(
5292019-10-17T19:26:46 <wumpus> it looks like he isn't logged in-- you can't post here in that case, and worse, you don't really get feedback--I had the same problem some meetings ago
5302019-10-17T19:26:47 <moneyball> i raise it here because (a) create awareness (b) solicit feedback on the idea (c) solicit ideas for how to invite high quality broad reviewers
5312019-10-17T19:27:13 <moneyball> i'm thinking we will communicate this on bitcoin-dev, lightning-dev, optech newsletters + slack to member companies
5322019-10-17T19:27:35 *** davterra has quit IRC
5332019-10-17T19:28:26 <sipa> sounds like a great idea to get feedback
5342019-10-17T19:28:30 <moneyball> the goal of this is to generate high quality feedback, give us further confidence in the proposal, give the Core project confidence to proceed with code review and QA of the existing PR, and to improve the decentralization / broader participation of review of the proposal
5352019-10-17T19:28:43 <sipa> there is no PR
5362019-10-17T19:28:48 *** MarcoFalke_ has quit IRC
5372019-10-17T19:28:50 *** davterra has joined #bitcoin-core-dev
5382019-10-17T19:28:52 <moneyball> sorry, branch
5392019-10-17T19:29:02 <aj> to proceed with getting an implementation that we can PR :)
5402019-10-17T19:29:04 *** MarcoFalke has joined #bitcoin-core-dev
5412019-10-17T19:29:18 <sipa> yeah
5422019-10-17T19:29:40 <MarcoFalke> test
5432019-10-17T19:29:42 <jnewbery> (b) I think it's a good idea
5442019-10-17T19:29:47 <sipa> MarcoFalke: reading you loud and clear
5452019-10-17T19:29:47 <aj> MarcoFalke: success
5462019-10-17T19:29:53 <MarcoFalke> I was wondering why no one responeded to me for days
5472019-10-17T19:29:57 <jonasschnelli> heh
5482019-10-17T19:29:59 <sipa> oww
5492019-10-17T19:30:19 <fanquake> moneyball sounds good. I see some australian friendly time slots as well
5502019-10-17T19:30:19 <jnewbery> welcome back, MarcoFalke
5512019-10-17T19:30:21 <wumpus> oh crap
5522019-10-17T19:30:36 <promag> lol
5532019-10-17T19:30:57 <achow101> moneyball: is the idea to kind of do it in the style of the pr review club?
5542019-10-17T19:31:02 <wumpus> kafkaIRC
5552019-10-17T19:31:28 <sipa> wumpus: IRC where only some people see what certain others are saying... sounds like twitter to me
5562019-10-17T19:31:38 <moneyball> achow101: aj has proposed a small group study structure then come together as a larger group once a week via IRC for Q&A (see the doc for details)
5572019-10-17T19:31:49 <MarcoFalke> I think the issue was the znc put an underscore behind my name and bitcoin-core-dev only allows logged in users to post?
5582019-10-17T19:31:54 <MarcoFalke> (sorry ot)
5592019-10-17T19:31:56 <moneyball> it will definitely require diligence and commitment, but i think it is necessary for a high quality review of the proposal
5602019-10-17T19:31:59 <wumpus> sipa: yes it seems the same kind of shadowban idea
5612019-10-17T19:33:08 <wumpus> MarcoFalke: yes, it allows only logged in users to post, though you can log in while having an alternative nick (by using /msg nickserv login <registered_user> <pass> AFAIK instead of just /... login <PASS>)
5622019-10-17T19:33:15 <moneyball> "once a week" = twice a week at different times to provide good global coverage
5632019-10-17T19:33:39 <wumpus> MarcoFalke: the crazy thing is that freenode doesn't seem to send an error message anymore in that case
5642019-10-17T19:33:57 <sipa> 7 weeks seems like a lot, but i also agree it's not something that can be done in 1-2 hours
5652019-10-17T19:33:59 <jeremyrubin> i think it would make sense to talk about deployment/acceptance criteria
5662019-10-17T19:34:47 <wumpus> MarcoFalke: the reason for "only registered users can post" is for some spam avoidance, it used to be really bad at some point, maybe it's no longer necessary I don't know
5672019-10-17T19:34:48 <sipa> jeremyrubin: imho that's an entirely different discussion; we first need to know if the ecosystem is on board including all the details it entails (to the extent they care), then we can talk about activation
5682019-10-17T19:35:06 <warren> MarcoFalke: strongly recommend figuring out the nickserv SASL or TLS cert authentication, then you'll never connect without login
5692019-10-17T19:35:32 <wumpus> warren: somehow it did happen to me once
5702019-10-17T19:35:44 <achow101> moneyball: who are the participants? open to public?
5712019-10-17T19:35:47 <warren> wumpus: yeah server splits or other weird conditions
5722019-10-17T19:35:57 <jeremyrubin> sipa: thats what i said kinda
5732019-10-17T19:36:34 <jeremyrubin> "we first need to know if the ecosystem is on board" == acceptance criteria
5742019-10-17T19:37:09 *** mdunnio has quit IRC
5752019-10-17T19:37:17 <jeremyrubin> knowing what that means, i agree, is a separate discussion
5762019-10-17T19:37:31 *** mdunnio has joined #bitcoin-core-dev
5772019-10-17T19:37:50 <moneyball> achow101: open to public. some level of moderation may be needed just to keep folks on track and avoid trolls. i mention above the proposed method of outreach. if others have ideas let me know.
5782019-10-17T19:37:53 *** real_or_random has joined #bitcoin-core-dev
5792019-10-17T19:38:08 <jeremyrubin> but an impt one for taproot and other stuff too, separate from the actual instance
5802019-10-17T19:38:25 <aj> sipa: i don't think shrinking it below 5 "sessions" works, and multiple sessions a week seems a bit intense, 7 weeks seems the max before hitting xmas/new year, and 5 + 2 weeks padding seems okayish
5812019-10-17T19:38:42 <sipa> jeremyrubin: i have no idea what you're trying to say
5822019-10-17T19:38:50 <sipa> aj: ok
5832019-10-17T19:39:01 <jeremyrubin> ok
5842019-10-17T19:39:11 <jeremyrubin> can chat out of band later
5852019-10-17T19:39:17 <sipa> ok
5862019-10-17T19:40:19 <moneyball> also feel free to comment directly in the doc if you have ideas or concerns
5872019-10-17T19:40:51 <moneyball> thanks everyone! hope to see many of you participate. it is a fairly large commitment but as aj points out in the doc:
5882019-10-17T19:40:55 <moneyball> https://www.irccloud.com/pastebin/igNUbnnf/
5892019-10-17T19:41:02 <wumpus> thanks!
5902019-10-17T19:41:15 <sipa> sgtm
5912019-10-17T19:43:28 <MarcoFalke> #proposedmeetingtopic address relay and spv clients
5922019-10-17T19:43:35 <gleb> I wanted to mention that in #17163 we're discussion whether we should stop relaying addresses to light clients or just limit relay to the cases where it does not hurt addr propagation.
5932019-10-17T19:43:35 <gleb> It's not clear for us whether SPV should sync their addr database with random peers from the network. Input welcome!
5942019-10-17T19:43:37 <gribble> https://github.com/bitcoin/bitcoin/issues/17163 | p2p: Avoid relaying ADDR messages to SPV clients by naumenkogs · Pull Request #17163 · bitcoin/bitcoin · GitHub
5952019-10-17T19:44:45 <gleb> I guess we tend to "allowing SPV to ask for addresses does not hurt", so the latter, but I'd like to hear more opinions.
5962019-10-17T19:45:00 <MarcoFalke> I guess we switched topics?
5972019-10-17T19:45:05 <MarcoFalke> #topic address relay and spv clients
5982019-10-17T19:46:23 <gleb> To be clear: currently when we get a short ADDR message (less than 10), we choose 1 or 2 peers to relay forward. That's the primary way to announce new nodes in the network. Currently it's possible that we choose SPV which will throw it on the floor, which is unfortunate.
5992019-10-17T19:47:26 <aj> how about just biassing against picking peers for the 1 or 2 to relay for if those peers haven't sent us ADDR messages already, if that makes sense?
6002019-10-17T19:47:36 <achow101> I think it would hurt SPV clients to not receive addr messages
6012019-10-17T19:47:46 <achow101> *for them to not receive addr messages
6022019-10-17T19:48:55 <gleb> I also mentioned above that an explicit service flag is maybe a good idea, to decouple addr-relay from SPV/non-SPV reasoning.
6032019-10-17T19:49:41 <gleb> Or whatever other explicit way you can imagine. aj: Biasing is sort of that, but implicit.
6042019-10-17T19:50:36 <gleb> Anyway, just wanted to mention that this discussion is taking place in #17163. Let's continue there. Thanks.
6052019-10-17T19:50:38 <gribble> https://github.com/bitcoin/bitcoin/issues/17163 | p2p: Avoid relaying ADDR messages to SPV clients by naumenkogs · Pull Request #17163 · bitcoin/bitcoin · GitHub
6062019-10-17T19:50:45 <achow101> gleb: are you certain that spv clients discard addr messages?
6072019-10-17T19:51:22 <MarcoFalke> as mentioned on the pull request, SPV clients should not deal with addr messages. I can only see ways in which they shoot themselves in the foot
6082019-10-17T19:51:30 <wumpus> maybe most current ones do, but it's not a necessary coupling
6092019-10-17T19:51:40 <sipa> MarcoFalke: i don't understand that comment
6102019-10-17T19:51:54 <sipa> and i don't understand what SPV has to do with it
6112019-10-17T19:52:12 <MarcoFalke> Though, there might be a node without NODE_NETWORK set that wants addr messages
6122019-10-17T19:52:13 <wumpus> I don't get why SPV clients couldn't implement full address management instead of blindly trusting DNS seeders
6132019-10-17T19:52:18 <MarcoFalke> So that coupling doesn't make sense
6142019-10-17T19:52:46 <achow101> i don't understand what about spv makes it such that they don't need addrs
6152019-10-17T19:52:49 <wumpus> right
6162019-10-17T19:52:58 <MarcoFalke> wumpus: I doubt implementing address management is trivial
6172019-10-17T19:53:07 <MarcoFalke> See for example feeler connections
6182019-10-17T19:53:08 <wumpus> no one is talking about 'trivial'
6192019-10-17T19:53:17 <sipa> MarcoFalke: i'm sure it's nontrivial, but it's nontrivial for everyone
6202019-10-17T19:53:28 <wumpus> but why couldn't they if they wanted?
6212019-10-17T19:54:02 <wumpus> so the reasoning is 'SPV implementations tend to be trivial, so they won't implement something as complex as addr handling'
6222019-10-17T19:54:04 <sipa> i agree partially with luke-jr that it's reasonable for lightweight clients to instead rely on a trusted server... but not all light clients do that; and within those that do, i think doing actual ip address management is far more reasonable that blindly using dns seeds
6232019-10-17T19:54:14 <wumpus> which more or less makes sense but it's very indirect
6242019-10-17T19:55:00 <warren> The "throwing to the floor" part is concerning but I'm thinking address relay is best effort. It is reasonable to need to connect to multiple/many peers before you get any quality addresses. There is no guaratee that a peer you try first is honest.
6252019-10-17T19:55:12 <BlueMatt> what does wasting a service bit cost? we've got a bunch of 'em :p
6262019-10-17T19:55:28 *** rex4539 has quit IRC
6272019-10-17T19:55:51 <achow101> wumpus: but at the same time, they are probably using some library like bitcoinj that already handles it for them (at least I think bitcoinj uses addrs)
6282019-10-17T19:55:54 <MarcoFalke> would the service bit be for "i want addr messages" or "i send addr messages"
6292019-10-17T19:56:10 <wumpus> achow101: that's another assumption though, based on current software
6302019-10-17T19:56:18 <wumpus> achow101: I"m not sure that should determine the protocol
6312019-10-17T19:56:34 <sipa> i think a service bit makes sense (e.g. explicitly opting out of address relay), but i think that's an independent question of whether we want to bias our own relay away from nodes we assume won't participate in relaying further
6322019-10-17T19:56:47 <gleb> MarcoFalke: Your peer shouldn't care whether you promise to send them something or not
6332019-10-17T19:56:56 <MarcoFalke> I also think it makes sense to make this more explicit with service bits or a new message type
6342019-10-17T19:57:02 <MarcoFalke> Would addrv2 help with that?
6352019-10-17T19:57:22 <wumpus> it could be added to that
6362019-10-17T19:57:31 <dongcarl> addrv2 has a message to indicate that I want addrv2 messages
6372019-10-17T19:57:57 <dongcarl> I'm hearing we want some kind of more complex negotiation?
6382019-10-17T19:58:02 <wumpus> the same mechanism (say, a new message) for requesting addrv2 messages could be used to request *NO* addr messages
6392019-10-17T19:58:22 <MarcoFalke> gleb: It is useful to know whether a peer might not relay addr messages, but still wants them
6402019-10-17T19:58:26 <wumpus> dongcarl: I don't think it would be more complex
6412019-10-17T19:58:38 <wumpus> just a third option (besides addr and addrv2)
6422019-10-17T19:58:50 <gleb> MarcoFalke: yeah, if they want, they should signalize. But whether they send us or not â we don't care.
6432019-10-17T19:58:59 <gleb> Okay, it seems like I change a PR to avoid forwarding ADDR to SPV, but still allow SPV to ask for addresses.
6442019-10-17T19:59:26 <warren> +1
6452019-10-17T19:59:31 <gleb> And then we should expand addrv2 spec for this further change separately.
6462019-10-17T19:59:33 <sipa> that sounds reasonable
6472019-10-17T19:59:38 <achow101> how are you determining a node is spv? no node_network?
6482019-10-17T19:59:51 <gleb> and no node_network_limited.
6492019-10-17T19:59:58 <aj> (we also drop ADDRs on the floor if they're from a node we've set as block-relay-only per #15759)
6502019-10-17T20:00:01 <gribble> https://github.com/bitcoin/bitcoin/issues/15759 | p2p: Add 2 outbound block-relay-only connections by sdaftuar · Pull Request #15759 · bitcoin/bitcoin · GitHub
6512019-10-17T20:00:07 <achow101> that'd affect old pruned nodes tho
6522019-10-17T20:00:24 <wumpus> aj: oh? block relay only also means no addr relay?
6532019-10-17T20:00:27 <gleb> Yeah, but we already don't forward short addr to "block_relay_only" :)
6542019-10-17T20:00:30 <wumpus> aj: I kind of wondered that
6552019-10-17T20:00:40 <BlueMatt> time
6562019-10-17T20:00:49 <aj> wumpus: only for the 2 of 10 outbounds when we do tx's but have a couple of block-relay-only nodes
6572019-10-17T20:01:13 <wumpus> #endmeeting
6582019-10-17T20:01:13 <lightningbot> Meeting ended Thu Oct 17 20:01:13 2019 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
6592019-10-17T20:01:13 <lightningbot> Minutes: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2019/bitcoin-core-dev.2019-10-17-19.00.html
6602019-10-17T20:01:13 <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2019/bitcoin-core-dev.2019-10-17-19.00.txt
6612019-10-17T20:01:13 <lightningbot> Log: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2019/bitcoin-core-dev.2019-10-17-19.00.log.html
6622019-10-17T20:01:22 <aj> gleb: but we might pick a node who's chosen us as block_relay_only to forward addresses to
6632019-10-17T20:01:39 <MarcoFalke> gleb: this ^ for example
6642019-10-17T20:01:46 <achow101> filter by fRelay
6652019-10-17T20:02:26 <gleb> aj: In current implementation we won't pick a node which is set to be block_relay_only.
6662019-10-17T20:02:30 <MarcoFalke> I think we should guess whether a node relays (sends) addr messages based on other (unrelated) service bits or version flags
6672019-10-17T20:02:51 <aj> gleb: block_relay_only reflects our choice, not our peer's choice
6682019-10-17T20:03:14 <aj> or fRelay reflects that, i think; bit long since i've looked at it now
6692019-10-17T20:03:19 <MarcoFalke> gleb: That doesn't mean that in the future there might be a blocks-only-relay-and-addr-relay node
6702019-10-17T20:03:25 <gleb> It should be per-link, non per-direction, otherwise doesn't make sense.
6712019-10-17T20:03:51 <MarcoFalke> s/might/won't/
6722019-10-17T20:03:53 <gleb> Because then transactions will flow through that link, just in one direction :)
6732019-10-17T20:05:00 <aj> gleb: right, but for -blocksonly you want ADDR but not txs to flow, and you don't know if the other guy's selected you as block_relay_only or is doing -blocksonly in general
6742019-10-17T20:05:32 <aj> (i think)
6752019-10-17T20:06:10 <achow101> imo we should do the service bit thing to explicitly ask for or opt out of addr messages. all of the things mentioned don't necessarily exclude needing addrs
6762019-10-17T20:09:43 <gleb> achow101: Before service bit thing happens, I am suggesting to still allow everybody to learn, but just not forward them <10 addr messages.
6772019-10-17T20:15:51 <MarcoFalke> Sure, old Bitcoin Core nodes won't set that service bit, so they should be accomodated for and provided with addr messages
6782019-10-17T20:27:59 <luke-jr> [19:55:54] <MarcoFalke> would the service bit be for "i want addr messages" or "i send addr messages" <-- it doesn't make sense to use service bits for "i want"
6792019-10-17T20:28:18 <luke-jr> that can very easily be done at connection negotiation
6802019-10-17T20:30:39 <meshcollider> Oops forgot the meeting
6812019-10-17T20:35:16 <meshcollider> The taproot thing sounds good to me too
6822019-10-17T20:38:34 *** Guyver2 has quit IRC
6832019-10-17T20:42:10 *** mmgen has quit IRC
6842019-10-17T20:47:21 *** drbrule has quit IRC
6852019-10-17T20:47:41 <luke-jr> moneyball: ACK/HOLD isn't clear. If there's minor changes desired, does that need a HOLDâ :/
6862019-10-17T21:00:01 *** chrissie1 has quit IRC
6872019-10-17T21:03:02 *** captjakk has joined #bitcoin-core-dev
6882019-10-17T21:10:44 <aj> luke-jr: some minor changes shouldn't need a HOLD (like "maybe add a reference to https://..." or "might be clearer if X was described before Y") ; and still want to go through github issues/PRs to actually get changes made. i'm thinking of ACK/HOLD as more like the summaries on the Segwit_support wiki page
6892019-10-17T21:12:05 <aj> luke-jr: (also, a double question-mark character? fancy)
6902019-10-17T21:17:44 *** ski1 has joined #bitcoin-core-dev
6912019-10-17T21:18:05 *** nullptr| has quit IRC
6922019-10-17T21:18:11 <luke-jr> I haven't checked if my review comments were addressed yet; I wonder if I should do that in advance, or wait for the meetings
6932019-10-17T21:20:04 *** nullptr| has joined #bitcoin-core-dev
6942019-10-17T21:20:31 <sipa> luke-jr: i never understood your comment about avoiding space savings
6952019-10-17T21:21:22 <sipa> do you just mean to clarify whether it's about bandwidth or other kinds of savings?
6962019-10-17T21:21:46 <luke-jr> sipa: I mean weight shouldn't be gamed.
6972019-10-17T21:22:16 <luke-jr> if a different weight is desirable, the algorithm for weight can be proposed adjusted, but just omitting bytes to manipulate weight isn't a good way
6982019-10-17T21:22:45 <aj> s/omitting/adding/ ?
6992019-10-17T21:23:02 <luke-jr> aj: IIRC it was omissions in the earlier draft
7002019-10-17T21:23:13 <sipa> ?
7012019-10-17T21:23:32 <sipa> weight = base_size + 3 * witness_size; nothing in taproot ever did anything else
7022019-10-17T21:23:36 <luke-jr> I'll need to go re-read, sec
7032019-10-17T21:24:54 <aj> there's "Instead, the taproot annex can be used to add weight to the witness ..." in bip-tapscript; otherwise i've no idea
7042019-10-17T21:25:13 <sipa> one idea for the "annex" (but not currently proposed) is that it could be used to add a "extra weight" marker, which would then translate to an additional allowance for example for hypothetical future opcodes that have a much higher cpu cost per byte than existing things
7052019-10-17T21:25:49 <sipa> fwiw, it seems that right now, blocks full of sha256, blocks full of stack operations, or blocks full of signature checks remarkably are all very similar in their cpu cost per byte for verifiers
7062019-10-17T21:26:40 <luke-jr> sipa: basically, my point is that p2pkh, p2wpkh, and the new taproot equivalent with the same CPU/IO/etc costs should have the same weight, not be tweaked in special-casing ways to reduce it
7072019-10-17T21:27:23 <sipa> i don't understand
7082019-10-17T21:27:33 <sipa> we're trying to use block space as efficiently as possible
7092019-10-17T21:27:48 <sipa> without increasing cpu cost per byte
7102019-10-17T21:28:31 <sipa> (i'd argue that if it becomes possible to do the same thing with less bytes, but significantly increase how burdensome it is to validation, that would be a bad thing, but i don't think that's the case)
7112019-10-17T21:29:37 <luke-jr> I don't see how that isn't self-contradicting
7122019-10-17T21:29:37 <aj> iirc it costs slightly more to send to a taproot address than p2wpkh (because it's a 32B point not a 20B hash) and corresponding less to spend via taproot key path (64B sig, versus 33B key reveal and 72B DER signature), but they average out almost the same in weight
7132019-10-17T21:29:57 <luke-jr> what does it mean to "increase efficiency" of block space use, without increasing CPU cost per byte?
7142019-10-17T21:30:47 <sipa> luke-jr: if i can perform a payment on chain with fewer bytes, but also reduce the CPU cost needed to verify it, is it justified that the weight also goes down?
7152019-10-17T21:30:49 <aj> batch verification decreases the cpu cost per signature, so if that were the only factor more sigs per byte could keep cpu cost stable
7162019-10-17T21:30:59 <luke-jr> I seem to recall special-casing where something is omitted if it's a particular value.. but I'm having trouble finding it now
7172019-10-17T21:31:19 <luke-jr> sipa: so Taproot in fact uses less CPU time?
7182019-10-17T21:31:23 <luke-jr> I would think it uses more
7192019-10-17T21:31:32 <sipa> luke-jr: if batch validation is implemented, significantly less
7202019-10-17T21:31:54 <luke-jr> isn't that just per transaction, though? so 1 input wouldn't benefit?
7212019-10-17T21:32:06 <sipa> you can batch all signatures in a block
7222019-10-17T21:32:10 <sipa> or even more
7232019-10-17T21:32:44 <luke-jr> hmm
7242019-10-17T21:33:33 <sipa> note that batch validation is not the same as aggregation; there is still a signature on chain per logical signature to check; you just have a faster algorithm that can tell you whether all of them are valid or not (which won't tell you which ones are invalid if it fails, but in block validation that's not relevant)
7252019-10-17T21:33:41 <aj> luke-jr: SIGHASH_ALL signatures are 64 bytes, versus others being 65 bytes; that's the only case like that that comes to mind
7262019-10-17T21:33:50 <luke-jr> can we fix it so segwit/taproot are on the same weight scale as pre-segwit? or would that need to be another BIP? because right now, the weights are too low
7272019-10-17T21:34:11 <luke-jr> (this is admittedly a different issue beyond merely not making it worse)
7282019-10-17T21:34:29 <luke-jr> aj: that sounds like what I remember; why shouldn't they all be 65?
7292019-10-17T21:34:33 <sipa> i don't believe that belongs in the same bip
7302019-10-17T21:35:03 <luke-jr> the code would likely be simpler to have 65 bytes for everything
7312019-10-17T21:36:13 <luke-jr> and unless I'm mistaken, SIGHASH_ALL vs other SIGHASH don't change actual resource costs
7322019-10-17T21:36:17 <aj> sighash_all is slightly easier to calculate (hash is the same for all sighash_all sigs in a tx)
7332019-10-17T21:36:53 <aj> err, in an input, except for codesep use
7342019-10-17T21:36:54 <sipa> i think it would save maybe 2 lines of code here: https://github.com/sipa/bitcoin/blob/taproot/src/script/interpreter.cpp#L1527L1533
7352019-10-17T21:37:34 <sipa> i think there is a fungibility benefit to encouraging a default sighash
7362019-10-17T21:38:41 <luke-jr> 4 lines
7372019-10-17T21:38:45 <luke-jr> if (sig.size() != 65) return false;
7382019-10-17T21:38:46 <sipa> ok!
7392019-10-17T21:38:47 <luke-jr> uint8_t hashtype = sig.back();
7402019-10-17T21:38:48 <luke-jr> sig.pop_back();
7412019-10-17T21:40:27 <luke-jr> I think the fungibility thing is stretching it, but aj may have a point
7422019-10-17T21:40:39 *** arik_ has joined #bitcoin-core-dev
7432019-10-17T21:40:49 <luke-jr> sipa: did you understand/address my other comments?
7442019-10-17T21:43:45 <sipa> the non-overridable branches thing was answered i think in the thread, and is also in the document; you can use a point without known DL as internal key, and the result is something that can provably only be spent using scripts
7452019-10-17T21:45:05 <sipa> salting branches shouldn't be needed if you don't reuse pubkeys
7462019-10-17T21:46:00 <luke-jr> what if a branch doesn't have any keys?
7472019-10-17T21:46:26 <aj> you can pair it with a branch that's "OP_RETURN <salt>"
7482019-10-17T21:46:30 <luke-jr> anyone-can-spend is apparently useful to troll the IRS :P
7492019-10-17T21:46:41 <luke-jr> aj: ah, nice idea
7502019-10-17T21:48:45 *** bitcoin-git has joined #bitcoin-core-dev
7512019-10-17T21:48:45 <bitcoin-git> [bitcoin] ch4ot1c closed pull request #16797: scripts: Add convenience script for committing scripted-diffs from a file (master...scripts/commit-script) https://github.com/bitcoin/bitcoin/pull/16797
7522019-10-17T21:48:46 *** bitcoin-git has left #bitcoin-core-dev
7532019-10-17T21:58:53 *** marcoagner has quit IRC
7542019-10-17T22:18:40 *** Zenton has quit IRC
7552019-10-17T22:22:09 *** arik_ has quit IRC
7562019-10-17T22:24:44 *** arik_ has joined #bitcoin-core-dev
7572019-10-17T22:47:36 *** mdunnio has quit IRC
7582019-10-17T22:48:59 *** mdunnio has joined #bitcoin-core-dev
7592019-10-17T22:50:12 *** shesek` has quit IRC
7602019-10-17T22:53:49 *** jkczyz has quit IRC
7612019-10-17T22:55:43 *** mdunnio has quit IRC
7622019-10-17T22:57:45 *** mdunnio has joined #bitcoin-core-dev
7632019-10-17T23:07:59 *** bitcoin-git has joined #bitcoin-core-dev
7642019-10-17T23:07:59 <bitcoin-git> [bitcoin] promag opened pull request #17182: 0.19: Revert 14193 to fix 17112 (0.19...2019-10-revert-14193-fix-17112) https://github.com/bitcoin/bitcoin/pull/17182
7652019-10-17T23:08:00 *** bitcoin-git has left #bitcoin-core-dev
7662019-10-17T23:08:17 *** willcl_ark has quit IRC
7672019-10-17T23:13:51 *** jkczyz has joined #bitcoin-core-dev
7682019-10-17T23:14:04 *** astro has quit IRC
7692019-10-17T23:15:40 *** astro has joined #bitcoin-core-dev
7702019-10-17T23:24:02 *** belcher has quit IRC
7712019-10-17T23:33:45 <promag> ^ 14963, #16443 and probably others are making the revert hard
7722019-10-17T23:33:48 <gribble> https://github.com/bitcoin/bitcoin/issues/16443 | refactor: have CCoins* data managed under CChainState by jamesob · Pull Request #16443 · bitcoin/bitcoin · GitHub
7732019-10-17T23:34:22 <promag> lots of annotations were merged
7742019-10-17T23:34:40 *** belcher has joined #bitcoin-core-dev
7752019-10-17T23:35:38 *** mdunnio has quit IRC
7762019-10-17T23:37:02 *** AaronvanW has quit IRC
7772019-10-17T23:47:44 *** ajonas has quit IRC
7782019-10-17T23:51:17 *** Highway61 has quit IRC