12020-05-08T00:00:02 *** Guest44912 has quit IRC
22020-05-08T00:02:29 *** promag_ has quit IRC
32020-05-08T00:10:54 *** jarthur_ has joined #bitcoin-core-dev
42020-05-08T00:11:22 *** jonatack_ has quit IRC
52020-05-08T00:11:55 *** jonatack has joined #bitcoin-core-dev
62020-05-08T00:12:24 *** MrSquanchee has quit IRC
72020-05-08T00:12:26 *** go11111111111 has joined #bitcoin-core-dev
82020-05-08T00:14:18 *** jarthur has quit IRC
92020-05-08T00:15:10 *** go121212 has quit IRC
102020-05-08T00:15:31 *** jarthur has joined #bitcoin-core-dev
112020-05-08T00:19:58 *** promag_ has joined #bitcoin-core-dev
122020-05-08T00:22:17 *** Snuupy1 has joined #bitcoin-core-dev
132020-05-08T00:24:14 <midnight> sipa: hi! graphs..?
142020-05-08T00:24:19 <midnight> :-)
152020-05-08T00:24:24 *** promag_ has quit IRC
162020-05-08T00:28:23 <sipa> midnight: what's wrong with them?
172020-05-08T00:28:54 *** AaronvanW has quit IRC
182020-05-08T00:34:13 *** theStack has quit IRC
192020-05-08T00:35:55 *** mol_ has joined #bitcoin-core-dev
202020-05-08T00:36:04 *** mol has quit IRC
212020-05-08T00:40:27 *** sipsorcery has quit IRC
222020-05-08T00:40:49 *** sipsorcery has joined #bitcoin-core-dev
232020-05-08T00:43:30 *** jarthur_ has joined #bitcoin-core-dev
242020-05-08T00:46:05 *** sipsorcery has quit IRC
252020-05-08T00:46:36 *** jarthur has quit IRC
262020-05-08T00:58:20 *** jonatack has quit IRC
272020-05-08T01:06:54 *** sipsorcery has joined #bitcoin-core-dev
282020-05-08T01:29:10 *** sipsorcery has quit IRC
292020-05-08T01:31:01 *** bitcoin-git has joined #bitcoin-core-dev
302020-05-08T01:31:02 <bitcoin-git> [bitcoin] fanquake opened pull request #18910: p2p: add MAX_FEELER_CONNECTIONS constant (master...add_max_feeler_connections) https://github.com/bitcoin/bitcoin/pull/18910
312020-05-08T01:31:03 *** bitcoin-git has left #bitcoin-core-dev
322020-05-08T01:37:03 *** jarthur_ has quit IRC
332020-05-08T01:40:54 *** Highway61 has quit IRC
342020-05-08T02:25:28 *** mol_ has quit IRC
352020-05-08T02:50:08 *** mol has joined #bitcoin-core-dev
362020-05-08T02:52:08 *** surja795 has quit IRC
372020-05-08T02:52:29 *** surja795 has joined #bitcoin-core-dev
382020-05-08T03:00:01 *** Snuupy1 has quit IRC
392020-05-08T03:21:56 *** nhandler1 has joined #bitcoin-core-dev
402020-05-08T03:24:18 *** surja795 has quit IRC
412020-05-08T03:30:49 *** mol has quit IRC
422020-05-08T03:35:22 *** proofofkeags has quit IRC
432020-05-08T03:36:17 *** DeanGuss has joined #bitcoin-core-dev
442020-05-08T04:05:31 *** justanotheruser has quit IRC
452020-05-08T04:09:54 *** justanotheruser has joined #bitcoin-core-dev
462020-05-08T04:14:39 *** proofofkeags has joined #bitcoin-core-dev
472020-05-08T04:19:17 *** proofofkeags has quit IRC
482020-05-08T04:19:53 *** vasild_ has joined #bitcoin-core-dev
492020-05-08T04:22:43 *** vasild has quit IRC
502020-05-08T04:22:44 *** vasild_ is now known as vasild
512020-05-08T04:25:11 *** promag_ has joined #bitcoin-core-dev
522020-05-08T04:30:21 *** promag_ has quit IRC
532020-05-08T04:43:48 *** dfmb__ has joined #bitcoin-core-dev
542020-05-08T04:45:33 *** proofofkeags has joined #bitcoin-core-dev
552020-05-08T04:47:44 *** dfmb___ has joined #bitcoin-core-dev
562020-05-08T04:48:17 *** dfmb___ has joined #bitcoin-core-dev
572020-05-08T04:48:32 *** dfmb_ has joined #bitcoin-core-dev
582020-05-08T04:49:56 *** proofofkeags has quit IRC
592020-05-08T04:50:43 *** dfmb__ has quit IRC
602020-05-08T04:52:42 *** DeanGuss has quit IRC
612020-05-08T05:06:30 *** DeanGuss has joined #bitcoin-core-dev
622020-05-08T05:16:11 *** Talkless has joined #bitcoin-core-dev
632020-05-08T05:20:48 *** bitcoin-git has joined #bitcoin-core-dev
642020-05-08T05:20:49 <bitcoin-git> [bitcoin] practicalswift opened pull request #18912: ci: Run fuzz testing test cases (bitcoin-core/qa-assets) under valgrind to catch memory errors (master...fuzzers-under-valgrind) https://github.com/bitcoin/bitcoin/pull/18912
652020-05-08T05:20:50 *** bitcoin-git has left #bitcoin-core-dev
662020-05-08T05:29:34 *** Talkless has quit IRC
672020-05-08T05:30:23 *** Talkless has joined #bitcoin-core-dev
682020-05-08T05:32:36 *** mol has joined #bitcoin-core-dev
692020-05-08T05:59:34 *** Highway61 has joined #bitcoin-core-dev
702020-05-08T06:00:01 *** nhandler1 has quit IRC
712020-05-08T06:12:16 *** brakmic has joined #bitcoin-core-dev
722020-05-08T06:18:17 *** Zao_ has joined #bitcoin-core-dev
732020-05-08T06:26:35 *** mol_ has joined #bitcoin-core-dev
742020-05-08T06:29:41 *** mol has quit IRC
752020-05-08T06:30:03 *** jb55 has quit IRC
762020-05-08T06:32:01 *** mol_ has quit IRC
772020-05-08T06:34:18 *** mol has joined #bitcoin-core-dev
782020-05-08T06:34:19 *** jb55 has joined #bitcoin-core-dev
792020-05-08T06:47:03 *** mol_ has joined #bitcoin-core-dev
802020-05-08T06:50:19 *** mol has quit IRC
812020-05-08T07:13:00 *** molz_ has joined #bitcoin-core-dev
822020-05-08T07:16:54 *** mol_ has quit IRC
832020-05-08T07:40:00 *** jonatack has joined #bitcoin-core-dev
842020-05-08T07:54:00 *** ghost43 has quit IRC
852020-05-08T07:54:26 *** cncr04s has quit IRC
862020-05-08T07:54:58 *** ghost43 has joined #bitcoin-core-dev
872020-05-08T07:56:43 *** cncr04s has joined #bitcoin-core-dev
882020-05-08T07:58:39 <jonasschnelli> jonatack really strange the fuzz crash you get with the v2 deserializer
892020-05-08T07:59:24 <jonasschnelli> GetMessage() sets m_raw_message_size to header_size + msg.m_message_size,... which a few lines later gets tested through assert(msg.m_raw_message_size == header_size + msg.m_message_size); (which fails)
902020-05-08T07:59:26 *** brakmic_ has joined #bitcoin-core-dev
912020-05-08T08:00:50 *** brakmic__ has joined #bitcoin-core-dev
922020-05-08T08:02:31 *** brakmic has quit IRC
932020-05-08T08:02:33 *** brakmi___ has joined #bitcoin-core-dev
942020-05-08T08:03:34 *** brakmic_ has quit IRC
952020-05-08T08:06:13 *** brakmic__ has quit IRC
962020-05-08T08:09:47 *** qubenix has quit IRC
972020-05-08T08:10:15 *** marcoagner has joined #bitcoin-core-dev
982020-05-08T08:10:21 *** qubenix has joined #bitcoin-core-dev
992020-05-08T08:11:17 *** brakmic has joined #bitcoin-core-dev
1002020-05-08T08:11:18 *** vasild has quit IRC
1012020-05-08T08:11:40 <jb55> smells like memory corruption
1022020-05-08T08:11:59 <jonasschnelli> jonatack: found the issue revealed by the fuzzer
1032020-05-08T08:15:08 *** brakmi___ has quit IRC
1042020-05-08T08:20:03 *** brakmic_ has joined #bitcoin-core-dev
1052020-05-08T08:23:43 *** brakmic has quit IRC
1062020-05-08T08:25:05 *** emilengler has joined #bitcoin-core-dev
1072020-05-08T08:27:03 *** vasild has joined #bitcoin-core-dev
1082020-05-08T08:50:40 *** promag_ has joined #bitcoin-core-dev
1092020-05-08T08:51:50 *** michaelfolkson has joined #bitcoin-core-dev
1102020-05-08T08:54:08 <jonasschnelli> sipa: do you think it is a problem to not MAC the length in the V2 BIP324 protocol? See comment: https://gist.github.com/jonasschnelli/c530ea8421b8d0e80c51486325587c52#gistcomment-3295536
1112020-05-08T08:56:41 *** brakmic has joined #bitcoin-core-dev
1122020-05-08T08:56:46 *** michaelfolkson has quit IRC
1132020-05-08T08:58:01 *** brakmic__ has joined #bitcoin-core-dev
1142020-05-08T08:58:06 *** brakmic_ has quit IRC
1152020-05-08T09:00:02 *** Zao_ has quit IRC
1162020-05-08T09:01:02 *** brakmic has quit IRC
1172020-05-08T09:10:41 *** promag_ has quit IRC
1182020-05-08T09:12:14 *** dfmb___ has quit IRC
1192020-05-08T09:14:37 *** promag_ has joined #bitcoin-core-dev
1202020-05-08T09:22:02 *** maop has joined #bitcoin-core-dev
1212020-05-08T09:24:36 *** surja795 has joined #bitcoin-core-dev
1222020-05-08T09:26:09 *** promag_ has quit IRC
1232020-05-08T09:30:46 *** theStack has joined #bitcoin-core-dev
1242020-05-08T09:31:46 *** jorijn has quit IRC
1252020-05-08T09:32:06 *** jorijn has joined #bitcoin-core-dev
1262020-05-08T09:32:23 *** AaronvanW has joined #bitcoin-core-dev
1272020-05-08T09:35:56 <jonatack> jonasschnelli: nice!
1282020-05-08T09:36:06 *** promag_ has joined #bitcoin-core-dev
1292020-05-08T09:36:09 <jonatack> will re-review
1302020-05-08T09:36:16 *** promag_ has quit IRC
1312020-05-08T09:36:30 *** promag_ has joined #bitcoin-core-dev
1322020-05-08T09:36:52 <sipa> jonasschnelli: i need to think about that; i hoped we could avoid these concerns by copying an existing construction :)
1332020-05-08T09:41:19 <jonasschnelli> me two...
1342020-05-08T09:47:45 *** promag_ has quit IRC
1352020-05-08T09:53:46 *** timothy has joined #bitcoin-core-dev
1362020-05-08T09:59:39 *** jorijn has quit IRC
1372020-05-08T10:00:04 *** jorijn has joined #bitcoin-core-dev
1382020-05-08T10:15:23 *** DeanGuss has quit IRC
1392020-05-08T10:19:55 *** promag_ has joined #bitcoin-core-dev
1402020-05-08T10:24:20 *** promag_ has quit IRC
1412020-05-08T10:47:00 *** brakmic__ has quit IRC
1422020-05-08T10:47:21 *** brakmic has joined #bitcoin-core-dev
1432020-05-08T10:54:47 *** brakmic has quit IRC
1442020-05-08T11:17:41 *** promag_ has joined #bitcoin-core-dev
1452020-05-08T11:28:46 *** emilengler has quit IRC
1462020-05-08T11:43:43 *** ghost43 has quit IRC
1472020-05-08T11:43:43 *** jb55 has quit IRC
1482020-05-08T11:44:41 *** ghost43 has joined #bitcoin-core-dev
1492020-05-08T11:44:44 *** Emcy has quit IRC
1502020-05-08T11:45:58 *** Emcy has joined #bitcoin-core-dev
1512020-05-08T11:51:58 *** jb55 has joined #bitcoin-core-dev
1522020-05-08T11:53:50 *** bitcoin-git has joined #bitcoin-core-dev
1532020-05-08T11:53:51 <bitcoin-git> [bitcoin] hebasto opened pull request #18914: refactor: Apply override specifier consistently (master...200508-override) https://github.com/bitcoin/bitcoin/pull/18914
1542020-05-08T11:53:52 *** bitcoin-git has left #bitcoin-core-dev
1552020-05-08T11:58:21 *** promag_ has quit IRC
1562020-05-08T12:00:01 *** maop has quit IRC
1572020-05-08T12:00:50 *** emilengler has joined #bitcoin-core-dev
1582020-05-08T12:15:40 *** Aaronvan_ has joined #bitcoin-core-dev
1592020-05-08T12:15:43 *** mol_ has joined #bitcoin-core-dev
1602020-05-08T12:16:52 *** mol_ has quit IRC
1612020-05-08T12:17:15 *** mol_ has joined #bitcoin-core-dev
1622020-05-08T12:17:23 *** kristapsk has quit IRC
1632020-05-08T12:18:10 *** AaronvanW has quit IRC
1642020-05-08T12:18:11 *** molz_ has quit IRC
1652020-05-08T12:18:11 *** GAit has quit IRC
1662020-05-08T12:18:35 *** GAit has joined #bitcoin-core-dev
1672020-05-08T12:22:19 *** Highway61 has quit IRC
1682020-05-08T12:22:20 *** Highway62 has joined #bitcoin-core-dev
1692020-05-08T12:24:04 *** mol_ has quit IRC
1702020-05-08T12:24:25 *** kcalvinalvin has quit IRC
1712020-05-08T12:24:40 *** Highway62 is now known as Highway61
1722020-05-08T12:24:46 *** dfmb_ has joined #bitcoin-core-dev
1732020-05-08T12:27:10 *** kcalvinalvin has joined #bitcoin-core-dev
1742020-05-08T12:30:49 *** cltrbreak_MAD2 is now known as ctrlbreak
1752020-05-08T12:32:04 *** ghost43 has quit IRC
1762020-05-08T12:32:40 *** ghost43 has joined #bitcoin-core-dev
1772020-05-08T12:43:27 *** jb55 has quit IRC
1782020-05-08T12:43:57 *** jb55 has joined #bitcoin-core-dev
1792020-05-08T12:45:44 *** kristapsk has joined #bitcoin-core-dev
1802020-05-08T12:47:51 *** molakala has joined #bitcoin-core-dev
1812020-05-08T12:53:03 *** flamingspinach has joined #bitcoin-core-dev
1822020-05-08T12:54:51 *** manantial has joined #bitcoin-core-dev
1832020-05-08T12:55:07 *** roconnor has quit IRC
1842020-05-08T13:07:11 *** promag_ has joined #bitcoin-core-dev
1852020-05-08T13:12:13 *** mol has joined #bitcoin-core-dev
1862020-05-08T13:14:29 *** roconnor has joined #bitcoin-core-dev
1872020-05-08T13:19:11 *** promag_ has quit IRC
1882020-05-08T13:22:36 *** DeanGuss has joined #bitcoin-core-dev
1892020-05-08T13:28:17 *** mol has quit IRC
1902020-05-08T13:28:44 *** mol has joined #bitcoin-core-dev
1912020-05-08T13:44:03 <dfmb_> Hi im a noob, just wondering who decides which updates to deploy on bitcoin code? LetÅ say I make a pull request on the bitcoin github who decides that udpate is valid or it isn't ?
1922020-05-08T13:46:25 *** proofofkeags has joined #bitcoin-core-dev
1932020-05-08T13:51:11 <belcher> dfmb_ thats a common question, have a read of this https://blog.lopp.net/who-controls-bitcoin-core-/
1942020-05-08T13:51:42 <belcher> focusing on the github is a bit of a misdirection IMO, there have been situations in the past where the github code said one thing but users in practice ran some other code
1952020-05-08T13:59:09 *** Aaronvan_ has quit IRC
1962020-05-08T14:03:28 *** mdunnio has joined #bitcoin-core-dev
1972020-05-08T14:03:38 <dfmb_> got it, thnks!
1982020-05-08T14:08:04 *** promag_ has joined #bitcoin-core-dev
1992020-05-08T14:09:48 *** promag_ has quit IRC
2002020-05-08T14:19:44 *** geeker has joined #bitcoin-core-dev
2012020-05-08T14:25:42 *** BlueMatt has quit IRC
2022020-05-08T14:25:53 *** BlueMatt_ has joined #bitcoin-core-dev
2032020-05-08T14:29:23 *** mol_ has joined #bitcoin-core-dev
2042020-05-08T14:32:08 *** mol has quit IRC
2052020-05-08T14:32:18 *** molz_ has joined #bitcoin-core-dev
2062020-05-08T14:35:14 *** mol_ has quit IRC
2072020-05-08T14:36:10 *** promag_ has joined #bitcoin-core-dev
2082020-05-08T14:37:55 *** promag_ has quit IRC
2092020-05-08T14:40:17 *** Guyver2 has joined #bitcoin-core-dev
2102020-05-08T14:41:11 *** promag_ has joined #bitcoin-core-dev
2112020-05-08T14:41:57 *** AaronvanW has joined #bitcoin-core-dev
2122020-05-08T14:49:11 *** proofofkeags has quit IRC
2132020-05-08T15:00:02 *** flamingspinach has quit IRC
2142020-05-08T15:04:07 *** promag_ has quit IRC
2152020-05-08T15:06:36 *** promag_ has joined #bitcoin-core-dev
2162020-05-08T15:09:46 *** mol_ has joined #bitcoin-core-dev
2172020-05-08T15:11:27 *** promag_ has quit IRC
2182020-05-08T15:12:31 *** proofofkeags has joined #bitcoin-core-dev
2192020-05-08T15:12:38 *** molz_ has quit IRC
2202020-05-08T15:13:42 *** proofofkeags has quit IRC
2212020-05-08T15:14:41 *** proofofkeags has joined #bitcoin-core-dev
2222020-05-08T15:14:42 *** proofofkeags has quit IRC
2232020-05-08T15:14:56 *** proofofkeags has joined #bitcoin-core-dev
2242020-05-08T15:16:12 *** proofofkeags has quit IRC
2252020-05-08T15:17:32 *** proofofkeags has joined #bitcoin-core-dev
2262020-05-08T15:17:33 *** proofofkeags has quit IRC
2272020-05-08T15:17:48 *** proofofkeags has joined #bitcoin-core-dev
2282020-05-08T15:20:51 *** justanotheruser has quit IRC
2292020-05-08T15:21:19 *** luto1 has joined #bitcoin-core-dev
2302020-05-08T15:25:23 *** bitcoin-git has joined #bitcoin-core-dev
2312020-05-08T15:25:25 <bitcoin-git> [bitcoin] MarcoFalke pushed 4 commits to master: https://github.com/bitcoin/bitcoin/compare/f54753293fe7...3930014abcdd
2322020-05-08T15:25:25 <bitcoin-git> bitcoin/master 89a28e0 Sjors Provoost: [test] add v0.16.3 backwards compatibility test
2332020-05-08T15:25:25 <bitcoin-git> bitcoin/master 9c246b8 Sjors Provoost: [test] backwards compatibility: bump v0.19.0.1 to v0.19.1
2342020-05-08T15:25:26 <bitcoin-git> bitcoin/master d135c29 Sjors Provoost: [ci] make list of previous releases to download a setting
2352020-05-08T15:25:27 *** bitcoin-git has left #bitcoin-core-dev
2362020-05-08T15:25:43 *** bitcoin-git has joined #bitcoin-core-dev
2372020-05-08T15:25:44 <bitcoin-git> [bitcoin] MarcoFalke merged pull request #18864: Add v0.16.3 backwards compatibility test, bump v0.19.0.1 to v0.19.1 (master...2020/05/backwards_compat) https://github.com/bitcoin/bitcoin/pull/18864
2382020-05-08T15:25:45 *** bitcoin-git has left #bitcoin-core-dev
2392020-05-08T15:29:04 *** promag_ has joined #bitcoin-core-dev
2402020-05-08T15:30:19 *** geeker has quit IRC
2412020-05-08T15:30:29 *** geeker_ has joined #bitcoin-core-dev
2422020-05-08T15:33:40 *** promag_ has quit IRC
2432020-05-08T15:36:46 *** justanotheruser has joined #bitcoin-core-dev
2442020-05-08T15:37:13 *** promag_ has joined #bitcoin-core-dev
2452020-05-08T15:41:32 *** geeker_ has quit IRC
2462020-05-08T15:46:11 *** geeker has joined #bitcoin-core-dev
2472020-05-08T15:49:41 *** promag_ has quit IRC
2482020-05-08T16:11:02 *** pinheadmz has quit IRC
2492020-05-08T16:15:36 *** Highway61 has quit IRC
2502020-05-08T16:18:53 *** Highway61 has joined #bitcoin-core-dev
2512020-05-08T16:19:44 *** bitcoin-git has joined #bitcoin-core-dev
2522020-05-08T16:19:44 <bitcoin-git> [bitcoin] MarcoFalke pushed 6 commits to master: https://github.com/bitcoin/bitcoin/compare/3930014abcdd...5b24f6084ede
2532020-05-08T16:19:45 <bitcoin-git> bitcoin/master 23b9fa2 Hennadii Stepanov: gui: Add detailed text to BitcoinGUI::message
2542020-05-08T16:19:45 <bitcoin-git> bitcoin/master 917ca93 Hennadii Stepanov: Make ThreadSafe{MessageBox|Question} bilingual
2552020-05-08T16:19:45 <bitcoin-git> bitcoin/master 7e923d4 Hennadii Stepanov: Make InitError bilingual
2562020-05-08T16:19:47 *** bitcoin-git has left #bitcoin-core-dev
2572020-05-08T16:20:00 *** vasild_ has joined #bitcoin-core-dev
2582020-05-08T16:20:59 *** bitcoin-git has joined #bitcoin-core-dev
2592020-05-08T16:20:59 <bitcoin-git> [bitcoin] MarcoFalke merged pull request #16224: gui: Bilingual GUI error messages (master...20190617-bilingual-errors) https://github.com/bitcoin/bitcoin/pull/16224
2602020-05-08T16:21:00 *** bitcoin-git has left #bitcoin-core-dev
2612020-05-08T16:21:27 <hebasto> \o/
2622020-05-08T16:23:03 *** vasild has quit IRC
2632020-05-08T16:23:04 *** vasild_ is now known as vasild
2642020-05-08T16:25:43 *** DeanGuss has quit IRC
2652020-05-08T16:29:01 *** instagibbs has quit IRC
2662020-05-08T16:29:51 *** instagibbs has joined #bitcoin-core-dev
2672020-05-08T16:37:45 *** DeanGuss has joined #bitcoin-core-dev
2682020-05-08T16:38:20 *** drizztbsd has joined #bitcoin-core-dev
2692020-05-08T16:39:13 *** timothy has quit IRC
2702020-05-08T16:43:29 *** filchef has joined #bitcoin-core-dev
2712020-05-08T16:44:26 *** dongcarl has quit IRC
2722020-05-08T16:53:00 *** molakala has quit IRC
2732020-05-08T16:54:42 *** pinheadmz has joined #bitcoin-core-dev
2742020-05-08T16:55:05 *** promag_ has joined #bitcoin-core-dev
2752020-05-08T16:57:17 *** molakala has joined #bitcoin-core-dev
2762020-05-08T16:59:28 *** promag_ has quit IRC
2772020-05-08T17:11:03 *** proofofkeags has quit IRC
2782020-05-08T17:12:49 *** proofofkeags has joined #bitcoin-core-dev
2792020-05-08T17:12:50 *** proofofkeags has quit IRC
2802020-05-08T17:13:05 *** proofofkeags has joined #bitcoin-core-dev
2812020-05-08T17:18:53 *** promag_ has joined #bitcoin-core-dev
2822020-05-08T17:19:00 *** jarthur has joined #bitcoin-core-dev
2832020-05-08T17:30:39 *** promag_ has quit IRC
2842020-05-08T17:33:55 *** jarthur has quit IRC
2852020-05-08T17:34:36 *** jarthur has joined #bitcoin-core-dev
2862020-05-08T17:38:46 *** timothy has joined #bitcoin-core-dev
2872020-05-08T17:39:34 *** drizztbsd has quit IRC
2882020-05-08T17:58:44 *** geeker has quit IRC
2892020-05-08T17:59:36 *** geeker has joined #bitcoin-core-dev
2902020-05-08T18:00:01 *** luto1 has quit IRC
2912020-05-08T18:11:22 *** Talkless has quit IRC
2922020-05-08T18:21:43 *** per has quit IRC
2932020-05-08T18:22:02 *** stranger64 has joined #bitcoin-core-dev
2942020-05-08T18:25:50 *** bitcoin-git has joined #bitcoin-core-dev
2952020-05-08T18:25:50 <bitcoin-git> [bitcoin] brakmic opened pull request #18917: fuzz: fix vector size problem in system fuzzer (master...fix-system-fuzzer) https://github.com/bitcoin/bitcoin/pull/18917
2962020-05-08T18:25:51 *** bitcoin-git has left #bitcoin-core-dev
2972020-05-08T18:47:36 *** timothy has quit IRC
2982020-05-08T18:57:51 *** promag_ has joined #bitcoin-core-dev
2992020-05-08T19:00:27 <meshcollider> #startmeeting
3002020-05-08T19:00:27 <lightningbot> Meeting started Fri May 8 19:00:27 2020 UTC. The chair is meshcollider. Information about MeetBot at http://wiki.debian.org/MeetBot.
3012020-05-08T19:00:27 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
3022020-05-08T19:00:30 <provoostenator> hi
3032020-05-08T19:00:32 <jonatack> hi
3042020-05-08T19:00:38 <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
3052020-05-08T19:00:39 <meshcollider> jeremyrubin emilengler jonatack hebasto jb55
3062020-05-08T19:00:40 <achow101> hi
3072020-05-08T19:01:42 <meshcollider> The main topic we have to discuss this week is the wallet DB
3082020-05-08T19:02:04 <meshcollider> #topic wallet DB (achow101)
3092020-05-08T19:02:16 *** promag_ has quit IRC
3102020-05-08T19:02:24 <meshcollider> There was a bit of discussion earlier in the week already
3112020-05-08T19:02:33 <jnewbery> hi
3122020-05-08T19:02:35 <fjahr> hi
3132020-05-08T19:04:19 <achow101> yes
3142020-05-08T19:04:25 <meshcollider> http://www.erisian.com.au/bitcoin-core-dev/log-2020-05-05.html
3152020-05-08T19:04:53 <jonatack> http://www.erisian.com.au/bitcoin-core-dev/log-2020-05-05.html#l-100
3162020-05-08T19:05:12 <achow101> Also #18916
3172020-05-08T19:05:14 <gribble> https://github.com/bitcoin/bitcoin/issues/18916 | Sqlite wallet storage · Issue #18916 · bitcoin/bitcoin · GitHub
3182020-05-08T19:06:05 <achow101> (and probably 5 or so old issues and PRs)
3192020-05-08T19:06:52 <provoostenator> Is there any reason why descriptor wallets are special when it comes to introducing new storage?
3202020-05-08T19:06:55 <achow101> I'd like to move us off of BDB to something else. What that something else is, we can
3212020-05-08T19:06:59 <achow101> *we can discuss later
3222020-05-08T19:07:26 <achow101> I wanted to do this specifically for descriptor wallets because descriptor wallets are a wholly new thing so it made logical sense to me to introduce another wholly new thing with the descriptor wallets
3232020-05-08T19:07:32 <achow101> since it's already backwards incompatible anyways
3242020-05-08T19:08:09 <meshcollider> provoostenator: that's what the bulk of the discussion with sipa a few days ago was, he believes it's entirely orthogonal
3252020-05-08T19:08:11 <provoostenator> True, assuming it's something we can get merge-ready before 0.21
3262020-05-08T19:08:27 <achow101> then we can ditch bdb whenever we ditch legacy wallets
3272020-05-08T19:08:36 <jonatack> iirc the conclusion of that discussion was that descriptor wallets and the DB ought to be orthogonal concerns?
3282020-05-08T19:08:41 <achow101> jonatack: yes
3292020-05-08T19:08:42 <meshcollider> Exactly, it has to be 0.21 if it's going to be a descriptor wallet thing
3302020-05-08T19:09:03 <achow101> I think the conclusion of that discussion was implement it agnostic of the wallet type since it is orthogonal
3312020-05-08T19:09:13 <provoostenator> They are orthogonal, but it's nice to have if we can do these things at the same time.
3322020-05-08T19:09:14 <achow101> then later we can restrict it to descriptor wallets if we get it in fast enough
3332020-05-08T19:09:25 <luke-jr> a long time ago, we wanted to move to an append-only wallet file format
3342020-05-08T19:09:37 <sipa> i think it should be developed as orthogonal - the way it's exposed to users can be to require sqlite wallets for descriptor wallets if it's ready for 0.21, and otherwise it should remain orthogonal
3352020-05-08T19:09:50 <sipa> luke-jr: i'm aware :)
3362020-05-08T19:09:56 <provoostenator> sipa: that makes sense
3372020-05-08T19:10:52 <meshcollider> yep
3382020-05-08T19:10:53 <achow101> luke-jr: I actually don't think append only makes a ton of sense for us anymore. we're constantly updating and rewriting records
3392020-05-08T19:10:59 *** real_or_random has quit IRC
3402020-05-08T19:11:10 <achow101> e.g. CHDChain is updated for every single new key
3412020-05-08T19:11:18 <achow101> (in legacy wallets)
3422020-05-08T19:11:39 <jnewbery> 'require sqlite wallets for descriptor wallets' seems like it could be a really nice thing. (I haven't read the previous discussion)
3432020-05-08T19:11:43 <sipa> but it's kind of reinventing the wheel - sqlite is overkill, but it's (in my understanding) very well tested and does what we'd need; probably with more assurances than what a self-developed solution can provide at the levels of effort we'd be willing to put into it
3442020-05-08T19:11:51 <luke-jr> achow101: does it need to be?
3452020-05-08T19:12:11 <sipa> achow101: that's not really relevant; an append-only format would still compact whenever too many records are rewritten
3462020-05-08T19:12:13 *** real_or_random has joined #bitcoin-core-dev
3472020-05-08T19:12:24 <luke-jr> achow101: abstractly, we don't need to be rewriting often
3482020-05-08T19:12:59 <luke-jr> do we know how good sqlite's compatibility guarantees are? or are we just going to end up int he same place soon?
3492020-05-08T19:13:13 <luke-jr> can an old sqlite open a new sqlite db?
3502020-05-08T19:13:15 <achow101> luke-jr: i think so? regardless, I'd also like to not touch application level stuff, just the blob storage to keep things simple
3512020-05-08T19:13:16 <provoostenator> It can be run in javascript :-)
3522020-05-08T19:13:18 <sipa> luke-jr: yes
3532020-05-08T19:13:35 <sipa> achow101: we're still rewriting very infrequently compared to everything stored in the file, so i think the approach of an append-only format that gets occasionally compacted makes perfect sense
3542020-05-08T19:13:39 <achow101> luke-jr: sqlite promises that compatibility will be maintained to at least 2050 or something like that. and everything is public domain
3552020-05-08T19:13:40 <gwillen> I think sqlite is approximately the most-tested piece of software in existence
3562020-05-08T19:13:51 <gwillen> outside of extremely specialized things like the space shuttle
3572020-05-08T19:14:00 <luke-jr> achow101: everything is open source in bdb4/5 too
3582020-05-08T19:14:22 <achow101> luke-jr: public domain meaning no license attached
3592020-05-08T19:14:34 <luke-jr> achow101: that's a bad thing, not a good one :P
3602020-05-08T19:14:53 <achow101> how so? it means that we won't have them move to agpl like bdb did
3612020-05-08T19:15:12 <luke-jr> achow101: they can move to AGPL just as easily as BDB did. But it's bad because PD isn't legal in some places
3622020-05-08T19:15:25 <sipa> achow101: it's just whether we're willing to put effort into building and maintaining a new format just to avoid some of the complexity of sqlite
3632020-05-08T19:15:36 <sipa> (which i think isn't worth it today)
3642020-05-08T19:15:41 <achow101> From their website: "The SQLite file format is stable, cross-platform, and backwards compatible and the developers pledge to keep it that way through at least the year 2050." and "SQLite source code is in the public-domain and is free to everyone to use for any purpose."
3652020-05-08T19:15:43 <luke-jr> tbh maintaining bdb is probably easier than maintaining sqlite
3662020-05-08T19:15:45 <gwillen> I have never heard a credible lawyer claim that PD is "not legal"
3672020-05-08T19:15:47 <provoostenator> luke-jr: is it illegal in places where Bitcoin is legal?
3682020-05-08T19:15:50 <gwillen> in any jurisdiction
3692020-05-08T19:15:57 <gwillen> I have heard some people who are not lawyers claim that
3702020-05-08T19:15:58 <luke-jr> achow101: it's forward-compatible that is the concern
3712020-05-08T19:16:03 <luke-jr> provoostenator: no idea
3722020-05-08T19:16:04 <gwillen> my impression is that they are mostly confused
3732020-05-08T19:16:43 <sipa> https://www.sqlite.org/copyright.html
3742020-05-08T19:16:44 <sipa> read that
3752020-05-08T19:17:30 <provoostenator> How far do we need to be forward-compatible? The purpose of that is to make it easier to downgrade from a bad soft fork or bug, right?
3762020-05-08T19:17:36 <provoostenator> Not to downgrade all the way to 0.1
3772020-05-08T19:19:40 <sipa> if existing use is any evidence, there are tons of applications using sqlite for application-level storage like we do - but those who are using bdb seems to be mostly old software that's moving away from it (slapd to lmdb, subversion to fsfs, ...)
3782020-05-08T19:20:10 <luke-jr> sipa: but how many that support downgrading?
3792020-05-08T19:20:10 <achow101> provoostenator: at the very least, within the versions that are still maintained
3802020-05-08T19:20:39 <sipa> luke-jr: bdb is terrible at forward compatibility, i don't understand
3812020-05-08T19:20:53 <luke-jr> sipa: yes, I'm just not sure sqlite improves on this
3822020-05-08T19:20:57 <gwillen> btw here is the paper that tested a bunch of database engines for whether they misuse filesystem APIs in ways that make them vulnerable to data loss
3832020-05-08T19:20:57 <provoostenator> Right, so that means we have to have a careful upgrade policy for the sqlite dependency, that's documented somewhere
3842020-05-08T19:21:00 <gwillen> https://www.usenix.org/system/files/conference/osdi14/osdi14-paper-pillai.pdf
3852020-05-08T19:21:01 <luke-jr> and while bdb might be maintainable, sqlite is a lot more complex
3862020-05-08T19:21:02 <ryanofsky> should be aware most of the work involved in this is just abstracting the existing code. if it's just a key value store and you want to swap out sqlite for lukedb that should be pretty easy
3872020-05-08T19:21:08 <gwillen> sqlite in write-ahead-logging mode is literally the only one that passed
3882020-05-08T19:21:09 <luke-jr> and AFAIK we don't gain anything from sqlite's complexity
3892020-05-08T19:21:15 <sipa> luke-jr: sqlite is a single cpp file if you want
3902020-05-08T19:21:25 <sipa> it couldn't be more simple
3912020-05-08T19:21:31 <gwillen> leveldb failed, they did not test bdb unfortunately
3922020-05-08T19:21:35 <luke-jr> sipa: shoving everything into a single file doesn't impress me?
3932020-05-08T19:21:48 <achow101> luke-jr: i'd like to make use of sqlite's complexity with actual tables and columns, just not initially
3942020-05-08T19:21:49 <sipa> luke-jr: then use the library
3952020-05-08T19:21:56 <luke-jr> sipa: not the point
3962020-05-08T19:22:03 <sipa> then i don't understand your point
3972020-05-08T19:22:12 <sipa> bdb is a maintenance nightmare in my impression
3982020-05-08T19:22:28 <jnewbery> I think it's kinda weird that we claim forward-compatibility. We don't have any tests for it, and I can't imagine anyone cares, except for (maybe) downgrading one version.
3992020-05-08T19:22:33 <luke-jr> my main point is we gain nothing by moving to sqlite afaik
4002020-05-08T19:22:40 <gwillen> luke-jr: did you read the paper I linked
4012020-05-08T19:22:51 <meshcollider> Yes the existing code needs a significant tidy-up to abstract before a new db can be introduced, that's something achow101 messaged me about yesterday, it's going to be quite a difficult job
4022020-05-08T19:22:59 <sipa> sqlite explicitly has compatibility as a design goal
4032020-05-08T19:23:09 <luke-jr> gwillen: no; in practice, we have bdb working today
4042020-05-08T19:23:18 <gwillen> sqlite is the only database engine that actually passes tests of correctness for safely storing data on disk
4052020-05-08T19:23:21 <sipa> for bdb it seems like an afterthought that's effectively only achieved by it being abandoned
4062020-05-08T19:23:33 <gwillen> this is because sqlite is the most tested piece of software in existence
4072020-05-08T19:23:39 <provoostenator> jnewbery: we do have tests for it, as of recently: https://github.com/bitcoin/bitcoin/blob/master/test/functional/feature_backwards_compatibility.py#L221
4082020-05-08T19:23:48 <gwillen> (admitting, again, that bdb was not included in the list tested, but I would be shocked if it managed to pass)
4092020-05-08T19:24:15 <provoostenator> That test loads master branch wallets all the back to 0.17
4102020-05-08T19:24:33 <provoostenator> (as in, it opens them using the 0.17 binary)
4112020-05-08T19:24:57 <achow101> luke-jr: we currently have a ton of hacks to make bdb consistent and not corrupt itself. I think sqlite gives us better guarantees of that. additionally it doesn't have persistent log files like bdb, everything is mostly self contained within a single file with the exception being active writes
4122020-05-08T19:25:02 <sipa> bdb also has a ton of complexity we don't use, though of a different nature than sqlite; it is designed for multi-process applications accessing the same database simultaneously, with locking, synchronization, ... overhead
4132020-05-08T19:25:15 <provoostenator> Doesn't BlueMatt_ have a Rust database?
4142020-05-08T19:25:21 <sipa> achow101: sqlite has a write log
4152020-05-08T19:25:25 <luke-jr> sipa: so does sqlite..>?
4162020-05-08T19:25:32 <jnewbery> ok, but I still claim my second statement is true. Literally nobody wants to run a v0.20 wallet on v0.17 software.
4172020-05-08T19:25:39 <achow101> sipa: it cleans up the journal when everything is flushed
4182020-05-08T19:25:40 <sipa> luke-jr: no, sqlite is single-process
4192020-05-08T19:25:44 <luke-jr> jnewbery: I might.
4202020-05-08T19:25:47 <sipa> achow101: of course
4212020-05-08T19:25:53 <luke-jr> jnewbery: I'm still using 0.13 for my real wallet
4222020-05-08T19:26:23 <luke-jr> sipa: but you can use sqlite from multiple programs on the same db IIRC
4232020-05-08T19:26:24 <jnewbery> then still use it. But the expectation that you can take that wallet, load it in master, do something with it and then reload it in 0.13 is unrealistic
4242020-05-08T19:26:32 <sipa> luke-jr: not simultaneously
4252020-05-08T19:26:48 <achow101> sipa: there's an option for that. but it's not relevant to us
4262020-05-08T19:26:51 <luke-jr> jnewbery: it works today, so clearly not unrealistic..
4272020-05-08T19:26:55 <sipa> ah
4282020-05-08T19:26:58 <sipa> maybe i'm wrong
4292020-05-08T19:27:01 <meshcollider> If someone is still using 0.13, they probably *won't* ever edit it in master, that's probably the point
4302020-05-08T19:27:13 <provoostenator> We also have wallet-tool now, so we could make it easier to dump wallets into a more universal text based format
4312020-05-08T19:27:15 <achow101> luke-jr: I think you might be an edge case
4322020-05-08T19:27:24 <meshcollider> A few versions of forward compatibility seems fine
4332020-05-08T19:27:32 <provoostenator> And then you can use older versions to import from that text format
4342020-05-08T19:27:43 *** DeanGuss has quit IRC
4352020-05-08T19:27:45 *** Dean_Guss has joined #bitcoin-core-dev
4362020-05-08T19:27:46 <sipa> as long as achow101 doesn't go through with his start-using-table-features, a trivial dump+load with command-line tools would always be possible to convert between bdb and sqlite even
4372020-05-08T19:27:58 <gwillen> I am surprised to learn that forward-compatibility exists, isn't there a minimum version field in the wallet that gets rolled forward sometimes?
4382020-05-08T19:28:05 <gwillen> does that only happen if you actively use a new feature?
4392020-05-08T19:28:08 <achow101> gwillen: only with explicity upgrades
4402020-05-08T19:28:09 <luke-jr> gwillen: only when the user requests it
4412020-05-08T19:28:11 <sipa> gwillen: only when you explicitly use -upgradewallet
4422020-05-08T19:28:16 <sipa> or the RPC now
4432020-05-08T19:28:20 <jnewbery> luke-jr: is your opposition to this because it makes it more difficult to maintain bitcoin knots if the dependencies in bitcoin core change?
4442020-05-08T19:28:28 <luke-jr> jnewbery: no
4452020-05-08T19:28:30 <provoostenator> It's just something we have to take into account early on, making sure dumpwallet can dump descriptor wallets.
4462020-05-08T19:29:14 <luke-jr> jnewbery: I just don't see the benefit, and it seems quite possible we end up in a worse situation
4472020-05-08T19:29:39 <sipa> you don't think there is a downside to being effectively locked with abandoned software?
4482020-05-08T19:29:57 <luke-jr> no? that's just stability
4492020-05-08T19:30:05 <provoostenator> I'm not familiar enough with the code differences between sqlite and bdb, but it seems like sqlite is alive.
4502020-05-08T19:30:06 *** BlueMatt_ has left #bitcoin-core-dev
4512020-05-08T19:30:12 *** BlueMatt has joined #bitcoin-core-dev
4522020-05-08T19:30:15 <provoostenator> And we can't jump to BDB 18
4532020-05-08T19:30:18 <jonatack> it sounds like there is rough consensus to look into eventually moving to sqlite
4542020-05-08T19:30:25 <luke-jr> provoostenator: alive-ness seems like a negative here
4552020-05-08T19:30:30 <sipa> luke-jr: ...
4562020-05-08T19:30:33 <meshcollider> We would have to keep the bdb support for the long term anyway
4572020-05-08T19:30:37 *** BlueMatt is now known as Guest41060
4582020-05-08T19:30:39 <luke-jr> for a wallet store, stability is needed, not constant change
4592020-05-08T19:30:48 <achow101> at the very least, I think it would be good to move forward with refactoring and cleaning up the existing db storage code
4602020-05-08T19:30:53 <sipa> format stability yes, which sqlite has
4612020-05-08T19:30:53 <meshcollider> ^
4622020-05-08T19:30:54 <provoostenator> Non-deadness is good, too much change is bad.
4632020-05-08T19:31:04 <achow101> in such a way that adding *some other* db in the end can be done more easily
4642020-05-08T19:31:13 <achow101> whether that's sqlite, logdb, or something else
4652020-05-08T19:31:13 <ryanofsky> what is dead may never die
4662020-05-08T19:31:15 <luke-jr> sipa: backwards-compatible is not forwards-compatible
4672020-05-08T19:31:16 *** Guest41060 has quit IRC
4682020-05-08T19:31:16 *** Guest41060 has joined #bitcoin-core-dev
4692020-05-08T19:31:32 <luke-jr> achow101: certainly
4702020-05-08T19:31:35 <meshcollider> I don't think anyone can complain about just a code cleanup in advance of a db introduction
4712020-05-08T19:31:45 <jonatack> ^
4722020-05-08T19:31:51 <provoostenator> Forwards compatilibyt isn't a big deal if we have a canonical dump format.
4732020-05-08T19:32:05 <sipa> provoostenator: we don't have a canonical dump format, but we don't need one
4742020-05-08T19:32:08 <sipa> csv works great
4752020-05-08T19:32:15 <sipa> it's a key-value store ffs
4762020-05-08T19:32:20 <achow101> luke-jr: sqlite has a table of format changes: https://sqlite.org/formatchng.html and it looks like the latest format hasn't changed
4772020-05-08T19:32:35 <provoostenator> sipa: csv is fine by me
4782020-05-08T19:32:59 <sipa> sqlite3 is btw what everything uses
4792020-05-08T19:33:05 <luke-jr> achow101: ok, so that table seems to prove my point
4802020-05-08T19:33:16 <luke-jr> what if we switch to sqlite3, and sqlite4 completely breaks compatibility?
4812020-05-08T19:33:27 <gwillen> luke-jr: your point is that sqlite has not changed its format in 16 years, since before bitcoin was invented?
4822020-05-08T19:33:28 <luke-jr> "The new file format is very different and is completely incompatible with the version 2 file format."
4832020-05-08T19:33:35 <gwillen> and has a direct statement that it will never do so again?
4842020-05-08T19:33:36 <gwillen> that point?
4852020-05-08T19:33:41 <sipa> sqlite3 was released in 2004
4862020-05-08T19:33:51 <provoostenator> "In other words, since 2004 all SQLite releases have been backwards compatible, though not necessarily forwards compatible."
4872020-05-08T19:33:56 <achow101> luke-jr: they had a sqlite4. it was killed
4882020-05-08T19:34:12 <provoostenator> Which means we need to be able to dump (into a CSV )to compensate for lack of forwards compatibility.
4892020-05-08T19:34:23 <meshcollider> If we just use basic features, like we do in BDB, there's even less of a chance of breaking forwards compatibility
4902020-05-08T19:34:23 <provoostenator> But upgrading should be fine.
4912020-05-08T19:34:28 <luke-jr> " Since 2004, there have been enhancements to SQLite such that newer database files are unreadable by older versions of the SQLite library." â¹
4922020-05-08T19:34:28 <sipa> provoostenator: that's more relevant, but i believe it's only when you use database features that were introduced later
4932020-05-08T19:34:46 <gwillen> I believe when you create an sqlite database file you can specify the file version
4942020-05-08T19:34:48 <sipa> luke-jr: and the same is true for bdb 4.8, bdb 6, ...
4952020-05-08T19:34:52 <sipa> luke-jr: what is your point?
4962020-05-08T19:34:58 <achow101> provoostenator: I believe they have a minversion type thing like we do, but it's for new features that you have to explicitly use
4972020-05-08T19:35:00 <gwillen> so if you don't desire to use features that were added after 2004, you just set your file version to 2004
4982020-05-08T19:35:15 <luke-jr> sipa: my point is we don't want to get stuck with sqlite3.31
4992020-05-08T19:35:16 <sipa> if you think sticking to bdb 4.8 is fine, then sticking to sqlite 3.whatever it is now is also fine
5002020-05-08T19:35:21 <gwillen> then you can read or write it with any versiono of sqlite that exists
5012020-05-08T19:35:29 <luke-jr> due to sqlite's activity, there is a lot more pressure to drop old verisons
5022020-05-08T19:35:31 <sipa> luke-jr: but being stuck with bdb 4.8 is fine?
5032020-05-08T19:35:37 <luke-jr> yes, bdb is dead
5042020-05-08T19:35:46 <meshcollider> Anyway, achow101 did mention at the start that we can decide on the choice of db later
5052020-05-08T19:35:53 <sipa> if it being dead is fine, then you can treat sqlite as dead too
5062020-05-08T19:36:00 <sipa> i really don't comprehend your argument
5072020-05-08T19:36:00 <luke-jr> you can't, because it isn't
5082020-05-08T19:36:08 <luke-jr> distros will continue updating it
5092020-05-08T19:36:08 <meshcollider> Is there anything else you want to discuss achow101, about the code abstraction or anything?
5102020-05-08T19:36:18 <provoostenator> The idea was to include the source, right?
5112020-05-08T19:36:26 <luke-jr> definitely NACK
5122020-05-08T19:36:40 <sipa> provoostenator: i'm not sure that's a necessary
5132020-05-08T19:36:42 <achow101> if anyone wants to read about the mess that is our loading code and what I would like to change: https://gist.github.com/achow101/cda3ea1bb07f585e56caaf969e842188
5142020-05-08T19:37:07 <provoostenator> If we rely on distros then you can't pretend it's dead.
5152020-05-08T19:37:14 <achow101> so the next point of possible contention is where to put salvagewallet because that needs to be moved out of loading code
5162020-05-08T19:37:39 <achow101> I think i'll just dump it into wallettool for now
5172020-05-08T19:38:45 <jnewbery> achow101: +1
5182020-05-08T19:38:55 <achow101> and another thing to discuss: whether we still want to support the old multiwallet method where you renamed the wallet.dat file. so multiple wallets were in the same dbenv
5192020-05-08T19:38:58 <sipa> that makes sense
5202020-05-08T19:39:13 <achow101> I think we have to remove that support otherwise it will get in the way of the abstraction
5212020-05-08T19:39:49 <jnewbery> achow101: is there a migration path? A way to move separate wallets into their own directories on load?
5222020-05-08T19:40:24 <luke-jr> no need to rename, just -wallet=foo.dat
5232020-05-08T19:41:10 <ryanofsky> jnewbery: it is possible to move them manually, wallet-tool could also be extended to help with this, but I think automatic migration would be the best
5242020-05-08T19:41:12 <achow101> jnewbery: use your preferred file explorer and move some wallet file?
5252020-05-08T19:41:42 <ryanofsky> or maybe not, automatic migration might cause problems if people are doing automated backups of existing files
5262020-05-08T19:41:56 <achow101> I would not go with automatic migration
5272020-05-08T19:42:19 <achow101> what i've done currently is to give a very verbose warning about what you have to do manually
5282020-05-08T19:42:26 <achow101> s/warning/error
5292020-05-08T19:43:01 <ryanofsky> i don't think it should actually be that big of a deal to keep supporting them either, but I can see why you don't want to do that
5302020-05-08T19:43:02 <jnewbery> giving manual instructions for something the user will only ever need to do once seems reasonable
5312020-05-08T19:43:16 <ryanofsky> +1
5322020-05-08T19:43:30 <provoostenator> As long as the GUI offers a "wizard" for that?
5332020-05-08T19:43:36 <jnewbery> presumably users that have configured multi-wallet are fairly advanced and can handle moving files into a directory
5342020-05-08T19:44:07 <provoostenator> I would say RPC users should be able to use "mv"
5352020-05-08T19:44:11 <achow101> I think any user still using that behavior had to got into multiwallet very early on where you had to set startup options. so presumably they know what they're doing
5362020-05-08T19:44:26 <ryanofsky> jnewbery, it means they started bitcoin at some point with a -wallet=something command line argument, but maybe that is advanced enough
5372020-05-08T19:44:27 <jnewbery> provoostenator: I don't think it's necessary, and the development/testing overhead to get right that maybe a few hundred(?) people will only use once seems disproportionate.
5382020-05-08T19:44:28 <meshcollider> At least those who made them before the multiwallet GUI create dialog
5392020-05-08T19:44:42 <meshcollider> Which is well after separate directories was introduced
5402020-05-08T19:44:58 <achow101> i think it predates the createwallet rpc?
5412020-05-08T19:45:09 <ryanofsky> yes, predates the rpcs and gui stuff iirc
5422020-05-08T19:45:14 <provoostenator> Oh ok, if it doesn't affect single wallet users, and only effects multi-wallet users before the GUI supported that, it's fine.
5432020-05-08T19:46:32 <meshcollider> Nice write-up btw achow101
5442020-05-08T19:46:50 <ryanofsky> it affects single wallet users who used -wallet option prior to multiwallet support too, but maybe they are even less of a concerns
5452020-05-08T19:48:08 <luke-jr> does moving just wallet.dat work, or is some magic needed with the database/ dir?
5462020-05-08T19:48:18 <luke-jr> I guess backupwallet is always an option
5472020-05-08T19:48:28 <achow101> luke-jr: as long as everything was shut down cleanly, just moving the wallet.dat will work
5482020-05-08T19:48:43 <ryanofsky> you just need to create a directory with a "wallet.dat" file, assuming there are no old logs
5492020-05-08T19:49:21 <ryanofsky> if there are logs in the directory, they are shared between all the wallet files in the directory, so there is some risk of data loss if you don't copy them too
5502020-05-08T19:50:26 <luke-jr> [19:32:05] <sipa> provoostenator: we don't have a canonical dump format, but we don't need one <-- btw, there is the dumpwallet RPC
5512020-05-08T19:50:40 <luke-jr> which is a mess IMO
5522020-05-08T19:50:48 <sipa> dumpwallet does not achieve that at all
5532020-05-08T19:50:52 <ryanofsky> just looked up, #1889 is the pr that introduce the -wallet option for wallets with custom names
5542020-05-08T19:50:54 <gribble> https://github.com/bitcoin/bitcoin/issues/1889 | let user select wallet file with -wallet=foo.dat by tcatm · Pull Request #1889 · bitcoin/bitcoin · GitHub
5552020-05-08T19:50:59 <provoostenator> luke-jr: yes, but dumpwallet is dsiabled for desciptor wallets, and needs to be redone properly anyway
5562020-05-08T19:51:09 <sipa> it dumps private keys, and a few other things - it does not dump all the wallet data that lets you recreate the same wallet again
5572020-05-08T19:51:10 <provoostenator> But that should be doable
5582020-05-08T19:51:30 <jnewbery> My opinion on forward/backward wallet compatibility is that we should support 2 versions in either direction, and make sure that we have 100% test coverage of all features. The fact that we have code like https://github.com/bitcoin/bitcoin/blob/5b24f6084ede92d0f493ff416b4726245140b2c1/src/wallet/walletdb.cpp#L284 which is supposed to support some wallet quirk in 2012 that isn't tested and
5592020-05-08T19:51:33 <luke-jr> sipa: there's a paired loadwallet too; it just isn't lossless
5602020-05-08T19:51:36 <jnewbery> probably wasn't even in an actual release is crazy.
5612020-05-08T19:51:37 <provoostenator> The reverse of that new dumpwallet just needs to be smart enough to ignore stuff it doesn't know.
5622020-05-08T19:52:31 <achow101> provoostenator: we already have importwallet to do the inverse of dumpwallet
5632020-05-08T19:52:32 <sipa> luke-jr: i'm aware, i think i wrote it
5642020-05-08T19:52:36 <achow101> I think both need changes
5652020-05-08T19:53:16 <sipa> agree
5662020-05-08T19:53:19 <luke-jr> jnewbery: 3.16.0 it says?
5672020-05-08T19:53:20 *** promag has quit IRC
5682020-05-08T19:53:48 <luke-jr> if we were sticking to bdb, we could just tell people to use db4.8dump or whatever XD
5692020-05-08T19:55:02 <meshcollider> Ok last 5 mins, anything else anyone wanted to discuss?
5702020-05-08T19:55:07 <jonatack> achow101: that is a really helpful writeup
5712020-05-08T19:56:32 <jonatack> meshcollider: blockers/high-priority?
5722020-05-08T19:56:56 <meshcollider> Any changes for high priority? Probably covered yesterday
5732020-05-08T19:57:19 <achow101> i'd just like to review beg for both #16946 and #17681
5742020-05-08T19:57:21 <gribble> https://github.com/bitcoin/bitcoin/issues/16946 | wallet: include a checksum of encrypted private keys by achow101 · Pull Request #16946 · bitcoin/bitcoin · GitHub
5752020-05-08T19:57:23 <gribble> https://github.com/bitcoin/bitcoin/issues/17681 | wallet: Keep inactive seeds after sethdseed and derive keys from them as needed by achow101 · Pull Request #17681 · bitcoin/bitcoin · GitHub
5762020-05-08T19:57:42 <provoostenator> People are always welcome to play with #16549
5772020-05-08T19:57:44 <gribble> https://github.com/bitcoin/bitcoin/issues/16549 | UI external signer support (e.g. hardware wallet) by Sjors · Pull Request #16549 · bitcoin/bitcoin · GitHub
5782020-05-08T19:57:59 <provoostenator> (draft, not high priority)
5792020-05-08T19:58:02 *** molz_ has joined #bitcoin-core-dev
5802020-05-08T19:58:42 <meshcollider> Alright, thanks everyone for the discussion :)
5812020-05-08T19:58:43 <jnewbery> achow101: we're going to cover 17681 in review club next wednesday (ryanofsky hosting). It'd be great if you could join us
5822020-05-08T19:58:47 <meshcollider> #endmeeting
5832020-05-08T19:58:47 <lightningbot> Meeting ended Fri May 8 19:58:47 2020 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
5842020-05-08T19:58:47 <lightningbot> Minutes: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2020/bitcoin-core-dev.2020-05-08-19.00.html
5852020-05-08T19:58:47 <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2020/bitcoin-core-dev.2020-05-08-19.00.txt
5862020-05-08T19:58:47 <lightningbot> Log: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2020/bitcoin-core-dev.2020-05-08-19.00.log.html
5872020-05-08T19:59:03 <achow101> jnewbery: I'll try to remember to join
5882020-05-08T19:59:06 <jonatack> will look at those PRs. #18594 if anyone interested is pretty far along.
5892020-05-08T19:59:09 <gribble> https://github.com/bitcoin/bitcoin/issues/18594 | cli: display multiwallet balances in -getinfo by jonatack · Pull Request #18594 · bitcoin/bitcoin · GitHub
5902020-05-08T19:59:25 <jnewbery> achow101: I'll ping ya
5912020-05-08T19:59:26 <jonatack> it's the client-side version
5922020-05-08T20:01:08 *** mol_ has quit IRC
5932020-05-08T20:06:03 *** promag has joined #bitcoin-core-dev
5942020-05-08T20:07:50 *** bitcoin-git has joined #bitcoin-core-dev
5952020-05-08T20:07:50 <bitcoin-git> [bitcoin] brakmic closed pull request #18908: util: raise a deadly signal in system.cpp fuzzer (master...fuzz-ub-argsmanager) https://github.com/bitcoin/bitcoin/pull/18908
5962020-05-08T20:07:51 *** bitcoin-git has left #bitcoin-core-dev
5972020-05-08T20:09:03 *** Guest41060 has left #bitcoin-core-dev
5982020-05-08T20:09:34 *** Guest41060 has joined #bitcoin-core-dev
5992020-05-08T20:11:57 <jnewbery> Does anyone know what this failure in appveyor means: https://ci.appveyor.com/project/DrahtBot/bitcoin/builds/32747418 ? I tried rerunning and it's happened twice in a row
6002020-05-08T20:16:16 <sipa> where is _ defined?
6012020-05-08T20:16:19 <sipa> it's kinda hard to grep for
6022020-05-08T20:17:02 <sipa> oh, got it
6032020-05-08T20:17:06 <sipa> util/translation.h
6042020-05-08T20:17:25 <sipa> i'm confused why this code compiles at all (outside of appveyor)
6052020-05-08T20:17:36 <sipa> oh no
6062020-05-08T20:18:06 <sipa> _ returns a bilingual_string, InitError takes a bilingual string... why is appveyor complaining that it's being passed an std::string?
6072020-05-08T20:26:06 *** Guyver2 has quit IRC
6082020-05-08T20:26:52 *** molz_ has quit IRC
6092020-05-08T20:27:11 *** molz_ has joined #bitcoin-core-dev
6102020-05-08T20:28:34 <jnewbery> I'm going to try rebasing on master. There were changes merged in #16224, but I don't see why that should affect my branch
6112020-05-08T20:28:36 <gribble> https://github.com/bitcoin/bitcoin/issues/16224 | gui: Bilingual GUI error messages by hebasto · Pull Request #16224 · bitcoin/bitcoin · GitHub
6122020-05-08T20:29:18 <sipa> ah, i was just checking master
6132020-05-08T20:30:34 <jnewbery> I have to say that fighting against our CIs is really painful. It seems like that's where I've spent most of my time for this PR.
6142020-05-08T20:33:25 *** jarthur has quit IRC
6152020-05-08T20:35:12 *** sdaftuar has quit IRC
6162020-05-08T20:40:54 *** sdaftuar has joined #bitcoin-core-dev
6172020-05-08T20:40:59 *** Dean_Guss has quit IRC
6182020-05-08T20:41:20 <jnewbery> ok, it was a silent merge conflict with 16224. Thanks to jonatack for pointing me in the right direction
6192020-05-08T20:41:53 *** molz_ has quit IRC
6202020-05-08T20:43:56 <sipa> jnewbery: re compatibility...i think for backward compatibility we essentially want to be able to load any old wallet file, back to 0.1... but for very far back formats i think it's fine if that needs an explicit conversion step first (possibly using wallet-tool or something similar)
6212020-05-08T20:45:02 *** vasild has quit IRC
6222020-05-08T20:45:14 *** vasild has joined #bitcoin-core-dev
6232020-05-08T20:45:17 *** promag_ has joined #bitcoin-core-dev
6242020-05-08T20:45:59 *** promag has quit IRC
6252020-05-08T20:46:00 <sipa> 2 major releases is not much though...
6262020-05-08T20:46:37 <jnewbery> sipa: what if that explicit convertion step is "load it on v0.xx first"?
6272020-05-08T20:46:40 *** promag has joined #bitcoin-core-dev
6282020-05-08T20:47:08 *** Guest41060 is now known as BlueMatt
6292020-05-08T20:47:29 <jnewbery> I'd argue that if we don't test something we can't really claim that we support it.
6302020-05-08T20:48:07 <sipa> then we should test it :)
6312020-05-08T20:49:13 *** promag_ has quit IRC
6322020-05-08T20:49:32 <jnewbery> Maybe, but it's probably not worth the developer time. I'm personally not interested in writing tests for v0.1 wallets.
6332020-05-08T20:49:46 *** promag_ has joined #bitcoin-core-dev
6342020-05-08T20:51:32 *** promag has quit IRC
6352020-05-08T20:52:14 <sipa> fair, but there is a difference between supporting and not gratuitously breaking
6362020-05-08T20:52:31 *** mol has joined #bitcoin-core-dev
6372020-05-08T20:52:39 *** promag has joined #bitcoin-core-dev
6382020-05-08T20:53:44 *** promag_ has quit IRC
6392020-05-08T20:53:56 *** promag_ has joined #bitcoin-core-dev
6402020-05-08T20:53:57 <sipa> i think it'd be unfortunate if someone needs to jump through hoops like running already-unsupported versions just to get access to a years-old wallet file
6412020-05-08T20:54:10 <jnewbery> If it's to improve code quality and remove debt, it's not gratuitous
6422020-05-08T20:54:25 <jnewbery> unfortunate but not the end of the world
6432020-05-08T20:55:14 <sipa> ok, let me then be more clear: i think it's ok if someone with a wallet file from 2012 has to go through some hoops to load a wallet
6442020-05-08T20:55:22 <sipa> i don't think that's ok for a wallet from 2017
6452020-05-08T20:55:55 <sipa> these things can be very long lived
6462020-05-08T20:56:01 <sipa> and sometimes forgotten about
6472020-05-08T20:56:17 <jnewbery> that also seems reasonable to me. 2 versions is maybe too aggresive.
6482020-05-08T20:58:01 <sipa> for forward compatibility i think shorter timelines are acceptable; nobody expects being able to downgrade to years old software
6492020-05-08T20:58:25 <sipa> but being able to roll back after an incompatibility introduced in one version vs the next is very desirable
6502020-05-08T20:59:56 <jnewbery> yes, I think 1 or 2 is acceptable for forward compatibility
6512020-05-08T21:00:02 *** stranger64 has quit IRC
6522020-05-08T21:02:12 *** promag has quit IRC
6532020-05-08T21:03:12 *** promag_ has quit IRC
6542020-05-08T21:03:48 *** promag has joined #bitcoin-core-dev
6552020-05-08T21:12:44 *** promag_ has joined #bitcoin-core-dev
6562020-05-08T21:13:11 *** promag has quit IRC
6572020-05-08T21:13:26 *** promag has joined #bitcoin-core-dev
6582020-05-08T21:17:41 *** promag_ has quit IRC
6592020-05-08T21:19:15 *** promag has quit IRC
6602020-05-08T21:19:51 *** promag has joined #bitcoin-core-dev
6612020-05-08T21:20:55 *** Linoleum has joined #bitcoin-core-dev
6622020-05-08T21:22:35 *** promag has quit IRC
6632020-05-08T21:22:48 *** promag has joined #bitcoin-core-dev
6642020-05-08T21:26:24 <sipa> when using the snap package, is it expected that the binaries are called bitcoin-core.daemon bitcoin-core.cli ... instead of the usual ones?
6652020-05-08T21:31:13 *** manantial has quit IRC
6662020-05-08T21:36:14 <sipa> fwiw, sqlite 3.6.10 (compiled with everything --disable-...) from 2009 can open a database i created with 3.31.1 (compiled with every --enable-...) fine
6672020-05-08T21:36:49 <sipa> 3.6.10 because it's the earliest available in the git clone i'm using
6682020-05-08T21:56:55 <sipa> also, there is a db creation option that guarantees compatibility with 3.0.0
6692020-05-08T21:58:02 <sipa> otherwise it seems forward compatibility exists down to 3.3.0, except when newer extensions are explicitly used
6702020-05-08T22:01:26 *** promag_ has joined #bitcoin-core-dev
6712020-05-08T22:01:53 <luke-jr> [21:56:55] <sipa> also, there is a db creation option that guarantees compatibility with 3.0.0 <-- nice
6722020-05-08T22:02:25 <luke-jr> is there one that guarantees compatibility with the current stable version in major distros?
6732020-05-08T22:02:43 <luke-jr> (eg, if Core were compiled against some future version we can't anticipate)
6742020-05-08T22:02:53 <sipa> no, it seems there have not been any actual format changes since 3.3.0 in 2006
6752020-05-08T22:03:14 <sipa> only extension
6762020-05-08T22:03:17 <luke-jr> ok, so what we'd want is an option to force compat with 3.3
6772020-05-08T22:03:27 *** molakala has quit IRC
6782020-05-08T22:04:25 <luke-jr> if someone builds against some future sqlite 3.90, we'd want to be sure it remains compatible with what we're using now
6792020-05-08T22:04:30 *** emilengler has quit IRC
6802020-05-08T22:06:26 *** promag_ has quit IRC
6812020-05-08T22:06:48 *** molakala has joined #bitcoin-core-dev
6822020-05-08T22:11:13 *** jnewbery has quit IRC
6832020-05-08T22:13:28 *** bitcoin-git has joined #bitcoin-core-dev
6842020-05-08T22:13:29 <bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/5b24f6084ede...b55866969e24
6852020-05-08T22:13:29 <bitcoin-git> bitcoin/master 095bc9a Harris: fuzz: fix vector size problem in system fuzzer
6862020-05-08T22:13:30 <bitcoin-git> bitcoin/master b558669 MarcoFalke: Merge #18917: fuzz: fix vector size problem in system fuzzer
6872020-05-08T22:13:32 *** bitcoin-git has left #bitcoin-core-dev
6882020-05-08T22:13:48 *** bitcoin-git has joined #bitcoin-core-dev
6892020-05-08T22:13:48 <bitcoin-git> [bitcoin] MarcoFalke merged pull request #18917: fuzz: fix vector size problem in system fuzzer (master...fix-system-fuzzer) https://github.com/bitcoin/bitcoin/pull/18917
6902020-05-08T22:13:50 *** bitcoin-git has left #bitcoin-core-dev
6912020-05-08T22:14:58 *** molakala has quit IRC
6922020-05-08T22:16:53 *** Dean_Guss has joined #bitcoin-core-dev
6932020-05-08T22:29:33 *** justanotheruser has quit IRC
6942020-05-08T22:36:40 *** jnewbery has joined #bitcoin-core-dev
6952020-05-08T22:43:15 *** justanotheruser has joined #bitcoin-core-dev
6962020-05-08T22:44:45 *** IGHOR has quit IRC
6972020-05-08T22:45:04 *** IGHOR has joined #bitcoin-core-dev
6982020-05-08T22:52:19 *** dfmb_ has quit IRC
6992020-05-08T22:59:46 *** promag_ has joined #bitcoin-core-dev
7002020-05-08T22:59:48 *** mdunnio has quit IRC
7012020-05-08T23:02:18 *** promag_ has quit IRC
7022020-05-08T23:03:51 *** dfmb_ has joined #bitcoin-core-dev
7032020-05-08T23:03:51 *** dfmb__ has joined #bitcoin-core-dev
7042020-05-08T23:12:35 *** bitcoin-git has joined #bitcoin-core-dev
7052020-05-08T23:12:36 <bitcoin-git> [bitcoin] achow101 opened pull request #18918: wallet: Move salvagewallet into wallettool (master...wallettool-salvagewallet) https://github.com/bitcoin/bitcoin/pull/18918
7062020-05-08T23:12:37 *** bitcoin-git has left #bitcoin-core-dev
7072020-05-08T23:13:55 *** bitcoin-git has joined #bitcoin-core-dev
7082020-05-08T23:13:56 <bitcoin-git> [bitcoin] MarcoFalke opened pull request #18919: test: Add gettransaction test for "coin-join" tx (master...2005-testCoinJoinGetTx) https://github.com/bitcoin/bitcoin/pull/18919
7092020-05-08T23:14:07 *** bitcoin-git has left #bitcoin-core-dev
7102020-05-08T23:16:32 *** promag has quit IRC
7112020-05-08T23:17:04 *** promag has joined #bitcoin-core-dev
7122020-05-08T23:19:23 *** Dean_Guss has quit IRC
7132020-05-08T23:24:15 *** Dean_Guss has joined #bitcoin-core-dev
7142020-05-08T23:33:06 *** bitcoin-git has joined #bitcoin-core-dev
7152020-05-08T23:33:06 <bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/b55866969e24...376294cde6b1
7162020-05-08T23:33:07 <bitcoin-git> bitcoin/master fae153b MarcoFalke: test: Fix verack race to avoid intermittent test failures
7172020-05-08T23:33:07 <bitcoin-git> bitcoin/master 376294c MarcoFalke: Merge #18866: test: Fix verack race to avoid intermittent test failures
7182020-05-08T23:33:09 *** bitcoin-git has left #bitcoin-core-dev
7192020-05-08T23:33:26 *** bitcoin-git has joined #bitcoin-core-dev
7202020-05-08T23:33:26 <bitcoin-git> [bitcoin] MarcoFalke merged pull request #18866: test: Fix verack race to avoid intermittent test failures (master...2005-qaVerackRace) https://github.com/bitcoin/bitcoin/pull/18866
7212020-05-08T23:33:28 *** bitcoin-git has left #bitcoin-core-dev
7222020-05-08T23:47:07 <sipa> MarcoFalke: i don't think issues should be closed because nobody is working on them
7232020-05-08T23:47:08 *** Chris_Stewart_5 has quit IRC
7242020-05-08T23:47:19 <sipa> or at least, not only for that reason
7252020-05-08T23:54:17 *** proofofkeags has quit IRC