12020-05-07T00:00:03 *** alexsuraci has quit IRC
22020-05-07T00:00:33 *** promag_ has quit IRC
32020-05-07T00:02:53 *** mol has quit IRC
42020-05-07T00:03:21 *** mol has joined #bitcoin-core-dev
52020-05-07T00:05:32 *** promag_ has joined #bitcoin-core-dev
62020-05-07T00:07:00 *** dfmb_ has quit IRC
72020-05-07T00:12:49 *** proofofkeags has quit IRC
82020-05-07T00:13:22 *** proofofkeags has joined #bitcoin-core-dev
92020-05-07T00:16:46 *** mdunnio has quit IRC
102020-05-07T00:17:16 *** proofofkeags has quit IRC
112020-05-07T00:17:30 *** proofofkeags has joined #bitcoin-core-dev
122020-05-07T00:22:01 *** r251d has quit IRC
132020-05-07T00:22:05 *** SchwarzeLocke has joined #bitcoin-core-dev
142020-05-07T00:31:58 *** proofofkeags has quit IRC
152020-05-07T00:32:04 *** mdunnio has joined #bitcoin-core-dev
162020-05-07T00:32:32 *** proofofkeags has joined #bitcoin-core-dev
172020-05-07T00:34:12 *** lightlike has quit IRC
182020-05-07T00:37:06 *** proofofkeags has quit IRC
192020-05-07T00:58:57 *** promag_ has quit IRC
202020-05-07T01:03:57 *** mdunnio has quit IRC
212020-05-07T01:04:09 *** proofofkeags has joined #bitcoin-core-dev
222020-05-07T01:04:26 *** promag_ has joined #bitcoin-core-dev
232020-05-07T01:08:28 *** proofofkeags has quit IRC
242020-05-07T01:09:06 *** promag_ has quit IRC
252020-05-07T01:10:51 *** Chris_Stewart_5 has quit IRC
262020-05-07T01:13:31 *** Chris_Stewart_5 has joined #bitcoin-core-dev
272020-05-07T01:19:00 *** promag has quit IRC
282020-05-07T01:19:33 *** promag has joined #bitcoin-core-dev
292020-05-07T01:23:55 *** promag has quit IRC
302020-05-07T01:30:34 *** SiAnDoG has quit IRC
312020-05-07T01:36:41 *** tryphe_ is now known as tryphe
322020-05-07T01:39:59 *** proofofkeags has joined #bitcoin-core-dev
332020-05-07T01:44:28 *** proofofkeags has quit IRC
342020-05-07T01:47:55 *** bitcoin-git has joined #bitcoin-core-dev
352020-05-07T01:47:55 <bitcoin-git> [bitcoin] luke-jr opened pull request #18902: Bugfix: Only use git for build info if the repository is actually the right one (master...fix_gitdir_again) https://github.com/bitcoin/bitcoin/pull/18902
362020-05-07T01:47:56 *** bitcoin-git has left #bitcoin-core-dev
372020-05-07T01:53:03 *** Emcy has quit IRC
382020-05-07T01:59:23 *** Emcy has joined #bitcoin-core-dev
392020-05-07T02:17:34 *** mol has quit IRC
402020-05-07T02:50:02 *** proofofkeags has joined #bitcoin-core-dev
412020-05-07T02:57:20 *** surja795 has quit IRC
422020-05-07T03:00:01 *** SchwarzeLocke has quit IRC
432020-05-07T03:00:32 *** surja795 has joined #bitcoin-core-dev
442020-05-07T03:20:19 *** surja795 has quit IRC
452020-05-07T03:21:17 *** carldani1 has joined #bitcoin-core-dev
462020-05-07T03:30:47 *** surja795 has joined #bitcoin-core-dev
472020-05-07T03:35:50 *** surja795 has quit IRC
482020-05-07T03:35:54 *** bitcoin-git has joined #bitcoin-core-dev
492020-05-07T03:35:54 <bitcoin-git> [bitcoin] fanquake opened pull request #18903: test: fix TEST_PREVIOUS_RELEASES check (master...getenv_defaults_to_None) https://github.com/bitcoin/bitcoin/pull/18903
502020-05-07T03:35:55 *** bitcoin-git has left #bitcoin-core-dev
512020-05-07T03:39:16 *** proofofkeags has quit IRC
522020-05-07T03:45:22 *** SiAnDoG has joined #bitcoin-core-dev
532020-05-07T03:54:53 *** geeker has joined #bitcoin-core-dev
542020-05-07T04:01:16 *** SiAnDoG has quit IRC
552020-05-07T04:01:36 *** SiAnDoG has joined #bitcoin-core-dev
562020-05-07T04:10:32 *** per has quit IRC
572020-05-07T04:15:17 *** per has joined #bitcoin-core-dev
582020-05-07T04:18:40 *** mol has joined #bitcoin-core-dev
592020-05-07T04:19:37 *** proofofkeags has joined #bitcoin-core-dev
602020-05-07T04:19:55 *** vasild_ has joined #bitcoin-core-dev
612020-05-07T04:23:03 *** vasild has quit IRC
622020-05-07T04:23:04 *** vasild_ is now known as vasild
632020-05-07T04:24:02 *** proofofkeags has quit IRC
642020-05-07T04:24:47 *** stackingcore21 has quit IRC
652020-05-07T04:24:57 *** stackingcore21 has joined #bitcoin-core-dev
662020-05-07T04:32:37 *** mol_ has joined #bitcoin-core-dev
672020-05-07T04:35:10 *** jarthur_ has joined #bitcoin-core-dev
682020-05-07T04:35:58 *** mol has quit IRC
692020-05-07T04:38:07 *** jarthur has quit IRC
702020-05-07T04:44:39 *** jarthur_ has quit IRC
712020-05-07T04:51:30 *** molz_ has joined #bitcoin-core-dev
722020-05-07T04:53:43 *** per has quit IRC
732020-05-07T04:54:37 *** mol_ has quit IRC
742020-05-07T04:58:59 *** mol_ has joined #bitcoin-core-dev
752020-05-07T04:59:08 *** proofofkeags has joined #bitcoin-core-dev
762020-05-07T05:00:21 *** DeanGuss has quit IRC
772020-05-07T05:00:52 *** DeanGuss has joined #bitcoin-core-dev
782020-05-07T05:02:26 *** molz_ has quit IRC
792020-05-07T05:03:18 *** mol has joined #bitcoin-core-dev
802020-05-07T05:03:43 *** proofofkeags has quit IRC
812020-05-07T05:06:53 *** mol_ has quit IRC
822020-05-07T05:18:23 *** promag has joined #bitcoin-core-dev
832020-05-07T05:23:46 *** geeker_ has joined #bitcoin-core-dev
842020-05-07T05:23:47 *** geeker has quit IRC
852020-05-07T05:30:48 *** jarthur has joined #bitcoin-core-dev
862020-05-07T05:31:04 *** geeker_ has quit IRC
872020-05-07T05:40:11 *** frosted_bird has joined #bitcoin-core-dev
882020-05-07T05:45:23 *** jarthur has quit IRC
892020-05-07T05:46:04 *** frosted_bird has quit IRC
902020-05-07T06:00:02 *** carldani1 has quit IRC
912020-05-07T06:02:43 *** jarthur has joined #bitcoin-core-dev
922020-05-07T06:12:55 *** guest534543 has joined #bitcoin-core-dev
932020-05-07T06:16:58 *** Kiminuo has quit IRC
942020-05-07T06:19:12 *** promag has quit IRC
952020-05-07T06:20:58 *** jarthur has quit IRC
962020-05-07T06:22:10 *** panda1 has joined #bitcoin-core-dev
972020-05-07T06:24:29 *** emilengler has joined #bitcoin-core-dev
982020-05-07T06:26:59 *** jarthur has joined #bitcoin-core-dev
992020-05-07T06:38:01 *** DeanGuss has quit IRC
1002020-05-07T06:38:16 *** DeanGuss has joined #bitcoin-core-dev
1012020-05-07T06:46:54 *** DeanGuss has quit IRC
1022020-05-07T06:47:03 *** DeanGuss has joined #bitcoin-core-dev
1032020-05-07T06:47:33 *** jarthur has quit IRC
1042020-05-07T06:48:25 *** jarthur has joined #bitcoin-core-dev
1052020-05-07T06:48:28 *** bitcoin-git has joined #bitcoin-core-dev
1062020-05-07T06:48:28 <bitcoin-git> [bitcoin] bvbfan opened pull request #18904: Don't call lsn_reset in periodic flush (master...lsn_reset_fix) https://github.com/bitcoin/bitcoin/pull/18904
1072020-05-07T06:48:29 *** bitcoin-git has left #bitcoin-core-dev
1082020-05-07T06:56:02 *** jarthur has quit IRC
1092020-05-07T06:59:54 *** proofofkeags has joined #bitcoin-core-dev
1102020-05-07T07:02:38 *** jarthur has joined #bitcoin-core-dev
1112020-05-07T07:04:34 *** proofofkeags has quit IRC
1122020-05-07T07:04:40 *** jarthur has quit IRC
1132020-05-07T07:05:15 *** jarthur has joined #bitcoin-core-dev
1142020-05-07T07:09:58 *** jarthur has quit IRC
1152020-05-07T07:30:42 *** michaelfolkson has joined #bitcoin-core-dev
1162020-05-07T07:32:11 *** michaelfolkson has quit IRC
1172020-05-07T07:38:46 *** bitcoin-git has joined #bitcoin-core-dev
1182020-05-07T07:38:46 <bitcoin-git> [bitcoin] jonasschnelli closed pull request #14046: net: Refactor message parsing (CNetMessage), adds flexibility (master...2018/08/bip151_pre_refactor) https://github.com/bitcoin/bitcoin/pull/14046
1192020-05-07T07:38:47 *** bitcoin-git has left #bitcoin-core-dev
1202020-05-07T07:42:36 *** bitcoin-git has joined #bitcoin-core-dev
1212020-05-07T07:42:36 <bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/7bcc42b4035b...3b1e289248dc
1222020-05-07T07:42:37 <bitcoin-git> bitcoin/master a029805 fanquake: build: remove -Qunused-arguments workaround for clang + ccache
1232020-05-07T07:42:38 <bitcoin-git> bitcoin/master 3b1e289 fanquake: Merge #18535: build: remove -Qunused-arguments workaround for clang + ccac...
1242020-05-07T07:42:39 *** bitcoin-git has left #bitcoin-core-dev
1252020-05-07T07:43:05 *** bitcoin-git has joined #bitcoin-core-dev
1262020-05-07T07:43:06 <bitcoin-git> [bitcoin] fanquake merged pull request #18535: build: remove -Qunused-arguments workaround for clang + ccache (master...dont_quash_unused_driver_arguments) https://github.com/bitcoin/bitcoin/pull/18535
1272020-05-07T07:43:07 *** bitcoin-git has left #bitcoin-core-dev
1282020-05-07T07:43:48 *** michaelfolkson has joined #bitcoin-core-dev
1292020-05-07T07:46:38 *** michaelfolkson has quit IRC
1302020-05-07T07:54:33 *** mol_ has joined #bitcoin-core-dev
1312020-05-07T07:56:31 *** inpharmaticist[m has quit IRC
1322020-05-07T07:56:32 *** peltre has quit IRC
1332020-05-07T07:56:32 *** endogenic has quit IRC
1342020-05-07T07:56:32 *** NicolasDorier has quit IRC
1352020-05-07T07:56:32 *** _flow_ has quit IRC
1362020-05-07T07:56:32 *** jkczyz has quit IRC
1372020-05-07T07:56:33 *** mr_burdell has quit IRC
1382020-05-07T07:57:53 *** mol has quit IRC
1392020-05-07T07:58:23 *** Guyver2 has joined #bitcoin-core-dev
1402020-05-07T08:01:28 *** inpharmaticist[m has joined #bitcoin-core-dev
1412020-05-07T08:01:28 *** peltre has joined #bitcoin-core-dev
1422020-05-07T08:01:28 *** endogenic has joined #bitcoin-core-dev
1432020-05-07T08:01:28 *** NicolasDorier has joined #bitcoin-core-dev
1442020-05-07T08:01:28 *** jkczyz has joined #bitcoin-core-dev
1452020-05-07T08:01:28 *** _flow_ has joined #bitcoin-core-dev
1462020-05-07T08:01:28 *** mr_burdell has joined #bitcoin-core-dev
1472020-05-07T08:02:38 *** michaelfolkson has joined #bitcoin-core-dev
1482020-05-07T08:02:42 *** michaelfolkson has quit IRC
1492020-05-07T08:07:24 *** marcoagner has joined #bitcoin-core-dev
1502020-05-07T08:23:01 *** roconnor has quit IRC
1512020-05-07T08:23:24 *** peltre has quit IRC
1522020-05-07T08:23:53 *** peltre has joined #bitcoin-core-dev
1532020-05-07T08:34:40 *** sipsorcery has joined #bitcoin-core-dev
1542020-05-07T08:38:19 *** promag has joined #bitcoin-core-dev
1552020-05-07T08:38:34 *** promag_ has joined #bitcoin-core-dev
1562020-05-07T08:38:34 <wumpus> luke-jr: maybe split out the add-prefix commit for now, that one's straightforward
1572020-05-07T08:49:15 *** guest534543 has quit IRC
1582020-05-07T09:00:01 *** panda1 has quit IRC
1592020-05-07T09:00:54 *** proofofkeags has joined #bitcoin-core-dev
1602020-05-07T09:05:37 *** proofofkeags has quit IRC
1612020-05-07T09:18:46 *** dfmb_ has joined #bitcoin-core-dev
1622020-05-07T09:20:06 *** promag has quit IRC
1632020-05-07T09:22:10 *** subdriven1 has joined #bitcoin-core-dev
1642020-05-07T09:39:49 *** mrostecki has quit IRC
1652020-05-07T09:39:49 *** thunderbiscuit[m has quit IRC
1662020-05-07T09:39:50 *** icota[m] has quit IRC
1672020-05-07T09:40:00 *** TheFuzzStone[m] has quit IRC
1682020-05-07T09:40:34 *** inpharmaticist[m has quit IRC
1692020-05-07T09:49:25 *** AaronvanW has joined #bitcoin-core-dev
1702020-05-07T09:51:04 *** promag has joined #bitcoin-core-dev
1712020-05-07T09:53:58 *** inpharmaticist[m has joined #bitcoin-core-dev
1722020-05-07T09:55:41 *** promag has quit IRC
1732020-05-07T10:01:22 *** icota[m] has joined #bitcoin-core-dev
1742020-05-07T10:01:22 *** mrostecki has joined #bitcoin-core-dev
1752020-05-07T10:01:22 *** TheFuzzStone[m] has joined #bitcoin-core-dev
1762020-05-07T10:01:29 *** thunderbiscuit[m has joined #bitcoin-core-dev
1772020-05-07T10:14:49 *** surja795 has joined #bitcoin-core-dev
1782020-05-07T10:19:17 *** surja795 has quit IRC
1792020-05-07T10:19:50 *** surja795 has joined #bitcoin-core-dev
1802020-05-07T10:23:54 *** promag has joined #bitcoin-core-dev
1812020-05-07T10:24:18 *** surja795 has quit IRC
1822020-05-07T10:24:45 *** dfmbbtc has joined #bitcoin-core-dev
1832020-05-07T10:25:40 *** timothy has joined #bitcoin-core-dev
1842020-05-07T10:27:32 *** dfmb_ has quit IRC
1852020-05-07T10:32:02 *** justanotheruser has quit IRC
1862020-05-07T10:44:22 *** dfmb_btc has joined #bitcoin-core-dev
1872020-05-07T10:44:41 *** jb55 has quit IRC
1882020-05-07T10:45:08 *** jb55 has joined #bitcoin-core-dev
1892020-05-07T10:47:25 *** dfmbbtc has quit IRC
1902020-05-07T10:53:44 *** DeanGuss has quit IRC
1912020-05-07T11:01:26 *** promag has quit IRC
1922020-05-07T11:03:34 *** molz_ has joined #bitcoin-core-dev
1932020-05-07T11:04:22 *** dfmbbtc has joined #bitcoin-core-dev
1942020-05-07T11:06:38 *** mol_ has quit IRC
1952020-05-07T11:07:58 *** dfmb_btc has quit IRC
1962020-05-07T11:24:20 *** dfmb_btc has joined #bitcoin-core-dev
1972020-05-07T11:27:47 *** dfmbbtc has quit IRC
1982020-05-07T11:36:34 *** braydonf has quit IRC
1992020-05-07T11:36:59 *** braydonf has joined #bitcoin-core-dev
2002020-05-07T11:49:13 *** surja795 has joined #bitcoin-core-dev
2012020-05-07T11:50:43 *** jonatack_ has joined #bitcoin-core-dev
2022020-05-07T11:53:54 *** surja795 has quit IRC
2032020-05-07T11:54:13 *** jonatack has quit IRC
2042020-05-07T11:58:14 *** bitcoin-git has joined #bitcoin-core-dev
2052020-05-07T11:58:14 <bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/3b1e289248dc...c1cd2b5a97f4
2062020-05-07T11:58:15 <bitcoin-git> bitcoin/master fa082d0 MarcoFalke: travis: Remove valgrind
2072020-05-07T11:58:15 <bitcoin-git> bitcoin/master c1cd2b5 MarcoFalke: Merge #18899: travis: Remove valgrind
2082020-05-07T11:58:17 *** bitcoin-git has left #bitcoin-core-dev
2092020-05-07T11:58:34 *** bitcoin-git has joined #bitcoin-core-dev
2102020-05-07T11:58:34 <bitcoin-git> [bitcoin] MarcoFalke merged pull request #18899: travis: Remove valgrind (master...2005-RemoveTravis) https://github.com/bitcoin/bitcoin/pull/18899
2112020-05-07T11:58:39 *** bitcoin-git has left #bitcoin-core-dev
2122020-05-07T12:00:00 *** per has joined #bitcoin-core-dev
2132020-05-07T12:00:02 *** subdriven1 has quit IRC
2142020-05-07T12:04:27 *** dfmbbtc has joined #bitcoin-core-dev
2152020-05-07T12:06:47 *** theStack has joined #bitcoin-core-dev
2162020-05-07T12:07:27 *** dfmb_btc has quit IRC
2172020-05-07T12:14:37 *** dfmb_btc has joined #bitcoin-core-dev
2182020-05-07T12:17:26 *** dfmbbtc has quit IRC
2192020-05-07T12:18:20 *** bpalmer1 has joined #bitcoin-core-dev
2202020-05-07T12:18:27 *** Kiminuo has joined #bitcoin-core-dev
2212020-05-07T12:22:51 *** Deacyde has quit IRC
2222020-05-07T12:23:31 *** mol_ has joined #bitcoin-core-dev
2232020-05-07T12:24:29 *** dfmbbtc has joined #bitcoin-core-dev
2242020-05-07T12:24:52 *** Kiminuo has quit IRC
2252020-05-07T12:26:14 *** molz_ has quit IRC
2262020-05-07T12:27:26 *** dfmb_btc has quit IRC
2272020-05-07T12:38:47 *** Emcy has quit IRC
2282020-05-07T12:40:15 *** Emcy has joined #bitcoin-core-dev
2292020-05-07T12:45:10 *** Highway61 has joined #bitcoin-core-dev
2302020-05-07T12:47:33 <luke-jr> wumpus: I'd agree, but in light of the regression to #7522, it looks like we either need to do #18902 (which builds on the re-tar-ing), or restore the build.h hack
2312020-05-07T12:47:35 <gribble> https://github.com/bitcoin/bitcoin/issues/18902 | Bugfix: Only use git for build info if the repository is actually the right one by luke-jr · Pull Request #18902 · bitcoin/bitcoin · GitHub
2322020-05-07T12:47:37 <gribble> https://github.com/bitcoin/bitcoin/issues/7522 | Bugfix: Only use git for build info if the repository is actually the right one by luke-jr · Pull Request #7522 · bitcoin/bitcoin · GitHub
2332020-05-07T12:58:10 *** surja795 has joined #bitcoin-core-dev
2342020-05-07T13:00:49 *** bitcoin-git has joined #bitcoin-core-dev
2352020-05-07T13:00:49 <bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/c1cd2b5a97f4...56611b0e2405
2362020-05-07T13:00:50 <bitcoin-git> bitcoin/master 1e94a2b Russell Yanofsky: depends: Add --sysroot option to mac os native compile flags
2372020-05-07T13:00:51 <bitcoin-git> bitcoin/master 56611b0 fanquake: Merge #18743: depends: Add --sysroot option to mac os native compile flags...
2382020-05-07T13:00:52 *** bitcoin-git has left #bitcoin-core-dev
2392020-05-07T13:01:10 *** bitcoin-git has joined #bitcoin-core-dev
2402020-05-07T13:01:10 <bitcoin-git> [bitcoin] fanquake merged pull request #18743: depends: Add --sysroot option to mac os native compile flags (master...pr/sysroot) https://github.com/bitcoin/bitcoin/pull/18743
2412020-05-07T13:01:12 *** bitcoin-git has left #bitcoin-core-dev
2422020-05-07T13:03:09 *** surja795 has quit IRC
2432020-05-07T13:03:42 *** IGHOR has quit IRC
2442020-05-07T13:09:22 *** IGHOR has joined #bitcoin-core-dev
2452020-05-07T13:14:54 *** molakala has joined #bitcoin-core-dev
2462020-05-07T13:27:59 *** roconnor has joined #bitcoin-core-dev
2472020-05-07T13:33:14 <hebasto> luke-jr: what is wrong with "regression to #7522"? what builds fail?
2482020-05-07T13:33:17 <gribble> https://github.com/bitcoin/bitcoin/issues/7522 | Bugfix: Only use git for build info if the repository is actually the right one by luke-jr · Pull Request #7522 · bitcoin/bitcoin · GitHub
2492020-05-07T13:34:37 <luke-jr> hebasto: builds will get the wrong version/hash embedded, from unrelated git repos, and access unrelated git data outside the source code root
2502020-05-07T13:35:11 <hebasto> luke-jr: gitian?
2512020-05-07T13:35:19 <luke-jr> no, not gitian
2522020-05-07T13:35:40 <luke-jr> eg, https://bugs.gentoo.org/476294
2532020-05-07T13:36:51 <luke-jr> relying on broken behaviour in gitian is not a good idea anyway
2542020-05-07T13:37:27 <hebasto> IIUC, it is related to package maintaining?
2552020-05-07T13:38:48 <luke-jr> hebasto: it's related to building non-git source, within a subdirectory of a foreign git repo
2562020-05-07T13:39:09 <luke-jr> even without the sandboxing Gentoo used to detect it, it would still do the wrong thing
2572020-05-07T13:39:33 <luke-jr> you were able to remove the build.h hack successfully, *because* you were relying on this incorrect behaviour
2582020-05-07T13:45:49 *** mol_ has quit IRC
2592020-05-07T13:47:56 <hebasto> luke-jr: I see now...
2602020-05-07T13:48:29 *** proofofkeags has joined #bitcoin-core-dev
2612020-05-07T13:56:31 <luke-jr> hebasto: so in light of that, any ideas for doing this better? âº
2622020-05-07T13:59:08 *** mdunnio has joined #bitcoin-core-dev
2632020-05-07T14:00:00 *** brakmic has joined #bitcoin-core-dev
2642020-05-07T14:00:16 *** bitcoin-git has joined #bitcoin-core-dev
2652020-05-07T14:00:17 <bitcoin-git> [bitcoin] MarcoFalke opened pull request #18905: travis: Remove s390x (master...2005-removeTravis) https://github.com/bitcoin/bitcoin/pull/18905
2662020-05-07T14:00:18 *** bitcoin-git has left #bitcoin-core-dev
2672020-05-07T14:01:19 <hebasto> luke-jr: still looking for...
2682020-05-07T14:08:52 <luke-jr> if only git substitutions let you do a tag name..
2692020-05-07T14:09:17 <hebasto> BITCOIN_GENBUILD_NO_GIT variable?
2702020-05-07T14:28:53 *** bitcoin-git has joined #bitcoin-core-dev
2712020-05-07T14:28:54 <bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/56611b0e2405...f54753293fe7
2722020-05-07T14:28:54 <bitcoin-git> bitcoin/master 8c705ff MarcoFalke: travis: Remove s390x
2732020-05-07T14:28:55 <bitcoin-git> bitcoin/master f547532 MarcoFalke: Merge #18905: travis: Remove s390x
2742020-05-07T14:28:56 *** bitcoin-git has left #bitcoin-core-dev
2752020-05-07T14:29:13 *** bitcoin-git has joined #bitcoin-core-dev
2762020-05-07T14:29:14 <bitcoin-git> [bitcoin] MarcoFalke merged pull request #18905: travis: Remove s390x (master...2005-removeTravis) https://github.com/bitcoin/bitcoin/pull/18905
2772020-05-07T14:29:15 *** bitcoin-git has left #bitcoin-core-dev
2782020-05-07T14:31:25 *** promag has joined #bitcoin-core-dev
2792020-05-07T14:43:25 <luke-jr> hebasto: ?
2802020-05-07T14:45:00 *** mol has joined #bitcoin-core-dev
2812020-05-07T14:45:15 <hebasto> could setting BITCOIN_GENBUILD_NO_GIT=1 prevent from getting version/hash from unrelated git repos?
2822020-05-07T14:46:53 <luke-jr> yes, but shouldn't be needed
2832020-05-07T14:49:00 *** proofofkeags has quit IRC
2842020-05-07T14:49:22 <hebasto> it seems the simplest solution along with your commit https://github.com/bitcoin/bitcoin/pull/18818/commits/b9054bce073620f9bf8ff99cde23056e93012b53
2852020-05-07T14:50:15 <hebasto> I mean w.r.t. 0.20 release process
2862020-05-07T14:51:10 <luke-jr> users needing extra steps to workaround a regression isn't really a solution
2872020-05-07T14:54:29 *** dfmb_btc has joined #bitcoin-core-dev
2882020-05-07T14:56:00 <hebasto> isn't BITCOIN_GENBUILD_NO_GIT intended for this?
2892020-05-07T14:56:20 <hebasto> than extra step could be documented
2902020-05-07T14:56:22 *** dfmb_btc has joined #bitcoin-core-dev
2912020-05-07T14:57:33 <hebasto> besides, building within a subdirectory of a foreign git repo seems not a common case
2922020-05-07T14:57:48 *** dfmbbtc has quit IRC
2932020-05-07T14:58:29 <luke-jr> hebasto: no, it isn't.
2942020-05-07T14:58:43 <luke-jr> just because it's uncommon doesn't mean we should do the wrong thing..
2952020-05-07T15:00:01 *** bpalmer1 has quit IRC
2962020-05-07T15:00:51 *** proofofkeags has joined #bitcoin-core-dev
2972020-05-07T15:03:19 <hebasto> if not this case, what are other usecases for BITCOIN_GENBUILD_NO_GIT ?
2982020-05-07T15:04:20 *** dfmbbtc has joined #bitcoin-core-dev
2992020-05-07T15:05:30 *** proofofkeags has quit IRC
3002020-05-07T15:05:49 <luke-jr> hebasto: if for some reason the user doesn't want git called at all
3012020-05-07T15:07:25 *** dfmb_btc has quit IRC
3022020-05-07T15:11:55 *** michaelfolkson has joined #bitcoin-core-dev
3032020-05-07T15:12:42 *** jarthur has joined #bitcoin-core-dev
3042020-05-07T15:18:48 *** promag has quit IRC
3052020-05-07T15:25:44 *** michaelfolkson has quit IRC
3062020-05-07T15:26:32 *** jarthur has quit IRC
3072020-05-07T15:26:39 *** michaelfolkson has joined #bitcoin-core-dev
3082020-05-07T15:27:09 *** jarthur has joined #bitcoin-core-dev
3092020-05-07T15:32:39 *** jarthur has quit IRC
3102020-05-07T15:32:52 *** jarthur has joined #bitcoin-core-dev
3112020-05-07T15:33:18 *** surja795 has joined #bitcoin-core-dev
3122020-05-07T15:37:00 *** agrotronic has joined #bitcoin-core-dev
3132020-05-07T15:37:55 *** surja795 has quit IRC
3142020-05-07T15:42:56 *** kljasdfvv has quit IRC
3152020-05-07T15:45:26 <achow101> luke-jr: what do you do for bdb for the ppa?
3162020-05-07T15:49:07 *** Talkless has joined #bitcoin-core-dev
3172020-05-07T15:51:01 <luke-jr> achow101: links to system db4.8
3182020-05-07T15:52:30 *** kers has joined #bitcoin-core-dev
3192020-05-07T15:52:41 <luke-jr> which is also a package provided by the ppa
3202020-05-07T15:54:44 *** Guyver2_ has joined #bitcoin-core-dev
3212020-05-07T15:57:14 *** Guyver2 has quit IRC
3222020-05-07T15:58:39 *** promag has joined #bitcoin-core-dev
3232020-05-07T15:59:28 *** andrewtoth_ has joined #bitcoin-core-dev
3242020-05-07T15:59:43 *** andrewtoth has quit IRC
3252020-05-07T16:00:04 *** andrewtoth_ has quit IRC
3262020-05-07T16:00:17 *** proofofkeags has joined #bitcoin-core-dev
3272020-05-07T16:02:34 *** michaelf_ has joined #bitcoin-core-dev
3282020-05-07T16:03:14 *** promag has quit IRC
3292020-05-07T16:04:06 *** michaelfolkson has quit IRC
3302020-05-07T16:19:56 *** vasild_ has joined #bitcoin-core-dev
3312020-05-07T16:20:33 *** jarthur_ has joined #bitcoin-core-dev
3322020-05-07T16:20:43 *** agrotronic has quit IRC
3332020-05-07T16:21:06 *** dfmbbtc has quit IRC
3342020-05-07T16:21:35 *** dfmbbtc has joined #bitcoin-core-dev
3352020-05-07T16:23:03 *** vasild has quit IRC
3362020-05-07T16:23:04 *** vasild_ is now known as vasild
3372020-05-07T16:23:53 *** jarthur has quit IRC
3382020-05-07T16:24:34 *** dfmb_btc has joined #bitcoin-core-dev
3392020-05-07T16:26:18 *** jarthur_ has quit IRC
3402020-05-07T16:27:56 *** dfmbbtc has quit IRC
3412020-05-07T16:38:51 *** Guyver2_ is now known as Guyver2
3422020-05-07T16:40:33 *** jarthur has joined #bitcoin-core-dev
3432020-05-07T16:41:32 *** promag has joined #bitcoin-core-dev
3442020-05-07T16:45:07 *** jarthur has quit IRC
3452020-05-07T16:45:33 *** jb55 has quit IRC
3462020-05-07T16:50:30 *** jb55 has joined #bitcoin-core-dev
3472020-05-07T16:50:43 *** mol has quit IRC
3482020-05-07T16:59:18 *** lightlike has joined #bitcoin-core-dev
3492020-05-07T17:01:20 *** jonatack_ has quit IRC
3502020-05-07T17:01:39 *** jonatack has joined #bitcoin-core-dev
3512020-05-07T17:01:46 *** michaelf_ has quit IRC
3522020-05-07T17:02:23 *** jarthur has joined #bitcoin-core-dev
3532020-05-07T17:04:22 *** michaelfolkson has joined #bitcoin-core-dev
3542020-05-07T17:11:17 *** jarthur_ has joined #bitcoin-core-dev
3552020-05-07T17:12:13 *** promag has quit IRC
3562020-05-07T17:14:52 *** jarthur has quit IRC
3572020-05-07T17:17:15 *** promag has joined #bitcoin-core-dev
3582020-05-07T17:25:12 *** proofofkeags has quit IRC
3592020-05-07T17:28:25 *** promag has quit IRC
3602020-05-07T17:28:59 *** promag has joined #bitcoin-core-dev
3612020-05-07T17:33:27 *** promag has quit IRC
3622020-05-07T17:34:26 *** AaronvanW has quit IRC
3632020-05-07T17:34:46 *** AaronvanW has joined #bitcoin-core-dev
3642020-05-07T17:36:48 *** tryphe_ has joined #bitcoin-core-dev
3652020-05-07T17:39:35 *** tryphe has quit IRC
3662020-05-07T17:44:18 *** proofofkeags has joined #bitcoin-core-dev
3672020-05-07T17:48:24 *** tryphe_ is now known as tryphe
3682020-05-07T17:49:39 *** mol has joined #bitcoin-core-dev
3692020-05-07T17:50:02 *** promag has joined #bitcoin-core-dev
3702020-05-07T17:53:32 *** timothy has quit IRC
3712020-05-07T18:00:01 *** kers has quit IRC
3722020-05-07T18:01:51 *** promag has quit IRC
3732020-05-07T18:03:23 *** bitdex has quit IRC
3742020-05-07T18:11:14 *** justanotheruser has joined #bitcoin-core-dev
3752020-05-07T18:14:20 *** jarthur_ has quit IRC
3762020-05-07T18:14:31 *** kvaciral has joined #bitcoin-core-dev
3772020-05-07T18:16:03 *** jarthur has joined #bitcoin-core-dev
3782020-05-07T18:16:48 *** jarthur has joined #bitcoin-core-dev
3792020-05-07T18:20:03 *** Dimlock has joined #bitcoin-core-dev
3802020-05-07T18:21:20 *** promag has joined #bitcoin-core-dev
3812020-05-07T18:26:06 *** michaelfolkson has quit IRC
3822020-05-07T18:32:07 *** promag has quit IRC
3832020-05-07T18:32:59 *** bitdex has joined #bitcoin-core-dev
3842020-05-07T18:33:27 *** michaelfolkson has joined #bitcoin-core-dev
3852020-05-07T18:35:26 *** bitcoin-git has joined #bitcoin-core-dev
3862020-05-07T18:35:27 <bitcoin-git> [bitcoin] achow101 opened pull request #18907: walletdb: Don't remove database transaction logs and instead error (master...dont-retry-bdbenv) https://github.com/bitcoin/bitcoin/pull/18907
3872020-05-07T18:35:27 *** bitcoin-git has left #bitcoin-core-dev
3882020-05-07T18:40:11 *** promag has joined #bitcoin-core-dev
3892020-05-07T18:41:48 *** nothingmuch has quit IRC
3902020-05-07T18:41:48 *** bsm117532 has quit IRC
3912020-05-07T18:41:57 *** theStack has quit IRC
3922020-05-07T18:47:11 *** promag has quit IRC
3932020-05-07T18:47:25 *** promag_ is now known as promag
3942020-05-07T18:47:28 <promag> I can't be in the meeting, I think #18578 and #18894 should be for 0.20
3952020-05-07T18:47:30 <gribble> https://github.com/bitcoin/bitcoin/issues/18578 | gui: Fix leak in CoinControlDialog::updateView by promag · Pull Request #18578 · bitcoin/bitcoin · GitHub
3962020-05-07T18:47:31 <gribble> https://github.com/bitcoin/bitcoin/issues/18894 | gui: Fix manual coin control with multiple wallets loaded by promag · Pull Request #18894 · bitcoin/bitcoin · GitHub
3972020-05-07T18:47:48 *** promag_ has joined #bitcoin-core-dev
3982020-05-07T18:48:44 *** davterra has quit IRC
3992020-05-07T18:50:50 *** promag_ has quit IRC
4002020-05-07T18:52:43 *** bitcoin-git has joined #bitcoin-core-dev
4012020-05-07T18:52:44 <bitcoin-git> [bitcoin] brakmic opened pull request #18908: util: fix UB error in ArgsManager::ParseParameters (master...fuzz-ub-argsmanager) https://github.com/bitcoin/bitcoin/pull/18908
4022020-05-07T18:52:56 *** bitcoin-git has left #bitcoin-core-dev
4032020-05-07T19:02:06 <fjahr> meeting?
4042020-05-07T19:02:10 <wumpus> #startmeeting
4052020-05-07T19:02:10 <lightningbot> Meeting started Thu May 7 19:02:10 2020 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
4062020-05-07T19:02:10 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
4072020-05-07T19:02:14 <jonasschnelli> hi
4082020-05-07T19:02:18 <meshcollider> hi
4092020-05-07T19:02:19 <fjahr> hi
4102020-05-07T19:02:27 <achow101> hi
4112020-05-07T19:02:30 <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 ariard digi_james amiti fjahr
4122020-05-07T19:02:31 <sipsorcery> hi
4132020-05-07T19:02:31 <elichai2> hi
4142020-05-07T19:02:31 <wumpus> jeremyrubin lightlike emilengler jonatack hebasto jb55
4152020-05-07T19:02:33 <gleb> hi
4162020-05-07T19:02:41 <ariard> hi
4172020-05-07T19:02:43 <jonatack> hi
4182020-05-07T19:02:48 <sipa> hi
4192020-05-07T19:02:56 <jb55> hi
4202020-05-07T19:03:02 <jnewbery> hi
4212020-05-07T19:03:16 <wumpus> one proposed topic (by jnewbery): removing valgrind from travis PR builds but that was already done
4222020-05-07T19:03:36 <gleb> I have something to bring up, unless we're still to busy with 0.20...
4232020-05-07T19:03:42 <meshcollider> There was another by Andrew re. wallet storage
4242020-05-07T19:03:58 <jnewbery> I have a little bit to add to the valgrind topic, just for context
4252020-05-07T19:04:20 <wumpus> gleb: if you have any topics to propose please do
4262020-05-07T19:04:36 <wumpus> we're not too busy with 0.20, 0.20 is going pretty slow at the moment
4272020-05-07T19:05:04 <gleb> I want to ask about adding extra threads in light of my work in #18421
4282020-05-07T19:05:05 <wumpus> most focus is on 0.21/master
4292020-05-07T19:05:06 <gribble> https://github.com/bitcoin/bitcoin/issues/18421 | Periodically update DNS caches for better privacy of non-reachable nodes by naumenkogs · Pull Request #18421 · bitcoin/bitcoin · GitHub
4302020-05-07T19:05:22 <wumpus> ok
4312020-05-07T19:05:50 <wumpus> we'll come to those, let's start with high prio as usual
4322020-05-07T19:05:51 <jkczyz> hi
4332020-05-07T19:06:03 <wumpus> #topic High priority for review
4342020-05-07T19:06:18 <achow101> meshcollider: I think that topic is for tomorrow's wallet meeting
4352020-05-07T19:06:33 <wumpus> https://github.com/bitcoin/bitcoin/projects/8 4 blockers, 1 bugfix, 5 chasing concept ACK
4362020-05-07T19:06:37 <jnewbery> I'd like to add #18877 please
4372020-05-07T19:06:39 <meshcollider> achow101: ok sure :)
4382020-05-07T19:06:40 <gribble> https://github.com/bitcoin/bitcoin/issues/18877 | Serve cfcheckpt requests by jnewbery · Pull Request #18877 · bitcoin/bitcoin · GitHub
4392020-05-07T19:07:30 <wumpus> jnewbery: added
4402020-05-07T19:07:37 <wumpus> (to blockers, I suppose?)
4412020-05-07T19:07:42 <jnewbery> yes
4422020-05-07T19:07:52 <jnewbery> blocking the rest of BIP 157 implementation
4432020-05-07T19:07:53 <jnewbery> thanks!
4442020-05-07T19:08:03 <lightlike> #17037, which is on "chasing concept ACKs", was closed yesterday
4452020-05-07T19:08:05 <gribble> https://github.com/bitcoin/bitcoin/issues/17037 | Testschains: Many regtests with different genesis and default datadir by jtimon · Pull Request #17037 · bitcoin/bitcoin · GitHub
4462020-05-07T19:08:50 <wumpus> lightlike: thanks, removed
4472020-05-07T19:09:42 <wumpus> anything else to change/add/remove?
4482020-05-07T19:10:21 <jonatack> nice to see the blockers moving forward lately
4492020-05-07T19:10:32 <wumpus> yes, two have been merged this week IIRC
4502020-05-07T19:11:18 <wumpus> looks like #17994 is kind of close to merge too
4512020-05-07T19:11:21 <gribble> https://github.com/bitcoin/bitcoin/issues/17994 | validation: flush undo files after last block write by kallewoof · Pull Request #17994 · bitcoin/bitcoin · GitHub
4522020-05-07T19:11:30 *** bitdex has quit IRC
4532020-05-07T19:11:43 <wumpus> and #16946
4542020-05-07T19:11:46 <gribble> https://github.com/bitcoin/bitcoin/issues/16946 | wallet: include a checksum of encrypted private keys by achow101 · Pull Request #16946 · bitcoin/bitcoin · GitHub
4552020-05-07T19:12:29 <wumpus> #topic Adding another scheduler thread (gleb)
4562020-05-07T19:12:37 <gleb> I implemented #18421 which helps non-reachable nodes to be less visible to the upstream infrastructure (DNS servers, ASNs).
4572020-05-07T19:12:37 <gleb> The idea is to query DNS periodically by already-known reachable nodes, to update the caches, so that non-reachable nodes are served from caches.
4582020-05-07T19:12:39 <gribble> https://github.com/bitcoin/bitcoin/issues/18421 | Periodically update DNS caches for better privacy of non-reachable nodes by naumenkogs · Pull Request #18421 · bitcoin/bitcoin · GitHub
4592020-05-07T19:12:46 <gleb> It requires reachable nodes execute this query periodically, and potentially that DNS request might take several minutes. AFAIK, it is a part of the low-level stack, and canât be easily solved on application level. Because of this, we canât safely integrate this feature into existing threads: all of them sort of assume nothing would block them
4602020-05-07T19:12:46 <gleb> for so long.
4612020-05-07T19:13:10 <gleb> So I was wondering what should be a good solution here? Give up on the idea because itâs not worth adding a new thread? Or maybe add a new thread keeping in mind it will be useful in future for similar (non-restricted) tasks? Or maybe modify scheduler to limit max exec time (not sure how to do that in practiceâ¦)
4622020-05-07T19:13:19 <wumpus> can't this be done asynchronously?
4632020-05-07T19:13:37 <wumpus> it seems the thread would spend most of its time waiting for the network anyhow
4642020-05-07T19:13:39 *** Talkless has quit IRC
4652020-05-07T19:14:08 <gleb> Yeah, it hangs on the network call.
4662020-05-07T19:14:10 <wumpus> IIRC libevent has some async DNS functionality
4672020-05-07T19:14:49 <luke-jr> oops, sorry I'm late
4682020-05-07T19:15:05 <gleb> That might help actually! Will investigate this then. Thank you wumpus. Wasn't sure which tools we have available.
4692020-05-07T19:15:28 <wumpus> in any case, on 32-bit systems we don't want to add another thread, on 64 bit systems it doesn't matter
4702020-05-07T19:16:01 *** bitcoin-git has joined #bitcoin-core-dev
4712020-05-07T19:16:02 <bitcoin-git> [bitcoin] luke-jr opened pull request #18909: [0.20] Fix release tarball (0.20...fix_release_tarball-0.20) https://github.com/bitcoin/bitcoin/pull/18909
4722020-05-07T19:16:03 *** bitcoin-git has left #bitcoin-core-dev
4732020-05-07T19:16:05 <gleb> What's the reason behind not adding it on 32-bit?
4742020-05-07T19:16:07 <wumpus> the 2MB/4MB of virtual memory for the stack that is only mapped when it is used is only a problem on 32 bit
4752020-05-07T19:16:20 <wumpus> virtual memory space
4762020-05-07T19:16:24 <gleb> Oh, i see.
4772020-05-07T19:16:33 <wumpus> it's really tight on 32 bit already
4782020-05-07T19:16:42 *** DeanGuss has joined #bitcoin-core-dev
4792020-05-07T19:16:48 <gleb> Alright, I opened an issue for broader thread discussion is #18488, if anyone is interested. Otherwise, done here, will explore libevent.
4802020-05-07T19:16:49 <gribble> https://github.com/bitcoin/bitcoin/issues/18488 | Support for non-immediate periodic tasks with variable runtime · Issue #18488 · bitcoin/bitcoin · GitHub
4812020-05-07T19:17:05 <wumpus> in any case if you can avoid adding a thread that'd be good
4822020-05-07T19:19:48 <ariard> do people have a bit of time to talk about bip157 or more broadly light clients ?
4832020-05-07T19:19:49 <wumpus> #topic Removing valgrind from travis (jnewbery)
4842020-05-07T19:20:05 <jnewbery> thanks wumpus
4852020-05-07T19:20:24 <jnewbery> like you say, this was mostly resolved this morning, but I thought I'd give some more context in general
4862020-05-07T19:20:30 <jnewbery> In December, we added a travis job to run all the functional test in valgrind for every PR.
4872020-05-07T19:20:36 <jnewbery> That meant that ci runs were taking around 3 hours (and much longer in some cases due to backlog).
4882020-05-07T19:20:40 <jnewbery> Thankfully, we're not doing that since this morning :)
4892020-05-07T19:20:41 <wumpus> ariard: probably there's some time left, though it's preferred if you propose topics at the beginning of the meeting or between meetings with #proposedmeetingtopic
4902020-05-07T19:20:46 <jnewbery> We are, however, still running ASan/LSan and UBSan jobs, which take about an hour.
4912020-05-07T19:20:55 <jnewbery> I think that's too long for a PR ci job. Preferably travis runs should return in a few minutes to allow fast iteration on PRs. Longer running jobs can be done on a nightly travis build on master.
4922020-05-07T19:21:05 <jnewbery> I did a bunch of work in 2017/18 to make ci jobs faster, so I was surprised to see how much slower they've become since then.
4932020-05-07T19:21:12 <ariard> wumpus: ah yes I proposed yesterday but I should have used #proposedmeetingtopic right
4942020-05-07T19:21:53 <gleb> Nice to hear travis no longer takes hours because of valgrind, it was painful last time I rebased my things at a busy day. Thanks jnewbery
4952020-05-07T19:21:55 <wumpus> as I said in the PR I think it'd still make sense to run the unit tests and one functional test (spinning up and down bitcoind) in travis to test the init/shutdown sequence
4962020-05-07T19:21:59 <elichai2> I have a suggestion, but I'm not sure how easy to implement is that
4972020-05-07T19:22:02 <wumpus> but running it on everythign was always overkill
4982020-05-07T19:22:02 <jnewbery> Really, just a plea to keep travis times down on PR jobs. It makes developers' lives much pleasanter!
4992020-05-07T19:22:17 <wumpus> I agree, long turnaround times for tests are bad for a project
5002020-05-07T19:22:27 <elichai2> we can have a "fast" CI on PRs and a longer one after it was accepted to merge, so before the actual merge it will run in another CI
5012020-05-07T19:22:31 <wumpus> please use testing time and resources efficiently
5022020-05-07T19:22:43 <luke-jr> elichai2: does Travis support that?
5032020-05-07T19:22:51 <wumpus> don't do silly or overkill things
5042020-05-07T19:23:07 <sipa> i think that would introduce way more process overhead for maintainers
5052020-05-07T19:23:08 <jonasschnelli> also... don't forget that bitcoinbuilds.org runs usually faster but without the ASAN/TSAN and fuzzers
5062020-05-07T19:23:23 <elichai2> luke-jr: good question, sadly I doubt it supports it natively . I know rust-lang is doing it via a bot.
5072020-05-07T19:23:23 <jonasschnelli> (for a quick feedback on a PR)
5082020-05-07T19:23:26 <wumpus> jonasschnelli: hah
5092020-05-07T19:23:41 <luke-jr> jonasschnelli: can we get that to report to GitHub?
5102020-05-07T19:23:50 <jonasschnelli> luke-jr: it is
5112020-05-07T19:23:57 <jnewbery> I think it probably does support it. You just set it up to run on every push to master
5122020-05-07T19:23:59 * luke-jr didn't notice O.o
5132020-05-07T19:24:08 <jonasschnelli> https://github.com/jonasschnelli/bitcoin-core-ci
5142020-05-07T19:24:19 <luke-jr> jnewbery: well, it'd be nice to get them aall runn BEFORE merge
5152020-05-07T19:24:20 <jonatack> jonasschnelli: yes, i always look at bitcoinbuilds for first feedback, then much later, travis on my own github branch and on bitcoin/bitcoin
5162020-05-07T19:24:22 <jnewbery> but like sipa says, anything that causes things to not get caught pre-merge transfers work to the maintainers
5172020-05-07T19:24:24 <elichai2> sipa: well we could delegate it to a bot, but it will require implementing and a big change on how merges happen(more uses of bots) which probably not everyone will like
5182020-05-07T19:24:31 <jonatack> jonasschnelli: i'm grateful for bitcoinbuilds
5192020-05-07T19:24:43 <elichai2> oh sipa was talking about nightly builds
5202020-05-07T19:24:50 <luke-jr> I only see AppVeyor and Travis on the PR I just made..
5212020-05-07T19:24:53 <sipa> we're talking about different things
5222020-05-07T19:25:05 <sipa> i'm totally in favor of doing more work on master merges than on PRs
5232020-05-07T19:25:26 <sipa> things can always be reverted if there is an unexpected problem soon after merging
5242020-05-07T19:26:17 <elichai2> sipa: and then maintainers need to check the result on the nightly CI and revert if something broke it?
5252020-05-07T19:26:17 <wumpus> rather not, of course, but the full valgrind run wasn't that effective in catching things anyway
5262020-05-07T19:26:19 <sipa> i don't think adding separate CI between PRs before and after they're "accepted" is a good idea as it just pushes more work to maintainers (arguably a more scarce resource than CI infrastructure...)
5272020-05-07T19:26:41 <luke-jr> does valgrind do anything the *Sans don't?
5282020-05-07T19:26:57 <sipa> luke-jr: it can test actual production binaries
5292020-05-07T19:26:58 <elichai2> luke-jr: I think gmaxwell show me an example once but I don't remember
5302020-05-07T19:27:10 <luke-jr> sipa: oh, true
5312020-05-07T19:27:23 <sipa> the sans all require different builds that invasively change the output
5322020-05-07T19:27:28 <luke-jr> well, Valgrind does it by runtime patching of stuff⦠not sure that's much different?
5332020-05-07T19:27:46 <luke-jr> and emulation IIRC
5342020-05-07T19:27:47 <sipa> (they can also test things that valgrind can't, because they have knowledge of the source code)
5352020-05-07T19:27:53 <wumpus> yes
5362020-05-07T19:27:54 <luke-jr> (I've seen Valgrind emulate an instruction *wrong* before)
5372020-05-07T19:28:05 <sipa> luke-jr: sure
5382020-05-07T19:28:18 <wumpus> both approaches have their advantages and disadvantages I think that's clear
5392020-05-07T19:28:37 <sipa> but it is certainly possible that a bug in the source code exists that persists into production binaries (and can be caught by valgrind), but is compiled out in sanitizer builds
5402020-05-07T19:29:01 <wumpus> true
5412020-05-07T19:29:12 <sipa> because it's very optimizer dependent for example, and sanitizer builds prevent some optimizations (or at least interfere with it significantly)
5422020-05-07T19:29:14 <wumpus> so yes it's good to test master under valgrind as well
5432020-05-07T19:29:30 <wumpus> once in a while at least
5442020-05-07T19:29:41 <elichai2> can the opposite also be true? (ie overflow that is optimized out because the read was never used etc)
5452020-05-07T19:29:50 <sipa> sure
5462020-05-07T19:29:56 <sipa> that's what sanitizers are for
5472020-05-07T19:30:10 <sipa> they primarily test for discoverable bugs in the source code
5482020-05-07T19:31:02 <wumpus> yes good point
5492020-05-07T19:31:35 <elichai2> FWIW I think I have a mainnet node lying around running under valgrind constantly (although since covid I didn't check it)
5502020-05-07T19:32:18 <jonasschnelli> elichai2: social node distancing
5512020-05-07T19:32:28 <wumpus> hehe
5522020-05-07T19:32:34 <luke-jr> aka Tor?
5532020-05-07T19:32:36 <elichai2> yeah lol, I don't want it to get infected with some UB :P
5542020-05-07T19:33:16 *** bitdex has joined #bitcoin-core-dev
5552020-05-07T19:33:39 <wumpus> #topic bip157 and light clients (ariard)
5562020-05-07T19:33:41 <jonatack> the full valgrind run brought to light some issues for me recently that lead to more robust code... #18681 was an example
5572020-05-07T19:33:43 <gribble> https://github.com/bitcoin/bitcoin/issues/18681 | donotmerge: build: Enable thread-local with glibc compat by laanwj · Pull Request #18681 · bitcoin/bitcoin · GitHub
5582020-05-07T19:34:03 <jonatack> er, #18691
5592020-05-07T19:34:06 <gribble> https://github.com/bitcoin/bitcoin/issues/18691 | test: add wait_for_cookie_credentials() to framework for rpcwait tests by jonatack · Pull Request #18691 · bitcoin/bitcoin · GitHub
5602020-05-07T19:34:20 <ariard> Yes so about light client I had really interesting discussion with people
5612020-05-07T19:34:41 <ariard> and the constructive outcome of this was it would be better to have a more defined policy
5622020-05-07T19:35:06 <ariard> when we now a solution isn't perfect, but at same time not restrain the project to make steps forward
5632020-05-07T19:35:24 <ariard> what I was worry about, is by supporting bip157 in core, all people building such nice LN wallets
5642020-05-07T19:35:29 <wumpus> jonatack: hehe the cookie file race was detected just because valgrind makes things slow :)
5652020-05-07T19:35:34 <ariard> consider the validation backend as a solved issue
5662020-05-07T19:35:40 <luke-jr> BIP157 isn't just "not perfect", it's harmful/backward
5672020-05-07T19:35:41 <jonatack> yep :p
5682020-05-07T19:35:43 *** theStack has joined #bitcoin-core-dev
5692020-05-07T19:36:10 <ariard> instead of having well-awareness, they are free-riding on the p2p network for now
5702020-05-07T19:38:09 <jonasschnelli> I think BIP157 support in core is a conceptual no brainer. The question is maybe more, if it should be open to non-whitelisted peers (random peers).
5712020-05-07T19:38:10 <ariard> and having a better idea for which bip157 support was aimed, people using their mobile wallets with their full-nodes
5722020-05-07T19:38:25 <ariard> or servicing random clients in the wild, which maybe a bit insecure
5732020-05-07T19:39:02 <sipa> there is nothing insecure about it; it's just a bad idea for them to trust random peers
5742020-05-07T19:39:07 <wumpus> the same issue as with the bloom filters again
5752020-05-07T19:39:09 <sipa> (but that's still better than BIP37...)
5762020-05-07T19:39:15 <luke-jr> jonasschnelli: what is the use case for it?
5772020-05-07T19:39:30 <wumpus> (though at least this doesn't have as much DoS potential)
5782020-05-07T19:39:35 <sipa> wumpus: i don't think so;
5792020-05-07T19:39:37 <sipa> exactly
5802020-05-07T19:39:42 <luke-jr> bloom filters are strictly better I think
5812020-05-07T19:39:49 <sipa> BIP157 support is very cheap for the server
5822020-05-07T19:39:51 <sipa> luke-jr: how so?
5832020-05-07T19:39:56 <wumpus> it's a kind of 'altruism' that might not be warranted
5842020-05-07T19:40:00 <luke-jr> sipa: lower overhead
5852020-05-07T19:40:09 <sipa> luke-jr: for whom?
5862020-05-07T19:40:09 <ariard> on the security aspect, supporting bip157 in core encourage people to connect directly to random peers
5872020-05-07T19:40:10 <wumpus> luke-jr: wait, how?
5882020-05-07T19:40:16 <luke-jr> sipa: for everyone
5892020-05-07T19:40:19 <sipa> luke-jr: wut
5902020-05-07T19:40:27 <ariard> and almost all bip157 clietns, dont't have strong addr management countermeasures
5912020-05-07T19:40:40 <wumpus> ariard: but that's *their* problem
5922020-05-07T19:40:40 <sipa> BIP157 is certainly harder on clients
5932020-05-07T19:40:41 <ariard> *peer management protection
5942020-05-07T19:40:43 <luke-jr> take the reasonable use case of a user using a light wallet with their own full node
5952020-05-07T19:40:52 <wumpus> we care about the server side
5962020-05-07T19:40:53 <luke-jr> bloom does this fine, with very little overhead
5972020-05-07T19:40:58 <ariard> wumpus: but do you want to make it easy for people to build insecure solutions?
5982020-05-07T19:40:59 <luke-jr> you scan the blockchain once on the server side
5992020-05-07T19:41:08 <sipa> luke-jr: but you need to do it once per client
6002020-05-07T19:41:13 <sipa> with BIP157 you do it once
6012020-05-07T19:41:19 <luke-jr> sipa: how many people have multiple clients?
6022020-05-07T19:41:35 <luke-jr> and even a few clients is still relatively low total overhead there
6032020-05-07T19:41:38 <wumpus> scanning on the server side was always the problem
6042020-05-07T19:41:48 <luke-jr> wumpus: but that's exactly the ideal in this case
6052020-05-07T19:41:55 <luke-jr> you don't want to burden your phone/battery
6062020-05-07T19:41:56 <wumpus> if you allow random people on the internet to offload computation to you, you're infinitely generous
6072020-05-07T19:42:07 <luke-jr> you don't. this isn't for random people, it's for trusted peersâ¦
6082020-05-07T19:42:12 <luke-jr> your own wallets
6092020-05-07T19:42:21 <ariard> scanning on the server side isn't great, even worst with LN clients verifying channel opening
6102020-05-07T19:42:22 <wumpus> for whitelisted peers it's okay
6112020-05-07T19:42:25 <wumpus> sure
6122020-05-07T19:42:26 <luke-jr> random people using it is harmful, and the very reason to avoid merging it
6132020-05-07T19:42:27 *** owowo has quit IRC
6142020-05-07T19:42:54 <luke-jr> ariard: server side typically has ~unlimited power
6152020-05-07T19:42:56 <sipa> luke-jr: i agree it's a bad idea; i'm not sure it is harmful
6162020-05-07T19:42:59 <luke-jr> client has a battery to worry about
6172020-05-07T19:43:20 <luke-jr> sipa: it encourages light wallets to use foreign nodes
6182020-05-07T19:43:22 <sipa> and it would be far less of a bad idea if it was softforked in, so the filters are verifiable
6192020-05-07T19:43:25 <ariard> maybe it should be part of the release node, to advice whitelisting
6202020-05-07T19:43:29 <ariard> *notes
6212020-05-07T19:43:36 <sipa> but that's not going to happen any time soon
6222020-05-07T19:43:38 <luke-jr> sipa: that doesn't fix the problem of people not usign their own node
6232020-05-07T19:43:46 <jnewbery> if it's your own server, you don't need an spv protocol. Just upload your xpub
6242020-05-07T19:43:49 <sipa> luke-jr: not everyone uses their own full node, period
6252020-05-07T19:43:52 <theStack> so the rationale here from luke-jr is that in the end every person should have its own full node?
6262020-05-07T19:43:56 <sipa> luke-jr: there are good and bad ways to deal with it
6272020-05-07T19:43:57 <ariard> luke-jr: yes but rescannning code of core isn't that performant, no parallelization, a lot of lock tacking
6282020-05-07T19:44:01 <luke-jr> jnewbery: yes, that direction seems a lot better IMO
6292020-05-07T19:44:12 <jonasschnelli> I think ariard concern is hypothetical but IMO boils down on limiting bandwidth,... you can write a client today that downloads all blocks over and over again.
6302020-05-07T19:44:14 <jnewbery> good, so your use case is solved
6312020-05-07T19:44:35 <luke-jr> jnewbery: â
6322020-05-07T19:44:49 <ariard> jonasschenelli: are you thinking about intentional DoS ?
6332020-05-07T19:44:56 <luke-jr> my point is that there is no use case for neutrino
6342020-05-07T19:44:59 <jnewbery> not everyone wants to use bitcoin in the same way as you, and that's ok
6352020-05-07T19:45:05 <jonasschnelli> ariard: both... intentional or just because of the use cases
6362020-05-07T19:45:13 <luke-jr> Bitcoin's security model depends on at least most people using their own full ndoe
6372020-05-07T19:45:39 <luke-jr> it's okay if there are exceptions, but there's no reason to cater to them, especially when the network's security is already at high risk
6382020-05-07T19:45:40 <sipa> luke-jr: i strongly disagree; it depends on enough people independently verifying the blockchain
6392020-05-07T19:45:43 <jonasschnelli> if there is the concern that there are too many BIP157 clients,... one might want to limit the bandwidth
6402020-05-07T19:45:44 <ariard> jonasschenelli: okay my point was really about LN clients, for which bip157 was designed, not an application which needs to download block over and over
6412020-05-07T19:45:51 <luke-jr> sipa: enough people = most
6422020-05-07T19:46:01 <sipa> luke-jr: i strongly disagree
6432020-05-07T19:46:09 <luke-jr> sipa: a minority verifying is useless if the majority imposes the invalid chain economically
6442020-05-07T19:46:17 <jonasschnelli> ariard: Same for any SPV client,... right?
6452020-05-07T19:46:34 *** michaelf_ has joined #bitcoin-core-dev
6462020-05-07T19:46:35 <ariard> jonasschenlli: yes my concern isn't bip157 specific, I do think that's the best option available today
6472020-05-07T19:46:46 <luke-jr> stratum > bloom > bip157
6482020-05-07T19:46:59 <luke-jr> for private/trusted usage
6492020-05-07T19:47:08 <luke-jr> which is the only usage we should support IMO
6502020-05-07T19:47:11 <ariard> it's more how do you scale any light client protocol to avoid building centralized chain access services when they hit a scaling roof
6512020-05-07T19:47:45 <gleb> luke-jr: I assume you meant electrum?
6522020-05-07T19:47:48 <luke-jr> ariard: there's no difference
6532020-05-07T19:47:50 <sipa> luke-jr: bip157 has other advantages over bloom filters, such as being able to connect to two nodes and comparing the filters, permitting a "1 of 2 nodes is trusted" security model
6542020-05-07T19:47:55 <luke-jr> gleb: Stratum is the protocol Electrum uses, yes
6552020-05-07T19:47:58 *** tryphe_ has joined #bitcoin-core-dev
6562020-05-07T19:48:10 <jonasschnelli> ariard: I would expect that wallet providers ship a recent pack of filters with the ap
6572020-05-07T19:48:11 <ariard> overall, bip157 is good for experimentation, while keeping awareness there is still unsolved issues on security and scalability
6582020-05-07T19:48:13 <luke-jr> sipa: but improving security of light wallets is a net loss of security for the network
6592020-05-07T19:48:24 <luke-jr> sipa: because now fewer people will use a full node of their own
6602020-05-07T19:48:30 <sipa> luke-jr: 99.99% of users don't even have SPV level verification
6612020-05-07T19:48:40 <jonasschnelli> ariard: the beauty is also that filters can be retrieved from centralized sources and CDNs
6622020-05-07T19:48:46 <luke-jr> sipa: if 99.99% don't have their own full node, Bitcoin has failed
6632020-05-07T19:48:52 *** owowo has joined #bitcoin-core-dev
6642020-05-07T19:48:53 *** owowo has joined #bitcoin-core-dev
6652020-05-07T19:49:02 <jonatack> fwiw, i'm running a bip157 node on mainnet with -peercfilters=1 -blockfilterindex=1 to test for the first time, and /blockfilter/basic is 4 GB
6662020-05-07T19:49:06 *** michaelfolkson has quit IRC
6672020-05-07T19:49:10 <ariard> jonasschnelli: yes but what's your trust model with such centralized sources and CDNS
6682020-05-07T19:49:40 <jonasschnelli> ariard: IMO the goal for compact block filters is to get a block commitment at some point
6692020-05-07T19:49:42 <ariard> you can dissociate getting the filters from such CDN and getting filters-headers/headers from the p2p network
6702020-05-07T19:50:08 <jonasschnelli> ariard: also, one can crosscheck the CDN filters against some p2p loaded bip157 filters
6712020-05-07T19:50:13 <ariard> jonasschenlli: it would simplify SPV logic and improve their security but even committed you still need to download them
6722020-05-07T19:50:20 <sipa> luke-jr: Ok.
6732020-05-07T19:50:37 <jonasschnelli> ariard: what is the worry with downloading them?
6742020-05-07T19:50:39 <sipa> i don't think this discussion will lead anywhere
6752020-05-07T19:50:54 *** tryphe has quit IRC
6762020-05-07T19:50:57 <jonasschnelli> better continue the ML discussion I think
6772020-05-07T19:50:58 <ariard> jonasschnelli: bandwidth cost if you download them directly from the p2p network
6782020-05-07T19:51:11 <jonasschnelli> (happy to continue outside of this meeting)
6792020-05-07T19:51:37 <ariard> jonasschnelli: but yes I agree you can crosscheck the CDN filters against filter-headers provided from the p2p network
6802020-05-07T19:51:50 <kanzure> is the contention that light clients should be doing IBD and validation?
6812020-05-07T19:52:09 <jonasschnelli> heh
6822020-05-07T19:52:40 <sipa> kanzure: i think luke-jr is contending that light clients shouldn't exist, and all wallets should be either a full node, or connected to the user's own trusted full node
6832020-05-07T19:52:41 <ariard> kanzure: no my concern is assuming you have the bip157 light client paradigm, how do you make it scale ecosystem-wise
6842020-05-07T19:52:47 <sipa> at least for a majority of users
6852020-05-07T19:52:50 <kanzure> next question: how many times should someone have to do IBD? i think the correct answer should be only once ever....
6862020-05-07T19:53:12 <kanzure> [if they can keep integrity of their download and state]
6872020-05-07T19:53:14 <sipa> ariard: i don't understand how your concern is any different from nodes serving blocks *at all*
6882020-05-07T19:53:32 <jonasschnelli> kanzure: next question: how many random peers have I misused by testing mainnet IBD
6892020-05-07T19:53:44 <kanzure> these and other disturbing questions.
6902020-05-07T19:54:01 <luke-jr> sipa: ideally
6912020-05-07T19:54:20 <luke-jr> at least, that as long as the situation is not good, anything that makes light clients better, is harmful to Bitcoin, and shouldn't be merged
6922020-05-07T19:54:48 <luke-jr> because that can only result in fewer people using a full node
6932020-05-07T19:55:00 <ariard> sipa: it's another issue but yes also an unsolved problem, my assumption was you may have a desquilibritate number of light clients compare to full-nodes
6942020-05-07T19:55:06 <ariard> and maybe faster than expected
6952020-05-07T19:55:13 <sipa> luke-jr: my belief is that bitcoin offers a choice for financial autonomy, and choice is a good thing - not everyone will choose to make maximal use of that, but everyone who wants to should be able to
6962020-05-07T19:55:16 <jonasschnelli> Yes. The only difference to blocks serving (which seems to cause much more traffic) is that blocks served to bip157 are pure consumption while blocks served to full nodes should - ideally - be served to other peers.
6972020-05-07T19:55:39 <luke-jr> sipa: you already have that choice with fiat: you can print monopoly money, and refuse to honour USD
6982020-05-07T19:55:41 <ariard> jonasschelli: yes you may have assume some reciprocity between full-nodes peers
6992020-05-07T19:55:44 <jnewbery> ariard: imposing upload costs on peers is something that is caused by any activity on the p2p network. It doesn't make much sense to distinguish between application data types because there will always be some other data you can download. Peer upload resource cost can really only be done on the net layer by deprioritizing nodes that are taking up resource.
7002020-05-07T19:55:49 <ariard> at least I see incentives far more aligned
7012020-05-07T19:56:07 *** promag_ has joined #bitcoin-core-dev
7022020-05-07T19:56:08 <sipa> luke-jr: this is not productive
7032020-05-07T19:56:08 <jonasschnelli> agree with jnewbery
7042020-05-07T19:56:23 <wumpus> 4 minutes to go
7052020-05-07T19:56:41 <luke-jr> sipa: it's the same thing; if most people just trust miners, then the people who don't trust miners will simply get cut off when miners do something they don't like; the losers are the full nodes
7062020-05-07T19:57:47 <luke-jr> light clients are a hardfork to "no rules at all"
7072020-05-07T19:58:33 <sipa> perhaps - but far less easily than having money on coinbase is a hardfork to "whatever monetary policy coinbase likes"
7082020-05-07T19:58:36 <ariard> jnewbery: but ideally you do want to increase security by increasing connectivity, like I prefer to offer my bandwidth to other full-nodes for censorship-resistance?
7092020-05-07T19:58:55 <jnewbery> then don't enable serving cfilters :)
7102020-05-07T19:58:56 <luke-jr> sipa: it's the same, but miner(s) instead of coinbase
7112020-05-07T19:59:24 *** michaelfolkson has joined #bitcoin-core-dev
7122020-05-07T19:59:36 <jonasschnelli> ariard: there is no way you know if the blocks you serve are for other full nodes
7132020-05-07T19:59:40 <ariard> jnewbery: sorry I don't get you on depriorirtizing nodes that are taking up resources, can you precise?
7142020-05-07T19:59:59 <luke-jr> jonasschnelli: technically true, but what non-full nodes download full blocks these days?
7152020-05-07T20:00:03 <jnewbery> ariard: here's another example for you. If a peer asks for the same block twice, should you serve it again? You're clearly not helping block propagation
7162020-05-07T20:00:22 <jonasschnelli> luke-jr: wasabi did for a while (full block SPV)
7172020-05-07T20:00:23 <jnewbery> if your answer is 'no', then you need to keep internal book-keeping of which blocks you've served to whom
7182020-05-07T20:00:26 <jonasschnelli> (maybe still does)
7192020-05-07T20:00:27 <sipa> ariard: if a node asks too much of your resources (memory, cpu, bandwidth, i/o), deprioritize serving their incoming requests
7202020-05-07T20:00:36 <jnewbery> if your answer is 'yes', then how is it any different from serving a cfilter?
7212020-05-07T20:00:52 <ariard> jnewbery: maybe that's a fault-tolerance case and it makes sense to serve it again
7222020-05-07T20:01:08 *** promag_ has quit IRC
7232020-05-07T20:01:24 *** michaelf_ has quit IRC
7242020-05-07T20:01:39 <ariard> sipa: yes but we don't do this AFAIK? and if everyone start to deprioritizie servicing bip157 clients you do have an issue
7252020-05-07T20:01:48 <sipa> ariard: no, but we absolutely should
7262020-05-07T20:02:09 <jnewbery> sipa: +1
7272020-05-07T20:02:15 <sipa> (not BIP157 specifically, just in general - if you ask too much of us and we get overloaded, deprioritize)
7282020-05-07T20:02:29 * luke-jr still hasn't heard a use case for merging BIP157 at all, aside from harming Bitcoin
7292020-05-07T20:02:46 <jonatack> question: if bip157 is opt-in, and a full node can soon export a descriptor wallet xpub, why would a full node turn on serving cfilters?
7302020-05-07T20:03:17 <wumpus> this should be the end of the meeting
7312020-05-07T20:03:26 <sipa> i don't see what exporting and xpub has to do with that
7322020-05-07T20:03:31 <wumpus> maybe we should continue next week
7332020-05-07T20:03:34 * luke-jr either
7342020-05-07T20:03:43 <ariard> jonasschnelli: yes you may not know what kind of clients you're servicing, but with all this stuff we make assumptions of what kind of clients
7352020-05-07T20:03:50 <ariard> are effectively deployed ?
7362020-05-07T20:04:06 <ariard> wumpus: yes we can end, but thanks for all your points it's really interesting
7372020-05-07T20:04:44 <wumpus> #endmeeting
7382020-05-07T20:04:44 <lightningbot> Meeting ended Thu May 7 20:04:44 2020 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
7392020-05-07T20:04:44 <lightningbot> Minutes: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2020/bitcoin-core-dev.2020-05-07-19.02.html
7402020-05-07T20:04:44 <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2020/bitcoin-core-dev.2020-05-07-19.02.txt
7412020-05-07T20:04:44 <lightningbot> Log: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2020/bitcoin-core-dev.2020-05-07-19.02.log.html
7422020-05-07T20:04:48 <luke-jr> maybe we can get NicolasDorier to join next week <.<
7432020-05-07T20:05:23 <luke-jr> although it might be the middle of the night there
7442020-05-07T20:05:37 <sipa> this discussion should really be on the ML
7452020-05-07T20:07:49 <luke-jr> it is, I need to read recent replies
7462020-05-07T20:08:49 <ariard> luke-jr: I've read your point on supermajority of the economy, but isn't this assuming you can see the economic traffic?
7472020-05-07T20:09:16 <ariard> and with LN you may have not see the real payment traffic because channel
7482020-05-07T20:09:41 <luke-jr> ariard: measuring it accurately would require that, but not understanding what we depend on
7492020-05-07T20:09:58 <luke-jr> even today, we can't measure it accurately, but we can see it's not in a good situation
7502020-05-07T20:14:51 <ariard> luke-jr: and what's your opinon on fallback-full-node in case of fork detection ? Like you can switch to an authoritative blockchain view in case of anomalies
7512020-05-07T20:15:08 <ariard> but at least you don't have to download all blocks in regular time
7522020-05-07T20:15:19 *** sipa has left #bitcoin-core-dev
7532020-05-07T20:15:48 <luke-jr> ariard: so every stale block, you IBDâ
7542020-05-07T20:16:07 *** mdunnio_ has joined #bitcoin-core-dev
7552020-05-07T20:17:39 <luke-jr> ariard: if you have the capability to run a full node all the time (necessary for any similar ideas), why wouldn't you just run it regularly anyway?
7562020-05-07T20:18:28 *** tryphe_ is now known as tryphe
7572020-05-07T20:18:38 *** mdunnio has quit IRC
7582020-05-07T20:18:42 <theStack> luke-jr: would you mind shortly explaining how your full node count script works? what are the criteria to identify a peer as "full node"?
7592020-05-07T20:22:33 <ariard> luke-jr: no after seeing like 6-blocks fork, you do connect to a full-node, and rescan filters from fork branch common ancestor until the fallback node tip
7602020-05-07T20:22:49 *** surja795 has joined #bitcoin-core-dev
7612020-05-07T20:23:19 <ariard> you may not have the capability to run a full-node, but you may know someone around you that you can point your light client to in case of anomalies
7622020-05-07T20:23:57 <ariard> also maybe you can do something like assumeutxo, in case of anomalies download a utxo set and IBD from then?
7632020-05-07T20:25:25 <luke-jr> ariard: you can't connect to your full node unless you run one. connecting to *a* full node is what light clients normally do..
7642020-05-07T20:25:33 <luke-jr> ariard: filters don't prove anything
7652020-05-07T20:25:57 <luke-jr> if you're okay trusting someone around you, you can do that *normally*
7662020-05-07T20:26:08 <luke-jr> assumeutxo does not reduce sync time
7672020-05-07T20:26:31 <luke-jr> assumeutxo is only acceptable provided the full IBD from zero is performed still
7682020-05-07T20:30:37 <ariard> luke-jr: assuming you do have authentication deployed at some point, you may not connect to *a* full node but actually Bob's full-node
7692020-05-07T20:31:41 <ariard> and Bob maybe not okay to offer you bandwidth, but still okay to provide you headers, and you somehow trust Bob
7702020-05-07T20:32:10 <ariard> you can have a set of semi-trusted fallback nodes, like Alice, Bob, etc
7712020-05-07T20:32:36 <luke-jr> ariard: you can do that with bloom already
7722020-05-07T20:33:35 <ariard> luke-jr: right I'm not arguing bip157-vs-bip37 here, but more broadly on light-client model in case of forks
7732020-05-07T20:34:36 <luke-jr> ariard: if you have a node you personally trust, that's not quite the same thing as the light-client model
7742020-05-07T20:34:41 <luke-jr> even if you're only using that node to verify headers
7752020-05-07T20:36:42 <luke-jr> perhaps you don't trust the person as much as yourself, but it's still much closer to "your own full node" than light wallet
7762020-05-07T20:38:56 <luke-jr> (actually, checking your incoming transactions against full nodes run by *the people you care to pay* might even be more secure than your own full node? XD)
7772020-05-07T20:40:05 *** emilengler has quit IRC
7782020-05-07T20:43:18 *** MrSquanchee has joined #bitcoin-core-dev
7792020-05-07T20:44:10 *** dfmb_btc has quit IRC
7802020-05-07T20:45:03 *** vasild has quit IRC
7812020-05-07T20:47:00 *** Highway62 has joined #bitcoin-core-dev
7822020-05-07T20:48:39 *** Highway61 has quit IRC
7832020-05-07T20:48:39 *** Highway62 is now known as Highway61
7842020-05-07T20:55:15 *** vasild has joined #bitcoin-core-dev
7852020-05-07T21:00:02 *** Dimlock has quit IRC
7862020-05-07T21:00:04 *** michaelfolkson has quit IRC
7872020-05-07T21:00:50 *** bsm117532 has joined #bitcoin-core-dev
7882020-05-07T21:08:19 *** Highway62 has joined #bitcoin-core-dev
7892020-05-07T21:10:25 *** Highway61 has quit IRC
7902020-05-07T21:10:26 *** Highway62 is now known as Highway61
7912020-05-07T21:22:08 *** Guyver2 has quit IRC
7922020-05-07T21:50:51 *** RandIter has joined #bitcoin-core-dev
7932020-05-07T21:50:56 *** RandIter is now known as Guest44912
7942020-05-07T21:53:32 *** molakala has quit IRC
7952020-05-07T22:14:37 <achow101> would it be reasonable to replace salvagewallet with a bdb deserializer and try to recover key-values ourselves instead?
7962020-05-07T22:14:54 *** surja795 has quit IRC
7972020-05-07T22:15:30 *** surja795 has joined #bitcoin-core-dev
7982020-05-07T22:20:18 *** surja795 has quit IRC
7992020-05-07T22:21:09 *** sipa has joined #bitcoin-core-dev
8002020-05-07T22:23:13 <jnewbery> achow101: lots of previous discussion on this: https://github.com/bitcoin/bitcoin/pull/10540, https://github.com/bitcoin/bitcoin/issues/10991
8012020-05-07T22:23:26 <achow101> jnewbery: yeah, reading through a bunch of that now
8022020-05-07T22:23:27 <jnewbery> I think it should be in a separate wallet tool
8032020-05-07T22:26:16 *** brytemorio has joined #bitcoin-core-dev
8042020-05-07T22:30:03 *** promag_ has joined #bitcoin-core-dev
8052020-05-07T22:34:33 *** promag_ has quit IRC
8062020-05-07T22:46:26 *** marcoagner has quit IRC
8072020-05-07T22:47:50 *** brakmic has quit IRC
8082020-05-07T22:51:28 *** brytemorio has quit IRC
8092020-05-07T22:53:18 *** lightlike has quit IRC
8102020-05-07T23:03:12 *** promag_ has joined #bitcoin-core-dev
8112020-05-07T23:10:09 *** mdunnio_ has quit IRC
8122020-05-07T23:12:45 <luke-jr> achow101: deserialize why? just search for the data we need in any format? :P
8132020-05-07T23:14:43 *** vasild has quit IRC
8142020-05-07T23:19:23 *** DeanGuss has quit IRC
8152020-05-07T23:19:38 *** bitcoin-git has joined #bitcoin-core-dev
8162020-05-07T23:19:38 <bitcoin-git> [bitcoin] MarcoFalke closed pull request #18385: WIP contrib: Add keys.openpgp.org as backup server (master...2003-contribPGPBackupServer) https://github.com/bitcoin/bitcoin/pull/18385
8172020-05-07T23:19:39 *** bitcoin-git has left #bitcoin-core-dev
8182020-05-07T23:20:13 *** bitcoin-git has joined #bitcoin-core-dev
8192020-05-07T23:20:13 <bitcoin-git> [bitcoin] MarcoFalke closed pull request #18352: WIP NOMERGE [bench] gitian builds for OP_IF bench (master...2003-benchGitianOPIF) https://github.com/bitcoin/bitcoin/pull/18352
8202020-05-07T23:20:14 *** bitcoin-git has left #bitcoin-core-dev
8212020-05-07T23:21:08 *** bitcoin-git has joined #bitcoin-core-dev
8222020-05-07T23:21:08 <bitcoin-git> [bitcoin] MarcoFalke closed pull request #15845: wallet: Fast rescan with BIP157 block filters (master...1904-walletFastRescan) https://github.com/bitcoin/bitcoin/pull/15845
8232020-05-07T23:21:09 *** bitcoin-git has left #bitcoin-core-dev
8242020-05-07T23:21:23 *** bitcoin-git has joined #bitcoin-core-dev
8252020-05-07T23:21:23 <bitcoin-git> [bitcoin] fanquake closed pull request #16003: init: Fixes for file descriptor accounting (master...fd-limits-3) https://github.com/bitcoin/bitcoin/pull/16003
8262020-05-07T23:21:24 *** bitcoin-git has left #bitcoin-core-dev
8272020-05-07T23:21:39 *** vasild has joined #bitcoin-core-dev
8282020-05-07T23:22:27 *** surja795 has joined #bitcoin-core-dev
8292020-05-07T23:34:17 *** promag_ has quit IRC
8302020-05-07T23:35:23 *** justanotheruser has quit IRC
8312020-05-07T23:44:31 *** promag_ has joined #bitcoin-core-dev
8322020-05-07T23:51:24 *** jonatack_ has joined #bitcoin-core-dev
8332020-05-07T23:54:10 *** justanotheruser has joined #bitcoin-core-dev
8342020-05-07T23:54:28 *** jonatack has quit IRC