12020-11-12T00:00:01 *** darkbot-rc4 <darkbot-rc4!~darkbot-r@139.28.218.148> has quit IRC ()
22020-11-12T00:01:08 *** gleb2 <gleb2!~gleb@178.150.137.228> has quit IRC (Quit: Ping timeout (120 seconds))
32020-11-12T00:02:18 *** gleb <gleb!~gleb@178.150.137.228> has joined #bitcoin-core-dev
42020-11-12T00:22:22 *** cmeiklejohn1 <cmeiklejohn1!~cmeiklejo@84.39.117.57> has joined #bitcoin-core-dev
52020-11-12T00:25:50 *** Tennis <Tennis!~Tennis@unaffiliated/tennis> has quit IRC (Quit: Leaving)
62020-11-12T00:27:14 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
72020-11-12T00:27:14 <bitcoin-git> [bitcoin] meshcollider pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/d9f5132736f3...c2d8ba6265a4
82020-11-12T00:27:15 <bitcoin-git> bitcoin/master 69f59af Luke Dashjr: Bugfix: Wallet: Soft-fail exceptions within ListWalletDir file checks
92020-11-12T00:27:15 <bitcoin-git> bitcoin/master 24d2d33 Luke Dashjr: QA: wallet_multiwallet: Check that recursive symlink directory and wallet....
102020-11-12T00:27:16 <bitcoin-git> bitcoin/master c2d8ba6 Samuel Dobson: Merge #19502: Bugfix: Wallet: Soft-fail exceptions within ListWalletDir fi...
112020-11-12T00:27:17 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
122020-11-12T00:28:09 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
132020-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
142020-11-12T00:28:10 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
152020-11-12T00:33:54 *** bitdex <bitdex!~bitdex@gateway/tor-sasl/bitdex> has joined #bitcoin-core-dev
162020-11-12T00:46:18 *** Emcy_ <Emcy_!~Emcy@unaffiliated/emcy> has quit IRC (Read error: Connection reset by peer)
172020-11-12T00:49:10 *** Emcy <Emcy!~Emcy@unaffiliated/emcy> has joined #bitcoin-core-dev
182020-11-12T00:49:37 *** AaronvanW <AaronvanW!~AaronvanW@unaffiliated/aaronvanw> has quit IRC ()
192020-11-12T00:51:10 *** AaronvanW <AaronvanW!~AaronvanW@unaffiliated/aaronvanw> has joined #bitcoin-core-dev
202020-11-12T00:53:45 *** queip <queip!~queip@unaffiliated/rezurus> has quit IRC (Ping timeout: 240 seconds)
212020-11-12T00:57:23 *** k3tan <k3tan!~pi@gateway/tor-sasl/k3tan> has quit IRC (Ping timeout: 240 seconds)
222020-11-12T00:59:59 *** da39a3ee5e6b4b0d <da39a3ee5e6b4b0d!~da39a3ee5@cm-171-98-69-228.revip7.asianet.co.th> has joined #bitcoin-core-dev
232020-11-12T01:05:13 *** k3tan <k3tan!~pi@gateway/tor-sasl/k3tan> has joined #bitcoin-core-dev
242020-11-12T01:06:49 *** da39a3ee5e6b4b0d <da39a3ee5e6b4b0d!~da39a3ee5@cm-171-98-69-228.revip7.asianet.co.th> has quit IRC (Ping timeout: 264 seconds)
252020-11-12T01:10:30 *** da39a3ee5e6b4b0d <da39a3ee5e6b4b0d!~da39a3ee5@cm-171-98-69-228.revip7.asianet.co.th> has joined #bitcoin-core-dev
262020-11-12T01:22:26 *** rc_423 <rc_423!~r_423@cpe-75-185-100-189.cinci.res.rr.com> has joined #bitcoin-core-dev
272020-11-12T01:25:44 *** AaronvanW <AaronvanW!~AaronvanW@unaffiliated/aaronvanw> has quit IRC (Remote host closed the connection)
282020-11-12T01:26:31 *** mrostecki <mrostecki!~mrostecki@gateway/tor-sasl/mrostecki> has quit IRC (Remote host closed the connection)
292020-11-12T01:35:30 *** da39a3ee5e6b4b0d <da39a3ee5e6b4b0d!~da39a3ee5@cm-171-98-69-228.revip7.asianet.co.th> has quit IRC (Ping timeout: 260 seconds)
302020-11-12T01:46:09 *** da39a3ee5e6b4b0d <da39a3ee5e6b4b0d!~da39a3ee5@67.23.55.162> has joined #bitcoin-core-dev
312020-11-12T01:47:58 *** m9aq <m9aq!~m9aq@106.37.187.213> has joined #bitcoin-core-dev
322020-11-12T01:49:22 *** promag <promag!~promag@188.250.84.129> has quit IRC (Remote host closed the connection)
332020-11-12T02:27:11 *** da39a3ee5e6b4b0d <da39a3ee5e6b4b0d!~da39a3ee5@67.23.55.162> has quit IRC (Quit: Textual IRC Client: www.textualapp.com)
342020-11-12T02:30:42 *** bitdex <bitdex!~bitdex@gateway/tor-sasl/bitdex> has quit IRC (Remote host closed the connection)
352020-11-12T02:31:06 *** bitdex <bitdex!~bitdex@gateway/tor-sasl/bitdex> has joined #bitcoin-core-dev
362020-11-12T02:34:52 *** AaronvanW <AaronvanW!~AaronvanW@unaffiliated/aaronvanw> has joined #bitcoin-core-dev
372020-11-12T02:37:44 *** da39a3ee5e6b4b0d <da39a3ee5e6b4b0d!~da39a3ee5@cm-171-98-69-228.revip7.asianet.co.th> has joined #bitcoin-core-dev
382020-11-12T02:45:31 *** glozow <glozow!uid453516@gateway/web/irccloud.com/x-xodpewyyywlkchym> has quit IRC (Quit: Connection closed for inactivity)
392020-11-12T02:50:31 *** queip <queip!~queip@unaffiliated/rezurus> has joined #bitcoin-core-dev
402020-11-12T03:00:01 *** cmeiklejohn1 <cmeiklejohn1!~cmeiklejo@84.39.117.57> has quit IRC ()
412020-11-12T03:05:34 *** AaronvanW <AaronvanW!~AaronvanW@unaffiliated/aaronvanw> has quit IRC (Ping timeout: 260 seconds)
422020-11-12T03:19:29 *** da39a3ee5e6b4b0d <da39a3ee5e6b4b0d!~da39a3ee5@cm-171-98-69-228.revip7.asianet.co.th> has quit IRC (Ping timeout: 265 seconds)
432020-11-12T03:23:12 *** true-asset <true-asset!~true-asse@84.39.117.57> has joined #bitcoin-core-dev
442020-11-12T03:26:50 *** m9aq_ <m9aq_!~m9aq@106.37.187.213> has joined #bitcoin-core-dev
452020-11-12T03:28:21 *** m9aq <m9aq!~m9aq@106.37.187.213> has quit IRC (Ping timeout: 258 seconds)
462020-11-12T03:28:21 *** m9aq_ is now known as m9aq
472020-11-12T03:38:14 *** gribble <gribble!~gribble@unaffiliated/nanotube/bot/gribble> has quit IRC (Remote host closed the connection)
482020-11-12T03:54:02 *** belcher_ <belcher_!~belcher@unaffiliated/belcher> has joined #bitcoin-core-dev
492020-11-12T03:56:46 *** belcher <belcher!~belcher@unaffiliated/belcher> has quit IRC (Ping timeout: 272 seconds)
502020-11-12T04:04:04 *** kristapsk <kristapsk!~KK@gateway/tor-sasl/kristapsk> has quit IRC (Remote host closed the connection)
512020-11-12T04:08:28 *** kristapsk <kristapsk!~KK@gateway/tor-sasl/kristapsk> has joined #bitcoin-core-dev
522020-11-12T04:11:29 *** kexkey <kexkey!~kexkey@static-198-54-132-153.cust.tzulo.com> has quit IRC (Ping timeout: 260 seconds)
532020-11-12T04:16:42 *** gribble <gribble!~gribble@unaffiliated/nanotube/bot/gribble> has joined #bitcoin-core-dev
542020-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)
552020-11-12T04:41:24 *** DeanGuss <DeanGuss!~dean@gateway/tor-sasl/deanguss> has joined #bitcoin-core-dev
562020-11-12T04:43:43 *** DeanWeen <DeanWeen!~dean@gateway/tor-sasl/deanguss> has quit IRC (Ping timeout: 240 seconds)
572020-11-12T04:54:43 *** Deacyde <Deacyde!~Deacyde@unaffiliated/deacyde> has quit IRC (Quit: May the Shwartz be with you)
582020-11-12T05:02:32 *** AaronvanW <AaronvanW!~AaronvanW@unaffiliated/aaronvanw> has joined #bitcoin-core-dev
592020-11-12T05:06:23 *** tryphe <tryphe!~tryphe@unaffiliated/tryphe> has joined #bitcoin-core-dev
602020-11-12T05:07:47 *** tryphe_ <tryphe_!~tryphe@unaffiliated/tryphe> has quit IRC (Ping timeout: 260 seconds)
612020-11-12T05:11:26 *** justanotheruser <justanotheruser!~justanoth@unaffiliated/justanotheruser> has quit IRC (Ping timeout: 264 seconds)
622020-11-12T05:18:07 *** justanotheruser <justanotheruser!~justanoth@unaffiliated/justanotheruser> has joined #bitcoin-core-dev
632020-11-12T05:36:16 *** AaronvanW <AaronvanW!~AaronvanW@unaffiliated/aaronvanw> has quit IRC (Ping timeout: 265 seconds)
642020-11-12T05:42:42 *** visage_ <visage_!~visage_@unaffiliated/visage/x-6658724> has quit IRC (Quit: Textual IRC Client: www.textualapp.com)
652020-11-12T05:44:37 *** m9aq <m9aq!~m9aq@106.37.187.213> has quit IRC (Ping timeout: 264 seconds)
662020-11-12T05:44:52 *** m9aq <m9aq!~m9aq@106.37.187.213> has joined #bitcoin-core-dev
672020-11-12T06:00:01 *** true-asset <true-asset!~true-asse@84.39.117.57> has quit IRC ()
682020-11-12T06:02:53 *** EagleTM <EagleTM!~EagleTM@unaffiliated/eagletm> has joined #bitcoin-core-dev
692020-11-12T06:08:28 *** bosch-0 <bosch-0!uid472282@gateway/web/irccloud.com/x-gjvbqlqofnghqnkw> has joined #bitcoin-core-dev
702020-11-12T06:11:03 *** az0re <az0re!~az0re@gateway/tor-sasl/az0re> has quit IRC (Ping timeout: 240 seconds)
712020-11-12T06:22:38 *** slewis <slewis!~slewis@178.162.212.214> has joined #bitcoin-core-dev
722020-11-12T06:33:24 *** Bullit <Bullit!~Bullit01@042-236-158-163.dynamic.caiway.nl> has joined #bitcoin-core-dev
732020-11-12T06:56:19 *** az0re <az0re!~az0re@gateway/tor-sasl/az0re> has joined #bitcoin-core-dev
742020-11-12T06:57:09 *** m9aq <m9aq!~m9aq@106.37.187.213> has quit IRC (Ping timeout: 260 seconds)
752020-11-12T07:28:08 *** andrewtoth_ <andrewtoth_!~andrewtot@gateway/tor-sasl/andrewtoth> has joined #bitcoin-core-dev
762020-11-12T07:30:19 *** _andrewtoth_ <_andrewtoth_!~andrewtot@gateway/tor-sasl/andrewtoth> has quit IRC (Remote host closed the connection)
772020-11-12T07:33:08 *** AaronvanW <AaronvanW!~AaronvanW@unaffiliated/aaronvanw> has joined #bitcoin-core-dev
782020-11-12T07:44:04 *** queip <queip!~queip@unaffiliated/rezurus> has quit IRC (Ping timeout: 246 seconds)
792020-11-12T07:45:07 *** yanmaani <yanmaani!~yanmaani@gateway/tor-sasl/yanmaani> has joined #bitcoin-core-dev
802020-11-12T07:48:10 *** queip <queip!~queip@unaffiliated/rezurus> has joined #bitcoin-core-dev
812020-11-12T07:52:51 <hebasto> it seems merged #19502 resolves all issues of #18095, so the latter could be closed.
822020-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
832020-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
842020-11-12T07:55:12 *** tryphe_ <tryphe_!~tryphe@unaffiliated/tryphe> has joined #bitcoin-core-dev
852020-11-12T07:55:45 *** tryphe <tryphe!~tryphe@unaffiliated/tryphe> has quit IRC (Ping timeout: 240 seconds)
862020-11-12T08:03:57 *** Kiminuo <Kiminuo!~mix@141.98.103.92> has joined #bitcoin-core-dev
872020-11-12T08:04:33 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
882020-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
892020-11-12T08:04:35 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
902020-11-12T08:06:28 *** AaronvanW <AaronvanW!~AaronvanW@unaffiliated/aaronvanw> has quit IRC (Ping timeout: 246 seconds)
912020-11-12T08:17:38 *** bosch-0 <bosch-0!uid472282@gateway/web/irccloud.com/x-gjvbqlqofnghqnkw> has quit IRC (Quit: Connection closed for inactivity)
922020-11-12T08:28:06 *** Guyver2 <Guyver2!Guyver@guyver2.xs4all.nl> has joined #bitcoin-core-dev
932020-11-12T08:34:49 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
942020-11-12T08:34:50 <bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/c2d8ba6265a4...bcd142e479fa
952020-11-12T08:34:50 <bitcoin-git> bitcoin/master c82336c fanquake: Remove references to CreateWalletFromFile
962020-11-12T08:34:51 <bitcoin-git> bitcoin/master bcd142e MarcoFalke: Merge #20285: Remove references to CreateWalletFromFile
972020-11-12T08:34:53 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
982020-11-12T08:35:09 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
992020-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
1002020-11-12T08:35:10 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
1012020-11-12T08:36:44 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
1022020-11-12T08:36:44 <bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/bcd142e479fa...027e51f71517
1032020-11-12T08:36:44 <bitcoin-git> bitcoin/master ee11a41 practicalswift: Avoid signed integer overflow when loading a mempool.dat file with a malfo...
1042020-11-12T08:36:45 <bitcoin-git> bitcoin/master 027e51f MarcoFalke: Merge #20372: Avoid signed integer overflow when loading a mempool.dat fil...
1052020-11-12T08:36:46 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
1062020-11-12T08:37:04 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
1072020-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
1082020-11-12T08:37:06 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
1092020-11-12T08:39:52 *** promag <promag!~promag@188.250.84.129> has joined #bitcoin-core-dev
1102020-11-12T08:45:40 *** da39a3ee5e6b4b0d <da39a3ee5e6b4b0d!~da39a3ee5@cm-171-98-69-228.revip7.asianet.co.th> has joined #bitcoin-core-dev
1112020-11-12T08:45:53 *** IGHOR <IGHOR!~quassel@176.121.4.135> has quit IRC (Quit: No Ping reply in 180 seconds.)
1122020-11-12T08:48:01 *** IGHOR <IGHOR!~quassel@176.121.4.135> has joined #bitcoin-core-dev
1132020-11-12T08:58:11 *** AdulrunaRedviva <AdulrunaRedviva!c3d69d22@195.214.157.34> has joined #bitcoin-core-dev
1142020-11-12T08:59:48 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
1152020-11-12T08:59:48 <bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/027e51f71517...af8ec1d3e576
1162020-11-12T08:59:48 <bitcoin-git> bitcoin/master 3c77b80 practicalswift: fuzz: Improve coverage for CPartialMerkleTree fuzzing harness
1172020-11-12T08:59:49 <bitcoin-git> bitcoin/master af8ec1d MarcoFalke: Merge #20375: fuzz: Improve coverage for CPartialMerkleTree fuzzing harnes...
1182020-11-12T08:59:50 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
1192020-11-12T09:00:01 *** slewis <slewis!~slewis@178.162.212.214> has quit IRC ()
1202020-11-12T09:00:05 *** icota[m] <icota[m]!icotamatri@gateway/shell/matrix.org/x-jfxechrxuoddrluf> has quit IRC (Quit: Idle for 30+ days)
1212020-11-12T09:00:08 *** da39a3ee5e6b4b0d <da39a3ee5e6b4b0d!~da39a3ee5@cm-171-98-69-228.revip7.asianet.co.th> has quit IRC (Ping timeout: 272 seconds)
1222020-11-12T09:00:08 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
1232020-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
1242020-11-12T09:00:09 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
1252020-11-12T09:09:06 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
1262020-11-12T09:09:06 <bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/af8ec1d3e576...8a486158cbc3
1272020-11-12T09:09:07 <bitcoin-git> bitcoin/master 79ef832 practicalswift: tests: Add fuzzing harness for CConnman
1282020-11-12T09:09:07 <bitcoin-git> bitcoin/master 8a48615 MarcoFalke: Merge #20188: tests: Add fuzzing harness for CConnman
1292020-11-12T09:09:08 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
1302020-11-12T09:09:26 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
1312020-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
1322020-11-12T09:09:27 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
1332020-11-12T09:14:25 *** Victorsueca <Victorsueca!~Victorsue@unaffiliated/victorsueca> has quit IRC (Ping timeout: 240 seconds)
1342020-11-12T09:20:32 *** opsec_x12 <opsec_x12!~opsec_x12@44-25-143-49.ip.hamwan.net> has joined #bitcoin-core-dev
1352020-11-12T09:24:18 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
1362020-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
1372020-11-12T09:24:19 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
1382020-11-12T09:29:49 *** luke-jr <luke-jr!~luke-jr@unaffiliated/luke-jr> has quit IRC (Quit: ZNC - http://znc.sourceforge.net)
1392020-11-12T09:30:13 *** luke-jr <luke-jr!~luke-jr@unaffiliated/luke-jr> has joined #bitcoin-core-dev
1402020-11-12T09:36:09 *** promag <promag!~promag@188.250.84.129> has quit IRC (Remote host closed the connection)
1412020-11-12T09:39:11 *** promag <promag!~promag@188.250.84.129> has joined #bitcoin-core-dev
1422020-11-12T09:44:34 *** jeremyrubin <jeremyrubin!~jr@c-73-15-215-148.hsd1.ca.comcast.net> has quit IRC (Ping timeout: 260 seconds)
1432020-11-12T09:56:06 *** tsmango <tsmango!~tsmango@178.239.168.171> has joined #bitcoin-core-dev
1442020-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)
1452020-11-12T10:03:23 *** sr_gi <sr_gi!~sr_gi@static-120-201-229-77.ipcom.comunitel.net> has joined #bitcoin-core-dev
1462020-11-12T10:03:58 *** AaronvanW <AaronvanW!~AaronvanW@unaffiliated/aaronvanw> has joined #bitcoin-core-dev
1472020-11-12T10:08:48 *** vasild_ <vasild_!~vd@gateway/tor-sasl/vasild> has joined #bitcoin-core-dev
1482020-11-12T10:08:58 *** troygiorshev <troygiorshev!~troygiors@d67-193-140-136.home3.cgocable.net> has quit IRC (Ping timeout: 246 seconds)
1492020-11-12T10:12:03 *** vasild <vasild!~vd@gateway/tor-sasl/vasild> has quit IRC (Ping timeout: 240 seconds)
1502020-11-12T10:12:04 *** vasild_ is now known as vasild
1512020-11-12T10:28:09 *** AdulrunaRedviva <AdulrunaRedviva!c3d69d22@195.214.157.34> has quit IRC (Remote host closed the connection)
1522020-11-12T10:31:22 *** da39a3ee5e6b4b0d <da39a3ee5e6b4b0d!~da39a3ee5@cm-171-98-69-228.revip7.asianet.co.th> has joined #bitcoin-core-dev
1532020-11-12T10:56:53 *** AdulrunaRedviva <AdulrunaRedviva!c3d69d22@195.214.157.34> has joined #bitcoin-core-dev
1542020-11-12T10:59:25 *** Guyver2_ <Guyver2_!Guyver@guyver2.xs4all.nl> has joined #bitcoin-core-dev
1552020-11-12T11:01:11 *** Lexyon____ <Lexyon____!sid402723@gateway/web/irccloud.com/x-xzmxwubdunekjens> has quit IRC (Quit: Connection closed for inactivity)
1562020-11-12T11:01:12 *** wonderworker <wonderworker!bc2b8820@188.43.136.32> has joined #bitcoin-core-dev
1572020-11-12T11:01:51 *** wonderworker <wonderworker!bc2b8820@188.43.136.32> has left #bitcoin-core-dev
1582020-11-12T11:02:22 *** Guyver2 <Guyver2!Guyver@guyver2.xs4all.nl> has quit IRC (Ping timeout: 256 seconds)
1592020-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.
1602020-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
1612020-11-12T11:05:15 <jonatack> Thanks to murch and achow101 for reviewing it so far.
1622020-11-12T11:16:56 *** Kiminuo <Kiminuo!~mix@141.98.103.92> has quit IRC (Ping timeout: 272 seconds)
1632020-11-12T11:18:06 *** AaronvanW <AaronvanW!~AaronvanW@unaffiliated/aaronvanw> has quit IRC (Remote host closed the connection)
1642020-11-12T11:18:22 *** AaronvanW <AaronvanW!~AaronvanW@unaffiliated/aaronvanw> has joined #bitcoin-core-dev
1652020-11-12T11:18:26 *** Aniyah8Lubowitz <Aniyah8Lubowitz!~Aniyah8Lu@static.57.1.216.95.clients.your-server.de> has joined #bitcoin-core-dev
1662020-11-12T11:24:34 *** mrostecki <mrostecki!~mrostecki@gateway/tor-sasl/mrostecki> has joined #bitcoin-core-dev
1672020-11-12T11:24:36 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
1682020-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
1692020-11-12T11:24:37 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
1702020-11-12T11:24:51 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
1712020-11-12T11:24:52 <bitcoin-git> [bitcoin] jonasschnelli pushed 4 commits to master: https://github.com/bitcoin/bitcoin/compare/8a486158cbc3...9bd131669729
1722020-11-12T11:24:53 <bitcoin-git> bitcoin/master 7b3b230 João Barbosa: move-only: Define TransactionNotification before TransactionTablePriv
1732020-11-12T11:24:54 <bitcoin-git> bitcoin/master 989e579 João Barbosa: qt: Make transaction notification queue wallet specific
1742020-11-12T11:24:55 <bitcoin-git> bitcoin/master 2414342 João Barbosa: refactor: qt: Use vQueueNotifications.clear()
1752020-11-12T11:24:56 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
1762020-11-12T11:34:15 *** kristapsk <kristapsk!~KK@gateway/tor-sasl/kristapsk> has quit IRC (Remote host closed the connection)
1772020-11-12T11:34:41 *** kristapsk <kristapsk!~KK@gateway/tor-sasl/kristapsk> has joined #bitcoin-core-dev
1782020-11-12T11:35:21 *** AdulrunaRedviva5 <AdulrunaRedviva5!c3d69d22@195.214.157.34> has joined #bitcoin-core-dev
1792020-11-12T11:35:28 *** AdulrunaRedviva5 <AdulrunaRedviva5!c3d69d22@195.214.157.34> has left #bitcoin-core-dev
1802020-11-12T11:38:25 *** AdulrunaRedviva <AdulrunaRedviva!c3d69d22@195.214.157.34> has quit IRC (Ping timeout: 245 seconds)
1812020-11-12T11:44:15 *** Guyver2__ <Guyver2__!Guyver@guyver2.xs4all.nl> has joined #bitcoin-core-dev
1822020-11-12T11:47:08 *** Guyver2_ <Guyver2_!Guyver@guyver2.xs4all.nl> has quit IRC (Ping timeout: 256 seconds)
1832020-11-12T11:49:36 *** einyx <einyx!einyx@fsf/member/einyx> has joined #bitcoin-core-dev
1842020-11-12T11:50:31 *** einyx_ <einyx_!einyx@fsf/member/einyx> has quit IRC (Ping timeout: 258 seconds)
1852020-11-12T12:00:01 *** tsmango <tsmango!~tsmango@178.239.168.171> has quit IRC ()
1862020-11-12T12:01:39 *** da39a3ee5e6b4b0d <da39a3ee5e6b4b0d!~da39a3ee5@cm-171-98-69-228.revip7.asianet.co.th> has quit IRC (Ping timeout: 256 seconds)
1872020-11-12T12:02:18 *** belcher_ is now known as belcher
1882020-11-12T12:16:43 *** Kiminuo <Kiminuo!~mix@141.98.103.92> has joined #bitcoin-core-dev
1892020-11-12T12:19:47 *** Aniyah8Lubowitz <Aniyah8Lubowitz!~Aniyah8Lu@static.57.1.216.95.clients.your-server.de> has quit IRC (Ping timeout: 256 seconds)
1902020-11-12T12:21:53 *** kristapsk_ <kristapsk_!~KK@gateway/tor-sasl/kristapsk> has joined #bitcoin-core-dev
1912020-11-12T12:24:03 *** kristapsk <kristapsk!~KK@gateway/tor-sasl/kristapsk> has quit IRC (Ping timeout: 240 seconds)
1922020-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
1932020-11-12T12:32:03 <MarcoFalke> vasild: Can be ignored
1942020-11-12T12:32:11 <MarcoFalke> Fix would be to rebase on current master, but we don't want that
1952020-11-12T12:33:05 <vasild> cirrus is not merging the tip of the PR into latest master before testing, like travis?
1962020-11-12T12:37:01 <MarcoFalke> not for the config
1972020-11-12T12:37:08 <vasild> ok
1982020-11-12T12:37:10 <MarcoFalke> Though the code is merged in the merge_base step
1992020-11-12T12:49:54 *** Tennis <Tennis!~Tennis@unaffiliated/tennis> has joined #bitcoin-core-dev
2002020-11-12T12:50:53 *** DeanWeen <DeanWeen!~dean@gateway/tor-sasl/deanguss> has joined #bitcoin-core-dev
2012020-11-12T12:53:03 *** DeanGuss <DeanGuss!~dean@gateway/tor-sasl/deanguss> has quit IRC (Ping timeout: 240 seconds)
2022020-11-12T12:54:37 *** tw1sted1 <tw1sted1!~tw1sted@195.206.169.184> has joined #bitcoin-core-dev
2032020-11-12T12:56:18 *** morcos <morcos!~morcos@gateway/tor-sasl/morcos> has quit IRC (Remote host closed the connection)
2042020-11-12T12:56:50 *** einyx <einyx!einyx@fsf/member/einyx> has quit IRC (Read error: Connection reset by peer)
2052020-11-12T12:57:01 *** morcos <morcos!~morcos@gateway/tor-sasl/morcos> has joined #bitcoin-core-dev
2062020-11-12T13:01:32 *** einyx <einyx!einyx@fsf/member/einyx> has joined #bitcoin-core-dev
2072020-11-12T13:06:31 *** Mercury_Vapor <Mercury_Vapor!~Mercury_V@174-082-166-092.res.spectrum.com> has joined #bitcoin-core-dev
2082020-11-12T13:07:29 *** glozow <glozow!uid453516@gateway/web/irccloud.com/x-bxytrqtdrqgdakox> has joined #bitcoin-core-dev
2092020-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?
2102020-11-12T13:24:51 <queip> recommended nomenclature for keys is: SK - secret key, PK - public key, HPK - hash of PK, right?
2112020-11-12T13:31:56 *** Guyver2__ is now known as Guyver2
2122020-11-12T13:35:25 *** filchef <filchef!~filchef@212.104.97.177> has joined #bitcoin-core-dev
2132020-11-12T13:44:47 <MarcoFalke> jonasschnelli: Nope. How is your config different from ./ci/test/00_setup_env_native_asan.sh ?
2142020-11-12T13:45:44 <MarcoFalke> the ci config is running Ubuntu focal
2152020-11-12T13:47:05 <jonasschnelli> I guess clang 8 (bbb) vs 10 (cirrus) should not make a difference
2162020-11-12T13:47:35 <jonasschnelli> bbb doesn't set -DARENA_DEBUG
2172020-11-12T14:08:22 *** einyx_ <einyx_!einyx@fsf/member/einyx> has joined #bitcoin-core-dev
2182020-11-12T14:09:04 *** einyx <einyx!einyx@fsf/member/einyx> has quit IRC (Ping timeout: 246 seconds)
2192020-11-12T14:17:04 <shesek> which block validity rules can be validated by spv clients?
2202020-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?
2212020-11-12T14:28:25 *** bitdex <bitdex!~bitdex@gateway/tor-sasl/bitdex> has quit IRC (Quit: = "")
2222020-11-12T14:34:07 *** shesek <shesek!~shesek@unaffiliated/shesek> has quit IRC (Remote host closed the connection)
2232020-11-12T14:36:46 *** shesek <shesek!~shesek@unaffiliated/shesek> has joined #bitcoin-core-dev
2242020-11-12T14:36:55 *** Emcy <Emcy!~Emcy@unaffiliated/emcy> has quit IRC (Read error: Connection reset by peer)
2252020-11-12T14:37:21 *** wullon <wullon!~wullon@241.243.86.88.rdns.comcable.net> has quit IRC (Read error: Connection reset by peer)
2262020-11-12T14:37:42 <shesek> (I got disconnected and didn't see replies if there were any)
2272020-11-12T14:38:04 *** wullon <wullon!~wullon@241.243.86.88.rdns.comcable.net> has joined #bitcoin-core-dev
2282020-11-12T14:45:23 *** Emcy <Emcy!~Emcy@unaffiliated/emcy> has joined #bitcoin-core-dev
2292020-11-12T14:51:48 *** kexkey <kexkey!~kexkey@static-198-54-132-137.cust.tzulo.com> has joined #bitcoin-core-dev
2302020-11-12T15:00:01 *** tw1sted1 <tw1sted1!~tw1sted@195.206.169.184> has quit IRC ()
2312020-11-12T15:18:54 <jonasschnelli> shesek: there where non. :)
2322020-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
2332020-11-12T15:20:39 <Kiminuo> shesek, see http://gnusha.org/bitcoin-core-dev/2020-11-12.log
2342020-11-12T15:20:41 <jonasschnelli> but I recommend to join #bitcoin-dev
2352020-11-12T15:20:55 <jonasschnelli> this channel is for bitcoin core development
2362020-11-12T15:21:26 *** SLNP <SLNP!~SLNP@89.249.74.218> has joined #bitcoin-core-dev
2372020-11-12T15:25:23 *** jeremyrubin <jeremyrubin!~jr@c-73-15-215-148.hsd1.ca.comcast.net> has joined #bitcoin-core-dev
2382020-11-12T15:26:13 <shesek> jonasschnelli, of course, apologies for going off topic, will take notice next time
2392020-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
2402020-11-12T15:27:58 <jonasschnelli> shesek: yeah.. maybe also #bitcoin can help
2412020-11-12T15:28:09 <jonasschnelli> luke-jr have made some thought on that AFAIK.
2422020-11-12T15:28:15 <jonasschnelli> (on your SPV question).
2432020-11-12T15:28:21 <pinheadmz> #bitcoin is basically /r/bitcoin
2442020-11-12T15:28:23 <jonasschnelli> Also look at BIP180 (https://github.com/bitcoin/bips/blob/master/bip-0180.mediawiki)
2452020-11-12T15:28:31 <pinheadmz> shesek ive gotten a lot of great help from #bitcoin-core-pr-reviews
2462020-11-12T15:29:19 *** SLNP <SLNP!~SLNP@89.249.74.218> has quit IRC (Ping timeout: 260 seconds)
2472020-11-12T15:29:38 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
2482020-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
2492020-11-12T15:29:47 <shesek> pinheadmz, is off topic considered okay there when there isn't a meeting going on?
2502020-11-12T15:29:48 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
2512020-11-12T15:29:59 <pinheadmz> yup, get in there
2522020-11-12T15:30:27 <shesek> jonasschnelli, iirc luke-jr ended up finding some issue with his proposed weight fraud proof mechanism, no?
2532020-11-12T15:30:49 <jonasschnelli> probably,.. I haven't followed and can't recall
2542020-11-12T15:39:21 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
2552020-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
2562020-11-12T15:39:22 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
2572020-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?
2582020-11-12T15:58:21 <jonasschnelli> warren: BIP324
2592020-11-12T15:58:26 <jonasschnelli> We are currently altering the AEAD though (make it simpler)
2602020-11-12T15:58:55 <warren> URL to draft?
2612020-11-12T15:58:57 <jonasschnelli> https://github.com/bitcoin/bips/pull/1024
2622020-11-12T15:59:08 <jonasschnelli> discussions also here: https://gist.github.com/jonasschnelli/c530ea8421b8d0e80c51486325587c52#ChaCha20Poly1305Bitcoin_Cipher_Suite
2632020-11-12T15:59:35 <jonasschnelli> we're getting there... I hope it will not take another 4 years. :)
2642020-11-12T16:05:01 <warren> thanks just had to point at it as an example
2652020-11-12T16:06:45 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
2662020-11-12T16:06:46 <bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/9bd131669729...0bd4929cd00e
2672020-11-12T16:06:46 <bitcoin-git> bitcoin/master 38ada89 Vasil Dimov: addrman: ensure old versions don't parse peers.dat
2682020-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
2692020-11-12T16:06:49 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
2702020-11-12T16:07:05 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
2712020-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
2722020-11-12T16:07:06 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
2732020-11-12T16:07:15 <vasild> \o/
2742020-11-12T16:57:12 *** Guyver2_ <Guyver2_!Guyver@guyver2.xs4all.nl> has joined #bitcoin-core-dev
2752020-11-12T16:58:25 *** Guyver2 <Guyver2!Guyver@guyver2.xs4all.nl> has quit IRC (Ping timeout: 264 seconds)
2762020-11-12T16:59:41 *** mrd <mrd!~mrd@185.163.110.116> has joined #bitcoin-core-dev
2772020-11-12T17:14:11 *** Guyver2_ is now known as Guyver2
2782020-11-12T17:16:13 *** nanotube <nanotube!~nanotube@unaffiliated/nanotube> has quit IRC (Ping timeout: 256 seconds)
2792020-11-12T17:21:16 *** Talkless <Talkless!~Talkless@mail.dargis.net> has joined #bitcoin-core-dev
2802020-11-12T17:37:26 *** brianhoffman <brianhoffman!~brianhoff@pool-71-191-34-154.washdc.fios.verizon.net> has quit IRC (Quit: brianhoffman)
2812020-11-12T17:41:04 *** Emcy <Emcy!~Emcy@unaffiliated/emcy> has quit IRC (Ping timeout: 256 seconds)
2822020-11-12T17:47:10 *** DeanWeen <DeanWeen!~dean@gateway/tor-sasl/deanguss> has quit IRC (Remote host closed the connection)
2832020-11-12T17:47:35 *** DeanWeen <DeanWeen!~dean@gateway/tor-sasl/deanguss> has joined #bitcoin-core-dev
2842020-11-12T17:50:49 *** Emcy <Emcy!~Emcy@unaffiliated/emcy> has joined #bitcoin-core-dev
2852020-11-12T17:54:47 *** nanotube <nanotube!~nanotube@unaffiliated/nanotube> has joined #bitcoin-core-dev
2862020-11-12T18:00:01 *** mrd <mrd!~mrd@185.163.110.116> has quit IRC ()
2872020-11-12T18:02:43 *** yanmaani <yanmaani!~yanmaani@gateway/tor-sasl/yanmaani> has quit IRC (Ping timeout: 240 seconds)
2882020-11-12T18:19:08 *** dviola <dviola!~diego@unaffiliated/dviola> has joined #bitcoin-core-dev
2892020-11-12T18:21:07 *** kierank1 <kierank1!~kierank@184.75.221.35> has joined #bitcoin-core-dev
2902020-11-12T18:32:16 <jnewbery> #proposedmeetingtopic limiting C++17 feature usage (see https://github.com/bitcoin/bitcoin/issues/16684#issuecomment-726214696)
2912020-11-12T18:37:25 *** promag <promag!~promag@188.250.84.129> has quit IRC (Remote host closed the connection)
2922020-11-12T18:40:40 *** ja <ja!janus@anubis.0x90.dk> has joined #bitcoin-core-dev
2932020-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
2942020-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
2952020-11-12T18:46:46 <provoostenator> Looks like Btcd is allergic to sendaddrv2: https://github.com/btcsuite/btcd/issues/1661 (cc roasbeef)
2962020-11-12T18:48:49 <provoostenator> (I should try an earlier version just to make sure it's not something else...)
2972020-11-12T18:49:29 *** lightlike <lightlike!~lightlike@p200300c7ef1a1b00c04f02a7739a7f7b.dip0.t-ipconnect.de> has joined #bitcoin-core-dev
2982020-11-12T18:51:27 *** mrostecki <mrostecki!~mrostecki@gateway/tor-sasl/mrostecki> has quit IRC (Remote host closed the connection)
2992020-11-12T18:51:36 *** luke <luke!~luke@bitnomial/staff/luke> has joined #bitcoin-core-dev
3002020-11-12T18:51:50 *** luke <luke!~luke@bitnomial/staff/luke> has quit IRC (Client Quit)
3012020-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
3022020-11-12T18:54:07 <provoostenator> It connects fine as of a slightly older commit 1d3ec2a1fda7446323786a52da1fd109c01aa6fb
3032020-11-12T18:54:48 <provoostenator> ja: it's not unfortunately; you'll have to spin up your own btcd and core machine somewhere.
3042020-11-12T19:00:30 <ja> i see so many booleans, and i am suspicious. for example https://github.com/bitcoin/bitcoin/commit/1d3ec2a1fda7446323786a52da1fd109c01aa6fb
3052020-11-12T19:00:47 <ja> i understand that it would be too much having a custom type for every single case
3062020-11-12T19:01:02 <hebasto> meeting?
3072020-11-12T19:01:04 <achow101> meeting?
3082020-11-12T19:01:12 <wumpus> #startmeeting
3092020-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.
3102020-11-12T19:01:13 <core-meetingbot> Available commands: action commands idea info link nick
3112020-11-12T19:01:17 <jnewbery> hi
3122020-11-12T19:01:19 <amiti> hi
3132020-11-12T19:01:19 <jonatack> hi
3142020-11-12T19:01:19 <jonasschnelli> hi
3152020-11-12T19:01:20 <emzy> hi
3162020-11-12T19:01:20 <luke-jr> hi
3172020-11-12T19:01:22 <hebasto> hi
3182020-11-12T19:01:24 <achow101> hi
3192020-11-12T19:01:25 <provoostenator> ja: that;s just an arbitary commit, nothing to do with the issue
3202020-11-12T19:01:26 <provoostenator> hi
3212020-11-12T19:01:33 <meshcollider> hi
3222020-11-12T19:01:36 <ja> provoostenator: i would explain if there wasn't a meeting now ;)
3232020-11-12T19:01:44 <fanquake> hi
3242020-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
3252020-11-12T19:01:50 <wumpus> petertodd phantomcircuit promag provoostenator ryanofsky sdaftuar sipa vasild wumpus
3262020-11-12T19:02:25 <fjahr> hi
3272020-11-12T19:02:39 <wumpus> one proposed meeting topic: limiting C++17 feature usage (jnewbery)
3282020-11-12T19:03:11 <wumpus> I guess the most pressing topic right now is the 0.21.0rc1 release
3292020-11-12T19:03:28 *** LarryRuane <LarryRuane!62f5cc94@c-98-245-204-148.hsd1.co.comcast.net> has joined #bitcoin-core-dev
3302020-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
3312020-11-12T19:03:57 <provoostenator> I'd like to get this in the release if possible: https://github.com/bitcoin-core/gui/pull/96
3322020-11-12T19:04:00 <wumpus> jonasschnelli's last minute fix seems trivial
3332020-11-12T19:04:10 <jonasschnelli> yes. can be merged I guess
3342020-11-12T19:04:11 <provoostenator> I reverted the string changes, so it's pretty simple now.
3352020-11-12T19:04:45 <hebasto> will review it tonight
3362020-11-12T19:04:58 <wumpus> provoostenator: ok!
3372020-11-12T19:05:05 <provoostenator> thx
3382020-11-12T19:05:05 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
3392020-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
3402020-11-12T19:05:06 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
3412020-11-12T19:05:09 <jonasschnelli> I'll look into it,... but was under the impression that we had code freeze already
3422020-11-12T19:05:10 <wumpus> yes, it's definitely too late for string changes
3432020-11-12T19:05:21 <sipa> hi
3442020-11-12T19:05:36 <provoostenator> The biggest thing that PR does is not recommend encryptino by default
3452020-11-12T19:05:51 <provoostenator> Which just seems a recipe for tears for brand new users.
3462020-11-12T19:06:17 <wumpus> I agree with that, encryption is torture for new users
3472020-11-12T19:06:22 <sipa> which PR are you talking about?
3482020-11-12T19:06:35 <hebasto> https://github.com/bitcoin-core/gui/pull/96
3492020-11-12T19:07:04 * hebasto sipa: ^
3502020-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
3512020-11-12T19:10:06 <wumpus> #20305 and #18836 are the big ones
3522020-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
3532020-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
3542020-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
3552020-11-12T19:10:57 <luke-jr> if anyone objects, they should speak up
3562020-11-12T19:11:13 <luke-jr> (see details on PR comments)
3572020-11-12T19:11:13 <wumpus> versus 0.20? or just versus previous intermediate master releases?
3582020-11-12T19:11:16 *** DeanWeen <DeanWeen!~dean@gateway/tor-sasl/deanguss> has quit IRC (Remote host closed the connection)
3592020-11-12T19:11:16 <wumpus> okay
3602020-11-12T19:11:19 <luke-jr> wumpus: 0.20
3612020-11-12T19:11:21 <jonatack> (for bumpfee)
3622020-11-12T19:11:32 <luke-jr> it's complex to explain, but IMO a reasonable concession
3632020-11-12T19:11:38 *** DeanWeen <DeanWeen!~dean@gateway/tor-sasl/deanguss> has joined #bitcoin-core-dev
3642020-11-12T19:11:42 <MarcoFalke> That certainly needs release notes, no?
3652020-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"
3662020-11-12T19:12:06 <jonatack> https://github.com/bitcoin/bitcoin/pull/20305#discussion_r520231413
3672020-11-12T19:12:24 <luke-jr> MarcoFalke: agreed
3682020-11-12T19:12:39 <jonatack> MarcoFalke: yes, definitely, we can edit the wiki.
3692020-11-12T19:13:06 *** kierank1 <kierank1!~kierank@184.75.221.35> has quit IRC (Ping timeout: 265 seconds)
3702020-11-12T19:13:31 <luke-jr> most likely trying to use the old interface will just error; worst case, it's fixable
3712020-11-12T19:14:03 <wumpus> ok
3722020-11-12T19:14:15 <jonatack> yes, for the bumpfee change, there's a 1e5 times difference in units in the downward direction
3732020-11-12T19:14:52 <wumpus> yeah downward is the only acceptable direction
3742020-11-12T19:15:00 <jonatack> also added a * WARNING * in the help
3752020-11-12T19:15:13 *** LarryRuane <LarryRuane!62f5cc94@c-98-245-204-148.hsd1.co.comcast.net> has quit IRC (Remote host closed the connection)
3762020-11-12T19:15:18 <luke-jr> oh. just thought of a possible danger
3772020-11-12T19:15:29 <luke-jr> if someone uses the new interface, with an old version
3782020-11-12T19:16:06 <provoostenator> luke-jr: that's dangerous in general, given some of the other fixes...
3792020-11-12T19:16:14 <luke-jr> provoostenator: ?
3802020-11-12T19:16:39 <luke-jr> I wonder if the magnitude would trigger the absurd fee warning
3812020-11-12T19:16:46 <provoostenator> #16257
3822020-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
3832020-11-12T19:17:01 <sipa> the default absurd fee threshold is 0.1 BTC or so, no?
3842020-11-12T19:17:22 <jonatack> yes iirc
3852020-11-12T19:17:35 <jonatack> per the tests i've added in any case
3862020-11-12T19:17:41 <queip> so it's decided to go with vB? WU was popular last year
3872020-11-12T19:17:55 *** promag <promag!~promag@188.250.84.129> has joined #bitcoin-core-dev
3882020-11-12T19:17:56 <provoostenator> People are still making payments with 0.1 BTC fees FWIW, quite often
3892020-11-12T19:18:08 <sipa> everyone uses sat/vB, afaik
3902020-11-12T19:18:24 <wumpus> `if there's any risk of it causing people to overpay fees it's unacceptable risk
3912020-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
3922020-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
3932020-11-12T19:19:18 <jonatack> *WU wasn't an option in the poll tho
3942020-11-12T19:19:21 <luke-jr> sipa: well, nothing is using sat/vB yet.. so it's a factor of 1e5/4
3952020-11-12T19:19:46 <sipa> luke-jr: almost every fee estimation website, most block explorers, ... do
3962020-11-12T19:19:54 <wumpus> so is that the case for #20305?
3972020-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
3982020-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
3992020-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
4002020-11-12T19:21:02 <luke-jr> minimum realistic bumpfee is probably 2sat/vB?
4012020-11-12T19:21:17 <meshcollider> I don't think there's ever any risk of overpayment here
4022020-11-12T19:21:19 <luke-jr> which at BTC/kB is 2 BTC/kB, over the absurd fee cutoff
4032020-11-12T19:21:26 <jonatack> luke-jr: min incremental fee is 1 sat/vB
4042020-11-12T19:21:26 <sipa> luke-jr: good point
4052020-11-12T19:21:35 <wumpus> underpayment is at least better, could always bump again
4062020-11-12T19:21:52 <luke-jr> so I *think* the magnitude is sufficient to avoid any loss in either direction
4072020-11-12T19:22:14 <luke-jr> which only leaves the WU question - but I don't think we have time to do another poll
4082020-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
4092020-11-12T19:22:43 <jonatack> AFAIK sats seem to be far and away what people want
4102020-11-12T19:22:59 <queip> ok just was asking
4112020-11-12T19:22:59 <michaelfolkson> +1
4122020-11-12T19:23:01 <luke-jr> jonatack: well, I assume it'd be sats/WU in that case
4132020-11-12T19:23:05 <jonatack> found the poll: https://twitter.com/jonatack/status/1318890833131823104?s=20
4142020-11-12T19:23:06 <emzy> +1
4152020-11-12T19:23:08 *** promag <promag!~promag@188.250.84.129> has quit IRC (Ping timeout: 256 seconds)
4162020-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?
4172020-11-12T19:24:24 <luke-jr> sipa: no
4182020-11-12T19:24:28 <meshcollider> I don't think it's worth bikeshedding over but I prefer sats/vB honestly
4192020-11-12T19:24:37 <wumpus> no, I think it's better to settle on one unit and one unit only for RPC
4202020-11-12T19:24:44 <luke-jr> sipa: this removes all unit choice, and just uses sat/vB
4212020-11-12T19:24:47 <meshcollider> sipa: we're trying to make it simpler :)
4222020-11-12T19:25:07 <sipa> luke-jr: how does that not break compatibility (as earlier releases all use BTC/kvB)?
4232020-11-12T19:25:08 <wumpus> adding a choice of units shouldn't be necesasry, it's a programmatic interface
4242020-11-12T19:25:18 <jonatack> right, so people don't have to pass in a choice of units with the estimate_mode param
4252020-11-12T19:25:24 <wumpus> just standardize something â¦
4262020-11-12T19:25:26 <luke-jr> sipa: the field name is different for everything except bumpfee
4272020-11-12T19:25:27 <sipa> feel free to tell me to just go read the PR
4282020-11-12T19:25:36 <luke-jr> sipa: and bumpfee is protected by the magnitude
4292020-11-12T19:25:56 <luke-jr> sipa: the old interface to bumpfee+fee_rate won't *work*, but it won't do damage either
4302020-11-12T19:26:26 <sipa> ok
4312020-11-12T19:26:36 <luke-jr> (other RPCs used "feeRate" instead of "fee_rate")
4322020-11-12T19:27:07 <luke-jr> IIRC only in options objects, so no positional mess (someone should double-check this)
4332020-11-12T19:27:26 <jonatack> yes. (in fundrawtxn and walletcreatefundedpsbt only)
4342020-11-12T19:27:40 *** evanpro <evanpro!~evanpro@195.206.169.184> has joined #bitcoin-core-dev
4352020-11-12T19:28:20 <jonatack> feeRate is only an arg, not an option, which we can deprecate as soon as people judge feasible
4362020-11-12T19:28:31 <jonatack> it's in BTC/kB
4372020-11-12T19:30:59 <wumpus> next topic?
4382020-11-12T19:31:07 <jonatack> (fwiw that PR adds a fair number of RPCExamples in send and sendtoaddress to help people use it)
4392020-11-12T19:31:41 <michaelfolkson> wumpus: yup
4402020-11-12T19:32:20 <wumpus> #topic limiting C++17 feature usage (jnewbery)
4412020-11-12T19:32:20 <core-meetingbot> topic: limiting C++17 feature usage (jnewbery)
4422020-11-12T19:32:38 <jnewbery> hi
4432020-11-12T19:32:39 <wumpus> link: https://github.com/bitcoin/bitcoin/issues/16684#issuecomment-726214696
4442020-11-12T19:32:48 <jnewbery> As a reminder, our plan for C++17 is here: https://github.com/bitcoin/bitcoin/issues/16684
4452020-11-12T19:32:56 <jnewbery> Once we branch v0.21 (imminently), we'll be able to start using c++14 and c++17 features.
4462020-11-12T19:33:02 <jnewbery> I expect lots of people have their favorite features that they want to start using.
4472020-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.
4482020-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.
4492020-11-12T19:33:17 <wumpus> so there's a specific feature that triggers a libc bug?
4502020-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?
4512020-11-12T19:34:06 <MarcoFalke> std::fs
4522020-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
4532020-11-12T19:34:18 <hebasto> or define minimum libc with fixed bug?
4542020-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
4552020-11-12T19:34:40 <MarcoFalke> We can't use std::fs because LTS versions of operating systems don't ship it
4562020-11-12T19:34:54 <sipa> well what's the alternative? does boost::shared_mutex not have the same problem?
4572020-11-12T19:34:58 <wumpus> every specific exclusion makes it more difficult for new contributors etc
4582020-11-12T19:35:11 <MarcoFalke> sipa: We already use boost::shared_mutex
4592020-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"
4602020-11-12T19:35:47 <wumpus> people don't generally consult a list of allowed features before contributing
4612020-11-12T19:35:48 <MarcoFalke> ah good point
4622020-11-12T19:35:50 <luke-jr> hmm
4632020-11-12T19:36:14 <wumpus> though things like "use boost::shared_mutex instead of std::shared_mutex" are clear and easy to enforce enough
4642020-11-12T19:36:21 <wumpus> or the fs one
4652020-11-12T19:36:29 <wumpus> we have our own fs abstraction anyway
4662020-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
4672020-11-12T19:36:38 <wumpus> sipa: yes
4682020-11-12T19:36:41 <wumpus> those two are easy
4692020-11-12T19:36:51 <MarcoFalke> sipa: The ci would fail if someone tried using std::fs
4702020-11-12T19:37:00 <sipa> oh, right
4712020-11-12T19:37:01 <MarcoFalke> (and gitian)
4722020-11-12T19:37:08 <sipa> my impression is that all these issues are STL features, not languages features
4732020-11-12T19:37:33 <sipa> and i expect that if you use a sufficient compiler version, all languages features will actually work
4742020-11-12T19:37:40 <jonatack> luke-jr: you are right, feeRate is an option
4752020-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" ?
4762020-11-12T19:38:42 <sipa> that's probably too restrictive
4772020-11-12T19:38:57 <wumpus> no,I think it's better to reject specific things if we have a good reason
4782020-11-12T19:39:01 <sipa> agree
4792020-11-12T19:39:03 <wumpus> and just accept standard C++17 otherwise
4802020-11-12T19:39:14 <sipa> i guess the concern is really about things that compile, but are known to not always work
4812020-11-12T19:39:17 <sipa> like this shared_mutex thing
4822020-11-12T19:39:23 <wumpus> right
4832020-11-12T19:39:27 <ja> jnewbery: should std::shared_mutex be avoided even if it is unknown whether boost::shared_mutex is also broken?
4842020-11-12T19:39:32 <sipa> and we should just outlaw while necessary... just as with any other compiler/stl bug
4852020-11-12T19:39:52 <jnewbery> I don't know enough about compilers to know how stable their C++17 stl features are
4862020-11-12T19:40:11 <wumpus> you would hope it is stable after more then three years
4872020-11-12T19:40:22 <jnewbery> you would, and yet here we are
4882020-11-12T19:40:26 <wumpus> of course, compiler and c++ librar ybugs happen sometimes
4892020-11-12T19:40:32 <wumpus> well yes it's a specific thing
4902020-11-12T19:40:45 <wumpus> even memcmp had a bug !!!
4912020-11-12T19:40:49 <jnewbery> we don't know how many other specific things there are
4922020-11-12T19:40:52 <wumpus> should we reject c89 featurs now
4932020-11-12T19:40:58 <sipa> haha
4942020-11-12T19:41:03 <MarcoFalke> Is there a minimal test case for the shared_mutex thing?
4952020-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
4962020-11-12T19:41:45 <ja> but glibc has test cases for the pthread primitives
4972020-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
4982020-11-12T19:42:23 <wumpus> this is one of the biggest risks in consensus driven systems isn't it
4992020-11-12T19:42:25 <jnewbery> wumpus: that's doesn't seem like it'd be true. New features are more likely to have bugs
5002020-11-12T19:42:26 <sipa> boost 1.71 does not seem to use STL's shared_mutex
5012020-11-12T19:42:42 <wumpus> jnewbery: I'm not convinced about that, code rot is a thing
5022020-11-12T19:42:44 <jnewbery> *or uncover existing bugs
5032020-11-12T19:42:59 <wumpus> new features might actually have *more* eyes on them
5042020-11-12T19:43:22 <luke-jr> sipa: unrelease boost might
5052020-11-12T19:43:29 <wumpus> this is an abyss without end anyway... we can only calculate in known bugs not potential ones
5062020-11-12T19:44:05 <luke-jr> if every distro has a fix, maybe just a sanity check is in order
5072020-11-12T19:44:12 <MarcoFalke> A future release of boost might decay boost::shared_mutex into std::shared_mutex
5082020-11-12T19:44:12 <jnewbery> My general point is that we shouldn't rush to use new features unless there's very clear benefit
5092020-11-12T19:44:24 <wumpus> MarcoFalke: yep
5102020-11-12T19:44:27 <luke-jr> otoh, isn't it just a deadlock worst case?
5112020-11-12T19:44:49 <jnewbery> and that if we do that, then we should codify what features can be used at the project level
5122020-11-12T19:44:53 <luke-jr> I think deadlock is fairly harmless for user-built binaries that simply require an updated OS to fix
5132020-11-12T19:45:09 <wumpus> no, I don't think we should make a long list of allowed c++17 features
5142020-11-12T19:45:10 <ja> luke-jr: if you use bitcoin to back a lightning node, a deadlock could be pretty bad, no?
5152020-11-12T19:45:16 <wumpus> only exclude ones that we know to cause problems
5162020-11-12T19:45:24 *** lightlike <lightlike!~lightlike@p200300c7ef1a1b00c04f02a7739a7f7b.dip0.t-ipconnect.de> has quit IRC (Quit: Leaving)
5172020-11-12T19:45:32 <luke-jr> ja: hmm, maybe - but aren't there supposed to be watchers?
5182020-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
5192020-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
5202020-11-12T19:46:43 <luke-jr> point is, that would be a scenario with two user errors
5212020-11-12T19:47:09 <michaelfolkson> Watchtowers only needed if you aren't online 100 percent of time (or for additional protection)
5222020-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
5232020-11-12T19:47:31 <ja> michaelfolkson: if you bitcoin node is deadlocked on a shared_mutex, are you online?
5242020-11-12T19:48:02 <michaelfolkson> I'd guess not ja :)
5252020-11-12T19:48:05 <wumpus> that should also be standard policy for the project already, no needless refactors
5262020-11-12T19:48:57 <michaelfolkson> But how long would you be deadlocked for?
5272020-11-12T19:49:08 <ja> 2 weeks, until you come back from vacation
5282020-11-12T19:49:09 <jnewbery> I think only introducing new features as they're needed is the more cautious approach
5292020-11-12T19:49:12 <luke-jr> michaelfolkson: indefinitely
5302020-11-12T19:49:18 <sipa> michaelfolkson: the definition of a deadlock implies it's forever
5312020-11-12T19:49:31 <michaelfolkson> Ok. That is a problem
5322020-11-12T19:49:38 <MarcoFalke> jnewbery: I don't think C++17 is "needed". We could stay with C++11 forever
5332020-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)
5342020-11-12T19:49:44 <luke-jr> but the same goes for any DoS vuln
5352020-11-12T19:49:48 <luke-jr> which seem fairly common
5362020-11-12T19:49:49 <wumpus> yes, we could stay in c++11 forever
5372020-11-12T19:50:24 <wumpus> but we've already decided not to
5382020-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
5392020-11-12T19:50:49 <wumpus> I don't think it would make the project any safer
5402020-11-12T19:51:12 <hebasto> we coudn't stay on C++11 due to new Qt versions
5412020-11-12T19:51:31 <luke-jr> hebasto: Qt dropped C++11 support? :o
5422020-11-12T19:51:32 <wumpus> just make an exception for the gui code...
5432020-11-12T19:51:40 <sipa> waot
5442020-11-12T19:51:49 <MarcoFalke> Use C++11 code, but compile it with -std=c++17
5452020-11-12T19:51:49 <sipa> this shared_lock thing sounds like a problem in pthread?
5462020-11-12T19:51:58 <sipa> which means it would also affect boost?
5472020-11-12T19:52:13 <wumpus> boost definitely uses pthread (but maybe in a different way?)
5482020-11-12T19:52:30 <hebasto> luke-jr: #19716
5492020-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
5502020-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
5512020-11-12T19:52:50 <wumpus> if it's a general pthread issue then we're already affected and c++17 is unimportant to this
5522020-11-12T19:52:56 <sipa> indeed
5532020-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.
5542020-11-12T19:53:03 <sipa> boost has its own shared_lock implementation
5552020-11-12T19:53:10 <luke-jr> hebasto: that looks like the opposite
5562020-11-12T19:53:12 <sipa> and doesn't use pthread's rwlock interface
5572020-11-12T19:53:18 <wumpus> great
5582020-11-12T19:53:25 <sipa> (in 1.71)
5592020-11-12T19:53:37 <wumpus> michaelfolkson: I don't think we can front-run any compiler or c++ library issues
5602020-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
5612020-11-12T19:54:31 <luke-jr> I wonder if we ought to add a CI using roconnor's memcmp bug detection
5622020-11-12T19:54:36 <wumpus> but that's just my opinion
5632020-11-12T19:55:03 <luke-jr> seeing as GCC/distros appear to have a disinterest in actually fixing it
5642020-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.
5652020-11-12T19:55:57 <luke-jr> fanquake: I don't see that mentioning in the linked issue?
5662020-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
5672020-11-12T19:56:45 <wumpus> as if we can judge how much risk the compiler or library change is anyway
5682020-11-12T19:56:49 <luke-jr> fanquake: you can't build Qt with C++14 and then link from C++11 code?
5692020-11-12T19:57:01 *** promag <promag!~promag@188.250.84.129> has joined #bitcoin-core-dev
5702020-11-12T19:57:39 <wumpus> could you ever have predicted this?
5712020-11-12T19:57:46 *** ajonas_ <ajonas_!uid385278@gateway/web/irccloud.com/x-vbrpaonosufznwgi> has joined #bitcoin-core-dev
5722020-11-12T19:57:53 <wumpus> did std::shared_mutex sound dangerous to you than boost::shared_mutex?
5732020-11-12T19:58:15 <wumpus> still, here we are
5742020-11-12T19:58:20 <jnewbery> changing to something new is always dangerous
5752020-11-12T19:58:31 <fanquake> luke-jr: I mentioned the details and linked to upstream in #19305
5762020-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
5772020-11-12T19:58:39 <wumpus> okay, so not change to anything new anymore then?
5782020-11-12T19:58:42 <sipa> jnewbery: boost has also had its fair share of bugs though
5792020-11-12T19:58:54 <wumpus> would this *specifically* have been risky to you?
5802020-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
5812020-11-12T19:59:07 <wumpus> if not, it would be a blanket reject c++17 features
5822020-11-12T19:59:15 <wumpus> yes
5832020-11-12T19:59:23 *** per <per!~per@gateway/tor-sasl/wsm> has quit IRC (Ping timeout: 240 seconds)
5842020-11-12T19:59:35 <wumpus> and yes, boost versions have also broken things sometimes
5852020-11-12T19:59:58 <wumpus> not upgrading boost is dangerous too, though
5862020-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
5872020-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
5882020-11-12T20:01:27 <wumpus> I don't think any general principple can be derived from this
5892020-11-12T20:01:32 *** per <per!~per@gateway/tor-sasl/wsm> has joined #bitcoin-core-dev
5902020-11-12T20:01:46 <wumpus> yes, being cautious is always good
5912020-11-12T20:01:49 <wumpus> I hope we already are cautious?
5922020-11-12T20:01:50 *** promag <promag!~promag@188.250.84.129> has quit IRC (Ping timeout: 264 seconds)
5932020-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
5942020-11-12T20:02:04 <wumpus> do you have any specific suggestion?
5952020-11-12T20:02:43 <sipa> and we do have a review and QA cycle, which are part of the process
5962020-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
5972020-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
5982020-11-12T20:03:10 <queip> that is, c++!7 forces such bump of minimal macosx version
5992020-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
6002020-11-12T20:03:22 <wumpus> queip: yes, I think that wa calculated in
6012020-11-12T20:03:29 <wumpus> I don't think that's a good idea
6022020-11-12T20:03:58 <wumpus> it's super confusing to new contributors for example
6032020-11-12T20:04:03 <michaelfolkson> Because of new contributors and because of not knowing what should go on that list wumpus?
6042020-11-12T20:04:07 <sipa> i think i agree with wumpus now
6052020-11-12T20:04:08 <wumpus> yes
6062020-11-12T20:04:21 <luke-jr> queip: we typically only guarantee support for the most recent stable version of an OS
6072020-11-12T20:04:28 <luke-jr> though Windows is apparently an exception
6082020-11-12T20:04:35 <sipa> what constitutes a "feature" even? is a new member function that was added to std::vector a "feature" ?
6092020-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
6102020-11-12T20:04:43 <wumpus> yes
6112020-11-12T20:04:50 <wumpus> do we hae to whitelist every function? every class?
6122020-11-12T20:05:05 <MarcoFalke> Generally, our insurance against build system bugs are tests
6132020-11-12T20:05:16 <wumpus> do you even want to maintain this list?
6142020-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?
6152020-11-12T20:06:33 <wumpus> only if we had a test reproducing the issue predictably I think
6162020-11-12T20:06:56 <MarcoFalke> we should add one
6172020-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
6182020-11-12T20:06:59 <sipa> yeah, it'd probably depend on how actively shared_mutex was used (and with how much contention...)
6192020-11-12T20:07:06 <wumpus> if it causes a random hang in travis, well, peple would think it's just another infrastructure issue
6202020-11-12T20:07:28 <wumpus> jnewbery: okay
6212020-11-12T20:07:31 <sipa> jnewbery: that conceptually makes sense, but what specifically is your suggestion?
6222020-11-12T20:07:42 <wumpus> jnewbery: feel free to make a list
6232020-11-12T20:07:45 <wumpus> jnewbery: and PR it
6242020-11-12T20:07:56 <wumpus> jnewbery: I'm not conceptually against it I just do not want to maintain it
6252020-11-12T20:07:59 <MarcoFalke> time, btw
6262020-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
6272020-11-12T20:08:00 <luke-jr> "Travis failed, can someone restart it for me?"
6282020-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
6292020-11-12T20:08:24 <wumpus> queip: again, feel free to maintian such a thing
6302020-11-12T20:08:38 <jnewbery> queip: that seems easier to me than arguing on each PR what is and isn't acceptable
6312020-11-12T20:08:59 <wumpus> I'm done with this (both the meeting and the discussion)
6322020-11-12T20:09:00 <wumpus> #endmeeting
6332020-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
6342020-11-12T20:09:01 <core-meetingbot> Meeting ended Thu Nov 12 20:09:00 2020 UTC.
6352020-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
6362020-11-12T20:09:17 <sipa> ok, practically, how would it be decided what is acceptable?
6372020-11-12T20:09:21 <wumpus> I think this project becomes impossible to maintian in the close feature
6382020-11-12T20:09:21 <MarcoFalke> How could we maintain the list of allowed features?
6392020-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
6402020-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
6412020-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
6422020-11-12T20:10:29 <wumpus> it's too risky anyway
6432020-11-12T20:10:33 <wumpus> this whole thing
6442020-11-12T20:10:43 <jonatack> (once upon a time, one might have said agile :))))
6452020-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?
6462020-11-12T20:11:14 <ja> provoostenator: that type could be used for example in the linked commit, and it would alliviate some boolean blindness
6472020-11-12T20:11:21 <wumpus> I'm not convinced even CPU features are reliable enough
6482020-11-12T20:11:28 <sipa> ja: i see you're a haskell programmer
6492020-11-12T20:11:30 <wumpus> if you really want to know
6502020-11-12T20:11:40 <ja> provoostenator: it is deliberately ambiguous towards exactly what should be checked. but better than a boolean, no?
6512020-11-12T20:12:57 <ja> sipa: i am not advocating lazy evaluation here, mind you ;) i don't think it is an obscure proposal
6522020-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
6532020-11-12T20:13:03 <wumpus> I think it's important to isolate the consensus code soon, and be extremely careful about that
6542020-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
6552020-11-12T20:13:19 <wumpus> I'm not sure we can be careful enough
6562020-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
6572020-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"
6582020-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
6592020-11-12T20:14:12 <wumpus> C++ is a way too complex language
6602020-11-12T20:14:35 <sipa> wumpus: as are the operating systems and hardware they run on...
6612020-11-12T20:14:40 <wumpus> sipa: yes
6622020-11-12T20:14:49 <sipa> i don't think that's a cause for despair... we have review and tests
6632020-11-12T20:14:57 <sipa> the real world is always messy
6642020-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"
6652020-11-12T20:15:22 <sipa> i don't think it's just that
6662020-11-12T20:15:26 <wumpus> well...
6672020-11-12T20:15:34 <sipa> i don't know how it would be maintained - by anyone
6682020-11-12T20:15:38 <MarcoFalke> I don't think an allow-list would conceptually work with c++ features
6692020-11-12T20:15:41 <wumpus> it's a bad idea because it takes resources from other things I gues
6702020-11-12T20:15:55 <wumpus> it's a huge project
6712020-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...
6722020-11-12T20:16:05 <wumpus> an probably not a big thing in risk-reduction in general
6732020-11-12T20:16:14 <sipa> jonatack: and every coredev since 2015 or so ;)
6742020-11-12T20:16:19 <jonatack> heh
6752020-11-12T20:16:22 <wumpus> jonatack: yess
6762020-11-12T20:16:31 <jnewbery> wumpus: adding wizzy new c++17 features makes it even huger (conceptually)
6772020-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
6782020-11-12T20:17:03 <wumpus> jnewbery: are there any you *specifcially* take offense to?
6792020-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?
6802020-11-12T20:17:34 <wumpus> sipa: yes, that
6812020-11-12T20:17:47 <Kiminuo> https://github.com/bitcoin/bitcoin/pull/19245 - Do I understand correctly that this is dead for foreseeable future?
6822020-11-12T20:17:47 <ja> wumpus: did you see the discussion on string_view?
6832020-11-12T20:17:51 <jnewbery> I'm not sure we should use string_views
6842020-11-12T20:17:54 <MarcoFalke> we already use the features. Either through boost, or through more verbose C++11 code
6852020-11-12T20:18:02 <wumpus> yes, I think isolating the conensus code would be most bang for buck with regard to risk minimalization
6862020-11-12T20:18:09 <jnewbery> ja: which discussion?
6872020-11-12T20:18:27 *** evanpro <evanpro!~evanpro@195.206.169.184> has quit IRC (Remote host closed the connection)
6882020-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
6892020-11-12T20:18:36 <ja> jnewbery: ah i just meant the comments in the issue #16684
6902020-11-12T20:18:38 <gribble> https://github.com/bitcoin/bitcoin/issues/16684 | Discussion: upgrading to C++17 · Issue #16684 · bitcoin/bitcoin · GitHub
6912020-11-12T20:18:49 <wumpus> bitcoin core is too big
6922020-11-12T20:19:21 <sipa> happy to see renewed activity on that front with dongcarl's recent PRs
6932020-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
6942020-11-12T20:19:27 <wumpus> yes
6952020-11-12T20:19:42 <jnewbery> ja: I hadn't seen that but my instinct is to agree with practicalswift - it introduces very sharp edges
6962020-11-12T20:19:58 <jonatack> jnewbery: in any case for my own work and reviewing, I'll be following your cautious approach
6972020-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
6982020-11-12T20:20:31 <sipa> i think introducing a new features/concepts should always be a red flag for review
6992020-11-12T20:20:39 <jnewbery> I trust sipa to use spans correctly, but I wouldn't encourage their use by everyone
7002020-11-12T20:20:43 <wumpus> that's different for everyone though, and just as true for old crufty featurs
7012020-11-12T20:20:58 <wumpus> (e.g. does anyone know about c++ multiple inheritance specifics?)
7022020-11-12T20:21:07 <jnewbery> spans and string_views are objectively more dangeroush than other language features
7032020-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
7042020-11-12T20:21:24 <luke-jr> why are we switching to spans if they're so hard to use?
7052020-11-12T20:21:32 <wumpus> jnewbery: well if it's a replacement for void*, size_t
7062020-11-12T20:21:39 <wumpus> jnewbery: it isn't any less safe
7072020-11-12T20:21:44 <sipa> jnewbery: (playing the devil's advocate here) i think they're less dangerous than points and lengths passed manually
7082020-11-12T20:21:49 <sipa> *pointers
7092020-11-12T20:21:50 <wumpus> all the span refactores have been that
7102020-11-12T20:21:53 <wumpus> just that
7112020-11-12T20:22:09 <wumpus> sipa: right
7122020-11-12T20:22:31 <wumpus> it makes things conceptually clearer than a pair of pointers and lengths
7132020-11-12T20:22:42 <wumpus> that's all, it shouldn't replace owned objects
7142020-11-12T20:23:01 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
7152020-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
7162020-11-12T20:23:03 * jonatack taking notes on the consensus isolation mentions
7172020-11-12T20:23:05 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
7182020-11-12T20:23:14 <ja> by using a data-type, it also allows the compiler to understand more invariants about your code
7192020-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
7202020-11-12T20:23:28 <ja> a compiler could have specific protections when using Span, that wouldn't otherwise be used
7212020-11-12T20:23:30 <MarcoFalke> *ACKed
7222020-11-12T20:23:47 <wumpus> MarcoFalke: yes
7232020-11-12T20:24:05 <sipa> ja: about that, can some people please review #19387
7242020-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
7252020-11-12T20:24:13 <MarcoFalke> code review is our best effort protecting against bad code
7262020-11-12T20:24:30 <MarcoFalke> Developer notes certainly do help to clarify guidelines
7272020-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
7282020-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
7292020-11-12T20:25:23 <wumpus> that's a good point and at least a specific one
7302020-11-12T20:25:47 <wumpus> but we can't go over everything and make a risk estimate upfront
7312020-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?
7322020-11-12T20:26:15 <jnewbery> I'd be wary of anyone adding try_emplace since the interface is so confusing
7332020-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)
7342020-11-12T20:27:27 <sipa> michaelfolkson: i've been adding elaborate fuzzers in several of my recent bigger PRs
7352020-11-12T20:27:50 <michaelfolkson> Do you do all your fuzzing on your laptop MarcoFalke? It takes hours sometimes
7362020-11-12T20:27:54 <wumpus> michaelfolkson: is there good documentation on how to get started?
7372020-11-12T20:28:05 <MarcoFalke> michaelfolkson: wumpus doc/fuzzing.md
7382020-11-12T20:28:15 <wumpus> thanks
7392020-11-12T20:28:17 <sipa> i'd encourage everyone to do the same...
7402020-11-12T20:28:30 <wumpus> I don't have any big CPUs though
7412020-11-12T20:28:46 <sipa> i'm less convinced about writing generic fuzzers for code you're not already familiar with
7422020-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
7432020-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)
7442020-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)
7452020-11-12T20:30:04 <MarcoFalke> michaelfolkson: If there is an issue with the docs you can file a bug (or fix them)
7462020-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
7472020-11-12T20:30:31 <MarcoFalke> sipa: Agree. The best fuzzers are the ones that trigger the most already-fixed bugs
7482020-11-12T20:30:49 <michaelfolkson> Right MarcoFalke. I will try to do this. But lots I don't know currently
7492020-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
7502020-11-12T20:31:16 <sipa> (but this is for fuzzers written with very intimite knowledge of what they're testing)
7512020-11-12T20:31:20 *** cfields <cfields!~cfields@unaffiliated/cfields> has joined #bitcoin-core-dev
7522020-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
7532020-11-12T20:33:16 <jonatack> (i have an older 4-core cpu)
7542020-11-12T20:33:17 *** flukiluke1 <flukiluke1!~flukiluke@185.204.1.185> has joined #bitcoin-core-dev
7552020-11-12T20:33:41 <michaelfolkson> By a few minutes you mean run them and stop them hours before completion jonatack?
7562020-11-12T20:34:09 <jonatack> michaelfolkson: they run until you halt them or they hit an issue
7572020-11-12T20:34:23 <sipa> fuzzing never completes
7582020-11-12T20:34:27 <wumpus> fuzzers never 'complete' do they
7592020-11-12T20:34:32 <wumpus> sipa: heh
7602020-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
7612020-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
7622020-11-12T20:35:37 <jonatack> ^
7632020-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"
7642020-11-12T20:35:40 <sipa> (all before it was PR'ed, and in some cases, started over)
7652020-11-12T20:35:55 <sipa> michaelfolkson: it's making random variations in the seeds, and see if those trigger anything
7662020-11-12T20:36:17 <sipa> it's somewhat coverage directed, the fuzzer "learns" what things are potentially relevant and what it isn't
7672020-11-12T20:36:23 <wumpus> there's a large degree of randomness involved so no one will be testing exactly the same thing
7682020-11-12T20:36:23 <sipa> but it's really just trying random things
7692020-11-12T20:36:26 <michaelfolkson> Ah ok. So the randomness ensures different things get "fuzzed"
7702020-11-12T20:36:40 <sipa> fuzzing == "introducing random variations"
7712020-11-12T20:37:32 <sipa> we do need a bitcoin core specific fuzzing farm that can run fuzzers with months of CPU time though
7722020-11-12T20:37:32 <jonatack> there were two really good Review Club meetings on fuzzing
7732020-11-12T20:37:42 <jonatack> https://bitcoincore.reviews/17860
7742020-11-12T20:37:56 *** Talkless <Talkless!~Talkless@mail.dargis.net> has quit IRC (Quit: Konversation terminated!)
7752020-11-12T20:37:57 <michaelfolkson> Yup. Still have lots and lots of questions though ;)
7762020-11-12T20:38:01 <sipa> shouldn't be too hard to find hardware
7772020-11-12T20:38:08 <jonatack> https://bitcoincore.reviews/18521
7782020-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
7792020-11-12T20:40:00 <sipa> michaelfolkson: why would there be a difference?
7802020-11-12T20:40:01 <MarcoFalke> michaelfolkson: fuzzing should be done
7812020-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 ;)
7822020-11-12T20:40:20 <MarcoFalke> It is additive. Running two machines is better than running one machine
7832020-11-12T20:40:59 <michaelfolkson> Targeted fuzzing on individual machines. Mass comprehensive fuzzing on a fuzzing farm?
7842020-11-12T20:41:10 <michaelfolkson> Would that not be the end goal?
7852020-11-12T20:41:20 <sipa> what is "targetted fuzzing" ?
7862020-11-12T20:41:42 <sipa> i'll run fuzzers myself locally for code i'm developing if it includes a fuzzer
7872020-11-12T20:42:17 <michaelfolkson> " i'm less convinced about writing generic fuzzers for code you're not already familiar with"
7882020-11-12T20:42:31 <michaelfolkson> s/targeted/non-generic
7892020-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
7902020-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
7912020-11-12T20:43:28 <MarcoFalke> ja: Nothing wrong, but tests that don't find issues are not that useful
7922020-11-12T20:43:29 <sipa> that's not the case though - and all fuzzing right now is people individually running fuzzers
7932020-11-12T20:43:52 <sipa> ja: if you do learn, it's a great exercise
7942020-11-12T20:44:08 <michaelfolkson> It is a time issue. Only 24 hours in a day
7952020-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 ;)
7962020-11-12T20:44:33 <sipa> michaelfolkson: that was about *writing* fuzzers, not running them
7972020-11-12T20:44:34 <MarcoFalke> michaelfolkson: With 2 CPUs there are 48 CPU hours in one day
7982020-11-12T20:44:53 <michaelfolkson> Haha ok
7992020-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
8002020-11-12T20:45:04 <MarcoFalke> ja: Indeed. I am not discouraging anyone to write tests.
8012020-11-12T20:45:09 *** promag <promag!~promag@188.250.84.129> has joined #bitcoin-core-dev
8022020-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
8032020-11-12T20:46:06 <sipa> that doesn't mean they're useless, or that i want to discourage people from doing so
8042020-11-12T20:46:31 <sipa> but i think there is more value in first understanding the code deeper, and then writing more targetted tests
8052020-11-12T20:46:54 <michaelfolkson> The problem is not understanding the Core codebase and history of bugs rather than understanding fuzzing?
8062020-11-12T20:47:26 <michaelfolkson> This isn't a "general expertise" in fuzzing issue?
8072020-11-12T20:47:47 <MarcoFalke> I do think we have a shortage of expertise
8082020-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)
8092020-11-12T20:53:03 <MarcoFalke> sipa: for the fuzz engine it shouldn't make a difference
8102020-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
8112020-11-12T20:54:16 <sipa> but right now the build dir for fuzzing is gigabytes
8122020-11-12T20:54:38 <MarcoFalke> the seeds are also gigabytes
8132020-11-12T20:55:30 <MarcoFalke> I'll probably create a pull to create a single binary after the branch-off
8142020-11-12T20:55:50 <MarcoFalke> then, they can also be compiled normally (by default)
8152020-11-12T20:55:57 <MarcoFalke> for non-fuzz builds
8162020-11-12T20:56:14 <sipa> yeah, it's not just a space issue, also compile time
8172020-11-12T20:56:25 <sipa> running the full linker 100s of times
8182020-11-12T20:56:43 <MarcoFalke> why can't ccache cache the linker result?
8192020-11-12T20:57:47 <sipa> i'm not sure if linking is ccached, actually
8202020-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
8212020-11-12T20:58:28 <MarcoFalke> fair enough
8222020-11-12T20:59:13 <sipa> MarcoFalke: so you're convinced it doesn't matter for the fuzzing engine?
8232020-11-12T20:59:26 <MarcoFalke> why should it?
8242020-11-12T20:59:27 <sipa> that sounds reasonable to me, but i thought we'd want to have some kind of benchmark first
8252020-11-12T20:59:35 <sipa> more reachable code or something
8262020-11-12T20:59:49 <sipa> i don't know exactly how the fuzzing engine reasons about those things
8272020-11-12T21:00:02 *** flukiluke1 <flukiluke1!~flukiluke@185.204.1.185> has quit IRC ()
8282020-11-12T21:00:35 <sipa> qa-assets directory is 1.3 GiB for me; a full build in fuzz mode is 7.3 GiB
8292020-11-12T21:00:42 <MarcoFalke> It might break symbolic execution, but we don't use that
8302020-11-12T21:00:58 <sipa> what's symbolic execution?
8312020-11-12T21:02:00 <MarcoFalke> Not using values, but symbols (as in math) for detecting violating conditions
8322020-11-12T21:02:39 <sipa> ok, i knew that... i mean specifially in the context of fuzzing
8332020-11-12T21:02:52 <sipa> are there fuzz engines that can take advantage of that?
8342020-11-12T21:03:19 <MarcoFalke> yes, but I haven't tried them
8352020-11-12T21:04:15 <sipa> ah cool
8362020-11-12T21:04:22 <MarcoFalke> https://www.youtube.com/watch?v=h_A8IRBEtdQ
8372020-11-12T21:05:03 <MarcoFalke> :( Can't play it anymore. Looks like youtube deleted all webm transcodings for videos with less than 10k views
8382020-11-12T21:07:12 <sipa> works fine here?
8392020-11-12T21:08:27 <michaelfolkson> Works for me fine in the browser
8402020-11-12T21:10:04 *** jeremyrubin <jeremyrubin!~jr@c-73-15-215-148.hsd1.ca.comcast.net> has quit IRC (Ping timeout: 265 seconds)
8412020-11-12T21:10:51 <queip> MarcoFalke: works for me, YT has outage yesterday, perhaps it's stay intermittent in some places
8422020-11-12T21:12:21 <MarcoFalke> oh, it is WEBM DASH
8432020-11-12T21:12:21 *** promag <promag!~promag@188.250.84.129> has quit IRC (Remote host closed the connection)
8442020-11-12T21:13:52 <MarcoFalke> hmm https://bugzilla.mozilla.org/show_bug.cgi?id=778617
8452020-11-12T21:20:50 *** Guyver2 <Guyver2!Guyver@guyver2.xs4all.nl> has quit IRC (Quit: Going offline, see ya! (www.adiirc.com))
8462020-11-12T21:22:39 <ja> michaelfolkson: which codec is it using?
8472020-11-12T21:23:17 *** James_F1 <James_F1!~James_F@178.162.212.214> has joined #bitcoin-core-dev
8482020-11-12T21:29:17 *** jeremyrubin <jeremyrubin!~jr@c-73-15-215-148.hsd1.ca.comcast.net> has joined #bitcoin-core-dev
8492020-11-12T21:36:13 *** nckx <nckx!~nckx@tobias.gr> has quit IRC (Ping timeout: 264 seconds)
8502020-11-12T21:49:04 *** CubicEarth <CubicEarth!~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net> has quit IRC (Ping timeout: 260 seconds)
8512020-11-12T21:51:48 *** CubicEarth <CubicEarth!~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net> has joined #bitcoin-core-dev
8522020-11-12T21:54:36 *** troygiorshev <troygiorshev!~troygiors@d67-193-140-136.home3.cgocable.net> has joined #bitcoin-core-dev
8532020-11-12T21:57:57 <troygiorshev> !topic
8542020-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
8552020-11-12T22:00:24 *** Cory <Cory!~Cory@unaffiliated/cory> has quit IRC (Ping timeout: 258 seconds)
8562020-11-12T22:06:55 *** Cory <Cory!~Cory@unaffiliated/cory> has joined #bitcoin-core-dev
8572020-11-12T22:08:22 *** filchef <filchef!~filchef@212.104.97.177> has quit IRC (Quit: KVIrc 5.0.0 Aria http://www.kvirc.net/)
8582020-11-12T22:08:57 *** vasild_ <vasild_!~vd@gateway/tor-sasl/vasild> has joined #bitcoin-core-dev
8592020-11-12T22:12:03 *** vasild <vasild!~vd@gateway/tor-sasl/vasild> has quit IRC (Ping timeout: 240 seconds)
8602020-11-12T22:12:04 *** vasild_ is now known as vasild
8612020-11-12T22:19:36 *** TheRec <TheRec!~toto@drupal.org/user/146860/view> has quit IRC ()
8622020-11-12T22:24:42 *** promag <promag!~promag@188.250.84.129> has joined #bitcoin-core-dev
8632020-11-12T22:28:27 *** Kiminuo <Kiminuo!~mix@141.98.103.92> has quit IRC (Ping timeout: 256 seconds)
8642020-11-12T22:31:16 *** proofofkeags <proofofkeags!~proofofke@174-16-205-160.hlrn.qwest.net> has quit IRC (Ping timeout: 244 seconds)
8652020-11-12T22:32:51 *** nckx <nckx!~nckx@tobias.gr> has joined #bitcoin-core-dev
8662020-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)
8672020-11-12T22:34:08 *** sr_gi <sr_gi!~sr_gi@static-120-201-229-77.ipcom.comunitel.net> has joined #bitcoin-core-dev
8682020-11-12T22:43:09 *** TheRec <TheRec!~toto@drupal.org/user/146860/view> has joined #bitcoin-core-dev
8692020-11-12T22:57:26 *** yanmaani <yanmaani!~yanmaani@gateway/tor-sasl/yanmaani> has joined #bitcoin-core-dev
8702020-11-12T23:07:48 *** davterra <davterra!~davterra@69.4.234.71> has quit IRC (Read error: Connection reset by peer)
8712020-11-12T23:08:01 *** davterra <davterra!~davterra@69.4.234.71> has joined #bitcoin-core-dev
8722020-11-12T23:08:05 *** nanotube <nanotube!~nanotube@unaffiliated/nanotube> has quit IRC (Ping timeout: 240 seconds)
8732020-11-12T23:12:23 *** jb55 <jb55!~jb55@gateway/tor-sasl/jb55> has quit IRC (Ping timeout: 240 seconds)
8742020-11-12T23:16:00 *** nanotube <nanotube!~nanotube@unaffiliated/nanotube> has joined #bitcoin-core-dev
8752020-11-12T23:19:03 *** promag <promag!~promag@188.250.84.129> has quit IRC (Remote host closed the connection)
8762020-11-12T23:21:08 *** jeremyrubin <jeremyrubin!~jr@c-73-15-215-148.hsd1.ca.comcast.net> has quit IRC (Ping timeout: 256 seconds)
8772020-11-12T23:21:49 *** mrostecki <mrostecki!~mrostecki@gateway/tor-sasl/mrostecki> has joined #bitcoin-core-dev
8782020-11-12T23:26:10 *** bralyclow2 <bralyclow2!~bralyclow@unaffiliated/bralyclow> has joined #bitcoin-core-dev
8792020-11-12T23:26:35 *** jb55 <jb55!~jb55@gateway/tor-sasl/jb55> has joined #bitcoin-core-dev
8802020-11-12T23:55:34 *** mol_ <mol_!~mol@unaffiliated/molly> has quit IRC (Read error: Connection reset by peer)
8812020-11-12T23:55:59 *** mol_ <mol_!~mol@unaffiliated/molly> has joined #bitcoin-core-dev
8822020-11-12T23:57:33 *** midnight <midnight!~midnight@unaffiliated/midnightmagic> has quit IRC (Ping timeout: 244 seconds)