12021-05-04T00:06:01 *** belcher <belcher!~belcher@unaffiliated/belcher> has quit IRC (Ping timeout: 252 seconds)
22021-05-04T00:12:35 *** jeremyrubin <jeremyrubin!~jr@024-176-247-182.res.spectrum.com> has joined #bitcoin-core-dev
32021-05-04T00:17:04 *** faketoshi <faketoshi!~quassel@192.252.212.36> has joined #bitcoin-core-dev
42021-05-04T00:19:50 *** belcher <belcher!~belcher@unaffiliated/belcher> has joined #bitcoin-core-dev
52021-05-04T00:20:07 *** bcman <bcman!~quassel@192.252.212.38> has quit IRC (Ping timeout: 265 seconds)
62021-05-04T00:25:11 *** yanmaani1 is now known as yanmaani
72021-05-04T00:25:26 *** proofofkeags <proofofkeags!~proofofke@205.209.28.54> has quit IRC (Ping timeout: 240 seconds)
82021-05-04T00:52:55 *** vincenzopalazzo <vincenzopalazzo!~vincenzop@host-79-37-17-61.retail.telecomitalia.it> has quit IRC (Quit: Leaving)
92021-05-04T01:07:47 *** jeremyrubin <jeremyrubin!~jr@024-176-247-182.res.spectrum.com> has quit IRC (Read error: Connection reset by peer)
102021-05-04T01:09:00 *** jeremyrubin <jeremyrubin!~jr@024-176-247-182.res.spectrum.com> has joined #bitcoin-core-dev
112021-05-04T01:10:20 *** Eagle[TM] <Eagle[TM]!~EagleTM@unaffiliated/eagletm> has joined #bitcoin-core-dev
122021-05-04T01:11:06 *** EagleTM <EagleTM!~EagleTM@unaffiliated/eagletm> has quit IRC (Ping timeout: 240 seconds)
132021-05-04T01:16:02 *** _dvd <_dvd!dvd@nat/redhat/x-fojdbtkrnypbdhxb> has joined #bitcoin-core-dev
142021-05-04T01:26:03 *** mips <mips!~mips@gateway/tor-sasl/mips> has quit IRC (Quit: Leaving)
152021-05-04T01:28:06 *** GarouDan <GarouDan!~GarouDan@191.242.119.219.fibra.plimtelecom.com.br> has joined #bitcoin-core-dev
162021-05-04T01:32:38 *** GarouDan <GarouDan!~GarouDan@191.242.119.219.fibra.plimtelecom.com.br> has quit IRC (Ping timeout: 246 seconds)
172021-05-04T01:33:24 *** OP_NOP <OP_NOP!OP_NOP@gateway/vpn/privateinternetaccess/opnop/x-41418994> has joined #bitcoin-core-dev
182021-05-04T01:47:54 *** spinza <spinza!~spin@102.132.245.16> has quit IRC (Quit: Coyote finally caught up with me...)
192021-05-04T01:48:39 *** yanmaani1 <yanmaani1!~yanmaani@gateway/tor-sasl/yanmaani> has joined #bitcoin-core-dev
202021-05-04T01:51:04 *** CubicEarth <CubicEarth!~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net> has quit IRC (Ping timeout: 252 seconds)
212021-05-04T01:51:57 *** yanmaani <yanmaani!~yanmaani@gateway/tor-sasl/yanmaani> has quit IRC (Ping timeout: 240 seconds)
222021-05-04T01:54:25 *** CubicEarth <CubicEarth!~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net> has joined #bitcoin-core-dev
232021-05-04T01:58:45 *** yanmaani1 is now known as yanmaani
242021-05-04T02:15:40 *** spinza <spinza!~spin@102.132.245.16> has joined #bitcoin-core-dev
252021-05-04T02:20:24 *** GarouDan <GarouDan!~GarouDan@191.242.119.219.fibra.plimtelecom.com.br> has joined #bitcoin-core-dev
262021-05-04T02:31:39 *** inquis <inquis!~inquis@139.28.218.148> has quit IRC (Remote host closed the connection)
272021-05-04T02:38:45 *** DeanGuss <DeanGuss!~dean@gateway/tor-sasl/deanguss> has quit IRC (Ping timeout: 240 seconds)
282021-05-04T02:53:22 *** DeanGuss <DeanGuss!~dean@gateway/tor-sasl/deanguss> has joined #bitcoin-core-dev
292021-05-04T03:03:58 *** OP_NOP <OP_NOP!OP_NOP@gateway/vpn/privateinternetaccess/opnop/x-41418994> has quit IRC (Ping timeout: 265 seconds)
302021-05-04T03:13:40 *** awesome_doge <awesome_doge!~Thunderbi@118-163-120-175.HINET-IP.hinet.net> has joined #bitcoin-core-dev
312021-05-04T03:20:11 *** sturles <sturles!~sturles@unaffiliated/sturles> has quit IRC (Ping timeout: 240 seconds)
322021-05-04T03:22:04 *** sturles <sturles!~sturles@sauron.uio.no> has joined #bitcoin-core-dev
332021-05-04T03:49:07 *** erwin_bullet <erwin_bullet!~erwin_bul@195.140.213.38> has joined #bitcoin-core-dev
342021-05-04T03:50:56 *** GarouDan <GarouDan!~GarouDan@191.242.119.219.fibra.plimtelecom.com.br> has quit IRC (Remote host closed the connection)
352021-05-04T04:20:21 *** justanotheruser <justanotheruser!~justanoth@unaffiliated/justanotheruser> has joined #bitcoin-core-dev
362021-05-04T04:26:51 *** EastSideTony <EastSideTony!6b81a5cc@107-129-165-204.lightspeed.sntcca.sbcglobal.net> has joined #bitcoin-core-dev
372021-05-04T04:27:53 *** EastSideTony <EastSideTony!6b81a5cc@107-129-165-204.lightspeed.sntcca.sbcglobal.net> has quit IRC (Client Quit)
382021-05-04T04:49:35 *** sipsorcery <sipsorcery!~sipsorcer@2a02:8084:6981:7880::3> has quit IRC (Ping timeout: 260 seconds)
392021-05-04T04:51:04 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
402021-05-04T04:51:05 <bitcoin-git> [bitcoin] MarcoFalke pushed 4 commits to master: https://github.com/bitcoin/bitcoin/compare/bf5e6a7771b3...e2d4e67a8fcc
412021-05-04T04:51:05 <bitcoin-git> bitcoin/master fa2197c MarcoFalke: test: Use loop to register RPCs
422021-05-04T04:51:06 <bitcoin-git> bitcoin/master 000098f MarcoFalke: test: Use throwing variant accessor
432021-05-04T04:51:07 <bitcoin-git> bitcoin/master fa8a888 MarcoFalke: bench: Remove duplicate constants
442021-05-04T04:51:08 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
452021-05-04T04:51:23 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
462021-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
472021-05-04T04:51:25 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
482021-05-04T05:14:01 *** jeremyrubin <jeremyrubin!~jr@024-176-247-182.res.spectrum.com> has quit IRC (Ping timeout: 252 seconds)
492021-05-04T05:30:00 *** pox <pox!~pox@gateway/tor-sasl/pox> has joined #bitcoin-core-dev
502021-05-04T05:39:43 *** mips <mips!~mips@gateway/tor-sasl/mips> has joined #bitcoin-core-dev
512021-05-04T05:55:26 *** erwin_bullet <erwin_bullet!~erwin_bul@195.140.213.38> has quit IRC (Remote host closed the connection)
522021-05-04T05:57:35 *** Guyver2 <Guyver2!~Guyver@guyver2.xs4all.nl> has joined #bitcoin-core-dev
532021-05-04T06:07:49 *** Zao_ <Zao_!~Zao_@185.163.110.100> has joined #bitcoin-core-dev
542021-05-04T06:27:13 *** jeremyrubin <jeremyrubin!~jr@024-176-247-182.res.spectrum.com> has joined #bitcoin-core-dev
552021-05-04T06:27:58 *** smctwo <smctwo!~smctwo@87.200.180.239> has joined #bitcoin-core-dev
562021-05-04T06:32:46 *** smctwo <smctwo!~smctwo@87.200.180.239> has quit IRC (Ping timeout: 265 seconds)
572021-05-04T06:33:26 *** awesome_doge <awesome_doge!~Thunderbi@118-163-120-175.HINET-IP.hinet.net> has quit IRC (Quit: awesome_doge)
582021-05-04T06:38:39 *** jungly <jungly!~jungly@host-82-49-146-18.retail.telecomitalia.it> has joined #bitcoin-core-dev
592021-05-04T07:00:00 *** sipsorcery <sipsorcery!~sipsorcer@2a02:8084:6981:7880::3> has joined #bitcoin-core-dev
602021-05-04T07:16:59 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
612021-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
622021-05-04T07:17:00 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
632021-05-04T07:18:03 *** duringo <duringo!2d57d6c5@45.87.214.197> has quit IRC (Ping timeout: 240 seconds)
642021-05-04T07:27:31 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
652021-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
662021-05-04T07:27:33 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
672021-05-04T07:40:24 *** jespada <jespada!~jespada@87.74.37.248> has joined #bitcoin-core-dev
682021-05-04T07:43:30 *** Guyver2_ <Guyver2_!~Guyver@guyver2.xs4all.nl> has joined #bitcoin-core-dev
692021-05-04T07:45:15 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
702021-05-04T07:45:16 <bitcoin-git> [bitcoin] laanwj pushed 4 commits to master: https://github.com/bitcoin/bitcoin/compare/e2d4e67a8fcc...ab9a566ab333
712021-05-04T07:45:16 <bitcoin-git> bitcoin/master ea269c7 Jon Atack: contrib: parse I2P addresses in generate-seeds.py
722021-05-04T07:45:17 <bitcoin-git> bitcoin/master e01f173 Jon Atack: contrib: add a few I2P seed nodes
732021-05-04T07:45:17 <bitcoin-git> bitcoin/master 142e2da Jon Atack: net: add I2P seeds to chainparamsseeds
742021-05-04T07:45:18 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
752021-05-04T07:45:34 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
762021-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
772021-05-04T07:45:36 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
782021-05-04T07:45:51 *** Guyver2 <Guyver2!~Guyver@guyver2.xs4all.nl> has quit IRC (Ping timeout: 260 seconds)
792021-05-04T07:46:53 *** prayank <prayank!~andr0irc@2402:8100:206c:68c8:30b0:af4b:7735:463b> has joined #bitcoin-core-dev
802021-05-04T07:55:10 <wumpus> ryanofsky: done
812021-05-04T07:57:36 *** dnm21881[m] <dnm21881[m]!dnm21881ma@gateway/shell/matrix.org/x-llapygmoibnbsrtg> has joined #bitcoin-core-dev
822021-05-04T07:58:36 *** dnm21881[m] <dnm21881[m]!dnm21881ma@gateway/shell/matrix.org/x-llapygmoibnbsrtg> has left #bitcoin-core-dev
832021-05-04T08:00:02 *** lkqwejhhgasdjhgn <lkqwejhhgasdjhgn!~kljkljklk@p200300d46f06bf00ea203cd14cca75b0.dip0.t-ipconnect.de> has joined #bitcoin-core-dev
842021-05-04T08:04:07 <gmaxwell> Antpool taproot block, thats over 50% hashpower now.
852021-05-04T08:06:40 <aj> \o/
862021-05-04T08:07:26 *** owowo <owowo!~ovovo@unaffiliated/ovovo> has quit IRC (Ping timeout: 240 seconds)
872021-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?
882021-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.
892021-05-04T08:11:52 <hugohn> (also yay on Taproot signaling progress)
902021-05-04T08:12:40 *** Guyver2_ <Guyver2_!~Guyver@guyver2.xs4all.nl> has quit IRC (Quit: Going offline, see ya! (www.adiirc.com))
912021-05-04T08:14:17 <wumpus> hugohn: nothing, it should just get a BIP number assigned
922021-05-04T08:15:09 *** yanmaani <yanmaani!~yanmaani@gateway/tor-sasl/yanmaani> has quit IRC (Ping timeout: 240 seconds)
932021-05-04T08:15:56 *** yanmaani <yanmaani!~yanmaani@gateway/tor-sasl/yanmaani> has joined #bitcoin-core-dev
942021-05-04T08:16:45 <wumpus> ping @luke-jr ^
952021-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
962021-05-04T08:19:49 <hugohn> @wumpus @aj thanks !
972021-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
982021-05-04T08:20:16 <hugohn> I've already named the branch "bip-hugonguyen-bsms". Does it need to be included in the spec itself?
992021-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 :)
1002021-05-04T08:26:31 <hugohn> not to mention the long ID is a mouthful / harder to share
1012021-05-04T08:27:49 <hugohn> although the idea of of a more decentralized process does sound good
1022021-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.
1032021-05-04T08:29:08 <wumpus> an idea we had early was to simply use the PR number as BIP number
1042021-05-04T08:29:45 <wumpus> some projects (rust, I think?) use this approach
1052021-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
1062021-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
1072021-05-04T08:32:41 <hugohn> right. if it's not a simple sequence generator, a BIP on BIPs probably makes more sense.
1082021-05-04T08:33:02 <wumpus> this is mustly a problem if it would be managed by as scriptbot
1092021-05-04T08:33:27 <wumpus> you mean like BIP1 and 2?
1102021-05-04T08:34:11 <hugohn> yes
1112021-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
1122021-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
1132021-05-04T08:39:54 <michaelfolkson> A few things I think are probably in need of a revamp (or at least a discussion)
1142021-05-04T08:40:02 <hugohn> thanks @michaelfolkson . I'd take a look.
1152021-05-04T08:40:59 <wumpus> ideally it should be a fast and low-friction process
1162021-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)
1172021-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
1182021-05-04T08:52:39 <wumpus> correct, that is what the GUI repo is for
1192021-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
1202021-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.
1212021-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.
1222021-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
1232021-05-04T08:57:24 <michaelfolkson> hugohn: I personally think it would be overkill to give the BIPs repo its own org
1242021-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?
1252021-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
1262021-05-04T08:59:22 <michaelfolkson> https://github.com/bitcoin-core/gui/issues/"
1272021-05-04T08:59:35 <wumpus> michaelfolkson: yes, except it should send you to the GUI repo
1282021-05-04T08:59:50 <wumpus> oh okay, that's a bit weird but i guess it works
1292021-05-04T08:59:57 <michaelfolkson> wumpus: Ah ok I see what you mean
1302021-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
1312021-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
1322021-05-04T09:01:42 <michaelfolkson> Right
1332021-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
1342021-05-04T09:07:11 *** sipsorcery <sipsorcery!~sipsorcer@2a02:8084:6981:7880::3> has quit IRC (Ping timeout: 260 seconds)
1352021-05-04T09:16:01 *** sipsorcery <sipsorcery!~sipsorcer@2a02:8084:6981:7880::3> has joined #bitcoin-core-dev
1362021-05-04T09:38:21 *** braydonf_ <braydonf_!~braydon@gateway/tor-sasl/braydonf> has quit IRC (Ping timeout: 240 seconds)
1372021-05-04T09:39:39 *** ogo <ogo!~ogo@gateway/tor-sasl/ogo> has joined #bitcoin-core-dev
1382021-05-04T09:39:42 *** braydonf_ <braydonf_!~braydon@gateway/tor-sasl/braydonf> has joined #bitcoin-core-dev
1392021-05-04T10:03:56 *** vincenzopalazzo <vincenzopalazzo!~vincenzop@host-79-37-17-61.retail.telecomitalia.it> has joined #bitcoin-core-dev
1402021-05-04T10:04:12 *** Eagle[TM] <Eagle[TM]!~EagleTM@unaffiliated/eagletm> has quit IRC (Ping timeout: 252 seconds)
1412021-05-04T10:08:42 *** jespada <jespada!~jespada@87.74.37.248> has quit IRC (Quit: Leaving)
1422021-05-04T10:21:17 *** Sage56Koss <Sage56Koss!~Sage56Kos@static.57.1.216.95.clients.your-server.de> has joined #bitcoin-core-dev
1432021-05-04T10:26:13 *** Sage56Koss <Sage56Koss!~Sage56Kos@static.57.1.216.95.clients.your-server.de> has quit IRC (Ping timeout: 265 seconds)
1442021-05-04T10:37:18 *** owowo <owowo!~ovovo@91.193.4.45> has joined #bitcoin-core-dev
1452021-05-04T10:40:29 *** d0minik <d0minik!5f5afe59@ip5f5afe59.dynamic.kabel-deutschland.de> has joined #bitcoin-core-dev
1462021-05-04T10:41:59 *** d0minik <d0minik!5f5afe59@ip5f5afe59.dynamic.kabel-deutschland.de> has quit IRC (Client Quit)
1472021-05-04T11:19:01 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
1482021-05-04T11:19:01 <bitcoin-git> [bitcoin] fanquake pushed 4 commits to master: https://github.com/bitcoin/bitcoin/compare/ab9a566ab333...0ca8b7e7ecd5
1492021-05-04T11:19:02 <bitcoin-git> bitcoin/master faeabef MarcoFalke: ci: Enable D_GLIBCXX_DEBUG for multiprocess task
1502021-05-04T11:19:02 <bitcoin-git> bitcoin/master fad0f21 MarcoFalke: ci: Use clang in multiprocess task to avoid OOM
1512021-05-04T11:19:03 <bitcoin-git> bitcoin/master fa44f51 MarcoFalke: ci: Clarify that previous_releases task is using DEBUG
1522021-05-04T11:19:04 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
1532021-05-04T11:19:21 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
1542021-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
1552021-05-04T11:19:23 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
1562021-05-04T11:26:46 *** xxxyyyzzz111 <xxxyyyzzz111!014084b8@1-64-132-184.static.netvigator.com> has joined #bitcoin-core-dev
1572021-05-04T11:27:36 *** xxxyyyzzz111 <xxxyyyzzz111!014084b8@1-64-132-184.static.netvigator.com> has left #bitcoin-core-dev
1582021-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
1592021-05-04T11:43:50 <fanquake> I see 169 uses of fuzzed_data_provider.ConsumeBool() ?
1602021-05-04T11:44:22 <jonatack> er, ConsumeEnum, mistyped...or do we prefer to avoid changing enums to use it
1612021-05-04T11:45:35 *** prayank <prayank!~andr0irc@2402:8100:206c:68c8:30b0:af4b:7735:463b> has quit IRC (Ping timeout: 250 seconds)
1622021-05-04T11:47:01 *** prayank <prayank!~andr0irc@2402:8100:206c:68c8:2d54:9856:1ebd:884f> has joined #bitcoin-core-dev
1632021-05-04T11:52:59 *** bithees <bithees!6e25f434@WGPON-37244-52.wateen.net> has joined #bitcoin-core-dev
1642021-05-04T11:53:21 *** bithees <bithees!6e25f434@WGPON-37244-52.wateen.net> has quit IRC (Client Quit)
1652021-05-04T11:55:40 <jonatack> will propose using ConsumeEnum() and see what reviewers say
1662021-05-04T12:06:43 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
1672021-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
1682021-05-04T12:06:44 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
1692021-05-04T12:16:30 *** ShapeShifter499 <ShapeShifter499!~ShapeShif@unaffiliated/shapeshifter499> has joined #bitcoin-core-dev
1702021-05-04T12:25:27 *** Zao_ <Zao_!~Zao_@185.163.110.100> has quit IRC (Remote host closed the connection)
1712021-05-04T12:33:42 *** OldMiner <OldMiner!~OldMiner@185.169.233.12> has joined #bitcoin-core-dev
1722021-05-04T12:33:52 *** smartineng <smartineng!~Icedove@88.135.18.171> has joined #bitcoin-core-dev
1732021-05-04T12:45:58 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
1742021-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
1752021-05-04T12:45:59 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
1762021-05-04T12:46:41 *** GarouDan <GarouDan!~GarouDan@191.242.119.219.fibra.plimtelecom.com.br> has joined #bitcoin-core-dev
1772021-05-04T12:58:45 *** braydonf_ <braydonf_!~braydon@gateway/tor-sasl/braydonf> has quit IRC (Ping timeout: 240 seconds)
1782021-05-04T12:59:37 *** braydonf_ <braydonf_!~braydon@gateway/tor-sasl/braydonf> has joined #bitcoin-core-dev
1792021-05-04T13:07:45 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
1802021-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
1812021-05-04T13:07:47 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
1822021-05-04T13:08:56 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
1832021-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
1842021-05-04T13:08:57 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
1852021-05-04T13:15:19 *** mol_ <mol_!~mol@unaffiliated/molly> has joined #bitcoin-core-dev
1862021-05-04T13:17:53 *** mol <mol!~mol@unaffiliated/molly> has quit IRC (Ping timeout: 246 seconds)
1872021-05-04T13:20:02 *** jespada <jespada!~jespada@87.74.37.248> has joined #bitcoin-core-dev
1882021-05-04T13:24:17 *** smctwo <smctwo!~smctwo@87.200.180.239> has joined #bitcoin-core-dev
1892021-05-04T13:25:44 *** prayank <prayank!~andr0irc@2402:8100:206c:68c8:2d54:9856:1ebd:884f> has quit IRC (Quit: irc thread exit)
1902021-05-04T13:28:13 *** smctwo <smctwo!~smctwo@87.200.180.239> has quit IRC (Ping timeout: 240 seconds)
1912021-05-04T13:33:05 *** ghost43 <ghost43!~daer@gateway/tor-sasl/daer> has quit IRC (Remote host closed the connection)
1922021-05-04T13:33:30 *** ghost43 <ghost43!~daer@gateway/tor-sasl/daer> has joined #bitcoin-core-dev
1932021-05-04T13:34:21 *** mips <mips!~mips@gateway/tor-sasl/mips> has quit IRC (Ping timeout: 240 seconds)
1942021-05-04T13:40:36 *** undvrainbowvita8 <undvrainbowvita8!~egp_@128-71-13-3.broadband.corbina.ru> has quit IRC (Ping timeout: 268 seconds)
1952021-05-04T13:55:41 *** mol_ <mol_!~mol@unaffiliated/molly> has quit IRC (Ping timeout: 260 seconds)
1962021-05-04T14:07:59 *** mol <mol!~mol@unaffiliated/molly> has joined #bitcoin-core-dev
1972021-05-04T14:12:45 *** xenial-user <xenial-user!~puppy@host109-156-143-160.range109-156.btcentralplus.com> has joined #bitcoin-core-dev
1982021-05-04T14:14:05 *** xenial-user <xenial-user!~puppy@host109-156-143-160.range109-156.btcentralplus.com> has left #bitcoin-core-dev
1992021-05-04T14:39:17 *** ShapeShifter499 <ShapeShifter499!~ShapeShif@unaffiliated/shapeshifter499> has quit IRC (Quit: ShapeShifter499)
2002021-05-04T14:43:33 *** braydonf_ <braydonf_!~braydon@gateway/tor-sasl/braydonf> has quit IRC (Ping timeout: 240 seconds)
2012021-05-04T14:44:37 *** braydonf_ <braydonf_!~braydon@gateway/tor-sasl/braydonf> has joined #bitcoin-core-dev
2022021-05-04T14:49:58 *** cguida1 <cguida1!~Adium@2806:2f0:51c1:5cee:e16e:b2eb:67a2:57d9> has joined #bitcoin-core-dev
2032021-05-04T14:53:27 *** cguida <cguida!~Adium@2806:2f0:51c1:5cee:ec28:28d8:7d26:5683> has quit IRC (Ping timeout: 260 seconds)
2042021-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
2052021-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
2062021-05-04T15:02:10 <vasild> sounds plausible?
2072021-05-04T15:03:53 *** stortz <stortz!c8b9c69a@unaffiliated/stortz> has joined #bitcoin-core-dev
2082021-05-04T15:06:25 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
2092021-05-04T15:06:26 <bitcoin-git> [bitcoin] MarcoFalke pushed 4 commits to master: https://github.com/bitcoin/bitcoin/compare/0ca8b7e7ecd5...a1c6434e19bc
2102021-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
2112021-05-04T15:06:27 <bitcoin-git> bitcoin/master fa399a7 MarcoFalke: ci: Use clang-12 in msan task
2122021-05-04T15:06:28 <bitcoin-git> bitcoin/master fa0422c MarcoFalke: ci: Add msan fuzz config
2132021-05-04T15:06:36 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
2142021-05-04T15:06:55 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
2152021-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
2162021-05-04T15:06:57 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
2172021-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.
2182021-05-04T15:08:32 <vasild> does it assume contigious values starting from 0?
2192021-05-04T15:08:44 <jonatack> yes, same as before
2202021-05-04T15:09:02 <jonatack> only avoids having to add an alias to the enum in the codebase
2212021-05-04T15:09:04 <vasild> yeah, can't be otherwise :/
2222021-05-04T15:11:02 <jonatack> otherwise, there's the existing ConsumeWeakEnum(values list...
2232021-05-04T15:23:20 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
2242021-05-04T15:23:21 <bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/a1c6434e19bc...3f8f238deb5a
2252021-05-04T15:23:21 <bitcoin-git> bitcoin/master cf83b82 MarcoFalke: fuzz: Limit toxic test globals to their respective scope
2262021-05-04T15:23:22 <bitcoin-git> bitcoin/master 3f8f238 MarcoFalke: Merge bitcoin/bitcoin#21849: fuzz: Limit toxic test globals to their respe...
2272021-05-04T15:23:23 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
2282021-05-04T15:23:41 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
2292021-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
2302021-05-04T15:23:42 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
2312021-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."
2322021-05-04T15:50:56 <luke-jr> (unless it is)
2332021-05-04T15:51:46 *** smctwo <smctwo!~smctwo@37.245.210.234> has joined #bitcoin-core-dev
2342021-05-04T15:51:50 *** smctwo <smctwo!~smctwo@37.245.210.234> has quit IRC (Remote host closed the connection)
2352021-05-04T15:52:28 *** smctwo <smctwo!~smctwo@37.245.210.234> has joined #bitcoin-core-dev
2362021-05-04T15:59:57 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
2372021-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
2382021-05-04T15:59:59 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
2392021-05-04T16:08:10 *** smctwo_ <smctwo_!~smctwo@37.245.210.234> has joined #bitcoin-core-dev
2402021-05-04T16:08:32 *** smctwo_ <smctwo_!~smctwo@37.245.210.234> has quit IRC (Remote host closed the connection)
2412021-05-04T16:09:05 *** smctwo_ <smctwo_!~smctwo@37.245.210.234> has joined #bitcoin-core-dev
2422021-05-04T16:09:05 *** smctwo <smctwo!~smctwo@37.245.210.234> has quit IRC (Ping timeout: 260 seconds)
2432021-05-04T16:13:29 *** GarouDan <GarouDan!~GarouDan@191.242.119.219.fibra.plimtelecom.com.br> has quit IRC (Remote host closed the connection)
2442021-05-04T16:15:20 *** GarouDan_ <GarouDan_!~GarouDan@191.242.119.219.fibra.plimtelecom.com.br> has joined #bitcoin-core-dev
2452021-05-04T16:16:34 *** smctwo <smctwo!~smctwo@37.245.210.234> has joined #bitcoin-core-dev
2462021-05-04T16:17:45 *** stortz <stortz!c8b9c69a@unaffiliated/stortz> has quit IRC (Quit: Connection closed)
2472021-05-04T16:19:32 *** smctwo_ <smctwo_!~smctwo@37.245.210.234> has quit IRC (Ping timeout: 265 seconds)
2482021-05-04T16:20:01 *** GarouDan_ <GarouDan_!~GarouDan@191.242.119.219.fibra.plimtelecom.com.br> has quit IRC (Ping timeout: 265 seconds)
2492021-05-04T16:20:59 *** smctwo <smctwo!~smctwo@37.245.210.234> has quit IRC (Ping timeout: 265 seconds)
2502021-05-04T16:21:23 *** GarouDan <GarouDan!~GarouDan@191.242.119.219.fibra.plimtelecom.com.br> has joined #bitcoin-core-dev
2512021-05-04T16:24:44 *** smctwo <smctwo!~smctwo@37.245.210.234> has joined #bitcoin-core-dev
2522021-05-04T16:26:29 *** GarouDan <GarouDan!~GarouDan@191.242.119.219.fibra.plimtelecom.com.br> has quit IRC (Ping timeout: 268 seconds)
2532021-05-04T16:26:32 *** smctwo <smctwo!~smctwo@37.245.210.234> has quit IRC (Remote host closed the connection)
2542021-05-04T16:28:21 *** braydonf_ <braydonf_!~braydon@gateway/tor-sasl/braydonf> has quit IRC (Ping timeout: 240 seconds)
2552021-05-04T16:28:56 *** smctwo <smctwo!~smctwo@37.245.210.234> has joined #bitcoin-core-dev
2562021-05-04T16:28:59 *** lkqwejhhgasdjhgn <lkqwejhhgasdjhgn!~kljkljklk@p200300d46f06bf00ea203cd14cca75b0.dip0.t-ipconnect.de> has quit IRC (Quit: Konversation terminated!)
2572021-05-04T16:29:35 *** braydonf_ <braydonf_!~braydon@gateway/tor-sasl/braydonf> has joined #bitcoin-core-dev
2582021-05-04T16:33:39 *** smctwo <smctwo!~smctwo@37.245.210.234> has quit IRC (Remote host closed the connection)
2592021-05-04T17:00:18 *** proofofkeags <proofofkeags!~proofofke@205.209.28.54> has joined #bitcoin-core-dev
2602021-05-04T17:05:09 *** Talkless <Talkless!~Talkless@mail.dargis.net> has joined #bitcoin-core-dev
2612021-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
2622021-05-04T17:09:20 *** mol_ <mol_!~mol@unaffiliated/molly> has joined #bitcoin-core-dev
2632021-05-04T17:10:33 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
2642021-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
2652021-05-04T17:10:34 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
2662021-05-04T17:11:06 *** lightlike <lightlike!~lightlike@p200300c7ef197400945876005b846753.dip0.t-ipconnect.de> has joined #bitcoin-core-dev
2672021-05-04T17:12:28 *** mol <mol!~mol@unaffiliated/molly> has quit IRC (Ping timeout: 252 seconds)
2682021-05-04T17:18:52 *** smctwo <smctwo!~smctwo@91.75.111.136> has joined #bitcoin-core-dev
2692021-05-04T17:23:17 *** smctwo <smctwo!~smctwo@91.75.111.136> has quit IRC (Ping timeout: 260 seconds)
2702021-05-04T17:23:59 *** GarouDan <GarouDan!~GarouDan@191.242.119.219.fibra.plimtelecom.com.br> has joined #bitcoin-core-dev
2712021-05-04T17:24:24 *** Guyver2 <Guyver2!Guyver@guyver2.xs4all.nl> has joined #bitcoin-core-dev
2722021-05-04T17:25:45 *** cguida1 <cguida1!~Adium@2806:2f0:51c1:5cee:e16e:b2eb:67a2:57d9> has quit IRC (Quit: Leaving.)
2732021-05-04T17:36:31 *** jungly <jungly!~jungly@host-82-49-146-18.retail.telecomitalia.it> has quit IRC (Ping timeout: 252 seconds)
2742021-05-04T17:37:18 *** GarouDan <GarouDan!~GarouDan@191.242.119.219.fibra.plimtelecom.com.br> has quit IRC (Remote host closed the connection)
2752021-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.
2762021-05-04T17:46:35 *** sipsorcery <sipsorcery!~sipsorcer@2a02:8084:6981:7880::3> has quit IRC (Ping timeout: 260 seconds)
2772021-05-04T17:48:25 *** GarouDan <GarouDan!~GarouDan@191.242.119.219.fibra.plimtelecom.com.br> has joined #bitcoin-core-dev
2782021-05-04T17:52:29 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
2792021-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
2802021-05-04T17:52:30 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
2812021-05-04T17:53:18 *** GarouDan <GarouDan!~GarouDan@191.242.119.219.fibra.plimtelecom.com.br> has quit IRC (Ping timeout: 265 seconds)
2822021-05-04T17:56:05 *** justanotheruser <justanotheruser!~justanoth@unaffiliated/justanotheruser> has quit IRC (Ping timeout: 250 seconds)
2832021-05-04T17:56:52 *** justanotheruser <justanotheruser!~justanoth@unaffiliated/justanotheruser> has joined #bitcoin-core-dev
2842021-05-04T17:58:50 *** sipsorcery <sipsorcery!~sipsorcer@2a02:8084:6981:7880::3> has joined #bitcoin-core-dev
2852021-05-04T17:59:07 *** jarolrod <jarolrod!sid475272@gateway/web/irccloud.com/x-uxltcdqeskugbhyk> has quit IRC (Ping timeout: 245 seconds)
2862021-05-04T17:59:39 *** dunk <dunk!sid16@gateway/web/irccloud.com/x-szdtiubjgycubtjv> has quit IRC (Ping timeout: 260 seconds)
2872021-05-04T18:00:44 *** endogenic <endogenic!sid145991@gateway/web/irccloud.com/x-rpbwvsocatvzzacr> has quit IRC (Read error: Connection reset by peer)
2882021-05-04T18:00:51 *** digi_james <digi_james!sid281632@gateway/web/irccloud.com/x-bnvrcpkdhkxgxzpl> has quit IRC (Ping timeout: 250 seconds)
2892021-05-04T18:01:52 *** digi_james <digi_james!sid281632@gateway/web/irccloud.com/x-denjnhnlzrimsgue> has joined #bitcoin-core-dev
2902021-05-04T18:02:01 *** endogenic <endogenic!sid145991@gateway/web/irccloud.com/x-ygsbkwstspmhypgh> has joined #bitcoin-core-dev
2912021-05-04T18:02:09 *** jarolrod <jarolrod!sid475272@gateway/web/irccloud.com/x-urbxualqfzlausno> has joined #bitcoin-core-dev
2922021-05-04T18:02:15 *** dunk <dunk!sid16@gateway/web/irccloud.com/x-iomuwjcindcxowba> has joined #bitcoin-core-dev
2932021-05-04T18:02:22 *** hebasto <hebasto!sid449604@gateway/web/irccloud.com/x-gkvwysjshowrbwdf> has quit IRC (Ping timeout: 258 seconds)
2942021-05-04T18:04:34 *** hebasto <hebasto!sid449604@gateway/web/irccloud.com/x-legvqghpryoffxkf> has joined #bitcoin-core-dev
2952021-05-04T18:07:37 *** owowo <owowo!~ovovo@unaffiliated/ovovo> has quit IRC (Ping timeout: 260 seconds)
2962021-05-04T18:10:32 *** owowo <owowo!~ovovo@2a02:29b8:dc01:1881::2e> has joined #bitcoin-core-dev
2972021-05-04T18:19:20 *** IcKingAlpha <IcKingAlpha!~ident@62.182.99.225> has joined #bitcoin-core-dev
2982021-05-04T18:21:08 <robert_spigler> luke-jr: I agree with hugohn's analysis
2992021-05-04T18:22:52 *** vincenzopalazzo <vincenzopalazzo!~vincenzop@host-79-37-17-61.retail.telecomitalia.it> has quit IRC (Quit: Leaving)
3002021-05-04T19:02:59 *** pox <pox!~pox@gateway/tor-sasl/pox> has quit IRC (Remote host closed the connection)
3012021-05-04T19:04:38 *** pox <pox!~pox@gateway/tor-sasl/pox> has joined #bitcoin-core-dev
3022021-05-04T19:05:17 *** Talkless <Talkless!~Talkless@mail.dargis.net> has quit IRC (Quit: Konversation terminated!)
3032021-05-04T19:06:48 *** p0x <p0x!~pox@gateway/tor-sasl/pox> has joined #bitcoin-core-dev
3042021-05-04T19:07:00 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
3052021-05-04T19:07:01 <bitcoin-git> [bitcoin] Rqcker opened pull request #21857: Pull request (master...master) https://github.com/bitcoin/bitcoin/pull/21857
3062021-05-04T19:07:01 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
3072021-05-04T19:07:20 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
3082021-05-04T19:07:21 <bitcoin-git> [bitcoin] Rqcker closed pull request #21857: Pull request (master...master) https://github.com/bitcoin/bitcoin/pull/21857
3092021-05-04T19:07:21 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
3102021-05-04T19:09:33 *** pox <pox!~pox@gateway/tor-sasl/pox> has quit IRC (Ping timeout: 240 seconds)
3112021-05-04T19:16:15 *** justanotheruser <justanotheruser!~justanoth@unaffiliated/justanotheruser> has quit IRC (Ping timeout: 250 seconds)
3122021-05-04T19:20:29 *** sat <sat!571594ac@host-87-21-148-172.retail.telecomitalia.it> has joined #bitcoin-core-dev
3132021-05-04T19:23:00 *** duringo <duringo!2d57d6c5@45.87.214.197> has joined #bitcoin-core-dev
3142021-05-04T19:28:45 *** braydonf_ <braydonf_!~braydon@gateway/tor-sasl/braydonf> has quit IRC (Ping timeout: 240 seconds)
3152021-05-04T19:29:35 *** braydonf_ <braydonf_!~braydon@gateway/tor-sasl/braydonf> has joined #bitcoin-core-dev
3162021-05-04T19:30:10 *** sat <sat!571594ac@host-87-21-148-172.retail.telecomitalia.it> has quit IRC (Quit: Connection closed)
3172021-05-04T19:38:06 *** mol_ <mol_!~mol@unaffiliated/molly> has quit IRC (Ping timeout: 260 seconds)
3182021-05-04T19:45:13 *** mol <mol!~mol@unaffiliated/molly> has joined #bitcoin-core-dev
3192021-05-04T19:46:21 *** duringo <duringo!2d57d6c5@45.87.214.197> has quit IRC (Quit: Connection closed)
3202021-05-04T19:53:48 *** biteskola <biteskola!~biteskola@170.76.76.188.dynamic.jazztel.es> has joined #bitcoin-core-dev
3212021-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
3222021-05-04T19:58:51 *** justanotheruser <justanotheruser!~justanoth@unaffiliated/justanotheruser> has joined #bitcoin-core-dev
3232021-05-04T20:10:02 *** smartineng <smartineng!~Icedove@88.135.18.171> has quit IRC (Quit: smartineng)
3242021-05-04T20:16:19 *** p0x <p0x!~pox@gateway/tor-sasl/pox> has quit IRC (Remote host closed the connection)
3252021-05-04T20:18:27 *** OldMiner <OldMiner!~OldMiner@185.169.233.12> has quit IRC (Remote host closed the connection)
3262021-05-04T20:18:35 *** pox <pox!~pox@gateway/tor-sasl/pox> has joined #bitcoin-core-dev
3272021-05-04T20:22:58 *** zpao <zpao!~zpao@185.163.110.100> has joined #bitcoin-core-dev
3282021-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.
3292021-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
3302021-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.
3312021-05-04T20:56:04 *** duringo <duringo!c11b0cfd@193.27.12.253> has joined #bitcoin-core-dev
3322021-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.
3332021-05-04T20:56:34 <gmaxwell> Someone who cares about p2p might want to fix this.
3342021-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)
3352021-05-04T20:59:05 *** wumpus <wumpus!~ircclient@pdpc/supporter/professional/wumpus> has quit IRC (Ping timeout: 258 seconds)
3362021-05-04T20:59:06 <gmaxwell> (my correct behavior might be slowly fixing the second forked-chain problem since I should be healing the partition)
3372021-05-04T21:00:04 *** wumpus <wumpus!~ircclient@pdpc/supporter/professional/wumpus> has joined #bitcoin-core-dev
3382021-05-04T21:00:29 <jnewbery> #startmeeting
3392021-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.
3402021-05-04T21:00:29 <core-meetingbot> Available commands: action commands idea info link nick
3412021-05-04T21:00:34 <amiti> hi
3422021-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
3432021-05-04T21:00:36 <gleb> hi
3442021-05-04T21:00:42 <glozow> hi
3452021-05-04T21:00:42 <jnewbery> petertodd phantomcircuit promag provoostenator ryanofsky sdaftuar sipa vasild wumpus
3462021-05-04T21:00:48 <sipa> hi
3472021-05-04T21:00:58 <ajonas> hi
3482021-05-04T21:01:03 <jnewbery> There aren't any proposed topics in https://github.com/bitcoin-core/bitcoin-devwiki/wiki/P2P-IRC-meetings
3492021-05-04T21:01:20 <jnewbery> Feel free to share your priorities in https://github.com/bitcoin-core/bitcoin-devwiki/wiki/P2P-Current-Priorities
3502021-05-04T21:01:36 <jnewbery> Does anyone have any topics to add?
3512021-05-04T21:02:06 <sipa> i'm working on PR'ing minisketch
3522021-05-04T21:02:17 <sipa> i think it's in a good enough state now
3532021-05-04T21:02:46 <jnewbery> \o/
3542021-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.
3552021-05-04T21:03:02 <gleb> *to invite people to run nodes.
3562021-05-04T21:03:18 <sipa> gleb: cool, will run
3572021-05-04T21:03:22 <glozow> \o/
3582021-05-04T21:03:37 <jnewbery> sipa: are you looking for any specific help?
3592021-05-04T21:04:10 <sipa> not in particular, but review is of course always welcome
3602021-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
3612021-05-04T21:04:52 <sipa> also way faster compilation
3622021-05-04T21:05:09 <jnewbery> that seems good
3632021-05-04T21:06:13 <jnewbery> ok, any other topics?
3642021-05-04T21:07:01 <jnewbery> alright!
3652021-05-04T21:07:03 <jnewbery> #endmeeting
3662021-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
3672021-05-04T21:07:04 <core-meetingbot> Meeting ended Tue May 4 21:07:03 2021 UTC.
3682021-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
3692021-05-04T21:08:21 *** braydonf_ <braydonf_!~braydon@gateway/tor-sasl/braydonf> has quit IRC (Ping timeout: 240 seconds)
3702021-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?
3712021-05-04T21:09:35 *** braydonf_ <braydonf_!~braydon@gateway/tor-sasl/braydonf> has joined #bitcoin-core-dev
3722021-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
3732021-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
3742021-05-04T21:12:47 *** Guyver2 <Guyver2!Guyver@guyver2.xs4all.nl> has quit IRC (Quit: Going offline, see ya! (www.adiirc.com))
3752021-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
3762021-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.)
3772021-05-04T21:17:26 <gmaxwell> gleb: what protocol change?
3782021-05-04T21:17:29 *** smctwo <smctwo!~smctwo@bba597217.alshamil.net.ae> has joined #bitcoin-core-dev
3792021-05-04T21:17:35 <jnewbery> Did you try gating on fHaveWitness instead of fClient?
3802021-05-04T21:17:45 *** GarouDan <GarouDan!~GarouDan@191.242.119.219.fibra.plimtelecom.com.br> has joined #bitcoin-core-dev
3812021-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.
3822021-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)
3832021-05-04T21:21:50 <sipa> gleb: was it needed to include minisketch in bitcoin-tx?
3842021-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.
3852021-05-04T21:23:41 <gleb> gmaxwell: Ah hold on, maybe ignore that.
3862021-05-04T21:23:51 <gleb> I just realized maybe it's fine all the way.
3872021-05-04T21:24:12 <gleb> sipa: sorry, are you referring to the way I integrate minisketch in the erlay PR?
3882021-05-04T21:24:38 <sipa> gleb: yeah, cherry picking that
3892021-05-04T21:24:43 <sipa> just wonder if there was a reason for that
3902021-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.
3912021-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
3922021-05-04T21:26:56 <gleb> gmaxwell: I'm glad you're following the work anyway.
3932021-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.
3942021-05-04T21:29:06 <gleb> gmaxwell: Agree, I should think if I could gracefully disconnect the "general intuition" from protocol language.
3952021-05-04T21:29:52 <sipa> right, the protocol should only concern itself with "inbound" and "outbound" and "recon sender" and "recon receiver"
3962021-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?
3972021-05-04T21:31:07 *** GarouDan <GarouDan!~GarouDan@191.242.119.219.fibra.plimtelecom.com.br> has quit IRC (Remote host closed the connection)
3982021-05-04T21:31:49 *** undvrainbowvita8 <undvrainbowvita8!~egp_@128-71-13-3.broadband.corbina.ru> has joined #bitcoin-core-dev
3992021-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.
4002021-05-04T21:32:12 <gleb> I should admit I never considered this corner case.
4012021-05-04T21:33:11 <sipa> hmm, do we just want to disable reconciliation on connections to/from non-public IPs?
4022021-05-04T21:33:35 <gmaxwell> that shouldn't be neceesary.
4032021-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
4042021-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?
4052021-05-04T21:35:20 <gleb> sipa: right. Or maybe if there are N bridges, but A is still generally unavailable.
4062021-05-04T21:36:18 <sipa> sorry, i swapped notation; my A and B are the B and A in your explanation
4072021-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.
4082021-05-04T21:37:04 <sipa> gleb: is the logic "only use recon for transaction received from inbound connections" now?
4092021-05-04T21:37:21 <gleb> sipa: only use flood in that case.
4102021-05-04T21:37:40 <gleb> Ok, there are 2 relevant flags.
4112021-05-04T21:37:45 <sipa> gmaxwell: the choice whether to relay through recon or flood reveals information
4122021-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.
4132021-05-04T21:38:29 <sipa> gmaxwell: that's not what erlay proposes
4142021-05-04T21:38:55 <gmaxwell> I don't remember it being broken. :P
4152021-05-04T21:39:01 <gleb> sipa is correct, it was always either or
4162021-05-04T21:39:03 <sipa> come on
4172021-05-04T21:39:14 <gmaxwell> sipa: failing to add it to recon strictly wastes bandwidth, unless I'm confused.
4182021-05-04T21:39:23 <gmaxwell> Quite possible I'm confused.
4192021-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.
4202021-05-04T21:40:11 <gmaxwell> As your remote peer won't make the same flood/no-flood decision you do.
4212021-05-04T21:40:44 <gmaxwell> Am I confused?
4222021-05-04T21:40:50 <sipa> i'm trying to swap in the whole idea again :)
4232021-05-04T21:40:57 <gleb> Yeah same here, gimme a second.
4242021-05-04T21:41:00 <sipa> gleb: what happens with locally generated transactions?
4252021-05-04T21:41:05 <gmaxwell> I don't think this changes the fundimental issue gleb is looking at though.
4262021-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.
4272021-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...
4282021-05-04T21:42:46 <sipa> gleb: so in which cases do you only flood a tx?
4292021-05-04T21:43:57 <gleb> sipa: if the transaction is received from inbound AND the peer is 1 of 8 outbound flooding peers.
4302021-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)
4312021-05-04T21:44:45 <sipa> which for now is effectively all outbound peers?
4322021-05-04T21:45:04 <gleb> sipa: yes, now. ANd my confusion was the case after bump, but now I think that case is fine.
4332021-05-04T21:45:19 <gleb> The bridge case is not fine though. When this non-reachable is a bridge.
4342021-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
4352021-05-04T21:45:53 <sipa> i believe the solution is just changing the criterion to "received from inbound *with public IP* AND ..."
4362021-05-04T21:46:05 <gmaxwell> ehhh
4372021-05-04T21:46:28 <sipa> but i still want to understand this again
4382021-05-04T21:46:39 <sipa> because i don't remember why this flooding is done in the first place
4392021-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. :)
4402021-05-04T21:47:36 <sipa> gleb: you say "received", is that both when received through flooding and through recon?
4412021-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.
4422021-05-04T21:48:36 <gleb> It all looks like inbound inv.
4432021-05-04T21:48:47 <sipa> ok, just trying to reconcile my memory
4442021-05-04T21:49:02 <gleb> gmaxwell: I have to think why I didn't do additive
4452021-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?
4462021-05-04T21:49:33 <sipa> lightlike: no
4472021-05-04T21:49:41 <sipa> (well, both)
4482021-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.
4492021-05-04T21:49:45 <gleb> yeah, both.
4502021-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
4512021-05-04T21:50:56 <sipa> how does "received from an inbound connection" lead to that prediction?
4522021-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?
4532021-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...
4542021-05-04T21:52:08 <gleb> gmaxwell: ok, my approach works, and let me explain.
4552021-05-04T21:52:38 <gmaxwell> gleb: that is why the flooded relay is low fanout.
4562021-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.
4572021-05-04T21:52:55 <gleb> That's why both sets won't have the tx at the end
4582021-05-04T21:53:54 <gmaxwell> gleb: But node_b also could have recieved it from someone else first.
4592021-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
4602021-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.
4612021-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)
4622021-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
4632021-05-04T21:55:58 <sipa> (in case you flood)
4642021-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.
4652021-05-04T21:56:19 <sipa> delete if it was in that set in the first place, of course
4662021-05-04T21:56:39 <gmaxwell> okay I agree that would also work.
4672021-05-04T21:57:06 <gleb> Yeah, I see the point indeed. We should get rid of this extra assumption
4682021-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.
4692021-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?
4702021-05-04T21:58:21 <gleb> sipa: now, but I'm realizing now I should.
4712021-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
4722021-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.
4732021-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?
4742021-05-04T21:59:50 <sipa> gmaxwell: yes, it ~ns scal different
4752021-05-04T22:00:03 <sipa> not adding on both sides
4762021-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.
4772021-05-04T22:01:18 <gleb> If we stick to these rules, we also want to flood some to make relay across the "backbone" faster.
4782021-05-04T22:01:28 <gleb> gmaxwell: how would you suggest to flood?
4792021-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.
4802021-05-04T22:03:05 <gmaxwell> sipa: GOOD. I am glad to agree!
4812021-05-04T22:03:40 <gmaxwell> gleb: okay, I don't understand how I was ever okay with that. lol
4822021-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.
4832021-05-04T22:04:41 <gmaxwell> (e.g. the NATed node with some lan peers)
4842021-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"
4852021-05-04T22:05:13 <gleb> Which is, yeah, not true for NAT stuff.
4862021-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"?
4872021-05-04T22:08:00 <sipa> gmaxwell: by new do you mean "locally created", or "any new tx learned through whatever means at all" ?
4882021-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.
4892021-05-04T22:08:17 <sipa> (i assume the second, as the first is a pretty bad privacy leak)
4902021-05-04T22:08:20 <gmaxwell> newly learned, however we learned it.. flooding, local, retcon.
4912021-05-04T22:08:25 <gmaxwell> Anything accept to mempool accepts.
4922021-05-04T22:09:25 <gmaxwell> gleb: yes, its often useless. But it is still a constant amount of data per accepted transaction.
4932021-05-04T22:09:31 *** pox <pox!~pox@gateway/tor-sasl/pox> has quit IRC (Remote host closed the connection)
4942021-05-04T22:09:42 <gmaxwell> (and not an amount that grows with the number of peers it has)
4952021-05-04T22:10:14 *** pox <pox!~pox@gateway/tor-sasl/pox> has joined #bitcoin-core-dev
4962021-05-04T22:10:40 <gmaxwell> if fanout > 1 the vast majority of flooding will always be useless.
4972021-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?
4982021-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)
4992021-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
5002021-05-04T22:11:58 <gmaxwell> Right, at least at one point I know I was thinking in terms of fanout=2.
5012021-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.
5022021-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
5032021-05-04T22:14:43 <gmaxwell> sipa: yes I am starting to see how things ended up here.
5042021-05-04T22:15:00 <sipa> i don't really see the problem with it
5052021-05-04T22:15:31 <gleb> And we can always switch to something different if at some point NAT landscape changes?
5062021-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.
5072021-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.
5082021-05-04T22:17:01 <gmaxwell> I'm not sure why we'd intentionally do that.
5092021-05-04T22:18:10 <gleb> gmaxwell: the timings were 1s for 95% reachable, 5s for 95% non-reachable. Something along those numbers.
5102021-05-04T22:18:34 <gleb> (the time it takes to spread a transaction). Saying "rapidly forwarding" is not so different
5112021-05-04T22:18:47 <gleb> Again, assuming the topology.
5122021-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
5132021-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?
5142021-05-04T22:19:51 <gmaxwell> but not completely benign since now we have problems with txn originated 'near' these flooding non-participants.
5152021-05-04T22:20:19 *** smctwo <smctwo!~smctwo@bba597217.alshamil.net.ae> has quit IRC (Remote host closed the connection)
5162021-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.
5172021-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
5182021-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.
5192021-05-04T22:23:01 <sipa> figure 19 in the paper shows bandwidth/latency simulations for a number of configurations
5202021-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.
5212021-05-04T22:23:27 <gmaxwell> :P
5222021-05-04T22:23:55 <gmaxwell> but I don't really get the reasoning now. :(
5232021-05-04T22:24:48 <sipa> "flooding is not as useful to peers which are better connected than you are" is the summary i think
5242021-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.
5252021-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.
5262021-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
5272021-05-04T22:26:41 <sipa> gmaxwell: that's fair
5282021-05-04T22:27:19 <gleb> sipa: I can't explain that now.
5292021-05-04T22:28:27 <sipa> gleb: is that graph using the same logic (only flood transactions receiving on incoming connections)?
5302021-05-04T22:28:43 <gleb> sipa: yes I think so.
5312021-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
5322021-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
5332021-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
5342021-05-04T22:30:35 <gmaxwell> and only requested them from peers they connected out to (which were more themselves in the same broken state)
5352021-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)
5362021-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.
5372021-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.
5382021-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.
5392021-05-04T22:36:03 <gleb> Sorry for keeping the reachable terminology, I'm just explaining how sipa logic maps to my design.
5402021-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)
5412021-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.
5422021-05-04T22:37:22 <gleb> well, i mean you also would prefer to avoid reasoning about it in the design i thought?
5432021-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.
5442021-05-04T22:38:40 <gleb> gmaxwell: you mean sending tx bodies?
5452021-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
5462021-05-04T22:38:57 <gmaxwell> yes
5472021-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?
5482021-05-04T22:39:50 <gmaxwell> nah, it's like a 2:1 asymmetry as seen on my nodes.
5492021-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
5502021-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)
5512021-05-04T22:40:56 <gmaxwell> sipa: I actually mean bandwidth though both might be true.
5522021-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.
5532021-05-04T22:41:40 <sipa> i don't see why that would be the case
5542021-05-04T22:41:44 <gmaxwell> just thinking through the implications of taking the majority of nodes out of the general forwarding process.
5552021-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.
5562021-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.
5572021-05-04T22:43:25 <gmaxwell> ^
5582021-05-04T22:44:01 <sipa> ok let me be more specific about what i'm not convinced of
5592021-05-04T22:44:08 <gmaxwell> that doesn't seem desirable to me, ... some asymetry is unavoidable because they have fewer connections each.
5602021-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"
5612021-05-04T22:44:33 <gmaxwell> gleb: I don't think I ever considered that particular aspect before.
5622021-05-04T22:44:50 <gmaxwell> (lol well, I really don't know what I thought before, it's been too long)
5632021-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
5642021-05-04T22:45:53 *** GarouDan <GarouDan!~GarouDan@191.242.119.219.fibra.plimtelecom.com.br> has joined #bitcoin-core-dev
5652021-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
5662021-05-04T22:46:28 <gleb> I think greg's 2:1 can't agree with you.
5672021-05-04T22:47:01 <gleb> I assume, non-reachable sends 0.5x of reachable's tx body traffic?
5682021-05-04T22:47:02 <gmaxwell> sipa: sendign tx _bodies_ is never redundant.
5692021-05-04T22:47:13 <gmaxwell> lemme go get current figures one sec.
5702021-05-04T22:47:42 <sipa> gmaxwell: ah good point, every body only arrives at every node once
5712021-05-04T22:48:05 <sipa> whatever non-reachable nodes are doing in that regard must be compensated by others
5722021-05-04T22:48:16 <sipa> ok, that's convincing
5732021-05-04T22:49:10 *** Squidicc <Squidicc!~squid@pool-72-74-34-120.bstnma.fios.verizon.net> has joined #bitcoin-core-dev
5742021-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.
5752021-05-04T22:49:54 <gmaxwell> (it's just data in getpeerinfo)
5762021-05-04T22:50:06 <gleb> So potentially 2 problems with current design: 1) NAT privacy (could probably be fixed) 2) deepening the asymmetry
5772021-05-04T22:50:17 <gmaxwell> my very bad informal memory says that it was asymmetric, but except for bognon peers not THAT asymmetric.
5782021-05-04T22:50:27 <gmaxwell> bogon*
5792021-05-04T22:50:32 *** GarouDan <GarouDan!~GarouDan@191.242.119.219.fibra.plimtelecom.com.br> has quit IRC (Ping timeout: 252 seconds)
5802021-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)
5812021-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.
5822021-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.
5832021-05-04T22:54:14 <gleb> gmaxwell: was it symmetrical before groups? Even when we just had 2s/5s independent timers?
5842021-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.
5852021-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.
5862021-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.
5872021-05-04T22:57:01 <gmaxwell> which I couldn't dismiss as being some weird peer.
5882021-05-04T22:57:12 <gmaxwell> well, sipa is weird but his bitcoin node isn't. :P
5892021-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
5902021-05-04T22:57:40 <gleb> I think that could have been my first PR to core in 2018.
5912021-05-04T22:58:02 <gmaxwell> Well you don't know what you don't know.
5922021-05-04T22:58:21 <gmaxwell> You could easily model the txdata burden, I just never thought of it.
5932021-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.
5942021-05-04T23:00:08 <gmaxwell> sorry.
5952021-05-04T23:00:49 <gleb> But that stuff we also changed in the context of invblock or tx overhaul or something recently? :)
5962021-05-04T23:01:02 <gleb> like, this exact suggestion, making it random and not first received
5972021-05-04T23:02:52 *** smctwo <smctwo!~smctwo@bba597217.alshamil.net.ae> has joined #bitcoin-core-dev
5982021-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.
5992021-05-04T23:03:37 <gleb> Yeah, that's exactly figure 19, except it chooses the flood peers randomly.
6002021-05-04T23:04:05 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
6012021-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
6022021-05-04T23:04:07 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
6032021-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
6042021-05-04T23:08:29 <sipa> gmaxwell: something like that?
6052021-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"'
6062021-05-04T23:08:53 <gmaxwell> is what I ended up with.
6072021-05-04T23:09:06 <gmaxwell> but yea your is better.
6082021-05-04T23:09:46 <gmaxwell> these need to be normalized though because naturally you'll only recieve once.
6092021-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.
6102021-05-04T23:10:08 <sipa> gleb: that's surprising
6112021-05-04T23:10:37 <gmaxwell> that is anti-surprising to me! :P
6122021-05-04T23:11:06 *** smctwo <smctwo!~smctwo@bba597217.alshamil.net.ae> has quit IRC (Ping timeout: 240 seconds)
6132021-05-04T23:11:08 <sipa> it conflicts with my intuition for why increasing flooding reducing bandwidth
6142021-05-04T23:12:06 <gleb> oh, hold on, sorry, the simulator is old code and hard to understand now :(
6152021-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.
6162021-05-04T23:16:41 <gleb> And since inbound always initiates, we effectively announce "what is learned inbound". The lattest simulator has that it seems.
6172021-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?
6182021-05-04T23:17:57 <sipa> just trying "flood relay everything to 2-3-4-5-6-7-8 outbound peers" ?
6192021-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.
6202021-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.
6212021-05-04T23:21:22 <gleb> gmaxwell: you mean poor in the sense of asymmetry?
6222021-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.
6232021-05-04T23:22:21 <gmaxwell> (because the latter outnumber the former)
6242021-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.
6252021-05-04T23:23:07 <gmaxwell> :( I feel bad.
6262021-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
6272021-05-04T23:23:19 <sipa> (if we'd make it)
6282021-05-04T23:23:29 <gmaxwell> yea I don't think it really changes the implementation much except for a few lines here and there.
6292021-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
6302021-05-04T23:23:55 <gleb> sipa: i agree, most of the module remains the same, this stuff is even outside the module.
6312021-05-04T23:24:03 <gleb> sipa: i noted it, don't worry
6322021-05-04T23:24:08 <sipa> gleb: thanks!
6332021-05-04T23:24:26 <gmaxwell> in the meantime, minisketch could get merged, and dropped from the erlay PR. That would be nice progress.
6342021-05-04T23:24:41 <gleb> okay, thank you, i'll come back once i have the results. I agree on the plan ^
6352021-05-04T23:25:02 *** GarouDan <GarouDan!~GarouDan@191.242.119.219.fibra.plimtelecom.com.br> has joined #bitcoin-core-dev
6362021-05-04T23:25:57 *** smctwo <smctwo!~smctwo@bba597217.alshamil.net.ae> has joined #bitcoin-core-dev
6372021-05-04T23:30:46 *** smctwo <smctwo!~smctwo@bba597217.alshamil.net.ae> has quit IRC (Ping timeout: 240 seconds)
6382021-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)
6392021-05-04T23:31:55 *** sipsorcery <sipsorcery!~sipsorcer@2a02:8084:6981:7880::3> has quit IRC (Ping timeout: 260 seconds)
6402021-05-04T23:33:04 *** mrostecki <mrostecki!mrostecki@nat/suse/x-qunzagdczmwaveyc> has quit IRC (Ping timeout: 276 seconds)
6412021-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.
6422021-05-04T23:34:39 *** mrostecki <mrostecki!mrostecki@nat/suse/x-bdsgmfrittaifnzu> has joined #bitcoin-core-dev
6432021-05-04T23:49:24 *** lightlike <lightlike!~lightlike@p200300c7ef197400945876005b846753.dip0.t-ipconnect.de> has quit IRC (Quit: Leaving)
6442021-05-04T23:55:48 *** morcos <morcos!~morcos@gateway/tor-sasl/morcos> has quit IRC (Remote host closed the connection)
6452021-05-04T23:56:08 *** morcos <morcos!~morcos@gateway/tor-sasl/morcos> has joined #bitcoin-core-dev