1 2020-12-01T00:36:45  *** Klox04809318631 <Klox04809318631!~Klox@c-24-1-131-19.hsd1.il.comcast.net> has quit IRC (Ping timeout: 240 seconds)
  2 2020-12-01T00:37:22  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
  3 2020-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
  4 2020-12-01T00:37:30  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
  5 2020-12-01T00:38:39  *** Klox04809318631 <Klox04809318631!~Klox@c-24-1-131-19.hsd1.il.comcast.net> has joined #bitcoin-core-dev
  6 2020-12-01T01:06:16  *** mol <mol!~mol@unaffiliated/molly> has quit IRC (Ping timeout: 240 seconds)
  7 2020-12-01T01:13:00  *** da39a3ee5e6b4b0d <da39a3ee5e6b4b0d!~da39a3ee5@mx-ll-171.5.161-165.dynamic.3bb.co.th> has joined #bitcoin-core-dev
  8 2020-12-01T01:18:49  *** proofofkeags <proofofkeags!~proofofke@c-73-34-43-4.hsd1.co.comcast.net> has quit IRC (Ping timeout: 264 seconds)
  9 2020-12-01T01:26:13  *** aGHz_nfb <aGHz_nfb!~aGHz_nfb@185.163.110.116> has quit IRC (Remote host closed the connection)
 10 2020-12-01T01:27:08  *** reallll <reallll!~belcher@unaffiliated/belcher> has joined #bitcoin-core-dev
 11 2020-12-01T01:30:13  *** belcher <belcher!~belcher@unaffiliated/belcher> has quit IRC (Ping timeout: 264 seconds)
 12 2020-12-01T01:39:04  *** ghost43_ <ghost43_!~daer@gateway/tor-sasl/daer> has quit IRC (Remote host closed the connection)
 13 2020-12-01T01:39:21  *** ghost43 <ghost43!~daer@gateway/tor-sasl/daer> has joined #bitcoin-core-dev
 14 2020-12-01T01:40:16  *** lightlike <lightlike!~lightlike@p200300c7ef177a00b8e983ade8f2d04e.dip0.t-ipconnect.de> has quit IRC (Quit: Leaving)
 15 2020-12-01T01:43:44  *** davterra <davterra!~davterra@68.235.43.102> has quit IRC (Quit: Leaving)
 16 2020-12-01T01:46:50  *** EagleTM <EagleTM!~EagleTM@unaffiliated/eagletm> has quit IRC (Ping timeout: 256 seconds)
 17 2020-12-01T01:47:09  *** maop <maop!~maop@195.140.213.38> has joined #bitcoin-core-dev
 18 2020-12-01T01:48:38  *** AaronvanW <AaronvanW!~AaronvanW@unaffiliated/aaronvanw> has quit IRC (Remote host closed the connection)
 19 2020-12-01T01:52:32  *** davterra <davterra!~davterra@68.235.43.174> has joined #bitcoin-core-dev
 20 2020-12-01T02:01:29  *** jesseposner <jesseposner!~jp@2601:643:8980:bfd2:f040:ed44:8391:19d3> has joined #bitcoin-core-dev
 21 2020-12-01T02:10:08  <andytoshi> holy shit the taproot python tests are extensive
 22 2020-12-01T02:10:39  <sipa> :)
 23 2020-12-01T02:13:39  <luke-jr> XD
 24 2020-12-01T02:29:11  *** AaronvanW <AaronvanW!~AaronvanW@unaffiliated/aaronvanw> has joined #bitcoin-core-dev
 25 2020-12-01T02:32:10  *** proofofkeags <proofofkeags!~proofofke@174-16-212-53.hlrn.qwest.net> has joined #bitcoin-core-dev
 26 2020-12-01T02:33:36  *** AaronvanW <AaronvanW!~AaronvanW@unaffiliated/aaronvanw> has quit IRC (Ping timeout: 240 seconds)
 27 2020-12-01T02:42:34  *** mol <mol!~mol@unaffiliated/molly> has joined #bitcoin-core-dev
 28 2020-12-01T02:43:14  *** justanotheruser <justanotheruser!~justanoth@unaffiliated/justanotheruser> has quit IRC (Ping timeout: 264 seconds)
 29 2020-12-01T02:55:16  *** justanotheruser <justanotheruser!~justanoth@unaffiliated/justanotheruser> has joined #bitcoin-core-dev
 30 2020-12-01T04:02:52  *** kristapsk <kristapsk!~KK@gateway/tor-sasl/kristapsk> has quit IRC (Remote host closed the connection)
 31 2020-12-01T04:14:43  *** az0re <az0re!~az0re@gateway/tor-sasl/az0re> has quit IRC (Ping timeout: 240 seconds)
 32 2020-12-01T04:30:52  *** AaronvanW <AaronvanW!~AaronvanW@unaffiliated/aaronvanw> has joined #bitcoin-core-dev
 33 2020-12-01T04:53:57  *** miketwenty1 <miketwenty1!~miketwent@ec2-52-207-61-44.compute-1.amazonaws.com> has quit IRC (Remote host closed the connection)
 34 2020-12-01T04:56:01  *** TheHoliestRoger <TheHoliestRoger!~TheHolies@unaffiliated/theholiestroger> has quit IRC (Quit: Find me in #TheHolyRoger or https://theholyroger.com)
 35 2020-12-01T05:01:22  *** TheHoliestRoger <TheHoliestRoger!~TheHolies@unaffiliated/theholiestroger> has joined #bitcoin-core-dev
 36 2020-12-01T05:03:14  *** AaronvanW <AaronvanW!~AaronvanW@unaffiliated/aaronvanw> has quit IRC (Ping timeout: 256 seconds)
 37 2020-12-01T05:12:36  *** jonatack <jonatack!~jon@82.102.27.171> has quit IRC (Ping timeout: 240 seconds)
 38 2020-12-01T05:15:02  *** jonatack <jonatack!~jon@88.124.242.136> has joined #bitcoin-core-dev
 39 2020-12-01T05:21:11  *** az0re <az0re!~az0re@gateway/tor-sasl/az0re> has joined #bitcoin-core-dev
 40 2020-12-01T05:55:06  *** espiral <espiral!b9edb429@185.237.180.41> has joined #bitcoin-core-dev
 41 2020-12-01T05:55:27  *** maop <maop!~maop@195.140.213.38> has quit IRC (Remote host closed the connection)
 42 2020-12-01T05:59:38  *** espiral <espiral!b9edb429@185.237.180.41> has quit IRC (Remote host closed the connection)
 43 2020-12-01T06:08:17  *** gimps <gimps!~gimps@185.163.110.116> has joined #bitcoin-core-dev
 44 2020-12-01T06:08:25  *** openoms <openoms!~quassel@91.132.136.76> has quit IRC (Read error: Connection reset by peer)
 45 2020-12-01T06:08:41  *** EagleTM <EagleTM!~EagleTM@unaffiliated/eagletm> has joined #bitcoin-core-dev
 46 2020-12-01T06:09:12  *** openoms <openoms!~quassel@91.132.136.76> has joined #bitcoin-core-dev
 47 2020-12-01T06:10:53  *** IGHOR <IGHOR!~quassel@176.121.4.135> has quit IRC (Quit: http://quassel-irc.org ? ??????????? ?????????. ????-??.)
 48 2020-12-01T06:12:03  *** IGHOR <IGHOR!~quassel@176.121.4.135> has joined #bitcoin-core-dev
 49 2020-12-01T06:51:09  *** kristapsk <kristapsk!~KK@gateway/tor-sasl/kristapsk> has joined #bitcoin-core-dev
 50 2020-12-01T06:54:32  *** sdaftuar <sdaftuar!~sdaftuar@gateway/tor-sasl/sdaftuar> has quit IRC (Remote host closed the connection)
 51 2020-12-01T06:55:06  *** sdaftuar <sdaftuar!~sdaftuar@gateway/tor-sasl/sdaftuar> has joined #bitcoin-core-dev
 52 2020-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)
 53 2020-12-01T07:00:18  *** sr_gi <sr_gi!~sr_gi@80.174.218.168.dyn.user.ono.com> has joined #bitcoin-core-dev
 54 2020-12-01T07:00:28  *** AaronvanW <AaronvanW!~AaronvanW@unaffiliated/aaronvanw> has joined #bitcoin-core-dev
 55 2020-12-01T07:06:44  *** Kiminuo <Kiminuo!~mix@141.98.103.172> has joined #bitcoin-core-dev
 56 2020-12-01T07:31:12  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
 57 2020-12-01T07:31:12  <bitcoin-git> [bitcoin] MarcoFalke pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/81d5af42f4db...ffd5e7a8567d
 58 2020-12-01T07:31:13  <bitcoin-git> bitcoin/master 9429a39 practicalswift: Handle rename failure in DumpMempool(...) by using RenameOver(...) return ...
 59 2020-12-01T07:31:13  <bitcoin-git> bitcoin/master ce9dd45 practicalswift: Add [[nodiscard]] to RenameOver(...)
 60 2020-12-01T07:31:14  <bitcoin-git> bitcoin/master ffd5e7a MarcoFalke: Merge #20519: Handle rename failure in DumpMempool(...) by using the Renam...
 61 2020-12-01T07:31:15  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
 62 2020-12-01T07:31:32  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
 63 2020-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
 64 2020-12-01T07:31:33  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
 65 2020-12-01T07:33:59  *** AaronvanW <AaronvanW!~AaronvanW@unaffiliated/aaronvanw> has quit IRC (Ping timeout: 260 seconds)
 66 2020-12-01T08:21:57  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
 67 2020-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
 68 2020-12-01T08:21:58  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
 69 2020-12-01T08:25:34  *** Pavlenex <Pavlenex!~Thunderbi@178.220.103.52> has joined #bitcoin-core-dev
 70 2020-12-01T08:30:13  *** Pavlenex <Pavlenex!~Thunderbi@178.220.103.52> has quit IRC (Client Quit)
 71 2020-12-01T08:30:57  *** Pavlenex <Pavlenex!~Thunderbi@178.220.103.52> has joined #bitcoin-core-dev
 72 2020-12-01T08:34:16  *** Pavlenex <Pavlenex!~Thunderbi@178.220.103.52> has quit IRC (Client Quit)
 73 2020-12-01T08:41:59  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
 74 2020-12-01T08:42:00  <bitcoin-git> [bitcoin] MarcoFalke pushed 4 commits to master: https://github.com/bitcoin/bitcoin/compare/ffd5e7a8567d...24e4857b29b3
 75 2020-12-01T08:42:00  <bitcoin-git> bitcoin/master 12bd0fc Russell Yanofsky: Move NodeImpl from interfaces/node.cpp to node/interfaces.cpp
 76 2020-12-01T08:42:01  <bitcoin-git> bitcoin/master 2a26771 Russell Yanofsky: Move ChainImpl from interfaces/chain.cpp to node/interfaces.cpp
 77 2020-12-01T08:42:02  <bitcoin-git> bitcoin/master 629a929 Russell Yanofsky: Move WalletImpl from interfaces/wallet.cpp to wallet/interfaces.cpp
 78 2020-12-01T08:42:03  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
 79 2020-12-01T08:42:19  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
 80 2020-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
 81 2020-12-01T08:42:20  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
 82 2020-12-01T08:50:09  *** Pavlenex <Pavlenex!~Thunderbi@178.220.103.52> has joined #bitcoin-core-dev
 83 2020-12-01T09:04:07  *** tryphe <tryphe!~tryphe@unaffiliated/tryphe> has joined #bitcoin-core-dev
 84 2020-12-01T09:04:16  *** tryphe_ <tryphe_!~tryphe@unaffiliated/tryphe> has quit IRC (Ping timeout: 240 seconds)
 85 2020-12-01T09:05:06  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
 86 2020-12-01T09:05:06  <bitcoin-git> [bitcoin] MarcoFalke pushed 4 commits to master: https://github.com/bitcoin/bitcoin/compare/24e4857b29b3...cd720337fe9c
 87 2020-12-01T09:05:07  <bitcoin-git> bitcoin/master 9d4b4b2 Elle Mouton: refactor: Avoid double to int cast for nCheckFrequency
 88 2020-12-01T09:05:09  <bitcoin-git> bitcoin/master e331069 Elle Mouton: refactor: Make CTxMemPool::m_check_ratio a const and a constructor argumen...
 89 2020-12-01T09:05:09  <bitcoin-git> bitcoin/master f15e780 Elle Mouton: refactor: Clean up CTxMemPool initializer list
 90 2020-12-01T09:05:10  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
 91 2020-12-01T09:05:25  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
 92 2020-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
 93 2020-12-01T09:05:27  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
 94 2020-12-01T09:19:44  *** Guyver2 <Guyver2!Guyver@guyver2.xs4all.nl> has joined #bitcoin-core-dev
 95 2020-12-01T09:24:28  *** BGL <BGL!~twenty@75-149-171-58-Washington.hfc.comcastbusiness.net> has quit IRC (Ping timeout: 256 seconds)
 96 2020-12-01T09:31:19  *** AaronvanW <AaronvanW!~AaronvanW@unaffiliated/aaronvanw> has joined #bitcoin-core-dev
 97 2020-12-01T09:47:51  *** Victorsueca <Victorsueca!~Victorsue@unaffiliated/victorsueca> has joined #bitcoin-core-dev
 98 2020-12-01T09:59:38  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
 99 2020-12-01T09:59:38  <bitcoin-git> [bitcoin] jonasschnelli pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/cd720337fe9c...f2a673f15b51
100 2020-12-01T09:59:38  <bitcoin-git> bitcoin/master 86b1ab6 Hennadii Stepanov: refactor: Replace deprecated Qt::SystemLocale{Short,Long}Date
101 2020-12-01T09:59:39  <bitcoin-git> bitcoin/master f2a673f Jonas Schnelli: Merge bitcoin-core/gui#137: refactor: Replace deprecated Qt::SystemLocale{...
102 2020-12-01T09:59:40  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
103 2020-12-01T09:59:58  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
104 2020-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
105 2020-12-01T09:59:59  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
106 2020-12-01T10:02:33  *** vasild <vasild!~vd@gateway/tor-sasl/vasild> has quit IRC (Quit: leaving)
107 2020-12-01T10:03:49  *** AaronvanW <AaronvanW!~AaronvanW@unaffiliated/aaronvanw> has quit IRC (Ping timeout: 264 seconds)
108 2020-12-01T10:03:56  *** kexkey <kexkey!~kexkey@static-198-54-132-105.cust.tzulo.com> has quit IRC (Ping timeout: 240 seconds)
109 2020-12-01T10:07:47  *** Tennis <Tennis!~Tennis@unaffiliated/tennis> has joined #bitcoin-core-dev
110 2020-12-01T10:16:03  *** AaronvanW <AaronvanW!~AaronvanW@unaffiliated/aaronvanw> has joined #bitcoin-core-dev
111 2020-12-01T10:18:03  *** ghost43 <ghost43!~daer@gateway/tor-sasl/daer> has quit IRC (Ping timeout: 240 seconds)
112 2020-12-01T10:18:51  *** ghost43 <ghost43!~daer@gateway/tor-sasl/daer> has joined #bitcoin-core-dev
113 2020-12-01T10:22:41  *** AaronvanW <AaronvanW!~AaronvanW@unaffiliated/aaronvanw> has quit IRC (Remote host closed the connection)
114 2020-12-01T10:22:58  *** AaronvanW <AaronvanW!~AaronvanW@unaffiliated/aaronvanw> has joined #bitcoin-core-dev
115 2020-12-01T10:23:57  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
116 2020-12-01T10:23:58  <bitcoin-git> [bitcoin] jonasschnelli pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/f2a673f15b51...335d27d08141
117 2020-12-01T10:23:58  <bitcoin-git> bitcoin/master 1d578c0 Emil Engler: doc: Add bash as an OpenBSD dependency
118 2020-12-01T10:23:58  <bitcoin-git> bitcoin/master 335d27d Jonas Schnelli: Merge #20512: doc: Add bash as an OpenBSD dependency
119 2020-12-01T10:24:00  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
120 2020-12-01T10:24:17  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
121 2020-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
122 2020-12-01T10:24:18  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
123 2020-12-01T10:27:45  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
124 2020-12-01T10:27:46  <bitcoin-git> [bitcoin] jonasschnelli pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/335d27d08141...dcb7518067cd
125 2020-12-01T10:27:46  <bitcoin-git> bitcoin/master 65afe4c Hennadii Stepanov: build: Drop unneeded ApplicationServices framework dependency
126 2020-12-01T10:27:47  <bitcoin-git> bitcoin/master ec4a46d Hennadii Stepanov: build: Drop unneeded IOKit framework dependency
127 2020-12-01T10:27:47  <bitcoin-git> bitcoin/master dcb7518 Jonas Schnelli: Merge #20496: build: Drop unneeded macOS framework dependencies
128 2020-12-01T10:27:49  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
129 2020-12-01T10:28:05  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
130 2020-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
131 2020-12-01T10:28:06  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
132 2020-12-01T10:28:21  *** kljasdfvv <kljasdfvv!~flack@p200300d46f24de00fb39606f311c9ef9.dip0.t-ipconnect.de> has joined #bitcoin-core-dev
133 2020-12-01T10:29:00  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
134 2020-12-01T10:29:00  <bitcoin-git> [bitcoin] jonasschnelli pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/dcb7518067cd...277c225b8421
135 2020-12-01T10:29:01  <bitcoin-git> bitcoin/master 982e548 Jonas Schnelli: Don't set BDB flags when configuring without
136 2020-12-01T10:29:01  <bitcoin-git> bitcoin/master 277c225 Jonas Schnelli: Merge #20478: Don't set BDB flags when configuring without
137 2020-12-01T10:29:03  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
138 2020-12-01T10:29:20  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
139 2020-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
140 2020-12-01T10:29:21  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
141 2020-12-01T10:33:01  *** vasild <vasild!~vd@gateway/tor-sasl/vasild> has joined #bitcoin-core-dev
142 2020-12-01T10:34:11  *** vasild <vasild!~vd@gateway/tor-sasl/vasild> has quit IRC (Client Quit)
143 2020-12-01T10:35:47  *** vasild <vasild!~vd@gateway/tor-sasl/vasild> has joined #bitcoin-core-dev
144 2020-12-01T10:41:01  *** proofofkeags <proofofkeags!~proofofke@174-16-212-53.hlrn.qwest.net> has quit IRC (Ping timeout: 260 seconds)
145 2020-12-01T10:44:02  *** vasild <vasild!~vd@gateway/tor-sasl/vasild> has quit IRC (Disconnected by services)
146 2020-12-01T10:44:03  *** vasild_ <vasild_!~vd@gateway/tor-sasl/vasild> has joined #bitcoin-core-dev
147 2020-12-01T10:44:33  *** reallll is now known as belcher
148 2020-12-01T10:48:24  *** Pavlenex <Pavlenex!~Thunderbi@178.220.103.52> has quit IRC (Quit: Pavlenex)
149 2020-12-01T11:03:14  *** Kiminuo <Kiminuo!~mix@141.98.103.172> has quit IRC (Quit: Leaving)
150 2020-12-01T11:18:31  *** Josiane57Wyman <Josiane57Wyman!~Josiane57@static.57.1.216.95.clients.your-server.de> has joined #bitcoin-core-dev
151 2020-12-01T11:31:38  *** jeremyrubin <jeremyrubin!~jr@c-73-15-215-148.hsd1.ca.comcast.net> has quit IRC (Ping timeout: 256 seconds)
152 2020-12-01T11:34:54  *** Josiane57Wyman <Josiane57Wyman!~Josiane57@static.57.1.216.95.clients.your-server.de> has quit IRC (Ping timeout: 260 seconds)
153 2020-12-01T11:55:43  *** vasild_ <vasild_!~vd@gateway/tor-sasl/vasild> has quit IRC (Ping timeout: 240 seconds)
154 2020-12-01T11:59:36  *** vasild <vasild!~vd@gateway/tor-sasl/vasild> has joined #bitcoin-core-dev
155 2020-12-01T12:02:58  *** BGL <BGL!~twenty@75-149-171-58-Washington.hfc.comcastbusiness.net> has joined #bitcoin-core-dev
156 2020-12-01T12:11:11  *** Pavlenex <Pavlenex!~Thunderbi@178.220.103.52> has joined #bitcoin-core-dev
157 2020-12-01T12:25:28  *** gimps <gimps!~gimps@185.163.110.116> has quit IRC (Remote host closed the connection)
158 2020-12-01T12:39:44  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
159 2020-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
160 2020-12-01T12:39:45  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
161 2020-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…)
162 2020-12-01T13:06:39  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
163 2020-12-01T13:06:39  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/277c225b8421...dfd0b700886c
164 2020-12-01T13:06:40  <bitcoin-git> bitcoin/master 17a5f17 practicalswift: fuzz: Make addrman fuzzing harness deterministic
165 2020-12-01T13:06:40  <bitcoin-git> bitcoin/master dfd0b70 MarcoFalke: Merge #20425: fuzz: Make CAddrMan fuzzing harness deterministic
166 2020-12-01T13:06:42  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
167 2020-12-01T13:06:54  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
168 2020-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
169 2020-12-01T13:06:55  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
170 2020-12-01T13:14:23  *** ghost43 <ghost43!~daer@gateway/tor-sasl/daer> has quit IRC (Ping timeout: 240 seconds)
171 2020-12-01T13:15:50  *** ghost43 <ghost43!~daer@gateway/tor-sasl/daer> has joined #bitcoin-core-dev
172 2020-12-01T13:24:24  *** luke-jr <luke-jr!~luke-jr@unaffiliated/luke-jr> has quit IRC (Read error: Connection reset by peer)
173 2020-12-01T13:24:37  <MarcoFalke> michaelfolkson: Let's take this here
174 2020-12-01T13:25:56  <michaelfolkson> MarcoFalke: Sure, thanks
175 2020-12-01T13:26:30  *** luke-jr <luke-jr!~luke-jr@unaffiliated/luke-jr> has joined #bitcoin-core-dev
176 2020-12-01T13:27:00  <michaelfolkson> I think I'm misunderstanding terminology. So seeds will be randomly generated...
177 2020-12-01T13:28:35  <MarcoFalke> Some fuzz engines have command line switches to make them deterministic
178 2020-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
179 2020-12-01T13:29:03  <MarcoFalke> yes
180 2020-12-01T13:29:20  <MarcoFalke> if you can't reproduce, it will be hard to debug and fix
181 2020-12-01T13:29:49  *** da39a3ee5e6b4b0d <da39a3ee5e6b4b0d!~da39a3ee5@2403:6200:8876:9156:59b2:2700:3dd:eb69> has joined #bitcoin-core-dev
182 2020-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?
183 2020-12-01T13:31:20  <michaelfolkson> It is surely a logging issue rather than a choice of deterministic/random?
184 2020-12-01T13:32:44  <MarcoFalke> int main() { if (rand() > 2) crash(); }
185 2020-12-01T13:33:09  <MarcoFalke> how would you reliably reproduce a crash here, knowing the input?
186 2020-12-01T13:33:48  <MarcoFalke> how the input was generated is irrelevant to how to reproduce a bug
187 2020-12-01T13:34:41  <MarcoFalke> logging helps to debug intermittent (non-reproducible) bugs better
188 2020-12-01T13:35:05  <MarcoFalke> we have a lot of them, which is why logging is cranked up in all tests
189 2020-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
190 2020-12-01T13:37:36  <michaelfolkson> But how the fuzz tester initially generated 3 is irrelevant. It could have been deterministic or random
191 2020-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
192 2020-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?
193 2020-12-01T13:41:02  <MarcoFalke> whether the above example crashes is *independent* of the input
194 2020-12-01T13:41:25  <MarcoFalke> the progam takes no input, assuming that rand will ask the OS for randomness
195 2020-12-01T13:42:44  <MarcoFalke> and in most cases the OS randomness is not reproducible
196 2020-12-01T13:43:03  <michaelfolkson> And the problem is that we don't log what the OS supplied for randomness?
197 2020-12-01T13:43:37  <MarcoFalke> the problem is that we ask the os for randomness
198 2020-12-01T13:44:05  <MarcoFalke> tests should supply the randomness. Either with a hardcoded seed or letting the fuzz engine pick one
199 2020-12-01T13:44:35  <michaelfolkson> Ah so the problem is an external source of randomness rather than an internal source from within the tests
200 2020-12-01T13:45:03  <michaelfolkson> It is still random but it is generated within the tests
201 2020-12-01T13:45:04  <MarcoFalke> as long as the source is reproducible/deterministic, it can be from anywhere
202 2020-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
203 2020-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
204 2020-12-01T13:46:59  *** luke-jr <luke-jr!~luke-jr@unaffiliated/luke-jr> has quit IRC (Read error: Connection reset by peer)
205 2020-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
206 2020-12-01T13:47:59  *** luke-jr <luke-jr!~luke-jr@unaffiliated/luke-jr> has joined #bitcoin-core-dev
207 2020-12-01T13:48:20  *** luke-jr <luke-jr!~luke-jr@unaffiliated/luke-jr> has quit IRC (Read error: Connection reset by peer)
208 2020-12-01T13:49:06  *** einyx <einyx!einyx@fsf/member/einyx> has quit IRC (Ping timeout: 256 seconds)
209 2020-12-01T13:49:38  *** luke-jr <luke-jr!~luke-jr@unaffiliated/luke-jr> has joined #bitcoin-core-dev
210 2020-12-01T13:50:10  <MarcoFalke> yes, when "s/time/program execution/"
211 2020-12-01T13:50:34  <michaelfolkson> Gotcha. Thanks!
212 2020-12-01T13:51:33  <michaelfolkson> How would you explain what a fuzzing "harness" is?
213 2020-12-01T13:51:43  *** vasild <vasild!~vd@gateway/tor-sasl/vasild> has quit IRC (Ping timeout: 240 seconds)
214 2020-12-01T13:53:30  <MarcoFalke> a test case or one test target
215 2020-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/
216 2020-12-01T13:54:59  <michaelfolkson> Ok thanks for the help
217 2020-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.
218 2020-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
219 2020-12-01T14:02:19  *** Lightlike <Lightlike!b9ff439e@185.255.67.158> has joined #bitcoin-core-dev
220 2020-12-01T14:04:03  *** untwisted <untwisted!~untwisted@84.39.117.57> has joined #bitcoin-core-dev
221 2020-12-01T14:05:33  *** Lightlike <Lightlike!b9ff439e@185.255.67.158> has left #bitcoin-core-dev
222 2020-12-01T14:08:50  *** vasild <vasild!~vd@gateway/tor-sasl/vasild> has joined #bitcoin-core-dev
223 2020-12-01T14:14:10  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
224 2020-12-01T14:14:11  <bitcoin-git> [bitcoin] MarcoFalke pushed 9 commits to master: https://github.com/bitcoin/bitcoin/compare/dfd0b700886c...f17e8ba3a17b
225 2020-12-01T14:14:11  <bitcoin-git> bitcoin/master 18246ed Pieter Wuille: Fix and improve taproot_construct comments
226 2020-12-01T14:14:12  <bitcoin-git> bitcoin/master cdf900c Pieter Wuille: Document need_vin_vout_mismatch argument to make_spender
227 2020-12-01T14:14:12  <bitcoin-git> bitcoin/master 8dbb7de Pieter Wuille: Add comments to VerifyTaprootCommitment
228 2020-12-01T14:14:13  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
229 2020-12-01T14:14:30  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
230 2020-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
231 2020-12-01T14:14:32  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
232 2020-12-01T14:28:48  <michaelfolkson> How does one do that jnewbery? Just manually edit that dev wiki page?
233 2020-12-01T14:30:58  *** promag <promag!~promag@188.250.84.129> has quit IRC (Ping timeout: 246 seconds)
234 2020-12-01T14:43:52  *** luke-jr <luke-jr!~luke-jr@unaffiliated/luke-jr> has quit IRC (Read error: Connection reset by peer)
235 2020-12-01T14:45:04  *** luke-jr <luke-jr!~luke-jr@unaffiliated/luke-jr> has joined #bitcoin-core-dev
236 2020-12-01T14:45:23  *** promag <promag!~promag@188.250.84.129> has joined #bitcoin-core-dev
237 2020-12-01T14:48:25  *** untwisted <untwisted!~untwisted@84.39.117.57> has quit IRC (Remote host closed the connection)
238 2020-12-01T14:48:59  *** luke-jr <luke-jr!~luke-jr@unaffiliated/luke-jr> has quit IRC (Excess Flood)
239 2020-12-01T14:50:24  *** luke-jr <luke-jr!~luke-jr@unaffiliated/luke-jr> has joined #bitcoin-core-dev
240 2020-12-01T14:51:27  *** mol_ <mol_!~mol@unaffiliated/molly> has joined #bitcoin-core-dev
241 2020-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)
242 2020-12-01T14:54:04  <jnewbery> michaelfolkson: yes, just edit the page
243 2020-12-01T14:54:30  *** mol <mol!~mol@unaffiliated/molly> has quit IRC (Ping timeout: 256 seconds)
244 2020-12-01T14:56:26  *** luke-jr <luke-jr!~luke-jr@unaffiliated/luke-jr> has quit IRC (Excess Flood)
245 2020-12-01T14:56:49  *** luke-jr <luke-jr!~luke-jr@unaffiliated/luke-jr> has joined #bitcoin-core-dev
246 2020-12-01T14:59:48  *** tralfaz <tralfaz!~davterra@68.235.43.158> has joined #bitcoin-core-dev
247 2020-12-01T15:00:16  *** glozow <glozow!uid453516@gateway/web/irccloud.com/x-suaydrfreocgdkkl> has joined #bitcoin-core-dev
248 2020-12-01T15:00:18  <jnewbery> #startmeeting
249 2020-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.
250 2020-12-01T15:00:18  <core-meetingbot> Available commands: action commands idea info link nick
251 2020-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
252 2020-12-01T15:00:36  *** sturles <sturles!~sturles@gufseplassen00.slxdrift.no> has joined #bitcoin-core-dev
253 2020-12-01T15:00:40  <jnewbery> amiti fjahr jeremyrubin lightlike emilengler jonatack hebasto jb55 elichai2
254 2020-12-01T15:01:08  <glozow> hi
255 2020-12-01T15:01:09  <sipa> hi
256 2020-12-01T15:01:14  <gleb> hi
257 2020-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…)
258 2020-12-01T15:01:35  <ariard> hi
259 2020-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
260 2020-12-01T15:01:38  <wumpus> hi
261 2020-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
262 2020-12-01T15:01:41  <ajonas> Hi
263 2020-12-01T15:01:44  <michaelfolkson> hi
264 2020-12-01T15:02:00  <jnewbery> anyone have any proposed topics, or anything they want to share with the group?
265 2020-12-01T15:02:06  *** Lightlike <Lightlike!b9ff439e@185.255.67.158> has joined #bitcoin-core-dev
266 2020-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
267 2020-12-01T15:03:16  <jnewbery> #topic p2p fuzzing
268 2020-12-01T15:03:17  <core-meetingbot> topic: p2p fuzzing
269 2020-12-01T15:03:34  *** davterra <davterra!~davterra@68.235.43.174> has quit IRC (Ping timeout: 256 seconds)
270 2020-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 :)
271 2020-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.
272 2020-12-01T15:03:51  <fanquake> hi
273 2020-12-01T15:04:11  <michaelfolkson> Ok so it is a basic understanding issue?
274 2020-12-01T15:04:11  *** miketwenty1 <miketwenty1!~miketwent@136.55.84.49> has joined #bitcoin-core-dev
275 2020-12-01T15:04:16  <gleb> i think so.
276 2020-12-01T15:04:22  <michaelfolkson> Don't really get what it is trying to do
277 2020-12-01T15:04:39  <sipa> find bugs
278 2020-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
279 2020-12-01T15:05:12  <jnewbery> they contain lots of references to further reading for anyone who's curious
280 2020-12-01T15:05:24  <ariard> you can start with the docs of AFL/libfuzzer/hongfuzz and look for talk of their authors :)
281 2020-12-01T15:05:29  <sipa> michaelfolkson: what do you mean by p2p fuzzing btw?
282 2020-12-01T15:05:43  <MarcoFalke> there are already p2p fuzzers
283 2020-12-01T15:06:18  <emzy> Hi
284 2020-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
285 2020-12-01T15:06:29  <michaelfolkson> (I think)
286 2020-12-01T15:06:41  <MarcoFalke> I am working on increasing their coverage
287 2020-12-01T15:07:03  <ariard> IIRC practicalswift added coverage for a part of the p2p stack a while ago ?
288 2020-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
289 2020-12-01T15:07:56  <MarcoFalke> michaelfolkson: The ci does it on every PR
290 2020-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.
291 2020-12-01T15:08:15  <vasild> hi
292 2020-12-01T15:08:19  <sipa> michaelfolkson: i think you need to distintuish between "writing fuzzers" and ",running fuzzers"
293 2020-12-01T15:08:20  <michaelfolkson> Presumably say the P2P experts should also think about what should be fuzzed in a P2P contexts
294 2020-12-01T15:08:37  <MarcoFalke> sipa: and "generating seeds"
295 2020-12-01T15:08:40  <michaelfolkson> sipa: Right, could discuss both
296 2020-12-01T15:08:43  <sipa> running fuzzers is something everyone can do
297 2020-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
298 2020-12-01T15:09:15  *** Limnoria1 <Limnoria1!~Limnoria@195.140.213.38> has joined #bitcoin-core-dev
299 2020-12-01T15:09:26  <sipa> up to the author and what people believe is important in that context
300 2020-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
301 2020-12-01T15:10:04  <michaelfolkson> I guess that's my question on the writing them side
302 2020-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
303 2020-12-01T15:10:56  <jnewbery> I don't think there's a problem that needs to be solved here
304 2020-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.
305 2020-12-01T15:11:00  <sipa> obbiously?
306 2020-12-01T15:11:01  <MarcoFalke> michaelfolkson: I guess it is up to the author. Not everyone is adding unit tests or functional tests.
307 2020-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
308 2020-12-01T15:11:47  *** filchef <filchef!~filchef@212.104.97.177> has joined #bitcoin-core-dev
309 2020-12-01T15:12:23  <michaelfolkson> MarcoFalke: Not everyone is but everyone should at least be considering whether to or not. Right?
310 2020-12-01T15:12:35  <MarcoFalke> michaelfolkson: Ideally, yes
311 2020-12-01T15:13:26  <michaelfolkson> Ok thanks, that's helpful
312 2020-12-01T15:13:46  *** tralfaz is now known as davterra
313 2020-12-01T15:13:49  <jnewbery> any other topics?
314 2020-12-01T15:13:53  <michaelfolkson> I think the jnewbery point on what should be done on dedicated machines is something I have also wondered
315 2020-12-01T15:14:09  <sipa> michaelfolkson: run the fuzzers
316 2020-12-01T15:14:10  <ariard> a short note on state of tx-pinning/package-relay and discussion on the LN-side?
317 2020-12-01T15:14:15  <sipa> like our CI runs the tests
318 2020-12-01T15:14:22  <MarcoFalke> michaelfolkson: ./test/fuzz/test_runner.py --help
319 2020-12-01T15:15:04  <MarcoFalke> anyone can do it. It supports single run (ci) and generation (long running)
320 2020-12-01T15:15:37  <jnewbery> #topic tx pinning / package relay
321 2020-12-01T15:15:37  <core-meetingbot> topic: tx pinning / package relay
322 2020-12-01T15:15:48  <ariard> so we had this discussion few irc meeting ago with LN devs
323 2020-12-01T15:16:02  <ariard> we found yet-another case of tx-pinning after the new anchor spec
324 2020-12-01T15:16:07  <ariard> https://github.com/lightningnetwork/lightning-rfc/pull/803
325 2020-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
326 2020-12-01T15:16:49  <ariard> before to know exactly what we would be cool to ask as a change on the p2p layer
327 2020-12-01T15:17:06  <ariard> so right now I'm spending time hacking with RL to have the necessary toolchain
328 2020-12-01T15:17:11  <ariard> and that's all :)
329 2020-12-01T15:17:33  <ariard> *the attacks, we have multiple scenarios
330 2020-12-01T15:17:43  <glozow> what's the SIGHASH_SINGLE malleability? sorry i'm unfamiliar
331 2020-12-01T15:18:09  <sipa> RL?
332 2020-12-01T15:18:17  <fanquake> rust lightning
333 2020-12-01T15:18:24  <sipa> ah.
334 2020-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)
335 2020-12-01T15:19:14  <jnewbery> glozow: https://bitcoinops.org/en/newsletters/2020/09/16/#stealing-onchain-fees-from-ln-htlcs
336 2020-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
337 2020-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
338 2020-12-01T15:20:08  <ariard> michaelfolkson: yes we discovered another vulnerability but it wasn't mentinonned on the ML
339 2020-12-01T15:20:23  <glozow> ahhhh thanks
340 2020-12-01T15:20:40  <ariard> michaelfolkson: note also that pinning doesn't only affect LN but also bitcoin protocol like vaults, DLC
341 2020-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.
342 2020-12-01T15:21:13  <nehan> ariard: "split brain" is usually used to describe a temporary network partition in distributed systems.
343 2020-12-01T15:21:16  <ariard> nehan: thanks, I think the expression is from zeeman and was just reused at it is by t-bast
344 2020-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
345 2020-12-01T15:21:39  *** miketwen_ <miketwen_!~miketwent@ec2-52-207-61-44.compute-1.amazonaws.com> has joined #bitcoin-core-dev
346 2020-12-01T15:21:48  <sipa> i don't think it can be solved in general
347 2020-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?
348 2020-12-01T15:22:24  <nehan> ariard: not off the top of my head! will think about it.
349 2020-12-01T15:22:48  <jnewbery> inconsistent mempools
350 2020-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
351 2020-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
352 2020-12-01T15:24:25  *** miketwenty1 <miketwenty1!~miketwent@136.55.84.49> has quit IRC (Ping timeout: 240 seconds)
353 2020-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
354 2020-12-01T15:24:44  *** someone235 <someone235!uid419897@gateway/web/irccloud.com/x-xrruhlejkwndamue> has quit IRC (Quit: Connection closed for inactivity)
355 2020-12-01T15:25:13  <sipa> we can reduce the set of situations under which that can happen using better algorithms
356 2020-12-01T15:25:40  <sipa> but the problem in a generic sense seems inherent
357 2020-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
358 2020-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)
359 2020-12-01T15:26:28  <ariard> but for the other something like RBF-package relay _or_ rejecting low-fee pinning transaction might be a solution
360 2020-12-01T15:26:48  <sipa> ariard: my poijt is you'll always be able to find more things like that
361 2020-12-01T15:27:29  <sipa> and no solution (that doesn't introduce DOs attacks) is going to leave (possibly complicated) forms of pinning enabled
362 2020-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
363 2020-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?
364 2020-12-01T15:28:45  <sipa> yes
365 2020-12-01T15:29:04  <sipa> ok, then we agree :)
366 2020-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
367 2020-12-01T15:29:49  <michaelfolkson> All pinning is a problem. There are no specific forms of pinning that are particularly problematic I think...
368 2020-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
369 2020-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
370 2020-12-01T15:31:08  <sipa> redundant as in LN would do relay?
371 2020-12-01T15:31:19  <sipa> or something else!
372 2020-12-01T15:31:20  <sipa> ?
373 2020-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
374 2020-12-01T15:31:32  <ariard> like some broadcast your transaction over DNS or radio :)
375 2020-12-01T15:31:56  <sipa> oh
376 2020-12-01T15:32:50  <sipa> i was hoping LN, because it's an inherently different situation than bitcoin's identityless P2P
377 2020-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
378 2020-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
379 2020-12-01T15:33:41  <ariard> more you have redundant tx-relay network, better you're :)
380 2020-12-01T15:34:06  <sipa> better you're what?
381 2020-12-01T15:34:25  <ariard> harder it is for an attacker to jam with your tx-relay
382 2020-12-01T15:34:57  <jnewbery> "the more redundant networks you have, the better off you are"
383 2020-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 :) ?
384 2020-12-01T15:35:28  <sipa> jnewbery: ah thanks
385 2020-12-01T15:35:31  <ariard> jnewbery: ah, thanks
386 2020-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
387 2020-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)
388 2020-12-01T15:37:51  *** Pavlenex <Pavlenex!~Thunderbi@178.220.103.52> has quit IRC (Quit: Pavlenex)
389 2020-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
390 2020-12-01T15:39:39  <ariard> is anyone wants to do p2p review beg ?
391 2020-12-01T15:40:10  <michaelfolkson> What do you mean? You want to discuss the beg process?
392 2020-12-01T15:40:22  <michaelfolkson> Or beg for particular PRs?
393 2020-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
394 2020-12-01T15:41:01  <ariard> michaelfolkson: I mean p2p meetings are a nice spot for people to ask for reviews on their PR
395 2020-12-01T15:41:11  <michaelfolkson> Ah ok
396 2020-12-01T15:41:29  <michaelfolkson> Feel free to beg :)
397 2020-12-01T15:41:30  <jnewbery> any other topics?
398 2020-12-01T15:41:53  <sipa> gleb: want to mention the erlay bip updates?
399 2020-12-01T15:42:02  <gleb> Oh yeah sure.
400 2020-12-01T15:42:08  <jnewbery> #topic erlay bip updates
401 2020-12-01T15:42:08  <core-meetingbot> topic: erlay bip updates
402 2020-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)
403 2020-12-01T15:42:48  <gleb> We then don't give up, but make one more attempt.
404 2020-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.
405 2020-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)
406 2020-12-01T15:44:08  <gleb> In practice, the implementation turned out to be too complicated on the Bitcoin Core p2p protocol side.
407 2020-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.
408 2020-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.
409 2020-12-01T15:45:07  <gleb> For more rationale see the updated BIP, lemme give you a link.
410 2020-12-01T15:45:16  <gleb> https://github.com/bitcoin/bips/pull/899
411 2020-12-01T15:45:26  <sipa> it's also easier to extend to allow doing multiple tikes, if need be
412 2020-12-01T15:45:37  <gleb> And it's all in the #18261 now, fully ready for review, please review :)
413 2020-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
414 2020-12-01T15:45:45  <gleb> I'm willing to do any help for review facilitation.
415 2020-12-01T15:45:59  <gleb> Including 1-1 sessions over voice chat or something with code walkthrough.
416 2020-12-01T15:46:06  <sdaftuar> gleb: sounds good, i will take a look
417 2020-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?
418 2020-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 :)
419 2020-12-01T15:47:15  <sipa> jnewbery: no it's not; the current bip allows for extending exactly once
420 2020-12-01T15:47:37  *** Lightlike <Lightlike!b9ff439e@185.255.67.158> has quit IRC (Remote host closed the connection)
421 2020-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
422 2020-12-01T15:47:57  <sipa> but not simple at all for bisection
423 2020-12-01T15:48:08  <jnewbery> sipa: makes sense. Thanks
424 2020-12-01T15:49:09  <jnewbery> any final topics?
425 2020-12-01T15:49:37  <jnewbery> Thanks all!
426 2020-12-01T15:49:39  <jnewbery> #endmeeting
427 2020-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
428 2020-12-01T15:49:39  <core-meetingbot> Meeting ended Tue Dec  1 15:49:39 2020 UTC.
429 2020-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
430 2020-12-01T15:55:29  *** Guyver2_ <Guyver2_!Guyver@guyver2.xs4all.nl> has joined #bitcoin-core-dev
431 2020-12-01T15:58:32  *** Guyver2 <Guyver2!Guyver@guyver2.xs4all.nl> has quit IRC (Ping timeout: 256 seconds)
432 2020-12-01T16:01:07  *** Guyver2_ is now known as Guyver2
433 2020-12-01T16:02:19  *** Pavlenex <Pavlenex!~Thunderbi@178.220.103.52> has joined #bitcoin-core-dev
434 2020-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
435 2020-12-01T16:02:39  <vasild> what?
436 2020-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
437 2020-12-01T16:03:05  <vasild> "if the documentation and the code disagree, then both are probably wrong"
438 2020-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
439 2020-12-01T16:03:27  *** Pavlenex <Pavlenex!~Thunderbi@178.220.103.52> has quit IRC (Client Quit)
440 2020-12-01T16:03:47  <jnewbery> (which may be before the peer has sent verack)
441 2020-12-01T16:04:31  <jnewbery> I think ideally, it'd be sent between version and verack, like the wtxidrelay message
442 2020-12-01T16:06:24  <vasild> hmm
443 2020-12-01T16:06:47  <vasild> they seem to disagree indeed
444 2020-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?
445 2020-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)
446 2020-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)
447 2020-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)
448 2020-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
449 2020-12-01T16:13:25  <vasild> sdaftuar: it is not intentional
450 2020-12-01T16:13:35  <sipa> well, for addrv2 it doesn't matter
451 2020-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
452 2020-12-01T16:14:05  <sipa> jnewbery, sdaftuar: agree; it seems pointless but harmless
453 2020-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?
454 2020-12-01T16:14:46  <sipa> yes
455 2020-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
456 2020-12-01T16:15:39  <sipa> i'm happy we got bip154 in 0.21, but this isn't the time to change it anymore...
457 2020-12-01T16:15:44  <sipa> *bip155
458 2020-12-01T16:16:02  <sdaftuar> i'm just trying to figure out what to do with my block-relay-only peer negotiation proposal
459 2020-12-01T16:16:22  <sdaftuar> previously i had thoguht about requiring that turning on block-relay-only would turn off addr-relay
460 2020-12-01T16:16:38  <vasild> maybe bip155 should be corrected: "sendaddrv2 SHOULD be sent after receiving the verack message" s/receiving/sending/
461 2020-12-01T16:16:41  <sdaftuar> but it seemed overly prescriptive in some ways, and addr-relay should perhaps be negotiated separately
462 2020-12-01T16:16:57  <sdaftuar> but if we
463 2020-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
464 2020-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
465 2020-12-01T16:17:46  <sipa> vasild: i think that's the simplest fix
466 2020-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
467 2020-12-01T16:18:11  <sdaftuar> so that it can relay addrs to other peers instead
468 2020-12-01T16:18:42  <jnewbery> we already send addrs to light clients, which are addr relay black holes, I think
469 2020-12-01T16:18:44  <sdaftuar> seems a shame that "honest" behavior results in somewhat worse addr propagation
470 2020-12-01T16:18:49  <sdaftuar> i think that should be fixed or improved as well
471 2020-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.
472 2020-12-01T16:19:07  <sdaftuar> vasild: worth adding a new p2p message for it?
473 2020-12-01T16:19:12  <sdaftuar> we could go that route as well
474 2020-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
475 2020-12-01T16:19:40  <sdaftuar> though it's free
476 2020-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
477 2020-12-01T16:19:59  <sipa> jnewbery: and after sending the verack, no?
478 2020-12-01T16:20:34  <jnewbery> sipa: ah yes, you're right.
479 2020-12-01T16:20:54  <sipa> sdaftuar: how do you suggest dealing with spv clients being black holes?
480 2020-12-01T16:20:57  <jnewbery> do we really want to allow peers to switch from addrv1 to addrv2 at any point?
481 2020-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...
482 2020-12-01T16:21:17  <sipa> jnewbery: we already do, i think
483 2020-12-01T16:21:47  <sdaftuar> jnewbery: is there any problem with peers switching from addrv1 to addrv2?
484 2020-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"
485 2020-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
486 2020-12-01T16:22:53  <sipa> sdaftuar: which means?
487 2020-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
488 2020-12-01T16:24:17  <sdaftuar> which we can't control anyway
489 2020-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
490 2020-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"
491 2020-12-01T16:27:04  <sipa> or something like that, so that old spv software is set off by default
492 2020-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.
493 2020-12-01T16:27:44  <sipa> jnewbery: i agree, but i also think it's a cost we've already paid effectively
494 2020-12-01T16:27:47  <sdaftuar> jnewbery: it only goes in one direction right?
495 2020-12-01T16:28:03  <sipa> it works
496 2020-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
497 2020-12-01T16:28:25  <sipa> yes
498 2020-12-01T16:28:33  <sdaftuar> jnewbery: only because unnecessary changes are, well, unnecessary :)
499 2020-12-01T16:28:37  <sipa> but the same may be true in the other direction :)
500 2020-12-01T16:29:05  <sipa> making it impossible to renegotiate would need more code, not less
501 2020-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
502 2020-12-01T16:29:42  <sipa> jnewbery: of course
503 2020-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
504 2020-12-01T16:30:21  <sipa> jnewbery: and right now, it doesn't need code ro decide whether to ignore it or not
505 2020-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
506 2020-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
507 2020-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
508 2020-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
509 2020-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)
510 2020-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?
511 2020-12-01T16:35:08  <sipa> as opposed to say, add a code comment to clarify addrv2 status can change af any point
512 2020-12-01T16:35:27  <sipa> (and sendheaders, and filter status, and ...)
513 2020-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"
514 2020-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
515 2020-12-01T16:36:58  <sipa> i strongly disagree
516 2020-12-01T16:37:07  <sipa> there is no bug here
517 2020-12-01T16:37:24  <sipa> the time for something like this has passed
518 2020-12-01T16:37:28  <jnewbery> vasild: "send addrv2 between sending version and sending verack"
519 2020-12-01T16:37:47  <jnewbery> there's either a bug in the spec or the implementation
520 2020-12-01T16:38:03  <sipa> hmm, right
521 2020-12-01T16:38:09  <sipa> that's fair
522 2020-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
523 2020-12-01T16:39:09  <sipa> and i think because of that, the spec makes no sense
524 2020-12-01T16:39:22  <sipa> but you could see it differently
525 2020-12-01T16:39:30  <vasild> to me it looks like a bug/typo in the spec and should s/receiving/sending/
526 2020-12-01T16:39:39  <sipa> yeah, exactly
527 2020-12-01T16:43:53  <jnewbery> I don't think it's worth making an rc for this
528 2020-12-01T16:44:17  <vasild> agree
529 2020-12-01T16:44:26  *** jeremyrubin <jeremyrubin!~jr@c-73-15-215-148.hsd1.ca.comcast.net> has joined #bitcoin-core-dev
530 2020-12-01T16:44:34  <sipa> i think the simplest solution is fixing the spec
531 2020-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.
532 2020-12-01T16:45:03  <sipa> (not because it mismatches the implementation, but because it appears unintentional)
533 2020-12-01T16:45:58  <sipa> does the current 0.21rc code work correctly if it receives addrv2 before verack?
534 2020-12-01T16:46:01  <jnewbery> Oh, no we can't because we'll only process a sendaddrv2 after receiving a verack.
535 2020-12-01T16:46:08  <jnewbery> sipa: snap
536 2020-12-01T16:46:36  <vasild> "does the current 0.21rc code work correctly if it receives addrv2 before verack?" -- yes
537 2020-12-01T16:46:53  <jnewbery> vasild: no, we'll drop the message if we receive it before verack
538 2020-12-01T16:47:05  *** Pavlenex <Pavlenex!~Thunderbi@178.220.103.52> has joined #bitcoin-core-dev
539 2020-12-01T16:47:10  <jnewbery> https://github.com/bitcoin/bitcoin/blob/f17e8ba3a17b6516a1b1fb7f45d506a339e99f90/src/net_processing.cpp#L2538-L2541
540 2020-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
541 2020-12-01T16:47:50  <sipa> oh, i should perhaps hage brought this up during the meeting: should torv3 anchors work in 0.21?
542 2020-12-01T16:48:04  <sipa> do we consider that a missing feature or a bug?
543 2020-12-01T16:48:06  <vasild> jnewbery: right, sorry
544 2020-12-01T16:48:27  <jnewbery> sipa: I'd say missing feature
545 2020-12-01T16:49:04  <sipa> jnewbery: i'm beginning to lean in that direction too, and it seems hebasto agrees as well
546 2020-12-01T16:49:04  <jnewbery> we didn't have either before v0.21, so people aren't depending on them working together
547 2020-12-01T16:49:25  <sipa> yeah, and they're mostly an unobservable feature anyway
548 2020-12-01T16:49:53  *** ctrlbreak_MAD <ctrlbreak_MAD!~ctrlbreak@159.2.182.106> has joined #bitcoin-core-dev
549 2020-12-01T16:49:59  <vasild> seems like a good thing to "fix" in 0.21.1
550 2020-12-01T16:50:19  <vasild> (torv3 anchors)
551 2020-12-01T16:51:10  <sipa> vasild: saw #20516?
552 2020-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
553 2020-12-01T16:51:30  <vasild> sipa: yes, but did not dive in it yet in order to comment
554 2020-12-01T16:51:48  <sipa> sure, no rush
555 2020-12-01T16:51:57  <vasild> I did not get it why did you close the other small pr
556 2020-12-01T16:52:16  <sipa> vasild: it was intended as a quick fix for 0.21
557 2020-12-01T16:52:26  <vasild> it would get torv3 anchors
558 2020-12-01T16:52:58  <sipa> not as-is, it needed your patch or 20516 as well
559 2020-12-01T16:53:00  <vasild> yes, + the patch I posted in the comments
560 2020-12-01T16:53:28  *** ctrlbreak <ctrlbreak!~ctrlbreak@159.2.182.106> has quit IRC (Ping timeout: 265 seconds)
561 2020-12-01T16:53:35  <vasild> would the small pr + my patch in the comments cause any trouble for 20516? I think no
562 2020-12-01T16:53:51  <sipa> 201516 does exactly the same thing
563 2020-12-01T16:53:55  <sipa> just cleaner
564 2020-12-01T16:53:58  <sipa> (imo)
565 2020-12-01T16:54:22  <sipa> but it's not something i feel is worth it for 0.21 anymore
566 2020-12-01T16:54:38  <sipa> so i'd rather do it properly instead in 0.21.1 or 22
567 2020-12-01T16:54:53  <vasild> ok
568 2020-12-01T16:55:56  <sipa> 20516 makes it also fail deserialization if the on-disk version is unexpected, and adds more tests
569 2020-12-01T16:56:11  <sipa> (i wrote that before you commemted with your patch, otherwise i'd have based it on yours)
570 2020-12-01T16:58:23  <vasild> aha, since you mention "fail deserialization"...
571 2020-12-01T16:59:36  <vasild> should we compare the stream version with ondisk version in CAddress deserialization
572 2020-12-01T16:59:52  <vasild> and if one has ADDRV2_FORMAT set but the other does not then throw?
573 2020-12-01T17:00:14  <vasild> is this what you mean by "unexpected"?
574 2020-12-01T17:00:17  <sipa> that'll break anchors
575 2020-12-01T17:00:43  <sipa> once v2 is used for those, but an old anchors.dar is read
576 2020-12-01T17:00:44  <vasild> oh, right
577 2020-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
578 2020-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
579 2020-12-01T17:01:46  <vasild> during serialization?
580 2020-12-01T17:02:00  <sipa> but the other direction works
581 2020-12-01T17:02:27  <vasild> I see
582 2020-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)
583 2020-12-01T17:04:03  *** proofofkeags <proofofkeags!~proofofke@174-16-212-53.hlrn.qwest.net> has joined #bitcoin-core-dev
584 2020-12-01T17:06:24  *** lightlike <lightlike!~lightlike@p200300c7ef1ab3003906d5c2a9a5021c.dip0.t-ipconnect.de> has joined #bitcoin-core-dev
585 2020-12-01T17:07:01  <sipa> unfortunately, that means at least 4 versions
586 2020-12-01T17:07:29  <sipa> DISK, NETWORK_NOTIME, NETWORK_V1, NETWORK_V2
587 2020-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)
588 2020-12-01T17:13:23  <vasild> :-|
589 2020-12-01T17:15:49  <sipa> hmm, maybe we should just remove the "notime" functionality from CAddress
590 2020-12-01T17:16:06  *** einyx <einyx!einyx@fsf/member/einyx> has joined #bitcoin-core-dev
591 2020-12-01T17:16:09  <sipa> and just invoke it as serializing nServices and CService spearately
592 2020-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)
593 2020-12-01T17:26:31  *** sr_gi <sr_gi!~sr_gi@80.174.218.168.dyn.user.ono.com> has joined #bitcoin-core-dev
594 2020-12-01T17:33:02  *** Guyver2_ <Guyver2_!Guyver@guyver2.xs4all.nl> has joined #bitcoin-core-dev
595 2020-12-01T17:36:13  *** Guyver2 <Guyver2!Guyver@guyver2.xs4all.nl> has quit IRC (Ping timeout: 264 seconds)
596 2020-12-01T17:59:20  *** Talkless <Talkless!~Talkless@mail.dargis.net> has joined #bitcoin-core-dev
597 2020-12-01T18:13:01  *** Pavlenex <Pavlenex!~Thunderbi@178.220.103.52> has quit IRC (Quit: Pavlenex)
598 2020-12-01T18:19:06  *** kristapsk_ <kristapsk_!~KK@gateway/tor-sasl/kristapsk> has joined #bitcoin-core-dev
599 2020-12-01T18:21:03  *** sdaftuar <sdaftuar!~sdaftuar@gateway/tor-sasl/sdaftuar> has quit IRC (Ping timeout: 240 seconds)
600 2020-12-01T18:21:04  *** kristapsk <kristapsk!~KK@gateway/tor-sasl/kristapsk> has quit IRC (Ping timeout: 240 seconds)
601 2020-12-01T18:23:35  *** sdaftuar <sdaftuar!~sdaftuar@gateway/tor-sasl/sdaftuar> has joined #bitcoin-core-dev
602 2020-12-01T18:36:11  *** Randolf <Randolf!~randolf@184.70.10.188> has joined #bitcoin-core-dev
603 2020-12-01T18:36:58  *** Tennis <Tennis!~Tennis@unaffiliated/tennis> has quit IRC (Quit: Leaving)
604 2020-12-01T18:37:44  *** jonatack <jonatack!~jon@88.124.242.136> has quit IRC (Ping timeout: 272 seconds)
605 2020-12-01T18:38:09  *** jonatack <jonatack!~jon@109.232.227.138> has joined #bitcoin-core-dev
606 2020-12-01T18:38:58  *** Mercury_Vapor <Mercury_Vapor!~Mercury_V@174-082-166-092.res.spectrum.com> has quit IRC (Quit: Leaving)
607 2020-12-01T18:45:50  *** Mercury_Vapor <Mercury_Vapor!~Mercury_V@174-082-166-092.res.spectrum.com> has joined #bitcoin-core-dev
608 2020-12-01T18:50:29  *** kexkey <kexkey!~kexkey@static-198-54-132-121.cust.tzulo.com> has joined #bitcoin-core-dev
609 2020-12-01T19:05:01  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
610 2020-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
611 2020-12-01T19:05:02  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
612 2020-12-01T19:05:30  <sipa> vasild: ^
613 2020-12-01T19:25:57  *** brianhoffman <brianhoffman!~brianhoff@pool-71-191-34-154.washdc.fios.verizon.net> has joined #bitcoin-core-dev
614 2020-12-01T19:34:30  *** lightlike <lightlike!~lightlike@p200300c7ef1ab3003906d5c2a9a5021c.dip0.t-ipconnect.de> has quit IRC (Remote host closed the connection)
615 2020-12-01T19:34:48  *** AaronvanW <AaronvanW!~AaronvanW@unaffiliated/aaronvanw> has quit IRC (Remote host closed the connection)
616 2020-12-01T19:44:57  *** cltrbreak_MAD2 <cltrbreak_MAD2!~ctrlbreak@159.2.182.106> has joined #bitcoin-core-dev
617 2020-12-01T19:48:25  *** ctrlbreak_MAD <ctrlbreak_MAD!~ctrlbreak@159.2.182.106> has quit IRC (Ping timeout: 240 seconds)
618 2020-12-01T19:52:00  *** ctrlbreak_MAD <ctrlbreak_MAD!~ctrlbreak@159.2.182.106> has joined #bitcoin-core-dev
619 2020-12-01T19:55:25  *** cltrbreak_MAD2 <cltrbreak_MAD2!~ctrlbreak@159.2.182.106> has quit IRC (Ping timeout: 260 seconds)
620 2020-12-01T20:20:44  *** Talkless <Talkless!~Talkless@mail.dargis.net> has quit IRC (Quit: Konversation terminated!)
621 2020-12-01T20:40:05  *** ctrlbreak_MAD is now known as ctrlbreak
622 2020-12-01T20:47:45  *** AaronvanW <AaronvanW!~AaronvanW@unaffiliated/aaronvanw> has joined #bitcoin-core-dev
623 2020-12-01T20:47:48  *** ghost43 <ghost43!~daer@gateway/tor-sasl/daer> has quit IRC (Remote host closed the connection)
624 2020-12-01T20:49:50  *** ghost43 <ghost43!~daer@gateway/tor-sasl/daer> has joined #bitcoin-core-dev
625 2020-12-01T20:57:04  *** Guest19 <Guest19!~textual@78-2-110-233.adsl.net.t-com.hr> has joined #bitcoin-core-dev
626 2020-12-01T21:16:56  *** AaronvanW <AaronvanW!~AaronvanW@unaffiliated/aaronvanw> has quit IRC (Ping timeout: 240 seconds)
627 2020-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…)
628 2020-12-01T21:47:59  *** Guyver2__ <Guyver2__!Guyver@guyver2.xs4all.nl> has joined #bitcoin-core-dev
629 2020-12-01T21:50:26  *** Guyver2_ <Guyver2_!Guyver@guyver2.xs4all.nl> has quit IRC (Ping timeout: 256 seconds)
630 2020-12-01T22:17:31  *** Guyver2__ <Guyver2__!Guyver@guyver2.xs4all.nl> has quit IRC (Quit: Going offline, see ya! (www.adiirc.com))
631 2020-12-01T22:30:49  *** bhy <bhy!b0b58536@i15-les02-ntr-176-181-133-54.sfr.lns.abo.bbox.fr> has joined #bitcoin-core-dev
632 2020-12-01T22:31:56  *** filchef <filchef!~filchef@212.104.97.177> has quit IRC (Quit: KVIrc 5.0.0 Aria http://www.kvirc.net/)
633 2020-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)
634 2020-12-01T22:38:17  *** joelklabo <joelklabo!~textual@108-196-216-127.lightspeed.sntcca.sbcglobal.net> has joined #bitcoin-core-dev
635 2020-12-01T23:04:53  *** mrostecki <mrostecki!mrostecki@nat/suse/x-kwnqnqspcazesbuo> has quit IRC (Ping timeout: 272 seconds)
636 2020-12-01T23:10:09  <promag> quick question, does it makes sense to limit cookie auth to loopback? anyone using it in other ways?
637 2020-12-01T23:14:38  *** AaronvanW <AaronvanW!~AaronvanW@unaffiliated/aaronvanw> has joined #bitcoin-core-dev
638 2020-12-01T23:20:07  *** miketwen_ <miketwen_!~miketwent@ec2-52-207-61-44.compute-1.amazonaws.com> has quit IRC ()
639 2020-12-01T23:29:36  *** owowo <owowo!~ovovo@unaffiliated/ovovo> has quit IRC (Ping timeout: 256 seconds)
640 2020-12-01T23:35:07  *** owowo <owowo!~ovovo@unaffiliated/ovovo> has joined #bitcoin-core-dev
641 2020-12-01T23:37:19  *** pinheadmz <pinheadmz!~pinheadmz@71.190.30.138> has quit IRC (Read error: Connection reset by peer)
642 2020-12-01T23:38:08  *** pinheadmz <pinheadmz!~pinheadmz@71.190.30.138> has joined #bitcoin-core-dev
643 2020-12-01T23:45:45  *** EagleTM <EagleTM!~EagleTM@unaffiliated/eagletm> has quit IRC (Ping timeout: 265 seconds)
644 2020-12-01T23:48:16  *** AaronvanW <AaronvanW!~AaronvanW@unaffiliated/aaronvanw> has quit IRC (Ping timeout: 260 seconds)
645 2020-12-01T23:55:30  *** AaronvanW <AaronvanW!~AaronvanW@unaffiliated/aaronvanw> has joined #bitcoin-core-dev
646 2020-12-01T23:57:31  *** mrostecki <mrostecki!mrostecki@nat/suse/x-oplejjvnaxzshynh> has joined #bitcoin-core-dev