12020-12-01T00:36:45 *** Klox04809318631 <Klox04809318631!~Klox@c-24-1-131-19.hsd1.il.comcast.net> has quit IRC (Ping timeout: 240 seconds)
22020-12-01T00:37:22 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
32020-12-01T00:37:22 <bitcoin-git> [bitcoin] theStack opened pull request #20537: refactor: replace manual Satoshis-to-BTC conversions with FormatMoney() (master...20201129-use-formatmoney) https://github.com/bitcoin/bitcoin/pull/20537
42020-12-01T00:37:30 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
52020-12-01T00:38:39 *** Klox04809318631 <Klox04809318631!~Klox@c-24-1-131-19.hsd1.il.comcast.net> has joined #bitcoin-core-dev
62020-12-01T01:06:16 *** mol <mol!~mol@unaffiliated/molly> has quit IRC (Ping timeout: 240 seconds)
72020-12-01T01:13:00 *** da39a3ee5e6b4b0d <da39a3ee5e6b4b0d!~da39a3ee5@mx-ll-171.5.161-165.dynamic.3bb.co.th> has joined #bitcoin-core-dev
82020-12-01T01:18:49 *** proofofkeags <proofofkeags!~proofofke@c-73-34-43-4.hsd1.co.comcast.net> has quit IRC (Ping timeout: 264 seconds)
92020-12-01T01:26:13 *** aGHz_nfb <aGHz_nfb!~aGHz_nfb@185.163.110.116> has quit IRC (Remote host closed the connection)
102020-12-01T01:27:08 *** reallll <reallll!~belcher@unaffiliated/belcher> has joined #bitcoin-core-dev
112020-12-01T01:30:13 *** belcher <belcher!~belcher@unaffiliated/belcher> has quit IRC (Ping timeout: 264 seconds)
122020-12-01T01:39:04 *** ghost43_ <ghost43_!~daer@gateway/tor-sasl/daer> has quit IRC (Remote host closed the connection)
132020-12-01T01:39:21 *** ghost43 <ghost43!~daer@gateway/tor-sasl/daer> has joined #bitcoin-core-dev
142020-12-01T01:40:16 *** lightlike <lightlike!~lightlike@p200300c7ef177a00b8e983ade8f2d04e.dip0.t-ipconnect.de> has quit IRC (Quit: Leaving)
152020-12-01T01:43:44 *** davterra <davterra!~davterra@68.235.43.102> has quit IRC (Quit: Leaving)
162020-12-01T01:46:50 *** EagleTM <EagleTM!~EagleTM@unaffiliated/eagletm> has quit IRC (Ping timeout: 256 seconds)
172020-12-01T01:47:09 *** maop <maop!~maop@195.140.213.38> has joined #bitcoin-core-dev
182020-12-01T01:48:38 *** AaronvanW <AaronvanW!~AaronvanW@unaffiliated/aaronvanw> has quit IRC (Remote host closed the connection)
192020-12-01T01:52:32 *** davterra <davterra!~davterra@68.235.43.174> has joined #bitcoin-core-dev
202020-12-01T02:01:29 *** jesseposner <jesseposner!~jp@2601:643:8980:bfd2:f040:ed44:8391:19d3> has joined #bitcoin-core-dev
212020-12-01T02:10:08 <andytoshi> holy shit the taproot python tests are extensive
222020-12-01T02:10:39 <sipa> :)
232020-12-01T02:13:39 <luke-jr> XD
242020-12-01T02:29:11 *** AaronvanW <AaronvanW!~AaronvanW@unaffiliated/aaronvanw> has joined #bitcoin-core-dev
252020-12-01T02:32:10 *** proofofkeags <proofofkeags!~proofofke@174-16-212-53.hlrn.qwest.net> has joined #bitcoin-core-dev
262020-12-01T02:33:36 *** AaronvanW <AaronvanW!~AaronvanW@unaffiliated/aaronvanw> has quit IRC (Ping timeout: 240 seconds)
272020-12-01T02:42:34 *** mol <mol!~mol@unaffiliated/molly> has joined #bitcoin-core-dev
282020-12-01T02:43:14 *** justanotheruser <justanotheruser!~justanoth@unaffiliated/justanotheruser> has quit IRC (Ping timeout: 264 seconds)
292020-12-01T02:55:16 *** justanotheruser <justanotheruser!~justanoth@unaffiliated/justanotheruser> has joined #bitcoin-core-dev
302020-12-01T04:02:52 *** kristapsk <kristapsk!~KK@gateway/tor-sasl/kristapsk> has quit IRC (Remote host closed the connection)
312020-12-01T04:14:43 *** az0re <az0re!~az0re@gateway/tor-sasl/az0re> has quit IRC (Ping timeout: 240 seconds)
322020-12-01T04:30:52 *** AaronvanW <AaronvanW!~AaronvanW@unaffiliated/aaronvanw> has joined #bitcoin-core-dev
332020-12-01T04:53:57 *** miketwenty1 <miketwenty1!~miketwent@ec2-52-207-61-44.compute-1.amazonaws.com> has quit IRC (Remote host closed the connection)
342020-12-01T04:56:01 *** TheHoliestRoger <TheHoliestRoger!~TheHolies@unaffiliated/theholiestroger> has quit IRC (Quit: Find me in #TheHolyRoger or https://theholyroger.com)
352020-12-01T05:01:22 *** TheHoliestRoger <TheHoliestRoger!~TheHolies@unaffiliated/theholiestroger> has joined #bitcoin-core-dev
362020-12-01T05:03:14 *** AaronvanW <AaronvanW!~AaronvanW@unaffiliated/aaronvanw> has quit IRC (Ping timeout: 256 seconds)
372020-12-01T05:12:36 *** jonatack <jonatack!~jon@82.102.27.171> has quit IRC (Ping timeout: 240 seconds)
382020-12-01T05:15:02 *** jonatack <jonatack!~jon@88.124.242.136> has joined #bitcoin-core-dev
392020-12-01T05:21:11 *** az0re <az0re!~az0re@gateway/tor-sasl/az0re> has joined #bitcoin-core-dev
402020-12-01T05:55:06 *** espiral <espiral!b9edb429@185.237.180.41> has joined #bitcoin-core-dev
412020-12-01T05:55:27 *** maop <maop!~maop@195.140.213.38> has quit IRC (Remote host closed the connection)
422020-12-01T05:59:38 *** espiral <espiral!b9edb429@185.237.180.41> has quit IRC (Remote host closed the connection)
432020-12-01T06:08:17 *** gimps <gimps!~gimps@185.163.110.116> has joined #bitcoin-core-dev
442020-12-01T06:08:25 *** openoms <openoms!~quassel@91.132.136.76> has quit IRC (Read error: Connection reset by peer)
452020-12-01T06:08:41 *** EagleTM <EagleTM!~EagleTM@unaffiliated/eagletm> has joined #bitcoin-core-dev
462020-12-01T06:09:12 *** openoms <openoms!~quassel@91.132.136.76> has joined #bitcoin-core-dev
472020-12-01T06:10:53 *** IGHOR <IGHOR!~quassel@176.121.4.135> has quit IRC (Quit: http://quassel-irc.org ? ??????????? ?????????. ????-??.)
482020-12-01T06:12:03 *** IGHOR <IGHOR!~quassel@176.121.4.135> has joined #bitcoin-core-dev
492020-12-01T06:51:09 *** kristapsk <kristapsk!~KK@gateway/tor-sasl/kristapsk> has joined #bitcoin-core-dev
502020-12-01T06:54:32 *** sdaftuar <sdaftuar!~sdaftuar@gateway/tor-sasl/sdaftuar> has quit IRC (Remote host closed the connection)
512020-12-01T06:55:06 *** sdaftuar <sdaftuar!~sdaftuar@gateway/tor-sasl/sdaftuar> has joined #bitcoin-core-dev
522020-12-01T06:59:49 *** sr_gi <sr_gi!~sr_gi@80.174.218.168.dyn.user.ono.com> has quit IRC (Read error: Connection reset by peer)
532020-12-01T07:00:18 *** sr_gi <sr_gi!~sr_gi@80.174.218.168.dyn.user.ono.com> has joined #bitcoin-core-dev
542020-12-01T07:00:28 *** AaronvanW <AaronvanW!~AaronvanW@unaffiliated/aaronvanw> has joined #bitcoin-core-dev
552020-12-01T07:06:44 *** Kiminuo <Kiminuo!~mix@141.98.103.172> has joined #bitcoin-core-dev
562020-12-01T07:31:12 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
572020-12-01T07:31:12 <bitcoin-git> [bitcoin] MarcoFalke pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/81d5af42f4db...ffd5e7a8567d
582020-12-01T07:31:13 <bitcoin-git> bitcoin/master 9429a39 practicalswift: Handle rename failure in DumpMempool(...) by using RenameOver(...) return ...
592020-12-01T07:31:13 <bitcoin-git> bitcoin/master ce9dd45 practicalswift: Add [[nodiscard]] to RenameOver(...)
602020-12-01T07:31:14 <bitcoin-git> bitcoin/master ffd5e7a MarcoFalke: Merge #20519: Handle rename failure in DumpMempool(...) by using the Renam...
612020-12-01T07:31:15 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
622020-12-01T07:31:32 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
632020-12-01T07:31:32 <bitcoin-git> [bitcoin] MarcoFalke merged pull request #20519: Handle rename failure in DumpMempool(...) by using the RenameOver(...) return value. Add [[nodiscard]] to RenameOver(...). (master...renameover-nodiscard) https://github.com/bitcoin/bitcoin/pull/20519
642020-12-01T07:31:33 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
652020-12-01T07:33:59 *** AaronvanW <AaronvanW!~AaronvanW@unaffiliated/aaronvanw> has quit IRC (Ping timeout: 260 seconds)
662020-12-01T08:21:57 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
672020-12-01T08:21:57 <bitcoin-git> [bitcoin] naumenkogs opened pull request #20539: Avoid rebucketing on restart when it's not necessary (master...2020-12-01-rebucket-asmap-fix) https://github.com/bitcoin/bitcoin/pull/20539
682020-12-01T08:21:58 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
692020-12-01T08:25:34 *** Pavlenex <Pavlenex!~Thunderbi@178.220.103.52> has joined #bitcoin-core-dev
702020-12-01T08:30:13 *** Pavlenex <Pavlenex!~Thunderbi@178.220.103.52> has quit IRC (Client Quit)
712020-12-01T08:30:57 *** Pavlenex <Pavlenex!~Thunderbi@178.220.103.52> has joined #bitcoin-core-dev
722020-12-01T08:34:16 *** Pavlenex <Pavlenex!~Thunderbi@178.220.103.52> has quit IRC (Client Quit)
732020-12-01T08:41:59 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
742020-12-01T08:42:00 <bitcoin-git> [bitcoin] MarcoFalke pushed 4 commits to master: https://github.com/bitcoin/bitcoin/compare/ffd5e7a8567d...24e4857b29b3
752020-12-01T08:42:00 <bitcoin-git> bitcoin/master 12bd0fc Russell Yanofsky: Move NodeImpl from interfaces/node.cpp to node/interfaces.cpp
762020-12-01T08:42:01 <bitcoin-git> bitcoin/master 2a26771 Russell Yanofsky: Move ChainImpl from interfaces/chain.cpp to node/interfaces.cpp
772020-12-01T08:42:02 <bitcoin-git> bitcoin/master 629a929 Russell Yanofsky: Move WalletImpl from interfaces/wallet.cpp to wallet/interfaces.cpp
782020-12-01T08:42:03 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
792020-12-01T08:42:19 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
802020-12-01T08:42:19 <bitcoin-git> [bitcoin] MarcoFalke merged pull request #20494: refactor: Move node and wallet code out of src/interfaces (master...pr/ipc-mv) https://github.com/bitcoin/bitcoin/pull/20494
812020-12-01T08:42:20 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
822020-12-01T08:50:09 *** Pavlenex <Pavlenex!~Thunderbi@178.220.103.52> has joined #bitcoin-core-dev
832020-12-01T09:04:07 *** tryphe <tryphe!~tryphe@unaffiliated/tryphe> has joined #bitcoin-core-dev
842020-12-01T09:04:16 *** tryphe_ <tryphe_!~tryphe@unaffiliated/tryphe> has quit IRC (Ping timeout: 240 seconds)
852020-12-01T09:05:06 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
862020-12-01T09:05:06 <bitcoin-git> [bitcoin] MarcoFalke pushed 4 commits to master: https://github.com/bitcoin/bitcoin/compare/24e4857b29b3...cd720337fe9c
872020-12-01T09:05:07 <bitcoin-git> bitcoin/master 9d4b4b2 Elle Mouton: refactor: Avoid double to int cast for nCheckFrequency
882020-12-01T09:05:09 <bitcoin-git> bitcoin/master e331069 Elle Mouton: refactor: Make CTxMemPool::m_check_ratio a const and a constructor argumen...
892020-12-01T09:05:09 <bitcoin-git> bitcoin/master f15e780 Elle Mouton: refactor: Clean up CTxMemPool initializer list
902020-12-01T09:05:10 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
912020-12-01T09:05:25 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
922020-12-01T09:05:26 <bitcoin-git> [bitcoin] MarcoFalke merged pull request #20222: refactor: CTxMempool constructor clean up (master...ctxmempool_refactor) https://github.com/bitcoin/bitcoin/pull/20222
932020-12-01T09:05:27 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
942020-12-01T09:19:44 *** Guyver2 <Guyver2!Guyver@guyver2.xs4all.nl> has joined #bitcoin-core-dev
952020-12-01T09:24:28 *** BGL <BGL!~twenty@75-149-171-58-Washington.hfc.comcastbusiness.net> has quit IRC (Ping timeout: 256 seconds)
962020-12-01T09:31:19 *** AaronvanW <AaronvanW!~AaronvanW@unaffiliated/aaronvanw> has joined #bitcoin-core-dev
972020-12-01T09:47:51 *** Victorsueca <Victorsueca!~Victorsue@unaffiliated/victorsueca> has joined #bitcoin-core-dev
982020-12-01T09:59:38 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
992020-12-01T09:59:38 <bitcoin-git> [bitcoin] jonasschnelli pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/cd720337fe9c...f2a673f15b51
1002020-12-01T09:59:38 <bitcoin-git> bitcoin/master 86b1ab6 Hennadii Stepanov: refactor: Replace deprecated Qt::SystemLocale{Short,Long}Date
1012020-12-01T09:59:39 <bitcoin-git> bitcoin/master f2a673f Jonas Schnelli: Merge bitcoin-core/gui#137: refactor: Replace deprecated Qt::SystemLocale{...
1022020-12-01T09:59:40 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
1032020-12-01T09:59:58 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
1042020-12-01T09:59:58 <bitcoin-git> [gui] jonasschnelli merged pull request #137: refactor: Replace deprecated Qt::SystemLocale{Short,Long}Date (master...201127-locale) https://github.com/bitcoin-core/gui/pull/137
1052020-12-01T09:59:59 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
1062020-12-01T10:02:33 *** vasild <vasild!~vd@gateway/tor-sasl/vasild> has quit IRC (Quit: leaving)
1072020-12-01T10:03:49 *** AaronvanW <AaronvanW!~AaronvanW@unaffiliated/aaronvanw> has quit IRC (Ping timeout: 264 seconds)
1082020-12-01T10:03:56 *** kexkey <kexkey!~kexkey@static-198-54-132-105.cust.tzulo.com> has quit IRC (Ping timeout: 240 seconds)
1092020-12-01T10:07:47 *** Tennis <Tennis!~Tennis@unaffiliated/tennis> has joined #bitcoin-core-dev
1102020-12-01T10:16:03 *** AaronvanW <AaronvanW!~AaronvanW@unaffiliated/aaronvanw> has joined #bitcoin-core-dev
1112020-12-01T10:18:03 *** ghost43 <ghost43!~daer@gateway/tor-sasl/daer> has quit IRC (Ping timeout: 240 seconds)
1122020-12-01T10:18:51 *** ghost43 <ghost43!~daer@gateway/tor-sasl/daer> has joined #bitcoin-core-dev
1132020-12-01T10:22:41 *** AaronvanW <AaronvanW!~AaronvanW@unaffiliated/aaronvanw> has quit IRC (Remote host closed the connection)
1142020-12-01T10:22:58 *** AaronvanW <AaronvanW!~AaronvanW@unaffiliated/aaronvanw> has joined #bitcoin-core-dev
1152020-12-01T10:23:57 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
1162020-12-01T10:23:58 <bitcoin-git> [bitcoin] jonasschnelli pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/f2a673f15b51...335d27d08141
1172020-12-01T10:23:58 <bitcoin-git> bitcoin/master 1d578c0 Emil Engler: doc: Add bash as an OpenBSD dependency
1182020-12-01T10:23:58 <bitcoin-git> bitcoin/master 335d27d Jonas Schnelli: Merge #20512: doc: Add bash as an OpenBSD dependency
1192020-12-01T10:24:00 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
1202020-12-01T10:24:17 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
1212020-12-01T10:24:17 <bitcoin-git> [bitcoin] jonasschnelli merged pull request #20512: doc: Add bash as an OpenBSD dependency (master...2020-11-doc-build-openbsd-bash-dependency) https://github.com/bitcoin/bitcoin/pull/20512
1222020-12-01T10:24:18 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
1232020-12-01T10:27:45 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
1242020-12-01T10:27:46 <bitcoin-git> [bitcoin] jonasschnelli pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/335d27d08141...dcb7518067cd
1252020-12-01T10:27:46 <bitcoin-git> bitcoin/master 65afe4c Hennadii Stepanov: build: Drop unneeded ApplicationServices framework dependency
1262020-12-01T10:27:47 <bitcoin-git> bitcoin/master ec4a46d Hennadii Stepanov: build: Drop unneeded IOKit framework dependency
1272020-12-01T10:27:47 <bitcoin-git> bitcoin/master dcb7518 Jonas Schnelli: Merge #20496: build: Drop unneeded macOS framework dependencies
1282020-12-01T10:27:49 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
1292020-12-01T10:28:05 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
1302020-12-01T10:28:05 <bitcoin-git> [bitcoin] jonasschnelli merged pull request #20496: build: Drop unneeded macOS framework dependencies (master...201125-as) https://github.com/bitcoin/bitcoin/pull/20496
1312020-12-01T10:28:06 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
1322020-12-01T10:28:21 *** kljasdfvv <kljasdfvv!~flack@p200300d46f24de00fb39606f311c9ef9.dip0.t-ipconnect.de> has joined #bitcoin-core-dev
1332020-12-01T10:29:00 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
1342020-12-01T10:29:00 <bitcoin-git> [bitcoin] jonasschnelli pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/dcb7518067cd...277c225b8421
1352020-12-01T10:29:01 <bitcoin-git> bitcoin/master 982e548 Jonas Schnelli: Don't set BDB flags when configuring without
1362020-12-01T10:29:01 <bitcoin-git> bitcoin/master 277c225 Jonas Schnelli: Merge #20478: Don't set BDB flags when configuring without
1372020-12-01T10:29:03 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
1382020-12-01T10:29:20 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
1392020-12-01T10:29:20 <bitcoin-git> [bitcoin] jonasschnelli merged pull request #20478: Don't set BDB flags when configuring without (master...2020/11/bdbless_mac) https://github.com/bitcoin/bitcoin/pull/20478
1402020-12-01T10:29:21 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
1412020-12-01T10:33:01 *** vasild <vasild!~vd@gateway/tor-sasl/vasild> has joined #bitcoin-core-dev
1422020-12-01T10:34:11 *** vasild <vasild!~vd@gateway/tor-sasl/vasild> has quit IRC (Client Quit)
1432020-12-01T10:35:47 *** vasild <vasild!~vd@gateway/tor-sasl/vasild> has joined #bitcoin-core-dev
1442020-12-01T10:41:01 *** proofofkeags <proofofkeags!~proofofke@174-16-212-53.hlrn.qwest.net> has quit IRC (Ping timeout: 260 seconds)
1452020-12-01T10:44:02 *** vasild <vasild!~vd@gateway/tor-sasl/vasild> has quit IRC (Disconnected by services)
1462020-12-01T10:44:03 *** vasild_ <vasild_!~vd@gateway/tor-sasl/vasild> has joined #bitcoin-core-dev
1472020-12-01T10:44:33 *** reallll is now known as belcher
1482020-12-01T10:48:24 *** Pavlenex <Pavlenex!~Thunderbi@178.220.103.52> has quit IRC (Quit: Pavlenex)
1492020-12-01T11:03:14 *** Kiminuo <Kiminuo!~mix@141.98.103.172> has quit IRC (Quit: Leaving)
1502020-12-01T11:18:31 *** Josiane57Wyman <Josiane57Wyman!~Josiane57@static.57.1.216.95.clients.your-server.de> has joined #bitcoin-core-dev
1512020-12-01T11:31:38 *** jeremyrubin <jeremyrubin!~jr@c-73-15-215-148.hsd1.ca.comcast.net> has quit IRC (Ping timeout: 256 seconds)
1522020-12-01T11:34:54 *** Josiane57Wyman <Josiane57Wyman!~Josiane57@static.57.1.216.95.clients.your-server.de> has quit IRC (Ping timeout: 260 seconds)
1532020-12-01T11:55:43 *** vasild_ <vasild_!~vd@gateway/tor-sasl/vasild> has quit IRC (Ping timeout: 240 seconds)
1542020-12-01T11:59:36 *** vasild <vasild!~vd@gateway/tor-sasl/vasild> has joined #bitcoin-core-dev
1552020-12-01T12:02:58 *** BGL <BGL!~twenty@75-149-171-58-Washington.hfc.comcastbusiness.net> has joined #bitcoin-core-dev
1562020-12-01T12:11:11 *** Pavlenex <Pavlenex!~Thunderbi@178.220.103.52> has joined #bitcoin-core-dev
1572020-12-01T12:25:28 *** gimps <gimps!~gimps@185.163.110.116> has quit IRC (Remote host closed the connection)
1582020-12-01T12:39:44 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
1592020-12-01T12:39:44 <bitcoin-git> [bitcoin] MarcoFalke opened pull request #20540: test: Fix wallet_multiwallet issue on windows (master...2012-testmw) https://github.com/bitcoin/bitcoin/pull/20540
1602020-12-01T12:39:45 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
1612020-12-01T13:05:45 *** da39a3ee5e6b4b0d <da39a3ee5e6b4b0d!~da39a3ee5@mx-ll-171.5.161-165.dynamic.3bb.co.th> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzzâ¦)
1622020-12-01T13:06:39 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
1632020-12-01T13:06:39 <bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/277c225b8421...dfd0b700886c
1642020-12-01T13:06:40 <bitcoin-git> bitcoin/master 17a5f17 practicalswift: fuzz: Make addrman fuzzing harness deterministic
1652020-12-01T13:06:40 <bitcoin-git> bitcoin/master dfd0b70 MarcoFalke: Merge #20425: fuzz: Make CAddrMan fuzzing harness deterministic
1662020-12-01T13:06:42 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
1672020-12-01T13:06:54 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
1682020-12-01T13:06:54 <bitcoin-git> [bitcoin] MarcoFalke merged pull request #20425: fuzz: Make CAddrMan fuzzing harness deterministic (master...fuzzers-make-addrman-harness-deterministic) https://github.com/bitcoin/bitcoin/pull/20425
1692020-12-01T13:06:55 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
1702020-12-01T13:14:23 *** ghost43 <ghost43!~daer@gateway/tor-sasl/daer> has quit IRC (Ping timeout: 240 seconds)
1712020-12-01T13:15:50 *** ghost43 <ghost43!~daer@gateway/tor-sasl/daer> has joined #bitcoin-core-dev
1722020-12-01T13:24:24 *** luke-jr <luke-jr!~luke-jr@unaffiliated/luke-jr> has quit IRC (Read error: Connection reset by peer)
1732020-12-01T13:24:37 <MarcoFalke> michaelfolkson: Let's take this here
1742020-12-01T13:25:56 <michaelfolkson> MarcoFalke: Sure, thanks
1752020-12-01T13:26:30 *** luke-jr <luke-jr!~luke-jr@unaffiliated/luke-jr> has joined #bitcoin-core-dev
1762020-12-01T13:27:00 <michaelfolkson> I think I'm misunderstanding terminology. So seeds will be randomly generated...
1772020-12-01T13:28:35 <MarcoFalke> Some fuzz engines have command line switches to make them deterministic
1782020-12-01T13:28:49 <michaelfolkson> But if a fuzz tester finds an issue with a randomly generated seed a different fuzz tester who tries that same input needs to get the same result
1792020-12-01T13:29:03 <MarcoFalke> yes
1802020-12-01T13:29:20 <MarcoFalke> if you can't reproduce, it will be hard to debug and fix
1812020-12-01T13:29:49 *** da39a3ee5e6b4b0d <da39a3ee5e6b4b0d!~da39a3ee5@2403:6200:8876:9156:59b2:2700:3dd:eb69> has joined #bitcoin-core-dev
1822020-12-01T13:30:16 <michaelfolkson> But you can reproduce as long as you know what the inputs were. Whether they were randomly generated or not is surely irrelevant?
1832020-12-01T13:31:20 <michaelfolkson> It is surely a logging issue rather than a choice of deterministic/random?
1842020-12-01T13:32:44 <MarcoFalke> int main() { if (rand() > 2) crash(); }
1852020-12-01T13:33:09 <MarcoFalke> how would you reliably reproduce a crash here, knowing the input?
1862020-12-01T13:33:48 <MarcoFalke> how the input was generated is irrelevant to how to reproduce a bug
1872020-12-01T13:34:41 <MarcoFalke> logging helps to debug intermittent (non-reproducible) bugs better
1882020-12-01T13:35:05 <MarcoFalke> we have a lot of them, which is why logging is cranked up in all tests
1892020-12-01T13:36:42 <michaelfolkson> In your example one fuzz tester would crash the program with say an input of 3. For another fuzz tester to reproduce it they would need to know the other fuzz tester tried an input of 3
1902020-12-01T13:37:36 <michaelfolkson> But how the fuzz tester initially generated 3 is irrelevant. It could have been deterministic or random
1912020-12-01T13:39:02 <michaelfolkson> So in the PR there is a CAddrMan fuzzing harness. Again I'm not entirely sure how "harness" is defined
1922020-12-01T13:40:19 <michaelfolkson> But fuzz testers should be able to randomly generate addrs and try different addrs to other fuzz testers. As long as they log which addrs they tried and which addrs created issues?
1932020-12-01T13:41:02 <MarcoFalke> whether the above example crashes is *independent* of the input
1942020-12-01T13:41:25 <MarcoFalke> the progam takes no input, assuming that rand will ask the OS for randomness
1952020-12-01T13:42:44 <MarcoFalke> and in most cases the OS randomness is not reproducible
1962020-12-01T13:43:03 <michaelfolkson> And the problem is that we don't log what the OS supplied for randomness?
1972020-12-01T13:43:37 <MarcoFalke> the problem is that we ask the os for randomness
1982020-12-01T13:44:05 <MarcoFalke> tests should supply the randomness. Either with a hardcoded seed or letting the fuzz engine pick one
1992020-12-01T13:44:35 <michaelfolkson> Ah so the problem is an external source of randomness rather than an internal source from within the tests
2002020-12-01T13:45:03 <michaelfolkson> It is still random but it is generated within the tests
2012020-12-01T13:45:04 <MarcoFalke> as long as the source is reproducible/deterministic, it can be from anywhere
2022020-12-01T13:46:25 <michaelfolkson> And by that you mean a reproducible source of randomness is one that supplies the same inputs when it is asked for randomness
2032020-12-01T13:46:47 <michaelfolkson> Everytime it is asked for randomness it provides say inputs of 7,2,3 as the first three random inputs
2042020-12-01T13:46:59 *** luke-jr <luke-jr!~luke-jr@unaffiliated/luke-jr> has quit IRC (Read error: Connection reset by peer)
2052020-12-01T13:47:28 <michaelfolkson> The problem becomes when you ask it for randomness twice and it provides different inputs on the second time vs the first
2062020-12-01T13:47:59 *** luke-jr <luke-jr!~luke-jr@unaffiliated/luke-jr> has joined #bitcoin-core-dev
2072020-12-01T13:48:20 *** luke-jr <luke-jr!~luke-jr@unaffiliated/luke-jr> has quit IRC (Read error: Connection reset by peer)
2082020-12-01T13:49:06 *** einyx <einyx!einyx@fsf/member/einyx> has quit IRC (Ping timeout: 256 seconds)
2092020-12-01T13:49:38 *** luke-jr <luke-jr!~luke-jr@unaffiliated/luke-jr> has joined #bitcoin-core-dev
2102020-12-01T13:50:10 <MarcoFalke> yes, when "s/time/program execution/"
2112020-12-01T13:50:34 <michaelfolkson> Gotcha. Thanks!
2122020-12-01T13:51:33 <michaelfolkson> How would you explain what a fuzzing "harness" is?
2132020-12-01T13:51:43 *** vasild <vasild!~vd@gateway/tor-sasl/vasild> has quit IRC (Ping timeout: 240 seconds)
2142020-12-01T13:53:30 <MarcoFalke> a test case or one test target
2152020-12-01T13:54:34 <michaelfolkson> OK "entry-point executable" from this https://vdalabs.com/2019/02/01/microsoft-security-risk-detection-writing-a-custom-test-harness-to-fuzz-libraries/
2162020-12-01T13:54:59 <michaelfolkson> Ok thanks for the help
2172020-12-01T13:57:27 <jnewbery> hi folks. It's p2p irc meeting day. There aren't currently any topics in https://github.com/bitcoin-core/bitcoin-devwiki/wiki/P2P-IRC-meetings#1-dec-2020. Feel free to add anything you want to discuss. The meeting starts in just over an hour.
2182020-12-01T13:57:30 <gribble> https://github.com/bitcoin/bitcoin/issues/1 | JSON-RPC support for mobile devices ("ultra-lightweight" clients) · Issue #1 · bitcoin/bitcoin · GitHub
2192020-12-01T14:02:19 *** Lightlike <Lightlike!b9ff439e@185.255.67.158> has joined #bitcoin-core-dev
2202020-12-01T14:04:03 *** untwisted <untwisted!~untwisted@84.39.117.57> has joined #bitcoin-core-dev
2212020-12-01T14:05:33 *** Lightlike <Lightlike!b9ff439e@185.255.67.158> has left #bitcoin-core-dev
2222020-12-01T14:08:50 *** vasild <vasild!~vd@gateway/tor-sasl/vasild> has joined #bitcoin-core-dev
2232020-12-01T14:14:10 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
2242020-12-01T14:14:11 <bitcoin-git> [bitcoin] MarcoFalke pushed 9 commits to master: https://github.com/bitcoin/bitcoin/compare/dfd0b700886c...f17e8ba3a17b
2252020-12-01T14:14:11 <bitcoin-git> bitcoin/master 18246ed Pieter Wuille: Fix and improve taproot_construct comments
2262020-12-01T14:14:12 <bitcoin-git> bitcoin/master cdf900c Pieter Wuille: Document need_vin_vout_mismatch argument to make_spender
2272020-12-01T14:14:12 <bitcoin-git> bitcoin/master 8dbb7de Pieter Wuille: Add comments to VerifyTaprootCommitment
2282020-12-01T14:14:13 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
2292020-12-01T14:14:30 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
2302020-12-01T14:14:31 <bitcoin-git> [bitcoin] MarcoFalke merged pull request #20207: Follow-up extra comments on taproot code and tests (master...202010_taproot-comments) https://github.com/bitcoin/bitcoin/pull/20207
2312020-12-01T14:14:32 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
2322020-12-01T14:28:48 <michaelfolkson> How does one do that jnewbery? Just manually edit that dev wiki page?
2332020-12-01T14:30:58 *** promag <promag!~promag@188.250.84.129> has quit IRC (Ping timeout: 246 seconds)
2342020-12-01T14:43:52 *** luke-jr <luke-jr!~luke-jr@unaffiliated/luke-jr> has quit IRC (Read error: Connection reset by peer)
2352020-12-01T14:45:04 *** luke-jr <luke-jr!~luke-jr@unaffiliated/luke-jr> has joined #bitcoin-core-dev
2362020-12-01T14:45:23 *** promag <promag!~promag@188.250.84.129> has joined #bitcoin-core-dev
2372020-12-01T14:48:25 *** untwisted <untwisted!~untwisted@84.39.117.57> has quit IRC (Remote host closed the connection)
2382020-12-01T14:48:59 *** luke-jr <luke-jr!~luke-jr@unaffiliated/luke-jr> has quit IRC (Excess Flood)
2392020-12-01T14:50:24 *** luke-jr <luke-jr!~luke-jr@unaffiliated/luke-jr> has joined #bitcoin-core-dev
2402020-12-01T14:51:27 *** mol_ <mol_!~mol@unaffiliated/molly> has joined #bitcoin-core-dev
2412020-12-01T14:51:47 <sdaftuar> has anyone looked at m_addr_known to see if we should be manually clearing it every day? from a quick look at my logs, i estimate that my addr messages to my peers average substantially less than 5000 messages per day, which i think means that our daily self-announcements would propagate less frequently than we'd expect (maybe once every few days, instead of once per day)
2422020-12-01T14:54:04 <jnewbery> michaelfolkson: yes, just edit the page
2432020-12-01T14:54:30 *** mol <mol!~mol@unaffiliated/molly> has quit IRC (Ping timeout: 256 seconds)
2442020-12-01T14:56:26 *** luke-jr <luke-jr!~luke-jr@unaffiliated/luke-jr> has quit IRC (Excess Flood)
2452020-12-01T14:56:49 *** luke-jr <luke-jr!~luke-jr@unaffiliated/luke-jr> has joined #bitcoin-core-dev
2462020-12-01T14:59:48 *** tralfaz <tralfaz!~davterra@68.235.43.158> has joined #bitcoin-core-dev
2472020-12-01T15:00:16 *** glozow <glozow!uid453516@gateway/web/irccloud.com/x-suaydrfreocgdkkl> has joined #bitcoin-core-dev
2482020-12-01T15:00:18 <jnewbery> #startmeeting
2492020-12-01T15:00:18 <core-meetingbot> Meeting started Tue Dec 1 15:00:17 2020 UTC. The chair is jnewbery. Information about MeetBot at https://bitcoin.jonasschnelli.ch/ircmeetings.
2502020-12-01T15:00:18 <core-meetingbot> Available commands: action commands idea info link nick
2512020-12-01T15:00:34 <jnewbery> #bitcoin-core-dev P2P Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101 meshcollider jnewbery maaku fanquake promag provoostenator aj Chris_Stewart_5 dongcarl gwillen jamesob ken281221 ryanofsky gleb moneyball kvaciral ariard digi_james
2522020-12-01T15:00:36 *** sturles <sturles!~sturles@gufseplassen00.slxdrift.no> has joined #bitcoin-core-dev
2532020-12-01T15:00:40 <jnewbery> amiti fjahr jeremyrubin lightlike emilengler jonatack hebasto jb55 elichai2
2542020-12-01T15:01:08 <glozow> hi
2552020-12-01T15:01:09 <sipa> hi
2562020-12-01T15:01:14 <gleb> hi
2572020-12-01T15:01:29 *** da39a3ee5e6b4b0d <da39a3ee5e6b4b0d!~da39a3ee5@2403:6200:8876:9156:59b2:2700:3dd:eb69> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzzâ¦)
2582020-12-01T15:01:35 <ariard> hi
2592020-12-01T15:01:37 <jnewbery> hi folks. No proposed topics in https://github.com/bitcoin-core/bitcoin-devwiki/wiki/P2P-IRC-meetings#1-dec-2020 so could be a short meeting
2602020-12-01T15:01:38 <wumpus> hi
2612020-12-01T15:01:39 <gribble> https://github.com/bitcoin/bitcoin/issues/1 | JSON-RPC support for mobile devices ("ultra-lightweight" clients) · Issue #1 · bitcoin/bitcoin · GitHub
2622020-12-01T15:01:41 <ajonas> Hi
2632020-12-01T15:01:44 <michaelfolkson> hi
2642020-12-01T15:02:00 <jnewbery> anyone have any proposed topics, or anything they want to share with the group?
2652020-12-01T15:02:06 *** Lightlike <Lightlike!b9ff439e@185.255.67.158> has joined #bitcoin-core-dev
2662020-12-01T15:02:43 <michaelfolkson> I'd like to chat about people's thoughts on current P2P fuzzing and whether they do it. And if not why not
2672020-12-01T15:03:16 <jnewbery> #topic p2p fuzzing
2682020-12-01T15:03:17 <core-meetingbot> topic: p2p fuzzing
2692020-12-01T15:03:34 *** davterra <davterra!~davterra@68.235.43.174> has quit IRC (Ping timeout: 256 seconds)
2702020-12-01T15:03:40 <gleb> fuzzing is just a new concept to me, I don't do it because I need to take time to learn it first :)
2712020-12-01T15:03:43 <sdaftuar> if someone pointed me to an idiot's guide to fuzzing, i might do it. but i'm pretty clueless.
2722020-12-01T15:03:51 <fanquake> hi
2732020-12-01T15:04:11 <michaelfolkson> Ok so it is a basic understanding issue?
2742020-12-01T15:04:11 *** miketwenty1 <miketwenty1!~miketwent@136.55.84.49> has joined #bitcoin-core-dev
2752020-12-01T15:04:16 <gleb> i think so.
2762020-12-01T15:04:22 <michaelfolkson> Don't really get what it is trying to do
2772020-12-01T15:04:39 <sipa> find bugs
2782020-12-01T15:04:51 <jnewbery> There were a couple of good PR review club meetings hosted by Marco about fuzzing: https://bitcoincore.reviews/17860 https://bitcoincore.reviews/18521
2792020-12-01T15:05:12 <jnewbery> they contain lots of references to further reading for anyone who's curious
2802020-12-01T15:05:24 <ariard> you can start with the docs of AFL/libfuzzer/hongfuzz and look for talk of their authors :)
2812020-12-01T15:05:29 <sipa> michaelfolkson: what do you mean by p2p fuzzing btw?
2822020-12-01T15:05:43 <MarcoFalke> there are already p2p fuzzers
2832020-12-01T15:06:18 <emzy> Hi
2842020-12-01T15:06:24 <michaelfolkson> Yeah there is P2P code. And P2P experts in this meeting. It would be good eventually to bring that expertise on what should be fuzzed in a P2P context
2852020-12-01T15:06:29 <michaelfolkson> (I think)
2862020-12-01T15:06:41 <MarcoFalke> I am working on increasing their coverage
2872020-12-01T15:07:03 <ariard> IIRC practicalswift added coverage for a part of the p2p stack a while ago ?
2882020-12-01T15:07:38 <michaelfolkson> I guess it is an issue of whether fuzz coverage is something the expert fuzzers do or something that everyone thinks about when they open PR etc
2892020-12-01T15:07:56 <MarcoFalke> michaelfolkson: The ci does it on every PR
2902020-12-01T15:08:06 <jnewbery> I don't run the fuzzers locally because of the extra overhead of building them. I also expect most bugs except the very shallow ones to be discovered by fuzzers running continuously on dedicated machines.
2912020-12-01T15:08:15 <vasild> hi
2922020-12-01T15:08:19 <sipa> michaelfolkson: i think you need to distintuish between "writing fuzzers" and ",running fuzzers"
2932020-12-01T15:08:20 <michaelfolkson> Presumably say the P2P experts should also think about what should be fuzzed in a P2P contexts
2942020-12-01T15:08:37 <MarcoFalke> sipa: and "generating seeds"
2952020-12-01T15:08:40 <michaelfolkson> sipa: Right, could discuss both
2962020-12-01T15:08:43 <sipa> running fuzzers is something everyone can do
2972020-12-01T15:09:08 <sipa> writing fuzzers... that's just one way among dozens of how you can increasy confidence in code you're writing
2982020-12-01T15:09:15 *** Limnoria1 <Limnoria1!~Limnoria@195.140.213.38> has joined #bitcoin-core-dev
2992020-12-01T15:09:26 <sipa> up to the author and what people believe is important in that context
3002020-12-01T15:09:40 <michaelfolkson> Should we be thinking about writing fuzzers in the same way as we do writing unit tests and writing functional tests? Everybody should be thinking about adding them? Or just the fuzz test experts/team
3012020-12-01T15:10:04 <michaelfolkson> I guess that's my question on the writing them side
3022020-12-01T15:10:24 <michaelfolkson> And then on the running them side it is how do we get more people to run them as part of their workflow
3032020-12-01T15:10:56 <jnewbery> I don't think there's a problem that needs to be solved here
3042020-12-01T15:10:58 <nehan> hi. i found the PR club extremely helpful in learning how to fuzz. i was able to relatively quickly doing it having zero experience with it before.
3052020-12-01T15:11:00 <sipa> obbiously?
3062020-12-01T15:11:01 <MarcoFalke> michaelfolkson: I guess it is up to the author. Not everyone is adding unit tests or functional tests.
3072020-12-01T15:11:40 <sipa> michaelfolkson: again, it's one way among many of increasing confidence incyour code. some things lend themselves well for fuzz testing, others not so much
3082020-12-01T15:11:47 *** filchef <filchef!~filchef@212.104.97.177> has joined #bitcoin-core-dev
3092020-12-01T15:12:23 <michaelfolkson> MarcoFalke: Not everyone is but everyone should at least be considering whether to or not. Right?
3102020-12-01T15:12:35 <MarcoFalke> michaelfolkson: Ideally, yes
3112020-12-01T15:13:26 <michaelfolkson> Ok thanks, that's helpful
3122020-12-01T15:13:46 *** tralfaz is now known as davterra
3132020-12-01T15:13:49 <jnewbery> any other topics?
3142020-12-01T15:13:53 <michaelfolkson> I think the jnewbery point on what should be done on dedicated machines is something I have also wondered
3152020-12-01T15:14:09 <sipa> michaelfolkson: run the fuzzers
3162020-12-01T15:14:10 <ariard> a short note on state of tx-pinning/package-relay and discussion on the LN-side?
3172020-12-01T15:14:15 <sipa> like our CI runs the tests
3182020-12-01T15:14:22 <MarcoFalke> michaelfolkson: ./test/fuzz/test_runner.py --help
3192020-12-01T15:15:04 <MarcoFalke> anyone can do it. It supports single run (ci) and generation (long running)
3202020-12-01T15:15:37 <jnewbery> #topic tx pinning / package relay
3212020-12-01T15:15:37 <core-meetingbot> topic: tx pinning / package relay
3222020-12-01T15:15:48 <ariard> so we had this discussion few irc meeting ago with LN devs
3232020-12-01T15:16:02 <ariard> we found yet-another case of tx-pinning after the new anchor spec
3242020-12-01T15:16:07 <ariard> https://github.com/lightningnetwork/lightning-rfc/pull/803
3252020-12-01T15:16:26 <ariard> we would like to demo the attack actually explained here: https://github.com/t-bast/lightning-docs/blob/master/pinning-attacks.md
3262020-12-01T15:16:49 <ariard> before to know exactly what we would be cool to ask as a change on the p2p layer
3272020-12-01T15:17:06 <ariard> so right now I'm spending time hacking with RL to have the necessary toolchain
3282020-12-01T15:17:11 <ariard> and that's all :)
3292020-12-01T15:17:33 <ariard> *the attacks, we have multiple scenarios
3302020-12-01T15:17:43 <glozow> what's the SIGHASH_SINGLE malleability? sorry i'm unfamiliar
3312020-12-01T15:18:09 <sipa> RL?
3322020-12-01T15:18:17 <fanquake> rust lightning
3332020-12-01T15:18:24 <sipa> ah.
3342020-12-01T15:18:50 <ariard> glozow: it lets you sign only the index of the output, thus adding any output without cooperation of your LN counterparty (IIRC)
3352020-12-01T15:19:14 <jnewbery> glozow: https://bitcoinops.org/en/newsletters/2020/09/16/#stealing-onchain-fees-from-ln-htlcs
3362020-12-01T15:19:24 <michaelfolkson> And by case of tx-pinning you mean another scenario in Lightning where tx pinning is a problem. Rather than a new way to tx pin in Core
3372020-12-01T15:19:40 <sipa> glozow: all sighash modes are effecrively *intentional* malleability, they're there so soke tgings can be changed in a tx without affecting the sig
3382020-12-01T15:20:08 <ariard> michaelfolkson: yes we discovered another vulnerability but it wasn't mentinonned on the ML
3392020-12-01T15:20:23 <glozow> ahhhh thanks
3402020-12-01T15:20:40 <ariard> michaelfolkson: note also that pinning doesn't only affect LN but also bitcoin protocol like vaults, DLC
3412020-12-01T15:20:45 <nehan> nit ariard: I don't think you should use the term "split brains" to describe differing mempools. as you point out in the doc, mempools are different *by design*. saying it's a "split brain" implies there should be an unsplit (single) brain.
3422020-12-01T15:21:13 <nehan> ariard: "split brain" is usually used to describe a temporary network partition in distributed systems.
3432020-12-01T15:21:16 <ariard> nehan: thanks, I think the expression is from zeeman and was just reused at it is by t-bast
3442020-12-01T15:21:21 <michaelfolkson> So the messaging is like tx pinning should be even more of a priority to solve in Core than we already knew it was
3452020-12-01T15:21:39 *** miketwen_ <miketwen_!~miketwent@ec2-52-207-61-44.compute-1.amazonaws.com> has joined #bitcoin-core-dev
3462020-12-01T15:21:48 <sipa> i don't think it can be solved in general
3472020-12-01T15:21:50 <ariard> nehan: I think I used mempool-partition to describe the same phenomena but if you have a better distributed system expression?
3482020-12-01T15:22:24 <nehan> ariard: not off the top of my head! will think about it.
3492020-12-01T15:22:48 <jnewbery> inconsistent mempools
3502020-12-01T15:22:49 <ariard> sipa: define general ? if you mean for any bitcoin protocol without care of protocol designer I likely agree with you
3512020-12-01T15:24:11 <ariard> michaelfolkson: note that cdecker proposed a new tx-relay overlay to solve pinning instead of change to p2p tx-relay
3522020-12-01T15:24:25 *** miketwenty1 <miketwenty1!~miketwent@136.55.84.49> has quit IRC (Ping timeout: 240 seconds)
3532020-12-01T15:24:38 <sipa> ariard: i think dos protection will always result in an inability to accept transactions in some scenarios where that transaction would have been accepted from p2p in another state
3542020-12-01T15:24:44 *** someone235 <someone235!uid419897@gateway/web/irccloud.com/x-xrruhlejkwndamue> has quit IRC (Quit: Connection closed for inactivity)
3552020-12-01T15:25:13 <sipa> we can reduce the set of situations under which that can happen using better algorithms
3562020-12-01T15:25:40 <sipa> but the problem in a generic sense seems inherent
3572020-12-01T15:25:48 <michaelfolkson> ariard: So that would potentially be run by the Core nodes that care about Lightning? And the Core nodes that don't care wouldn't run it
3582020-12-01T15:25:49 <ariard> sipa: yes I agree on this! I describe such scenario here https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-June/002758.html (the 3rd one)
3592020-12-01T15:26:28 <ariard> but for the other something like RBF-package relay _or_ rejecting low-fee pinning transaction might be a solution
3602020-12-01T15:26:48 <sipa> ariard: my poijt is you'll always be able to find more things like that
3612020-12-01T15:27:29 <sipa> and no solution (that doesn't introduce DOs attacks) is going to leave (possibly complicated) forms of pinning enabled
3622020-12-01T15:28:24 <sipa> if it's only speaking forms of pinning that pose problems to you then it'd be good to know what those are
3632020-12-01T15:28:31 <ariard> ariard: I don't understand fully your last sentence, if you mean we'll always have complicated cases of pinning I agree?
3642020-12-01T15:28:45 <sipa> yes
3652020-12-01T15:29:04 <sipa> ok, then we agree :)
3662020-12-01T15:29:22 <ariard> okay so we agree on this, what I'm more interested to solve are the easy-to-execute pinning describe as scenario 1) and 2) in my june mail
3672020-12-01T15:29:49 <michaelfolkson> All pinning is a problem. There are no specific forms of pinning that are particularly problematic I think...
3682020-12-01T15:30:16 <ariard> to mitigate more complicated scenario we had this disccusion with matt about redundant tx-relay broadcast, but that's outside the tx-relay model
3692020-12-01T15:31:03 <ariard> michaelfolkson: not all the pinning have the same level of difficulty :) I invite you to read this mail https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-June/002758.html
3702020-12-01T15:31:08 <sipa> redundant as in LN would do relay?
3712020-12-01T15:31:19 <sipa> or something else!
3722020-12-01T15:31:20 <sipa> ?
3732020-12-01T15:31:23 <cdecker> Notice that the alternative transport over the lightning overlay is not intended to be a complete solution, just reduce the effectiveness of pinning by making it less likely to succeed
3742020-12-01T15:31:32 <ariard> like some broadcast your transaction over DNS or radio :)
3752020-12-01T15:31:56 <sipa> oh
3762020-12-01T15:32:50 <sipa> i was hoping LN, because it's an inherently different situation than bitcoin's identityless P2P
3772020-12-01T15:32:53 <ariard> like it's easy to pin a LN transaction if you know the full-node, but if this victim has another entry point to the p2p network you won't succeed
3782020-12-01T15:33:25 <ariard> sipa: yes, we had this discussion about embedding transaction in LN's onion, it does fit in the standard onion size
3792020-12-01T15:33:41 <ariard> more you have redundant tx-relay network, better you're :)
3802020-12-01T15:34:06 <sipa> better you're what?
3812020-12-01T15:34:25 <ariard> harder it is for an attacker to jam with your tx-relay
3822020-12-01T15:34:57 <jnewbery> "the more redundant networks you have, the better off you are"
3832020-12-01T15:35:10 <ariard> cdecker: yeah and it was relying on such lighthning overlay being adopted by miners? or what was the state of the discussion :) ?
3842020-12-01T15:35:28 <sipa> jnewbery: ah thanks
3852020-12-01T15:35:31 <ariard> jnewbery: ah, thanks
3862020-12-01T15:36:13 <ariard> anyway I didn't intend to occupy the spot, I'm working on demoing the tx-pinning LN attack we know about and learn from it
3872020-12-01T15:36:21 <cdecker> Yeah, I was hoping that it'd be attractive for miners to listen to the overlay since the feerate is higher (even though they don't beat absolute fee, which is really not the miner's main motivation)
3882020-12-01T15:37:51 *** Pavlenex <Pavlenex!~Thunderbi@178.220.103.52> has quit IRC (Quit: Pavlenex)
3892020-12-01T15:37:52 <ariard> that might be a way to align incentives, but still I'm not sure miners are great at maintaining an extended software stack
3902020-12-01T15:39:39 <ariard> is anyone wants to do p2p review beg ?
3912020-12-01T15:40:10 <michaelfolkson> What do you mean? You want to discuss the beg process?
3922020-12-01T15:40:22 <michaelfolkson> Or beg for particular PRs?
3932020-12-01T15:40:43 <cdecker> If there's interest from miners to get access I can write up a faux-bitcoin-node that acts as a bridge between bitcoin p2p and the ln overlay relay network
3942020-12-01T15:41:01 <ariard> michaelfolkson: I mean p2p meetings are a nice spot for people to ask for reviews on their PR
3952020-12-01T15:41:11 <michaelfolkson> Ah ok
3962020-12-01T15:41:29 <michaelfolkson> Feel free to beg :)
3972020-12-01T15:41:30 <jnewbery> any other topics?
3982020-12-01T15:41:53 <sipa> gleb: want to mention the erlay bip updates?
3992020-12-01T15:42:02 <gleb> Oh yeah sure.
4002020-12-01T15:42:08 <jnewbery> #topic erlay bip updates
4012020-12-01T15:42:08 <core-meetingbot> topic: erlay bip updates
4022020-12-01T15:42:31 <gleb> So sometimes reconciliation fails initially (first sketch is insufficient, because it's too small and allows to decode up to N differences)
4032020-12-01T15:42:48 <gleb> We then don't give up, but make one more attempt.
4042020-12-01T15:43:24 <gleb> There are 2 ways to make one more attempt while *still being 100% efficient*: bisection and extension. They are independent alternatives.
4052020-12-01T15:43:52 <gleb> We used to do bisection, because it allows to spend a bit less CPU cycles on computing sketches (and just a cool trick I guess)
4062020-12-01T15:44:08 <gleb> In practice, the implementation turned out to be too complicated on the Bitcoin Core p2p protocol side.
4072020-12-01T15:44:34 <gleb> So I switched the code to do sketch extensions instead. It's much less code, and the code complexity is now more aligned with general Bitcoin project complexity.
4082020-12-01T15:44:54 <gleb> And the fact it's a bit more CPU expensive doesn't matter because we expect sketches of very low capacity.
4092020-12-01T15:45:07 <gleb> For more rationale see the updated BIP, lemme give you a link.
4102020-12-01T15:45:16 <gleb> https://github.com/bitcoin/bips/pull/899
4112020-12-01T15:45:26 <sipa> it's also easier to extend to allow doing multiple tikes, if need be
4122020-12-01T15:45:37 <gleb> And it's all in the #18261 now, fully ready for review, please review :)
4132020-12-01T15:45:39 <gribble> https://github.com/bitcoin/bitcoin/issues/18261 | Erlay: bandwidth-efficient transaction relay protocol by naumenkogs · Pull Request #18261 · bitcoin/bitcoin · GitHub
4142020-12-01T15:45:45 <gleb> I'm willing to do any help for review facilitation.
4152020-12-01T15:45:59 <gleb> Including 1-1 sessions over voice chat or something with code walkthrough.
4162020-12-01T15:46:06 <sdaftuar> gleb: sounds good, i will take a look
4172020-12-01T15:46:26 <jnewbery> sipa: I assume you mean 'multiple times'. Why would you want to do that? Is that part of the erlay BIP?
4182020-12-01T15:47:15 <gleb> I don't really see why we'd need more than 1 extra round for now, especially with our transaction volumes and block size :)
4192020-12-01T15:47:15 <sipa> jnewbery: no it's not; the current bip allows for extending exactly once
4202020-12-01T15:47:37 *** Lightlike <Lightlike!b9ff439e@185.255.67.158> has quit IRC (Remote host closed the connection)
4212020-12-01T15:47:47 <sipa> but if we ever determine that doing it multiple times is beneficial, that'd be a trivial change for extending
4222020-12-01T15:47:57 <sipa> but not simple at all for bisection
4232020-12-01T15:48:08 <jnewbery> sipa: makes sense. Thanks
4242020-12-01T15:49:09 <jnewbery> any final topics?
4252020-12-01T15:49:37 <jnewbery> Thanks all!
4262020-12-01T15:49:39 <jnewbery> #endmeeting
4272020-12-01T15:49:39 <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
4282020-12-01T15:49:39 <core-meetingbot> Meeting ended Tue Dec 1 15:49:39 2020 UTC.
4292020-12-01T15:49:39 <core-meetingbot> Minutes: https://bitcoin.jonasschnelli.ch/ircmeetings/logs/bitcoin-core-dev/2020/bitcoin-core-dev.2020-12-01-15.00.moin.txt
4302020-12-01T15:55:29 *** Guyver2_ <Guyver2_!Guyver@guyver2.xs4all.nl> has joined #bitcoin-core-dev
4312020-12-01T15:58:32 *** Guyver2 <Guyver2!Guyver@guyver2.xs4all.nl> has quit IRC (Ping timeout: 256 seconds)
4322020-12-01T16:01:07 *** Guyver2_ is now known as Guyver2
4332020-12-01T16:02:19 *** Pavlenex <Pavlenex!~Thunderbi@178.220.103.52> has joined #bitcoin-core-dev
4342020-12-01T16:02:19 <jnewbery> vasild: if you're still around, I have a question about addrv2 support negotiation. There seems to be a discrepency between the bip and the implementation in Bitcoin Core
4352020-12-01T16:02:39 <vasild> what?
4362020-12-01T16:02:57 <jnewbery> in BIP 155, it says "sendaddrv2 SHOULD be sent after receiving the verack message from the peer": https://github.com/bitcoin/bips/blob/7e3284dafda168da34888977dbf4a55519b0c54d/bip-0155.mediawiki#L137
4372020-12-01T16:03:05 <vasild> "if the documentation and the code disagree, then both are probably wrong"
4382020-12-01T16:03:25 <jnewbery> in the implementation, we send it on receiving the version message: https://github.com/bitcoin/bitcoin/blob/f17e8ba3a17b6516a1b1fb7f45d506a339e99f90/src/net_processing.cpp#L2368
4392020-12-01T16:03:27 *** Pavlenex <Pavlenex!~Thunderbi@178.220.103.52> has quit IRC (Client Quit)
4402020-12-01T16:03:47 <jnewbery> (which may be before the peer has sent verack)
4412020-12-01T16:04:31 <jnewbery> I think ideally, it'd be sent between version and verack, like the wtxidrelay message
4422020-12-01T16:06:24 <vasild> hmm
4432020-12-01T16:06:47 <vasild> they seem to disagree indeed
4442020-12-01T16:09:37 <sdaftuar> that reminds me - i noticed that we send "sendaddrv2" messages to block-relay-only peers. is that intentional or desirable?
4452020-12-01T16:11:05 <vasild> for the implementation it does not matter when sendaddrv2 is sent and received, but I think there were considerations that no messages should be sent before sending verack (and WTXIDRELAY is somehow an exception to this)
4462020-12-01T16:12:10 <sipa> jnewbery: hmm, so really we have in practice two different styles of negotiation (after sending version, and after sending verack), and the bip actually suggests a third (after receiving verack)
4472020-12-01T16:12:17 <vasild> and since it is not necessary to send sendaddrv2 before sending verack I chose to send it after (don't add to the exception of WTXIDRELAY)
4482020-12-01T16:12:34 <jnewbery> if we tie addrv2 to the same p2p version as wtxidrelay (70016) we can change it to send between version and verack
4492020-12-01T16:13:25 <vasild> sdaftuar: it is not intentional
4502020-12-01T16:13:35 <sipa> well, for addrv2 it doesn't matter
4512020-12-01T16:13:46 <jnewbery> sdaftuar: we could skip sending the message to block-relay-only peers, but I don't think it does any harm to send it
4522020-12-01T16:14:05 <sipa> jnewbery, sdaftuar: agree; it seems pointless but harmless
4532020-12-01T16:14:36 <sdaftuar> i guess the ship has sailed on adding a flag to that message to indicate whether we participate in addr relay?
4542020-12-01T16:14:46 <sipa> yes
4552020-12-01T16:15:38 <jnewbery> there are other pointless-but-harmless messages during negotiation. We'll send wtxidrelay and sendaddrv2 to feeler connections before immediately disconnecting
4562020-12-01T16:15:39 <sipa> i'm happy we got bip154 in 0.21, but this isn't the time to change it anymore...
4572020-12-01T16:15:44 <sipa> *bip155
4582020-12-01T16:16:02 <sdaftuar> i'm just trying to figure out what to do with my block-relay-only peer negotiation proposal
4592020-12-01T16:16:22 <sdaftuar> previously i had thoguht about requiring that turning on block-relay-only would turn off addr-relay
4602020-12-01T16:16:38 <vasild> maybe bip155 should be corrected: "sendaddrv2 SHOULD be sent after receiving the verack message" s/receiving/sending/
4612020-12-01T16:16:41 <sdaftuar> but it seemed overly prescriptive in some ways, and addr-relay should perhaps be negotiated separately
4622020-12-01T16:16:57 <sdaftuar> but if we
4632020-12-01T16:17:11 <sdaftuar> but if we're giving up on addr-relay changes now, then perhaps i'll go back to my initial proposal
4642020-12-01T16:17:46 <jnewbery> sdaftuar: is there any benefit in turning off addr relay? We can just ignore any addr messages we get from that peer
4652020-12-01T16:17:46 <sipa> vasild: i think that's the simplest fix
4662020-12-01T16:18:04 <sdaftuar> i think it would helpful for the peer to know it shouldn't relay addresses to us because we're a black hole
4672020-12-01T16:18:11 <sdaftuar> so that it can relay addrs to other peers instead
4682020-12-01T16:18:42 <jnewbery> we already send addrs to light clients, which are addr relay black holes, I think
4692020-12-01T16:18:44 <sdaftuar> seems a shame that "honest" behavior results in somewhat worse addr propagation
4702020-12-01T16:18:49 <sdaftuar> i think that should be fixed or improved as well
4712020-12-01T16:18:52 <vasild> sdaftuar: I think "I participate in addr relay" and "I maintain a usable/complete addr database" should be negotiated/announced separately from sendaddrv2 (I support addrv2 format), even if we could change sendaddrv2 now.
4722020-12-01T16:19:07 <sdaftuar> vasild: worth adding a new p2p message for it?
4732020-12-01T16:19:12 <sdaftuar> we could go that route as well
4742020-12-01T16:19:34 <sdaftuar> i just was afraid that adding more p2p messages seems to raise complaints about the protocol being confusing or redundant
4752020-12-01T16:19:40 <sdaftuar> though it's free
4762020-12-01T16:19:41 <jnewbery> vasild: your suggested change to BIP155 isn't what Bitcoin Core is doing. It sends the message after receiving a version message
4772020-12-01T16:19:59 <sipa> jnewbery: and after sending the verack, no?
4782020-12-01T16:20:34 <jnewbery> sipa: ah yes, you're right.
4792020-12-01T16:20:54 <sipa> sdaftuar: how do you suggest dealing with spv clients being black holes?
4802020-12-01T16:20:57 <jnewbery> do we really want to allow peers to switch from addrv1 to addrv2 at any point?
4812020-12-01T16:21:14 <vasild> sdaftuar: what about introducing one generic message for announcing capabilities, like "I can do X, Y, Z". That idea was shot last time I mentioned it, IIRC...
4822020-12-01T16:21:17 <sipa> jnewbery: we already do, i think
4832020-12-01T16:21:47 <sdaftuar> jnewbery: is there any problem with peers switching from addrv1 to addrv2?
4842020-12-01T16:22:01 <sipa> jnewbery: addrv2 negotiation is really simple, it's just a message indicating "you're as of now allowed to send me addrv2 instead of addrv1"
4852020-12-01T16:22:22 <sdaftuar> sipa: my first thought was that if we allowed peers to opt-in (or out) of addr-relay, then we should just treat spv clients as honest network participants
4862020-12-01T16:22:53 <sipa> sdaftuar: which means?
4872020-12-01T16:23:32 <sdaftuar> if they want to participate in addr-relay, they can; the problem becomes one of software being broken for not implementing a negotiation feature if they don't relay addresses but indicate that they do
4882020-12-01T16:24:17 <sdaftuar> which we can't control anyway
4892020-12-01T16:24:43 <sdaftuar> the problem in my view is that honest software has no way to communicate not to send addr messages because they will get dropped
4902020-12-01T16:26:44 <sipa> sdaftuar: i guess my question is: with this new addr relay negotiation... do you make it "addr relay is by default on for NODE_NETWORK(_LIMITED) peers, off otherwise"
4912020-12-01T16:27:04 <sipa> or something like that, so that old spv software is set off by default
4922020-12-01T16:27:09 <jnewbery> It just seems easier to think about if we don't need to worry about addrv2 support changing during a peer's lifetime. I've had a quick skim of the code and agree that it's simple, but still think that the ability to effectively renegotiate addrv2 support is an unnecessary complexity.
4932020-12-01T16:27:44 <sipa> jnewbery: i agree, but i also think it's a cost we've already paid effectively
4942020-12-01T16:27:47 <sdaftuar> jnewbery: it only goes in one direction right?
4952020-12-01T16:28:03 <sipa> it works
4962020-12-01T16:28:11 <jnewbery> put another way: if we weren't currently able to renegotiate from addrv1 to addrv2 during a peer's lifetime, and I proposed that we added that as a feature, I think the suggestion would be NACKed immediately
4972020-12-01T16:28:25 <sipa> yes
4982020-12-01T16:28:33 <sdaftuar> jnewbery: only because unnecessary changes are, well, unnecessary :)
4992020-12-01T16:28:37 <sipa> but the same may be true in the other direction :)
5002020-12-01T16:29:05 <sipa> making it impossible to renegotiate would need more code, not less
5012020-12-01T16:29:06 <jnewbery> sipa: code complexity isn't a one-off cost. It's an ongoing burden for all current and future contributors
5022020-12-01T16:29:42 <sipa> jnewbery: of course
5032020-12-01T16:29:49 <jnewbery> sipa: no it wouldn't. The spec would say: "send sendaddrv2 between version and verack". Receiving the message at any other time would be ignored
5042020-12-01T16:30:21 <sipa> jnewbery: and right now, it doesn't need code ro decide whether to ignore it or not
5052020-12-01T16:31:00 <sipa> it's all trivial changes of course, but i don't think it's clear cut that one alternative is obviously simpler than the other
5062020-12-01T16:31:27 <jnewbery> sipa: yes, the burden is placed on the developer to audit whether it's safe to make that transition during the peer's lifetime, instead of it just being const
5072020-12-01T16:31:30 <sipa> you might have a point if *all* negotiation were between version and verack, but that's already not the case and won't be
5082020-12-01T16:32:08 <jnewbery> and the burden is also placed on any future developer who makes changes to the way addr relay works, to be aware that addrv2 support can change at any point
5092020-12-01T16:32:18 <sdaftuar> sipa: i think defaulting addr relay to off for non-NODE_NETWORK(_LIMITED) peers would be fine. (or eventually make that the default to give spv client authors sufficient warning, inc ase it's a surprise)
5102020-12-01T16:34:45 <sipa> jnewbery: i agree that's something to keep in mind... but is that really worth changing the code (and spec) for, given that there are several other things that behave in exactly the same way already?
5112020-12-01T16:35:08 <sipa> as opposed to say, add a code comment to clarify addrv2 status can change af any point
5122020-12-01T16:35:27 <sipa> (and sendheaders, and filter status, and ...)
5132020-12-01T16:36:20 <vasild> "send sendaddrv2 between version and verack" --> "send sendaddrv2 between sending version and sending verack" or "send sendaddrv2 between receiving version and receiving verack"
5142020-12-01T16:36:26 <jnewbery> sipa: one or both have to change anyway, and we now know the right way to negotiate features, so if there's another rc, I think we should take advantage of that
5152020-12-01T16:36:58 <sipa> i strongly disagree
5162020-12-01T16:37:07 <sipa> there is no bug here
5172020-12-01T16:37:24 <sipa> the time for something like this has passed
5182020-12-01T16:37:28 <jnewbery> vasild: "send addrv2 between sending version and sending verack"
5192020-12-01T16:37:47 <jnewbery> there's either a bug in the spec or the implementation
5202020-12-01T16:38:03 <sipa> hmm, right
5212020-12-01T16:38:09 <sipa> that's fair
5222020-12-01T16:38:46 <sipa> i was treating it as a typo in the spec, and assuked it was intended to mimick the existing feature negotiations
5232020-12-01T16:39:09 <sipa> and i think because of that, the spec makes no sense
5242020-12-01T16:39:22 <sipa> but you could see it differently
5252020-12-01T16:39:30 <vasild> to me it looks like a bug/typo in the spec and should s/receiving/sending/
5262020-12-01T16:39:39 <sipa> yeah, exactly
5272020-12-01T16:43:53 <jnewbery> I don't think it's worth making an rc for this
5282020-12-01T16:44:17 <vasild> agree
5292020-12-01T16:44:26 *** jeremyrubin <jeremyrubin!~jr@c-73-15-215-148.hsd1.ca.comcast.net> has joined #bitcoin-core-dev
5302020-12-01T16:44:34 <sipa> i think the simplest solution is fixing the spec
5312020-12-01T16:44:52 <jnewbery> I think my preferred change to the spec would be to s/after receiving the verack/after receiving the version/. That means that at least we can send our message between version and verack.
5322020-12-01T16:45:03 <sipa> (not because it mismatches the implementation, but because it appears unintentional)
5332020-12-01T16:45:58 <sipa> does the current 0.21rc code work correctly if it receives addrv2 before verack?
5342020-12-01T16:46:01 <jnewbery> Oh, no we can't because we'll only process a sendaddrv2 after receiving a verack.
5352020-12-01T16:46:08 <jnewbery> sipa: snap
5362020-12-01T16:46:36 <vasild> "does the current 0.21rc code work correctly if it receives addrv2 before verack?" -- yes
5372020-12-01T16:46:53 <jnewbery> vasild: no, we'll drop the message if we receive it before verack
5382020-12-01T16:47:05 *** Pavlenex <Pavlenex!~Thunderbi@178.220.103.52> has joined #bitcoin-core-dev
5392020-12-01T16:47:10 <jnewbery> https://github.com/bitcoin/bitcoin/blob/f17e8ba3a17b6516a1b1fb7f45d506a339e99f90/src/net_processing.cpp#L2538-L2541
5402020-12-01T16:47:40 <jnewbery> It'd be nice if we could consolidate all these feature negotiation messages to one place, but that seems impossible at this point
5412020-12-01T16:47:50 <sipa> oh, i should perhaps hage brought this up during the meeting: should torv3 anchors work in 0.21?
5422020-12-01T16:48:04 <sipa> do we consider that a missing feature or a bug?
5432020-12-01T16:48:06 <vasild> jnewbery: right, sorry
5442020-12-01T16:48:27 <jnewbery> sipa: I'd say missing feature
5452020-12-01T16:49:04 <sipa> jnewbery: i'm beginning to lean in that direction too, and it seems hebasto agrees as well
5462020-12-01T16:49:04 <jnewbery> we didn't have either before v0.21, so people aren't depending on them working together
5472020-12-01T16:49:25 <sipa> yeah, and they're mostly an unobservable feature anyway
5482020-12-01T16:49:53 *** ctrlbreak_MAD <ctrlbreak_MAD!~ctrlbreak@159.2.182.106> has joined #bitcoin-core-dev
5492020-12-01T16:49:59 <vasild> seems like a good thing to "fix" in 0.21.1
5502020-12-01T16:50:19 <vasild> (torv3 anchors)
5512020-12-01T16:51:10 <sipa> vasild: saw #20516?
5522020-12-01T16:51:11 <gribble> https://github.com/bitcoin/bitcoin/issues/20516 | Well-defined CAddress disk serialization, and addrv2 anchors.dat by sipa · Pull Request #20516 · bitcoin/bitcoin · GitHub
5532020-12-01T16:51:30 <vasild> sipa: yes, but did not dive in it yet in order to comment
5542020-12-01T16:51:48 <sipa> sure, no rush
5552020-12-01T16:51:57 <vasild> I did not get it why did you close the other small pr
5562020-12-01T16:52:16 <sipa> vasild: it was intended as a quick fix for 0.21
5572020-12-01T16:52:26 <vasild> it would get torv3 anchors
5582020-12-01T16:52:58 <sipa> not as-is, it needed your patch or 20516 as well
5592020-12-01T16:53:00 <vasild> yes, + the patch I posted in the comments
5602020-12-01T16:53:28 *** ctrlbreak <ctrlbreak!~ctrlbreak@159.2.182.106> has quit IRC (Ping timeout: 265 seconds)
5612020-12-01T16:53:35 <vasild> would the small pr + my patch in the comments cause any trouble for 20516? I think no
5622020-12-01T16:53:51 <sipa> 201516 does exactly the same thing
5632020-12-01T16:53:55 <sipa> just cleaner
5642020-12-01T16:53:58 <sipa> (imo)
5652020-12-01T16:54:22 <sipa> but it's not something i feel is worth it for 0.21 anymore
5662020-12-01T16:54:38 <sipa> so i'd rather do it properly instead in 0.21.1 or 22
5672020-12-01T16:54:53 <vasild> ok
5682020-12-01T16:55:56 <sipa> 20516 makes it also fail deserialization if the on-disk version is unexpected, and adds more tests
5692020-12-01T16:56:11 <sipa> (i wrote that before you commemted with your patch, otherwise i'd have based it on yours)
5702020-12-01T16:58:23 <vasild> aha, since you mention "fail deserialization"...
5712020-12-01T16:59:36 <vasild> should we compare the stream version with ondisk version in CAddress deserialization
5722020-12-01T16:59:52 <vasild> and if one has ADDRV2_FORMAT set but the other does not then throw?
5732020-12-01T17:00:14 <vasild> is this what you mean by "unexpected"?
5742020-12-01T17:00:17 <sipa> that'll break anchors
5752020-12-01T17:00:43 <sipa> once v2 is used for those, but an old anchors.dar is read
5762020-12-01T17:00:44 <vasild> oh, right
5772020-12-01T17:01:25 <sipa> the semantics in 20516 is that the ADDRV2_FORMAT in the stream version enables/disables the use of addrv2 in the disk version
5782020-12-01T17:01:45 <sipa> so you get an error if it is set in the disk version, but not in the stream version, on deserialize
5792020-12-01T17:01:46 <vasild> during serialization?
5802020-12-01T17:02:00 <sipa> but the other direction works
5812020-12-01T17:02:27 <vasild> I see
5822020-12-01T17:03:36 <sipa> i have a follow-up (the serializarion parameter stuff) that just splits all the different serialization types out, and removes ADDRV2_FORMAT from stream versions (but it remains inside the CAddress disk serializer)
5832020-12-01T17:04:03 *** proofofkeags <proofofkeags!~proofofke@174-16-212-53.hlrn.qwest.net> has joined #bitcoin-core-dev
5842020-12-01T17:06:24 *** lightlike <lightlike!~lightlike@p200300c7ef1ab3003906d5c2a9a5021c.dip0.t-ipconnect.de> has joined #bitcoin-core-dev
5852020-12-01T17:07:01 <sipa> unfortunately, that means at least 4 versions
5862020-12-01T17:07:29 <sipa> DISK, NETWORK_NOTIME, NETWORK_V1, NETWORK_V2
5872020-12-01T17:08:39 <sipa> but probably 5; so you have DISK_V1 and DISK_V1_OR_V2 (where pre-v3 addrman would set DISK_V1 which causes an error if a v2 addr on disk is in it)
5882020-12-01T17:13:23 <vasild> :-|
5892020-12-01T17:15:49 <sipa> hmm, maybe we should just remove the "notime" functionality from CAddress
5902020-12-01T17:16:06 *** einyx <einyx!einyx@fsf/member/einyx> has joined #bitcoin-core-dev
5912020-12-01T17:16:09 <sipa> and just invoke it as serializing nServices and CService spearately
5922020-12-01T17:26:10 *** sr_gi <sr_gi!~sr_gi@80.174.218.168.dyn.user.ono.com> has quit IRC (Read error: Connection reset by peer)
5932020-12-01T17:26:31 *** sr_gi <sr_gi!~sr_gi@80.174.218.168.dyn.user.ono.com> has joined #bitcoin-core-dev
5942020-12-01T17:33:02 *** Guyver2_ <Guyver2_!Guyver@guyver2.xs4all.nl> has joined #bitcoin-core-dev
5952020-12-01T17:36:13 *** Guyver2 <Guyver2!Guyver@guyver2.xs4all.nl> has quit IRC (Ping timeout: 264 seconds)
5962020-12-01T17:59:20 *** Talkless <Talkless!~Talkless@mail.dargis.net> has joined #bitcoin-core-dev
5972020-12-01T18:13:01 *** Pavlenex <Pavlenex!~Thunderbi@178.220.103.52> has quit IRC (Quit: Pavlenex)
5982020-12-01T18:19:06 *** kristapsk_ <kristapsk_!~KK@gateway/tor-sasl/kristapsk> has joined #bitcoin-core-dev
5992020-12-01T18:21:03 *** sdaftuar <sdaftuar!~sdaftuar@gateway/tor-sasl/sdaftuar> has quit IRC (Ping timeout: 240 seconds)
6002020-12-01T18:21:04 *** kristapsk <kristapsk!~KK@gateway/tor-sasl/kristapsk> has quit IRC (Ping timeout: 240 seconds)
6012020-12-01T18:23:35 *** sdaftuar <sdaftuar!~sdaftuar@gateway/tor-sasl/sdaftuar> has joined #bitcoin-core-dev
6022020-12-01T18:36:11 *** Randolf <Randolf!~randolf@184.70.10.188> has joined #bitcoin-core-dev
6032020-12-01T18:36:58 *** Tennis <Tennis!~Tennis@unaffiliated/tennis> has quit IRC (Quit: Leaving)
6042020-12-01T18:37:44 *** jonatack <jonatack!~jon@88.124.242.136> has quit IRC (Ping timeout: 272 seconds)
6052020-12-01T18:38:09 *** jonatack <jonatack!~jon@109.232.227.138> has joined #bitcoin-core-dev
6062020-12-01T18:38:58 *** Mercury_Vapor <Mercury_Vapor!~Mercury_V@174-082-166-092.res.spectrum.com> has quit IRC (Quit: Leaving)
6072020-12-01T18:45:50 *** Mercury_Vapor <Mercury_Vapor!~Mercury_V@174-082-166-092.res.spectrum.com> has joined #bitcoin-core-dev
6082020-12-01T18:50:29 *** kexkey <kexkey!~kexkey@static-198-54-132-121.cust.tzulo.com> has joined #bitcoin-core-dev
6092020-12-01T19:05:01 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
6102020-12-01T19:05:01 <bitcoin-git> [bitcoin] sipa opened pull request #20541: Move special CAddress-without-nTime logic to net_processing (master...202012_addr_without_time_is_no_addr) https://github.com/bitcoin/bitcoin/pull/20541
6112020-12-01T19:05:02 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
6122020-12-01T19:05:30 <sipa> vasild: ^
6132020-12-01T19:25:57 *** brianhoffman <brianhoffman!~brianhoff@pool-71-191-34-154.washdc.fios.verizon.net> has joined #bitcoin-core-dev
6142020-12-01T19:34:30 *** lightlike <lightlike!~lightlike@p200300c7ef1ab3003906d5c2a9a5021c.dip0.t-ipconnect.de> has quit IRC (Remote host closed the connection)
6152020-12-01T19:34:48 *** AaronvanW <AaronvanW!~AaronvanW@unaffiliated/aaronvanw> has quit IRC (Remote host closed the connection)
6162020-12-01T19:44:57 *** cltrbreak_MAD2 <cltrbreak_MAD2!~ctrlbreak@159.2.182.106> has joined #bitcoin-core-dev
6172020-12-01T19:48:25 *** ctrlbreak_MAD <ctrlbreak_MAD!~ctrlbreak@159.2.182.106> has quit IRC (Ping timeout: 240 seconds)
6182020-12-01T19:52:00 *** ctrlbreak_MAD <ctrlbreak_MAD!~ctrlbreak@159.2.182.106> has joined #bitcoin-core-dev
6192020-12-01T19:55:25 *** cltrbreak_MAD2 <cltrbreak_MAD2!~ctrlbreak@159.2.182.106> has quit IRC (Ping timeout: 260 seconds)
6202020-12-01T20:20:44 *** Talkless <Talkless!~Talkless@mail.dargis.net> has quit IRC (Quit: Konversation terminated!)
6212020-12-01T20:40:05 *** ctrlbreak_MAD is now known as ctrlbreak
6222020-12-01T20:47:45 *** AaronvanW <AaronvanW!~AaronvanW@unaffiliated/aaronvanw> has joined #bitcoin-core-dev
6232020-12-01T20:47:48 *** ghost43 <ghost43!~daer@gateway/tor-sasl/daer> has quit IRC (Remote host closed the connection)
6242020-12-01T20:49:50 *** ghost43 <ghost43!~daer@gateway/tor-sasl/daer> has joined #bitcoin-core-dev
6252020-12-01T20:57:04 *** Guest19 <Guest19!~textual@78-2-110-233.adsl.net.t-com.hr> has joined #bitcoin-core-dev
6262020-12-01T21:16:56 *** AaronvanW <AaronvanW!~AaronvanW@unaffiliated/aaronvanw> has quit IRC (Ping timeout: 240 seconds)
6272020-12-01T21:39:31 *** Guest19 <Guest19!~textual@78-2-110-233.adsl.net.t-com.hr> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzzâ¦)
6282020-12-01T21:47:59 *** Guyver2__ <Guyver2__!Guyver@guyver2.xs4all.nl> has joined #bitcoin-core-dev
6292020-12-01T21:50:26 *** Guyver2_ <Guyver2_!Guyver@guyver2.xs4all.nl> has quit IRC (Ping timeout: 256 seconds)
6302020-12-01T22:17:31 *** Guyver2__ <Guyver2__!Guyver@guyver2.xs4all.nl> has quit IRC (Quit: Going offline, see ya! (www.adiirc.com))
6312020-12-01T22:30:49 *** bhy <bhy!b0b58536@i15-les02-ntr-176-181-133-54.sfr.lns.abo.bbox.fr> has joined #bitcoin-core-dev
6322020-12-01T22:31:56 *** filchef <filchef!~filchef@212.104.97.177> has quit IRC (Quit: KVIrc 5.0.0 Aria http://www.kvirc.net/)
6332020-12-01T22:33:28 *** bhy <bhy!b0b58536@i15-les02-ntr-176-181-133-54.sfr.lns.abo.bbox.fr> has quit IRC (Remote host closed the connection)
6342020-12-01T22:38:17 *** joelklabo <joelklabo!~textual@108-196-216-127.lightspeed.sntcca.sbcglobal.net> has joined #bitcoin-core-dev
6352020-12-01T23:04:53 *** mrostecki <mrostecki!mrostecki@nat/suse/x-kwnqnqspcazesbuo> has quit IRC (Ping timeout: 272 seconds)
6362020-12-01T23:10:09 <promag> quick question, does it makes sense to limit cookie auth to loopback? anyone using it in other ways?
6372020-12-01T23:14:38 *** AaronvanW <AaronvanW!~AaronvanW@unaffiliated/aaronvanw> has joined #bitcoin-core-dev
6382020-12-01T23:20:07 *** miketwen_ <miketwen_!~miketwent@ec2-52-207-61-44.compute-1.amazonaws.com> has quit IRC ()
6392020-12-01T23:29:36 *** owowo <owowo!~ovovo@unaffiliated/ovovo> has quit IRC (Ping timeout: 256 seconds)
6402020-12-01T23:35:07 *** owowo <owowo!~ovovo@unaffiliated/ovovo> has joined #bitcoin-core-dev
6412020-12-01T23:37:19 *** pinheadmz <pinheadmz!~pinheadmz@71.190.30.138> has quit IRC (Read error: Connection reset by peer)
6422020-12-01T23:38:08 *** pinheadmz <pinheadmz!~pinheadmz@71.190.30.138> has joined #bitcoin-core-dev
6432020-12-01T23:45:45 *** EagleTM <EagleTM!~EagleTM@unaffiliated/eagletm> has quit IRC (Ping timeout: 265 seconds)
6442020-12-01T23:48:16 *** AaronvanW <AaronvanW!~AaronvanW@unaffiliated/aaronvanw> has quit IRC (Ping timeout: 260 seconds)
6452020-12-01T23:55:30 *** AaronvanW <AaronvanW!~AaronvanW@unaffiliated/aaronvanw> has joined #bitcoin-core-dev
6462020-12-01T23:57:31 *** mrostecki <mrostecki!mrostecki@nat/suse/x-oplejjvnaxzshynh> has joined #bitcoin-core-dev