--- Log opened Thu Sep 10 00:00:06 2020
--- Day changed Thu Sep 10 2020
00:00 -!- andreacab [~andreacab@2a02:120b:2c22:e0c0:d451:ba66:120e:205c] has joined #bitcoin-core-dev
00:09 -!- tralfaz [~davterra@gateway/tor-sasl/tralfaz] has joined #bitcoin-core-dev
00:10 < hebasto> who is interested in today's meeting topic suggested by jnewbery mind considering the overview gist https://gist.github.com/hebasto/072ad3a9370641b035a36d08607a3d34
00:10 -!- davterra [~davterra@gateway/tor-sasl/tralfaz] has quit [Remote host closed the connection]
00:11 -!- marcoagner [~user@2001:8a0:6a45:1900:2fd7:e0f0:d356:dd70] has joined #bitcoin-core-dev
00:21 -!- arowser [~arowser1@204.124.180.72] has quit [Remote host closed the connection]
00:21 -!- arowser [~arowser1@204.124.180.72] has joined #bitcoin-core-dev
00:23 -!- arowser [~arowser1@204.124.180.72] has quit [Remote host closed the connection]
00:23 -!- arowser [~arowser1@204.124.180.72] has joined #bitcoin-core-dev
00:28 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Ping timeout: 260 seconds]
00:28 -!- reallll [~belcher@unaffiliated/belcher] has joined #bitcoin-core-dev
00:31 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
00:31 < bitcoin-git> [bitcoin] sipa opened pull request #19931: Change CSipHasher's count variable to uint8_t (master...202009_siphash_sillyness) https://github.com/bitcoin/bitcoin/pull/19931
00:31 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
00:32 -!- belcher_ [~belcher@unaffiliated/belcher] has quit [Ping timeout: 265 seconds]
00:34 -!- Guyver2 [Guyver@guyver2.xs4all.nl] has joined #bitcoin-core-dev
00:47 -!- Madars [~null@unaffiliated/madars] has quit [Ping timeout: 240 seconds]
00:47 -!- promag [~promag@188.251.225.32] has joined #bitcoin-core-dev
00:48 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Ping timeout: 240 seconds]
00:48 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has quit [Remote host closed the connection]
00:48 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has joined #bitcoin-core-dev
00:50 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has quit [Remote host closed the connection]
00:51 -!- andreacab [~andreacab@2a02:120b:2c22:e0c0:d451:ba66:120e:205c] has quit [Remote host closed the connection]
00:51 -!- andreacab [~andreacab@2a02:120b:2c22:e0c0:d451:ba66:120e:205c] has joined #bitcoin-core-dev
00:54 -!- Cory [~Cory@unaffiliated/cory] has quit [Ping timeout: 246 seconds]
01:00 -!- Madars [~null@unaffiliated/madars] has joined #bitcoin-core-dev
01:04 -!- arowser [~arowser1@204.124.180.72] has quit [Remote host closed the connection]
01:04 -!- promag_ [~promag@188.251.225.32] has joined #bitcoin-core-dev
01:04 -!- arowser [~arowser1@204.124.180.72] has joined #bitcoin-core-dev
01:07 -!- Pavlenex [~Thunderbi@185.244.212.67] has joined #bitcoin-core-dev
01:08 -!- promag_ [~promag@188.251.225.32] has quit [Ping timeout: 256 seconds]
01:12 -!- Cory [~Cory@unaffiliated/cory] has joined #bitcoin-core-dev
01:17 -!- promag [~promag@188.251.225.32] has quit [Remote host closed the connection]
01:19 -!- Pavlenex [~Thunderbi@185.244.212.67] has quit [Quit: Pavlenex]
01:20 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined #bitcoin-core-dev
01:21 -!- promag [~promag@188.251.225.32] has joined #bitcoin-core-dev
01:23 -!- promag [~promag@188.251.225.32] has quit [Remote host closed the connection]
01:23 -!- andreacab [~andreacab@2a02:120b:2c22:e0c0:d451:ba66:120e:205c] has quit [Remote host closed the connection]
01:24 -!- Madars [~null@unaffiliated/madars] has quit [Ping timeout: 256 seconds]
01:24 -!- promag [~promag@188.251.225.32] has joined #bitcoin-core-dev
01:24 -!- andreacab [~andreacab@2a02:120b:2c22:e0c0:d451:ba66:120e:205c] has joined #bitcoin-core-dev
01:28 -!- andreacab [~andreacab@2a02:120b:2c22:e0c0:d451:ba66:120e:205c] has quit [Ping timeout: 240 seconds]
01:29 -!- andreacab [~andreacab@2a02:120b:2c22:e0c0:d451:ba66:120e:205c] has joined #bitcoin-core-dev
01:31 -!- reallll is now known as belcher
01:33 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
01:33 < bitcoin-git> [bitcoin] hebasto closed pull request #19926: gui: Add Tor icon (master...200909-tor) https://github.com/bitcoin/bitcoin/pull/19926
01:33 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
01:45 -!- promag [~promag@188.251.225.32] has quit [Remote host closed the connection]
01:47 -!- Pavlenex [~Thunderbi@185.244.212.67] has joined #bitcoin-core-dev
01:52 -!- promag [~promag@188.251.225.32] has joined #bitcoin-core-dev
01:52 -!- Madars [~null@unaffiliated/madars] has joined #bitcoin-core-dev
01:57 -!- jonatack [~jon@192.113.14.109.rev.sfr.net] has joined #bitcoin-core-dev
02:00 -!- vincenzopalazzo [~vincent@host-82-60-201-14.retail.telecomitalia.it] has joined #bitcoin-core-dev
02:00 -!- steven1 [~steven@178.162.204.214] has quit []
02:04 -!- promag [~promag@188.251.225.32] has quit [Remote host closed the connection]
02:05 -!- promag [~promag@188.251.225.32] has joined #bitcoin-core-dev
02:15 -!- promag [~promag@188.251.225.32] has quit [Remote host closed the connection]
02:15 -!- Madars [~null@unaffiliated/madars] has quit [Ping timeout: 256 seconds]
02:21 -!- Avelino [~Avelino@84.39.117.57] has joined #bitcoin-core-dev
02:27 -!- andreacab [~andreacab@2a02:120b:2c22:e0c0:d451:ba66:120e:205c] has quit [Remote host closed the connection]
02:28 -!- andreacab [~andreacab@2a02:120b:2c22:e0c0:d451:ba66:120e:205c] has joined #bitcoin-core-dev
02:29 -!- andreacab [~andreacab@2a02:120b:2c22:e0c0:d451:ba66:120e:205c] has quit [Remote host closed the connection]
02:29 -!- andreacab [~andreacab@2a02:120b:2c22:e0c0:d451:ba66:120e:205c] has joined #bitcoin-core-dev
02:34 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Remote host closed the connection]
02:34 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined #bitcoin-core-dev
02:36 -!- Pavlenex [~Thunderbi@185.244.212.67] has quit [Quit: Pavlenex]
02:36 -!- promag [~promag@188.251.225.32] has joined #bitcoin-core-dev
02:37 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 246 seconds]
02:38 -!- Pavlenex [~Thunderbi@185.244.212.67] has joined #bitcoin-core-dev
02:38 -!- Madars [~null@unaffiliated/madars] has joined #bitcoin-core-dev
02:42 -!- promag [~promag@188.251.225.32] has quit [Remote host closed the connection]
02:48 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has joined #bitcoin-core-dev
02:53 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has quit [Read error: Connection reset by peer]
02:53 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has joined #bitcoin-core-dev
02:58 -!- jonatack [~jon@192.113.14.109.rev.sfr.net] has quit [Ping timeout: 258 seconds]
02:58 -!- promag [~promag@188.251.225.32] has joined #bitcoin-core-dev
03:03 -!- Madars [~null@unaffiliated/madars] has quit [Ping timeout: 256 seconds]
03:03 -!- promag [~promag@188.251.225.32] has quit [Ping timeout: 240 seconds]
03:05 -!- andreacab [~andreacab@2a02:120b:2c22:e0c0:d451:ba66:120e:205c] has quit [Remote host closed the connection]
03:05 -!- andreacab [~andreacab@2a02:120b:2c22:e0c0:d451:ba66:120e:205c] has joined #bitcoin-core-dev
03:09 -!- mrostecki [~mrostecki@gateway/tor-sasl/mrostecki] has joined #bitcoin-core-dev
03:10 -!- andreacab [~andreacab@2a02:120b:2c22:e0c0:d451:ba66:120e:205c] has quit [Ping timeout: 244 seconds]
03:13 -!- tralfaz [~davterra@gateway/tor-sasl/tralfaz] has quit [Remote host closed the connection]
03:13 -!- tralfaz [~davterra@gateway/tor-sasl/tralfaz] has joined #bitcoin-core-dev
03:17 -!- Bullit [~Bullit01@042-236-158-163.dynamic.caiway.nl] has quit [Read error: Connection reset by peer]
03:18 -!- arowser [~arowser1@204.124.180.72] has quit [Remote host closed the connection]
03:18 -!- Bullit [~Bullit01@042-236-158-163.dynamic.caiway.nl] has joined #bitcoin-core-dev
03:18 -!- Tyrell41Kris [~Tyrell41K@static.57.1.216.95.clients.your-server.de] has joined #bitcoin-core-dev
03:18 -!- arowser [~arowser1@204.124.180.72] has joined #bitcoin-core-dev
03:20 -!- Evel-Knievel [~Evel-Knie@d5152f744.static.telenet.be] has quit [Ping timeout: 240 seconds]
03:21 -!- Evel-Knievel [~Evel-Knie@d5152f744.static.telenet.be] has joined #bitcoin-core-dev
03:24 -!- promag [~promag@188.251.225.32] has joined #bitcoin-core-dev
03:28 -!- arowser [~arowser1@204.124.180.72] has quit [Remote host closed the connection]
03:28 -!- arowser [~arowser1@204.124.180.72] has joined #bitcoin-core-dev
03:29 -!- promag [~promag@188.251.225.32] has quit [Ping timeout: 258 seconds]
03:29 -!- promag [~promag@188.251.225.32] has joined #bitcoin-core-dev
03:32 -!- Madars [~null@unaffiliated/madars] has joined #bitcoin-core-dev
03:36 -!- promag [~promag@188.251.225.32] has quit [Remote host closed the connection]
03:40 -!- Tyrell41Kris [~Tyrell41K@static.57.1.216.95.clients.your-server.de] has quit [Ping timeout: 265 seconds]
03:41 < jonasschnelli> #proposedmeetingtopic review the experience of 3 month bitcoin-core/gui repository
03:49 -!- andreacab [~andreacab@2a02:120b:2c22:e0c0:d451:ba66:120e:205c] has joined #bitcoin-core-dev
03:52 -!- Madars [~null@unaffiliated/madars] has quit [Ping timeout: 258 seconds]
03:54 -!- andreacab [~andreacab@2a02:120b:2c22:e0c0:d451:ba66:120e:205c] has quit [Ping timeout: 260 seconds]
04:00 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds]
04:01 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-dev
04:01 -!- andreacab [~andreacab@2a02:120b:2c22:e0c0:d451:ba66:120e:205c] has joined #bitcoin-core-dev
04:02 -!- Jackielove4u [uid43977@gateway/web/irccloud.com/x-pfpozdgfdlzxuabu] has quit [Quit: Connection closed for inactivity]
04:11 -!- ExEric3 [~exeric3@178.132.3.92] has quit [Remote host closed the connection]
04:12 -!- ExEric3 [~exeric3@178.132.3.92] has joined #bitcoin-core-dev
04:14 -!- Madars [~null@unaffiliated/madars] has joined #bitcoin-core-dev
04:31 -!- paz_ [~paz@24.14.251.223] has joined #bitcoin-core-dev
04:31 -!- paz_ is now known as Guest48339
04:35 -!- Madars [~null@unaffiliated/madars] has quit [Ping timeout: 246 seconds]
04:38 -!- promag [~promag@188.251.225.32] has joined #bitcoin-core-dev
04:42 -!- andreacab [~andreacab@2a02:120b:2c22:e0c0:d451:ba66:120e:205c] has quit [Remote host closed the connection]
04:42 -!- promag [~promag@188.251.225.32] has quit [Ping timeout: 258 seconds]
04:46 -!- andreacab [~andreacab@2a02:120b:2c22:e0c0:d451:ba66:120e:205c] has joined #bitcoin-core-dev
04:57 -!- promag [~promag@188.251.225.32] has joined #bitcoin-core-dev
04:57 -!- Avelino [~Avelino@84.39.117.57] has quit [Remote host closed the connection]
05:01 -!- promag [~promag@188.251.225.32] has quit [Ping timeout: 256 seconds]
05:02 -!- Madars [~null@unaffiliated/madars] has joined #bitcoin-core-dev
05:03 -!- Mercury_Vapor [~Mercury_V@174-082-166-092.res.spectrum.com] has joined #bitcoin-core-dev
05:05 -!- alko89 [~alko89@unaffiliated/alko89] has quit [Quit: ZNC 1.7.5 - https://znc.in]
05:05 -!- alko89 [~alko89@unaffiliated/alko89] has joined #bitcoin-core-dev
05:15 -!- andreacab [~andreacab@2a02:120b:2c22:e0c0:d451:ba66:120e:205c] has quit [Remote host closed the connection]
05:16 -!- andreacab [~andreacab@2a02:120b:2c22:e0c0:d451:ba66:120e:205c] has joined #bitcoin-core-dev
05:18 -!- provoostenator [~quassel@provoostenator.sprovoost.nl] has joined #bitcoin-core-dev
05:20 -!- andreacab [~andreacab@2a02:120b:2c22:e0c0:d451:ba66:120e:205c] has quit [Ping timeout: 246 seconds]
05:20 -!- wolfy13391 [~wolfy1339@178.162.204.214] has joined #bitcoin-core-dev
05:24 -!- Madars [~null@unaffiliated/madars] has quit [Ping timeout: 240 seconds]
05:27 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
05:29 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 256 seconds]
05:33 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has quit [Ping timeout: 265 seconds]
05:39 -!- Guyver2 [Guyver@guyver2.xs4all.nl] has quit [Quit: Going offline, see ya! (www.adiirc.com)]
05:43 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined #bitcoin-core-dev
05:47 -!- Emcy_ [~Emcy@unaffiliated/emcy] has joined #bitcoin-core-dev
05:47 -!- gzhao408 [uid453516@gateway/web/irccloud.com/x-pimjjomgbpnimdxh] has joined #bitcoin-core-dev
05:47 -!- Emcy [~Emcy@unaffiliated/emcy] has quit [Remote host closed the connection]
06:02 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has joined #bitcoin-core-dev
06:06 -!- arowser [~arowser1@204.124.180.72] has quit [Remote host closed the connection]
06:06 -!- arowser [~arowser1@204.124.180.72] has joined #bitcoin-core-dev
06:08 -!- arowser [~arowser1@204.124.180.72] has quit [Remote host closed the connection]
06:08 -!- arowser [~arowser1@204.124.180.72] has joined #bitcoin-core-dev
06:09 -!- arowser [~arowser1@204.124.180.72] has quit [Remote host closed the connection]
06:09 -!- arowser [~arowser1@204.124.180.72] has joined #bitcoin-core-dev
06:10 -!- arowser [~arowser1@204.124.180.72] has quit [Remote host closed the connection]
06:10 -!- arowser [~arowser1@204.124.180.72] has joined #bitcoin-core-dev
06:11 -!- Madars [~null@unaffiliated/madars] has joined #bitcoin-core-dev
06:11 -!- arowser [~arowser1@204.124.180.72] has quit [Remote host closed the connection]
06:11 -!- arowser [~arowser1@204.124.180.72] has joined #bitcoin-core-dev
06:12 -!- arowser [~arowser1@204.124.180.72] has quit [Remote host closed the connection]
06:12 -!- arowser [~arowser1@204.124.180.72] has joined #bitcoin-core-dev
06:24 -!- arowser [~arowser1@204.124.180.72] has quit [Remote host closed the connection]
06:24 -!- arowser [~arowser1@204.124.180.72] has joined #bitcoin-core-dev
06:36 -!- Madars [~null@unaffiliated/madars] has quit [Ping timeout: 264 seconds]
06:37 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Quit: jonatack]
06:41 -!- promag [~promag@bl19-178-66.dsl.telepac.pt] has joined #bitcoin-core-dev
06:58 -!- promag [~promag@bl19-178-66.dsl.telepac.pt] has quit [Remote host closed the connection]
07:00 -!- mdunnio [~mdunnio@208.59.170.5] has joined #bitcoin-core-dev
07:02 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined #bitcoin-core-dev
07:06 -!- arowser [~arowser1@204.124.180.72] has quit [Remote host closed the connection]
07:06 -!- arowser [~arowser1@204.124.180.72] has joined #bitcoin-core-dev
07:06 -!- proofofkeags [~proofofke@174-29-30-112.hlrn.qwest.net] has joined #bitcoin-core-dev
07:13 -!- mdunnio [~mdunnio@208.59.170.5] has quit [Remote host closed the connection]
07:13 -!- mdunnio [~mdunnio@208.59.170.5] has joined #bitcoin-core-dev
07:20 -!- shaunsun [shaunsun@gateway/vpn/privateinternetaccess/shaunsun] has joined #bitcoin-core-dev
07:26 -!- opsec_x122 [~opsec_x12@44-25-143-49.ip.hamwan.net] has joined #bitcoin-core-dev
07:29 -!- jeremyrubin [~jr@2601:645:c200:f539:bd11:45e8:9cd8:a7e6] has quit [Ping timeout: 244 seconds]
07:29 -!- jeremyrubin [~jr@2601:645:c200:f539:bd31:eec8:b7c2:d5b0] has joined #bitcoin-core-dev
07:29 -!- opsec_x12 [~opsec_x12@44-25-143-49.ip.hamwan.net] has quit [Ping timeout: 264 seconds]
07:29 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
07:30 < bitcoin-git> [bitcoin] Saibato opened pull request #19933: wallet: bugfix; if datadir has a trailing '/'  listwalletdir would strip lead char of walletname (master...wallet-fix-missing-chars-boost-1.47) https://github.com/bitcoin/bitcoin/pull/19933
07:30 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
07:31 -!- sdaftuar [~sdaftuar@gateway/tor-sasl/sdaftuar] has quit [Ping timeout: 240 seconds]
07:31 -!- afk11 [~afk11@gateway/tor-sasl/afk11] has quit [Ping timeout: 240 seconds]
07:33 -!- sdaftuar [~sdaftuar@gateway/tor-sasl/sdaftuar] has joined #bitcoin-core-dev
07:33 -!- afk11 [~afk11@gateway/tor-sasl/afk11] has joined #bitcoin-core-dev
07:35 -!- Madars [~null@unaffiliated/madars] has joined #bitcoin-core-dev
07:36 -!- promag [~promag@bl19-22-20.dsl.telepac.pt] has joined #bitcoin-core-dev
07:38 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
07:38 < bitcoin-git> [bitcoin] laanwj pushed 4 commits to master: https://github.com/bitcoin/bitcoin/compare/564e1ab0f3dc...a47e5964861d
07:38 < bitcoin-git> bitcoin/master 2ac8bf9 Pieter Wuille: Implement keccak-f[1600] and SHA3-256
07:38 < bitcoin-git> bitcoin/master 3f01ddb Pieter Wuille: Add SHA3 benchmark
07:38 < bitcoin-git> bitcoin/master ab654c7 Pieter Wuille: Unroll Keccak-f implementation
07:38 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
07:39 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
07:39 < bitcoin-git> [bitcoin] laanwj merged pull request #19841: Implement Keccak and SHA3_256 (master...202008_sha3) https://github.com/bitcoin/bitcoin/pull/19841
07:39 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
07:41 -!- promag [~promag@bl19-22-20.dsl.telepac.pt] has quit [Ping timeout: 256 seconds]
07:43 -!- opsec_x122 is now known as opsec_x12
07:46 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Read error: Connection reset by peer]
07:49 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev
07:51 -!- promag [~promag@bl19-22-20.dsl.telepac.pt] has joined #bitcoin-core-dev
07:51 -!- promag [~promag@bl19-22-20.dsl.telepac.pt] has quit [Read error: Connection reset by peer]
07:51 -!- promag [~promag@bl19-22-20.dsl.telepac.pt] has joined #bitcoin-core-dev
07:53 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
07:53 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has joined #bitcoin-core-dev
07:57 -!- gleb [~gleb@178.150.137.228] has quit [Ping timeout: 260 seconds]
07:57 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
07:57 < bitcoin-git> [bitcoin] practicalswift opened pull request #19934: tests: Add fuzzing harness for Keccak and SHA3_256 (master...fuzzers-keccak-and-sha3_256) https://github.com/bitcoin/bitcoin/pull/19934
07:57 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
08:00 -!- wolfy13391 [~wolfy1339@178.162.204.214] has quit []
08:02 -!- Guyver2 [Guyver@guyver2.xs4all.nl] has joined #bitcoin-core-dev
08:04 -!- andreacab [~andreacab@2a02:120b:2c22:e0c0:754f:5e6a:8cb5:b694] has joined #bitcoin-core-dev
08:06 -!- promag [~promag@bl19-22-20.dsl.telepac.pt] has quit [Remote host closed the connection]
08:07 -!- promag [~promag@Bl19-22-20.dsl.telepac.pt] has joined #bitcoin-core-dev
08:11 -!- Madars [~null@unaffiliated/madars] has quit [Ping timeout: 260 seconds]
08:16 -!- satoshi [~satoshi@186.167.243.52] has joined #bitcoin-core-dev
08:17 -!- satoshi [~satoshi@186.167.243.52] has quit [Remote host closed the connection]
08:20 -!- andreacab [~andreacab@2a02:120b:2c22:e0c0:754f:5e6a:8cb5:b694] has quit [Remote host closed the connection]
08:22 -!- chrippa [~chrippa@89.47.234.28] has joined #bitcoin-core-dev
08:30 -!- Guyver2_ [Guyver@guyver2.xs4all.nl] has joined #bitcoin-core-dev
08:31 -!- andreacab [~andreacab@12.46.194.178.dynamic.wline.res.cust.swisscom.ch] has joined #bitcoin-core-dev
08:31 -!- andreacab [~andreacab@12.46.194.178.dynamic.wline.res.cust.swisscom.ch] has quit [Remote host closed the connection]
08:32 -!- Guyver2 [Guyver@guyver2.xs4all.nl] has quit [Ping timeout: 256 seconds]
08:33 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
08:33 < bitcoin-git> [bitcoin] achow101 opened pull request #19935: Move SaltedHashers to separate file and add some new ones (master...mv-saltedhash) https://github.com/bitcoin/bitcoin/pull/19935
08:33 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
08:37 -!- troygiorshev [~troygiors@d67-193-140-136.home3.cgocable.net] has joined #bitcoin-core-dev
08:38 -!- troygiorshev [~troygiors@d67-193-140-136.home3.cgocable.net] has quit [Client Quit]
08:39 -!- IGHOR [~quassel@176.121.4.135] has quit [Ping timeout: 240 seconds]
08:43 -!- IGHOR [~quassel@176.121.4.135] has joined #bitcoin-core-dev
08:46 -!- afk11 [~afk11@gateway/tor-sasl/afk11] has quit [Remote host closed the connection]
08:46 -!- afk11 [~afk11@gateway/tor-sasl/afk11] has joined #bitcoin-core-dev
08:50 -!- Talkless [~Talkless@hst-227-49.splius.lt] has joined #bitcoin-core-dev
09:10 -!- Madars [~null@unaffiliated/madars] has joined #bitcoin-core-dev
09:12 -!- promag [~promag@Bl19-22-20.dsl.telepac.pt] has quit [Remote host closed the connection]
09:32 -!- arowser [~arowser1@204.124.180.72] has quit [Remote host closed the connection]
09:32 -!- arowser [~arowser1@204.124.180.72] has joined #bitcoin-core-dev
09:34 -!- Madars [~null@unaffiliated/madars] has quit [Ping timeout: 246 seconds]
09:37 -!- Emcy_ [~Emcy@unaffiliated/emcy] has quit [Read error: Connection reset by peer]
09:38 -!- Emcy [~Emcy@unaffiliated/emcy] has joined #bitcoin-core-dev
09:42 -!- afk11 [~afk11@gateway/tor-sasl/afk11] has quit [Ping timeout: 240 seconds]
09:43 -!- afk11 [~afk11@gateway/tor-sasl/afk11] has joined #bitcoin-core-dev
09:47 -!- MrPaz [~paz@24.14.251.223] has joined #bitcoin-core-dev
09:47 -!- Guest48339 [~paz@24.14.251.223] has quit [Quit: Leaving]
09:48 -!- promag [~promag@bl19-22-20.dsl.telepac.pt] has joined #bitcoin-core-dev
09:49 -!- MrPaz [~paz@24.14.251.223] has quit [Client Quit]
09:49 -!- MrPaz [~paz@24.14.251.223] has joined #bitcoin-core-dev
09:50 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has joined #bitcoin-core-dev
09:53 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev
09:53 -!- mrostecki [~mrostecki@gateway/tor-sasl/mrostecki] has quit [Remote host closed the connection]
09:53 -!- justtestingthiso [57868a6c@p57868a6c.dip0.t-ipconnect.de] has joined #bitcoin-core-dev
09:54 -!- mrostecki [~mrostecki@gateway/tor-sasl/mrostecki] has joined #bitcoin-core-dev
09:56 -!- promag [~promag@bl19-22-20.dsl.telepac.pt] has quit [Ping timeout: 264 seconds]
09:59 -!- promag_ [~promag@bl19-22-20.dsl.telepac.pt] has joined #bitcoin-core-dev
10:03 -!- Jackielove4u [uid43977@gateway/web/irccloud.com/x-xlvlfnqcloecnoox] has joined #bitcoin-core-dev
10:09 -!- justtestingthiso [57868a6c@p57868a6c.dip0.t-ipconnect.de] has left #bitcoin-core-dev []
10:10 -!- robertnnms [51f9ab45@lfbn-idf3-1-44-69.w81-249.abo.wanadoo.fr] has joined #bitcoin-core-dev
10:12 -!- robertnnms [51f9ab45@lfbn-idf3-1-44-69.w81-249.abo.wanadoo.fr] has left #bitcoin-core-dev []
10:13 -!- robertnnms [51f9ab45@lfbn-idf3-1-44-69.w81-249.abo.wanadoo.fr] has joined #bitcoin-core-dev
10:13 < robertnnms> Hi,I need to do advanced testing on testnet, but I would need between 10-15 BTC, could someone send me to the following address: tb1qs25dr4e8k29rwclxvnxedfdtprh5e89jtp5wleMany thanks
10:14 -!- satoshi [~satoshi@186.167.244.228] has joined #bitcoin-core-dev
10:14 -!- satoshi [~satoshi@186.167.244.228] has quit [Remote host closed the connection]
10:14 < dongcarl> Anyone know what the `UnloadBlockIndex` call here does in the context of initialization? https://github.com/bitcoin/bitcoin/blob/master/src/init.cpp#L1562
10:14 < dongcarl> First introduced in: https://github.com/bitcoin/bitcoin/commit/f7f3a96b74bb795d6e184a628adce21c744d234f#diff-c865a8939105e6350a50af02766291b7R805
10:14 -!- Madars [~null@unaffiliated/madars] has joined #bitcoin-core-dev
10:17 -!- Talkless [~Talkless@hst-227-49.splius.lt] has quit [Remote host closed the connection]
10:17 -!- Talkless [~Talkless@hst-227-49.splius.lt] has joined #bitcoin-core-dev
10:20 -!- arowser [~arowser1@204.124.180.72] has quit [Remote host closed the connection]
10:20 -!- arowser [~arowser1@204.124.180.72] has joined #bitcoin-core-dev
10:24 -!- promag [~promag@bl19-22-20.dsl.telepac.pt] has joined #bitcoin-core-dev
10:25 -!- promag_ [~promag@bl19-22-20.dsl.telepac.pt] has quit [Read error: Connection reset by peer]
10:26 -!- IGHOR [~quassel@176.121.4.135] has quit [Remote host closed the connection]
10:27 -!- IGHOR [~quassel@176.121.4.135] has joined #bitcoin-core-dev
10:35 -!- robertnnms [51f9ab45@lfbn-idf3-1-44-69.w81-249.abo.wanadoo.fr] has quit [Remote host closed the connection]
10:36 -!- promag [~promag@bl19-22-20.dsl.telepac.pt] has quit [Read error: Connection reset by peer]
10:36 -!- promag [~promag@bl19-22-20.dsl.telepac.pt] has joined #bitcoin-core-dev
10:36 -!- Madars [~null@unaffiliated/madars] has quit [Ping timeout: 246 seconds]
10:37 -!- IGHOR [~quassel@176.121.4.135] has quit [Remote host closed the connection]
10:38 -!- IGHOR [~quassel@176.121.4.135] has joined #bitcoin-core-dev
10:40 -!- Pavlenex [~Thunderbi@185.244.212.67] has quit [Ping timeout: 256 seconds]
10:41 -!- Pavlenex [~Thunderbi@185.244.212.67] has joined #bitcoin-core-dev
10:52 -!- promag [~promag@bl19-22-20.dsl.telepac.pt] has quit [Ping timeout: 265 seconds]
10:53 -!- Cassidy67Schambe [~Cassidy67@static.57.1.216.95.clients.your-server.de] has joined #bitcoin-core-dev
10:53 -!- promag [~promag@bl19-22-20.dsl.telepac.pt] has joined #bitcoin-core-dev
10:58 -!- Cassidy67Schambe [~Cassidy67@static.57.1.216.95.clients.your-server.de] has quit [Ping timeout: 258 seconds]
11:00 -!- chrippa [~chrippa@89.47.234.28] has quit []
11:02 < wumpus> dongcarl: it's in a retry loop, I think it's there in case a previous block index load only succeeds partially?
11:03 < sipa> yep
11:05 < dongcarl> I see, that makes sense...
11:10 < phantomcircuit> achow101, the only real solution for rescanning with a huge number of keys is to use the block filter indexes
11:10 < phantomcircuit> it takes absolutely ages otherwise
11:11 -!- Madars [~null@unaffiliated/madars] has joined #bitcoin-core-dev
11:15 -!- promag [~promag@bl19-22-20.dsl.telepac.pt] has quit [Remote host closed the connection]
11:17 -!- Guyver2_ [Guyver@guyver2.xs4all.nl] has quit [Quit: Going offline, see ya! (www.adiirc.com)]
11:18 -!- Guyver2 [Guyver@guyver2.xs4all.nl] has joined #bitcoin-core-dev
11:21 -!- popey1 [~popey@s91904426.blix.com] has joined #bitcoin-core-dev
11:23 < phantomcircuit> sipa, lol he closed the issue, what a child
11:23 < phantomcircuit> still wondering how he ended up with 150m keys
11:24 < sipa> i assume he generated them using a dictionary
11:30 < jonasschnelli> a cracker!
11:31 < jonasschnelli> Why he is not using a full indexer like electrs or so is unclear to me.
11:31 < wumpus> if it's a criminal even more reason to not give them ideas
11:32 < jonasschnelli> maybe he lost some of his mnemonic words...
11:33 < jonasschnelli> also... i would rather scan agains the UTXO set in that case (and not against all blocks)
11:33 < yanmaani> It's not a very competent attack that's for suer
11:37 -!- Highway62 [~Thunderbi@unaffiliated/highway61] has joined #bitcoin-core-dev
11:37 -!- Highway61 [~Thunderbi@unaffiliated/highway61] has quit [Ping timeout: 265 seconds]
11:37 -!- Highway62 is now known as Highway61
11:38 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 240 seconds]
11:38 -!- Madars [~null@unaffiliated/madars] has quit [Ping timeout: 265 seconds]
11:47 -!- gzhao408 [uid453516@gateway/web/irccloud.com/x-pimjjomgbpnimdxh] has quit [Quit: Connection closed for inactivity]
11:58 -!- lightlike [~lightlike@p200300c7ef19e60094135b145ee15ebe.dip0.t-ipconnect.de] has joined #bitcoin-core-dev
12:00 < wumpus> #startmeeting
12:00 < lightningbot> Meeting started Thu Sep 10 19:00:25 2020 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
12:00 < lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
12:00 < kanzure> hi
12:00 < achow101> hi
12:00 < jonasschnelli> hi
12:00 < hebasto> hi
12:00 < fjahr> hi
12:00 < 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
12:00 < wumpus> amiti fjahr jeremyrubin lightlike emilengler jonatack hebasto jb55 elichai2
12:01 < wumpus> two proposed meeting topics for today
12:01 < vasild> hi
12:01 < wumpus> strategies for removing recursive locking in the mempool (jnewbery), review the experience of 3 month bitcoin-core/gui repository (jonasschnelli)
12:01 < meshcollider> hi
12:01 < wumpus> any last minute topic proposals?
12:01 < jonatack> hi
12:02 < wumpus> #topic High priority for review
12:03 < wumpus> https://github.com/bitcoin/bitcoin/projects/8  11 blockers, 1 bugfix, 2 chasins concept ACK 
12:03 -!- rorp [43a994bd@c-67-169-148-189.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
12:03 < jonatack> #19845?
12:03 < gribble> https://github.com/bitcoin/bitcoin/issues/19845 | net: CNetAddr: add support to (un)serialize as ADDRv2 by vasild · Pull Request #19845 · bitcoin/bitcoin · GitHub
12:04 < meshcollider> Actually 10 now :) one was merged and hadn't been removed
12:04 < jnewbery> hi
12:04 < wumpus> jonatack: added
12:04 -!- promag [~promag@Bl19-22-20.dsl.telepac.pt] has joined #bitcoin-core-dev
12:05 < meshcollider>  #16378 pls
12:05 < gribble> https://github.com/bitcoin/bitcoin/issues/16378 | The ultimate send RPC by Sjors · Pull Request #16378 · bitcoin/bitcoin · GitHub
12:05 < achow101> #19077 please
12:06 < gribble> https://github.com/bitcoin/bitcoin/issues/19077 | wallet: Add sqlite as an alternative wallet database and use it for new descriptor wallets by achow101 · Pull Request #19077 · bitcoin/bitcoin · GitHub
12:06 < promag> #19033 for hp, ty
12:06 < gribble> https://github.com/bitcoin/bitcoin/issues/19033 | http: Release work queue after event base finish by promag · Pull Request #19033 · bitcoin/bitcoin · GitHub
12:06 < phantomcircuit> hi
12:06  * luke-jr pokes gribble
12:07 < wumpus> meshcollider, achow101  added
12:07 < wumpus> promag: already on there, right?
12:08 < jeremyrubin> i think so
12:08 < promag> indeed, I guess I have to name it "http: blocklist work queue..."
12:09 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net]
12:09 < wumpus> unless someone else just added it, but I vaguely remember it was already there
12:09 < wumpus> #topic Strategies for removing recursive locking in the mempool (jnewbery)
12:09 < wumpus> (https://github.com/bitcoin/bitcoin/pull/19872#issuecomment-688852261)
12:09 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev
12:09 < jnewbery> Thanks wumpus
12:10 < jnewbery> gist here: https://gist.github.com/hebasto/072ad3a9370641b035a36d08607a3d34
12:10 < jnewbery> summary: RecusiveMutex is generally considered bad, and avoided if possible. It'd be nice to change the mempool's mutex from recursive to non-recursive
12:10 -!- Talkless [~Talkless@hst-227-49.splius.lt] has quit [Quit: Konversation terminated!]
12:11 < wumpus> I think getting rid of the recursive locks is good, though, it seems changes are becoming increasingly risky
12:11 < wumpus> and involved
12:11 < jnewbery> There are different ways to do this, and hebasto would like some input on which way is preferred
12:11 < wumpus> we had all the low-hanging fruit I guess
12:12 < jnewbery> wumpus: i don't think so. I think there's a lot more low-hanging fruit (although cs_mempool isn't very low hanging)
12:12 < hebasto> tracking issue for all recursive mutexes #19303
12:12 < gribble> https://github.com/bitcoin/bitcoin/issues/19303 | Replace all of the RecursiveMutex instances with the Mutex ones · Issue #19303 · bitcoin/bitcoin · GitHub
12:12 < jeremyrubin> Probably makes more sense to have the locking external to the functions 
12:12 < jeremyrubin> More general to e.g., calling a function in a for loop
12:13 < jnewbery> Two possible ways are making a lot more of the mempool functions require the lock, and make locking external to the mempool
12:13 < wumpus> "... two functions could be used - one that locks and another that does not..." yes, that's the common solution
12:13 < jnewbery> and the other way is having two versions of the function - one which requires the lock and one which takes the lock
12:13 < jnewbery> wumpus: right
12:13 < wumpus> moving locking external has its own risks
12:13 < hebasto> what risk?
12:13 < jeremyrubin> wumpus: if we use the clang safety annotations it's lesser, right?
12:13 < wumpus> having separate private "without lock" avoids that
12:13 < jnewbery> wumpus: I agree. Best to keep locking internal wherever possible
12:14 < vasild> "the locking mechanism used by a thread-safe class is part of its internal implementation" (from https://gist.github.com/hebasto/072ad3a9370641b035a36d08607a3d34#gistcomment-3448023)
12:14  * luke-jr stabs ISP
12:14 < sipa> ideally, locks are internal
12:14 < wumpus> hebasto: well, it goes against, the principle of encapsulation, knowledge of how to remove locks moves to outside the code
12:15 < wumpus> hebasto: at the least it makes reasoning more difficult 
12:15 < hebasto> wumpus: agree
12:15 < sipa> if a lock is internal to a class, and the class never invokes a callback passed down from elsewhere while holding that lock, it even guarantees no deadlocks
12:15 < wumpus> lock annotations are not a replacement for that
12:16 -!- rorp [43a994bd@c-67-169-148-189.hsd1.ca.comcast.net] has quit [Remote host closed the connection]
12:16 < jnewbery> if locks can't always be internal, then making two versions of the public interface function makes it explicit where the function is called with the lock held and without.
12:16 < sipa> jnewbery: that's what CAddrMan does
12:16 < sipa> but i don't see how one conflicts with the other
12:17 < jeremyrubin> What about a type-safe (using newtype) pass lock guard in as arugment?
12:17 < jeremyrubin> That would have both safety properties
12:17 < sipa> jeremyrubin: it works, but imho it still reeks of bad design
12:17 < jeremyrubin> as there would only be one way to get a satisfying lock
12:17 < wumpus> I don't really like that, I hope that can be avoided
12:17 < promag> and I'd like to discuss for() { LOCK(cs); } VS { LOCK() for() {} }
12:18 < hebasto> how to name this two functions? some kind of suffix to distinguish them?
12:18 < jnewbery> sipa: I'm not saying they do. Ideally, all locks are internal. If they can't be and sometimes need to be held by the caller, make it explicit where that is by using Mutex and having two versions of public functions where needed.
12:18 < aj> promag: with or without performance benchmarks?
12:18 < wumpus> promag: well that depends on the granularity of the work, so locking overhad versus the loop body, and whether it's undesirable to hold the lock for long
12:18 < sipa> promag: grabbing an uncontended lock is ~100 cpu cycles
12:18 < jeremyrubin> hebasto: I'd do a type tag argument maybe; like atmoic primitives.
12:19 < jeremyrubin> but maybe that's overkill
12:19 -!- molz_ [~mol@unaffiliated/molly] has joined #bitcoin-core-dev
12:19 < sipa> jnewbery: sorry, i misread what you suggested
12:20 < aj> jeremyrubin: void foo(int x); void foo(int x, LockAlreadyHeld h);  foo(3, LockAlreadyHeld()); // ?
12:20 < wumpus> I'm starting to understand Marcofalke's point now--this is a lot of work, conflicts with other changes, while we don't have a direct problem with RecursiveMutex
12:20 < aj> jeremyrubin: LockAlreadyHeld(cs_main); ?
12:20 < jeremyrubin> aj: Uh that can work yeah
12:20 < vasild> promag: I would say if the current code does one of that, we better have some proof that changing it is for the better.
12:20 < sdaftuar> wumpus: that is my gut reaction as well
12:21 < promag> aj: in simple cases not really
12:21 < sdaftuar> it would be nice to motivate this change with some new behavior we wish to implement, that woudl benefit from it?
12:21 < wumpus> if it helps to have a non-recursive mutex for future mempool changes it makes sense to do it, of course, but this seems a lot of design work for a pure refactor
12:21 < wumpus> sdaftuar: +1
12:21 < jeremyrubin> overall, same. It works as is.
12:22 -!- mol_ [~mol@unaffiliated/molly] has quit [Ping timeout: 256 seconds]
12:22 < luke-jr> I suspect it actually might make future changes harder :x
12:22 < sipa> luke-jr: depends on how it's done, i think
12:22 < jeremyrubin> I think that's the motivation; if future changes are leaning more on the recursive mutexing we don't want to make them that way
12:22 < sipa> really usually cleaning up locking means cleaning up the boundary between interfaces
12:23 < sipa> and if that's a side effect, it may definitely make things easier
12:23 < promag> sipa: I'm taking about cs_main
12:23 < jnewbery> sipa: +1
12:23 < wumpus> sipa: yes, if it can make that clearer it's a good thing
12:23 < promag> wumpus: agree
12:23 < jnewbery> cs_main is something else entirely
12:23 < sipa> just doing a dumb "whatever necessary to avoid recursive locking" is unlikely to be beneficial
12:23 < wumpus> agree
12:23 -!- Pavlenex [~Thunderbi@185.244.212.67] has quit [Quit: Pavlenex]
12:24 < promag> vasild: agree
12:24 < sipa> but it's probably hard to speak very generically here
12:24 < jnewbery> I think adding a lock-not-held version of all public functions which may or may not hold a lock is a pretty trivial change
12:25 < promag> i'm meh with that approach
12:25 < jeremyrubin> It's kinda annoying for other patches if you have to change 2 func signatures
12:25 < wumpus> jnewbery: at least that can be done virtually mechanically which makes it easier to review
12:25 < jnewbery> I think changing the function to assert the lock is held and then adding locks outside the class _isn't_ a good change
12:25 < vasild> funcUnprotected() { do stuff; }; func() { LOCK(); funcUnprotected(); }
12:25 < sipa> jnewbery: that does not seem crazy, but it's easier to judge with code
12:26 < wumpus> jnewbery: +1
12:26 < sdaftuar> i'm a bit confused -- would some of those functions not be used?
12:26 < promag> jnewbery: IMO it's a good change if it comes with a follow up refactor 
12:26 < luke-jr> I don't see what's wrong with func() that locks if necessary, but also works inside an external lock :x
12:26 < jnewbery> sdaftuar: you'd only add new functions where it may or may not already hold the lock
12:27 < jeremyrubin> luke-jr: I think that's basically a recursive lock
12:27 < sipa> luke-jr: it's a very abstract objection, but to me it is: code should be written to work inside our outside the private parts of a class that need locking
12:27 < vasild> luke-jr: that's like re-implementing recursive mutex
12:27 < jeremyrubin> the difference being maybe you can assert if you know you have lock already or not
12:27 < luke-jr> sipa: this does..?
12:27 < sipa> luke-jr: it's just hard to reason about the interface if you have code that works in both
12:28 < wumpus> hand rolling a recursive-ish mutex sounds even worse than simply using one
12:28 < sipa> please no
12:28 < nehan> the argument in https://gist.github.com/hebasto/072ad3a9370641b035a36d08607a3d34 for why RecursiveMutex is bad indicates why it's bad to use RecursiveMutex in the first place (it is a symptom of an underlying problem). i do not see how it explains the benefit of removing RecursiveMutex without addressing the underlying problem.
12:28 -!- Highway61 [~Thunderbi@unaffiliated/highway61] has quit [Ping timeout: 246 seconds]
12:28 < sipa> nehan: +1
12:28 < nehan> which it sounds like what this dual-function thing is doing
12:28 -!- Highway62 [~Thunderbi@unaffiliated/highway61] has joined #bitcoin-core-dev
12:28 < sipa> nehan: i think the dual function makes the interface layer explicit
12:29 < nehan> so the benefit of it is making a small (perhaps important) step towards making the interface more clear?
12:29 < luke-jr> my point wasn't to reinvent RM, but that RM has a use :p
12:29 < jnewbery> and by making it explicit, brings to attention what the underlying problem may be
12:29 < sipa> nehan: right, it makes it obvious where the problem is
12:30 < sipa> it doesn't fix it
12:30 < wumpus> nehan: yes, the general arguments against recursive mutex described there definitely make sense
12:30 < sdaftuar> so i think the right next step would be to precisely define what the interface ought ot be
12:30 < sdaftuar> and then we can work towards that
12:30 < jeremyrubin> It sounds like it might be worth to prepare this PR and not merge it
12:30 < jeremyrubin> Because if it indentifies what the problem is, then we can see if a fix can be built on it
12:30 < sdaftuar> refactoring without a design in mind seems bad to me
12:31 < jnewbery> sometimes it's not a problem to have a function that can be called with or without a lock. Sometimes you want to carry out multiple operations on an object atomically. That's not a problem, but it's always better to be explicit about what you're doing
12:31 -!- Highway62 is now known as Highway61
12:31 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev
12:32 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
12:32 < bitcoin-git> [bitcoin] instagibbs opened pull request #19936: Test: batch rpc with params (master...batch_param) https://github.com/bitcoin/bitcoin/pull/19936
12:32 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
12:33 < promag> sipa: WITH_LOCK(..., ...) is already an indicator
12:33 < jnewbery> hebasto: did you have anything else that you wanted input on?
12:33 < vasild> I think we can/should make mempool.cs mutex private
12:33 < jnewbery> vasild: that's a lot of work
12:34 < jnewbery> and might not even be desirable
12:34 < hebasto> jnewbery: it seems all discussed. what is consensus?
12:34 < promag> vasild: lots of refactors right?
12:34 -!- Highway62 [~Thunderbi@unaffiliated/highway61] has joined #bitcoin-core-dev
12:34 < vasild> IMO amount of work would be comparable to making it non-recursive
12:35 < jnewbery> vasild: not even close, I don't think. There are lots of places where we make multiple calls to the mempool atomically. Those would all need to be changed into higher-level interfaces to the mempool
12:35 < wumpus> vasild: at least that'd remove the problem of public functions needing the lock held
12:35 -!- Highway61 [~Thunderbi@unaffiliated/highway61] has quit [Ping timeout: 240 seconds]
12:35 -!- Highway62 is now known as Highway61
12:35 < wumpus> but yes, it's also much more work
12:35 < vasild> ok, my assessment could be wrong
12:35 -!- sr_gi [~sr_gi@static-240-45-224-77.ipcom.comunitel.net] has quit [Read error: Connection reset by peer]
12:36 < jeremyrubin> wild idea: mempool via message passing only?
12:36 -!- sr_gi [~sr_gi@static-240-45-224-77.ipcom.comunitel.net] has joined #bitcoin-core-dev
12:36 < jnewbery> vasild: eg all of this would need to become a single call to the mempool: https://github.com/bitcoin/bitcoin/blob/564e1ab0f3dc573bd3ea60a80f6649c361243df9/src/rpc/blockchain.cpp#L1406-L1421
12:36 < jeremyrubin> Might be good as there are some proposals to make the mempool a separate entity 
12:36 < jeremyrubin> and message passing based would cleanly separate internal details
12:37 < hebasto> vasild: that is possible
12:37 < vasild> jnewbery: yes, I looked into that, it would be one call that returns a struct holding all the data, not a big deal
12:38 -!- Madars [~null@unaffiliated/madars] has joined #bitcoin-core-dev
12:38 < jonatack> i like sdaftuar's suggestion that it be motivated by new behavior or a clear idea of the desired design/interface
12:38 < jnewbery> vasild: maybe. It just feels like a much bigger change. If you had a branch that moved the lock to be totally internal, I'd be very interested to see it
12:38 < vasild> mempool.AtomicallyGiveMeYourStats(&pool_stats); ;-)
12:39 < vasild> jnewbery: no, I don't have
12:39 < aj> time for the gui repo topic?
12:39 < jeremyrubin> vasild: a mempool interior thread/workqueue with condvar for wake on return could implement that API :p 
12:39 < wumpus> I guess it would be good to see an example of the various proposals and maybe re-discuss next week
12:39 < hebasto> wumpus: +1
12:39 < wumpus> if this is all worth it at all
12:40 < wumpus> maybe we're creaeting a problem where there's none
12:40 < wumpus> #topic Review the experience of 3 month bitcoin-core/gui repository (jonasschnelli)
12:40 < sdaftuar> i would reiterate that a design document for how the mempool would ideally interact with the rest of our software would be very helpful for evaulating any proposals
12:40 < jonasschnelli> I'd like to collect feedback on how well the separation of the GUI repository has been received.
12:41 < jonasschnelli> my feedback: it's seems still unclear how we merge things back to the main repository and if that has been documented.
12:41 < wumpus> yes, what's the plan for merging back the GUI changes?
12:41 < jonasschnelli> on top, the mix of PRs on both sides feels confusing to me.
12:41 < jnewbery> I think Marco has a script that merges them into both repositories simultaneously, no?
12:41 < jonasschnelli> Overall,... i would have prefered to split of the repository with a split off through a clean interface (process seperation in some ways)
12:42 < wumpus> I think it's nice to have GUI design discussions etc in the other repo
12:42 < jonasschnelli> jnewbery: could be. I don't know.
12:42 < jonasschnelli> Yes. I also like the split of the discussions and some GUI only PRs.
12:42 < jonasschnelli> I just don't know what burden we have when merging things back
12:42 < wumpus> it's sufficiently distinct from what happens in the main repo that that makes sense
12:43 < jonasschnelli> Also,... things that touch both "sides": still unclear how to handle that
12:43 < wumpus> I don't know either, looks like Marco Falke is missing for this discussion
12:43 < jonasschnelli> looks like
12:43 < promag> wumpus: most people just have to go to both repos.. it was a good change for those that want stay away from gui stuff
12:43 < jonasschnelli> However we go further, I think it would be nice to document the process more clear
12:44 < jnewbery> they seem to be pretty synchronized. The GUI repository is just one merge commit behind bitcoin/bitcoin
12:44 < jonasschnelli> Also unclear to me how we handle merge conflicts if we merge node stuff into the GUI repository
12:44 < jeremyrubin> jonasschnelli: +1 on process isolation being important for making the separation clearer
12:44 < luke-jr> did anyone ever get in touch with GitHub about the PR issues?
12:44 < jnewbery> jonasschnelli: they're the same commits
12:45 < jnewbery> there's no conflicts because it's always fast-forwards
12:45 < wumpus> jeremyrubin: IIRC there's a PR that does process isolation
12:45 < jonasschnelli> jnewbery: Right. I tihink its a non-issue as long as they stay in sync. Which I guess is a manual script
12:46 < jeremyrubin> wumpus: ryanofsky's right?
12:46 < michaelfolkson> I think the major concern is if review decreases with it being separate. I think people on the GUI repo need to regularly prod (cc) GUI reviewers who spend most of their time on the main repo.
12:46 < wumpus> ryanofsky is working on that #19461
12:46 < gribble> https://github.com/bitcoin/bitcoin/issues/19461 | multiprocess: Add bitcoin-gui -ipcconnect option by ryanofsky · Pull Request #19461 · bitcoin/bitcoin · GitHub
12:46 < wumpus> yes
12:46 < jonasschnelli> michaelfolkson: maybe only an initial issue. I think there are now also contributors stepping forward _because_ its GUI only
12:47 < hebasto> ^ and designers
12:47 < wumpus> jonasschnelli: exactly, though there's some overlap, it's also meant to get a different group of people involved
12:47 < michaelfolkson> But mainly designers right jonasschnelli? It needs normal Core reviewers too
12:48 < michaelfolkson> I think for design related review it is a material success so far
12:48 < wumpus> ideally we want more GUI contributors, improving the GUI, they don't necessarily need to get involved with the rest of the code
12:48 < jonasschnelli> michaelfolkson: Yes. Thats correct.
12:48 < jonasschnelli> It's a different complexity level (mostly). Also the risks are different.
12:48 < vasild> I think a separate GUI repository only makes sense as long as both repositories contain different chunks of software. Right now both contain the same, e.g. the gui repo contains bitcoind.cpp, net_processing.cpp, etc. Would it be possible to make only src/qt in the gui repo (and then make it a git submodule in the main one)?
12:48 < wumpus> a different kind of complexity to navigate at least
12:48 < jeremyrubin> wumpus: is there a framework for moving forward ryanofsky's work? last I checked it was still nack on capnproto?
12:49 < wumpus> I definitely found out I can't do it, I can't handle the subjectivity and bikeshedding involved :)
12:49 < jonasschnelli> vasild: this is a valid point
12:49 < jonasschnelli> wumpus : that. yes.
12:50 < wumpus> vasild: maybe, though it can't be built independently anymore then, it's harder for contributors
12:50 < hebasto> bikeshedding is a work for designers, no?
12:50 < yanmaani> Can't you refactor it to make the GUI an RPC client?
12:50 < vasild> hm, right, src/qt can't be build separately
12:50 < yanmaani> (and then optionally have it spawn a bitcoind)
12:50 < vasild> make make it compilable, libsrcqt.so :)
12:51 < jonasschnelli> yanmaani: I would also like to see that
12:51 < yanmaani> Then the GUI could indeed be moved to a separate repo
12:51 < jonasschnelli> but I guess we are drifting off-topic
12:51 < yanmaani> and you could have other people making other GUIs in other frameworks
12:51 < wumpus> yanmaani: that's what the multiprocess PR does, basically
12:51 < sipa> people tried that in 2012 or so, but it's terrible as RPC is query-response based, not asynchronous
12:51 < sipa> but the multiprocess work does this the right way
12:51 < jonasschnelli> sipa: we could use the long polling to make it faster though
12:51 < yanmaani> sipa: is RPC single-threaded?
12:51 < wumpus> yanmaani: (except it doesn't use JSON-RPC but its own RPC mechanism)
12:52 < promag> yanmaani: no
12:52 < wumpus> in any case ryanofsky's work already exists
12:52 < sipa> yanmaani: it would be more useful if you'd comment after you've spent some time looking at the code
12:52 < yanmaani> ok :)
12:52 < wumpus> no need to brainstorm the 2012 idea of doing it again now
12:52 < provoostenator> I suggest waiting a while before opening that can of worms though :-)
12:52 < jnewbery> yanmaani: even more useful if you review/test ryanofsky's work!
12:53 < jonasschnelli> I think I suggest then that we pimp up the documentation on how things are managed between the two repositories, avoid questions, etc.
12:53 < wumpus> jonasschnelli: +1
12:53 < jeremyrubin> wumpus: if some set of maintainers can establish a bit more of a framework on the validity of ryanofsky's approach i would spend some cycles on it. but AFAIU some contribs are nack on the approach so I'm not sure how likely it will proceed if that remains the case or what can be done to un-nack
12:53 < jonasschnelli> Let's hope MarcoFalke has time and willingness to do this
12:53 < wumpus> just documenting things would make sense
12:53 < wumpus> jeremyrubin: who is completely against it?
12:53 < jonasschnelli> people deserve to know what happens with PRs they write on the GUI repo
12:53 < jeremyrubin> gmax iirc?
12:54 < jeremyrubin> iirc he was against capnproto at all and wanted a custom IPC lib
12:54 < hebasto> +1 for documenting
12:54 < wumpus> for using capnproto for the GUI? I don't think so, he hates using it for internet protocols, but for internal communication between processes it doesn't matter too much
12:54 < sipa> no reason to speculate here
12:54 -!- opsec_x122 [~opsec_x12@44-25-143-49.ip.hamwan.net] has joined #bitcoin-core-dev
12:54 < sipa> afaik ryanofsky said that capnproto could easily be swapped out for something else if needed
12:55 < jonasschnelli> just the glue
12:55 < provoostenator> Indeed
12:55 < wumpus> I'd really dislike rolling our own IPC mechanism tbh
12:55 < jeremyrubin> do we already depend on it?
12:55 < jeremyrubin> It's in depends :)
12:55 < wumpus> there are so many one already, not everything needs to be invented here
12:55 < provoostenator> We already merged the build stuff for it.
12:55 < jonasschnelli> I'm still in favour or RPC
12:55 < jeremyrubin> https://github.com/bitcoin/bitcoin/pull/10102#issuecomment-289842646
12:55 < provoostenator> But it's an opt-in config flag
12:55 < wumpus> sipa: yes, it should be easy to swap out
12:56 < wumpus> he designed it so that the specific mechanism used is abstracted
12:56 < jnewbery> jonasschnelli: I think it's even easier than I said. Marco just merges the gui PR branch into the bitcoin/bitcoin repo
12:56 < wumpus> better just review the code...
12:56 < jonasschnelli> RPC can also work async. But yes. Not the topic now.
12:56 < wumpus> jonasschnelli: I mean we can do something wildly different but *only* if someone is willing to do the work
12:56 < jnewbery> and then I guess there's a bot or something that is syncing bitcoin-core/gui to the latest master
12:56 < jonatack> there is a good recent writeup by ryanofsky, one month ago, here: https://bitcoincore.reviews/19160 
12:56 < wumpus> I see no reason to second-guess ryanofsky now after all this time
12:56 < jonasschnelli> wumpus: that's a point.
12:57 < jnewbery> https://github.com/bitcoin/bitcoin/pull/19071
12:57 < jeremyrubin> I have no issue with capnproto I think it's fine :)
12:57 < provoostenator> Last time I dug into it I found the approach pretty sane.
12:57 < wumpus> at least it's a step forward
12:57 < jeremyrubin> I spent a bunch of time reviewing it in '17 and think it's a good approach
12:57 < wumpus> when RPC one day converges on what we need for the GUI, then we can switch to that
12:58 -!- opsec_x12 [~opsec_x12@44-25-143-49.ip.hamwan.net] has quit [Ping timeout: 256 seconds]
12:58 < jonasschnelli> Haven't looked into it. But separating the GUI from the node via the internet/wireguard would be a requirement,.. right?
12:58 < wumpus> I think it's *very important* to take a step by step approach with things
12:58 < provoostenator> Conversely, when the IPC interface simplifies and needs fewer locks...
12:59 < wumpus> if not, we'll never go anywhere, this kind of thing has been proposed since at least 2012
12:59 < jonasschnelli> indeed
12:59 < wumpus> because everyone wants something else
12:59 < jonasschnelli> the power of open source
12:59 < wumpus> and then someone does it and peopel want yet something else
12:59 < jeremyrubin> I think that's all I'm asking. If ryanofsky's pr is reasonably reviewed
13:00 < wumpus> so, anyhow, if you're interested in process separation, please review ryanofsky's PRs
13:00 < jeremyrubin> there is no 'hard reason' it can't be merged
13:00 < jeremyrubin> which is great news for anyone willing to spend review cycles on it, it derisks that time spent
13:00 < wumpus> dont' come up with new wild ideas that would have to start from scratch :)
13:00 < sdaftuar> jeremyrubin: i would hope not, my understanding is that ryanofsky has been making progress towards this goal for quite some time now
13:00 -!- arowser [~arowser1@204.124.180.72] has quit [Remote host closed the connection]
13:01 -!- arowser [~arowser1@204.124.180.72] has joined #bitcoin-core-dev
13:01 < wumpus> of course after reviewing the PR you could give more targeted suggestions
13:01 < wumpus> oh, it's time
13:01 < wumpus> #endmeeting
13:01 < lightningbot> Meeting ended Thu Sep 10 20:01:42 2020 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
13:01 < lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2020/bitcoin-core-dev.2020-09-10-19.00.html
13:01 < lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2020/bitcoin-core-dev.2020-09-10-19.00.txt
13:01 < lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2020/bitcoin-core-dev.2020-09-10-19.00.log.html
13:01 < jonasschnelli> \o
13:01 < vasild> o/
13:02 < jonatack> psa, the signet PR seems to be in the final stretch if anyone wants to have a look
13:02 < wumpus> yay!
13:02 < jonatack> \o
13:02 < michaelfolkson> Final stretch as in we can start a barrage of follow up smaller signet PRs
13:03 -!- Madars [~null@unaffiliated/madars] has quit [Ping timeout: 258 seconds]
13:03 < wumpus> but FWIW I had the idea that the capnproto approach for IPC communication was widely concept-ACKed a long time ago, that's why the build system part was merged
13:03 < jeremyrubin> I hadn't tracked that development :)
13:03 < luke-jr> I don't see why we need two RPC interfaces ;)
13:04 < wumpus> it's not a RPC interface it's internal interface only
13:04 < wumpus> it will not be documented for external clients so it has much more flexibility
13:04 < wumpus> it will also not be compatible between versions
13:04 < luke-jr> no matter how we use it, it's an RPC interface..
13:04 < jeremyrubin> I reviewed the process isolation stuff relatively early on, but it wasn't clear that it was going to move forward and didn't think i could do anything to move the needle on making an IPC interface available.
13:04 < luke-jr> we could just as well add an undocumented and unstable JSON-RPC interface
13:04 < jeremyrubin> now that I know it is, I'll re-review :)
13:05 < wumpus> there's a very different set of requirements for it anyhow
13:05 < wumpus> but as said maybe they can converge in the future
13:05 < jeremyrubin> luke-jr: the difference is that you can fork a process and explicitly set up the IPC channel
13:05 < wumpus> the idea is to allow for some experimentation here
13:05 < jeremyrubin> so that the connection is internal to one parent process
13:06 < jeremyrubin> You could maybe do this for RPC, but the point of IPC is to allow deeper integration & work with e.g. shared memory.
13:06 < luke-jr> so it won't be possible to run the GUI on another machine? :/
13:06 < wumpus> it's simply a pipe, it could send every protocol, but in any case, capnproto is ok for now imo
13:07 < sipa> jeremyrubin: first thing i hear about shared memory
13:07 < wumpus> I doubt there are any plans about shared memory
13:08 < wumpus> if gmaxwell is queasy about capnproto I'm sure he'll go insane when you mention shared memory :-)
13:08 < wumpus> it's also really not needed for this
13:10 < yanmaani> It's two different approaches. With well-defined RPC and all that, you can run it on separate machines, and you can have other projects writing GUIs. With shared memory and more "usual" IPC, you're more tightly coupled. So you can iterate faster, but you lose some of the benefits of keeping -gui separate
13:10 < yanmaani> if it always has to be the same version, for instance
13:11 < wumpus> yes
13:12 < luke-jr> fwiw someone mentioned to me the other day a desire to revive wxBitcoin - better separation helps that too
13:13 < jeremyrubin> iirc capnproto had some shared memory stuff but i may be wrong
13:14 < yanmaani> If you do the separation very cleanly you could have hundreds of random bozos making GUIs. Whether this is great or horrifying is up to your imagination.
13:15 < wumpus> revive wxbitcoin?!? whyy
13:15 < sipa> lol
13:15 < sipa> has 3.9 been released already?
13:15 < yanmaani> It was I. I don't like Qt.
13:16 < wumpus> sigh, I don't even want to know, I want to have 0 to do with the GUI anymore
13:16 < sipa> eh, 2.9 - apparently yes, they're at 3.1.4
13:16 < wumpus> sipa: progressss
13:17 < sipa> yanmaani: use RPC :p
13:17 < yanmaani> well, with these changes, you can just jettison the unloved components of the codebase
13:17 < wumpus> I just dislike all the bikeshedding, everyone wants something else, I think "I don't like library X" is an awful reason
13:17 < yanmaani> Or I can procrastinate on it and wait for these changes to be made, and use whatever you eventually bikeshed on.
13:18 < wumpus> imo ideally the GUI design should really be made by someone that gets GUIs at a psychological level and designs something that is usable by end-users, not by developers bikeshedding over libraries and widget types
13:19 < yanmaani> imo you should have two groups
13:19 < yanmaani> one group of designers who know design who design the psychologically optimal GUI in photoshop
13:19 < wumpus> developes come with ever sillier concerns
13:19 < yanmaani> one group of developers who bikeshed over widget types
13:19 < sipa> yanmaani: will you pay them all?
13:19 < yanmaani> (and implement the mockup)
13:20 < wumpus> it's interaction design, you can't really do that in photoshop
13:20 < sipa> UX is far more than graphical design
13:20 < wumpus> ^^ very much this
13:20 < yanmaani> I actually like the way the current GUI looks, and the fact that Electrum has converged on something extremely similar to Core is reassuring
13:22 < phantomcircuit> what's missing from the current gui is mostly debug related things, but im guessing the intersection between people who need debug stuff and people who won't use the cli is pretty small
13:22 < sipa> i haven't used the GUI in years
13:23 < luke-jr> ♥ current GUI
13:23 < yanmaani> ^
13:23 < sipa> then what's the problem with Qt?
13:23 < wumpus> phantomcircuit: what debug information are you missing?
13:24  * luke-jr ♥ Qt too
13:24 < achow101> the current gui kinda sucks with multiwallet
13:24 < achow101> it's really easy to accidentally use the wrong wallet
13:25 < luke-jr> admittedly, I don't use multiwallet much yet
13:25 < luke-jr> too much in the habit of closing one and opening another
13:25 < wumpus> I only use multiwallet for watch-only things
13:25 < gwillen> I mostly use multiwallet for manual testing tbh, but it's fantastic for that
13:26 < achow101> I run multiple wallets watching the same thing lol
13:26 < achow101> tbf, one is legacy, another descriptor, and the last sqlite descriptor
13:26 < wumpus> hehe
13:27 < phantomcircuit> wumpus, "is this transaction in the mempool", "how big is the mempool" ie things that aren't actually relevant to most users
13:27 < wumpus> phantomcircuit: ah yes, mempool information is a bit sparse
13:27 < achow101> phantomcircuit: how big is the mempool is reported
13:28 < sipa> i'd like a debug tool with a secp256k1 DL solver
13:28 < luke-jr> phantomcircuit: Knots has some mempool graph stuff jonasschnelli wrote years ago
13:28 < sipa> would come in really.handy
13:28 < wumpus> did we never merge the mempool graph stuff?
13:28 < wumpus> I thought that was pretty nice
13:28 < luke-jr> wumpus: I have rebased versions of an older version of the PR
13:28 < jonasschnelli> I have picked this up recently
13:29 < luke-jr> jonasschnelli changed the RPC side of it all around, but never updated the GUI for it
13:29 < luke-jr> ah, nice
13:29 < wumpus> that's the kind of things I like about the GUI tbh, debug and data visualization
13:29 < sipa> indeed
13:29 < jonasschnelli> Made it more like Jochen Hoenick ones
13:29 < jonasschnelli> With few ranges
13:29 < jonasschnelli> I’ll PR that soon.
13:30 < wumpus> jonasschnelli: awesome!
13:30 < wumpus> I think it would be very nice if users can see those things locally, without having to go to a site
13:30 -!- Aracely71Hammes [~Aracely71@static.57.1.216.95.clients.your-server.de] has joined #bitcoin-core-dev
13:31 < jeremyrubin> [9/10/20 13:28] <sipa> i'd like a debug tool with a secp256k1 DL solver
13:32 < jeremyrubin> I'd think you'd see this before a good QT GUI debugger 
13:32 < jeremyrubin> The only question is if you can make a good trapdoor function out of bugs in QT
13:33 < jeremyrubin> BIP QT-root
13:35 -!- Aracely71Hammes [~Aracely71@static.57.1.216.95.clients.your-server.de] has quit [Ping timeout: 256 seconds]
13:36 < wumpus> a DL solver would definitely be useful :')
13:36 < wumpus> at least if it doesn't hold up the GUI loop for a million billion years
13:37 < sipa> haha
13:37 -!- Highway61 [~Thunderbi@unaffiliated/highway61] has quit [Ping timeout: 240 seconds]
13:39 < promag> <sipa> i haven't used the GUI in years
13:39 < promag> because GUI uses sipa
13:39 < jonasschnelli> for the ones interested in the mempool size/fee chart: https://github.com/bitcoin/bitcoin/compare/master...jonasschnelli:2020/03/mempool_graph?expand=1
13:39 < jonasschnelli> (it's WIP)
13:40 < jonasschnelli> It's more or less a clone of https://jochen-hoenicke.de/queue/#0,24h
13:40 < jonasschnelli> (but obviously internal and QT native)
13:40 < gribble> https://github.com/bitcoin/bitcoin/issues/0 | HTTP Error 404: Not Found
13:47 < phantomcircuit> sipa, btw going from 1000 to 100k keys only added 50% to the runtime of a rescan
13:47 < sipa> phantomcircuit: wait until you hit enough keys that the mapKeys structure doesn't fit in RAM anymore
13:47 < sipa> ;)
13:47 < luke-jr> could always use a bloom filter for the wallet keys, to speed it up ;)
13:48 < phantomcircuit> sipa, that would be a very very large number of keys
13:48 < sipa> phantomcircuit: you just have too much RAM
13:48 < sipa> ;)
13:49 < sipa> phantomcircuit: more seriously, i think the actual impact of number of keys on rescan speed isn't so much the O(log n) scaling, but whether or not the mapKeys fits in various levels of CPU cache or RAM
13:49 < phantomcircuit> sipa, indeed
13:50 < wumpus> jonasschnelli: that's great!
13:50 < phantomcircuit> luke-jr, the gcs filters that 'neutrino' use are what i was using, but to actually use them requires changing violating some assumptions the current logic has (namely that every block derives the filter key from the block hash)
13:54 -!- promag [~promag@Bl19-22-20.dsl.telepac.pt] has quit [Read error: Connection reset by peer]
13:54 -!- promag [~promag@Bl19-22-20.dsl.telepac.pt] has joined #bitcoin-core-dev
13:55 -!- promag [~promag@Bl19-22-20.dsl.telepac.pt] has quit [Read error: Connection reset by peer]
13:55 -!- promag [~promag@bl19-22-20.dsl.telepac.pt] has joined #bitcoin-core-dev
13:55 -!- tryphe [~tryphe@unaffiliated/tryphe] has joined #bitcoin-core-dev
13:57 -!- Madars [~null@unaffiliated/madars] has joined #bitcoin-core-dev
13:57 -!- vincenzopalazzo [~vincent@host-82-60-201-14.retail.telecomitalia.it] has quit [Remote host closed the connection]
13:57 -!- tryphe_ [~tryphe@unaffiliated/tryphe] has quit [Ping timeout: 240 seconds]
14:00 -!- popey1 [~popey@s91904426.blix.com] has quit []
14:00 -!- promag [~promag@bl19-22-20.dsl.telepac.pt] has quit [Ping timeout: 256 seconds]
14:00 -!- promag [~promag@Bl19-22-20.dsl.telepac.pt] has joined #bitcoin-core-dev
14:01 -!- Guyver2 [Guyver@guyver2.xs4all.nl] has quit [Quit: Going offline, see ya! (www.adiirc.com)]
14:01 < luke-jr> phantomcircuit: I meant the other direction
14:02 -!- promag [~promag@Bl19-22-20.dsl.telepac.pt] has quit [Read error: Connection reset by peer]
14:02 -!- promag [~promag@bl19-22-20.dsl.telepac.pt] has joined #bitcoin-core-dev
14:04 -!- Highway61 [~Thunderbi@unaffiliated/highway61] has joined #bitcoin-core-dev
14:05 < phantomcircuit> luke-jr, ?
14:05 < phantomcircuit> oh put the wallet keys into a filter
14:05 < luke-jr> yes
14:06 < luke-jr> if you do it right, you might even be able to do a union of the neutrino filters with the wallet filter..
14:06 < phantomcircuit> iirc most of the time for the current rescan is actually deserializing the block and verifying the merkle root
14:06 < achow101> sipa: interestingly on my branch where i've changed ~all of the wallet maps and sets to unordered_map/set, the rescan actually takes 10x longer. On both newly created legacy and descriptor wallets
14:06 < luke-jr> you don't need to verify the merkle root
14:06 < achow101> seems like siphash is a lot slower than one map comparison?
14:07 -!- Highway61 [~Thunderbi@unaffiliated/highway61] has quit [Client Quit]
14:07 < sipa> achow101: interesting
14:07 < achow101> actually, siphash probably isn't being used there, the hashers for CKeyID and CScriptID just use uint's GetUint64
14:08 < phantomcircuit> luke-jr, ok but it does verify the merkle tree because you're loading the block from disk
14:09 < yanmaani> would PRs be accepted where you replace std::unordered_map with something else for CCoinsViewCache, or is that not worth looking into?
14:10 < sipa> if it's measurably faster, possibly
14:10 < wumpus> jonasschnelli: will try it out a bit tomorrow
14:11 < phantomcircuit> luke-jr, anyways if you setup the gcs filter index things using a local static key then you can calculate the hashes that you need to check against and save them, which makes the rescan basically just finding the union of two sets
14:12 < luke-jr> phantomcircuit: but make both sets a filter
14:12 < phantomcircuit> luke-jr, i guess you could take the gcs set and make a bloom filter on top of that?
14:12 < wumpus> besides being demostratively faster, it also depends on 'something else', e.g. probably not if it introduces any new dependencies on boost, or anything else external
14:13 < phantomcircuit> iono i suspect that would actually be slower than just doing the giant union of the sets calculation
14:13 < wumpus> also as it's a consensus critical data structure it's something to be very careful with
14:13 < luke-jr> bdb!
14:13  * luke-jr hides
14:14 < jb55> achow101: agreed on multiwallet gui. this is something I still use cli for over qt. would be great to have an "all wallets" transaction view.
14:19 < sipa> jb55: if you have the same key/address/descriptor imported in multiple simultaneously-loaded wallets, an "all wallets" overview may be confusing
14:19  * sipa predicts people creating 1M wallets with the same 21 BTC UTXO on it, and screenshottijg their 21M BTC combined balance
14:20 < achow101> sipa: it feels like importing the same thing into multiple wallets might not be something people tend to do
14:20 < luke-jr> sipa: then don't use it? :P
14:20 < jb55> sipa: maybe they shouldn't do that :P
14:20 < sipa> jb55: seems achow101 just did!
14:21 < achow101> sipa: I suspect that you won't be able to load 1M wallets
14:22 -!- Theopolisme [~Theopolis@89.47.234.28] has joined #bitcoin-core-dev
14:22 < sipa> achow101: software should be optimized for all use cases!
14:22 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net]
14:22 < jb55> 150m keys should be instant imo
14:23 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev
14:23 -!- Madars [~null@unaffiliated/madars] has quit [Ping timeout: 256 seconds]
14:31 -!- tryphe [~tryphe@unaffiliated/tryphe] has quit [Read error: Connection reset by peer]
14:32 -!- tryphe [~tryphe@unaffiliated/tryphe] has joined #bitcoin-core-dev
15:03 -!- Madars [~null@unaffiliated/madars] has joined #bitcoin-core-dev
15:07 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has quit [Remote host closed the connection]
15:08 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has joined #bitcoin-core-dev
15:34 -!- Eagle[TM] [~EagleTM@unaffiliated/eagletm] has joined #bitcoin-core-dev
15:35 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has quit [Ping timeout: 258 seconds]
15:38 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
15:38 < bitcoin-git> [bitcoin] ajtowns opened pull request #19937: signet mining utility (master...202009-signet-generate) https://github.com/bitcoin/bitcoin/pull/19937
15:38 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
15:59 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds]
16:01 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-dev
16:02 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
16:16 -!- promag [~promag@bl19-22-20.dsl.telepac.pt] has quit [Remote host closed the connection]
16:21 -!- mdunnio [~mdunnio@208.59.170.5] has quit [Remote host closed the connection]
16:26 -!- shaunsun [shaunsun@gateway/vpn/privateinternetaccess/shaunsun] has quit [Ping timeout: 260 seconds]
16:34 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
16:39 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 258 seconds]
16:42 -!- lightlike [~lightlike@p200300c7ef19e60094135b145ee15ebe.dip0.t-ipconnect.de] has quit [Quit: Leaving]
16:45 -!- sr_gi [~sr_gi@static-240-45-224-77.ipcom.comunitel.net] has quit [Read error: Connection reset by peer]
16:45 -!- mdunnio [~mdunnio@208.59.170.5] has joined #bitcoin-core-dev
16:46 -!- sr_gi [~sr_gi@static-240-45-224-77.ipcom.comunitel.net] has joined #bitcoin-core-dev
16:50 -!- mdunnio [~mdunnio@208.59.170.5] has quit [Ping timeout: 265 seconds]
16:53 -!- Sambij [bc28b595@static.149.181.40.188.clients.your-server.de] has joined #bitcoin-core-dev
17:00 -!- Theopolisme [~Theopolis@89.47.234.28] has quit []
17:03 < achow101> under what circumstances would some script be in mapScripts that we would consider ISMINE_NO?
17:04 < achow101> I think the only case where that happens is addmultisigaddress
17:05 -!- Highway61 [~Thunderbi@unaffiliated/highway61] has joined #bitcoin-core-dev
17:07 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
17:08 -!- Highway61 [~Thunderbi@unaffiliated/highway61] has quit [Client Quit]
17:09 -!- Highway61 [~Thunderbi@unaffiliated/highway61] has joined #bitcoin-core-dev
17:09 -!- mdunnio [~mdunnio@208.59.170.5] has joined #bitcoin-core-dev
17:10 -!- isis_ is now known as isis
17:11 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 240 seconds]
17:14 -!- mdunnio [~mdunnio@208.59.170.5] has quit [Ping timeout: 265 seconds]
17:21 -!- solirc [~solirc@84.39.117.57] has joined #bitcoin-core-dev
17:33 < achow101> oh, apparently I had enable-debug on my hashtable branch and that's what caused the slowdown
17:36 < sipa> achow101: that explains
17:41 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 265 seconds]
17:50 -!- mdunnio [~mdunnio@208.59.170.5] has joined #bitcoin-core-dev
17:54 -!- mdunnio [~mdunnio@208.59.170.5] has quit [Ping timeout: 256 seconds]
17:56 -!- marcoagner [~user@2001:8a0:6a45:1900:2fd7:e0f0:d356:dd70] has quit [Ping timeout: 244 seconds]
18:04 < phantomcircuit> achow101, the debug stuff makes a few seemingly innocuous things comically slow
18:14 -!- arowser [~arowser1@204.124.180.72] has quit [Remote host closed the connection]
18:14 -!- arowser [~arowser1@204.124.180.72] has joined #bitcoin-core-dev
18:25 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev
18:26 -!- mdunnio [~mdunnio@208.59.170.5] has joined #bitcoin-core-dev
18:51 -!- opsec_x122 is now known as opsec_x12
18:57 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has joined #bitcoin-core-dev
18:59 -!- Eagle[TM] [~EagleTM@unaffiliated/eagletm] has quit [Ping timeout: 256 seconds]
19:09 -!- proofofkeags [~proofofke@174-29-30-112.hlrn.qwest.net] has quit [Quit: Leaving]
19:09 -!- proofofkeags [~proofofke@174-29-30-112.hlrn.qwest.net] has joined #bitcoin-core-dev
19:26 -!- mdunnio [~mdunnio@208.59.170.5] has quit [Remote host closed the connection]
19:38 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
19:59 -!- opsec_x12 [~opsec_x12@44-25-143-49.ip.hamwan.net] has quit [Ping timeout: 264 seconds]
20:00 -!- solirc [~solirc@84.39.117.57] has quit []
20:00 -!- mdunnio [~mdunnio@208.59.170.5] has joined #bitcoin-core-dev
20:05 -!- mdunnio [~mdunnio@208.59.170.5] has quit [Ping timeout: 258 seconds]
20:06 -!- Sambij [bc28b595@static.149.181.40.188.clients.your-server.de] has quit [Ping timeout: 245 seconds]
20:11 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 256 seconds]
20:21 -!- arowser [~arowser1@204.124.180.72] has quit [Remote host closed the connection]
20:21 -!- arowser [~arowser1@204.124.180.72] has joined #bitcoin-core-dev
20:22 -!- amueller [~amueller@195.140.213.38] has joined #bitcoin-core-dev
20:32 -!- Highway61 [~Thunderbi@unaffiliated/highway61] has quit [Quit: Highway61]
20:41 -!- opsec_x12 [~opsec_x12@44-25-143-49.ip.hamwan.net] has joined #bitcoin-core-dev
20:56 -!- sr_gi [~sr_gi@static-240-45-224-77.ipcom.comunitel.net] has quit [Read error: Connection reset by peer]
20:56 -!- sr_gi [~sr_gi@static-240-45-224-77.ipcom.comunitel.net] has joined #bitcoin-core-dev
21:18 -!- _________ [~textual@171.5.26.89] has joined #bitcoin-core-dev
21:18 -!- _________ is now known as Guest4692
21:32 -!- Guest4692 [~textual@171.5.26.89] has quit [Quit: Textual IRC Client: www.textualapp.com]
21:38 -!- da39a3ee5e6b4b0d [~textual@2403:6200:8876:edc:8931:b0c4:3f36:e776] has joined #bitcoin-core-dev
21:48 -!- proofofkeags [~proofofke@174-29-30-112.hlrn.qwest.net] has quit [Ping timeout: 258 seconds]
22:04 -!- opsec_x122 [~opsec_x12@44-25-143-49.ip.hamwan.net] has joined #bitcoin-core-dev
22:04 -!- opsec_x12 [~opsec_x12@44-25-143-49.ip.hamwan.net] has quit [Read error: Connection reset by peer]
22:08 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
22:11 -!- opsec_x122 [~opsec_x12@44-25-143-49.ip.hamwan.net] has quit [Ping timeout: 256 seconds]
22:13 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
22:13 < bitcoin-git> [bitcoin] fanquake pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/a47e5964861d...dffefda21de0
22:13 < bitcoin-git> bitcoin/master 36f8e0c Jon Atack: doc: update PyZMQ installation instructions, ZeroMQ link
22:13 < bitcoin-git> bitcoin/master 062e669 Jon Atack: script: fix zmq_sub.py file permissions
22:13 < bitcoin-git> bitcoin/master dffefda fanquake: Merge #19870: doc: update PyZMQ install instructions, fix zmq_sub.py file ...
22:13 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
22:13 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
22:13 < bitcoin-git> [bitcoin] fanquake merged pull request #19870: doc: update PyZMQ install instructions, fix zmq_sub.py file permissions (master...zmq-doc-fix) https://github.com/bitcoin/bitcoin/pull/19870
22:13 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
22:17 -!- opsec_x122 [~opsec_x12@44-25-143-49.ip.hamwan.net] has joined #bitcoin-core-dev
22:19 -!- cyberscout [~cyberscou@ip72-220-79-97.sd.sd.cox.net] has joined #bitcoin-core-dev
22:19 -!- opsec_x122 is now known as opsec_x12
22:20 -!- cyberscout [~cyberscou@ip72-220-79-97.sd.sd.cox.net] has quit [Client Quit]
22:24 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Quit: WeeChat 2.7.1]
22:34 -!- MrPaz [~paz@24.14.251.223] has quit [Ping timeout: 260 seconds]
22:41 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 260 seconds]
22:42 -!- mdunnio [~mdunnio@208.59.170.5] has joined #bitcoin-core-dev
22:47 -!- mdunnio [~mdunnio@208.59.170.5] has quit [Ping timeout: 265 seconds]
22:52 -!- mekster [~mekster@139.180.192.79] has quit [Read error: Connection reset by peer]
22:52 -!- mekster [~mekster@139.180.192.79] has joined #bitcoin-core-dev
22:53 -!- sdaftuar [~sdaftuar@gateway/tor-sasl/sdaftuar] has quit [Ping timeout: 240 seconds]
22:54 -!- sdaftuar [~sdaftuar@gateway/tor-sasl/sdaftuar] has joined #bitcoin-core-dev
22:55 -!- amueller [~amueller@195.140.213.38] has quit [Remote host closed the connection]
22:59 -!- mekster [~mekster@139.180.192.79] has quit [Read error: Connection reset by peer]
23:00 -!- lukedashjr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev
23:05 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 264 seconds]
23:05 -!- lukedashjr is now known as luke-jr
23:13 -!- mekster [~mekster@139.180.192.79] has joined #bitcoin-core-dev
23:21 -!- VitamineD [~VitamineD@217.146.82.202] has joined #bitcoin-core-dev
23:22 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
23:22 < bitcoin-git> [bitcoin] fanquake pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/dffefda21de0...9366a73d6951
23:22 < bitcoin-git> bitcoin/master a9f2014 eugene: build: use DIR_FUZZ_SEED_CORPUS if specified for cov_fuzz target
23:22 < bitcoin-git> bitcoin/master fb3bacc eugene: .gitignore: ignore qa-assets/ folder
23:22 < bitcoin-git> bitcoin/master 9366a73 fanquake: Merge #19916: build: allow user to specify DIR_FUZZ_SEED_CORPUS for cov_fu...
23:22 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
23:23 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
23:23 < bitcoin-git> [bitcoin] fanquake merged pull request #19916: build: allow user to specify DIR_FUZZ_SEED_CORPUS for cov_fuzz (master...cov_fuzz_cleanup_0908) https://github.com/bitcoin/bitcoin/pull/19916
23:23 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
23:25 < fanquake> Looking for Qs / concerns / concept ACKs in #18605. 
23:25 < gribble> https://github.com/bitcoin/bitcoin/issues/18605 | build: Link time garbage collection by fanquake · Pull Request #18605 · bitcoin/bitcoin · GitHub
23:27 < fanquake> We haven't made it to LTO yet, but this should be a (less risky) step in that sort of direction.
23:27 < sipa> fanquake: seema like a no brainer if it reduces binary sizes
23:27 < sipa> you mention that gc sections increases the binary size... by much?
23:32 < fanquake> sipa: yea for Windows. I can't remember exactly, but will rebuild and expand the note in the PR description.
23:53 < fanquake> sipa: bitcoind.exe is 12.69mb building master + link time gc (minimal depends), vs 11.50mb building master
23:54 < sipa> interesting
23:54 < sipa> that's pretty significant
23:55 < sipa> but only on windows?
23:56 < fanquake> Yea. Rebuilding Linux to now to double check the reductions.
23:56 < fanquake> That was also done with binutils 2.34, so quite a new version.
--- Log closed Fri Sep 11 00:00:15 2020