--- Log opened Thu May 07 00:00:14 2020 00:02 -!- jarthur [~jarthur@2605:6000:1019:4971:557d:7774:19de:6477] has joined #bitcoin-core-dev 00:04 -!- proofofkeags [~proofofke@174-29-9-247.hlrn.qwest.net] has quit [Ping timeout: 256 seconds] 00:04 -!- jarthur [~jarthur@2605:6000:1019:4971:557d:7774:19de:6477] has quit [Remote host closed the connection] 00:05 -!- jarthur [~jarthur@2605:6000:1019:4971:557d:7774:19de:6477] has joined #bitcoin-core-dev 00:09 -!- jarthur [~jarthur@2605:6000:1019:4971:557d:7774:19de:6477] has quit [Ping timeout: 260 seconds] 00:30 -!- michaelfolkson [~textual@2a00:23c5:be01:b201:cc78:c0db:3f4d:fe88] has joined #bitcoin-core-dev 00:32 -!- michaelfolkson [~textual@2a00:23c5:be01:b201:cc78:c0db:3f4d:fe88] has quit [Client Quit] 00:38 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 00:38 < 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 00:38 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 00:42 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 00:42 < bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/7bcc42b4035b...3b1e289248dc 00:42 < bitcoin-git> bitcoin/master a029805 fanquake: build: remove -Qunused-arguments workaround for clang + ccache 00:42 < bitcoin-git> bitcoin/master 3b1e289 fanquake: Merge #18535: build: remove -Qunused-arguments workaround for clang + ccac... 00:42 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 00:43 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 00:43 < 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 00:43 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 00:43 -!- michaelfolkson [~textual@2a00:23c5:be01:b201:6d15:199d:f584:8f52] has joined #bitcoin-core-dev 00:46 -!- michaelfolkson [~textual@2a00:23c5:be01:b201:6d15:199d:f584:8f52] has quit [Client Quit] 00:54 -!- mol_ [~mol@unaffiliated/molly] has joined #bitcoin-core-dev 00:56 -!- Netsplit *.net <-> *.split quits: jkczyz, _flow_, mr_burdell, peltre, NicolasDorier, inpharmaticist[m, endogenic 00:57 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 272 seconds] 00:58 -!- Guyver2 [Guyver@guyver2.xs4all.nl] has joined #bitcoin-core-dev 01:01 -!- Netsplit over, joins: mr_burdell, endogenic, NicolasDorier, jkczyz, inpharmaticist[m, peltre, _flow_ 01:02 -!- michaelfolkson [~textual@2a00:23c5:be01:b201:6d15:199d:f584:8f52] has joined #bitcoin-core-dev 01:02 -!- michaelfolkson [~textual@2a00:23c5:be01:b201:6d15:199d:f584:8f52] has quit [Client Quit] 01:07 -!- marcoagner [~user@bl13-226-166.dsl.telepac.pt] has joined #bitcoin-core-dev 01:23 -!- roconnor [~roconnor@host-45-58-197-21.dyn.295.ca] has quit [Ping timeout: 264 seconds] 01:23 -!- peltre [sid268329@gateway/web/irccloud.com/x-gqpwhefsxogbyghd] has quit [Max SendQ exceeded] 01:23 -!- peltre [sid268329@gateway/web/irccloud.com/x-efiezggjkjikakuw] has joined #bitcoin-core-dev 01:34 -!- sipsorcery [~sipsorcer@37.228.243.107] has joined #bitcoin-core-dev 01:38 -!- promag [~promag@Bl19-22-20.dsl.telepac.pt] has joined #bitcoin-core-dev 01:38 -!- promag_ [~promag@bl19-22-20.dsl.telepac.pt] has joined #bitcoin-core-dev 01:38 < wumpus> luke-jr: maybe split out the add-prefix commit for now, that one's straightforward 01:49 -!- guest534543 [~mix@141.98.103.236] has quit [Ping timeout: 256 seconds] 02:00 -!- panda1 [~panda@37.120.203.188] has quit [] 02:00 -!- proofofkeags [~proofofke@174-29-9-247.hlrn.qwest.net] has joined #bitcoin-core-dev 02:05 -!- proofofkeags [~proofofke@174-29-9-247.hlrn.qwest.net] has quit [Ping timeout: 264 seconds] 02:18 -!- dfmb_ [~dfmb_@2001:8a0:f342:ad01:dcdd:c28e:c397:6452] has joined #bitcoin-core-dev 02:20 -!- promag [~promag@Bl19-22-20.dsl.telepac.pt] has quit [Remote host closed the connection] 02:22 -!- subdriven1 [~subdriven@37.120.217.243] has joined #bitcoin-core-dev 02:39 -!- mrostecki [mrosteckim@gateway/shell/matrix.org/x-lzswqrhgdriaeavl] has quit [Quit: killed] 02:39 -!- thunderbiscuit[m [thunderbis@gateway/shell/matrix.org/x-ljcdiehsldxoxvfr] has quit [Quit: killed] 02:39 -!- icota[m] [icotamatri@gateway/shell/matrix.org/x-inrfpbneyedsmhht] has quit [Quit: killed] 02:39 -!- TheFuzzStone[m] [thefuzzsto@gateway/shell/matrix.org/x-zotisaadfyudvzwa] has quit [Quit: killed] 02:40 -!- inpharmaticist[m [inpharmati@gateway/shell/matrix.org/x-qrdcrbfzbdpurcfj] has quit [Quit: killed] 02:49 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 02:51 -!- promag [~promag@bl19-22-20.dsl.telepac.pt] has joined #bitcoin-core-dev 02:53 -!- inpharmaticist[m [inpharmati@gateway/shell/matrix.org/x-yanqdxjjaowniqwq] has joined #bitcoin-core-dev 02:55 -!- promag [~promag@bl19-22-20.dsl.telepac.pt] has quit [Ping timeout: 246 seconds] 03:01 -!- icota[m] [icotamatri@gateway/shell/matrix.org/x-ferchfbwyendkkci] has joined #bitcoin-core-dev 03:01 -!- mrostecki [mrosteckim@gateway/shell/matrix.org/x-vveimhcfetodjnze] has joined #bitcoin-core-dev 03:01 -!- TheFuzzStone[m] [thefuzzsto@gateway/shell/matrix.org/x-nvjjwawqtnxwvglo] has joined #bitcoin-core-dev 03:01 -!- thunderbiscuit[m [thunderbis@gateway/shell/matrix.org/x-kotuhurevbosmyzz] has joined #bitcoin-core-dev 03:14 -!- surja795 [~surja795@c-24-61-194-104.hsd1.ma.comcast.net] has joined #bitcoin-core-dev 03:19 -!- surja795 [~surja795@c-24-61-194-104.hsd1.ma.comcast.net] has quit [Remote host closed the connection] 03:19 -!- surja795 [~surja795@c-24-61-194-104.hsd1.ma.comcast.net] has joined #bitcoin-core-dev 03:23 -!- promag [~promag@bl19-22-20.dsl.telepac.pt] has joined #bitcoin-core-dev 03:24 -!- surja795 [~surja795@c-24-61-194-104.hsd1.ma.comcast.net] has quit [Ping timeout: 246 seconds] 03:24 -!- dfmbbtc [~dfmb_@2001:8a0:f342:ad01:2145:aef1:114a:6b07] has joined #bitcoin-core-dev 03:25 -!- timothy [~tredaelli@redhat/timothy] has joined #bitcoin-core-dev 03:27 -!- dfmb_ [~dfmb_@2001:8a0:f342:ad01:dcdd:c28e:c397:6452] has quit [Ping timeout: 256 seconds] 03:32 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 244 seconds] 03:44 -!- dfmb_btc [~dfmb_@2001:8a0:f342:ad01:f872:6c02:f240:b52c] has joined #bitcoin-core-dev 03:44 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Remote host closed the connection] 03:45 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined #bitcoin-core-dev 03:47 -!- dfmbbtc [~dfmb_@2001:8a0:f342:ad01:2145:aef1:114a:6b07] has quit [Ping timeout: 252 seconds] 03:53 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection] 04:01 -!- promag [~promag@bl19-22-20.dsl.telepac.pt] has quit [Remote host closed the connection] 04:03 -!- molz_ [~mol@unaffiliated/molly] has joined #bitcoin-core-dev 04:04 -!- dfmbbtc [~dfmb_@2001:8a0:f342:ad01:f5bf:232:7e68:eb10] has joined #bitcoin-core-dev 04:06 -!- mol_ [~mol@unaffiliated/molly] has quit [Ping timeout: 260 seconds] 04:07 -!- dfmb_btc [~dfmb_@2001:8a0:f342:ad01:f872:6c02:f240:b52c] has quit [Ping timeout: 260 seconds] 04:24 -!- dfmb_btc [~dfmb_@2001:8a0:f342:ad01:8c3c:5dad:7a4f:310a] has joined #bitcoin-core-dev 04:27 -!- dfmbbtc [~dfmb_@2001:8a0:f342:ad01:f5bf:232:7e68:eb10] has quit [Ping timeout: 260 seconds] 04:36 -!- braydonf [~braydon@gateway/tor-sasl/braydonf] has quit [Remote host closed the connection] 04:36 -!- braydonf [~braydon@gateway/tor-sasl/braydonf] has joined #bitcoin-core-dev 04:49 -!- surja795 [~surja795@c-24-61-194-104.hsd1.ma.comcast.net] has joined #bitcoin-core-dev 04:50 -!- jonatack_ [~jon@37.164.233.66] has joined #bitcoin-core-dev 04:53 -!- surja795 [~surja795@c-24-61-194-104.hsd1.ma.comcast.net] has quit [Ping timeout: 256 seconds] 04:54 -!- jonatack [~jon@37.173.38.62] has quit [Ping timeout: 264 seconds] 04:58 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 04:58 < bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/3b1e289248dc...c1cd2b5a97f4 04:58 < bitcoin-git> bitcoin/master fa082d0 MarcoFalke: travis: Remove valgrind 04:58 < bitcoin-git> bitcoin/master c1cd2b5 MarcoFalke: Merge #18899: travis: Remove valgrind 04:58 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 04:58 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 04:58 < bitcoin-git> [bitcoin] MarcoFalke merged pull request #18899: travis: Remove valgrind (master...2005-RemoveTravis) https://github.com/bitcoin/bitcoin/pull/18899 04:58 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 04:59 -!- per [~per@gateway/tor-sasl/wsm] has joined #bitcoin-core-dev 05:00 -!- subdriven1 [~subdriven@37.120.217.243] has quit [] 05:04 -!- dfmbbtc [~dfmb_@2001:8a0:f342:ad01:2c72:6490:9f2e:3d83] has joined #bitcoin-core-dev 05:06 -!- theStack [~honeybadg@vps1648322.vs.webtropia-customer.com] has joined #bitcoin-core-dev 05:07 -!- dfmb_btc [~dfmb_@2001:8a0:f342:ad01:8c3c:5dad:7a4f:310a] has quit [Ping timeout: 260 seconds] 05:14 -!- dfmb_btc [~dfmb_@2001:8a0:f342:ad01:c98:d71d:f0d2:8291] has joined #bitcoin-core-dev 05:17 -!- dfmbbtc [~dfmb_@2001:8a0:f342:ad01:2c72:6490:9f2e:3d83] has quit [Ping timeout: 240 seconds] 05:18 -!- bpalmer1 [~bpalmer@217.146.82.122] has joined #bitcoin-core-dev 05:18 -!- Kiminuo [~mix@141.98.103.76] has joined #bitcoin-core-dev 05:22 -!- Deacyde [~Deacyde@unaffiliated/deacyde] has quit [Read error: Connection reset by peer] 05:23 -!- mol_ [~mol@unaffiliated/molly] has joined #bitcoin-core-dev 05:24 -!- dfmbbtc [~dfmb_@2001:8a0:f342:ad01:484c:65dd:704:29fb] has joined #bitcoin-core-dev 05:24 -!- Kiminuo [~mix@141.98.103.76] has quit [Quit: Leaving] 05:26 -!- molz_ [~mol@unaffiliated/molly] has quit [Ping timeout: 240 seconds] 05:27 -!- dfmb_btc [~dfmb_@2001:8a0:f342:ad01:c98:d71d:f0d2:8291] has quit [Ping timeout: 240 seconds] 05:38 -!- Emcy [~Emcy@unaffiliated/emcy] has quit [Read error: Connection reset by peer] 05:40 -!- Emcy [~Emcy@unaffiliated/emcy] has joined #bitcoin-core-dev 05:45 -!- Highway61 [~Thunderbi@104.223.94.82] has joined #bitcoin-core-dev 05:47 < 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 05:47 < 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 05:47 < 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 05:58 -!- surja795 [~surja795@c-24-61-194-104.hsd1.ma.comcast.net] has joined #bitcoin-core-dev 06:00 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 06:00 < bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/c1cd2b5a97f4...56611b0e2405 06:00 < bitcoin-git> bitcoin/master 1e94a2b Russell Yanofsky: depends: Add --sysroot option to mac os native compile flags 06:00 < bitcoin-git> bitcoin/master 56611b0 fanquake: Merge #18743: depends: Add --sysroot option to mac os native compile flags... 06:00 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 06:01 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 06:01 < 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 06:01 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 06:03 -!- surja795 [~surja795@c-24-61-194-104.hsd1.ma.comcast.net] has quit [Ping timeout: 272 seconds] 06:03 -!- IGHOR [~quassel@93.178.216.72] has quit [Quit: http://quassel-irc.org ? ??????????? ?????????. ????-??.] 06:09 -!- IGHOR [~quassel@93.178.216.72] has joined #bitcoin-core-dev 06:14 -!- molakala [~sumanth.b@c-73-119-29-250.hsd1.ma.comcast.net] has joined #bitcoin-core-dev 06:27 -!- roconnor [~roconnor@host-45-58-197-21.dyn.295.ca] has joined #bitcoin-core-dev 06:33 < hebasto> luke-jr: what is wrong with "regression to #7522"? what builds fail? 06:33 < 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 06:34 < 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 06:35 < hebasto> luke-jr: gitian? 06:35 < luke-jr> no, not gitian 06:35 < luke-jr> eg, https://bugs.gentoo.org/476294 06:36 < luke-jr> relying on broken behaviour in gitian is not a good idea anyway 06:37 < hebasto> IIUC, it is related to package maintaining? 06:38 < luke-jr> hebasto: it's related to building non-git source, within a subdirectory of a foreign git repo 06:39 < luke-jr> even without the sandboxing Gentoo used to detect it, it would still do the wrong thing 06:39 < luke-jr> you were able to remove the build.h hack successfully, *because* you were relying on this incorrect behaviour 06:45 -!- mol_ [~mol@unaffiliated/molly] has quit [Ping timeout: 264 seconds] 06:47 < hebasto> luke-jr: I see now... 06:48 -!- proofofkeags [~proofofke@174-29-9-247.hlrn.qwest.net] has joined #bitcoin-core-dev 06:56 < luke-jr> hebasto: so in light of that, any ideas for doing this better? ☺ 06:59 -!- mdunnio [~mdunnio@208.59.170.5] has joined #bitcoin-core-dev 06:59 -!- brakmic [~brakmic@185.183.85.108] has joined #bitcoin-core-dev 07:00 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 07:00 < bitcoin-git> [bitcoin] MarcoFalke opened pull request #18905: travis: Remove s390x (master...2005-removeTravis) https://github.com/bitcoin/bitcoin/pull/18905 07:00 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 07:01 < hebasto> luke-jr: still looking for... 07:08 < luke-jr> if only git substitutions let you do a tag name.. 07:09 < hebasto> BITCOIN_GENBUILD_NO_GIT variable? 07:28 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 07:28 < bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/56611b0e2405...f54753293fe7 07:28 < bitcoin-git> bitcoin/master 8c705ff MarcoFalke: travis: Remove s390x 07:28 < bitcoin-git> bitcoin/master f547532 MarcoFalke: Merge #18905: travis: Remove s390x 07:28 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 07:29 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 07:29 < bitcoin-git> [bitcoin] MarcoFalke merged pull request #18905: travis: Remove s390x (master...2005-removeTravis) https://github.com/bitcoin/bitcoin/pull/18905 07:29 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 07:31 -!- promag [~promag@bl19-22-20.dsl.telepac.pt] has joined #bitcoin-core-dev 07:43 < luke-jr> hebasto: ? 07:45 -!- mol [~mol@unaffiliated/molly] has joined #bitcoin-core-dev 07:45 < hebasto> could setting BITCOIN_GENBUILD_NO_GIT=1 prevent from getting version/hash from unrelated git repos? 07:46 < luke-jr> yes, but shouldn't be needed 07:49 -!- proofofkeags [~proofofke@174-29-9-247.hlrn.qwest.net] has quit [Ping timeout: 258 seconds] 07:49 < hebasto> it seems the simplest solution along with your commit https://github.com/bitcoin/bitcoin/pull/18818/commits/b9054bce073620f9bf8ff99cde23056e93012b53 07:50 < hebasto> I mean w.r.t. 0.20 release process 07:51 < luke-jr> users needing extra steps to workaround a regression isn't really a solution 07:54 -!- dfmb_btc [~dfmb_@2001:8a0:f342:ad01:c439:3250:b865:80ad] has joined #bitcoin-core-dev 07:55 -!- dfmb_btc [~dfmb_@2001:8a0:f342:ad01:c439:3250:b865:80ad] has quit [Remote host closed the connection] 07:55 < hebasto> isn't BITCOIN_GENBUILD_NO_GIT intended for this? 07:56 < hebasto> than extra step could be documented 07:56 -!- dfmb_btc [~dfmb_@2001:8a0:f342:ad01:c439:3250:b865:80ad] has joined #bitcoin-core-dev 07:57 < hebasto> besides, building within a subdirectory of a foreign git repo seems not a common case 07:57 -!- dfmbbtc [~dfmb_@2001:8a0:f342:ad01:484c:65dd:704:29fb] has quit [Ping timeout: 260 seconds] 07:58 < luke-jr> hebasto: no, it isn't. 07:58 < luke-jr> just because it's uncommon doesn't mean we should do the wrong thing.. 08:00 -!- bpalmer1 [~bpalmer@217.146.82.122] has quit [] 08:00 -!- proofofkeags [~proofofke@174-29-9-247.hlrn.qwest.net] has joined #bitcoin-core-dev 08:03 < hebasto> if not this case, what are other usecases for BITCOIN_GENBUILD_NO_GIT ? 08:04 -!- dfmbbtc [~dfmb_@2001:8a0:f342:ad01:b014:7e0:ea87:50b5] has joined #bitcoin-core-dev 08:05 -!- proofofkeags [~proofofke@174-29-9-247.hlrn.qwest.net] has quit [Ping timeout: 256 seconds] 08:05 < luke-jr> hebasto: if for some reason the user doesn't want git called at all 08:07 -!- dfmb_btc [~dfmb_@2001:8a0:f342:ad01:c439:3250:b865:80ad] has quit [Ping timeout: 244 seconds] 08:11 -!- michaelfolkson [~textual@2a00:23c5:be01:b201:6c19:bdb9:a429:1127] has joined #bitcoin-core-dev 08:12 -!- jarthur [~jarthur@2605:6000:1019:4971:2da9:ccea:d254:afc4] has joined #bitcoin-core-dev 08:18 -!- promag [~promag@bl19-22-20.dsl.telepac.pt] has quit [Remote host closed the connection] 08:25 -!- michaelfolkson [~textual@2a00:23c5:be01:b201:6c19:bdb9:a429:1127] has quit [Quit: Sleep mode] 08:26 -!- jarthur [~jarthur@2605:6000:1019:4971:2da9:ccea:d254:afc4] has quit [Remote host closed the connection] 08:26 -!- michaelfolkson [~textual@2a00:23c5:be01:b201:6c19:bdb9:a429:1127] has joined #bitcoin-core-dev 08:27 -!- jarthur [~jarthur@2605:6000:1019:4971:2da9:ccea:d254:afc4] has joined #bitcoin-core-dev 08:32 -!- jarthur [~jarthur@2605:6000:1019:4971:2da9:ccea:d254:afc4] has quit [Remote host closed the connection] 08:32 -!- jarthur [~jarthur@2605:6000:1019:4971:6895:8d36:7946:d707] has joined #bitcoin-core-dev 08:33 -!- surja795 [~surja795@c-24-61-194-104.hsd1.ma.comcast.net] has joined #bitcoin-core-dev 08:37 -!- agrotronic [~agrotroni@237.red-83-52-176.dynamicip.rima-tde.net] has joined #bitcoin-core-dev 08:37 -!- surja795 [~surja795@c-24-61-194-104.hsd1.ma.comcast.net] has quit [Ping timeout: 260 seconds] 08:42 -!- kljasdfvv [~flack@p200300D46F079C0064587BB8C9AFE742.dip0.t-ipconnect.de] has quit [Quit: Konversation terminated!] 08:45 < achow101> luke-jr: what do you do for bdb for the ppa? 08:49 -!- Talkless [~Talkless@hst-227-49.splius.lt] has joined #bitcoin-core-dev 08:51 < luke-jr> achow101: links to system db4.8 08:52 -!- kers [~kers@37.120.203.188] has joined #bitcoin-core-dev 08:52 < luke-jr> which is also a package provided by the ppa 08:54 -!- Guyver2_ [Guyver@guyver2.xs4all.nl] has joined #bitcoin-core-dev 08:57 -!- Guyver2 [Guyver@guyver2.xs4all.nl] has quit [Ping timeout: 256 seconds] 08:58 -!- promag [~promag@bl19-22-20.dsl.telepac.pt] has joined #bitcoin-core-dev 08:59 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-dev 08:59 -!- andrewtoth [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Ping timeout: 240 seconds] 09:00 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection] 09:00 -!- proofofkeags [~proofofke@174-29-9-247.hlrn.qwest.net] has joined #bitcoin-core-dev 09:02 -!- michaelf_ [~textual@2a00:23c5:be01:b201:d011:ff30:38d9:30c9] has joined #bitcoin-core-dev 09:03 -!- promag [~promag@bl19-22-20.dsl.telepac.pt] has quit [Ping timeout: 256 seconds] 09:04 -!- michaelfolkson [~textual@2a00:23c5:be01:b201:6c19:bdb9:a429:1127] has quit [Ping timeout: 240 seconds] 09:19 -!- vasild_ [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-dev 09:20 -!- jarthur_ [~jarthur@2605:6000:1019:4971:2da9:ccea:d254:afc4] has joined #bitcoin-core-dev 09:20 -!- agrotronic [~agrotroni@237.red-83-52-176.dynamicip.rima-tde.net] has quit [Quit: Leaving] 09:21 -!- dfmbbtc [~dfmb_@2001:8a0:f342:ad01:b014:7e0:ea87:50b5] has quit [Remote host closed the connection] 09:21 -!- dfmbbtc [~dfmb_@2001:8a0:f342:ad01:b014:7e0:ea87:50b5] has joined #bitcoin-core-dev 09:23 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds] 09:23 -!- vasild_ is now known as vasild 09:23 -!- jarthur [~jarthur@2605:6000:1019:4971:6895:8d36:7946:d707] has quit [Ping timeout: 244 seconds] 09:24 -!- dfmb_btc [~dfmb_@2001:8a0:f342:ad01:9493:fd5d:cddc:bdd8] has joined #bitcoin-core-dev 09:26 -!- jarthur_ [~jarthur@2605:6000:1019:4971:2da9:ccea:d254:afc4] has quit [Remote host closed the connection] 09:27 -!- dfmbbtc [~dfmb_@2001:8a0:f342:ad01:b014:7e0:ea87:50b5] has quit [Ping timeout: 256 seconds] 09:38 -!- Guyver2_ is now known as Guyver2 09:40 -!- jarthur [~jarthur@2605:6000:1019:4971:f183:a637:1104:8414] has joined #bitcoin-core-dev 09:41 -!- promag [~promag@Bl19-22-20.dsl.telepac.pt] has joined #bitcoin-core-dev 09:45 -!- jarthur [~jarthur@2605:6000:1019:4971:f183:a637:1104:8414] has quit [Ping timeout: 260 seconds] 09:45 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Remote host closed the connection] 09:50 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined #bitcoin-core-dev 09:50 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 260 seconds] 09:59 -!- lightlike [~lightlike@p200300C7EF1D8900B0A411C1CCBBCDEB.dip0.t-ipconnect.de] has joined #bitcoin-core-dev 10:01 -!- jonatack_ [~jon@37.164.233.66] has quit [Quit: jonatack_] 10:01 -!- jonatack [~jon@37.164.233.66] has joined #bitcoin-core-dev 10:01 -!- michaelf_ [~textual@2a00:23c5:be01:b201:d011:ff30:38d9:30c9] has quit [Ping timeout: 240 seconds] 10:02 -!- jarthur [~jarthur@2605:6000:1019:4971:d12d:de70:a8e9:da20] has joined #bitcoin-core-dev 10:04 -!- michaelfolkson [~textual@2a00:23c5:be01:b201:358b:f356:e6b1:9e1b] has joined #bitcoin-core-dev 10:11 -!- jarthur_ [~jarthur@2605:6000:1019:4971:c99b:beeb:4e88:7ed8] has joined #bitcoin-core-dev 10:12 -!- promag [~promag@Bl19-22-20.dsl.telepac.pt] has quit [Remote host closed the connection] 10:14 -!- jarthur [~jarthur@2605:6000:1019:4971:d12d:de70:a8e9:da20] has quit [Ping timeout: 260 seconds] 10:17 -!- promag [~promag@Bl19-22-20.dsl.telepac.pt] has joined #bitcoin-core-dev 10:25 -!- proofofkeags [~proofofke@174-29-9-247.hlrn.qwest.net] has quit [Remote host closed the connection] 10:28 -!- promag [~promag@Bl19-22-20.dsl.telepac.pt] has quit [Remote host closed the connection] 10:28 -!- promag [~promag@bl19-22-20.dsl.telepac.pt] has joined #bitcoin-core-dev 10:33 -!- promag [~promag@bl19-22-20.dsl.telepac.pt] has quit [Ping timeout: 258 seconds] 10:34 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds] 10:34 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 10:36 -!- tryphe_ [~tryphe@unaffiliated/tryphe] has joined #bitcoin-core-dev 10:39 -!- tryphe [~tryphe@unaffiliated/tryphe] has quit [Ping timeout: 258 seconds] 10:44 -!- proofofkeags [~proofofke@174-29-9-247.hlrn.qwest.net] has joined #bitcoin-core-dev 10:48 -!- tryphe_ is now known as tryphe 10:49 -!- mol [~mol@unaffiliated/molly] has joined #bitcoin-core-dev 10:50 -!- promag [~promag@bl19-22-20.dsl.telepac.pt] has joined #bitcoin-core-dev 10:53 -!- timothy [~tredaelli@redhat/timothy] has quit [Remote host closed the connection] 11:00 -!- kers [~kers@37.120.203.188] has quit [] 11:01 -!- promag [~promag@bl19-22-20.dsl.telepac.pt] has quit [Remote host closed the connection] 11:03 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Ping timeout: 240 seconds] 11:11 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev 11:14 -!- jarthur_ [~jarthur@2605:6000:1019:4971:c99b:beeb:4e88:7ed8] has quit [Remote host closed the connection] 11:14 -!- kvaciral [~kvaciral@185.198.57.211] has joined #bitcoin-core-dev 11:16 -!- jarthur [~jarthur@2605:6000:1019:4971:c99b:beeb:4e88:7ed8] has joined #bitcoin-core-dev 11:16 -!- jarthur [~jarthur@2605:6000:1019:4971:c99b:beeb:4e88:7ed8] has quit [Read error: Connection reset by peer] 11:16 -!- jarthur [~jarthur@2605:6000:1019:4971:250b:ccc1:7682:e231] has joined #bitcoin-core-dev 11:20 -!- Dimlock [~Dimlock@84.39.117.57] has joined #bitcoin-core-dev 11:21 -!- promag [~promag@Bl19-22-20.dsl.telepac.pt] has joined #bitcoin-core-dev 11:26 -!- michaelfolkson [~textual@2a00:23c5:be01:b201:358b:f356:e6b1:9e1b] has quit [Ping timeout: 240 seconds] 11:32 -!- promag [~promag@Bl19-22-20.dsl.telepac.pt] has quit [Remote host closed the connection] 11:32 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #bitcoin-core-dev 11:33 -!- michaelfolkson [~textual@2a00:23c5:be01:b201:b924:7fc5:4d11:6eb2] has joined #bitcoin-core-dev 11:35 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 11:35 < 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 11:35 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 11:40 -!- promag [~promag@bl19-22-20.dsl.telepac.pt] has joined #bitcoin-core-dev 11:41 -!- nothingmuch [~nothingmu@unaffiliated/nothingmuch] has quit [Quit: ZNC - http://znc.in] 11:41 -!- bsm117532 [~bsm117532@unaffiliated/bsm117532] has quit [Quit: *burp*] 11:41 -!- theStack [~honeybadg@vps1648322.vs.webtropia-customer.com] has quit [Quit: Lost terminal] 11:47 -!- promag [~promag@bl19-22-20.dsl.telepac.pt] has quit [Disconnected by services] 11:47 -!- promag_ is now known as promag 11:47 < promag> I can't be in the meeting, I think #18578 and #18894 should be for 0.20 11:47 < gribble> https://github.com/bitcoin/bitcoin/issues/18578 | gui: Fix leak in CoinControlDialog::updateView by promag · Pull Request #18578 · bitcoin/bitcoin · GitHub 11:47 < 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 11:47 -!- promag_ [~promag@Bl19-22-20.dsl.telepac.pt] has joined #bitcoin-core-dev 11:48 -!- davterra [~dulyNoded@2601:603:4f00:63d0:a00:27ff:fed5:b769] has quit [Quit: Leaving] 11:50 -!- promag_ [~promag@Bl19-22-20.dsl.telepac.pt] has quit [Remote host closed the connection] 11:52 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 11:52 < 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 11:52 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 12:02 < fjahr> meeting? 12:02 < wumpus> #startmeeting 12:02 < lightningbot> Meeting started Thu May 7 19:02:10 2020 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot. 12:02 < lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic. 12:02 < jonasschnelli> hi 12:02 < meshcollider> hi 12:02 < fjahr> hi 12:02 < achow101> hi 12:02 < 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 12:02 < sipsorcery> hi 12:02 < elichai2> hi 12:02 < wumpus> jeremyrubin lightlike emilengler jonatack hebasto jb55 12:02 < gleb> hi 12:02 < ariard> hi 12:02 < jonatack> hi 12:02 < sipa> hi 12:02 < jb55> hi 12:03 < jnewbery> hi 12:03 < wumpus> one proposed topic (by jnewbery): removing valgrind from travis PR builds but that was already done 12:03 < gleb> I have something to bring up, unless we're still to busy with 0.20... 12:03 < meshcollider> There was another by Andrew re. wallet storage 12:03 < jnewbery> I have a little bit to add to the valgrind topic, just for context 12:04 < wumpus> gleb: if you have any topics to propose please do 12:04 < wumpus> we're not too busy with 0.20, 0.20 is going pretty slow at the moment 12:05 < gleb> I want to ask about adding extra threads in light of my work in #18421 12:05 < wumpus> most focus is on 0.21/master 12:05 < 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 12:05 < wumpus> ok 12:05 < jkczyz> hi 12:05 < wumpus> we'll come to those, let's start with high prio as usual 12:06 < wumpus> #topic High priority for review 12:06 < achow101> meshcollider: I think that topic is for tomorrow's wallet meeting 12:06 < wumpus> https://github.com/bitcoin/bitcoin/projects/8 4 blockers, 1 bugfix, 5 chasing concept ACK 12:06 < jnewbery> I'd like to add #18877 please 12:06 < meshcollider> achow101: ok sure :) 12:06 < gribble> https://github.com/bitcoin/bitcoin/issues/18877 | Serve cfcheckpt requests by jnewbery · Pull Request #18877 · bitcoin/bitcoin · GitHub 12:07 < wumpus> jnewbery: added 12:07 < wumpus> (to blockers, I suppose?) 12:07 < jnewbery> yes 12:07 < jnewbery> blocking the rest of BIP 157 implementation 12:07 < jnewbery> thanks! 12:08 < lightlike> #17037, which is on "chasing concept ACKs", was closed yesterday 12:08 < 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 12:08 < wumpus> lightlike: thanks, removed 12:09 < wumpus> anything else to change/add/remove? 12:10 < jonatack> nice to see the blockers moving forward lately 12:10 < wumpus> yes, two have been merged this week IIRC 12:11 < wumpus> looks like #17994 is kind of close to merge too 12:11 < gribble> https://github.com/bitcoin/bitcoin/issues/17994 | validation: flush undo files after last block write by kallewoof · Pull Request #17994 · bitcoin/bitcoin · GitHub 12:11 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Quit: = ""] 12:11 < wumpus> and #16946 12:11 < gribble> https://github.com/bitcoin/bitcoin/issues/16946 | wallet: include a checksum of encrypted private keys by achow101 · Pull Request #16946 · bitcoin/bitcoin · GitHub 12:12 < wumpus> #topic Adding another scheduler thread (gleb) 12:12 < gleb> I implemented #18421 which helps non-reachable nodes to be less visible to the upstream infrastructure (DNS servers, ASNs). 12:12 < 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. 12:12 < 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 12:12 < 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 12:12 < gleb> for so long. 12:13 < 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…) 12:13 < wumpus> can't this be done asynchronously? 12:13 < wumpus> it seems the thread would spend most of its time waiting for the network anyhow 12:13 -!- Talkless [~Talkless@hst-227-49.splius.lt] has quit [Quit: Konversation terminated!] 12:14 < gleb> Yeah, it hangs on the network call. 12:14 < wumpus> IIRC libevent has some async DNS functionality 12:14 < luke-jr> oops, sorry I'm late 12:15 < gleb> That might help actually! Will investigate this then. Thank you wumpus. Wasn't sure which tools we have available. 12:15 < wumpus> in any case, on 32-bit systems we don't want to add another thread, on 64 bit systems it doesn't matter 12:16 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 12:16 < 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 12:16 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 12:16 < gleb> What's the reason behind not adding it on 32-bit? 12:16 < 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 12:16 < wumpus> virtual memory space 12:16 < gleb> Oh, i see. 12:16 < wumpus> it's really tight on 32 bit already 12:16 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined #bitcoin-core-dev 12:16 < gleb> Alright, I opened an issue for broader thread discussion is #18488, if anyone is interested. Otherwise, done here, will explore libevent. 12:16 < gribble> https://github.com/bitcoin/bitcoin/issues/18488 | Support for non-immediate periodic tasks with variable runtime · Issue #18488 · bitcoin/bitcoin · GitHub 12:17 < wumpus> in any case if you can avoid adding a thread that'd be good 12:19 < ariard> do people have a bit of time to talk about bip157 or more broadly light clients ? 12:19 < wumpus> #topic Removing valgrind from travis (jnewbery) 12:20 < jnewbery> thanks wumpus 12:20 < jnewbery> like you say, this was mostly resolved this morning, but I thought I'd give some more context in general 12:20 < jnewbery> In December, we added a travis job to run all the functional test in valgrind for every PR. 12:20 < jnewbery> That meant that ci runs were taking around 3 hours (and much longer in some cases due to backlog). 12:20 < jnewbery> Thankfully, we're not doing that since this morning :) 12:20 < 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 12:20 < jnewbery> We are, however, still running ASan/LSan and UBSan jobs, which take about an hour. 12:20 < 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. 12:21 < 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. 12:21 < ariard> wumpus: ah yes I proposed yesterday but I should have used #proposedmeetingtopic right 12:21 < 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 12:21 < 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 12:21 < elichai2> I have a suggestion, but I'm not sure how easy to implement is that 12:22 < jnewbery> Really, just a plea to keep travis times down on PR jobs. It makes developers' lives much pleasanter! 12:22 < wumpus> but running it on everythign was always overkill 12:22 < wumpus> I agree, long turnaround times for tests are bad for a project 12:22 < 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 12:22 < wumpus> please use testing time and resources efficiently 12:22 < luke-jr> elichai2: does Travis support that? 12:22 < wumpus> don't do silly or overkill things 12:23 < sipa> i think that would introduce way more process overhead for maintainers 12:23 < jonasschnelli> also... don't forget that bitcoinbuilds.org runs usually faster but without the ASAN/TSAN and fuzzers 12:23 < elichai2> luke-jr: good question, sadly I doubt it supports it natively . I know rust-lang is doing it via a bot. 12:23 < jonasschnelli> (for a quick feedback on a PR) 12:23 < wumpus> jonasschnelli: hah 12:23 < luke-jr> jonasschnelli: can we get that to report to GitHub? 12:23 < jonasschnelli> luke-jr: it is 12:23 < jnewbery> I think it probably does support it. You just set it up to run on every push to master 12:23 * luke-jr didn't notice O.o 12:24 < jonasschnelli> https://github.com/jonasschnelli/bitcoin-core-ci 12:24 < luke-jr> jnewbery: well, it'd be nice to get them aall runn BEFORE merge 12:24 < jonatack> jonasschnelli: yes, i always look at bitcoinbuilds for first feedback, then much later, travis on my own github branch and on bitcoin/bitcoin 12:24 < jnewbery> but like sipa says, anything that causes things to not get caught pre-merge transfers work to the maintainers 12: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 12:24 < jonatack> jonasschnelli: i'm grateful for bitcoinbuilds 12:24 < elichai2> oh sipa was talking about nightly builds 12:24 < luke-jr> I only see AppVeyor and Travis on the PR I just made.. 12:24 < sipa> we're talking about different things 12:25 < sipa> i'm totally in favor of doing more work on master merges than on PRs 12:25 < sipa> things can always be reverted if there is an unexpected problem soon after merging 12:26 < elichai2> sipa: and then maintainers need to check the result on the nightly CI and revert if something broke it? 12:26 < wumpus> rather not, of course, but the full valgrind run wasn't that effective in catching things anyway 12:26 < 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...) 12:26 < luke-jr> does valgrind do anything the *Sans don't? 12:26 < sipa> luke-jr: it can test actual production binaries 12:26 < elichai2> luke-jr: I think gmaxwell show me an example once but I don't remember 12:27 < luke-jr> sipa: oh, true 12:27 < sipa> the sans all require different builds that invasively change the output 12:27 < luke-jr> well, Valgrind does it by runtime patching of stuff… not sure that's much different? 12:27 < luke-jr> and emulation IIRC 12:27 < sipa> (they can also test things that valgrind can't, because they have knowledge of the source code) 12:27 < wumpus> yes 12:27 < luke-jr> (I've seen Valgrind emulate an instruction *wrong* before) 12:28 < sipa> luke-jr: sure 12:28 < wumpus> both approaches have their advantages and disadvantages I think that's clear 12:28 < 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 12:29 < wumpus> true 12:29 < sipa> because it's very optimizer dependent for example, and sanitizer builds prevent some optimizations (or at least interfere with it significantly) 12:29 < wumpus> so yes it's good to test master under valgrind as well 12:29 < wumpus> once in a while at least 12:29 < elichai2> can the opposite also be true? (ie overflow that is optimized out because the read was never used etc) 12:29 < sipa> sure 12:29 < sipa> that's what sanitizers are for 12:30 < sipa> they primarily test for discoverable bugs in the source code 12:31 < wumpus> yes good point 12:31 < elichai2> FWIW I think I have a mainnet node lying around running under valgrind constantly (although since covid I didn't check it) 12:32 < jonasschnelli> elichai2: social node distancing 12:32 < wumpus> hehe 12:32 < luke-jr> aka Tor? 12:32 < elichai2> yeah lol, I don't want it to get infected with some UB :P 12:33 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #bitcoin-core-dev 12:33 < wumpus> #topic bip157 and light clients (ariard) 12:33 < jonatack> the full valgrind run brought to light some issues for me recently that lead to more robust code... #18681 was an example 12:33 < gribble> https://github.com/bitcoin/bitcoin/issues/18681 | donotmerge: build: Enable thread-local with glibc compat by laanwj · Pull Request #18681 · bitcoin/bitcoin · GitHub 12:34 < jonatack> er, #18691 12:34 < 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 12:34 < ariard> Yes so about light client I had really interesting discussion with people 12:34 < ariard> and the constructive outcome of this was it would be better to have a more defined policy 12:35 < ariard> when we now a solution isn't perfect, but at same time not restrain the project to make steps forward 12:35 < ariard> what I was worry about, is by supporting bip157 in core, all people building such nice LN wallets 12:35 < wumpus> jonatack: hehe the cookie file race was detected just because valgrind makes things slow :) 12:35 < ariard> consider the validation backend as a solved issue 12:35 < luke-jr> BIP157 isn't just "not perfect", it's harmful/backward 12:35 < jonatack> yep :p 12:35 -!- theStack [~honeybadg@vps1648322.vs.webtropia-customer.com] has joined #bitcoin-core-dev 12:36 < ariard> instead of having well-awareness, they are free-riding on the p2p network for now 12:38 < 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). 12:38 < ariard> and having a better idea for which bip157 support was aimed, people using their mobile wallets with their full-nodes 12:38 < ariard> or servicing random clients in the wild, which maybe a bit insecure 12:39 < sipa> there is nothing insecure about it; it's just a bad idea for them to trust random peers 12:39 < wumpus> the same issue as with the bloom filters again 12:39 < sipa> (but that's still better than BIP37...) 12:39 < luke-jr> jonasschnelli: what is the use case for it? 12:39 < wumpus> (though at least this doesn't have as much DoS potential) 12:39 < sipa> wumpus: i don't think so; 12:39 < sipa> exactly 12:39 < luke-jr> bloom filters are strictly better I think 12:39 < sipa> BIP157 support is very cheap for the server 12:39 < sipa> luke-jr: how so? 12:39 < wumpus> it's a kind of 'altruism' that might not be warranted 12:40 < luke-jr> sipa: lower overhead 12:40 < sipa> luke-jr: for whom? 12:40 < ariard> on the security aspect, supporting bip157 in core encourage people to connect directly to random peers 12:40 < wumpus> luke-jr: wait, how? 12:40 < luke-jr> sipa: for everyone 12:40 < sipa> luke-jr: wut 12:40 < ariard> and almost all bip157 clietns, dont't have strong addr management countermeasures 12:40 < wumpus> ariard: but that's *their* problem 12:40 < sipa> BIP157 is certainly harder on clients 12:40 < ariard> *peer management protection 12:40 < luke-jr> take the reasonable use case of a user using a light wallet with their own full node 12:40 < wumpus> we care about the server side 12:40 < luke-jr> bloom does this fine, with very little overhead 12:40 < ariard> wumpus: but do you want to make it easy for people to build insecure solutions? 12:40 < luke-jr> you scan the blockchain once on the server side 12:41 < sipa> luke-jr: but you need to do it once per client 12:41 < sipa> with BIP157 you do it once 12:41 < luke-jr> sipa: how many people have multiple clients? 12:41 < luke-jr> and even a few clients is still relatively low total overhead there 12:41 < wumpus> scanning on the server side was always the problem 12:41 < luke-jr> wumpus: but that's exactly the ideal in this case 12:41 < luke-jr> you don't want to burden your phone/battery 12:41 < wumpus> if you allow random people on the internet to offload computation to you, you're infinitely generous 12:42 < luke-jr> you don't. this isn't for random people, it's for trusted peers… 12:42 < luke-jr> your own wallets 12:42 < ariard> scanning on the server side isn't great, even worst with LN clients verifying channel opening 12:42 < wumpus> for whitelisted peers it's okay 12:42 < wumpus> sure 12:42 < luke-jr> random people using it is harmful, and the very reason to avoid merging it 12:42 -!- owowo [~ovovo@unaffiliated/ovovo] has quit [Ping timeout: 260 seconds] 12:42 < luke-jr> ariard: server side typically has ~unlimited power 12:42 < sipa> luke-jr: i agree it's a bad idea; i'm not sure it is harmful 12:42 < luke-jr> client has a battery to worry about 12:43 < luke-jr> sipa: it encourages light wallets to use foreign nodes 12:43 < sipa> and it would be far less of a bad idea if it was softforked in, so the filters are verifiable 12:43 < ariard> maybe it should be part of the release node, to advice whitelisting 12:43 < ariard> *notes 12:43 < sipa> but that's not going to happen any time soon 12:43 < luke-jr> sipa: that doesn't fix the problem of people not usign their own node 12:43 < jnewbery> if it's your own server, you don't need an spv protocol. Just upload your xpub 12:43 < sipa> luke-jr: not everyone uses their own full node, period 12:43 < theStack> so the rationale here from luke-jr is that in the end every person should have its own full node? 12:43 < sipa> luke-jr: there are good and bad ways to deal with it 12:43 < ariard> luke-jr: yes but rescannning code of core isn't that performant, no parallelization, a lot of lock tacking 12:44 < luke-jr> jnewbery: yes, that direction seems a lot better IMO 12:44 < 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. 12:44 < jnewbery> good, so your use case is solved 12:44 < luke-jr> jnewbery: ⁇ 12:44 < ariard> jonasschenelli: are you thinking about intentional DoS ? 12:44 < luke-jr> my point is that there is no use case for neutrino 12:44 < jnewbery> not everyone wants to use bitcoin in the same way as you, and that's ok 12:45 < jonasschnelli> ariard: both... intentional or just because of the use cases 12:45 < luke-jr> Bitcoin's security model depends on at least most people using their own full ndoe 12:45 < 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 12:45 < sipa> luke-jr: i strongly disagree; it depends on enough people independently verifying the blockchain 12:45 < jonasschnelli> if there is the concern that there are too many BIP157 clients,... one might want to limit the bandwidth 12:45 < 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 12:45 < luke-jr> sipa: enough people = most 12:46 < sipa> luke-jr: i strongly disagree 12:46 < luke-jr> sipa: a minority verifying is useless if the majority imposes the invalid chain economically 12:46 < jonasschnelli> ariard: Same for any SPV client,... right? 12:46 -!- michaelf_ [~textual@2a00:23c5:be01:b201:cd1d:1bfd:7620:fa2] has joined #bitcoin-core-dev 12:46 < ariard> jonasschenlli: yes my concern isn't bip157 specific, I do think that's the best option available today 12:46 < luke-jr> stratum > bloom > bip157 12:46 < luke-jr> for private/trusted usage 12:47 < luke-jr> which is the only usage we should support IMO 12:47 < 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 12:47 < gleb> luke-jr: I assume you meant electrum? 12:47 < luke-jr> ariard: there's no difference 12:47 < 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 12:47 < luke-jr> gleb: Stratum is the protocol Electrum uses, yes 12:47 -!- tryphe_ [~tryphe@unaffiliated/tryphe] has joined #bitcoin-core-dev 12:48 < jonasschnelli> ariard: I would expect that wallet providers ship a recent pack of filters with the ap 12:48 < ariard> overall, bip157 is good for experimentation, while keeping awareness there is still unsolved issues on security and scalability 12:48 < luke-jr> sipa: but improving security of light wallets is a net loss of security for the network 12:48 < luke-jr> sipa: because now fewer people will use a full node of their own 12:48 < sipa> luke-jr: 99.99% of users don't even have SPV level verification 12:48 < jonasschnelli> ariard: the beauty is also that filters can be retrieved from centralized sources and CDNs 12:48 < luke-jr> sipa: if 99.99% don't have their own full node, Bitcoin has failed 12:48 -!- owowo [~ovovo@193.32.127.156] has joined #bitcoin-core-dev 12:48 -!- owowo [~ovovo@193.32.127.156] has quit [Changing host] 12:48 -!- owowo [~ovovo@unaffiliated/ovovo] has joined #bitcoin-core-dev 12:49 < 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 12:49 -!- michaelfolkson [~textual@2a00:23c5:be01:b201:b924:7fc5:4d11:6eb2] has quit [Ping timeout: 240 seconds] 12:49 < ariard> jonasschnelli: yes but what's your trust model with such centralized sources and CDNS 12:49 < jonasschnelli> ariard: IMO the goal for compact block filters is to get a block commitment at some point 12:49 < ariard> you can dissociate getting the filters from such CDN and getting filters-headers/headers from the p2p network 12:50 < jonasschnelli> ariard: also, one can crosscheck the CDN filters against some p2p loaded bip157 filters 12:50 < ariard> jonasschenlli: it would simplify SPV logic and improve their security but even committed you still need to download them 12:50 < sipa> luke-jr: Ok. 12:50 < jonasschnelli> ariard: what is the worry with downloading them? 12:50 < sipa> i don't think this discussion will lead anywhere 12:50 -!- tryphe [~tryphe@unaffiliated/tryphe] has quit [Ping timeout: 240 seconds] 12:50 < jonasschnelli> better continue the ML discussion I think 12:50 < ariard> jonasschnelli: bandwidth cost if you download them directly from the p2p network 12:51 < jonasschnelli> (happy to continue outside of this meeting) 12:51 < ariard> jonasschnelli: but yes I agree you can crosscheck the CDN filters against filter-headers provided from the p2p network 12:51 < kanzure> is the contention that light clients should be doing IBD and validation? 12:52 < jonasschnelli> heh 12:52 < 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 12:52 < ariard> kanzure: no my concern is assuming you have the bip157 light client paradigm, how do you make it scale ecosystem-wise 12:52 < sipa> at least for a majority of users 12:52 < kanzure> next question: how many times should someone have to do IBD? i think the correct answer should be only once ever.... 12:53 < kanzure> [if they can keep integrity of their download and state] 12:53 < sipa> ariard: i don't understand how your concern is any different from nodes serving blocks *at all* 12:53 < jonasschnelli> kanzure: next question: how many random peers have I misused by testing mainnet IBD 12:53 < kanzure> these and other disturbing questions. 12:54 < luke-jr> sipa: ideally 12:54 < 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 12:54 < luke-jr> because that can only result in fewer people using a full node 12:55 < 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 12:55 < ariard> and maybe faster than expected 12:55 < 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 12:55 < 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. 12:55 < luke-jr> sipa: you already have that choice with fiat: you can print monopoly money, and refuse to honour USD 12:55 < ariard> jonasschelli: yes you may have assume some reciprocity between full-nodes peers 12:55 < 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. 12:55 < ariard> at least I see incentives far more aligned 12:56 -!- promag_ [~promag@bl19-22-20.dsl.telepac.pt] has joined #bitcoin-core-dev 12:56 < sipa> luke-jr: this is not productive 12:56 < jonasschnelli> agree with jnewbery 12:56 < wumpus> 4 minutes to go 12:56 < 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 12:57 < luke-jr> light clients are a hardfork to "no rules at all" 12:58 < sipa> perhaps - but far less easily than having money on coinbase is a hardfork to "whatever monetary policy coinbase likes" 12:58 < 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? 12:58 < jnewbery> then don't enable serving cfilters :) 12:58 < luke-jr> sipa: it's the same, but miner(s) instead of coinbase 12:59 -!- michaelfolkson [~textual@2a00:23c5:be01:b201:f48a:5010:9124:3934] has joined #bitcoin-core-dev 12:59 < jonasschnelli> ariard: there is no way you know if the blocks you serve are for other full nodes 12:59 < ariard> jnewbery: sorry I don't get you on depriorirtizing nodes that are taking up resources, can you precise? 12:59 < luke-jr> jonasschnelli: technically true, but what non-full nodes download full blocks these days? 13:00 < 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 13:00 < jonasschnelli> luke-jr: wasabi did for a while (full block SPV) 13:00 < jnewbery> if your answer is 'no', then you need to keep internal book-keeping of which blocks you've served to whom 13:00 < jonasschnelli> (maybe still does) 13:00 < sipa> ariard: if a node asks too much of your resources (memory, cpu, bandwidth, i/o), deprioritize serving their incoming requests 13:00 < jnewbery> if your answer is 'yes', then how is it any different from serving a cfilter? 13:00 < ariard> jnewbery: maybe that's a fault-tolerance case and it makes sense to serve it again 13:01 -!- promag_ [~promag@bl19-22-20.dsl.telepac.pt] has quit [Ping timeout: 272 seconds] 13:01 -!- michaelf_ [~textual@2a00:23c5:be01:b201:cd1d:1bfd:7620:fa2] has quit [Ping timeout: 244 seconds] 13:01 < ariard> sipa: yes but we don't do this AFAIK? and if everyone start to deprioritizie servicing bip157 clients you do have an issue 13:01 < sipa> ariard: no, but we absolutely should 13:02 < jnewbery> sipa: +1 13:02 < sipa> (not BIP157 specifically, just in general - if you ask too much of us and we get overloaded, deprioritize) 13:02 * luke-jr still hasn't heard a use case for merging BIP157 at all, aside from harming Bitcoin 13:02 < 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? 13:03 < wumpus> this should be the end of the meeting 13:03 < sipa> i don't see what exporting and xpub has to do with that 13:03 < wumpus> maybe we should continue next week 13:03 * luke-jr either 13:03 < 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 13:03 < ariard> are effectively deployed ? 13:04 < ariard> wumpus: yes we can end, but thanks for all your points it's really interesting 13:04 < wumpus> #endmeeting 13:04 < lightningbot> Meeting ended Thu May 7 20:04:44 2020 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) 13:04 < lightningbot> Minutes: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2020/bitcoin-core-dev.2020-05-07-19.02.html 13:04 < lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2020/bitcoin-core-dev.2020-05-07-19.02.txt 13:04 < lightningbot> Log: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2020/bitcoin-core-dev.2020-05-07-19.02.log.html 13:04 < luke-jr> maybe we can get NicolasDorier to join next week <.< 13:05 < luke-jr> although it might be the middle of the night there 13:05 < sipa> this discussion should really be on the ML 13:07 < luke-jr> it is, I need to read recent replies 13:08 < ariard> luke-jr: I've read your point on supermajority of the economy, but isn't this assuming you can see the economic traffic? 13:09 < ariard> and with LN you may have not see the real payment traffic because channel 13:09 < luke-jr> ariard: measuring it accurately would require that, but not understanding what we depend on 13:09 < luke-jr> even today, we can't measure it accurately, but we can see it's not in a good situation 13:14 < 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 13:15 < ariard> but at least you don't have to download all blocks in regular time 13:15 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has left #bitcoin-core-dev [] 13:15 < luke-jr> ariard: so every stale block, you IBD⁇ 13:16 -!- mdunnio_ [~mdunnio@208.59.170.5] has joined #bitcoin-core-dev 13:17 < 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? 13:18 -!- tryphe_ is now known as tryphe 13:18 -!- mdunnio [~mdunnio@208.59.170.5] has quit [Ping timeout: 260 seconds] 13:18 < 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"? 13:22 < 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 13:22 -!- surja795 [~surja795@c-24-61-194-104.hsd1.ma.comcast.net] has joined #bitcoin-core-dev 13:23 < 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 13:23 < ariard> also maybe you can do something like assumeutxo, in case of anomalies download a utxo set and IBD from then? 13: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.. 13:25 < luke-jr> ariard: filters don't prove anything 13:25 < luke-jr> if you're okay trusting someone around you, you can do that *normally* 13:26 < luke-jr> assumeutxo does not reduce sync time 13:26 < luke-jr> assumeutxo is only acceptable provided the full IBD from zero is performed still 13:30 < 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 13:31 < ariard> and Bob maybe not okay to offer you bandwidth, but still okay to provide you headers, and you somehow trust Bob 13:32 < ariard> you can have a set of semi-trusted fallback nodes, like Alice, Bob, etc 13:32 < luke-jr> ariard: you can do that with bloom already 13:33 < ariard> luke-jr: right I'm not arguing bip157-vs-bip37 here, but more broadly on light-client model in case of forks 13:34 < luke-jr> ariard: if you have a node you personally trust, that's not quite the same thing as the light-client model 13:34 < luke-jr> even if you're only using that node to verify headers 13:36 < 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 13:38 < 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) 13:40 -!- emilengler [~emilengle@stratum0/entity/emilengler] has quit [Quit: Leaving] 13:43 -!- MrSquanchee [uid421192@gateway/web/irccloud.com/x-ddkbmywbushmvmmg] has joined #bitcoin-core-dev 13:44 -!- dfmb_btc [~dfmb_@2001:8a0:f342:ad01:9493:fd5d:cddc:bdd8] has quit [Quit: Leaving] 13:45 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Remote host closed the connection] 13:47 -!- Highway62 [~Thunderbi@ip72-204-155-64.no.no.cox.net] has joined #bitcoin-core-dev 13:48 -!- Highway61 [~Thunderbi@104.223.94.82] has quit [Ping timeout: 272 seconds] 13:48 -!- Highway62 is now known as Highway61 13:55 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-dev 14:00 -!- Dimlock [~Dimlock@84.39.117.57] has quit [] 14:00 -!- michaelfolkson [~textual@2a00:23c5:be01:b201:f48a:5010:9124:3934] has quit [Quit: Sleep mode] 14:00 -!- bsm117532 [~bsm117532@unaffiliated/bsm117532] has joined #bitcoin-core-dev 14:08 -!- Highway62 [~Thunderbi@104.223.95.2] has joined #bitcoin-core-dev 14:10 -!- Highway61 [~Thunderbi@ip72-204-155-64.no.no.cox.net] has quit [Ping timeout: 264 seconds] 14:10 -!- Highway62 is now known as Highway61 14:22 -!- Guyver2 [Guyver@guyver2.xs4all.nl] has quit [Quit: Going offline, see ya! (www.adiirc.com)] 14:50 -!- RandIter [~RandIter@185.204.1.185] has joined #bitcoin-core-dev 14:50 -!- RandIter is now known as Guest44912 14:53 -!- molakala [~sumanth.b@c-73-119-29-250.hsd1.ma.comcast.net] has quit [Ping timeout: 246 seconds] 15:14 < achow101> would it be reasonable to replace salvagewallet with a bdb deserializer and try to recover key-values ourselves instead? 15:14 -!- surja795 [~surja795@c-24-61-194-104.hsd1.ma.comcast.net] has quit [Remote host closed the connection] 15:15 -!- surja795 [~surja795@c-24-61-194-104.hsd1.ma.comcast.net] has joined #bitcoin-core-dev 15:20 -!- surja795 [~surja795@c-24-61-194-104.hsd1.ma.comcast.net] has quit [Ping timeout: 256 seconds] 15:21 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has joined #bitcoin-core-dev 15:23 < jnewbery> achow101: lots of previous discussion on this: https://github.com/bitcoin/bitcoin/pull/10540, https://github.com/bitcoin/bitcoin/issues/10991 15:23 < achow101> jnewbery: yeah, reading through a bunch of that now 15:23 < jnewbery> I think it should be in a separate wallet tool 15:26 -!- brytemorio [~oriosne@161.129.70.143] has joined #bitcoin-core-dev 15:30 -!- promag_ [~promag@bl19-22-20.dsl.telepac.pt] has joined #bitcoin-core-dev 15:34 -!- promag_ [~promag@bl19-22-20.dsl.telepac.pt] has quit [Ping timeout: 260 seconds] 15:46 -!- marcoagner [~user@bl13-226-166.dsl.telepac.pt] has quit [Ping timeout: 272 seconds] 15:47 -!- brakmic [~brakmic@185.183.85.108] has quit [] 15:51 -!- brytemorio [~oriosne@161.129.70.143] has quit [Ping timeout: 260 seconds] 15:53 -!- lightlike [~lightlike@p200300C7EF1D8900B0A411C1CCBBCDEB.dip0.t-ipconnect.de] has quit [Quit: Leaving] 16:03 -!- promag_ [~promag@bl19-22-20.dsl.telepac.pt] has joined #bitcoin-core-dev 16:10 -!- mdunnio_ [~mdunnio@208.59.170.5] has quit [Remote host closed the connection] 16:12 < luke-jr> achow101: deserialize why? just search for the data we need in any format? :P 16:14 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds] 16:19 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Ping timeout: 240 seconds] 16:19 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 16:19 < 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 16:19 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 16:20 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 16:20 < 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 16:20 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 16:21 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 16:21 < 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 16:21 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 16:21 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 16:21 < 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 16:21 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 16:21 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-dev 16:22 -!- surja795 [~surja795@c-24-61-194-104.hsd1.ma.comcast.net] has joined #bitcoin-core-dev 16:34 -!- promag_ [~promag@bl19-22-20.dsl.telepac.pt] has quit [Remote host closed the connection] 16:35 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 246 seconds] 16:44 -!- promag_ [~promag@Bl19-22-20.dsl.telepac.pt] has joined #bitcoin-core-dev 16:51 -!- jonatack_ [~jon@37.165.219.151] has joined #bitcoin-core-dev 16:54 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev 16:54 -!- jonatack [~jon@37.164.233.66] has quit [Ping timeout: 260 seconds] 17:00 -!- Guest44912 [~RandIter@185.204.1.185] has quit [] 17:02 -!- promag_ [~promag@Bl19-22-20.dsl.telepac.pt] has quit [Remote host closed the connection] 17:10 -!- jarthur_ [~jarthur@2605:6000:1019:4971:c99b:beeb:4e88:7ed8] has joined #bitcoin-core-dev 17:11 -!- jarthur_ [~jarthur@2605:6000:1019:4971:c99b:beeb:4e88:7ed8] has quit [Remote host closed the connection] 17:11 -!- jonatack_ [~jon@37.165.219.151] has quit [Quit: jonatack_] 17:11 -!- jonatack [~jon@213.152.180.5] has joined #bitcoin-core-dev 17:12 -!- MrSquanchee [uid421192@gateway/web/irccloud.com/x-ddkbmywbushmvmmg] has quit [Quit: Connection closed for inactivity] 17:12 -!- go11111111111 [~go1111111@104.156.98.86] has joined #bitcoin-core-dev 17:14 -!- jarthur [~jarthur@2605:6000:1019:4971:250b:ccc1:7682:e231] has quit [Ping timeout: 260 seconds] 17:15 -!- go121212 [go1111111@gateway/vpn/privateinternetaccess/go1111111] has quit [Ping timeout: 256 seconds] 17:15 -!- jarthur [~jarthur@2605:6000:1019:4971:ad7b:8f4c:3237:1e3a] has joined #bitcoin-core-dev 17:19 -!- promag_ [~promag@Bl19-22-20.dsl.telepac.pt] has joined #bitcoin-core-dev 17:22 -!- Snuupy1 [~Snuupy@84.39.116.180] has joined #bitcoin-core-dev 17:24 < midnight> sipa: hi! graphs..? 17:24 < midnight> :-) 17:24 -!- promag_ [~promag@Bl19-22-20.dsl.telepac.pt] has quit [Remote host closed the connection] 17:28 < sipa> midnight: what's wrong with them? 17:28 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [] 17:34 -!- theStack [~honeybadg@vps1648322.vs.webtropia-customer.com] has quit [Quit: Lost terminal] 17:35 -!- mol_ [~mol@unaffiliated/molly] has joined #bitcoin-core-dev 17:36 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 256 seconds] 17:40 -!- sipsorcery [~sipsorcer@37.228.243.107] has quit [Ping timeout: 272 seconds] 17:40 -!- sipsorcery [~sipsorcer@37.228.243.107] has joined #bitcoin-core-dev 17:43 -!- jarthur_ [~jarthur@2605:6000:1019:4971:543a:43ec:4e7f:6c7c] has joined #bitcoin-core-dev 17:46 -!- sipsorcery [~sipsorcer@37.228.243.107] has quit [Ping timeout: 246 seconds] 17:46 -!- jarthur [~jarthur@2605:6000:1019:4971:ad7b:8f4c:3237:1e3a] has quit [Ping timeout: 244 seconds] 17:58 -!- jonatack [~jon@213.152.180.5] has quit [Ping timeout: 246 seconds] 18:06 -!- sipsorcery [~sipsorcer@37.228.243.107] has joined #bitcoin-core-dev 18:29 -!- sipsorcery [~sipsorcer@37.228.243.107] has quit [Read error: Connection reset by peer] 18:31 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 18:31 < 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 18:31 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 18:37 -!- jarthur_ [~jarthur@2605:6000:1019:4971:543a:43ec:4e7f:6c7c] has quit [] 18:40 -!- Highway61 [~Thunderbi@104.223.95.2] has quit [Ping timeout: 240 seconds] 19:25 -!- mol_ [~mol@unaffiliated/molly] has quit [Ping timeout: 246 seconds] 19:50 -!- mol [~mol@unaffiliated/molly] has joined #bitcoin-core-dev 19:52 -!- surja795 [~surja795@c-24-61-194-104.hsd1.ma.comcast.net] has quit [Remote host closed the connection] 19:52 -!- surja795 [~surja795@c-24-61-194-104.hsd1.ma.comcast.net] has joined #bitcoin-core-dev 20:00 -!- Snuupy1 [~Snuupy@84.39.116.180] has quit [] 20:21 -!- nhandler1 [~nhandler@195.206.183.79] has joined #bitcoin-core-dev 20:24 -!- surja795 [~surja795@c-24-61-194-104.hsd1.ma.comcast.net] has quit [Remote host closed the connection] 20:30 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 272 seconds] 20:35 -!- proofofkeags [~proofofke@174-29-9-247.hlrn.qwest.net] has quit [Remote host closed the connection] 20:36 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined #bitcoin-core-dev 21:05 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 244 seconds] 21:09 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev 21:14 -!- proofofkeags [~proofofke@174-29-9-247.hlrn.qwest.net] has joined #bitcoin-core-dev 21:19 -!- proofofkeags [~proofofke@174-29-9-247.hlrn.qwest.net] has quit [Ping timeout: 260 seconds] 21:19 -!- vasild_ [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-dev 21:22 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds] 21:22 -!- vasild_ is now known as vasild 21:25 -!- promag_ [~promag@bl19-22-20.dsl.telepac.pt] has joined #bitcoin-core-dev 21:30 -!- promag_ [~promag@bl19-22-20.dsl.telepac.pt] has quit [Ping timeout: 272 seconds] 21:43 -!- dfmb__ [~dfmb_@unaffiliated/dfmb/x-4009105] has joined #bitcoin-core-dev 21:45 -!- proofofkeags [~proofofke@174-29-9-247.hlrn.qwest.net] has joined #bitcoin-core-dev 21:47 -!- dfmb___ [~dfmb_@unaffiliated/dfmb/x-4009105] has joined #bitcoin-core-dev 21:47 -!- dfmb___ [~dfmb_@unaffiliated/dfmb/x-4009105] has quit [Client Quit] 21:48 -!- dfmb___ [~dfmb_@unaffiliated/dfmb/x-4009105] has joined #bitcoin-core-dev 21:48 -!- dfmb_ [~dfmb_@unaffiliated/dfmb/x-4009105] has joined #bitcoin-core-dev 21:48 -!- dfmb_ [~dfmb_@unaffiliated/dfmb/x-4009105] has quit [Client Quit] 21:49 -!- proofofkeags [~proofofke@174-29-9-247.hlrn.qwest.net] has quit [Ping timeout: 256 seconds] 21:50 -!- dfmb__ [~dfmb_@unaffiliated/dfmb/x-4009105] has quit [Ping timeout: 246 seconds] 21:52 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection] 22:06 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined #bitcoin-core-dev 22:16 -!- Talkless [~Talkless@hst-227-49.splius.lt] has joined #bitcoin-core-dev 22:20 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 22:20 < 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 22:20 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 22:29 -!- Talkless [~Talkless@hst-227-49.splius.lt] has quit [Quit: Konversation terminated!] 22:30 -!- Talkless [~Talkless@hst-227-49.splius.lt] has joined #bitcoin-core-dev 22:32 -!- mol [~mol@unaffiliated/molly] has joined #bitcoin-core-dev 22:59 -!- Highway61 [~Thunderbi@104.223.95.2] has joined #bitcoin-core-dev 23:00 -!- nhandler1 [~nhandler@195.206.183.79] has quit [] 23:12 -!- brakmic [~brakmic@185.183.85.108] has joined #bitcoin-core-dev 23:18 -!- Zao_ [~Zao_@37.120.203.188] has joined #bitcoin-core-dev 23:26 -!- mol_ [~mol@unaffiliated/molly] has joined #bitcoin-core-dev 23:29 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 256 seconds] 23:30 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Ping timeout: 240 seconds] 23:32 -!- mol_ [~mol@unaffiliated/molly] has quit [Ping timeout: 264 seconds] 23:34 -!- mol [~mol@unaffiliated/molly] has joined #bitcoin-core-dev 23:34 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined #bitcoin-core-dev 23:47 -!- mol_ [~mol@unaffiliated/molly] has joined #bitcoin-core-dev 23:50 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 272 seconds] --- Log closed Fri May 08 00:00:18 2020