1 2020-11-12T00:00:01  *** darkbot-rc4 <darkbot-rc4!~darkbot-r@139.28.218.148> has quit IRC ()
  2 2020-11-12T00:01:08  *** gleb2 <gleb2!~gleb@178.150.137.228> has quit IRC (Quit: Ping timeout (120 seconds))
  3 2020-11-12T00:02:18  *** gleb <gleb!~gleb@178.150.137.228> has joined #bitcoin-core-dev
  4 2020-11-12T00:22:22  *** cmeiklejohn1 <cmeiklejohn1!~cmeiklejo@84.39.117.57> has joined #bitcoin-core-dev
  5 2020-11-12T00:25:50  *** Tennis <Tennis!~Tennis@unaffiliated/tennis> has quit IRC (Quit: Leaving)
  6 2020-11-12T00:27:14  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
  7 2020-11-12T00:27:14  <bitcoin-git> [bitcoin] meshcollider pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/d9f5132736f3...c2d8ba6265a4
  8 2020-11-12T00:27:15  <bitcoin-git> bitcoin/master 69f59af Luke Dashjr: Bugfix: Wallet: Soft-fail exceptions within ListWalletDir file checks
  9 2020-11-12T00:27:15  <bitcoin-git> bitcoin/master 24d2d33 Luke Dashjr: QA: wallet_multiwallet: Check that recursive symlink directory and wallet....
 10 2020-11-12T00:27:16  <bitcoin-git> bitcoin/master c2d8ba6 Samuel Dobson: Merge #19502: Bugfix: Wallet: Soft-fail exceptions within ListWalletDir fi...
 11 2020-11-12T00:27:17  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
 12 2020-11-12T00:28:09  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
 13 2020-11-12T00:28:09  <bitcoin-git> [bitcoin] meshcollider merged pull request #19502: Bugfix: Wallet: Soft-fail exceptions within ListWalletDir file checks (master...bugfix_listwalletdir_errors) https://github.com/bitcoin/bitcoin/pull/19502
 14 2020-11-12T00:28:10  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
 15 2020-11-12T00:33:54  *** bitdex <bitdex!~bitdex@gateway/tor-sasl/bitdex> has joined #bitcoin-core-dev
 16 2020-11-12T00:46:18  *** Emcy_ <Emcy_!~Emcy@unaffiliated/emcy> has quit IRC (Read error: Connection reset by peer)
 17 2020-11-12T00:49:10  *** Emcy <Emcy!~Emcy@unaffiliated/emcy> has joined #bitcoin-core-dev
 18 2020-11-12T00:49:37  *** AaronvanW <AaronvanW!~AaronvanW@unaffiliated/aaronvanw> has quit IRC ()
 19 2020-11-12T00:51:10  *** AaronvanW <AaronvanW!~AaronvanW@unaffiliated/aaronvanw> has joined #bitcoin-core-dev
 20 2020-11-12T00:53:45  *** queip <queip!~queip@unaffiliated/rezurus> has quit IRC (Ping timeout: 240 seconds)
 21 2020-11-12T00:57:23  *** k3tan <k3tan!~pi@gateway/tor-sasl/k3tan> has quit IRC (Ping timeout: 240 seconds)
 22 2020-11-12T00:59:59  *** da39a3ee5e6b4b0d <da39a3ee5e6b4b0d!~da39a3ee5@cm-171-98-69-228.revip7.asianet.co.th> has joined #bitcoin-core-dev
 23 2020-11-12T01:05:13  *** k3tan <k3tan!~pi@gateway/tor-sasl/k3tan> has joined #bitcoin-core-dev
 24 2020-11-12T01:06:49  *** da39a3ee5e6b4b0d <da39a3ee5e6b4b0d!~da39a3ee5@cm-171-98-69-228.revip7.asianet.co.th> has quit IRC (Ping timeout: 264 seconds)
 25 2020-11-12T01:10:30  *** da39a3ee5e6b4b0d <da39a3ee5e6b4b0d!~da39a3ee5@cm-171-98-69-228.revip7.asianet.co.th> has joined #bitcoin-core-dev
 26 2020-11-12T01:22:26  *** rc_423 <rc_423!~r_423@cpe-75-185-100-189.cinci.res.rr.com> has joined #bitcoin-core-dev
 27 2020-11-12T01:25:44  *** AaronvanW <AaronvanW!~AaronvanW@unaffiliated/aaronvanw> has quit IRC (Remote host closed the connection)
 28 2020-11-12T01:26:31  *** mrostecki <mrostecki!~mrostecki@gateway/tor-sasl/mrostecki> has quit IRC (Remote host closed the connection)
 29 2020-11-12T01:35:30  *** da39a3ee5e6b4b0d <da39a3ee5e6b4b0d!~da39a3ee5@cm-171-98-69-228.revip7.asianet.co.th> has quit IRC (Ping timeout: 260 seconds)
 30 2020-11-12T01:46:09  *** da39a3ee5e6b4b0d <da39a3ee5e6b4b0d!~da39a3ee5@67.23.55.162> has joined #bitcoin-core-dev
 31 2020-11-12T01:47:58  *** m9aq <m9aq!~m9aq@106.37.187.213> has joined #bitcoin-core-dev
 32 2020-11-12T01:49:22  *** promag <promag!~promag@188.250.84.129> has quit IRC (Remote host closed the connection)
 33 2020-11-12T02:27:11  *** da39a3ee5e6b4b0d <da39a3ee5e6b4b0d!~da39a3ee5@67.23.55.162> has quit IRC (Quit: Textual IRC Client: www.textualapp.com)
 34 2020-11-12T02:30:42  *** bitdex <bitdex!~bitdex@gateway/tor-sasl/bitdex> has quit IRC (Remote host closed the connection)
 35 2020-11-12T02:31:06  *** bitdex <bitdex!~bitdex@gateway/tor-sasl/bitdex> has joined #bitcoin-core-dev
 36 2020-11-12T02:34:52  *** AaronvanW <AaronvanW!~AaronvanW@unaffiliated/aaronvanw> has joined #bitcoin-core-dev
 37 2020-11-12T02:37:44  *** da39a3ee5e6b4b0d <da39a3ee5e6b4b0d!~da39a3ee5@cm-171-98-69-228.revip7.asianet.co.th> has joined #bitcoin-core-dev
 38 2020-11-12T02:45:31  *** glozow <glozow!uid453516@gateway/web/irccloud.com/x-xodpewyyywlkchym> has quit IRC (Quit: Connection closed for inactivity)
 39 2020-11-12T02:50:31  *** queip <queip!~queip@unaffiliated/rezurus> has joined #bitcoin-core-dev
 40 2020-11-12T03:00:01  *** cmeiklejohn1 <cmeiklejohn1!~cmeiklejo@84.39.117.57> has quit IRC ()
 41 2020-11-12T03:05:34  *** AaronvanW <AaronvanW!~AaronvanW@unaffiliated/aaronvanw> has quit IRC (Ping timeout: 260 seconds)
 42 2020-11-12T03:19:29  *** da39a3ee5e6b4b0d <da39a3ee5e6b4b0d!~da39a3ee5@cm-171-98-69-228.revip7.asianet.co.th> has quit IRC (Ping timeout: 265 seconds)
 43 2020-11-12T03:23:12  *** true-asset <true-asset!~true-asse@84.39.117.57> has joined #bitcoin-core-dev
 44 2020-11-12T03:26:50  *** m9aq_ <m9aq_!~m9aq@106.37.187.213> has joined #bitcoin-core-dev
 45 2020-11-12T03:28:21  *** m9aq <m9aq!~m9aq@106.37.187.213> has quit IRC (Ping timeout: 258 seconds)
 46 2020-11-12T03:28:21  *** m9aq_ is now known as m9aq
 47 2020-11-12T03:38:14  *** gribble <gribble!~gribble@unaffiliated/nanotube/bot/gribble> has quit IRC (Remote host closed the connection)
 48 2020-11-12T03:54:02  *** belcher_ <belcher_!~belcher@unaffiliated/belcher> has joined #bitcoin-core-dev
 49 2020-11-12T03:56:46  *** belcher <belcher!~belcher@unaffiliated/belcher> has quit IRC (Ping timeout: 272 seconds)
 50 2020-11-12T04:04:04  *** kristapsk <kristapsk!~KK@gateway/tor-sasl/kristapsk> has quit IRC (Remote host closed the connection)
 51 2020-11-12T04:08:28  *** kristapsk <kristapsk!~KK@gateway/tor-sasl/kristapsk> has joined #bitcoin-core-dev
 52 2020-11-12T04:11:29  *** kexkey <kexkey!~kexkey@static-198-54-132-153.cust.tzulo.com> has quit IRC (Ping timeout: 260 seconds)
 53 2020-11-12T04:16:42  *** gribble <gribble!~gribble@unaffiliated/nanotube/bot/gribble> has joined #bitcoin-core-dev
 54 2020-11-12T04:38:09  *** Asbestos_Vapor <Asbestos_Vapor!~Mercury_V@174-082-166-092.res.spectrum.com> has quit IRC (Read error: Connection reset by peer)
 55 2020-11-12T04:41:24  *** DeanGuss <DeanGuss!~dean@gateway/tor-sasl/deanguss> has joined #bitcoin-core-dev
 56 2020-11-12T04:43:43  *** DeanWeen <DeanWeen!~dean@gateway/tor-sasl/deanguss> has quit IRC (Ping timeout: 240 seconds)
 57 2020-11-12T04:54:43  *** Deacyde <Deacyde!~Deacyde@unaffiliated/deacyde> has quit IRC (Quit: May the Shwartz be with you)
 58 2020-11-12T05:02:32  *** AaronvanW <AaronvanW!~AaronvanW@unaffiliated/aaronvanw> has joined #bitcoin-core-dev
 59 2020-11-12T05:06:23  *** tryphe <tryphe!~tryphe@unaffiliated/tryphe> has joined #bitcoin-core-dev
 60 2020-11-12T05:07:47  *** tryphe_ <tryphe_!~tryphe@unaffiliated/tryphe> has quit IRC (Ping timeout: 260 seconds)
 61 2020-11-12T05:11:26  *** justanotheruser <justanotheruser!~justanoth@unaffiliated/justanotheruser> has quit IRC (Ping timeout: 264 seconds)
 62 2020-11-12T05:18:07  *** justanotheruser <justanotheruser!~justanoth@unaffiliated/justanotheruser> has joined #bitcoin-core-dev
 63 2020-11-12T05:36:16  *** AaronvanW <AaronvanW!~AaronvanW@unaffiliated/aaronvanw> has quit IRC (Ping timeout: 265 seconds)
 64 2020-11-12T05:42:42  *** visage_ <visage_!~visage_@unaffiliated/visage/x-6658724> has quit IRC (Quit: Textual IRC Client: www.textualapp.com)
 65 2020-11-12T05:44:37  *** m9aq <m9aq!~m9aq@106.37.187.213> has quit IRC (Ping timeout: 264 seconds)
 66 2020-11-12T05:44:52  *** m9aq <m9aq!~m9aq@106.37.187.213> has joined #bitcoin-core-dev
 67 2020-11-12T06:00:01  *** true-asset <true-asset!~true-asse@84.39.117.57> has quit IRC ()
 68 2020-11-12T06:02:53  *** EagleTM <EagleTM!~EagleTM@unaffiliated/eagletm> has joined #bitcoin-core-dev
 69 2020-11-12T06:08:28  *** bosch-0 <bosch-0!uid472282@gateway/web/irccloud.com/x-gjvbqlqofnghqnkw> has joined #bitcoin-core-dev
 70 2020-11-12T06:11:03  *** az0re <az0re!~az0re@gateway/tor-sasl/az0re> has quit IRC (Ping timeout: 240 seconds)
 71 2020-11-12T06:22:38  *** slewis <slewis!~slewis@178.162.212.214> has joined #bitcoin-core-dev
 72 2020-11-12T06:33:24  *** Bullit <Bullit!~Bullit01@042-236-158-163.dynamic.caiway.nl> has joined #bitcoin-core-dev
 73 2020-11-12T06:56:19  *** az0re <az0re!~az0re@gateway/tor-sasl/az0re> has joined #bitcoin-core-dev
 74 2020-11-12T06:57:09  *** m9aq <m9aq!~m9aq@106.37.187.213> has quit IRC (Ping timeout: 260 seconds)
 75 2020-11-12T07:28:08  *** andrewtoth_ <andrewtoth_!~andrewtot@gateway/tor-sasl/andrewtoth> has joined #bitcoin-core-dev
 76 2020-11-12T07:30:19  *** _andrewtoth_ <_andrewtoth_!~andrewtot@gateway/tor-sasl/andrewtoth> has quit IRC (Remote host closed the connection)
 77 2020-11-12T07:33:08  *** AaronvanW <AaronvanW!~AaronvanW@unaffiliated/aaronvanw> has joined #bitcoin-core-dev
 78 2020-11-12T07:44:04  *** queip <queip!~queip@unaffiliated/rezurus> has quit IRC (Ping timeout: 246 seconds)
 79 2020-11-12T07:45:07  *** yanmaani <yanmaani!~yanmaani@gateway/tor-sasl/yanmaani> has joined #bitcoin-core-dev
 80 2020-11-12T07:48:10  *** queip <queip!~queip@unaffiliated/rezurus> has joined #bitcoin-core-dev
 81 2020-11-12T07:52:51  <hebasto> it seems merged #19502 resolves all issues of #18095, so the latter could be closed.
 82 2020-11-12T07:52:53  <gribble> https://github.com/bitcoin/bitcoin/issues/19502 | Bugfix: Wallet: Soft-fail exceptions within ListWalletDir file checks by luke-jr · Pull Request #19502 · bitcoin/bitcoin · GitHub
 83 2020-11-12T07:52:55  <gribble> https://github.com/bitcoin/bitcoin/issues/18095 | Fix crashes and infinite loop in ListWalletDir() by uhliksk · Pull Request #18095 · bitcoin/bitcoin · GitHub
 84 2020-11-12T07:55:12  *** tryphe_ <tryphe_!~tryphe@unaffiliated/tryphe> has joined #bitcoin-core-dev
 85 2020-11-12T07:55:45  *** tryphe <tryphe!~tryphe@unaffiliated/tryphe> has quit IRC (Ping timeout: 240 seconds)
 86 2020-11-12T08:03:57  *** Kiminuo <Kiminuo!~mix@141.98.103.92> has joined #bitcoin-core-dev
 87 2020-11-12T08:04:33  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
 88 2020-11-12T08:04:33  <bitcoin-git> [bitcoin] fanquake closed pull request #18095: Fix crashes and infinite loop in ListWalletDir() (master...master) https://github.com/bitcoin/bitcoin/pull/18095
 89 2020-11-12T08:04:35  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
 90 2020-11-12T08:06:28  *** AaronvanW <AaronvanW!~AaronvanW@unaffiliated/aaronvanw> has quit IRC (Ping timeout: 246 seconds)
 91 2020-11-12T08:17:38  *** bosch-0 <bosch-0!uid472282@gateway/web/irccloud.com/x-gjvbqlqofnghqnkw> has quit IRC (Quit: Connection closed for inactivity)
 92 2020-11-12T08:28:06  *** Guyver2 <Guyver2!Guyver@guyver2.xs4all.nl> has joined #bitcoin-core-dev
 93 2020-11-12T08:34:49  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
 94 2020-11-12T08:34:50  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/c2d8ba6265a4...bcd142e479fa
 95 2020-11-12T08:34:50  <bitcoin-git> bitcoin/master c82336c fanquake: Remove references to CreateWalletFromFile
 96 2020-11-12T08:34:51  <bitcoin-git> bitcoin/master bcd142e MarcoFalke: Merge #20285: Remove references to CreateWalletFromFile
 97 2020-11-12T08:34:53  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
 98 2020-11-12T08:35:09  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
 99 2020-11-12T08:35:09  <bitcoin-git> [bitcoin] MarcoFalke merged pull request #20285: Remove references to CreateWalletFromFile (master...createwalletfromfilenomore) https://github.com/bitcoin/bitcoin/pull/20285
100 2020-11-12T08:35:10  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
101 2020-11-12T08:36:44  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
102 2020-11-12T08:36:44  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/bcd142e479fa...027e51f71517
103 2020-11-12T08:36:44  <bitcoin-git> bitcoin/master ee11a41 practicalswift: Avoid signed integer overflow when loading a mempool.dat file with a malfo...
104 2020-11-12T08:36:45  <bitcoin-git> bitcoin/master 027e51f MarcoFalke: Merge #20372: Avoid signed integer overflow when loading a mempool.dat fil...
105 2020-11-12T08:36:46  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
106 2020-11-12T08:37:04  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
107 2020-11-12T08:37:04  <bitcoin-git> [bitcoin] MarcoFalke merged pull request #20372: Avoid signed integer overflow when loading a mempool.dat file with a malformed time field (master...load-mempool-time-integer-overflow) https://github.com/bitcoin/bitcoin/pull/20372
108 2020-11-12T08:37:06  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
109 2020-11-12T08:39:52  *** promag <promag!~promag@188.250.84.129> has joined #bitcoin-core-dev
110 2020-11-12T08:45:40  *** da39a3ee5e6b4b0d <da39a3ee5e6b4b0d!~da39a3ee5@cm-171-98-69-228.revip7.asianet.co.th> has joined #bitcoin-core-dev
111 2020-11-12T08:45:53  *** IGHOR <IGHOR!~quassel@176.121.4.135> has quit IRC (Quit: No Ping reply in 180 seconds.)
112 2020-11-12T08:48:01  *** IGHOR <IGHOR!~quassel@176.121.4.135> has joined #bitcoin-core-dev
113 2020-11-12T08:58:11  *** AdulrunaRedviva <AdulrunaRedviva!c3d69d22@195.214.157.34> has joined #bitcoin-core-dev
114 2020-11-12T08:59:48  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
115 2020-11-12T08:59:48  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/027e51f71517...af8ec1d3e576
116 2020-11-12T08:59:48  <bitcoin-git> bitcoin/master 3c77b80 practicalswift: fuzz: Improve coverage for CPartialMerkleTree fuzzing harness
117 2020-11-12T08:59:49  <bitcoin-git> bitcoin/master af8ec1d MarcoFalke: Merge #20375: fuzz: Improve coverage for CPartialMerkleTree fuzzing harnes...
118 2020-11-12T08:59:50  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
119 2020-11-12T09:00:01  *** slewis <slewis!~slewis@178.162.212.214> has quit IRC ()
120 2020-11-12T09:00:05  *** icota[m] <icota[m]!icotamatri@gateway/shell/matrix.org/x-jfxechrxuoddrluf> has quit IRC (Quit: Idle for 30+ days)
121 2020-11-12T09:00:08  *** da39a3ee5e6b4b0d <da39a3ee5e6b4b0d!~da39a3ee5@cm-171-98-69-228.revip7.asianet.co.th> has quit IRC (Ping timeout: 272 seconds)
122 2020-11-12T09:00:08  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
123 2020-11-12T09:00:08  <bitcoin-git> [bitcoin] MarcoFalke merged pull request #20375: fuzz: Improve coverage for CPartialMerkleTree fuzzing harness (master...fuzzers-2020-11-11) https://github.com/bitcoin/bitcoin/pull/20375
124 2020-11-12T09:00:09  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
125 2020-11-12T09:09:06  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
126 2020-11-12T09:09:06  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/af8ec1d3e576...8a486158cbc3
127 2020-11-12T09:09:07  <bitcoin-git> bitcoin/master 79ef832 practicalswift: tests: Add fuzzing harness for CConnman
128 2020-11-12T09:09:07  <bitcoin-git> bitcoin/master 8a48615 MarcoFalke: Merge #20188: tests: Add fuzzing harness for CConnman
129 2020-11-12T09:09:08  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
130 2020-11-12T09:09:26  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
131 2020-11-12T09:09:26  <bitcoin-git> [bitcoin] MarcoFalke merged pull request #20188: tests: Add fuzzing harness for CConnman (master...fuzzers-connman) https://github.com/bitcoin/bitcoin/pull/20188
132 2020-11-12T09:09:27  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
133 2020-11-12T09:14:25  *** Victorsueca <Victorsueca!~Victorsue@unaffiliated/victorsueca> has quit IRC (Ping timeout: 240 seconds)
134 2020-11-12T09:20:32  *** opsec_x12 <opsec_x12!~opsec_x12@44-25-143-49.ip.hamwan.net> has joined #bitcoin-core-dev
135 2020-11-12T09:24:18  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
136 2020-11-12T09:24:18  <bitcoin-git> [gui] hebasto closed pull request #127: Replace QMetaObject::invokeMethod with atomic operations (master...201102-queued) https://github.com/bitcoin-core/gui/pull/127
137 2020-11-12T09:24:19  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
138 2020-11-12T09:29:49  *** luke-jr <luke-jr!~luke-jr@unaffiliated/luke-jr> has quit IRC (Quit: ZNC - http://znc.sourceforge.net)
139 2020-11-12T09:30:13  *** luke-jr <luke-jr!~luke-jr@unaffiliated/luke-jr> has joined #bitcoin-core-dev
140 2020-11-12T09:36:09  *** promag <promag!~promag@188.250.84.129> has quit IRC (Remote host closed the connection)
141 2020-11-12T09:39:11  *** promag <promag!~promag@188.250.84.129> has joined #bitcoin-core-dev
142 2020-11-12T09:44:34  *** jeremyrubin <jeremyrubin!~jr@c-73-15-215-148.hsd1.ca.comcast.net> has quit IRC (Ping timeout: 260 seconds)
143 2020-11-12T09:56:06  *** tsmango <tsmango!~tsmango@178.239.168.171> has joined #bitcoin-core-dev
144 2020-11-12T10:02:46  *** sr_gi <sr_gi!~sr_gi@static-120-201-229-77.ipcom.comunitel.net> has quit IRC (Read error: Connection reset by peer)
145 2020-11-12T10:03:23  *** sr_gi <sr_gi!~sr_gi@static-120-201-229-77.ipcom.comunitel.net> has joined #bitcoin-core-dev
146 2020-11-12T10:03:58  *** AaronvanW <AaronvanW!~AaronvanW@unaffiliated/aaronvanw> has joined #bitcoin-core-dev
147 2020-11-12T10:08:48  *** vasild_ <vasild_!~vd@gateway/tor-sasl/vasild> has joined #bitcoin-core-dev
148 2020-11-12T10:08:58  *** troygiorshev <troygiorshev!~troygiors@d67-193-140-136.home3.cgocable.net> has quit IRC (Ping timeout: 246 seconds)
149 2020-11-12T10:12:03  *** vasild <vasild!~vd@gateway/tor-sasl/vasild> has quit IRC (Ping timeout: 240 seconds)
150 2020-11-12T10:12:04  *** vasild_ is now known as vasild
151 2020-11-12T10:28:09  *** AdulrunaRedviva <AdulrunaRedviva!c3d69d22@195.214.157.34> has quit IRC (Remote host closed the connection)
152 2020-11-12T10:31:22  *** da39a3ee5e6b4b0d <da39a3ee5e6b4b0d!~da39a3ee5@cm-171-98-69-228.revip7.asianet.co.th> has joined #bitcoin-core-dev
153 2020-11-12T10:56:53  *** AdulrunaRedviva <AdulrunaRedviva!c3d69d22@195.214.157.34> has joined #bitcoin-core-dev
154 2020-11-12T10:59:25  *** Guyver2_ <Guyver2_!Guyver@guyver2.xs4all.nl> has joined #bitcoin-core-dev
155 2020-11-12T11:01:11  *** Lexyon____ <Lexyon____!sid402723@gateway/web/irccloud.com/x-xzmxwubdunekjens> has quit IRC (Quit: Connection closed for inactivity)
156 2020-11-12T11:01:12  *** wonderworker <wonderworker!bc2b8820@188.43.136.32> has joined #bitcoin-core-dev
157 2020-11-12T11:01:51  *** wonderworker <wonderworker!bc2b8820@188.43.136.32> has left #bitcoin-core-dev
158 2020-11-12T11:02:22  *** Guyver2 <Guyver2!Guyver@guyver2.xs4all.nl> has quit IRC (Ping timeout: 256 seconds)
159 2020-11-12T11:02:43  <jonatack> Sorry to have been reviewing less than usual the past week. After spending time chopping wood on it, #20305 "wallet: introduce fee_rate sat/vB param/option" should be ready for final review for 0.21.
160 2020-11-12T11:02:46  <gribble> https://github.com/bitcoin/bitcoin/issues/20305 | wallet: introduce fee_rate sat/vB param/option by jonatack · Pull Request #20305 · bitcoin/bitcoin · GitHub
161 2020-11-12T11:05:15  <jonatack> Thanks to murch and achow101 for reviewing it so far.
162 2020-11-12T11:16:56  *** Kiminuo <Kiminuo!~mix@141.98.103.92> has quit IRC (Ping timeout: 272 seconds)
163 2020-11-12T11:18:06  *** AaronvanW <AaronvanW!~AaronvanW@unaffiliated/aaronvanw> has quit IRC (Remote host closed the connection)
164 2020-11-12T11:18:22  *** AaronvanW <AaronvanW!~AaronvanW@unaffiliated/aaronvanw> has joined #bitcoin-core-dev
165 2020-11-12T11:18:26  *** Aniyah8Lubowitz <Aniyah8Lubowitz!~Aniyah8Lu@static.57.1.216.95.clients.your-server.de> has joined #bitcoin-core-dev
166 2020-11-12T11:24:34  *** mrostecki <mrostecki!~mrostecki@gateway/tor-sasl/mrostecki> has joined #bitcoin-core-dev
167 2020-11-12T11:24:36  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
168 2020-11-12T11:24:36  <bitcoin-git> [gui] jonasschnelli merged pull request #120: Fix multiwallet transaction notifications (master...2020-10-fix-transaction-notifications) https://github.com/bitcoin-core/gui/pull/120
169 2020-11-12T11:24:37  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
170 2020-11-12T11:24:51  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
171 2020-11-12T11:24:52  <bitcoin-git> [bitcoin] jonasschnelli pushed 4 commits to master: https://github.com/bitcoin/bitcoin/compare/8a486158cbc3...9bd131669729
172 2020-11-12T11:24:53  <bitcoin-git> bitcoin/master 7b3b230 João Barbosa: move-only: Define TransactionNotification before  TransactionTablePriv
173 2020-11-12T11:24:54  <bitcoin-git> bitcoin/master 989e579 João Barbosa: qt: Make transaction notification queue wallet specific
174 2020-11-12T11:24:55  <bitcoin-git> bitcoin/master 2414342 João Barbosa: refactor: qt: Use vQueueNotifications.clear()
175 2020-11-12T11:24:56  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
176 2020-11-12T11:34:15  *** kristapsk <kristapsk!~KK@gateway/tor-sasl/kristapsk> has quit IRC (Remote host closed the connection)
177 2020-11-12T11:34:41  *** kristapsk <kristapsk!~KK@gateway/tor-sasl/kristapsk> has joined #bitcoin-core-dev
178 2020-11-12T11:35:21  *** AdulrunaRedviva5 <AdulrunaRedviva5!c3d69d22@195.214.157.34> has joined #bitcoin-core-dev
179 2020-11-12T11:35:28  *** AdulrunaRedviva5 <AdulrunaRedviva5!c3d69d22@195.214.157.34> has left #bitcoin-core-dev
180 2020-11-12T11:38:25  *** AdulrunaRedviva <AdulrunaRedviva!c3d69d22@195.214.157.34> has quit IRC (Ping timeout: 245 seconds)
181 2020-11-12T11:44:15  *** Guyver2__ <Guyver2__!Guyver@guyver2.xs4all.nl> has joined #bitcoin-core-dev
182 2020-11-12T11:47:08  *** Guyver2_ <Guyver2_!Guyver@guyver2.xs4all.nl> has quit IRC (Ping timeout: 256 seconds)
183 2020-11-12T11:49:36  *** einyx <einyx!einyx@fsf/member/einyx> has joined #bitcoin-core-dev
184 2020-11-12T11:50:31  *** einyx_ <einyx_!einyx@fsf/member/einyx> has quit IRC (Ping timeout: 258 seconds)
185 2020-11-12T12:00:01  *** tsmango <tsmango!~tsmango@178.239.168.171> has quit IRC ()
186 2020-11-12T12:01:39  *** da39a3ee5e6b4b0d <da39a3ee5e6b4b0d!~da39a3ee5@cm-171-98-69-228.revip7.asianet.co.th> has quit IRC (Ping timeout: 256 seconds)
187 2020-11-12T12:02:18  *** belcher_ is now known as belcher
188 2020-11-12T12:16:43  *** Kiminuo <Kiminuo!~mix@141.98.103.92> has joined #bitcoin-core-dev
189 2020-11-12T12:19:47  *** Aniyah8Lubowitz <Aniyah8Lubowitz!~Aniyah8Lu@static.57.1.216.95.clients.your-server.de> has quit IRC (Ping timeout: 256 seconds)
190 2020-11-12T12:21:53  *** kristapsk_ <kristapsk_!~KK@gateway/tor-sasl/kristapsk> has joined #bitcoin-core-dev
191 2020-11-12T12:24:03  *** kristapsk <kristapsk!~KK@gateway/tor-sasl/kristapsk> has quit IRC (Ping timeout: 240 seconds)
192 2020-11-12T12:30:51  <vasild> MarcoFalke: one of the test runs on https://github.com/bitcoin/bitcoin/pull/20284 is timing out, I restarted it 2 times, hmm
193 2020-11-12T12:32:03  <MarcoFalke> vasild: Can be ignored
194 2020-11-12T12:32:11  <MarcoFalke> Fix would be to rebase on current master, but we don't want that
195 2020-11-12T12:33:05  <vasild> cirrus is not merging the tip of the PR into latest master before testing, like travis?
196 2020-11-12T12:37:01  <MarcoFalke> not for the config
197 2020-11-12T12:37:08  <vasild> ok
198 2020-11-12T12:37:10  <MarcoFalke> Though the code is merged in the merge_base step
199 2020-11-12T12:49:54  *** Tennis <Tennis!~Tennis@unaffiliated/tennis> has joined #bitcoin-core-dev
200 2020-11-12T12:50:53  *** DeanWeen <DeanWeen!~dean@gateway/tor-sasl/deanguss> has joined #bitcoin-core-dev
201 2020-11-12T12:53:03  *** DeanGuss <DeanGuss!~dean@gateway/tor-sasl/deanguss> has quit IRC (Ping timeout: 240 seconds)
202 2020-11-12T12:54:37  *** tw1sted1 <tw1sted1!~tw1sted@195.206.169.184> has joined #bitcoin-core-dev
203 2020-11-12T12:56:18  *** morcos <morcos!~morcos@gateway/tor-sasl/morcos> has quit IRC (Remote host closed the connection)
204 2020-11-12T12:56:50  *** einyx <einyx!einyx@fsf/member/einyx> has quit IRC (Read error: Connection reset by peer)
205 2020-11-12T12:57:01  *** morcos <morcos!~morcos@gateway/tor-sasl/morcos> has joined #bitcoin-core-dev
206 2020-11-12T13:01:32  *** einyx <einyx!einyx@fsf/member/einyx> has joined #bitcoin-core-dev
207 2020-11-12T13:06:31  *** Mercury_Vapor <Mercury_Vapor!~Mercury_V@174-082-166-092.res.spectrum.com> has joined #bitcoin-core-dev
208 2020-11-12T13:07:29  *** glozow <glozow!uid453516@gateway/web/irccloud.com/x-bxytrqtdrqgdakox> has joined #bitcoin-core-dev
209 2020-11-12T13:23:36  <jonasschnelli> MarcoFalke: as for the devision by 0 in wallet.cpp, ... any idea why cirrus is not triggering the UndefinedBehaviorSanitizer error?
210 2020-11-12T13:24:51  <queip> recommended nomenclature for keys is: SK - secret key, PK - public key, HPK - hash  of PK, right?
211 2020-11-12T13:31:56  *** Guyver2__ is now known as Guyver2
212 2020-11-12T13:35:25  *** filchef <filchef!~filchef@212.104.97.177> has joined #bitcoin-core-dev
213 2020-11-12T13:44:47  <MarcoFalke> jonasschnelli: Nope. How is your config different from ./ci/test/00_setup_env_native_asan.sh ?
214 2020-11-12T13:45:44  <MarcoFalke> the ci config is running Ubuntu focal
215 2020-11-12T13:47:05  <jonasschnelli> I guess clang 8 (bbb) vs 10 (cirrus) should not make a difference
216 2020-11-12T13:47:35  <jonasschnelli> bbb doesn't set -DARENA_DEBUG
217 2020-11-12T14:08:22  *** einyx_ <einyx_!einyx@fsf/member/einyx> has joined #bitcoin-core-dev
218 2020-11-12T14:09:04  *** einyx <einyx!einyx@fsf/member/einyx> has quit IRC (Ping timeout: 246 seconds)
219 2020-11-12T14:17:04  <shesek> which block validity rules can be validated by spv clients?
220 2020-11-12T14:17:16  <shesek> the ones I have in mind is checking that the previous block hash connects properly, that the nonce matches the target bits, that the target bits match the last difficulty readjustment, that the difficulty readjustments themselves are valid, and the MTP rule. what more am I missing?
221 2020-11-12T14:28:25  *** bitdex <bitdex!~bitdex@gateway/tor-sasl/bitdex> has quit IRC (Quit: = "")
222 2020-11-12T14:34:07  *** shesek <shesek!~shesek@unaffiliated/shesek> has quit IRC (Remote host closed the connection)
223 2020-11-12T14:36:46  *** shesek <shesek!~shesek@unaffiliated/shesek> has joined #bitcoin-core-dev
224 2020-11-12T14:36:55  *** Emcy <Emcy!~Emcy@unaffiliated/emcy> has quit IRC (Read error: Connection reset by peer)
225 2020-11-12T14:37:21  *** wullon <wullon!~wullon@241.243.86.88.rdns.comcable.net> has quit IRC (Read error: Connection reset by peer)
226 2020-11-12T14:37:42  <shesek> (I got disconnected and didn't see replies if there were any)
227 2020-11-12T14:38:04  *** wullon <wullon!~wullon@241.243.86.88.rdns.comcable.net> has joined #bitcoin-core-dev
228 2020-11-12T14:45:23  *** Emcy <Emcy!~Emcy@unaffiliated/emcy> has joined #bitcoin-core-dev
229 2020-11-12T14:51:48  *** kexkey <kexkey!~kexkey@static-198-54-132-137.cust.tzulo.com> has joined #bitcoin-core-dev
230 2020-11-12T15:00:01  *** tw1sted1 <tw1sted1!~tw1sted@195.206.169.184> has quit IRC ()
231 2020-11-12T15:18:54  <jonasschnelli> shesek: there where non. :)
232 2020-11-12T15:20:25  <jonasschnelli> shesek: looks like you have a relatively complete list of what measures you can take when not validating the chain
233 2020-11-12T15:20:39  <Kiminuo> shesek, see http://gnusha.org/bitcoin-core-dev/2020-11-12.log
234 2020-11-12T15:20:41  <jonasschnelli> but I recommend to join #bitcoin-dev
235 2020-11-12T15:20:55  <jonasschnelli> this channel is for bitcoin core development
236 2020-11-12T15:21:26  *** SLNP <SLNP!~SLNP@89.249.74.218> has joined #bitcoin-core-dev
237 2020-11-12T15:25:23  *** jeremyrubin <jeremyrubin!~jr@c-73-15-215-148.hsd1.ca.comcast.net> has joined #bitcoin-core-dev
238 2020-11-12T15:26:13  <shesek> jonasschnelli, of course, apologies for going off topic, will take notice next time
239 2020-11-12T15:27:21  <shesek> honestly I kinda knew it, its just that #bitcoin-dev appears pretty much dead, all my scrollback there is join/part/quit messages
240 2020-11-12T15:27:58  <jonasschnelli> shesek: yeah.. maybe also #bitcoin can help
241 2020-11-12T15:28:09  <jonasschnelli> luke-jr have made some thought on that AFAIK.
242 2020-11-12T15:28:15  <jonasschnelli> (on your SPV question).
243 2020-11-12T15:28:21  <pinheadmz> #bitcoin is basically /r/bitcoin
244 2020-11-12T15:28:23  <jonasschnelli> Also look at BIP180 (https://github.com/bitcoin/bips/blob/master/bip-0180.mediawiki)
245 2020-11-12T15:28:31  <pinheadmz> shesek ive gotten a  lot of great help from #bitcoin-core-pr-reviews
246 2020-11-12T15:29:19  *** SLNP <SLNP!~SLNP@89.249.74.218> has quit IRC (Ping timeout: 260 seconds)
247 2020-11-12T15:29:38  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
248 2020-11-12T15:29:39  <bitcoin-git> [bitcoin] practicalswift opened pull request #20377: fuzz: Fill various small fuzzing gaps (master...fuzzers-2020-11-12) https://github.com/bitcoin/bitcoin/pull/20377
249 2020-11-12T15:29:47  <shesek> pinheadmz, is off topic considered okay there when there isn't a meeting going on?
250 2020-11-12T15:29:48  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
251 2020-11-12T15:29:59  <pinheadmz> yup, get in there
252 2020-11-12T15:30:27  <shesek> jonasschnelli, iirc luke-jr ended up finding some issue with his proposed weight fraud proof mechanism, no?
253 2020-11-12T15:30:49  <jonasschnelli> probably,.. I haven't followed and can't recall
254 2020-11-12T15:39:21  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
255 2020-11-12T15:39:21  <bitcoin-git> [bitcoin] jonasschnelli opened pull request #20378: fix potential devision by 0 (master...2020/11/fix_devnull_wallet) https://github.com/bitcoin/bitcoin/pull/20378
256 2020-11-12T15:39:22  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
257 2020-11-12T15:57:54  <warren> jonasschnelli: btw whatever happened to BIP150/151. Looking at BIPs now I don't see a replacement that supersedes them?
258 2020-11-12T15:58:21  <jonasschnelli> warren: BIP324
259 2020-11-12T15:58:26  <jonasschnelli> We are currently altering the AEAD though (make it simpler)
260 2020-11-12T15:58:55  <warren> URL to draft?
261 2020-11-12T15:58:57  <jonasschnelli> https://github.com/bitcoin/bips/pull/1024
262 2020-11-12T15:59:08  <jonasschnelli> discussions also here: https://gist.github.com/jonasschnelli/c530ea8421b8d0e80c51486325587c52#ChaCha20Poly1305Bitcoin_Cipher_Suite
263 2020-11-12T15:59:35  <jonasschnelli> we're getting there... I hope it will not take another 4 years. :)
264 2020-11-12T16:05:01  <warren> thanks just had to point at it as an example
265 2020-11-12T16:06:45  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
266 2020-11-12T16:06:46  <bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/9bd131669729...0bd4929cd00e
267 2020-11-12T16:06:46  <bitcoin-git> bitcoin/master 38ada89 Vasil Dimov: addrman: ensure old versions don't parse peers.dat
268 2020-11-12T16:06:47  <bitcoin-git> bitcoin/master 0bd4929 Wladimir J. van der Laan: Merge #20284: addrman: ensure old versions don't parse peers.dat
269 2020-11-12T16:06:49  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
270 2020-11-12T16:07:05  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
271 2020-11-12T16:07:05  <bitcoin-git> [bitcoin] laanwj merged pull request #20284: addrman: ensure old versions don't parse peers.dat (master...peers_dat_format) https://github.com/bitcoin/bitcoin/pull/20284
272 2020-11-12T16:07:06  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
273 2020-11-12T16:07:15  <vasild> \o/
274 2020-11-12T16:57:12  *** Guyver2_ <Guyver2_!Guyver@guyver2.xs4all.nl> has joined #bitcoin-core-dev
275 2020-11-12T16:58:25  *** Guyver2 <Guyver2!Guyver@guyver2.xs4all.nl> has quit IRC (Ping timeout: 264 seconds)
276 2020-11-12T16:59:41  *** mrd <mrd!~mrd@185.163.110.116> has joined #bitcoin-core-dev
277 2020-11-12T17:14:11  *** Guyver2_ is now known as Guyver2
278 2020-11-12T17:16:13  *** nanotube <nanotube!~nanotube@unaffiliated/nanotube> has quit IRC (Ping timeout: 256 seconds)
279 2020-11-12T17:21:16  *** Talkless <Talkless!~Talkless@mail.dargis.net> has joined #bitcoin-core-dev
280 2020-11-12T17:37:26  *** brianhoffman <brianhoffman!~brianhoff@pool-71-191-34-154.washdc.fios.verizon.net> has quit IRC (Quit: brianhoffman)
281 2020-11-12T17:41:04  *** Emcy <Emcy!~Emcy@unaffiliated/emcy> has quit IRC (Ping timeout: 256 seconds)
282 2020-11-12T17:47:10  *** DeanWeen <DeanWeen!~dean@gateway/tor-sasl/deanguss> has quit IRC (Remote host closed the connection)
283 2020-11-12T17:47:35  *** DeanWeen <DeanWeen!~dean@gateway/tor-sasl/deanguss> has joined #bitcoin-core-dev
284 2020-11-12T17:50:49  *** Emcy <Emcy!~Emcy@unaffiliated/emcy> has joined #bitcoin-core-dev
285 2020-11-12T17:54:47  *** nanotube <nanotube!~nanotube@unaffiliated/nanotube> has joined #bitcoin-core-dev
286 2020-11-12T18:00:01  *** mrd <mrd!~mrd@185.163.110.116> has quit IRC ()
287 2020-11-12T18:02:43  *** yanmaani <yanmaani!~yanmaani@gateway/tor-sasl/yanmaani> has quit IRC (Ping timeout: 240 seconds)
288 2020-11-12T18:19:08  *** dviola <dviola!~diego@unaffiliated/dviola> has joined #bitcoin-core-dev
289 2020-11-12T18:21:07  *** kierank1 <kierank1!~kierank@184.75.221.35> has joined #bitcoin-core-dev
290 2020-11-12T18:32:16  <jnewbery> #proposedmeetingtopic limiting C++17 feature usage (see https://github.com/bitcoin/bitcoin/issues/16684#issuecomment-726214696)
291 2020-11-12T18:37:25  *** promag <promag!~promag@188.250.84.129> has quit IRC (Remote host closed the connection)
292 2020-11-12T18:40:40  *** ja <ja!janus@anubis.0x90.dk> has joined #bitcoin-core-dev
293 2020-11-12T18:41:01  <ja> luke-jr: rhel 8 and fc30 was patched in february according to https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1864864/comments/2
294 2020-11-12T18:41:43  <ja> luke-jr: writing you here since the thread is already getting really long and i don't wanna add a comment which is answering a question already answered in a posted link
295 2020-11-12T18:46:46  <provoostenator> Looks like Btcd is allergic to sendaddrv2: https://github.com/btcsuite/btcd/issues/1661 (cc roasbeef)
296 2020-11-12T18:48:49  <provoostenator> (I should try an earlier version just to make sure it's not something else...)
297 2020-11-12T18:49:29  *** lightlike <lightlike!~lightlike@p200300c7ef1a1b00c04f02a7739a7f7b.dip0.t-ipconnect.de> has joined #bitcoin-core-dev
298 2020-11-12T18:51:27  *** mrostecki <mrostecki!~mrostecki@gateway/tor-sasl/mrostecki> has quit IRC (Remote host closed the connection)
299 2020-11-12T18:51:36  *** luke <luke!~luke@bitnomial/staff/luke> has joined #bitcoin-core-dev
300 2020-11-12T18:51:50  *** luke <luke!~luke@bitnomial/staff/luke> has quit IRC (Client Quit)
301 2020-11-12T18:53:42  <ja> provoostenator: is your testing setup public? it would be fun to try and connect all kinds of different versions with each other and draw a matrix :D
302 2020-11-12T18:54:07  <provoostenator> It connects fine as of a slightly older commit 1d3ec2a1fda7446323786a52da1fd109c01aa6fb
303 2020-11-12T18:54:48  <provoostenator> ja: it's not unfortunately; you'll have to spin up your own btcd and core machine somewhere.
304 2020-11-12T19:00:30  <ja> i see so many booleans, and i am suspicious. for example https://github.com/bitcoin/bitcoin/commit/1d3ec2a1fda7446323786a52da1fd109c01aa6fb
305 2020-11-12T19:00:47  <ja> i understand that it would be too much having a custom type for every single case
306 2020-11-12T19:01:02  <hebasto> meeting?
307 2020-11-12T19:01:04  <achow101> meeting?
308 2020-11-12T19:01:12  <wumpus> #startmeeting
309 2020-11-12T19:01:13  <core-meetingbot> Meeting started Thu Nov 12 19:01:12 2020 UTC.  The chair is wumpus. Information about MeetBot at https://bitcoin.jonasschnelli.ch/ircmeetings.
310 2020-11-12T19:01:13  <core-meetingbot> Available commands: action commands idea info link nick
311 2020-11-12T19:01:17  <jnewbery> hi
312 2020-11-12T19:01:19  <amiti> hi
313 2020-11-12T19:01:19  <jonatack> hi
314 2020-11-12T19:01:19  <jonasschnelli> hi
315 2020-11-12T19:01:20  <emzy> hi
316 2020-11-12T19:01:20  <luke-jr> hi
317 2020-11-12T19:01:22  <hebasto> hi
318 2020-11-12T19:01:24  <achow101> hi
319 2020-11-12T19:01:25  <provoostenator> ja: that;s just an arbitary commit, nothing to do with the issue
320 2020-11-12T19:01:26  <provoostenator> hi
321 2020-11-12T19:01:33  <meshcollider> hi
322 2020-11-12T19:01:36  <ja> provoostenator: i would explain if there wasn't a meeting now ;)
323 2020-11-12T19:01:44  <fanquake> hi
324 2020-11-12T19:01:48  <wumpus> #bitcoin-core-dev Meeting: achow101 aj amiti ariard bluematt cfields Chris_Stewart_5 digi_james dongcarl elichai2 emilengler fanquake fjahr gleb gmaxwell gwillen hebasto instagibbs jamesob jb55 jeremyrubin jl2012 jnewbery jonasschnelli jonatack jtimon kallewoof kanzure kvaciral lightlike luke-jr maaku marcofalke meshcollider michagogo moneyball morcos nehan NicolasDorier paveljanik
325 2020-11-12T19:01:50  <wumpus> petertodd phantomcircuit promag provoostenator ryanofsky sdaftuar sipa vasild wumpus
326 2020-11-12T19:02:25  <fjahr> hi
327 2020-11-12T19:02:39  <wumpus> one proposed meeting topic: limiting C++17 feature usage (jnewbery)
328 2020-11-12T19:03:11  <wumpus> I guess the most pressing topic right now is the 0.21.0rc1 release
329 2020-11-12T19:03:28  *** LarryRuane <LarryRuane!62f5cc94@c-98-245-204-148.hsd1.co.comcast.net> has joined #bitcoin-core-dev
330 2020-11-12T19:03:41  <wumpus> at least there's only three PRs left on the milestone:  https://github.com/bitcoin/bitcoin/pulls?q=is%3Aopen+is%3Apr+milestone%3A0.21.0
331 2020-11-12T19:03:57  <provoostenator> I'd like to get this in the release if possible: https://github.com/bitcoin-core/gui/pull/96
332 2020-11-12T19:04:00  <wumpus> jonasschnelli's last minute fix seems trivial
333 2020-11-12T19:04:10  <jonasschnelli> yes. can be merged I guess
334 2020-11-12T19:04:11  <provoostenator> I reverted the string changes, so it's pretty simple now.
335 2020-11-12T19:04:45  <hebasto> will review it tonight
336 2020-11-12T19:04:58  <wumpus> provoostenator: ok!
337 2020-11-12T19:05:05  <provoostenator> thx
338 2020-11-12T19:05:05  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
339 2020-11-12T19:05:05  <bitcoin-git> [bitcoin] practicalswift opened pull request #20379: tests: Remove no longer needed UBSan suppression (float divide-by-zero in validation.cpp) (master...remove-ubsan-suppressions) https://github.com/bitcoin/bitcoin/pull/20379
340 2020-11-12T19:05:06  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
341 2020-11-12T19:05:09  <jonasschnelli> I'll look into it,... but was under the impression that we had code freeze already
342 2020-11-12T19:05:10  <wumpus> yes, it's definitely too late for string changes
343 2020-11-12T19:05:21  <sipa> hi
344 2020-11-12T19:05:36  <provoostenator> The biggest thing that PR does is not recommend encryptino by default
345 2020-11-12T19:05:51  <provoostenator> Which just seems a recipe for tears for brand new users.
346 2020-11-12T19:06:17  <wumpus> I agree with that, encryption is torture for new users
347 2020-11-12T19:06:22  <sipa> which PR are you talking about?
348 2020-11-12T19:06:35  <hebasto> https://github.com/bitcoin-core/gui/pull/96
349 2020-11-12T19:07:04  * hebasto sipa: ^
350 2020-11-12T19:08:55  <wumpus> in any case please help review the last remaining PRs for 0.21: https://github.com/bitcoin/bitcoin/pulls?q=is%3Aopen+is%3Apr+milestone%3A0.21.0   and https://github.com/bitcoin-core/gui/milestone/1
351 2020-11-12T19:10:06  <wumpus> #20305 and #18836 are the big ones
352 2020-11-12T19:10:09  <gribble> https://github.com/bitcoin/bitcoin/issues/20305 | wallet: introduce fee_rate sat/vB param/option by jonatack · Pull Request #20305 · bitcoin/bitcoin · GitHub
353 2020-11-12T19:10:12  <gribble> https://github.com/bitcoin/bitcoin/issues/18836 | wallet: upgradewallet fixes and additional tests by achow101 · Pull Request #18836 · bitcoin/bitcoin · GitHub
354 2020-11-12T19:10:47  <luke-jr> 20305 should be noted to break RPC compatibility, but in a way that I and others feel is okay
355 2020-11-12T19:10:57  <luke-jr> if anyone objects, they should speak up
356 2020-11-12T19:11:13  <luke-jr> (see details on PR comments)
357 2020-11-12T19:11:13  <wumpus> versus 0.20? or just versus previous intermediate master releases?
358 2020-11-12T19:11:16  *** DeanWeen <DeanWeen!~dean@gateway/tor-sasl/deanguss> has quit IRC (Remote host closed the connection)
359 2020-11-12T19:11:16  <wumpus> okay
360 2020-11-12T19:11:19  <luke-jr> wumpus: 0.20
361 2020-11-12T19:11:21  <jonatack> (for bumpfee)
362 2020-11-12T19:11:32  <luke-jr> it's complex to explain, but IMO a reasonable concession
363 2020-11-12T19:11:38  *** DeanWeen <DeanWeen!~dean@gateway/tor-sasl/deanguss> has joined #bitcoin-core-dev
364 2020-11-12T19:11:42  <MarcoFalke> That certainly needs release notes, no?
365 2020-11-12T19:11:52  <jonatack> relevant comment by murch on that: "uckily, this is very benign. In the worst case, someone is going to get upped to the minRelayTxFee silently and sends at 1 sat/vB. Since RBF is on by default, they should be able bump when they notice. +1"
366 2020-11-12T19:12:06  <jonatack> https://github.com/bitcoin/bitcoin/pull/20305#discussion_r520231413
367 2020-11-12T19:12:24  <luke-jr> MarcoFalke: agreed
368 2020-11-12T19:12:39  <jonatack> MarcoFalke: yes, definitely, we can edit the wiki.
369 2020-11-12T19:13:06  *** kierank1 <kierank1!~kierank@184.75.221.35> has quit IRC (Ping timeout: 265 seconds)
370 2020-11-12T19:13:31  <luke-jr> most likely trying to use the old interface will just error; worst case, it's fixable
371 2020-11-12T19:14:03  <wumpus> ok
372 2020-11-12T19:14:15  <jonatack> yes, for the bumpfee change, there's a 1e5 times difference in units in the downward direction
373 2020-11-12T19:14:52  <wumpus> yeah downward is the only acceptable direction
374 2020-11-12T19:15:00  <jonatack> also added a * WARNING * in the help
375 2020-11-12T19:15:13  *** LarryRuane <LarryRuane!62f5cc94@c-98-245-204-148.hsd1.co.comcast.net> has quit IRC (Remote host closed the connection)
376 2020-11-12T19:15:18  <luke-jr> oh. just thought of a possible danger
377 2020-11-12T19:15:29  <luke-jr> if someone uses the new interface, with an old version
378 2020-11-12T19:16:06  <provoostenator> luke-jr: that's dangerous in general, given some of the other fixes...
379 2020-11-12T19:16:14  <luke-jr> provoostenator: ?
380 2020-11-12T19:16:39  <luke-jr> I wonder if the magnitude would trigger the absurd fee warning
381 2020-11-12T19:16:46  <provoostenator> #16257
382 2020-11-12T19:16:50  <gribble> https://github.com/bitcoin/bitcoin/issues/16257 | [wallet] abort when attempting to fund a transaction above -maxtxfee by Sjors · Pull Request #16257 · bitcoin/bitcoin · GitHub
383 2020-11-12T19:17:01  <sipa> the default absurd fee threshold is 0.1 BTC or so, no?
384 2020-11-12T19:17:22  <jonatack> yes iirc
385 2020-11-12T19:17:35  <jonatack> per the tests i've added in any case
386 2020-11-12T19:17:41  <queip> so it's decided to go with vB? WU was popular last year
387 2020-11-12T19:17:55  *** promag <promag!~promag@188.250.84.129> has joined #bitcoin-core-dev
388 2020-11-12T19:17:56  <provoostenator> People are still making payments with 0.1 BTC fees FWIW, quite often
389 2020-11-12T19:18:08  <sipa> everyone uses sat/vB, afaik
390 2020-11-12T19:18:24  <wumpus> `if there's any risk of it causing people to overpay fees it's unacceptable risk
391 2020-11-12T19:18:55  <sipa> i think WU is dangerous because it can result in a 4x factor off, which isn't enough to be likely to trigger other warning mechanisms
392 2020-11-12T19:19:00  <jonatack> queip: recent twitter poll showed a 20 to 1 preference for sat/vB over BTC/kB, wasn't an option though
393 2020-11-12T19:19:18  <jonatack> *WU wasn't an option in the poll tho
394 2020-11-12T19:19:21  <luke-jr> sipa: well, nothing is using sat/vB yet.. so it's a factor of 1e5/4
395 2020-11-12T19:19:46  <sipa> luke-jr: almost every fee estimation website, most block explorers, ... do
396 2020-11-12T19:19:54  <wumpus> so is that the case for #20305?
397 2020-11-12T19:19:56  <gribble> https://github.com/bitcoin/bitcoin/issues/20305 | wallet: introduce fee_rate sat/vB param/option by jonatack · Pull Request #20305 · bitcoin/bitcoin · GitHub
398 2020-11-12T19:20:07  <meshcollider> provoostenator: it's the wrong direction, even if they intended to send at 1btc, they'd end up at 1sat/vB
399 2020-11-12T19:20:56  <michaelfolkson> Slight overpayment -> Risk of slight monetary loss. Slight underpayment -> Risk of not being propagated? I guess it depends on how high the original fee was
400 2020-11-12T19:21:02  <luke-jr> minimum realistic bumpfee is probably 2sat/vB?
401 2020-11-12T19:21:17  <meshcollider> I don't think there's ever any risk of overpayment here
402 2020-11-12T19:21:19  <luke-jr> which at BTC/kB is 2 BTC/kB, over the absurd fee cutoff
403 2020-11-12T19:21:26  <jonatack> luke-jr: min incremental fee is 1 sat/vB
404 2020-11-12T19:21:26  <sipa> luke-jr: good point
405 2020-11-12T19:21:35  <wumpus> underpayment is at least better, could always bump again
406 2020-11-12T19:21:52  <luke-jr> so I *think* the magnitude is sufficient to avoid any loss in either direction
407 2020-11-12T19:22:14  <luke-jr> which only leaves the WU question - but I don't think we have time to do another poll
408 2020-11-12T19:22:25  <luke-jr> if people prefer WU and have to divide by 4, it's not the end of the world anywaty
409 2020-11-12T19:22:43  <jonatack> AFAIK sats seem to be far and away what people want
410 2020-11-12T19:22:59  <queip> ok just was asking
411 2020-11-12T19:22:59  <michaelfolkson> +1
412 2020-11-12T19:23:01  <luke-jr> jonatack: well, I assume it'd be sats/WU in that case
413 2020-11-12T19:23:05  <jonatack> found the poll: https://twitter.com/jonatack/status/1318890833131823104?s=20
414 2020-11-12T19:23:06  <emzy> +1
415 2020-11-12T19:23:08  *** promag <promag!~promag@188.250.84.129> has quit IRC (Ping timeout: 256 seconds)
416 2020-11-12T19:24:13  <sipa> i haven't paid attention to the actual solution we're going for now... but would it be easy to add more units later?
417 2020-11-12T19:24:24  <luke-jr> sipa: no
418 2020-11-12T19:24:28  <meshcollider> I don't think it's worth bikeshedding over but I prefer sats/vB honestly
419 2020-11-12T19:24:37  <wumpus> no, I think it's better to settle on one unit and one unit only for RPC
420 2020-11-12T19:24:44  <luke-jr> sipa: this removes all unit choice, and just uses sat/vB
421 2020-11-12T19:24:47  <meshcollider> sipa: we're trying to make it simpler :)
422 2020-11-12T19:25:07  <sipa> luke-jr: how does that not break compatibility (as earlier releases all use BTC/kvB)?
423 2020-11-12T19:25:08  <wumpus> adding a choice of units shouldn't be necesasry, it's a programmatic interface
424 2020-11-12T19:25:18  <jonatack> right, so people don't have to pass in a choice of units with the estimate_mode param
425 2020-11-12T19:25:24  <wumpus> just standardize something …
426 2020-11-12T19:25:26  <luke-jr> sipa: the field name is different for everything except bumpfee
427 2020-11-12T19:25:27  <sipa> feel free to tell me to just go read the PR
428 2020-11-12T19:25:36  <luke-jr> sipa: and bumpfee is protected by the magnitude
429 2020-11-12T19:25:56  <luke-jr> sipa: the old interface to bumpfee+fee_rate won't *work*, but it won't do damage either
430 2020-11-12T19:26:26  <sipa> ok
431 2020-11-12T19:26:36  <luke-jr> (other RPCs used "feeRate" instead of "fee_rate")
432 2020-11-12T19:27:07  <luke-jr> IIRC only in options objects, so no positional mess (someone should double-check this)
433 2020-11-12T19:27:26  <jonatack> yes. (in fundrawtxn and walletcreatefundedpsbt only)
434 2020-11-12T19:27:40  *** evanpro <evanpro!~evanpro@195.206.169.184> has joined #bitcoin-core-dev
435 2020-11-12T19:28:20  <jonatack> feeRate is only an arg, not an option, which we can deprecate as soon as people judge feasible
436 2020-11-12T19:28:31  <jonatack> it's in BTC/kB
437 2020-11-12T19:30:59  <wumpus> next topic?
438 2020-11-12T19:31:07  <jonatack> (fwiw that PR adds a fair number of RPCExamples in send and sendtoaddress to help people use it)
439 2020-11-12T19:31:41  <michaelfolkson> wumpus: yup
440 2020-11-12T19:32:20  <wumpus> #topic limiting C++17 feature usage (jnewbery)
441 2020-11-12T19:32:20  <core-meetingbot> topic: limiting C++17 feature usage (jnewbery)
442 2020-11-12T19:32:38  <jnewbery> hi
443 2020-11-12T19:32:39  <wumpus> link: https://github.com/bitcoin/bitcoin/issues/16684#issuecomment-726214696
444 2020-11-12T19:32:48  <jnewbery> As a reminder, our plan for C++17 is here: https://github.com/bitcoin/bitcoin/issues/16684
445 2020-11-12T19:32:56  <jnewbery> Once we branch v0.21 (imminently), we'll be able to start using c++14 and c++17 features.
446 2020-11-12T19:33:02  <jnewbery> I expect lots of people have their favorite features that they want to start using.
447 2020-11-12T19:33:11  <jnewbery> I was wondering whether we should have a project-wide policy on which new features we should allow, or if there are any we should disallow in the project for now.
448 2020-11-12T19:33:16  <jnewbery> Prompted by https://github.com/bitcoin/bitcoin/issues/16684#issuecomment-726214696, where Cory ran into a bug in glibc when using std::shared_mutex.
449 2020-11-12T19:33:17  <wumpus> so there's a specific feature that triggers a libc bug?
450 2020-11-12T19:33:26  <jnewbery> So std::shared_mutex is one that I think we should avoid, at least until we better understand the bug, but are there others?
451 2020-11-12T19:34:06  <MarcoFalke> std::fs
452 2020-11-12T19:34:08  <wumpus> I'd rather not do that, that for 0.22 full C++17 is allowed, but that is a good reason to disallow that one for now
453 2020-11-12T19:34:18  <hebasto> or define minimum libc with fixed bug?
454 2020-11-12T19:34:19  <sipa> i vaguely remember some issues with trying to use std::filesystem by someone, but i'm not sure if that was because they weren't familiar enough with the build system, or if there were actual problems with it
455 2020-11-12T19:34:40  <MarcoFalke> We can't use std::fs because LTS versions of operating systems don't ship it
456 2020-11-12T19:34:54  <sipa> well what's the alternative? does boost::shared_mutex not have the same problem?
457 2020-11-12T19:34:58  <wumpus> every specific exclusion makes it more difficult for new contributors etc
458 2020-11-12T19:35:11  <MarcoFalke> sipa: We already use boost::shared_mutex
459 2020-11-12T19:35:38  <sipa> MarcoFalke: right, my concern is that boost, when compiled in c++17 mode, will just go "oh the STL provides this, just delegate to that"
460 2020-11-12T19:35:47  <wumpus> people don't generally consult a list of allowed features before contributing
461 2020-11-12T19:35:48  <MarcoFalke> ah good point
462 2020-11-12T19:35:50  <luke-jr> hmm
463 2020-11-12T19:36:14  <wumpus> though things like "use boost::shared_mutex instead of std::shared_mutex" are clear and easy to enforce enough
464 2020-11-12T19:36:21  <wumpus> or the fs one
465 2020-11-12T19:36:29  <wumpus> we have our own fs abstraction anyway
466 2020-11-12T19:36:30  <sipa> it wouldn't be hard to add a linter to outlaw "std::filesistem" and "std::shared_mutex" in the codebase or so
467 2020-11-12T19:36:38  <wumpus> sipa: yes
468 2020-11-12T19:36:41  <wumpus> those two are easy
469 2020-11-12T19:36:51  <MarcoFalke> sipa: The ci would fail if someone tried using std::fs
470 2020-11-12T19:37:00  <sipa> oh, right
471 2020-11-12T19:37:01  <MarcoFalke> (and gitian)
472 2020-11-12T19:37:08  <sipa> my impression is that all these issues are STL features, not languages features
473 2020-11-12T19:37:33  <sipa> and i expect that if you use a sufficient compiler version, all languages features will actually work
474 2020-11-12T19:37:40  <jonatack> luke-jr: you are right, feeRate is an option
475 2020-11-12T19:38:09  <sipa> so perhaps the policy can be "you can use all language features, but initially we'll want to whitelist STL features" ?
476 2020-11-12T19:38:42  <sipa> that's probably too restrictive
477 2020-11-12T19:38:57  <wumpus> no,I think it's better to reject specific things if we have a good reason
478 2020-11-12T19:39:01  <sipa> agree
479 2020-11-12T19:39:03  <wumpus> and just accept standard C++17 otherwise
480 2020-11-12T19:39:14  <sipa> i guess the concern is really about things that compile, but are known to not always work
481 2020-11-12T19:39:17  <sipa> like this shared_mutex thing
482 2020-11-12T19:39:23  <wumpus> right
483 2020-11-12T19:39:27  <ja> jnewbery: should std::shared_mutex be avoided even if it is unknown whether boost::shared_mutex is also broken?
484 2020-11-12T19:39:32  <sipa> and we should just outlaw while necessary... just as with any other compiler/stl bug
485 2020-11-12T19:39:52  <jnewbery> I don't know enough about compilers to know how stable their C++17 stl features are
486 2020-11-12T19:40:11  <wumpus> you would hope it is stable after more then three years
487 2020-11-12T19:40:22  <jnewbery> you would, and yet here we are
488 2020-11-12T19:40:26  <wumpus> of course, compiler and c++ librar ybugs happen sometimes
489 2020-11-12T19:40:32  <wumpus> well yes it's a specific thing
490 2020-11-12T19:40:45  <wumpus> even memcmp had a bug !!!
491 2020-11-12T19:40:49  <jnewbery> we don't know how many other specific things there are
492 2020-11-12T19:40:52  <wumpus> should we reject c89 featurs now
493 2020-11-12T19:40:58  <sipa> haha
494 2020-11-12T19:41:03  <MarcoFalke> Is there a minimal test case for the shared_mutex thing?
495 2020-11-12T19:41:31  <ja> it is still not clear to me which glibc bug it actually is, there are linked two different bugs from the c++17 thread
496 2020-11-12T19:41:45  <ja> but glibc has test cases for the pthread primitives
497 2020-11-12T19:41:46  <wumpus> it's not possible to guarantee that usage of compiler or library features doesn't have bugs, this is just as true for old features as now ones
498 2020-11-12T19:42:23  <wumpus> this is one of the biggest risks in consensus driven systems isn't it
499 2020-11-12T19:42:25  <jnewbery> wumpus: that's doesn't seem like it'd be true. New features are more likely to have bugs
500 2020-11-12T19:42:26  <sipa> boost 1.71 does not seem to use STL's shared_mutex
501 2020-11-12T19:42:42  <wumpus> jnewbery: I'm not convinced about that, code rot is a thing
502 2020-11-12T19:42:44  <jnewbery> *or uncover existing bugs
503 2020-11-12T19:42:59  <wumpus> new features might actually have *more* eyes on them
504 2020-11-12T19:43:22  <luke-jr> sipa: unrelease boost might
505 2020-11-12T19:43:29  <wumpus> this is an abyss without end anyway... we can only calculate in known bugs not potential ones
506 2020-11-12T19:44:05  <luke-jr> if every distro has a fix, maybe just a sanity check is in order
507 2020-11-12T19:44:12  <MarcoFalke> A future release of boost might decay boost::shared_mutex into std::shared_mutex
508 2020-11-12T19:44:12  <jnewbery> My general point is that we shouldn't rush to use new features unless there's very clear benefit
509 2020-11-12T19:44:24  <wumpus> MarcoFalke: yep
510 2020-11-12T19:44:27  <luke-jr> otoh, isn't it just a deadlock worst case?
511 2020-11-12T19:44:49  <jnewbery> and that if we do that, then we should codify what features can be used at the project level
512 2020-11-12T19:44:53  <luke-jr> I think deadlock is fairly harmless for user-built binaries that simply require an updated OS to fix
513 2020-11-12T19:45:09  <wumpus> no, I don't think we should make a long list of allowed c++17 features
514 2020-11-12T19:45:10  <ja> luke-jr: if you use bitcoin to back a lightning node, a deadlock could be pretty bad, no?
515 2020-11-12T19:45:16  <wumpus> only exclude ones that we know to cause problems
516 2020-11-12T19:45:24  *** lightlike <lightlike!~lightlike@p200300c7ef1a1b00c04f02a7739a7f7b.dip0.t-ipconnect.de> has quit IRC (Quit: Leaving)
517 2020-11-12T19:45:32  <luke-jr> ja: hmm, maybe - but aren't there supposed to be watchers?
518 2020-11-12T19:46:05  <wumpus> we have already made the decision to use c++17, maybe we should be more careful in consensus code, but that's *always* the case for any change
519 2020-11-12T19:46:06  <ja> luke-jr: i don't know how many people are running watchers. it is irrelevant whether there is supposed to be
520 2020-11-12T19:46:43  <luke-jr> point is, that would be a scenario with two user errors
521 2020-11-12T19:47:09  <michaelfolkson> Watchtowers only needed if you aren't online 100 percent of time (or for additional protection)
522 2020-11-12T19:47:26  <wumpus> and sure, we should take the same care as we did for c++11, don't change things for the sake of changing them
523 2020-11-12T19:47:31  <ja> michaelfolkson: if you bitcoin node is deadlocked on a shared_mutex, are you online?
524 2020-11-12T19:48:02  <michaelfolkson> I'd guess not ja :)
525 2020-11-12T19:48:05  <wumpus> that should also be standard policy for the project already, no needless refactors
526 2020-11-12T19:48:57  <michaelfolkson> But how long would you be deadlocked for?
527 2020-11-12T19:49:08  <ja> 2 weeks, until you come back from vacation
528 2020-11-12T19:49:09  <jnewbery> I think only introducing new features as they're needed is the more cautious approach
529 2020-11-12T19:49:12  <luke-jr> michaelfolkson: indefinitely
530 2020-11-12T19:49:18  <sipa> michaelfolkson: the definition of a deadlock implies it's forever
531 2020-11-12T19:49:31  <michaelfolkson> Ok. That is a problem
532 2020-11-12T19:49:38  <MarcoFalke> jnewbery: I don't think C++17 is "needed". We could stay with C++11 forever
533 2020-11-12T19:49:41  <wumpus> in new code I think full c++17 should be allowed (apart from what we have labaled as dangerous features)
534 2020-11-12T19:49:44  <luke-jr> but the same goes for any DoS vuln
535 2020-11-12T19:49:48  <luke-jr> which seem fairly common
536 2020-11-12T19:49:49  <wumpus> yes, we could stay in c++11 forever
537 2020-11-12T19:50:24  <wumpus> but we've already decided not to
538 2020-11-12T19:50:42  <jnewbery> It would be nice if we could have some nuance in these discussions instead of talking about C89 and staying on C++11 forever
539 2020-11-12T19:50:49  <wumpus> I don't think it would make the project any safer
540 2020-11-12T19:51:12  <hebasto> we coudn't stay on C++11 due to new Qt versions
541 2020-11-12T19:51:31  <luke-jr> hebasto: Qt dropped C++11 support? :o
542 2020-11-12T19:51:32  <wumpus> just make an exception for the gui code...
543 2020-11-12T19:51:40  <sipa> waot
544 2020-11-12T19:51:49  <MarcoFalke> Use C++11 code, but compile it with -std=c++17
545 2020-11-12T19:51:49  <sipa> this shared_lock thing sounds like a problem in pthread?
546 2020-11-12T19:51:58  <sipa> which means it would also affect boost?
547 2020-11-12T19:52:13  <wumpus> boost definitely uses pthread (but maybe in a different way?)
548 2020-11-12T19:52:30  <hebasto> luke-jr: #19716
549 2020-11-12T19:52:32  <gribble> https://github.com/bitcoin/bitcoin/issues/19716 | build: Qt 5.15.x by fanquake · Pull Request #19716 · bitcoin/bitcoin · GitHub
550 2020-11-12T19:52:46  <michaelfolkson> jnewbery: I think the nuance goes when wumpus says new contributors won't consult guides. But agreed I'd guess nuance is the better way to go
551 2020-11-12T19:52:50  <wumpus> if it's a general pthread issue then we're already affected and c++17 is unimportant to this
552 2020-11-12T19:52:56  <sipa> indeed
553 2020-11-12T19:52:58  <jonatack> At the end of the day, these things are going to come down to code review and incremental adjustments and guidelines as needed.
554 2020-11-12T19:53:03  <sipa> boost has its own shared_lock implementation
555 2020-11-12T19:53:10  <luke-jr> hebasto: that looks like the opposite
556 2020-11-12T19:53:12  <sipa> and doesn't use pthread's rwlock interface
557 2020-11-12T19:53:18  <wumpus> great
558 2020-11-12T19:53:25  <sipa> (in 1.71)
559 2020-11-12T19:53:37  <wumpus> michaelfolkson: I don't think we can front-run any compiler or c++ library issues
560 2020-11-12T19:54:21  <wumpus> avoiding c++17 features would give a false sense of security imo, it's not like it's brand new
561 2020-11-12T19:54:31  <luke-jr> I wonder if we ought to add a CI using roconnor's memcmp bug detection
562 2020-11-12T19:54:36  <wumpus> but that's just my opinion
563 2020-11-12T19:55:03  <luke-jr> seeing as GCC/distros appear to have a disinterest in actually fixing it
564 2020-11-12T19:55:11  <fanquake> luke-jr: opposite of what? Qt started using C++14 features in its code, and essentially “forgot” that it was still meant to support c++11. An issue was opened but they never did anything to fix the issue.
565 2020-11-12T19:55:57  <luke-jr> fanquake: I don't see that mentioning in the linked issue?
566 2020-11-12T19:56:17  <wumpus> I'm not sure how more nuanced you want this, I don't think it's useful to evaluate every single c++17 feature in the meeting at least
567 2020-11-12T19:56:45  <wumpus> as if we can judge how much risk the compiler or library change is anyway
568 2020-11-12T19:56:49  <luke-jr> fanquake: you can't build Qt with C++14 and then link from C++11 code?
569 2020-11-12T19:57:01  *** promag <promag!~promag@188.250.84.129> has joined #bitcoin-core-dev
570 2020-11-12T19:57:39  <wumpus> could you ever have predicted this?
571 2020-11-12T19:57:46  *** ajonas_ <ajonas_!uid385278@gateway/web/irccloud.com/x-vbrpaonosufznwgi> has joined #bitcoin-core-dev
572 2020-11-12T19:57:53  <wumpus> did std::shared_mutex sound dangerous to you than boost::shared_mutex?
573 2020-11-12T19:58:15  <wumpus> still, here we are
574 2020-11-12T19:58:20  <jnewbery> changing to something new is always dangerous
575 2020-11-12T19:58:31  <fanquake> luke-jr: I mentioned the details and linked to upstream in #19305
576 2020-11-12T19:58:34  <gribble> https://github.com/bitcoin/bitcoin/issues/19305 | doc: add C++17 release note for 0.21.0 by fanquake · Pull Request #19305 · bitcoin/bitcoin · GitHub
577 2020-11-12T19:58:39  <wumpus> okay, so not change to anything new anymore then?
578 2020-11-12T19:58:42  <sipa> jnewbery: boost has also had its fair share of bugs though
579 2020-11-12T19:58:54  <wumpus> would this *specifically* have been risky to you?
580 2020-11-12T19:59:06  <sipa> and a priori it seems a reasonable assumption that things that make it into the C++ standard have matured enough that they're less risky
581 2020-11-12T19:59:07  <wumpus> if not, it would be a blanket reject c++17 features
582 2020-11-12T19:59:15  <wumpus> yes
583 2020-11-12T19:59:23  *** per <per!~per@gateway/tor-sasl/wsm> has quit IRC (Ping timeout: 240 seconds)
584 2020-11-12T19:59:35  <wumpus> and yes, boost versions have also broken things sometimes
585 2020-11-12T19:59:58  <wumpus> not upgrading boost is dangerous too, though
586 2020-11-12T20:00:55  <MarcoFalke> With other project upgrading, at some point boost::feature is going to be less tested than std::feature. Code changes inside boost, which we can't anticipate are going to eventually break the feautre
587 2020-11-12T20:01:24  <jnewbery> I don't see any strong arguments against being cautious about new features, but I'm not getting the impression that I've convinced anyone
588 2020-11-12T20:01:27  <wumpus> I don't think any general principple can be derived from this
589 2020-11-12T20:01:32  *** per <per!~per@gateway/tor-sasl/wsm> has joined #bitcoin-core-dev
590 2020-11-12T20:01:46  <wumpus> yes, being cautious is always good
591 2020-11-12T20:01:49  <wumpus> I hope we already are cautious?
592 2020-11-12T20:01:50  *** promag <promag!~promag@188.250.84.129> has quit IRC (Ping timeout: 264 seconds)
593 2020-11-12T20:02:01  <sipa> jnewbery: i think we should always be caution about new features, but i don't think this is very specific to new language/stl features
594 2020-11-12T20:02:04  <wumpus> do you have any specific suggestion?
595 2020-11-12T20:02:43  <sipa> and we do have a review and QA cycle, which are part of the process
596 2020-11-12T20:02:43  <queip> as it was mentioned, compiling for old mac os x will break, also related to SDK versions afair. In context of Gitian for example
597 2020-11-12T20:03:00  <ja> the decision should ideally be derived from usage patterns, not from how new the feature is. a 10 year old language feature that nobody uses can't be relied on. the age of the feature is a proxy for how widely used it is, which is a proxy for how buggy it is
598 2020-11-12T20:03:10  <queip> that is, c++!7 forces such bump of minimal macosx version
599 2020-11-12T20:03:19  <jnewbery> I didn't think sipa's suggestion of having a list of allowed features was bad. That list would grow over time
600 2020-11-12T20:03:22  <wumpus> queip: yes, I think that wa calculated in
601 2020-11-12T20:03:29  <wumpus> I don't think that's a good idea
602 2020-11-12T20:03:58  <wumpus> it's super confusing to new contributors for example
603 2020-11-12T20:04:03  <michaelfolkson> Because of new contributors and because of not knowing what should go on that list wumpus?
604 2020-11-12T20:04:07  <sipa> i think i agree with wumpus now
605 2020-11-12T20:04:08  <wumpus> yes
606 2020-11-12T20:04:21  <luke-jr> queip: we typically only guarantee support for the most recent stable version of an OS
607 2020-11-12T20:04:28  <luke-jr> though Windows is apparently an exception
608 2020-11-12T20:04:35  <sipa> what constitutes a "feature" even? is a new member function that was added to std::vector a "feature" ?
609 2020-11-12T20:04:36  <wumpus> if we really dislike certain features then we should disallow them, but I don't think it makes sense to partially allow a standard
610 2020-11-12T20:04:43  <wumpus> yes
611 2020-11-12T20:04:50  <wumpus> do we hae to whitelist every function? every class?
612 2020-11-12T20:05:05  <MarcoFalke> Generally, our insurance against build system bugs are tests
613 2020-11-12T20:05:16  <wumpus> do you even want to maintain this list?
614 2020-11-12T20:05:46  <sipa> maybe a good question to ask ourselves: if we had started using std::shared_mutex, would we have caught this issue before release?
615 2020-11-12T20:06:33  <wumpus> only if we had a test reproducing the issue predictably I think
616 2020-11-12T20:06:56  <MarcoFalke> we should add one
617 2020-11-12T20:06:58  <jnewbery> wumpus: I don't think we should be setting our project standards based on what features new contributors might want to use. We have project standards precisely so all contributors write code in a common way
618 2020-11-12T20:06:59  <sipa> yeah, it'd probably depend on how actively shared_mutex was used (and with how much contention...)
619 2020-11-12T20:07:06  <wumpus> if it causes a random hang in travis, well, peple would think it's just another infrastructure issue
620 2020-11-12T20:07:28  <wumpus> jnewbery: okay
621 2020-11-12T20:07:31  <sipa> jnewbery: that conceptually makes sense, but what specifically is your suggestion?
622 2020-11-12T20:07:42  <wumpus> jnewbery: feel free to make a list
623 2020-11-12T20:07:45  <wumpus> jnewbery: and PR it
624 2020-11-12T20:07:56  <wumpus> jnewbery: I'm not conceptually against it I just do not want to maintain it
625 2020-11-12T20:07:59  <MarcoFalke> time, btw
626 2020-11-12T20:08:00  <michaelfolkson> The new contributor argument I don't think is particularly convincing. But the problems of constructing a list is more convincing to me
627 2020-11-12T20:08:00  <luke-jr> "Travis failed, can someone restart it for me?"
628 2020-11-12T20:08:10  <queip> apparently not popular opinion, but a white list of allowed free functions, and classes, would make it easier to guard against someone using obscure function that happens to be buggy.  Though also a review can anyway guard against it - "why not use the more common solution to this problem". Either way read list of, probably 20 recommended classes and functions, is not that hard for new developer
629 2020-11-12T20:08:24  <wumpus> queip: again, feel free to maintian such a thing
630 2020-11-12T20:08:38  <jnewbery> queip: that seems easier to me than arguing on each PR what is and isn't acceptable
631 2020-11-12T20:08:59  <wumpus> I'm done with this (both the meeting and the discussion)
632 2020-11-12T20:09:00  <wumpus> #endmeeting
633 2020-11-12T20:09:01  <core-meetingbot> topic: Bitcoin Core development discussion and commit log | Feel free to watch, but please take commentary and usage questions to #bitcoin | Channel logs: http://www.erisian.com.au/bitcoin-core-dev/, http://gnusha.org/bitcoin-core-dev/ | Meeting topics http://gnusha.org/bitcoin-core-dev/proposedmeetingtopics.txt / http://gnusha.org/bitcoin-core-dev/proposedwalletmeetingtopics.txt
634 2020-11-12T20:09:01  <core-meetingbot> Meeting ended Thu Nov 12 20:09:00 2020 UTC.
635 2020-11-12T20:09:01  <core-meetingbot> Minutes:        https://bitcoin.jonasschnelli.ch/ircmeetings/logs/bitcoin-core-dev/2020/bitcoin-core-dev.2020-11-12-19.01.moin.txt
636 2020-11-12T20:09:17  <sipa> ok, practically, how would it be decided what is acceptable?
637 2020-11-12T20:09:21  <wumpus> I think this project becomes impossible to maintian in the close feature
638 2020-11-12T20:09:21  <MarcoFalke> How could we maintain the list of allowed features?
639 2020-11-12T20:10:05  <wumpus> if you want to micro-manage every C++ function and class and feature that people use in a huge project like this go ahead
640 2020-11-12T20:10:13  <jonatack> I don't disagree with guidelines, but reckon they'll be shaped in a bottom-up, rather than top-down, fashion: ongoing, continual, incremental
641 2020-11-12T20:10:25  <ja> provoostenator: i linked the commit https://github.com/bitcoin/bitcoin/commit/1d3ec2a1fda7446323786a52da1fd109c01aa6fb because i wanted to discuss this compromise on boolean blindness in general, not specific to the btcd issue
642 2020-11-12T20:10:29  <wumpus> it's too risky anyway
643 2020-11-12T20:10:33  <wumpus> this whole thing
644 2020-11-12T20:10:43  <jonatack> (once upon a time, one might have said agile :))))
645 2020-11-12T20:10:52  <ja> provoostenator: my question is: would it be useful to have a general purpose type : ShouldBeChecked = Check | DontCheck instead of bool?
646 2020-11-12T20:11:14  <ja> provoostenator: that type could be used for example in the linked commit, and it would alliviate some boolean blindness
647 2020-11-12T20:11:21  <wumpus> I'm not convinced even CPU features are reliable enough
648 2020-11-12T20:11:28  <sipa> ja: i see you're a haskell programmer
649 2020-11-12T20:11:30  <wumpus> if you really want to know
650 2020-11-12T20:11:40  <ja> provoostenator: it is deliberately ambiguous towards exactly what should be checked. but better than a boolean, no?
651 2020-11-12T20:12:57  <ja> sipa: i am not advocating lazy evaluation here, mind you ;) i don't think it is an obscure proposal
652 2020-11-12T20:12:57  <MarcoFalke> Compiling with C++17 will probably make the std lib use those features, and we couldn't protect against that with a allow-list
653 2020-11-12T20:13:03  <wumpus> I think it's important to isolate the consensus code soon, and be extremely careful about that
654 2020-11-12T20:13:14  <sipa> jnewbery: so imagine we had this whitelist - at whatever granularity - and someone suggested that std::shared_lock should be added to it... what process would be followed to decide that
655 2020-11-12T20:13:19  <wumpus> I'm not sure we can be careful enough
656 2020-11-12T20:13:29  <jnewbery> jonatack: in general, that seems like a reasonable approach. But in this case when there are lots of new features on offer, then starting more restrictive and gradually allowing new features seems more cautious
657 2020-11-12T20:13:53  <sipa> jnewbery: my guess is... unless we specifically knew about this pthread issue, everyone would be like "that seems very reasonable, it's in every STL, tests work, ... go for it"
658 2020-11-12T20:13:54  <jnewbery> sipa: I'm not sure. It might not be practical, but I wanted to raise it as something we should at least thing about
659 2020-11-12T20:14:12  <wumpus> C++ is a way too complex language
660 2020-11-12T20:14:35  <sipa> wumpus: as are the operating systems and hardware they run on...
661 2020-11-12T20:14:40  <wumpus> sipa: yes
662 2020-11-12T20:14:49  <sipa> i don't think that's a cause for despair... we have review and tests
663 2020-11-12T20:14:57  <sipa> the real world is always messy
664 2020-11-12T20:15:05  <jnewbery> "This is a bad idea" is different from "I'm not conceptually against it but I don't want to maintain it"
665 2020-11-12T20:15:22  <sipa> i don't think it's just that
666 2020-11-12T20:15:26  <wumpus> well...
667 2020-11-12T20:15:34  <sipa> i don't know how it would be maintained - by anyone
668 2020-11-12T20:15:38  <MarcoFalke> I don't think an allow-list would conceptually work with c++ features
669 2020-11-12T20:15:41  <wumpus> it's a bad idea because it takes resources from other things I gues
670 2020-11-12T20:15:55  <wumpus> it's a huge project
671 2020-11-12T20:15:57  <jonatack> wumpus: isolating consensus code is a topic i've noticed you come back to repeatedly over time. a good topic for the next coredev...
672 2020-11-12T20:16:05  <wumpus> an probably not a big thing in risk-reduction in general
673 2020-11-12T20:16:14  <sipa> jonatack: and every coredev since 2015 or so ;)
674 2020-11-12T20:16:19  <jonatack> heh
675 2020-11-12T20:16:22  <wumpus> jonatack: yess
676 2020-11-12T20:16:31  <jnewbery> wumpus: adding wizzy new c++17 features makes it even huger (conceptually)
677 2020-11-12T20:16:53  <wumpus> jnewbery: I'm not convinced about that, I don't think there's anythign specific or whizzy about c++17 features
678 2020-11-12T20:17:03  <wumpus> jnewbery: are there any you *specifcially* take offense to?
679 2020-11-12T20:17:26  <sipa> jnewbery: maybe... but specifically here, if you didn't know about the pthread thing... wouldn't you think that replacing boost::shared_mutex with std::shared_mutex is reducing risk surface?
680 2020-11-12T20:17:34  <wumpus> sipa: yes, that
681 2020-11-12T20:17:47  <Kiminuo> https://github.com/bitcoin/bitcoin/pull/19245 - Do I understand correctly that this is dead for foreseeable future?
682 2020-11-12T20:17:47  <ja> wumpus: did you see the discussion on string_view?
683 2020-11-12T20:17:51  <jnewbery> I'm not sure we should use string_views
684 2020-11-12T20:17:54  <MarcoFalke> we already use the features. Either through boost, or through more verbose C++11 code
685 2020-11-12T20:18:02  <wumpus> yes, I think isolating the conensus code would be most bang for buck with regard to risk minimalization
686 2020-11-12T20:18:09  <jnewbery> ja: which discussion?
687 2020-11-12T20:18:27  *** evanpro <evanpro!~evanpro@195.206.169.184> has quit IRC (Remote host closed the connection)
688 2020-11-12T20:18:34  <wumpus> make it clear which areas of the code are the really risky ones that could break bitcoin as a thing
689 2020-11-12T20:18:36  <ja> jnewbery: ah i just meant the comments in the issue #16684
690 2020-11-12T20:18:38  <gribble> https://github.com/bitcoin/bitcoin/issues/16684 | Discussion: upgrading to C++17 · Issue #16684 · bitcoin/bitcoin · GitHub
691 2020-11-12T20:18:49  <wumpus> bitcoin core is too big
692 2020-11-12T20:19:21  <sipa> happy to see renewed activity on that front with dongcarl's recent PRs
693 2020-11-12T20:19:24  <wumpus> but I've been screaming into the void about this since forever, I'm happy dongcarl1 picked up on it
694 2020-11-12T20:19:27  <wumpus> yes
695 2020-11-12T20:19:42  <jnewbery> ja: I hadn't seen that but my instinct is to agree with practicalswift - it introduces very sharp edges
696 2020-11-12T20:19:58  <jonatack> jnewbery: in any case for my own work and reviewing, I'll be following your cautious approach
697 2020-11-12T20:20:12  <jnewbery> new features aren't dangerous just because they may have bugs. They're also dangerous because developers might not know how to use them safely
698 2020-11-12T20:20:31  <sipa> i think introducing a new features/concepts should always be a red flag for review
699 2020-11-12T20:20:39  <jnewbery> I trust sipa to use spans correctly, but I wouldn't encourage their use by everyone
700 2020-11-12T20:20:43  <wumpus> that's different for everyone though, and just as true for old crufty featurs
701 2020-11-12T20:20:58  <wumpus> (e.g. does anyone know about c++ multiple inheritance specifics?)
702 2020-11-12T20:21:07  <jnewbery> spans and string_views are objectively more dangeroush than other language features
703 2020-11-12T20:21:23  <michaelfolkson> We certainly can't have a guide that says if you are sipa you can use it and if you are not you can't haha
704 2020-11-12T20:21:24  <luke-jr> why are we switching to spans if they're so hard to use?
705 2020-11-12T20:21:32  <wumpus> jnewbery: well if it's a replacement for void*, size_t
706 2020-11-12T20:21:39  <wumpus> jnewbery: it isn't any less safe
707 2020-11-12T20:21:44  <sipa> jnewbery: (playing the devil's advocate here) i think they're less dangerous than points and lengths passed manually
708 2020-11-12T20:21:49  <sipa> *pointers
709 2020-11-12T20:21:50  <wumpus> all the span refactores have been that
710 2020-11-12T20:21:53  <wumpus> just that
711 2020-11-12T20:22:09  <wumpus> sipa: right
712 2020-11-12T20:22:31  <wumpus> it makes things conceptually clearer than a pair of pointers and lengths
713 2020-11-12T20:22:42  <wumpus> that's all, it shouldn't replace owned objects
714 2020-11-12T20:23:01  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
715 2020-11-12T20:23:01  <bitcoin-git> [bitcoin] practicalswift opened pull request #20380: doc: Add instructions on how to fuzz the P2P layer using Honggfuzz NetDriver (master...honggfuzz-p2p-fuzzing) https://github.com/bitcoin/bitcoin/pull/20380
716 2020-11-12T20:23:03  * jonatack taking notes on the consensus isolation mentions
717 2020-11-12T20:23:05  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
718 2020-11-12T20:23:14  <ja> by using a data-type, it also allows the compiler to understand more invariants about your code
719 2020-11-12T20:23:26  <MarcoFalke> I think it would be very concerning if people ACK code changes that use features they don't know how to use safely
720 2020-11-12T20:23:28  <ja> a compiler could have specific protections when using Span, that wouldn't otherwise be used
721 2020-11-12T20:23:30  <MarcoFalke> *ACKed
722 2020-11-12T20:23:47  <wumpus> MarcoFalke: yes
723 2020-11-12T20:24:05  <sipa> ja: about that, can some people please review #19387
724 2020-11-12T20:24:07  <gribble> https://github.com/bitcoin/bitcoin/issues/19387 | span: update constructors to match c++20 draft spec and add lifetimebound attribute by theuni · Pull Request #19387 · bitcoin/bitcoin · GitHub
725 2020-11-12T20:24:13  <MarcoFalke> code review is our best effort protecting against bad code
726 2020-11-12T20:24:30  <MarcoFalke> Developer notes certainly do help to clarify guidelines
727 2020-11-12T20:24:32  <wumpus> it's good to be cautious anyway, but I don't think making an explicit list of everything is going to help
728 2020-11-12T20:25:14  <wumpus> and if we're worried about string_view and spans specifically then we should be careful to review changes introducing those carefully
729 2020-11-12T20:25:23  <wumpus> that's a good point and at least a specific one
730 2020-11-12T20:25:47  <wumpus> but we can't go over everything and make a risk estimate upfront
731 2020-11-12T20:26:14  <michaelfolkson> Can I ask about fuzzing? At the moment fuzzing seems to be a two man show (practicalswift and MarcoFalke). Is there anything additional we can do to get more people to engage with fuzzing?
732 2020-11-12T20:26:15  <jnewbery> I'd be wary of anyone adding try_emplace since the interface is so confusing
733 2020-11-12T20:27:11  <MarcoFalke> michaelfolkson: You can help by writing fuzzers, reviewing fuzz pull requests, or run the fuzz engine youself and contribute seeds (hopefully ones that don't trigger bugs)
734 2020-11-12T20:27:27  <sipa> michaelfolkson: i've been adding elaborate fuzzers in several of my recent bigger PRs
735 2020-11-12T20:27:50  <michaelfolkson> Do you do all your fuzzing on your laptop MarcoFalke? It takes hours sometimes
736 2020-11-12T20:27:54  <wumpus> michaelfolkson: is there good documentation on how to get started?
737 2020-11-12T20:28:05  <MarcoFalke> michaelfolkson: wumpus doc/fuzzing.md
738 2020-11-12T20:28:15  <wumpus> thanks
739 2020-11-12T20:28:17  <sipa> i'd encourage everyone to do the same...
740 2020-11-12T20:28:30  <wumpus> I don't have any big CPUs though
741 2020-11-12T20:28:46  <sipa> i'm less convinced about writing generic fuzzers for code you're not already familiar with
742 2020-11-12T20:28:49  <MarcoFalke> michaelfolkson: I use my laptop with a fuzz engine, sometimes vim to create seeds. I am also running a server 24/7
743 2020-11-12T20:29:17  <sipa> it's useful in the long term, but may need very long fuzzing times to hit anything interesting (much less actual issues)
744 2020-11-12T20:29:18  <michaelfolkson> I think the docs could be improved (but I can't criticise if I haven't tried to improve them)
745 2020-11-12T20:30:04  <MarcoFalke> michaelfolkson: If there is an issue with the docs you can file a bug (or fix them)
746 2020-11-12T20:30:13  <michaelfolkson> It is daunting though when they can take hours to run. And there were troubleshooting issues on Mac which I'm going to avoid by running them on Linux instead
747 2020-11-12T20:30:31  <MarcoFalke> sipa: Agree. The best fuzzers are the ones that trigger the most already-fixed bugs
748 2020-11-12T20:30:49  <michaelfolkson> Right MarcoFalke. I will try to do this. But lots I don't know currently
749 2020-11-12T20:30:50  <sipa> michaelfolkson: i run mine on my 16-core desktop, let it run overnight... all actual problems i've found are within minutes/hours of running
750 2020-11-12T20:31:16  <sipa> (but this is for fuzzers written with very intimite knowledge of what they're testing)
751 2020-11-12T20:31:20  *** cfields <cfields!~cfields@unaffiliated/cfields> has joined #bitcoin-core-dev
752 2020-11-12T20:32:38  <jonatack> michaelfolkson: fuzzers aren't an issue to run overnight to review PRs, or even for a few minutes if you're tight on time as a sanity check and describe that in your review
753 2020-11-12T20:33:16  <jonatack> (i have an older 4-core cpu)
754 2020-11-12T20:33:17  *** flukiluke1 <flukiluke1!~flukiluke@185.204.1.185> has joined #bitcoin-core-dev
755 2020-11-12T20:33:41  <michaelfolkson> By a few minutes you mean run them and stop them hours before completion jonatack?
756 2020-11-12T20:34:09  <jonatack> michaelfolkson: they run until you halt them or they hit an issue
757 2020-11-12T20:34:23  <sipa> fuzzing never completes
758 2020-11-12T20:34:27  <wumpus> fuzzers never 'complete' do they
759 2020-11-12T20:34:32  <wumpus> sipa: heh
760 2020-11-12T20:34:51  <jonatack> michaelfolkson: when reviewing, sometimes running them for less than a minute finds things, e.g. was the case for the BIP324 implementation
761 2020-11-12T20:35:26  <sipa> i found several issues while developing txrequest by writing a fuzzer in parallel with it... it found several crashing bugs within minutes
762 2020-11-12T20:35:37  <jonatack> ^
763 2020-11-12T20:35:37  <michaelfolkson> Does that mean everyone who fuzzes for a few minutes are fuzzing the same thing? And everything else doesn't get "fuzzed"
764 2020-11-12T20:35:40  <sipa> (all before it was PR'ed, and in some cases, started over)
765 2020-11-12T20:35:55  <sipa> michaelfolkson: it's making random variations in the seeds, and see if those trigger anything
766 2020-11-12T20:36:17  <sipa> it's somewhat coverage directed, the fuzzer "learns" what things are potentially relevant and what it isn't
767 2020-11-12T20:36:23  <wumpus> there's a large degree of randomness involved so no one will be testing exactly the same thing
768 2020-11-12T20:36:23  <sipa> but it's really just trying random things
769 2020-11-12T20:36:26  <michaelfolkson> Ah ok. So the randomness ensures different things get "fuzzed"
770 2020-11-12T20:36:40  <sipa> fuzzing == "introducing random variations"
771 2020-11-12T20:37:32  <sipa> we do need a bitcoin core specific fuzzing farm that can run fuzzers with months of CPU time though
772 2020-11-12T20:37:32  <jonatack> there were two really good Review Club meetings on fuzzing
773 2020-11-12T20:37:42  <jonatack> https://bitcoincore.reviews/17860
774 2020-11-12T20:37:56  *** Talkless <Talkless!~Talkless@mail.dargis.net> has quit IRC (Quit: Konversation terminated!)
775 2020-11-12T20:37:57  <michaelfolkson> Yup. Still have lots and lots of questions though ;)
776 2020-11-12T20:38:01  <sipa> shouldn't be too hard to find hardware
777 2020-11-12T20:38:08  <jonatack> https://bitcoincore.reviews/18521
778 2020-11-12T20:39:25  <michaelfolkson> It certainly seems to me the ultimate goal should be guidance on what will be done on a fuzzing farm and what should be done on individual machines
779 2020-11-12T20:40:00  <sipa> michaelfolkson: why would there be a difference?
780 2020-11-12T20:40:01  <MarcoFalke> michaelfolkson: fuzzing should be done
781 2020-11-12T20:40:11  <ja> michaelfolkson: you could engineer a test that breaks only when path A getting taken exactly a million times, and then path B is taken once. if that is a "different thing", your use of "ensures" is wrong ;)
782 2020-11-12T20:40:20  <MarcoFalke> It is additive. Running two machines is better than running one machine
783 2020-11-12T20:40:59  <michaelfolkson> Targeted fuzzing on individual machines. Mass comprehensive fuzzing on a fuzzing farm?
784 2020-11-12T20:41:10  <michaelfolkson> Would that not be the end goal?
785 2020-11-12T20:41:20  <sipa> what is "targetted fuzzing" ?
786 2020-11-12T20:41:42  <sipa> i'll run fuzzers myself locally for code i'm developing if it includes a fuzzer
787 2020-11-12T20:42:17  <michaelfolkson> " i'm less convinced about writing generic fuzzers for code you're not already familiar with"
788 2020-11-12T20:42:31  <michaelfolkson> s/targeted/non-generic
789 2020-11-12T20:43:00  <ja> what's wrong with writing tests for code you don't know? you'll learn the true invariants even if you try to break invariants that don't exist
790 2020-11-12T20:43:25  <sipa> if we had a server farm, and it's orders of magnitude more compute power than what i can do personally, i wouldn't bother with doing anything else myself
791 2020-11-12T20:43:28  <MarcoFalke> ja: Nothing wrong, but tests that don't find issues are not that useful
792 2020-11-12T20:43:29  <sipa> that's not the case though - and all fuzzing right now is people individually running fuzzers
793 2020-11-12T20:43:52  <sipa> ja: if you do learn, it's a great exercise
794 2020-11-12T20:44:08  <michaelfolkson> It is a time issue. Only 24 hours in a day
795 2020-11-12T20:44:21  <ja> MarcoFalke: right, but given that you may find an issue, that could be fixed even if the fuzzing setup doesn't get merged, i think it should be encouraged ;)
796 2020-11-12T20:44:33  <sipa> michaelfolkson: that was about *writing* fuzzers, not running them
797 2020-11-12T20:44:34  <MarcoFalke> michaelfolkson: With 2 CPUs there are 48 CPU hours in one day
798 2020-11-12T20:44:53  <michaelfolkson> Haha ok
799 2020-11-12T20:44:57  <ja> the bottleneck is always the reviewing, right? but if you find a true invariant getting broken, that is still valuable if the fuzzer doesn't get merged
800 2020-11-12T20:45:04  <MarcoFalke> ja: Indeed. I am not discouraging anyone to write tests.
801 2020-11-12T20:45:09  *** promag <promag!~promag@188.250.84.129> has joined #bitcoin-core-dev
802 2020-11-12T20:45:51  <sipa> my view is that many fuzzers we currently have are very superficial, because they're written by someone who doesn't know what they should be testing
803 2020-11-12T20:46:06  <sipa> that doesn't mean they're useless, or that i want to discourage people from doing so
804 2020-11-12T20:46:31  <sipa> but i think there is more value in first understanding the code deeper, and then writing more targetted tests
805 2020-11-12T20:46:54  <michaelfolkson> The problem is not understanding the Core codebase and history of bugs rather than understanding fuzzing?
806 2020-11-12T20:47:26  <michaelfolkson> This isn't a "general expertise" in fuzzing issue?
807 2020-11-12T20:47:47  <MarcoFalke> I do think we have a shortage of expertise
808 2020-11-12T20:52:06  <sipa> i think there is a useful question to be answered that probably isn't too hard with people unfamiliar with the codebase: can we reasonably merge multiple fuzzers into a single binary (and have the actual fuzzer selected by a command line argument)
809 2020-11-12T20:53:03  <MarcoFalke> sipa: for the fuzz engine it shouldn't make a difference
810 2020-11-12T20:53:54  <sipa> we know that it is bad to mix multiple feature tests into one fuzzer (e.g. by using the first N bytes of the input to select the feature), as the fuzz engine will try to cross-pollinate to no avail
811 2020-11-12T20:54:16  <sipa> but right now the build dir for fuzzing is gigabytes
812 2020-11-12T20:54:38  <MarcoFalke> the seeds are also gigabytes
813 2020-11-12T20:55:30  <MarcoFalke> I'll probably create a pull to create a single binary after the branch-off
814 2020-11-12T20:55:50  <MarcoFalke> then, they can also be compiled normally (by default)
815 2020-11-12T20:55:57  <MarcoFalke> for non-fuzz builds
816 2020-11-12T20:56:14  <sipa> yeah, it's not just a space issue, also compile time
817 2020-11-12T20:56:25  <sipa> running the full linker 100s of times
818 2020-11-12T20:56:43  <MarcoFalke> why can't ccache cache the linker result?
819 2020-11-12T20:57:47  <sipa> i'm not sure if linking is ccached, actually
820 2020-11-12T20:58:06  <sipa> but does it matter? any code change in say net_processing.cpp means all fuzzers have to be fully relinked
821 2020-11-12T20:58:28  <MarcoFalke> fair enough
822 2020-11-12T20:59:13  <sipa> MarcoFalke: so you're convinced it doesn't matter for the fuzzing engine?
823 2020-11-12T20:59:26  <MarcoFalke> why should it?
824 2020-11-12T20:59:27  <sipa> that sounds reasonable to me, but i thought we'd want to have some kind of benchmark first
825 2020-11-12T20:59:35  <sipa> more reachable code or something
826 2020-11-12T20:59:49  <sipa> i don't know exactly how the fuzzing engine reasons about those things
827 2020-11-12T21:00:02  *** flukiluke1 <flukiluke1!~flukiluke@185.204.1.185> has quit IRC ()
828 2020-11-12T21:00:35  <sipa> qa-assets directory is 1.3 GiB for me; a full build in fuzz mode is 7.3 GiB
829 2020-11-12T21:00:42  <MarcoFalke> It might break symbolic execution, but we don't use that
830 2020-11-12T21:00:58  <sipa> what's symbolic execution?
831 2020-11-12T21:02:00  <MarcoFalke> Not using values, but symbols (as in math) for detecting violating conditions
832 2020-11-12T21:02:39  <sipa> ok, i knew that... i mean specifially in the context of fuzzing
833 2020-11-12T21:02:52  <sipa> are there fuzz engines that can take advantage of that?
834 2020-11-12T21:03:19  <MarcoFalke> yes, but I haven't tried them
835 2020-11-12T21:04:15  <sipa> ah cool
836 2020-11-12T21:04:22  <MarcoFalke> https://www.youtube.com/watch?v=h_A8IRBEtdQ
837 2020-11-12T21:05:03  <MarcoFalke> :( Can't play it anymore. Looks like youtube deleted all webm transcodings for videos with less than 10k views
838 2020-11-12T21:07:12  <sipa> works fine here?
839 2020-11-12T21:08:27  <michaelfolkson> Works for me fine in the browser
840 2020-11-12T21:10:04  *** jeremyrubin <jeremyrubin!~jr@c-73-15-215-148.hsd1.ca.comcast.net> has quit IRC (Ping timeout: 265 seconds)
841 2020-11-12T21:10:51  <queip> MarcoFalke: works for me, YT has outage yesterday, perhaps it's stay intermittent in some places
842 2020-11-12T21:12:21  <MarcoFalke> oh, it is WEBM DASH
843 2020-11-12T21:12:21  *** promag <promag!~promag@188.250.84.129> has quit IRC (Remote host closed the connection)
844 2020-11-12T21:13:52  <MarcoFalke> hmm https://bugzilla.mozilla.org/show_bug.cgi?id=778617
845 2020-11-12T21:20:50  *** Guyver2 <Guyver2!Guyver@guyver2.xs4all.nl> has quit IRC (Quit: Going offline, see ya! (www.adiirc.com))
846 2020-11-12T21:22:39  <ja> michaelfolkson: which codec is it using?
847 2020-11-12T21:23:17  *** James_F1 <James_F1!~James_F@178.162.212.214> has joined #bitcoin-core-dev
848 2020-11-12T21:29:17  *** jeremyrubin <jeremyrubin!~jr@c-73-15-215-148.hsd1.ca.comcast.net> has joined #bitcoin-core-dev
849 2020-11-12T21:36:13  *** nckx <nckx!~nckx@tobias.gr> has quit IRC (Ping timeout: 264 seconds)
850 2020-11-12T21:49:04  *** CubicEarth <CubicEarth!~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net> has quit IRC (Ping timeout: 260 seconds)
851 2020-11-12T21:51:48  *** CubicEarth <CubicEarth!~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net> has joined #bitcoin-core-dev
852 2020-11-12T21:54:36  *** troygiorshev <troygiorshev!~troygiors@d67-193-140-136.home3.cgocable.net> has joined #bitcoin-core-dev
853 2020-11-12T21:57:57  <troygiorshev> !topic
854 2020-11-12T21:57:57  <gribble> Bitcoin Core development discussion and commit log | Feel free to watch, but please take commentary and usage questions to #bitcoin | Channel logs: http://www.erisian.com.au/bitcoin-core-dev/, http://gnusha.org/bitcoin-core-dev/ | Meeting topics http://gnusha.org/bitcoin-core-dev/proposedmeetingtopics.txt / http://gnusha.org/bitcoin-core-dev/proposedwalletmeetingtopics.txt
855 2020-11-12T22:00:24  *** Cory <Cory!~Cory@unaffiliated/cory> has quit IRC (Ping timeout: 258 seconds)
856 2020-11-12T22:06:55  *** Cory <Cory!~Cory@unaffiliated/cory> has joined #bitcoin-core-dev
857 2020-11-12T22:08:22  *** filchef <filchef!~filchef@212.104.97.177> has quit IRC (Quit: KVIrc 5.0.0 Aria http://www.kvirc.net/)
858 2020-11-12T22:08:57  *** vasild_ <vasild_!~vd@gateway/tor-sasl/vasild> has joined #bitcoin-core-dev
859 2020-11-12T22:12:03  *** vasild <vasild!~vd@gateway/tor-sasl/vasild> has quit IRC (Ping timeout: 240 seconds)
860 2020-11-12T22:12:04  *** vasild_ is now known as vasild
861 2020-11-12T22:19:36  *** TheRec <TheRec!~toto@drupal.org/user/146860/view> has quit IRC ()
862 2020-11-12T22:24:42  *** promag <promag!~promag@188.250.84.129> has joined #bitcoin-core-dev
863 2020-11-12T22:28:27  *** Kiminuo <Kiminuo!~mix@141.98.103.92> has quit IRC (Ping timeout: 256 seconds)
864 2020-11-12T22:31:16  *** proofofkeags <proofofkeags!~proofofke@174-16-205-160.hlrn.qwest.net> has quit IRC (Ping timeout: 244 seconds)
865 2020-11-12T22:32:51  *** nckx <nckx!~nckx@tobias.gr> has joined #bitcoin-core-dev
866 2020-11-12T22:33:49  *** sr_gi <sr_gi!~sr_gi@static-120-201-229-77.ipcom.comunitel.net> has quit IRC (Read error: Connection reset by peer)
867 2020-11-12T22:34:08  *** sr_gi <sr_gi!~sr_gi@static-120-201-229-77.ipcom.comunitel.net> has joined #bitcoin-core-dev
868 2020-11-12T22:43:09  *** TheRec <TheRec!~toto@drupal.org/user/146860/view> has joined #bitcoin-core-dev
869 2020-11-12T22:57:26  *** yanmaani <yanmaani!~yanmaani@gateway/tor-sasl/yanmaani> has joined #bitcoin-core-dev
870 2020-11-12T23:07:48  *** davterra <davterra!~davterra@69.4.234.71> has quit IRC (Read error: Connection reset by peer)
871 2020-11-12T23:08:01  *** davterra <davterra!~davterra@69.4.234.71> has joined #bitcoin-core-dev
872 2020-11-12T23:08:05  *** nanotube <nanotube!~nanotube@unaffiliated/nanotube> has quit IRC (Ping timeout: 240 seconds)
873 2020-11-12T23:12:23  *** jb55 <jb55!~jb55@gateway/tor-sasl/jb55> has quit IRC (Ping timeout: 240 seconds)
874 2020-11-12T23:16:00  *** nanotube <nanotube!~nanotube@unaffiliated/nanotube> has joined #bitcoin-core-dev
875 2020-11-12T23:19:03  *** promag <promag!~promag@188.250.84.129> has quit IRC (Remote host closed the connection)
876 2020-11-12T23:21:08  *** jeremyrubin <jeremyrubin!~jr@c-73-15-215-148.hsd1.ca.comcast.net> has quit IRC (Ping timeout: 256 seconds)
877 2020-11-12T23:21:49  *** mrostecki <mrostecki!~mrostecki@gateway/tor-sasl/mrostecki> has joined #bitcoin-core-dev
878 2020-11-12T23:26:10  *** bralyclow2 <bralyclow2!~bralyclow@unaffiliated/bralyclow> has joined #bitcoin-core-dev
879 2020-11-12T23:26:35  *** jb55 <jb55!~jb55@gateway/tor-sasl/jb55> has joined #bitcoin-core-dev
880 2020-11-12T23:55:34  *** mol_ <mol_!~mol@unaffiliated/molly> has quit IRC (Read error: Connection reset by peer)
881 2020-11-12T23:55:59  *** mol_ <mol_!~mol@unaffiliated/molly> has joined #bitcoin-core-dev
882 2020-11-12T23:57:33  *** midnight <midnight!~midnight@unaffiliated/midnightmagic> has quit IRC (Ping timeout: 244 seconds)