1 2021-05-04T00:06:01  *** belcher <belcher!~belcher@unaffiliated/belcher> has quit IRC (Ping timeout: 252 seconds)
  2 2021-05-04T00:12:35  *** jeremyrubin <jeremyrubin!~jr@024-176-247-182.res.spectrum.com> has joined #bitcoin-core-dev
  3 2021-05-04T00:17:04  *** faketoshi <faketoshi!~quassel@> has joined #bitcoin-core-dev
  4 2021-05-04T00:19:50  *** belcher <belcher!~belcher@unaffiliated/belcher> has joined #bitcoin-core-dev
  5 2021-05-04T00:20:07  *** bcman <bcman!~quassel@> has quit IRC (Ping timeout: 265 seconds)
  6 2021-05-04T00:25:11  *** yanmaani1 is now known as yanmaani
  7 2021-05-04T00:25:26  *** proofofkeags <proofofkeags!~proofofke@> has quit IRC (Ping timeout: 240 seconds)
  8 2021-05-04T00:52:55  *** vincenzopalazzo <vincenzopalazzo!~vincenzop@host-79-37-17-61.retail.telecomitalia.it> has quit IRC (Quit: Leaving)
  9 2021-05-04T01:07:47  *** jeremyrubin <jeremyrubin!~jr@024-176-247-182.res.spectrum.com> has quit IRC (Read error: Connection reset by peer)
 10 2021-05-04T01:09:00  *** jeremyrubin <jeremyrubin!~jr@024-176-247-182.res.spectrum.com> has joined #bitcoin-core-dev
 11 2021-05-04T01:10:20  *** Eagle[TM] <Eagle[TM]!~EagleTM@unaffiliated/eagletm> has joined #bitcoin-core-dev
 12 2021-05-04T01:11:06  *** EagleTM <EagleTM!~EagleTM@unaffiliated/eagletm> has quit IRC (Ping timeout: 240 seconds)
 13 2021-05-04T01:16:02  *** _dvd <_dvd!dvd@nat/redhat/x-fojdbtkrnypbdhxb> has joined #bitcoin-core-dev
 14 2021-05-04T01:26:03  *** mips <mips!~mips@gateway/tor-sasl/mips> has quit IRC (Quit: Leaving)
 15 2021-05-04T01:28:06  *** GarouDan <GarouDan!~GarouDan@> has joined #bitcoin-core-dev
 16 2021-05-04T01:32:38  *** GarouDan <GarouDan!~GarouDan@> has quit IRC (Ping timeout: 246 seconds)
 17 2021-05-04T01:33:24  *** OP_NOP <OP_NOP!OP_NOP@gateway/vpn/privateinternetaccess/opnop/x-41418994> has joined #bitcoin-core-dev
 18 2021-05-04T01:47:54  *** spinza <spinza!~spin@> has quit IRC (Quit: Coyote finally caught up with me...)
 19 2021-05-04T01:48:39  *** yanmaani1 <yanmaani1!~yanmaani@gateway/tor-sasl/yanmaani> has joined #bitcoin-core-dev
 20 2021-05-04T01:51:04  *** CubicEarth <CubicEarth!~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net> has quit IRC (Ping timeout: 252 seconds)
 21 2021-05-04T01:51:57  *** yanmaani <yanmaani!~yanmaani@gateway/tor-sasl/yanmaani> has quit IRC (Ping timeout: 240 seconds)
 22 2021-05-04T01:54:25  *** CubicEarth <CubicEarth!~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net> has joined #bitcoin-core-dev
 23 2021-05-04T01:58:45  *** yanmaani1 is now known as yanmaani
 24 2021-05-04T02:15:40  *** spinza <spinza!~spin@> has joined #bitcoin-core-dev
 25 2021-05-04T02:20:24  *** GarouDan <GarouDan!~GarouDan@> has joined #bitcoin-core-dev
 26 2021-05-04T02:31:39  *** inquis <inquis!~inquis@> has quit IRC (Remote host closed the connection)
 27 2021-05-04T02:38:45  *** DeanGuss <DeanGuss!~dean@gateway/tor-sasl/deanguss> has quit IRC (Ping timeout: 240 seconds)
 28 2021-05-04T02:53:22  *** DeanGuss <DeanGuss!~dean@gateway/tor-sasl/deanguss> has joined #bitcoin-core-dev
 29 2021-05-04T03:03:58  *** OP_NOP <OP_NOP!OP_NOP@gateway/vpn/privateinternetaccess/opnop/x-41418994> has quit IRC (Ping timeout: 265 seconds)
 30 2021-05-04T03:13:40  *** awesome_doge <awesome_doge!~Thunderbi@118-163-120-175.HINET-IP.hinet.net> has joined #bitcoin-core-dev
 31 2021-05-04T03:20:11  *** sturles <sturles!~sturles@unaffiliated/sturles> has quit IRC (Ping timeout: 240 seconds)
 32 2021-05-04T03:22:04  *** sturles <sturles!~sturles@sauron.uio.no> has joined #bitcoin-core-dev
 33 2021-05-04T03:49:07  *** erwin_bullet <erwin_bullet!~erwin_bul@> has joined #bitcoin-core-dev
 34 2021-05-04T03:50:56  *** GarouDan <GarouDan!~GarouDan@> has quit IRC (Remote host closed the connection)
 35 2021-05-04T04:20:21  *** justanotheruser <justanotheruser!~justanoth@unaffiliated/justanotheruser> has joined #bitcoin-core-dev
 36 2021-05-04T04:26:51  *** EastSideTony <EastSideTony!6b81a5cc@107-129-165-204.lightspeed.sntcca.sbcglobal.net> has joined #bitcoin-core-dev
 37 2021-05-04T04:27:53  *** EastSideTony <EastSideTony!6b81a5cc@107-129-165-204.lightspeed.sntcca.sbcglobal.net> has quit IRC (Client Quit)
 38 2021-05-04T04:49:35  *** sipsorcery <sipsorcery!~sipsorcer@2a02:8084:6981:7880::3> has quit IRC (Ping timeout: 260 seconds)
 39 2021-05-04T04:51:04  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
 40 2021-05-04T04:51:05  <bitcoin-git> [bitcoin] MarcoFalke pushed 4 commits to master: https://github.com/bitcoin/bitcoin/compare/bf5e6a7771b3...e2d4e67a8fcc
 41 2021-05-04T04:51:05  <bitcoin-git> bitcoin/master fa2197c MarcoFalke: test: Use loop to register RPCs
 42 2021-05-04T04:51:06  <bitcoin-git> bitcoin/master 000098f MarcoFalke: test: Use throwing variant accessor
 43 2021-05-04T04:51:07  <bitcoin-git> bitcoin/master fa8a888 MarcoFalke: bench: Remove duplicate constants
 44 2021-05-04T04:51:08  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
 45 2021-05-04T04:51:23  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
 46 2021-05-04T04:51:24  <bitcoin-git> [bitcoin] MarcoFalke merged pull request #21840: test: Misc refactor to get rid of &foo[0] raw pointers (master...2105-testRefactor) https://github.com/bitcoin/bitcoin/pull/21840
 47 2021-05-04T04:51:25  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
 48 2021-05-04T05:14:01  *** jeremyrubin <jeremyrubin!~jr@024-176-247-182.res.spectrum.com> has quit IRC (Ping timeout: 252 seconds)
 49 2021-05-04T05:30:00  *** pox <pox!~pox@gateway/tor-sasl/pox> has joined #bitcoin-core-dev
 50 2021-05-04T05:39:43  *** mips <mips!~mips@gateway/tor-sasl/mips> has joined #bitcoin-core-dev
 51 2021-05-04T05:55:26  *** erwin_bullet <erwin_bullet!~erwin_bul@> has quit IRC (Remote host closed the connection)
 52 2021-05-04T05:57:35  *** Guyver2 <Guyver2!~Guyver@guyver2.xs4all.nl> has joined #bitcoin-core-dev
 53 2021-05-04T06:07:49  *** Zao_ <Zao_!~Zao_@> has joined #bitcoin-core-dev
 54 2021-05-04T06:27:13  *** jeremyrubin <jeremyrubin!~jr@024-176-247-182.res.spectrum.com> has joined #bitcoin-core-dev
 55 2021-05-04T06:27:58  *** smctwo <smctwo!~smctwo@> has joined #bitcoin-core-dev
 56 2021-05-04T06:32:46  *** smctwo <smctwo!~smctwo@> has quit IRC (Ping timeout: 265 seconds)
 57 2021-05-04T06:33:26  *** awesome_doge <awesome_doge!~Thunderbi@118-163-120-175.HINET-IP.hinet.net> has quit IRC (Quit: awesome_doge)
 58 2021-05-04T06:38:39  *** jungly <jungly!~jungly@host-82-49-146-18.retail.telecomitalia.it> has joined #bitcoin-core-dev
 59 2021-05-04T07:00:00  *** sipsorcery <sipsorcery!~sipsorcer@2a02:8084:6981:7880::3> has joined #bitcoin-core-dev
 60 2021-05-04T07:16:59  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
 61 2021-05-04T07:16:59  <bitcoin-git> [bitcoin] MarcoFalke opened pull request #21848: refactor: Make CFeeRate constructor arch-independent (master...2105-feerate) https://github.com/bitcoin/bitcoin/pull/21848
 62 2021-05-04T07:17:00  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
 63 2021-05-04T07:18:03  *** duringo <duringo!2d57d6c5@> has quit IRC (Ping timeout: 240 seconds)
 64 2021-05-04T07:27:31  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
 65 2021-05-04T07:27:32  <bitcoin-git> [bitcoin] MarcoFalke opened pull request #21849: fuzz: Limit toxic test globals to their respective scope (master...2105-fuzzToxic) https://github.com/bitcoin/bitcoin/pull/21849
 66 2021-05-04T07:27:33  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
 67 2021-05-04T07:40:24  *** jespada <jespada!~jespada@> has joined #bitcoin-core-dev
 68 2021-05-04T07:43:30  *** Guyver2_ <Guyver2_!~Guyver@guyver2.xs4all.nl> has joined #bitcoin-core-dev
 69 2021-05-04T07:45:15  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
 70 2021-05-04T07:45:16  <bitcoin-git> [bitcoin] laanwj pushed 4 commits to master: https://github.com/bitcoin/bitcoin/compare/e2d4e67a8fcc...ab9a566ab333
 71 2021-05-04T07:45:16  <bitcoin-git> bitcoin/master ea269c7 Jon Atack: contrib: parse I2P addresses in generate-seeds.py
 72 2021-05-04T07:45:17  <bitcoin-git> bitcoin/master e01f173 Jon Atack: contrib: add a few I2P seed nodes
 73 2021-05-04T07:45:17  <bitcoin-git> bitcoin/master 142e2da Jon Atack: net: add I2P seeds to chainparamsseeds
 74 2021-05-04T07:45:18  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
 75 2021-05-04T07:45:34  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
 76 2021-05-04T07:45:35  <bitcoin-git> [bitcoin] laanwj merged pull request #21825: net: add I2P hardcoded seeds (master...i2p-hardcoded-seeds) https://github.com/bitcoin/bitcoin/pull/21825
 77 2021-05-04T07:45:36  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
 78 2021-05-04T07:45:51  *** Guyver2 <Guyver2!~Guyver@guyver2.xs4all.nl> has quit IRC (Ping timeout: 260 seconds)
 79 2021-05-04T07:46:53  *** prayank <prayank!~andr0irc@2402:8100:206c:68c8:30b0:af4b:7735:463b> has joined #bitcoin-core-dev
 80 2021-05-04T07:55:10  <wumpus> ryanofsky: done
 81 2021-05-04T07:57:36  *** dnm21881[m] <dnm21881[m]!dnm21881ma@gateway/shell/matrix.org/x-llapygmoibnbsrtg> has joined #bitcoin-core-dev
 82 2021-05-04T07:58:36  *** dnm21881[m] <dnm21881[m]!dnm21881ma@gateway/shell/matrix.org/x-llapygmoibnbsrtg> has left #bitcoin-core-dev
 83 2021-05-04T08:00:02  *** lkqwejhhgasdjhgn <lkqwejhhgasdjhgn!~kljkljklk@p200300d46f06bf00ea203cd14cca75b0.dip0.t-ipconnect.de> has joined #bitcoin-core-dev
 84 2021-05-04T08:04:07  <gmaxwell> Antpool taproot block, thats over 50% hashpower now.
 85 2021-05-04T08:06:40  <aj> \o/
 86 2021-05-04T08:07:26  *** owowo <owowo!~ovovo@unaffiliated/ovovo> has quit IRC (Ping timeout: 240 seconds)
 87 2021-05-04T08:11:33  <hugohn> hi, I'm curious what else needs to be done before https://github.com/bitcoin/bips/pull/1097 can get a BIP number assigned?
 88 2021-05-04T08:11:33  <hugohn> I saw some chatter earlier about folks wanting to change the BIP process, but until that becomes more clear I assume the process stays the same.
 89 2021-05-04T08:11:52  <hugohn> (also yay on Taproot signaling progress)
 90 2021-05-04T08:12:40  *** Guyver2_ <Guyver2_!~Guyver@guyver2.xs4all.nl> has quit IRC (Quit: Going offline, see ya! (www.adiirc.com))
 91 2021-05-04T08:14:17  <wumpus> hugohn: nothing, it should just get a BIP number assigned
 92 2021-05-04T08:15:09  *** yanmaani <yanmaani!~yanmaani@gateway/tor-sasl/yanmaani> has quit IRC (Ping timeout: 240 seconds)
 93 2021-05-04T08:15:56  *** yanmaani <yanmaani!~yanmaani@gateway/tor-sasl/yanmaani> has joined #bitcoin-core-dev
 94 2021-05-04T08:16:45  <wumpus> ping @luke-jr ^
 95 2021-05-04T08:16:47  <aj> hugohn: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018868.html suggests assigning a name in the meantime, i guess like hugohn-multisig-setup; otherwise what wumpus said
 96 2021-05-04T08:19:49  <hugohn> @wumpus @aj thanks !
 97 2021-05-04T08:19:51  <wumpus> yes, moving to names might make sense too, in any case please don't let bitcoin innovation be stuck on having to centrally assign numbers, this shouldn't be an issue
 98 2021-05-04T08:20:16  <hugohn> I've already named the branch "bip-hugonguyen-bsms". Does it need to be included in the spec itself?
 99 2021-05-04T08:25:37  <hugohn> on a side note: I think using BIP numbers or acronyms like BSMS / PSBT as unique identifiers for a spec is still more ideal. Using personal names as identifiers for a standard seems... weird :)
100 2021-05-04T08:26:31  <hugohn> not to mention the long ID is a mouthful / harder to share
101 2021-05-04T08:27:49  <hugohn> although the idea of of a more decentralized process does sound good
102 2021-05-04T08:29:07  <hugohn> maybe the process could be decoupled, but the ID aspect could stay centralized (e.g. there could be a BIP on BIP number generation). just thinking out loud.
103 2021-05-04T08:29:08  <wumpus> an idea we had early was to simply use the PR number as BIP number
104 2021-05-04T08:29:45  <wumpus> some projects (rust, I think?) use this approach
105 2021-05-04T08:30:13  <wumpus> but also there was some effort to make BIP numbers meaningful, certain ranges map to certain things, it is not simply a sequence generator
106 2021-05-04T08:32:33  <wumpus> agree that having an author name in it is weird, on the other hand, namespacing is hard, many projects eventually settle on organization/pseudonym based namespacing to prevent name squatting etc
107 2021-05-04T08:32:41  <hugohn> right. if it's not a simple sequence generator, a BIP on BIPs probably makes more sense.
108 2021-05-04T08:33:02  <wumpus> this is mustly a problem if it would be managed by as scriptbot
109 2021-05-04T08:33:27  <wumpus> you mean like BIP1 and 2?
110 2021-05-04T08:34:11  <hugohn> yes
111 2021-05-04T08:34:29  <wumpus> in any case, this discussion is kind of off-topic here, the bitcoin core project is one implementation, that the current BIPs repository is in the same orginazation is a historical artifact, it does not mean BIPs 'belong' to bitcoin core or something like that
112 2021-05-04T08:39:22  <michaelfolkson> I think there will be future discussions on a revised BIP process once (hopefully) Taproot activation is completed hugohn if you'd like to engage with that https://github.com/bitcoin/bips/pull/1015
113 2021-05-04T08:39:54  <michaelfolkson> A few things I think are probably in need of a revamp (or at least a discussion)
114 2021-05-04T08:40:02  <hugohn> thanks @michaelfolkson . I'd take a look.
115 2021-05-04T08:40:59  <wumpus> ideally it should be a fast and low-friction process
116 2021-05-04T08:44:08  <michaelfolkson> Right, there are a few edge cases that need ironing out too eg what "Rejected" means and how you get out of "Rejected" status (if indeed you ever do)
117 2021-05-04T08:51:53  <michaelfolkson> I'm assuming GUI translation issues should be in the GUI repo and not the main repo? https://github.com/bitcoin/bitcoin/issues/21847
118 2021-05-04T08:52:39  <wumpus> correct, that is what the GUI repo is for
119 2021-05-04T08:53:27  <wumpus> i think we should add an entry to the "https://github.com/bitcoin/bitcoin/issues/new/choose" list for GUI issues, redirecting people to the appropriate repository
120 2021-05-04T08:54:42  <hugohn> @wumpus I understand. I think we should continue with this "historical artifact", as unfortunate as it is, until there's a better way.
121 2021-05-04T08:55:04  <hugohn> As the Bitcoin protocol slowly ossifies, the bulk of new specs will likely be in the Application layer. It does make less sense to bundle them with the Core project.
122 2021-05-04T08:56:57  <michaelfolkson> hugohn: They aren't really bundled with the Core project. It is true the BIPs repo is under the Bitcoin Core GitHub org but no Bitcoin Core maintainers merge BIP PRs afaik so I think it is fine under the Core org
123 2021-05-04T08:57:24  <michaelfolkson> hugohn: I personally think it would be overkill to give the BIPs repo its own org
124 2021-05-04T08:59:00  <michaelfolkson> wumpus: There already is "An issue or feature request related to the GUI" option when you open an issue. Is that what you mean?
125 2021-05-04T08:59:22  <michaelfolkson> wumpus: You click on that option and you get "Any report, issue or feature request related to the GUI should be reported at
126 2021-05-04T08:59:22  <michaelfolkson> https://github.com/bitcoin-core/gui/issues/"
127 2021-05-04T08:59:35  <wumpus> michaelfolkson: yes, except it should send you to the GUI repo
128 2021-05-04T08:59:50  <wumpus> oh okay, that's a bit weird but i guess it works
129 2021-05-04T08:59:57  <michaelfolkson> wumpus: Ah ok I see what you mean
130 2021-05-04T09:01:34  <michaelfolkson> I agree that would be optimal but not sure if you can be redirected to a different repo when you click a new issue option
131 2021-05-04T09:01:35  <wumpus> i guess the problem is that "gui" will have the same options, by definition, because it has the same underlying repository
132 2021-05-04T09:01:42  <michaelfolkson> Right
133 2021-05-04T09:02:59  <wumpus> i thought it could be like the "view policy" link for security reports, but apparently that one is a special edge cases by github
134 2021-05-04T09:07:11  *** sipsorcery <sipsorcery!~sipsorcer@2a02:8084:6981:7880::3> has quit IRC (Ping timeout: 260 seconds)
135 2021-05-04T09:16:01  *** sipsorcery <sipsorcery!~sipsorcer@2a02:8084:6981:7880::3> has joined #bitcoin-core-dev
136 2021-05-04T09:38:21  *** braydonf_ <braydonf_!~braydon@gateway/tor-sasl/braydonf> has quit IRC (Ping timeout: 240 seconds)
137 2021-05-04T09:39:39  *** ogo <ogo!~ogo@gateway/tor-sasl/ogo> has joined #bitcoin-core-dev
138 2021-05-04T09:39:42  *** braydonf_ <braydonf_!~braydon@gateway/tor-sasl/braydonf> has joined #bitcoin-core-dev
139 2021-05-04T10:03:56  *** vincenzopalazzo <vincenzopalazzo!~vincenzop@host-79-37-17-61.retail.telecomitalia.it> has joined #bitcoin-core-dev
140 2021-05-04T10:04:12  *** Eagle[TM] <Eagle[TM]!~EagleTM@unaffiliated/eagletm> has quit IRC (Ping timeout: 252 seconds)
141 2021-05-04T10:08:42  *** jespada <jespada!~jespada@> has quit IRC (Quit: Leaving)
142 2021-05-04T10:21:17  *** Sage56Koss <Sage56Koss!~Sage56Kos@static.> has joined #bitcoin-core-dev
143 2021-05-04T10:26:13  *** Sage56Koss <Sage56Koss!~Sage56Kos@static.> has quit IRC (Ping timeout: 265 seconds)
144 2021-05-04T10:37:18  *** owowo <owowo!~ovovo@> has joined #bitcoin-core-dev
145 2021-05-04T10:40:29  *** d0minik <d0minik!5f5afe59@ip5f5afe59.dynamic.kabel-deutschland.de> has joined #bitcoin-core-dev
146 2021-05-04T10:41:59  *** d0minik <d0minik!5f5afe59@ip5f5afe59.dynamic.kabel-deutschland.de> has quit IRC (Client Quit)
147 2021-05-04T11:19:01  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
148 2021-05-04T11:19:01  <bitcoin-git> [bitcoin] fanquake pushed 4 commits to master: https://github.com/bitcoin/bitcoin/compare/ab9a566ab333...0ca8b7e7ecd5
149 2021-05-04T11:19:02  <bitcoin-git> bitcoin/master faeabef MarcoFalke: ci: Enable D_GLIBCXX_DEBUG for multiprocess task
150 2021-05-04T11:19:02  <bitcoin-git> bitcoin/master fad0f21 MarcoFalke: ci: Use clang in multiprocess task to avoid OOM
151 2021-05-04T11:19:03  <bitcoin-git> bitcoin/master fa44f51 MarcoFalke: ci: Clarify that previous_releases task is using DEBUG
152 2021-05-04T11:19:04  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
153 2021-05-04T11:19:21  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
154 2021-05-04T11:19:21  <bitcoin-git> [bitcoin] fanquake merged pull request #21812: ci: Enable D_GLIBCXX_DEBUG for multiprocess task (master...2104-ciDEBUG) https://github.com/bitcoin/bitcoin/pull/21812
155 2021-05-04T11:19:23  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
156 2021-05-04T11:26:46  *** xxxyyyzzz111 <xxxyyyzzz111!014084b8@1-64-132-184.static.netvigator.com> has joined #bitcoin-core-dev
157 2021-05-04T11:27:36  *** xxxyyyzzz111 <xxxyyyzzz111!014084b8@1-64-132-184.static.netvigator.com> has left #bitcoin-core-dev
158 2021-05-04T11:42:20  <jonatack> MarcoFalke: question regarding fuzzed_data_provider.ConsumeBool(), which exists but isn't used yet...is it ok to add a line to an enum to use it? e.g. adding "kMaxValue = NET_MAX," at the end of netaddress.h::enum Network
159 2021-05-04T11:43:50  <fanquake> I see 169 uses of fuzzed_data_provider.ConsumeBool() ?
160 2021-05-04T11:44:22  <jonatack> er, ConsumeEnum, mistyped...or do we prefer to avoid changing enums to use it
161 2021-05-04T11:45:35  *** prayank <prayank!~andr0irc@2402:8100:206c:68c8:30b0:af4b:7735:463b> has quit IRC (Ping timeout: 250 seconds)
162 2021-05-04T11:47:01  *** prayank <prayank!~andr0irc@2402:8100:206c:68c8:2d54:9856:1ebd:884f> has joined #bitcoin-core-dev
163 2021-05-04T11:52:59  *** bithees <bithees!6e25f434@WGPON-37244-52.wateen.net> has joined #bitcoin-core-dev
164 2021-05-04T11:53:21  *** bithees <bithees!6e25f434@WGPON-37244-52.wateen.net> has quit IRC (Client Quit)
165 2021-05-04T11:55:40  <jonatack> will propose using ConsumeEnum() and see what reviewers say
166 2021-05-04T12:06:43  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
167 2021-05-04T12:06:44  <bitcoin-git> [bitcoin] kiminuo opened pull request #21850: Remove `GetDataDir(net_specific)` function (master...feature/2021-05-get-data-dir-step-2) https://github.com/bitcoin/bitcoin/pull/21850
168 2021-05-04T12:06:44  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
169 2021-05-04T12:16:30  *** ShapeShifter499 <ShapeShifter499!~ShapeShif@unaffiliated/shapeshifter499> has joined #bitcoin-core-dev
170 2021-05-04T12:25:27  *** Zao_ <Zao_!~Zao_@> has quit IRC (Remote host closed the connection)
171 2021-05-04T12:33:42  *** OldMiner <OldMiner!~OldMiner@> has joined #bitcoin-core-dev
172 2021-05-04T12:33:52  *** smartineng <smartineng!~Icedove@> has joined #bitcoin-core-dev
173 2021-05-04T12:45:58  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
174 2021-05-04T12:45:58  <bitcoin-git> [bitcoin] fanquake opened pull request #21851: [WIP] build: support cross-compiling for arm64-apple-darwin20 (Apple M1) in depends (master...m1_support_depends) https://github.com/bitcoin/bitcoin/pull/21851
175 2021-05-04T12:45:59  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
176 2021-05-04T12:46:41  *** GarouDan <GarouDan!~GarouDan@> has joined #bitcoin-core-dev
177 2021-05-04T12:58:45  *** braydonf_ <braydonf_!~braydon@gateway/tor-sasl/braydonf> has quit IRC (Ping timeout: 240 seconds)
178 2021-05-04T12:59:37  *** braydonf_ <braydonf_!~braydon@gateway/tor-sasl/braydonf> has joined #bitcoin-core-dev
179 2021-05-04T13:07:45  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
180 2021-05-04T13:07:46  <bitcoin-git> [bitcoin] MarcoFalke opened pull request #21852: ci: Add msan fuzz config (master...2105-ci12Msan) https://github.com/bitcoin/bitcoin/pull/21852
181 2021-05-04T13:07:47  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
182 2021-05-04T13:08:56  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
183 2021-05-04T13:08:56  <bitcoin-git> [bitcoin] fanquake closed pull request #21414: doc: add arm macOS depends platform triplet (master...macOS-platform-triplets) https://github.com/bitcoin/bitcoin/pull/21414
184 2021-05-04T13:08:57  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
185 2021-05-04T13:15:19  *** mol_ <mol_!~mol@unaffiliated/molly> has joined #bitcoin-core-dev
186 2021-05-04T13:17:53  *** mol <mol!~mol@unaffiliated/molly> has quit IRC (Ping timeout: 246 seconds)
187 2021-05-04T13:20:02  *** jespada <jespada!~jespada@> has joined #bitcoin-core-dev
188 2021-05-04T13:24:17  *** smctwo <smctwo!~smctwo@> has joined #bitcoin-core-dev
189 2021-05-04T13:25:44  *** prayank <prayank!~andr0irc@2402:8100:206c:68c8:2d54:9856:1ebd:884f> has quit IRC (Quit: irc thread exit)
190 2021-05-04T13:28:13  *** smctwo <smctwo!~smctwo@> has quit IRC (Ping timeout: 240 seconds)
191 2021-05-04T13:33:05  *** ghost43 <ghost43!~daer@gateway/tor-sasl/daer> has quit IRC (Remote host closed the connection)
192 2021-05-04T13:33:30  *** ghost43 <ghost43!~daer@gateway/tor-sasl/daer> has joined #bitcoin-core-dev
193 2021-05-04T13:34:21  *** mips <mips!~mips@gateway/tor-sasl/mips> has quit IRC (Ping timeout: 240 seconds)
194 2021-05-04T13:40:36  *** undvrainbowvita8 <undvrainbowvita8!~egp_@128-71-13-3.broadband.corbina.ru> has quit IRC (Ping timeout: 268 seconds)
195 2021-05-04T13:55:41  *** mol_ <mol_!~mol@unaffiliated/molly> has quit IRC (Ping timeout: 260 seconds)
196 2021-05-04T14:07:59  *** mol <mol!~mol@unaffiliated/molly> has joined #bitcoin-core-dev
197 2021-05-04T14:12:45  *** xenial-user <xenial-user!~puppy@host109-156-143-160.range109-156.btcentralplus.com> has joined #bitcoin-core-dev
198 2021-05-04T14:14:05  *** xenial-user <xenial-user!~puppy@host109-156-143-160.range109-156.btcentralplus.com> has left #bitcoin-core-dev
199 2021-05-04T14:39:17  *** ShapeShifter499 <ShapeShifter499!~ShapeShif@unaffiliated/shapeshifter499> has quit IRC (Quit: ShapeShifter499)
200 2021-05-04T14:43:33  *** braydonf_ <braydonf_!~braydon@gateway/tor-sasl/braydonf> has quit IRC (Ping timeout: 240 seconds)
201 2021-05-04T14:44:37  *** braydonf_ <braydonf_!~braydon@gateway/tor-sasl/braydonf> has joined #bitcoin-core-dev
202 2021-05-04T14:49:58  *** cguida1 <cguida1!~Adium@2806:2f0:51c1:5cee:e16e:b2eb:67a2:57d9> has joined #bitcoin-core-dev
203 2021-05-04T14:53:27  *** cguida <cguida!~Adium@2806:2f0:51c1:5cee:ec28:28d8:7d26:5683> has quit IRC (Ping timeout: 260 seconds)
204 2021-05-04T15:00:54  <vasild> sdaftuar: https://github.com/bitcoin/bitcoin/pull/20685#discussion_r625856311 -- maybe the i2p router was restarted or the connection to it was interrupted in some way and the i2p thread did RemoveLocal() (here: https://github.com/bitcoin/bitcoin/blob/0ca8b7e7ecd5bc537fbc1e372f6755a34a136f7f/src/net.cpp#L2232-L2234) which undid the initial AddLocal(MANUAL) due to externalip
205 2021-05-04T15:01:39  <vasild> later when the connection was reestablished the i2p thread does AddLocal(BIND) which is not "strong" enough to overcome fDiscover==false
206 2021-05-04T15:02:10  <vasild> sounds plausible?
207 2021-05-04T15:03:53  *** stortz <stortz!c8b9c69a@unaffiliated/stortz> has joined #bitcoin-core-dev
208 2021-05-04T15:06:25  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
209 2021-05-04T15:06:26  <bitcoin-git> [bitcoin] MarcoFalke pushed 4 commits to master: https://github.com/bitcoin/bitcoin/compare/0ca8b7e7ecd5...a1c6434e19bc
210 2021-05-04T15:06:27  <bitcoin-git> bitcoin/master fab3017 MarcoFalke: ci: Set BASE_SCRATCH_DIR early, so that it can be used in test configs
211 2021-05-04T15:06:27  <bitcoin-git> bitcoin/master fa399a7 MarcoFalke: ci: Use clang-12 in msan task
212 2021-05-04T15:06:28  <bitcoin-git> bitcoin/master fa0422c MarcoFalke: ci: Add msan fuzz config
213 2021-05-04T15:06:36  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
214 2021-05-04T15:06:55  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
215 2021-05-04T15:06:56  <bitcoin-git> [bitcoin] MarcoFalke merged pull request #21852: ci: Add msan fuzz config (master...2105-ci12Msan) https://github.com/bitcoin/bitcoin/pull/21852
216 2021-05-04T15:06:57  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
217 2021-05-04T15:07:15  <jonatack> update on FuzzedDataProvider::ConsumeEnum(), proposed to allow passing it a std::optional<T> max_value, so ConsumeEnum() may be used without needing to change existing enums.
218 2021-05-04T15:08:32  <vasild> does it assume contigious values starting from 0?
219 2021-05-04T15:08:44  <jonatack> yes, same as before
220 2021-05-04T15:09:02  <jonatack> only avoids having to add an alias to the enum in the codebase
221 2021-05-04T15:09:04  <vasild> yeah, can't be otherwise :/
222 2021-05-04T15:11:02  <jonatack> otherwise, there's the existing ConsumeWeakEnum(values list...
223 2021-05-04T15:23:20  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
224 2021-05-04T15:23:21  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/a1c6434e19bc...3f8f238deb5a
225 2021-05-04T15:23:21  <bitcoin-git> bitcoin/master cf83b82 MarcoFalke: fuzz: Limit toxic test globals to their respective scope
226 2021-05-04T15:23:22  <bitcoin-git> bitcoin/master 3f8f238 MarcoFalke: Merge bitcoin/bitcoin#21849: fuzz: Limit toxic test globals to their respe...
227 2021-05-04T15:23:23  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
228 2021-05-04T15:23:41  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
229 2021-05-04T15:23:41  <bitcoin-git> [bitcoin] MarcoFalke merged pull request #21849: fuzz: Limit toxic test globals to their respective scope (master...2105-fuzzToxic) https://github.com/bitcoin/bitcoin/pull/21849
230 2021-05-04T15:23:42  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
231 2021-05-04T15:50:44  <luke-jr> hugohn: I think what it is missing, is something like "This BIP is not compatible with existing multisig software/hardware at all."
232 2021-05-04T15:50:56  <luke-jr> (unless it is)
233 2021-05-04T15:51:46  *** smctwo <smctwo!~smctwo@> has joined #bitcoin-core-dev
234 2021-05-04T15:51:50  *** smctwo <smctwo!~smctwo@> has quit IRC (Remote host closed the connection)
235 2021-05-04T15:52:28  *** smctwo <smctwo!~smctwo@> has joined #bitcoin-core-dev
236 2021-05-04T15:59:57  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
237 2021-05-04T15:59:57  <bitcoin-git> [bitcoin] Relaxo143 opened pull request #21854: doc: make small corrections (v0.21.1 release notes) (master...patch-1) https://github.com/bitcoin/bitcoin/pull/21854
238 2021-05-04T15:59:59  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
239 2021-05-04T16:08:10  *** smctwo_ <smctwo_!~smctwo@> has joined #bitcoin-core-dev
240 2021-05-04T16:08:32  *** smctwo_ <smctwo_!~smctwo@> has quit IRC (Remote host closed the connection)
241 2021-05-04T16:09:05  *** smctwo_ <smctwo_!~smctwo@> has joined #bitcoin-core-dev
242 2021-05-04T16:09:05  *** smctwo <smctwo!~smctwo@> has quit IRC (Ping timeout: 260 seconds)
243 2021-05-04T16:13:29  *** GarouDan <GarouDan!~GarouDan@> has quit IRC (Remote host closed the connection)
244 2021-05-04T16:15:20  *** GarouDan_ <GarouDan_!~GarouDan@> has joined #bitcoin-core-dev
245 2021-05-04T16:16:34  *** smctwo <smctwo!~smctwo@> has joined #bitcoin-core-dev
246 2021-05-04T16:17:45  *** stortz <stortz!c8b9c69a@unaffiliated/stortz> has quit IRC (Quit: Connection closed)
247 2021-05-04T16:19:32  *** smctwo_ <smctwo_!~smctwo@> has quit IRC (Ping timeout: 265 seconds)
248 2021-05-04T16:20:01  *** GarouDan_ <GarouDan_!~GarouDan@> has quit IRC (Ping timeout: 265 seconds)
249 2021-05-04T16:20:59  *** smctwo <smctwo!~smctwo@> has quit IRC (Ping timeout: 265 seconds)
250 2021-05-04T16:21:23  *** GarouDan <GarouDan!~GarouDan@> has joined #bitcoin-core-dev
251 2021-05-04T16:24:44  *** smctwo <smctwo!~smctwo@> has joined #bitcoin-core-dev
252 2021-05-04T16:26:29  *** GarouDan <GarouDan!~GarouDan@> has quit IRC (Ping timeout: 268 seconds)
253 2021-05-04T16:26:32  *** smctwo <smctwo!~smctwo@> has quit IRC (Remote host closed the connection)
254 2021-05-04T16:28:21  *** braydonf_ <braydonf_!~braydon@gateway/tor-sasl/braydonf> has quit IRC (Ping timeout: 240 seconds)
255 2021-05-04T16:28:56  *** smctwo <smctwo!~smctwo@> has joined #bitcoin-core-dev
256 2021-05-04T16:28:59  *** lkqwejhhgasdjhgn <lkqwejhhgasdjhgn!~kljkljklk@p200300d46f06bf00ea203cd14cca75b0.dip0.t-ipconnect.de> has quit IRC (Quit: Konversation terminated!)
257 2021-05-04T16:29:35  *** braydonf_ <braydonf_!~braydon@gateway/tor-sasl/braydonf> has joined #bitcoin-core-dev
258 2021-05-04T16:33:39  *** smctwo <smctwo!~smctwo@> has quit IRC (Remote host closed the connection)
259 2021-05-04T17:00:18  *** proofofkeags <proofofkeags!~proofofke@> has joined #bitcoin-core-dev
260 2021-05-04T17:05:09  *** Talkless <Talkless!~Talkless@mail.dargis.net> has joined #bitcoin-core-dev
261 2021-05-04T17:08:38  <michaelfolkson> fanquake: Someone is building Core on Apple M1 here https://bitcoin.stackexchange.com/questions/105126/could-not-detect-boost-libraries-when-configuring-bitcoin-core-apple-m1-mac-mi
262 2021-05-04T17:09:20  *** mol_ <mol_!~mol@unaffiliated/molly> has joined #bitcoin-core-dev
263 2021-05-04T17:10:33  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
264 2021-05-04T17:10:34  <bitcoin-git> [bitcoin] jonatack opened pull request #21855: fuzz: enable passing a max value to FuzzedDataProvider::ConsumeEnum() (master...ConsumeEnum-enable-passing-max-value) https://github.com/bitcoin/bitcoin/pull/21855
265 2021-05-04T17:10:34  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
266 2021-05-04T17:11:06  *** lightlike <lightlike!~lightlike@p200300c7ef197400945876005b846753.dip0.t-ipconnect.de> has joined #bitcoin-core-dev
267 2021-05-04T17:12:28  *** mol <mol!~mol@unaffiliated/molly> has quit IRC (Ping timeout: 252 seconds)
268 2021-05-04T17:18:52  *** smctwo <smctwo!~smctwo@> has joined #bitcoin-core-dev
269 2021-05-04T17:23:17  *** smctwo <smctwo!~smctwo@> has quit IRC (Ping timeout: 260 seconds)
270 2021-05-04T17:23:59  *** GarouDan <GarouDan!~GarouDan@> has joined #bitcoin-core-dev
271 2021-05-04T17:24:24  *** Guyver2 <Guyver2!Guyver@guyver2.xs4all.nl> has joined #bitcoin-core-dev
272 2021-05-04T17:25:45  *** cguida1 <cguida1!~Adium@2806:2f0:51c1:5cee:e16e:b2eb:67a2:57d9> has quit IRC (Quit: Leaving.)
273 2021-05-04T17:36:31  *** jungly <jungly!~jungly@host-82-49-146-18.retail.telecomitalia.it> has quit IRC (Ping timeout: 252 seconds)
274 2021-05-04T17:37:18  *** GarouDan <GarouDan!~GarouDan@> has quit IRC (Remote host closed the connection)
275 2021-05-04T17:42:38  <hugohn> @luke-jr the inclusion of things like NO_ENCRYPTION mode and BIP39-like PBKDF2 function parameters in the spec is to help with backward compatibility. IMO the main thing that might not be backward compatible with all vendors is the stateful nature of the Signers, which I have stated in the Compatibility section.
276 2021-05-04T17:46:35  *** sipsorcery <sipsorcery!~sipsorcer@2a02:8084:6981:7880::3> has quit IRC (Ping timeout: 260 seconds)
277 2021-05-04T17:48:25  *** GarouDan <GarouDan!~GarouDan@> has joined #bitcoin-core-dev
278 2021-05-04T17:52:29  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
279 2021-05-04T17:52:30  <bitcoin-git> [bitcoin] adamjonas opened pull request #21856: doc: add OSS-Fuzz section to fuzzing.md doc (master...add-oss-fuzz) https://github.com/bitcoin/bitcoin/pull/21856
280 2021-05-04T17:52:30  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
281 2021-05-04T17:53:18  *** GarouDan <GarouDan!~GarouDan@> has quit IRC (Ping timeout: 265 seconds)
282 2021-05-04T17:56:05  *** justanotheruser <justanotheruser!~justanoth@unaffiliated/justanotheruser> has quit IRC (Ping timeout: 250 seconds)
283 2021-05-04T17:56:52  *** justanotheruser <justanotheruser!~justanoth@unaffiliated/justanotheruser> has joined #bitcoin-core-dev
284 2021-05-04T17:58:50  *** sipsorcery <sipsorcery!~sipsorcer@2a02:8084:6981:7880::3> has joined #bitcoin-core-dev
285 2021-05-04T17:59:07  *** jarolrod <jarolrod!sid475272@gateway/web/irccloud.com/x-uxltcdqeskugbhyk> has quit IRC (Ping timeout: 245 seconds)
286 2021-05-04T17:59:39  *** dunk <dunk!sid16@gateway/web/irccloud.com/x-szdtiubjgycubtjv> has quit IRC (Ping timeout: 260 seconds)
287 2021-05-04T18:00:44  *** endogenic <endogenic!sid145991@gateway/web/irccloud.com/x-rpbwvsocatvzzacr> has quit IRC (Read error: Connection reset by peer)
288 2021-05-04T18:00:51  *** digi_james <digi_james!sid281632@gateway/web/irccloud.com/x-bnvrcpkdhkxgxzpl> has quit IRC (Ping timeout: 250 seconds)
289 2021-05-04T18:01:52  *** digi_james <digi_james!sid281632@gateway/web/irccloud.com/x-denjnhnlzrimsgue> has joined #bitcoin-core-dev
290 2021-05-04T18:02:01  *** endogenic <endogenic!sid145991@gateway/web/irccloud.com/x-ygsbkwstspmhypgh> has joined #bitcoin-core-dev
291 2021-05-04T18:02:09  *** jarolrod <jarolrod!sid475272@gateway/web/irccloud.com/x-urbxualqfzlausno> has joined #bitcoin-core-dev
292 2021-05-04T18:02:15  *** dunk <dunk!sid16@gateway/web/irccloud.com/x-iomuwjcindcxowba> has joined #bitcoin-core-dev
293 2021-05-04T18:02:22  *** hebasto <hebasto!sid449604@gateway/web/irccloud.com/x-gkvwysjshowrbwdf> has quit IRC (Ping timeout: 258 seconds)
294 2021-05-04T18:04:34  *** hebasto <hebasto!sid449604@gateway/web/irccloud.com/x-legvqghpryoffxkf> has joined #bitcoin-core-dev
295 2021-05-04T18:07:37  *** owowo <owowo!~ovovo@unaffiliated/ovovo> has quit IRC (Ping timeout: 260 seconds)
296 2021-05-04T18:10:32  *** owowo <owowo!~ovovo@2a02:29b8:dc01:1881::2e> has joined #bitcoin-core-dev
297 2021-05-04T18:19:20  *** IcKingAlpha <IcKingAlpha!~ident@> has joined #bitcoin-core-dev
298 2021-05-04T18:21:08  <robert_spigler> luke-jr: I agree with hugohn's analysis
299 2021-05-04T18:22:52  *** vincenzopalazzo <vincenzopalazzo!~vincenzop@host-79-37-17-61.retail.telecomitalia.it> has quit IRC (Quit: Leaving)
300 2021-05-04T19:02:59  *** pox <pox!~pox@gateway/tor-sasl/pox> has quit IRC (Remote host closed the connection)
301 2021-05-04T19:04:38  *** pox <pox!~pox@gateway/tor-sasl/pox> has joined #bitcoin-core-dev
302 2021-05-04T19:05:17  *** Talkless <Talkless!~Talkless@mail.dargis.net> has quit IRC (Quit: Konversation terminated!)
303 2021-05-04T19:06:48  *** p0x <p0x!~pox@gateway/tor-sasl/pox> has joined #bitcoin-core-dev
304 2021-05-04T19:07:00  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
305 2021-05-04T19:07:01  <bitcoin-git> [bitcoin] Rqcker opened pull request #21857: Pull request (master...master) https://github.com/bitcoin/bitcoin/pull/21857
306 2021-05-04T19:07:01  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
307 2021-05-04T19:07:20  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
308 2021-05-04T19:07:21  <bitcoin-git> [bitcoin] Rqcker closed pull request #21857: Pull request (master...master) https://github.com/bitcoin/bitcoin/pull/21857
309 2021-05-04T19:07:21  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
310 2021-05-04T19:09:33  *** pox <pox!~pox@gateway/tor-sasl/pox> has quit IRC (Ping timeout: 240 seconds)
311 2021-05-04T19:16:15  *** justanotheruser <justanotheruser!~justanoth@unaffiliated/justanotheruser> has quit IRC (Ping timeout: 250 seconds)
312 2021-05-04T19:20:29  *** sat <sat!571594ac@host-87-21-148-172.retail.telecomitalia.it> has joined #bitcoin-core-dev
313 2021-05-04T19:23:00  *** duringo <duringo!2d57d6c5@> has joined #bitcoin-core-dev
314 2021-05-04T19:28:45  *** braydonf_ <braydonf_!~braydon@gateway/tor-sasl/braydonf> has quit IRC (Ping timeout: 240 seconds)
315 2021-05-04T19:29:35  *** braydonf_ <braydonf_!~braydon@gateway/tor-sasl/braydonf> has joined #bitcoin-core-dev
316 2021-05-04T19:30:10  *** sat <sat!571594ac@host-87-21-148-172.retail.telecomitalia.it> has quit IRC (Quit: Connection closed)
317 2021-05-04T19:38:06  *** mol_ <mol_!~mol@unaffiliated/molly> has quit IRC (Ping timeout: 260 seconds)
318 2021-05-04T19:45:13  *** mol <mol!~mol@unaffiliated/molly> has joined #bitcoin-core-dev
319 2021-05-04T19:46:21  *** duringo <duringo!2d57d6c5@> has quit IRC (Quit: Connection closed)
320 2021-05-04T19:53:48  *** biteskola <biteskola!~biteskola@> has joined #bitcoin-core-dev
321 2021-05-04T19:58:36  <luke-jr> robert_spigler: I'm not saying it should or shouldn't be a certain answer - but it needs to be in the BIP, whatever it is :p
322 2021-05-04T19:58:51  *** justanotheruser <justanotheruser!~justanoth@unaffiliated/justanotheruser> has joined #bitcoin-core-dev
323 2021-05-04T20:10:02  *** smartineng <smartineng!~Icedove@> has quit IRC (Quit: smartineng)
324 2021-05-04T20:16:19  *** p0x <p0x!~pox@gateway/tor-sasl/pox> has quit IRC (Remote host closed the connection)
325 2021-05-04T20:18:27  *** OldMiner <OldMiner!~OldMiner@> has quit IRC (Remote host closed the connection)
326 2021-05-04T20:18:35  *** pox <pox!~pox@gateway/tor-sasl/pox> has joined #bitcoin-core-dev
327 2021-05-04T20:22:58  *** zpao <zpao!~zpao@> has joined #bitcoin-core-dev
328 2021-05-04T20:52:11  <jnewbery> Hi folks. We have a p2p meeting scheduled in 10 minutes. Currently there aren't any proposed topics at https://github.com/bitcoin-core/bitcoin-devwiki/wiki/P2P-IRC-meetings.
329 2021-05-04T20:55:44  <gmaxwell> Current bitcoin core causes really old nodes to be unable to sync and to dos attack you.  The issue is that prior to 0.7-ish the size of headers messages wasn't limited, and the node requests headers from everyone.  They blast you with a multimegabyte header and disconnect and go do it to someoen else.  These old nodes seem to have also formed a fork at an early height, nodes that have this
330 2021-05-04T20:55:50  <gmaxwell> fork will send it to you and get rejected for sending a fork before the highest checkpoing-- another product of requesting headers.
331 2021-05-04T20:56:04  *** duringo <duringo!c11b0cfd@> has joined #bitcoin-core-dev
332 2021-05-04T20:56:28  <gmaxwell> Fixing this appears to be trivial: Just don't ever request headers from peers that aren't NODE_WITNESS-- the node will never request blocks from them anyways.   But I changed this and it breaks like a dozen tests, some of which didn't seem trivial to fix.
333 2021-05-04T20:56:34  <gmaxwell> Someone who cares about p2p might want to fix this.
334 2021-05-04T20:58:12  <gmaxwell> (until I stopped sending headers reqests to non-node witness peers, this garbage was few percent of my (pruned) node's bandwidth usage)
335 2021-05-04T20:59:05  *** wumpus <wumpus!~ircclient@pdpc/supporter/professional/wumpus> has quit IRC (Ping timeout: 258 seconds)
336 2021-05-04T20:59:06  <gmaxwell> (my correct behavior might be slowly fixing the second forked-chain problem since I should be healing the partition)
337 2021-05-04T21:00:04  *** wumpus <wumpus!~ircclient@pdpc/supporter/professional/wumpus> has joined #bitcoin-core-dev
338 2021-05-04T21:00:29  <jnewbery> #startmeeting
339 2021-05-04T21:00:29  <core-meetingbot> Meeting started Tue May  4 21:00:29 2021 UTC.  The chair is jnewbery. Information about MeetBot at https://bitcoin.jonasschnelli.ch/ircmeetings.
340 2021-05-04T21:00:29  <core-meetingbot> Available commands: action commands idea info link nick
341 2021-05-04T21:00:34  <amiti> hi
342 2021-05-04T21:00:36  <jnewbery> #bitcoin-core-dev Meeting: achow101 aj amiti ariard bluematt cfields Chris_Stewart_5 digi_james dongcarl elichai2 emilengler fanquake fjahr gleb glozow gmaxwell gwillen hebasto instagibbs jamesob jb55 jeremyrubin jl2012 jnewbery jonasschnelli jonatack jtimon kallewoof kanzure kvaciral lightlike luke-jr maaku marcofalke meshcollider michagogo moneyball morcos nehan NicolasDorier paveljanik
343 2021-05-04T21:00:36  <gleb> hi
344 2021-05-04T21:00:42  <glozow> hi
345 2021-05-04T21:00:42  <jnewbery> petertodd phantomcircuit promag provoostenator ryanofsky sdaftuar sipa vasild wumpus
346 2021-05-04T21:00:48  <sipa> hi
347 2021-05-04T21:00:58  <ajonas> hi
348 2021-05-04T21:01:03  <jnewbery> There aren't any proposed topics in https://github.com/bitcoin-core/bitcoin-devwiki/wiki/P2P-IRC-meetings
349 2021-05-04T21:01:20  <jnewbery> Feel free to share your priorities in https://github.com/bitcoin-core/bitcoin-devwiki/wiki/P2P-Current-Priorities
350 2021-05-04T21:01:36  <jnewbery> Does anyone have any topics to add?
351 2021-05-04T21:02:06  <sipa> i'm working on PR'ing minisketch
352 2021-05-04T21:02:17  <sipa> i think it's in a good enough state now
353 2021-05-04T21:02:46  <jnewbery> \o/
354 2021-05-04T21:02:52  <gleb> sipa: thank you! I'm working on more or less finalizing erlay to invite people running nodes. Fully went through antoine's review, gonna make one protocol tweak it seems.
355 2021-05-04T21:03:02  <gleb> *to invite people to run nodes.
356 2021-05-04T21:03:18  <sipa> gleb: cool, will run
357 2021-05-04T21:03:22  <glozow> \o/
358 2021-05-04T21:03:37  <jnewbery> sipa: are you looking for any specific help?
359 2021-05-04T21:04:10  <sipa> not in particular, but review is of course always welcome
360 2021-05-04T21:04:44  <sipa> with this PR https://github.com/sipa/minisketch/pull/20 (making us able to just build field size 32 instead of everything) the binary size goes from 3 MB to 64 KiB
361 2021-05-04T21:04:52  <sipa> also way faster compilation
362 2021-05-04T21:05:09  <jnewbery> that seems good
363 2021-05-04T21:06:13  <jnewbery> ok, any other topics?
364 2021-05-04T21:07:01  <jnewbery> alright!
365 2021-05-04T21:07:03  <jnewbery> #endmeeting
366 2021-05-04T21:07:04  <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
367 2021-05-04T21:07:04  <core-meetingbot> Meeting ended Tue May  4 21:07:03 2021 UTC.
368 2021-05-04T21:07:04  <core-meetingbot> Minutes:        https://bitcoin.jonasschnelli.ch/ircmeetings/logs/bitcoin-core-dev/2021/bitcoin-core-dev.2021-05-04-21.00.moin.txt
369 2021-05-04T21:08:21  *** braydonf_ <braydonf_!~braydon@gateway/tor-sasl/braydonf> has quit IRC (Ping timeout: 240 seconds)
370 2021-05-04T21:09:03  <jnewbery> gmaxwell: I'm surprised there are a dozen tests with nodes that aren't signalling NODE_WITNESS. Do you have a branch?
371 2021-05-04T21:09:35  *** braydonf_ <braydonf_!~braydon@gateway/tor-sasl/braydonf> has joined #bitcoin-core-dev
372 2021-05-04T21:10:26  <jnewbery> as far as I'm aware, the only functional test with a node that doesn't signal NODE_WITNESS is p2p_segwit.py (and that should be removed in #21090
373 2021-05-04T21:10:28  <gribble> https://github.com/bitcoin/bitcoin/issues/21090 | Default to NODE_WITNESS in nLocalServices by dhruv · Pull Request #21090 · bitcoin/bitcoin · GitHub
374 2021-05-04T21:12:47  *** Guyver2 <Guyver2!Guyver@guyver2.xs4all.nl> has quit IRC (Quit: Going offline, see ya! (www.adiirc.com))
375 2021-05-04T21:14:38  <gmaxwell> Well dozen is probably an exaggeration, it was more than p2p_segwit.   This might implement the expected functionality: https://0bin.net/paste/1ugjq4jz#XcT5A29tp0YlpDnYDs9NRD92Z9myByRpsJOMzwButl4
376 2021-05-04T21:15:02  <gmaxwell> (I say might because the patch I run locally is much larger, but it looks like I previously saved out that chunk while trying to run the tests.)
377 2021-05-04T21:17:26  <gmaxwell> gleb: what protocol change?
378 2021-05-04T21:17:29  *** smctwo <smctwo!~smctwo@bba597217.alshamil.net.ae> has joined #bitcoin-core-dev
379 2021-05-04T21:17:35  <jnewbery> Did you try gating on fHaveWitness instead of fClient?
380 2021-05-04T21:17:45  *** GarouDan <GarouDan!~GarouDan@> has joined #bitcoin-core-dev
381 2021-05-04T21:20:23  <gmaxwell> No, though we shouldn't be sending headers requests to non-node-network peers either--. But ah, I see your point wrt implicated tests.
382 2021-05-04T21:21:20  <gleb> gmaxwell: antoine found this inconsistency, let me explain here in short (full convo is here: https://github.com/bitcoin/bitcoin/pull/21515#discussion_r624952992)
383 2021-05-04T21:21:50  <sipa> gleb: was it needed to include minisketch in bitcoin-tx?
384 2021-05-04T21:22:33  <gmaxwell> (my sequence was that I just fixed it for myself to see that it fixed the behavior... then just tried running the tests to see if it looked like it would be easy to submit upstream,  it failed a number of tests, so I just dropped it into the patch I carry.
385 2021-05-04T21:23:41  <gleb> gmaxwell: Ah hold on, maybe ignore that.
386 2021-05-04T21:23:51  <gleb> I just realized maybe it's fine all the way.
387 2021-05-04T21:24:12  <gleb> sipa: sorry, are you referring to the way I integrate minisketch in the erlay PR?
388 2021-05-04T21:24:38  <sipa> gleb: yeah, cherry picking that
389 2021-05-04T21:24:43  <sipa> just wonder if there was a reason for that
390 2021-05-04T21:25:30  <gleb> gmaxwell: yeah indeed, I withdraw my comment, no protocol tweaks. Will finish last touches per antoine feedback tomorrow, and freeze the version to run nodes.
391 2021-05-04T21:26:25  <gmaxwell> gleb: good because I was about to respond to you hear after reading that saying I didn't undrestand the issue there. :P
392 2021-05-04T21:26:56  <gleb> gmaxwell: I'm glad you're following the work anyway.
393 2021-05-04T21:27:38  <gmaxwell> gleb: I think in general when we talk about erlay (e.g. in the paper and elsewhere) we use this "non-reachable peer" terminology, but non-reachability doesn't exist explicitly anywhere in the implementation of bitcoin core or the bitcoin protocol... so although non-reachable peers were a good concept for modling, it can be a little confusing when it comes to the implementation.
394 2021-05-04T21:29:06  <gleb> gmaxwell: Agree, I should think if I could gracefully disconnect the "general intuition" from protocol language.
395 2021-05-04T21:29:52  <sipa> right, the protocol should only concern itself with "inbound" and "outbound" and "recon sender" and "recon receiver"
396 2021-05-04T21:30:20  <gleb> Also, I should think about non-reachable nodes with a node from the same NAT or something, I just realized our current approach is prone in this case?
397 2021-05-04T21:31:07  *** GarouDan <GarouDan!~GarouDan@> has quit IRC (Remote host closed the connection)
398 2021-05-04T21:31:49  *** undvrainbowvita8 <undvrainbowvita8!~egp_@128-71-13-3.broadband.corbina.ru> has joined #bitcoin-core-dev
399 2021-05-04T21:31:55  <gleb> Say my "non-reachable" node A (as the peers can easily tell by probing IP) has my own trusted inbound node B and that's the only connection for B, then the peers can easily tell that transactions flooded from B are either from B or from A.
400 2021-05-04T21:32:12  <gleb> I should admit I never considered this corner case.
401 2021-05-04T21:33:11  <sipa> hmm, do we just want to disable reconciliation on connections to/from non-public IPs?
402 2021-05-04T21:33:35  <gmaxwell> that shouldn't be neceesary.
403 2021-05-04T21:34:18  <sipa> i think the problem is: you have internal node A, only connected to bridge node B, which is connected to the public network
404 2021-05-04T21:35:19  <sipa> if A relay a tx to B, B will treat this as being a reachable node, and use erlay to relay it further... which it would never do if B were just a non-reachable node without internal nodes behind it?
405 2021-05-04T21:35:20  <gleb> sipa: right. Or maybe if there are N bridges, but A is still generally unavailable.
406 2021-05-04T21:36:18  <sipa> sorry, i swapped notation; my A and B are the B and A in your explanation
407 2021-05-04T21:37:04  <gmaxwell> I don't want to comment much because I've probably forgotten everything but this seems confused to me.  The privacy loss comes from flooding conditionally flooding, using the reconcillation itself is just additive and harmless.
408 2021-05-04T21:37:04  <sipa> gleb: is the logic "only use recon for transaction received from inbound connections" now?
409 2021-05-04T21:37:21  <gleb> sipa: only use flood in that case.
410 2021-05-04T21:37:40  <gleb> Ok, there are 2 relevant flags.
411 2021-05-04T21:37:45  <sipa> gmaxwell: the choice whether to relay through recon or flood reveals information
412 2021-05-04T21:38:17  <gmaxwell> sipa: It should always relay through recon (otherwise it's potentially just adding missed items to the sets), it might choose to additionally relay through flooding.
413 2021-05-04T21:38:29  <sipa> gmaxwell: that's not what erlay proposes
414 2021-05-04T21:38:55  <gmaxwell> I don't remember it being broken. :P
415 2021-05-04T21:39:01  <gleb> sipa is correct, it was always either or
416 2021-05-04T21:39:03  <sipa> come on
417 2021-05-04T21:39:14  <gmaxwell> sipa: failing to add it to recon strictly wastes bandwidth, unless I'm confused.
418 2021-05-04T21:39:23  <gmaxwell> Quite possible I'm confused.
419 2021-05-04T21:39:55  <gmaxwell> If you don't add it to recon but your remote peer does, you just end up with a fake difference.
420 2021-05-04T21:40:11  <gmaxwell> As your remote peer won't make the same flood/no-flood decision you do.
421 2021-05-04T21:40:44  <gmaxwell> Am I confused?
422 2021-05-04T21:40:50  <sipa> i'm trying to swap in the whole idea again :)
423 2021-05-04T21:40:57  <gleb> Yeah same here, gimme a second.
424 2021-05-04T21:41:00  <sipa> gleb: what happens with locally generated transactions?
425 2021-05-04T21:41:05  <gmaxwell> I don't think this changes the fundimental issue gleb is looking at though.
426 2021-05-04T21:41:18  <gmaxwell> But I'm trying to remember how any of this works so every piece of confusion is standing out for me.
427 2021-05-04T21:41:52  <gleb> sipa: The idea was to always reconcile local transactions. It's done to preserve privacy of non-reachable, but you won't understand why unless you know the full protocol...
428 2021-05-04T21:42:46  <sipa> gleb: so in which cases do you only flood a tx?
429 2021-05-04T21:43:57  <gleb> sipa: if the transaction is received from inbound AND the peer is 1 of 8 outbound flooding peers.
430 2021-05-04T21:44:44  <gleb> The idea is: non reachable has no inbounds, so they never flood (so local txs should also not be flooded)
431 2021-05-04T21:44:45  <sipa> which for now is effectively all outbound peers?
432 2021-05-04T21:45:04  <gleb> sipa: yes, now. ANd my confusion was the case after bump, but now I think that case is fine.
433 2021-05-04T21:45:19  <gleb> The bridge case is not fine though. When this non-reachable is a bridge.
434 2021-05-04T21:45:42  <gmaxwell> If a transaction that comes in from an inbound peers is only flooded out and not reconciled, how will those txn ever end up in reconcoillation? :P
435 2021-05-04T21:45:53  <sipa> i believe the solution is just changing the criterion to "received from inbound *with public IP* AND ..."
436 2021-05-04T21:46:05  <gmaxwell> ehhh
437 2021-05-04T21:46:28  <sipa> but i still want to understand this again
438 2021-05-04T21:46:39  <sipa> because i don't remember why this flooding is done in the first place
439 2021-05-04T21:47:20  <gmaxwell> I still don't believe that it floods instead of reconcilling rather than in addition to, I think that is either transparently wrong or I'm badly corrupted. :)
440 2021-05-04T21:47:36  <sipa> gleb: you say "received", is that both when received through flooding and through recon?
441 2021-05-04T21:48:26  <gleb> sipa: currently there is no distinction, since we added an extra round for INV (just non-duplicate INV). It's possible to compare by short id, but currently I don't.
442 2021-05-04T21:48:36  <gleb> It all looks like inbound inv.
443 2021-05-04T21:48:47  <sipa> ok, just trying to reconcile my memory
444 2021-05-04T21:49:02  <gleb> gmaxwell: I have to think why I didn't do additive
445 2021-05-04T21:49:21  <lightlike> isn't recon/flooding a property of the connection instead of the transaction? So that a tx received from an inbound would be flooded to outbounds, but reconciled with other inbound peers?
446 2021-05-04T21:49:33  <sipa> lightlike: no
447 2021-05-04T21:49:41  <sipa> (well, both)
448 2021-05-04T21:49:45  <gmaxwell> My stored approximation of early is that you reconcile with peers, and also flood each transaction you recieve, regardless of how you recieve them, with low fanout to outbound peers (obeying the normal rules about not sending a peer a txn you already know they have).  I know this isn't exact in the details.
449 2021-05-04T21:49:45  <gleb> yeah, both.
450 2021-05-04T21:50:31  <sipa> so the decision to flood and not reconcile should correspond to a prediction that you will have that tx while your peer won't
451 2021-05-04T21:50:56  <sipa> how does "received from an inbound connection" lead to that prediction?
452 2021-05-04T21:51:38  <gleb> gmaxwell: The problem with that is that non-reachable nodes will do too much useless flooding. They learn a transaction from 1 reconciliation, and then they flood to all the rest outbound peers?
453 2021-05-04T21:51:43  <gmaxwell> gleb: If nodeA and nodeB  both recieve tx X,  and nodeA decides to recon it, and nodeB decides to flood it,  then the recon wastes bandwidth.  The process I understood you describing above wouldn't have peers making the same recon decision for the same txn...
454 2021-05-04T21:52:08  <gleb> gmaxwell: ok, my approach works, and let me explain.
455 2021-05-04T21:52:38  <gmaxwell> gleb: that is why the flooded relay is low fanout.
456 2021-05-04T21:52:42  <gleb> Node A doesn't add tx to the set_B because it flooded the tx to B. Node B doesn't add it to the set_A because it was received from A.
457 2021-05-04T21:52:55  <gleb> That's why both sets won't have the tx at the end
458 2021-05-04T21:53:54  <gmaxwell> gleb: But node_b also could have recieved it from someone else first.
459 2021-05-04T21:54:16  <sipa> yes, it's clear to me you don't want to both flood and add to recon set, because the peer won't relay the tx back from to, so adding it to the set would hurt reconciliation
460 2021-05-04T21:54:49  <gmaxwell> sipa: Why wouldn't they add the flooded txn to it, if was new to them?  It's free if both sides have it.
461 2021-05-04T21:54:53  <sipa> the question is why is there an assumption in this received-from-inbound-and-relay-to-outbound case that there won't be a relay in the other direction (as in: why can't the peer have learned the tx from elsewhere)
462 2021-05-04T21:55:54  <sipa> gmaxwell: any tx you actually receive announced through flooding you can delete from that peer's recon set (not sure if the current implementation does that), but if it does, that seems strictly better than adding
463 2021-05-04T21:55:58  <sipa> (in case you flood)
464 2021-05-04T21:56:19  <gmaxwell> Consider, nodeb gets a txn from c,  nodea also gets a txn from c.  Nodea elects to flood it to a, nodeb elects to recon it to a.  Now there is an excess set difference.  If instead nodea flooded it and added it to recon, and B did as well (including for flooded txn recieved from a) the only time there would be a retcon difference is during a race with the flooding.
465 2021-05-04T21:56:19  <sipa> delete if it was in that set in the first place, of course
466 2021-05-04T21:56:39  <gmaxwell> okay I agree that would also work.
467 2021-05-04T21:57:06  <gleb> Yeah, I see the point indeed. We should get rid of this extra assumption
468 2021-05-04T21:57:10  <gmaxwell> I think they're ... the same?  in both cases you get a extra item in recon during a race between a flood and a recon.
469 2021-05-04T21:57:59  <sipa> gleb: do you do this currently in the code? if i INV a tx to you for whatever reason, and that tx was in your recon set with me, do you delete it from that set?
470 2021-05-04T21:58:21  <gleb> sipa: now, but I'm realizing now I should.
471 2021-05-04T21:58:32  <sipa> gmaxwell: yeah, you either want to both add it, or both delete it when flooded- deleting seems slightly more efficient
472 2021-05-04T21:58:46  <gmaxwell> In any case, the model where everything is recon and some flooding occurs at low order doesn't have the issue that outbound only nodes behave differently, other than they just happened to not recieve any txn via flooding so they'll get txn later.   I'm not arguing that it should work that way, just trying to remember the motivation for it not working that way.
473 2021-05-04T21:59:31  <gmaxwell> sipa: Agreed. Though I'm not clear why deleting is slightly more effcicient? just that never adding it on one side takes less computation?
474 2021-05-04T21:59:50  <sipa> gmaxwell: yes, it ~ns scal different
475 2021-05-04T22:00:03  <sipa> not adding on both sides
476 2021-05-04T22:00:53  <gleb> gmaxwell: well, I chose to reconcile in a queue-manner every 2 seconds (16 seconds per peer). And the queue consists of outbounds.
477 2021-05-04T22:01:18  <gleb> If we stick to these rules, we also want to flood some to make relay across the "backbone" faster.
478 2021-05-04T22:01:28  <gleb> gmaxwell: how would you suggest to flood?
479 2021-05-04T22:02:34  <gleb> My suggestion is to flood to fixed 8 outbounds, and only what was received inbound. In that case, it just gets relayed though the network of reachable nodes super fast, without non-reachable doing useless stuff ever.
480 2021-05-04T22:03:05  <gmaxwell> sipa: GOOD. I am glad to agree!
481 2021-05-04T22:03:40  <gmaxwell> gleb: okay, I don't understand how I was ever okay with that. lol
482 2021-05-04T22:04:22  <gmaxwell> The issue is that it imposes a strong assumption on the existance of a "non-reachable node" -- which as you are realizing now (and maybe did before?) -- no such clean distinction really exists.
483 2021-05-04T22:04:41  <gmaxwell> (e.g. the NATed node with some lan peers)
484 2021-05-04T22:05:01  <gleb> gmaxwell: not really, I never have "if non-reachable". It just makes this implicit categorization by looking at "txs received inbound"
485 2021-05-04T22:05:13  <gleb> Which is, yeah, not true for NAT stuff.
486 2021-05-04T22:07:09  <gmaxwell> I don't have any of our old discussions-- lost the server :( -- it might be useful to see how we changed from "flood each new txn to a few outbound peers" to "flood to 8 outbound peers (currently all) but only things learned from inbound peers"?
487 2021-05-04T22:08:00  <sipa> gmaxwell: by new do you mean "locally created", or "any new tx learned through whatever means at all" ?
488 2021-05-04T22:08:13  <gleb> gmaxwell: despite us not liking, non-reachable nodes is the majority of the network. If they flood, it's very likely to be useless, because their public peers likely already know the tx.
489 2021-05-04T22:08:17  <sipa> (i assume the second, as the first is a pretty bad privacy leak)
490 2021-05-04T22:08:20  <gmaxwell> newly learned, however we learned it.. flooding, local, retcon.
491 2021-05-04T22:08:25  <gmaxwell> Anything accept to mempool accepts.
492 2021-05-04T22:09:25  <gmaxwell> gleb: yes, its often useless.   But it is still a constant amount of data per accepted transaction.
493 2021-05-04T22:09:31  *** pox <pox!~pox@gateway/tor-sasl/pox> has quit IRC (Remote host closed the connection)
494 2021-05-04T22:09:42  <gmaxwell> (and not an amount that grows with the number of peers it has)
495 2021-05-04T22:10:14  *** pox <pox!~pox@gateway/tor-sasl/pox> has joined #bitcoin-core-dev
496 2021-05-04T22:10:40  <gmaxwell> if fanout > 1 the vast majority of flooding will always be useless.
497 2021-05-04T22:11:01  <gleb> A reconciliation happens every 16 seconds, flood trigger is every 1/2 seconds or something. If flood to only outbound, a non-reachable nodes will flood almost all transactions to their reachable peers. So recon set will be empty?
498 2021-05-04T22:11:24  <gleb> You suggest to try fanout=2/3? If fanout=8, we end up getting 0 gain today (just better scaling)
499 2021-05-04T22:11:53  <sipa> the fact that flooding is only outbound does imply that more well-reachable nodes will learn about transactions faster than less-reachable nodes
500 2021-05-04T22:11:58  <gmaxwell> Right, at least at one point I know I was thinking in terms of fanout=2.
501 2021-05-04T22:13:13  <gmaxwell> perhaps we should reconsider that asymmetry, and instead do something like flooding only happens in one direction on each link,  and whichever side knew more transactions in the last recon is the potentially-flodder.
502 2021-05-04T22:14:28  <sipa> so in that sense i can see how deciding to not flood outbound-received transactions may be a useful optimization... the network structure implies that you're receiving generally from a group of peers who likely are better connected than you are
503 2021-05-04T22:14:43  <gmaxwell> sipa: yes I am starting to see how things ended up here.
504 2021-05-04T22:15:00  <sipa> i don't really see the problem with it
505 2021-05-04T22:15:31  <gleb> And we can always switch to something different if at some point NAT landscape changes?
506 2021-05-04T22:15:37  <gmaxwell> Basically nowhere else in the bitcoin protocol is there this in/out distinction -- just in tx relay privacy timers (which were 'recently' introduced relatively speaking) and in peer eviction.
507 2021-05-04T22:16:29  <gmaxwell> for one thing it takes 80% or whatever of bitcoin nodes out of participation in rapidly forwarding transactions, which seems ... like a really big step to take without an obvious reason.
508 2021-05-04T22:17:01  <gmaxwell> I'm not sure why we'd intentionally do that.
509 2021-05-04T22:18:10  <gleb> gmaxwell: the timings were 1s for 95% reachable, 5s for 95% non-reachable. Something along those numbers.
510 2021-05-04T22:18:34  <gleb> (the time it takes to spread a transaction). Saying "rapidly forwarding" is not so different
511 2021-05-04T22:18:47  <gleb> Again, assuming the topology.
512 2021-05-04T22:19:25  <gmaxwell> Like, have we made a series of single steps that were logcal but gives a weird outcome?  Step 1. relay faster to outbound peers because we control them, so they're less likely to be spies monitoring our txn.  Step 2. Introduce reconcillation, but make flooding only happen for reachable nodes because it has some moral similarity to step 1.   Conclusion, 80% of bitcoin nodes no longer participate
513 2021-05-04T22:19:31  <gmaxwell> in fast propagation?   But that wasn't the original goal, it seems like a side-effect though perhaps a benign one?
514 2021-05-04T22:19:51  <gmaxwell> but not completely benign since now we have problems with txn originated 'near' these flooding non-participants.
515 2021-05-04T22:20:19  *** smctwo <smctwo!~smctwo@bba597217.alshamil.net.ae> has quit IRC (Remote host closed the connection)
516 2021-05-04T22:20:51  <gleb> gmaxwell: I believe I made those steps, I even had 1-3 steps above. I always tried to keep you and pieter in sync, but you might have got lost at some point.
517 2021-05-04T22:20:55  <sipa> but even without the assymetry in flood relay speed between outbound/inbound, it is the case that better connected nodes (which is correlated with connections to them) will learn about transactions fasters
518 2021-05-04T22:22:09  <gmaxwell> sipa: indeed, that was why the strawman alternative I suggested above elected whatever direction that sourced more txn to be the flooding direction.
519 2021-05-04T22:23:01  <sipa> figure 19 in the paper shows bandwidth/latency simulations for a number of configurations
520 2021-05-04T22:23:24  <gmaxwell> gleb: I probably wasn't lost, I probably was right there with you at the time, following along with whatever reasoning got us there.
521 2021-05-04T22:23:27  <gmaxwell> :P
522 2021-05-04T22:23:55  <gmaxwell> but I don't really get the reasoning now. :(
523 2021-05-04T22:24:48  <sipa> "flooding is not as useful to peers which are better connected than you are" is the summary i think
524 2021-05-04T22:24:54  <gmaxwell> sipa: re: better connected,  esp if outbound connections are increased, it's not even unlikely that a NATed node could end up better connected than some arbitarily selected inbound only node.
525 2021-05-04T22:24:54  <gleb> sipa: in those experiments, I never tried to pick the flood peers in a smart way. It was always N, M% random across inbound/outbound.
526 2021-05-04T22:26:01  <sipa> gleb: it is surprising to me that in fig 19 in the paper, increasing the number of outbound flood peers improves both bandwidth and latency
527 2021-05-04T22:26:41  <sipa> gmaxwell: that's fair
528 2021-05-04T22:27:19  <gleb> sipa: I can't explain that now.
529 2021-05-04T22:28:27  <sipa> gleb: is that graph using the same logic (only flood transactions receiving on incoming connections)?
530 2021-05-04T22:28:43  <gleb> sipa: yes I think so.
531 2021-05-04T22:29:39  <sipa> that suggests that that decision (relay tx received via inbound through flooding to outbounds) is (in your simulation model) a very good predictor of who won't have a tx already
532 2021-05-04T22:30:13  <sipa> basically you want to use flooding when you have reasons to believe you had a tx earlier than the recipient, while recon is for when you and your peer are equals
533 2021-05-04T22:30:29  <gmaxwell> maybe I should step back and also try to explain my general unease with the hard in/out split.  Essentially, it makes a strong assumption on the global structure of the network.    Recently in dogecoin there were network collapse issues related to a similar asymmetry during IBD... where almost the entire network was all in IBD because it had fallen behind, and as result wouldn't serve blocks
534 2021-05-04T22:30:35  <gmaxwell> and only requested them from peers they connected out to (which were more themselves in the same broken state)
535 2021-05-04T22:30:48  <sipa> and i guess "receiving through inbound" is a very good predictor for that (again, in your model, which may not actually correspond to reality)
536 2021-05-04T22:34:28  <gmaxwell> sipa:  If you flood txn recieved through flooding, then indeed, those are going to be the txn that are new.   I don't actually know that in/out really matters for that to be true, except when only flooding to outbound makes it true.
537 2021-05-04T22:34:37  <gleb> sipa: yeah, and that achieved in the following ways. Flooding is mainly used across reachable. We cap at 8 outbounds, so even though "having earlier" is true in 50%, that's fine because it's capped.
538 2021-05-04T22:35:42  <gleb> sipa: For reconciliation it matters mainly for non-reachable, and efficiency is achieved by reconciling every 2 seconds via queue. When you hit 2*8=16 seconds interval per peer, you already reconciled with 7 other peers since last time, so you are almost equal to that 8th peer.
539 2021-05-04T22:36:03  <gleb> Sorry for keeping the reachable terminology, I'm just explaining how sipa logic maps to my design.
540 2021-05-04T22:36:34  <gleb> Yeah, if the topology changes, it would no longer be as efficient. We might see more bandwidth (unlikely more than currently)
541 2021-05-04T22:36:53  <gmaxwell> thats fine. my comment about the term being confusing was because it looked like it was causing confusion in the review.
542 2021-05-04T22:37:22  <gleb> well, i mean you also would prefer to avoid reasoning about it in the design i thought?
543 2021-05-04T22:38:05  <gmaxwell> gleb: like I think with the currently proposed design, the bandwidth per node on reachable nodes may go up a lot... becuase previously non-reachable nodes participated actively in forwarding turn into passive participants and don't forward mcuh txn at all.
544 2021-05-04T22:38:40  <gleb> gmaxwell: you mean sending tx bodies?
545 2021-05-04T22:38:49  <gmaxwell> gleb: maybe, thats my impression now but it could just be that I forgot why I used to think it was okay.  But I'm not confused by its current existance in the design
546 2021-05-04T22:38:57  <gmaxwell> yes
547 2021-05-04T22:39:36  <sipa> perhaps it is the case that even today most relay done by non-reachable nodes doesn't actually contribute much to tx propagation?
548 2021-05-04T22:39:50  <gmaxwell> nah, it's like a 2:1 asymmetry as seen on my nodes.
549 2021-05-04T22:40:16  <sipa> by "contribute" in don't mean in terms of bandwidth, but in terms of how much propagation speed would suffer if they stopped
550 2021-05-04T22:40:40  <gmaxwell> (if you go through your IRC logs with me you'll see maybe a year ago I saw that and thought something was wrong that it was so asymetric then realized it was finally that nodes updated to the most recent broadcast timing logic)
551 2021-05-04T22:40:56  <gmaxwell> sipa: I actually mean bandwidth though both might be true.
552 2021-05-04T22:41:17  <gleb> gmaxwell: yes, I think this is very true. Reachable will take more work on forwarding tx bodies, making it even more asymmetrical. I think that's fair to expect.
553 2021-05-04T22:41:40  <sipa> i don't see why that would be the case
554 2021-05-04T22:41:44  <gmaxwell> just thinking through the implications of taking the majority of nodes out of the general forwarding process.
555 2021-05-04T22:42:50  <gmaxwell> sipa: for discussion, assume 80% of nodes are behind nat.  Right now, they probably carry the majority of the work transmititng txs  (yes, they're slower, but there are many more of them).  Post erlay, they won't realy tx bodies except fairly rarely.
556 2021-05-04T22:43:15  <gleb> sipa: consider an average non-reachable node. The time between any reconciliations for it is 2 seconds. And the time of relaying across *all reachable* is 1 second. I think this implies most tx body work is done by reachable.
557 2021-05-04T22:43:25  <gmaxwell> ^
558 2021-05-04T22:44:01  <sipa> ok let me be more specific about what i'm not convinced of
559 2021-05-04T22:44:08  <gmaxwell> that doesn't seem desirable to me, ... some asymetry is unavoidable because they have fewer connections each.
560 2021-05-04T22:44:09  <gleb> I probably was like "but they will still save a lot of announcements, so it's fine to increase tx body work"
561 2021-05-04T22:44:33  <gmaxwell> gleb: I don't think I ever considered that particular aspect before.
562 2021-05-04T22:44:50  <gmaxwell> (lol well, I really don't know what I thought before, it's been too long)
563 2021-05-04T22:45:44  <sipa> i believe it is possible (but don't know) that if we could today change the code so that non-reachable nodes drastically reduce how much they perform tx announcements and that when doing so (a) bandwidth usage of reachable nodes won't be affected much and (b) propagation delays won't suffer much
564 2021-05-04T22:45:53  *** GarouDan <GarouDan!~GarouDan@> has joined #bitcoin-core-dev
565 2021-05-04T22:46:09  <sipa> basically i'm saying that it could be the case that effectively a lot of tx propagation work performed today by non-reachable nodes is redundant
566 2021-05-04T22:46:28  <gleb> I think greg's 2:1 can't agree with you.
567 2021-05-04T22:47:01  <gleb> I assume, non-reachable sends 0.5x of reachable's tx body traffic?
568 2021-05-04T22:47:02  <gmaxwell> sipa: sendign tx _bodies_ is never redundant.
569 2021-05-04T22:47:13  <gmaxwell> lemme go get current figures one sec.
570 2021-05-04T22:47:42  <sipa> gmaxwell: ah good point, every body only arrives at every node once
571 2021-05-04T22:48:05  <sipa> whatever non-reachable nodes are doing in that regard must be compensated by others
572 2021-05-04T22:48:16  <sipa> ok, that's convincing
573 2021-05-04T22:49:10  *** Squidicc <Squidicc!~squid@pool-72-74-34-120.bstnma.fios.verizon.net> has joined #bitcoin-core-dev
574 2021-05-04T22:49:43  <gmaxwell> crap I lost my shell history on my node and now need to remember how to use JQ... I want to look at the ratio tx message sizes on inbound peers.
575 2021-05-04T22:49:54  <gmaxwell> (it's just data in getpeerinfo)
576 2021-05-04T22:50:06  <gleb> So potentially 2 problems with current design: 1) NAT privacy (could probably be fixed) 2) deepening the asymmetry
577 2021-05-04T22:50:17  <gmaxwell> my very bad informal memory says that it was asymmetric, but except for bognon peers not THAT asymmetric.
578 2021-05-04T22:50:27  <gmaxwell> bogon*
579 2021-05-04T22:50:32  *** GarouDan <GarouDan!~GarouDan@> has quit IRC (Ping timeout: 252 seconds)
580 2021-05-04T22:50:41  *** Squidicuz <Squidicuz!~squid@pool-72-74-34-120.bstnma.fios.verizon.net> has quit IRC (Read error: Connection reset by peer)
581 2021-05-04T22:53:07  <gmaxwell> also: fwiw, we created most of this asymmetry 'recently' with the relay grouping stuff... and it wasn't an intended effect.  When I did notice it I was confused/surprised.  Though I don't think the current level is a problem.
582 2021-05-04T22:53:51  <gmaxwell> I had automation that was identifyign spies to ban based on part of that ratio and I noticed when it started flagging lots more peers.
583 2021-05-04T22:54:14  <gleb> gmaxwell: was it symmetrical before groups? Even when we just had 2s/5s independent timers?
584 2021-05-04T22:55:02  <gmaxwell> gleb: SO, it wasn't asymmetrical enough for me to notice, but I think I was triggering on unusual as 2:1. It's a little hard to say for absolute sure because deployments happen over time.
585 2021-05-04T22:55:55  <gmaxwell> It's not impossible that the independant 2/5sec change was the cause, and it just took a long time to be deployed enough for me to notice (or some other factor made it more visible).  But I think it's likely that making all inbounds share a group was the cause.
586 2021-05-04T22:56:50  <gmaxwell> I didn't *really* realize something was going on that I didn't understand until I saw a big asymmetry on a connection between sipa's node and mine.
587 2021-05-04T22:57:01  <gmaxwell> which I couldn't dismiss as being some weird peer.
588 2021-05-04T22:57:12  <gmaxwell> well, sipa is weird but his bitcoin node isn't. :P
589 2021-05-04T22:57:30  <gleb> gmaxwell: sad we haven't noticed that during the shared timer design, that's the stuff i like to model... but probably didn't know how to at a time
590 2021-05-04T22:57:40  <gleb> I think that could have been my first PR to core in 2018.
591 2021-05-04T22:58:02  <gmaxwell> Well you don't know what you don't know.
592 2021-05-04T22:58:21  <gmaxwell> You could easily model the txdata burden, I just never thought of it.
593 2021-05-04T23:00:02  <gmaxwell> The tx serving burden has come up before, but in a different context-- like if you get multiple INVs for the same tx at almost the same time, it's better to pick the source more randomly rather than always go to the first.
594 2021-05-04T23:00:08  <gmaxwell> sorry.
595 2021-05-04T23:00:49  <gleb> But that stuff we also changed in the context of invblock or tx overhaul or something recently? :)
596 2021-05-04T23:01:02  <gleb> like, this exact suggestion, making it random and not first received
597 2021-05-04T23:02:52  *** smctwo <smctwo!~smctwo@bba597217.alshamil.net.ae> has joined #bitcoin-core-dev
598 2021-05-04T23:03:22  <gleb> So, if we want to make it more symmetrical, we indeed could direct some flooding into inbound, and independently from the tx source (maaaybe based on prev performance). I expect we loose some overall efficiency that way, but if that's desired.
599 2021-05-04T23:03:37  <gleb> Yeah, that's exactly figure 19, except it chooses the flood peers randomly.
600 2021-05-04T23:04:05  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
601 2021-05-04T23:04:06  <bitcoin-git> [bitcoin] fanquake closed pull request #21854: doc: make small corrections (v0.21.1 release notes) (master...patch-1) https://github.com/bitcoin/bitcoin/pull/21854
602 2021-05-04T23:04:07  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
603 2021-05-04T23:07:30  <sipa> ./src/bitcoin-cli getpeerinfo | jq -r 'map("\(if .inbound then "I" else "O" end) \((.bytessent_per_msg.tx // 0) / ((.bytessent_per_msg.tx // 0) + (1 + .bytesrecv_per_msg.tx // 0)))") | .[]' | sort -g
604 2021-05-04T23:08:29  <sipa> gmaxwell: something like that?
605 2021-05-04T23:08:48  <gmaxwell> ./bitcoin-cli getpeerinfo | jq -c '.[] | select(."bytessent_per_msg"."tx">0) | select(."bytesrecv_per_msg"."tx">0) | select(."inbound"==false) | ."bytessent_per_msg"."tx"/."bytesrecv_per_msg"."tx"'
606 2021-05-04T23:08:53  <gmaxwell> is what I ended up with.
607 2021-05-04T23:09:06  <gmaxwell> but yea your is better.
608 2021-05-04T23:09:46  <gmaxwell> these need to be normalized though because naturally you'll only recieve once.
609 2021-05-04T23:09:48  <gleb> sipa: I'm looking at my simulator, and I'm realizing I had no "received from inbound" policy at a time. Same in the paper. It was always just "flood to 8 outbounds" policy.
610 2021-05-04T23:10:08  <sipa> gleb: that's surprising
611 2021-05-04T23:10:37  <gmaxwell> that is anti-surprising to me! :P
612 2021-05-04T23:11:06  *** smctwo <smctwo!~smctwo@bba597217.alshamil.net.ae> has quit IRC (Ping timeout: 240 seconds)
613 2021-05-04T23:11:08  <sipa> it conflicts with my intuition for why increasing flooding reducing bandwidth
614 2021-05-04T23:12:06  <gleb> oh, hold on, sorry, the simulator is old code and hard to understand now :(
615 2021-05-04T23:15:47  <gleb> It seems like at the time the idea was to only flood what's announced by reconciliation initiator to reconciliation responder (not backwards). Sorry again for this thought bouncing. Yeah, it seems i always had this idea in mind: try not to flood from non-reachable nodes.
616 2021-05-04T23:16:41  <gleb> And since inbound always initiates, we effectively announce "what is learned inbound". The lattest simulator has that it seems.
617 2021-05-04T23:17:13  <gleb> Anyway, so should we try other configurations again and see how much bandwidth gain we loose by not making topology assumptions?
618 2021-05-04T23:17:57  <sipa> just trying "flood relay everything to 2-3-4-5-6-7-8 outbound peers" ?
619 2021-05-04T23:19:49  <gmaxwell> sipa: so my node has 65 peers that I've exchanged txn with, and overall has sent 3.26x the tx data it has recieved. I think that ratio is pretty low, considering it only recieves once but sends up to 65 times.
620 2021-05-04T23:20:45  <gmaxwell> gleb: also maybe add to the simulator something to get information on how much tx body data will be sent/recieved?  I'm pretty sure the current scheme will behave pretty poorly in that respect.
621 2021-05-04T23:21:22  <gleb> gmaxwell: you mean poor in the sense of asymmetry?
622 2021-05-04T23:21:55  <gmaxwell> gleb: yeah, poor in the sense that total traffic on reachable nodes would increase a lot, while traffic at each non-reachable node decreases a bit.
623 2021-05-04T23:22:21  <gmaxwell> (because the latter outnumber the former)
624 2021-05-04T23:22:48  <gleb> Okay, maybe it's time to re-implement the simulator so that other people can actually review and use it easier. I'll start looking into it tomorrow.
625 2021-05-04T23:23:07  <gmaxwell> :( I feel bad.
626 2021-05-04T23:23:13  <sipa> this is a fairly simple policy change, so i don't think this needs to hold up code review much
627 2021-05-04T23:23:19  <sipa> (if we'd make it)
628 2021-05-04T23:23:29  <gmaxwell> yea I don't think it really changes the implementation much except for a few lines here and there.
629 2021-05-04T23:23:50  <sipa> oh, and don't forget the "remove from recon sets whatever is send/received through flooding" - i think that matters
630 2021-05-04T23:23:55  <gleb> sipa: i agree, most of the module remains the same, this stuff is even outside the module.
631 2021-05-04T23:24:03  <gleb> sipa: i noted it, don't worry
632 2021-05-04T23:24:08  <sipa> gleb: thanks!
633 2021-05-04T23:24:26  <gmaxwell> in the meantime, minisketch could get merged, and dropped from the erlay PR. That would be nice progress.
634 2021-05-04T23:24:41  <gleb> okay, thank you, i'll come back once i have the results. I agree on the plan ^
635 2021-05-04T23:25:02  *** GarouDan <GarouDan!~GarouDan@> has joined #bitcoin-core-dev
636 2021-05-04T23:25:57  *** smctwo <smctwo!~smctwo@bba597217.alshamil.net.ae> has joined #bitcoin-core-dev
637 2021-05-04T23:30:46  *** smctwo <smctwo!~smctwo@bba597217.alshamil.net.ae> has quit IRC (Ping timeout: 240 seconds)
638 2021-05-04T23:31:27  <gmaxwell> sipa: I have this vague idea that since my tx body ratio is 3.26x that my inv data ratio should be also 3.26x, ideally.  (of course it won't be, it'll be beteen 32 and 64x because I have 64 peers and invs are flooded)
639 2021-05-04T23:31:55  *** sipsorcery <sipsorcery!~sipsorcer@2a02:8084:6981:7880::3> has quit IRC (Ping timeout: 260 seconds)
640 2021-05-04T23:33:04  *** mrostecki <mrostecki!mrostecki@nat/suse/x-qunzagdczmwaveyc> has quit IRC (Ping timeout: 276 seconds)
641 2021-05-04T23:34:00  <gmaxwell> oh, no it won't the invs ratio will be near 1 but both sides will be 64 times larger. duh.
642 2021-05-04T23:34:39  *** mrostecki <mrostecki!mrostecki@nat/suse/x-bdsgmfrittaifnzu> has joined #bitcoin-core-dev
643 2021-05-04T23:49:24  *** lightlike <lightlike!~lightlike@p200300c7ef197400945876005b846753.dip0.t-ipconnect.de> has quit IRC (Quit: Leaving)
644 2021-05-04T23:55:48  *** morcos <morcos!~morcos@gateway/tor-sasl/morcos> has quit IRC (Remote host closed the connection)
645 2021-05-04T23:56:08  *** morcos <morcos!~morcos@gateway/tor-sasl/morcos> has joined #bitcoin-core-dev