--- Log opened Thu Jun 11 00:00:46 2020
00:02 -!- windsok [~windsok@unaffiliated/windsok] has quit [Ping timeout: 256 seconds]
00:05 -!- jarthur_ [~jarthur@2605:6000:1019:63cd:5bc:1f88:8104:f97d] has quit [Remote host closed the connection]
00:05 -!- windsok [~windsok@rarepepe.cash] has joined #bitcoin-core-dev
00:05 -!- windsok [~windsok@rarepepe.cash] has quit [Changing host]
00:05 -!- windsok [~windsok@unaffiliated/windsok] has joined #bitcoin-core-dev
00:22 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
00:22 < bitcoin-git> [bitcoin] luke-jr opened pull request #19243: banman: Limit resources consumed by misbehaving node deprioitisation (master...misbehaving_limit) https://github.com/bitcoin/bitcoin/pull/19243
00:22 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
00:23 -!- SiAnDoG [~514nDoG@gateway/tor-sasl/siandog] has joined #bitcoin-core-dev
00:35 -!- kabaum [~kabaum@2001:9b1:efd:9b00:55d3:b22b:b6e1:f9c2] has joined #bitcoin-core-dev
00:36 < luke-jr> is it just me, or do we currently have a bug where a misbehaving node makes itself immune to a real/user-set ban less than 24 hours long?
00:37 < luke-jr> also, is there any realistic way to write functional tests for many misbehaving nodes? XD
00:37 < luke-jr> (or even a handful..)
00:37 -!- Guyver2 [Guyver@guyver2.xs4all.nl] has joined #bitcoin-core-dev
00:54 -!- tryphe [~tryphe@unaffiliated/tryphe] has quit [Read error: Connection reset by peer]
00:55 -!- tryphe [~tryphe@unaffiliated/tryphe] has joined #bitcoin-core-dev
00:55 -!- braydonf [~braydon@gateway/tor-sasl/braydonf] has quit [Ping timeout: 240 seconds]
00:57 -!- braydonf [~braydon@gateway/tor-sasl/braydonf] has joined #bitcoin-core-dev
01:15 -!- sipsorcery [~sipsorcer@37.228.243.107] has quit [Read error: Connection reset by peer]
01:22 -!- justan0theruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev
01:25 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 260 seconds]
01:31 -!- Pavlenex [~Thunderbi@141.98.103.251] has joined #bitcoin-core-dev
01:33 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
01:37 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net]
01:38 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev
01:38 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
01:38 < bitcoin-git> [bitcoin] fanquake pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/6762a627ecb8...45a6811d36fc
01:38 < bitcoin-git> bitcoin/master faedb50 MarcoFalke: test: pep-8 mining_basic
01:38 < bitcoin-git> bitcoin/master fa98e10 MarcoFalke: test: Remove leftover comment in mining_basic
01:38 < bitcoin-git> bitcoin/master 45a6811 fanquake: Merge #19206: test: Remove leftover comment in mining_basic
01:38 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
01:38 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
01:38 < bitcoin-git> [bitcoin] fanquake merged pull request #19206: test: Remove leftover comment in mining_basic (master...2006-testComment) https://github.com/bitcoin/bitcoin/pull/19206
01:39 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
01:43 -!- windsok [~windsok@unaffiliated/windsok] has quit [Ping timeout: 272 seconds]
01:44 -!- windsok [~windsok@unaffiliated/windsok] has joined #bitcoin-core-dev
01:55 -!- justan0theruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 272 seconds]
01:55 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev
02:00 -!- engil1 [~engil@94.229.74.91] has quit []
02:05 -!- jarthur [~jarthur@2605:6000:1019:63cd:5bc:1f88:8104:f97d] has joined #bitcoin-core-dev
02:10 -!- jarthur [~jarthur@2605:6000:1019:63cd:5bc:1f88:8104:f97d] has quit [Ping timeout: 256 seconds]
02:21 -!- Waithamai [~Waithamai@195.206.169.238] has joined #bitcoin-core-dev
02:22 -!- Waithamai is now known as Guest65675
02:48 -!- S3RK [~s3rk@47.246.66.112] has joined #bitcoin-core-dev
02:56 -!- S3RK [~s3rk@47.246.66.112] has quit [Ping timeout: 265 seconds]
03:01 -!- S3RK [~s3rk@47.246.66.112] has joined #bitcoin-core-dev
03:05 -!- Marie16Stracke [~Marie16St@static.57.1.216.95.clients.your-server.de] has joined #bitcoin-core-dev
03:08 -!- awesome-doge [lplplpmatr@gateway/shell/matrix.org/x-cajpvhhsiadvmixi] has joined #bitcoin-core-dev
03:10 -!- Marie16Stracke [~Marie16St@static.57.1.216.95.clients.your-server.de] has quit [Ping timeout: 260 seconds]
03:12 -!- S3RK [~s3rk@47.246.66.112] has quit [Ping timeout: 260 seconds]
03:16 -!- promag [~promag@bl19-22-20.dsl.telepac.pt] has joined #bitcoin-core-dev
03:21 -!- Asbestos_Vapor [~Mercury_V@174-082-166-092.res.spectrum.com] has joined #bitcoin-core-dev
03:25 -!- promag [~promag@bl19-22-20.dsl.telepac.pt] has quit [Remote host closed the connection]
03:25 -!- Mercury_Vapor [~Mercury_V@174-082-166-092.res.spectrum.com] has quit [Ping timeout: 265 seconds]
03:25 -!- promag [~promag@Bl19-22-20.dsl.telepac.pt] has joined #bitcoin-core-dev
03:27 -!- promag_ [~promag@Bl19-22-20.dsl.telepac.pt] has joined #bitcoin-core-dev
03:27 -!- promag [~promag@Bl19-22-20.dsl.telepac.pt] has quit [Read error: Connection reset by peer]
03:28 -!- S3RK [~s3rk@47.246.66.112] has joined #bitcoin-core-dev
03:51 -!- rafalcpp [~racalcppp@ip-178-214.ists.pl] has joined #bitcoin-core-dev
03:53 -!- Relis [~Relis@cpc96290-lewi18-2-0-cust910.2-4.cable.virginm.net] has joined #bitcoin-core-dev
04:02 -!- Relis [~Relis@cpc96290-lewi18-2-0-cust910.2-4.cable.virginm.net] has quit [Quit: This computer has gone to sleep]
04:06 -!- Pavlenex [~Thunderbi@141.98.103.251] has quit [Quit: Pavlenex]
04:06 -!- jarthur [~jarthur@2605:6000:1019:63cd:5bc:1f88:8104:f97d] has joined #bitcoin-core-dev
04:12 -!- jarthur [~jarthur@2605:6000:1019:63cd:5bc:1f88:8104:f97d] has quit [Ping timeout: 260 seconds]
04:27 -!- S3RK [~s3rk@47.246.66.112] has quit [Remote host closed the connection]
04:27 -!- S3RK [~s3rk@47.246.66.112] has joined #bitcoin-core-dev
04:29 -!- S3RK [~s3rk@47.246.66.112] has quit [Remote host closed the connection]
04:29 -!- S3RK [~s3rk@47.246.66.112] has joined #bitcoin-core-dev
04:39 -!- Relis [~Relis@cpc96290-lewi18-2-0-cust910.2-4.cable.virginm.net] has joined #bitcoin-core-dev
04:40 -!- S3RK [~s3rk@47.246.66.112] has quit [Remote host closed the connection]
04:40 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
04:40 < bitcoin-git> [bitcoin] kiminuo opened pull request #19245: [WIP DONOTMERGE] Replace boost::filesystem with std::filesystem (in c++17) (master...feature/2020-06-replace-boost-filesystem-with-cpp17-filesystem) https://github.com/bitcoin/bitcoin/pull/19245
04:40 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
04:40 -!- S3RK [~s3rk@47.246.66.112] has joined #bitcoin-core-dev
04:42 -!- Kiminuo [~mix@141.98.103.180] has joined #bitcoin-core-dev
04:45 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Quit: = ""]
04:47 -!- S3RK [~s3rk@47.246.66.112] has quit [Ping timeout: 256 seconds]
04:57 -!- owowo [~ovovo@unaffiliated/ovovo] has quit [Ping timeout: 256 seconds]
04:58 -!- belcher [~belcher@unaffiliated/belcher] has joined #bitcoin-core-dev
05:00 -!- Guest65675 [~Waithamai@195.206.169.238] has quit []
05:02 -!- owowo [~ovovo@unaffiliated/ovovo] has joined #bitcoin-core-dev
05:09 -!- rafalcpp [~racalcppp@ip-178-214.ists.pl] has quit [Ping timeout: 256 seconds]
05:11 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 256 seconds]
05:14 -!- Guyver2 [Guyver@guyver2.xs4all.nl] has quit [Quit: Going offline, see ya! (www.adiirc.com)]
05:15 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev
05:22 -!- izaki1 [~izaki@195.206.169.238] has joined #bitcoin-core-dev
05:25 -!- S3RK [~s3rk@47.246.66.112] has joined #bitcoin-core-dev
05:30 -!- rafalcpp [~racalcppp@ip-178-214.ists.pl] has joined #bitcoin-core-dev
05:32 -!- prusnak [sid403625@gateway/web/irccloud.com/x-hkezqmmeoszcbmgq] has quit [Read error: Connection reset by peer]
05:32 -!- prusnak [sid403625@gateway/web/irccloud.com/x-vuyreppzkftfuwkk] has joined #bitcoin-core-dev
05:32 -!- hugohn [sid304114@gateway/web/irccloud.com/x-zuvdkgvfwlxxvniv] has quit [Read error: Connection reset by peer]
05:32 -!- schmidty [sid297174@gateway/web/irccloud.com/x-nngxwkzqbkdnzwpw] has quit [Read error: Connection reset by peer]
05:32 -!- hugohn [sid304114@gateway/web/irccloud.com/x-tktjmdwaptlvxwyu] has joined #bitcoin-core-dev
05:33 -!- arik__ [sid402902@gateway/web/irccloud.com/x-zwbeskgvzstdxdkz] has quit [Read error: Connection reset by peer]
05:33 -!- schmidty [sid297174@gateway/web/irccloud.com/x-jmabqekawstlkbtw] has joined #bitcoin-core-dev
05:33 -!- pierre_rochard [sid299882@gateway/web/irccloud.com/x-spwrfouxaaawdzaz] has quit [Read error: Connection reset by peer]
05:33 -!- jkczyz [sid419941@gateway/web/irccloud.com/x-cmdidozedoxkrfli] has quit [Read error: Connection reset by peer]
05:33 -!- amiti [sid373138@gateway/web/irccloud.com/x-ihxzbbxnsodekzrj] has quit [Write error: Connection reset by peer]
05:33 -!- michagogo [uid14316@wikia/Michagogo] has quit [Read error: Connection reset by peer]
05:33 -!- vfP56jSe [sid321684@gateway/web/irccloud.com/x-kwigvwuqfsdhytgz] has quit [Read error: Connection reset by peer]
05:33 -!- arik__ [sid402902@gateway/web/irccloud.com/x-cwymbzphenxznlzz] has joined #bitcoin-core-dev
05:33 -!- jkczyz [sid419941@gateway/web/irccloud.com/x-tvumzoynjieujdzb] has joined #bitcoin-core-dev
05:33 -!- amiti [sid373138@gateway/web/irccloud.com/x-hgjyjsqravpgpkiv] has joined #bitcoin-core-dev
05:33 -!- pierre_rochard [sid299882@gateway/web/irccloud.com/x-wybbemtkcdzkqynv] has joined #bitcoin-core-dev
05:33 -!- vfP56jSe [sid321684@gateway/web/irccloud.com/x-duzdkkelrathvzqx] has joined #bitcoin-core-dev
05:33 -!- michagogo [uid14316@wikia/Michagogo] has joined #bitcoin-core-dev
05:36 -!- S3RK [~s3rk@47.246.66.112] has quit [Ping timeout: 260 seconds]
05:38 -!- pretyflaco [~k3m@2001:a61:4e3:7701:d4:6723:a834:efb3] has joined #bitcoin-core-dev
05:43 -!- troygiorshev [~troygiors@CPEdcef09a0ed55-CM0c473d74be00.cpe.net.cable.rogers.com] has joined #bitcoin-core-dev
06:02 -!- troygiorshev [~troygiors@CPEdcef09a0ed55-CM0c473d74be00.cpe.net.cable.rogers.com] has quit [Quit: leaving]
06:02 -!- troygiorshev [~troygiors@CPEdcef09a0ed55-CM0c473d74be00.cpe.net.cable.rogers.com] has joined #bitcoin-core-dev
06:07 -!- jarthur [~jarthur@2605:6000:1019:63cd:5bc:1f88:8104:f97d] has joined #bitcoin-core-dev
06:11 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
06:11 < bitcoin-git> [bitcoin] practicalswift opened pull request #19247: tests: Add fuzzing harness for {Read,Write}{LE,BE}{16,32,64} (crypto/common.h) (master...fuzzers-crypto_common) https://github.com/bitcoin/bitcoin/pull/19247
06:11 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
06:12 -!- rafalcpp [~racalcppp@ip-178-214.ists.pl] has quit [Ping timeout: 260 seconds]
06:12 -!- jarthur [~jarthur@2605:6000:1019:63cd:5bc:1f88:8104:f97d] has quit [Ping timeout: 260 seconds]
06:27 -!- rafalcpp [~racalcppp@ip-178-214.ists.pl] has joined #bitcoin-core-dev
06:39 -!- dfmb_ [~dfmb_@unaffiliated/dfmb/x-4009105] has joined #bitcoin-core-dev
06:39 -!- dfmb_ [~dfmb_@unaffiliated/dfmb/x-4009105] has quit [Remote host closed the connection]
06:54 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
06:54 < bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/45a6811d36fc...7a24cca82906
06:54 < bitcoin-git> bitcoin/master f42f5e5 Russell Yanofsky: refactor: Combine GetWalletForJSONRPCRequest and EnsureWalletIsAvailable f...
06:54 < bitcoin-git> bitcoin/master 7a24cca MarcoFalke: Merge #19100: refactor: Combine GetWalletForJSONRPCRequest and EnsureWalle...
06:54 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
06:54 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
06:54 < bitcoin-git> [bitcoin] MarcoFalke merged pull request #19100: refactor: Combine GetWalletForJSONRPCRequest and EnsureWalletIsAvailable functions (master...pr/ensa) https://github.com/bitcoin/bitcoin/pull/19100
06:54 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
07:06 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
07:06 < bitcoin-git> [bitcoin] hebasto opened pull request #19249: Add means to handle negative capabilities in the Clang Thread Safety annotations (master...200611-nc) https://github.com/bitcoin/bitcoin/pull/19249
07:06 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
07:09 -!- proofofkeags [~proofofke@71-218-146-180.hlrn.qwest.net] has joined #bitcoin-core-dev
07:20 -!- Kiminuo [~mix@141.98.103.180] has quit [Ping timeout: 246 seconds]
07:25 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
07:25 < bitcoin-git> [bitcoin] MarcoFalke opened pull request #19250: wallet: [move-only bugfix] Make RPC help compile-time static (master...2006-rpcWalletHelp) https://github.com/bitcoin/bitcoin/pull/19250
07:25 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
07:34 -!- Kiminuo [~mix@141.98.103.180] has joined #bitcoin-core-dev
07:37 -!- real_or_random [~real_or_r@173.249.7.254] has quit [Quit: ZNC 1.7.5 - https://znc.in]
07:38 -!- real_or_random [~real_or_r@2a02:c207:3002:7468::1] has joined #bitcoin-core-dev
07:44 -!- mol_ [~mol@unaffiliated/molly] has quit [Ping timeout: 246 seconds]
07:49 -!- Pavlenex [~Thunderbi@141.98.103.251] has joined #bitcoin-core-dev
08:00 -!- izaki1 [~izaki@195.206.169.238] has quit []
08:08 -!- jarthur [~jarthur@2605:6000:1019:63cd:5bc:1f88:8104:f97d] has joined #bitcoin-core-dev
08:13 -!- jarthur [~jarthur@2605:6000:1019:63cd:5bc:1f88:8104:f97d] has quit [Ping timeout: 256 seconds]
08:22 -!- llamma1 [~llamma@178.162.204.238] has joined #bitcoin-core-dev
08:22 -!- mol [~mol@unaffiliated/molly] has joined #bitcoin-core-dev
08:22 -!- midnight [~midnight@unaffiliated/midnightmagic] has quit [Ping timeout: 272 seconds]
08:23 -!- jarthur [~jarthur@2605:6000:1019:63cd:8924:c6f9:7074:2cda] has joined #bitcoin-core-dev
08:25 < hebasto> please remind how to propose a meeting topic in advance?
08:26 < achow101> hebasto: using #proposedmeetingtopic
08:26 < hebasto> achow101: thanks
08:27 < hebasto> #proposedmeetingtopic Bump minimum required Clang version to 3.5
08:27 < hebasto> ^ in the context of #19249
08:27 < gribble> https://github.com/bitcoin/bitcoin/issues/19249 | Add means to handle negative capabilities in the Clang Thread Safety annotations by hebasto · Pull Request #19249 · bitcoin/bitcoin · GitHub
08:32 -!- Relis [~Relis@cpc96290-lewi18-2-0-cust910.2-4.cable.virginm.net] has quit [Quit: This computer has gone to sleep]
08:34 -!- sipsorcery [~sipsorcer@37.228.243.107] has joined #bitcoin-core-dev
08:41 -!- troygiorshev [~troygiors@CPEdcef09a0ed55-CM0c473d74be00.cpe.net.cable.rogers.com] has quit [Ping timeout: 256 seconds]
08:42 -!- jarthur [~jarthur@2605:6000:1019:63cd:8924:c6f9:7074:2cda] has quit [Ping timeout: 256 seconds]
08:43 -!- Relis [~Relis@cpc96290-lewi18-2-0-cust910.2-4.cable.virginm.net] has joined #bitcoin-core-dev
08:43 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
08:43 < bitcoin-git> [bitcoin] hebasto opened pull request #19251: [Do Not Merge] ci: Temporary Test Case for negative capabilities in the Clang Thread Safety annotations (master...200611-dnm-test) https://github.com/bitcoin/bitcoin/pull/19251
08:43 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
08:46 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 260 seconds]
08:47 -!- jarthur [~jarthur@2605:6000:1019:63cd:947f:c7b:ab47:cbfa] has joined #bitcoin-core-dev
08:47 -!- midnight [~midnight@unaffiliated/midnightmagic] has joined #bitcoin-core-dev
08:52 -!- troygiorshev [~troygiors@CPEdcef09a0ed55-CM0c473d74be00.cpe.net.cable.rogers.com] has joined #bitcoin-core-dev
09:02 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev
09:05 -!- Talkless [~Talkless@hst-227-49.splius.lt] has joined #bitcoin-core-dev
09:13 -!- S3RK [~s3rk@47.246.66.112] has joined #bitcoin-core-dev
09:20 -!- vasild_ [~vd@gateway/tor-sasl/vasild] 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:32 < wumpus> I think we should bump compiler versions after C++17, not bother witht it sooner
09:32 < wumpus> no need to complicate this with multiple bumps
09:38 < wumpus> but note that #16684 has no mention of clang versions
09:39 < gribble> https://github.com/bitcoin/bitcoin/issues/16684 | Discussion: upgrading to C++17 · Issue #16684 · bitcoin/bitcoin · GitHub
09:39 < wumpus> I think we need to determine what clang version to require as minimum then
09:39 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 256 seconds]
09:41 -!- pretyflaco1 [~k3m@185.213.155.166] has joined #bitcoin-core-dev
09:41 < sipa> clang advertizes full c++17 support as of version 5
09:41 < sipa> but it seems nearly all features are present in 4
09:44 -!- troygiorshev [~troygiors@CPEdcef09a0ed55-CM0c473d74be00.cpe.net.cable.rogers.com] has quit [Quit: leaving]
09:44 -!- pretyflaco [~k3m@2001:a61:4e3:7701:d4:6723:a834:efb3] has quit [Ping timeout: 256 seconds]
09:44 -!- troygiorshev [~troygiors@CPEdcef09a0ed55-CM0c473d74be00.cpe.net.cable.rogers.com] has joined #bitcoin-core-dev
09:44 -!- guest534543 [~mix@193.9.112.244] has joined #bitcoin-core-dev
09:47 < wumpus> right: https://clang.llvm.org/cxx_status.html#cxx17  and some (more obscure?) things are only in 9/10
09:47 < hebasto> wumpus: yes, C++17 is near. Do you mean 19249 should be dropped for now, or could move on without clang version bumping?
09:47 < wumpus> hebasto: if you can make it optional
09:48 -!- Kiminuo [~mix@141.98.103.180] has quit [Ping timeout: 240 seconds]
09:48 < wumpus> I think we should let the minimum version also depend on what is generally available in Linux distros' to make sure we can test against it easily
09:48 < hebasto> that is the problem: make it optional will clutter the code
09:48 < wumpus> hebasto: then I'd say delay it until a bump is needed for c++17
09:49 < hebasto> jessie 3.5; xenial 3.8
09:50 -!- troygiorshev [~troygiors@CPEdcef09a0ed55-CM0c473d74be00.cpe.net.cable.rogers.com] has quit [Quit: leaving]
09:51 -!- troygiorshev [~troygiors@CPEdcef09a0ed55-CM0c473d74be00.cpe.net.cable.rogers.com] has joined #bitcoin-core-dev
09:51 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
09:51 < bitcoin-git> [bitcoin] MarcoFalke pushed 4 commits to master: https://github.com/bitcoin/bitcoin/compare/7a24cca82906...85f7db22841e
09:51 < bitcoin-git> bitcoin/master e380818 John Newbery: Revert "[TESTS] Move base58 to own module to break circular dependency"
09:51 < bitcoin-git> bitcoin/master b216b0b John Newbery: [tests] sort imports in rpc_createmultisig.py
09:51 < bitcoin-git> bitcoin/master 3a83a01 John Newbery: [tests] move generate_wif_key to wallet_util.py
09:51 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
09:51 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
09:51 < bitcoin-git> [bitcoin] MarcoFalke merged pull request #19239: tests: move generate_wif_key to wallet_util.py (master...2020-06-generate-wif-key) https://github.com/bitcoin/bitcoin/pull/19239
09:51 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
09:52 < wumpus> hebasto: you might want to post that into the c++17 issue 
09:57 -!- roconnor [~roconnor@host-45-78-199-248.dyn.295.ca] has quit [Read error: Connection reset by peer]
10:01 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
10:01 < bitcoin-git> [bitcoin] MarcoFalke pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/85f7db22841e...8682414d0238
10:01 < bitcoin-git> bitcoin/master 4a8181b practicalswift: tests: Add std::vector<uint8_t> ConsumeFixedLengthByteVector(FuzzedDataPro...
10:01 < bitcoin-git> bitcoin/master cf5b8f6 practicalswift: tests: Add fuzzing harness for {Read,Write}{LE,BE}{16,32,64} (crypto/commo...
10:01 < bitcoin-git> bitcoin/master 8682414 MarcoFalke: Merge #19247: tests: Add fuzzing harness for {Read,Write}{LE,BE}{16,32,64}...
10:01 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
10:01 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
10:01 < bitcoin-git> [bitcoin] MarcoFalke merged pull request #19247: tests: Add fuzzing harness for {Read,Write}{LE,BE}{16,32,64} (crypto/common.h) (master...fuzzers-crypto_common) https://github.com/bitcoin/bitcoin/pull/19247
10:01 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
10:02 < wumpus> hebasto: thanks for doing the research though, let's discuss it further in the meeting
10:03 -!- icota[m] [icotamatri@gateway/shell/matrix.org/x-hmlapeyzopliczrv] has joined #bitcoin-core-dev
10:04 -!- ExEric3 [~exeric3@178.132.3.92] has joined #bitcoin-core-dev
10:04 -!- troygiorshev [~troygiors@CPEdcef09a0ed55-CM0c473d74be00.cpe.net.cable.rogers.com] has quit [Quit: leaving]
10:05 -!- troygiorshev [~troygiors@CPEdcef09a0ed55-CM0c473d74be00.cpe.net.cable.rogers.com] has joined #bitcoin-core-dev
10:08 -!- Guyver2 [Guyver@guyver2.xs4all.nl] has joined #bitcoin-core-dev
10:10 -!- troygiorshev [~troygiors@CPEdcef09a0ed55-CM0c473d74be00.cpe.net.cable.rogers.com] has quit [Quit: leaving]
10:10 -!- troygiorshev [~troygiors@CPEdcef09a0ed55-CM0c473d74be00.cpe.net.cable.rogers.com] has joined #bitcoin-core-dev
10:25 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection]
10:25 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #bitcoin-core-dev
10:31 -!- mol_ [~mol@unaffiliated/molly] has joined #bitcoin-core-dev
10:33 -!- troygiorshev [~troygiors@CPEdcef09a0ed55-CM0c473d74be00.cpe.net.cable.rogers.com] has quit [Quit: leaving]
10:33 -!- troygiorshev [~troygiors@CPEdcef09a0ed55-CM0c473d74be00.cpe.net.cable.rogers.com] has joined #bitcoin-core-dev
10:34 -!- molz_ [~mol@unaffiliated/molly] has joined #bitcoin-core-dev
10:35 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 264 seconds]
10:35 -!- molz_ [~mol@unaffiliated/molly] has quit [Read error: Connection reset by peer]
10:35 -!- molz_ [~mol@unaffiliated/molly] has joined #bitcoin-core-dev
10:36 -!- rafalcpp [~racalcppp@ip-178-214.ists.pl] has quit [Ping timeout: 256 seconds]
10:36 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev
10:37 -!- molz_ [~mol@unaffiliated/molly] has quit [Read error: Connection reset by peer]
10:37 -!- molz_ [~mol@unaffiliated/molly] has joined #bitcoin-core-dev
10:37 -!- proofofkeags [~proofofke@71-218-146-180.hlrn.qwest.net] has quit [Remote host closed the connection]
10:38 -!- mol_ [~mol@unaffiliated/molly] has quit [Ping timeout: 240 seconds]
10:38 -!- proofofkeags [~proofofke@71-218-146-180.hlrn.qwest.net] has joined #bitcoin-core-dev
10:38 -!- rafalcpp [~racalcppp@ip-178-214.ists.pl] has joined #bitcoin-core-dev
10:39 -!- Guyver2_ [Guyver@guyver2.xs4all.nl] has joined #bitcoin-core-dev
10:42 -!- Guyver2 [Guyver@guyver2.xs4all.nl] has quit [Ping timeout: 256 seconds]
10:42 -!- molz_ [~mol@unaffiliated/molly] has quit [Ping timeout: 260 seconds]
10:42 -!- proofofkeags [~proofofke@71-218-146-180.hlrn.qwest.net] has quit [Ping timeout: 258 seconds]
10:43 -!- Guyver2_ is now known as Guyver2
10:44 -!- troygiorshev [~troygiors@CPEdcef09a0ed55-CM0c473d74be00.cpe.net.cable.rogers.com] has quit [Quit: leaving]
10:45 -!- troygiorshev [~troygiors@CPEdcef09a0ed55-CM0c473d74be00.cpe.net.cable.rogers.com] has joined #bitcoin-core-dev
10:45 -!- isis_ is now known as isis
10:45 -!- proofofkeags [~proofofke@71-218-146-180.hlrn.qwest.net] has joined #bitcoin-core-dev
10:47 -!- rafalcpp [~racalcppp@ip-178-214.ists.pl] has quit [Ping timeout: 256 seconds]
10:50 -!- mol [~mol@unaffiliated/molly] has joined #bitcoin-core-dev
10:51 -!- troygiorshev [~troygiors@CPEdcef09a0ed55-CM0c473d74be00.cpe.net.cable.rogers.com] has quit [Quit: leaving]
10:52 -!- troygiorshev [~troygiors@CPEdcef09a0ed55-CM0c473d74be00.cpe.net.cable.rogers.com] has joined #bitcoin-core-dev
10:53 -!- troygiorshev [~troygiors@CPEdcef09a0ed55-CM0c473d74be00.cpe.net.cable.rogers.com] has quit [Client Quit]
10:53 -!- dviola [~diego@unaffiliated/dviola] has quit [Quit: WeeChat 2.8]
10:54 -!- troygiorshev [~troygiors@CPEdcef09a0ed55-CM0c473d74be00.cpe.net.cable.rogers.com] has joined #bitcoin-core-dev
11:00 -!- llamma1 [~llamma@178.162.204.238] has quit []
11:03 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
11:03 < bitcoin-git> [bitcoin] gzhao408 opened pull request #19252: [wip] test: wait for disconnect in disconnect_p2ps + bloomfilter test followups (master...test-disconnect-p2ps-wait) https://github.com/bitcoin/bitcoin/pull/19252
11:03 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
11:07 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
11:07 < bitcoin-git> [bitcoin] jnewbery opened pull request #19253: Tests: tidy up address.py and segwit_addr.py (master...2020-06-addr-unit-tests) https://github.com/bitcoin/bitcoin/pull/19253
11:07 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
11:13 -!- dr-orlovsky [~dr-orlovs@xdsl-188-154-186-21.adslplus.ch] has joined #bitcoin-core-dev
11:13 -!- rafalcpp [~racalcppp@ip-178-214.ists.pl] has joined #bitcoin-core-dev
11:16 -!- guest534543 [~mix@193.9.112.244] has quit [Quit: Leaving]
11:16 -!- Kiminuo [~mix@193.9.112.244] has joined #bitcoin-core-dev
11:20 -!- jtk [~jtk@84.39.116.180] has joined #bitcoin-core-dev
11:22 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
11:26 -!- gleb [~gleb@159.224.16.138] has joined #bitcoin-core-dev
11:29 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has joined #bitcoin-core-dev
11:37 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
11:37 < bitcoin-git> [bitcoin] MarcoFalke pushed 6 commits to master: https://github.com/bitcoin/bitcoin/compare/8682414d0238...b33136b6ba98
11:37 < bitcoin-git> bitcoin/master e8acc60 gzhao408: [test] add mempool msg test for node with bloomfilter enabled
11:37 < bitcoin-git> bitcoin/master 497a619 gzhao408: [test] add BIP 37 test for node with fRelay=false
11:37 < bitcoin-git> bitcoin/master 4ef80f0 gzhao408: [test] sending invalid msgs to node with bloomfilters=0 causes disconnect
11:37 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
11:37 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
11:37 < bitcoin-git> [bitcoin] MarcoFalke merged pull request #19083: test: msg_mempool, fRelay, and other bloomfilter tests (master...test-bloomfilter) https://github.com/bitcoin/bitcoin/pull/19083
11:37 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
11:40 -!- rafalcpp [~racalcppp@ip-178-214.ists.pl] has quit [Ping timeout: 264 seconds]
11:47 -!- danielyin [~danielyin@204.11.107.220] has joined #bitcoin-core-dev
11:47 -!- danielyi1 [~danielyin@204.11.107.220] has joined #bitcoin-core-dev
11:52 -!- danielyin [~danielyin@204.11.107.220] has quit [Quit: leaving]
11:52 -!- danielyi1 [~danielyin@204.11.107.220] has quit [Quit: leaving]
11:53 -!- danielyin [~danielyin@204.11.107.220] has joined #bitcoin-core-dev
11:57 -!- gimballock [b8a4b1b9@d-184-164-177-185.fl.cpe.atlanticbb.net] has joined #bitcoin-core-dev
11:59 < phantomcircuit> MarcoFalke, are you the wallet maintainer?
11:59 < MarcoFalke> no :shock:
11:59 < jonasschnelli> phantomcircuit: meshcollider 
12:00 < meshcollider> Hi :)
12:00 < wumpus> #startmeeting
12:00 < lightningbot> Meeting started Thu Jun 11 19:00:18 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 < achow101> hi
12:00 < jonasschnelli> hi
12:00 < hebasto> hi
12:00 < kanzure> 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 amiti fjahr
12:00 < wumpus> jeremyrubin lightlike emilengler jonatack hebasto jb55 elichai2
12:00 < jeremyrubin> hola
12:00 < fjahr> hi
12:00 < meshcollider> hi
12:00 < jamesob> hi
12:01 < jonatack> hi
12:01 < amiti> hi
12:01 < gleb> hi
12:01 < wumpus> hi
12:01 < sipa> hi
12:01 < troygiorshev> hi
12:01 < jnewbery> hi
12:02 < MarcoFalke> hi
12:02 < gwillen> hi
12:02 < jkczyz> hi
12:02 < wumpus> one proposed topic: Bump minimum required Clang version to 3.5 (hebasto)
12:03 < dongcarl> hebasto: links?
12:03 < MarcoFalke> As I posted in the thread, debian oldoldstable is on clang-4
12:03 < wumpus> (you can propose topics between meetings with #proposedmeetingtopic, or now before the meeting)
12:03 < MarcoFalke> Not sure why this is so controversial
12:03 < wumpus> please wait with discussion about the topic until the topic
12:03 < MarcoFalke> sorry
12:03 < dongcarl> sry
12:04 < jeremyrubin> #proposedmeetingtopic feature detection API
12:04 < wumpus> yeah you don't have to use that tag inside the meeting we see it :)
12:04 < jeremyrubin> (i think it helps for grepping logs)
12:04 < wumpus> #topic High priority for review
12:05 < gleb> Could I nominate #18991 for blockers? I think it's a big improvement for p2p privacy, and it would also unlock me from further work on AddrMan.
12:05 < gribble> https://github.com/bitcoin/bitcoin/issues/18991 | Cache responses to GETADDR to prevent topology leaks by naumenkogs · Pull Request #18991 · bitcoin/bitcoin · GitHub
12:05 < wumpus> 13(!) blockers, 0 bugfixes, 3 items chasing ACK https://github.com/bitcoin/bitcoin/projects/8
12:05 < gleb> Oh i see....
12:06 < jamesob> if anyone wants to see forward motion on assumeutxo, #18637 is the one to review
12:06 < gribble> https://github.com/bitcoin/bitcoin/issues/18637 | coins: allow cache resize after init by jamesob · Pull Request #18637 · bitcoin/bitcoin · GitHub
12:06 < MarcoFalke> I'd like to add #19071
12:06 < gribble> https://github.com/bitcoin/bitcoin/issues/19071 | doc: Separate repository for the gui by MarcoFalke · Pull Request #19071 · bitcoin/bitcoin · GitHub
12:06 < MarcoFalke> Not sure what is left there
12:06 < wumpus> gleb: added
12:07 < MarcoFalke> Mine is not a blocker, so feel free to ignore ;)
12:07 < gleb> thank you! We need couple more eyes on #18991. It's a little code with big impact, not much prior knowledge required but it would expose you to the logic of addr relay! So really nice to review please come :)
12:07 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection]
12:07 < gribble> https://github.com/bitcoin/bitcoin/issues/18991 | Cache responses to GETADDR to prevent topology leaks by naumenkogs · Pull Request #18991 · bitcoin/bitcoin · GitHub
12:07 < wumpus> 18637 is already in there
12:08 < wumpus> 19071 added
12:09 -!- proofofkeags [~proofofke@71-218-146-180.hlrn.qwest.net] has quit [Remote host closed the connection]
12:09 < jamesob> wumupus: yep just additional heads-up since people seem to ask about where the project's at from time to time
12:09 < jnewbery> #proposedmeetingtopic Add Really Really High Priority For Review project
12:09 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #bitcoin-core-dev
12:09 < jamesob> haha
12:09 < wumpus> oh noooo
12:09 -!- proofofkeags [~proofofke@71-218-146-180.hlrn.qwest.net] has joined #bitcoin-core-dev
12:09 < wumpus> sky high elite priority for review project
12:10 < gleb> Jokes aside, maybe would be useful to re-iterate on the usability/usefulness of the high-prio stuff. Maybe PRs should expire from there or somehting.
12:10 < jamesob> that's interesting. probably no way of doing automatic expiry with github though
12:11 < jamesob> maybe drahtbot?
12:11 -!- Talkless [~Talkless@hst-227-49.splius.lt] has quit [Quit: Konversation terminated!]
12:11 < MarcoFalke> I found that putting something in high prio has no effect on review activity
12:11 < wumpus> I don't think we need automatic expiry, let's just try to pay attention ourselves
12:11 < gleb> I don't think it makes sense to automate such a low-latency thing.
12:11 < gleb> Or rather low-bandwidth I should say.
12:11 < wumpus> MarcoFalke: well at least I pay more attention to it, for what it's worth
12:11 < gleb> I just wanted to make sure wumpus and co are comfortable with evicting things from tht list.
12:11 < wumpus> although, the higher the number of things on there the less it matters I'd definiltly agree
12:12 < jonatack> jnewbery: good point. when the list is short, i follow it. when it's long, i make my own list.
12:12 < jeremyrubin> although review blocked, I am happy having a project
12:12 < wumpus> I guess it's good that every contributor can propose something that's most important for them now
12:12 < jeremyrubin> So maybe letting more contributors manage a project is better than the high prior for review as it is better to sort work
12:13 < wumpus> I'm not sure that needs any bots or automatic expiry to be honest
12:13 < MarcoFalke> Agree
12:13 < jeremyrubin> Especially if the important-ness is blocking related, projects can help hilight the follow on work
12:13 < jnewbery> wumpus: I agree. At the very least, it's useful for contributors to signal "this is _my_ highest priority PR right now"
12:13 < hebasto> a bit more projects seems good
12:13 < wumpus> jnewbery: exactly
12:13 < gleb> jnewbery: only when people look at the list :)
12:13 < jnewbery> but you shouldn't assume that anyone else cares :)
12:14 < wumpus> if no one cares, no one cares, nothing to do about that
12:14 -!- kvaciral [~kvaciral@185.198.57.211] has joined #bitcoin-core-dev
12:14 -!- proofofkeags [~proofofke@71-218-146-180.hlrn.qwest.net] has quit [Ping timeout: 256 seconds]
12:14 < fjahr> I think the length is ok. Reviewers just have to take a pick and often not all of them are relevant for oneself.
12:15 < wumpus> it's, sometimes, kind of absurd sometimes how much money sails on this project compared to how little attention review gets, but it's only one of the many mysteries
12:15 < jeremyrubin> wumpus: you need to tokenize review for that
12:15 < MarcoFalke> For some high prio stuff I am unqualfied to review because I am lacking the background, so even forcing me to review wouldn't yield anything better than a "Concept ACK"
12:16 < jeremyrubin> MarcoFalke: +1
12:16 < wumpus> yes, I don't have any solutions either, that's what I meant
12:16 < gleb> maybe lists per domain: wallet p2p mining consensus etc with a maintainer would make it efficient, i dunno.
12:16 < jnewbery> wumpus: I expect there's more effort and time going into review on this project than at any point in the past
12:16 < wumpus> jnewbery: I'm happy to hear that
12:17 < wumpus> gleb: nah…
12:17 < wumpus> you can already sort issues per label, you know
12:17 < wumpus> and PRs
12:17 < gleb> Right.
12:18 < wumpus> I don't think high priority for review is suppsoed to become that long that it needs to be sorted into categories as well
12:18 < wumpus> but who knows :-)
12:18 < MarcoFalke> The number of open pull requests keeps growing ...
12:18 < wumpus> I think one problem is the huge number of different concerns and aspects in one project
12:18 < wumpus> but we've been over that
12:19 < wumpus> #topic Bump minimum required Clang version to 3.5 (hebasto)
12:19 < hebasto> hi
12:19 < hebasto> negative capabilities in clang thread safety analysis are a great tool to prevent deadlocks
12:19 < jonatack> I agree with it remaining ad hoc. Ideally people would not put non-blocking, non-completely review-ready PRs in the list, and pull their own PRs off if less high-priority than others.
12:19 < wumpus> personally, I think we should hold off doing any compiler version bumps until C++17
12:19 < hebasto> #19249
12:19 < gribble> https://github.com/bitcoin/bitcoin/issues/19249 | Add means to handle negative capabilities in the Clang Thread Safety annotations by hebasto · Pull Request #19249 · bitcoin/bitcoin · GitHub
12:19 < MarcoFalke> I think I misunderstood what the annotation do, so I will need to re-review the changes, but if they are useful, we shouldn't hold them back for 4 months.
12:20 < hebasto> example of usage: #19238
12:20 < gribble> https://github.com/bitcoin/bitcoin/issues/19238 | refactor: Replace RecursiveMutex with Mutex in CAddrMan by hebasto · Pull Request #19238 · bitcoin/bitcoin · GitHub
12:20 < hebasto> example of error catching #19251
12:20 < gribble> https://github.com/bitcoin/bitcoin/issues/19251 | [Do Not Merge] ci: Temporary Test Case for negative capabilities in the Clang Thread Safety annotations by hebasto · Pull Request #19251 · bitcoin/bitcoin · GitHub
12:20 < MarcoFalke> no distro is using this ancient version of clang, and gcc is used by default to compile  anyway
12:20 < wumpus> I don't think requiring *everyone* to use a newer compiler just for some annotations and checking is that great
12:20 < sipa> wumpus: i have no strong opinion either way; bumping to (already such an old) new clang seems fairly low friction
12:20 < hebasto> it requires clang 3.5+
12:21 < MarcoFalke> wumpus: Is any os using pre-3.5 clang?
12:21 < wumpus> if a few peopel compile with those annotations it aleady helps
12:21 < dongcarl> https://repology.org/project/clang/versions
12:21 -!- ajonas [sid385278@gateway/web/irccloud.com/x-vvqiawmttlehinlw] has quit []
12:21 < wumpus> it doesn't have to be everyone
12:21 < sipa> but if we're going to do a big bump soon anyway, that's ok too
12:21 < MarcoFalke> oldoldstable debian is on clang-4
12:21 < sipa> clang 3.5 is from 2015
12:21 -!- adamjonas [sid385278@gateway/web/irccloud.com/x-xvaqxaghrqhajtnq] has joined #bitcoin-core-dev
12:21 < wumpus> I'm not necessarily opposed to this specific bump, but I think we're spending too much time doing small bumps
12:22 -!- dviola [~diego@unaffiliated/dviola] has joined #bitcoin-core-dev
12:22 < wumpus> I'd like to make an "ambitious" bump for C++17, it's a good rationale
12:22 < MarcoFalke> This is merely a documentation change. It should have no effect in practice 
12:22 < hebasto> agree 
12:23 < wumpus> ok...
12:23 < wumpus> I don't care strongly just update it then
12:23 < wumpus> please don't come back next week that you need another bump though ;)
12:23 < jeremyrubin> Personal note that I find the safety annotations really confusing
12:23 < hebasto> which way?
12:24 < hebasto> EXCLUSIVE_LOCKS_REQUIRED(!mutex) looks good and works well
12:24 < MarcoFalke> if the change doesn't make it in because it is not worthwhile, clang won't be bumped
12:25 < wumpus> I think it's worthwhile to check
12:25 < wumpus> for compilers that support it
12:25 < jeremyrubin> I don't quite know how to use them for some of the tasks that I would like to prove safe :) Would be interested to learn more; I have a couple examples where we over-lock and I'm not sure how to use the exclusive locks required negation to accomplish that
12:25 < wumpus> I do not think it's a worthwhile reason to drop compilers that don't support it
12:25 < jeremyrubin> We can take it offline though
12:25 < wumpus> then again I'm not fanatic in supporting ancient stuff either
12:26 < wumpus> if oldoldstable is already 4.0, let's require 4.09
12:26 < wumpus> 4.0*
12:26 < MarcoFalke> Anyway, let's first check if the annotations make sense
12:27 < hebasto> examples are here #19238
12:27 < gribble> https://github.com/bitcoin/bitcoin/issues/19238 | refactor: Replace RecursiveMutex with Mutex in CAddrMan by hebasto · Pull Request #19238 · bitcoin/bitcoin · GitHub
12:27 < wumpus> but my point was, we *know* we're going to drop support for old compilers with C++17, so all time spend discussing bumps before that is probably wasted
12:27 < hebasto> so 3.5 or 4.0 ?
12:28 < wumpus> MarcoFalke: yes, let's be sure of that first
12:28 < hebasto> ok
12:28 < wumpus> #topic Feature detection API (jeremyrubin)
12:29 < jeremyrubin> Not too much; but there was some discussion on this w.r.t. people building on top of core
12:30 < jeremyrubin> That detecting which RPCs are available requires firing off a batch of RPCs and seeing what error codes come back
12:30 < jeremyrubin> This is... suboptimal
12:30 -!- proofofkeags [~proofofke@71-218-146-180.hlrn.qwest.net] has joined #bitcoin-core-dev
12:30 < MarcoFalke> jeremyrubin: Only with whitelists
12:30 < jeremyrubin> MarcoFalke: no, all the time
12:30 < jeremyrubin> BTCPayServer does this to detect features across versions on startup
12:30 < jnewbery> doesn't the help RPC list all methods?
12:30 < MarcoFalke> Yeah, what jnewbery said ^ 
12:31 < jeremyrubin> But there's also a need to know what semantics/arguments are available and if the semantic has changed at all
12:31 < wumpus> well you only have to do it once
12:31 < MarcoFalke> jeremyrubin: The RPC version number is used for that
12:31 < wumpus> it's only suboptimal if you have to do it all the time, in which case, you're probably doing something wrong
12:31 < MarcoFalke> or you can parse the help
12:32 < wumpus> yes, the RPC version number would be the thing to check for that
12:32 < jeremyrubin> Yeah. I think it's more that we should expose some nicer way of doing this and filtering across the whitelists.
12:32 < sipa> i wouldn't object to an RPC that returns all supported RPCs in JSON form
12:32 < sipa> if that's what we're talking about
12:32 < jnewbery> this seems to be part of integration testing if BTCPayServer or whatever starts using a new version
12:32 < sipa> we already have that information ready anyway
12:33 < jeremyrubin> Also the whitelists are non-interpreted, so they aren't that useful because you then need to replicate the whitelist algorithm locally from it
12:33 < wumpus> would be nice to have a machine-interpratable version of the RPC help in general
12:33 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 240 seconds]
12:33 < jeremyrubin> I think there was also a desire to have per-RPC versioning
12:33 < wumpus> this is an idea that has been around since 2012 or so
12:33 < MarcoFalke> I am working on that
12:33 < MarcoFalke> (the machine readable help)
12:33 < jeremyrubin> Which IDK if it's super useful, but it was requested
12:34 < dongcarl> machine-readable help would just be something like an OpenAPI spec?
12:34 < jeremyrubin> It is nice to know if theres a breaking RPC change that you are aware on startup that there was a change
12:34 < wumpus> per-rpc versioning? oh no, please don't make RPC versioning any more of a hassle as it is already
12:34 < MarcoFalke> wumpus the rpc is versioned on the major version of Bitcoin Core https://github.com/bitcoin/bitcoin/blob/master/doc/JSON-RPC-interface.md 
12:34 -!- proofofkeags [~proofofke@71-218-146-180.hlrn.qwest.net] has quit [Remote host closed the connection]
12:34 < jeremyrubin> don't shoot the messenger. If it's an issue I'd rather just rename RPCs rpc_name_v1 when theres a change
12:35 < wumpus> I don't get it, what does it pprovide on top of the global version number
12:35 -!- proofofkeags [~proofofke@71-218-146-180.hlrn.qwest.net] has joined #bitcoin-core-dev
12:35 < MarcoFalke> oh, it is the same as the global version number
12:35 < wumpus> in general, only major bitcoin core versions introduce breaking RPC changes
12:35 < wumpus> (that's how it's supposed to be, at least, if not, I guess that's a bug in itself)
12:35 < MarcoFalke> dongcarl: It can be anything, even just `help(format="json")` as an RPC
12:36 < jeremyrubin> I think it's that a major version doesn't break *everything*
12:36 < MarcoFalke> wumpus: Correct, that is what the doc says
12:36 < jeremyrubin> So it's if you need to upgrade all your logic or not
12:36 < wumpus> before upgrading to a new major version you need to check the release notes for all the calls you're using in your software
12:36 < jeremyrubin> Well the issue is that's not a developer issue
12:36 < jeremyrubin> that's a userland issue
12:37 < jeremyrubin> unless the user is bundling the node
12:37 < jeremyrubin> *developer 
12:37 < wumpus> same for client software I guess
12:38 < jeremyrubin> Yeah so if a user starts with an older node, BTCPayServer tries to be compatible. And every developer could write their own maps of breaking changes and what works or doesn't 
12:38 < wumpus> what would per-RPC versioning look like in any case? like, instead of calling sendtoaddress, you'd call sendtoaddress/v4 ?
12:38 < jeremyrubin> But i think the request is to handle it inside of core
12:38 < jeremyrubin> Ah, I think it would be in the get_avail_rpcs
12:38 < jeremyrubin> You would get a current version, and a broken at version
12:38 < wumpus> there was an idea like that at one point I guess
12:39 < jeremyrubin> so if you're expecting something v3 compliant, but it tells you broken at v4, then you can alert the user to upgrade
12:39 < wumpus> e.g. have an endpoint /v2  that would expose calls with new arguments
12:39 < jeremyrubin> yeah. I don't have a proposal for this BTW.
12:39 < wumpus> but, to be honest, nothing is that organized, you really need to pay attention to the major bitcoin core release in practice
12:40 < jeremyrubin> That's why I think it makes a good meeting topic as it's something downstream users are complaining about, and would be good to make life easier for them.
12:40 < jeremyrubin> I think a JSON of rpcs and available args would be good. 
12:41 < wumpus> I still don't see how that is better than just looking at the major version. We don't need to expose release notes information on the RPC interface.
12:41 < sipa> i don't think the current_version and broken_at_version idea is crazy
12:41 < jnewbery> I think we've generally been pretty responsible with maintaining RPC compatibility. The deprecatedrpc functionality gives clients plenty of warning when anything important changes.
12:41 < wumpus> yes
12:42 < wumpus> I'm not sure for what RPCs this is a practical problem
12:42 < jeremyrubin> I think the reason for putting thought into it is if we're going to do *some* feature detection, we want it to be sufficiently future proof as then future feature detection would be broken
12:43 < jeremyrubin> if we change the feature detection API
12:43 -!- adamjonas [sid385278@gateway/web/irccloud.com/x-xvaqxaghrqhajtnq] has quit []
12:43 < sipa> having some examples of what RPCs have caused issues in the past would be good to know, indeed
12:43 < dongcarl> Sounds like if this is a downstream complaint we need to look at the specific cases and see what could be done that would solve a majority of them. jeremyrubin Are there links?
12:43 -!- ajonas [sid385278@gateway/web/irccloud.com/x-vhempwuqoncysdxy] has joined #bitcoin-core-dev
12:43 < sipa> perhaps all we need to do is be more careful about breaking compatbility
12:43 < jeremyrubin> https://github.com/bitcoin/bitcoin/issues/12248
12:43 < wumpus> sipa: especially in cases that can pass silently
12:44 < jeremyrubin> https://github.com/bitcoin/bitcoin/pull/19117
12:44 < wumpus> maybe renaming a RPC if its fields change isn't that bad an idea
12:44 < dongcarl> jeremyrubin: Are there links to the downstream convo?
12:44 < wumpus> though in general we've been careful to keep the same patern for arguments, e.g. we *still* have a dummy argument for getbalance
12:45 < jeremyrubin> I think the main thing I broke is batching API when using whitelists. unaware of links for their internal issue on that
12:45 < jeremyrubin> Because if you're using whitelists, the method of feature discovery (calling all required RPCS) fails
12:45 < wumpus> I'm still confused about whitelisting tbh
12:46 < jeremyrubin> Which calling all RPCs to discover the features is... bad. Because RPCs can do things
12:46 < wumpus> I don't think RPC whitelisting should have been something that ended up in bitcoind
12:46 < wumpus> been anyhow
12:47 < wumpus> some very application-specific security requirements are finding their way in
12:47 < jnewbery> all of this stuff seems like it should be the responsibility of a proxy
12:47 < wumpus> and this has nothing to do with differences between versions
12:47 < wumpus> jnewbery: yes
12:47 < jeremyrubin> dongcarl: here's the issue https://github.com/bitcoin/bitcoin/issues/19087
12:47 < MarcoFalke> But then different rpcusers shouldn't be in bitcoind either?
12:48 < jeremyrubin> I do think that we could rip out all authentication for RPCusers
12:48 < MarcoFalke> Just have one authpair and the proxy can deal with users
12:48 < jeremyrubin> It's a lot of complexity and if the answer is to proxy it just make Bitcoind not listen by default & require SSH auth'd proxy to connect
12:49 < wumpus> MarcoFalke: I'm not for reverting it, just, it's not a no-holds-barred pretext to introduce all kinds of per-RPC auth mechanisms into bitcoind
12:49 < yevaud> I think that it gives the wrong message, that unprivileged users are an expected thing. there's already a large number of people running with RPC bound to public interfaces as it is. 
12:50 < wumpus> wait, no, don't bind RPC to public interfaces
12:50 < MarcoFalke> I am not for reverting it either. Just saying that we already have more than the minimal required functionality in core
12:50 < wumpus> this kind of people that want this are enterprises I guess, with *very specific* security and auditing requirements
12:50 < yevaud> by all means it allows you to have granular control of the permissions from your service, but it is easily misinterpreted. 
12:51 < wumpus> exposing things on the public internet is just plain dumb
12:51 < jeremyrubin> i think public probably means internal-public
12:51 < wumpus> the only interface that bitcoind provides that (hopefully) is internet-hardened is P2P
12:51 < wumpus> anyhow, any other topics?
12:51 < jnewbery> It looks to me like 19087 is the result of two features interacting badly (batching and whitelists). Adding more complexity and another feature (versioning) doesn't seem like the correct remedy.
12:52 < jeremyrubin> So the need for versioning exists outside of the conflict there
12:52 < jeremyrubin> The core issue is that people are struggling to do feature detection
12:52 < jeremyrubin> And are calling a list of all RPCs to do that
12:52 < jeremyrubin> So we should have a better paradigm for that
12:52 < wumpus> imo: look at the major version number of bitcoin core
12:52 < MarcoFalke> What about the pull request that returns the RPC methods for the current user?
12:52 < wumpus> if you're not sure, warn the user
12:53 < jeremyrubin> MarcoFalke: it returns the whitelist, not the list of RPC methods
12:53 < wumpus> nothing will be enough to machine-represent the subtleties of differences between versions
12:53 < jeremyrubin> And the whitelist can contain things that aren't currently defined RPCs
12:53 < wumpus> whitelist has nothing to do with this
12:53 < jeremyrubin> Hence the issue being, what people want is a detect-avaialble-features API
12:53 < MarcoFalke> why can't the whitelist be sanitized before returning it?
12:54 < jeremyrubin> Then it's a detect available features API
12:54 < jeremyrubin> Which is what the issue is about; but if we're doing that it makes sense to think it through
12:54 < jeremyrubin> And listen to users on what sort of feature detection things they need/want
12:54 < jeremyrubin> And RPC versioning came up as a request
12:54 < wumpus> jnewbery: it definitely seems like digging in deeper after making a mistake
12:55 < jeremyrubin> I'm OK with just returning a filtered RPC whitelist tho, it would work, but maybe we need a v2 feature detection later which I'd want to avoid
12:55 < wumpus> to be clear I applaud attempts to have machine-readable documentation for RPCs like MarcoFalke is working on
12:55 < jonatack> jeremyrubin: wasn't there a really good external site once that documented all the RPC API versions in detail?
12:56 < wumpus> and if that gives a list of available RPC calls, sure, that could be useful
12:56 < jnewbery> jonatack: bitcoincore.org :)
12:56 < yevaud> https://chainquery.com/bitcoin-cli probably. 
12:56 < jnewbery> https://bitcoincore.org/en/doc/
12:56 -!- rafalcpp [~racalcppp@ip-178-214.ists.pl] has joined #bitcoin-core-dev
12:57 < jeremyrubin> Anyways I agree largely it doesn't belong in core; things like the wallet also probably shouldn't be there
12:57 < wumpus> yes
12:57 < jonatack> yes, and I knew another one that was outstanding, but don't recall what it was
12:57 < wumpus> too much score creep
12:58 < wumpus> scope creep
12:58 < jeremyrubin> But it's just making due with helping users/devs write secure software
12:58 < jeremyrubin> *making do
12:58 < jeremyrubin> If someone has a good proxy implementation that can be put into a sub-process maybe that would help
12:58 < wumpus> I think a layered approach is a better way to make secure software
12:58 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev
13:00 < sipa> *DONG*
13:00 < wumpus> #endmeeting
13:00 < lightningbot> Meeting ended Thu Jun 11 20:00:06 2020 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
13:00 < lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2020/bitcoin-core-dev.2020-06-11-19.00.html
13:00 < lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2020/bitcoin-core-dev.2020-06-11-19.00.txt
13:00 < lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2020/bitcoin-core-dev.2020-06-11-19.00.log.html
13:00 < dongcarl> Perhaps a good topic for some day where there aren't many topics is: what things can we remove from bitcoin-core that would have a net-positive impact?
13:00 < dongcarl> sipa: yes? :P
13:00 < hebasto> jeremyrubin: "I have a couple examples where we over-lock..." mind sharing?\
13:00 < jnewbery> please don't remove sipa
13:01 < wumpus> dongcarl: I'm just trying to prevent adding too many things
13:01 < aj> jnewbery: but sipa's something that has a net-positive impact, so fits dongcarl's requirements
13:01 < jeremyrubin> dongcarl: russ has a great way of doing that but it requires adding something big :p 
13:01 < dongcarl> :brainfried:
13:02 < sipa> *floink*
13:02 < wumpus> we have a kitchen_sink.cpp now, that should be enough, stop adding things please xD
13:02 < sipa> wut?
13:02 < wumpus> ./src/test/fuzz/kitchen_sink.cpp
13:02 < achow101> dongcarl: deep fried brains?
13:02 < jeremyrubin> you've been removed sipa
13:02 < jamesob> > *DONG* 
13:02 < jamesob> didn't know there was a gong in here
13:02 < sipa> hmm does that not need some kind of voting algorithm?
13:02 < jeremyrubin> I like MarcoFalke's suggestion of completely getting rid of credentials in core
13:03 < sipa> "you are the weakest link, bye bye" style
13:03 < dongcarl> jeremyrubin: A proxy could be maintained in a separate repo
13:03 < wumpus> I don't think it's worth getting rid of now
13:03 < jeremyrubin> I think you probably do want it to be... shipped with and started by 'bitcoind' tho
13:04 < MarcoFalke> Make it opt in for now -use_rpcusers_that_is_going_to_be_removed_in_2025=1
13:04 < MarcoFalke> then remove
13:04 < wumpus> checking against 3 credentials instead of 1, is not that much overhead
13:04 < jeremyrubin> I kind of like a model where bitcoind is a compatible set of processes that run
13:04 < sipa> i think getting rid of the auth mechanism is too big a breaking change
13:04 < wumpus> yes
13:04 < yevaud> "a proxy" can just be nginx, except for the rpccookie bit. 
13:04 < jeremyrubin> and bitcoin-node is the just network process
13:04 < jeremyrubin> I think it doesn't have to be breaking at all
13:04 < sipa> yes, dreaming is nice
13:04 < wumpus> you can argue it shouldn't have been introduced in the first place, but it makes no sense to remove it now
13:04 < wumpus> you should be careful what you PR
13:05 < wumpus> and what you merge
13:05 < wumpus> pay attention and review, also conceptually
13:06 < wumpus> and with regard to maintenance burden
13:06 < yevaud> jeremyrubin: it turns out that breaking up bitcoin into different daemons needs a comical amount of state exposed, sadly. 
13:06 < jeremyrubin> I don't think so for RPC credentials
13:06 < jeremyrubin> I think it's relatively small
13:06 < wumpus> I'm trying to be careful but too many people just want to kitchen sink everything
13:07 < jeremyrubin> Is anyone opposed to work that separates out RPC credentials to a different thread, makes sure there's no state leak? Then when Russ pushes through the experimental capnproto stuff it can be forked out?
13:07 < wumpus> it shouldn't be a different thread, no
13:07 < yevaud> capnproto? 
13:07 < sipa> i don't see how any of these things are related
13:08 < wumpus> agree
13:08 < wumpus> it sounds like complicating things even more (at least inthe repository)
13:09 < jeremyrubin> The idea being to make the credentialing system removed from core. Doesn't need to be a thread, just an object that can pass things to core through a proxy-like interface
13:09 < sipa> define "removed from core"
13:09 < sipa> from the codebase?
13:09 < sipa> from the process?
13:09 < sipa> from the interface?
13:09 < wumpus> some people are actually filtering RPC and using some external proxy to filter allowed/disallowed RPC calls
13:09 < wumpus> no changes to bitcoin coren eeded, at all
13:09 < jeremyrubin> Ah
13:09 < jeremyrubin> I'm not just talking about the lists
13:09 < jeremyrubin> I'm talking about the identities as well
13:10 < wumpus> they can do that as well
13:10 < jeremyrubin> Yep
13:10 < wumpus> and logging
13:10 < wumpus> et
13:10 < jeremyrubin> And by removed I mean that it could be a separate binary
13:10 < wumpus> yes, or a script
13:10 < wumpus> there's nothing we need to do for this
13:10 < wumpus> it's socially scalable :)
13:11 < jeremyrubin> wumpus: it's more if you want to 'remove the crap' from Core, you can actually get rid of the code that's there
13:11 < yevaud> the panacea really is getting the wallet and networking into their own daemons, but that's not going to happen any time soon. 
13:11 < wumpus> I'm not trying to remove anything, just to prevent adding it
13:12 < wumpus> once added it's pretty much too late
13:12 -!- Eagle[TM] [~EagleTM@unaffiliated/eagletm] has quit [Ping timeout: 264 seconds]
13:12 < jeremyrubin> Ah ok. So one thing that is in favor of feature discovery in that context
13:12 < jeremyrubin> Is that you can write a generic proxy that learns the features from core and not have to ever touch that program
13:13 < jeremyrubin> So maybe there's some minimal set of features that make writing these proxies a bit better.
13:13 < wumpus> the proxy should already know what is allowd and what not, that shouldn't determine on the target
13:14 < jeremyrubin> Allowed/disallowed differs from exists/doesn't exist and versions
13:14 < jeremyrubin> E.g., if I configure a proxy for v1 to be safe, but v2 adds an argument which is unsafe
13:14 < jeremyrubin> That's a bad situation
13:14 < wumpus> yes before upgrading bitcoin core (definitely the major version) you need to make sure your other software is compatible 
13:15 < jeremyrubin> Yeah i think that's just asking a bit much of the user...
13:15 < jeremyrubin> but I guess they'll lose their funds sooner or later if that's the case so maybe we don't care to help them?
13:15 < wumpus> I don't think any general mechanism can prevent that unless you can describe *every* detail of the RPC interface programatically ,and even then
13:16 < wumpus> wait, I don't think we should do RPC changes that can result in losing funds in the first place?!?
13:16 < wumpus> we've been very careful with this, even getbalance still has a dummy argument
13:16 < jeremyrubin> I think that's inevitable that new flags can do stupid things
13:16 < jeremyrubin> E.g., adding a maxFeeRate flag that previously was set to a fixed constant
13:17 < wumpus> if you see any RPC change that can result in old software suddenly doing destructive things please flag it on review
13:17 < jeremyrubin> Herculean task :p 
13:17 < wumpus> well if it is too much of a task to pay attention to review of things like that
13:18 < wumpus> it's definitely too much to expect people to update some featur detection mechanism
13:18 < jeremyrubin> I mean to say I'm not even aware of all of the downstream software, let alone how it handles these things
13:18 < wumpus> be realistic here
13:19 < jeremyrubin> Well I think it's sort of a case of helping the developers do the right thing.
13:19 < jeremyrubin> I'm growing in fondness for explicit aliases for all rpcs
13:20 < jeremyrubin> I think swift's mangler does something where A(foo: int, bar:String?) becomes A() and A_with_bar()
13:20 < wumpus> you could achieve something like that by forbidding default arguments
13:21 < wumpus> if some new argument is added, it needs to be specified ... then again, that completely breaks backwards compatibility, which is for most people even worse I think
13:21 < jeremyrubin> Well... maybe not?
13:22 < wumpus> there's an implicit expectation already that calling the same RPCs with the same arguments keeps doing the same
13:22 < wumpus> if any arguments are added their default is the same as what was done before
13:22 < wumpus> in any case, it would help if you have specific examples of where this went wrong in the past
13:22 < wumpus> where people lost funds due to RPCs changing
13:23 < jeremyrubin> Not off the top of my head. But I can imagine someone sanitizing a JSON for arguments by checking what's there against the old arguments, but not checking for presence of new ones
13:23 < wumpus> if not, this is kind of an empty discussion, something that is already avoided at all ocsts
13:23 < jeremyrubin> and then an attacker being able to sneak in an argument that changes the behavior.
13:24 < wumpus> where did the attacker come from? this was about accidental version incompatiblities right
13:24 < jeremyrubin> Would be prevented by explicitly destructing/rebuilding the JSON with only the desired args. Don't know how common that is tho
13:24  * wumpus is confused, logging off for now
13:24 < jeremyrubin> Yeah sorry not trying to cause a kerfuffle over it
13:25 < jeremyrubin> I don't know what to tell end-users other than to ship their applications with a specific bitcoind version
13:25 < jeremyrubin> which i think is an OK answerrt
13:26 -!- lightlike [~lightlike@2a02:810d:b80:c2c:9412:1960:46f5:bcb0] has joined #bitcoin-core-dev
13:26 -!- SiAnDoG [~514nDoG@gateway/tor-sasl/siandog] has quit [Quit: SiAnDoG]
13:27 < phantomcircuit> meshcollider, i've been working on the "rescanblockchain" rpc and noticed a few oddities in the wallet logic; for example #19216
13:27 < gribble> https://github.com/bitcoin/bitcoin/issues/19216 | wallet: Remove first parameter to ScanForWalletTransactions start_hash by pstratem · Pull Request #19216 · bitcoin/bitcoin · GitHub
13:28 < sipa> jeremyrubin: i think that wumpus' point is that no matter how well we try to encode compatibilities electronically, things may be too subtle and in the end people/client developers will for production use still need to refer to the release notes 
13:28 < jeremyrubin> sipa: agree 100%.
13:28 < sipa> jeremyrubin: but at the same time, solving compatibility is a much more widely scoped problem than the security side
13:28 < sipa> RPC changes should not impact security
13:28 < phantomcircuit> meshcollider, im going through other parameters looking for oddities as well
13:29 < harding> This is what I tell devs to do if they want to learn all the differences in RPCs between releases: https://github.com/zkSNACKs/WalletWasabi/issues/3037#issuecomment-581143233
13:29 < wumpus> yes, I think that's another reason I'm confused about things like whitelists and credentials, the RPC interface was never supposed to be hardened against attackers like that, it was supposed to be a trusted interface for applications
13:30 < jeremyrubin> sipa: in the example I was giving above I was imagining some frontend app passes a JSON of a desired RPC call. The server checks all the arguments it knows about for that rpc, and sends to the server. But a new RPC was added in the new version of core running. Then the frontend-hacker adds that parameter. And a bad RPC call accidentally gets passed.
13:31 < sipa> jeremyrubin: if the frontend that does the security check is compromised, i don't see how problems can be avoided?
13:31 < jeremyrubin> No the backend server is doing the check
13:31 < sipa> ok, then i don't understand the problem
13:32 < jeremyrubin> Ok. So imagine v1 RPC A has arg 'good'. V2 adds arg 'bad' default = 0
13:32 < MarcoFalke> I plan to write a feature detection in 5 lines of python and add it to the test framework. No changes to core required.
13:32 < sipa> jeremyrubin: that should never happen
13:32 < MarcoFalke> We might be over-engineering this a bit
13:32 < jeremyrubin> sipa: why not? We add default args all the time.
13:33 < sipa> and they shouldn't impact security
13:33 < jeremyrubin> and the 'bad' one by default does nothing
13:33 -!- Pavlenex [~Thunderbi@141.98.103.251] has quit [Quit: Pavlenex]
13:33 < jeremyrubin> But we add ones that could impact security if set to a bad value?
13:33 < wumpus> sipa: exactly, that should already never happen, so there shouldn't be need to describe it
13:33 < jeremyrubin> things like feerates
13:33 < wumpus> which was my point with catching these things at review time
13:34 < sipa> jeremyrubin: i'm still missing part of your context
13:34 < sipa> "the server checks ... and sends to the server"
13:34 < jeremyrubin> Ah yeah I was still explaining but you told me that I was already off
13:34 < sipa> there are multiple servers involved?
13:34 < sipa> ok
13:34 < jeremyrubin> There's a frontend, a backend, and a core node
13:35 < jeremyrubin> (I'll tell you when I'm done)
13:35 < jeremyrubin> Frontend generates and RPC, passes it to the backend. Backend sanitizes, passes to core
13:35 < jeremyrubin> v1: A good. v2: A good, bad=0
13:36 < sipa> sounds like the backends needs to disallow parameters it does not know about
13:36 < jeremyrubin> the backend initially checks that A.good is 0 or 1
13:36 < jeremyrubin> Yes
13:36 < jeremyrubin> My point being that originally Core was doing this check
13:36 < jeremyrubin> And then when the default arg gets introduced core stops doing this
13:36 < wumpus> exactly, the security checking thing should be careful to only pass through what it knows about
13:36 < wumpus> this was always the case
13:36 -!- Kiminuo [~mix@193.9.112.244] has quit [Ping timeout: 264 seconds]
13:36 < jeremyrubin> So when core goes V1 -> V2 there's a potential for a security issue
13:36 < sipa> jeremyrubin: that's why a security-enforcing proxy needs to work with whitelisting
13:37 < sipa> per RPC, per parameter
13:37 < jeremyrubin> I don't think we're disagreeing on any of this
13:37 < sipa> then i don't see the problem
13:38 < jeremyrubin> I'm just saying I don't think it's that common that this happens, and there's an opportunity to introduce some stuff that helps prevent these bugs.
13:38 < jeremyrubin> I don't think it eliminates them
13:38 < jeremyrubin> But I think it could help reasonable app developers not have these sorts of mistake
13:38 < sipa> ok, i agree there - but i don't think it's worth the complexity, especially as it risks giving a false sense of security
13:39 < jeremyrubin> fwiw my proposal is essentially an API where you do feature detect and fail to start if it doesn't match your expected feature set
13:39 < sipa> changes to the RPC interface should be safe in such a way that if an RPC that worked in the past was fine, if it still exists in the new version, is still fine
13:40 < sipa> jeremyrubin: but how do you define feature? is a slightly different way that ping messages are scheduled a feature change? because it may be observable through the minping field
13:41 < sipa> and if feature changes are restricted to things that could have a security impact... the probably just shouldn't happen
13:41 < jeremyrubin> You know it's a good question to ask more of the app developers (e.g., LN btcpay)
13:42 < jeremyrubin> I think it's also an interesting question if there were a change we had to make for security, how would we make sure old software didn't do the broken thing on new nodes (hopefully never happens but you never know)
13:42 < jeremyrubin> Again I don't really have a concrete proposal here
13:42 < sipa> we could rename RPCs if we're somehow forced to change their semantics very substantially
13:42 < jeremyrubin> I just know that calling all the RPCs in a batch to see what's on sounds like a very wrong idea
13:43 < jeremyrubin> And would like to help BTCPayServer not do that
13:43 < sipa> yes, they should check version numbers - i agree
13:43 < sipa> with wumpus 
13:43 < jeremyrubin> Maybe a good one is just an RPC where you submit a list of RPCs an arguments intended to the node
13:43 < sipa> and just fail to start if it's not a known one
13:44 < jeremyrubin> Yeah that could be the answer
13:44 < meshcollider> phantomcircuit: sounds good :)
13:44 < jeremyrubin> I do know that RPC whitelisting did expose this problem by changing what batching returns when something isn't whitelisted in the batch. So I regret that. But seems like there should be a good answer of what BTCPayServer should implement instead of that for detection
13:45 < jeremyrubin> NicolasDorier: ^^^ stop it :)
13:45 < sipa> and we could automate some things, which would mean that generally client versions will break slightly less often when facing an unknown server... but if semantics are super critical, that still risks breaking things, and they still really should just check the version number
13:45 -!- dgenr8 [~dgenr8@unaffiliated/dgenr8] has quit [Quit: Leaving]
13:47 < jeremyrubin> Ah!
13:47 < jeremyrubin> Here's a great reason to do this; makes people more likely to upgrade their supported node version :p 
13:48 -!- dgenr8 [~dgenr8@unaffiliated/dgenr8] has joined #bitcoin-core-dev
13:48 < jeremyrubin> But I'm basically at my depth on this issue; I don't have a current major core-dependent app dealing with compatibility issues so it is really a matter of e.g. roasbeef, NicolasDorier to chime in on it.
13:49 < jeremyrubin> I think in terms of the actual Bug I'm OK with wontfix if you're using batching + whitelist with non whitelisted rpcs
13:50 < sipa> it sounds like the batching/whitelist implementation was just broken?
13:50 < jeremyrubin> Not really?
13:50 < sipa> i'm not familiar with the issue
13:50 < jeremyrubin> So if you call a batch
13:51 < jeremyrubin> and one of the RPCs is not whitelisted
13:51 < jeremyrubin> It will call the prefix
13:51 < jeremyrubin> and then just return the RPC not found for the whole thing
13:51 < jeremyrubin> rather than RPC not found for that specific RPC
13:51 < jeremyrubin> as the batch result
13:51 < jeremyrubin> Was my understanding of the issue
13:51 < sipa> that sounds like a bug?
13:52 < jeremyrubin> https://github.com/bitcoin/bitcoin/issues/19087#issuecomment-636883880
13:53 < jeremyrubin> I mean the bigger picture issue is that this *should* have come up in review and integration testing
13:53 < jeremyrubin> as it seems to break btcpayserver on startup
13:53 < jeremyrubin> And whitelistrpc has been merged for a while 
13:53 < sipa> and it should definitely have come up during rc testing...
13:53 < jeremyrubin> It's not like some corner case issue
13:54 < sipa> but i don't see why we can't just fix this in 0.20.1
13:54 < jeremyrubin> It can be fixed, but permanently 0.20 will be hard to start against for BTCPayServer if using rpcwhitelist
13:54 < sipa> sure, they should have a better way of doing feature detection, but it sounds like this just gratutiously broke compatibility, so we should restore it?
13:55 < sipa> well that's what you have bugfix releases for
13:55 < sipa> bugs happen, and sometimes they're detected too late
13:55 < jeremyrubin> Well it didn't break it thaaat gratuitously. If you don't use RPC Whitelist OR you detect features differently, it would not come up
13:55 < sipa> by gratuitously i don't mean that this was trivial to find; just that it comes at no benefit
13:56 -!- promag [~promag@bl19-22-20.dsl.telepac.pt] has joined #bitcoin-core-dev
13:56 < sipa> as in: i don't expect anyone to (want to) rely on the new behavior
13:56 < jeremyrubin> Ah. Yes. Agree 100%
13:56 < sipa> so we should fix it
13:56 < jeremyrubin> The new behavior is obviously a defect
13:56 < sipa> the feature discovery (or version checking) discussion is orthogonal
13:57 < jeremyrubin> It is, which is what I've been trying to get across
13:57 < jeremyrubin> There's a defect. The reason we found it was doing X. X is shocking. We should fix the defect and provide a better way to X
13:58 < sipa> or tell people that instead of X, they should be doing Y which is already possible instead :)
13:58 < sipa> but we should still fix the defect
13:59 < sipa> is there an issue (or PR) for the fix?
13:59 < jeremyrubin> Sure... which is sort of the question that started this. What is Y? Is just parsing the help page sufficient? Should we JSON expose it? 
13:59 < jeremyrubin> sipa: no, not yet.
13:59 < sipa> Y is checking the version number
14:00 -!- jtk [~jtk@84.39.116.180] has quit []
14:00 < jeremyrubin> I think that it's sort of a 'draw the fucking owl' answer though. So check the version number and hardcode all RPCs and the arguments they can take?
14:00 < wumpus> also, as said, there is work underway in making the help more programatically parsable, so if that's what you want to do it's only going to become easier
14:01 < sipa> jeremyrubin: i mean... what are they doing with the information about which RPCs are available? presumably pretty much something like that already?
14:02 < wumpus> of course it's never going to be a perfect representation fully covering all changes and all subtleties, it's not there to give a false sense of security
14:03 < jeremyrubin> sipa: good question? Not sure. I would imagine some kind of start with assuming a base version with X features and a dispatch table of functionality that implemented inefficiently client side. See what comes back and replace the client versions with RPC versions?
14:04 < sipa> yes
14:04 < jeremyrubin> So the code is never aware of what version at all, just aware of what's allowed and adds the on-node versions as applicable.
14:04 < jeremyrubin> There's no mapping of version 18 has Y and version 19 has Y + Z
14:04 < jeremyrubin> but i'm not sure 
14:04 < jeremyrubin> That's just a guess
14:04 < promag> jnewbery: https://github.com/bitcoin/bitcoin/projects/2 needs minor update
14:04 < sipa> i think we're grasping at straws
14:05 < jeremyrubin> yeah I'll defer to roasbeef and NicolasDorier who probably have the best knowledge on their use case
14:05 < promag> 1. replace #17457 with #18894 (which is already merged) and 2. #15202 is merged too
14:05 < gribble> https://github.com/bitcoin/bitcoin/issues/17457 | gui: Fix manual coin control with multiple wallets loaded by promag · Pull Request #17457 · bitcoin/bitcoin · GitHub
14:05 < 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
14:05 < gribble> https://github.com/bitcoin/bitcoin/issues/15202 | gui: Add Close All Wallets action by promag · Pull Request #15202 · bitcoin/bitcoin · GitHub
14:10 < dongcarl> jonasschnelli: Rebased your 2019/08/net_v2 branch using the commits from the latest PRs here: https://github.com/bitcoin/bitcoin/compare/master...dongcarl:2020-06-netv2-no-simplify, the netv2 test fails due to UB, is this worth pursuing or shall I wait until there's more work on the BIP?
14:11 < jeremyrubin> sipa: wumpus: apologies for the drawn out conversation here. It's not a particularly major thing I'm trying to get in for Core, but I just feel somewhat responsible for having introduced it to advocate for the users even if I don't really know what they want/need on this one.
14:13 -!- Guyver2 [Guyver@guyver2.xs4all.nl] has quit [Quit: Going offline, see ya! (www.adiirc.com)]
14:29 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 246 seconds]
14:32 < jnewbery> promag: done. Thank you for you persistance on multiwallet!
14:36 < promag> jnewbery: https://imgflip.com/i/44tpti
14:42 -!- Dali [708956dd@221.112137086.m-net.ne.jp] has joined #bitcoin-core-dev
14:44 -!- Dali [708956dd@221.112137086.m-net.ne.jp] has left #bitcoin-core-dev []
14:55 -!- rafalcpp [~racalcppp@ip-178-214.ists.pl] has quit [Ping timeout: 246 seconds]
14:56 -!- fredy2 [~fredy@178.162.204.238] has joined #bitcoin-core-dev
15:02 -!- pinheadm_ [~pinheadmz@pool-100-33-69-78.nycmny.fios.verizon.net] has joined #bitcoin-core-dev
15:03 -!- danielyin [~danielyin@204.11.107.220] has left #bitcoin-core-dev []
15:04 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 264 seconds]
15:05 -!- pinheadmz [~pinheadmz@96.47.229.196] has quit [Ping timeout: 264 seconds]
15:07 -!- danielyin [~danielyin@204.11.107.220] has joined #bitcoin-core-dev
15:23 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev
15:33 -!- lightlike [~lightlike@2a02:810d:b80:c2c:9412:1960:46f5:bcb0] has quit [Quit: Leaving]
15:48 -!- rafalcpp [~racalcppp@ip-178-214.ists.pl] has joined #bitcoin-core-dev
15:52 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit []
16:14 -!- sipsorcery [~sipsorcer@37.228.243.107] has quit [Ping timeout: 256 seconds]
16:36 -!- gimballock [b8a4b1b9@d-184-164-177-185.fl.cpe.atlanticbb.net] has quit [Remote host closed the connection]
16:38 -!- proofofkeags [~proofofke@71-218-146-180.hlrn.qwest.net] has quit [Remote host closed the connection]
16:39 -!- proofofkeags [~proofofke@71-218-146-180.hlrn.qwest.net] has joined #bitcoin-core-dev
16:43 -!- proofofkeags [~proofofke@71-218-146-180.hlrn.qwest.net] has quit [Ping timeout: 246 seconds]
16:51 -!- rafalcpp [~racalcppp@ip-178-214.ists.pl] has quit [Ping timeout: 260 seconds]
16:59 -!- pinheadm_ [~pinheadmz@pool-100-33-69-78.nycmny.fios.verizon.net] has quit [Quit: pinheadm_]
17:00 -!- fredy2 [~fredy@178.162.204.238] has quit []
17:00 -!- pinheadmz [~pinheadmz@pool-100-33-69-78.nycmny.fios.verizon.net] has joined #bitcoin-core-dev
17:09 -!- proofofkeags [~proofofke@71-218-146-180.hlrn.qwest.net] has joined #bitcoin-core-dev
17:12 -!- davterra [~dulyNoded@172.83.40.73] has joined #bitcoin-core-dev
17:21 -!- promag [~promag@bl19-22-20.dsl.telepac.pt] has quit [Remote host closed the connection]
17:21 -!- ozbot [~ozbot@178.162.204.238] has joined #bitcoin-core-dev
17:28 -!- belcher [~belcher@unaffiliated/belcher] has quit [Quit: Leaving]
17:52 -!- promag [~promag@bl19-22-20.dsl.telepac.pt] has joined #bitcoin-core-dev
17:53 -!- troygiorshev [~troygiors@CPEdcef09a0ed55-CM0c473d74be00.cpe.net.cable.rogers.com] has quit [Ping timeout: 258 seconds]
17:53 -!- troygiorshev [~troygiors@CPEdcef09a0ed55-CM0c473d74be00.cpe.net.cable.rogers.com] has joined #bitcoin-core-dev
17:56 -!- S3RK [~s3rk@47.246.66.112] has quit [Ping timeout: 246 seconds]
17:57 -!- promag [~promag@bl19-22-20.dsl.telepac.pt] has quit [Ping timeout: 264 seconds]
18:06 -!- harrigan [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has quit [Quit: ZNC 1.7.5 - https://znc.in]
18:06 -!- harrigan [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has joined #bitcoin-core-dev
18:11 -!- drbrule [sid395654@gateway/web/irccloud.com/x-fxllvnqndzobbgts] has quit [Ping timeout: 240 seconds]
18:13 -!- GoldmanSats [uid428607@gateway/web/irccloud.com/x-qbjwffstvckesqgv] has quit [Ping timeout: 256 seconds]
18:13 -!- drbrule [sid395654@gateway/web/irccloud.com/x-rciywqaishtihtqf] has joined #bitcoin-core-dev
18:13 -!- troygiorshev [~troygiors@CPEdcef09a0ed55-CM0c473d74be00.cpe.net.cable.rogers.com] has quit [Ping timeout: 246 seconds]
18:13 -!- nejon [sid38993@gateway/web/irccloud.com/x-mzpnnumrlfzobtbl] has quit [Ping timeout: 246 seconds]
18:14 -!- proofofkeags [~proofofke@71-218-146-180.hlrn.qwest.net] has quit [Remote host closed the connection]
18:14 -!- troygiorshev [~troygiors@CPEdcef09a0ed55-CM0c473d74be00.cpe.net.cable.rogers.com] has joined #bitcoin-core-dev
18:17 -!- drbrule [sid395654@gateway/web/irccloud.com/x-rciywqaishtihtqf] has quit [Max SendQ exceeded]
18:17 -!- fanquake [sid369002@gateway/web/irccloud.com/x-fhmfssifughellja] has quit [Ping timeout: 246 seconds]
18:23 -!- drbrule [sid395654@gateway/web/irccloud.com/x-xufhixvhyoctdbiz] has joined #bitcoin-core-dev
18:23 -!- GoldmanSats [uid428607@gateway/web/irccloud.com/x-hfirlhhvpgeplgtq] has joined #bitcoin-core-dev
18:23 -!- fanquake [sid369002@gateway/web/irccloud.com/x-dpentetezvtqljkq] has joined #bitcoin-core-dev
18:23 -!- nejon [sid38993@gateway/web/irccloud.com/x-wsttkphxwamhdmxr] has joined #bitcoin-core-dev
18:28 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #bitcoin-core-dev
18:31 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
18:31 -!- pretyflaco1 [~k3m@185.213.155.166] has quit [Read error: Connection reset by peer]
18:31 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has joined #bitcoin-core-dev
18:31 -!- S3RK [~s3rk@47.246.66.112] has joined #bitcoin-core-dev
18:40 -!- Relis [~Relis@cpc96290-lewi18-2-0-cust910.2-4.cable.virginm.net] has quit [Quit: This computer has gone to sleep]
18:41 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
18:41 -!- Relis [~Relis@cpc96290-lewi18-2-0-cust910.2-4.cable.virginm.net] has joined #bitcoin-core-dev
18:42 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has joined #bitcoin-core-dev
18:50 -!- Squidicuz [~squid@pool-72-74-34-120.bstnma.fios.verizon.net] has joined #bitcoin-core-dev
18:57 -!- proofofkeags [~proofofke@71-218-146-180.hlrn.qwest.net] has joined #bitcoin-core-dev
19:00 -!- provoostenator [~quassel@provoostenator.sprovoost.nl] has quit [Remote host closed the connection]
19:01 -!- provoostenator [~quassel@provoostenator.sprovoost.nl] has joined #bitcoin-core-dev
19:04 -!- proofofkeags [~proofofke@71-218-146-180.hlrn.qwest.net] has quit [Ping timeout: 260 seconds]
19:26 -!- Relis [~Relis@cpc96290-lewi18-2-0-cust910.2-4.cable.virginm.net] has quit [Quit: This computer has gone to sleep]
19:55 -!- dr-orlovsky [~dr-orlovs@xdsl-188-154-186-21.adslplus.ch] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
19:56 -!- Relis [~Relis@cpc96290-lewi18-2-0-cust910.2-4.cable.virginm.net] has joined #bitcoin-core-dev
19:58 -!- Relis [~Relis@cpc96290-lewi18-2-0-cust910.2-4.cable.virginm.net] has quit [Client Quit]
19:59 -!- Relis [~Relis@cpc96290-lewi18-2-0-cust910.2-4.cable.virginm.net] has joined #bitcoin-core-dev
20:00 -!- ozbot [~ozbot@178.162.204.238] has quit []
20:11 -!- proofofkeags [~proofofke@71-218-146-180.hlrn.qwest.net] has joined #bitcoin-core-dev
20:15 -!- proofofkeags [~proofofke@71-218-146-180.hlrn.qwest.net] has quit [Ping timeout: 256 seconds]
20:22 -!- Relis [~Relis@cpc96290-lewi18-2-0-cust910.2-4.cable.virginm.net] has quit [Quit: This computer has gone to sleep]
20:22 -!- ensky [~ensky@217.146.82.122] has joined #bitcoin-core-dev
20:26 -!- Relis [~Relis@cpc96290-lewi18-2-0-cust910.2-4.cable.virginm.net] has joined #bitcoin-core-dev
20:28 -!- promag [~promag@bl19-22-20.dsl.telepac.pt] has joined #bitcoin-core-dev
20:33 -!- promag [~promag@bl19-22-20.dsl.telepac.pt] has quit [Ping timeout: 264 seconds]
20:36 -!- Relis [~Relis@cpc96290-lewi18-2-0-cust910.2-4.cable.virginm.net] has quit [Quit: This computer has gone to sleep]
20:37 -!- Relis [~Relis@cpc96290-lewi18-2-0-cust910.2-4.cable.virginm.net] has joined #bitcoin-core-dev
20:58 -!- Relis [~Relis@cpc96290-lewi18-2-0-cust910.2-4.cable.virginm.net] has quit [Quit: This computer has gone to sleep]
20:59 -!- troygiorshev [~troygiors@CPEdcef09a0ed55-CM0c473d74be00.cpe.net.cable.rogers.com] has quit [Ping timeout: 256 seconds]
21:00 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
21:01 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has joined #bitcoin-core-dev
21:23 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds]
21:30 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-dev
21:36 -!- shesek [~shesek@unaffiliated/shesek] has quit [Read error: Connection reset by peer]
21:36 -!- shesek [~shesek@185.3.145.28] has joined #bitcoin-core-dev
21:36 -!- shesek [~shesek@185.3.145.28] has quit [Changing host]
21:36 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev
21:50 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net]
21:50 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev
22:00 -!- go121212 [~go1111111@104.156.98.86] has joined #bitcoin-core-dev
22:03 -!- go11111111111 [go1111111@gateway/vpn/privateinternetaccess/go1111111] has quit [Ping timeout: 265 seconds]
22:28 -!- baldur [~baldur@pool-173-56-240-14.nycmny.fios.verizon.net] has quit [Ping timeout: 240 seconds]
22:31 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
22:31 < bitcoin-git> [bitcoin] fanquake opened pull request #19256: refactor: fix Boost signals2 -Wmaybe-uninitialized warning (master...boost_optional_last_value) https://github.com/bitcoin/bitcoin/pull/19256
22:31 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
22:34 -!- sipsorcery [~sipsorcer@37.228.243.107] has joined #bitcoin-core-dev
22:41 -!- baldur [~baldur@pool-173-56-240-14.nycmny.fios.verizon.net] has joined #bitcoin-core-dev
23:00 -!- ensky [~ensky@217.146.82.122] has quit []
23:00 -!- S3RK [~s3rk@47.246.66.112] has quit [Remote host closed the connection]
23:02 -!- promag [~promag@bl19-22-20.dsl.telepac.pt] has joined #bitcoin-core-dev
23:02 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 260 seconds]
23:06 -!- promag [~promag@bl19-22-20.dsl.telepac.pt] has quit [Ping timeout: 256 seconds]
23:12 -!- yancy [~root@2400:8902::f03c:92ff:fe70:a5ac] has quit [Quit: WeeChat 2.3]
23:21 -!- dviola [~diego@unaffiliated/dviola] has quit [Quit: WeeChat 2.8]
23:22 -!- pcmanus [~pcmanus@217.146.82.122] has joined #bitcoin-core-dev
23:24 -!- shesek [~shesek@185.3.145.28] has joined #bitcoin-core-dev
23:24 -!- shesek [~shesek@185.3.145.28] has quit [Changing host]
23:24 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev
23:37 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has joined #bitcoin-core-dev
23:43 < jonasschnelli> dongcarl: I think its good to wait for now with further implementations. The main reason is the v2 upgrade functionality with downgrade-attack prevention
--- Log closed Fri Jun 12 00:00:47 2020