--- Log opened Thu Feb 02 00:00:09 2023
--- Day changed Thu Feb 02 2023
00:00 -!- b_101 [~robert@fixed-187-189-246-111.totalplay.net] has quit [Ping timeout: 260 seconds]
00:03 -!- javi404 [~quassel@c-73-1-238-68.hsd1.fl.comcast.net] has quit [Remote host closed the connection]
00:04 -!- javi404 [~quassel@c-73-1-238-68.hsd1.fl.comcast.net] has joined #bitcoin-core-dev
00:33 -!- dermoth [~dermoth@user/dermoth] has quit [Ping timeout: 255 seconds]
00:36 -!- robszarka [~szarka@24-124-20-18-static.midco.net] has joined #bitcoin-core-dev
00:39 -!- szarka [~szarka@24-124-20-18-static.midco.net] has quit [Ping timeout: 252 seconds]
00:42 -!- enyc [~enyc@user/enyc] has quit [Ping timeout: 264 seconds]
00:44 -!- rszarka [~szarka@172-5-81-212.lightspeed.mssnks.sbcglobal.net] has joined #bitcoin-core-dev
00:47 -!- robszarka [~szarka@24-124-20-18-static.midco.net] has quit [Ping timeout: 248 seconds]
00:51 -!- Guyver2 [~Guyver@77-174-98-73.fixed.kpn.net] has joined #bitcoin-core-dev
01:10 -!- robszarka [~szarka@24-124-20-18-static.midco.net] has joined #bitcoin-core-dev
01:10 -!- robszarka [~szarka@24-124-20-18-static.midco.net] has quit [K-Lined]
01:12 -!- szarka [~szarka@2001:48f8:9004:580:a4b2:2e59:5fd0:de7e] has joined #bitcoin-core-dev
01:13 -!- rszarka [~szarka@172-5-81-212.lightspeed.mssnks.sbcglobal.net] has quit [Ping timeout: 248 seconds]
01:22 -!- dermoth [~dermoth@user/dermoth] has joined #bitcoin-core-dev
01:24 -!- dougefish [~dougefish@2a00:a041:3c18:b400:1ac0:4dff:fe34:3985] has joined #bitcoin-core-dev
01:30 -!- dermoth [~dermoth@user/dermoth] has quit [Ping timeout: 255 seconds]
01:42 -!- dermoth [~dermoth@user/dermoth] has joined #bitcoin-core-dev
01:43 < bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/fdd363ebd917...102645280b94
01:43 < bitcoin-git> bitcoin/master 71383f2 fanquake: ci: avoid using -Werror for older compilers
01:43 < bitcoin-git> bitcoin/master 1026452 MarcoFalke: Merge bitcoin/bitcoin#27013: ci: avoid using `-Werror` for older compilers
01:43 < bitcoin-git> [bitcoin] MarcoFalke merged pull request #27013: ci: avoid using `-Werror` for older compilers (master...avoid_werror_older_release_compiler) https://github.com/bitcoin/bitcoin/pull/27013
01:52 -!- PaperSword [~Thunderbi@securemail.qrsnap.io] has joined #bitcoin-core-dev
02:00 -!- Guyver2 [~Guyver@77-174-98-73.fixed.kpn.net] has left #bitcoin-core-dev [Closing Window]
02:00 -!- MrFrancis [~MrFrancis@2001:8a0:fa4c:901:8d8b:fd03:72e6:773e] has joined #bitcoin-core-dev
02:01 -!- hsmiths [~Thunderbi@76-240-112-146.lightspeed.irvnca.sbcglobal.net] has quit [Ping timeout: 260 seconds]
02:20 < bitcoin-git> [bitcoin] fanquake closed pull request #26348: Make P2SH redeem script "IF .. PUSH x ELSE ... PUSH y ENDIF CHECKMULTISIG .. " standard (master...master) https://github.com/bitcoin/bitcoin/pull/26348
02:30 < bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/102645280b94...9dc50a5a0788
02:30 < bitcoin-git> bitcoin/master fad7af7 MarcoFalke: Use steady clock for logging timer
02:30 < bitcoin-git> bitcoin/master 9dc50a5 fanquake: Merge bitcoin/bitcoin#27005: util: Use steady clock for logging timer
02:31 < bitcoin-git> [bitcoin] fanquake merged pull request #27005: util: Use steady clock for logging timer (master...2301-log-steady-clock-🔆) https://github.com/bitcoin/bitcoin/pull/27005
02:36 -!- ghost43_ [~ghost43@gateway/tor-sasl/ghost43] has quit [Remote host closed the connection]
02:36 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #bitcoin-core-dev
02:47 < bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/9dc50a5a0788...21138fe37724
02:47 < bitcoin-git> bitcoin/master fa47b28 MarcoFalke: refactor: Remove unused CDataStream SerializeMany constructor
02:47 < bitcoin-git> bitcoin/master 21138fe fanquake: Merge bitcoin/bitcoin#26992: refactor: Remove unused CDataStream Serialize...
02:47 < bitcoin-git> [bitcoin] fanquake merged pull request #26992: refactor: Remove unused CDataStream SerializeMany constructor (master...2301-ser-many-remove-💻) https://github.com/bitcoin/bitcoin/pull/26992
02:52 -!- sudoforge [~sudoforge@wireguard/tunneler/sudoforge] has joined #bitcoin-core-dev
02:53 -!- Guest3492 [~Guest34@110.235.229.2] has joined #bitcoin-core-dev
02:53 -!- Guest3492 [~Guest34@110.235.229.2] has quit [Client Quit]
02:57 -!- Livestradamus8 [~Livestrad@user/livestradamus] has joined #bitcoin-core-dev
02:59 -!- Livestradamus [~Livestrad@user/livestradamus] has quit [Ping timeout: 248 seconds]
02:59 -!- Livestradamus8 is now known as Livestradamus
03:05 -!- PaperSword [~Thunderbi@securemail.qrsnap.io] has quit [Quit: PaperSword]
03:13 -!- AaronvanW [~AaronvanW@user/AaronvanW] has joined #bitcoin-core-dev
03:28 < fjahr> sipa: Thanks a lot for taking a look! On performance/bottneck.py: Yeah, I am sure there is room for improvement in terms of performance, I only glanced at bottleneck.py briefly and saw that it uses a different approach (I use numpy and pandas) so I skipped digging deeper because I just wanted to get something out that sort of works for conceptual discussion. I will work on improving performance when we have agreement on 
03:28 < fjahr> data sources and the release process steps.
03:28 < fjahr> And yeah, that was my understanding that we would work towards shipping a file with Bitcoin Core. Maybe in the first iteration it gets shipped with the release but it’s not used by default. However users could use the included file by just passing -asmap=1 and they don’t have to get the file from somewhere and provide it explicitly. I think that might be a good intermediate step. Of course they should still be able to 
03:28 < fjahr> override it with their own file.
03:29 < fjahr> On the asmap file export for audit purposes: I didn’t spend much time thing about it but my first question would be, do we really need to make it that explicit? I am thinking of the ASMap file as code, it’s just not tracked in the repo. But the selected candidate file could still be pulled from the asmap-data repo and included in the reproducible build process, right? So those that run the build process will not get the 
03:29 < fjahr> same result if the file is different, those that check the signatures can be sure the right file was used. And those that want to look at the raw file can download it from asmap-data and compare the hash. If we need it I would suggest the binary writes it out to default-asmap.dat in the datadir. But I am a developer and move stuff around in the datadir all the time, so maybe my opinion doesn’t align with most users and 
03:29 < fjahr> for them an explicit export RPC is better. I think someone will write that RPC eventually anyway, might be a good first issue.
03:29 < fjahr> On how to use the multimap stuff: yeah, that would need a change in the bucketing logic and I haven’t worked on that yet. But the background is: Initially gleb already mentioned this as a potential issue and “stretch goal” in his write-up after coredev zurich, that there are big entities that have multiple ASNs and just bucketing for ASNs alone doesn’t catch that. Since the ROAs are signed we know that if there are 
03:29 < fjahr> two valid ROAs for the same IP block but with different ASNs, then either this is the same entity that has multiple ASNs or these are two different entities that have very close business ties. Either way I think it makes sense to stick both ASNs in the same bucket in that case. But indeed it’s a nice to have for the start, but I wanted to name it as a clear additional win from using RPKI. In Kartograf I am currently 
03:29 < fjahr> discarding the additional ROAs. Unfortunately there is no good tie-breaker when deciding between two different ROAs but we can just decide on something.
03:32 < fjahr> We could probably also solve this without changing the bucketing logic by writing synthetic consolidated ASNs into the asmap. But that is just a spontaneous idea, I will need to think about this more.
03:33 < fjahr> Downside, that would probably make it harder to audit the ASMap.
03:45 < bitcoin-git> [gui] hebasto merged pull request #704: Correctly limit overview transaction list (master...2023_01_FixOverviewTxList) https://github.com/bitcoin-core/gui/pull/704
03:46 < bitcoin-git> [bitcoin] hebasto pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/21138fe37724...526f67a5cabf
03:46 < bitcoin-git> bitcoin/master 08209c0 John Moffett: Correctly limit overview transaction list
03:46 < bitcoin-git> bitcoin/master 526f67a Hennadii Stepanov: Merge bitcoin-core/gui#704: Correctly limit overview transaction list
03:49 < bitcoin-git> [bitcoin] willcl-ark opened pull request #27025: github: Switch to yaml issue templates (master...yaml-issue-templates) https://github.com/bitcoin/bitcoin/pull/27025
04:05 -!- MrFrancis [~MrFrancis@2001:8a0:fa4c:901:8d8b:fd03:72e6:773e] has quit [Ping timeout: 248 seconds]
04:19 < bitcoin-git> [gui] hebasto merged pull request #695: Fix misleading RPC console wallet message (master...2023_01_FixNoWalletRPCConsoleMessage) https://github.com/bitcoin-core/gui/pull/695
04:19 < bitcoin-git> [bitcoin] hebasto pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/526f67a5cabf...ea41abade4b7
04:19 < bitcoin-git> bitcoin/master 576f7b8 John Moffett: Fix misleading RPC console wallet message
04:19 < bitcoin-git> bitcoin/master ea41aba Hennadii Stepanov: Merge bitcoin-core/gui#695: Fix misleading RPC console wallet message
04:20 -!- dviola [~diego@user/dviola] has joined #bitcoin-core-dev
04:22 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Quit: Leaving]
04:22 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #bitcoin-core-dev
04:30 -!- Norrin [~NorrinRad@gateway/tor-sasl/norrinradd] has quit [Remote host closed the connection]
04:51 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:dc72:ba28:fc:9810] has quit [Remote host closed the connection]
04:52 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:dc72:ba28:fc:9810] has joined #bitcoin-core-dev
04:53 -!- MrFrancis [~MrFrancis@2001:8a0:fa4c:901:8d8b:fd03:72e6:773e] has joined #bitcoin-core-dev
05:02 -!- AaronvanW [~AaronvanW@user/AaronvanW] has quit [Remote host closed the connection]
05:04 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:dc72:ba28:fc:9810] has quit [Remote host closed the connection]
05:04 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:dc72:ba28:fc:9810] has joined #bitcoin-core-dev
05:12 -!- MrFrancis [~MrFrancis@2001:8a0:fa4c:901:8d8b:fd03:72e6:773e] has quit [Ping timeout: 252 seconds]
05:20 < sipa> fjahr: Oh you're talking about one entity having multiple ASNs? Or multiple IPs having the same ASN?
05:20 < sipa> In the first case, if it can be identified, it doesn't matter; just give them one number. The actual numbers don't matter, just whether IPs are in the same or different ASNs.
05:21 < fjahr> one entity having multiple ASN and each ASN announcing multiple IP blocks, with some overlap on the IP blocks between them
05:23 < fjahr> yeah, that would be the "synthetic" ASN then, where the ASN in asmap is not the same as it was in the ROA, just makes auditing/resoning harder I think, but I will try this out
05:24 < sipa> The only thing the actual choice of ASN matters for is when switching from one asmap to another, a remapping in addrman happens... if the more thing remain in the same ASN the less information will collide on update.
05:24 -!- nanotube [~nanotube@user/nanotube] has quit [Ping timeout: 252 seconds]
05:24 < sipa> So if you use some way of choosing a synthetic ASN (probably from the set of real ones), it's better to do it in a way that does flip-flop too much.
05:25 < sipa> fjahr: You're right, perhaps being able to inspect the built-in asmap doesn't matter too much; it can be consider source code, and presumably can be found when looking at the source.
05:30 < sipa> I looked at your example PR with IP ASN mappings text file... I saw it contains a number of things the current binary format can't deal with (AS0, and multiple numbers separated by underscores or commas; also a few numbers that are too large). If I drop all of those (picking the first in case of _ and ,), I get an encoded file that's close in size to what my collection/bottlenecking logic does, though a very substantial portion of the IP ranges are mapped
05:30 < sipa> differently.
05:31 -!- AaronvanW [~AaronvanW@user/AaronvanW] has joined #bitcoin-core-dev
05:31 -!- Norrin [~NorrinRad@gateway/tor-sasl/norrinradd] has joined #bitcoin-core-dev
05:33 < fjahr> ok, I will play with that concept of joining ASNs a bit and see what the results would look like. I know about 10% of valid ROAs have another ROA that announces a different ASN for the same IP block but beyond that I need better statistics.
05:33 < fjahr> Ok, weird about the formatting stuff, I will take a look.
05:35 < fjahr> For the differences as well I will have to check where they are coming from. The example is partly RPKI and partly collector (CAIDA PFX2ASN), yours is only collectors so I would assume the differences are between the RPKI and collectors but let's see.
05:36 < sipa> Did you see my asmap-tool.py that can compute a diff of mappings (either in txt or binary form)?
05:37 < fjahr> Since I discarded a random ROA if there were multiple for the same IP block, that alone could explain multiple % of differences
05:37 < sipa> https://github.com/sipa/asmap/blob/nextgen/asmap-tool.py
05:37 < fjahr> I saw it yeah, I will use it, also asmapy has some diff logic that I wanted the test/review as well
05:38 < sipa> It was something like 10-20% of the internet was mapped differently.
05:38 < fjahr> It's a jungle out there :)
05:38 < sipa> yeah
05:40 < brunoerg> @fjahr: I created the diff tool on asmapy from the sipa's one, they're basically similar.
05:40 < fjahr> sipa: ah, what's the time delta between your file and mine? Did you use collector data from the same day?
05:41 < fjahr> brunoerg: ok
05:41 < sipa> i created mine yesterday
05:41 < sipa> now there is a % difference even between two consecutive days, with the same data sources and tooling
05:41 < sipa> but the difference i saw between yours and mine was way bigger than that
05:42 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Quit: = ""]
05:42 < fjahr> ok, will investigate
05:50 -!- Norrin [~NorrinRad@gateway/tor-sasl/norrinradd] has quit [Ping timeout: 255 seconds]
05:51 -!- Norrin [~NorrinRad@gateway/tor-sasl/norrinradd] has joined #bitcoin-core-dev
05:54 < sipa> @fjahr Does your code do bottleneck analysis actually? (if all routes to an IP range X go through the same last two ASNs, you list the first of those as that range's AS rather than the last one)?
05:56 -!- halosghost [~halosghos@user/halosghost] has joined #bitcoin-core-dev
05:56 -!- yanmaani [~yanmaani@gateway/tor-sasl/yanmaani] has quit [Ping timeout: 255 seconds]
06:06 -!- virtu [~virtu@2001:470:69fc:105::2:c105] has joined #bitcoin-core-dev
06:07 -!- virtu [~virtu@2001:470:69fc:105::2:c105] has quit [Changing host]
06:07 -!- virtu [~virtu@user/virtu] has joined #bitcoin-core-dev
06:12 -!- Norrin [~NorrinRad@gateway/tor-sasl/norrinradd] has quit [Ping timeout: 255 seconds]
06:17 -!- Norrin [~NorrinRad@gateway/tor-sasl/norrinradd] has joined #bitcoin-core-dev
06:24 < fjahr> sipa: No, I don’t use a BGP dump right now so I don’t see that data. I am not sure yet if the bottleneck logic is really an improvement when using collector data since it can also be an attack vector. But I haven’t had enough time to form an opinion. I will compare datasets with and without bottleneck logic to see how much of the difference it explains. The ROAs authenticate the announcing ASN so it will probably be 
06:24 < fjahr> the last one usually. Everything else being equal I am not sure what might be better: an authenticated source or and unauthenticated bottleneck. But I have a feeling that some of this will also be resolved via the multimap stuff, i.e. if one ASN is a bottleneck to another ASN, I think there is a high chance that these ASNs are the same entity or related and then (if they use RPKI) hopefully they also authenticate both ASNs 
06:24 < fjahr> for the IP block that the one ASN is the bottleneck for. But this already on my list to explore further as well :)
06:25 < sipa> Ah, I see. That would be a big reason why we'd see differences between the resulting data.
06:26 < sipa> I'll redo but without the bottleneck logic, and see if that results in a smaller diff.
06:27 < sipa> Yeah, I'm not sure what's best either (unauthenticated bgpdump with bottleneck analysis, or authenticated data source that doesn't support that).
06:29 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Remote host closed the connection]
06:29 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #bitcoin-core-dev
06:32 < fjahr> Thanks! Yeah, maybe even both things can be combined in some way that also requires more research.
06:36 -!- yanmaani [~yanmaani@gateway/tor-sasl/yanmaani] has joined #bitcoin-core-dev
06:36 -!- yanmaani [~yanmaani@gateway/tor-sasl/yanmaani] has quit [Remote host closed the connection]
06:37 -!- yanmaani [~yanmaani@gateway/tor-sasl/yanmaani] has joined #bitcoin-core-dev
06:52 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:dc72:ba28:fc:9810] has quit [Remote host closed the connection]
06:53 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:dc72:ba28:fc:9810] has joined #bitcoin-core-dev
07:11 < bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/ea41abade4b7...b3ef3291993d
07:11 < bitcoin-git> bitcoin/master fa486de MarcoFalke: ci: Cache package manager install step
07:11 < bitcoin-git> bitcoin/master b3ef329 MarcoFalke: Merge bitcoin/bitcoin#26976: ci: Cache package manager install step
07:11 < bitcoin-git> [bitcoin] MarcoFalke merged pull request #26976: ci: Cache package manager install step (master...2301-ci-cache-apt-🚴) https://github.com/bitcoin/bitcoin/pull/26976
07:14 -!- Yihen [~textual@122.115.32.55] has quit [Ping timeout: 252 seconds]
07:34 < bitcoin-git> [bitcoin] fanquake opened pull request #27027: build: use _FORTIFY_SOURCE=3 (master...fortify_source_3) https://github.com/bitcoin/bitcoin/pull/27027
07:48 < bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/b3ef3291993d...c2028f98aec3
07:48 < bitcoin-git> bitcoin/master fa6986a MarcoFalke: ci: Print iwyu patch in git diff format
07:48 < bitcoin-git> bitcoin/master c2028f9 fanquake: Merge bitcoin/bitcoin#27012: ci: Print iwyu patch in git diff format
07:48 < bitcoin-git> [bitcoin] fanquake merged pull request #27012: ci: Print iwyu patch in git diff format (master...2302-ci-iwyu-git-diff-📖) https://github.com/bitcoin/bitcoin/pull/27012
07:52 -!- AaronvanW [~AaronvanW@user/AaronvanW] has quit [Remote host closed the connection]
07:53 -!- b_101 [~robert@fixed-187-189-246-111.totalplay.net] has joined #bitcoin-core-dev
07:57 -!- b_101 [~robert@fixed-187-189-246-111.totalplay.net] has quit [Ping timeout: 248 seconds]
07:58 -!- b_101 [~robert@fixed-187-189-246-111.totalplay.net] has joined #bitcoin-core-dev
08:03 -!- b_101 [~robert@fixed-187-189-246-111.totalplay.net] has quit [Ping timeout: 252 seconds]
08:04 -!- b_101 [~robert@fixed-187-189-246-111.totalplay.net] has joined #bitcoin-core-dev
08:08 -!- b_101 [~robert@fixed-187-189-246-111.totalplay.net] has quit [Ping timeout: 260 seconds]
08:09 -!- b_101 [~robert@fixed-187-189-246-111.totalplay.net] has joined #bitcoin-core-dev
08:10 -!- MrFrancis [~MrFrancis@2001:8a0:fa4c:901:8d8b:fd03:72e6:773e] has joined #bitcoin-core-dev
08:15 < instagibbs> with nanobench is there a way to do expensive prep outside of actual measured run? or do something like a "lap" functionality to see how long each section takes?
08:15 < instagibbs> read the docs and couldnt find anything like that
08:16 < fanquake> think you can just do it before calling bench.run()?
08:17 -!- b_101 [~robert@fixed-187-189-246-111.totalplay.net] has quit [Ping timeout: 248 seconds]
08:17 < instagibbs> if it doesn't have to be redone yeah
08:18 -!- b_101 [~robert@fixed-187-189-246-111.totalplay.net] has joined #bitcoin-core-dev
08:19 < sipa> i was going to suggest the same; if that's not what you mean, I'm not sure I understand the question
08:21 < instagibbs> If there's expensive prep that is blown away by each run, is there a way to do the expensive prep i nthe loop but not count towards the bench
08:21 < instagibbs> Alternative question: is there a cheap way to clone a CTxMemPool :)
08:22 < bitcoin-git> [bitcoin] MarcoFalke opened pull request #27028:  ci: Cache more stuff in the ci images: msan, iwyu, pip, sdks  (master...2301-ci-cache-apt-🚴) https://github.com/bitcoin/bitcoin/pull/27028
08:22 < sipa> Create two benchmarks, one with just the prep step, and another with both the prep and the benchmark?
08:22 < instagibbs> true
08:22 -!- b_101 [~robert@fixed-187-189-246-111.totalplay.net] has quit [Ping timeout: 248 seconds]
08:23 -!- AaronvanW [~AaronvanW@user/AaronvanW] has joined #bitcoin-core-dev
08:23 < sipa> it may very well destroy all precision your benchmark has, though
08:23 -!- b_101 [~robert@fixed-187-189-246-111.totalplay.net] has joined #bitcoin-core-dev
08:23 < sipa> because you'll be subtracting two very close numbers both with relative errors
08:23 -!- SpellChecker [~SpellChec@user/SpellChecker] has quit [Ping timeout: 255 seconds]
08:24 -!- SpellChecker_ [~SpellChec@user/SpellChecker] has joined #bitcoin-core-dev
08:24 < instagibbs> depends on how bad this scales, but noted
08:27 -!- b_101 [~robert@fixed-187-189-246-111.totalplay.net] has quit [Ping timeout: 252 seconds]
08:28 < bitcoin-git> [bitcoin] hebasto closed pull request #23609: build: Add -fvisibility=hidden flag for macOS host (master...211126-reduce) https://github.com/bitcoin/bitcoin/pull/23609
08:41 -!- roze_paul [~quassel@142.243.254.224] has joined #bitcoin-core-dev
08:51 < bitcoin-git> [bitcoin] fanquake opened pull request #27029: guix: consolidate to glibc 2.27 for Linux builds (master...glibc_2_27) https://github.com/bitcoin/bitcoin/pull/27029
08:54 < bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/c2028f98aec3...7753efcbcf3c
08:54 < bitcoin-git> bitcoin/master fab9f7d MarcoFalke: test: Use std::unique_ptr over manual delete in coins_tests
08:54 < bitcoin-git> bitcoin/master 7753efc fanquake: Merge bitcoin/bitcoin#27004: test: Use std::unique_ptr over manual delete ...
08:54 < bitcoin-git> [bitcoin] fanquake merged pull request #27004: test: Use std::unique_ptr over manual delete in coins_tests (master...2301-test-uniq-ptr-🕴) https://github.com/bitcoin/bitcoin/pull/27004
08:55 -!- sudoforge [~sudoforge@wireguard/tunneler/sudoforge] has quit [Ping timeout: 265 seconds]
09:08 -!- qxs [~qxs@gateway/tor-sasl/qxs] has quit [Remote host closed the connection]
09:08 -!- qxs [~qxs@gateway/tor-sasl/qxs] has joined #bitcoin-core-dev
09:08 < sipa> @fjahr I probably won't be around for today's IRC meeting.
09:13 -!- FrancisMr [~MrFrancis@2001:8a0:fa4c:901:8d8b:fd03:72e6:773e] has joined #bitcoin-core-dev
09:14 < fjahr> sipa: I am sure it won't be the last on this topic, thanks for the useful feedback so far!
09:16 -!- MrFrancis [~MrFrancis@2001:8a0:fa4c:901:8d8b:fd03:72e6:773e] has quit [Ping timeout: 248 seconds]
09:21 -!- salvatoshi [~salvatosh@genymobile-2-6-86.fib.nerim.net] has quit [Ping timeout: 252 seconds]
09:30 -!- as2333 [~as2333@host230.190-138-75.telecom.net.ar] has joined #bitcoin-core-dev
09:33 -!- Guest7 [~Guest7@2409:4071:e8c:ca9a:45ae:c5cd:4c36:6606] has joined #bitcoin-core-dev
09:35 -!- Guest7 [~Guest7@2409:4071:e8c:ca9a:45ae:c5cd:4c36:6606] has quit [Client Quit]
09:53 -!- yanmaani [~yanmaani@gateway/tor-sasl/yanmaani] has quit [Ping timeout: 255 seconds]
09:54 -!- yanmaani [~yanmaani@gateway/tor-sasl/yanmaani] has joined #bitcoin-core-dev
09:59 -!- roze_paul [~quassel@142.243.254.224] has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
10:07 -!- Norrin [~NorrinRad@gateway/tor-sasl/norrinradd] has quit [Remote host closed the connection]
10:09 -!- qxs [~qxs@gateway/tor-sasl/qxs] has quit [Remote host closed the connection]
10:10 -!- qxs [~qxs@gateway/tor-sasl/qxs] has joined #bitcoin-core-dev
10:11 -!- Guest45_ [~textual@2601:248:500:2da0::318a] has joined #bitcoin-core-dev
10:13 -!- Talkless [~Talkless@mail.dargis.net] has joined #bitcoin-core-dev
10:39 -!- Guest45_ [~textual@2601:248:500:2da0::318a] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
10:43 -!- FrancisMr [~MrFrancis@2001:8a0:fa4c:901:8d8b:fd03:72e6:773e] has quit [Ping timeout: 252 seconds]
10:46 -!- FrancisMr [~MrFrancis@2001:8a0:fa4c:901:8d8b:fd03:72e6:773e] has joined #bitcoin-core-dev
10:50 -!- Guest45_ [~textual@2601:248:500:2da0::318a] has joined #bitcoin-core-dev
10:52 -!- pablomartin [~pablomart@5-101-143-126.as42831.net] has joined #bitcoin-core-dev
10:54 -!- hernanmarino [~hernanmar@181.99.169.107] has joined #bitcoin-core-dev
10:56 -!- Guest45_ [~textual@2601:248:500:2da0::318a] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
10:58 -!- Guest45_ [~textual@2601:248:500:2da0::318a] has joined #bitcoin-core-dev
10:58 -!- b_101 [~robert@fixed-187-189-246-111.totalplay.net] has joined #bitcoin-core-dev
11:00 < MacroFake> hi
11:00 < warren> hi
11:00 < achow101> #startmeeting
11:00 <@core-meetingbot> Meeting started Thu Feb  2 19:00:22 2023 UTC.  The chair is achow101. Information about MeetBot at https://bitcoin.jonasschnelli.ch/ircmeetings.
11:00 <@core-meetingbot> Available commands: action commands idea info link nick
11:00 < brunoerg> hi
11:00 < achow101> #bitcoin-core-dev Meeting: achow101 aj amiti ariard b10c BlueMatt cfields Chris_Stewart_5 darosior digi_james dongcarl elichai2 emilengler fanquake fjahr gleb glozow gmaxwell gwillen hebasto instagibbs jamesob jarolrod jb55 jeremyrubin jl2012 jnewbery jonasschnelli jonatack jtimon kallewoof kanzure kvaciral laanwj larryruane lightlike luke-jr maaku marcofalke meshcollider michagogo moneyball morcos nehan NicolasDorier paveljanik petertodd 
11:00 < achow101> phantomcircuit promag provoostenator ryanofsky sdaftuar sipa vasild
11:00 < hebasto> hi
11:00 < fjahr> hi
11:00 < jon_atack> hi
11:00 < furszy> hi
11:00 < lightlike> hi
11:01 < achow101> There are two preproposed meeting topics: ASMap in the release process (fjahr), Self-hosted Gitlab instance (fjahr)
11:01 < achow101> anything else to add to the list?
11:01 < glozow> hi
11:01 < pinheadmz> hi
11:01 < achow101> #topic high priority for review
11:01 <@core-meetingbot> topic: high priority for review
11:01 < MacroFake> for me plz: https://github.com/bitcoin-core/gui/pull/697 (Remove reindex special case from the progress bar label) 
11:02 < achow101> https://github.com/orgs/bitcoin/projects/1
11:02 < LarryRuane> hi
11:02 < achow101> anything to add/remove/merge?
11:02 < kanzure> hi
11:03 < achow101> MacroFake: done
11:03 < MacroFake> thanks!
11:04 < achow101> #22693 and #25740 are both recently needs rebase
11:04 <@gribble> https://github.com/bitcoin/bitcoin/issues/22693 | RPC/Wallet: Add "use_txids" to output of getaddressinfo by luke-jr · Pull Request #22693 · bitcoin/bitcoin · GitHub
11:04 <@gribble> https://github.com/bitcoin/bitcoin/issues/25740 | assumeutxo: background validation completion by jamesob · Pull Request #25740 · bitcoin/bitcoin · GitHub
11:04 -!- darosior [~darosior@194.36.189.246] has quit [Read error: Connection reset by peer]
11:04 -!- darosior [~darosior@194.36.189.246] has joined #bitcoin-core-dev
11:05 < achow101> #topic ASMap in the release process (fjahr)
11:05 <@core-meetingbot> topic: ASMap in the release process (fjahr)
11:06 < fjahr> Hi, first of all, sorry about the wordy write-up, I should have included a tldr; I just wrote a quick one for those that didn’t have the time to read it. The main points I am making are: 1. In order to ship an asmap file with the release we want to make sure it’s the best quality data. The main way to QA was assumed to be based on diffing files. I tried to find a systematical way to do QA via diffs so I don’t think it 
11:06 < fjahr> is a reliable option. 2. Instead we should make the asmap creation process transparent and reproducible. The asmap file should be treated like a PR, it will be presented and reviewers can test and run QA on it as they like but that is not part of the release process or responsibility of maintainer. 3. Quality of the input data is even more important. I believe that for our purpose rpki > irr > collectors, in terms of 
11:06 < fjahr> quality. So far only collectors were considered as an input source.
11:06 < fjahr> Thanks to everyone who provided feedback so far! There was some nice feedback from sipa here earlier today, it shows that in the process of joining the input data the devil is in the details and there is still more research to be done but I think it’s moving in the right direction. Also my code is buggy ^^
11:06 < achow101> doesn't getting asmap data require having your own AS?
11:07 < fjahr> I would like to answer any questions and take feedback on what is bothering people.
11:07 < sipa> hi, i'm half here
11:07 < fjahr> achow101: there are lots of open sources for data. the approaches we are discussing are all built on those.
11:08 < achow101> i should probably read the backscroll
11:08 < fjahr> But if you have any way to open a BGP session, you can collect the global feed youself and for some people that may be a preferred aproach
11:09 < fjahr> But most people probably won't be able to do it
11:09 < fjahr> Achow101: the "general knowledge" section in the write-up should be interesting :)
11:09 < fjahr> https://gist.github.com/fjahr/bf0ff0917e03a4e49fac0617b2b35747
11:09 < sipa> As I understand it, there are 2 main ways of building the data: (a) from BGP routes (which requires being your own BGP node, or getting trusted data from someone dumping it) or (b) authoritatively from the assigmed mappings directly.
11:09 < brunoerg> > The main way to QA was assumed to be based on diffing files
11:10 < achow101> #link https://gist.github.com/fjahr/bf0ff0917e03a4e49fac0617b2b35747
11:10 < brunoerg> I agree, but what should we compare? 
11:11 < fjahr> My opinion the diffing question: That’s probably the most controversial point among those that have dove deeper into the topic. In short: I just couldn’t find any way to develop a concise set of rules that could be giving a clear indication if a file is safe/unsafe and I tried really hard (TM). So I think if we tell people they can run a diff and there is a X% match on metric Y that means it’s safe, then we give 
11:11 < fjahr> people a false sense of security at best, at worst the release process becomes a mess because people are unsure if the numbers mean the file is safe or not and then nobody ends up using it. I am happy to review if people have suggestions for this but if we wait for this then the process will drag on for a while IMO.
11:11 -!- darosior [~darosior@194.36.189.246] has quit [Ping timeout: 248 seconds]
11:11 < sipa> FWIW, I concur that diffing isn't viable as a means of QA (or not the primary one at least), the differences from maps constructed from one day to another often have substantial changes already (more than you as a human could look at and judge "this looks reasonable" or not).
11:11 < fjahr> So, I think "we" as in as a part of the release process shouldn't compare anything IMO
11:12 < lightlike> fjahr: but what should a reviewer do in order to ack the PR?
11:12 < fjahr> But anyone can run experiments, that's what the review phase is for
11:12 < brunoerg> I made an experiment generating 2 files from 2 last Core's release date and there was A LOT of changes
11:12 < fjahr> lightlike: that's up to the reviewer, I mean I don't tell people how to review my PRs
11:13 < fjahr> of course there will be knowledge sharing and tools written for this
11:13 < fjahr> but people can not expect Bitcoin core maintainers to do that work for them
11:13 < sipa> As I understand it, @fjahr's suggesting is that we effectively establish a reproducible process for building the maps, so hopefully it suffices for some reviewers to actually reproduce it
11:13 < fjahr> brunoerg: yepp, and that's the problem
11:14 < sipa> Though what that process would be seems a bit unspecified for now?
11:14 < brunoerg> @fjahr: but in that PR you would tell how you generated that file in order to reviewers to follow the same step?
11:15 < fjahr> sipa: will need to be specified a lot more in detail, yes
11:15 < fjahr> brunoerg: from the same raw files, yes
11:15 < jamesob> achow101: thanks for the ping, I'll rebase AU momentarily
11:15 < brunoerg> cool
11:16 < fjahr> the raw files are also uploaded in the zip file
11:17 < achow101> that doesn't really solve the problem though, the raw files could just be malicious
11:17 < sipa> Maybe a bit more practical, do you expect that the txt range/asn map file will become part of the bitcoin core source repo? or just the combined binary dat file? or neither?
11:18 < sipa> binary file is roughly 1.2 MB right now
11:18 < fjahr> For the RPKI data the only way it could be malicious is there could be stuff missing
11:18 < fjahr> everything else can be malicious, yes, but that the general crux with BGP
11:19 < fjahr> so you can be Amazon or the NSA and still end up with a BGP hijack in your routing table
11:19 -!- Guest45_ [~textual@2601:248:500:2da0::318a] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
11:19 < sipa> RPKI is signed, right?
11:20 < fjahr> sipa: I think not in the source, I mean it's possible, but it seems more elegant to have the candidates in asmap-data seperately and only join it during build process
11:20 < fjahr> sipa: yes
11:21 < achow101> do we expect asmap to be in our release distributions?
11:21 < fjahr> The easiest way to explain it is: RPKI is SSL for BGP (very roughly)
11:21 < fjahr> achow101: that is kind of the goal
11:22 < sipa> @achow101 My hope is that eventually it'll end up being part of the binary, or a separately-distributed file that's part of the installation and used by default
11:22 < fjahr> *end goal, there may be intermittend steps where it's not the default etc.
11:23 < fjahr> The one downside of RPKI is it's not deployed everywhere so it can not be the only data source
11:24 < sipa> but we could use RPKI as primary, and only use other sources for ranges for which RPKI is not available?
11:24 < fjahr> yes, that is the approach I build with kartograf
11:25 < fjahr> It's a POC: https://github.com/fjahr/kartograf
11:25 -!- Guest45_ [~textual@2601:248:500:2da0::318a] has joined #bitcoin-core-dev
11:27 < fjahr> A few people have asked this: yes, I will also post this to the ML soon, just wanted to hear from this group first, particular potential pushback on the release process stuff
11:28 -!- darosior [~darosior@194.36.189.246] has joined #bitcoin-core-dev
11:28 < fjahr> Any more questions? I am happy to answer at any time here or in DMs, I hope we can get as many people onboard on this problem space as possible to get more review :)
11:30 < achow101> thanks for reviving this project. I'll have to do some more reading before I can give an feedback
11:30 < achow101> #topic Self-hosted Gitlab instance (fjahr)
11:30 < fjahr> achow101: great, thanks!
11:30 <@core-meetingbot> topic: Self-hosted Gitlab instance (fjahr)
11:30 < fjahr> Err, basically I just wanted to repeat what I said earlier: Just a quick announcement/invite if someone wants to get access and try stuff out, also happy to share admin access with the people I know, it’s a playground. Currently some key features are missing because it’s on the Community Plan but there are open source specific licenses and Mike Schmidt has been in contact with them already about an Enterprise license, 
11:30 < fjahr> we’ll probably coordinate more on that soon. But I am a more focussed on ASMap for now tbh.
11:31 < fjahr> It’s here: gitlab.sighash.org, but requires registration to see anything currently. No need for an email confirmation so you can enter whatever you want. Just ping me because I have to confirm you. I haven’t figured out all the settings so hopefully this will change as well soon.
11:31 < fjahr> That's already it, I wasn't present at the last core dev but I read the notes on the topic so I thought it might be helpful
11:31 -!- Guest45_ [~textual@2601:248:500:2da0::318a] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
11:32 < MacroFake> fjahr: Would be good to answer the basic questions from the wiki
11:32 < achow101> we have a wiki page with some links to older discussions on this topic: https://github.com/bitcoin-core/bitcoin-devwiki/wiki/GitHub-alternatives-for-Bitcoin-Core
11:32 < MacroFake> https://github.com/bitcoin-core/bitcoin-devwiki/wiki/GitHub-alternatives-for-Bitcoin-Core#evaluation-scheme
11:33 < fjahr> right, yeah, so if anyone wants to help me answer these questions, let me know :D
11:33 < jon_atack> achow101: i think the idea was to include the ASMap data in the distributed binary but not in the repository. discussion about this took place here: https://www.erisian.com.au/bitcoin-core-dev/log-2019-06-20.html#l-632
11:33 < jon_atack> (sorry, catching up)
11:35 < achow101> any other topics to discuss?
11:35 < jon_atack> achow101: mind adding https://github.com/bitcoin/bitcoin/pull/26283 to the blockers list?
11:36 < jon_atack> #26283
11:36 <@gribble> https://github.com/bitcoin/bitcoin/issues/26283 | p2p: Fill reconciliation sets and request reconciliation (Erlay) by naumenkogs · Pull Request #26283 · bitcoin/bitcoin · GitHub
11:36 -!- Guest45_ [~textual@2601:248:500:2da0::318a] has joined #bitcoin-core-dev
11:36 < jon_atack> seems to be in final review phase, i plan to get to it
11:36 < achow101> jon_atack: done
11:36 < jon_atack> achow101: ty
11:36 < achow101> #endmeeting
11:36 <@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
11:36 <@core-meetingbot> Meeting ended Thu Feb  2 19:36:53 2023 UTC.  
11:36 <@core-meetingbot> Minutes:        https://bitcoin.jonasschnelli.ch/ircmeetings/logs/bitcoin-core-dev/2023/bitcoin-core-dev.2023-02-02-19.00.moin.txt
11:39 < jon_atack> added it to https://github.com/orgs/bitcoin/projects/5/views/1 as well
11:43 < MacroFake> fjahr: Could add a "Sign in with GitHub" to your Gitlab?
11:44 < fjahr> ser, didn't we want to leave GH? ;)
11:44 < fjahr> I will check :)
11:47 -!- AaronvanW [~AaronvanW@user/AaronvanW] has quit [Quit: Leaving...]
11:50 < MacroFake> fjahr: Yeah, not sure if I was trolling
11:52 -!- qxs [~qxs@gateway/tor-sasl/qxs] has quit [Remote host closed the connection]
11:55 -!- qxs [~qxs@gateway/tor-sasl/qxs] has joined #bitcoin-core-dev
12:00 -!- Guest45_ [~textual@2601:248:500:2da0::318a] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
12:00 -!- AlissonM [~AlissonM@dynamic-089-204-137-096.89.204.137.pool.telefonica.de] has joined #bitcoin-core-dev
12:01 -!- AlissonM [~AlissonM@dynamic-089-204-137-096.89.204.137.pool.telefonica.de] has quit [Client Quit]
12:03 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:dc72:ba28:fc:9810] has quit [Remote host closed the connection]
12:04 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-dev
12:08 -!- Guest45_ [~textual@2601:248:500:2da0::318a] has joined #bitcoin-core-dev
12:08 < MacroFake> Basic downside would likely be that someone (who?) would need to host the server, do sysadmin stuff, do anti-DoS, run the CI
12:08 -!- scg [~scg@161.132.197.96] has quit [Ping timeout: 260 seconds]
12:09 < MacroFake> If any of this breaks down, and the person is on holiday, the whole project will be on forced holiday
12:09 < bitcoin-git> [bitcoin] hebasto closed pull request #26763: ci: Treat IWYU violations as errors (master...221228-iwyu) https://github.com/bitcoin/bitcoin/pull/26763
12:12 < bitcoin-git> [bitcoin] hebasto closed pull request #26766: ci: Use clang-15 and IWYU v0.19 in "tidy" task (master...221228-clang15) https://github.com/bitcoin/bitcoin/pull/26766
12:12 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Remote host closed the connection]
12:13 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-dev
12:16 -!- Talkless [~Talkless@mail.dargis.net] has quit [Quit: Konversation terminated!]
12:26 < fjahr> MacroFake: Yeah, I have only started to think about this, I think one possible solution could be that multiple people run their own instances and they are syncing the main instance and if the main instance is attacked one of the old followers becomes the new main instance, but it sounds pretty dirty...
12:26 -!- pablomartin4btc [~pablomart@5-101-143-126.as42831.net] has joined #bitcoin-core-dev
12:27 < MacroFake> Is there support for syncing on GitLab?
12:27 < fjahr> I am not sure gitlab is the best solution but it was the easiest to set up and several people seemed eager to try, so I am just experimenting
12:27 < fjahr> yeah
12:27 -!- pablomartin [~pablomart@5-101-143-126.as42831.net] has quit [Ping timeout: 268 seconds]
12:27 < MacroFake> I mean all of the stuff (issues, comments, reviews, ....)
12:27 < MacroFake> Doing a git mirror is trivial
12:27 < fjahr> quite a lot, between GH and GL, between GL and GL self-hosted/enterprise
12:28 < fjahr> yeah all of it as far as I understood, I pull all of that from GH over to my GL instance
12:29 < fjahr> it's just stuck now on the state from a week ago because continuous sync is an enterprise license feature and we haven't gotten that yet
12:32 -!- Guest45_ [~textual@2601:248:500:2da0::318a] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
12:32 -!- Guest45_ [~textual@2601:248:500:2da0::318a] has joined #bitcoin-core-dev
12:34 -!- Guest45_ [~textual@2601:248:500:2da0::318a] has quit [Client Quit]
12:45 -!- FrancisMr [~MrFrancis@2001:8a0:fa4c:901:8d8b:fd03:72e6:773e] has quit [Ping timeout: 248 seconds]
12:49 -!- b_101 [~robert@fixed-187-189-246-111.totalplay.net] has quit [Ping timeout: 252 seconds]
12:51 < fjahr> MacroFake: Given that the syncing between GH and GL seems pretty good, one simple step would be to configure an official mirror on GL (official, not self-hosted) that just keeps syncing. That would at least give a simple backup in case GH becomes hostile but GL doesn't (yet). It's from one central entity to another but nobody has to run infra. Not sure if this was already discussed or maybe someone is already doing this in 
12:51 < fjahr> a private repo...
12:51 -!- b_101 [~robert@fixed-187-189-246-111.totalplay.net] has joined #bitcoin-core-dev
12:52 < MacroFake> Running a backup sounds good. (There is a gh-meta backup, but it can't be browsed)
12:52 < MacroFake> Though, if GitHub deletes the repo, then GitLab might as well?
12:54 < fjahr> sure, it's not a great protection in case of a real purge
12:54 -!- bugs_ [~bugs@user/bugs/x-5128603] has joined #bitcoin-core-dev
12:54 < MacroFake> Is there a service that hosts GitLab instances and promises to not delete them?
12:55 < fjahr> I think Tor does a similar think, I think GL is their main git host and they sync it to GH for visibility, seems to work well judging from outside
12:56 < fjahr> hehe, promises are meant to be broken
12:57 < fjahr> can we put the code on megaupload? %)
12:57 -!- b_101 [~robert@fixed-187-189-246-111.totalplay.net] has quit [Ping timeout: 252 seconds]
12:58 < MacroFake> tor only mirrors the .git stuff on gh
12:58 -!- b_101 [~robert@fixed-187-189-246-111.totalplay.net] has joined #bitcoin-core-dev
12:59 < fjahr> hm, ok, probably they don't people to start commenting in GH thinking it's were the action is. Would be interesting to check if the conversations can be mirror while at the same time participation can be prevented.
13:00 < sipa> I don't think our concern isn't really mirrorring the git data. That's easy. It's having a place for development, which means having issues/prs/...
13:00 < fjahr> hosting the code in ordinal inscriptions? *hides*
13:02 < fjahr> sipa: yeah the syncing of that works well between GH and GL, so at least there could be a quick switch
13:03 -!- b_101 [~robert@fixed-187-189-246-111.totalplay.net] has quit [Ping timeout: 252 seconds]
13:03 -!- halo [~halosghos@user/halosghost] has joined #bitcoin-core-dev
13:03 -!- guest5 [~guest5@41.83.135.140] has joined #bitcoin-core-dev
13:04 -!- b_101 [~robert@fixed-187-189-246-111.totalplay.net] has joined #bitcoin-core-dev
13:04 -!- ___nick___ [~quassel@cpc68289-cdif17-2-0-cust317.5-1.cable.virginm.net] has quit [Ping timeout: 248 seconds]
13:04 -!- halosghost [~halosghos@user/halosghost] has quit [Ping timeout: 264 seconds]
13:05 < fjahr> Maybe a self-hosted GL that follows GH with everything and can't be shut down like a repo on GL.com is the best trade-off, it could be kept private until its needed and then the hosting isn't that big of a challenge while it's not in use and it's not too bad if it goes down for a day. The sync can catch up.
13:07 < fjahr> The setup isn't so hard, but the license is needed. And the license stuff also makes me a bit suspicious that GL could shut down a self-hosted instance too, but didn't research that yet.
13:08 -!- b_101 [~robert@fixed-187-189-246-111.totalplay.net] has quit [Ping timeout: 248 seconds]
13:10 -!- b_101 [~robert@fixed-187-189-246-111.totalplay.net] has joined #bitcoin-core-dev
13:10 < MacroFake> which of the 13 gitlab legal entities would be responsible for the project? :sweat-smile: https://about.gitlab.com/company/visiting/
13:11 < fjahr> it's a 1 out of 13 multisig probably
13:12 -!- salvatoshi [~salvatosh@lfbn-idf3-1-333-227.w83-199.abo.wanadoo.fr] has joined #bitcoin-core-dev
13:15 -!- sudoforge [~sudoforge@wireguard/tunneler/sudoforge] has joined #bitcoin-core-dev
13:17 -!- b_101 [~robert@fixed-187-189-246-111.totalplay.net] has quit [Ping timeout: 268 seconds]
13:18 -!- b_101 [~robert@fixed-187-189-246-111.totalplay.net] has joined #bitcoin-core-dev
13:20 < MacroFake> fjahr: You could start your asmap repo on GitLab to start fetching experience
13:20 < MacroFake> I might move some of mine
13:23 -!- b_101 [~robert@fixed-187-189-246-111.totalplay.net] has quit [Ping timeout: 268 seconds]
13:24 -!- Norrin [~NorrinRad@gateway/tor-sasl/norrinradd] has joined #bitcoin-core-dev
13:24 < fjahr> MacroFake: the downside is it creates a bit bigger barrier for getting other people involved that are primarily on GH, but I will experiment and move something over I think
13:25 < MacroFake> fjahr: Well, if that is a reason, then we wouldn't want to move the other repos as well, unless they are already gone?
13:27 < fjahr> do you mean moving or mirroring? The mirroring allows to move when the mirrored repo is suddenly gone, no need to move before that.
13:28 < fjahr> I understand move as making it the primary place were development and discussion happens
13:29 < MacroFake> Yeah, but then it should be a read-only mirror to avoid confusion, unless there is a two-way sync?
13:29 < fjahr> there is even two way sync functionality but that sounds like asking for trouble
13:30 < MacroFake> heh, right
13:32 < fjahr> maybe we should play it through with a fake repo on GH, create some PRs, make som discussion, read-only mirror it on a self-hosted GL and then delete the GH and switch over to the GL mirror and continue development there
13:37 -!- Guest45_ [~textual@2601:248:500:2da0::318a] has joined #bitcoin-core-dev
13:39 -!- b_101 [~robert@fixed-187-189-246-111.totalplay.net] has joined #bitcoin-core-dev
13:39 -!- Guest45_ [~textual@2601:248:500:2da0::318a] has quit [Client Quit]
13:39 < fjahr> I will try this out
13:40 -!- Guest3312 [~Guest33@103.144.92.226] has joined #bitcoin-core-dev
13:44 -!- bugs_ [~bugs@user/bugs/x-5128603] has quit [Quit: Leaving]
13:44 -!- Guest3312 [~Guest33@103.144.92.226] has quit [Client Quit]
13:45 -!- Guest2003 [~Guest2003@103.144.92.230] has joined #bitcoin-core-dev
13:50 -!- pablomartin4btc [~pablomart@5-101-143-126.as42831.net] has quit [Quit: Leaving]
13:51 -!- Guest128 [~Guest12@27.57.138.226] has joined #bitcoin-core-dev
13:56 -!- halo is now known as alot
13:58 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Remote host closed the connection]
13:58 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:dc72:ba28:fc:9810] has joined #bitcoin-core-dev
14:03 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:dc72:ba28:fc:9810] has quit [Ping timeout: 255 seconds]
14:06 -!- Guest2003 [~Guest2003@103.144.92.230] has quit [Quit: Client closed]
14:14 -!- AaronvanW [~AaronvanW@user/AaronvanW] has joined #bitcoin-core-dev
14:14 -!- yanmaani [~yanmaani@gateway/tor-sasl/yanmaani] has quit [Ping timeout: 255 seconds]
14:17 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-dev
14:18 -!- yanmaani [~yanmaani@gateway/tor-sasl/yanmaani] has joined #bitcoin-core-dev
14:23 -!- hernanmarino [~hernanmar@181.99.169.107] has quit [Quit: Leaving]
14:28 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Remote host closed the connection]
14:28 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:dc72:ba28:fc:9810] has joined #bitcoin-core-dev
14:29 -!- salvatoshi [~salvatosh@lfbn-idf3-1-333-227.w83-199.abo.wanadoo.fr] has quit [Ping timeout: 268 seconds]
14:30 -!- b_101 [~robert@fixed-187-189-246-111.totalplay.net] has quit [Ping timeout: 252 seconds]
14:30 -!- yanmaani [~yanmaani@gateway/tor-sasl/yanmaani] has quit [Remote host closed the connection]
14:31 -!- b_101 [~robert@fixed-187-189-246-111.totalplay.net] has joined #bitcoin-core-dev
14:32 -!- Guest45_ [~textual@2601:248:500:2da0::318a] has joined #bitcoin-core-dev
14:32 -!- AaronvanW [~AaronvanW@user/AaronvanW] has quit [Quit: Leaving...]
14:52 -!- yanmaani [~yanmaani@gateway/tor-sasl/yanmaani] has joined #bitcoin-core-dev
14:57 -!- Guest45_ [~textual@2601:248:500:2da0::318a] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
15:05 -!- Zenton [~user@user/zenton] has quit [Ping timeout: 264 seconds]
15:07 -!- Zenton [~user@user/zenton] has joined #bitcoin-core-dev
15:12 -!- b_101 [~robert@fixed-187-189-246-111.totalplay.net] has quit [Ping timeout: 252 seconds]
15:12 -!- b_101 [~robert@fixed-187-189-246-111.totalplay.net] has joined #bitcoin-core-dev
15:13 -!- alot [~halosghos@user/halosghost] has quit [Quit: WeeChat 3.8]
15:17 -!- b_101 [~robert@fixed-187-189-246-111.totalplay.net] has quit [Ping timeout: 260 seconds]
15:18 -!- b_101 [~robert@fixed-187-189-246-111.totalplay.net] has joined #bitcoin-core-dev
15:18 -!- Guest128 [~Guest12@27.57.138.226] has quit [Quit: Client closed]
15:22 -!- yanmaani [~yanmaani@gateway/tor-sasl/yanmaani] has quit [Remote host closed the connection]
15:22 -!- yanmaani [~yanmaani@gateway/tor-sasl/yanmaani] has joined #bitcoin-core-dev
15:23 -!- b_101 [~robert@fixed-187-189-246-111.totalplay.net] has quit [Ping timeout: 248 seconds]
15:24 -!- b_101 [~robert@fixed-187-189-246-111.totalplay.net] has joined #bitcoin-core-dev
15:24 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:dc72:ba28:fc:9810] has quit [Remote host closed the connection]
15:25 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:dc72:ba28:fc:9810] has joined #bitcoin-core-dev
15:29 -!- b_101 [~robert@fixed-187-189-246-111.totalplay.net] has quit [Ping timeout: 260 seconds]
15:50 -!- b_101 [~robert@fixed-187-189-246-111.totalplay.net] has joined #bitcoin-core-dev
16:38 -!- Guest30 [~Guest30@67-2-38-200.slkc.qwest.net] has joined #bitcoin-core-dev
16:40 -!- Guest30 [~Guest30@67-2-38-200.slkc.qwest.net] has left #bitcoin-core-dev []
16:52 -!- Guest45_ [~textual@c-73-209-115-49.hsd1.il.comcast.net] has joined #bitcoin-core-dev
16:57 -!- sudoforge [~sudoforge@wireguard/tunneler/sudoforge] has quit [Quit: 404]
16:58 -!- guest5 [~guest5@41.83.135.140] has quit [Ping timeout: 260 seconds]
17:01 -!- FrancisMr [~MrFrancis@2001:8a0:fa4c:901:8d8b:fd03:72e6:773e] has joined #bitcoin-core-dev
17:10 -!- Guest45_ [~textual@c-73-209-115-49.hsd1.il.comcast.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
17:14 -!- nanotube [~nanotube@user/nanotube] has joined #bitcoin-core-dev
17:33 -!- jarthur [~jarthur@user/jarthur] has quit [Quit: jarthur]
17:52 -!- b_101 [~robert@fixed-187-189-246-111.totalplay.net] has quit [Ping timeout: 252 seconds]
17:53 -!- b_101 [~robert@fixed-187-189-246-111.totalplay.net] has joined #bitcoin-core-dev
17:58 -!- b_101 [~robert@fixed-187-189-246-111.totalplay.net] has quit [Ping timeout: 248 seconds]
18:04 -!- b_101 [~robert@187.189.246.111] has joined #bitcoin-core-dev
18:09 -!- b_101 [~robert@187.189.246.111] has quit [Ping timeout: 252 seconds]
18:44 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #bitcoin-core-dev
19:22 -!- jamesob [~jamesob@141.156.173.67] has quit [Read error: Connection reset by peer]
19:22 -!- jamesob [~jamesob@141.156.173.67] has joined #bitcoin-core-dev
19:25 -!- FrancisMr [~MrFrancis@2001:8a0:fa4c:901:8d8b:fd03:72e6:773e] has quit [Ping timeout: 248 seconds]
19:29 -!- b_101 [~robert@fixed-187-189-246-111.totalplay.net] has joined #bitcoin-core-dev
19:55 -!- PaperSword [~Thunderbi@securemail.qrsnap.io] has joined #bitcoin-core-dev
20:11 -!- jonatack1 [~jonatack@user/jonatack] has joined #bitcoin-core-dev
20:13 -!- jon_atack [~jonatack@user/jonatack] has quit [Ping timeout: 246 seconds]
21:01 -!- cmirror [~cmirror@4.53.92.114] has quit [Remote host closed the connection]
21:01 -!- cmirror [~cmirror@4.53.92.114] has joined #bitcoin-core-dev
21:27 -!- mably [uid99779@id-99779.helmsley.irccloud.com] has quit [Quit: Connection closed for inactivity]
22:02 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Ping timeout: 255 seconds]
22:05 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #bitcoin-core-dev
22:10 < bitcoin-git> [bitcoin] martinus opened pull request #27030: Update nanobench to version v4.3.10 (master...2023-02-update-nanobench) https://github.com/bitcoin/bitcoin/pull/27030
22:34 -!- as2333 [~as2333@host230.190-138-75.telecom.net.ar] has quit [Quit: as2333]
22:38 -!- b_101 [~robert@fixed-187-189-246-111.totalplay.net] has quit [Ping timeout: 268 seconds]
22:45 -!- Yihen [~textual@122.115.32.55] has joined #bitcoin-core-dev
23:23 -!- b_101 [~robert@fixed-187-189-246-111.totalplay.net] has joined #bitcoin-core-dev
23:27 -!- b_101 [~robert@fixed-187-189-246-111.totalplay.net] has quit [Ping timeout: 255 seconds]
23:39 -!- javi404 [~quassel@c-73-1-238-68.hsd1.fl.comcast.net] has quit [Ping timeout: 260 seconds]
23:43 -!- javi404 [~quassel@c-73-1-238-68.hsd1.fl.comcast.net] has joined #bitcoin-core-dev
--- Log closed Fri Feb 03 00:00:33 2023