--- Log opened Thu Apr 16 00:00:53 2020
--- Day changed Thu Apr 16 2020
00:00 -!- promag [~promag@bl19-22-20.dsl.telepac.pt] has joined #bitcoin-core-dev
00:10 -!- captjakk [~captjakk@174-29-9-247.hlrn.qwest.net] has joined #bitcoin-core-dev
00:15 -!- captjakk [~captjakk@174-29-9-247.hlrn.qwest.net] has quit [Ping timeout: 265 seconds]
00:21 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
00:44 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds]
00:46 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-dev
00:46 < ryanofsky> meshcollider: i think both prs should be dropped, but first pr is basically harmless, only second pr has bad side effects
00:56 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
00:56 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
01:04 -!- promag [~promag@bl19-22-20.dsl.telepac.pt] has quit [Ping timeout: 256 seconds]
01:07 -!- brakmic [~brakmic@ip-176-198-41-116.hsi05.unitymediagroup.de] has joined #bitcoin-core-dev
01:11 -!- brakmic [~brakmic@ip-176-198-41-116.hsi05.unitymediagroup.de] has quit [Remote host closed the connection]
01:12 -!- brakmic [~brakmic@ip-176-198-41-116.hsi05.unitymediagroup.de] has joined #bitcoin-core-dev
01:14 -!- brakmic_ [~brakmic@141.98.102.156] has joined #bitcoin-core-dev
01:17 -!- brakmic [~brakmic@ip-176-198-41-116.hsi05.unitymediagroup.de] has quit [Ping timeout: 256 seconds]
01:20 -!- marcoagner [~user@2001:8a0:6a5f:a900:6d3e:1158:b50:97b6] has joined #bitcoin-core-dev
01:28 -!- Kiminuo [~mix@141.98.103.118] has quit [Ping timeout: 256 seconds]
01:37 -!- emilengler [~emilengle@stratum0/entity/emilengler] has joined #bitcoin-core-dev
01:43 -!- promag [~promag@bl19-22-20.dsl.telepac.pt] has joined #bitcoin-core-dev
01:43 -!- promag_ [~promag@bl19-22-20.dsl.telepac.pt] has joined #bitcoin-core-dev
02:00 -!- Guest89944 [~nighmi@139.28.218.198] has quit []
02:00 -!- Eagle[TM] [~EagleTM@unaffiliated/eagletm] has quit [Ping timeout: 250 seconds]
02:07 -!- jonatack [~jon@213.152.162.69] has quit [Ping timeout: 258 seconds]
02:09 -!- jonatack [~jon@37.166.74.11] has joined #bitcoin-core-dev
02:11 -!- captjakk [~captjakk@174-29-9-247.hlrn.qwest.net] has joined #bitcoin-core-dev
02:16 -!- captjakk [~captjakk@174-29-9-247.hlrn.qwest.net] has quit [Ping timeout: 256 seconds]
02:22 -!- Mikaku1 [~Mikaku@217.146.82.122] has joined #bitcoin-core-dev
02:26 -!- timothy [~tredaelli@redhat/timothy] has joined #bitcoin-core-dev
02:34 -!- murray_ [~murray@static.56.37.130.94.clients.your-server.de] has joined #bitcoin-core-dev
02:34 -!- murrayn [~murray@unaffiliated/murrayn] has quit [Read error: Connection reset by peer]
02:34 -!- murray_ [~murray@static.56.37.130.94.clients.your-server.de] has left #bitcoin-core-dev []
02:35 -!- murrayn [~murray@unaffiliated/murrayn] has joined #bitcoin-core-dev
02:44 < wumpus> meshcollider: the logic is like: *IF* we need a rc2, might as well include them, I think
02:44 < wumpus> I don't think they necessiate a rc2 by themselves
02:45 < wumpus> but generally for major releases we have around 4-5 rcs so ok
02:45 -!- brakmic_ [~brakmic@141.98.102.156] has quit []
02:45 -!- brakmic [~brakmic@141.98.102.156] has joined #bitcoin-core-dev
02:46 < wumpus> but we could remove the milestone from it if people prefer that (especially if they have bad side effects), or generally if they don't get enough ACKs
02:54 -!- jonatack [~jon@37.166.74.11] has quit [Ping timeout: 264 seconds]
02:55 -!- jonatack [~jon@213.152.161.85] has joined #bitcoin-core-dev
02:55 -!- jonatack [~jon@213.152.161.85] has quit [Client Quit]
02:55 -!- jonatack [~jon@213.152.161.85] has joined #bitcoin-core-dev
02:59 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 246 seconds]
03:04 -!- Celine59Mann [~Celine59M@ns334669.ip-5-196-64.eu] has joined #bitcoin-core-dev
03:09 -!- promag__ [~promag@bl19-22-20.dsl.telepac.pt] has joined #bitcoin-core-dev
03:09 -!- promag_ [~promag@bl19-22-20.dsl.telepac.pt] has quit [Read error: Connection reset by peer]
03:11 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds]
03:16 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-dev
03:17 -!- pinheadmz_ [~matthewzi@pool-100-33-69-78.nycmny.fios.verizon.net] has joined #bitcoin-core-dev
03:18 < meshcollider> I don't think they've even got the milestone, it was just mentioned in the OP
03:19 < meshcollider> First PR is harmless but also pointless 
03:20 -!- pinheadmz [~matthewzi@pool-100-33-69-78.nycmny.fios.verizon.net] has quit [Ping timeout: 240 seconds]
03:20 -!- pinheadmz_ is now known as pinheadmz
03:23 < jonatack> meshcollider: fwiw #17824 has acks by kallewoof and myself and review by instagibbs and achow101
03:23 < gribble> https://github.com/bitcoin/bitcoin/issues/17824 | wallet: Prefer full destination groups in coin selection by fjahr · Pull Request #17824 · bitcoin/bitcoin · GitHub
03:23 < jonatack> it's a bugfix for #17603
03:23 < gribble> https://github.com/bitcoin/bitcoin/issues/17603 | partial spend avoidance makes partial spends and getbalances doesnt notice · Issue #17603 · bitcoin/bitcoin · GitHub
03:25 -!- Celine59Mann [~Celine59M@ns334669.ip-5-196-64.eu] has quit [Ping timeout: 250 seconds]
03:26 < meshcollider> jonatack: cool thanks, I'll look at it first thing tomorrow morning, it's getting late here :)
03:27 < jonatack> meshcollider: 👍
03:29 < meshcollider> ryanofsky: After reading through your comments, I agree with you, I'll close both the PRs
03:29 < meshcollider> If Luke has a strong argument that we are missing, we can discuss in the meeting tomorrow
03:31 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
03:31 < bitcoin-git> [bitcoin] meshcollider closed pull request #18550: Store destdata for change in separate key for backward compatibility (master...changedata) https://github.com/bitcoin/bitcoin/pull/18550
03:31 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
03:32 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
03:32 < bitcoin-git> [bitcoin] meshcollider closed pull request #18572: Wallet: Accept "changedata" db key as an alias to "destdata" (master...changedata_forwardcompat) https://github.com/bitcoin/bitcoin/pull/18572
03:32 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
03:34 < jonatack> Next wallet meeting is April 24 (in 8 days) if not mistaken
03:35 < jonatack> (we did one last week)
03:36 < aj> on this side of the world, regular meeting is tomorrow
03:47 < fanquake> aj: tossing a coin on attendance
03:57 < meshcollider> Yeah sorry I mean the regular meeting which is "today"
04:13 -!- IGHOR [~quassel@93.178.216.72] has quit [Ping timeout: 240 seconds]
04:26 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
04:28 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has joined #bitcoin-core-dev
04:28 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
04:28 < bitcoin-git> [bitcoin] jonatack opened pull request #18664: fuzz: fix unused variable compiler warning (master...fix-unused-variable-warning) https://github.com/bitcoin/bitcoin/pull/18664
04:28 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
04:29 -!- timothy [~tredaelli@redhat/timothy] has quit [Remote host closed the connection]
04:35 -!- amsudeep [~sudeep@1.39.173.89] has quit [Quit: Konversation terminated!]
04:35 -!- amsudeep [~sudeep@1.39.173.89] has joined #bitcoin-core-dev
04:42 -!- mytwocentimes [~mytwocent@178.197.227.159] has quit [Remote host closed the connection]
04:42 -!- mytwocentimes [~mytwocent@104.140.54.51] has joined #bitcoin-core-dev
04:43 -!- jonatack [~jon@213.152.161.85] has quit [Quit: jonatack]
04:47 -!- captjakk [~captjakk@174-29-9-247.hlrn.qwest.net] has joined #bitcoin-core-dev
04:47 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
04:51 -!- mol_ [~molly@unaffiliated/molly] has quit [Ping timeout: 260 seconds]
04:52 -!- captjakk [~captjakk@174-29-9-247.hlrn.qwest.net] has quit [Ping timeout: 265 seconds]
04:55 -!- Kiminuo [~mix@141.98.103.150] has joined #bitcoin-core-dev
04:56 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined #bitcoin-core-dev
04:58 -!- mol [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
05:00 -!- Mikaku1 [~Mikaku@217.146.82.122] has quit []
05:22 -!- Dantman [~Dantman@139.28.218.198] has joined #bitcoin-core-dev
05:31 -!- Highway61 [~Thunderbi@104.129.24.138] has joined #bitcoin-core-dev
05:33 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
05:33 < bitcoin-git> [bitcoin] hebasto opened pull request #18665: Do not expose -logthreadnames when it does not work (master...200416-logthreads) https://github.com/bitcoin/bitcoin/pull/18665
05:33 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
05:33 -!- mytwocentimes [~mytwocent@104.140.54.51] has quit [Remote host closed the connection]
05:34 -!- mytwocentimes [~mytwocent@104.140.54.51] has joined #bitcoin-core-dev
05:44 -!- fengling [~qinfengli@45.32.53.207] has quit [Quit: WeeChat 1.4]
05:54 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
05:54 < bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/544709763e1f...e16718a8b3db
05:54 < bitcoin-git> bitcoin/master f63dec1 Pieter Wuille: [REFACTOR] Initialize PrecomputedTransactionData in CheckInputScripts
05:54 < bitcoin-git> bitcoin/master e16718a MarcoFalke: Merge #18401: Refactor: Initialize PrecomputedTransactionData in CheckInpu...
05:54 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
05:54 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
05:54 < bitcoin-git> [bitcoin] MarcoFalke merged pull request #18401: Refactor: Initialize PrecomputedTransactionData in CheckInputScripts (master...2020-03-precomputedtransactiondata) https://github.com/bitcoin/bitcoin/pull/18401
05:54 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
06:30 -!- timothy [~tredaelli@redhat/timothy] has joined #bitcoin-core-dev
06:48 -!- captjakk [~captjakk@174-29-9-247.hlrn.qwest.net] has joined #bitcoin-core-dev
06:52 -!- captjakk [~captjakk@174-29-9-247.hlrn.qwest.net] has quit [Ping timeout: 256 seconds]
07:01 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
07:01 < bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/e16718a8b3db...79b0459648e3
07:01 < bitcoin-git> bitcoin/master a95af77 practicalswift: qt: Make bitcoin.ico non-executable
07:01 < bitcoin-git> bitcoin/master 79b0459 MarcoFalke: Merge #18650: qt: Make bitcoin.ico non-executable
07:01 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
07:01 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
07:01 < bitcoin-git> [bitcoin] MarcoFalke merged pull request #18650: qt: Make bitcoin.ico non-executable (master...bitcoin.ico-executable-flag) https://github.com/bitcoin/bitcoin/pull/18650
07:01 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
07:08 -!- IGHOR [~quassel@93.178.216.72] has joined #bitcoin-core-dev
07:11 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
07:11 < bitcoin-git> [bitcoin] hebasto opened pull request #18667: ci: Limit cache size regardless of NO_DEPENDS (master...200416-ci-cache) https://github.com/bitcoin/bitcoin/pull/18667
07:11 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
07:11 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has quit [Remote host closed the connection]
07:12 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has joined #bitcoin-core-dev
07:13 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
07:13 < bitcoin-git> [bitcoin] MarcoFalke pushed 5 commits to master: https://github.com/bitcoin/bitcoin/compare/79b0459648e3...661e8df1b63b
07:13 < bitcoin-git> bitcoin/master 727b67e Jon Atack: test: add coverage for bitcoin-cli -rpcwait
07:13 < bitcoin-git> bitcoin/master becc8b9 Jon Atack: test: verify bitcoin-cli -version with node stopped
07:13 < bitcoin-git> bitcoin/master bb13f46 Jon Atack: test: verify cli.getwalletinfo in wallet section
07:13 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
07:13 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
07:13 < bitcoin-git> [bitcoin] MarcoFalke merged pull request #18653:  test: add coverage for bitcoin-cli -rpcwait (master...rpcwait-test-coverage) https://github.com/bitcoin/bitcoin/pull/18653
07:13 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
07:14 -!- fibo [500566ca@202.102-5-80.static.virginmediabusiness.co.uk] has joined #bitcoin-core-dev
07:14 -!- fibo [500566ca@202.102-5-80.static.virginmediabusiness.co.uk] has quit [Remote host closed the connection]
07:15 -!- fizo [500566ca@202.102-5-80.static.virginmediabusiness.co.uk] has joined #bitcoin-core-dev
07:28 -!- fizo [500566ca@202.102-5-80.static.virginmediabusiness.co.uk] has quit [Remote host closed the connection]
07:39 -!- theStack [~honeybadg@vps1648322.vs.webtropia-customer.com] has joined #bitcoin-core-dev
07:40 -!- dviola [~diego@unaffiliated/dviola] has quit [Quit: WeeChat 2.8]
07:56 -!- Talkless [~Talkless@hst-227-49.splius.lt] has joined #bitcoin-core-dev
08:00 -!- Dantman [~Dantman@139.28.218.198] has quit []
08:02 -!- TheRec_ [~toto@drupal.org/user/146860/view] has quit [Ping timeout: 265 seconds]
08:08 -!- per is now known as wsm
08:14 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
08:14 < bitcoin-git> [bitcoin] MarcoFalke opened pull request #18669: log: Use Join() helper when listing log categories (master...2004-logJoin) https://github.com/bitcoin/bitcoin/pull/18669
08:14 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
08:15 -!- captjakk [~captjakk@174-29-9-247.hlrn.qwest.net] has joined #bitcoin-core-dev
08:20 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
08:20 < bitcoin-git> [bitcoin] theStack opened pull request #18670: refactor: Remove unused method CBloomFilter::reset() (master...20200416-refactor-remove-unused-bloom-filter-reset) https://github.com/bitcoin/bitcoin/pull/18670
08:20 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
08:20 -!- kik1 [~kik1@195.206.183.79] has joined #bitcoin-core-dev
08:30 < theStack> i have a linking problem on the fuzz test http_request:
08:30 < theStack> /home/honeybadger/buidl/bitcoin_fuzz/src/test/fuzz/http_request.cpp:34: undefined reference to `evhttp_parse_firstline_'
08:31 < theStack> i found out though that i have libevent version 2.0.21, but the minimum required version is 2.0.22 (according to doc/dependencies.md)
08:31 < theStack> shouldn't the build process check for all minimum required versions?
08:32 < theStack> (without fuzzing enabled, everything compiles fine on master branch)
08:33 -!- jarthur [~jarthur@2605:6000:1019:4971:e543:bf2b:9e11:b562] has joined #bitcoin-core-dev
08:43 -!- unruly247 [~unruly247@104.194.248.178] has quit [Remote host closed the connection]
08:44 -!- unruly247 [~unruly247@104.194.248.178] has joined #bitcoin-core-dev
08:45 -!- unruly247 [~unruly247@104.194.248.178] has quit [Remote host closed the connection]
08:46 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
08:46 < bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/661e8df1b63b...f4c0ad4aefe0
08:46 < bitcoin-git> bitcoin/master 9986608 Russell Yanofsky: test: Verify findCommonAncestor always initializes outputs
08:46 < bitcoin-git> bitcoin/master f4c0ad4 MarcoFalke: Merge #18660: test: Verify findCommonAncestor always initializes outputs
08:46 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
08:46 -!- unruly247 [~unruly247@104.194.248.178] has joined #bitcoin-core-dev
08:46 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
08:46 < bitcoin-git> [bitcoin] MarcoFalke merged pull request #18660: test: Verify findCommonAncestor always initializes outputs (master...pr/commoninit) https://github.com/bitcoin/bitcoin/pull/18660
08:46 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
08:46 -!- unruly247 [~unruly247@104.194.248.178] has quit [Remote host closed the connection]
08:49 -!- unruly247 [~unruly247@104.194.248.178] has joined #bitcoin-core-dev
08:52 -!- TheRec [~toto@84-75-225-47.dclient.hispeed.ch] has joined #bitcoin-core-dev
08:52 -!- TheRec [~toto@84-75-225-47.dclient.hispeed.ch] has quit [Changing host]
08:52 -!- TheRec [~toto@drupal.org/user/146860/view] has joined #bitcoin-core-dev
08:54 -!- andrewtoth [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection]
08:54 -!- andrewtoth [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-dev
08:56 -!- captjakk [~captjakk@174-29-9-247.hlrn.qwest.net] has quit [Remote host closed the connection]
08:57 -!- captjakk [~captjakk@174-29-9-247.hlrn.qwest.net] has joined #bitcoin-core-dev
09:01 -!- Emcy [~Emcy@unaffiliated/emcy] has quit [Remote host closed the connection]
09:01 -!- Emcy [~Emcy@unaffiliated/emcy] has joined #bitcoin-core-dev
09:03 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
09:03 < bitcoin-git> [bitcoin] MarcoFalke opened pull request #18671: wallet: Add BlockUntilSyncedToCurrentChain to dumpwallet (master...2004-walletDumpChain) https://github.com/bitcoin/bitcoin/pull/18671
09:03 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
09:26 -!- Emcy [~Emcy@unaffiliated/emcy] has quit [Remote host closed the connection]
09:27 -!- Emcy [~Emcy@unaffiliated/emcy] has joined #bitcoin-core-dev
09:29 -!- mol_ [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
09:31 -!- Emcy [~Emcy@unaffiliated/emcy] has quit [Remote host closed the connection]
09:32 -!- Emcy [~Emcy@unaffiliated/emcy] has joined #bitcoin-core-dev
09:33 -!- mol [~molly@unaffiliated/molly] has quit [Ping timeout: 256 seconds]
09:36 -!- alko89 [~alko@cpe-85-10-28-138.static.amis.net] has joined #bitcoin-core-dev
09:38 -!- emilengler [~emilengle@stratum0/entity/emilengler] has quit [Quit: Leaving]
09:41 -!- jarthur [~jarthur@2605:6000:1019:4971:e543:bf2b:9e11:b562] has quit [Remote host closed the connection]
09:41 -!- jarthur [~jarthur@2605:6000:1019:4971:b51c:6afa:6ad5:df5b] has joined #bitcoin-core-dev
09:42 -!- andrewtoth [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection]
09:43 -!- andrewtoth [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-dev
09:43 -!- emilengler [~emilengle@stratum0/entity/emilengler] has joined #bitcoin-core-dev
09:54 -!- captjakk [~captjakk@174-29-9-247.hlrn.qwest.net] has quit [Remote host closed the connection]
09:55 -!- captjakk [~captjakk@174-29-9-247.hlrn.qwest.net] has joined #bitcoin-core-dev
09:58 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
09:58 < bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/f4c0ad4aefe0...d8dfcea5d956
09:58 < bitcoin-git> bitcoin/master bee88b8 James O'Beirne: tests: have coins simulation test also use CCoinsViewDB
09:58 < bitcoin-git> bitcoin/master d8dfcea MarcoFalke: Merge #17669: tests: have coins simulation test also use CCoinsViewDB
09:58 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
09:59 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
09:59 < bitcoin-git> [bitcoin] MarcoFalke merged pull request #17669: tests: have coins simulation test also use CCoinsViewDB (master...2019-12-coins-tests) https://github.com/bitcoin/bitcoin/pull/17669
09:59 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
10:00 -!- captjakk [~captjakk@174-29-9-247.hlrn.qwest.net] has quit [Ping timeout: 260 seconds]
10:07 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
10:07 < bitcoin-git> [bitcoin] theStack opened pull request #18672: test: add further BIP37 size limit checks to p2p_filter.py (master...20200416-test-add-further-bloom-filter-size-limit-checks) https://github.com/bitcoin/bitcoin/pull/18672
10:07 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
10:09 -!- molz_ [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
10:12 -!- mol_ [~molly@unaffiliated/molly] has quit [Ping timeout: 256 seconds]
10:13 -!- mol [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
10:15 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
10:15 < bitcoin-git> [bitcoin] MarcoFalke opened pull request #18673: scripted-diff: Sort test includes (master...2004-testSortIncludes) https://github.com/bitcoin/bitcoin/pull/18673
10:15 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
10:16 -!- molz_ [~molly@unaffiliated/molly] has quit [Ping timeout: 256 seconds]
10:36 -!- Kiminuo [~mix@141.98.103.150] has quit [Read error: Connection reset by peer]
10:36 -!- Kiminuo [~mix@141.98.103.150] has joined #bitcoin-core-dev
10:37 -!- mytwocentimes [~mytwocent@104.140.54.51] has quit [Remote host closed the connection]
10:39 -!- mytwocentimes [~mytwocent@104.140.54.51] has joined #bitcoin-core-dev
10:46 -!- captjakk [~captjakk@174-29-9-247.hlrn.qwest.net] has joined #bitcoin-core-dev
10:48 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev
10:54 < MarcoFalke> theStack: Maybe file an issue?
11:00 -!- kik1 [~kik1@195.206.183.79] has quit []
11:05 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-dev
11:06 -!- andrewtoth [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Ping timeout: 240 seconds]
11:08 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev
11:11 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Ping timeout: 240 seconds]
11:14 -!- berndj [~berndj@azna.co.za] has quit [Quit: ZNC - http://znc.in]
11:15 -!- captjakk [~captjakk@174-29-9-247.hlrn.qwest.net] has quit [Remote host closed the connection]
11:16 -!- captjakk [~captjakk@174-29-9-247.hlrn.qwest.net] has joined #bitcoin-core-dev
11:16 -!- mytwocentimes [~mytwocent@104.140.54.51] has quit [Remote host closed the connection]
11:16 -!- mytwocentimes [~mytwocent@104.140.54.51] has joined #bitcoin-core-dev
11:21 -!- captjakk_ [~captjakk@174-29-9-247.hlrn.qwest.net] has joined #bitcoin-core-dev
11:22 -!- mikeyman77 [~mikeyman7@89.40.181.148] has joined #bitcoin-core-dev
11:22 -!- captjakk_ [~captjakk@174-29-9-247.hlrn.qwest.net] has quit [Remote host closed the connection]
11:23 -!- captjakk_ [~captjakk@174-29-9-247.hlrn.qwest.net] has joined #bitcoin-core-dev
11:23 -!- captjakk_ [~captjakk@174-29-9-247.hlrn.qwest.net] has quit [Remote host closed the connection]
11:24 -!- captjakk_ [~captjakk@174-29-9-247.hlrn.qwest.net] has joined #bitcoin-core-dev
11:25 -!- berndj [~berndj@azna.co.za] has joined #bitcoin-core-dev
11:26 -!- captjakk [~captjakk@174-29-9-247.hlrn.qwest.net] has quit [Ping timeout: 264 seconds]
11:28 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
11:30 -!- mol [~molly@unaffiliated/molly] has quit [Ping timeout: 256 seconds]
11:30 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has joined #bitcoin-core-dev
11:32 -!- amsudeep [~sudeep@1.39.173.89] has quit [Read error: Connection reset by peer]
11:33 < wumpus> checking the minimum libevent version in configure would make sense
11:34 < wumpus> the build system has historically not checked minimum versions at all as far as I know, but it'd be a good thing to do, bigger chance that someone will figure out what is the problem in that way than having to check a separate documentation file
11:35 < wumpus> libevent 2.0.21 is *ancient* though
11:35 < wumpus> 8 years old now
11:35 -!- berndj [~berndj@azna.co.za] has quit [Quit: ZNC - http://znc.in]
11:36 < wumpus> things move on and we can't support old software forever, that's just not realistic
11:37 < luke-jr> the old version isn't what matters for such questions IMO
11:37 < luke-jr> but rather, how old/widespread is the new minimum?
11:37 -!- mol [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
11:38 < wumpus> there is no new minimum
11:39 < wumpus> this is about enforcing the current minimum in configure.ac
11:39 -!- berndj [~berndj@azna.co.za] has joined #bitcoin-core-dev
11:40 -!- brakmic [~brakmic@141.98.102.156] has quit [Ping timeout: 240 seconds]
11:41 < wumpus> which has been 2.0.22 pretty much forever
11:41 < luke-jr> afaik that's pretty easy
11:41 < MarcoFalke> I don't understand how Bitcoin Core compiles fine, but the fuzz tests don't
11:41 -!- kvaciral [~kvaciral@185.198.57.211] has joined #bitcoin-core-dev
11:43 < wumpus> I don't, either, but please just use a newer libevent version, many bugs have been fixed since
11:55 -!- captjakk_ [~captjakk@174-29-9-247.hlrn.qwest.net] has quit [Remote host closed the connection]
11:55 -!- captjakk [~captjakk@174-29-9-247.hlrn.qwest.net] has joined #bitcoin-core-dev
12:00 -!- captjakk [~captjakk@174-29-9-247.hlrn.qwest.net] has quit [Ping timeout: 250 seconds]
12:00 < MarcoFalke> Yeah, fuzzing old libevent isn't that helpful
12:01 < meshcollider> Meeting?
12:02 < luke-jr> (let's get to the wallet issue this time)
12:03 < achow101> meeting?
12:03 < wumpus> #startmeeting
12:03 < lightningbot> Meeting started Thu Apr 16 19:03:58 2020 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
12:03 < lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
12:03 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Quit: jb55]
12:04 < jonasschnelli> hi
12:04 < sipa> hi
12:04 < achow101> hi
12:04 < amiti> hi
12:04 < meshcollider> hi
12:04 < jonatack> hi
12:04 < cfields> hi
12:04 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined #bitcoin-core-dev
12:04 < kanzure> hi
12:04 < 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:04 < wumpus> jeremyrubin lightlike emilengler jonatack hebasto jb55
12:04 < dongcarl> hi
12:04 < elichai2> Hi
12:04 < jb55> hi
12:05 < wumpus> one proposed topic: experimental libmultiprocess, next steps for multiprocess in general (MarcoFalke)
12:05 < MarcoFalke> hi
12:05 < luke-jr> wumpus: I proposed one last week.. which really should get addressed before 0.20
12:05 < phantomcircuit> hi
12:05 < jkczyz> hi
12:05 < fjahr> hi
12:05 < cfields> I know fanquake really wants to be part of the multiprocess conversation but he can't make the meeting today.
12:05 < hebasto> hi
12:06 < cfields> maybe we can introduce the issue here and pick it up on the PR?
12:07 < wumpus> luke-jr: can you be more specific? the last topic suggestion from you that I see is the PPA URL and we've spent half a meeting on that
12:07 < wumpus> #topic High priority for review
12:07 < luke-jr> wumpus: right now, the wallet implementation is still broken, and if we don't address it before 0.20, it complicates backward compatibility
12:08 < sipa> can i haz #185512
12:08 < gribble> https://github.com/bitcoin/bitcoin/issues/185512 | HTTP Error 404: Not Found
12:08 < jonasschnelli> may I add #18242 to the hp list?
12:08 < sipa> can i haz #18512
12:08 < midnight> hi!
12:08 < gribble> https://github.com/bitcoin/bitcoin/issues/18242 | Add BIP324 encrypted p2p transport de-/serializer (only used in tests) by jonasschnelli · Pull Request #18242 · bitcoin/bitcoin · GitHub
12:08 < gribble> https://github.com/bitcoin/bitcoin/issues/18512 | Improve asmap checks and add sanity check by sipa · Pull Request #18512 · bitcoin/bitcoin · GitHub
12:08 < luke-jr> re #18192, #18550, #18572, and #18608
12:08 < gribble> https://github.com/bitcoin/bitcoin/issues/18192 | Bugfix: Wallet: Safely deal with change in the address book by luke-jr · Pull Request #18192 · bitcoin/bitcoin · GitHub
12:08 < gribble> https://github.com/bitcoin/bitcoin/issues/18550 | Store destdata for change in separate key for backward compatibility by luke-jr · Pull Request #18550 · bitcoin/bitcoin · GitHub
12:08 < gribble> https://github.com/bitcoin/bitcoin/issues/18572 | Wallet: Accept "changedata" db key as an alias to "destdata" by luke-jr · Pull Request #18572 · bitcoin/bitcoin · GitHub
12:08 < gribble> https://github.com/bitcoin/bitcoin/issues/18608 | refactor: Remove CAddressBookData::destdata by ryanofsky · Pull Request #18608 · bitcoin/bitcoin · GitHub
12:08 < wumpus> uhmm slow down a bit please
12:08 < jonasschnelli> ;-)
12:09 < luke-jr> (my list is not for high-prio-for-review topic)
12:10 < achow101> #18598 for 0.20 tag and backport (or merge now)
12:10 < gribble> https://github.com/bitcoin/bitcoin/issues/18598 | gitian: Add missing automake package to gitian-win-signer.yml by achow101 · Pull Request #18598 · bitcoin/bitcoin · GitHub
12:10 < wumpus> jonasschnelli: sipa  added
12:11 < jonasschnelli> thanks
12:11 < MarcoFalke> achow101: Assigned milestone. I think this will be dealt with in rc2
12:12 < wumpus> yes, if it's required for windows signing on some environments it definitely needs to go into the next rc
12:12 < wumpus> I didn't need it for LXC fwiw
12:12 < jonasschnelli> me2
12:12 < MarcoFalke> happens only on docker/podman
12:12 < hebasto> yes, lxc does need it
12:12 < achow101> yeah, seems to be a virutaliation specific issue
12:13 < achow101> just wanted to make sure no one forgot about it
12:13 < hebasto> achow101: mind specify it in pr description?
12:13 < wumpus> yes, good point
12:13 < jonatack> i think i ran into it when win gitian signing with docker
12:14 < achow101> hebasto: done
12:14 < wumpus> makes sense
12:15 < wumpus> luke-jr: I think there have been some disagreements about your PRs, meshcollider was concerned about #18550 for example
12:15 < gribble> https://github.com/bitcoin/bitcoin/issues/18550 | Store destdata for change in separate key for backward compatibility by luke-jr · Pull Request #18550 · bitcoin/bitcoin · GitHub
12:16 < wumpus> it's probably too late in the release cycle to do changes like that
12:16 < luke-jr> wumpus: are we changing to that topic now? I can wait a bit
12:16 < luke-jr> it's a bugfix
12:17 < MarcoFalke> What bug is it fixing? You didn't include any regression tests
12:17 < meshcollider> ryanofsky should really be here for this discussion too
12:17 < ryanofsky> here
12:17 < luke-jr> MarcoFalke: I don't see how to make tests for this kind of thing
12:18 < ryanofsky> My summary of the destdata issue is https://github.com/bitcoin/bitcoin/pull/18550#issuecomment-612672886
12:18 < wumpus> so is it a regression in 0.20?
12:18 < MarcoFalke> Is this a bug that users can observe or is it only a developer issue?
12:19 < luke-jr> it's a wallet format issue
12:19 < luke-jr> if we don't fix it now, it complicates backward compatibility when we do fix it later
12:19 < wumpus> yes, if it's hard to write a test for and it's not a GUI issue that usually means it's very hard to observe
12:19 < luke-jr> it's hard to write a test, because the breaking is backward compatibility
12:19 < luke-jr> so we'd need a way to run an old version
12:20 < MarcoFalke> the python tests can do that
12:20 < meshcollider> It's not a new issue, the actual issue itself was fixed in #18192
12:20 < gribble> https://github.com/bitcoin/bitcoin/issues/18192 | Bugfix: Wallet: Safely deal with change in the address book by luke-jr · Pull Request #18192 · bitcoin/bitcoin · GitHub
12:20 < luke-jr> "destdata" was added in a manner that it only supported non-change
12:20 < ryanofsky> Luke, I'm not sure what the exact issue you are concerned about, your PR changes behavior in lots of ways, most of them bad
12:20 < luke-jr> but now we suddenly need to support it for change too
12:20 < wumpus> destdata has been in there since 2012 or so isn't it
12:20 < luke-jr> the problem remaining is that the fix in #18192 breaks compatibility
12:20 < gribble> https://github.com/bitcoin/bitcoin/issues/18192 | Bugfix: Wallet: Safely deal with change in the address book by luke-jr · Pull Request #18192 · bitcoin/bitcoin · GitHub
12:20 < sipa> luke-jr: can you give an exact scenario for reproducing the issue?
12:20 < luke-jr> wumpus: yes, 0.9
12:21 < luke-jr> sipa: set a destdata on change, then use the wallet in an older version
12:21 < sipa> assuming no further changes related to the topic go into 0.20
12:21 < wumpus> why does it now suddenly need to be changed before 0.20
12:21 < sipa> what does a user do to cause "set a destdata on change" ?
12:21 < ryanofsky> luke-jr, that is a pre-existing bug in 0.19
12:21 < luke-jr> sipa: currently, it is possible only be using an avoid-reuse wallet
12:21 < ryanofsky> it already sets destdata on change and then starts treating it as nonchange
12:21 < luke-jr> only by*
12:22 < achow101> luke-jr: IMO it isn't worth trying to fix this display bug with users who upgrade then downgrade
12:22 < MarcoFalke> I'd say that anything that is not a regression can wait for 0.20.1 or 0.21.0
12:22 < luke-jr> achow101: it will come back when downgrading 0.21 to 0.20
12:22 < ryanofsky> it'd be easy to backport a trivial fix for that issue in the 0.19 branch, but this PR only makes the bug and introduces other bugs
12:22 < achow101> because it's already an issue for those users using the old software, this isn't a regression
12:22 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-dev
12:22 < luke-jr> unless we specifically exclude "used" from the fix in 0.21
12:22 < ryanofsky> *masks the bug
12:22 < sipa> what is the impact? is it just the change address showing up in the address book, or more?
12:23 < luke-jr> sipa: just that, I think
12:23 < luke-jr> (which can be serious IMO)\
12:23 < achow101> sipa: it may have an effect on coin selection
12:23 -!- ossifrage [~ossifrage@unaffiliated/ossifrage] has quit [Read error: Connection reset by peer]
12:23 < achow101> in particular trusted change vs untrusted non-change
12:23 < luke-jr> achow101: well, if it's spent…
12:24 < sipa> my understanding is that it does not affect IsChange, unless a user also goes to set an explicit label on one of those (now shown) change addresses?
12:24 < wumpus> who uses the address book for receiving addresses anyhow
12:24 < luke-jr> sipa: it does
12:24 < luke-jr> sipa: when the change is used, it gets a "" label
12:24 < sipa> i see
12:24 < luke-jr> wumpus: uh, everyone?
12:24 < sipa> i certainly don't, but i don't think that's an important question; if we have an address book, it should work
12:25 < wumpus> luke-jr: I must admit I haven't used the address book *at all* for years, but last time I did it was to check an address I sent to
12:25 < luke-jr> sipa: this gets worse if we add any new features using destdata - for example, marking which destination are actually used to provide warnings on reuse
12:25 < ryanofsky> this is right but it's a preexisting bug, 0.19 already marks addresses used and has the same bug
12:25 < achow101> CAddressBook effects more than just the address book IIRC
12:25 < luke-jr> wumpus: how do you even receive without using it now?
12:25 < sipa> it affecting IsChange is more concerning to me
12:25 < wumpus> luke-jr: create new receiving address in the receive tab, give it out
12:25 < luke-jr> wumpus: that uses the address book..
12:26 < wumpus> no, it doesn't, the 'payment request' table is separate
12:26 < sipa> ok, this is a semantics discussion; this is not productive
12:26 < MarcoFalke> we should just remove the wallet and gui. Doesn't that solve the problem?
12:26 < luke-jr> -.-
12:26 < luke-jr> ryanofsky was proposing removing destdata entirely, but that breaks compatibility in new ways, and loses a big feature IMO
12:26 -!- jarthur_ [~jarthur@cpe-66-68-134-212.austin.res.rr.com] has joined #bitcoin-core-dev
12:27 < ryanofsky> no, that is not my proposal
12:27 < ryanofsky> my proposal is a refactoring that does not change behavior in any way
12:27 -!- Landryl [~Landryl@ns528256.ip-192-99-10.net] has joined #bitcoin-core-dev
12:27 < ryanofsky> and is meant to prevent bugs like this in the future, but it's basically orthogonal to what we are talking about
12:27 < achow101> I think the question is whether we will try to fix this in the future in a way that allows downgrading to 0.19
12:27 < ryanofsky> i described the bug https://github.com/bitcoin/bitcoin/pull/18550#issuecomment-612672886
12:27 < luke-jr> achow101: to 0.20*
12:27 < sipa> so am i correct that this triggers only if a user on 0.19 has avoid-reuse on, and then uses 0.19 or 0.20?
12:27 < ryanofsky> and have 3 solutions for dealing with it
12:27 < wumpus> destdata was mainly introduced to store payment request data and such, if it's no longer needed it should be removed
12:28 < wumpus> but not for 0.20
12:28 < ryanofsky> my PR is separate and compatible with all 3 approaches
12:28 < sipa> or also when they use 0.20 and then downgrades in certain cases?
12:28 < luke-jr> sipa: it's unfixable for already-released 0.19; my hope is to fix it so downgrading to 0.20 works
12:28 < luke-jr> wumpus: it's still needed
12:28 < luke-jr> destdata is nice because you don't need to upgrade wallets to get features using new metadata
12:29 < achow101> to be clear, is the issue *only* with downgrading?
12:29 < luke-jr> achow101: yes, which is something we've always tried to support for wallets
12:29 < tryphe> address book should be removed outright imo, metadeta that can be modified in a locked wallet is kind of silly
12:29 < achow101> If we didn't care about dowgrading at all, this would not be an issue?
12:29 < ryanofsky> the issue is not only with downgrading, but the fix only deals with downgrading, and is only partial
12:29 -!- jarthur [~jarthur@2605:6000:1019:4971:b51c:6afa:6ad5:df5b] has quit [Ping timeout: 240 seconds]
12:29 < ryanofsky> and it introduces other bug of avoding-reuse feature in 0.19 being broken
12:30 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
12:30 < bitcoin-git> [bitcoin] jnewbery opened pull request #18675: tests: Don't initialize PrecomputedTransactionData in txvalidationcache tests (master...2020-04-precomputedtransactiondata-txvalidationcache) https://github.com/bitcoin/bitcoin/pull/18675
12:30 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
12:30 < achow101> ryanofsky: what's your pr?
12:30 < sipa> can someone give me an exact user scenario that results in a user observing something incorrect, where they start with 0.20.0rc1 as we have now (and then do thing, or downgrade, or ...)
12:31 < ryanofsky> again my pr is orthogonal, refactoring only #18608, comptaible with any dataformat we chose now or in the future
12:31 < wumpus> tryphe: I think that's unrelated; wallet encryption in bitcoin core only protects private keys, nothing more. Labels and such are not part of that either and should definitely be kept.
12:31 < gribble> https://github.com/bitcoin/bitcoin/issues/18608 | refactor: Remove CAddressBookData::destdata by ryanofsky · Pull Request #18608 · bitcoin/bitcoin · GitHub
12:31 -!- jarthur_ [~jarthur@cpe-66-68-134-212.austin.res.rr.com] has quit [Ping timeout: 264 seconds]
12:32 < luke-jr> sipa: create avoid-reuse wallet; send a transaction that has change; spend that change; suddenly that change is no longer change
12:32 < ryanofsky> the scenario is just a change address gets used, and 0.19 software treats all addresses marked as used as nonchange
12:32 < ryanofsky> this is a pre-existing scenario that has been around since 0.19
12:32 < ryanofsky> and the only way to fix it reliably is with backports
12:32 < luke-jr> sipa: the last step is only in 0.19
12:32 < luke-jr> (the result)
12:32 < luke-jr> sipa: but if we fix this in 0.21, 0.20 would no longer see the "used" flag unless we special-case it
12:33 < sipa> luke-jr: that very much depends on how it is fixed
12:33 < ryanofsky> luke's pr is a partial fix for the the issue because it stops marking addresses as used in a way 0.19 understands, and marks them used in a different way it is blind to
12:33 < sipa> my concern right now is behavior that is observable with 0.20
12:33 < ryanofsky> there are 0 bugs observable with 0.20
12:33 < luke-jr> I don't see a way to fix it later, without special-casing 0.20 support
12:34 < wumpus> tbh if it's only a minor backwards compatibility issue that is only apparent in downgrading, I wouldn't want to do things substantially different because of it
12:34 -!- captjakk [~captjakk@174-29-9-247.hlrn.qwest.net] has joined #bitcoin-core-dev
12:34 < tryphe> wumpus, mostly agree, although allowing modification of metadata of someone's wallet while in cold storage that they might assume stays constant opens up a lot of doors for bad actors
12:34 < achow101> How about we revert the "fix" in 0.20 and try again for 0.21? It seems like ~no one has complained about this bug in 0.19
12:34 < ryanofsky> the fix in 0.20 is correct and causes no backwards compatiability issues
12:34 < sipa> luke-jr: if after that scenario (create avoid-reuse in 0.20; create change in 0.20; spend change in 0.20; downgrade to 0.19; do things), the user upgrades again to 0.20, is the issue resolved, or might it persist?
12:34 < meshcollider> I don't think that's a good idea, the fix is still an improvement
12:34 < luke-jr> achow101: leaving it as-is now is strictly less bad than reverting I think
12:34 < sipa> tryphe: please stay on topic
12:34 < wumpus> tryphe: if that's your concern, encrypt the entire wallet file or store it on an encrypted file system, it's not something bitcoin core's wallet encyrption solves
12:34 < ryanofsky> the fix causes no issues whatsoever
12:34 -!- jarthur [~jarthur@cpe-66-68-134-212.austin.res.rr.com] has joined #bitcoin-core-dev
12:35 < ryanofsky> i mean the fix that's already been merged causes no issues, the new fix proposed is a different story
12:35 < luke-jr> sipa: the issue remains resolved in 0.20, provided the user doesn't see it in 0.19 and set a label or something
12:35 < sipa> luke-jr: thank you
12:35 < luke-jr> (in fact, I think 0.19 making the broken state itself, would also appear correct in 0.20)
12:36 < wumpus> okay
12:36 < sipa> that's good to hear as well
12:36 < wumpus> yes, that's good to hear
12:36 < sipa> i think we should document the issue in the release notes, with the point that if the issue appears, upgrading (again) to 0.20 will fix things unless a user manually set a label on an errorneously-shown address in 0.19
12:37 < luke-jr> my biggest "end result" concern, is that I don't think users should need to -upgradewallet to get address reuse warnings when we finally merge that ; but that's a few steps into the future
12:37 < sipa> for 0.21, we can discuss solutions - whether those involved -upgradewallet or special-casing the 0.20 behavior
12:37 < achow101> luke-jr: with what is currently merged, why is changing the fix necessary?
12:37 < achow101> as in why is your proposed 0.21 fix necessary
12:38 < luke-jr> achow101: it's one thing to break compatibility with <0.19 only for avoid-reuse wallets>, another entirely to break compatibiltiy with <normal wallets going back forever>
12:38 < luke-jr> achow101: since "used" destdata is only in avoid-reuse, we have the former situation right now
12:38 < luke-jr> but as soon as we add destdata for change on normal wallets, we get the latter
12:38 -!- captjakk [~captjakk@174-29-9-247.hlrn.qwest.net] has quit [Ping timeout: 260 seconds]
12:39 < achow101> are we adding destdata for change on normal wallets?
12:39 < luke-jr> achow101: that's my plan for address reuse warnings
12:39 < ryanofsky> achow101, yes, we've been doing that since kallewoof implemented avoidreuse
12:39 < wumpus> just a reminder that we have to reserve some time for MarcoFalke's topic as well
12:39 < jonatack> i agree with sipa's proposals (and with meshcollider and ryanofsky that it's better to keep fix in luke-jr's merged pr)
12:39 < luke-jr> that's how it can avoid needing a -walletupgrade
12:39 < achow101> ryanofsky: that's only for avoid reuse
12:40 < achow101> luke-jr: i see, so what if we don't do that?
12:40 < achow101> and just don't change it
12:40 < luke-jr> achow101: I don't understand what you mean
12:40 < luke-jr> if we don't add address reuse warnigns, we don't have address reuse warnings..
12:40 < achow101> why do we have to add destdata on change for normal wallets
12:40 < luke-jr> to mark the change address as used
12:41 < achow101> if the wallet doesn't signal avoidreuse, then there's no need?
12:41 -!- vasild_ [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-dev
12:41 < luke-jr> address reuse warnings are for all wallets
12:41 < sipa> yeah, address reuse warnings != avoidreuse behavior
12:41 < achow101> ok i see
12:41 < sipa> but can't that be done with a different db record instead?
12:41 < achow101> there's the context I'm missing :)
12:41 < luke-jr> sipa: that's a wallet format change, and needs -upgradewallet
12:41 < ryanofsky> sipa, yes
12:42 < sipa> luke-jr: why? old wallets would just ignore the record
12:42 < ryanofsky> from https://github.com/bitcoin/bitcoin/pull/18550#issuecomment-612672886
12:42 < ryanofsky> option 1 is keep using "destdata" record
12:42 < ryanofsky> option 2 is switch to "changedata" record
12:42 < sipa> also, can't the usage data be computed at runtime from other wallet data?
12:42 < ryanofsky> option 3 is "useddata" record
12:43 < luke-jr> sipa: historical best practice?
12:43 < sipa> ?
12:43 < luke-jr> sipa: maybe in this case (I haven't looked into that option yet, but I plan to), but this will probably come up again either way
12:43 < meshcollider> Using a different record would be fine, only a minor code complication
12:43 < luke-jr> sipa: we've always tried to not change wallet format outside of an explicit -upgradewallet
12:43 < meshcollider> I dont think it would come up again luke-jr 
12:43 < luke-jr> meshcollider: tax metadata for example
12:43 < sipa> luke-jr: it sounds to me like no wallet format change is needed *at all* for this functionality
12:44 < meshcollider> Again use a different record, not destdata
12:44 < luke-jr> meshcollider: what different record?
12:44 < sipa> i think this is taking us too far
12:44 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds]
12:44 -!- vasild_ is now known as vasild
12:44 < luke-jr> meshcollider: adding a new one is a wallet format change..
12:45 < sipa> so be it?
12:45 < achow101> luke-jr: we've added/changed records before without needing upgradewallet
12:45 < wumpus> please wrap up this topic
12:45 < meshcollider> In a backwards compatible way if it's new
12:45 < sipa> if it's a record old wallets can just ignore, no need for upgradewallet
12:45 < luke-jr> achow101: we have?
12:45 < sipa> otherwise, use it
12:45 < luke-jr> ok then
12:45 < meshcollider> Yes the topic is done, the PRs are closed as noone else concept ACKs the change
12:45 < achow101> luke-jr: see UpgradeKeyMetadata
12:45 < wumpus> #topic experimental libmultiprocess, next steps for multiprocess in general (MarcoFalke)
12:45 < MarcoFalke> Background is that libmultiprocess has been added to ./depends , and libmultiprocess compile and link flags have been added to our makefile. Everything was opt-in but after merge discussion concluded that it was too early to do this step, so the change has been reverted. I (and ryanofsky) would like to hear and discuss everyone's concerns about libmultiprocess as part of the meeting for brainstorming.
12:46 < MarcoFalke> cc cfields
12:46 < cfields> ^^
12:46 < MarcoFalke> cc fanquake (probably sleeping)
12:46 < sipa> my impression is that we should only merge changes for this if the plan is that eventually this will end up in release binaries
12:46 < sipa> it's not clear to me if that's the case
12:46 < cfields> fanquake listed a bunch of really good questions, and ryanofsky has given good answers to on #18588.
12:46 < gribble> https://github.com/bitcoin/bitcoin/issues/18588 | Revert "Merge #16367: Multiprocess build support" by MarcoFalke · Pull Request #18588 · bitcoin/bitcoin · GitHub
12:46 < MarcoFalke> sipa: Eventually that was the goal (at least as I understood it)
12:47 < ryanofsky> that is the goal as far as i know
12:47 < MarcoFalke> sipa: Though, there was no timeline for it
12:47 < cfields> sipa: yes, that was exactly my concern as well. The path forward isn't clear enough to be merging it in in-parts, imo.
12:47 < wumpus> sipa: yes, I think that's obvious
12:48 < sipa> i haven't paid that much attention to the multiprocess project as i don't really care about it (and kind of dread pulling in extra dependencies like capnproto), but i assumed that it was something lots of people wanted - which is fine
12:48 < wumpus> though it's probably ok to have it experimental for a while before it ends up in release binaries
12:48 < ryanofsky> maybe relevant: it builds new binaries
12:48 < sipa> wumpus: sure
12:49 < wumpus> I'm not really sure I like importing capnproto either, just now we got rid of google serialization thing
12:49 < ryanofsky> so a theoretical release could include existing binaries, alongside new multiprocess binaries that let you start and stop node/gui/wallet separately and connect each other
12:49 < wumpus> then again it's probably better than hand-rolling everything
12:49 < MarcoFalke> The multiprocess and capnproto will stay opt-in unless it is decided to change it that
12:50 < luke-jr> ryanofsky: can the same binary do single-process and multiprocess?
12:50 < MarcoFalke> luke-jr: No, they are two binaries
12:50 < luke-jr> I mean hypothetically
12:50 < wumpus> ryanofsky: I'm not sure I like that solution, couldn't we emulate the old way using the new binaries without shipping everything twice?
12:50 < ryanofsky> yes, I just didn't add the option
12:50 < ryanofsky> there is lots of flexibility here
12:51 < wumpus> with the static builds we do that's expensive
12:51 < ryanofsky> I just built separate binaries because i meant I had to run ./configure less often
12:51 < ryanofsky> If we want unified binaries with a runtime options, that's easy too
12:51 < wumpus> ah yes like busybox
12:52 < luke-jr> eg, bitcoin-qt gets what we have now; bitcoin-qt -process=foo gets just the foo part in MP mode
12:52 < wumpus> that kinda makes sense
12:53 < ryanofsky> these are really just packaging questions, my question is how to make progress on getting code reviewed
12:53 < wumpus> well, 'just packaging questions' are kind of important to do this, I think
12:53 < luke-jr> review club? :P
12:54 < wumpus> if you split up things people are going to ask how to re-bundle them :)
12:54 < ryanofsky> i mean, packaging questions are the things you would be deciding on last, and maybe changing with trial and error
12:55 < cfields> ryanofsky: some of those packaging questions come down to language choices though, those things need to be decided on much earlier.
12:55 < ryanofsky> 99% of the code stays the same regardless
12:55 < wumpus> in any case if you want concept ACK on multiprocess, concept ACK, I think it's a good thing in the longer run
12:55 -!- jarthur_ [~jarthur@cpe-66-68-134-212.austin.res.rr.com] has joined #bitcoin-core-dev
12:55 < ryanofsky> cfields ?
12:55 < wumpus> security-wise process isloation is a good start as well
12:56 < cfields> ryanofsky: I'm curious to know, for example, what the downside of using the c++11 version libmultiprocess you've mentioned?
12:56 < jonasschnelli> looking forward to wireguard-tunnel the GUI to a remote node.
12:56 < cfields> does that mean dragging boost back in?
12:57 < wumpus> so maybe the packaging details is the only thing we can disagree on :)
12:57 < ryanofsky> cfields, no downside, i can revert the vasild pr and replace std::optional with boost::optional again
12:57 < jonasschnelli> (but I guess that needs much more)
12:57 < wumpus> wait, why?
12:57 < MarcoFalke> In about 6 months we'll have C++17
12:57 < ryanofsky> jonasschnelli, not too much, you can kind of do it with my existing branch if you use socat (existing branch only create UNIX socket)
12:57 < cfields> wumpus: I'm just trying to understand our options.
12:58 < wumpus> how can we be using std::optional in the first place we haven''t switched to C++17 yet right?
12:58 -!- jarthur [~jarthur@cpe-66-68-134-212.austin.res.rr.com] has quit [Ping timeout: 256 seconds]
12:58 < sipa> wumpus: libmultiprocess is using std::optional, but we're not using libmultiprocess yet
12:58 < ryanofsky> wumpus, we are not, libmultiprocess used it internally because vasild submitted a pr to get rid of boost, and i thought it was nice
12:58 < wumpus> I think the idea was to have 0.21 still c++11 compatible then go full c++17 for 0.22
12:58 < MarcoFalke> wumpus: libmultiprocess is compiled with c++14 flags in depends
12:58 < sipa> if it's just std::optional or boost::optional... that sounds like something we can just decide whenever it's merged
12:58 < wumpus> c++14??!
12:59 < wumpus> nooo
12:59 < MarcoFalke> s/is/was/
12:59 < luke-jr> do we need to fork upstream to get C++11 support?
12:59 < sipa> if multiprocess integration only lands with 0.22, we'd be fine
12:59 < ryanofsky> it works fine now...
12:59 < sipa> otherwise, it seems it can easily be turned into c++11 compatible
12:59 < MarcoFalke> sipa: Yes, that was my thinking
12:59 < wumpus> I doubt that has to depend on using boost::optional or std::optional they're kind of the same right?
12:59 < luke-jr> ryanofsky: with a non-C++14 compiler?
12:59 < wumpus> could use a wrapper or something like we do for fs.h
12:59 -!- brakmic [~brakmic@5.180.62.40] has joined #bitcoin-core-dev
13:00 < wumpus> but we intentionally skipped over C++14, we're not going to do that now
13:00 < achow101> don't we have an Optional wrapper already?
13:00 < luke-jr> yes
13:00 < wumpus> achow101: lol yes we do
13:00 < ryanofsky> i'm not sure what's not supposed to work here
13:01 < wumpus> in any case I agree these are all small details?
13:01 < MarcoFalke> I think boost::optional vs std::optional should be the least of our concerns in regard to multiprocess. This is just a sylistic issue
13:01 < MarcoFalke> wumpus: jup
13:01 < jonatack> ryanofsky: why not add the PR to blockers?
13:01 < wumpus> let's go forward with multiprocess imo
13:01 < wumpus> my biggest gripe is really the serialization lib dependency not boost
13:01 -!- jarthur [~jarthur@2605:6000:1019:4971:451:45b8:ad4c:996d] has joined #bitcoin-core-dev
13:02 < wumpus> everyone wants to get rid of boost but also not get rid of boost it's not going to happen any time soon
13:02 < ryanofsky> jonatack, #16367 has been in high priority list, and was even merged (then got reverted)
13:02 < gribble> https://github.com/bitcoin/bitcoin/issues/16367 | Multiprocess build support by ryanofsky · Pull Request #16367 · bitcoin/bitcoin · GitHub
13:02 < MarcoFalke> So I think people don't want a half-merged multiprocess? In which case we should focus on the main pr
13:03 < wumpus> we should wrap up the meeting btw
13:03 < wumpus> sorry for only leaving so little time for this
13:03 < cfields> MarcoFalke: I didn't want a half-decided multiprocess. If we've decided to move forward on defaulting it, I have no issue with the merge.
13:03 < luke-jr> it would be nice if there was a standard interface involved here, but lacking that, why not just use serialization.h?
13:03 < ryanofsky> wumpus, it's a valid concern. as much as possible I tried to make framework agnostic to serializtion and allow substituting in other implementations later
13:03 < jb55> wumpus: I've also ran into build issues with changing capnproto versions. is there a plan to rework that branch without capnproto? 
13:03 < luke-jr> cfields: why do we need to default it?
13:04 < cfields> luke-jr: ship the binaries by default, sorry.
13:04 < luke-jr> ah
13:04 < wumpus> jb55: so the thing is, I think, that our own serialization framework is not powerful enough
13:04 < sipa> for the wallet<->node communication my big hope was that the protocol would be Bitcoin P2P, so that it can be substituted with whatever on either side... but it doesn't seem anyone's working on that
13:04 < jonatack> ryanofsky: yes; a re-opened PR when it's ready (since you mentioned review)
13:04 -!- jarthur_ [~jarthur@cpe-66-68-134-212.austin.res.rr.com] has quit [Ping timeout: 240 seconds]
13:04 < wumpus> jb55: also using consensus serialization for other things might not be the best idea, so people have used something else
13:05 < ryanofsky> sipa, we're maybe getting closer that that with ariard's prs
13:05 < sipa> ryanofsky: okay
13:05 < wumpus> but yes what particular library to use, no idea
13:05 < ryanofsky> he's stripping down the node/wallet interface so it's something more akin to p2p
13:05 -!- Talkless [~Talkless@hst-227-49.splius.lt] has quit [Quit: Konversation terminated!]
13:05 < MarcoFalke> sipa: Wouldn't that be dangerous to accidentally connect to a malicious remote p2p node?
13:05 < wumpus> ryanofsky: oh that's nice!
13:05 < jb55> what pr is that
13:05 < luke-jr> just to be clear: we're not planning on making the interfaces backward/forward compatible, right?
13:05 < sipa> MarcoFalke: well you'd have SPV security - which may be even desirable
13:06 < sipa> ryanofsky: (i didn't mean that as a "you shouldn't do what you're doing" - they're orthogonal ways of separating things; a P2P-protocol based one is just what i'm more interested in)
13:06 < ryanofsky> jb55, i think he only has locking PRs open now that make node/wallet more asynhrnous, but he has branches to do things like store block info in wallet i believe
13:06 < wumpus> but for an experimental thing it might be OK to rely on capnproto
13:06 < wumpus> I don't want to stand in the way of that
13:06 < ryanofsky> sipa, yes, I know that, that's the way I look at it too
13:07 < wumpus> we've often enough delayed things before some 'perfect solutoin' would appear which then would never happen
13:07 < sipa> agreed
13:07 < jb55> so experimental with plans to replace it eventually? 
13:07 < wumpus> yess
13:07 < jb55> I'm ok with that
13:07 < sipa> ryanofsky: what specifically does capnproto offer that's hard to do in our own serialization.h?
13:07 < cfields> sgtm
13:07 < sipa> or is it just avoiding lots of boilerplate code
13:08 < sipa> (which may be a valid reason too)
13:08 < wumpus> boilerplate I think
13:08 -!- timothy [~tredaelli@redhat/timothy] has quit [Remote host closed the connection]
13:08 < wumpus> capnproto autogenerates a lot
13:08 < ryanofsky> sipa, it's a whole io framework, more than just serialization
13:08 < ryanofsky> it's higher level even than things like grpc and thrift, it gives you object handles and supports callbacks
13:09 < wumpus> right, it's a real RPC mechanism, not just serialization
13:09 < sipa> i see
13:09 < wumpus> it goes further than protobuf in that regard
13:09 < ryanofsky> and i've found it just very nice to work with, but I've tried to make everything around it as flexible as possible so it could be swapped with something else
13:10 < luke-jr> so might be more apt to compare it to bitcoind's RPC server..
13:10 < wumpus> also it doesn't need to be compatible between differnt verisons
13:10 < wumpus> as it's only used for internal communication
13:10 < jb55> if its in in-tree as an experimental maybe we can get more people working on it... status has been ambiguous for so long
13:10 < wumpus> between components of the same release
13:10 < wumpus> luke-jr: nononono it's *NOT* an official API
13:10 < ryanofsky> wumpus, yes that is true, though capnproto does have same nice versioning / compatibility features as protobufs
13:10 < luke-jr> wumpus: I mean technically comparable, not supported the same
13:10 < wumpus> luke-jr: ok :)
13:11 < wumpus> agreed in that case
13:11 < luke-jr> wumpus: I too would be against a stable interface for this right now :P
13:11 < luke-jr> (unless we literally made it use bitcoind RPC maybe)
13:11 < wumpus> yes, maybe in the future
13:11 < wumpus> ok, let's wrap up the meeting
13:11 < cfields> Thanks for the discussion :)
13:11 < wumpus> thank you too
13:11 < ryanofsky> yes, the interfaces is just the headers in src/interfaces/, changes very often
13:11 < sipa> it's certainly hard to agree on a stable interface 2 major releases before we plan to have it available :p
13:11 < wumpus> sipa: lol exactly
13:12 < wumpus> #endmeeting
13:12 < lightningbot> Meeting ended Thu Apr 16 20:12:09 2020 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
13:12 < lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2020/bitcoin-core-dev.2020-04-16-19.03.html
13:12 < lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2020/bitcoin-core-dev.2020-04-16-19.03.txt
13:12 < lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2020/bitcoin-core-dev.2020-04-16-19.03.log.html
13:12 -!- jarthur_ [~jarthur@cpe-66-68-134-212.austin.res.rr.com] has joined #bitcoin-core-dev
13:12 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
13:12 < bitcoin-git> [bitcoin] hebasto opened pull request #18676: build: Check libevent minimum version in configure script (master...200416-libevent) https://github.com/bitcoin/bitcoin/pull/18676
13:12 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
13:14 -!- owowo [~ovovo@unaffiliated/ovovo] has quit [Read error: Connection reset by peer]
13:14 -!- jarthur [~jarthur@2605:6000:1019:4971:451:45b8:ad4c:996d] has quit [Ping timeout: 265 seconds]
13:14 < wumpus> ^^ thanks hebasto 
13:14 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
13:14 < bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/d8dfcea5d956...447f8676b2e9
13:14 < bitcoin-git> bitcoin/master 0c63187 Hennadii Stepanov: ci: Limit cache size regardless of NO_DEPENDS
13:14 < bitcoin-git> bitcoin/master 447f867 MarcoFalke: Merge #18667: ci: Limit cache size regardless of NO_DEPENDS
13:14 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
13:15 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
13:15 < bitcoin-git> [bitcoin] MarcoFalke merged pull request #18667: ci: Limit cache size regardless of NO_DEPENDS (master...200416-ci-cache) https://github.com/bitcoin/bitcoin/pull/18667
13:15 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
13:15 < MarcoFalke> PSA: I will probably clear all travis caches now, because of this bug in the ci scripts ^
13:15 -!- berndj [~berndj@azna.co.za] has quit [Quit: ZNC - http://znc.in]
13:16 -!- captjakk [~captjakk@174-29-9-247.hlrn.qwest.net] has joined #bitcoin-core-dev
13:19 < sipa> i forgot to bring it up again in the meeting, but i'd like some opinions on how to move forward with asmap... 0.20 will have (experimental?) support for it, but the user is responsible for constructing/finding/... the map file somewhere
13:20 < sipa> i have #18573 that adds a binary for constructing/decoding these map files, which is an approach i like, but perhaps it's better to keep this out of bitcoin core's scope for now, unsure
13:20 < gribble> https://github.com/bitcoin/bitcoin/issues/18573 | [RFC] bitcoin-asmap utility by sipa · Pull Request #18573 · bitcoin/bitcoin · GitHub
13:21 -!- berndj [~berndj@azna.co.za] has joined #bitcoin-core-dev
13:22 -!- owowo [~ovovo@unaffiliated/ovovo] has joined #bitcoin-core-dev
13:23 < wumpus> sipa: I'm not sure, on one hand it's useful to have encoding and decoding in one place, on the other I don't really like adding more and more binaries to the distribution
13:23 < wumpus> MarcoFalke: SGTM
13:24 < wumpus> sipa: we've intentionally kept all kinds of developer tools in bitcoin-maintainer-tools repo instead, but if you think this is something a lot of users are going to need we could ship it with bitcoin core itself sure
13:25 < wumpus> I mean, if everyone is going to generate their own asmap instead of downloading a pre-generated one
13:25 < wumpus> but that's your question I guess
13:26 < sipa> wumpus: or being able to verify a shipped one
13:27 < sipa> but yes, things depend on how these things get used, how distribution is handled, what expectations people have around the process...
13:28 < wumpus> right
13:28 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
13:28 < bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/447f8676b2e9...8f2497941ef1
13:28 < bitcoin-git> bitcoin/master e44aeef Andrew Chow: gitian: Add missing automake package to gitian-win-signer.yml
13:28 < bitcoin-git> bitcoin/master 8f24979 Wladimir J. van der Laan: Merge #18598: gitian: Add missing automake package to gitian-win-signer.ym...
13:28 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
13:28 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
13:28 < bitcoin-git> [bitcoin] laanwj merged pull request #18598: gitian: Add missing automake package to gitian-win-signer.yml (master...fix-gitian-win-signer) https://github.com/bitcoin/bitcoin/pull/18598
13:28 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
13:33 < luke-jr> sipa: ideally we should keep it separate IMO - but does it need to share a lot of code?
13:33 < luke-jr> I hope the multiprocess eventually leads to a separate wallet/GUI repos too ☺
13:33 < sipa> luke-jr: i think the primary advantage is that it allows testing/fuzzing the encoder together with the exact code bitcoin core is using for lookups
13:34 < luke-jr> sipa: no reason we can't test across repos?
13:34 < sipa> it could be a separate repository that's subtreed or otherwise included in the build of course
13:34 < sipa> but that's not really my question
13:35 < luke-jr> nah, just pull it in for QA?
13:36 < luke-jr> like Python
13:36 < sipa> i'm confused
13:36 -!- jarthur_ is now known as jarthur
13:37 < luke-jr> sipa: we only need Python to run tests, not to build
13:37 < sipa> sure
13:37 < luke-jr> if bitcoin-asmap is available, we can use it for tests too, but still separate from the main repo
13:37 < luke-jr> no?
13:38 < sipa> luke-jr: you mean if the binary is available?
13:38 < luke-jr> sure
13:38 < sipa> that'd be extremely slow
13:38 < luke-jr> ?
13:38 < sipa> if you'd need to invoke the binary for every test case
13:38 < sipa> my fuzz test right now generates random inputs to the encoder function used by bitcoin-asmap directly
13:39 < sipa> that's orders of magnitude faster
13:39 < luke-jr> hmm
13:39 < sipa> and verifies them against the interpreter code used for lookup
13:39 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
13:39 < bitcoin-git> [bitcoin] MarcoFalke pushed 5 commits to master: https://github.com/bitcoin/bitcoin/compare/8f2497941ef1...969ee8549496
13:39 < bitcoin-git> bitcoin/master fa2bc41 MarcoFalke: tools: Add unused argsman to bench_bitcoin
13:39 < bitcoin-git> bitcoin/master fa46aeb MarcoFalke: scripted-diff: Replace gArgs with local argsman in bench
13:39 < bitcoin-git> bitcoin/master fae00a7 MarcoFalke: bench: Remove unused argsman.ClearArgs
13:39 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
13:39 < luke-jr> maybe encode+lookup should be a library? :x
13:40 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
13:40 < bitcoin-git> [bitcoin] MarcoFalke merged pull request #18662: test: Replace gArgs with local argsman in bench (master...2004-toolsArgsman) https://github.com/bitcoin/bitcoin/pull/18662
13:40 < luke-jr> or pair of libraries sharing a repo
13:40 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
13:40 < sipa> yes, that's a possibility
13:40 < sipa> it's a bunch of overhead though
13:40 < sipa> as in, process/maintenance overhead
13:41 < sipa> if it's something that's more widely interesting, perhaps it makes sense
13:41 < luke-jr> it does sound potentially useful outside Bitcoin Core too
13:41 < sipa> i'm not sure to what extent it is
13:41 < sipa> i agree
13:42 < luke-jr> in fact, I think BitTorrent clients do something similar for banning copyright trolls?
13:42 < sipa> no idea
13:42 -!- BlueMatt [~BlueMatt@unaffiliated/bluematt] has quit [Quit: Quit]
13:44 -!- BlueMatt [~BlueMatt@unaffiliated/bluematt] has joined #bitcoin-core-dev
13:44 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
13:44 < bitcoin-git> [bitcoin] ryanofsky opened pull request #18677: Multiprocess build support (master...pr/ipc-build2) https://github.com/bitcoin/bitcoin/pull/18677
13:44 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
13:45 -!- TheRec [~toto@drupal.org/user/146860/view] has quit [Read error: Connection reset by peer]
13:46 -!- TheRec [~toto@84-75-225-47.dclient.hispeed.ch] has joined #bitcoin-core-dev
13:46 -!- TheRec [~toto@84-75-225-47.dclient.hispeed.ch] has quit [Changing host]
13:46 -!- TheRec [~toto@drupal.org/user/146860/view] has joined #bitcoin-core-dev
13:55 < jb55> sipa: is there a writeup about the asmap stuff somewhere? what's problems its trying to solve, how and why I need to generate those files, etc. as one of the people who maintains the bitcoin package on nixos, would I need to generate that and package it for users, etc? 
13:56 < sipa> jb55: we really don't know
13:57 < sipa> it's a binary blob you can load into bitcoin core that affects how it selects outgoing peers and prioritizes incoming connections
13:57 < sipa> that's all there is for 0.20
13:58 < sipa> i have a repo with some python scripts that can generate the file (sipa/asmap), and there is a rust project that can take BGP dump files and produce input for those python scripts
13:58 < sipa> right now it's just an experimental feature as we don't really know what the process for distribution/generation will look like
13:59 -!- emilengler [~emilengle@stratum0/entity/emilengler] has quit [Quit: Leaving]
13:59 < sipa> maybe at some point it becomes part of gitian builds, or something similar
13:59 < sipa> maybe some day it's built into the binary even
13:59 < jb55> it's not much work for package maintainers to pull a signed binary blob from somewhere and include it as an option, or even generate it ourselves from the tools
14:00 < sipa> yes, but who would you trust to sign it
14:00 -!- mikeyman77 [~mikeyman7@89.40.181.148] has quit []
14:00 < jb55> if it was signed with the same key we're using for verifying bitcoin releases for instance
14:00 < sipa> ideally you verify gitian signatures :)
14:01 < sipa> so it's not a single party you're trusting
14:01 < sipa> but if we're talking about the entire process for building these map files... it's not deterministic, as the source material is BGP dumps that come from... somewhere
14:01 < sipa> and they change constantly
14:02 < sipa> so it's not really something that can be gitian-verified
14:02 < jb55> could those be poisoned somehow? 
14:02 < jb55> don't know much about bgp
14:02 < sipa> well you need be your own ISP to have access to BGP dumps, and even then you only see "your view" of the internet
14:03 < sipa> you can download BGP dumps from various locations of course
14:04 < jb55> would a typical user want to generate these themselves? how would they verify they are legit? Is the point to prevent eclispe like attacks?
14:04 < sipa> and an attacker supplying you with an asmap file definitely would make eclipse attacks easier for them
14:04 < jb55> right
14:04 < sipa> jb55: better partition resistance, ... too
14:05 < sipa> jb55: i have more questions than answers about the correct procedure :)
14:05 < jb55> could you be attacked during the process of generating the maps? just trying to understand possible attacks here wrt. generating them on the package distro side
14:07 < sipa> so the process is (bgp dumps) -> mapping (currently, using gleb's rust tool); mapping -> asmap file (currently using some python scripts, or the bitcoin-asmap tool i'm adding in 18573)
14:08 < sipa> brb, lunch
14:08 < jb55> sipa: cool I'll take a look
14:16 -!- SiAnDoG_ [~514nDoG@gateway/tor-sasl/siandog] has quit [Remote host closed the connection]
14:17 -!- brakmic_ [~brakmic@ip-176-198-41-116.hsi05.unitymediagroup.de] has joined #bitcoin-core-dev
14:17 -!- SiAnDoG_ [~514nDoG@gateway/tor-sasl/siandog] has joined #bitcoin-core-dev
14:19 -!- jarthur_ [~jarthur@cpe-66-68-134-212.austin.res.rr.com] has joined #bitcoin-core-dev
14:20 -!- brakmic [~brakmic@5.180.62.40] has quit [Ping timeout: 260 seconds]
14:20 -!- SiAnDoG_ [~514nDoG@gateway/tor-sasl/siandog] has quit [Remote host closed the connection]
14:20 -!- SiAnDoG_ [~514nDoG@gateway/tor-sasl/siandog] has joined #bitcoin-core-dev
14:21 -!- [42]1 [~42]@84.39.116.180] has joined #bitcoin-core-dev
14:23 -!- jarthur [~jarthur@cpe-66-68-134-212.austin.res.rr.com] has quit [Ping timeout: 258 seconds]
14:23 -!- SiAnDoG_ [~514nDoG@gateway/tor-sasl/siandog] has quit [Remote host closed the connection]
14:24 -!- SiAnDoG_ [~514nDoG@gateway/tor-sasl/siandog] has joined #bitcoin-core-dev
14:36 -!- brakmic_ [~brakmic@ip-176-198-41-116.hsi05.unitymediagroup.de] has quit []
14:36 -!- brakmic [~brakmic@185.183.85.108] has joined #bitcoin-core-dev
14:39 < jonatack> jb55: there's an extensive review club writeup
14:40 < jonatack> jb55: https://bitcoincore.reviews/16702
14:40 < jb55> jonatack: thanks
14:42 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 256 seconds]
14:44 -!- Emcy [~Emcy@unaffiliated/emcy] has quit [Remote host closed the connection]
14:45 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
14:46 -!- Emcy [~Emcy@unaffiliated/emcy] has joined #bitcoin-core-dev
14:47 < jonatack> jb55: fwiw i've been running a node with -asmap pointing to the file in a git cloned sipa/asmap repo since last December, you can see the ASN mappings via either getpeerinfo ("mapped_as") or in the GUI peers window ("Mapped AS")
14:49 < jb55> I assume you don't have to worry about this stuff if you run onlynet=onion?
14:50 < sipa> jb55: if you're reachable on public IPv4/IPv6 you may
14:50 < sipa> (onlynet only controls outgoing connections, iirc)
14:50 < jb55> ah
14:54 < jonatack> yes, as per doc/tor.md, incoming connections are not affected by onlynet=onion
14:54 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
14:55 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has joined #bitcoin-core-dev
14:55 < sipa> to clarify: asmap affects two things independently: the choice of outgoing connections to make, and prioritization of incoming connections when the max connection count is reached
14:55 < sipa> with onlynet=tor the first one disappears of course
15:00 -!- ossifrage [~ossifrage@unaffiliated/ossifrage] has joined #bitcoin-core-dev
15:01 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Quit: WeeChat 2.4]
15:01 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
15:01 < phantomcircuit> sipa, ip<->asn lookup is definitely something that would be useful outside of bitcoin, i've tried myself to do it in the past but without an active bgp session it's basically impossible to get the map at all
15:02 < sipa> that's good to know
15:02 < jonatack> sipa: that's a good point, and i didn't discuss inbounds in the writeup... may update it
15:03 < sipa> jonatack: i think the outbound selection is certainly the more impactful change
15:04 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has quit [Ping timeout: 240 seconds]
15:04 < sipa> phantomcircuit: though asmap is really about efficiently encoding the map, *once you have a mapping* - i don't think there is a clear-cut optimal solution for building those maps
15:05 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has joined #bitcoin-core-dev
15:08 < sipa> FWIW, the map with data from asmap-rs (sourced from RIPE NCC data) a week or two ago, with my latest optimized encoder, is 1210027 bytes
15:08 -!- filchef [~filchef@212.104.97.177] has joined #bitcoin-core-dev
15:09 -!- filchef [~filchef@212.104.97.177] has quit [Client Quit]
15:10 < sipa> however, we certainly don't want to go encourage everyone to go download from RIPE independently... i doubt they're set up for that
15:10 < BlueMatt> note that you probably want to preprocess the ripe ris data feed a bit - it includes a bunch of nonsense paths
15:10 < sipa> maybe we should ask them to publish hashes of their dumps
15:11 < wumpus> I do think this could be useful for other projects, on the other hand, making a library out of it before any other project expressed concrete interest might be scope creep
15:11 < sipa> BlueMatt: i've indeed noticed some bogus stuff in there
15:11 < sipa> fd58:9520:1361:6800::/126 AS136168
15:11 -!- Guyver2 [Guyver@guyver2.xs4all.nl] has quit [Quit: Going offline, see ya! (www.adiirc.com)]
15:11 < BlueMatt> heh, thats mild
15:11 < BlueMatt> but, ye
15:11 < BlueMatt> a
15:13 < sipa> BlueMatt: if you have ideas for some useful filtering, please open an issue on https://github.com/0ii/asmap-rs or so
15:13 < sipa> maybe it already does some processing, don't know
15:13 < BlueMatt> hmm, probably a) < /24 /48 v6, b) gotta compare with others, probably
15:13 < BlueMatt> would have to look at differences to figure out whts really broken
15:14 -!- jarthur_ is now known as jarthur
15:34 < sipa> another reason for keeping asmap inline for now is that the format is really designed for the specific use case we have (it's only really efficient when you're allowed to remap unused ranges arbitrarily) and isn't super extensible (only AS numbers up to 2^25 i think)
15:34 < sipa> if the codebase is kept in one place it's probably easier to introduce changes
15:34 -!- brakmic [~brakmic@185.183.85.108] has quit []
15:41 -!- marcoagner [~user@2001:8a0:6a5f:a900:6d3e:1158:b50:97b6] has quit [Ping timeout: 252 seconds]
15:42 -!- jarthur [~jarthur@cpe-66-68-134-212.austin.res.rr.com] has quit []
15:58 < wumpus> agree, though 'as part of the bitcoin core project' is in one place, more or less, it doesn't necessarily mean one repository
16:16 -!- captjakk [~captjakk@174-29-9-247.hlrn.qwest.net] has quit [Remote host closed the connection]
16:17 -!- captjakk [~captjakk@174-29-9-247.hlrn.qwest.net] has joined #bitcoin-core-dev
16:19 -!- captjakk [~captjakk@174-29-9-247.hlrn.qwest.net] has quit [Remote host closed the connection]
16:19 -!- captjakk [~captjakk@174-29-9-247.hlrn.qwest.net] has joined #bitcoin-core-dev
16:21 -!- tryphe [~tryphe@unaffiliated/tryphe] has quit [Read error: Connection reset by peer]
16:22 -!- tryphe [~tryphe@unaffiliated/tryphe] has joined #bitcoin-core-dev
16:24 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
16:24 < bitcoin-git> [bitcoin] MarcoFalke closed pull request #18612: script: Remove undocumented and unused operator+ (master...2004-scriptNoAdd) https://github.com/bitcoin/bitcoin/pull/18612
16:24 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
16:24 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
16:24 < bitcoin-git> [bitcoin] MarcoFalke reopened pull request #18612: script: Remove undocumented and unused operator+ (master...2004-scriptNoAdd) https://github.com/bitcoin/bitcoin/pull/18612
16:24 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
16:31 < sipa> wumpus: yeah
16:32 < fanquake> monorepo is the way
16:40 -!- shaunsun [shaunsun@gateway/vpn/privateinternetaccess/shaunsun] has joined #bitcoin-core-dev
16:58 -!- rjected [~dan@pool-71-184-77-198.bstnma.fios.verizon.net] has quit [Ping timeout: 260 seconds]
16:58 -!- mytwocentimes [~mytwocent@104.140.54.51] has quit [Remote host closed the connection]
16:59 -!- mytwocentimes [~mytwocent@104.140.54.51] has joined #bitcoin-core-dev
16:59 -!- rjected [~dan@pool-71-184-77-198.bstnma.fios.verizon.net] has joined #bitcoin-core-dev
17:00 -!- [42]1 [~42]@84.39.116.180] has quit []
17:04 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 264 seconds]
17:22 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev
17:22 -!- kbrosnan1 [~kbrosnan@84.39.117.57] has joined #bitcoin-core-dev
17:23 -!- captjakk [~captjakk@174-29-9-247.hlrn.qwest.net] has quit [Quit: Leaving...]
17:24 -!- mol [~molly@unaffiliated/molly] has quit [Ping timeout: 256 seconds]
17:37 -!- shaunsun [shaunsun@gateway/vpn/privateinternetaccess/shaunsun] has quit [Quit: Leaving]
18:22 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Quit: = ""]
18:23 -!- promag [~promag@bl19-22-20.dsl.telepac.pt] has quit [Remote host closed the connection]
18:25 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 250 seconds]
18:27 -!- mol [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
18:33 -!- promag [~promag@bl19-22-20.dsl.telepac.pt] has joined #bitcoin-core-dev
18:38 -!- promag [~promag@bl19-22-20.dsl.telepac.pt] has quit [Ping timeout: 256 seconds]
19:05 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #bitcoin-core-dev
19:33 -!- jarthur [~jarthur@2605:6000:1019:4971:a4cb:2ac8:5aba:91ef] has joined #bitcoin-core-dev
19:36 -!- Highway61 [~Thunderbi@104.129.24.138] has quit [Ping timeout: 265 seconds]
20:00 -!- kbrosnan1 [~kbrosnan@84.39.117.57] has quit []
20:04 -!- TheHoliestRoger [~TheHolies@unaffiliated/theholiestroger] has quit [Ping timeout: 256 seconds]
20:07 -!- TheHoliestRoger [~TheHolies@unaffiliated/theholiestroger] has joined #bitcoin-core-dev
20:15 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
20:15 < bitcoin-git> [bitcoin] fanquake closed pull request #18661: Compress PNG images with `zopflipng`. (master...master) https://github.com/bitcoin/bitcoin/pull/18661
20:15 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
20:22 -!- Fare [~Fare@195.206.183.79] has joined #bitcoin-core-dev
20:22 -!- Fare is now known as Guest44683
20:27 -!- btc_thc [annalee@kosher.marriageiguana.com] has quit [Quit: Buy Bitcoin]
20:29 -!- btc_thc [annalee@kosher.marriageiguana.com] has joined #bitcoin-core-dev
21:09 -!- tryphe_ [~tryphe@unaffiliated/tryphe] has joined #bitcoin-core-dev
21:13 -!- tryphe [~tryphe@unaffiliated/tryphe] has quit [Ping timeout: 250 seconds]
21:30 -!- promag__ [~promag@bl19-22-20.dsl.telepac.pt] has quit [Ping timeout: 258 seconds]
21:33 -!- promag [~promag@Bl19-22-20.dsl.telepac.pt] has joined #bitcoin-core-dev
21:38 -!- promag [~promag@Bl19-22-20.dsl.telepac.pt] has quit [Ping timeout: 260 seconds]
21:41 -!- mol [~molly@unaffiliated/molly] has quit [Ping timeout: 256 seconds]
21:55 -!- Talkless [~Talkless@hst-227-49.splius.lt] has joined #bitcoin-core-dev
21:56 -!- Talkless [~Talkless@hst-227-49.splius.lt] has quit [Client Quit]
22:10 -!- Netsplit *.net <-> *.split quits: jkczyz, _flow_, mrostecki, icota[m], thaumavorio_, NicolasDorier, endogenic, akionak_, mr_burdell
22:15 -!- Netsplit over, joins: mr_burdell, endogenic, NicolasDorier, icota[m], jkczyz, mrostecki, _flow_, akionak_, thaumavorio_
22:18 -!- CubicEarth [~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net] has quit [Ping timeout: 264 seconds]
22:20 -!- CubicEarth [~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net] has joined #bitcoin-core-dev
22:23 -!- Guest44683 [~Fare@195.206.183.79] has quit [Ping timeout: 256 seconds]
22:25 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
22:26 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has joined #bitcoin-core-dev
22:30 -!- APrOn [~APrOn@77.243.177.38] has joined #bitcoin-core-dev
22:32 -!- jarthur [~jarthur@2605:6000:1019:4971:a4cb:2ac8:5aba:91ef] has quit [Remote host closed the connection]
22:54 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
22:54 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has joined #bitcoin-core-dev
22:57 -!- mytwocentimes [~mytwocent@104.140.54.51] has quit [Remote host closed the connection]
22:57 -!- mytwocentimes [~mytwocent@104.140.54.51] has joined #bitcoin-core-dev
22:59 -!- Highway61 [~Thunderbi@104.129.24.138] has joined #bitcoin-core-dev
23:00 -!- APrOn [~APrOn@77.243.177.38] has quit []
23:19 -!- sdaftuar [~sdaftuar@gateway/tor-sasl/sdaftuar] has quit [Remote host closed the connection]
23:19 -!- SiAnDoG_ [~514nDoG@gateway/tor-sasl/siandog] has quit [Remote host closed the connection]
23:19 -!- SiAnDoG_ [~514nDoG@gateway/tor-sasl/siandog] has joined #bitcoin-core-dev
23:20 -!- sdaftuar [~sdaftuar@gateway/tor-sasl/sdaftuar] has joined #bitcoin-core-dev
23:21 -!- alorente [~alorente@184.75.223.227] has joined #bitcoin-core-dev
23:32 -!- sdaftuar [~sdaftuar@gateway/tor-sasl/sdaftuar] has quit [Ping timeout: 240 seconds]
23:37 -!- sdaftuar [~sdaftuar@gateway/tor-sasl/sdaftuar] has joined #bitcoin-core-dev
23:43 -!- ponrpclog [244b402e@36.75.64.46] has joined #bitcoin-core-dev
23:45 -!- ponrpclog [244b402e@36.75.64.46] has quit [Remote host closed the connection]
23:57 -!- mol [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
--- Log closed Fri Apr 17 00:00:54 2020